digitalmars.D.learn - Rationale for classes as reference types
- A Lahav (4/4) Aug 07 2008 Can anyone please explain the design rationale for classes being referen...
- Steven Schveighoffer (14/20) Aug 07 2008 Because of many reasons Walter has described in the past. The one that
- Bill Baxter (7/28) Aug 07 2008 It's called "slicing".
- Steven Schveighoffer (4/37) Aug 07 2008 I also would like this request to be granted:
- Bill Baxter (8/11) Aug 07 2008 Although I can't say I've ever had a big need for that, it makes sense
- A Lahav (5/49) Aug 08 2008 Agree, and more than that - why shouldn't it be the default case?
- bearophile (6/7) Aug 08 2008 If your question is "why aren't classes allocated on the stack by defaul...
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!
Aug 07 2008
"A Lahav" wroteCan 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
Aug 07 2008
On Fri, Aug 8, 2008 at 1:10 AM, Steven Schveighoffer <schveiguy yahoo.com> wrote:"A Lahav" wroteIt's called "slicing".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.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
Aug 07 2008
"Bill Baxter" wroteOn Fri, Aug 8, 2008 at 1:10 AM, Steven Schveighoffer wrote:I also would like this request to be granted: http://d.puremagic.com/issues/show_bug.cgi?id=2070 -Steve"A Lahav" wroteIt's called "slicing".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.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.
Aug 07 2008
On Fri, Aug 8, 2008 at 4:33 AM, Steven Schveighoffer <schveiguy yahoo.com> wrote:"Bill Baxter" wroteI also would like this request to be granted: http://d.puremagic.com/issues/show_bug.cgi?id=2070Although 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
Aug 07 2008
Steven Schveighoffer Wrote:"Bill Baxter" wroteThanks - so where can I find what Walter said?On Fri, Aug 8, 2008 at 1:10 AM, Steven Schveighoffer wrote:"A Lahav" wroteIt's called "slicing".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.Agree, and more than that - why shouldn't it be the default case?I also would like this request to be granted: http://d.puremagic.com/issues/show_bug.cgi?id=2070I 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.-SteveAnother 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?
Aug 08 2008
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
Aug 08 2008