• A Lahav <aviadlahav gmail.com> Aug 07 2008
• "Steven Schveighoffer" <schveiguy yahoo.com> Aug 07 2008
• "Bill Baxter" <wbaxter gmail.com> Aug 07 2008
• "Steven Schveighoffer" <schveiguy yahoo.com> Aug 07 2008
• A Lahav <aviadlahav gmail.com> Aug 08 2008
• bearophile <bearophileHUGS lycos.com> Aug 08 2008
• "Bill Baxter" <wbaxter gmail.com> Aug 07 2008

A Lahav <aviadlahav gmail.com> writes:

Can anyone please explain the design rationale for classes being reference
types exclusively?

I ask this because I really like my classes to be allocated on the stack or be
value-type data members, the performance boost you get eliminiting all these
unnecessary heap operations is entirely not neglible.

Otherwise I'll have a real problem considering D for my own use...

Thanks!

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"A Lahav" wrote
 Can anyone please explain the design rationale for classes being reference 
 types exclusively?

 I ask this because I really like my classes to be allocated on the stack 
 or be value-type data members, the performance boost you get eliminiting 
 all these unnecessary heap operations is entirely not neglible.

 Otherwise I'll have a real problem considering D for my own use...


Because of many reasons Walter has described in the past.  The one that 
sticks out to me is the chopping effect (don't know if this is the right 
term).  Let's say a function returns a non-reference class instance, and 
your function returns a derived instance.  The return value chops off the 
derived stuff.

I like the way classes are always references.  But there is a way to ensure 
a class gets allocated on the stack:

scope c = new MyClass(...);

This will allocate the class on the stack.  Be sure not to return a 
reference to it later though!

Another possibility is to use structs instead, which do not have 
inheritance, and so will not cause the chopping effect.

-Steve 

"Bill Baxter" <wbaxter gmail.com> writes:

On Fri, Aug 8, 2008 at 1:10 AM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:
 "A Lahav" wrote
 Can anyone please explain the design rationale for classes being reference
 types exclusively?

 I ask this because I really like my classes to be allocated on the stack
 or be value-type data members, the performance boost you get eliminiting
 all these unnecessary heap operations is entirely not neglible.

 Otherwise I'll have a real problem considering D for my own use...


 Because of many reasons Walter has described in the past.  The one that
 sticks out to me is the chopping effect (don't know if this is the right
 term).  Let's say a function returns a non-reference class instance, and
 your function returns a derived instance.  The return value chops off the
 derived stuff.


It's called "slicing".

 I like the way classes are always references.  But there is a way to ensure
 a class gets allocated on the stack:

 scope c = new MyClass(...);

 This will allocate the class on the stack.  Be sure not to return a
 reference to it later though!

 Another possibility is to use structs instead, which do not have
 inheritance, and so will not cause the chopping effect.


As has been mentioned in the past, it would definitely be nice if you
could also make a "scope MyClass" as a member of another class or
struct.

--bb

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Bill Baxter" wrote
 On Fri, Aug 8, 2008 at 1:10 AM, Steven Schveighoffer
 wrote:
 "A Lahav" wrote
 Can anyone please explain the design rationale for classes being 
 reference
 types exclusively?

 I ask this because I really like my classes to be allocated on the stack
 or be value-type data members, the performance boost you get eliminiting
 all these unnecessary heap operations is entirely not neglible.

 Otherwise I'll have a real problem considering D for my own use...


 Because of many reasons Walter has described in the past.  The one that
 sticks out to me is the chopping effect (don't know if this is the right
 term).  Let's say a function returns a non-reference class instance, and
 your function returns a derived instance.  The return value chops off the
 derived stuff.


 It's called "slicing".

 I like the way classes are always references.  But there is a way to 
 ensure
 a class gets allocated on the stack:

 scope c = new MyClass(...);

 This will allocate the class on the stack.  Be sure not to return a
 reference to it later though!

 Another possibility is to use structs instead, which do not have
 inheritance, and so will not cause the chopping effect.


 As has been mentioned in the past, it would definitely be nice if you
 could also make a "scope MyClass" as a member of another class or
 struct.


I also would like this request to be granted: 
http://d.puremagic.com/issues/show_bug.cgi?id=2070

-Steve 

A Lahav <aviadlahav gmail.com> writes:

Steven Schveighoffer Wrote:

 "Bill Baxter" wrote
 On Fri, Aug 8, 2008 at 1:10 AM, Steven Schveighoffer
 wrote:
 "A Lahav" wrote
 Can anyone please explain the design rationale for classes being 
 reference
 types exclusively?

 I ask this because I really like my classes to be allocated on the stack
 or be value-type data members, the performance boost you get eliminiting
 all these unnecessary heap operations is entirely not neglible.

 Otherwise I'll have a real problem considering D for my own use...


 Because of many reasons Walter has described in the past.  The one that
 sticks out to me is the chopping effect (don't know if this is the right
 term).  Let's say a function returns a non-reference class instance, and
 your function returns a derived instance.  The return value chops off the
 derived stuff.


 It's called "slicing".




Thanks - so where can I find what Walter said?

 I like the way classes are always references.  But there is a way to 
 ensure
 a class gets allocated on the stack:

 scope c = new MyClass(...);

 This will allocate the class on the stack.  Be sure not to return a
 reference to it later though!

 Another possibility is to use structs instead, which do not have
 inheritance, and so will not cause the chopping effect.


 As has been mentioned in the past, it would definitely be nice if you
 could also make a "scope MyClass" as a member of another class or
 struct.


 I also would like this request to be granted: 
 http://d.puremagic.com/issues/show_bug.cgi?id=2070
 



 -Steve 
 
 


Another thing I didn't find any information about, I guess you know more than
me here:
My dream is having member classes size determined in (dynamic) link time. This
would solve IMHO a lot of versioning problems without having to revert to
heap-allocated objects and object factories. Probably such a request entails an
ABI modification. Can anyone comment?

bearophile <bearophileHUGS lycos.com> writes:

A Lahav:
 Agree, and more than that - why shouldn't it be the default case?


If your question is "why aren't classes allocated on the stack by default", the
answer is simple: heap allocated classes are safer (and more flexible), you can
use them around your program, and the GC takes care of them.

The D language is (I hope) designed to be safe by default when possible (and
when it doesn't make the programs crawl), and to give you (when possible) a way
to do the unsafe thing if you ask for it explicitly (kind of the opposite of C,
see the int x = void; too).

For max speed you have to use C/C++/asm/HLA/etc.

Bye,
bearophile

"Bill Baxter" <wbaxter gmail.com> writes:

On Fri, Aug 8, 2008 at 4:33 AM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:
 "Bill Baxter" wrote


 I also would like this request to be granted:
 http://d.puremagic.com/issues/show_bug.cgi?id=2070


Although I can't say I've ever had a big need for that, it makes sense
that something like that should work.  Just from the standpoint of
making things nice and orthogonal.  I see no reason why you shouldn't
be able to put storage classes on anonymous variables like that.
Seems like your request would be pretty easy to implement too.

--bb