|
Boost : |
Subject: Re: [boost] discussion of garbage collection in C++
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-04-21 15:59:36
Gregory Peele ARA/CFD wrote:
> I'm not going to dispute that it's always possible to design good
> software packages without a GC, and I think that you should always
> consider non-GC designs first (not that we have much of a choice in
> C++
> at this point, which is the problem under discussion.) But especially
> for prototypes where proving algorithm feasibility is more important
> than clean design, or in the real world where we don't have unlimited
> time to develop and deliver our software using developers who aren't
> necessarily C++ programming gods, a GC could make life much easier by
> ensuring that we could rely on "good enough" automated memory
> management.
Bjarne's definition of C++ was "C++ is a library and systems programming language." I don't know if someone has filled in the blank with a better adjective yet. Currently we also use it for application level programming because it is pretty good for that too, but we also use heterogeneous language systems where python, lua or *shudder* tcl runtime environments run on top of a C++ foundation and call C++ library and system interfaces through bindings. It would be very nice, and I mentioned this to Bjarne when he was last at Intel, to have a C++ runtime environment complete with garbage collection so that we could use it for application programming, rapid prototyping and scripting. He wasn't too keen on the idea, but there are commercial C++ runtime environments out there and C# is just runtime C++ that they broke compatibility on purpose. MS Office applications written in C++ running in interpreted mode with JIT compilation with only 15% runtime penalty was the proof point for C#. Why stop half way? Why not have an open source C++ runtime environment if the goal is applications programming and rapid prototyping in C++ with open source components? An open source GC library is a good building block for such a system, and of course we'd prefer to implement it in C++. Using the GC library to implement runtime environments for GC languages is one of the use cases where I think a GC library is a great thing to have in boost. I just don't want to see it misused. Prototypes all to often turn into products with little more efforting put in than a good sales pitch.
Regards,
Luke
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk