Raindog wrote:
Mathias Gaunard wrote:
Simonson, Lucanus J wrote:
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++.
Why build a runtime environment based on GC when you can make a better one that is not?
Because the majority of programmers have proven that they obviously prefer a GC environment over an RAII one. Given that a large number of C++ programmers don't even take advantage of RAII, I would say that a c++ runtime w/ GC and RAII would be very appealing to a larger number of people.
Whenever anyone writes "the majority of programmers..." one can discount the subsequent statement "the majority" of the time. .Net, Java, Python, Perl, Ruby, D et al automatically provide GC. Wonderful for non-deterministic memory management, poor to hopeless for any other form of resource management. C++ provides RAII resource management using smart pointers, with boost::shared_ptr<T> probably being used by quite a few C++ programmers worldwide. C++ is wonderful for all forms of resource management in general, but much more difficult for cross-referenced memory management, where boost::weak_ptr<T> offers one solution. Microsoft and Sun and other languages decided that their programmers did not want to have to think about memory management at all, fair enough, and would live with half-baked or programmer hand-rolled solutions to other resource management issues. So GC, that emperor with a big hole covering his nakedness, is all the popular rage and everyone pretends that the hole does not exist or is adequately covered with a nice patch. RAII and GC in C++ ? Sure, as long as today GC is strictly optional. But I, who have run into resource management issues much, much more often in my programming of non-C++ computer languages than I have run into cross-referencing memory issues programming in C++ will stick with C++ smart pointers. Currently mixing C++ RAII and GC in C++ is a headache I do not want. Good luck to others in using them both, in other words in mixing deterministic and non-deterministic destruction and being happy that everything is used correctly ( RAII objects holding GC objects and vice versa, containers of RAII objects holding GC objects and vice versa ). That is why I think that a real solution to using RAII and GC in C++ must come from the ability to tag objects at the class level, and only occasionally at the object level, as a non-memory resource holding object, and that the syntax for doing dynamic memory management in C++ must encompass both smart pointers and GC allocations of memory under the same mnemonics. In the ideal case a programmer should only have to create an object and then forget about having to manually delete it, and either RAII smart pointers kick in for deterministic destruction when non-memory resources have to be released or GC kicks in for non-deterministic destruction of objects when only memory is involved. That ideal case should exist for all languages, but Microsoft, Sun, and others want to pretend that GC is good enough. It isn't, and it has been one of the biggest frauds in computer programming in pretending that it is.