Re: SGCL - Garbage Collector for C++
On Mar 3, 1:20 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On 2 mar, 19:17, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On 1 mar, 06:23, Ian Collins <ian-n...@hotmail.com> wrote:
But how does a user know if an object has to be deleted,
or whether it can be left to the GC?
Maybe because he knows what the object is used for, and
why he created it in the first place?
But he'd have to whether the object had to be deleted, or
could be left for the GC.
Certainly. But that's always the case. You don't create
objects without knowing the role of the object, or what it's
there for.
But why add yet another facet?
I'm afraid I don't understand. I'm not adding anything. It's
all already there. About the only thing I'm suggesting is to
separate concerns, so the program can worry about each
separately, without being concerned about the other if it's not
relevant. (Note that there are special cases already where you
separate these concerns. It's an underlying principle in the
containers in the standard library, for example, where
initialization and allocation, as well as destruction and
deallocation, are rigorously separated.)
It's the ambiguity with C++ I don't like, especially as
C++ provides language features that make GC an
irrelevance.
Not an irrelevance. Less important, but programmer
productivity is never really irrelevant.
I still contend that correct and systematic use of smart
pointers does make GC an irrelevance without any sacrifice
in productivity.
It adds to the programmer work load. It's more code you have to
write.
No, once written, smart pointer types can be used just like
any other, no extra work at all. One may have to choose which
type to use and there is always the risk of getting it wrong.
And you don't see a contradition in those two sentences? In my
work, most pointers are for navigation, and the navigational
possibilities are full of cycles. Using smart pointers
systematically would involve a great deal of extra analysis.
(Of course, in this context, there is no problem with regards to
when to delete the objects, and the garbage collection is mainly
a safety net, to allow trapping the use of a dangling pointer,
and not really necessary for reasons of memory management.)
There are other contexts where boost::shared_ptr (or my
pre-boost shared pointers) do work well, but again, I have to
think about them---I've identified the fact that the objects
don't need deterministic disposal (otherwise, I can't use
boost::shared_ptr), but I still have to consider possible
cycles, etc. It's not overwhelming, but it is a little bit of
extra work.
But the same could happen with a mix of GC and user managed
objects.
You can always neglect to correctly terminate the life of an
object. I've never found it to be a frequent problem,
however---less frequent than correctly handling some other major
events in the object lifetime. And boost::shared_ptr doesn't
really help, since you're likely to still have a pointer to the
object.
A more frequent problem is dangling pointers: the object's
lifetime has ended, but you've neglected to inform an interested
party. Garbage collection makes it easy to check for this,
whenever you use the pointer. (You can also make it work with a
combination of shared_ptr and weak_ptr, but it requires more
effort.)
As I said before, it's not GC I object to, it's mixing GC and
"conventional" memory management.
You don't mix them. All memory management is by garbage
collection.
I'd also object the mixing raw pointers with smart pointers
for dynamic objects.
In which case, you'll never use smart pointers, because there
just aren't enough different types of them to handle all of the
cases. (Unless you create a smart pointer which really does
nothing, for navigational purposes.)
I tried that, and gave up with it. It resulted in too many
memory leaks. In my applications, most pointers are used for
navigation, not for ownership. And raw pointers work perfectly
well for navigation.
Ah, well that's where our domains differ. Most of the places where I
would have used pointers are in containers, manipulating DOM trees or
for passing objects between threads.
I don't know what a DOM tree is
The Document Object Model. I do a lot of work with XML and
XHTML documents!
Oops. I've actually used it, both in Java and in C++. I just
didn't recognize the name right off.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34