Is this really the best way to get the size of a class instance given the type?

  MyClass.classinfo.init.length;

--bb

Bill Baxter wrote:
> Is this really the best way to get the size of a class instance given the type?
> 
>   MyClass.classinfo.init.length;

Yes.  And this only works at run time.  I proposed a new .isizeof property to simplify things, but it didn't seem terribly popular.  See:

http://d.puremagic.com/issues/show_bug.cgi?id=88


Sean

I like isizeof better than classinfo.init.length.  Not only for brevity, but a compile time value could be useful.

"Sean Kelly" <sean@f4.ca> wrote in message news:ej9u8k$2ek2$1@digitaldaemon.com...
> Bill Baxter wrote:
>> Is this really the best way to get the size of a class instance given the type?
>>
>>   MyClass.classinfo.init.length;
>
> Yes.  And this only works at run time.  I proposed a new .isizeof property to simplify things, but it didn't seem terribly popular.  See:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=88
>
>
> Sean

Sean Kelly wrote:
> Bill Baxter wrote:
> 
>> Is this really the best way to get the size of a class instance given the type?
>>
>>   MyClass.classinfo.init.length;
> 
> 
> Yes.  And this only works at run time.  I proposed a new .isizeof property to simplify things, but it didn't seem terribly popular.  See:
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=88
> 
> 
> Sean

Well you've got my vote.  MyClass.classinfo.init.length is terribly unintuitive compared to sizeof(MyClass) in c++.

--bb

Sean Kelly wrote:
> Bill Baxter wrote:
>> Is this really the best way to get the size of a class instance given the type?
>>
>>   MyClass.classinfo.init.length;
> 
> Yes.  And this only works at run time.  I proposed a new .isizeof property to simplify things, but it didn't seem terribly popular.  See:
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=88
> 
> 
> Sean

I suppose sizeof(MyClass) could simply return the right value. I don't see how the size of a class' handle can be useful.

L.

Lionello Lunesu wrote:
> Sean Kelly wrote:
>> Bill Baxter wrote:
>>> Is this really the best way to get the size of a class instance given the type?
>>>
>>>   MyClass.classinfo.init.length;
>>
>> Yes.  And this only works at run time.  I proposed a new .isizeof property to simplify things, but it didn't seem terribly popular.  See:
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=88
>>
>>
>> Sean
> 
> I suppose sizeof(MyClass) could simply return the right value. I don't see how the size of a class' handle can be useful.
> 
> L.

I suspect the reason is that for doing various low-level things you might actually need to know how much space the thing is occupying on the stack.  Like a varargs, for instance.  You need to know how big the thing is on the stack to advance the _argptr properly.  It doesn't matter how big the instance data on the heap is.

I just now did a web search to see what other GC languages that hide pointers from you do.

Java just doesn't have sizeof apparently.

C# has it.  From the spec:
  "For all other (non predefined types), the result of the sizeof operator is implementation-defined and is classified as a value, not a constant.
...
When applied to an operand that has struct type, the result is the total number of bytes in a variable of that type, including any padding."

So basically it sounds like they say you can't count on sizeof(aclass) returning anything in particular.

I guess when it comes down to it, finding the size of a class is really only useful for satisfying one's curiosity and optimizing member orders to get better alignment.  And for that purpose I guess it doesn't really have to be that intuitive a name.

--bb

Bill Baxter wrote:
> 
> I guess when it comes down to it, finding the size of a class is really only useful for satisfying one's curiosity and optimizing member orders to get better alignment.  And for that purpose I guess it doesn't really have to be that intuitive a name.

But the existing method only works at run time, which doesn't allow for things like this:

    byte[MyClass.isizeof] buf;
    MyClass c = new(&buf[0]) MyClass();
    scope(exit) delete c;

Evil, I know, but it kind of stinks that alloca is the only means we currently have to construct classes on the stack.


Sean

Sean Kelly wrote:
> Bill Baxter wrote:
>>
>> I guess when it comes down to it, finding the size of a class is really only useful for satisfying one's curiosity and optimizing member orders to get better alignment.  And for that purpose I guess it doesn't really have to be that intuitive a name.
> 
> But the existing method only works at run time, which doesn't allow for things like this:
> 
>     byte[MyClass.isizeof] buf;
>     MyClass c = new(&buf[0]) MyClass();
>     scope(exit) delete c;
> 
> Evil, I know, but it kind of stinks that alloca is the only means we currently have to construct classes on the stack.

Oh yeh.  Forgot about the runtime only thing.  So I'll change my tune to: if classinfo.init.length were available at runtime *then* it would be good enough.

But I presume making that so is not much easier than adding isizeof.  If it were easy, then classinfo.init.length wouldn't have had the runtime restriction to begin with.

--bb

Bill Baxter wrote:
> Lionello Lunesu wrote:
>> Sean Kelly wrote:
>>> Bill Baxter wrote:
>>>> Is this really the best way to get the size of a class instance given the type?
>>>>
>>>>   MyClass.classinfo.init.length;
>>>
>>> Yes.  And this only works at run time.  I proposed a new .isizeof property to simplify things, but it didn't seem terribly popular.  See:
>>>
>>> http://d.puremagic.com/issues/show_bug.cgi?id=88
>>>
>>>
>>> Sean
>>
>> I suppose sizeof(MyClass) could simply return the right value. I don't see how the size of a class' handle can be useful.
>>
>> L.
> 
> I suspect the reason is that for doing various low-level things you might actually need to know how much space the thing is occupying on the stack.  Like a varargs, for instance.  You need to know how big the thing is on the stack to advance the _argptr properly.  It doesn't matter how big the instance data on the heap is.
> 
> I just now did a web search to see what other GC languages that hide pointers from you do.
> 
> Java just doesn't have sizeof apparently.
> 
> C# has it.  From the spec:
>   "For all other (non predefined types), the result of the sizeof operator is implementation-defined and is classified as a value, not a constant.
> ...
> When applied to an operand that has struct type, the result is the total number of bytes in a variable of that type, including any padding."
> 
> So basically it sounds like they say you can't count on sizeof(aclass) returning anything in particular.
> 
> I guess when it comes down to it, finding the size of a class is really only useful for satisfying one's curiosity and optimizing member orders to get better alignment.  And for that purpose I guess it doesn't really have to be that intuitive a name.
> 
> --bb

Uh, according to the D spec, the order of the members of a _class_ may be changed by the compiler, so optimizing manually would have no effect.

L.

Lionello Lunesu wrote:
> Bill Baxter wrote:
>> I guess when it comes down to it, finding the size of a class is really only useful for satisfying one's curiosity and optimizing member orders to get better alignment.  And for that purpose I guess it doesn't really have to be that intuitive a name.

> Lionello Lunesu wrote:
>
> Uh, according to the D spec, the order of the members of a _class_ may be changed by the compiler, so optimizing manually would have no effect.
> 
> L.

Tell that to dmd 0.174:

import std.stdio : writefln;

class A
{
    char a;
    int  b;
    char c;
    char d;
    char e;
}
class B
{
    char a;
    char c;
    char d;
    char e;
    int  b;
}

void main()
{
    writefln("Sizeof A = ", A.classinfo.init.length);
    writefln("Sizeof B = ", B.classinfo.init.length);
}

>> Sizeof A = 19
>> Sizeof B = 16

And in practice A will probably take 20 bytes, because the thing after it in memory will want to be aligned on a 4-byte boundary too.

So the key word in the spec is that the order _may_ be changed, not that it will.  C and C++ specs have always had the same sort of language, but in practice very few if any compilers reorder members.  They will, however, add in padding to get optimal alignment.

Yes, optimizations such as the above are, strictly speaking, implementation-dependent.  But that's OK if you've fixed your implementation.

--bb