Garbage collection in C++
pushpa...@gmail.com
Is garbage collection possible in C++. It doesn't come as part of
language support. Is there any specific reason for the same due to the
way the language is designed. Or it is discouraged due to
some specific reason. If someone can give inputs on the same, it will
be of great help.
Regards,
Pushpa
Chris M. Thomasson
news:22b430aa-4990-4dcf...@a29g2000pra.googlegroups.com...
> Hi all,
>
> Is garbage collection possible in C++.
Sure:
http://www.hpl.hp.com/personal/Hans_Boehm/gc
> It doesn't come as part of
> language support. Is there any specific reason for the same due to the
> way the language is designed. Or it is discouraged due to
> some specific reason. If someone can give inputs on the same, it will
> be of great help.
C++ is a low-level systems language, IMVHO, that's no place for a GC to
be...
Bharath
> <pushpakul...@gmail.com> wrote in message
Check out: http://www.research.att.com/~bs/bs_faq.html#garbage-collection
- bharath
Juha Nieminen
I have absolutely no experience in third-party garbage collectors for
C++. What I have always wondered, though, is how those can handle a
situation like:
int* foo()
{
int* table = new int[100];
return table+40;
}
The pointer to the beginning of the allocated array dies when foo()
terminates, but a pointer to one of its elements lives beyond the scope
of foo(). This pointer may be used in the calling code. A garbage
collector would have to:
1) Know that there's still a live pointer pointing to (an element
inside) the array, and thus it cannot destroy it yet.
2) Know to delete the array properly (ie. from the original pointer
pointing to the beginning of the array, rather than the one which lived
longer than that) when that returned pointer dies and the GC runs.
I suppose they have figured out these problems. I'm just wondering how.
Pete Becker
>
> I have absolutely no experience in third-party garbage collectors for
> C++. What I have always wondered, though, is how those can handle a
> situation like:
>
> int* foo()
> {
> int* table = new int[100];
> return table+40;
> }
>
> The pointer to the beginning of the allocated array dies when foo()
> terminates, but a pointer to one of its elements lives beyond the scope
> of foo(). This pointer may be used in the calling code. A garbage
> collector would have to:
>
> 1) Know that there's still a live pointer pointing to (an element
> inside) the array, and thus it cannot destroy it yet.
>
> 2) Know to delete the array properly (ie. from the original pointer
> pointing to the beginning of the array, rather than the one which lived
> longer than that) when that returned pointer dies and the GC runs.
>
> I suppose they have figured out these problems. I'm just wondering how.
It's just a bit of bookkeeping. When the array is allocated the
collector makes notes about the size of the allocated block and where
it begins. The returned pointer points into the allocated block, so the
block is still live.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)
Joe Smith
<pushpa...@gmail.com> wrote in message
news:22b430aa-4990-4dcf...@a29g2000pra.googlegroups.com...
The C++ standardization commitee is working with some garbage collection
related proposals,
although no official garbage collection mechanism will be included in C++0x.
It is not yet clear
if the auxillary proposal to make it easier to support garbage collection
via third party libraries
will be approved for C++0x or not.
Pete Becker
It's quite clear, since it was approved at the September meeting. <g>
Search for "safely derived pointer" in the current working draft.
Joe Smith
"Pete Becker" <pe...@versatilecoding.com> wrote in message
news:2008111514561516807-pete@versatilecodingcom...
> On 2008-11-15 13:44:20 -0500, "Joe Smith" <unknown...@hotmail.com>
> said:
>> The C++ standardization commitee is working with some garbage collection
>> related proposals,
>> although no official garbage collection mechanism will be included in
>> C++0x. It is not yet clear
>> if the auxillary proposal to make it easier to support garbage collection
>> via third party libraries
>> will be approved for C++0x or not.
>
> It's quite clear, since it was approved at the September meeting. <g>
> Search for "safely derived pointer" in the current working draft.
>
if the auxillary proposal was included. I'm trying to follow things, but
I am not reading every posted paper, so I may well miss things.
Chris M. Thomasson
news:7OCTk.31$m74...@newsfe24.iad...
C++ is nice because it allows the user to apply just enough of its features
to get the job done. You can use C++ for kernel programming; just not all of
it...
;^D
James Kanze
> Is garbage collection possible in C++.
Yes and no. There are, in fact, a few constructs which could
break it, and there are potential compiler optimizations which
could prevent it from being used.. In practice, the language
constructs are recognized as poor programming practice, and
something to be avoided, regardless, and compilers don't do
optimizations which would break it, and in fact, it is more or
less widely used; see
http://www.hpl.hp.com/personal/Hans_Boehm/gc/.
> It doesn't come as part of language support. Is there any
> specific reason for the same due to the way the language is
> designed. Or it is discouraged due to some specific reason. If
> someone can give inputs on the same, it will be of great help.
More history than any other reasons. It's readily available,
and works, and is being used by a number of people.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
> <pushpakul...@gmail.com> wrote in message
> news:22b430aa-4990-4dcf...@a29g2000pra.googlegroups.com...
> > Is garbage collection possible in C++.
> Sure:
> http://www.hpl.hp.com/personal/Hans_Boehm/gc
> > It doesn't come as part of language support. Is there any
> > specific reason for the same due to the way the language is
> > designed. Or it is discouraged due to some specific reason.
> > If someone can give inputs on the same, it will be of great
> > help.
> C++ is a low-level systems language, IMVHO, that's no place
> for a GC to be...
C++ is a multi-paradigm language, usable in many contexts. If
you're writing kernel code, a garbage collector certainly has no
place; nor do exceptions, for that matter. And if you're
implementing a garbage collector, obviously, you can't use it.
But for most application programs, it's stupid not to.
George Kettleborough
A related question if I may: Is garbage collection necessary if the
programmer follows a strict RAII design ie. only allocating and
deallocating resources in constructors and destructors? Is garbage
collection just to enable you to program more like Java ie. creating
objects on the heap by using new everywhere? What is the advantage of this?
Java also has the finally block, and I understand this won't be
implemented in C++(0x) any time soon because it's not necessary with
RAII. Can garbage collection in C++ work to the same extent as it does
in Java without the finally block?
--
George Kettleborough
Ian Collins
> On 15/11/08 15:57, pushpa...@gmail.com wrote:
>> Hi all,
>>
>> Is garbage collection possible in C++. It doesn't come as part of
>> language support. Is there any specific reason for the same due to the
>> way the language is designed. Or it is discouraged due to
>> some specific reason. If someone can give inputs on the same, it will
>> be of great help.
>>
>> Regards,
>> Pushpa
>
> A related question if I may: Is garbage collection necessary if the
> programmer follows a strict RAII design ie. only allocating and
> deallocating resources in constructors and destructors? Is garbage
> collection just to enable you to program more like Java ie. creating
> objects on the heap by using new everywhere? What is the advantage of this?
>
> Java also has the finally block, and I understand this won't be
> implemented in C++(0x) any time soon because it's not necessary with
> RAII. Can garbage collection in C++ work to the same extent as it does
> in Java without the finally block?
>
Yes.
--
Ian Collins
James Kanze
<g.kettleboro...@member.fsf.org> wrote:
> On 15/11/08 15:57, pushpakul...@gmail.com wrote:
> > Is garbage collection possible in C++. It doesn't come as
> > part of language support. Is there any specific reason for
> > the same due to the way the language is designed. Or it is
> > discouraged due to some specific reason. If someone can give
> > inputs on the same, it will be of great help.
> A related question if I may: Is garbage collection necessary
> if the programmer follows a strict RAII design ie. only
> allocating and deallocating resources in constructors and
> destructors?
It rarely makes sense to allocate memory in constructors and
deallocate in destructors. If that's what you're doing, it's
generally preferable to use an object directly, with no dynamic
allocation. There are exceptions, of course, but they're a lot
less frequent than people make out. The main motivation for
using dynamic allocation is precisely because the lifetime of
the object must be arbitrary, and doesn't fit any pre-defined
pattern.
> Is garbage collection just to enable you to program more like
> Java ie. creating objects on the heap by using new everywhere?
> What is the advantage of this?
At the lowest level, garbage collection has two major effects:
it allows memory which can no longer be accessed to be reused
(without programmer intervention), and it forbids memory which
can still be accessed from being reused. The first results in
less work for the programmer in a number of specific instances;
it isn't the panacea that some Java proponents would have us
believe, but every little bit helps. The second results in more
robust programs; the memory for one object can't be reused for
another object due to a premature delete. (Premature delete is
a bug that can be exploited to break security, so you definitly
want garbage collection for this reason if your program connects
directly to the Internet.)
> Java also has the finally block, and I understand this won't
> be implemented in C++(0x) any time soon because it's not
> necessary with RAII. Can garbage collection in C++ work to the
> same extent as it does in Java without the finally block?
What does garbage collection have to do with the finally block?
For that matter, at the level garbage collection works, what is
the difference between a finally block and the destructor of a
local object?
George Kettleborough
> On Nov 16, 8:38 am, George Kettleborough
> <g.kettleboro...@member.fsf.org> wrote:
>> On 15/11/08 15:57, pushpakul...@gmail.com wrote:
>
>>> Is garbage collection possible in C++. It doesn't come as
>>> part of language support. Is there any specific reason for
>>> the same due to the way the language is designed. Or it is
>>> discouraged due to some specific reason. If someone can give
>>> inputs on the same, it will be of great help.
>
>> A related question if I may: Is garbage collection necessary
>> if the programmer follows a strict RAII design ie. only
>> allocating and deallocating resources in constructors and
>> destructors?
>
> It rarely makes sense to allocate memory in constructors and
> deallocate in destructors. If that's what you're doing, it's
> generally preferable to use an object directly, with no dynamic
> allocation. There are exceptions, of course, but they're a lot
> less frequent than people make out. The main motivation for
> using dynamic allocation is precisely because the lifetime of
> the object must be arbitrary, and doesn't fit any pre-defined
> pattern.
How would you implement something like a vector without dynamically
allocated memory? I thought dynamically allocated memory was used
because the amount of memory needed can only be decided at run time.
>> Is garbage collection just to enable you to program more like
>> Java ie. creating objects on the heap by using new everywhere?
>> What is the advantage of this?
>
> At the lowest level, garbage collection has two major effects:
> it allows memory which can no longer be accessed to be reused
> (without programmer intervention), and it forbids memory which
> can still be accessed from being reused. The first results in
> less work for the programmer in a number of specific instances;
> it isn't the panacea that some Java proponents would have us
> believe, but every little bit helps. The second results in more
> robust programs; the memory for one object can't be reused for
> another object due to a premature delete. (Premature delete is
> a bug that can be exploited to break security, so you definitly
> want garbage collection for this reason if your program connects
> directly to the Internet.)
I suppose what I don't get is why you would ever want to create objects
on the stack. It's something you can't do in Java, and it's much quicker
to create them on the stack plus they get destructed automatically when
the go out of scope.
>> Java also has the finally block, and I understand this won't
>> be implemented in C++(0x) any time soon because it's not
>> necessary with RAII. Can garbage collection in C++ work to the
>> same extent as it does in Java without the finally block?
>
> What does garbage collection have to do with the finally block?
> For that matter, at the level garbage collection works, what is
> the difference between a finally block and the destructor of a
> local object?
Well, if you are using new in a try block, and an exception is thrown,
C++ will guarantee the destruction of the pointer and anything else on
the stack but it won't call delete for what you allocated there. I
thought the finally block was to "clean up" any resources you allocated
in the try block, something that isn't necessary if you don't
dynamically allocate resources in there (but instead in the constructors
of objects create there, which are guaranteed to be destroyed).
Maybe I have got this all wrong and I am confusing myself, forgive me
because I'm only just beginning to really learn C++!
--
George Kettleborough
Erik Wikström
Yes, vectors (and other containers) generally needs dynamic allocations
since you do not know how much memory they will need when they are
created (and you might not have enough space on the stack). But for
these kinds of things memory management is easy since you know when you
need to free the memory (when the container dies). The problem is when
you need to create an object in one place and then pass on ownership to
somewhere else (which in turn might pass on ownership).
>>> Java also has the finally block, and I understand this won't
>>> be implemented in C++(0x) any time soon because it's not
>>> necessary with RAII. Can garbage collection in C++ work to the
>>> same extent as it does in Java without the finally block?
>>
>> What does garbage collection have to do with the finally block?
>> For that matter, at the level garbage collection works, what is
>> the difference between a finally block and the destructor of a
>> local object?
>
> Well, if you are using new in a try block, and an exception is thrown,
> C++ will guarantee the destruction of the pointer and anything else on
> the stack but it won't call delete for what you allocated there. I
> thought the finally block was to "clean up" any resources you allocated
> in the try block, something that isn't necessary if you don't
> dynamically allocate resources in there (but instead in the constructors
> of objects create there, which are guaranteed to be destroyed).
For those kinds of situations you can use auto_ptr or some other smart
pointer which will take care of freeing the allocated memory when they
go out of scope (such as when an exception is thrown). What you can not
do without finally is to free other resources, such as opened files,
unless you build a smart fstream or use guard-classes (can't remember if
that is the correct term). Of course, if the fstream is on the stack you
do not have to worry.
--
Erik Wikström
Juha Nieminen
> It rarely makes sense to allocate memory in constructors and
> deallocate in destructors. If that's what you're doing, it's
> generally preferable to use an object directly, with no dynamic
> allocation.
Just because the only place where the memory is deallocated is inside
the destructor, that doesn't mean the memory is *always* deallocated
when the destructor is called. Think about smart pointers and other
similar classes (such as eg. some implementation of std::string which
implements copy-on-write).
Besides, if the object allocates a variable amount of memory, then
allocation and destruction is obviously necessary regardless of how you
use the object.
Juha Nieminen
> A related question if I may: Is garbage collection necessary if the
> programmer follows a strict RAII design ie. only allocating and
> deallocating resources in constructors and destructors? Is garbage
> collection just to enable you to program more like Java ie. creating
> objects on the heap by using new everywhere? What is the advantage of this?
In my previous job I worked for over 5 years in an extensive C++
project, and in my current job I have done so for over 1.5 years.
Although counting lines of code is not really a perfect measurement of
the amount of work done, and I haven't measured exactly how much code I
have written in total in these two jobs, I wouldn't be surprised if it
was well over 100k LOC. Many of the programs deal with dynamically
allocated memory in rather complex ways.
I have from time to time checked for memory leaks in all my programs
with profilers. How many memory leaks have I had in all these years in
all my C++ programs? Zero. Not even once have I had a single memory leak
in any of my code. During these tests I have found many memory leaks in
third-party libraries (which I had to then fix myself), but none in my
own code.
Also I don't remember even once having accessed freed memory. I have
had a few cases where I have accessed allocated memory out of boundaries
(usually because of an off-by-1 mistake), but even those have been less
than a dozen (mostly in the earlier years), and caught rather quickly.
I really haven't ever felt the need for a GC engine in my work. Could
a GC engine have made my job easier in a few cases? Maybe. I can't say
for sure. At most it could have perhaps saved a bit of writing work, but
not increased the correctness of my code in any way. C++ makes it quite
easy to write safe code when you follow some simple rules.
> Java also has the finally block, and I understand this won't be
> implemented in C++(0x) any time soon because it's not necessary with
> RAII.
I must admit I don't have too much Java programming experience, but if
I'm not completely mistaken, finally-blocks can be used in Java, for
example, to do things like this (in pseudo-java):
void foo()
{
try
{
infile = open_file_here;
perform_lots_of_complicated_stuff_which_might_throw;
}
finally
{
close(infile);
}
}
Of course in situations like this there just is no need for a
'finally' block in C++, as the same effect can be achieved almost
automatically:
void foo()
{
std::istream infile(whatever);
perform_lots_of_complicated_stuff_which_might_throw;
// the stream will be automatically closed when foo() is exited
// without having to do anything special to achieve that.
}
Sam
> On 15/11/08 15:57, pushpa...@gmail.com wrote:
>> Hi all,
>>
>> Is garbage collection possible in C++. It doesn't come as part of
>> language support. Is there any specific reason for the same due to the
>> way the language is designed. Or it is discouraged due to
>> some specific reason. If someone can give inputs on the same, it will
>> be of great help.
>>
>> Regards,
>> Pushpa
>
> A related question if I may: Is garbage collection necessary
I'll stop right here. The answer is, obviously, "no", insofar as C++ is
concerned.
The regular posts here about garbage collection in C++ typically come from
newbie programmers who haven't acquired sufficient discipline to keep track
of their own objects. So they seek for a security blanket called "garbage
collection", so they don't have to worry about it, and can proceed to churn
out their spaghetti code without worry, just like they do in Java.
Occasionally some of them stumble across one of several "garbage collection
for C++" libraries, that float out there, and think they've hit paydirt.
Unfortunately, they fail to realize that there are fundamental differences
between C++ and Java, and no "garbage collection" library is going to solve
it.
> Is garbage collection just to enable you to program more like Java ie.
> creating objects on the heap by using new everywhere?
Yes. And not caring about proper class design, and structure. The "C++ for
dummies" approach.
> RAII. Can garbage collection in C++ work to the same extent as it does
> in Java without the finally block?
No. Garbage collection in C++ will not work to the same extent, but for
other reasons.
Juha Nieminen
>> Is garbage collection just to enable you to program more like Java ie.
>> creating objects on the heap by using new everywhere?
>
> Yes. And not caring about proper class design, and structure. The "C++
> for dummies" approach.
Sometimes I get the impression that garbage collection actually causes
people to write *less* modular and more imperative programs. GC doesn't
really encourage encapsulation and modularity.
Sure, you might not get a (permanent) memory leak when you have GC and
you can freely allocate and toss anything you like, but I wonder if this
kind of "irresponsible" programming style doesn't naturally lead to less
modular, less encapsulated programs which are more akin to spaghetti code.
Keith H Duggar
> On Nov 15, 5:32 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > C++ is a low-level systems language, IMVHO, that's no place
> > for a GC to be...
>
> C++ is a multi-paradigm language, usable in many contexts. If
> you're writing kernel code, a garbage collector certainly has no
> place; nor do exceptions, for that matter. And if you're
> implementing a garbage collector, obviously, you can't use it.
> But for most application programs, it's stupid not to.
RAII, RRID, STL containers, automatic variables, value-based design,
and other software design patterns have served exceptionally well in
eliminating both the need and the want for GC in my work.
Furthermore almost every memory management problem I remember finding
recently that would have gone unnoticed in a GC environment was not
only
a resource management problem but was also a logical or design flaw
that
was much better found than swept under the GC rug.
Finally, the deterministic design patterns we employ to eliminate
memory
management problems also apply directly to other scare resources such
as
ports, handles, connections, locks, etc. The same cannot be said for
GC.
How does the above make me stupid for not using GC?
KHD
Keith H Duggar
My experience echos Juha's almost exactly and I entirely agree
with his conclusion. Futhermore, the determinstic design patterns
that C++ supports help one manage /any/ scarce resource; they are
not limited primarily to memory as GC is. Finally and ironically,
GC can sweep design errors under the rug actually reducing the
semantic correctness of your code rather than improving it.
KHD
hurcan solter
concurrent programming
it may get really confusing the manage the lifetime of objects when
multiple threads
accessing them ,deleting an object when another thread making use of
it may cause you
headaches(e.g lock-free data structures). although there are solutions
like thread-safe reference counting or hazard pointers they are either
complex or steep on performance and their use are not widespread. GC
may relieve you there.
Hurcan Solter
James Kanze
That's certainly one possible reason. It doesn't affect
application code too often, however, because it's already
handled by things like std::vector. If you're implementing
something like the standard library, my comments probably don't
apply. But I doubt that that's the case for most of us.
> >> Is garbage collection just to enable you to program more
> >> like Java ie. creating objects on the heap by using new
> >> everywhere? What is the advantage of this?
> > At the lowest level, garbage collection has two major
> > effects: it allows memory which can no longer be accessed to
> > be reused (without programmer intervention), and it forbids
> > memory which can still be accessed from being reused. The
> > first results in less work for the programmer in a number of
> > specific instances; it isn't the panacea that some Java
> > proponents would have us believe, but every little bit
> > helps. The second results in more robust programs; the
> > memory for one object can't be reused for another object due
> > to a premature delete. (Premature delete is a bug that can
> > be exploited to break security, so you definitly want
> > garbage collection for this reason if your program connects
> > directly to the Internet.)
> I suppose what I don't get is why you would ever want to
> create objects on the stack. It's something you can't do in
> Java, and it's much quicker to create them on the stack plus
> they get destructed automatically when the go out of scope.
I'm not sure I understand what you're saying. You seem to be
contradicting yourself; I suspect that you left out a word
somewhere, but I'm not sure where.
Anyway, unlike Java, C++ has full support for value types, and
you should use them whenever appropriate. In practice, most
objects will be on the stack.
> >> Java also has the finally block, and I understand this
> >> won't be implemented in C++(0x) any time soon because it's
> >> not necessary with RAII. Can garbage collection in C++ work
> >> to the same extent as it does in Java without the finally
> >> block?
> > What does garbage collection have to do with the finally
> > block? For that matter, at the level garbage collection
> > works, what is the difference between a finally block and
> > the destructor of a local object?
> Well, if you are using new in a try block, and an exception is
> thrown, C++ will guarantee the destruction of the pointer and
> anything else on the stack but it won't call delete for what
> you allocated there. I thought the finally block was to "clean
> up" any resources you allocated in the try block, something
> that isn't necessary if you don't dynamically allocate
> resources in there (but instead in the constructors of objects
> create there, which are guaranteed to be destroyed).
The finally block is there to do any actions that must be
performed, period. Just because you have garbage collection
doesn't mean that the could be other actions which need to be
performed.
In C++, destructors of on stack objects (RAII) do the same job.
They require a bit more coding to use in isolated cases, but in
general cases (which seem to prevail), they ensure that the
"clean-up" code is implemented with the code which causes it to
be required, and make it much more difficult for the client
programmer to forget it.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
> James Kanze wrote:
> > It rarely makes sense to allocate memory in constructors and
> > deallocate in destructors. If that's what you're doing,
> > it's generally preferable to use an object directly, with no
> > dynamic allocation.
> Just because the only place where the memory is deallocated is
> inside the destructor, that doesn't mean the memory is
> *always* deallocated when the destructor is called. Think
> about smart pointers and other similar classes (such as eg.
> some implementation of std::string which implements
> copy-on-write).
But the only thing forcing the delete into a smart pointer buys
you is confuscation? The main reason for using dynamic memory
at the application level (implementing std::Vector is obviously
a different situation) is because you need arbitrary lifetime.
The object's lifetime ends in response to some external event.
The handler for that event does the delete.
> Besides, if the object allocates a variable amount of memory,
> then allocation and destruction is obviously necessary
> regardless of how you use the object.
If you're talking about things like vector or map, they're
already written, so they're not my problem. If you're talking
about dynamically types objects, it's true that this sometimes
leads to dynamic allocation even if the object logically should
have block scope. I've not found the case to be that frequent,
but it certainly occurs. In such cases, std::auto_ptr is your
friend, and the delete will be called by the destructor of the
std::auto_ptr. Cases where a normal user would write a delete
in a destructor are fairly rare, however (although the
compilation firewall idiom would be an obvious exception).
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
> George Kettleborough wrote:
> > A related question if I may: Is garbage collection necessary
> > if the programmer follows a strict RAII design ie. only
> > allocating and deallocating resources in constructors and
> > destructors? Is garbage collection just to enable you to
> > program more like Java ie. creating objects on the heap by
> > using new everywhere? What is the advantage of this?
> In my previous job I worked for over 5 years in an extensive
> C++ project, and in my current job I have done so for over 1.5
> years. Although counting lines of code is not really a
> perfect measurement of the amount of work done, and I haven't
> measured exactly how much code I have written in total in
> these two jobs, I wouldn't be surprised if it was well over
> 100k LOC. Many of the programs deal with dynamically allocated
> memory in rather complex ways.
> I have from time to time checked for memory leaks in all my
> programs with profilers. How many memory leaks have I had in
> all these years in all my C++ programs? Zero. Not even once
> have I had a single memory leak in any of my code. During
> these tests I have found many memory leaks in third-party
> libraries (which I had to then fix myself), but none in my own
> code.
So how is this different from C? Obviously, you can write C++
code which doesn't leak memory. Just as obviously, you can
write C code which doesn't leak memory. It's just a question of
the effort involved.
> Also I don't remember even once having accessed freed memory.
> I have had a few cases where I have accessed allocated memory
> out of boundaries (usually because of an off-by-1 mistake),
> but even those have been less than a dozen (mostly in the
> earlier years), and caught rather quickly.
The classical C error: strcpy( malloc( strlen( s ) ), s ):-)?
(Back when I was working in C, if someone came to me because
their code was crashing in strange ways, this was the first
thing I'd look for.)
> I really haven't ever felt the need for a GC engine in my
> work. Could a GC engine have made my job easier in a few
> cases? Maybe. I can't say for sure. At most it could have
> perhaps saved a bit of writing work, but not increased the
> correctness of my code in any way. C++ makes it quite easy to
> write safe code when you follow some simple rules.
Yes and no. C++ certainly provides a number of tools which can
be used to improve safety. It doesn't require their use,
however, and I've seen a lot of programmers which don't use them
systematically. And of course, human beings being what they
are, regardless of the tools or the process, mistakes will
occasionally creap in.
James Kanze
> >> Is garbage collection possible in C++. It doesn't come as
> >> part of language support. Is there any specific reason for
> >> the same due to the way the language is designed. Or it is
> >> discouraged due to some specific reason. If someone can
> >> give inputs on the same, it will be of great help.
> > A related question if I may: Is garbage collection necessary
> I'll stop right here. The answer is, obviously, "no", insofar
> as C++ is concerned.
It's not necessary, no. For that matter, classes aren't
necessary either. Garbage collection is just a tool: it reduces
programmer workload, and increases the security of the resulting
code.
> The regular posts here about garbage collection in C++
> typically come from newbie programmers who haven't acquired
> sufficient discipline to keep track of their own objects.
Yah. Newbies with 20 years of C++ experience. Newbies who
unlike you actually know what they're doing. (FWIW, one of the
proponents of garbage collection in the C++ standards committee
is Bjarne Stroustrup. And he's got even more C++ experience
than I do.)
If I were in your place, I wouldn't talk about newbies. You've
consistently shown a lack of understanding of even the most
basic issues in your own postings.
> So they seek for a security blanket called "garbage
> collection", so they don't have to worry about it, and can
> proceed to churn out their spaghetti code without worry, just
> like they do in Java.
That is, of course, the most obvious bullshit I've ever seen.
There are cases where garbage collection isn't appropriate, and
cases where it is necessary. Both are relatively rare; most of
the time, it will save some programmer effort, and result in
cleaner code, but only to a limited degree.
James Kanze
> Sam wrote:
> >> Is garbage collection just to enable you to program more
> >> like Java ie. creating objects on the heap by using new
> >> everywhere?
> > Yes. And not caring about proper class design, and
> > structure. The "C++ for dummies" approach.
> Sometimes I get the impression that garbage collection
> actually causes people to write *less* modular and more
> imperative programs. GC doesn't really encourage encapsulation
> and modularity.
Garbage collection doesn't "encourage" anything. It's just a
tool. To be used when appropriate. I use it whenever I can,
and find that it results in less lines of code and more robust
and maintainable code.
James Kanze
> although it is not strictly necessary , it has its uses with
> concurrent programming it may get really confusing the manage
> the lifetime of objects when multiple threads
Attention! Garbage collection does NOT manage the lifetime of
objects. It only manages memory. It's generally useful in
multithreaded environments for performance reasons, but it
doesn't address issues as to which thread has the right to
access which objects when. That problem is completely
orthogonal to how you manage memory (unless you're writing the
memory management code yourself, of course).
Sam
> On Nov 16, 3:54 pm, Sam <s...@email-scan.com> wrote:
>> George Kettleborough writes:
>> > On 15/11/08 15:57, pushpakul...@gmail.com wrote:
>
>> >> Is garbage collection possible in C++. It doesn't come as
>> >> part of language support. Is there any specific reason for
>> >> the same due to the way the language is designed. Or it is
>> >> discouraged due to some specific reason. If someone can
>> >> give inputs on the same, it will be of great help.
>
>> > A related question if I may: Is garbage collection necessary
>
>> I'll stop right here. The answer is, obviously, "no", insofar
>> as C++ is concerned.
>
> It's not necessary, no. For that matter, classes aren't
> necessary either. Garbage collection is just a tool: it reduces
So is a shovel. It's also a tool. There are situations where you can use a
shovel to do something useful. C++ isn't one of them.
>> The regular posts here about garbage collection in C++
>> typically come from newbie programmers who haven't acquired
>> sufficient discipline to keep track of their own objects.
>
> Yah. Newbies with 20 years of C++ experience. Newbies who
Don't get snippy with me, young man. I outrank you by a few years.
> unlike you actually know what they're doing. (FWIW, one of the
> proponents of garbage collection in the C++ standards committee
> is Bjarne Stroustrup. And he's got even more C++ experience
> than I do.)
A quick search finds no evidence that he is a "proponent" of garbage
collection. He discusses the subject, but not from a position of advocacy,
and actually argues that there are better techniques available, in C++, than
garbage collection.
James Kanze
> James Kanze writes:
> > On Nov 16, 3:54 pm, Sam <s...@email-scan.com> wrote:
> >> George Kettleborough writes:
> >> > On 15/11/08 15:57, pushpakul...@gmail.com wrote:
> >> >> Is garbage collection possible in C++. It doesn't come
> >> >> as part of language support. Is there any specific
> >> >> reason for the same due to the way the language is
> >> >> designed. Or it is discouraged due to some specific
> >> >> reason. If someone can give inputs on the same, it will
> >> >> be of great help.
> >> > A related question if I may: Is garbage collection necessary
> >> I'll stop right here. The answer is, obviously, "no",
> >> insofar as C++ is concerned.
> > It's not necessary, no. For that matter, classes aren't
> > necessary either. Garbage collection is just a tool: it
> > reduces
>
> So is a shovel. It's also a tool. There are situations where
> you can use a shovel to do something useful. C++ isn't one of
> them.
You might try a better analogy. Shovels aren't used in
programming in general (although there are more than a few
programs that I would like to bury). Garbage collection is
useful in C++, and in fact, is actively being used by a number
of programmers.
> >> The regular posts here about garbage collection in C++
> >> typically come from newbie programmers who haven't acquired
> >> sufficient discipline to keep track of their own objects.
> > Yah. Newbies with 20 years of C++ experience. Newbies who
> Don't get snippy with me, young man. I outrank you by a few
> years.
If you did, you'd be retired. (The first machine I ever
programmed was an IBM 1401. Beat that if you can:-).)
> > unlike you actually know what they're doing. (FWIW, one of the
> > proponents of garbage collection in the C++ standards committee
> > is Bjarne Stroustrup. And he's got even more C++ experience
> > than I do.)
> A quick search finds no evidence that he is a "proponent" of
> garbage collection.
Have you checked in the discussions on the mail reflectors of
the standardization group? He's more interested in other
aspects, but has expressed himself in favor of garbage
collection on several occasions.
Note that this is an evolution in his position (due, I suspect,
to an evolution in garbage collection technolgy); before 1990,
he doubtlessly could have added it without really asking anyone.
But the technology available before 1990 is a far cry from what
is available today.
> He discusses the subject, but not from a position of advocacy,
> and actually argues that there are better techniques
> available, in C++, than garbage collection.
There are certainly better techniques for some things. For
others, not necessarily. Anything which reduces the amount of
code I have to write myself is a good thing; there are enough
real problems in my applications that I don't have to
artificially create extra work just to keep me busy. And like
all techniques, it can easily be abused, but the fact that
something can be abused isn't a reason for not including it in
C++.
The only real problem garbage collection has is that it has been
presented as a panacea by some (not all) Java proponents; I've
actually been told that you couldn't have memory leaks in Java,
because of garbage collection (at the same time that Sun was
admitting to serious memory leaks in Swing). If you expect
garbage collection to solve every problem, you're going to be
disappointed. But that's not a problem with garbage collection;
that's a problem with your expectations. (And it's not really
unlike many of the postings here on the subject of smart
pointers.)
Chris M. Thomasson
"James Kanze" <james...@gmail.com> wrote in message
news:39609efb-1a8d-4a37...@w1g2000prk.googlegroups.com...[...]
> > So they seek for a security blanket called "garbage
> > collection", so they don't have to worry about it, and can
> > proceed to churn out their spaghetti code without worry, just
> > like they do in Java.
> That is, of course, the most obvious bullshit I've ever seen.
> There are cases where garbage collection isn't appropriate, and
> cases where it is necessary.
Humm.. Can you give an example or two of a scenario in which a GC is
absolutely required/necessary? For some reason, I can't seem to think of one
off the top of my head. What am I missing? Perhaps I misunderstand your use
of the word "necessary"...
> Both are relatively rare; most of
> the time, it will save some programmer effort, and result in
> cleaner code, but only to a limited degree.
I have seen a couple of cases in which a GC covered up more than a "simple
memory leak". Simple example... What if the memory leak was entangled in a
logic error that sometimes caused weird execution results. If the programmer
was alerted to the memory leak, perhaps he/she could have noticed the logic
error as well. Of course, this is highly contrived case. However, it can
occur.
One bad thing about GC is that it sometimes pulls programmers into a false
sense of security, and they end up creating a sloppy design. This is NOT the
fault of the GC, but of the lazy programmer. One can create efficiently
engineered programs _and_ use a GC at the same time.
Juha Nieminen
> So how is this different from C?
C++ makes it much easier to write safe code, and following the
principles which make code safer is much simpler. In other words, there
are lots of situations where you simply don't have to worry about
leakages in any way in C++, while you do have to worry about then in C
because C doesn't help automatizing.
For example, if I instantiate an std::istream at the beginning of a
function, I just don't have to care about closing that file handle at
all. The std::istream object does it automatically for me completely
regardless of where, when and how the function in question is exited,
and regardless of how many exit points it might have. This is not the
case in C, where you always have to be very careful to not to leak (a
file handle in this case).
A garbage collection engine would certainly be much more useful when
programming in C because in C it requires a lot more work to write safe
code, and a GC engine can help a lot in that. In C++ it's my personal
feeling that a GC engine is not *that* useful.
(Of course regardless of having a GC, you can still leak file handles.)
Juha Nieminen
>> Sometimes I get the impression that garbage collection
>> actually causes people to write *less* modular and more
>> imperative programs. GC doesn't really encourage encapsulation
>> and modularity.
>
> Garbage collection doesn't "encourage" anything.
I tend to disagree. Garbage collection encourages writing
"irresponsible" code. By this I mean that since there's no need for
objects to have (memory handling) responsibilities, it easily leads to
the programmer not creating such objects at all, which in turn leads to
a more imperative style of programming, rather than a more modular style.
Some people may (and do) argue that this is a good thing, but I
wouldn't be so sure. Granted, you won't leak memory (well, not
permanently at least), but your code may suffer from spaghettification
just because you were too lazy to actually write some modules rather
than writing "raw" code.
And no, this doesn't mean *all* programmers using a GC'd language
suffer from this.
> It's just a tool. To be used when appropriate.
Well, if it would be a *choice*, then it wouldn't be so bad. There are
languages, however, where you are force-fed and you have no choice.
Chris M. Thomasson
news:QwjUk.173$Ge4...@read4.inet.fi...
> James Kanze wrote:
>> So how is this different from C?
>
> C++ makes it much easier to write safe code, and following the
> principles which make code safer is much simpler. In other words, there
> are lots of situations where you simply don't have to worry about
> leakages in any way in C++, while you do have to worry about then in C
> because C doesn't help automatizing.
>
> For example, if I instantiate an std::istream at the beginning of a
> function, I just don't have to care about closing that file handle at
> all. The std::istream object does it automatically for me completely
> regardless of where, when and how the function in question is exited,
> and regardless of how many exit points it might have. This is not the
> case in C, where you always have to be very careful to not to leak (a
> file handle in this case).
Closing a file handle in a dtor can be _very_ problematic indeed; read here:
http://groups.google.com/group/comp.lang.c++/browse_frm/thread/ec97ab562016d016
Chris M. Thomasson
"Chris M. Thomasson" <n...@spam.invalid> wrote in message
news:lEjUk.7810$Wd1....@newsfe06.iad...
> "Juha Nieminen" <nos...@thanks.invalid> wrote in message
> news:QwjUk.173$Ge4...@read4.inet.fi...
>> James Kanze wrote:
>>> So how is this different from C?
>>
>> C++ makes it much easier to write safe code, and following the
>> principles which make code safer is much simpler. In other words, there
>> are lots of situations where you simply don't have to worry about
>> leakages in any way in C++, while you do have to worry about then in C
>> because C doesn't help automatizing.
>>
>> For example, if I instantiate an std::istream at the beginning of a
>> function, I just don't have to care about closing that file handle at
>> all. The std::istream object does it automatically for me completely
>> regardless of where, when and how the function in question is exited,
>> and regardless of how many exit points it might have. This is not the
>> case in C, where you always have to be very careful to not to leak (a
>> file handle in this case).
>
> Closing a file handle in a dtor can be _very_ problematic indeed; read
> here:
>
> http://groups.google.com/group/comp.lang.c++/browse_frm/thread/ec97ab562016d016
refer to the file copy problem in following post:
http://groups.google.com/group/comp.lang.c++/msg/78a928139ca349f4
if the system specific internal call to close the file fails in the dtor of
the higher level file object, well, then the shi% will hit the fan;
permanent data loss! Ouch.
:^/
Hans Bos
"Juha Nieminen" <nos...@thanks.invalid> schreef in bericht
news:PCjUk.174$Ge4...@read4.inet.fi...
> James Kanze wrote:
>>> Sometimes I get the impression that garbage collection
>>> actually causes people to write *less* modular and more
>>> imperative programs. GC doesn't really encourage encapsulation
>>> and modularity.
>>
>> Garbage collection doesn't "encourage" anything.
>
> I tend to disagree. Garbage collection encourages writing
> "irresponsible" code. By this I mean that since there's no need for
> objects to have (memory handling) responsibilities, it easily leads to
> the programmer not creating such objects at all, which in turn leads to
> a more imperative style of programming, rather than a more modular style.
Are saying that people that can't make proper programs using garbage
collection will make good programs without gc?
Sam
> On Nov 17, 1:08 pm, Sam <s...@email-scan.com> wrote:
>> James Kanze writes:
>> > It's not necessary, no. For that matter, classes aren't
>> > necessary either. Garbage collection is just a tool: it
>> > reduces
>>
>> So is a shovel. It's also a tool. There are situations where
>> you can use a shovel to do something useful. C++ isn't one of
>> them.
>
> You might try a better analogy. Shovels aren't used in
> programming in general (although there are more than a few
> programs that I would like to bury). Garbage collection is
> useful in C++, and in fact, is actively being used by a number
> of programmers.
Garbage collection is as useful for C++ as a fifth leg would be useful to a
dog. A dog with five legs might find some use for the extra one, but most of
the time it would just get in the way.
Some people may find some cockamamie "garbage collection library" useful,
but many more do not. Furthermore, there are also people who also find
intermediate code generators useful too. Specifically ones that swallow some
glob of XML, and spew out robo-generate spaghetti code that does something
else XML-related. It's useful to a small minority, because it allows them to
put their brain in "park", and not bother learning how the stuff should
work. Which leaves them completely helpless if the end result does not work
as expected, since they have no clue how the spaghetti code works, and
what's wrong with it.
>> He discusses the subject, but not from a position of advocacy,
>> and actually argues that there are better techniques
>> available, in C++, than garbage collection.
>
> There are certainly better techniques for some things. For
> others, not necessarily. Anything which reduces the amount of
> code I have to write myself is a good thing; there are enough
There is no such magic wand that one can wave, and make a bunch of code
disappear. Anyone who thinks that is fooling themselves. Garbage
collection-based design results in larger memory requirements, greater
resources, and slower code. That's the tradeoff for not having to bother
with such troublesome tasks as keeping proper track of your objects,
yourself.
But if I wanted to go in that direction, I'd use Java.
Sam
> "Juha Nieminen" <nos...@thanks.invalid> schreef in bericht
> news:PCjUk.174$Ge4...@read4.inet.fi...
>> I tend to disagree. Garbage collection encourages writing
>> "irresponsible" code. By this I mean that since there's no need for
>> objects to have (memory handling) responsibilities, it easily leads to
>> the programmer not creating such objects at all, which in turn leads to
>> a more imperative style of programming, rather than a more modular style.
>
> Are saying that people that can't make proper programs using garbage
> collection will make good programs without gc?
No, they won't make any programs at all.
Which is a good thing. But only from a theoretical viewpoint. From a
practical viewpoint, those kinds of people should be encourage to spew out
reams of atrocious code. Some people make a pretty good living cleaning up
these messes.
Keith H Duggar
Yes. However, garbage collection is /only/ going to reclaim
memory, eventually. It's not going to correct the logical and
potentially far more serious design bugs that leaked memory
in the first place. In fact, garbage collection can and does
hide bugs exactly by allowing access to objects that should
not be accessed thus actually reducing correctness. How do
you respond to this?
The various C++ techniques that of course are familiar to you
for managing memory deterministically not only help one prevent
garbage memory, they also help one properly manage other scare
resources which garbage collection does nothing for. How do you
respond to this? Is it not better to learn the more general more
comprehensive deterministic resource management paradigms that C++
supports? And to apply them uniformly and widely?
> C++ is a multi-paradigm language, usable in many contexts. If
> you're writing kernel code, a garbage collector certainly has
> no place; nor do exceptions, for that matter. And if you're
> implementing a garbage collector, obviously, you can't use it.
> But for most application programs, it's stupid not to.
RAII, RRID, STL containers, automatic variables, value types,
and other software design patterns have served exceptionally
well in eliminating both the need and the want for GC for me.
Furthermore almost every memory management problem I remember
finding recently that would have gone unnoticed with GC in use,
was not only a resource management problem but was also a flaw
in logic or design that was much better found than swept under
the GC rug.
Finally, the deterministic design patterns C++ supports for
memory management also apply directly to other scare resources
such as ports, handles, connections, locks, etc. The same cannot
be said for GC.
In light of the above, why is it "stupid" not to use GC?
KHD
Keith H Duggar
> On Nov 16, 11:46 pm, hurcan solter <hsol...@gmail.com> wrote:
>
> > although it is not strictly necessary , it has its uses with
> > concurrent programming it may get really confusing the manage
> > the lifetime of objects when multiple threads
>
> Attention! Garbage collection does NOT manage the lifetime of
> objects. It only manages memory.
Attention! In practice the above is FALSE! If it were correct
there would not have been the rather lengthy discussion recently
in comp.lang.c++.moderated among a few of the world's foremost
C++ experts regarding "zombie" states etc.
http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/c9079ef911de670f/
(Don't be fooled by the topic. It was a Trojan Horse bearing the
gift of GC. For example see the subthread starting with post 63.
If the link fails search for "throwing default constructors".)
When one tries to divorce, in practical terms, the concepts of
object "lifetime" and object "storage" the can opens and spills
worms all over your language model. Since you did not post in
that recent thread I'm not sure what your solution for
"destroyed but not deallocated"
is. If you have one please post it so that Andrei and the like
can employ (or at least research) it.
KHD
James Kanze
> James Kanze wrote:
[...]
> A garbage collection engine would certainly be much more
> useful when programming in C because in C it requires a lot
> more work to write safe code, and a GC engine can help a lot
> in that. In C++ it's my personal feeling that a GC engine is
> not *that* useful.
For what definition of "that". It's certainly not as essential
as it is in Java. On the other hand, it fits into the
philosophy of C++, giving the programmer a maximum of tools for
him to choose from, rather than a limited set, predefined by
someone's idea of what is "good".
> (Of course regardless of having a GC, you can still leak file
> handles.)
That's an entirely different issue, which neither GC nor RAII
really address; unlike freeing memory, freeing a file handle can
fail, so you have to do it explicitly, in order to check the
status and handle a possible error. (It's also different
because it affects state outside the program; until you close
the file, other programs can't see what you've written to it.)
James Kanze
> On Nov 17, 4:18 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Nov 16, 1:24 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> > > I really haven't ever felt the need for a GC engine in my
> > > work. Could a GC engine have made my job easier in a few
> > > cases? Maybe. I can't say for sure. At most it could have
> > > perhaps saved a bit of writing work, but not increased the
> > > correctness of my code in any way. C++ makes it quite easy
> > > to write safe code when you follow some simple rules.
> > Yes and no. C++ certainly provides a number of tools which
> > can be used to improve safety. It doesn't require their
> > use, however, and I've seen a lot of programmers which don't
> > use them systematically. And of course, human beings being
> > what they are, regardless of the tools or the process,
> > mistakes will occasionally creap in.
> Yes. However, garbage collection is /only/ going to reclaim
> memory, eventually. It's not going to correct the logical and
> potentially far more serious design bugs that leaked memory in
> the first place.
Woah. If the error is leaked memory, garbage collection may
correct it. Or it may not, depending on whether there is still
a pointer floating around to the memory. (The Java bugs data
base has more than a few cases of memory leaks in it.)
That's not what garbage collection is for. Garbage collection
isn't designed to make an incorrect program correct---I don't
think any tool can guarantee that. Garbage collection (like all
of the other tools I know) is designed to make it easier to
write a correct program. It also makes the effects of some
errors (dangling pointers) less critical.
> In fact, garbage collection can and does hide bugs exactly by
> allowing access to objects that should not be accessed thus
> actually reducing correctness. How do you respond to this?
How should I respond to some wild and erroneous claim? In fact,
garbage collection helps to detect bugs; it is necessary in
order to effectively detect precisely the bug you describe.
Without garbage collection, it's undefined behavior; with
garbagea collection, it's a testable condition.
> The various C++ techniques that of course are familiar to you
> for managing memory deterministically not only help one
> prevent garbage memory,
They also require additional work.
> they also help one properly manage other scare resources which
> garbage collection does nothing for. How do you respond to
> this?
Different "resources" have different constraints. Garbage
collection is fine for memory. RAII often (usually?) works well
for locks and such. You need explicit, programmer controlled
management for resources such as open files, where "release" can
fail. One size doesn't fit all.
Memory is, of course, a very special resource, since it is used
by *all* objects. Only a very small subset of objects use any
other resource (except CPU, but that one pretty much takes care
of itself). So if memory is automatically managed, only a very
small subset of objects need explicit handling, rather than all
of them. Which means less work for the programmer.
> Is it not better to learn the more general more comprehensive
> deterministic resource management paradigms that C++ supports?
> And to apply them uniformly and widely?
You need to understand many different types of resource
management (and often transaction management in general---the
problem isn't just resources) if you want to write correct code.
Garbage collection doesn't dumb down the language, so that
idiots can use it. It just means that an intelligent programmer
has less lines of code to write. No more, no less.
> > C++ is a multi-paradigm language, usable in many contexts. If
> > you're writing kernel code, a garbage collector certainly has
> > no place; nor do exceptions, for that matter. And if you're
> > implementing a garbage collector, obviously, you can't use it.
> > But for most application programs, it's stupid not to.
> RAII, RRID, STL containers, automatic variables, value types,
> and other software design patterns have served exceptionally
> well in eliminating both the need and the want for GC for me.
Exactly. You've mentionned a number of very useful tools.
Garbage collection is just one more to add to the list.
Sometimes, it will mean that you need to write less code.
> Furthermore almost every memory management problem I remember
> finding recently that would have gone unnoticed with GC in
> use, was not only a resource management problem but was also a
> flaw in logic or design that was much better found than swept
> under the GC rug.
That's an oxymoron. If it was a memory management problem, then
garbage collection might have solved it (or it might not---if
you leave unused entries in an std::map, garbage collection
isn't going to remove them for you). If it was a flaw in logic
or design, then it's not a memory management problem. And if it
isn't detected by your development process (code review, tests,
etc.), with or without garbage collection, then you have a
serious problem in your development process.
> Finally, the deterministic design patterns C++ supports for
> memory management also apply directly to other scare resources
> such as ports, handles, connections, locks, etc. The same
> cannot be said for GC.
Except that there is no one design pattern that applies equally
to all resources (or other state which must be rolled back).
> In light of the above, why is it "stupid" not to use GC?
Not doing so means more lines of code. If you don't have enough
to do, and your employer is happy to pay you for busy work,
fine. Otherwise, you really should have garbage collection in
your tool kit (supposing other constraints allow it).
James Kanze
> James Kanze wrote:
> >> Sometimes I get the impression that garbage collection
> >> actually causes people to write *less* modular and more
> >> imperative programs. GC doesn't really encourage encapsulation
> >> and modularity.
> > Garbage collection doesn't "encourage" anything.
> I tend to disagree.
Sorry, but it's a statement of fact. Garbage collection is just
a tool; a piece of code. It can't encourage or discourage
anything.
At one time, some proponents of garbage collection were trying
to sell it as a silver bullet. Or rather, to sell it as part of
a larger package which was presented as a silver bullet.
Serious programmers, of course, no that silver bullets don't
exist.
> Garbage collection encourages writing "irresponsible" code.
How can some code in your machine encourage anything. You're
attributing motives and characterists of a living being to an
inanimate object. (There's a name for this, but I've forgotten
it. But it's frequent among programmers---how often do you hear
a programmer talk about a "bug" which "crept into" his software,
rather than to say "I made an error"?)
> By this I mean that since there's no need for objects to have
> (memory handling) responsibilities, it easily leads to the
> programmer not creating such objects at all, which in turn
> leads to a more imperative style of programming, rather than a
> more modular style.
Sorry, but I can't follow this at all. Garbage collection
certainly reduces the need for objects dedicated uniquely to
memory management, but how does this relate to whether code is
imperative or not.
For that matter, there are cases where an imperative style is
good. One size doesn't fit all; you need to use the appropriate
technique, among all of those available, to solve each problem.
In practice, garbage collection makes OO (OO in the sense of
using polymorphic objects) easier; polymorphic objects generally
have to be allocated dynamically (supposing the exact type not
known at compile time).
> Some people may (and do) argue that this is a good thing,
What is a good thing?
> but
> I wouldn't be so sure. Granted, you won't leak memory (well,
> not permanently at least),
Where to you get this. Garbage collection doesn't mean that you
won't leak memory. The bug list for Java contains a number of
memory leaks.
> but your code may suffer from spaghettification just because
> you were too lazy to actually write some modules rather than
> writing "raw" code.
> And no, this doesn't mean *all* programmers using a GC'd
> language suffer from this.
Programmers who want to write spaghetti will write spaghetti.
With or without garbage collection. You're not going to claim
that C and C++ encourage readability, I hope. Not with the
preprocessor, pointer arithmetic, and their declaration syntax.
> > It's just a tool. To be used when appropriate.
> Well, if it would be a *choice*, then it wouldn't be so bad.
> There are languages, however, where you are force-fed and you
> have no choice.
We're talking about C++ here. Where the guiding principle is
that the programmer knows best. And the philosophy is to give
him as many different tools as possible, for him to choose what
it best at any given time.
Other languages have other philosophies. In some cases, what
they were trying to force-feed you wasn't actually a bad idea.
(I'm thinking of Eiffel and programming by contract.) But even
then, experience (mine, anyway) shows that it doesn't pay off in
the long run. As the technology (the tools set) becomes more
widely used, we learn more about it, and change our ideas
somewhat about how to use it.
There are doubtlessly applications where garbage collection
shouldn't be used at all. (There are, in fact, applications
where dynamic memory shouldn't be used at all.) And it
certainly isn't the solution for everything. But the fact that
a technology can be misused has never been an argument against
introducing it into C++, provided that it also has advantages
when correctly used.
James Kanze
:-). Yes. For a long time, C was my job security. Nothing
quite beats pointer arithmetic for spewing out reams of code
that only a guru can maintain, and the implicit declaration of
functions can be pretty cool too.
I'll admit that I don't quite understand this argument with
regards to garbage collection. Bad programmers will be bad
programmers, with or without garbage collection. ("The
determined Real Programmer can write Fortran in any language.")
C++ already offers a lot of useful features for making a mess of
things; globally, I think that in the hands of a good
programmer, garbage collection will result in smaller, easier to
understand programs (that corresponds to my experience, at
least---and I consider myself a good programmer), but I'm sure
that the bad programmers will find original ways to use it to
screw things up as well.
This is, I think, a major point in the philosophy of C++. Some
languages try to limit you to a small subset of programming
constructs, claiming that doing this will ensure maintainable
programs (or sometimes even claiming that it will ensure correct
programs). Of course, each new language in this group disagrees
which constructs, and it never works out in the end---bad
programmers are too clever. C++, on the other hand, takes the
attitude that the programmer is a mature and responsible adult,
and is not totally incompetent. And that you can and should
give him whatever tools he can best make use of, even if he
could abuse them. Or to use a frequent analogy, some languages
won't give you a saw, because you might cut yourself. C++ gives
you a chain saw, a rip saw, a band saw, and a couple of other
types of saws. So you can cut yourself badly if you don't know
what you're doing. But also cut wood, metal, or anything else,
in just about any shape you want. In this regard, garbage
collection is just another type of saw.
James Kanze
> James Kanze writes:
> > On Nov 17, 1:08 pm, Sam <s...@email-scan.com> wrote:
> >> James Kanze writes:
> >> > It's not necessary, no. For that matter, classes aren't
> >> > necessary either. Garbage collection is just a tool: it
> >> > reduces
> >> So is a shovel. It's also a tool. There are situations
> >> where you can use a shovel to do something useful. C++
> >> isn't one of them.
> > You might try a better analogy. Shovels aren't used in
> > programming in general (although there are more than a few
> > programs that I would like to bury). Garbage collection is
> > useful in C++, and in fact, is actively being used by a
> > number of programmers.
> Garbage collection is as useful for C++ as a fifth leg would
> be useful to a dog. A dog with five legs might find some use
> for the extra one, but most of the time it would just get in
> the way.
Another ridiculous analogy, which doesn't relate to anything.
> Some people may find some cockamamie "garbage collection
> library" useful, but many more do not.
Really. Every one I've talked to who's used the Boehm collector
has found it useful.
> Furthermore, there are also people who also find intermediate
> code generators useful too. Specifically ones that swallow
> some glob of XML, and spew out robo-generate spaghetti code
> that does something else XML-related. It's useful to a small
> minority, because it allows them to put their brain in "park",
> and not bother learning how the stuff should work. Which
> leaves them completely helpless if the end result does not
> work as expected, since they have no clue how the spaghetti
> code works, and what's wrong with it.
In other words, if I need to tokenize input, I should write my
tokenizer by hand, rather than use some regular expression based
tool. If I want to test my application, I should write all of
the boiler plate code by hand, rather than using some test
generator. If I want to run a program consisting of machine
instructions, I should write the machine instructions by hand,
rather than using some compiler and linker.
I think you're being a bit silly. And missing the point. Doing
less work (writing less lines of code, etc.) is good.
> >> He discusses the subject, but not from a position of
> >> advocacy, and actually argues that there are better
> >> techniques available, in C++, than garbage collection.
> > There are certainly better techniques for some things. For
> > others, not necessarily. Anything which reduces the amount
> > of code I have to write myself is a good thing; there are
> > enough
> There is no such magic wand that one can wave, and make a
> bunch of code disappear. Anyone who thinks that is fooling
> themselves. Garbage collection-based design results in larger
> memory requirements, greater resources, and slower code.
Than what? In the cases I've actually seen, garbage collection
does result in increased memory use, sometimes significantly,
and this must be taken into account. (But what is cheaper,
memory, or programmer time.) In most cases, it results in the
program running faster, or appearing to. (But of course, you
could manually optimize the non-garbage collected code to do the
same thing.)
James Kanze
> "James Kanze" <james.ka...@gmail.com> wrote in message
> news:39609efb-1a8d-4a37...@w1g2000prk.googlegroups.com...
> On Nov 16, 3:54 pm, Sam <s...@email-scan.com> wrote:
> [...]
> > > So they seek for a security blanket called "garbage
> > > collection", so they don't have to worry about it, and can
> > > proceed to churn out their spaghetti code without worry,
> > > just like they do in Java.
> > That is, of course, the most obvious bullshit I've ever
> > seen. There are cases where garbage collection isn't
> > appropriate, and cases where it is necessary.
> Humm.. Can you give an example or two of a scenario in which a
> GC is absolutely required/necessary?
Off hand, no, but I think Hans Boehm had one.
> For some reason, I can't seem to think of one off the top of
> my head. What am I missing? Perhaps I misunderstand your use
> of the word "necessary"...
Sort of. The statement wasn't meant to be taken as giving any
absolute limits, but rather simply to indicate that there is a
great range. (Of course, if you have limited resources to
develop the code, and garbage collection means you need to write
less lines of code---which it usually does---you could argue
that it is necessary to develop the code within budget.)
> > Both are relatively rare; most of the time, it will save
> > some programmer effort, and result in cleaner code, but only
> > to a limited degree.
> I have seen a couple of cases in which a GC covered up more
> than a "simple memory leak". Simple example... What if the
> memory leak was entangled in a logic error that sometimes
> caused weird execution results. If the programmer was alerted
> to the memory leak, perhaps he/she could have noticed the
> logic error as well. Of course, this is highly contrived case.
> However, it can occur.
Not with any of the organizations I've worked with. In the ones
which took quality seriously, code review and tests would have
detected the error. In the other ones, the leak likely would
have gone undetected.
Dangling pointers are a different issue. Garbage collection
allows reliable detection of dangling pointers to dynamically
allocated memory (but not to local variables); without garbage
collection, you can't detect the case reliably. And dangling
pointers are a known security risk for programs connecting to an
open network.
> One bad thing about GC is that it sometimes pulls programmers
> into a false sense of security,
Garbage collection is just a bunch of code. It doesn't "pull"
programmers in any way. Anthropomorphic analogies really don't
apply; code is not a living being.
> and they end up creating a sloppy design. This is NOT the
> fault of the GC, but of the lazy programmer.
Or the incompetent one. Or the mismanaged one. But programmers
don't need garbage collection to be lazy, incompetent or
mismanaged.
> One can create efficiently engineered programs _and_ use a GC
> at the same time.
Certainly. And that's why it should be an available option, to
be used as appropriate.
Hendrik Schober
> On Nov 16, 8:38 am, George Kettleborough
> <g.kettleboro...@member.fsf.org> wrote:
>
>>> Is garbage collection possible in C++. It doesn't come as
>>> part of language support. Is there any specific reason for
>>> the same due to the way the language is designed. Or it is
>>> discouraged due to some specific reason. If someone can give
>>> inputs on the same, it will be of great help.
>
>> A related question if I may: Is garbage collection necessary
>> allocating and deallocating resources in constructors and
>> destructors?
>
> deallocate in destructors. If that's what you're doing, it's
> generally preferable to use an object directly, with no dynamic
Except that the latter isn't polymorphic.
Schobi
James Kanze
> On Nov 17, 4:28 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Nov 16, 11:46 pm, hurcan solter <hsol...@gmail.com> wrote:
> > > although it is not strictly necessary , it has its uses
> > > with concurrent programming it may get really confusing
> > > the manage the lifetime of objects when multiple threads
> > Attention! Garbage collection does NOT manage the lifetime
> > of objects. It only manages memory.
> Attention! In practice the above is FALSE!
Apparently, then, you don't even know what garbage collection
does. Garbage collection manages memory. It does NOT manage
object lifetime. The two are different things (and the C++
standard very decisively keeps them separate).
> If it were correct there would not have been the rather
> lengthy discussion recently in comp.lang.c++.moderated among a
> few of the world's foremost C++ experts regarding "zombie"
> states etc.
> http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thr...
> (Don't be fooled by the topic. It was a Trojan Horse bearing
> the gift of GC. For example see the subthread starting with
> post 63. If the link fails search for "throwing default
> constructors".)
> When one tries to divorce, in practical terms, the concepts of
> object "lifetime" and object "storage" the can opens and
> spills worms all over your language model. Since you did not
> post in that recent thread I'm not sure what your solution for
> "destroyed but not deallocated"
> is. If you have one please post it so that Andrei and the like
> can employ (or at least research) it.
It's not a recent topic, and Andrei and I have discussed it in
newsgroups in the past, and unless his position has radically
changed, we more or less agree.
But I'm not sure what your question is. It's obvious that in
this case, garbage collection is necessary to protect against
and detect using dangling pointers. The idiom works because
with garbage collection, memory management is decoupled from
object lifetime; because even though the object has ceased to
exist, the memory behind it cannot be reused as long as anyone
has a pointer to it.
Sam
> On Nov 18, 12:40 am, Sam <s...@email-scan.com> wrote:
>
>> Garbage collection is as useful for C++ as a fifth leg would
>> be useful to a dog. A dog with five legs might find some use
>> for the extra one, but most of the time it would just get in
>> the way.
>
> Another ridiculous analogy, which doesn't relate to anything.
Really? What exactly is so ridiculous about it. A dog does just fine having
only four legs. It has no pressing need for a fifth one. If he had one, he'd
probably find some use for it, but most of the time it'll just get in the
way. A perfect analogy for garbage collection.
>> Some people may find some cockamamie "garbage collection
>> library" useful, but many more do not.
>
> Really. Every one I've talked to who's used the Boehm collector
> has found it useful.
You cannot extrapolate such a small sample to the world at large.
Furhtermore -- this is a perfect example:
* Forget about having a proper design. Just start allocating globs, left and
right, and rely on the garbage collector to clean up after you. This is
really a sign of a naive and inexperienced developer.
* There's nothing I like more than my application grinding to a halt, while
the garbage collector scans the heap for pointers.
>> Furthermore, there are also people who also find intermediate
>> code generators useful too. Specifically ones that swallow
>> some glob of XML, and spew out robo-generate spaghetti code
>> that does something else XML-related. It's useful to a small
>> minority, because it allows them to put their brain in "park",
>> and not bother learning how the stuff should work. Which
>> leaves them completely helpless if the end result does not
>> work as expected, since they have no clue how the spaghetti
>> code works, and what's wrong with it.
>
> In other words, if I need to tokenize input, I should write my
> tokenizer by hand, rather than use some regular expression based
> tool. If I want to test my application, I should write all of
> the boiler plate code by hand, rather than using some test
> generator. If I want to run a program consisting of machine
> instructions, I should write the machine instructions by hand,
> rather than using some compiler and linker.
A garbage collector is not a tokenizer and not a compiler. Both of these
tools do what cannot be done efficiently in other ways. There's nothing some
garbage collector does can do that cannot be done using proper design,
methodology, and programming practices. Your argument is that a garbage
collector saves you time from having to do all those pesky things one needs
to do, in order to implement something properly. Well, I suppose, but
sometimes one needs to spend the appropriate amount of time to do things
right. It's an investment well spent.
And, yes, there are certain occasions where a hand-built lexer is better.
>> There is no such magic wand that one can wave, and make a
>> bunch of code disappear. Anyone who thinks that is fooling
>> themselves. Garbage collection-based design results in larger
>> memory requirements, greater resources, and slower code.
>
> Than what?
Than proper C++ code that's designed correctly, by someone who knows what
he's doing.
> In the cases I've actually seen, garbage collection
> does result in increased memory use, sometimes significantly,
> and this must be taken into account. (But what is cheaper,
Indeed. The Sun approach. Throw gobs of memory at the problem, and hope that
it goes away.
Now I understand why people were so amazed when I managed to produce an
XML-database gateway, in C++, that consumed less than a hundred or so
of heap, per process instance. Doing these kinds of things efficiently, with
an eye towards minimizing your footprint, is virtually unknown, these days,
now with all these fancy-shmancy garbage collectors and robocode-spewers
making it "convenient" for most not to actually learn how to do this right.
zr
> On Nov 16, 11:46 pm, hurcan solter <hsol...@gmail.com> wrote:
>
> > although it is not strictly necessary , it has its uses with
> > concurrent programming it may get really confusing the manage
> > the lifetime of objects when multiple threads
>
> Attention! Garbage collection does NOT manage the lifetime of
> objects. It only manages memory. It's generally useful in
> multithreaded environments for performance reasons, but it
> doesn't address issues as to which thread has the right to
> access which objects when. That problem is completely
> orthogonal to how you manage memory (unless you're writing the
> memory management code yourself, of course).
>
you show a convincing example?
Matthias Buelow
> Yes. However, garbage collection is /only/ going to reclaim
> memory, eventually. It's not going to correct the logical and
> potentially far more serious design bugs that leaked memory
> in the first place.
Yes, GC does not correct any bugs, you're right about that ;). However,
there are many situations where having to do manual deallocation is just
additional work without any benefit. For example, if you're doing a lot
of tree handling, building trees, throwing them away again etc., you
don't really want to traverse the tree to free all the elements if you
throw it away. Much more convenient to simply "forget" the pointer to
the tree and let automatic memory management wipe it up.
(This is a bit relativized if you have a situation where you need to
have destructors run in tree nodes; in general, the concepts of
destructors and GC don't really work well together, and imho,
destructors are rather an ugly add-hoc hack that stems from the lack of
automatic memory management and because of that unfortunately has firmly
established itself in C++...)
Matthias Buelow
> By this I mean that since there's no need for
> objects to have (memory handling) responsibilities, it easily leads to
> the programmer not creating such objects at all,
Isn't that a good thing? The best code is the one you don't have to
write. Down with bureaucracy. Creating objects just to keep track of
memory dependencies is... inane?
> which in turn leads to
> a more imperative style of programming, rather than a more modular style.
Imperative programming and modular programming are orthogonal concepts.
Matthias Buelow
> How can GC improve the performance of a multithreaded application? Can
> you show a convincing example?
Many of today's programs (OO or not) have a high
allocation(/deallocation) rate. This means that most objects become
garbage quickly. With many GCs, their collection time is a function of
the amount of live data, that is, they don't have to traverse the
garbage at all. This means in total, in such a situation, there's less
work to do than in a manual deallocation scheme, where all the garbage
is being traversed aswell.
I don't know if multithreading is any factor here; with manual schemes,
you have to do synchronization, too.
zr
But even if in these (rare/common) cases where GC can improve
performance over manual deallocation, isn't there a better solution
which would give better performance than GC? Is performance a real
consideration for adding GC to the language?
Matthias Buelow
> But even if in these (rare/common) cases where GC can improve
> performance over manual deallocation, isn't there a better solution
> which would give better performance than GC? Is performance a real
> consideration for adding GC to the language?
No, convenience is. If it increases performance, all the better.
anon
>
> "James Kanze" <james...@gmail.com> wrote in message
> On Nov 16, 3:54 pm, Sam <s...@email-scan.com> wrote:
> [...]
>> > So they seek for a security blanket called "garbage
>> > collection", so they don't have to worry about it, and can
>> > proceed to churn out their spaghetti code without worry, just
>> > like they do in Java.
>
>> That is, of course, the most obvious bullshit I've ever seen.
>> There are cases where garbage collection isn't appropriate, and
>> cases where it is necessary.
>
> Humm.. Can you give an example or two of a scenario in which a GC is
> your use of the word "necessary"...
>
>
1) without gc
class A
{
};
A* foo()
{
A *a = NULL;
A *b = NULL;
a = new A;
try
{
b = new A;
}
catch(...)
{
delete(a);
}
// do something
return a;
}
2) with GC
class A
{
};
A* foo()
{
std::auto_ptr< A > a( new A );
std::auto_ptr< A > b( new A );
// do something
return a.release();
}
Would this do?
Another example:
class X
{
public:
X()
{
throw 1111;
}
};
class A
{
public:
A() : a( new int ), b( new X )
{
}
// memory leak when b throws
int *a;
X *b;
};
vs
class A
{
public:
A() : a( new int ), b( new X )
{
}
// OK
std::auto_ptr< int > a;
std::auto_ptr< X > b;
};
Chris M. Thomasson
news:6ofv0oF...@mid.dfncis.de...
> Keith H Duggar wrote:
>
>> Yes. However, garbage collection is /only/ going to reclaim
>> memory, eventually. It's not going to correct the logical and
>> potentially far more serious design bugs that leaked memory
>> in the first place.
>
> Yes, GC does not correct any bugs, you're right about that ;). However,
> there are many situations where having to do manual deallocation is just
> additional work without any benefit. For example, if you're doing a lot
> of tree handling, building trees, throwing them away again etc., you
> don't really want to traverse the tree to free all the elements if you
> throw it away. Much more convenient to simply "forget" the pointer to
> the tree and let automatic memory management wipe it up.
I would build a node cache for the trees; why free the memory when you can
reuse some of it? You can do this in a GC environment, but it requires you
to traverse a "portion" of the tree.
Also, why not use a __partitioned__ region allocation algorithm for the
nodes in different trees? That way, a single call to `std::free()' will
promptly destroy all the memory which makes up a given trees nodes in a
single operation. AFAICT, that's more efficient than a GC. Region allocation
is not complicated and drastically amortizes the number of times you need to
call free.
Generally, I find that "clever" __partitioned__ region allocation can give
you the best of both worlds... You get deterministic manual memory
management, and the calls to free get heavily amortized.
> (This is a bit relativized if you have a situation where you need to
> have destructors run in tree nodes; in general, the concepts of
> destructors and GC don't really work well together, and imho,
> destructors are rather an ugly add-hoc hack that stems from the lack of
> automatic memory management and because of that unfortunately has firmly
> established itself in C++...)
I think dtors are very convenient...
Matthias Buelow
> Generally, I find that "clever" __partitioned__ region allocation can
> give you the best of both worlds...
You seem to completely fail to understand the point I was trying to
make: Using GC in my example is not to speed up the program, or
whatever, but to avoid even having to think abut this. "Clever"
partition schemes or whatever need thinking effort, that could be
directed at more interesting parts of the program than memory management.
James Kanze
> Keith H Duggar wrote:
> > Yes. However, garbage collection is /only/ going to reclaim
> > memory, eventually. It's not going to correct the logical
> > and potentially far more serious design bugs that leaked
> > memory in the first place.
> Yes, GC does not correct any bugs, you're right about that ;).
> However, there are many situations where having to do manual
> deallocation is just additional work without any benefit.
Exactly.
> For example, if you're doing a lot of tree handling, building
> trees, throwing them away again etc., you don't really want to
> traverse the tree to free all the elements if you throw it
> away. Much more convenient to simply "forget" the pointer to
> the tree and let automatic memory management wipe it up.
> (This is a bit relativized if you have a situation where you
> need to have destructors run in tree nodes; in general, the
> concepts of destructors and GC don't really work well
> together, and imho, destructors are rather an ugly add-hoc
> hack that stems from the lack of automatic memory management
> and because of that unfortunately has firmly established
> itself in C++...)
Yes and no. Destructors and garbage collection are in some ways
orthogonal; destructors are exceedingly useful for local
variables, where they effectively replace finally blocks, only
with the provision that the client can't forget them when
needed. They are much less useful elsewhere, except for
substituting for garbage collection.
James Kanze
> news:6ofv0oF...@mid.dfncis.de...
> > Keith H Duggar wrote:
> >> Yes. However, garbage collection is /only/ going to reclaim
> >> memory, eventually. It's not going to correct the logical and
> >> potentially far more serious design bugs that leaked memory
> >> in the first place.
> > Yes, GC does not correct any bugs, you're right about that
> > ;). However, there are many situations where having to do
> > manual deallocation is just additional work without any
> > benefit. For example, if you're doing a lot of tree
> > handling, building trees, throwing them away again etc., you
> > don't really want to traverse the tree to free all the
> > elements if you throw it away. Much more convenient to
> > simply "forget" the pointer to the tree and let automatic
> > memory management wipe it up.
> I would build a node cache for the trees;
In other words, extra work. That's exactly what Matthias was
arguing against.
> why free the memory when you can reuse some of it?
Why do extra work when you don't have to?
> You can do this in a GC environment, but it requires you to
> traverse a "portion" of the tree.
> Also, why not use a __partitioned__ region allocation
> algorithm for the nodes in different trees? That way, a single
> call to `std::free()' will promptly destroy all the memory
> which makes up a given trees nodes in a single operation.
> AFAICT, that's more efficient than a GC.
For the programmer? Since when is writing additional code more
efficient.
Chris M. Thomasson
> Chris M. Thomasson wrote:
>
>> Generally, I find that "clever" __partitioned__ region allocation can
>> give you the best of both worlds...
>
> You seem to completely fail to understand the point I was trying to
> make: Using GC in my example is not to speed up the program, or
> whatever, but to avoid even having to think abut this. "Clever"
> partition schemes or whatever need thinking effort,
Does GC promote a nanny state? Just kidding! Anyway, partitioned region
allocation schemes can definitely help reduce your "thinking effort". For
instance, take this very simple C pseudo-code into account:
static struct region_allocator g_ralloc = REGION_STATIC_INIT;
static struct tree g_tree1 = TREE_STATIC_INIT;
static struct tree g_tree2 = TREE_STATIC_INIT;
static struct tree g_tree3 = TREE_STATIC_INIT;
static struct tree g_tree4 = TREE_STATIC_INIT;
int main(void) {
unsigned i;
struct region_partition* rp1 = region_allocate(&g_ralloc, 4096);
struct region_partition* rp2 = region_allocate(&g_ralloc, 4096);
for (i = 0; i < 1234; ++i) {
struct node* node1 = region_partition_allocate(rp1, sizeof(*node));
struct node* node2 = region_partition_allocate(rp1, sizeof(*node));
struct node* node3 = region_partition_allocate(rp2, sizeof(*node));
struct node* node4 = region_partition_allocate(rp2, sizeof(*node));
tree_push(&g_tree1, node1);
tree_push(&g_tree2, node2);
tree_push(&g_tree3, node3);
tree_push(&g_tree4, node4);
}
region_flush(&g_ralloc);
return 0;
};
No need to explicitly traverse all of the trees. Instead, one single call to
`region_flush()' results in the automatic freeing of all its contained
partitions. You could also free individual partitions. See how it eliminates
the need to free individual nodes? Also, more than one tree can share a
single partition. In the example, trees 1-2 share partition 1, and trees 3-4
share partition 2. IMVHO, its a fairly flexible allocation scheme indeed.
> that could be
> directed at more interesting parts of the program than memory management.
IMVHO, efficient memory management is an interesting part of any program...
Humm...
Chris M. Thomasson
On Nov 18, 4:15 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > "Matthias Buelow" <m...@incubus.de> wrote in message
> > news:6ofv0oF...@mid.dfncis.de...
> > > Keith H Duggar wrote:
> > >> Yes. However, garbage collection is /only/ going to reclaim
> > >> memory, eventually. It's not going to correct the logical and
> > >> potentially far more serious design bugs that leaked memory
> > >> in the first place.
> > > Yes, GC does not correct any bugs, you're right about that
> > > ;). However, there are many situations where having to do
> > > manual deallocation is just additional work without any
> > > benefit. For example, if you're doing a lot of tree
> > > handling, building trees, throwing them away again etc., you
> > > don't really want to traverse the tree to free all the
> > > elements if you throw it away. Much more convenient to
> > > simply "forget" the pointer to the tree and let automatic
> > > memory management wipe it up.
> > I would build a node cache for the trees;
> In other words, extra work. That's exactly what Matthias was
> arguing against.
> > why free the memory when you can reuse some of it?
> Why do extra work when you don't have to?
> > You can do this in a GC environment, but it requires you to
> > traverse a "portion" of the tree.
A node cache reduces the number of calls to `new'; IMHO, this is a good
thing.
> > Also, why not use a __partitioned__ region allocation
> > algorithm for the nodes in different trees? That way, a single
> > call to `std::free()' will promptly destroy all the memory
> > which makes up a given trees nodes in a single operation.
> > AFAICT, that's more efficient than a GC.
> For the programmer?
For the program.
> Since when is writing additional code more efficient.
Its worth it that extra work increases the scalability, throughput and
performance of a program.
Chris M. Thomasson
There are multi-threaded allocation algorihtms that do not need any
synchronization whatsoever on thread local allocations/deallocations from a
region that is not empty. Remote deallocations can be implemented wait-free
with a single atomic fetch-and-add, or lock-free with a simple
compare-and-swap loop. Here is a very crude and quick example of one:
http://webpages.charter.net/appcore/vzoom/malloc/sergey_vzmem_thread.html
James Kanze
> > On Nov 18, 12:40 am, Sam <s...@email-scan.com> wrote:
> >> Garbage collection is as useful for C++ as a fifth leg
> >> would be useful to a dog. A dog with five legs might find
> >> some use for the extra one, but most of the time it would
> >> just get in the way.
> > Another ridiculous analogy, which doesn't relate to anything.
> Really? What exactly is so ridiculous about it.
Because it doesn't relate to anything. A dog isn't like a
program, and a fifth leg has nothing to do with garbage
collection. I could just as easily make the analogy of C++
today being a dog with three legs, and garbage collection the
fourth leg. It's a little bit closer to the truth, but not
really much, since dogs and programming languages aren't really
comparable.
> A dog does just fine having only four legs. It has no pressing
> need for a fifth one. If he had one, he'd probably find some
> use for it, but most of the time it'll just get in the way. A
> perfect analogy for garbage collection.
I'd say that reducing the number of lines of code I have to
write is a pressing need:-). (Actually, my employers would say
it, since I'm paid on a time passed basis.)
> >> Some people may find some cockamamie "garbage collection
> >> library" useful, but many more do not.
> > Really. Every one I've talked to who's used the Boehm
> > collector has found it useful.
> You cannot extrapolate such a small sample to the world at
> large.
Do you have any other sample to work with. I'm not aware of any
other garbage collector.
> Furhtermore -- this is a perfect example:
> * Forget about having a proper design. Just start allocating
> globs, left and right, and rely on the garbage collector to
> clean up after you. This is really a sign of a naive and
> inexperienced developer.
Obviously, some one who doesn't know software engineering.
> * There's nothing I like more than my application grinding to
> a halt, while the garbage collector scans the heap for
> pointers.
Obvously, soe one who doesn't know how garbage collection works
today.
Sorry, but I deal in facts, not in myths and wild stories which
have no basis in reality.
> >> Furthermore, there are also people who also find
> >> intermediate code generators useful too. Specifically ones
> >> that swallow some glob of XML, and spew out robo-generate
> >> spaghetti code that does something else XML-related. It's
> >> useful to a small minority, because it allows them to put
> >> their brain in "park", and not bother learning how the
> >> stuff should work. Which leaves them completely helpless if
> >> the end result does not work as expected, since they have
> >> no clue how the spaghetti code works, and what's wrong with
> >> it.
> > In other words, if I need to tokenize input, I should write
> > my tokenizer by hand, rather than use some regular
> > expression based tool. If I want to test my application, I
> > should write all of the boiler plate code by hand, rather
> > than using some test generator. If I want to run a program
> > consisting of machine instructions, I should write the
> > machine instructions by hand, rather than using some
> > compiler and linker.
> A garbage collector is not a tokenizer and not a compiler.
> Both of these tools do what cannot be done efficiently in
> other ways.
And how is a garbage collector different. Without these tools,
you can certainly get the job done, but you need to write more
code to do it. Unlike comparing C++ to a dog, this is a valid
analogy.
> There's nothing some garbage collector does can do that cannot
> be done using proper design, methodology, and programming
> practices.
And a bit of extra work. Exactly. There's also nothing that
flex can do that cannot be done using proper design, methodology
and programming practice.
> Your argument is that a garbage collector saves you time from
> having to do all those pesky things one needs to do, in order
> to implement something properly. Well, I suppose, but
> sometimes one needs to spend the appropriate amount of time to
> do things right. It's an investment well spent.
Hacking out code to solve an already solved problem is not an
investment well spent.
> And, yes, there are certain occasions where a hand-built lexer
> is better.
Oh, certainly. And there are certain occasions when you won't
want to use garbage collection as well; no one is claiming the
contrary.
> >> There is no such magic wand that one can wave, and make a
> >> bunch of code disappear. Anyone who thinks that is fooling
> >> themselves. Garbage collection-based design results in
> >> larger memory requirements, greater resources, and slower
> >> code.
> > Than what?
> Than proper C++ code that's designed correctly, by someone who
> knows what he's doing.
Well, if he really knows what he's doing, he's got the Boehm
collector in his tool box, and will use it when it's
appropriate.
> > In the cases I've actually seen, garbage collection does
> > result in increased memory use, sometimes significantly, and
> > this must be taken into account. (But what is cheaper,
> Indeed. The Sun approach. Throw gobs of memory at the problem,
> and hope that it goes away.
It's not gobs, and it's not a vain hope. Using garbage
collection reduces the number of lines of code needed to write a
correct application. Even more, it reduces the effort required,
since I don't have to choose which smart pointer to use where.
> Now I understand why people were so amazed when I managed to
> produce an XML-database gateway, in C++, that consumed less
> than a hundred or so of heap, per process instance.
Which doesn't say anything. If you're using a SAX based parser,
there's no need for a big heap, with or without garbage
collection (and this is a perfect example of where garbage
collection does reduce the amount of work). If you're using a
DOM parser, the heap size will depend on input. If the people
who were so amazed were only familiar with DOM, and you used
SAX, you've not proved anything. (For that matter, the fact
that people are amazed generally doesn't prove much. I know a
lot of people who are amazed at Windows.)
> Doing these kinds of things efficiently, with an eye towards
> minimizing your footprint, is virtually unknown, these days,
> now with all these fancy-shmancy garbage collectors and
> robocode-spewers making it "convenient" for most not to
> actually learn how to do this right.
Apparently, wasting time worrying about things that don't matter
isn't unknown yet. There are times when your memory use
footprint is important, and there are times when it isn't.
Whether my application uses 100KB (without garbage collection)
or 200KB (with) really doesn't interest my boss as much as how
much time I need to produce it.
It's all about engineering trade-offs, and having them
available.
James Kanze
> "James Kanze" <james.ka...@gmail.com> wrote in message
> news:10c505fb-3038-42e7...@a26g2000prf.googlegroups.com...
> On Nov 18, 4:15 pm, "Chris M. Thomasson" <n...@spam.invalid>
> wrote:
> > In other words, extra work. That's exactly what Matthias was
> > arguing against.
> > > why free the memory when you can reuse some of it?
> > Why do extra work when you don't have to?
> > > You can do this in a GC environment, but it requires you to
> > > traverse a "portion" of the tree.
> A node cache reduces the number of calls to `new'; IMHO, this
> is a good thing.
The best thing would be that the program would use no memory,
run in 0 time, and be ready last week, with no programmers
having worked on it. It's not going to happen, so we have to
compromize. Reducing the number of calls to new might be a good
thing (although it's not been proven), but is it worth more
money than it costs to implement it?
> > > Also, why not use a __partitioned__ region allocation
> > > algorithm for the nodes in different trees? That way, a single
> > > call to `std::free()' will promptly destroy all the memory
> > > which makes up a given trees nodes in a single operation.
> > > AFAICT, that's more efficient than a GC.
> > For the programmer?
> For the program.
For what aspect of the program? Development cost?
Maintainability?
> > Since when is writing additional code more efficient.
> Its worth it that extra work increases the scalability,
> throughput and performance of a program.
If scalability, throughput and performance are not adequate
otherwise, then you have to do something. There are certainly
some applications where garbage collection has no place. But
they're not typical; most of the time, garbage collection will
save programmer time (and thus money) at a negligible cost
elsewhere.
Matthias Buelow
> There are multi-threaded allocation algorihtms that do not need any
> synchronization whatsoever on thread local allocations/deallocations
> from a region that is not empty.
Very good; I would think that this can (and is being) implemented for
automatic memory management, too. In the trivial case (no inter-thread
dependencies), it is obvious, and in other cases, you still have the
same synchronization problem with manual management, only it might've
moved from the alloc/dealloc routines into the application logic.
SG
> You seem to completely fail to understand the point I was trying to
> make: Using GC in my example is not to speed up the program, or
> whatever, but to avoid even having to think abut this. "Clever"
> directed at more interesting parts of the program than memory management.
This "thinking effort" pays off greatly. You only have to do this the
first couple of times. Ideally you'll become friends with handy idioms
that solve a lot of your problems without GC and without the need to
think about it so hard. It may take some time getting used to but as
far as I can tell it won't be a time waster in the long run. Note: I
know both worlds (8 years of Java experience).
IMHO, this tree example is a good one for something you can EASILY
solve without
a) garbage collection
b) getting headaches
I don't want to rule out that GC might be useful in some areas. But I
have yet to run across these kinds of problems where I would
appreciate having garbage collection. I think that avoiding garbage
PRODUCTION is fairly easy in many cases once you admit to a certain
style of programming.
Cheers!
SG
Juha Nieminen
> Closing a file handle in a dtor can be _very_ problematic indeed; read
> here:
Not more problematic than leaving the file handle open. (Besides, the
file handle was just an *example*.)
Chris M. Thomasson
"Juha Nieminen" <nos...@thanks.invalid> wrote in message
news:jyCUk.90$mk3...@read4.inet.fi...
> Chris M. Thomasson wrote:
>> Closing a file handle in a dtor can be _very_ problematic indeed; read
>> here:
>
> Not more problematic than leaving the file handle open.
How do you know that the dtor of the file wrapper object actually closed the
file? The system specific file close function can fail; think along the
lines of POSIX 'fclose()'
> (Besides, the file handle was just an *example*.)
I was nit-picking; sorry about that.
:^/
Juha Nieminen
> destructors are exceedingly useful for local
> variables, where they effectively replace finally blocks, only
> with the provision that the client can't forget them when
> needed. They are much less useful elsewhere, except for
> substituting for garbage collection.
Memory is not the only resource which needs managing. (And even in
some cases what you are managing *is* memory, but not memory which a GC
can collect. Eg. the "memory" being managed might be, for example, an
mmapped file or a bitmap in the display hardware.)
Also sometimes even when managing pure memory, you might still want to
do something special before deallocating. (Weak pointers are a very good
example.)
Juha Nieminen
> Are saying that people that can't make proper programs using garbage
> collection will make good programs without gc?
No. I'm saying that people who are fluent in programming might be more
tempted to write imperative code rather than modular code when they have
a GC engine available. After all, the imperative code usually requires
less writing (at least for the first version of the program).
Matthias Buelow
> No. I'm saying that people who are fluent in programming might be more
> tempted to write imperative code rather than modular code when they have
> a GC engine available. After all, the imperative code usually requires
> less writing (at least for the first version of the program).
I really don't understand what you mean by this.
Imperative code is:
foobie = bletch;
blorgh = knork;
Modular imperative code is:
Gront::foobie = Blobbr::bletch;
Krawall::blorgh = Wibbl::knork;
assuming there are modules Gront, Blobbr, Krawall and Wibble, which
contain these entities and :: denotes module resolution.
Manual memory management is imperative. In contrast, automatic memory
management is practically a necessity in non-imperative languages.
Functional languages like ML, Haskell etc. all have automatic memory
management. Lisp has always had GC. It would be totally impractical
attempting to manage memory manually in these high-level languages.
Juha Nieminen
> »There were two versions of it, one in Lisp and one in
> C++. The display subsystem of the Lisp version was faster.
> There were various reasons, but an important one was GC:
> the C++ code copied a lot of buffers because they got
> passed around in fairly complex ways, so it could be quite
> difficult to know when one could be deallocated. To avoid
> that problem, the C++ programmers just copied. The Lisp
> was GCed, so the Lisp programmers never had to worry about
> it; they just passed the buffers around, which reduced
> both memory use and CPU cycles spent copying.«
Yes, it's completely "fair" to compare a C++ program which doesn't
understand the concept of a smart pointer to lisp, where "smart
pointers" (in the sense that memory is garbage-collected) are inherent.
Yes: It requires more work to make that work in C++ with smart
pointers than the same thing in lisp (although making a copy-on-write
version of std::vector is not all that hard). However, that doesn't mean
that the C++ version cannot be as efficient as the lisp version. It only
means the C++ programmers were incompetent.
> »A lot of us thought in the 1990s that the big battle would
> be between procedural and object oriented programming, and
> we thought that object oriented programming would provide
> a big boost in programmer productivity. I thought that,
> too. Some people still think that. It turns out we were
> wrong. Object oriented programming is handy dandy, but
> it's not really the productivity booster that was
> promised. The real significant productivity advance we've
> had in programming has been from languages which manage
> memory for you automatically.«
I still wouldn't trade modules (the most crucial part of OOP) for GC,
if I had to make an excluding choice.
> »[A]llocation in modern JVMs is far faster than the best
> performing malloc implementations. The common code path
> for new Object() in HotSpot 1.4.2 and later is
> approximately 10 machine instructions (data provided by
> Sun; see Resources), whereas the best performing malloc
> implementations in C require on average between 60 and 100
> instructions per call (Detlefs, et. al.; see Resources).
I like how this misses one of the main reasons why memory allocation
can be slow: Cache behavior.
From experience I would estimate that the number of instructions
executed when allocating/deallocating amounts to maybe 10-20% of the
total speed, and the remaining 80-90% depends on how cache-friendly the
allocation system is. Cache misses are enormously expensive.
Good GC engines do indeed have the advantage that they can defragment
memory and make allocations more cache-friendly. This is harder (but not
impossible) to do in C/C++.
> »Perhaps the most important realisation I had while developing
> this critique is that high level languages are more important
> to programming than object-orientation. That is, languages
> which have the attribute that they remove the burden of
> bookkeeping from the programmer to enhance maintainability and
> flexibility are more significant than languages which just
> add object-oriented features. While C++ adds object-orientation
> to C, it fails in the more important attribute of being high
> level. This greatly diminishes any benefits of the
> object-oriented paradigm.«
On the other hand many "high-level languages" offer abstractions at
the expense of memory usage efficiency. There are "high-level languages"
where it's prohibitively difficult to create very memory-efficient
programs (which handle enormous amounts of data) while still maintaining
a fair amount of abstraction and maintainability.
This seems to have been the trend during the past 10-20 years:
Completely disregard memory usage efficiency in favor of higher level
abstractions. After all, everybody has a supercomputer on their desk and
everything they do with it is play tic-tac-toe. You don't need memory
usage efficiency, right?
C++ might not be all fancy-pancy with all the latest fads in
programming, but at least it offers the tools to write very
memory-efficient programs which are still very well designed, with a
high degree of modularity, abstraction and maintainability. That cannot
be said about all programming languages.
Juha Nieminen
>>> Garbage collection doesn't "encourage" anything.
>
>> I tend to disagree.
>
> Sorry, but it's a statement of fact.
It might be a fact in *your* case. I disagree on it being a fact for
everybody.
I suppose we'd have to just agree to disagree.
Matthias Buelow
> abstractions. After all, everybody has a supercomputer on their desk and
> everything they do with it is play tic-tac-toe. You don't need memory
> usage efficiency, right?
And what is most of the desktop software written in?
> C++ might not be all fancy-pancy with all the latest fads in
> programming, but at least it offers the tools to write very
> memory-efficient programs which are still very well designed, with a
> high degree of modularity, abstraction and maintainability.
However, it seems to be exceedingly difficult to actually do so;
otherwise, why are most of today's applications so slow, memory hogging
and buggy?
Juha Nieminen
> Juha Nieminen wrote:
>
>> By this I mean that since there's no need for
>> objects to have (memory handling) responsibilities, it easily leads to
>> the programmer not creating such objects at all,
>
> Isn't that a good thing?
No, because it makes the code less abstract and less modular.
> The best code is the one you don't have to
> write. Down with bureaucracy. Creating objects just to keep track of
> memory dependencies is... inane?
Then don't create objects whose sole purpose is to keep track of
memory dependencies. Create objects which have a purpose and a role in
the entire design.
This might not be the best possible example of what I'm talking about,
but I think it's at least close:
Don't do: SmartArray<char> myString = new char[100];
Instead, do: String myString(100);
The "String" is effectively performing the same bookkeeping job as the
"SmartArray<char>" would, but it's already at a much higher conceptual
and abstraction level, and thus better from a design point of view.
Gargabe collection often tempts writing code like the first example,
rather than code like the second example.
>> which in turn leads to
>> a more imperative style of programming, rather than a more modular style.
>
> Imperative programming and modular programming are orthogonal concepts.
An imperative programming style can be detrimental if overweights the
modularity of the overall design.
Chris M. Thomasson
Because bloat-ware is cool! ;^D
Why do you think that most of Google is written in C++?
Chris M. Thomasson
"Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
news:C++-20081...@ram.dialup.fu-berlin.de...
[...]
> http://www.joelonsoftware.com/articles/APIWar.html
>
> 蒜A]llocation in modern JVMs is far faster than the best
> performing malloc implementations.
[...]
This is hardcore MAJOR BULLSHI%! Who ever wrote that crap is __TOTALLY__
ignorant; WOW!
What a moron.
:^|
Hendrik Schober
You mean the one who messed up the attribution of the quote?
Schobi
Hendrik Schober
> On Nov 17, 8:29 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>> James Kanze wrote:
>>>> Sometimes I get the impression that garbage collection
>>>> actually causes people to write *less* modular and more
>>>> imperative programs. GC doesn't really encourage encapsulation
>>>> and modularity.
>
>>> Garbage collection doesn't "encourage" anything.
>
>> I tend to disagree.
>
> a tool; a piece of code. It can't encourage or discourage
> anything.
OO is "just a tool", too.
Doesn't it encourage specific ways to program?
(Note that I do not necessarily defend Juha's position.
I just find yours a very weak argument.)
> [...]
Schobi
Juha Nieminen
> However, it seems to be exceedingly difficult to actually do so;
> otherwise, why are most of today's applications so slow, memory hogging
> and buggy?
Becomes the majority of programmers hired out there are incompetent?
A different programming language is not going to help that problem.
Juha Nieminen
>> 蒜A]llocation in modern JVMs is far faster than the best
>> performing malloc implementations.
> [...]
>
> This is hardcore MAJOR BULLSHI%! Who ever wrote that crap is __TOTALLY__
> ignorant; WOW!
Have you actually measured for yourself, or are you basing your
opinion on assumptions?
Juha Nieminen
> Juha Nieminen wrote:
>
>> No. I'm saying that people who are fluent in programming might be more
>> tempted to write imperative code rather than modular code when they have
>> a GC engine available. After all, the imperative code usually requires
>> less writing (at least for the first version of the program).
>
> I really don't understand what you mean by this.
char* myString = new char[100];
vs.
std::string myString(100, ' ');
(And don't nitpick on the details of the example. It's just an
example. Try to understand my *point*.)
If we had a GC engine, we might be tempted to write like the first
line above because, after all, we don't have to care about the
management of that memory. Of course the first line is extremely
non-abstract: It hard-codes the type, size and geometry of the array,
and exposes that it's accessed through a char pointer.
The second line is the more modular approach: It has encapsulated the
details inside the object, rather than them being exposed. It doesn't
hard-code the array type, it doesn't even hard-code that it *is* a
(contiguous) array, it doesn't hard-code how the array is accessed or
how it's stored in memory, and it doesn't necessarily make the array
fixed in size.
However, if you didn't have a string class like that already handled
to you by a library, the lazy approach would be to use the first method
rather than doing the work of actually encapsulating the whole concept
of "string" into a class.
I feel that a GC engine just gives the incentive to do exactly that:
Skip on the pesky encapsulation and do it in the imperative way. It's
less writing in the short run.
Matthias Buelow
> Don't do: SmartArray<char> myString = new char[100];
> Instead, do: String myString(100);
>
> Gargabe collection often tempts writing code like the first example,
> rather than code like the second example.
I don't see any truth to this statement at all.
>>> a more imperative style of programming, rather than a more modular style.
>> Imperative programming and modular programming are orthogonal concepts.
>
> An imperative programming style can be detrimental if overweights the
> modularity of the overall design.
This sentence doesn't make any sense either. Are you using a gibberish
generator?
Matthias Buelow
> char* myString = new char[100];
> vs.
> std::string myString(100, ' ');
> If we had a GC engine, we might be tempted to write like the first
> line above because, after all, we don't have to care about the
> management of that memory.
Maybe you would, I wouldn't.
> The second line is the more modular approach: It has encapsulated the
> details inside the object, rather than them being exposed. It doesn't
> hard-code the array type, it doesn't even hard-code that it *is* a
> (contiguous) array, it doesn't hard-code how the array is accessed or
> how it's stored in memory, and it doesn't necessarily make the array
> fixed in size.
And what's that got to do with GC vs. manual memory management?
> However, if you didn't have a string class like that already handled
> to you by a library, the lazy approach would be to use the first method
> rather than doing the work of actually encapsulating the whole concept
> of "string" into a class.
>
> I feel that a GC engine just gives the incentive to do exactly that:
> Skip on the pesky encapsulation and do it in the imperative way. It's
> less writing in the short run.
So you say, the whole incentive for you to abstract is memory handling.
I'm sorry you don't see the more obvious advantages of abstraction.
Automatic memory management is an abstraction in the same way that using
a string datatype over a char array is: it is relieving the programmer
of uninteresting implementation details.
Juha Nieminen
> And what's that got to do with GC vs. manual memory management?
Ok, if you can't or don't want to understand my point, then don't.
Juha Nieminen
> Juha Nieminen wrote:
>
>> Don't do: SmartArray<char> myString = new char[100];
>> Instead, do: String myString(100);
>>
>> Gargabe collection often tempts writing code like the first example,
>> rather than code like the second example.
>
> I don't see any truth to this statement at all.
Then don't.
>>>> a more imperative style of programming, rather than a more modular style.
>>> Imperative programming and modular programming are orthogonal concepts.
>> An imperative programming style can be detrimental if overweights the
>> modularity of the overall design.
>
> This sentence doesn't make any sense either. Are you using a gibberish
> generator?
If you don't want to understand, then so be it.
James Kanze
> James Kanze wrote:
> > destructors are exceedingly useful for local
> > variables, where they effectively replace finally blocks, only
> > with the provision that the client can't forget them when
> > needed. They are much less useful elsewhere, except for
> > substituting for garbage collection.
> Memory is not the only resource which needs managing.
And? Garbage collection is only concerned with memory. Other
resources need other tools.
> (And even in some cases what you are managing *is* memory, but
> not memory which a GC can collect. Eg. the "memory" being
> managed might be, for example, an mmapped file or a bitmap in
> the display hardware.)
Not sure I follow. There are certainly cases where what
superficially looks like memory isn't memory in the garbage
collector sense; in those cases, you use some other tool.
> Also sometimes even when managing pure memory, you might still
> want to do something special before deallocating. (Weak
> pointers are a very good example.)
Well, most garbage collectors support finalization (which is NOT
the same thing as a destructor); I'll admit, though, that I've
never really found a use for it.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Chris M. Thomasson
"Juha Nieminen" <nos...@thanks.invalid> wrote in message
I have measured for myself. I have created multi-threaded allocators that
are just as fast, or faster, than recent JVM's.
Chris M. Thomasson
> Chris M. Thomasson wrote:
>
>> There are multi-threaded allocation algorihtms that do not need any
>> synchronization whatsoever on thread local allocations/deallocations
>> from a region that is not empty.
>
> Very good; I would think that this can (and is being) implemented for
> automatic memory management, too.
Absolutely!
> In the trivial case (no inter-thread
> dependencies), it is obvious, and in other cases, you still have the
> same synchronization problem with manual management, only it might've
> moved from the alloc/dealloc routines into the application logic.
The internal allocator synchronization is separate from the application
synchronization. So, technically, its was not moved from alloc/dealloc
routines to application. The application always needs to ensure that the
memory it "explicitly" frees is in a persistent quiescent state. GC can
remove the need to follow this requirement.
This is why GC can make the creation of non-blocking algorihtms easier.
However, it has the side-effect of making your algorithm totally GC
dependant. You cannot really port it to a platform that does not have a GC.
Luckily, there are other algorihtms out there than can make non-blocking
algorithms GC independent.
Chris M. Thomasson
news:4d5d20a2-65ff-4e3f...@b38g2000prf.googlegroups.com...
On Nov 17, 11:28 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Nov 16, 11:46 pm, hurcan solter <hsol...@gmail.com> wrote:
> >
> > > although it is not strictly necessary , it has its uses with
> > > concurrent programming it may get really confusing the manage
> > > the lifetime of objects when multiple threads
> >
> > Attention! Garbage collection does NOT manage the lifetime of
> > objects. It only manages memory. It's generally useful in
> > multithreaded environments for performance reasons, but it
> > doesn't address issues as to which thread has the right to
> > access which objects when. That problem is completely
> > orthogonal to how you manage memory (unless you're writing the
> > memory management code yourself, of course).
> How can GC improve the performance of a multithreaded application? Can
> you show a convincing example?
What about removing the need for atomic reference counting and/or expensive
memory barriers? Of course you don't need a heavy full-blown GC to achieve
that. One can instead make use of an efficient PDR algorithm; PDR stands for
`Partial Copy-On-Write Deferred Reclamation'. The term was coined by Joe
Seigh over on `comp.programming.threads':
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/82376b7295e6ce1a
If you wish to lean more about the technique, please ask on that newsgroup.
James Kanze
> Stefan Ram wrote:
> > »There were two versions of it, one in Lisp and one in
> > C++. The display subsystem of the Lisp version was faster.
> > There were various reasons, but an important one was GC:
> > the C++ code copied a lot of buffers because they got
> > passed around in fairly complex ways, so it could be quite
> > difficult to know when one could be deallocated. To avoid
> > that problem, the C++ programmers just copied. The Lisp
> > was GCed, so the Lisp programmers never had to worry about
> > it; they just passed the buffers around, which reduced
> > both memory use and CPU cycles spent copying.«
> Yes, it's completely "fair" to compare a C++ program which
> doesn't understand the concept of a smart pointer to lisp,
> where "smart pointers" (in the sense that memory is
> garbage-collected) are inherent.
It looks to me like he's comparing to programs which do the same
thing. Probably written by people competent in the language
being used.
I'm familiar with this quote myself. I think it is somewhat
dated; it is comparing C++ as it was written some years ago with
Lisp as it was implemented some years ago. In practice, C++ has
evolved, both with regards to the language, and with regards to
the way competent programmers use it. I don't know about Lisp,
but I do know that garbage collectors have also evolved, and
that modern garbage collection is considerably faster than most
implementations of malloc (which haven't evolved). In many use
patterns, anyway.
> Yes: It requires more work to make that work in C++ with smart
> pointers than the same thing in lisp (although making a
> copy-on-write version of std::vector is not all that hard).
Making one that is multithread safe, and still has the desired
performance, is far from trivial. The experts who wrote the g++
library tried for std::string, and failed. (I'm obviously
ignoring the complexity issues; you can't use copy on write for
a fully conformant implementation of std::vector, because
something like operator[] could no longer be implemented in
constant time.)
> However, that doesn't mean that the C++ version cannot be as
> efficient as the lisp version. It only means the C++
> programmers were incompetent.
Bullshit.
> > »A lot of us thought in the 1990s that the big battle would
> > be between procedural and object oriented programming, and
> > we thought that object oriented programming would provide
> > a big boost in programmer productivity. I thought that,
> > too. Some people still think that. It turns out we were
> > wrong. Object oriented programming is handy dandy, but
> > it's not really the productivity booster that was
> > promised. The real significant productivity advance we've
> > had in programming has been from languages which manage
> > memory for you automatically.«
> I still wouldn't trade modules (the most crucial part of OOP)
> for GC, if I had to make an excluding choice.
I agree, in C++, and if we had any change of getting full
support for modules in C++, in this version, I'd be for it. But
there is no existing practice to base it on, which means that
modules are a lot more work, and involve considerable risk.
> > »[A]llocation in modern JVMs is far faster than the best
> > performing malloc implementations. The common code path
> > for new Object() in HotSpot 1.4.2 and later is
> > approximately 10 machine instructions (data provided by
> > Sun; see Resources), whereas the best performing malloc
> > implementations in C require on average between 60 and 100
> > instructions per call (Detlefs, et. al.; see Resources).
> I like how this misses one of the main reasons why memory
> allocation can be slow: Cache behavior.
True. For good cache behavior, you need a copying garbage
collector, and I don't think that that's in the cards for C++.
> From experience I would estimate that the number of
> instructions executed when allocating/deallocating amounts to
> maybe 10-20% of the total speed, and the remaining 80-90%
> depends on how cache-friendly the allocation system is. Cache
> misses are enormously expensive.
How much of a role they play depends largely on the application.
And while a copying collector can definitely have considerably
better locality than any manual allocator, I'm not sure that it
makes a difference in very many programs.
> Good GC engines do indeed have the advantage that they can
> defragment memory and make allocations more cache-friendly.
> This is harder (but not impossible) to do in C/C++.
There has been some research on using a "mostly copying"
collector with C and C++. If I were developing a compiler,
that's the route I'd go. But it requires considerable
collaboration from the compiler.
> > »Perhaps the most important realisation I had while developing
> > this critique is that high level languages are more important
> > to programming than object-orientation. That is, languages
> > which have the attribute that they remove the burden of
> > bookkeeping from the programmer to enhance maintainability and
> > flexibility are more significant than languages which just
> > add object-oriented features. While C++ adds object-orientation
> > to C, it fails in the more important attribute of being high
> > level. This greatly diminishes any benefits of the
> > object-oriented paradigm.«
> On the other hand many "high-level languages" offer
> abstractions at the expense of memory usage efficiency. There
> are "high-level languages" where it's prohibitively difficult
> to create very memory-efficient programs (which handle
> enormous amounts of data) while still maintaining a fair
> amount of abstraction and maintainability.
> This seems to have been the trend during the past 10-20 years:
> Completely disregard memory usage efficiency in favor of
> higher level abstractions. After all, everybody has a
> supercomputer on their desk and everything they do with it is
> play tic-tac-toe. You don't need memory usage efficiency,
> right?
Yes and no. In my case, most of the software I write runs on a
single machine, or on just a couple of machines; I'm not writing
shrink-wrapped software. And from a cost point of view, it's
several orders of magnitudes cheaper to configure them with
sufficient memory than it is for me to optimize the memory
footprint down to the last byte. I've known exceptions. One
case where three programmers spend two weaks just to gain 20
some bytes of code. So the program fit into a single ROM,
instead of requiring two. There were seven million examples of
the product built, and six man-weeks was less expensive than
seven million ROM's. But for most people, a couple of KB, or
even a couple of MB more or less aren't going to affect
anything.
James Kanze
> Matthias Buelow wrote:
> > However, it seems to be exceedingly difficult to actually do
> > so; otherwise, why are most of today's applications so slow,
> > memory hogging and buggy?
> Becomes the majority of programmers hired out there are
> incompetent?
Because the majority of companies don't have good development
processes. I don't believe that most programmers are
incompetent.
> A different programming language is not going to help that
> problem.
Certainly not. There are no silver bullets. And a bad process
will produce bad programs, even with the best of tools.
James Kanze
> "Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
> news:C++-20081...@ram.dialup.fu-berlin.de...
> [...]>http://www.joelonsoftware.com/articles/APIWar.html
>
> > »[A]llocation in modern JVMs is far faster than the best
> > performing malloc implementations.
> [...]
> This is hardcore MAJOR BULLSHI%! Who ever wrote that crap is
> __TOTALLY__ ignorant; WOW!
More likely, he's done some actual measurements, rather than
just basing his opinion on prejudices. That corresponds more or
less with the actual measurements I've made at different times.
For programs with a lot of allocation of short lived objects,
garbage collection beats malloc/free hands-down, performance
wise.
James Kanze
> James Kanze wrote:
> >>> Garbage collection doesn't "encourage" anything.
> >> I tend to disagree.
> > Sorry, but it's a statement of fact.
> It might be a fact in *your* case. I disagree on it being a
> fact for everybody.
There are objective facts, which do hold for everyone, whether
you like it or not. And a simple tool like garbage collection
is simply not capable of "encouraging" (or "discouraging")
anything. You're committing anthromorphism, and giving garbage
collection a power that it just doesn't have.
James Kanze
> James Kanze wrote:
> > On Nov 17, 8:29 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> >> James Kanze wrote:
> >>>> Sometimes I get the impression that garbage collection
> >>>> actually causes people to write *less* modular and more
> >>>> imperative programs. GC doesn't really encourage
> >>>> encapsulation and modularity.
> >>> Garbage collection doesn't "encourage" anything.
> >> I tend to disagree.
> > Sorry, but it's a statement of fact. Garbage collection is
> > just a tool; a piece of code. It can't encourage or
> > discourage anything.
> OO is "just a tool", too.
OO is more than just that.
> Doesn't it encourage specific ways to program?
> (Note that I do not necessarily defend Juha's position.
> I just find yours a very weak argument.)
Yes and no. It's certain that the programming language we use
does condition us to some degree. But garbage collection isn't
a programming language, nor a paradigm. It's just a very low
level tool. As such, it isn't capable of such an effect.
(Perhap Juha is confusing this with the effects of some
programming languages that happen to use garbage collection.
But C++ with garbage collection won't become Java, nor anything
like it. It will remain very much C++.)
Matthias Buelow
> Becomes the majority of programmers hired out there are incompetent?
Well, you have identified the core problem, all right.
> A different programming language is not going to help that problem.
A different memory management mechanism is not going to make much of a
difference here but it can assist the good programmers.
Chris M. Thomasson
news:b4c335d6-2e3d-412b...@v16g2000prc.googlegroups.com...
On Nov 18, 8:23 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > "Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
> > news:C++-20081...@ram.dialup.fu-berlin.de...
> > [...]>http://www.joelonsoftware.com/articles/APIWar.html
> >
> > > 蒜A]llocation in modern JVMs is far faster than the best
> > > performing malloc implementations.
> > [...]
> > This is hardcore MAJOR BULLSHI%! Who ever wrote that crap is
> > __TOTALLY__ ignorant; WOW!
> More likely, he's done some actual measurements, rather than
> just basing his opinion on prejudices. That corresponds more or
> less with the actual measurements I've made at different times.
> For programs with a lot of allocation of short lived objects,
> garbage collection beats malloc/free hands-down, performance
> wise.
Your acting as if GC totally devastates malloc/free; this is simply not
true. BTW, what makes you think I would actually allocate/deallocate single
objects with malloc/free? Here is pointer to simple region allocator which
is based on malloc/free:
http://groups.google.com/group/comp.lang.c++/browse_frm/thread/0419bf7caebf53ac
Here is a crude implementation of a scaleable general-purpose multi-threaded
region allocator which overloads global operator new/delete:
http://webpages.charter.net/appcore/vzoom/malloc/sergey_vzmem_thread.html
Last time I checked, JVM does not totally beat region allocation based on
malloc/free.
Perhaps I should code up a simple test application for this group. However,
I am not sure it would actually be on topic. What do you think?