Leandro Lucarella wrote:
Andrei Alexandrescu, el 20 de enero a las 20:48 me escribiste:
BCS wrote:
Hello Andrei,
BCS wrote:
Also there is one thing that -nogc would have over what you are
talking about; you could use it on some modules and not others. If I
have some performance critical code where attempting to use the GC
would break it's perf contract, I can put it in it's own module and
compile just it with -nogc and then link it in with code that does
use the GC.
Meh. This has been discussed in the C++ standardization committee, and
it gets really tricky real fast when you e.g. use together several
libraries, each with its own view of memory management. My impression:
don't.
Why would having one chunk of code get checked for calls to the GC
and another not be any more complicated than mixing
malloc/free+add/removeRoot with normal GC? I'm beginning to wonder
if I'm calling for something different than other people are.
What I'm thinking of would have zero effect on the generated code,
the only effect it would have is to cause an error when some code
would normally attempt to invoke the GC.
It's much more complicated than that. What if a library returns an
object or an array to another library?
The same that happens in C now, memory management is part of the interface
and you should state if the returned object's memory is managed by the
library or the user.
This introduces a problem D doesn't have now, but let's keep the focus
here, this will be used mostly only in embedded environments, where this
problem is already present, so it's not too bad. People using "regular"
D probably won't be using any "embedded library". They other way arround
could be a little more likely, and since "embedded guys" are tought, they
should be able to cope with this issue (or avoid using "regular"
D libraries that use the GC).
I very much see people using a reference-counted approach to GC in a
non-embedded application.
Andrei
