View Issue Details

IDProjectCategoryView StatusLast Update
0015416FPCCompilerpublic2020-03-05 09:09
ReporterIgor Sudarikov Assigned To 
Status feedbackResolutionopen 
Summary0015416: "OffsetOf(structutred type, field)" internal funtion feature request
DescriptionIt would be better to use such function instead of dirty tricks such as "PtrUInt(@TMyClass(nil).fField)".

Ability to easily know field offset is quite useful in some tasks such as binding to script libraries. Also, the described trick does not work for records.
TagsNo tags attached.
Fixed in Revision
Attached Files


Marco van de Voort

2009-12-22 16:37

manager   ~0033261

For records it is PtrUInt(@r.fField)-PtrUint(@r) btw

Igor Sudarikov

2009-12-22 16:52

reporter   ~0033262

I meant, there is no way of knowing record field offset without declaration of a variable of this record type ("r" in your case) or a pointer-to-record type ( PtrUInt(@PMyRecord(nil)^.fField) ).

Both ways require extra code not directly related to field offset calculation.


2009-12-23 23:54

reporter   ~0033294

imho, it is good to implement this function at least for variable or pointer

Jonas Schäfer

2009-12-26 15:13

reporter   ~0033326

I would support it. In my script library (Thorium) I had to declare global variables and calculate the offset in the initialization section which is not the best solution, in my opinion.


2009-12-26 16:10

administrator   ~0033330

There is no extra variable or whatever needed. ptruint(@trecord(nil^).field) is enough.

Marco van de Voort

2010-03-21 17:42

manager   ~0035881

So this can be closed?

Igor Sudarikov

2010-03-22 22:09

reporter   ~0035940

Of course it can be resolved as "won't fix". But I still think that such function provides a much cleaner way of knowing field offset than tricks described above.

Marco van de Voort

2010-03-26 11:14

manager   ~0036108

To be honest, I agree with you.

Ivo Steinmann

2010-04-28 00:59

developer   ~0037050

I agree also, I hate this construct "ptruint(@trecord(nil^).field)" and I often wished something like OffsetOf


2010-05-03 08:57

reporter   ~0037181

offsetof(type, member-designator) introduced as internal function in ANSI C99, look like it is realy need function, since it provided by standart.


2010-05-03 11:13

administrator   ~0037186

Patches are welcome ;)

Sven Barth

2011-03-05 12:19

manager   ~0046409

What about using "ofs"? It works only with variables and returns the absolute address of the field, but in most circumstances you should have a variable of that type nevertheless.


  TMyRecord: record
    i: LongInt;
    q: QWord;
    b: Boolean;

  t: TMyRecord;
  Writeln('t.i: ', ofs(t.i));
  Writeln('t.q: ', ofs(t.q));
  Writeln('t.b: ', ofs(t.b));

For those that are not satisfied by this: Extended "ofs" to support types as well should be easier than to add a complete new symbol. ;)


Marco van de Voort

2011-07-29 17:14

manager   ~0050268

If that is doable, that is fine with me too :-)

Paul Ishenin

2013-01-18 08:26

developer   ~0064982

I also don't understand the difference between ofs(RecordType.Field) and the suggested Offset(RecordType, Field).

Sven Barth

2013-01-18 13:11

manager   ~0064989

The difference is that "ofs" does currently not support "RecordType.Field", but only "RecordVar.Field".


Marco van de Voort

2013-01-20 01:19

manager   ~0065024

Thinking some more, I don't think overloading functions like this is nice. I like offsetof better.


2016-09-23 21:29

reporter   ~0094794

Last edited: 2016-09-28 09:49

View 5 revisions

OffsetOf would be extremely useful feature. Not just because it saves typing, but because OffsetOf can be used in constant expressions.

This is not possible with the pointer trick - code like this:

const C = SizeUInt(@Rec(NIL^).field);
var v: SizeUInt = SizeUInt(@Rec(NIL^).field);

will not compile (Error: Illegal expression).

By the way, is there any reason to implement it as OffsetOf(Rec, Field) rather than OffsetOf(Rec.Field).


2016-09-28 07:20

reporter   ~0094841

Last edited: 2016-09-28 08:10

View 2 revisions

> By the way, is there any reason to implement it as SizeOf(Rec, Field) rather than SizeOf(Rec.Field).
Probably because SizeOf(Rec.Field) is already implemented... for a couple of decades, if not mistaken ;-)

>Thinking some more, I don't think overloading functions like this is nice. I like offsetof better.
Too little, too late ;-) SizeOf() works for both accounts as well.


2016-09-28 09:48

reporter   ~0094848

Of course I meant OffsetOf :). I'll fix it.

Marco van de Voort

2020-03-03 13:17

manager   ~0121339

Asked again in thread,

jamie philbrook

2020-03-04 00:17

reporter   ~0121348

Yes, that would be nice feature of the compiler, I miss that from the Days of C/Asm.

 Also think about sizeless arrays of what ever type at the end of the Record would be nice too, instead of using the empty Record Hack..

Issue History

Date Modified Username Field Change
2009-12-22 16:13 Igor Sudarikov New Issue
2009-12-22 16:37 Marco van de Voort Note Added: 0033261
2009-12-22 16:52 Igor Sudarikov Note Added: 0033262
2009-12-23 23:54 AlexRayne Note Added: 0033294
2009-12-26 15:13 Jonas Schäfer Note Added: 0033326
2009-12-26 16:10 Florian Note Added: 0033330
2010-03-21 17:42 Marco van de Voort Note Added: 0035881
2010-03-22 22:09 Igor Sudarikov Note Added: 0035940
2010-03-26 11:14 Marco van de Voort Note Added: 0036108
2010-04-28 00:59 Ivo Steinmann Note Added: 0037050
2010-05-03 08:57 AlexRayne Note Added: 0037181
2010-05-03 11:13 Florian Note Added: 0037186
2011-03-05 12:19 Sven Barth Note Added: 0046409
2011-07-29 17:14 Marco van de Voort Note Added: 0050268
2013-01-18 08:26 Paul Ishenin Note Added: 0064982
2013-01-18 08:26 Paul Ishenin Status new => feedback
2013-01-18 13:11 Sven Barth Note Added: 0064989
2013-01-20 01:19 Marco van de Voort Note Added: 0065024
2016-09-23 21:29 p_daniel Note Added: 0094794
2016-09-23 21:32 p_daniel Note Edited: 0094794 View Revisions
2016-09-23 21:33 p_daniel Note Edited: 0094794 View Revisions
2016-09-23 21:35 p_daniel Note Edited: 0094794 View Revisions
2016-09-28 07:20 Lychee Note Added: 0094841
2016-09-28 08:10 Lychee Note Edited: 0094841 View Revisions
2016-09-28 09:48 p_daniel Note Added: 0094848
2016-09-28 09:49 p_daniel Note Edited: 0094794 View Revisions
2020-03-03 13:17 Marco van de Voort Note Added: 0121339
2020-03-04 00:17 jamie philbrook Note Added: 0121348