structs vs classes
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.
Re: structs vs classes
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
Re: structs vs classes
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
Re: structs vs classes
Jim 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
Re: structs vs classes
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?
Re: structs vs classes
Jim napisał: > I'm only discussing the heap/stack difference. Classes with value semantics would be prone to the slicing problem. -- Tomek
Re: structs vs classes
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.
Re: structs vs classes
Simen kjaeraas Wrote: > Jim 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 allocatedunlike 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?
Re: structs vs classes
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
Re: structs vs classes
Jim 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
Re: structs vs classes
Simen kjaeraas Wrote: > Jim 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.
Re: structs vs classes
On Sat, 29 Jan 2011 15:45:41 +0100, Tomek Sowiński 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. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: structs vs classes
Matthias Walter napisał: > 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 AFAIR scope classes are to be banished from the language. There's emplace instead. http://digitalmars.com/d/2.0/phobos/std_conv.html#emplace -- Tomek
Re: structs vs classes
AFAIR scope classes are to be banished from the language. There's emplace instead. std.typecons' scoped() is to be used.
Re: structs vs classes
Patrick Kreft wrote: On Sat, 29 Jan 2011 15:45:41 +0100, Tomek Sowiński 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? -- Simen
Re: structs vs classes
On 29/01/11 9:36 PM, Simen kjaeraas wrote: Patrick Kreft wrote: On Sat, 29 Jan 2011 15:45:41 +0100, Tomek Sowiński 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++).
Re: structs vs classes
On Sun, 30 Jan 2011 00:16:20 +0100, Peter Alexander wrote: On 29/01/11 9:36 PM, Simen kjaeraas wrote: Patrick Kreft wrote: On Sat, 29 Jan 2011 15:45:41 +0100, Tomek Sowiński 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++). 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/
Re: structs vs classes
On Saturday 29 January 2011 07:11:41 Jim wrote:
> 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.
structs are value types. classes are reference types. That can drastically
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
when dealing with reference types. For a value type, it'll be a copy. For a
reference type, it's just copying the reference, so the function is free to
change the state of the object that you passed in. How on earth would the
compiler decide which behavior is correct? It can't. That's up to the
programmer.
The differences between structs and classes are critical. It's _not_ just a
question of optimization. And the compiler can't generally make an optimization
choice based on whether a type is derived or not anyway, because it also needs
to know whether a type is derivide from _it_, and it can't know that at compile
time thanks to the separate compilation model. Classes don't know about what
types are derived from them, and the derived types could be in entirely
separate
libraries - separate shared libraries even (assuming that shared libraries are
properly supported, which is on the TODO list).
C# also chose to make structs and classes separate. It's a solide design
decision. In many, many cases, how a classes is designed and functions is
affected by how it is instantiated. It can make a big difference whether a type
is
intended to be instantiated on the stack or on the heap.
structs are value types without inheritance or polymorphism. They support RAII.
classes are reference types with inheritance and polymorphism. They don't
really
support RAII (they have destructors, but there's no guarantee that they'll ever
be called, and there are various limitation on their destructors).
They are distinctly different. It was a mistake for C++ to have polymorphic
types
which could go on the stack. It causes slicing and ultimately doesn't make
sense. If you program in C++, you learn to deal with it and program in a way
that it doesn't cause problems, but it's still a problematic design choice.
Separating user-defined value and reference types makes things considerably
cleaner and safer. C# did and and D does it. Java didn't do it, but that's
because it doesn't _have_ user-defined value types. C++ is the only language
that
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
classes is a solid one.
- Jonathan M davis
