> > int *baz = (int *)0 + bar;

>

> This isn't even well formed. You can't add pointers together.

He's not. (int *)0 is a pointer and bar is an integer.



---
[ 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                       ]

> I am myself mainly interested in the latter category. Here C++ needs to
> have some extensions so that the information about global, automatic,
> heap, temporary (in "registers") etc. objects become available, so that
> the GC can trace and only clean up the required stuff in a manner typical
> of that GC.

    If I am iterested in GC at all, I am also interesting in this kind
only...

> If one is using a ref count, the syntax might be
>    ref<T> t = new T(...);
>    ...
> When using a GC, the operator new() also may be attached to the GC. So the
> syntax might (symbolically) be
>   GC gc; // Create a gc object.
>   ...
>   ref<T, gc> t = new(gc) T(...);

    I think this could be effectively managed by library. Frankly, I was
trying something recently and it could be done in less than 500 lines of
code... I has almost same memory penalty as ref-count and is almost as fast
as boehm's GC... but of course, there may be some kind of quirk I do not
know about yet.

> Most likely, if one is using objects that need special semantic actions at
> specific point is time, like a file or window that needs to be closed,
> then one will have to implement special functions to handle that, rather
> than relying on the C++ destructors.

    Consider this:

    struc Foo {
        std::string foo;
    };

    gc_new Foo;

    You are mixing here GC allocated block with variable containing normally
heap allocated data inside it. If GC would not call destructor when
releasing it, this would cause a memory leak.

    So I think that optional (in sense only some of memory is collectable
and rest is managed normally) GC must call destructors (my silly code does
it ;).

Mirek


---
[ 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                       ]

In article <aojn1u$10d7$1@news.vol.cz>, cxl@centrum.cz ("Mirek Fidler") wrote:

>> If one is using a ref count, the syntax might be
>>    ref<T> t = new T(...);
>>    ...
>> When using a GC, the operator new() also may be attached to the GC. So the
>> syntax might (symbolically) be
>>   GC gc; // Create a gc object.
>>   ...
>>   ref<T, gc> t = new(gc) T(...);
>
>    I think this could be effectively managed by library. Frankly, I was
>trying something recently and it could be done in less than 500 lines of
>code... I has almost same memory penalty as ref-count and is almost as fast
>as boehm's GC... but of course, there may be some kind of quirk I do not
>know about yet.

I think of it as C++ extended in just a few ways so that GC's can be
written as libraries. One thing needed is to be able to keep track of the
different objects, global, registers, automatic, heap, etc. -- The GC will
need that in order to determine which objects to cleanup. This is an
information that the C++ compiler writer already must keep track of.

In addition, the GC must know which references to trace if tracing is to
be used.

Then the syntax should be such that is easy to use and fairly transparent.

Also note that a C++ GC might work in ways that standard GC's do not: For
example, if an objects is created as automatic, i.e., put onto the
function parameter stack, and later bound by a GC reference to an external
object which survives the function call expiration, then a GC might works
so that it moves that object to the heap. -- This would be a C++
replacement of alloca(): If an object does not have an extended lifespan,
this GC will be about as fast as alloca(), only causing time expensive
heap allocations when runtime semantics require it.

>> Most likely, if one is using objects that need special semantic actions at
>> specific point is time, like a file or window that needs to be closed,
>> then one will have to implement special functions to handle that, rather
>> than relying on the C++ destructors.
>
>    Consider this:
>
>    struc Foo {
>        std::string foo;
>    };
>
>    gc_new Foo;
>
>    You are mixing here GC allocated block with variable containing normally
>heap allocated data inside it. If GC would not call destructor when
>releasing it, this would cause a memory leak.

The context here was the question whether to use both destructors and
finalizers:

The GC should ensure that each destructor is called only once, and exactly once.

One can construct examples, where this resolving is somewhat tricky, for
example an object a1 that references a2 which references a1 back. For ways
to resolve this is as follows:

When the a1 destructor is initiated, the object a1 should be marked so
that its destructor is not called again. If a2 tries to call the
destructor of a1, one should issue an exception. So the destructor of a2
must have some code checking whether the object a1 is alive.

This method seems to be the best to avoid getting down into the semantic
problems with automated schemes from the C++ language construction level
point of view. Otherwise, an alternative solution might be that the
destructor of a1 is merely ignored, as it destructor has already
initiated.

This could also be a difference between type of GC'c. A single GC might
admit both modes, depending on objects a1 and a2.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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                       ]

> >> Most likely, if one is using objects that need special semantic actions
at
> >> specific point is time, like a file or window that needs to be closed,
> >> then one will have to implement special functions to handle that,
rather
> >> than relying on the C++ destructors.
> >
> >    Consider this:
> >
> >    struc Foo {
> >        std::string foo;
> >    };
> >
> >    gc_new Foo;
> >
> >    You are mixing here GC allocated block with variable containing
normally
> >heap allocated data inside it. If GC would not call destructor when
> >releasing it, this would cause a memory leak.
>
> The context here was the question whether to use both destructors and
> finalizers:
>
> The GC should ensure that each destructor is called only once, and exactly
once.

    I think that the right answer is that destructor is finalizer (in sense
I understand concept of finalizer).

    Manual calling of destructor for gc_newed objects should be in any case
banned. So destructor gets called only once - just before releasing memory
block.

> One can construct examples, where this resolving is somewhat tricky, for
> example an object a1 that references a2 which references a1 back. For ways
> to resolve this is as follows:
>
> When the a1 destructor is initiated, the object a1 should be marked so
> that its destructor is not called again. If a2 tries to call the
> destructor of a1, one should issue an exception. So the destructor of a2
> must have some code checking whether the object a1 is alive.

    Perhaps I am missing here something. How could a2 call destructor of a1
?

Mirek


---
[ 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                       ]

In article <aokhog$1fjd$1@news.vol.cz>, cxl@centrum.cz ("Mirek Fidler") wrote:
>> The GC should ensure that each destructor is called only once, and exactly
>once.
>
>    I think that the right answer is that destructor is finalizer (in sense
>I understand concept of finalizer).

I am not sure what the exact difference is, and it seems unlclear in the
discussions that I have seen. -- Probably, if one gets as far as writing
GC's in the new C++ language extensions, one will see what is required.

>    Manual calling of destructor for gc_newed objects should be in any case
>banned. So destructor gets called only once - just before releasing memory
>block.

One can also admit explicit destructor calls and mark the GC maintained
reference down so that the object is considered dead as soon as the
destructor has started to execute.

>> One can construct examples, where this resolving is somewhat tricky, for
>> example an object a1 that references a2 which references a1 back. For ways
>> to resolve this is as follows:
>>
>> When the a1 destructor is initiated, the object a1 should be marked so
>> that its destructor is not called again. If a2 tries to call the
>> destructor of a1, one should issue an exception. So the destructor of a2
>> must have some code checking whether the object a1 is alive.
>
>    Perhaps I am missing here something. How could a2 call destructor of a1

Just take two objects that reference each other: Then both destructors
should be called by the GC. But one will attempt to initialize additional,
prohibited destructor calls.

So there must be a mechanism in place, preventing that.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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                       ]

Hans Aberg wrote:

> In article <aokhog$1fjd$1@news.vol.cz>, cxl@centrum.cz ("Mirek Fidler") wrote:
>
>>>The GC should ensure that each destructor is called only once, and exactly
>>>
>>once.
>>
>>   I think that the right answer is that destructor is finalizer (in sense
>>I understand concept of finalizer).


    NO.  A destructor is not a finalizer.  Very different semantics.
This was discussed to death weeks ago.  Read the archives.

     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                       ]

ken@DIESPAMDIEcompinnovations.com ("Ken Shaw") wrote in message
news:<ao9fkk$pr4@dispatch.concentric.net>...
> "Wil Evers" <bouncer@dev.null> wrote in message
> news:3da73556$0$67091$e4fe514c@dreader3.news.xs4all.nl...
> > In article <ao74s0$hjv@dispatch.concentric.net>, Ken Shaw wrote:

> > > Please explain what part of the standard this code violates:

> > > int *foo = new int;
> > > int bar = foo - (int *)0;
> > > int *baz = (int *)0 + bar;

> > 5.7.5:
> >   When an expression that has integral type is added to or
> >   subtracted from a pointer, the result has the type of the pointer
> >   operand.
> >   (...)
> >   If both the pointer operand and the result point to elements of
> >   the same array object, or one past the last element of the array
> >   object, the evaluation shall not produce an overflow; otherwise,
> >   the behavior is undefined.

> Undefined maybe but this works on every compiler I have access
> to. Also without fail every compiler I use allows xor of 2 pointers
> and storage of outcome in an int.

Really.  It works on the Sparc compilers I use, but I've known it to
fail with Intel compilers.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

> > Come on. Presumption that pointers are in reality 32 or 64 (or, in
> > the worst case, 36 :) bit
>
> Don't forget 12 and 15 bit. (I've worked in both environments - it
> seems safe to assume that you haven't) More interestingly, I've also
> used platforms where the address size was 20 bits, and the natural
> integer size was 16 bits.

    Sure I worked in such environments. But then, you will have much more
problems than C++ standard conformance and udefined behaviour. Personaly, I
was rather using assembler on platforms with 16 bit pointers and I cannot
imagine that using C++ would be of any benefit on them.

    And, aside from special applications with special requirements, most of
current C++ applications simply would not work on other than 32-64 bit
pointer platforms with virtual memory, whether they are converting pointers
to integers or not.

> > numeric values meaning machine address will work on much more
> > platform/compiler pairs than most of "standard-conformant" template
> > stuff.
>
> If the "standard conformant template stuff" you refer to doesn't
> work, then your compiler isn't standard conformant, is it? So anything
> you say about that compiler is irrelevant in terms of conformance.

    As number of standard conformant compilers is close to zero, we all have
to deal with these kinds of problems..

> > For most applications, such a presumption (that pointer is numeric
> > address) will never cause problems.
>
> That's your opinion, and you're entitled to it. But if you ever start
> writing software thats inteded to stop commercial aircraft from
> falling out of the sky, please do the courtesy of letting me know so I
> can stop travelling by air.

    :) So you consider aircraft with all device drivers of aircraft controls
written using assembler rather than C/C++ (with implementation defined
behaviour) more safe ?

> You'd better ask the people who want to ban bit-manipulations of
> pointers - I'm not one of them, I'm merely pointing out that the
> behaviour is undefined (Naturally, you're welcome to read the standard
> yourself rather than rely on my reading it for you).
>
> >
> > Will C++0x  still be considered to be language suitable for systems
> > programming ?
>
>  Of course, if you'd followed the thread, then you'd know that the
> "banning" of such manipulation is tied up with support for garbage
> collection (read the subject line) - and I don't think I've heard
> anyone advocate the use of GC in systems programming.

    Well, that is why I am asking them :) Sorry that this ended as reply to
you...

Mirek

P.S.: Sorry for being off-topic. If this continues, I will rather start new
thread... ("C++ as lowlevel language").


---
[ 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                       ]

In article <bs5xm1ns.fsf@ender.evo6.com>, Andy Sawyer wrote:

> On Mon, 14 Oct 2002 15:05:16 +0000 (UTC), cxl@centrum.cz ("Mirek
> Fidler") wrote:
>
>> So using XOR trick in sense of _practical_ portability causes much
>> less problems than using e.g. member templates.
>
> Not when you're talking about standard conforming compilers (last time
> I looked, the "std" in the name of this newsgroup, was a contraction
> of "standard". If I'm wrong in that understanding, I'm happy to see
> your evidence.

Please note that using the XOR trick doesn't necessarily imply undefined
behavior in today's standard C++; the standard provides certain guarantees
about casts from a pointer to an integral type and back (see 5.2.10, rules
4 and 5).

[snip]

>> In fact, if banning such practices in future C++ standard is to be
>> considered, I would like to ask one important question:

[snip]

>> Will C++0x  still be considered to be language suitable for systems
>> programming ?
>
>  Of course, if you'd followed the thread, then you'd know that the
> "banning" of such manipulation is tied up with support for garbage
> collection (read the subject line) - and I don't think I've heard
> anyone advocate the use of GC in systems programming.

Adding conservative GC wouldn't necessarily 'ban' all bitwise pointer
manipulation; it would ban those programs that use such a mangled pointer
as the *only* reference to a heap-allocated object.

I'm sure some people would say that such a ban would make C++ insuitable
for systems programming.  I've heard that same complaint about other C++
features, such as dynamic memory allocation, destructors and exception
handling.

- Wil

--
Wil Evers, DOOSYS R&D, Utrecht, Holland
[wil underscore evers at doosys dot com]

---
[ 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                       ]

"James Kanze" <kanze@gabi-soft.de> wrote in message
news:d6651fb6.0210140527.467bd90f@posting.google.com...
> ken@DIESPAMDIEcompinnovations.com ("Ken Shaw") wrote in message
> news:<ao9fkk$pr4@dispatch.concentric.net>...
> > "Wil Evers" <bouncer@dev.null> wrote in message
> > news:3da73556$0$67091$e4fe514c@dreader3.news.xs4all.nl...
> > > In article <ao74s0$hjv@dispatch.concentric.net>, Ken Shaw wrote:
>
> > > > Please explain what part of the standard this code violates:
>
> > > > int *foo = new int;
> > > > int bar = foo - (int *)0;
> > > > int *baz = (int *)0 + bar;
>
> > > 5.7.5:
> > >   When an expression that has integral type is added to or
> > >   subtracted from a pointer, the result has the type of the pointer
> > >   operand.
> > >   (...)
> > >   If both the pointer operand and the result point to elements of
> > >   the same array object, or one past the last element of the array
> > >   object, the evaluation shall not produce an overflow; otherwise,
> > >   the behavior is undefined.
>
> > Undefined maybe but this works on every compiler I have access
> > to. Also without fail every compiler I use allows xor of 2 pointers
> > and storage of outcome in an int.
>
> Really.  It works on the Sparc compilers I use, but I've known it to
> fail with Intel compilers.
>

Roughly the following code works on gcc 2.95 for redhat linux, MSVC 6 and
Code Warrior (I forget the version and not anywhere near the machine) for
Mac. I may be leaving out some detail from the production code but don't
have the time to go hunt it down right now.

int *foo = new int;
int *bar = new int;
unsigned int baz = (unsigned int)(foo) ^ (unsigned int)(bar);

Ken Shaw


---
[ 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                       ]

belvis@pacbell.net (Bob Bell) wrote in message news:<c87c1cfb.0210102039.695f69bf@posting.google.com>...
>
> Well, you already have a problem. Putting pointers into ints *is*
> undefined behavior.

No, it's not. See 5.2.10/5.

---
[ 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                       ]

bouncer@dev.null (Wil Evers) wrote in message
news:<3dab1e0a$0$33890$e4fe514c@dreader4.news.xs4all.nl>...

> Adding conservative GC wouldn't necessarily 'ban' all bitwise pointer
> manipulation; it would ban those programs that use such a mangled
> pointer as the *only* reference to a heap-allocated object.

Well, one of the reasons for using the xor trick was to have one less
pointer per node:-).

On the other hand, the overhead for variable sized dynamic allocation is
at least a pointer, generally more.  So if you're using operator new (or
malloc) to get the pointers in the first place, you're wasting more
memory than you've gained, and if you aren't, then a garbage collector
wouldn't be interested in your objects anyway.

Frankly, I'm more worried about things like distributed or persistent
objects, where potentially, the only pointer is on a different machine
or is in an object that is on disk.  In practice, I don't think that it
will be a problem, since such objects must be "addressable" by something
other than a C++ pointer, and you would normally have a map of that
something else to C++ pointers, but there is a world of difference
between "I don't think" and "There aren't such programs".

> I'm sure some people would say that such a ban would make C++
> insuitable for systems programming.  I've heard that same complaint
> about other C++ features, such as dynamic memory allocation,
> destructors and exception handling.

Well, you probably cannot use the C++ dynamic memory allocator to write
the C++ dynamic memory allocator.  Within the OS, you almost certainly
need a special allocator, and there will be places where you can't use
dynamic memory at all.  Same thing for exceptions.

The answer to that is, of course, when you are in such places, don't use
those features.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

ken@DIESPAMDIEcompinnovations.com ("Ken Shaw") wrote in message
news:<aof2uk$prt@dispatch.concentric.net>...
> "James Kanze" <kanze@gabi-soft.de> wrote in message
> news:d6651fb6.0210140527.467bd90f@posting.google.com...
> > ken@DIESPAMDIEcompinnovations.com ("Ken Shaw") wrote in message
> > news:<ao9fkk$pr4@dispatch.concentric.net>...
> > > "Wil Evers" <bouncer@dev.null> wrote in message
> > > news:3da73556$0$67091$e4fe514c@dreader3.news.xs4all.nl...
> > > > In article <ao74s0$hjv@dispatch.concentric.net>, Ken Shaw wrote:

> > > > > Please explain what part of the standard this code violates:

> > > > > int *foo = new int;
> > > > > int bar = foo - (int *)0;
> > > > > int *baz = (int *)0 + bar;

> > > > 5.7.5:
> > > >   When an expression that has integral type is added to or
> > > >   subtracted from a pointer, the result has the type of the pointer
> > > >   operand.
> > > >   (...)
> > > >   If both the pointer operand and the result point to elements of
> > > >   the same array object, or one past the last element of the array
> > > >   object, the evaluation shall not produce an overflow; otherwise,
> > > >   the behavior is undefined.

> > > Undefined maybe  but this  works on every  compiler I  have access
> > > to.  Also  without fail  every  compiler I  use  allows  xor of  2
> > > pointers and storage of outcome in an int.

> > Really.  It works on the Sparc compilers I use, but I've known it to
> > fail with Intel compilers.

> Roughly the following code works on gcc 2.95 for redhat linux, MSVC 6
> and Code Warrior (I forget the version and not anywhere near the
> machine) for Mac. I may be leaving out some detail from the production
> code but don't have the time to go hunt it down right now.

> int *foo = new int;
> int *bar = new int;
> unsigned int baz = (unsigned int)(foo) ^ (unsigned int)(bar);

I'm not sure, but I think it should work on a Mac.  Linux castrates
Intel processors, so it also still works.  The last professional work I
did on Intel processors, however, used 48 bit pointers, with 32 bit
longs.  Using 64 bit longs would have been a reasonable alternative, but
let's face it, if the processor can address 2^48 bytes of memory, it's a
pretty poor excuse of an OS which won't let you do it.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

cxl@centrum.cz ("Mirek Fidler") wrote in message news:<aoed5m$21l$1@news.vol.cz>...
[Destructor discussion omitted]
>
>     IT DOES NOT. Solving problem without GC means just rethinking your
> programming style in favor of using containers, or simply stated, to use
> scope to manage resources.
That's clearly the fundamental issue.  If your program can easily be
written such that all object lifetimes end with a scope, there is not
much point to using a garbage collector.  But in many cases that's
hard.  In a few cases (cf.
http://www.hpl.hp.com/personal/Hans_Boehm/gc/example.html) it seems to
be impossible without significant performance loss.

Once you accept that an object's lifetime doesn't end at a
well-defined program point, it also becomes unsafe to just run
destructors synchronously, e.g. as a result of a zero reference count.
 Otherwise you can construct examples in which the destructor
deadlocks because it needs a lock that the thread already owns, etc.
Thus I claim that in cases in which a tracing collector is useful, the
loss of synchronous destructors doesn't hurt; they were broken (for
that case) anyway.

If garbage collection is available, you do need two mechanisms to
perform destructor-like operations:

1) Synchronous destructors (or possibly try-finally blocks and
explicit calls) to perform synchronous cleanups in those cases in
which you can (for non-memory resources probably the usual case), and
you have to (typically rare).

2) An asynchronous finalizer-like mechanism for cleanups of objects
whose death is detected by the GC.

It's not terrribly hard to use a combination of those, e.g to close
files explicitly when possible, and to have the garbage collector
clean up (or report) those you missed.
>
>     BTW, there is one thing I cannot understand - why all GUI-toolkit
> writers organize composite widgets like this
>
> class Dialog {
>     Button *button1;
>     EditField *edit;
> };
>
>     while "the right way" should be
>
> class Dialog {
>     Button button1;
>     EditField edit;
> };
How does that work if you want to use a subclass My_Button of Button
in a Dialog?

>
>     Boehm's collector... Another buzzword. While I really like the idea,
> there should be always mentioned one thing (if I was able to understand it
> principles right): it is principally wrong algorithm.
> It works only on statistical presumptions (like "there will not be too much
> doubles that look like pointers") and thus will fail with some
> application domains - IMHO building GIS-web server would fail with Boehm's
> collector, simply because GIS is memory hungry and may allocate as much as
> hunderts of megabytes of memory - and, statistically, much more doubles will
> look like pointers then.. Such a server would really not be suitable to run
> for days...
My employer would be happy to sell you a machine with 64-bit addresses
to solve that problem :-) .

More seriously, if we assume 32-bit adddresses, and if your web server
uses new or malloc, it is probably already relying on statictical
properties.  Robson proved many years ago that any malloc-like memory
allocator could, in the worst case, multiply your space requirements
by something like log2(max/min) due to fragmentation, where max and
min are the maximum and minimum object sizes.  And many commonly used
malloc/new implementations have substantially worse worst-case space
overhead.  Assuming your web server can allocate 0.5GB of memory, and
the largest chunk of memory it allocates is on the order of a MB,
there is no guarantee that you won't need more than 4GB, even with an
optimally constructed malloc.

The only way out of this is compaction (or a 64-bit address space).
And almost certainly the least painful way to get compaction is with a
type accurate garbage collector.  Or you can rely on statistics.

>     Perhaps we differ only on level what standard should add... If standard
> would add just tools to help build GC by library (like reflection, some sort
> of stack examination, hook to malloc to signalize collecting etc.), and
> would be able to add it with no performance impact on existing code, I
> agree.
So do I.  But remember that fully type-accurate (nonconservative) GC
on arbitrary objects in C++ (or C) is hard.  Unions (and especially
pointers to unions members!) are the most painful piece.  The nice
thing about a conservative collector is that it can use the type
information you care to give it (and are willing to trust), but can
overlook the missing pieces.  The alternative is to throw out the code
that relies on the missing pieces, and possibly rewrite the rest to
follow the GC conventions.

Hans

---
[ 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                       ]

In article <1178a29f.0210151335.679c0d80@posting.google.com>,
Hans_Boehm@hp.com (Hans-J. Boehm) wrote:

>>     IT DOES NOT. Solving problem without GC means just rethinking your
>> programming style in favor of using containers, or simply stated, to use
>> scope to manage resources.
>That's clearly the fundamental issue.  If your program can easily be
>written such that all object lifetimes end with a scope, there is not
>much point to using a garbage collector.  But in many cases that's
>hard.

This is a point often lost in the GC discussion: Sometimes a genuine GC is
needed, because all lost pointers are not possible to clean up.

One such situation is when implementing a dynamic language of some sort.
Then it is very hard to do that in C++, because one cannot currently keep
track of the automatic and temporary objects that the C++ compiler so
conveniently otherwise allocates for you.

The most common method of cleaning up dead pointers is to take down the
whole program. But this does not work when a program is turned into a
library, say a DLL to be used with some IDE (integrated development
system). -- I have some problems with Bison & M4 turned into DLL's with my
IDE. Then, as these programs do not release their resources, after a
couple of compiles, the IDE runs out of memory. It would be very difficult
to modify the C code sources so that this does not happen.

So there are situations where one wants a program to be able to run
forever, and able to cleanup its dead objects.

>>     Perhaps we differ only on level what standard should add... If standard
>> would add just tools to help build GC by library (like reflection, some sort
>> of stack examination, hook to malloc to signalize collecting etc.), and
>> would be able to add it with no performance impact on existing code, I
>> agree.
>So do I.  But remember that fully type-accurate (nonconservative) GC
>on arbitrary objects in C++ (or C) is hard.  Unions (and especially
>pointers to unions members!) are the most painful piece.  The nice
>thing about a conservative collector is that it can use the type
>information you care to give it (and are willing to trust), but can
>overlook the missing pieces.  The alternative is to throw out the code
>that relies on the missing pieces, and possibly rewrite the rest to
>follow the GC conventions.

Following this GC discussions over a period of time (before the some
hundred plus posts in this thread! :-) ), I have noticed that there are
two different kinds of GC that people may want to have:

The first one is a Boehm like GC (sorry the buzz-word :-) ) that can
somehow is used as an alternative malloc/operator new memory allocator. In
this category, one wants old code to work as much as possible with minimal
source code alteration.

The second category is when writing new code that requires a more exact
GC: It might be non-deterministic GC or not, but it should only cleanup a
certain category of objects. This is the variation needed when
implementing for example dynamic languages: One then may use in effect
more than one GC depending on the size or nature of the object. For
example small objects may be put on a linked list, whereas larger ones may
use a two-space copy-GC. Or something.

I am myself mainly interested in the latter category. Here C++ needs to
have some extensions so that the information about global, automatic,
heap, temporary (in "registers") etc. objects become available, so that
the GC can trace and only clean up the required stuff in a manner typical
of that GC.

If one is using a ref count, the syntax might be
   ref<T> t = new T(...);
   ...
When using a GC, the operator new() also may be attached to the GC. So the
syntax might (symbolically) be
  GC gc; // Create a gc object.
  ...
  ref<T, gc> t = new(gc) T(...);
  ...

In addition, the GC must carry information about how it should trace: If
the reference is distributed or in a closed file or something, should then
that objects be cleanuped? Perhaps the object it points to is maintained
by another GC, say a program that can be picked down, and should not be
collected for that reason. If an object contains references to objects
that the GC does not maintain, should the GC still trace through the
pointers of that GC to see if those objects should be collected (probably
objects will have somehow "registered" with a GC in order for it to see
it).

>If garbage collection is available, you do need two mechanisms to
>perform destructor-like operations:
>
>1) Synchronous destructors (or possibly try-finally blocks and
>explicit calls) to perform synchronous cleanups in those cases in
>which you can (for non-memory resources probably the usual case), and
>you have to (typically rare).
>
>2) An asynchronous finalizer-like mechanism for cleanups of objects
>whose death is detected by the GC.

This is also an equation that I arrive at, but I do not see all the details:

When using a ref count (in non-threaded environments), it seems perfectly
OK to run the object destructor only when the object itself is destroyed.

If that picture should be translated into the GC model & C++ automatic
objects, then when an object leaves a C++ environment, a signal is sent to
the GC to decide whether the object destructor is run or not.

Most likely, if one is using objects that need special semantic actions at
specific point is time, like a file or window that needs to be closed,
then one will have to implement special functions to handle that, rather
than relying on the C++ destructors. -- One can note that there is a
difference between closing a file and maintaining a reference to it so
that it can be opened later via that reference, and in addition discarding
the reference to it so that the reference cannot be used anymore. The
latter would mostly be needed if memory resources are scarce.

But suppose a multiply referenced window is closed, maintained by the GC,
and somebody else tries to reference that window with a still apparently
live GC reference. Then it must be possible to check that the object
itself is dead before use; if one tries to access an object that is dead,
then one should get a C++ exception thrown. (Like when dynamic_cast<T&>
finds a 0 pointer.)

So, probably for rare uses, one can think of code where the destructor is
run explicitly, and where other uses of the object is checked via the GC
before actual use. Inadvertent access of dead object causes a C++
exception to be thrown.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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                       ]

"Niklas Matthies" <news_comp.std.c++_expires-2002-10-01@nmhq.net> wrote
in message
news:slrnaqdq29.396.news_comp.std.c++_expires-2002-10-01@moongate.nmhq.n
et...
> On Thu, 10 Oct 2002 21:56:05 +0000 (UTC), "Ken Alverson"
<Ken@Alverson.net> wrote:
> >
> >  Like Wil said, this just looks like a mess to me.  Xoring pointers
is a
> >  total hack, and any code that does so is invoking undefined
behavior
>
> How so? Pointer objects can be read and written as an array of
unsigned
> char, which certainly can be xored, and computing the bit pattern of
> the original pointer object from those xored values and writing it
into
> a pointer object as an unsigned char array certainly results in the
same
> valid pointer value. No undefined behavior here.

Reviewing the standard, I do concede that you can convert a pointer to
an integer, do funny things to the integer, and then (as long as you end
up with the original integer) convert it back into a valid pointer.  It
still doesn't strike me as a good idea, but perhaps that is because I'm
not seeing how by doing so one is able to conjure up extra memory.

Ken


---
[ 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                       ]

""Stephen Howe"" <SPAMstephen.howeGUARD@tnsofres.com> wrote in message
news:3da6c81d$0$1293$ed9e5944@reading.news.pipex.net...
>
> > Besides, by xoring pointers, you are preventing the compiler from
> > properly optimizing the swap (for example - on x86, XCHG would be
more
> > efficient)
>
> No it wouldn't. Most modern compilers avoid XCHG like the plague
because it
> does a implied LOCK if one of the operands is memory

Sorry, I'm used to situations where the implied LOCK is desirable.
However, I can't imagine XOR is the fastest way to swap pointers.

Bringing this back to C++, isn't preventing this type of argument
exactly why we have std::swap?

Ken


---
[ 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                       ]

In article <3da71c65$0$1293$ed9e5944@reading.news.pipex.net>, Stephen Howe
wrote:

>> This trick saves 1 pointer per node of a dlist, a not insubstantial thing
> in the not too distant past and
>> an optimization my boss ( the original author ) is not going to willingly
> give up.
>
> How so? Each node requires two pointers: a pointer to the previous
> element, a pointer to the next element. That is no different from
> std::list. AFAIK, all double-linked lists are the same in that regard.

The XOR trick that came up in this thread is used for managing a
doubly-linked list using only a single pointer-sized field per node.  For
each node, we XOR the address of previous node with the address of the
next node, and store the resulting bit pattern in the node itself.

When going forward through the list, the address of the next node is found
by XORing the address of the previous node with the bit pattern stored in
the current node; when going backward through the list, the address of the
previous node is found by XORing the address of the next node with the bit
pattern stored in the current node.

Starting from the root set (the program's statically allocated data, its
stack and CPU registers), the Boehm collector recursively searches for bit
patterns that might be interpreted as pointers to objects on the heap.   If
it finds such a pattern, the corresponding heap object is considered
reachable; otherwise, it concludes its memory can be recycled.

Since the Boehm collector probably won't recognize the XORed bit patterns
as pointers to heap objects, it will prematurely recycle the memory
allocated to the list nodes.

- Wil

--
Wil Evers, DOOSYS R&D, Utrecht, Holland
[wil underscore evers at doosys dot com]

---
[ 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                       ]

"Wil Evers" <bouncer@dev.null> wrote in message
news:3da73556$0$67091$e4fe514c@dreader3.news.xs4all.nl...
> In article <ao74s0$hjv@dispatch.concentric.net>, Ken Shaw wrote:
>
> > Please explain what part of the standard this code violates:
> >
> > int *foo = new int;
> > int bar = foo - (int *)0;
> > int *baz = (int *)0 + bar;
>
> 5.7.5:
>
>   When an expression that has integral type is added to or
>   subtracted from a pointer, the result has the type of the
>   pointer operand.
>   (...)
>   If both the pointer operand and the result point to elements
>   of the same array object, or one past the last element
>   of the array object, the evaluation shall not produce an
>   overflow; otherwise, the behavior is undefined.
>

Undefined maybe but this works on every compiler I have access to. Also
without fail every compiler I use allows xor of 2 pointers and storage of
outcome in an int.

Ken Shaw



---
[ 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                       ]

""Ken Alverson"" <Ken@Alverson.net> wrote in message
news:ao7i40$e4$1@eeyore.INS.cwru.edu...
> "Niklas Matthies" <news_comp.std.c++_expires-2002-10-01@nmhq.net> wrote
> in message
> news:slrnaqdq29.396.news_comp.std.c++_expires-2002-10-01@moongate.nmhq.n
> et...
> > On Thu, 10 Oct 2002 21:56:05 +0000 (UTC), "Ken Alverson"
> <Ken@Alverson.net> wrote:
> > >
> > >  Like Wil said, this just looks like a mess to me.  Xoring pointers
> is a
> > >  total hack, and any code that does so is invoking undefined
> behavior
> >
> > How so? Pointer objects can be read and written as an array of
> unsigned
> > char, which certainly can be xored, and computing the bit pattern of
> > the original pointer object from those xored values and writing it
> into
> > a pointer object as an unsigned char array certainly results in the
> same
> > valid pointer value. No undefined behavior here.
>
> Reviewing the standard, I do concede that you can convert a pointer to
> an integer, do funny things to the integer, and then (as long as you end
> up with the original integer) convert it back into a valid pointer.  It
> still doesn't strike me as a good idea, but perhaps that is because I'm
> not seeing how by doing so one is able to conjure up extra memory.
>

So by xor'ing the previous and next pointers together you can store only 1
int in a dlist rather than 2 pointers.

Ken Shaw



---
[ 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                       ]

ken@DIESPAMDIEcompinnovations.com ("Ken Shaw") writes:

> "Wil Evers" <bouncer@dev.null> wrote in message
> news:3da73556$0$67091$e4fe514c@dreader3.news.xs4all.nl...
> > In article <ao74s0$hjv@dispatch.concentric.net>, Ken Shaw wrote:
> >
> > > Please explain what part of the standard this code violates:
> > >
> > > int *foo =3D new int;
> > > int bar =3D foo - (int *)0;
> > > int *baz =3D (int *)0 + bar;
> >
> > 5.7.5:
> >
> >   When an expression that has integral type is added to or
> >   subtracted from a pointer, the result has the type of the
> >   pointer operand.
> >   (...)
> >   If both the pointer operand and the result point to elements
> >   of the same array object, or one past the last element
> >   of the array object, the evaluation shall not produce an
> >   overflow; otherwise, the behavior is undefined.
> >
>=20
> Undefined maybe but this works on every compiler I have access to.

How many architectures are you trying? This behaviour, whilst clearly
- and _explicitly_ undefined, is the kind of behaviour which either
"works" or doesn't "work" based of hardware architecture, rather than
compiler implementation.

> Also without fail every compiler I use allows xor of 2 pointers and
> storage of outcome in an int.

Then quite clearly, every compiler you use is non-conforming, since
5.12 (Bitwise exclusive OR operator), paragraph 1 states:

  "The operator applies only to integral or enumeration operands."

By contrast to your experience, every compiler _I_ use=B9 rejects xor of
2 pointers.

Regards,
 Andy S.

Footnotes:=20
=B9  Or at least, use regularly. There are several that I use which I do
not have installed on my notebook.
--=20
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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                       ]

> > I think this is common problem - most of "smart pointers" are hidden
> > containers.
>
> Not at all.

    Well, I am speaking here from my perspective and experience... It really
depends on style, but I found that simple thinking about "auto_ptr<T>"
as of container that can hold zero or one object of type T (or
derived from T) at least clears your style a lot...

> If you use pointers just to point to things, you end up with a large
> number of different strong pointer types, because ownership patterns
> vary.

    Again, I can speak only for myself and thounsands of lines of C++ code I
write, but I really use only raw pointers and something I call Ptr<T>, which
is strong (in sense it nullifies when pointed object gets destructed) and
serializable pointer (in sense that when it is stored to e.g. file and the
object it points to is also stored and then both of them are restored from
file, Ptr<T> again points to the object). I need no more. Considering wide
area of problems our organization has to solve (compilers, SQL-based
aplications, GUI, GIS, simple everything you can imagine), I simply cannot
understand all the buzz
around GC... For me, GC would not simplify things, it may just further
complicate them...

> > I also think that GC will never work well with destructor idea - it is
> > complement view of problem.

> The two ideas are orthogonal.  There are a lot of classes which either
> don't have destructors (e.g. complex), or only have them in order to
> manage memory (e.g. string).  There are also a number of classes which
> use destructors to manage resources other than memory.  Most of the
> time, these end up being used as local variables, so garbage collection
> doesn't change a thing.

    I think that problem is not about "top-level" variables but rather about
member variables. It is nice when you can say there is no problem about:

void foo() {
    istream in;
    ....
}

    but what about

struct Foo {
    istream in;
};

    Thus you will end up examining each class internals whether it is
"garbage collectable".

    So, the ideas are really complement rather than orthogonal - classes,
that rely on destructors for realeasing resources cannot be collected by GC.

    Sure, you propose you can always call "delete" for them. But how will
you know that class can be GC-collected ? Imagine library that exposes only
abstract interfaces, or some form of hierarchy (e.g. stream hierarchy is a
good example). You will never be sure whether you can rely on GC or should
call
delete. This would be much more mess than it is now.

> > And, while GC may take care about memory resources, destructors take
> > care about all kinds of resources plus they do it synchronously - two
> > things you never get from GC.
>
> Garbage collection only solves one problem.  That's sure.  It doesn't
> claim to solve any more.  And it only solves it partially, at that.

    Plus, GC solves problem that is already solved.

> On the other hand, solving the problem without garbage collection means
> more code must be written, which increases the risk of errors, and the
> time it takes to develop software.

    IT DOES NOT. Solving problem without GC means just rethinking your
programming style in favor of using containers, or simply stated, to use
scope to manage resources.

    BTW, there is one thing I cannot understand - why all GUI-toolkit
writers organize composite widgets like this

class Dialog {
    Button *button1;
    EditField *edit;
};

    while "the right way" should be

class Dialog {
    Button button1;
    EditField edit;
};

    This is just one thing that needs to be rethinked. BTW, this is also
nice example when not using GC actually means less code to write - you avoid
all the new's to create sub-widgets.

> If programmer time is a free resource in your environment, you don't
> need garbage collection.  Because frankly, if your organization can't
> write a correct program without garbage collection, it won't be able to
> write one with garbage collection.  On the other hand, if it can develop
> correct programs without garbage collection, it can do so more cheaply
> and more quickly with garbage collection.

    Well, not me :)

> > At this level there is no difference between writing
>
> > gc_ptr<Something> x = gc_new Something;
>
> > from any other form (with slight ugliness of gc_new being macro). And
> > above can be rather effectively managed by library. Sure, they may be
> > performance impact between this and GC build in language core, but
> > that may be negligible (I volunteer to build such GC library and find
> > out :).
>
> Be sure to compare it to the Boehm collector (existing practice which
> doesn't require any markers in the source code).

    Boehm's collector... Another buzzword. While I really like the idea,
there should be always mentioned one thing (if I was able to understand it
principles right): it is principally wrong algorithm.
It works only on statistical presumptions (like "there will not be too much
doubles that look like pointers") and thus will fail with some
application domains - IMHO building GIS-web server would fail with Boehm's
collector, simply because GIS is memory hungry and may allocate as much as
hunderts of megabytes of memory - and, statistically, much more doubles will
look like pointers then.. Such a server would really not be suitable to run
for days...

> So what's the point.  The standard may add garbage collection.  It might
> even define some semantics for it.  But it certainly won't impose any

    Perhaps we differ only on level what standard should add... If standard
would add just tools to help build GC by library (like reflection, some sort
of stack examination, hook to malloc to signalize collecting etc.), and
would be able to add it with no performance impact on existing code, I
agree.

    If standard would add GC as non-optional standard for memory allocation,
I disagree. OTOH, I am not afraid of this as this would impose major
incompatibilities with current C++.

Mirek



---
[ 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                       ]

>> Undefined maybe but this works on every compiler I have access to.

> How many architectures are you trying? This behaviour, whilst clearly
>- and _explicitly_ undefined, is the kind of behaviour which either
>"works" or doesn't "work" based of hardware architecture, rather than
>compiler implementation.

Come on. Presumption that pointers are in reality 32 or 64 (or, in the worst
case, 36 :) bit numeric values meaning machine address will work on much
more platform/compiler pairs than most of "standard-conformant" template
stuff. So using XOR trick in sense of _practical_ portability causes much
less problems than using e.g. member templates. For most applications, such
a presumption (that pointer is numeric address) will never cause problems.

In fact, if banning such practices in future C++ standard is to be
considered, I would like to ask one important question:

Will C++0x  still be considered to be language suitable for systems
programming ?

Mirek


---
[ 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                       ]

On Mon, 14 Oct 2002 15:05:16 +0000 (UTC), cxl@centrum.cz ("Mirek
Fidler") wrote:

> >> Undefined maybe but this works on every compiler I have access to.
>
> > How many architectures are you trying? This behaviour, whilst clearly
> >- and _explicitly_ undefined, is the kind of behaviour which either
> >"works" or doesn't "work" based of hardware architecture, rather than
> >compiler implementation.
>
> Come on. Presumption that pointers are in reality 32 or 64 (or, in
> the worst case, 36 :) bit

Don't forget 12 and 15 bit. (I've worked in both environments - it
seems safe to assume that you haven't) More interestingly, I've also
used platforms where the address size was 20 bits, and the natural
integer size was 16 bits.

> numeric values meaning machine address will work on much more
> platform/compiler pairs than most of "standard-conformant" template
> stuff.

If the "standard conformant template stuff" you refer to doesn't
work, then your compiler isn't standard conformant, is it? So anything
you say about that compiler is irrelevant in terms of conformance.

> So using XOR trick in sense of _practical_ portability causes much
> less problems than using e.g. member templates.

Not when you're talking about standard conforming compilers (last time
I looked, the "std" in the name of this newsgroup, was a contraction
of "standard". If I'm wrong in that understanding, I'm happy to see
your evidence.

> For most applications, such a presumption (that pointer is numeric
> address) will never cause problems.

That's your opinion, and you're entitled to it. But if you ever start
writing software thats inteded to stop commercial aircraft from
falling out of the sky, please do the courtesy of letting me know so I
can stop travelling by air.

> In fact, if banning such practices in future C++ standard is to be
> considered, I would like to ask one important question:

You'd better ask the people who want to ban bit-manipulations of
pointers - I'm not one of them, I'm merely pointing out that the
behaviour is undefined (Naturally, you're welcome to read the standard
yourself rather than rely on my reading it for you).

>
> Will C++0x  still be considered to be language suitable for systems
> programming ?

 Of course, if you'd followed the thread, then you'd know that the
"banning" of such manipulation is tied up with support for garbage
collection (read the subject line) - and I don't think I've heard
anyone advocate the use of GC in systems programming.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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                       ]

Ken@Alverson.net ("Ken Alverson") wrote in message
news:<ao7i40$e4$1@eeyore.INS.cwru.edu>...
> "Niklas Matthies" <news_comp.std.c++_expires-2002-10-01@nmhq.net>
> wrote in message
> news:slrnaqdq29.396.news_comp.std.c++_expires-2002-10-01@moongate.nmhq.n
> et...
> > On Thu, 10 Oct 2002 21:56:05 +0000 (UTC), "Ken Alverson"
> > <Ken@Alverson.net> wrote:
> > >  Like Wil said, this just looks like a mess to me.  Xoring
> > >  pointers is a total hack, and any code that does so is invoking
> > >  undefined behavior

> > How so? Pointer objects can be read and written as an array of
> > unsigned char, which certainly can be xored, and computing the bit
> > pattern of the original pointer object from those xored values and
> > writing it into a pointer object as an unsigned char array certainly
> > results in the same valid pointer value. No undefined behavior here.

> Reviewing the standard, I do concede that you can convert a pointer to
> an integer, do funny things to the integer, and then (as long as you
> end up with the original integer) convert it back into a valid
> pointer.  It still doesn't strike me as a good idea, but perhaps that
> is because I'm not seeing how by doing so one is able to conjure up
> extra memory.

It's not necessarily a good idea.  The person who originally mentionned
the problem didn't say that it was, or that we should all rush out and
write programs this way.  He said he had a lot of legacy code which did
this.  The criteria for good code weren't always what they are today,
the xor trick can save memory under certain conditions, and there was a
time when saving every little bit of memory was important.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

E. Mark Ping wrote:

> Sigh.  Clearly you didn't read the links I put in the post.
>
> Having user-called Dispose means...


I just went ahead and read some of them. All of the complexity
that I saw there, and on the MS web site, and your reply, is due
to mistaken design, which is trying to be all things to all people.

Dispose is for resources that must be released as soons as possible
after the code is done using them. Classes which use this should be
designed for callers who use them properly. This means that it is
the caller's responsibility to make sure that Dispose is called
once and only once, and to prevent multiple threads from accessing
it at the same time. The class needs no finalizer.

The concept that GC saves you from worrying about object
lifetimes is illusion.

---
[ 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                       ]

"Wil Evers" <bouncer@dev.null> wrote in message
news:3da5c115$0$33978$e4fe514c@dreader7.news.xs4all.nl...
> In article <ao49in$irt@dispatch.concentric.net>, Ken Shaw wrote:
>
> > My company uses a huge amount of legacy code which includes many old C
> > pointer tricks including the xor trick in doubly linked lists and many
> > other places where pointers are contained in ints for various reasons.
>
> Boy, that sounds like a mess.  I wouldn't be my company's future on it.

Actually for a dlist with several tens of thousands of nodes it is quite
fast and efficient. Each node is 4 bytes smaller than the stl list and
access is comparable. The objects were first implemented in the early 90's
and at this point are quite thoroughly debugged and optimized.

>
> > This code is very heavily used through out several large projects and
> > cannot be simply or easily changed.
>
> Why?

There is absolutely no time or budget to go into working code and "fix"
unbroken code.

>
> > A compiler which supports that paragraph would never be purchased by
> > my company.
>
> Not even if you can switch off the collector and get back the old
behavior?
>

Note you said add a paragraph to the standard making putting pointers into
int's undefined behaviour. At present we use 3 compilers already with
mutually exclusive compiler flags which makes make file maintenace a
headache already. Inevitably some new project using our classes would leave
out that compiler flag which would probably only show up in a release build
and, unless someone relized right away what had happened, we would then
spent a lot of time debugging.

My primary consideration for any change to C++ is that the new feature
should break not one line of legal code period. Check with anyone who had
legacy projects that needed to be compiled after the compilers that
supported namespaces came out. For us it was a 4 day affair of going through
each source file and adding the using declaration to each while also
removing the .h from all the system include files and add c to all the C
include files. I then had the joy of explaining to the owner why several
hundred man/hours had been spent on doing unbilled work.

Ken Shaw




---
[ 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                       ]

""Ken Shaw"" <ken@DIESPAMDIEcompinnovations.com> wrote in message
news:ao49in$irt@dispatch.concentric.net...
>
> My company uses a huge amount of legacy code which includes many old C
> pointer tricks including the xor trick in doubly linked lists and many
other
> places where pointers are contained in ints for various reasons.

Like Wil said, this just looks like a mess to me.  Xoring pointers is a
total hack, and any code that does so is invoking undefined behavior - I
don't think such an argument should hold weight in determining future
changes.

Besides, by xoring pointers, you are preventing the compiler from
properly optimizing the swap (for example - on x86, XCHG would be more
efficient)

Ken


---
[ 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                       ]

===================================== MODERATOR'S COMMENT:
 This is drifting off-topic for this newsgroup; please
ensure that followups relate to C++ standardisation.




===================================== END OF MODERATOR'S COMMENT
> Besides, by xoring pointers, you are preventing the compiler from
> properly optimizing the swap (for example - on x86, XCHG would be more
> efficient)

No it wouldn't. Most modern compilers avoid XCHG like the plague because it
does a implied LOCK if one of the operands is memory

Stephen Howe


---
[ 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                       ]

bouncer@dev.null (Wil Evers) wrote in message
news:<3da548a4$0$4002$e4fe514c@dreader6.news.xs4all.nl>...

> As far as I can see, there isn't really that much to implement. To
> 'legalize' the Boehm collector, some wording that forbids the use of
> disguised pointers to heap objects would have to be added to the
> standard. Elsewhere in this thread, James Kanze wrote:

>         Formally, all that is really needed is a statement to the effect
>         that once all pointers to the object in the task image have
>         ceased to exist, any further access to the object is undefined
>         behavior.

> That sounds like a good start to me.

Just to clarify a point: the idea isn't originally from me.  Bjarne
Stroupstrup had a proposal along these lines before the last standard
was adopted, and I think I heard something similar from Andy Koenig well
before that.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

ken@DIESPAMDIEcompinnovations.com ("Ken Shaw") wrote in message
news:<ao4rmj$irt@dispatch.concentric.net>...

> My primary consideration for any change to C++ is that the new feature
> should break not one line of legal code period. Check with anyone who
> had legacy projects that needed to be compiled after the compilers
> that supported namespaces came out. For us it was a 4 day affair of
> going through each source file and adding the using declaration to
> each while also removing the .h from all the system include files and
> add c to all the C include files. I then had the joy of explaining to
> the owner why several hundred man/hours had been spent on doing
> unbilled work.

I think that this is an important point, and I agree with the concerns
expressed.  (You can't just rewrite legacy code because you know a
better way to do it today.)

If I were designing a new language, from scratch, I'm sure that garbage
collection would be the default, and that you'd have to take steps to
turn it off.  But C++ doesn't have this luxury.  While I strongly favor
some sort of garbage collection, the *default* behavior of the language
must be unchanged.  The user *must* take some active step to tell the
compiler that his project uses no hidden pointers.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

ken@DIESPAMDIEcompinnovations.com ("Ken Shaw") wrote in message news:<ao4rmj$irt@dispatch.concentric.net>...
> "Wil Evers" <bouncer@dev.null> wrote in message
> news:3da5c115$0$33978$e4fe514c@dreader7.news.xs4all.nl...
> > In article <ao49in$irt@dispatch.concentric.net>, Ken Shaw wrote:
> > > A compiler which supports that paragraph would never be purchased by
> > > my company.
> >
> > Not even if you can switch off the collector and get back the old
>  behavior?
> >
>
> Note you said add a paragraph to the standard making putting pointers into
> int's undefined behaviour.

Well, you already have a problem. Putting pointers into ints *is*
undefined behavior.

Bob

---
[ 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                       ]

""Ken Alverson"" <Ken@Alverson.net> wrote in message
news:ao4srq$6pj$1@eeyore.INS.cwru.edu...
> ""Ken Shaw"" <ken@DIESPAMDIEcompinnovations.com> wrote in message
> news:ao49in$irt@dispatch.concentric.net...
> >
> > My company uses a huge amount of legacy code which includes many old C
> > pointer tricks including the xor trick in doubly linked lists and many
> other
> > places where pointers are contained in ints for various reasons.
>
> Like Wil said, this just looks like a mess to me.  Xoring pointers is a
> total hack, and any code that does so is invoking undefined behavior - I
> don't think such an argument should hold weight in determining future
> changes.
>
> Besides, by xoring pointers, you are preventing the compiler from
> properly optimizing the swap (for example - on x86, XCHG would be more
> efficient)
>

What undefined behaviour? The standard is clear that pointers can be stored
in integral data types of sufficient size. This trick saves 1 pointer per
node of a dlist, a not insubstantial thing in the not too distant past and
an optimization my boss ( the original author ) is not going to willingly
give up.

Ken Shaw



---
[ 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                       ]

On Thu, 10 Oct 2002 21:56:05 +0000 (UTC), "Ken Alverson" <Ken@Alverson.net> wrote:
>  ""Ken Shaw"" <ken@DIESPAMDIEcompinnovations.com> wrote in message
>  news:ao49in$irt@dispatch.concentric.net...
> >
> > My company uses a huge amount of legacy code which includes many old
> > C pointer tricks including the xor trick in doubly linked lists and
> > many other places where pointers are contained in ints for various
> > reasons.
>
>  Like Wil said, this just looks like a mess to me.  Xoring pointers is a
>  total hack, and any code that does so is invoking undefined behavior

How so? Pointer objects can be read and written as an array of unsigned
char, which certainly can be xored, and computing the bit pattern of
the original pointer object from those xored values and writing it into
a pointer object as an unsigned char array certainly results in the same
valid pointer value. No undefined behavior here.

-- Niklas Matthies
--
Save Farscape - get informed and involved: http://farscape.wdsection.com/
Together, we can get Farscape back on air. Crackers *do* matter.

---
[ 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                       ]

"Bob Bell" <belvis@pacbell.net> wrote in message news:c87c1cfb.0210102039.695f69bf@posting.google.com...

> Well, you already have a problem. Putting pointers into ints *is*
> undefined behavior.
>
Nope, just implementation defined.



---
[ 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                       ]

"Bob Bell" <belvis@pacbell.net> wrote in message
news:c87c1cfb.0210102039.695f69bf@posting.google.com...
> ken@DIESPAMDIEcompinnovations.com ("Ken Shaw") wrote in message
news:<ao4rmj$irt@dispatch.concentric.net>...
> > "Wil Evers" <bouncer@dev.null> wrote in message
> > news:3da5c115$0$33978$e4fe514c@dreader7.news.xs4all.nl...
> > > In article <ao49in$irt@dispatch.concentric.net>, Ken Shaw wrote:
> > > > A compiler which supports that paragraph would never be purchased by
> > > > my company.
> > >
> > > Not even if you can switch off the collector and get back the old
> >  behavior?
> > >
> >
> > Note you said add a paragraph to the standard making putting pointers
into
> > int's undefined behaviour.
>
> Well, you already have a problem. Putting pointers into ints *is*
> undefined behavior.
>

Please explain what part of the standard this code violates:

int *foo = new int;
int bar = foo - (int *)0;
int *baz = (int *)0 + bar;

Ken Shaw


---
[ 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                       ]

Ken Shaw wrote:
> Please explain what part of the standard this code violates:
> int *foo = new int;
This is fine.

> int bar = foo - (int *)0;
This violates 5.7/6. Subtraction of two pointers is undefined
behavior if they do not both point to elements or one past the
end of the same array.

> int *baz = (int *)0 + bar;
This violates 5.7/5. Addition of an integer and a pointer is
undefined if the pointer and the result of the addition are
not both pointers to elements or one past the end of the same
array.

---
[ 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                       ]

""Ken Shaw"" <ken@DIESPAMDIEcompinnovations.com> wrote in message news:ao74s0$hjv@dispatch.concentric.net...
>
> int bar = foo - (int *)0;

This is undefined behavior (5.7/6)

Unless both pointers point to elements of the same array object, or one
past the last element of the array object, the behavior is undefined.

> int *baz = (int *)0 + bar;

This isn't even well formed.   You can't add pointers together.



---
[ 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                       ]

""Ken Shaw"" <ken@DIESPAMDIEcompinnovations.com> wrote in message
news:ao74s0$hjv@dispatch.concentric.net...
>
> Please explain what part of the standard this code violates:
>
> int *foo = new int;
> int bar = foo - (int *)0;
> int *baz = (int *)0 + bar;

5.7 looks relevant to me:

4) For the purposes of these operators, a pointer to a nonarray object
behaves the same as a pointer to the first
element of an array of length one with the type of the object as its
element type.
[...]
6) When two pointers to elements of the same array object are
subtracted, the result is the difference of the
subscripts of the two array elements. [...] Unless both pointers point
to elements
of the same array object, or one past the last element of the array
object, the behavior is undefined.

Unless I'm missing something fundamental, foo and (int*)0 are not
pointers to the same array, therefore the subtraction (and the addition)
are undefined behavior.

Not a violation, per se - seems to be syntactically legal, but not
guaranteed to do what you expect.

Ken


---
[ 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                       ]

Allan W wrote:
> geoff_field@suespammers.org ("Geoff Field") wrote
>
>>"Wil Evers" <bouncer@dev.null> wrote
>>
>>>a standard
>>>networking (TCP/IP) library was mentioned by Bjarne Stroustrup as one of
>>>the things that should be in C++Ox.
>>
>>Is that going to be an IPv6-capable library?  Protocol independant?
>>UDP as well?
>>
>>Just how far would it go?
>
>
> Start by merging common implementations of sockets and/or winsock.
> Remove anything specific to certain platforms or vendors, such as
> window handles. What's left is your first approximation.

   Oh, so "networking" is limited to only TCP running over IP, huh?  That ought
to be very interesting procedurally to try and get an ISO standard (ISO 14882,
the C++ standard) to be a derivative work (the C++ networking library) based off
from IETF RFCs and forsake ISO's own OSI protocol-stack standards.

   I do think that any C++ networking library's API should be
protocol-independent (i.e., just as useful on IBM SNA as on TCP/IP and just as
useful on ISO's OSI protocol stack as on TCP/IP), if for no other reason than to
have the even remotest chance of handling some IPv21 or IPv37 in the future.  I
would certainly hope that the library would at a minimum demonstrate that it can
reside on top of TCP/IP, UDP/IP, TP4/CNLS, X.25 and one or more protocol-stacks
from the IBM world (e.g., SNA).  (I'd throw DECnet in there too if DEC still
existed as a stand-alone corporation.)

   I do think that any C++ networking library should be handle both the
connection-oriented (TCP) and connectionless (UDP) schools of thought.  Indeed
the networking library really ought to admit that there is a graduated scale in
of connection-orientedness as demonstrated in OSI's TP0 through TP4 and in
LAP-D's UITS versus AITS.  Both UITS & AITS are session-/connection-oriented.

---
[ 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                       ]

ken@DIESPAMDIEcompinnovations.com ("Ken Shaw") wrote (abridged):
> >   Formally, all that is really needed is a statement to the
> >   effect that once all pointers to the object in the task image
> >   have ceased to exist, any further access to the object is undefined
> >   behavior.
>
> My company uses a huge amount of legacy code which includes many old C
> pointer tricks including the xor trick in doubly linked lists and many
> other places where pointers are contained in ints for various
> reasons. This code is very heavily used through out several large
> projects and cannot be simply or easily changed. A compiler which
> supports that paragraph would never be purchased by my company.

Surely "supports" is the wrong word here. Your existing compilers already
support that paragraph, because the current behaviour is included within
undefined behaviour.

And also, isn't converting pointers to ints and back again already not
required to be supported? It is only supported if there is an integral
type big enough, and there is no guarantee that such a type exists. So you
are already relying on vendor-specific features.

I don't think anything would change for you. Commercial pressure would
mean your vendor would continue to supply a compiler which supported the
XOR trick, and that compiler could continue to conform to the new
standard. The sky would not fall.

  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                       ]

> This trick saves 1 pointer per node of a dlist, a not insubstantial thing
in the not too distant past and
> an optimization my boss ( the original author ) is not going to willingly
give up.

How so? Each node requires two pointers: a pointer to the previous element,
a pointer to the next element. That is no different from std::list. AFAIK,
all double-linked lists are the same in that regard.

Stephen Howe


---
[ 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                       ]

In article <ao74s0$hjv@dispatch.concentric.net>, Ken Shaw wrote:

> Please explain what part of the standard this code violates:
>
> int *foo = new int;
> int bar = foo - (int *)0;
> int *baz = (int *)0 + bar;

5.7.5:

  When an expression that has integral type is added to or
  subtracted from a pointer, the result has the type of the
  pointer operand.
  (...)
  If both the pointer operand and the result point to elements
  of the same array object, or one past the last element
  of the array object, the evaluation shall not produce an
  overflow; otherwise, the behavior is undefined.

- Wil

--
Wil Evers, DOOSYS R&D, Utrecht, Holland
[wil underscore evers at doosys dot com]

---
[ 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                       ]

ron@sensor.com ("Ron Natalie") wrote in message
news:<Knio9.809$cG.799@fe04>...
> "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in
> message news:fxNiIxA1bVo9Ew8$@robinton.demon.co.uk...

> > Perhaps we need to leave all existing mechanisms in place and add a
> > quite separate facility by providing a garbage collection type. I am
> > thinking about something such as a new fundamental pointer/reference
> > like feature. Let me use an @ for now:

> > inr@ i_gc;

> Actually, all you really need is a GC qualifier.

> gc int* i_gc;

> You could convert a non-gc qualified pointer to a gc one but not
> vice-versa.

Which means that I couldn't use garbage collected objects with any
existing functions.

Intuitively, I tend more toward a new new (gc_new) -- memory allocated
with gc_new is garbage collected, memory not allocated with gc_new
isn't.  This isn't without problems, though, since...

    [...]

> Of course in either case, the system could (and really must) support
> destructor invocation on the collected memory.  Much of what I can
> invision using this for has some side effect in the destructor that I
> would need to have.

If you need side effects, you almost always need them to occur at a
specific time, so destructors of garbage collected objects aren't an
appropriate place for them.  Generally speaking, I tend to favor not
calling destructors when garbage collecting.

The place where this fails is when the garbage collected object contains
objects which use non-garbage collected memory (e.g. std::string).  In
this case, if the memory isn't garbage collected, then the destructor
must be called to free it.

This wouldn't be a problem if garbage collection were the default, and
non-garbage collected allocation were something exceptional.  To do
this, however, would require rewriting the history of C++.

It might be less of a problem if the standard containers (or at least
the default allocator) were specified to use garbage collection.  This
is a change with regards to the current situation, and I'm not really
sure what the implications are.

Ideally, I'd like to be able to write a program using just gc_new, and
forget about delete.  At least most of the time.  But I'm not sure how
to attain this 1) without modifying the semantics of existing code, and
2) while still maintaining the possibility of working without garbage
collection if necessary.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

In article <anu9rb$hko62$2@ID-32913.news.dfncis.de>, Nicola Musatti
<Nicola.Musatti@ObjectWay.it> writes
>Hi,
>I have read the whole thread, but I have a question that does not stem
>from any specific message. What is wrong with library based garbage
>collection, as opposed to having it directly supported by the core
>language?

I think that it relies on a degree of self discipline that is fine with
wide awake and competent programmers but that may be absent when tired,
rushed to finish or lacking as much expertise as one thinks one has.

It also has problems with retrofitting. For example, how does a library
solution allow me to have a GCed int?

Perhaps there are solutions, but I think that we should look for a clean
simple core solution with as much automatic application as possible.

For example a function parameter that is specified as a
'pointer/reference ' to a GC object should be able to accept non GC
values but not non-GC ones (because promises about it being  impossible
to have leaked or aliased accesses cannot be met).


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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                       ]

""Lawrence Rust"" <lvr@nospam.softsystem.co.uk> wrote in message news:kiAo9.148$ld2.3880@newsfep3-gui.server.ntli.net...
>
> Wouldn't it be more correct to write:
>
> int* gc i_gc;
>
> as with cv qualification indicating that i_gc is garbage collected, not the
> items pointer to by i_gc?
>
You're probably right.   I was waffling between it being a qualifier like cv
or a storage class specifier, but I think you're right.



---
[ 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                       ]

"James Kanze" <kanze@gabi-soft.de> wrote in message news:d6651fb6.0210080835.72154a32@posting.google.com...

> Which means that I couldn't use garbage collected objects with any
> existing functions.

Correct, it wouldn't be safe.   How do you know the function wouldn't store
the pointer in a non-gc pointer.   The GC might then delete it while a pointer
to it still exists.

> Intuitively, I tend more toward a new new (gc_new) -- memory allocated
> with gc_new is garbage collected, memory not allocated with gc_new
> isn't.  This isn't without problems, though, since...

How do you find out where pointers might list.   I argue that the sweep all
data space is NOT a good idea.

> If you need side effects, you almost always need them to occur at a
> specific time, so destructors of garbage collected objects aren't an
> appropriate place for them.  Generally speaking, I tend to favor not
> calling destructors when garbage collecting.

I disagree.   If for example the object is some sort of file stream or
interface to some graphic widget that involves a system resource
being freed, having that resource freed when the GC detects the
C++ object is no longer in use is important.

If destructors aren't called it stabs at the very heart of the C++ object
model.



---
[ 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                       ]

In article <a_Eo9.265559$F21.39535@fe02>, Ron Natalie <ron@sensor.com>
writes
>I disagree.   If for example the object is some sort of file stream or
>interface to some graphic widget that involves a system resource
>being freed, having that resource freed when the GC detects the
>C++ object is no longer in use is important.
>
>If destructors aren't called it stabs at the very heart of the C++ object
>model.

Yes, which means that objects in gc space must 'know' about there dtors.
I think that probably means that they should be ones with vtables. The
other kind are those with POD flavour. The more I think about this the
more I think we need core support.

How workable would be a requirement that objects handled with a gc
feature must either be ones with trivial or virtual dtors.
--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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                       ]

James Kanze wrote:
> It makes it easier.  For example, without garbage collection, you
> typically need several types of pointers.  With garbage collection, you
> will need less, and the type of the pointer will almost always be
> evident from the semantics -- no need to worry about breaking cycles,
> for example.

Hasn't the Java experience shown differently? In recent versions
of the language, they've introduced several kinds of weak pointers
that don't count the same as ordinary pointers for GC purposes.
This is because it's quite easy to leave references to memory
lying around even though the program will never use that memory
again - after all, not cleaning up memory after being done with
it is what GC is supposed to buy.

---
[ 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                       ]

"Wil Evers" <bouncer@dev.null> wrote in message
news:3d9b5098$0$16211$e4fe514c@dreader7.news.xs4all.nl...
> Hi,
>
> As a C++ user, I'd like to know if the committee is considering (optional)
> garbage collection for the next version of the C++ standard.

Interesting that in all this discussion, there hasn't been any mention (or
did I miss one?) of the one C++ implementation which is a shipping product
that includes garbage collection as a core extension - MSVC7 (aka VC.NET).

Microsoft's version of making C++ work in a GC'd environment is known as
"Managed C++".  You can read about it at

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmxspec/ht
ml/vcManagedExtensionsSpec_Start.asp

(watch for line wrap - long URL).

Like it or not, it's now "existing practice", and AFIAK, the only existing
practice of a C++ implementation with core language support for GC.

So what's good about it?  What's bad about it?  Should the next standard rev
adopt this style of core langauge support?  Of course, there are other
extensions in "Managed C++" that don't relate directly to GC (such as
reflection, versioning, metadata, the new #using directive, etc), but I
think those can be treated as independent issues.

-cd

---
[ 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                       ]

francis.glassborow@ntlworld.com (Francis Glassborow) writes:

> How workable would be a requirement that objects handled with a gc
> feature must either be ones with trivial or virtual dtors.

I'd be wary of a special-case constraint like that - personally, I
think we already have more than enough "special case" behaviour in the
language to teach students (and, of course, I spend _far_ less time
teaching than _some_ readers of this newsgroup :-).

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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                       ]

"Nicola Musatti" <Nicola.Musatti@ObjectWay.it> wrote in message news:anu9rb$hko62$2@ID-32913.news.dfncis.de...

> I have read the whole thread, but I have a question that does not stem
> from any specific message. What is wrong with library based garbage
> collection, as opposed to having it directly supported by the core language?

The distinction is blured.   Clearly there is a library component required.   However
as people have pointed out, a library only solution may not be sufficient.   To improve
upon the "any old location in memory might have a pointer value in it" requires some
additional hint about declarations passed to the runtime.



---
[ 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                       ]

In article <d6651fb6.0210080845.21a8265e@posting.google.com>,
James Kanze <kanze@gabi-soft.de> wrote:
>emarkp@CSUA.Berkeley.EDU (E. Mark Ping) wrote in message
>news:<ansjtp$7ta$1@agate.berkeley.edu>...
>> 2) The example above (and all circular references) are design errors.
>
>A double linked list is a design error?

Okay, that's a pretty good counterexample. :)

Seriously, it's a clue as to how much I use the STL that I don't think
about the implementaiton of a doubly-linked-list.   In my own work
(and I elaborated on that later in the post) I differentiate between
owners and non-owners, where owners are responsible for resource
management and non-owners aren't.  (Of course, an owner of one
resource might be a non-owner of another.)  Owners hold their
resources with smart pointers, or manage them manually.  Non-owners
have no business doing either.

Hence in the doubly-linked-list example, the nodes are non-owners.
The collection object is not the owner.  And the nodes are held
together with pointers that the collection object manages.  Now that I
think about that one more carefully, the distinction seems more
artificial than I thought before.


I agreed elsewhere (and independently) with your idea of gc_new--
having a GC allocator or heap rather than a type or type modifier.  I
think that's more compatible with modern C++.
--
Mark Ping
emarkp@soda.CSUA.Berkeley.EDU

---
[ 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                       ]

In article <3crhewyc.fsf@ender.evo6.com>, Andy Sawyer wrote:

> bouncer@dev.null (Wil Evers) writes:
>
>> I'd say this is a matter of style.  It is certainly possible to write
>> robust C++ code without having to rely on GC; however, it seems to me we
>> have a few examples illustrating that the GC-approach can be effective
>> too.
>>
>> If that is true, then it is up to you to explain why GC should remain
>> unsupported by standard C++.
>
> That's a _very_ slippery slope. Please explain to me why the following
> should remain unsupported by standard C++:
>
> - A standard graphics library
> - A standard networking library
> - Run-time compilation (c.f. Perl's "eval")
> - etc, etc, etc.
>
> (This is, or course, rhetorical).

Each of the questions you raise here seem valid to me; in fact, a standard
networking (TCP/IP) library was mentioned by Bjarne Stroustrup as one of
the things that should be in C++Ox.

> There are a huge number of features that people think would be "good
> to have" in standard C++. But I would suggest that it is up to the
> proponent(s) of such features to explain why those features should be
> supported.

As far as (optional and conservative) GC is concerned, I can see four
reasons:

(*) It would add support for a commonly used programming style;
(*) It only requires a few small changes to the language spec;
(*) The impact on existing code is minimal;
(*) There is a substantial amount of prior art in mixing C/C++ with
conservative GC, showing that it can be done.

- Wil

--
Wil Evers, DOOSYS R&D, Utrecht, Holland
[wil underscore evers at doosys dot com]

---
[ 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                       ]

Ron Natalie wrote:
> I disagree.   If for example the object is some sort of file stream or
> interface to some graphic widget that involves a system resource
> being freed, having that resource freed when the GC detects the
> C++ object is no longer in use is important.

No, because by then it's too late. These resources come from a
limited pool, generally, so you do not have the option of waiting
until an arbitray time after last use for them to be reclaimed.

> If destructors aren't called it stabs at the very heart of the
 > C++ object model.

No. In C++ it's perfectly possible, legal, and useful to create
objects and never destruct them. RAII must continue to work, for
objects with automatic scope. For heap objects, if you want it
destructed, call delete, even with GC.

As I've said before when this came up, if you want finalization
(i.e., code which runs when an object is reclaimed by GC), then
it should be done by registering a separate, reachable object
with the collector, and giving that object a pointer or copy of
the resource which needs to be reclaimed. This completely avoids
the possibility of object resurrection which otherwise plagues
finalization code which is part of the object itself.

---
[ 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                       ]

In article <d6651fb6.0210080835.72154a32@posting.google.com>, James Kanze
wrote:

> If you need side effects, you almost always need them to occur at a
> specific time, so destructors of garbage collected objects aren't an
> appropriate place for them.  Generally speaking, I tend to favor not
> calling destructors when garbage collecting.
>
> The place where this fails is when the garbage collected object contains
> objects which use non-garbage collected memory (e.g. std::string).  In
> this case, if the memory isn't garbage collected, then the destructor
> must be called to free it.

I seem to be missing something.  Are you suggesting std::string can't use
garbage-collected memory for its character buffer?

When a std::string object becomes unreachable, that simply means one less
path from the root set to its character buffer.  We don't necessarily need
a destructor call to tell the garbage collector about this; it is able to
figure this out by itself.  After the last path to the buffer is gone, it
can be recycled, just like any other heap-allocated object.

- Wil

--
Wil Evers, DOOSYS R&D, Utrecht, Holland
[wil underscore evers at doosys dot com]

---
[ 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                       ]

In article <d6Io9.1630$xx7.197105900@newssvr13.news.prodigy.com>,
Carl Daniel <cpdaniel@pacbell.net> wrote:
>Microsoft's version of making C++ work in a GC'd environment is known as
>"Managed C++".  You can read about it at
[snip]
>So what's good about it?  What's bad about it?  Should the next
>standard rev adopt this style of core langauge support?  Of course,
>there are other extensions in "Managed C++" that don't relate
>directly to GC (such as reflection, versioning, metadata, the new
>#using directive, etc), but I think those can be treated as
>independent issues.

Excellent point.  I mentioned elsewhere some serious issues with the
design, in message: <ansjtp$7ta$1@agate.berkeley.edu>

To repeat:

In C# there was an attempt to allow deterministic GC by manually
calling the "Dispose" function, which releases non-memory resources.
That introduces a whole host of problems, including differentiating
(in user code) between Disposing because of a user call vs. Disposing
during GC--because you can't talk about other objects if you're
disposing--they might have already been disposed.  That limitation
destroys the concept of ownership, because if the owner is being GC'd,
it can't dispose of the things it owns.

C# and Managed C++ garbage collection are both on the .Net framework
and the docs indicate (rather poorly IMO) that C++ destructors
(changed to Finalize) and C# destructors (changed to Finalize also)
work the same way.

See also the thread "Some changes I'd like..." and "Some changes I'd
lke [Repost]" in microsoft.public.dotnet.languages.csharp.

Here are the google links (watch for long links):

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&frame=right&rnum=1&thl=0,1028368294,1028363994,1028357452,1028346473,1028341712,1028339139,1028257232,1028339242,1028336875,1028333668,1028332041&seekm=ub53%23OHRCHA.1864%40tkmsftngp12#link1

or

http://makeashorterlink.com/?Y38422C02

for short


"Some changes I'd like [Repost]"
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&threadm=%23%24hX%23WHRCHA.2512%40tkmsftngp11&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26safe%3Doff%26selm%3D%2523%2524hX%2523WHRCHA.2512%2540tkmsftngp11

or

http://makeashorterlink.com/?W57416C02

for short

--
Mark Ping
emarkp@soda.CSUA.Berkeley.EDU

---
[ 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                       ]

bouncer@dev.null (Wil Evers) writes:

> In article <3crhewyc.fsf@ender.evo6.com>, Andy Sawyer wrote:
>
> > bouncer@dev.null (Wil Evers) writes:
> >
> >> I'd say this is a matter of style.  It is certainly possible to write
> >> robust C++ code without having to rely on GC; however, it seems to me we
> >> have a few examples illustrating that the GC-approach can be effective
> >> too.
> >>
> >> If that is true, then it is up to you to explain why GC should remain
> >> unsupported by standard C++.
> >
> > That's a _very_ slippery slope. Please explain to me why the following
> > should remain unsupported by standard C++:
> >
> > - A standard graphics library
> > - A standard networking library
> > - Run-time compilation (c.f. Perl's "eval")
> > - etc, etc, etc.
> >
> > (This is, or course, rhetorical).
>
> Each of the questions you raise here seem valid to me; in fact, a standard
> networking (TCP/IP) library was mentioned by Bjarne Stroustrup as one of
> the things that should be in C++Ox.

As I said, the questions were rhetorical. I'm not sure how you managed
to so completely miss my point, which was - as was quite clear from
both the context and what I wrote - that it is not (as you claimed) up
to the original poster to explain why GC should remain unsupported,
but that it was up to you (as a proponent of GC) to explain why is
should be supported.

> > There are a huge number of features that people think would be "good
> > to have" in standard C++. But I would suggest that it is up to the
> > proponent(s) of such features to explain why those features should be
> > supported.
>
> As far as (optional and conservative) GC is concerned, I can see four
> reasons:
>
> (*) It would add support for a commonly used programming style;

So would adding run-time compilation. And I don't see that happening
any time soon.

> (*) It only requires a few small changes to the language spec;

I've seen "a few small changes" take months, even years, to implement
in contexts which are much simpler than the C++ language spec. How
few, and how small?

> (*) The impact on existing code is minimal;

If the impact on existing code is "minimal", as opposed to "none" then
that may well be an obstacle to GC support. There are literally
millions of lines of C++ code out there, and somebody has to pay the
cost of maintainance of that code. "minimal" changes often turn out to
be anything but, and that cost could be considerable.

> (*) There is a substantial amount of prior art in mixing C/C++ with
> conservative GC, showing that it can be done.

There are lots of things that "can be done". That does not, in itself,
mean that we should do them all.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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                       ]

E. Mark Ping wrote:
> In C# there was an attempt to allow deterministic GC by manually
> calling the "Dispose" function, which releases non-memory resources.
> That introduces a whole host of problems

How can having Dispose introduce a whole host of problems?
Are you claiming that programmers should never write code
which releases resources?

---
[ 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                       ]

"Wil Evers" <bouncer@dev.null> wrote in message
news:3da33268$0$4002$e4fe514c@dreader6.news.xs4all.nl...
> In article <3crhewyc.fsf@ender.evo6.com>, Andy Sawyer wrote:
[snip]
> > - A standard graphics library
> > - A standard networking library
> > - Run-time compilation (c.f. Perl's "eval")
> > - etc, etc, etc.
> >
> > (This is, or course, rhetorical).
>
> Each of the questions you raise here seem valid to me; in fact, a standard
> networking (TCP/IP) library was mentioned by Bjarne Stroustrup as one of
> the things that should be in C++Ox.

Is that going to be an IPv6-capable library?  Protocol independant?
UDP as well?

Just how far would it go?

[snip]

Geoff

--
Geoff Field,    Professional geek, amateur stage-levelling gauge.
Spamtraps: geoff_field@suespammers.org, geofffield@hotmail.com or
geoff_field@great-atuin.co.uk; Real Email: gcfield at optusnet dot com dot
au
The suespammers.org mail server is located in California; do not send
unsolicited bulk or commercial e-mail to my suespammers.org address


---
[ 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                       ]

bouncer@dev.null (Wil Evers) wrote in message
news:<3da33bb9$0$33981$e4fe514c@dreader7.news.xs4all.nl>...
> In article <d6651fb6.0210080835.72154a32@posting.google.com>, James
> Kanze wrote:

> > If you need side effects, you almost always need them to occur at a
> > specific time, so destructors of garbage collected objects aren't an
> > appropriate place for them.  Generally speaking, I tend to favor not
> > calling destructors when garbage collecting.

> > The place where this fails is when the garbage collected object
> > contains objects which use non-garbage collected memory
> > (e.g. std::string).  In this case, if the memory isn't garbage
> > collected, then the destructor must be called to free it.

> I seem to be missing something.  Are you suggesting std::string can't
> use garbage-collected memory for its character buffer?

I'm suggesting that most current implementations don't.

I'm also suggesting that if it does, the implementation might have to
provide two versions, because garbage collection will probably be
optional, and std::string must work even if the user chooses to turn it
off.

> When a std::string object becomes unreachable, that simply means one
> less path from the root set to its character buffer.  We don't
> necessarily need a destructor call to tell the garbage collector about
> this; it is able to figure this out by itself.  After the last path to
> the buffer is gone, it can be recycled, just like any other
> heap-allocated object.

This is roughly the way I would like to see garbage collection managed.
No special new, no nothing.  But if an object is unreachable, the system
can reclaim its memory.  Without any further ado.  (Since it is
unreachable, its destructor couldn't otherwise be called, so it
shouldn't be called from garbage collection either.)

But I'm not the only person involved, and I'll have to admit that this
preference is based on gut feeling, and not on any real hands on
experience.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

ron@sensor.com ("Ron Natalie") wrote in message
news:<a_Eo9.265559$F21.39535@fe02>...
> "James Kanze" <kanze@gabi-soft.de> wrote in message
> news:d6651fb6.0210080835.72154a32@posting.google.com...

> > Which means that I couldn't use garbage collected objects with any
> > existing functions.

> Correct, it wouldn't be safe.  How do you know the function wouldn't
> store the pointer in a non-gc pointer.  The GC might then delete it
> while a pointer to it still exists.

> > Intuitively, I tend more toward a new new (gc_new) -- memory allocated
> > with gc_new is garbage collected, memory not allocated with gc_new
> > isn't.  This isn't without problems, though, since...

> How do you find out where pointers might list.  I argue that the sweep
> all data space is NOT a good idea.

But you don't say why?  I can think of some potential reasons (touching
every page in the task image causes thrashing), but they don't seem to
cause problems with current garbage collectors.

In fact, I'm having a hard time figuring out exactly why you are against
garbage collection.

> > If you need side effects, you almost always need them to occur at a
> > specific time, so destructors of garbage collected objects aren't an
> > appropriate place for them.  Generally speaking, I tend to favor not
> > calling destructors when garbage collecting.

> I disagree.  If for example the object is some sort of file stream or
> interface to some graphic widget that involves a system resource being
> freed, having that resource freed when the GC detects the C++ object
> is no longer in use is important.

So what happens if GC never recovers the object?  Garbage collection
normally only happens when you run low on memory -- you could easily
completely run out of open file descriptors without running low on
memory or calling garbage collection.  About all I would consider trying
to do in a destructor called by the garbage collector is error checking;
if an object that was collected had an open file descriptor, I would
close it (better late than never), but I would treat the case as an
error (log it, etc.)

But then, I don't expect garbage collection to solve all my problems.
And I don't want to see it oversold, as was the case with Java.  Recent
versions of the Java runtime, for example, will trigger garbage
collection if they run out of open file descriptors.  IMHO, this is just
hiding an error (and what about other resources?), which, while it may
make things look good short term, has deleterious effects on the quality
of the code long term.

> If destructors aren't called it stabs at the very heart of the C++
> object model.

That depends on the formal description of garbage collection.  And the
formal description of the C++ object model ; even today, I can call the
operator delete function directly, and bypass any destructors.
Formally, all that is really needed is a statement to the effect that
once all pointers to the object in the task image have ceased to exist,
any further access to the object is undefined behavior.  Conceptually,
you have infinite memory, but you allow the system to reuse any memory
that is no longer accessible.  (With this model, of course, calling the
destructor would be undefined behavior, since it involves accessing the
object.  But the standard could easily make an exception.)

What I'd really like to see is some concrete experience.  Garbage
collectors exist for C++, but they don't seem to be heavily used.

Generally, they add the restriction that you can't "hide" a pointer and
expect to use it later.  Does this cause any problems in real programs?
Intuitively, I doubt it, but it would be nice if some concrete
experience confirmed my suspicions.

The existing garbage collectors have an option as to whether to call
destructors or not.  Do actual programs have problems one way or the
other, or is it completely irrelevant?  Again, my gut fealing is that
destructors shouldn't be called, but my gut fealing is no substitute for
actual hands on experience.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

hyrosen@mail.com (Hyman Rosen) wrote in message
news:<1034106575.731201@master.nyc.kbcfp.com>...
> James Kanze wrote:
> > It makes it easier.  For example, without garbage collection, you
> > typically need several types of pointers.  With garbage collection,
> > you will need less, and the type of the pointer will almost always
> > be evident from the semantics -- no need to worry about breaking
> > cycles, for example.

> Hasn't the Java experience shown differently? In recent versions of
> the language, they've introduced several kinds of weak pointers that
> don't count the same as ordinary pointers for GC purposes.  This is
> because it's quite easy to leave references to memory lying around
> even though the program will never use that memory again - after all,
> not cleaning up memory after being done with it is what GC is supposed
> to buy.

I'm not sure to what degree the Java experience is relevant to C++.  My
impression is that the new types of pointers (sorry, references) were
added to hide previous design errors, more than for any other
reasons:-).

One thing that is clear from the Java experience, however, is that user
code must have some means of interacting with the garbage collector.
While I don't think that weak pointers are the way to go, a large map or
similar data structure should have some way of being informed that more
memory is needed, so that it could eventually clean out entries no
longer needed.  Although I fear that even this feature would be
overused.  (Normally, the program should make some general assumptions
about how much resources it wants to use, and take steps that the map
doesn't grow to extend beyond this.)

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

> >     I write tons of C++ code, using average one 'delete' per 10000
> > lines of code (with no memory leaks). What is GC usefull for then ?
>
> It makes it easier.  For example, without garbage collection, you
> typically need several types of pointers.

    You rather need to use containers. I think this is common problem - most
of "smart pointers" are hidden containers. If you use pointers just to point
to things rather than to hold data, you end up using simple raw pointers
and/or some form of "strong" pointers in case of unclear object lifetimes
(to avoid dangling pointers).

> With garbage collection, you
> will need less, and the type of the pointer will almost always be
> evident from the semantics -- no need to worry about breaking cycles,
> for example.

    I think that implementing GC into C++ core language would end in much
more types of pointers.
I also think that GC will never work well with destructor idea - it is
complement view of problem. And, while GC may take care about memory
resources, destructors take care about all kinds of resources plus they do
it synchronously - two things you never get from GC.

    Well, there may be rare situations when GC would serve better. As far as
I know, it is impossible to add GC to C++ without marking GC collected
pointers and objects - otherwise it would completely break compatibility. At
this level there is no difference between writing

gc_ptr<Something> x = gc_new Something;

from any other form (with slight ugliness of gc_new being macro). And above
can be rather effectively managed by library. Sure, they may be performance
impact between this and GC build in language core, but that may be
negligible (I volunteer to build such GC library and find out :).

(Let me notice that I am not speaking here about any ref-counted "semi-GC"
or any conservative "I will release *almost*all* unused memory" solutions,
but full mark-and-sweep GC).

Mirek



---
[ 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                       ]

Geoff Field wrote:
>
> "Wil Evers" <bouncer@dev.null> wrote in message
> news:3da33268$0$4002$e4fe514c@dreader6.news.xs4all.nl...
> > In article <3crhewyc.fsf@ender.evo6.com>, Andy Sawyer wrote:
> [snip]
> > > - A standard graphics library
> > > - A standard networking library
> > > - Run-time compilation (c.f. Perl's "eval")
> > > - etc, etc, etc.
> > >
> > > (This is, or course, rhetorical).
> >
> > Each of the questions you raise here seem valid to me; in fact, a standard
> > networking (TCP/IP) library was mentioned by Bjarne Stroustrup as one of
> > the things that should be in C++Ox.
>
> Is that going to be an IPv6-capable library?  Protocol independant?
> UDP as well?
>
> Just how far would it go?
>

Nowhere, yet. Don't confuse "it might be nice to add" with "we're going
to add."

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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                       ]

emarkp@CSUA.Berkeley.EDU (E. Mark Ping) wrote in message
news:<anv7ha$vv1$1@agate.berkeley.edu>...
> In article <d6651fb6.0210080845.21a8265e@posting.google.com>,
> James Kanze <kanze@gabi-soft.de> wrote:
> >emarkp@CSUA.Berkeley.EDU (E. Mark Ping) wrote in message
> >news:<ansjtp$7ta$1@agate.berkeley.edu>...
> >> 2) The example above (and all circular references) are design errors.

> >A double linked list is a design error?

> Okay, that's a pretty good counterexample. :)

> Seriously, it's a clue as to how much I use the STL that I don't think
> about the implementaiton of a doubly-linked-list.

I think that the problem is present in any number of graph structures.

> In my own work (and I elaborated on that later in the post) I
> differentiate between owners and non-owners, where owners are
> responsible for resource management and non-owners aren't.  (Of
> course, an owner of one resource might be a non-owner of another.)
> Owners hold their resources with smart pointers, or manage them
> manually.  Non-owners have no business doing either.

I've generally done something similar.  Except that non-owners use smart
pointers too -- smart pointers which are automatically set to null when
the object is deleted.  It's almost always worked for me.  (I had one
problem with it in my last project.)  But all this means is that graph
structures don't occur in the domains I work in.  (That's not actually
true, but the objects in the graph structures are always "owned"
externally to the structure.  Also, in a number of applications, most of
the entity objects had defined lifetimes -- they were created and
destroyed as a result of external events.  In this case, there are no
owning objects, and the destruction is almost always a "delete this".)

> Hence in the doubly-linked-list example, the nodes are non-owners.
> The collection object is not the owner.  And the nodes are held
> together with pointers that the collection object manages.  Now that I
> think about that one more carefully, the distinction seems more
> artificial than I thought before.

The double linked list is a classical example where the distinction
doesn't work directly for memory management.  In a real sense, the list
is the owner of its nodes -- the neighboring nodes certainly aren't
owners.  But the list doesn't have pointers to the nodes.

The problem is trivial to solve for the double linked list; all it takes
is a bit of extra logic in the list class (once).  I'm less sure about
more complicated graph structures.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

>> If destructors aren't called it stabs at the very heart of the C++
>> object model.
>
>That depends on the formal description of garbage collection.  And the
>formal description of the C++ object model ; even today, I can call the
>operator delete function directly, and bypass any destructors.
>Formally, all that is really needed is a statement to the effect that
>once all pointers to the object in the task image have ceased to exist,
>any further access to the object is undefined behavior.  Conceptually,
>you have infinite memory, but you allow the system to reuse any memory
>that is no longer accessible.  (With this model, of course, calling the
>destructor would be undefined behavior, since it involves accessing the
>object.  But the standard could easily make an exception.)

    But in case you do not call destructors, you cannot contain non-GC based
variables in GC managed structs. Consider this:

struct Foo {
    std::string bar; // not GC managed
};

gc_ptr<Foo> q = gc_new Foo;//or any other GC-optional syntax

If Foo gets collected and ~Foo() is not called, this results in memory leak,
as bar's destructor is not called and bar's internal data not released !

Mirek


---
[ 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                       ]

In article <1034168823.946525@master.nyc.kbcfp.com>,
Hyman Rosen <hyrosen@mail.com> wrote:
>E. Mark Ping wrote:
>> In C# there was an attempt to allow deterministic GC by manually
>> calling the "Dispose" function, which releases non-memory resources.
>> That introduces a whole host of problems
>
>How can having Dispose introduce a whole host of problems?
>Are you claiming that programmers should never write code
>which releases resources?

Sigh.  Clearly you didn't read the links I put in the post.

Having user-called Dispose means that you can have a reachable object
which is already disposed.  It also means that you must determine on a
per-object basis whether it has been disposed or not.  Additionally,
you must be able to handle the situation in which the object was *not*
manually disposed, but was disposed by the GC--when (in the case of
NDGC) you can't refer to other objects, because they might have
already been GC'd.  Lastly, you have to avoid disposing twice (this is
probably the least of the issues IMO).  Oh, and in C# you have to make
sure this is all thread-safe.  Now, the examples in the C#
documentation get most of this right, but I recall seeing a few
different examples of how to do Dispose(), and some showed more of the
steps than others, and none of them mentioned thread-safety.

The model in C++ is that you manage all resources.  Auto-objects have
a clearly defined lifetime which can help a lot in managing the
resources.  Libraries can be used to simplify the process.  In .Net,
you have GC, except when you don't (sort of), and when you don't, it's
a hassle, requires a *lot* of repeated code, and the examples are
wrong to various degrees.
--
Mark Ping
emarkp@soda.CSUA.Berkeley.EDU

---
[ 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                       ]

geoff_field@suespammers.org ("Geoff Field") wrote
> "Wil Evers" <bouncer@dev.null> wrote
> > a standard
> > networking (TCP/IP) library was mentioned by Bjarne Stroustrup as one of
> > the things that should be in C++Ox.
>
> Is that going to be an IPv6-capable library?  Protocol independant?
> UDP as well?
>
> Just how far would it go?

Start by merging common implementations of sockets and/or winsock.
Remove anything specific to certain platforms or vendors, such as
window handles. What's left is your first approximation.

---
[ 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                       ]

In article <it0cs30y.fsf@ender.evo6.com>, Andy Sawyer wrote:

> bouncer@dev.null (Wil Evers) writes:
>
>> In article <3crhewyc.fsf@ender.evo6.com>, Andy Sawyer wrote:
>>
>> > That's a _very_ slippery slope. Please explain to me why the following
>> > should remain unsupported by standard C++:
>> >
>> > - A standard graphics library
>> > - A standard networking library
>> > - Run-time compilation (c.f. Perl's "eval")
>> > - etc, etc, etc.
>> >
>> > (This is, or course, rhetorical).
>>
>> Each of the questions you raise here seem valid to me; in fact, a
>> standard networking (TCP/IP) library was mentioned by Bjarne Stroustrup
>> as one of the things that should be in C++Ox.
>
> As I said, the questions were rhetorical. I'm not sure how you managed
> to so completely miss my point, which was - as was quite clear from
> both the context and what I wrote - that it is not (as you claimed) up
> to the original poster to explain why GC should remain unsupported,
> but that it was up to you (as a proponent of GC) to explain why is
> should be supported.

I don't believe I missed your point; maybe we just don't agree.  As far as
I'm concerned, C++ exists to serve its users.  From a user's perspective,
it is quite natural to wonder why C++ doesn't have a standard graphics
library, a standard networking library, or run-time compilation.

Obviously, that doesn't mean there aren't any valid reasons why a certain
feature should, perhaps just for now, be left out: its consequences may not
be sufficiently clear, it may be inconsistent with the rest of the
language, difficult or impossible to implement, or the committee's agenda
could simply be overloaded.

When discussing the pros and cons of a specific language feature, it helps
to be explicit about such issues.

>> > There are a huge number of features that people think would be "good
>> > to have" in standard C++. But I would suggest that it is up to the
>> > proponent(s) of such features to explain why those features should be
>> > supported.
>>
>> As far as (optional and conservative) GC is concerned, I can see four
>> reasons:
>>
>> (*) It would add support for a commonly used programming style;
>
> So would adding run-time compilation. And I don't see that happening
> any time soon.

Perhaps, but I don't see what that has to do with GC.

>> (*) It only requires a few small changes to the language spec;
>
> I've seen "a few small changes" take months, even years, to implement
> in contexts which are much simpler than the C++ language spec. How
> few, and how small?

As far as I can see, there isn't really that much to implement.  To
'legalize' the Boehm collector, some wording that forbids the use of
disguised pointers to heap objects would have to be added to the standard.
Elsewhere in this thread, James Kanze wrote:

        Formally, all that is really needed is a statement to the effect
        that once all pointers to the object in the task image have
        ceased to exist, any further access to the object is undefined
        behavior.

That sounds like a good start to me.

>> (*) The impact on existing code is minimal;
>
> If the impact on existing code is "minimal", as opposed to "none" then
> that may well be an obstacle to GC support. There are literally
> millions of lines of C++ code out there, and somebody has to pay the
> cost of maintainance of that code. "minimal" changes often turn out to
> be anything but, and that cost could be considerable.

Which is one of the reasons why it is often said that GC in C++ should be
optional.  Almost all code will survive, but if you do have any code that
breaks the rules, and you can't or don't want to fix it, you can simply
disable the collector.

>> (*) There is a substantial amount of prior art in mixing C/C++ with
>> conservative GC, showing that it can be done.
>
> There are lots of things that "can be done". That does not, in itself,
> mean that we should do them all.

Right.  New features should only be added because of their benefits.

Regards,

- Wil

--
Wil Evers, DOOSYS R&D, Utrecht, Holland
[wil underscore evers at doosys dot com]

---
[ 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                       ]

"Wil Evers" <bouncer@dev.null> wrote in message
news:3da548a4$0$4002$e4fe514c@dreader6.news.xs4all.nl...
> In article <it0cs30y.fsf@ender.evo6.com>, Andy Sawyer wrote:
>
> > bouncer@dev.null (Wil Evers) writes:
> >
> >> In article <3crhewyc.fsf@ender.evo6.com>, Andy Sawyer wrote:
> >>
> >> > That's a _very_ slippery slope. Please explain to me why the
following
> >> > should remain unsupported by standard C++:
> >> >
> >> > - A standard graphics library
> >> > - A standard networking library
> >> > - Run-time compilation (c.f. Perl's "eval")
> >> > - etc, etc, etc.
> >> >
> >> > (This is, or course, rhetorical).
> >>
> >> Each of the questions you raise here seem valid to me; in fact, a
> >> standard networking (TCP/IP) library was mentioned by Bjarne Stroustrup
> >> as one of the things that should be in C++Ox.
> >
> > As I said, the questions were rhetorical. I'm not sure how you managed
> > to so completely miss my point, which was - as was quite clear from
> > both the context and what I wrote - that it is not (as you claimed) up
> > to the original poster to explain why GC should remain unsupported,
> > but that it was up to you (as a proponent of GC) to explain why is
> > should be supported.
>
> I don't believe I missed your point; maybe we just don't agree.  As far as
> I'm concerned, C++ exists to serve its users.  From a user's perspective,
> it is quite natural to wonder why C++ doesn't have a standard graphics
> library, a standard networking library, or run-time compilation.
>
> Obviously, that doesn't mean there aren't any valid reasons why a certain
> feature should, perhaps just for now, be left out: its consequences may
not
> be sufficiently clear, it may be inconsistent with the rest of the
> language, difficult or impossible to implement, or the committee's agenda
> could simply be overloaded.
>
> When discussing the pros and cons of a specific language feature, it helps
> to be explicit about such issues.
>
> >> > There are a huge number of features that people think would be "good
> >> > to have" in standard C++. But I would suggest that it is up to the
> >> > proponent(s) of such features to explain why those features should be
> >> > supported.
> >>
> >> As far as (optional and conservative) GC is concerned, I can see four
> >> reasons:
> >>
> >> (*) It would add support for a commonly used programming style;
> >
> > So would adding run-time compilation. And I don't see that happening
> > any time soon.
>
> Perhaps, but I don't see what that has to do with GC.
>
> >> (*) It only requires a few small changes to the language spec;
> >
> > I've seen "a few small changes" take months, even years, to implement
> > in contexts which are much simpler than the C++ language spec. How
> > few, and how small?
>
> As far as I can see, there isn't really that much to implement.  To
> 'legalize' the Boehm collector, some wording that forbids the use of
> disguised pointers to heap objects would have to be added to the standard.
> Elsewhere in this thread, James Kanze wrote:
>
>         Formally, all that is really needed is a statement to the effect
>         that once all pointers to the object in the task image have
>         ceased to exist, any further access to the object is undefined
>         behavior.
>
> That sounds like a good start to me.

Sounds like a terrible place to start to me.

My company uses a huge amount of legacy code which includes many old C
pointer tricks including the xor trick in doubly linked lists and many other
places where pointers are contained in ints for various reasons. This code
is very heavily used through out several large projects and cannot be simply
or easily changed. A compiler which supports that paragraph would never be
purchased by my company.

Ken Shaw



---
[ 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                       ]

cxl@centrum.cz ("Mirek Fidler") wrote in message
news:<ao27n3$20q7$1@news.vol.cz>...
> >> If destructors aren't called it stabs at the very heart of the C++
> >> object model.

> >That depends on the formal description of garbage collection.  And
> >the formal description of the C++ object model ; even today, I can
> >call the operator delete function directly, and bypass any
> >destructors.  Formally, all that is really needed is a statement to
> >the effect that once all pointers to the object in the task image
> >have ceased to exist, any further access to the object is undefined
> >behavior.  Conceptually, you have infinite memory, but you allow the
> >system to reuse any memory that is no longer accessible.  (With this
> >model, of course, calling the destructor would be undefined behavior,
> >since it involves accessing the object.  But the standard could
> >easily make an exception.)

>     But in case you do not call destructors, you cannot contain non-GC
> based variables in GC managed structs. Consider this:

> struct Foo {
>     std::string bar; // not GC managed
> };

> gc_ptr<Foo> q = gc_new Foo;//or any other GC-optional syntax

> If Foo gets collected and ~Foo() is not called, this results in memory
> leak, as bar's destructor is not called and bar's internal data not
> released !

That depends on the model of GC adopted.

I see three large possibilities:

  - a pointer attribute -- only certain pointers are taken into
    consideration,

  - a special new -- only objects allocated with the garbage collected
    new can be collected, and

  - a simple rule which says that it is undefined behavior if you try to
    access an object after a time when there has been no legal pointer
    to it in the program.

In the last case, there is no problem.  The memory allocated by string
gets garbage collected.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

hyrosen@mail.com (Hyman Rosen) wrote in message
news:<1034168823.946525@master.nyc.kbcfp.com>...
> E. Mark Ping wrote:
> > In C# there was an attempt to allow deterministic GC by manually
> > calling the "Dispose" function, which releases non-memory resources.
> > That introduces a whole host of problems

> How can having Dispose introduce a whole host of problems?  Are you
> claiming that programmers should never write code which releases
> resources?

I'm not sure, but if C# uses reference semantics, like Java, you need
something (which Java doesn't have).

One essential criteron for garbage collection in C++, I think, is that
it have no effect on local variables.  And the the delete operator still
work as it currently does.  All current C++ programs which don't "hide"
pointers to life objects still work, exactly as they currently work.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

Francis Glassborow wrote:

> In article <anu9rb$hko62$2@ID-32913.news.dfncis.de>, Nicola Musatti
> <Nicola.Musatti@ObjectWay.it> writes
>
>> What is wrong with library based garbage  collection, as opposed
>> to having it directly supported by the core language?
>
> I think that it relies on a degree of self discipline that is fine with
> wide awake and competent programmers but that may be absent when tired,
> rushed to finish or lacking as much expertise as one thinks one has.

Yet no more than is currently required to program C++. I believe it
wouldn't be much different than with pointers vs. smart pointers.

> It also has problems with retrofitting. For example, how does a library
> solution allow me to have a GCed int?

If you expect to write something like:

gc int i = 5;

I agree that it's not possible without resorting to preprocessing.
Personally I'd be more than happy with

int * i = new(gc) int(5);

> Perhaps there are solutions, but I think that we should look for a clean
> simple core solution with as much automatic application as possible.

I don't agree. You may be able to come out with a syntax that is very
simple when considered in isolation. The need to explicitly manage the
interaction between gc'ed and non gc'ed objects will make this
simplicity misleading.

Cheers,
Nicola Musatti

---
[ 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                       ]

Mirek Fidler wrote:
>>>If destructors aren't called it stabs at the very heart of the C++
>>>object model.
>>
>>That depends on the formal description of garbage collection.  And the
>>formal description of the C++ object model ; even today, I can call the
>>operator delete function directly, and bypass any destructors.
>>Formally, all that is really needed is a statement to the effect that
>>once all pointers to the object in the task image have ceased to exist,
>>any further access to the object is undefined behavior.  Conceptually,
>>you have infinite memory, but you allow the system to reuse any memory
>>that is no longer accessible.  (With this model, of course, calling the
>>destructor would be undefined behavior, since it involves accessing the
>>object.  But the standard could easily make an exception.)
>
>
>     But in case you do not call destructors, you cannot contain non-GC based
> variables in GC managed structs. Consider this:
>
> struct Foo {
>     std::string bar; // not GC managed
> };
>
> gc_ptr<Foo> q = gc_new Foo;//or any other GC-optional syntax
>
> If Foo gets collected and ~Foo() is not called, this results in memory leak,
> as bar's destructor is not called and bar's internal data not released !

If you decide not to call destructors for garbage collected objects,
then there is no point in having special gc_ptr. And then since all heap
objects can be garbage collected, you do not have memory leaks either.

---
[ 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                       ]

cxl@centrum.cz ("Mirek Fidler") wrote in message
news:<ao1to3$17gl$1@news.vol.cz>...
> > >     I write tons of C++ code, using average one 'delete' per 10000
> > > lines of code (with no memory leaks). What is GC usefull for then
> > > ?

> > It makes it easier.  For example, without garbage collection, you
> > typically need several types of pointers.

>     You rather need to use containers.

What is the relationship between containers, and navigation?

> I think this is common problem - most of "smart pointers" are hidden
> containers.

Not at all.

> If you use pointers just to point to things rather than to hold data,
> you end up using simple raw pointers and/or some form of "strong"
> pointers in case of unclear object lifetimes (to avoid dangling
> pointers).

If you use pointers just to point to things, you end up with a large
number of different strong pointer types, because ownership patterns
vary.

> > With garbage collection, you will need less, and the type of the
> > pointer will almost always be evident from the semantics -- no need
> > to worry about breaking cycles, for example.

>     I think that implementing GC into C++ core language would end in
> much more types of pointers.

Why?

> I also think that GC will never work well with destructor idea - it is
> complement view of problem.

The two ideas are orthogonal.  There are a lot of classes which either
don't have destructors (e.g. complex), or only have them in order to
manage memory (e.g. string).  There are also a number of classes which
use destructors to manage resources other than memory.  Most of the
time, these end up being used as local variables, so garbage collection
doesn't change a thing.  Occasionally, you need explicit control of the
lifetime, so you use new and delete.  There, too, garbage collection
doesn't change a thing, since even with garbage collection, delete
should work, and should call the destructor.  Finally, you have some
large scale classes where the destructor may have some real semantics --
sending notifications, if nothing else.  These classes would also be
handled as they are currently.  (In my code, most of these classes
terminate their life by means of a "delete this".)

> And, while GC may take care about memory resources, destructors take
> care about all kinds of resources plus they do it synchronously - two
> things you never get from GC.

Garbage collection only solves one problem.  That's sure.  It doesn't
claim to solve any more.  And it only solves it partially, at that.

On the other hand, solving the problem without garbage collection means
more code must be written, which increases the risk of errors, and the
time it takes to develop software.

So the most accurate description of garbage collection wouldn't even be
that it takes care of memory resources.  The correct description is that
it makes it easier for the programmer (less code, less development time)
to take care of memory resources.

If programmer time is a free resource in your environment, you don't
need garbage collection.  Because frankly, if your organization can't
write a correct program without garbage collection, it won't be able to
write one with garbage collection.  On the other hand, if it can develop
correct programs without garbage collection, it can do so more cheaply
and more quickly with garbage collection.

>     Well, there may be rare situations when GC would serve better. As
> far as I know, it is impossible to add GC to C++ without marking GC
> collected pointers and objects - otherwise it would completely break
> compatibility.

The current implementations don't do this.  If you do mark pointers in
some way, you have a larger set of options with regards to implementing
garbage collection, but collectors exist, and are used, which don't
require this.

> At this level there is no difference between writing

> gc_ptr<Something> x = gc_new Something;

> from any other form (with slight ugliness of gc_new being macro). And
> above can be rather effectively managed by library. Sure, they may be
> performance impact between this and GC build in language core, but
> that may be negligible (I volunteer to build such GC library and find
> out :).

Be sure to compare it to the Boehm collector (existing practice which
doesn't require any markers in the source code).

> (Let me notice that I am not speaking here about any ref-counted
> "semi-GC" or any conservative "I will release *almost*all* unused
> memory" solutions, but full mark-and-sweep GC).

So what's the point.  The standard may add garbage collection.  It might
even define some semantics for it.  But it certainly won't impose any
implementation, and I can't imagine a quality implementation using "full
mark-and-sweep" (whatever that is); I suspect that some sort of
generational collector would be most appropriate for most applications,
with the option of dropping in a real time collector if neeed (and
getting guaranteed response times, something not possible with the
current new and delete operators).

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

emarkp@CSUA.Berkeley.EDU (E. Mark Ping) wrote in message
news:<ao27uk$1sdr$1@agate.berkeley.edu>...
> In article <1034168823.946525@master.nyc.kbcfp.com>,
> Hyman Rosen <hyrosen@mail.com> wrote:
> >E. Mark Ping wrote:
> >> In C# there was an attempt to allow deterministic GC by manually
> >> calling the "Dispose" function, which releases non-memory
> >> resources.  That introduces a whole host of problems

> >How can having Dispose introduce a whole host of problems?  Are you
> >claiming that programmers should never write code which releases
> >resources?

> Sigh.  Clearly you didn't read the links I put in the post.

> Having user-called Dispose means that you can have a reachable object
> which is already disposed.

So.  The current situation is that you can have a pointer to an object
which has not only been "disposed" (whose destructor has been called),
but whose memory has been freed.  Which is even worse.

> It also means that you must determine on a per-object basis whether it
> has been disposed or not.  Additionally, you must be able to handle
> the situation in which the object was *not* manually disposed, but was
> disposed by the GC--when (in the case of NDGC) you can't refer to
> other objects, because they might have already been GC'd.  Lastly, you
> have to avoid disposing twice (this is probably the least of the
> issues IMO).  Oh, and in C# you have to make sure this is all
> thread-safe.  Now, the examples in the C# documentation get most of
> this right, but I recall seeing a few different examples of how to do
> Dispose(), and some showed more of the steps than others, and none of
> them mentioned thread-safety.

It's not a simple solution.  Garbage collection helps here, since at
least the object's memory is still there -- if nothing else, you can set
a flag, which is tested on entry of each function.  (This is sort of
like closing a filebuf, or ?)

Saying that garbage collection doesn't solve all problems, or that you
can still write incorrect programs with it, isn't really an argument
against it.  After all, addition doesn't solve all problems either, and
you can certainly write incorrect programs using it, but no one is
saying that we shouldn't have it.

And whatever else, C# at least deserves credit for addressing the
problem, rather than trying to pretend that it doesn't exist, as in
Java.

> The model in C++ is that you manage all resources.

The thing that makes C++ the language that it is is that it doesn't
impose a model.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

James Kanze wrote:

> cxl@centrum.cz ("Mirek Fidler") wrote
> >    But in case you do not call destructors, you cannot contain non-GC
> >based variables in GC managed structs. Consider this:
>
> >struct Foo {
> >    std::string bar; // not GC managed
> >};
>
> >gc_ptr q = gc_new Foo;//or any other GC-optional syntax
>
> >If Foo gets collected and ~Foo() is not called, this results in memory
> >leak, as bar's destructor is not called and bar's internal data not
> >released !
>
> That depends on the model of GC adopted.


Once again, I point out that my model of separate reachable finalizers
fits this scenario perfectly:

struct string_releaser : public GC_finalizer
{
 string_releaser(string &victim) : victim(victim) { }
 void finalize() { victim.~string(); }
 string &victim;
};

gc_ptr q = gc_new Foo;
gc_register_finalizer(q, new string_releaser(q->bar));

---
[ 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                       ]

In article <ao49in$irt@dispatch.concentric.net>, Ken Shaw wrote:

> My company uses a huge amount of legacy code which includes many old C
> pointer tricks including the xor trick in doubly linked lists and many
> other places where pointers are contained in ints for various reasons.

Boy, that sounds like a mess.  I wouldn't be my company's future on it.

> This code is very heavily used through out several large projects and
> cannot be simply or easily changed.

Why?

> A compiler which supports that paragraph would never be purchased by
> my company.

Not even if you can switch off the collector and get back the old behavior?

- Wil

--
Wil Evers, DOOSYS R&D, Utrecht, Holland
[wil underscore evers at doosys dot com]

---
[ 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                       ]

> "Wil Evers" <bouncer@dev.null> wrote
> > As a C++ user, I'd like to know if the committee is considering (optional)
> > garbage collection for the next version of the C++ standard.

ron@sensor.com ("Ron Natalie") wrote
> I hope not.   Do you have a clue as to what this would mean?

With a tiny amount of language support, what we currently call GC could
be done much more efficiently than any third-party tool could ever hope to
(no scans needed) and also deterministically (as soon as the last
pointer is released, the delete happens), and the destructors could even
be executed at that time -- without needing Java's
"finally" block or anything similar.

All the compiler would have to do, is create the equivalent of a
"smart pointer" instead of a raw pointer. Currently, every object on
the heap maintains a size parameter somewhere internally; now it would
also have to maintain a reference count. The "smart pointer" would know
how to increment and decrement this count, and also how to call the
destructor. The smart pointer would also be able to differentiate
between items on the heap, and all other items.

Compilers would have to be able to turn this option off, for two
reasons:
(1) Code that uses this pseudo-GC would not mix well with code that does
    not -- such as legacy object libraries, or code compiled in other
    languages. We would need to turn it off for projects that use them.
(2) There might be a tiny performance hit. It wouldn't affect most
    business applications, but some real-time code (and some code compiled
    by people with a knee-jerk reaction against this whole idea) would
    need to disable it.

On the other hand, I don't think that you need any changes to the
standard to support this today. AFAIK, the current standard says only
that a pointer "points" to an object; there is no requirement that it
must literally contain a machine address. The null pointer is NOT an
exception in this regard; 3.9.2/3 says:
    The value representation of pointer types is
    implementation-defined.
This also means that pointers could contain the index of a relocatable
block, which would allow the run-time engine to reposition those blocks
and still keep pointers valid... Possibly useless on a virtual-memory
machine, but very useful on limited-memory computers such as embedded
processors.

---
[ 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                       ]

"Allan W" <allan_w@my-dejanews.com> wrote in message news:7f2735a5.0210041157.565e75eb@posting.google.com...
> > "Wil Evers" <bouncer@dev.null> wrote
> > > As a C++ user, I'd like to know if the committee is considering (optional)
> > > garbage collection for the next version of the C++ standard.
>
> ron@sensor.com ("Ron Natalie") wrote
> > I hope not.   Do you have a clue as to what this would mean?
>
>
> All the compiler would have to do, is create the equivalent of a
> "smart pointer" instead of a raw pointer.

This is in fact not really garbage collection, and not what bouncer was
suggesting.   It's an interesting idea though.  I'm not overly found of the
mark and sweep methodology.   They either so conservative to be useless
or not rigorous enough to work properly.



---
[ 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                       ]

Allan W wrote:
 > now it would also have to maintain a reference count

But reference counts are insufficient for full GC:

struct me { me *p; me() : p(this) { } };
int main() { for (;;) new me; }

With real GC, this program happily runs forever.
With reference counting, it consumes all memory.

---
[ 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                       ]

Hyman Rosen wrote:

> Allan W wrote:
>  > now it would also have to maintain a reference count
>
> But reference counts are insufficient for full GC:
>
> struct me { me *p; me() : p(this) { } };
> int main() { for (;;) new me; }
>
> With real GC, this program happily runs forever.
> With reference counting, it consumes all memory.

I have implemented my own version of reference
counted pointer -- have a different syntax, and will
run forever with your example:
   struct me {
        typical struct or class construct
   };

  int main()
  {
      for (;;) {
          ref_ptr<me>  me_ptr(new me);
      }
   }

It's not GC, but works on GCC, though. ;-)

I don't think GC should be included in the
standard either.

Shao

---
[ 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                       ]

In article <5Qkn9.9915$Jw5.5573@fe04>, Ron Natalie wrote:

> "Wil Evers" <bouncer@dev.null> wrote in message
> news:1033738582.360852@news.knoware.nl...
>
>>  If a few minor restrictions on the use of pointers were added to the
>> standard, this would become a legal thing to do in C++.  IMHO, we should
>> think of this as simply following existing practice.
>
> How is it following existing practice if you change the rules from the way
> things are now?

Conservative collectors forbid the use of 'disguised' pointers to
heap-allocated objects.  For example, you can't write a pointer to a file,
read it back later and expect the object it points to will still be there,
or use the exclusive-or trick to save a few bytes in the nodes of a doubly
linked list.

These restrictions apply to today's C++ when used in combination with a
conservative collector, and seem to cause very few problems.

- Wil

--
Wil Evers, DOOSYS R&D, Utrecht, Holland
[wil underscore evers at doosys dot com]

---
[ 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                       ]

In article <d6651fb6.0210040344.1cc219be@posting.google.com>, James Kanze
wrote:

> bouncer@dev.null (Wil Evers) wrote in message
> news:<3d9b5098$0$16211$e4fe514c@dreader7.news.xs4all.nl>...
>
>> As a C++ user, I'd like to know if the committee is considering
>> (optional) garbage collection for the next version of the C++
>> standard.
>
> They were supposed to consider it for the original version.  It was
> mentionned, along with templates and exceptions, in the list of
> essential extensions for the language.

Does that mean it is not on the agenda for C++0x?

Thanks,

- Wil

--
Wil Evers, DOOSYS R&D, Utrecht, Holland
[wil underscore evers at doosys dot com]

---
[ 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                       ]

In article <1033765572.863382@master.nyc.kbcfp.com>, Hyman Rosen
<hyrosen@mail.com> writes
>Allan W wrote:
>> now it would also have to maintain a reference count
>
>But reference counts are insufficient for full GC:
>
>struct me { me *p; me() : p(this) { } };
>int main() { for (;;) new me; }
>
>With real GC, this program happily runs forever.
>With reference counting, it consumes all memory.

Perhaps we need to leave all existing mechanisms in place and add a
quite separate facility by providing a garbage collection type. I am
thinking about something such as a new fundamental pointer/reference
like feature. Let me use an @ for now:

inr@ i_gc;

declares an entity that can only be initialised with a dynamic instance
and can only be bound to other gc types so that:

int i;
i_gc = new int; // OK
int@ j_gc = i_gc; // OK
j_hc = new int; // now it has its own
int& i_ref = i_gc; // fails

void foo(int@);

foo(i); // fails
foo(&i); // fails
foo(i_gc); //OK

I have no idea whether this idea can be fleshed out to be useful. Think
of it as a builtin GC smart reference like thing with semantics somewhat
like Java's variables of object or array type.



--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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                       ]

> If not, why not?

    Perhaps because in well written C++ code (using RAII idiom) they are
almost useless...

    I write tons of C++ code, using average one 'delete' per 10000 lines of
code (with no memory leaks). What is GC usefull for then ?

Mirek


---
[ 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                       ]

Allan W wrote:

>> "Wil Evers" <bouncer@dev.null> wrote
>> > As a C++ user, I'd like to know if the committee is considering
>> > (optional) garbage collection for the next version of the C++ standard.
>
> ron@sensor.com ("Ron Natalie") wrote
>> I hope not.   Do you have a clue as to what this would mean?
>
> With a tiny amount of language support, what we currently call GC could
> be done much more efficiently than any third-party tool could ever hope to
> (no scans needed) and also deterministically (as soon as the last
> pointer is released, the delete happens), and the destructors could even
> be executed at that time -- without needing Java's
> "finally" block or anything similar.

Against full reference count implementation, like you suggest, a
conservative GC will probably win measured by CPU time. Just reference
counting is not a good replacement for GC. The per-pointer overhead for
reference counting is quite a show-stopper.

Another prerequisite for automatically calling destructors is a minimal form
of type reflection available at runtime, for all kinds of types, e.g. int,
char, classes, etc. Howto get that into C++ without turning it all over, or
introducing even more overhead? This is not an easy thing.

Bernd Strieder

---
[ 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                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message news:fxNiIxA1bVo9Ew8$@robinton.demon.co.uk...
> > Perhaps we need to leave all existing mechanisms in place and add a
> quite separate facility by providing a garbage collection type. I am
> thinking about something such as a new fundamental pointer/reference
> like feature. Let me use an @ for now:
>
> inr@ i_gc;
>

Actually, all you really need is a GC qualifier.

gc int* i_gc;

You could convert a non-gc qualified pointer to a gc one but not vice-versa.
The GC would be have smart enough not to gag on any non-gc pointers
provided (which shouldn't be hard).   This provides the minimal code impact
and could support either a reference-counted or mark-and-sweep internal
representation.   A non gc-qualified pointer would work normally with no
performance loss.   In a reference-counted style, the modification of the
pointer would be possibly less efficient if the modification involves hitting
the reference counter.   In a mark-and-sweep style system, the pointers that
needed to be examined would be clearly specified without having to worry
about aliasing with other pieces of memory.

Of course in either case, the system could (and really must) support  destructor
invocation on the collected memory.   Much of what I can invision using this
for has some side effect in the destructor that I would need to have.



---
[ 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                       ]

bouncer@dev.null (Wil Evers) wrote in message
news:<3da08b1b$0$9984$e4fe514c@dreader6.news.xs4all.nl>...
> In article <d6651fb6.0210040344.1cc219be@posting.google.com>, James
> Kanze wrote:
> > bouncer@dev.null (Wil Evers) wrote in message
> > news:<3d9b5098$0$16211$e4fe514c@dreader7.news.xs4all.nl>...

> >> As a C++ user, I'd like to know if the committee is considering
> >> (optional) garbage collection for the next version of the C++
> >> standard.

> > They were supposed to consider it for the original version.  It was
> > mentionned, along with templates and exceptions, in the list of
> > essential extensions for the language.

> Does that mean it is not on the agenda for C++0x?

I have no idea.

In fact, it never got on the agenda for C++98.  I think there was a
proposal at one point, but it occured too late to be really considered,
and the authors withdrew it.  I would presume that this proposal would
at least be discussed for C++0x, but for the moment, I don't think that
there is anything formally decided with regards to C++0x, neither an
agenda, nor a timetable.

Obviously, if a formal proposal is made, the committee will be required
to discuss it.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

strieder@informatik.uni-kl.de (Bernd Strieder) writes:

> This is not an easy thing.

Didn't somebody=B9 once say "we choose to [...] do these things not
because they are easy, but because they are hard?"


Regards,
 Andy S.

Footnotes:=20
=B9  For those that need a hint, Rot13 this: Wbua S Xraarql
--=20
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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                       ]

In article <anq8al$1o7g$1@news.vol.cz>, Mirek Fidler wrote:

>> If not, why not?
>
>     Perhaps because in well written C++ code (using RAII idiom) they are
> almost useless...
>
>     I write tons of C++ code, using average one 'delete' per 10000 lines
>     of
> code (with no memory leaks). What is GC usefull for then ?

I'd say this is a matter of style.  It is certainly possible to write
robust C++ code without having to rely on GC; however, it seems to me we
have a few examples illustrating that the GC-approach can be effective too.

If that is true, then it is up to you to explain why GC should remain
unsupported by standard C++.

- Wil

--
Wil Evers, DOOSYS R&D, Utrecht, Holland
[wil underscore evers at doosys dot com]

---
[ 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                       ]

"Andy Sawyer" <andys@evo6.com> wrote in message news:lm5af7f6.fsf@ender.evo6.com...
strieder@informatik.uni-kl.de (Bernd Strieder) writes:

> Didn't somebody    once say "we choose to [...] do these things not
> because they are easy, but because they are hard?"

Somebody was President John F. Kennedy, September 12, 1962.
He was talking about the effort of sending a man to the moon.   Some
what of a larger task than extending C++'s memory management.



---
[ 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                       ]

In article <1033765572.863382@master.nyc.kbcfp.com>,
Hyman Rosen <hyrosen@mail.com> wrote:
>Allan W wrote:
> > now it would also have to maintain a reference count
>
>But reference counts are insufficient for full GC:
>
>struct me { me *p; me() : p(this) { } };
>int main() { for (;;) new me; }
>
>With real GC, this program happily runs forever.
>With reference counting, it consumes all memory.

Define "real GC".  Java GC is ref-count based, is it not?  Are you
saying that Java doesn't have "real GC"?

1) I firmly believe that it is impossible to create a compiler which
prevent all design errors.  I think we can all agree on that.

2) The example above (and all circular references) are design errors.
I think there's likely to be some disagreement on that topic.

The C# team decided (precisely because of circular references) to not
use ref-counted GC.  Now, because of that they chose nondeterministic
destruction (from my reading, a mark-and-sweep type alg).

I don't think nondeterministic destruction is compatible with C++.
RAII is a far too accepted (and *good* IMO) idiom that would be
seriously damaged with ND GC.  In C# there was an attempt to allow
deterministic GC by manually calling the "Dispose" function, which
releases non-memory resources.  That introduces a whole host of
problems, including differentiating (in user code) between Disposing
because of a user call vs. Disposing during GC--because you can't talk
about other objects if you're disposing--they might have already been
disposed.  That limitation destroys the concept of ownership, because
if the owner is being GC'd, it can't dispose of the things it owns.

Additionally, it imposes a false dichotomy between "managed resouces"
(memory) and "unmanaged resources" (everything else).

The result is that to implement Dispose correctly (and in a
thread-safe manner), the user has to duplicate dozens of lines of code
for each class.  It's a nightmare.


I think C++ would benefit from a mixture between GC/nonGC code to make
the job easier.  Of course, we already do that with smart pointers.
Circular references don't need to cause circular dependencies, because
the owners hold every reference as a smart pointer, whereas non-owners
hold raw pointers.  That way there's never a chain of ref-counted
pointers.

That said, I'd bet the majority of C++ users asking for GC simply
don't use the tools available (like smart pointers, Andrei
Alexandrescu's small object model, etc.).  I think before GC is
seriously addressed, there should be agreement on precisely what the
limitations are of the existing methods.


If GC is added, there's another question: is it on a per-object basis
or a per-heap basis?  That is, must I declare a GC object which is
always GC?  Or can I allocate from a GC heap which handles all GC?
--
Mark Ping
emarkp@soda.CSUA.Berkeley.EDU

---
[ 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                       ]

"Mirek Fidler":
>     I write tons of C++ code, using average one 'delete'
> per 10000 lines of
> code (with no memory leaks). What is GC usefull for then ?

It is a buzzword, so it sells.

Also some believe that it makes their job easier.  Apparently I have a
different idea - I have worked with a GC based language, which was told to
have a very god GC... it still had problems and it was unpredictable.

I can believe that for certain tasks GC can be really convenient.  I am yet
to see how systems programming and garbage collection are connected...

Some companies do virtual machine environments which require (AFAIU) GC.
For C++ not to be PITA to use on those systems language support is needed.

And last but not least GC takes away responsibility from the programmer.
With all its consequences.

WW


---
[ 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                       ]

"Wil Evers" <bouncer@dev.null> wrote in message
news:3da1ee6f$0$3998$e4fe514c@dreader6.news.xs4all.nl...
> In article <anq8al$1o7g$1@news.vol.cz>, Mirek Fidler wrote:
> I'd say this is a matter of style.  It is certainly possible to write
> robust C++ code without having to rely on GC; however, it seems to me we
> have a few examples illustrating that the GC-approach can be effective
too.
>
> If that is true, then it is up to you to explain why GC should remain
> unsupported by standard C++.

Quite the reverse, actually.  Since we have plenty of examples of robust and
efficient C++ programs developed without GC, it's up to you to provide a
rationale for why it should be added to the next rev of the standard.  We
don't add things to the standard simply because there's no good reason NOT
to do so.  Rather, things are added because there are compelling reasons why
we SHOULD do so.

-cd


---
[ 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                       ]

bouncer@dev.null (Wil Evers) writes:

> I'd say this is a matter of style.  It is certainly possible to write
> robust C++ code without having to rely on GC; however, it seems to me we
> have a few examples illustrating that the GC-approach can be effective too.
>
> If that is true, then it is up to you to explain why GC should remain
> unsupported by standard C++.

That's a _very_ slippery slope. Please explain to me why the following
should remain unsupported by standard C++:

- A standard graphics library
- A standard networking library
- Run-time compilation (c.f. Perl's "eval")
- etc, etc, etc.

(This is, or course, rhetorical).

There are a huge number of features that people think would be "good
to have" in standard C++. But I would suggest that it is up to the
proponent(s) of such features to explain why those features should be
supported.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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                       ]

Hi,
allan_w@my-dejanews.com (Allan W) wrote:
> All the compiler would have to do, is create the equivalent of a
> "smart pointer" instead of a raw pointer.

This is not at all equivalent to garbage collection! Apart from the objects
referencing themselves in a cyclic way which are not easily release with
smart pointers but with garabage collection, there is another issue garbage
collection is better at than smart pointers: The maintainance of the reference
count can easily become a dominating cost, especially in multi-threaded
environments where pointers might be shared between different threads. When
using garbage collection, there is no need to maintain a reference count: the
resource is simply released once it has detected to be unreachable.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

---
[ 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                       ]

E. Mark Ping wrote:
> Define "real GC".  Java GC is ref-count based, is it not?

No, it is not. It is true GC.

---
[ 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                       ]

ron@sensor.com ("Ron Natalie") writes:

> "Andy Sawyer" <andys@evo6.com> wrote in message
> news:lm5af7f6.fsf@ender.evo6.com...
>
> > Didn't somebody=B9 once say "we choose to [...] do these things not
> > because they are easy, but because they are hard?"
>=20
> Somebody was President John F. Kennedy

Indeed. That's why I named him (albeit Rot13'd) in my post.

> He was talking about the effort of sending a man to the moon.   Some
> what of a larger task than extending C++'s memory management.

That remains to be seen :-)

Regards,
 Andy S.
--=20
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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                       ]

Hi,
I have read the whole thread, but I have a question that does not stem
from any specific message. What is wrong with library based garbage
collection, as opposed to having it directly supported by the core language?

Cheers,
Nicola Musatti

---
[ 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                       ]

In article <1034030130.797378@master.nyc.kbcfp.com>,
Hyman Rosen <hyrosen@mail.com> wrote:
>E. Mark Ping wrote:
>> Define "real GC".  Java GC is ref-count based, is it not?
>
>No, it is not. It is true GC.

How do you define "true GC" -- and is there a difference between "real
GC" and "true GC"?  Which ecumenical council establishes the
difference? (sigh)


If "real GC" or "true GC" is non-deterministic, would you address the
issues of NDGC I raised?
--
Mark Ping
emarkp@soda.CSUA.Berkeley.EDU

---
[ 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                       ]

""Ron Natalie"" <ron@sensor.com> wrote...
> Actually, all you really need is a GC qualifier.
>
> gc int* i_gc;

Wouldn't it be more correct to write:

int* gc i_gc;

as with cv qualification indicating that i_gc is garbage collected, not the
items pointer to by i_gc?

-- Lawrence Rust, Software Systems, www.softsystem.co.uk

---
[ 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                       ]

cxl@centrum.cz ("Mirek Fidler") wrote in message
news:<anq8al$1o7g$1@news.vol.cz>...
> > If not, why not?

>     Perhaps because in well written C++ code (using RAII idiom) they
> are almost useless...

>     I write tons of C++ code, using average one 'delete' per 10000
> lines of code (with no memory leaks). What is GC usefull for then ?

It makes it easier.  For example, without garbage collection, you
typically need several types of pointers.  With garbage collection, you
will need less, and the type of the pointer will almost always be
evident from the semantics -- no need to worry about breaking cycles,
for example.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

emarkp@CSUA.Berkeley.EDU (E. Mark Ping) wrote in message
news:<ansjtp$7ta$1@agate.berkeley.edu>...

> Define "real GC".  Java GC is ref-count based, is it not?

The language specification doesn't say.  It does say, however, that the
garbage collector must handle cyclic references correctly.  And none of
the implementations I'm familiar with use reference counting.

    [...]

> 2) The example above (and all circular references) are design errors.

A double linked list is a design error?

    [...]
> I don't think nondeterministic destruction is compatible with C++.

I tend to agree, which is why I tend toward the opinion that the garbage
collector shouldn't call destructors.  But I don't think that the final
word has been said yet.

> Additionally, it imposes a false dichotomy between "managed resouces"
> (memory) and "unmanaged resources" (everything else).

The question is simply one of the abstraction used.  With garbage
collection, the abstraction is that memory is illimited.  Much in the
way we consider that an int is an integer.  In both cases, we make a
certain number of border checks to ensure that the validity holds, and
get on with it, without worrying about the errors in the exception in
most of the code.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

Hi,

As a C++ user, I'd like to know if the committee is considering (optional)
garbage collection for the next version of the C++ standard.

If so, what is the status of the discussion?  Is there any documentation
available on the WEB?

If not, why not?

Thanks,

- Wil

--
Wil Evers, DOOSYS R&D, Utrecht, Holland
[wil underscore evers at doosys dot com]

---
[ 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                       ]

"Wil Evers" <bouncer@dev.null> wrote in message news:3d9b5098$0$16211$e4fe514c@dreader7.news.xs4all.nl...

> As a C++ user, I'd like to know if the committee is considering (optional)
> garbage collection for the next version of the C++ standard.

I hope not.   Do you have a clue as to what this would mean?



---
[ 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                       ]

bouncer@dev.null (Wil Evers) wrote in message
news:<3d9b5098$0$16211$e4fe514c@dreader7.news.xs4all.nl>...

> As a C++ user, I'd like to know if the committee is considering
> (optional) garbage collection for the next version of the C++
> standard.

They were supposed to consider it for the original version.  It was
mentionned, along with templates and exceptions, in the list of
essential extensions for the language.

> If so, what is the status of the discussion?

I'm not sure.  I know that some people have done considerable work on
it.

> Is there any documentation available on the WEB?

See http://www.iecc.com/gclist/GC-faq.html.  It's not C++ specific, but
will give you a general introduction, and has links to the various
proposals that have been made.

> If not, why not?

I've never been able to figure that one out myself.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

In article <8a1n9.118385$F21.8159@fe02>, Ron Natalie wrote:

> "Wil Evers" <bouncer@dev.null> wrote in message
> news:3d9b5098$0$16211$e4fe514c@dreader7.news.xs4all.nl...
>
>> As a C++ user, I'd like to know if the committee is considering
>> (optional) garbage collection for the next version of the C++ standard.
>
> I hope not.   Do you have a clue as to what this would mean?

I think so :-).  In fact, conservative collectors like the Boehm collector
are currently being used in several major C and C++ projects; the impact of
convervative GC on existing code appears to be minimal.

If a few minor restrictions on the use of pointers were added to the
standard, this would become a legal thing to do in C++.  IMHO, we should
think of this as simply following existing practice.

- Wil

--
Wil Evers, DOOSYS R&D BV, Utrecht, Holland
[Wil underscore Evers at doosys dot com]

---
[ 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                       ]

"Wil Evers" <bouncer@dev.null> wrote in message news:1033738582.360852@news.knoware.nl...

>
> I think so :-).  In fact, conservative collectors like the Boehm collector
> are currently being used in several major C and C++ projects; the impact of
> convervative GC on existing code appears to be minimal.

Ahh, you're talking about a fairly weak GC system.   OK, I'm less concerned
about that (but still not convinced it belongs in the standard).

>  If a few minor restrictions on the use of pointers were added to the
> standard, this would become a legal thing to do in C++.  IMHO, we should
> think of this as simply following existing practice.

How is it following existing practice if you change the rules from the way things
are now?



---
[ 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                       ]