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