"Dave Harris" <brangdon@cix.co.uk> wrote in message
news:memo.20020619232845.1523B@brangdon.madasafish.com...
> nagle@animats.com (John Nagle) wrote (abridged):
> >     I'm not necessarily arguing for GC
>
> Me neither. I am scared optional GC will split the C++ community into
> those which use it and those which don't. Will they be able to share code?

If the GC system is designed correctly, of course they can.  Putting
something on the GC heap simply requires some syntax that's different from
putting something on the standard heap (say overload placement new or
require a keyword or derivation in the class declaration).  Yes, there will
be some areas for misuse, but no more so then already exists for dynamically
allocated memory (i.e. you have to insure ownership isn't shared by two
different collection "entities").

Bill Kempf

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

William E. Kempf wrote:

> "Dave Harris" <brangdon@cix.co.uk> wrote in message
> news:memo.20020619232845.1523B@brangdon.madasafish.com...
>
>>nagle@animats.com (John Nagle) wrote (abridged):
>>
>>>    I'm not necessarily arguing for GC
>>>
>>Me neither. I am scared optional GC will split the C++ community into
>>those which use it and those which don't. Will they be able to share code?
>>
>
> If the GC system is designed correctly, of course they can.  Putting
> something on the GC heap simply requires some syntax that's different from
> putting something on the standard heap (say overload placement new or
> require a keyword or derivation in the class declaration).  Yes, there will
> be some areas for misuse, but no more so then already exists for dynamically
> allocated memory (i.e. you have to insure ownership isn't shared by two
> different collection "entities").


   The syntactic difference which you mention is alone enough to divide
the C++ community into the haves and the have-nots regarding GC (or
should I say, the permits versus the prohibits regarding GC).  If a
source-code base is at least tens of thousands of lines, then an
overhaul tweaking only minor syntactic differences throughout can
quickly become overwhelmingly cost-prohibitive as one GC-ifies or
de-GC-ifies the 3rd-party code on which one wishes to depend upon.  (Of
course the mere supposition of such overhaul assumes that the
GC-prohibiting app-domain has the source-code for the GCed dependent
layer at all which one would not have in binary-only distributions.)

   Furthermore if a software design is focusing solely on using GC, then
the deallocation portion of the design is most likely absent or
degenerate.  If the GC-dependent software design is to be used in a
GC-prohibiting app-domain, adding/fortifying such end-of-object-lifetime
design is often nontrivial for classes which have nontrivial dtors (or
nontrivial finalizers).  This is especially true if the use of GC was
motivated by solving the cycle-of-references problem which plagues
reference-counting deallocation techniques. (And I still refuse to use
the term "GC" for reference-counting deallocation-techniques, due to
lack of explicit exploratory "collector").

   Note that the *sharing* of code among source-code bases (i.e.,
higher-layers becoming dependent on some external lower-layer software)
is far different than *collocating* GCed software with GC-unaware
software within the same address-space where neither the GCed &
GC-unaware software depends on the other.

   In an attempt to eliminate the need for such toggle-GC overhauls when
a GC-prohibiting app-domain wishes to use GCed software within the same
address-space, one can imagine duplicate distributions of software: 1)
one with GC turned on for GC-permitting app-domains and 2) one with GC
turned off for GC-prohibiting app-domains.  This has significant cost of
duplication and complicates maintenance.  This dual mode support could
be yet another form of coming pro-GC versus anti-GC split if full-blown
GC (with exploratory "collector" and/or with finalizers) is in C++0x.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nagle@animats.com (John Nagle) wrote (abridged):
>     Objects which throw an exception during construction do
> not get a "reset_object" call.  Thus, "reset_object" is
> guaranteed a fully constructed object.

Presumably reset_object is invoked for fully-constructed sub-objects,
though. Else their resources would never be released.


>     I'm not necessarily arguing for GC

Me neither. I am scared optional GC will split the C++ community into
those which use it and those which don't. Will they be able to share code?


> but adding unsafe GC would be a huge mistake.

Where do we draw the line? If GC'd objects cannot have destructors, then
maybe they shouldn't be allowed in delete expressions, either. Perhaps
pointers to them should be default-initialised to NULL. Perhaps even
pointer arithmetic should be disallowed. In effect, we'd have a Java-like
subset within C++. Do we really want to go this far?

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Dave Harris wrote:

> glancaster@ntlworld.com (Garry Lancaster) wrote (abridged):

>>It doesn't solve the underlying problem of resurrection for
>>the programmer though. It's a bit like "solving" the problem of
>>burglary by legalising it (and expecting anyone at risk to fit
>>iron bars to their windows).


    I previously argued that the way to handle "finalization"
(assuming you want it) is as follows:

    Have the garbage collector
call something named, say, "reset_object" on unreachable
objects.  Objects are guaranteed that "reset_object" will
be called at least once before release.  "reset_object" may be called
more than once.  If an unreachable object makes itself reachable
inside "reset_object" called from the garbage collector,
the collector may not release the object.

    Objects which throw an exception during construction do
not get a "reset_object" call.  Thus, "reset_object" is
guaranteed a fully constructed object.

    GC objects may not have destructors, only "reset_object",
which doesn't come with the "only ever called once"
guarantee of a destructor.  Hence the need for a different
name.

    This is sound.

    I'm not necessarily arguing for GC, but adding
unsafe GC would be a huge mistake.  If it has to go in,
it needs to be done right.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]