View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015416||FPC||Compiler||public||2009-12-22 16:13||2020-03-05 09:09|
|Reporter||Igor Sudarikov||Assigned To|
|Summary||0015416: "OffsetOf(structutred type, field)" internal funtion feature request|
|Description||It 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.
|Tags||No tags attached.|
|Fixed in Revision|
||For records it is PtrUInt(@r.fField)-PtrUint(@r) btw|
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.
||imho, it is good to implement this function at least for variable or pointer|
||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.|
||There is no extra variable or whatever needed. ptruint(@trecord(nil^).field) is enough.|
||So this can be closed?|
||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.|
||To be honest, I agree with you.|
||I agree also, I hate this construct "ptruint(@trecord(nil^).field)" and I often wished something like OffsetOf|
||offsetof(type, member-designator) introduced as internal function in ANSI C99, look like it is realy need function, since it provided by standart.|
||Patches are welcome ;)|
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.
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. ;)
||If that is doable, that is fine with me too :-)|
||I also don't understand the difference between ofs(RecordType.Field) and the suggested Offset(RecordType, Field).|
The difference is that "ofs" does currently not support "RecordType.Field", but only "RecordVar.Field".
||Thinking some more, I don't think overloading functions like this is nice. I like offsetof better.|
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).
> 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.
||Of course I meant OffsetOf :). I'll fix it.|
||Asked again in thread, https://forum.lazarus.freepascal.org/index.php?topic=48749.msg351540#msg351540|
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..
|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|