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
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 "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
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 reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Jim <bitcirkel yahoo.com> wrote:



 "All class-based objects are dynamically allocated=E2=80=94unlike 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 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=


t  =


 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
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 next sibling parent reply 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
parent reply "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
parent reply "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> =


wrote:

 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
parent reply 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
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=




 wrote:

 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=






se

 of that.


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




he

 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  parent reply 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.


 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


 I'm only discussing the heap/stack difference.


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:

http://www.digitalmars.com/d/2.0/memory.html#stackclass

Matthias



 Jan 29 2011



  parent reply 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



  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  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  parent reply Jim <bitcirkel yahoo.com>  writes:


biozic Wrote:


 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?



Yes, abandoning new if it would help. Objects on the heap could be managed by
different garbage collectors (or with different settings, mark-sweep,
precise/conservative, reference-counting, etc.).

I don't want to have to change the definition of the type. The instantiation is
a separate concern to the implementation. It should be up to the user of a type
to decide whether to allocate it on the stack or the heap and so on.

The compiler should be intelligent enough to see whether the class is derived
or not and do its optmisations accordingly.



 Jan 29 2011



  parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Saturday 29 January 2011 07:11:41 Jim wrote:

 biozic Wrote:

 Le 29/01/11 14:43, Jim a =C3=A9crit :

 I'm a bit troubled with the class/struct dichotomy. I would prefer th=






em

 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.
=20
 Think about containers for example, should they be classes or structs?
 Do you want them on the stack or on the heap?
=20
 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.


=20
 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.).
=20
 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?


=20
 Yes, abandoning new if it would help. Objects on the heap could be managed
 by different garbage collectors (or with different settings, mark-sweep,
 precise/conservative, reference-counting, etc.).
=20
 I don't want to have to change the definition of the type. The
 instantiation is a separate concern to the implementation. It should be up
 to the user of a type to decide whether to allocate it on the stack or the
 heap and so on.
=20
 The compiler should be intelligent enough to see whether the class is
 derived or not and do its optmisations accordingly.


structs are value types. classes are reference types. That can drastically=
=20
change how they are designed and used. Passing something to

void func(A a) {/*...*/}

is going to have _vastly_ different behavior when dealing with value types =
than=20
when dealing with reference types. For a value type, it'll be a copy. For a=
=20
reference type, it's just copying the reference, so the function is free to=
=20
change the state of the object that you passed in. How on earth would the=20
compiler decide which behavior is correct? It can't. That's up to the=20
programmer.

The differences between structs and classes are critical. It's _not_ just a=
=20
question of optimization. And the compiler can't generally make an optimiza=
tion=20
choice based on whether a type is derived or not anyway, because it also ne=
eds=20
to know whether a type is derivide from _it_, and it can't know that at com=
pile=20
time thanks to the separate compilation model. Classes don't know about wha=
t=20
types are derived from them, and the derived types could be in entirely sep=
arate=20
libraries - separate shared libraries even (assuming that shared libraries =
are=20
properly supported, which is on the TODO list).


decision. In many, many cases, how a classes is designed and functions is=20
affected by how it is instantiated. It can make a big difference whether a =
type is=20
intended to be instantiated on the stack or on the heap.

structs are value types without inheritance or polymorphism. They support R=
AII.

classes are reference types with inheritance and polymorphism. They don't r=
eally=20
support RAII (they have destructors, but there's no guarantee that they'll =
ever=20
be called, and there are various limitation on their destructors).

They are distinctly different. It was a mistake for C++ to have polymorphic=
 types=20
which could go on the stack. It causes slicing and ultimately doesn't make=
=20
sense. If you program in C++, you learn to deal with it and program in a wa=
y=20
that it doesn't cause problems, but it's still a problematic design choice.=
=20
Separating user-defined value and reference types makes things considerably=
=20

=20
because it doesn't _have_ user-defined value types. C++ is the only languag=
e that=20
I know of which tries to conflate user-defined value and reference types.

It may take some getting used to, but D's choice of separating structs and=
=20
classes is a solid one.

=2D Jonathan M davis



 Jan 29 2011