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?

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

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.