Re: Do you use a garbage collector?
On Apr 10, 4:33 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
Lloyd Bonafide wrote:
How many of you c.l.c++'ers use one, and in what percentage
of your projects is one used? I have never used one in
personal or professional C++ programming. Am I a holdover
to days gone by?
I have never used a GC for C++, yet in none of my C++ projects
(professional or hobby) in the last 5+ years have I had a
memory leak. I often use tools such as valgrind and AQTime to
check for memory leaks, and they have yet to report any leak.
And I wrote C and assembler for some 20 years before starting in
C++, and I never had a memory leak in them, either. From
experience, I'd say that you can either write correct programs
in any language, or you can't do it in any language. The
question is one of cost. How much effort does it take.
Garbage collection is a tool which reduces the amount of coding
necessary in some specific cases. As such, it would be foolish
not to avail oneself of it when appropriate. And it would be
just as foolish to expect it to suddenly solve all your
problems, just like that.
There just exists a *style* of programming in C++ which very
naturally leads to encapsulated, clean and safe code. (This
style is drastically different from how, for example, Java
programming is usually done.)
There are many styles of programming, both in C++ and in any
other language. Many of them don't lead to encapsulated, clean
and safe code. A few do. I use very similar styles of
programming in both Java and C++, but I've seen some pretty bad
code in both as well.
Of course, I don't quite see the relevance to garbage collection
in this. Quite obviously, you can write bad code with garbage
collection. And just as obviously, you can write bad code
without garbage collection.
One situation where GC *might* help a bit is in efficiency if
you are constantly allocating and deallocating huge amounts of
small objects in tight loops. 'new' and 'delete' in C++ are
rather slow operations, and a well-designed GC might speed
things up.
However, part of my C++ programming style just naturally also
avoids doing tons of news and deletes in tight loops (which
is, again, very different from eg. Java programming where you
basically have no choice). Thus this has never been a problem
in practice.
There are applications, of course, where you don't have the
choice; where you're developing dynamic structures (graphs,
etc.). But even there, the real gain is not in runtime (which
will rarely differ more than 10%-15% one way or the other), but
in development time. If the design determines that object
lifetime can be non-determinate, then you don't have to worry
about it when coding.
Obviously, in languages in which every object is allocated
dynamically, such objects are an overwhelming majority---almost
by definition, a value type doesn't have a determinate lifetime.
In C++, typically, objects without a determinate lifetime tend
more to be special cases: value types with variable size, or
which are too expensive to copy, even when you'd like to, or
"agents": small polymorphic objects without much, if any, state,
which are passed around, typically so that an object A can do
something dependent on the actual type of another object B.
While such objects aren't the majority, at least not in most C++
programs, they do occur often enough to make it worth having
garbage collection in your toolkit. Every little bit helps, as
they say.
Even if I some day stumble across a situation where constant
allocations and deallocations are impacting negatively the
speed of a program, and there just isn't a way around it, I
can use a more efficient allocator than the default one used
by the compiler. (I have measured speedups to up to over 8
times when using an efficient allocator compared to the
default one.)
You seem to be misunderstanding the argument. There are
specific times when garbage collection might be chosen for
performance reasons, but they are fairly rare, and as you say,
you can also optimize the performance of manual schemes. The
main argument for garbage collection is greater programmer
efficiency.
(There is a second argument, involving security. The fact that
the underlying memory of an object cannot be used for any other
object as long as there remains a pointer to the original
object. In an ideal system, of course, there wouldn't be such
pointers. But in practice, it's nice that you can make behavior
defined even if they happen to occur.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34