Re: Garbage Collection - The Trash Begins To Pile Up
Of course, I can make mistakes, but if instead of using char[],
I use std::string, I'm pretty sure that no memory will be leaked even
every single statement of my function throws an exception. But I
understand your points.
You've a potential resource leak every time you use operator new, and a
potential dangling pointer problem every time you use RAII. For example,
just store a reference to an RAII stack allocated std::string into a
global map.
Ok. But storing reference to local objects in a less common mistake.
That's the way the stack works and GC is not going to save us from
this. The only problem with RAII, in my opinion is that it forces the
creation of dummy classes. It's too much typing. I think that a
mechanism similar to D's scope(success)/scope(exit) is needed. If
lambda expression are added to C++, we can develop a library solution
simulating this scope constructions and make RAII easier to use.
And hopefully, you carefully did all the auto_ptr/unique_ptr/shared_ptr
decisions correctly, along with the transfers. Then when someone else
comes along and modifies your code, they don't botch that all up by
failing to understand all the subtle details of when to use which ptr type.
I my opinion, memory should be better allocated with a function
returning a unique_ptr instead of a raw pointer. This would avoid a lot
of leaks and will make us think about the ownership of that memory.
With variadic templates it would be easy to develop a function wrapping
"new" and returning a non-leakable pointer:
template<typename T, typename... Args>
unique_ptr<T> create_new(const Args&... args)
{
return unique_ptr<T>(new T(args...);
}
Creating a new object:
//No leakable object
auto p = create_new<MyClass>(arg1, arg2, arg3);
Having raw pointers around it's not a good idea and small (if they are
standard, even better, no doubt) utilities. Well, this is a bit
off-topic, I'm afraid.
So, based on your experience, do you think that transparent garbage
collection (N2128, new/delete garbage collected, scanning for pointers
in integers if the class is not gc_strict, operator < and == with
pointers, using pointers as hash keys...) can have performance issues
or algorithm limitations comparing to a C++/CLI-like approach (a
different pointer type, the compiler forbids castings on those
pointers...)?
There is no C++ finalization proposal yet AFAIK, and I think that
having GC without solving finalization is not desirable. Which is, in
your opinion, the best way to deal with finalization issues that have
arisen in other languages (Java problems, for example, are mentioned
N2128)?
The problems happen like when one decides that object-oriented
programming is the One True Path, and then tries to bash everything into
being an object. GC is not the One True Path. But it works well enough
for a large set of common problems. But when you need finalizers,
destructors, or to close file handles, GC is the wrong answer. The four
general forms of memory management are:
1) explicit
2) RAII
3) reference counting
4) GC
C++ supports 1,2,3, D supports 1,2,4. There's some ongoing investigation
between myself and colleagues on a way to support 3 in D, and then the
programmer will be able to select the right approach for the right problem.
So let's add 4 also to C++, but let's make also easier to use 2 (scope,
rollback functions, or whatever we call them). Anyway, I'm still
interested in your opinion in the previous questions:
1) do you think that transparent garbage collection (N2128, new/delete
garbage collected, scanning for pointers in integers if the class is
not gc_strict, operator < and == with pointers, using pointers as hash
keys...) can have performance issues or algorithm limitations comparing
to a C++/CLI-like approach?
2) Which is, in your opinion, the best way to deal with finalization
issues with GC that have arisen in other languages?
Regards,
Ion
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]