www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - structs vs classes

reply Jim <bitcirkel yahoo.com> writes:
I'm a bit troubled with the class/struct dichotomy. I would prefer them both to
use the same keyword. Heap/stack allocation could be specified during
instantiation instead. Why? Now you need to choose one over the other. Not even
C++ has this limitation.

Think about containers for example, should they be classes or structs? Do you
want them on the stack or on the heap?

I guess it's possible to define the entire container as a mixin now. That would
let you have both heap and stack containers share definition, but generally I
think that the dichotomy should be abolished.
Jan 29 2011
next sibling parent reply so <so so.do> writes:
 I'm a bit troubled with the class/struct dichotomy. I would prefer them  
 both to use the same keyword. Heap/stack allocation could be specified  
 during instantiation instead. Why? Now you need to choose one over the  
 other. Not even C++ has this limitation.

This keeps coming and i have no idea how people think C++ treatment is any way good. You are free to call the D design of struct/class the worst possible, but at least don't base your reasoning to C++ please. C++: both class and struct are exactly same, except one trivial: struct A : B { }; means: class A : public B { public: }; In D they are quite different and they have different keywords. http://www.digitalmars.com/d/2.0/class.html http://www.digitalmars.com/d/2.0/struct.html
Jan 29 2011
next sibling parent reply Jim <bitcirkel yahoo.com> writes:
I'm only discussing the heap/stack difference.



so Wrote:

 I'm a bit troubled with the class/struct dichotomy. I would prefer them  
 both to use the same keyword. Heap/stack allocation could be specified  
 during instantiation instead. Why? Now you need to choose one over the  
 other. Not even C++ has this limitation.

This keeps coming and i have no idea how people think C++ treatment is any way good. You are free to call the D design of struct/class the worst possible, but at least don't base your reasoning to C++ please. C++: both class and struct are exactly same, except one trivial: struct A : B { }; means: class A : public B { public: }; In D they are quite different and they have different keywords. http://www.digitalmars.com/d/2.0/class.html http://www.digitalmars.com/d/2.0/struct.html

Jan 29 2011
next sibling parent reply Jim <bitcirkel yahoo.com> writes:
Simen kjaeraas Wrote:

 Jim <bitcirkel yahoo.com> wrote:
 
 I'm only discussing the heap/stack difference.

In D you are allowed to safely put your structs on the heap, and unsafely put your classes on the stack. What more do you want? Also, a D struct is POD. It has no vtable, it does not support subtyping except via alias this, and it is simply a different beast from classes. This is a good thing, as you often want such a light-weight abstraction. How would you suppose we retain this if we were to abolish this dichotomy? -- Simen

Oh? "All class-based objects are dynamically allocated—unlike in C++, there is no way to allocate a class object on the stack." - The D Programming Language, chapter 6. The lightweight nature of structs is very appealing though. I like that very much of course. Couldn't that be optimised by the compiler alone knowing that a class wasn't derived?
Jan 29 2011
parent Jim <bitcirkel yahoo.com> writes:
Simen kjaeraas Wrote:

 Jim <bitcirkel yahoo.com> wrote:
 
 
 "All class-based objects are dynamically allocated—unlike in C++, there  
 is no way to allocate a class object on the stack."
 - The D Programming Language, chapter 6.

That would probably be better written as "there is no built-in way to allocate a class object on the stack." D is a pragmatic system programming language. If you want to treat this blob of memory as a Foo, and you're willing to jump through some hoops, it can be done. But the language does not encourage this. Like I said, putting a class on the stack is an unsafe thing to do (see http://en.wikipedia.org/wiki/Object_slicing), and it was deemed that the language should not directly support such an idiom. It is still doable in a library.
 The lightweight nature of structs is very appealing though. I like that  
 very much of course. Couldn't that be optimised by the compiler alone  
 knowing that a class wasn't derived?

Perhaps, in some cases. Final classes might. If a class is not marked final, someone might derive from it, include this from a DLL or otherwise, and boom goes the program. -- Simen

Okay, thanks! I learned some from this thread.
Jan 29 2011
prev sibling parent Peter Alexander <peter.alexander.au gmail.com> writes:
On 29/01/11 9:36 PM, Simen kjaeraas wrote:
 Patrick Kreft <patrick_kreft gmx.net> wrote:

 On Sat, 29 Jan 2011 15:45:41 +0100, Tomek Sowiński <just ask.me> wrote:

 Jim napisał:

 I'm only discussing the heap/stack difference.

Classes with value semantics would be prone to the slicing problem.

That is because of the type system not classes or value semantic cause of that.

Really? How would I go about stuffing a 16-byte class instance into the 8 bytes allocated on the stack, anyway?

I believe his point is that you can't, and the type system shouldn't allow it (as it does in C++).
Jan 29 2011
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Jim <bitcirkel yahoo.com> wrote:

 I'm only discussing the heap/stack difference.

In D you are allowed to safely put your structs on the heap, and unsafely put your classes on the stack. What more do you want? Also, a D struct is POD. It has no vtable, it does not support subtyping except via alias this, and it is simply a different beast from classes. This is a good thing, as you often want such a light-weight abstraction. How would you suppose we retain this if we were to abolish this dichotomy? -- Simen
Jan 29 2011
prev sibling next sibling parent Matthias Walter <xammy xammy.homelinux.net> writes:
On 01/29/2011 09:13 AM, Jim wrote:
 so Wrote:

 I'm a bit troubled with the class/struct dichotomy. I would prefer them  
 both to use the same keyword. Heap/stack allocation could be specified  
 during instantiation instead. Why? Now you need to choose one over the  
 other. Not even C++ has this limitation.

way good. You are free to call the D design of struct/class the worst possible, but at least don't base your reasoning to C++ please. C++: both class and struct are exactly same, except one trivial: struct A : B { }; means: class A : public B { public: }; In D they are quite different and they have different keywords. http://www.digitalmars.com/d/2.0/class.html http://www.digitalmars.com/d/2.0/struct.html


can decide whether you want to allocate a class on the stack: http://www.digitalmars.com/d/2.0/memory.html#stackclass Matthias
Jan 29 2011
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Jim <bitcirkel yahoo.com> wrote:


 "All class-based objects are dynamically allocated=E2=80=94unlike in C=

 is no way to allocate a class object on the stack."
 - The D Programming Language, chapter 6.

That would probably be better written as "there is no built-in way to allocate a class object on the stack." D is a pragmatic system programmi= ng language. If you want to treat this blob of memory as a Foo, and you're willing to jump through some hoops, it can be done. But the language doe= s not encourage this. Like I said, putting a class on the stack is an unsafe thing to do (see http://en.wikipedia.org/wiki/Object_slicing), and it was deemed that the= language should not directly support such an idiom. It is still doable i= n a library.
 The lightweight nature of structs is very appealing though. I like tha=

 very much of course. Couldn't that be optimised by the compiler alone =

 knowing that a class wasn't derived?

Perhaps, in some cases. Final classes might. If a class is not marked final, someone might derive from it, include this from a DLL or otherwis= e, and boom goes the program. -- = Simen
Jan 29 2011
prev sibling next sibling parent "Patrick Kreft" <patrick_kreft gmx.net> writes:
On Sat, 29 Jan 2011 15:45:41 +0100, Tomek Sowi=C5=84ski <just ask.me> wr=
ote:

 Jim napisa=C5=82:

 I'm only discussing the heap/stack difference.

Classes with value semantics would be prone to the slicing problem.

That is because of the type system not classes or value semantic cause o= f = that. -- = Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Jan 29 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
 AFAIR scope classes are to be banished from the language. There's  
 emplace instead.

std.typecons' scoped() is to be used.
Jan 29 2011
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Patrick Kreft <patrick_kreft gmx.net> wrote:

 On Sat, 29 Jan 2011 15:45:41 +0100, Tomek Sowi=C5=84ski <just ask.me> =

 Jim napisa=C5=82:

 I'm only discussing the heap/stack difference.

Classes with value semantics would be prone to the slicing problem.

That is because of the type system not classes or value semantic cause=

 of that.

Really? How would I go about stuffing a 16-byte class instance into the 8 bytes allocated on the stack, anyway? -- = Simen
Jan 29 2011
prev sibling parent "Patrick Kreft" <patrick_kreft gmx.net> writes:
On Sun, 30 Jan 2011 00:16:20 +0100, Peter Alexander  =

<peter.alexander.au gmail.com> wrote:

 On 29/01/11 9:36 PM, Simen kjaeraas wrote:
 Patrick Kreft <patrick_kreft gmx.net> wrote:

 On Sat, 29 Jan 2011 15:45:41 +0100, Tomek Sowi=C5=84ski <just ask.me=


 Jim napisa=C5=82:

 I'm only discussing the heap/stack difference.

Classes with value semantics would be prone to the slicing problem.=





That is because of the type system not classes or value semantic cau=



 of that.

Really? How would I go about stuffing a 16-byte class instance into t=


 8 bytes allocated on the stack, anyway?

I believe his point is that you can't, and the type system shouldn't =

 allow it (as it does in C++).

Well not exactly, i mean it's true for D and all languages, which use = nominal type system, but it's not true for all languages. -- = Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Jan 29 2011
prev sibling next sibling parent biozic <dransic free.fr> writes:
Le 29/01/11 14:43, Jim a Ă©crit :
 I'm a bit troubled with the class/struct dichotomy. I would prefer them both
to use the same keyword. Heap/stack allocation could be specified during
instantiation instead. Why? Now you need to choose one over the other. Not even
C++ has this limitation.

 Think about containers for example, should they be classes or structs? Do you
want them on the stack or on the heap?

 I guess it's possible to define the entire container as a mixin now. That
would let you have both heap and stack containers share definition, but
generally I think that the dichotomy should be abolished.

The difference between class and struct in D is more than heap or stack allocation. Having a common keyword for them would unwisely mask their fundamental differences (inheritance/polymorphism, reference/value semantics, etc.). Perhaps the suggestion is in fact one that has already been made but for which I can't remember the conclusion: how about abandoning 'new' in favor of more specific keywords/library templates that control whether the instantiation occur on the heap or on the stack?
Jan 29 2011
prev sibling next sibling parent Tomek =?ISO-8859-2?Q?Sowi=F1ski?= <just ask.me> writes:
Jim napisa=B3:

 I'm only discussing the heap/stack difference.

Classes with value semantics would be prone to the slicing problem.=20 --=20 Tomek
Jan 29 2011
prev sibling parent Tomek =?ISO-8859-2?Q?Sowi=F1ski?= <just ask.me> writes:
Matthias Walter napisa=B3:

 That is of course a difference, but no argument. The reason is that you
 can decide whether you want to allocate a class on the stack:
=20
 http://www.digitalmars.com/d/2.0/memory.html#stackclass

AFAIR scope classes are to be banished from the language. There's emplace i= nstead. http://digitalmars.com/d/2.0/phobos/std_conv.html#emplace --=20 Tomek
Jan 29 2011