Craig Black wrote:
"Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message
news:hj8gd7$2so...@digitalmars.com...
Craig Black wrote:
"Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in
message news:hj7vnu$200...@digitalmars.com...
BCS wrote:
Hello Andrei,
The nice part about refcounting is that for the most part you don't
need to cripple the language.
I think people are trying to say that disallowing use of GC stuff
wouldn't cripple the language.
Well it's a fact that there would be fewer idioms and options
accessible. So I didn't mean it in a derogatory way as much as a
factual statement.
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.
There are certainly challenges, even perhaps some that I haven't
thought of, with mixing manual memory management and GC code. But
perhaps there is a bigger problem with the approach you describe.
Correct me if I'm wrong, but it seems that what you propose is a
-nogc option that would fragment all D code into two incompatible
groups. If my -nogc code could not be used with anyone else's D
code, then what I have is not a dialect of D at all, but a different
incompatible language.
I know this issue is a challenging problem from a language design
standpoint, and I see why you would have some disdain for it.
However, this is not an impossible problem to solve. For example, I
believe Managed C++ does this, albeit with some weird syntax, but
this proves that it can be done. Anyway, just my 2 cents.
It's reasonable to say that you decide at application design level
what memory management approach you want to choose. That doesn't
fragment the community. The decision is similar to many others made at
the same level: libraries used, build flags, target platform(s),
pointer size (32 vs. 64, not an option yet for dmd), etc.
Andrei
Are we talking about the same thing here? The things you mention here
do not create two incompatible styles of programming. I would like to
point out how great it is that Phobos and Tango can be compiled together
in the same application. Now they are interoperable. If -nogc code
can't be used together with GC code, then we create a similar schism as
having two incompatible "standard" libraries.
Well if we get into details we'll figure that things must be quite
different for different memory management models. For example Object in
ref-counted mode is not a class anymore, it's a struct. So now there's
going to be two parts in an app: those in which Object is a class, and
those in which Object is a struct. Reconciling those would be a tall order.
Andrei
