www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - some design thoughts

reply B.G. <B.G._member pathlink.com> writes:
1) auto auto.

Some things can have an auto attribute.

What about an optional compiler switch, so that compiler makes efforts to 
apply the auto attribute automatically to as many things as possible.
(my apologies if I've missed something about auto attribute)
What I mean is, in at least obvious situations code is emitted by compiler to
collect some OBVIOUS garbage immediately.

This might be interesting for some environments.

2) Shouldn't there be an easy way to provide a completely custom memory
management mechanism for entire memory allocation and deallocation for a
particular D program or library?
I thought of some way to be able to tell the root Object class to use some
custom new/delete method, and be automatically inherited by all other classes
unless some class wants it's own new/delete.
On the other hand this would only work with classes, but I wanted arrays to work
this way too.
To be short, I thought some global memory management hook would be nice to have.

2a) if I override new/delete() for a class, is there a way to call 'standard'
new/delete() methods? or is it at least legal to say super.new() or something?
Apr 29 2005
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"B.G." <B.G._member pathlink.com> wrote in message 
news:d4t96p$nak$1 digitaldaemon.com...

 1) auto auto.

 Some things can have an auto attribute.

 What about an optional compiler switch, so that compiler makes 
 efforts to
 apply the auto attribute automatically to as many things as 
 possible.
 (my apologies if I've missed something about auto attribute)
 What I mean is, in at least obvious situations code is emitted by 
 compiler to
 collect some OBVIOUS garbage immediately.

 This might be interesting for some environments.


I can see it'd be a nice feature for production optimisation, but I 
wonder whether people might end up being led into situations of 
designing and implementing bad programs, by virtue of comping to 
rely on such _optional_ behaviour.


 2) Shouldn't there be an easy way to provide a completely custom 
 memory
 management mechanism for entire memory allocation and deallocation 
 for a
 particular D program


yes, I guess


 or library?


no, unless you mean dynamic library. If you do, I think the jury's 
still out on that. Eric, Kris, etc. can better comment on it than 
me.
Apr 29 2005
parent B.G. <B.G._member pathlink.com> writes:
In article <d4uub9$27ri$1 digitaldaemon.com>, Matthew says...

"B.G." <B.G._member pathlink.com> wrote in message 
news:d4t96p$nak$1 digitaldaemon.com...

 1) auto auto.

 Some things can have an auto attribute.

 What about an optional compiler switch, so that compiler makes 
 efforts to
 apply the auto attribute automatically to as many things as 
 possible.
 (my apologies if I've missed something about auto attribute)
 What I mean is, in at least obvious situations code is emitted by 
 compiler to
 collect some OBVIOUS garbage immediately.

 This might be interesting for some environments.


I can see it'd be a nice feature for production optimisation, but I 
wonder whether people might end up being led into situations of 
designing and implementing bad programs, by virtue of comping to 
rely on such _optional_ behaviour.


It won't necessarily be optimal for all types of applications, 'delayed' garbage
collection will keep it's benefits anyway, but rather for some memory-tight
environments, or near-realtime applications. It's hard for me to evaluate the
impact of such behaviour, and if it should become a common production-level
optimisation. I think it's rather application dependant.


 2) Shouldn't there be an easy way to provide a completely custom 
 memory
 management mechanism for entire memory allocation and deallocation 
 for a
 particular D program


yes, I guess


 or library?


no, unless you mean dynamic library. If you do, I think the jury's 
still out on that. Eric, Kris, etc. can better comment on it than 
me.
May 02 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"B.G." <B.G._member pathlink.com> wrote in message
news:d4t96p$nak$1 digitaldaemon.com...

 1) auto auto.

 Some things can have an auto attribute.

 What about an optional compiler switch, so that compiler makes efforts to
 apply the auto attribute automatically to as many things as possible.
 (my apologies if I've missed something about auto attribute)
 What I mean is, in at least obvious situations code is emitted by compiler


to

 collect some OBVIOUS garbage immediately.

 This might be interesting for some environments.


The jargon for this is called 'escape analysis'. It's a perfectly reasonable
for the compiler optimizer to do this automatically, no need to have a
switch for it.




 2) Shouldn't there be an easy way to provide a completely custom memory
 management mechanism for entire memory allocation and deallocation for a
 particular D program or library?
 I thought of some way to be able to tell the root Object class to use some
 custom new/delete method, and be automatically inherited by all other


classes

 unless some class wants it's own new/delete.
 On the other hand this would only work with classes, but I wanted arrays


to work

 this way too.
 To be short, I thought some global memory management hook would be nice to


have.

 2a) if I override new/delete() for a class, is there a way to call


'standard'

 new/delete() methods? or is it at least legal to say super.new() or


something?

In C++, one can globally override operators new/delete. I've used this a few
times, and it nearly always turned out to be a bad idea. The problem is the
high risk of breaking some third party library code that relied on
new/delete being the defaults. It's more robust to allow this only on a
per-class or per-struct basis.

Of course, the entire gc is pluggable. You can substitute your own by just
linking it in rather than letting the one in Phobos be linked in.
May 01 2005
next sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
Of course, the entire gc is pluggable. You can substitute your own by just
linking it in rather than letting the one in Phobos be linked in.


So I can use my own compacting gc without problems (hypothetically)?

I thought Object.hash() would use the objects address to calculate the hashcode
(I can't remeber where I read this. Perhaps I'm wrong.)
May 01 2005
prev sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 2a) if I override new/delete() for a class, is there a way to 
 call


 'standard'

 new/delete() methods? or is it at least legal to say super.new() 
 or


 something?

 In C++, one can globally override operators new/delete. I've used 
 this a few
 times, and it nearly always turned out to be a bad idea. The 
 problem is the
 high risk of breaking some third party library code that relied on
 new/delete being the defaults. It's more robust to allow this only 
 on a
 per-class or per-struct basis.


Very interesting. Any chance of you posting your thoughts on 
http://www.artima.com/weblogs/viewpost.jsp?thread=104861? I think 
it'd be a valuable contribution
May 01 2005