• nobody (22/22) Aug 16 2006 It is my understanding that only structs guarantee you an order of the f...
• Sean Kelly (23/35) Aug 16 2006 For what it's worth, you can specify a default value for struct members,...
• nobody (22/46) Aug 16 2006 Thanks for your reply. D's default initialization was part of what I had...

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?

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

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.