www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Instantiating Objects On the C Runtime Heap

reply "Craig Black" <cblack ara.com> writes:
I just read the Digital Mars Tech Tips on the D website about how to 
instantiate objects on the C runtime heap.  It's cool that it can be done 
but shouldn't there be an easier way to do this?  I think there will be a 
lot of people that shy away from GC especially considering the current GC 
algorithm used in D.

-Craig 
Sep 28 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <dheb5s$15v$1 digitaldaemon.com>, Craig Black says...
I just read the Digital Mars Tech Tips on the D website about how to 
instantiate objects on the C runtime heap.  It's cool that it can be done 
but shouldn't there be an easier way to do this?  I think there will be a 
lot of people that shy away from GC especially considering the current GC 
algorithm used in D.

Without copy constructible UDTs I'm not sure I'd want to write an application in D that used a substantial amount of non-GC memory, as there simply is no easy way to manage it. That said, D's GC has shown to perform better than the Boehm GC, so speed isn't a major issue at the moment, even if it could be better with a generational GC. Sean
Sep 28 2005
parent reply "Craig Black" <cblack ara.com> writes:
Forgive my ignorance of D, but there are no user defined copy constructors? 
You are right, this would not work.  Would it be that hard to add copy 
constructors?

-Craig

"Sean Kelly" <sean f4.ca> wrote in message 
news:dhedlh$40j$1 digitaldaemon.com...
 In article <dheb5s$15v$1 digitaldaemon.com>, Craig Black says...
I just read the Digital Mars Tech Tips on the D website about how to
instantiate objects on the C runtime heap.  It's cool that it can be done
but shouldn't there be an easier way to do this?  I think there will be a
lot of people that shy away from GC especially considering the current GC
algorithm used in D.

Without copy constructible UDTs I'm not sure I'd want to write an application in D that used a substantial amount of non-GC memory, as there simply is no easy way to manage it. That said, D's GC has shown to perform better than the Boehm GC, so speed isn't a major issue at the moment, even if it could be better with a generational GC. Sean

Sep 29 2005
parent Sean Kelly <sean f4.ca> writes:
In article <dhh748$2mn7$1 digitaldaemon.com>, Craig Black says...
Forgive my ignorance of D, but there are no user defined copy constructors? 
You are right, this would not work.  Would it be that hard to add copy 
constructors?

You can add them to classes easuly enough: class C { this( C rhs ) {} } except classes are deals with via references, so you have to do the copying explicitly: C a = new C(); C b = new C( a ); Structs are value-based but don't have constructors or assignment operators, so it's much the same thing there--manual copy: struct S { void copy( S rhs ) {} } S a; S b; b.copy( a ); You could try some tricks with static methods: struct S { static S copy( S rhs ) { S tmp; tmp.x = rhs.x; return tmp; } S a; S b = S.copy( a ); But this is no less error-prone than the alternatives. Ultimately, as both the class and struct-based methods require the copying to be handled manually, I don't consider them feasible. I'm willing to live without implicit casting (as I agree with Walter that it can be more trouble than it's worth), but the lack of copy semantics in D is somewhat frustrating. I posted something a week or two ago about the lack of consistency for UDTs (classes are pointer types but omit the pointer qualifier in order to disallow their construction on the stack, and 'auto' was strangely added to mimic stack-based behavior for classes), but mostly to blow off some steam--it's not something I expect to change before 1.0. Sean
Sep 29 2005