Question about D's quantum-esque type system
nobody at mailinator.com
Wed Aug 16 13:03:27 PDT 2006
Sean Kelly wrote:
> nobody wrote:
>> It is my understanding that only structs guarantee you an order of the
>> fields you define while not allowing constructors. Which means whether
>> you want to initialize the fields via static struct building functions
>> or member functions you have no assurance the struct fields hold
>> meaningful data unless by happenstance you have a situation in which
>> the default values of the fields can be creatively used to get a
>> freshly initialized struct to be meaningful.
> For what it's worth, you can specify a default value for struct members,
> you just can't supply a this() function:
Thanks for your reply. D's default initialization was part of what I had in mind
when I suggested structs might sometimes be given sensible default values. I do
appreciate that you pointed that out in case I had missed it. The most frequent
case of grief on my part is getting arrays initialized in structs. Changing
default valued member fields is no problem. Allocating arrays twice is not
generally the sort of thing you want to have to do twice. The only sane default
seems to be null.
So now no matter how many functions you have to test for initialization in each.
The ones that really hurt are opIndex and opIndexAssign which are almost
certainly going to be down in the deepest loops.
>> However, classes allow a constructor but at the loss of any guarantee
>> of the order of the fields. So you can be sure your initialized class
>> starts out with meaningful values but you cannot map the class
>> instance directly onto some data structure in memory nor can a class
>> instance imitate a data structure.
> I'll admit I'm a bit disappointed that my .isizeof proposal was ignored,
> as it would have been nice to be able to construct class instances into
> static buffers. I would be surprised if member order were not
> guaranteed (though a more compact layout may be possible if the compiler
> could rearrange data), but offset is obviously affected by data in any
> parent classes.
http://www.digitalmars.com/d/class.html fields section says
"The D compiler is free to rearrange the order of fields in a class to
optimally pack them in an implementation-defined manner."
Implementation-defined seems to be more about aligning everything for fast acess
instead of compaction. The first 8 bytes of a TGA file represent 6 fields with
sizes (in order) <1, 1, 1, 2, 2, 1>. Even structs are 8 byte aligned by default
and so will move fields around for maximal alignment without specifically using
However, I take your point that even with order guaranteed it would be difficult
to get a class instance's fields mapped onto a random memory location. Certainly
.isizeof sounds like it might have helped.
More information about the Digitalmars-d-learn