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