August 11, 2013
On Sunday, 11 August 2013 at 17:28:33 UTC, JS wrote:
> What's the difference between init.length and classInstanceSize?


classInstanceSize is based on the static type, whereas typeid() fetches the dynamic type. Consider the following:

===
void showSizes(Object obj) {
   import std.stdio;
   writeln("Static size: ", __traits(classInstanceSize, typeof(obj)));
   writeln("Actual size: ", typeid(obj).init.length);
}

class Foo {
  int a;
  int b;
}

void main() {
   Foo foo = new Foo();
   showSizes(foo);
}
===

// note this would be 4 bytes for the monitor, 4 bytes for the vtable pointer
Static size: 8

// this is the size of the parent class, Object, plus the size of Foo's members
Actual size: 16


The difference is because showSizes statically only knows how to deal with the specific type written (Object), but it is legal to pass any derived objects to that function too. Since child classes can add more members, their sizes can change.

typeid() gets information about the specific instance, so it gives accurate details about the child class. typeof() and __traits always work on the static type.

> The class instance size must be known at compile time

Unless you have the specific static type (in that case, use a template instead of a virtual function), you can't do that. Consider this:

===
auto lib = new SharedLibrary("plugin.dll");
auto create = cast(Object function()) lib.getProcAddress("createObject");

if(create !is null) {
   Object o = create();
   // what is o?
}
===


This plugin, by its nature, couldn't be known at compile time. It might not even exist yet at the time you're compiling the application!

The dll could write its own class though - the function might look like this:

===
module plugin;

class CoolPlugin {
   int a;
   int b;
   override string toString() {
      return "I have two members!";
   }
}

export Object createObject() {
   return new CoolPlugin();
}
===


And there's no way for you to know how big CoolPlugin is at compile time. You can't see that code at all to know these details.

At runtime, however, it is doable - that's where the typeid() comes in. It looks up the automatically generated run time type information.
August 11, 2013
On 08/11/2013 07:26 PM, JS wrote:
> On Sunday, 11 August 2013 at 17:12:48 UTC, Timon Gehr wrote:
>> On 08/11/2013 05:28 PM, JS wrote:
>>> On Sunday, 11 August 2013 at 13:40:41 UTC, Timon Gehr wrote:
>>>> On 08/11/2013 06:25 AM, JS wrote:
>>>>> Given an object, is there a built in way to get the size of the class
>>>>> the object represents?
>>>>
>>>> Yes.
>>>
>>> Troll.
>>
>> http://en.wikipedia.org/wiki/Troll_(Internet)
>
> Seriously, do you not have anything better to do with your life?

No. How about you?

> Why do you hang out on my posts if you are the one that's not the troll.

That's obvious. You are the _first_ guy capably trolling these newsgroups, so we are still too naive to believe that you are not receptive to rational argumentation and incapable of constructive discussion.

> I don't want any of your help

The best way to not receive help is to quit asking for help.

> so why don't you just do us all a favor and ignore any post I make?
>

I am as confused about this as you are but I can't talk for everyone.


What is _your_ motivation, 'JS'?
If you think your posts are worth ignoring, simply stop making noise.
August 11, 2013
On Sunday, 11 August 2013 at 17:03:04 UTC, JS wrote:
> This is essentially what I'm doing BUT I am trying to avoid having to repeat the exact same crap in every class because it is time consuming, verbose, and error prone.

I was answering to Maxim, I don't give a fuck about your problems.
August 11, 2013
On Sunday, 11 August 2013 at 18:15:28 UTC, Timon Gehr wrote:
> On 08/11/2013 07:26 PM, JS wrote:
>> On Sunday, 11 August 2013 at 17:12:48 UTC, Timon Gehr wrote:
>>> On 08/11/2013 05:28 PM, JS wrote:
>>>> On Sunday, 11 August 2013 at 13:40:41 UTC, Timon Gehr wrote:
>>>>> On 08/11/2013 06:25 AM, JS wrote:
>>>>>> Given an object, is there a built in way to get the size of the class
>>>>>> the object represents?
>>>>>
>>>>> Yes.
>>>>
>>>> Troll.
>>>
>>> http://en.wikipedia.org/wiki/Troll_(Internet)
>>
>> Seriously, do you not have anything better to do with your life?
>
> No. How about you?
>

That explains it all. How bout you get a life?

>> Why do you hang out on my posts if you are the one that's not the troll.
>
> That's obvious. You are the _first_ guy capably trolling these newsgroups, so we are still too naive to believe that you are not receptive to rational argumentation and incapable of constructive discussion.
>

Really? Because I won't except your help hands down. You are an arrogant bastard who thinks you know it all. When someone challenges you because they won't accept you as the god you then cry like a little bitch.

>> I don't want any of your help
>
> The best way to not receive help is to quit asking for help.

Rigghhtt... your logic is wonderful. Don't ask for help in .learn. I guess you are trying to run me off because you can't stand me huh? Well the feeling is mutual... but at least there are a few intelligent people still left in here that actually want to help for the sake of helping and not to feed their ego.

>> so why don't you just do us all a favor and ignore any post I make?
>>
>
> I am as confused about this as you are but I can't talk for everyone.
>
>
> What is _your_ motivation, 'JS'?
> If you think your posts are worth ignoring, simply stop making noise.

Again, here is your very arrogant egotistical personality shining through(only other arrogant egotistical people will not see this). What is useless to one person is not to another. If you weren't so arrogant you would see this and let me make my posts in peace and let those that want to help me do that. Instead you rant against my posts in my thread to shut it down... but yet you call me the troll.

August 11, 2013
On Sunday, 11 August 2013 at 18:18:22 UTC, Dicebot wrote:
> On Sunday, 11 August 2013 at 17:03:04 UTC, JS wrote:
>> This is essentially what I'm doing BUT I am trying to avoid having to repeat the exact same crap in every class because it is time consuming, verbose, and error prone.
>
> I was answering to Maxim, I don't give a fuck about your problems.

THEN WHY THE FUCK DO YOU POST ON MY THREAD? You have not helped or tried to help one post. You have only ever tried to shut down any questions or suggestions I have based on your arrogant belief system that everyone and everything revolves around you... yet you continue to invade my posts. Seriously, Why can't you just leave me the fuck along and ignore my posts? Is it difficult? No, it's not. This suggests you intentionally want to make trouble. In any case, I'm through talking to you bastards. I will ignore your post from now on. In fact, I'll write a script at some point to simply remove your posts, Tim's, and others that want to act like little fucking arrogant kids that haven't got their ass kicked hard enough to realize they are not the center of the universe.
August 11, 2013
I think you're missing the point to some degree(I realize there is a diff between an object and a type, but I should be able to easily get the class size of an object at run time regardless if the object is typed as a base class). The code below does this, but at a cost of verbosity.

Here is code that exactly demonstrates what I am essentially trying to do. The only drawback now is having to mixin the template for each class which I would want to automate and it would be nice to wrap the RT and CT methods in subclasses without overhead.

http://dpaste.dzfl.pl/757eeb05



Note, I can easily get the class size, name, etc... by using the object or the type.



import std.stdio;



mixin template tObject(alias T)
{
	override @property int classSize() { return __traits(classInstanceSize, T); };
	override @property string className() { return T.stringof; };
	immutable static int ClassSize = __traits(classInstanceSize, T);
	immutable static string ClassName = T.stringof;
	static T New(Args...)(Args args) { writeln(T.ClassSize); return new T(args); }

}

interface iObject(T)
{
	@property int classSize();
	@property string className();
	
}

class A : iObject!A
{
	double x;
        mixin tObject!A;
}

class B : A
{
	double y;
        mixin tObject!B;
	double z, t;
}


void main()
{
	A a = A.New();
        A b = B.New();
	writeln(a.classSize);
	writeln(b.classSize);
	readln;
}

August 11, 2013
On Sunday, 11 August 2013 at 18:29:15 UTC, JS wrote:
> THEN WHY THE FUCK DO YOU POST ON MY THREAD?

Because you are so funny when you rage and I take pleasure in stressing someone as retarded as you ;)

Well, actually not. It was just to clarify possible misconception by Maxim. Still feels good.
August 11, 2013
On Sunday, 11 August 2013 at 18:33:19 UTC, JS wrote:
> The code below does this, but at a cost of verbosity.

I don't see what the difference is in functionality - it looks to me that you just reimplemented what the compiler does automatically with typeid.

The way typeid(obj) works is similar to a virtual function call internally, indeed, Class.vtbl[0] is a pointer to its TypeInfo instance.

But anyway, then the typeinfo contains functions for the class name and size, pretty similar to what you just did.


What does your implementation give you that typeid() doesn't?
August 11, 2013
You seem to show a certain amount of sophistication in projecting your own attributes on others. Why not retarget that creativity to achieve something useful?
August 11, 2013
On 2013-08-11, 20:33, JS wrote:

> I think you're missing the point to some degree(I realize there is a diff between an object and a type, but I should be able to easily get the class size of an object at run time regardless if the object is typed as a base class). The code below does this, but at a cost of verbosity.
>
> Here is code that exactly demonstrates what I am essentially trying to do. The only drawback now is having to mixin the template for each class which I would want to automate and it would be nice to wrap the RT and CT methods in subclasses without overhead.

It would appear that some information is lost when calling typeid from an
interface. I would have expected this to work:

interface I {
    final
    size_t size() {
        return typeid(this).init.length;
    }
}

class A {}

class B : A, I {
    int a;
}

void test1() {
    I i = new B();
    assert(i.size > 0); // Fails.
}


A bit more experimentation shows:

void test2() {
    B b = new B();
    I i = b;
    A a = b;

    assert(typeid(a) == typeid(b)); // Passes.
    assert(typeid(i) == typeid(b)); // Fails.

    assert(typeid(b).init.length > 0); // Passes.
    assert(typeid(i).init.length > 0); // Fails.
}


It appears thus that the error is in typeid(interface), which does not
give the actual typeid.

The workaround is as follows:


interface I {
    final
    size_t size() {
        return typeid(cast(Object)this).init.length;
    }
}


Is this what you want? Is it good enough? I have no idea, as you're
notoriously bad at describing what you want, but pretty good at
attacking people.

If you're looking for a no-overhead solution, then this might not be
good enough. I'm surprised that a virtual function call is fine,
though.