> : In other words, the standard should define what is meant by
"unreferenced"
> : storage, but the implementation can use whatever technique (easy
> : or difficult) is necessary to achieve the desired result.
>
> I'm not sure it is possible at all in a programming language that
> allows pointer mathematics. For example;
>  Foo* f = new Foo[4];
>  f += 2;
> Is f[0] dereferenced? What about f[3]? And, what if the equation
> is more complex, and the value of f depends on if statements and
> while loops. I wouldn't be surprised if this problem is mappable
> to the halting problem.

(I assume by 'dereferenced' you mean 'no longer referenced'.)

Pointer arithmetic is only one problem.  What about disguising pointers as
integers?

Bjarne Stroustrup's GC 'proposal' (scare quotes because it's pretty vague)
would expect programs that do weird things with pointers _and_ rely on GC
to have implementation-defined behaviour, i.e. it would be up to the
implementation what guarantees it made about when an object might be
collected in these sorts of cases.  That's fair enough for programs that do
silly things like casting pointers to ints, but pointer arithmetic for
arrays is pretty common (though already broken in C++ thanks to implicit
derived-to-base conversions), and as you point out, is probably intractable
as far as GC is concerned.  So that seems to make GC pretty much
implementation defined, which is exactly what the current WP allows for
anyway, although implicitly.

While I see the need for GC, can we make it part of the standard in any
useful way?  Or even a future revision?

Roly Perera
----
Interactive Computers Ltd
3 Cumberland Road
Acton
London  W3 6EX
Phone: +44 (956) 414 395
Phax:  +44 (181) 932 2490
Email: rolyp@private.nethead.co.uk
----
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:

>More complicated problems involve things like memcpy'ing a pointer into
>a char array, at an address that is not correctly aligned for a pointer.
>Or encrypting or compressing a memcpy'ed pointer.  Or storing the
>pointer in a different process, perhaps on a different machine.  Or on
>disk.  All of these things are currently legal in C++, and cannot be
>correctly handled by garbage collection.  I presume that what Andy
>Koenig meant by making garbage collection a legal option was to formally
>make this sort of behavior undefined.

I agree that such behavior should be undefined. However, if that were
the case, I would like the standard to specify something like the
following:

   void gc_freeze(void *);
   void gc_unfreeze(void *);

This would allow the programmer to manually put a memory block out of
reach of the garbage collector. Whole blocks would be frozen and
unfrozen this way, even if the pointer pointed to the middle of the
block. The behavior is undefined if the pointers don't point into
heap-allocated storage. The functions would be defined as no-ops for
implementations that do not support GC or if GC were turned off.

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I entirely sympathise with the need for GC.  There are application
architectures that make heavy use of dynamic allocation and that (more to
the point) maintain references of indefinite extent (i.e. there's no
_obvious_ - read 'determinable without reference counting' - point at which
it's OK to delete an object).  For such apps GC makes sense, whether it's
built into the language, supplied by a library, or implemented by the
programmer.

However...

> Note that a definition of "unreferenced" memory would be needed
> for merely _allowing_ implementations to do garbage collection; above
> I'm talking about the what would be needed for the more ambitious
> step of _requiring_ implementations to do garbage collection.
>
> (This discussion is mostly hypothetical.  I agree with the view stated
> by James Kanze and others that it is too late at this stage for the
> coming C++ standard to require implementations to do garbage collection.)

...we can't require implementations to _do_ garbage collection - we can
only require them to be _able_ to do it.  This could of course be what you
meant :-)

Roly Perera
----
Interactive Computers Ltd
3 Cumberland Road
Acton
London  W3 6EX
Phone: +44 (956) 414 395
Phax:  +44 (181) 932 2490
Email: rolyp@private.nethead.co.uk
----
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <4t70vo$dq@mulga.cs.mu.OZ.AU>, fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
|>
|> I believe Stroustrup's proposal includes a definition of reachability
|> that counts interior pointers (pointers to fields of a struct or to
|> elements of an array).  So it would allow the common things like pointer
|> arithmetic for arrays; only programs that do "wierd" things such as
|> casting pointers to integers would depend on implementation-defined
|> behaviour.

They are already depending on implementation specific behavior since
casting an integer to a pointer will not necessarily get you a valid
pointer on a machine that has pointers longer than integers or tagged
pointers.  If such code won't work with GC, well, too bad for that code.
You don't expect code to be portable that assigns an int to a short, later
back to an int, and then expects the original value back.

I had to port some C code like that once (casting ints to pointers and back)
to such a machine (longer pointers than ints) and it was a real mess.  The
weird part was it was supposed to be "highly portable" code for a GC!
--

- Bill Seurer     ID Tools and Compiler Development      IBM Rochester, MN
  Business: BillSeurer@vnet.ibm.com               Home: BillSeurer@aol.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

phalpern@truffle.ma.ultranet.com (Pablo Halpern) writes:

>I agree that such behavior should be undefined. However, if that were
>the case, I would like the standard to specify something like the
>following:
>
>   void gc_freeze(void *);
>   void gc_unfreeze(void *);
>
>This would allow the programmer to manually put a memory block out of
>reach of the garbage collector.

Fortunately it's very easy for a user to implement these functions
without any support from the garbage collector.  Just keep the frozen
pointers in some sort of collection data type (such as an STL set).
That will ensure that they're referenced.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Roly Perera" <rolyp@private.nethead.co.uk> writes:

>Pointer arithmetic is only one problem.  What about disguising pointers as
>integers?
>
>Bjarne Stroustrup's GC 'proposal' (scare quotes because it's pretty vague)
>would expect programs that do weird things with pointers _and_ rely on GC
>to have implementation-defined behaviour, i.e. it would be up to the
>implementation what guarantees it made about when an object might be
>collected in these sorts of cases.  That's fair enough for programs that do
>silly things like casting pointers to ints, but pointer arithmetic for
>arrays is pretty common

I believe Stroustrup's proposal includes a definition of reachability
that counts interior pointers (pointers to fields of a struct or to
elements of an array).  So it would allow the common things like pointer
arithmetic for arrays; only programs that do "wierd" things such as
casting pointers to integers would depend on implementation-defined
behaviour.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Roly Perera" <rolyp@private.nethead.co.uk> writes:

>...we can't require implementations to _do_ garbage collection - we can
>only require them to be _able_ to do it.  This could of course be what you
>meant :-)

No, that wasn't what I meant.

I think we certainly _could_ require implementations to do garbage collection.
For example, we could simply include a statement in the standard exactly
to that effect: "implementations are required to perform garbage collection".

(Whether or not we _should_ do so is another question.)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze US/ESC 60/3/141 #40763 (kanze@lts.sel.alcatel.de) wrote:

: |> It must not interract with the operating
: |> system beyond using native new/delete and malloc/free.

: Why do you make this restriction on GC, and not on malloc/free
: themselves?  Why should GC be required to be implemented over
: malloc/free, and not vice versa.

I do not place this restriction on malloc/free because they already have
standardized behavior.

I didn't say GC had to use malloc/free.  I implied it -could- use malloc
and free.  However, my intention was to restrict aspects of GC behavior to
being defined in terms of existing, well-understood and portable language
features.

: |> It may require
: |> special compiler support (preferably not) but must not require special
: |> hardware support.

: This would seem to be the implementor's problem, not yours.  It is, in
: fact, not relevant to any standardization effort; after all, the C/C++
: allow special hardware support for floating point arithmetic, but don't
: require it.

That's precisely my point.  My intent is to require a GC that will work
properly on many diverse platforms, not just Unix systems.

: |> It must not cost me anything if I don't want to use it.

: Agreed.

: |> It must allow me to explicitly delete memory.

: All of the proposals I've seen allow this.

: |> It must work properly even
: |> if I never delete memory.

: Agreed.  If not, what's the point.

: |> It must finalize objects in memory it collects.

: I believe the Boehm collector does this.  I know that some others do.
: IMHO, though, this shouldn't be necessary.  Garbage collection is for
: managing memory, not other things.  If an object needs finalization for
: some other reasons (and many do), then I don't see why it should be the
: responsibility of garbage collection to take care of it.

Because finalization and release are inextricably linked in C++.  GC must
do this because, quite simple, it goes with the territory.  I believe
"Garbage" isn't really just a memory issue.  I believe it is a general
resource issue.  It is hard to manage resource release in OO applications
for the same reasons and in the same way it is for memory.

: |> It must collect memory soon after it is no longer in use (since object
: |> finalization often releases resources other than memory).
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <01bb79be$d2d14da0$0b8549c2@my-computer> "Roly Perera"
<rolyp@private.nethead.co.uk> writes:

|> Bjarne Stroustrup's GC 'proposal' (scare quotes because it's pretty vague)
|> would expect programs that do weird things with pointers _and_ rely on GC
|> to have implementation-defined behaviour, i.e. it would be up to the
|> implementation what guarantees it made about when an object might be
|> collected in these sorts of cases.  That's fair enough for programs that do
|> silly things like casting pointers to ints, but pointer arithmetic for
|> arrays is pretty common (though already broken in C++ thanks to implicit
|> derived-to-base conversions), and as you point out, is probably intractable
|> as far as GC is concerned.  So that seems to make GC pretty much
|> implementation defined, which is exactly what the current WP allows for
|> anyway, although implicitly.

If the problem is so intractable, how is it that the currently available
garbage collectors (like the Boehm collector) have no problems with it?
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <4t6ldq$37h@news2.delphi.com> jodle@bix.com (jodle) writes:

|> James Kanze US/ESC 60/3/141 #40763 (kanze@lts.sel.alcatel.de) wrote:

|> : |> It must not interract with the operating
|> : |> system beyond using native new/delete and malloc/free.

|> : Why do you make this restriction on GC, and not on malloc/free
|> : themselves?  Why should GC be required to be implemented over
|> : malloc/free, and not vice versa.

|> I do not place this restriction on malloc/free because they already have
|> standardized behavior.

What we are proposing is that garbage collection also have a
standardized behavior.

|> I didn't say GC had to use malloc/free.  I implied it -could- use malloc
|> and free.  However, my intention was to restrict aspects of GC behavior to
|> being defined in terms of existing, well-understood and portable language
|> features.

|> : |> It may require
|> : |> special compiler support (preferably not) but must not require special
|> : |> hardware support.

|> : This would seem to be the implementor's problem, not yours.  It is, in
|> : fact, not relevant to any standardization effort; after all, the C/C++
|> : allow special hardware support for floating point arithmetic, but don't
|> : require it.

|> That's precisely my point.  My intent is to require a GC that will work
|> properly on many diverse platforms, not just Unix systems.

I don't understand your point.  The interface (what the user sees) to
garbage collection is defined.  What the implementor does behind my back
is none of my business.  IMHO, an implementation of garbage collection
that didn't use special hardware when it was available is only
acceptable in the present situation, where you have to accept what you
can get.

I see the problem as exactly the same as floating point.  If there is
hardware support for floating point, it would be a mighty poor
implementation that didn't use it (at least optionally).  If there is no
hardware support, it is up to the implementation to do something else.
As a user, all that counts is the interface level.  (Adding two floating
point numbers had better work.)

|> : |> It must not cost me anything if I don't want to use it.

|> : Agreed.

|> : |> It must allow me to explicitly delete memory.

|> : All of the proposals I've seen allow this.

|> : |> It must work properly even
|> : |> if I never delete memory.

|> : Agreed.  If not, what's the point.

|> : |> It must finalize objects in memory it collects.

|> : I believe the Boehm collector does this.  I know that some others do.
|> : IMHO, though, this shouldn't be necessary.  Garbage collection is for
|> : managing memory, not other things.  If an object needs finalization for
|> : some other reasons (and many do), then I don't see why it should be the
|> : responsibility of garbage collection to take care of it.

|> Because finalization and release are inextricably linked in C++.  GC must
|> do this because, quite simple, it goes with the territory.  I believe
|> "Garbage" isn't really just a memory issue.  I believe it is a general
|> resource issue.  It is hard to manage resource release in OO applications
|> for the same reasons and in the same way it is for memory.

Here I disagree.  "Garbage collection" is not a silver bullet, that must
solve all resource management problems.  It simplifies the
implementation of one particular problem.  Only.  Garbage collection
will not free you of the responsibility of defining relationships within
your application.  It will not handle resources other than memory.
IMHO, it should not even handle problems of ensuring finalization,
although at least one collector (Boehm's) does call destructors when it
reclaims memory.

If you do the design right, it is not that hard to manage resources in
OO applications.  At any rate, managing resources *IS* part of the
design (IMHO).  In this regard, however, I don't normally consider
memory per se as a resource.  (The design does address issues of object
lifetime, and who is responsible for triggering finalization.)

What garbage collection does do is simplify the implementation.  IMHO,
if your design is not complete enough to be able to implement the
application without garbage collection, then it will probably not work
correctly with garbage collection either (although the problems may not
be as apparent, nor as serious).  However, given a complete design,
garbage collection will generally simplify the implementation
significantly.  Thus, for example, in my applications, there are a
significant number of classes which *MUST* derive from RefCntObj, and
functions which take or return RefCntPtr's.  This involves extra code,
extra run-time and introduces some arbitrary constraints; garbage
collection would simplify this part of the implementation.  (In
applications with cycles of pointers, the simplification could be very
significant.  It is very hard to get the implementation correct when the
simple solutions like reference counting don't work.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

seurer@rchland.ibm.com (Bill Seurer) writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>|>
>|> ... only programs that do "wierd" things such as
>|> casting pointers to integers would depend on implementation-defined
>|> behaviour.
>
>They are already depending on implementation specific behavior  [...]

You're right, casting pointers to integers and back does have
implementation-defined behaviour.  But there are similar things --
such as memcpy()ing pointers into arrays of unsigned char,
shuffling the unsigned chars, unshuffling them, and then copying them
back and finally dereferencing the pointer -- that according to the
current C standard do not depend on any implementation-defined,
unspecified, or undefined behaviour.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4sm6nf$8ja@news2.ios.com> aishdas@haven.ios.com (Micha
Berger) writes:

|> Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote:
|> : In other words, the standard should define what is meant by "unreferenced"

|> : storage, but the implementation can use whatever technique (easy
|> : or difficult) is necessary to achieve the desired result.

|> I'm not sure it is possible at all in a programming language that
|> allows pointer mathematics. For example;
|>  Foo* f = new Foo[4];
|>  f += 2;
|> Is f[0] dereferenced? What about f[3]? And, what if the equation
|> is more complex, and the value of f depends on if statements and
|> while loops. I wouldn't be surprised if this problem is mappable
|> to the halting problem.

The garbage collection does not know about f[0], or f[3].  All it is
concerned with is the block allocated by new.

In practice, of course, you don't even need pointer arithmetic to have
this problem.  It is present in any language with multiple inheritance.

And of course, any garbage collection implementation for C or C++ will
have to deal with it.  The Boehm collector handles it, for example.

More complicated problems involve things like memcpy'ing a pointer into
a char array, at an address that is not correctly aligned for a pointer.
Or encrypting or compressing a memcpy'ed pointer.  Or storing the
pointer in a different process, perhaps on a different machine.  Or on
disk.  All of these things are currently legal in C++, and cannot be
correctly handled by garbage collection.  I presume that what Andy
Koenig meant by making garbage collection a legal option was to formally
make this sort of behavior undefined.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4sic7t$9vu@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
>
> >how do you rigorously specify what is meant by garbage collection
> >without describing the implementation?  An easy solution here is not to
> >specify it, perhaps hinting at the intent.
>
> I would suggest specifying it, albeit in a perhaps non-rigorous manner.

Garbage collection can and has been described in at least semi-formal
manners. Most of these descriptions rely of type safety, and so are
unsuitable for languages which allow arbitrary type casts (my knowledge
of standard c++ is insufficient to say whether c++ falls into this
category).

stuart
--
--
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <KANZE.96Jul19120015@slsvgqt.lts.sel.alcatel.de> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

> More complicated problems involve things like memcpy'ing a pointer into
> a char array, at an address that is not correctly aligned for a pointer.
> Or encrypting or compressing a memcpy'ed pointer.  Or storing the
> pointer in a different process, perhaps on a different machine.  Or on
> disk.  All of these things are currently legal in C++, and cannot be
> correctly handled by garbage collection.  I presume that what Andy
> Koenig meant by making garbage collection a legal option was to formally
> make this sort of behavior undefined.

Some forms of garbage collection can handle at least some of the
above mentioned cases. Reference counting handles pointers saved
to disk or stored in another address space. This is why some
distributed OSs use a variation on reference counting to perform
garbage collection.

OTOH, reference counting has quite different efficiency
characteristics to marking or copying garbage collection
techniques.

Conservative collectors can be configured to handle mis-aligned
pointers etc, at the cost of retaining extra non-live objects.

stuart
--
--


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

J. Kanze (kanze@gabi-soft.fr) wrote:

: In article <4rjl3c$iot@news.BelWue.DE> fjh@mundook.cs.mu.OZ.AU (Fergus
: Henderson) writes:

: |> Fortunately this problem has already been solved.
: |> See, for example, the Ada 83 standard.

: C++ and Ada are two distinctly different languages, with different
: definitions concerning object lifetime, referencing, etc.  As far as I
: know (but I could be wrong), Ada has no concept of finalization
: (destructors, in C++), for example.

Amen.  Also, all actual types in Ada83 have procedural scope (directly or
because they belong to packages which are instantiated with procedural
scope).  Ada also did not have any form of polymorphism.  This provides a
natural opportunity to garbage collect; when a type goes away, all the
memory allocated for it goes away.  If the programmer is any good at all,
types will be defined with a narrow scope; no more widely defined than is
necessary.

This scheme would be virtually useless in C++ since procedure-scope types
are the exception instead of the only game in town.  In fact,
function-scope classes serve best as an indicator that the programmer is
still lost in the void between procedural and object-oriented programming.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

J. Kanze (kanze@gabi-soft.fr) wrote:

: IMHO: if C++ accepts garbage collection, it should be based on a working
: implementation, so that we know what we are getting ourselves into.  I

Agreed.

: think that the Boehm implementation would be a good place to start.  I
: can imagine that if it had been available in 1991, say, and proposed,

I think the Boehm implementation is a good strawman, nothing more.  Having
looked at the source extensively and used it a bit, I now know what I want
from a Garbage Collector.  It must not be fooled by false pointers.  The
dynamics of using it must be competative with explicit management, even in
small, saturated address spaces.  It must not interract with the operating
system beyond using native new/delete and malloc/free.  It may require
special compiler support (preferably not) but must not require special
hardware support.  It must not cost me anything if I don't want to use it.
It must allow me to explicitly delete memory.  It must work properly even
if I never delete memory.  It must finalize objects in memory it collects.
It must collect memory soon after it is no longer in use (since object
finalization often releases resources other than memory).

I solemnly vow to never use a collector that doesn't meet these (and
possibly other) requirements. In general, it seems to me that GC is
similar to serialization services in many regards.  I think it is fair to
impose similar requirements.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4stndd$36e@news2.delphi.com> jodle@bix.com (jodle) writes:

|> J. Kanze (kanze@gabi-soft.fr) wrote:

|> : IMHO: if C++ accepts garbage collection, it should be based on a working
|> : implementation, so that we know what we are getting ourselves into.  I

|> Agreed.

|> : think that the Boehm implementation would be a good place to start.  I
|> : can imagine that if it had been available in 1991, say, and proposed,

|> I think the Boehm implementation is a good strawman, nothing more.  Having
|> looked at the source extensively and used it a bit, I now know what I want
|> from a Garbage Collector.  It must not be fooled by false pointers.

This requires language support, so that the garbage collector can obtain
the information as to what is and what isn't a pointer.

|> The
|> dynamics of using it must be competative with explicit management, even in
|> small, saturated address spaces.

This is an implementation issue.  I would suppose that implementations
with small, saturated address spaces would use a garbage collector
adapted to their needs.  On most Unix systems, the algorithms used in
malloc and free are not at all adapted to small saturated address
spaces.

|> It must not interract with the operating
|> system beyond using native new/delete and malloc/free.

Why do you make this restriction on GC, and not on malloc/free
themselves?  Why should GC be required to be implemented over
malloc/free, and not vice versa.

|> It may require
|> special compiler support (preferably not) but must not require special
|> hardware support.

This would seem to be the implementor's problem, not yours.  It is, in
fact, not relevant to any standardization effort; after all, the C/C++
allow special hardware support for floating point arithmetic, but don't
require it.

|> It must not cost me anything if I don't want to use it.

Agreed.

|> It must allow me to explicitly delete memory.

All of the proposals I've seen allow this.

|> It must work properly even
|> if I never delete memory.

Agreed.  If not, what's the point.

|> It must finalize objects in memory it collects.

I believe the Boehm collector does this.  I know that some others do.
IMHO, though, this shouldn't be necessary.  Garbage collection is for
managing memory, not other things.  If an object needs finalization for
some other reasons (and many do), then I don't see why it should be the
responsibility of garbage collection to take care of it.

|> It must collect memory soon after it is no longer in use (since object
|> finalization often releases resources other than memory).

If you need explicit finalization, you need explicit finalization.
Garbage collection is designed to solve one implementation level
problem.  It doesn't (and shouldn't) attempt to solve other problems
(managing locks, etc.).  And it doesn't free you of your design
responsibilities.  (If your object is a window, for example, you
shouldn't expect garbage collection to somehow know exactly when it
should be deleted from the screen.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4stndd$36e@news2.delphi.com> jodle@bix.com (jodle) writes:

> I think the Boehm implementation is a good strawman, nothing more.  Having
> looked at the source extensively and used it a bit, I now know what I want
> from a Garbage Collector.

I think it's important to bear in mind the design motivations
behind the Boehm implementation. These were mainly (a) portability
from compiler to compiler (b) portability from architecture to
architecture (c) portability from OS to OS (with the exception
of dynamically linked libraries) (d) incrementality.

As a proof that GC could be done, these were very important,
since they meant that people could d/l and run the collector
themselves. In an industrial strength implementation, other
factors could be more important.

For those unfamiliar with the Boehm collector, the following
paper is recommended:

Hans-Juergen Boehm. Garbage collection in an uncooperative environ-
ment. Software - Practice and Experience, 18(9):807-820, Sept 1988.

> It must not be fooled by false pointers.

I'm not sure what you mean by "false pointers", but I'll assume
that you mean bit patterns which could be pointers into the stack
but aren't because they're actually integers (or reals or ...).

This property, called Conservatism in the literature, is the
only (known) way of overcoming a lack of type knowledge about
objects. If the collector has complete type knowledge, which
includes all objects on the stack, in the globals and on the
stack, it can avoid being fooled. Complete type knowledge
generally requires compiler support, since the compiler
controls the layout of globals and stack frames.

Bear in mind that complete type knowledge may pose difficulties
linking garbage collectors with other languages.

> It must allow me to explicitly delete memory.

Indeed. There are a very interesting class of (compile-time)
optimisations which explicit freeing of memory allows. Be
aware, however, that explicitly freeing an object does not
necessarily lead to the explicit freeing of all referenced
objects, even if these other objects have no other references
to them.

> It must collect memory soon after it is no longer in use
> (since object finalization often releases resources other
> than memory).

This is a hard one. Generally, in a non-threaded environment,
the GCer only gets control when you (a) allocate memory (b)
when you force it do a garbage collection. In a threaded
environment, the GCer is often a separate thread. Generally
the collection speed of these algorithms is guaranteed to
ensure completion of a collection before memory is
exhausted, rather than freeing of unreferenced objects within
a certain time period.

For those unfamiliar finalisation, the following paper is
recommended:

Martin C. Atkins and Lee R. Nackman. The active deallocation of ob-
jects in object-oriented systems.  Software- Practice and Experience,
18(11):1073-1089, November 1988.


Personally, I think that if GC is to be used, sufficient room
must be left for researchers to develop new methods,
implementors to find new ways of implementing them and for
users to select a GCer that suits their needs. For those
unfamiliar with the wide range of possible garbage collector
implementations, the following paper is recommended:

H. Corporaal and T. Veldman. The design space of garbage collection. In
Proceedings, Advanced Computer Technology, Reliable Systems and Appli-
cations, 5th Annual European Computer Conference., pages 423-428, 1991.


stuart


--
--


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

kanze@gabi-soft.fr (J. Kanze) writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>|> ark@research.att.com (Andrew Koenig) writes:
>|> >There is another problem, which I think would have been serious if
>|> >the committee had officially debated garbage collection: How does
>|> >one specify it as part of a standard?
>
>|> Fortunately this problem has already been solved.
>|> See, for example, the Ada 83 standard.
>
>This is pleasant information.  Does it also mean that the large amount
>of time and work that the standardization committee did on templates was
>wasted, because Ada 83 had them (under the name of generic modules) too?

No.  For one thing, Ada generic modules are very different from C++
templates.  But the fact that other programming language standards
committees have found reasonable solutions to the same problem means
that fears that the problem is insurmountable are misplaced.  The C++
committee might not be able to lift the wording from the Ada standard
unchanged, but unless there is some particular reason why the concepts
used in the Ada standard couldn't be applied for C++, it surely can't
be such a serious problem.

>C++ and Ada are two distinctly different languages, with different
>definitions concerning object lifetime, referencing, etc.

While the wording is different, and many of the details differ,
the underlying concepts are really not that different, are they?

>As far as I know (but I could be wrong), Ada has no concept of finalization
>(destructors, in C++), for example.

Ada 95 does, although Ada 83 didn't.

>Also, if I understand correctly, garbage collection is only permitted in
>Ada, not required.

That's correct.

Oh, I'm sorry.  I see now that Andrew Koenig was talking about requiring
garbage collection.   My example of the Ada standard only showed a standard
that permitted garbage collection.  As such, it's really not relevant to
Andrew's point.  My apologies for that mistake!

I see now from re-reading his original post that I have quoted him
out-of-context in a way that could have mislead; I must again apologize.


There may perhaps be some other standard(s) that do mandate garbage
collection, but I don't know of them off-hand.

>And garbage collected Ada implementations are rare.
>Maybe there was something in the Ada standard for garbage collection
>which made it unpleasantly difficult.

There was -- two things, actually.

One was tasking; obviously garbage collection is going to be much more
difficult if you have to worry about other tasks potentially modifying
data while the garbage collector is trying to collect it.

The other thing was simply all those other features -- type checking,
packages, generics, exceptions, etc.  At the time (1983), many of these
features were not well understood, and so the overall degree of
implementation difficulty was very high; by the time they'd done
everything else, Ada implementors didn't have much
energy/time/capital/whatever left over to implement garbage
collection.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

[Moderator's note: this article is crossposted to comp.std.c++ and to
comp.lang.c++.moderated.  Followups are directed by default to
comp.std.c++ only.  mha]

In article <4rjl3c$iot@news.BelWue.DE> fjh@mundook.cs.mu.OZ.AU (Fergus
Henderson) writes:

|> In comp.lang.c++.moderated,
|> ark@research.att.com (Andrew Koenig) writes:

|> >There is another problem, which I think would have been serious if
|> >the committee had officially debated garbage collection: How does
|> >one specify it as part of a standard?

|> Fortunately this problem has already been solved.
|> See, for example, the Ada 83 standard.

This is pleasant information.  Does it also mean that the large amount
of time and work that the standardization committee did on templates was
wasted, because Ada 83 had them (under the name of generic modules) too?

C++ and Ada are two distinctly different languages, with different
definitions concerning object lifetime, referencing, etc.  As far as I
know (but I could be wrong), Ada has no concept of finalization
(destructors, in C++), for example.

Also, if I understand correctly, garbage collection is only permitted in
Ada, not required.  And garbage collected Ada implementations are rare.
Maybe there was something in the Ada standard for garbage collection
which made it unpleasantly difficult.

IMHO: if C++ accepts garbage collection, it should be based on a working
implementation, so that we know what we are getting ourselves into.  I
think that the Boehm implementation would be a good place to start.  I
can imagine that if it had been available in 1991, say, and proposed,
that we would have garbage collection in this round of standardization.
It wasn't, and we don't.  I have great hopes for the next round,
however.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4sdr2q$n07@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU
(Fergus Henderson) writes:

|> kanze@gabi-soft.fr (J. Kanze) writes:

|> >fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
|> >|> ark@research.att.com (Andrew Koenig) writes:
|> >|> >There is another problem, which I think would have been serious if
|> >|> >the committee had officially debated garbage collection: How does
|> >|> >one specify it as part of a standard?
|> >
|> >|> Fortunately this problem has already been solved.
|> >|> See, for example, the Ada 83 standard.
|> >
|> >This is pleasant information.  Does it also mean that the large amount
|> >of time and work that the standardization committee did on templates was
|> >wasted, because Ada 83 had them (under the name of generic modules) too?

|> No.  For one thing, Ada generic modules are very different from C++
|> templates.  But the fact that other programming language standards
|> committees have found reasonable solutions to the same problem means
|> that fears that the problem is insurmountable are misplaced.  The C++
|> committee might not be able to lift the wording from the Ada standard
|> unchanged, but unless there is some particular reason why the concepts
|> used in the Ada standard couldn't be applied for C++, it surely can't
|> be such a serious problem.

Agreed.  I was, in my somewhat cynical fashion, not trying to say that
the problem was unsolvable, but that it was not yet solved.  I am sure
that it can be solved.  Given the current schedule, however, I doubt
that it could be solved "on time".

|> >C++ and Ada are two distinctly different languages, with different
|> >definitions concerning object lifetime, referencing, etc.

|> While the wording is different, and many of the details differ,
|> the underlying concepts are really not that different, are they?

With regards to GC, there are significant differences.  In Ada, you
either have a pointer to an object, or you don't.  In C++, suppose you
cast the pointer to a char*, then add 5 to it.  Do you still have a
pointer to the original object?  (IMHO, no.)  Can you garbage collect
the original object?  (I would prefer not, although since I don't do
that sort of thing, it is not an important point with me.)

|> >As far as I know (but I could be wrong), Ada has no concept of finalization
|> >(destructors, in C++), for example.

|> Ada 95 does, although Ada 83 didn't.

|> >Also, if I understand correctly, garbage collection is only permitted in
|> >Ada, not required.

|> That's correct.

    [...]
|> There may perhaps be some other standard(s) that do mandate garbage
|> collection, but I don't know of them off-hand.

There are language definitions which mandate garbage collection
(Modula-3, Eiffel).  The ones I'm familiar with are not ISO standards; I
cannot say whether their definitions would be adequate for an ISO
standard.

With regards to the standardization of garbage collection, I can see two
immediate difficulties.  The first must be solved: when can a system
collect an object?  This problem must be solved even to make garbage
collection a legal implementation option.  The second is more difficult:
how do you rigorously specify what is meant by garbage collection
without describing the implementation?  An easy solution here is not to
specify it, perhaps hinting at the intent.  After all, while it is
obviously the intent, I do not believe that the C standard guarantees
that memory released by free will ever be reused.

|> >And garbage collected Ada implementations are rare.
|> >Maybe there was something in the Ada standard for garbage collection
|> >which made it unpleasantly difficult.

|> There was -- two things, actually.

|> One was tasking; obviously garbage collection is going to be much more
|> difficult if you have to worry about other tasks potentially modifying
|> data while the garbage collector is trying to collect it.

Regardless of what the standard says, any implementor today will also
have to deal with a threaded environment in C++.

|> The other thing was simply all those other features -- type checking,
|> packages, generics, exceptions, etc.  At the time (1983), many of these
|> features were not well understood, and so the overall degree of
|> implementation difficulty was very high; by the time they'd done
|> everything else, Ada implementors didn't have much
|> energy/time/capital/whatever left over to implement garbage
|> collection.

That scenario reminds me of the situation with another language I
know:-).
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote:

> There may perhaps be some other standard(s) that do mandate garbage
> collection, but I don't know of them off-hand.

Common Lisp?


--
Lars Farm, lars.farm@nts.mh.se
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

>how do you rigorously specify what is meant by garbage collection
>without describing the implementation?  An easy solution here is not to
>specify it, perhaps hinting at the intent.

I would suggest specifying it, albeit in a perhaps non-rigorous manner.

>After all, while it is
>obviously the intent, I do not believe that the C standard guarantees
>that memory released by free will ever be reused.

Yes, that's a very good point.  The C++ committee's draft working paper
says of operator delete that it "reclaims" the memory, without defining
what is meant by this.  It also adds the following note:

|   Note:
|     It is  unspecified  under  what  conditions  part  or  all  of  such
|     reclaimed  storage is allocated by a subsequent call to operator new
|     or any of calloc, malloc, or realloc, declared in <cstdlib>.

If this is sufficient for `operator delete' (and it is),
then if we were to require implementations to support garbage
collection I think it would be equally sufficient to say that an
implementation must "reclaim" unreferenced storage, adding a similar
caveat about it being unspecified under what conditions such storage
was reused.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>>>>> "Fergus" == Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> writes:

    Fergus> If this is sufficient for `operator delete' (and it is),
    Fergus> then if we were to require implementations to support
    Fergus> garbage collection I think it would be equally sufficient
    Fergus> to say that an implementation must "reclaim" unreferenced
    Fergus> storage, adding a similar caveat about it being
    Fergus> unspecified under what conditions such storage was reused.

Would an implementation that "reclaimed" the memory upon termination
of the program be conformant?  And I still cannot see how the GC can
easily determine "unreferenced" storage in the general case.  Would it
make sense to have collectable and uncollectable objects then?  If so,
how to avoid the programmer problems that GC was supposed to solve in
the first place?

--
Achim Gratz.

--+<[ It's the small pleasures that make life so miserable. ]>+--
WWW:    http://www.inf.tu-dresden.de/~ag7/{english/}
E-Mail: gratz@ite.inf.tu-dresden.de
Phone:  +49 351 4575 - 325
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

gratz@ite.inf.tu-dresden.de (Achim Gratz) writes:

>>>>>> "Fergus" == Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> writes:
>
>    Fergus> If this is sufficient for `operator delete' (and it is),
>    Fergus> then if we were to require implementations to support
>    Fergus> garbage collection I think it would be equally sufficient
>    Fergus> to say that an implementation must "reclaim" unreferenced
>    Fergus> storage, adding a similar caveat about it being
>    Fergus> unspecified under what conditions such storage was reused.
>
>Would an implementation that "reclaimed" the memory upon termination
>of the program be conformant?

Would an implementation of free() that "reclaimed" the memory on
termination of the program be conformant?

>And I still cannot see how the GC can
>easily determine "unreferenced" storage in the general case.

The standard should dictate what, but not how -- the implementation
details should be, well, up to the implementation!

In other words, the standard should define what is meant by "unreferenced"
storage, but the implementation can use whatever technique (easy
or difficult) is necessary to achieve the desired result.

Note that a definition of "unreferenced" memory would be needed
for merely _allowing_ implementations to do garbage collection; above
I'm talking about the what would be needed for the more ambitious
step of _requiring_ implementations to do garbage collection.

(This discussion is mostly hypothetical.  I agree with the view stated
by James Kanze and others that it is too late at this stage for the
coming C++ standard to require implementations to do garbage collection.)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I see a problem with auto_ptr.   I think auto_ptr's behaviour
would fail in this case:
   //intptr1 will own int(3)
   autoptr<int> intptr1 = new int(3);
   {
      //intptr2 will take ownership from intptr1
      autoptr<int> intptr2=intptr1;
   } //intptr2 falls out of scope
   (*intptr1)++;   //increments a int that is deleted!


Reference counting smart pointers do not have this limitation.
I have written a RC smart pointer that operates similar to Steve's
implementation.   It does not fail in the above situation.  Will a RC
smart (auto) pointer be a part of the new C++ standard?  Or is my
understanding of autoptr flawed?

--
Chris Busch








[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In comp.lang.c++.moderated,
ark@research.att.com (Andrew Koenig) writes:

>There is another problem, which I think would have been serious if
>the committee had officially debated garbage collection: How does
>one specify it as part of a standard?

Fortunately this problem has already been solved.
See, for example, the Ada 83 standard.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
--
<mailto:dietmar.kuehl@uni-konstanz.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]