«

I followed a link to James Kanze's web site in another thread and was
surprised to read this comment by a link to a GC:

"I can't imagine writing C++ without it"

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?

Lloyd Bonafide wrote:
> I followed a link to James Kanze's web site in another thread and was
> surprised to read this comment by a link to a GC:
>
> "I can't imagine writing C++ without it"
>
> 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 can't tell what professional C++ programming is about or similar, but
I've also never used a GC for any of my projects (and those included
ones with several months of development time and non-trivial structure).

I've never seen the need for it and in fact am rather happy if I can do
the memory management explicitelly rather than by a GC which feels
cleaner to me (BTW, I also only once needed to do reference-counting, so
for those things the "refcounting requires more time than GC"-argument
is out).

Daniel

--
Done: Bar-Sam-Val-Wiz, Dwa-Elf-Hum-Orc, Cha-Law, Fem-Mal
Underway: Ran-Gno-Neu-Fem
To go: Arc-Cav-Hea-Kni-Mon-Pri-Rog-Tou

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.

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.)

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.

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.)

Juha Nieminen <> writes:

> 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.
>
> 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.)
>
> 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.
>
> 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.)

Now, on another level, I'd say that the problem is that this safe
style you must adopt in C++ to avoid memory leaks is a burden that
forces you to spend your energy in a sterile direction.

More dynamic languages, with a garbage collector, are liberating your
mind, so your free neurons can now think about more interesting
software problems (like for example, AI, or providing a better user
experience, etc).


--
__Pascal Bourguignon__

Lloyd Bonafide wrote:
> I followed a link to James Kanze's web site in another thread and was
> surprised to read this comment by a link to a GC:
>
> "I can't imagine writing C++ without it"
>
> 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 use RAII. I've had memory leaks but it's usually due to some third
party application I didn't understand adequately. I was never able to
figure out why AQTime was reporting large chunks of memory loss in my
use of the sqlite3 library for example. We abandoned its use.

Pascal J. Bourguignon wrote:

> More dynamic languages, with a garbage collector, are liberating your
> mind, so your free neurons can now think about more interesting
> software problems (like for example, AI, or providing a better user
> experience, etc).

Hey now, what's this nonsense against the pure joy if your program looks
totally cryptic, proves that you know the fine details of an 800 pages
thick standard, and runs an infinite loop in under 3 seconds...

On Apr 10, 10:03*am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:

> More dynamic languages, with a garbage collector, are liberating your
> mind, so your free neurons can now think about more interesting
> software problems (like for example, AI, or providing a better user
> experience, etc).

You still have to worry about leaking memory (and dereferencing null
pointers) in languages like Java.

http://www.ibm.com/developerworks/li...aks/index.html

Pascal J. Bourguignon wrote:
> Now, on another level, I'd say that the problem is that this safe
> style you must adopt in C++ to avoid memory leaks is a burden that
> forces you to spend your energy in a sterile direction.

I strongly disagree. This style of programming almost automatically
leads to a clean, abstract, encapsulated design, which is only a good thing.

Programmers using languages with GC (such as Java) might not need to
worry about where their dynamically-allocated memory is going, but
neither do I, in most cases. I even dare to claim that at least in some
cases this style of modular programming produces cleaner, simpler, more
understandable and in some cases even more efficient code than a
"mindlessly use 'new' everywhere" style of programming.

I honestly don't feel that I need to put any extra effort to produce
this kind of safe and clean code. Given that I usually like the end
result as a design, even if I have to put that bit of extra effort it's
totally worth it.

> More dynamic languages, with a garbage collector, are liberating your
> mind, so your free neurons can now think about more interesting
> software problems (like for example, AI, or providing a better user
> experience, etc).

I have my doubts that this "liberating" style of programming somehow
automatically leads to clean, modular and abstract designs. All the
contrary, I would even claim that at least in some cases it leads to the
opposite direction ("reckless programming").

Razii wrote:
> In C++, each "new" allocation request
> will be sent to the operating system, which is slow.

That's blatantly false.

At least with the memory allocation logic in linux's libc (and I guess
in most other unix systems as well) the only system call that is made is
brk(), which increments the size of the heap. AFAIK this is done in
relatively large chunks to avoid every minuscule 'new' causing a brk()
call. Thus the OS is called relatively rarely. The actual memory
allocation of the blocks allocated with 'new' (or 'malloc') are done by
the routine in libc, not by the OS.

I don't know how Windows compilers do it, but I bet it's something
very similar to this.

I don't see how this is so much different from what Java does.

In article <>,
says...
> On Thu, 10 Apr 2008 17:33:21 +0300, Juha Nieminen
> <> wrote:
>
> > 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)
>
> Howeever, Java allocates new memory blocks on it's internal heap
> (which is allocated in huge chunks from the OS). In this way, in most
> of the cases it bypasses memory allocation mechanisms of the
> underlying OS and is very fast. In C++, each "new" allocation request
> will be sent to the operating system, which is slow.

I know of one library implementation for which this was true (one of the
first 32-bit versions of Visual C++), but it's generally false. Even in
that version of that compiler, the library _contained_ code to allocate
from the OS in large blocks, and then do sub-allocations out of that
block. For reasons known only to Microsoft, that code was disabled by
default.

There is still typically some difference in speed, at least when a
compacting GC is used. Specifically, since this keeps the free memory in
the heap in one large chunk, allocation is done about like on a stack.

By contrast, with a manually managed heap that doesn't do compaction,
you end up with free blocks interspersed with blocks in use. In a really
traditional design, the allocator might round the requested size up to
the next multiple of, say, 16 bytes, and then walk through the list of
free blocks to find one large enough to satisfy the request. When it
found one, it would check the current size of the block, and if it
exceeded the requested size by at least some margin, it would split the
block in two, satisfying the request with one and placing the other back
on the free list.

More recent designs do things like rounding requests to powers of two
(starting from 16 or so), and keeping a separate free list for each
size. Once you've rounded up the size, you search in the correct list,
and either a block is there, or it isn't. If it isn't, you go to the
next larger block size, split that block in half, satisfy the request
with one half, and place the other half on the previously-empty free
list for its new size.

The former version can be quite slow, especially if there are a lot of
free blocks in the system. As you can probably guess, the latter can
improve speed quite a bit.

--
Later,
Jerry.

The universe is a figment of its own imagination.