www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Question about D's quantum-esque type system

reply nobody <nobody mailinator.com> writes:
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.

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.

So it seems you either know where the data is or you know it is meaningful. I 
think the only way I can see to have both happen is using a struct within a
class:

struct OderedData
{
   /* ordered data */
}

class InitializedData
{
   OrderedData* data;

   /* ctor[s], dtor */
}

I am curious whether I am correct and if so why D was designed this way?
Aug 16 2006
parent reply Sean Kelly <sean f4.ca> writes:
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: struct S { int x = 5; char y = 'a'; } void main() { S s; printf( "%d\n%c\n", s.x, s.y ); } prints: 5 a
 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. Sean
Aug 16 2006
parent nobody <nobody mailinator.com> writes:
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 align. 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.
Aug 16 2006