Andrei Alexandrescu Wrote: > 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
That's the problem. We ARE talking about two different things. You are thinking -nogc should denote reference counting. If we are talking about reference counting, then I agree with you. However, circular references become an issue, and D code compiled this way will have to be fixed somehow to resolve this, perhaps using weak pointers as you mentioned earlier. -Craig
