kanze@gabi-soft.de (James Kanze) wrote (abridged):
> It is possible to implement the boost::shared_ptr so that it works, by
> keeping the mappings between the objects and the counter in some sort
> of external data structure.  It isn't simple, however, since pointers
> to base objects don't always have the same address as pointers to
> derived objects.

Are you thinking of multiple inheritance here? I am not sure that
intrusive counts cope with multiple inheritance any better. Both base
classes may have their own counts.


> Globally, however, after much experimenting, I've come to the
> conclusion that smart pointers don't really work in general, at least
> for memory management.  The *ONLY* more or less automatic solution
> which really works is garbage collection.

I am not sure garbage collection works, either. It means we have to start
distinguishing between two kinds of object: those that own resources which
need to be released in a timely way, and those that don't.

An object of the second kind should not be allowed to own an object of the
first kind. This seems like a potentially massive burden.

  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                       ]

brangdon@cix.co.uk (Dave Harris) writes:

|>  kanze@gabi-soft.de (James Kanze) wrote (abridged):
|>  > It is possible to implement the boost::shared_ptr so that it
|>  > works, by keeping the mappings between the objects and the
|>  > counter in some sort of external data structure.  It isn't
|>  > simple, however, since pointers to base objects don't always
|>  > have the same address as pointers to derived objects.

|>  Are you thinking of multiple inheritance here?

Technically, you don't need multiple inheritance.  A base class is
never required to have the same physical address as the derived class.
But practically, yes, it is in the case of multiple inheritance where
the problem will occur.

If the object is polymorphic (has at least one virtual function), then
a dynamic cast can be used to obtain a pointer to the complete object.
But requiring a dynamic_cast and an insertion into a map in order to
create a smart pointer is a lot, and I'm sure a lot of people would
object to requiring it.

|>  I am not sure that intrusive counts cope with multiple inheritance
|>  any better. Both base classes may have their own counts.

The counter is in a base class (CountedObject, or some such).
Obviously, this class must be inherited virtually whenever multiple
inheritance is involved.

This isn't perfect either, of course.  The decision concerning virtual
inheritance occurs at a very low level in the inheritance tree --
often before you have any idea that multiple inheritance will be
involved.  The obvious solution is to specify that derivation from
CountedObject must always be virtual, but virtual inheritance has a
price, and many will object to having to pay it even when it isn't
needed.

|>  > Globally, however, after much experimenting, I've come to the
|>  > conclusion that smart pointers don't really work in general, at
|>  > least for memory management.  The *ONLY* more or less automatic
|>  > solution which really works is garbage collection.

|>  I am not sure garbage collection works, either. It means we have
|>  to start distinguishing between two kinds of object: those that
|>  own resources which need to be released in a timely way, and those
|>  that don't.

You have to do that anyway, even with reference counted pointers.

|>  An object of the second kind should not be allowed to own an
|>  object of the first kind. This seems like a potentially massive
|>  burden.

Anytime you have a resource which must be released in a timely manner,
you have to consider its release as part of your design requirements,
and treat it.  Regardless of the memory management tools used.  There
may be rare cases where the analysis will reveal that reference
counting does exactly the right thing (or at least something
acceptable), but from my experience, I don't think that they will be
that often.

--
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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.com> wrote in message
news:ae6njj$dup$1@eeyore.INS.cwru.edu...
> "Mike Schilling" <mscottschilling@hotmail.com> wrote in message
> news:8YAN8.6432$rG6.507512155@newssvr13.news.prodigy.com...
> > "Garry Lancaster" <glancaster@ntlworld.com> wrote in message
> > news:9BiN8.5804$lQ.29730@newsfep1-win.server.ntli.net...
> > >
> > > 4. Guarantees that all destructors of GC objects are called
> > > eventually (except in the case of abnormal program termination).
> >
> > Can you exaplin the reasoning behind number 4?   What are you picturing
a
> > finalizer doing that program termination wouldn't do?
>
> That's easy...any non operating system cleanup.  Simple example:
>
> hypothetical_xml_output_mechanism* xml = foo();
> xml.BeginNode("mynode");
>   xml.CreateAttribute("bar","baz");
>   xml.BeginNode("subnode");
>     xml.CreateText("hum de dum dum");
> // xml falls out of scope
>
> Now, the operating system isn't going to close our xml nodes on program
> termination, but a finalizer might...
I consider allowing xml to fall out of scope without being "close"d here
pretty awful practice, as bad as lertting an open file objsct go out of
scope. It is true that an open Java FileStream object is closed by its
finalizer, but letting that happen is poor coding; a file (or an XML output
mechanism) should be specifically closed when the program is done with it.

Looking at it another way, if I were doing a code review, I'd have no
confidence that xml was actually fully constructed at the end of that block.
If it were, the fact should be noted, and what better way to note it than to
close the object?

>
> Another example?  The OS isn't going to flush non-OS file buffers (like a
> stream buffer that is managed by the usermode code)
Likewise; if it's time to close the stream, close it.  If the stream is
stdout, it needs to be closed on exit (normal or abnormal), but atexit
already does that.


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

> Garry Lancaster wrote:
> > To summarise, to be acceptable to me a C++ GC must be:
> >
> > 1. Optional in the sense that programmers can choose to
> > use it or not use it as they see fit. (Ideally, I would like to
> > be able to mix GC and non-GC heap allocation in the same
> > program.)
> >
> > 2. Does not remove any existing memory management
> > techniques from the language.
> >
> > 3. Capable of collecting data structures containing cyclic
> > references (without requiring additional programmer
> > intervention e.g. weak back pointers).
> >
> > 4. Guarantees that all destructors of GC objects are called
> > eventually (except in the case of abnormal program termination).
> >
> > Using *that* definition of GC, what is wrong with it?

Daniel Miller:
>    i.e., Using THAT DEFINITION OF A DESIRED-STATE FOR A *HYPOTHETICAL*
> GC WHICH HAS NO EXISTIHNG INSTANTIATION YET, what is wrong with it?
>
>    The most obvious thing wrong is that such a
> utopian GC does not yet exist or, if it does exist for C++,
> it is not yet widely-known.  When will you be submitting
> such a "GC" for evaluation by us all?  If not from you, then
> from whom instead?  There darned well better be such a
> technique used in practice for multiple years before
> standardization, lest we have another repeat of the
> export keyword fiasco, regarding something which was
> standardized 4 years before its first existence which
> still has yet to receive any industrial experience for
> evaluation of merit.
>
>    Because the term "finalizer" is absent and because
> dtors would apparently serve as the sole end-of-lifetime
> dismantling mechanism, I would be very much interested
> in evaluating such a technique before judging it.

I wholeheartedly agree that a working implementation
would be required prior to standardization. But we need
to discuss what we are trying to achieve first and flush
out any obvious problems. In other words, design
must necessarily preceed implementation. Be patient.
>From my own experiments I can tell you that a system
that meets my four critieria is not difficult to implement.
However, an efficient, multi-threaded implementation
would still be an interesting challenge for just about
anyone, and would really benefit from integration with
the compiler.

GC is no spring chicken: it has been about since
the 1950s. It has very little in common with export,
whose rather sudden invention was primarily a
political fix (or so I am told by someone who was
in a position to know the truth.)

> Until such a utopian GC exists, I will continue using the
> Boehm collector as the referent for my criticisms of GC.

In that case, your criticisms will be irrelevant when
others discuss aspects of a standard GC that differ
from Boehm et al.'s system. As, indeed, they have
been.

>    By the way, #1 is a red herring (i.e., merely pretty-sounding words
> which distract us from the primary deleterious ramification) if the
> popularity/frequency of (mis)application of GC is so great that a design
> cannot prohibit it without also prohibiting the vast majority of COTS
> libraries & infrastructure.  When one has a hammer (i.e., GC) in one's
> hand, everything looks like a nail to some habit-minded people.

Misuse is a different issue from that of point 1, optionality,
which is vital for those who wish to continue to use the
current heap allocation system. You of all people should
appreciate that.

Of course some people will misuse GC. Some
people misuse inheritance, exceptions and just
about every other feature of C++. We need to balance
the needs of naive novices (who to be honest tend
not to be in charge of designing library interfaces)
with those who are more competent and this is
difficult sometimes.

In the UK we don't ban hammers just because of the
occasional sore thumb, we have very heavy restrictions
on guns because they can easily be used to kill, and
we have moderate restrictions on knives which fall
between the two. I think GC is more like the hammer
case, particularly when compared with other C++
features like casting, but you are entitled to your
opinion.

> I predict that GC will be overused and misapplied, displacing
> what has been one of the greatest strengths of the C++
> community for nearly 2 decades (of the C community for
> longer than that): overt design attention paid to resource
> deallocation & lifetime.

I agree this is one of C++'s strengths and, perversely, it
is also one of its weaknesses. A language which gives
you a choice of GC or non-GC allocation is a stronger
language than one that permits only one or the other.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

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

Daniel Miller <daniel.miller@tellabs.com> wrote in message
news:<3D064E0D.5060906@tellabs.com>...
> Garry Lancaster wrote:

> [...snip...]
> > Boehm's system is good, but it is not a particularly great fit for
> > C++ standardization as it was originally designed for use in C
> > without any special compiler support. The finalizer system is a
> > case in point. It is set up using global function pointers, so
> > some jiggery-pokery is required to get it to call a destructor or
> > other member function. Moreover, as both Bill Kempf and I have
> > said, we want a C++ system that guarantees all destructors be
> > called eventually, and it seems that Boehm's system may not offer
> > this guarantee

> > To summarise, to be acceptable to me a C++ GC must be:

> > 1. Optional in the sense that programmers can choose to use it or
> > not use it as they see fit. (Ideally, I would like to be able to
> > mix GC and non-GC heap allocation in the same program.)

> > 2. Does not remove any existing memory management techniques from
> > the language.

> > 3. Capable of collecting data structures containing cyclic
> > references (without requiring additional programmer intervention
> > e.g. weak back pointers).

> > 4. Guarantees that all destructors of GC objects are called
> > eventually (except in the case of abnormal program termination).

> > Using *that* definition of GC, what is wrong with it?

>    i.e., Using THAT DEFINITION OF A DESIRED-STATE FOR A
> *HYPOTHETICAL* GC WHICH HAS NO EXISTIHNG INSTANTIATION YET, what is
> wrong with it?

I believe that correctly configured, the Boehm collector meets all of
these requirements.  It is certainly optional:-).  It doesn't remove
any existing memory management techniques from the language.  It is
capable of collecting data structures with cyclic references.  (It is
also capable of recognizing that memory is in use even when the only
pointers to it are interal pointers -- a very important point which
wasn't mentionned.)  And I think that it also can guarantee that all
of the destructors of garbage collected objects are eventually called,
although I'm less certain here.  (I'm also not convinced that this is
an essential criterion.)

>    The most obvious thing wrong is that such a utopian GC does not
> yet exist or, if it does exist for C++, it is not yet widely-known.

It is part and parcel of g++.

> When will you be submitting such a "GC" for evaluation by us all?

There was a proposal for the last round of standardization.  The
general feeling was that it came to late to be considered, and the
authors withdrew it.  Globally, it was a lot better formulated, and a
lot more detailed and precise, than many things that actually made it
into the final standard.  It was also based on existing practice (the
Boehm collector).

> If not from you, then from whom instead?  There darned well better
> be such a technique used in practice for multiple years before
> standardization, lest we have another repeat of the export keyword
> fiasco, regarding something which was standardized 4 years before
> its first existence which still has yet to receive any industrial
> experience for evaluation of merit.

I don't know how long the Boehm collector has been around, but it was
there before the last standard was adopted.  Since the next version of
the standard won't be adopted until the end of this decade, at the
earliest, that meant the garbage collection for C++ will have been
around longer than templates were when they were adopted.  Not export,
but templates.

>    Because the term "finalizer" is absent and because dtors would
> apparently serve as the sole end-of-lifetime dismantling mechanism,
> I would be very much interested in evaluating such a technique
> before judging it.  Until such a utopian GC exists, I will continue
> using the Boehm collector as the referent for my criticisms of GC.

>    By the way, #1 is a red herring (i.e., merely pretty-sounding
> words which distract us from the primary deleterious ramification)
> if the popularity/frequency of (mis)application of GC is so great
> that a design cannot prohibit it without also prohibiting the vast
> majority of COTS libraries & infrastructure.  When one has a hammer
> (i.e., GC) in one's hand, everything looks like a nail to some
> habit-minded people.  I predict that GC will be overused and
> misapplied, displacing what has been one of the greatest strengths
> of the C++ community for nearly 2 decades (of the C community for
> longer than that): overt design attention paid to resource
> deallocation & lifetime.

Garbage collection *will* be overused when it first becomes generally
available.  As were operator overloading, inheritance and virtual
functions, templates, threads, dynamic linking...

There is, regretfully, a tendancy to treat any new technology as the
silver bullet, to be used as the final solution for every and all
problems.  I fear that there is not much we can do about that.  And I
certainly hope that we won't remove e.g. operator overloading,
inheritance and templates from the standard just because they were,
and often still are, misused.

--
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

> Garry Lancaster wrote:
> > To summarise, to be acceptable to me a C++ GC must be:
> >
> > 1. Optional in the sense that programmers can choose to
> > use it or not use it as they see fit. (Ideally, I would like to
> > be able to mix GC and non-GC heap allocation in the same
> > program.)
> >
> > 2. Does not remove any existing memory management
> > techniques from the language.
> >
> > 3. Capable of collecting data structures containing cyclic
> > references (without requiring additional programmer
> > intervention e.g. weak back pointers).
> >
> > 4. Guarantees that all destructors of GC objects are called
> > eventually (except in the case of abnormal program termination).
> >
> > Using *that* definition of GC, what is wrong with it?

Ross Smith:
> (1) It adds a completely unnecessary feature to the
> language, wasting compiler developers' time and
> effort in implementing it.

Believe me, compiler developers are more than
capable of speaking up for themselves ;-)

> We already have a perfectly good resource management
> method: RAII. > Adding GC would add gratuitous complexity
> to the language to absolutely no advantage.

In C++ GC is not intended to replace RAII. In fact, some
GC libraries make heavy use of RAII in their implementation.

RAII works very well for resources with one owner. When
the owner is destroyed it takes the resource with it. It
doesn't work when ownership is shared. That's when
you benefit from a form of GC, even if it is just simple
reference counting. But simple reference counting cannot
deal with arbitrary cyclic references which is when one of
the more involved GC algorithms becomes useful.

The advantage of GC is primarily a reduction in
development time due to a simplification of the
application's heap memory management code.
Special case application code for different data
structures can be avoided by using a general
GC algorithm.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net



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

Mike Schilling wrote:

> "Garry Lancaster" <glancaster@ntlworld.com> wrote in message
> news:9BiN8.5804$lQ.29730@newsfep1-win.server.ntli.net...

>>4. Guarantees that all destructors of GC objects are called
>>eventually (except in the case of abnormal program termination).
>
> Can you exaplin the reasoning behind number 4?   What are you picturing a
> finalizer doing that program termination wouldn't do?


     Flushing output buffers before closing a file, perhaps?

     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                       ]

James Kanze <kanze@gabi-soft.de> wrote:
> Daniel Miller <daniel.miller@tellabs.com> wrote in message
> news:<3D064E0D.5060906@tellabs.com>...
>
> >    The most obvious thing wrong is that such a utopian GC does not
> > yet exist or, if it does exist for C++, it is not yet widely-known.
>
> It is part and parcel of g++.

If you're thinking of Boehm, then you're slightly mistaken:  that GC is
used by gcj (the Java compiler), but not by g++.

Now, the gcc/g++ compiler uses a garbage collector /inside itself/ to
clean up its own data structures, but that's not available to the user.


> Garbage collection *will* be overused when it first becomes generally
> available.  As were operator overloading, inheritance and virtual
> functions, templates, threads, dynamic linking...
>
> There is, regretfully, a tendancy to treat any new technology as the
> silver bullet, to be used as the final solution for every and all
> problems.  I fear that there is not much we can do about that.

Not until we get Humans 2.0, not much...


Phil

--
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

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

> > Garry Lancaster wrote:
> > > Boehm's system is good, but it is not a particularly great fit for
> > > C++ standardization as it was originally designed for use in C
> > > without any special compiler support. The finalizer system is a
> > > case in point. It is set up using global function pointers, so
> > > some jiggery-pokery is required to get it to call a destructor or
> > > other member function. Moreover, as both Bill Kempf and I have
> > > said, we want a C++ system that guarantees all destructors be
> > > called eventually, and it seems that Boehm's system may not offer
> > > this guarantee
>
> > > To summarise, to be acceptable to me a C++ GC must be:
>
> > > 1. Optional in the sense that programmers can choose to use it or
> > > not use it as they see fit. (Ideally, I would like to be able to
> > > mix GC and non-GC heap allocation in the same program.)
>
> > > 2. Does not remove any existing memory management techniques from
> > > the language.
>
> > > 3. Capable of collecting data structures containing cyclic
> > > references (without requiring additional programmer intervention
> > > e.g. weak back pointers).
>
> > > 4. Guarantees that all destructors of GC objects are called
> > > eventually (except in the case of abnormal program termination).
>
> > > Using *that* definition of GC, what is wrong with it?

Daniel Miller:
> >    i.e., Using THAT DEFINITION OF A DESIRED-STATE FOR A
> > *HYPOTHETICAL* GC WHICH HAS NO EXISTIHNG INSTANTIATION YET, what is
> > wrong with it?

James Kanze:
> I believe that correctly configured, the Boehm collector meets all of
> these requirements.  It is certainly optional:-).  It doesn't remove
> any existing memory management techniques from the language.  It is
> capable of collecting data structures with cyclic references.  (It is
> also capable of recognizing that memory is in use even when the only
> pointers to it are interal pointers -- a very important point which
> wasn't mentionned.)

Yes, that's essential, particularly as the usual
implementations of multiple inheritance lead to use
of internal pointers without any special effort on the
programmers part. Perhaps I should have stated it
explicitly: internal pointers are OK, disguised
pointers are not.

> And I think that it also can guarantee that all
> of the destructors of garbage collected objects are eventually called,
> although I'm less certain here.

I think this is actually the point where it does fall
short of my criteria, although from my reading of the
docs like you I wasn't 100% sure either way.

I am a little uneasy about the way in which Boehm et
al's system offers optionality, but I deliberately phrased
my criteria so as not to exclude it in that regard.

Speaking of standardizing Boehm et al.'s collector is
a bit of red herring. We standardize requirements, not
particular implementations. The exact Boehm et al.
interface is a little clunky because it has to work without
any compiler support, so this is unlikely to make it into
the standard. But if a system *based upon* Boehm et
al.'s meets the eventual requirements, great. If we get a
standard C++ GC one would hope at least some
compiler vendors will go beyond what is possible in
uncooperative compiler environments. For example,
a mostly-precise collector should be faster, whether
significantly so I do not know.

> (I'm also not convinced that this is an essential criterion.)

Hmm. I think it is less important in languages that
never had guaranteed destructor calling in the first
place. But in C++ I would need a hell of a lot of
persuading to accept this loss.

> >    The most obvious thing wrong is that such a utopian GC does not
> > yet exist or, if it does exist for C++, it is not yet widely-known.
>
> It is part and parcel of g++.

Interesting. I see the GCC's Objective-C compiler has a GC
based on Boehm et al's, but I couldn't find any information
about GC within g++ (gnu.org was being weird and Google
didn't shed any light). One of the downsides of them being
a non-commercial organization is that they do a lot of great
stuff that you never hear about. Have you got a link for it?

> > When will you be submitting such a "GC" for evaluation by us all?
>
> There was a proposal for the last round of standardization.  The
> general feeling was that it came to late to be considered, and the
> authors withdrew it.  Globally, it was a lot better formulated, and a
> lot more detailed and precise, than many things that actually made it
> into the final standard.  It was also based on existing practice (the
> Boehm collector).

Also interesting. I have seen the Stroustrup paper
but if there is another one I'd appreciate a link or even
just the paper number if I can still get it from the ISO site.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net


---
[ 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 Fri,  7 Jun 2002 18:12:36 GMT, William E. Kempf wrote in
<newscache$qugcxg$ki4$1@frodo.bagend.com>:

> "Garry Lancaster" <glancaster@ntlworld.com> wrote in message
> news:Rl5M8.4756$L66.620702@news6-win.server.ntlworld.com...
> > Alex Oren:
> > > > You have no idea when the GC will decide to
> > > > collect the item.  Immediately, in 1 second, in 10 hours, sometime in
> > > > the next decade or (if enough memory is available) never.
> >
> > That "never" relies on misconception #2 and would
> > not be acceptable in C++ I think. Otherwise, it
> > depends on the GC collection strategy.
>
> I agree that adding "never" to the list of possibilities is pointless.
> However, I must agree that in systems like they've talked about GC is
> entirely inappropriate.  Even if there were some way to put some gaurantee
> on the amount of lapsed time allowed, let's say within 1 minute of the last
> root pointer going away, the non-determinism involved in GC would still make
> it problematic at best for such systems.

See the server example below...

> However, I must again point out that every language I've seen that uses GC
> provides some way to deterministically deal with the recollection of
> non-memory resources.  Java's mechanism (finally blocks) may not be ideal
> and may lead to bugs, but it *CAN* be employed in XAOP style programming.

The Java try/finally mechanism puts the onus on the *user* of the
resource.  It is not much better than using a cleanup() method and
insisting that the user calls it.

> > > > Specifically, relying on finalizers to free resources that are more
> > > > scarce than memory (e.g., file handles on some systems) is a
> > > > particularly bad idea.
> >
> > It depends. If the resource is only slightly scarcer than
> > memory or the GC is collecting aggressively, I would
> > suggest more leeway is appropriate. In C++ when
> > a blanket language design decision would be unduly
> > restrictive, we tend to let the programmer decide.
>
> I'd agree with this as well, though it depends on circumstances.  If file
> handles are scarce, but still number in the 100s, a text editor can probably
> get away with having the handles collected when finalizers are run.

Consider a server that runs for days (years?) in a high traffic
environment.  Now replace "file handles" with "sockets", "DB handles",
etc.

>  This is
> especially true if we can tell the GC to start a collection phase if we fail
> to acquire a file handle.

Or a socket.  Or a DB handle.  OR a widget resource.  Or a mutex.

Or, in the general case:

   class UserDefinedResouceWrapper {
   public:
      UserDefinedResouceWrapper();  // Acquire resource
      ~UserDefinedResouceWrapper(); // Release resource
   };

Now the GC has to be aware of every RAII guard you can think of.

>  On systems described by Daniel, however, I don't
> think I'd ever trust the GC to collect such resources in the finalizers.
> That's simply not an argument for not including GC, however.

The argument was that finalizers cannot do the work of destructors.
I never argued against GC.


Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

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

Garry Lancaster:
> > > > 4. Guarantees that all destructors of GC objects are called
> > > > eventually (except in the case of abnormal program termination).

Mike Schilling:
> > > Can you exaplin the reasoning behind number 4?   What are you
> > > picturing a finalizer doing that program termination wouldn't do?

Ken Alverson:
> > That's easy...any non operating system cleanup.  Simple example:
> >
> > hypothetical_xml_output_mechanism* xml = foo();
> > xml.BeginNode("mynode");
> >   xml.CreateAttribute("bar","baz");
> >   xml.BeginNode("subnode");
> >     xml.CreateText("hum de dum dum");
> > // xml falls out of scope
> >
> > Now, the operating system isn't going to close our xml nodes on program
> > termination, but a finalizer might...

Mike Schilling:
> I consider allowing xml to fall out of scope without being "close"d here
> pretty awful practice, as bad as lertting an open file objsct go out of
> scope. It is true that an open Java FileStream object is closed by its
> finalizer, but letting that happen is poor coding; a file (or an XML
output
> mechanism) should be specifically closed when the program is done with it.

Ignoring Java and getting back to C++, the whole concept of
RAII is that destructors do clean-up. There is no reason not
to have an explicit close function in addition, but it turns out
by far the easiest way to achieve exception safety in code is
to have the destructor do the clean-up if it is not already done.
Sutter's "Exceptional C++" and Meyers's "More Effective C++"
explain all this in more detail.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

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

"Garry Lancaster" <glancaster@ntlworld.com> wrote in message
news:9BiN8.5804$lQ.29730@newsfep1-win.server.ntli.net...
> To summarise, to be acceptable to me a C++ GC must be:
>
> 1. Optional in the sense that programmers can choose to
> use it or not use it as they see fit. (Ideally, I would like to
> be able to mix GC and non-GC heap allocation in the same
> program.)

I think it goes beyond ideally.  You *must* be able to allocate to either
heap.

> 2. Does not remove any existing memory management
> techniques from the language.
>
> 3. Capable of collecting data structures containing cyclic
> references (without requiring additional programmer
> intervention e.g. weak back pointers).
>
> 4. Guarantees that all destructors of GC objects are called
> eventually (except in the case of abnormal program termination).

This one is a bit more tricky.  All GCed objects *must* have their finalizer
called.  Whether or not this finalizer is the object's destructor is
questionable, and I don't have enough knowledge/expertise to say here.  At
the very least I'd like the option (possibly the default) of specifying the
finalizer call the destructor.

Bill Kempf

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

"Mike Schilling" <mscottschilling@hotmail.com> wrote in message
news:94LN8.6502$8S1.517636238@newssvr13.news.prodigy.com...
> "Ken Alverson" <Ken@Alverson.com> wrote in message
> news:ae6njj$dup$1@eeyore.INS.cwru.edu...
> >
> > hypothetical_xml_output_mechanism* xml = foo();
> > xml.BeginNode("mynode");
> >   xml.CreateAttribute("bar","baz");
> >   xml.BeginNode("subnode");
> >     xml.CreateText("hum de dum dum");
> > // xml falls out of scope
> >
> > Now, the operating system isn't going to close our xml nodes on program
> > termination, but a finalizer might...
> I consider allowing xml to fall out of scope without being "close"d here
> pretty awful practice, as bad as lertting an open file objsct go out of
> scope. It is true that an open Java FileStream object is closed by its
> finalizer, but letting that happen is poor coding; a file (or an XML
output
> mechanism) should be specifically closed when the program is done with it.
>
> Looking at it another way, if I were doing a code review, I'd have no
> confidence that xml was actually fully constructed at the end of that
block.
> If it were, the fact should be noted, and what better way to note it than
to
> close the object?
>

I feel this is the kind of naive programming style that is implicitly (but
possibly innocently) encouraged by GC-based procedural languages. Novices
will do this kind of thing all the time. Not that there aren't already a lot
of bad things novices will do, but this would likely be added to that list.

A friend of mine put it yesterday, in a comment about all this discussion of
how to make GC work correctly with C++ destructors/finalizers: "all the
effort to avoid having to manage the lifetime of objects and you still have
to."

On the other hand, sometimes it would be useful to be able to use GC-style
bookkeeping for certain data structures that have complex end-of-life
semantics but are explicitly finalized before becoming eligible for
collection. GC would be a good way to assign finalization-optional lifetime
semantics to objects, which could possibly even lead to deallocation
optimizations in some cases (for instance, instead of deallocating
hypothetical_gc_container<gc_T>'s internal memory immediately, that work
could be deferred). Deallocation overhead can be significant in some
situations, for instance, when you are trying to deal with thousands of
"small" objects which do not really have any useful finalization semantics
other than to release memory.

thanks,
hys

--
Hillel Y. Sims
hsims AT factset.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                       ]

"Daniel Miller" <daniel.miller@tellabs.com> wrote in message
news:3D065552.5070603@tellabs.com...
> William E. Kempf wrote:
>
> > "Daniel Miller" <daniel.miller@tellabs.com> wrote in message
> > news:3D0531FC.7040803@tellabs.com...
> >
> >
> >>   I have never claimed that anything would be *removed*.  I am stating
> >>that the distracting presence of finalizers as a competitor to &
> >>displacer of dtors clouds RAII to the point that XAOP is eroded.
> >>
> >
> > This is the crux of the disagreement, I think.  The above is FUD, with
no
> > data to back it up.
>
>
>    Oh, so do you in fact have a utopian GC which would like to recommend
> to us all which is today demonstrating the entire desired-state of the
> GC feature-set in industrial practice?  Where may I obtain today this
> existing utopian GC for evaluation?  Where may J16/WG21 obtain today
> this existing utopian GC for standardization by evaluating its
> established industrial practice?

What feature set?  There's some things I'd like changed, but the Boehm
collector meets the important ones for this discussion.  Is it utopian?  Of
course not.  Nor do I think it's _possible_ for a utopian solution to
anything, let alone GC.  The C++ language let's you shoot yourself in the
foot in an infinite number of way, and yet we manage to use the language
effectively every day.  You're claiming that either GC will make this
impossible, or at best will make it more likely that people will misuse the
language.  This is FUD.  GC can certainly be misused, but there's no
evidence that it's mere existence will cause the misuse you claim.  As a
counter example, I believe there's more danger for misuse with
multi-threading then with GC, but you're in agreement that multi-threading
should be added as an optional part of the C++ standard.

> >  Is it possible that this fear may turn out to be
> > correct?
>
>  > Yes, but I doubt it.
> [...snip...]
>
>    Is it possible that a utopian GC will be able to balance all of the
> trade-offs perfectly to achieve every one of its lofty goals?  Maybe,
> maybe not.  Time will tell, as would observation of the industrial
> practice of using that utopian GC prior to standardization.

The existence or lack there of, of a "utopian GC" is irrelevant.  The mere
existence of GC, even if severely flawed, won't necessarily lead to the
misuse that you fear.

>    Aren't we both (rightfully) out on a limb here predicting the future?

No, I'm not predicting the future at all, out on a limb or not.

>   Aren't we both (rightfully) discussing a spectrum of possible futures?
>   I know that I am trying to point out the undesirable states so that we
> steer clear of them.  You and Garry Lancaster are describing the desired
> state and especially the benefits of a hypothetical desired-state GC.
> Both positive & negative viewpoints (as well as proponent & contrarian
> viewpoints) must be presented in public forums to let the community know
> 1) the expectations of GC to be satisfied as a goal and 2) the fears of
> GC to be avoided as a goal.  Such diversity of free speech is the nature
> of public forums (as well as the benefit).

You hold a belief that's unfounded, AFAIK, that the mere existence of GC
will erode RAII and jeapordize C++ as a language choice for embedded
systems.  As Garry has pointed out in this thread, this fear can only be
gauranteed to prove correct if GC were to somehow cause RAII to no longer
work in C++.  With out this, the fear is unfounded and can only be based on
a belief that C++ programmers are stupid and would therefore arbitrarily
choose GC for all memory management.  Even if that were true, don't you
think the embedded folks would know better?  And that the committee would
know better?

Bill Kempf


======================================= MODERATOR'S COMMENT:
 Treading the edge of a flame-war, everyone please take care...

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

"Alex Oren" <response@myrealbox.com> wrote in message
news:a0lfgusitq0hgu11kda6jddfkp11e3bona@4ax.com...
> On Fri,  7 Jun 2002 18:12:36 GMT, William E. Kempf wrote in
> <newscache$qugcxg$ki4$1@frodo.bagend.com>:
>
> > "Garry Lancaster" <glancaster@ntlworld.com> wrote in message
> > news:Rl5M8.4756$L66.620702@news6-win.server.ntlworld.com...
> > > Alex Oren:
> > However, I must again point out that every language I've seen that uses
GC
> > provides some way to deterministically deal with the recollection of
> > non-memory resources.  Java's mechanism (finally blocks) may not be
ideal
> > and may lead to bugs, but it *CAN* be employed in XAOP style
programming.
>
> The Java try/finally mechanism puts the onus on the *user* of the
> resource.  It is not much better than using a cleanup() method and
> insisting that the user calls it.

It's better in that it allows a mechanism to *insure* the cleanup method is
called.  That's the important part of XAOP.  I've tried to research this
concept, but there's little I can find on the web.  But this is the first
I've heard anyone claim that XAOP requires there be no onus on the user.
Regardless, there are ways to code the transactions such that there's no
onus on the user to call the "cleanup" methods, using some sort of callback
mechanism.  Still ugly, yes.  The C++ RAII idiom is obviously superior since
there's less onus on the user, but I don't think it's required for XAOP.

> > > > > Specifically, relying on finalizers to free resources that are
more
> > > > > scarce than memory (e.g., file handles on some systems) is a
> > > > > particularly bad idea.
> > >
> > > It depends. If the resource is only slightly scarcer than
> > > memory or the GC is collecting aggressively, I would
> > > suggest more leeway is appropriate. In C++ when
> > > a blanket language design decision would be unduly
> > > restrictive, we tend to let the programmer decide.
> >
> > I'd agree with this as well, though it depends on circumstances.  If
file
> > handles are scarce, but still number in the 100s, a text editor can
probably
> > get away with having the handles collected when finalizers are run.
>
> Consider a server that runs for days (years?) in a high traffic
> environment.  Now replace "file handles" with "sockets", "DB handles",
> etc.

Read what I said again.  Put emphasis on "it depends on circumstances".
Some applications can get away with letting the GC system collect certain
non-memory resources, while other applications can not.  Forcing either form
of management seems to me to be wrong.

> >  This is
> > especially true if we can tell the GC to start a collection phase if we
fail
> > to acquire a file handle.
>
> Or a socket.  Or a DB handle.  OR a widget resource.  Or a mutex.

So you agree then?

(BTW, when you mention a mutex I hope you don't meen a lock on the mutex.
Locks had better be reclaimed immediately, not non-deterministically.)

> Or, in the general case:
>
>    class UserDefinedResouceWrapper {
>    public:
>       UserDefinedResouceWrapper();  // Acquire resource
>       ~UserDefinedResouceWrapper(); // Release resource
>    };
>
> Now the GC has to be aware of every RAII guard you can think of.

No, it doesn't.  The application programmer has to decide if he should put
an object on the GC heap or rely on RAII or other resource management
techniques.  Just to emphasise it again, we're not talking an all or nothing
choice here.  If C++ were to standardize a GC it would have to be an
optional feature, if for no other reason then to insure backwards
compatibility (though obviously RAII is better then GC for many, I'd say
most, cases any way).

> >  On systems described by Daniel, however, I don't
> > think I'd ever trust the GC to collect such resources in the finalizers.
> > That's simply not an argument for not including GC, however.
>
> The argument was that finalizers cannot do the work of destructors.
> I never argued against GC.

What does that mean?  Finalizers and destructors both do the same thing...
they clean up resources when an object is destroyed.  In some GC systems
that exist for C++ today they are even one and the same thing (i.e. the
destructor is run when the object is "finalized").

Bill Kempf

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

"Garry Lancaster" <glancaster@ntlworld.com> wrote in message
news:<KZhM8.499$A62.65450@news11-gui.server.ntli.net>...
> |>  James Kanze:
> |>  > It depends on what you mean by a defect.

> Garry Lancaster:
> |>  A conservative definition could be: failure to meet
> |>  specification or a self-inconsistent specification.  If you want
> |>  to go a little further I won't quibble, but be explicit about
> |>  what you mean. Saying it "doesn't work in quite a number of real
> |>  programs" is too vague.

> James Kanze:
> > That's roughly what I would use for an implementation, and by that
> > definition, the implementation of boost::shared_ptr doesn't have a
> > defect.

> > What I said, however, was that it didn't work in real
> > applications.

> Actually what you wrote originally was it "doesn't work in *quite a
> number of* real programs" (my emphasis). What you just wrote makes
> it sound like it doesn't work in *any*!

"Quite a number" is more accurate.

> > That doesn't necessarily mean the implementation is defective.

> That may not be what you intended it to mean, but that is the
> inference that will be drawn when you write that something "doesn't
> work". Had you just said it isn't suitable for all applications, we
> wouldn't be having this (part of the) discussion.

Doesn't work means simply that it doesn't work.  It reclaims the
memory too early.

>From what I understand, the implementors are aware of this problem,
and have decided that it isn't important.

> If you don't wish to use shared_ptr,

I'd rather use shared_ptr than some home built solution.  But it
doesn't work in my applications.  It's not a question of what I want.
If the thing deletes the object when there are still pointers to it,
it doesn't work.

> that is fine with me, but if you are going to imply that there is
> some kind of problem with it you should be prepared to back up that
> up with some kind of real example, preferably involving code, rather
> than just vague or inaccurate generalizations.

The examples are known.  I've presented them before, too.

> (Who knows, someone might be able to solve the problem for you or it
> might even help refine shared_ptr's design?)

The solutions are known.  I don't know why they aren't used.

Globally, however, after much experimenting, I've come to the
conclusion that smart pointers don't really work in general, at least
for memory management.  The *ONLY* more or less automatic solution
which really works is garbage collection.

> [snip]

> > The problem is simple: my objects enrole themselves with other
> > objects, e.g. for accepting events or for generating state change
> > notifications.  In some cases (not all, of course), these other
> > objects participate in the ownership of the object.

> > This doesn't work with boost::shared_ptr.  It does work with every
> > other reference counted pointer I've used.

> On the contrary, what you describe is entirely possible with
> boost::shared_ptr. Possibly there is some additional important
> constraint that you have not disclosed. If you don't give a clear
> example it is impossible to say.

Try it, and you will find that the memory is freed too early.

The situation occurs in many real programs.  The worst aspect of it is
that the situation may only occur as a result of a modification, after
the original program is fully committed to using shared_ptr.  For this
reason, I strongly discourage any use of the boost::shared_ptr.

Note that the reference counted pointer described in Scott Meyers
doesn't have this problem.  It does require that the pointed to object
derive from a special base class however.  This doesn't cause me any
problems, but is unacceptable to others.

It is possible to implement the boost::shared_ptr so that it works, by
keeping the mappings between the objects and the counter in some sort
of external data structure.  It isn't simple, however, since pointers
to base objects don't always have the same address as pointers to
derived objects.  And it does introduce a large degree of complexity.
IMHO, this is too high a price to pay for being able to point to any
object.  But opinions in this regard may vary.

> |>  > But I'm not saying standardize my smart pointer, rather than
> |>  > Boost's. I'm saying that the requirements on smart pointers
> |>  > are complex enough that no one size fits all, and that they
> |>  > probably shouldn't be standardized.

> |>  This is not an argument against standardization: we don't say we
> |>  shouldn't standardize vector because sometimes list is better,
> |>  do we?

> > The difference is that both vectors and lists are well understood
> > concepts, with a large body of existing practice.  So it is pretty
> > clear what is and is not needed.

> > This is still far from being the case with regards to smart
> > pointers.

> Well, if there is a particular point you don't understand, yet feel
> is important, you could ask here.

I understand that the existing practice varies widely, and that there
is no one universal solution.  I understand that at least one of the
most widely used implementations doesn't work correctly, and results
in the objects being prematurely destructed.

What more do I have to understand in order to understand that the
concept is not yet ripe for standardization?

> As for not having a large body of existing practice, I would have
> said the exact opposite is true: if there is one thing that the C++
> world has no shortage of it is reference- counted smart pointer
> implementations.

Correct.  All different.  And none that really work for all, or even
most of the cases.  Everyone is in favor of some sort of reference
counted pointer, but no one agrees as to what sort.

> > Do we really want to repeat the debacle of auto_ptr?

> One of the problems that keeps cropping up with auto_ptr is that
> people want to put them in the standard containers.  Their needs
> would actually be satisfied much better by a reference-counted
> pointer like shared_ptr.

Just don't try and put a raw pointer into two containers of
boost::shared_ptr:-).  Sounds a lot like the problem with auto_ptr.

It is exactly this problem which causes me to say that shared_ptr
doesn't work.

> A reference- counted smart pointer is such a must have in modern C++
> development that it would be far better to standardize one than to
> have everyone invent their own slightly different incompatible, and
> usually not-as-good-as-shared_ptr, version.

I've yet to see one that wasn't better than shared_ptr.

More generally, however, I've used many different ones extensively,
and the only conclusion I can come to is that we absolutely need
garbage collection, so we can avoid the problems (managing cycles, for
example) that they all impose.

> James Kanze:
> >>>> [C++ destructors must be run] when delete is explicitly
> >>>> invoked.
>
> Garry Lancaster:
> |>  |>  This may not be permitted. If I recall correctly neither the
> |>  |>  Java or C# GC system permit it nor does shared_ptr.

> James Kanze:
> |>  > The Boehm collector (for C++) does.

> |>  So it seems fair to say that some do and some don't.

> > We're talking about C++.  (Asking whether the destructor is called
> > on local variables, or whether you can explicitly call delete, in
> > Java, is nonsense.)

> No-one mentioned destroying local variables in Java. However, when
> devising a GC system for C++ it is eminently sensible to look at all
> prior art. Including, but not limited to, Java. The fact that Java
> does not have a keyword called delete is irrelevant but the fact
> that it has no *equivalent* of delete is entirely relevant.

The fact that it has no equivalent of delete means that we cannot look
for prior art concerning how to handle delete here.

> > What other collectors do you know?  Which ones don't allow calling
> > delete explicitly?

> Just taking the Boehm collector with which I think we are both at
> least vaguely familiar, the docs seem to indicate explicit delete is
> permitted in some cases but not all.

>From everything I've read, explicit delete is always possible.  What
is unclear (or configurable) is whether delete will be called when an
otherwise undeleted object is garbage collected.

> While allowing explicit delete on all GC objects is perfectly
> possible generally, it can be a source of complexity without much
> advantage over normal manual memory management i.e. deciding you
> will call explicit delete before object allocation rather than
> sometime afterwards.  So, I wouldn't necessarily assume, as you do,
> that it would be a feature of any standard C++ GC.

> There are a number of other GC systems available for C++. Look at

> http://www.hpl.hp.com/personal/Hans_Boehm/gc/

> for some links or try Google.

> > (Agreed, you could call shared_ptr a garbage collector.

> I would, just. Some do, some don't ;-)

Maybe that's my problem with reference counted pointers.  They are a
form of garbage collection.  A form that is hopelessly broken.

> > In that case, some do, and some don't.  But if the goal is true
> > garbage collection, all of the reference counted pointers I've
> > seen in C++ are seriously broken.

> They wouldn't collect cyclic references without additional fiddling
> (nor are they specified to), if that's what you mean by "seriously
> broken".

Right.  In this context ("the goal is true garbage collection").

Other than that, used judiciously, in a limited manner, they can
sometimes be useful.  But their merits have been largely oversold.
And of course, garbage collection solves all of the problems reference
counted pointers do, only better.

> [...]

> |>  What you appear to be saying is that unless the timing of
> |>  destruction/finalization can be determined without inspecting
> |>  certain portions of the run-time system which you do not wish to
> |>  inspect, you don't believe we should have it at all. I would
> |>  like to see you explain *why* you make this linkage.

> > Quite simply because I don't have any desire to add the complexity
> > unless there is a real use for it.

> The #1 real use is with classes that are already written and perhaps
> use non-GC memory management internally.  If you ban non-trivial
> destruction for objects that are garbage collected, you will not be
> able to garbage collect objects of these classes, nor will you be
> able to have such objects as data members of GC objects. So, no
> garbage collected vectors or basic_strings, for example.

This is probably where it will be most difficult to define what the
standard should say.  IMHO, it would be very silly if a system
supported garbage collection, and e.g. std::string and std::vector
didn't use it for their own, internal memory management.  Except that
there may be a very few, special cases, where I need the destructors
of my object called immediately, when the vector is destructed.  (This
is a non-issue for std::string, since the character type cannot have a
non-trivial destructor.)

Allocators should be able to handle this solution somehow.  I have a
special allocator type for the garbage collected vector, which is
partially specialized on this allocator type to use a no-op
destructor.  Ideally, the default version would use garbage
collection, but backwards compatibility probably prevent this.  So
once again, C++ ends up with the wrong default, and extra effort being
necessary to handle the "normal" case.

--
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

"William E. Kempf" wrote:
[...]
> > The argument was that finalizers cannot do the work of destructors.
> > I never argued against GC.
>
> What does that mean?  Finalizers and destructors both do the same thing...
> they clean up resources when an object is destroyed.  In some GC systems
> that exist for C++ today they are even one and the same thing (i.e. the
> destructor is run when the object is "finalized").

Nah, for objects with non-trivial C++-classic destructors, I'd probably
rather make GC-finalizers perhaps-even-'const' methods -- allowing them
to do whatever they want w.r.t. the outside world ['resurrection' including]
and invoke real GC-destructors (these beasts should impose limitations w.r.t.
publishing 'this'[1]) only when it's known for sure that the object is finally
FOREVER-DEAD [will end up finally in Nirvana] and just can't anymore become
resurrected; I'd probably also provide optional 'resurrectors' that will be
invoked 'on resurrection']. Or am I missing something?

Well, Y'know all this stuff with extra end-of-{current}-life/begin-of-{new}-
life pre/post methods [finalizers and resurrectors] looks/smells rather
similar to the pre-destructors and post-constructors that I personally DEADLY
NEED in the next C++ version. The 'only difference' for GC-objects would be
just a couple of 'extra restrictions' and that nice 'feature' w.r.t pre-post
stuff could be invoked MULTIPLE times [due to potentially infinite number
of finalization/resurrection cycles]. Oder? ;-) ;-)

regards,
alexander.

[1] In addition to poly/non-poly qualifiers [to fix somewhat brain-dead
    'polimorhic behaivor' during object construction and destruction; hello
    Garry&James ;-)] I'd probably add one more qualifer ['almost-dead' this
    ptr] for objects that have reached GC-destruction. It should be simply
    impossible to store such ptr/ref in any object(s) those life time could
    span beyond the rest of already-under-destruction object collected by
    garbage collector. Well, that [i.e. 'almost-dead' qualifier] could be
    probably helpful even for non-GC objects... unless all this [post/pre
    stuff including] is just impossible to implement/makes no sense. Sorry,
    then. ;-) ;-)

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

   regarding the defect in boost::shared_ptr

James Kanze wrote:

> "Garry Lancaster" <glancaster@ntlworld.com> wrote in message
> news:<KZhM8.499$A62.65450@news11-gui.server.ntli.net>...

[...snip...]

>>>The problem is simple: my objects enrole themselves with other
>>>objects, e.g. for accepting events or for generating state change
>>>notifications.  In some cases (not all, of course), these other
>>>objects participate in the ownership of the object.
>>>
>
>>>This doesn't work with boost::shared_ptr.  It does work with every
>>>other reference counted pointer I've used.
>>>
>
>>On the contrary, what you describe is entirely possible with
>>boost::shared_ptr. Possibly there is some additional important
>>constraint that you have not disclosed. If you don't give a clear
>>example it is impossible to say.
>>
>
> Try it, and you will find that the memory is freed too early.
>
> The situation occurs in many real programs.  The worst aspect of it is
> that the situation may only occur as a result of a modification, after
> the original program is fully committed to using shared_ptr.  For this
> reason, I strongly discourage any use of the boost::shared_ptr.
>
> Note that the reference counted pointer described in Scott Meyers
> doesn't have this problem.  It does require that the pointed to object
> derive from a special base class however.  This doesn't cause me any
> problems, but is unacceptable to others.


   I have been reading this boost::shared_ptr-oriented subthread with
interest.  If I may interject here, James, it seems from my
3rd-party-observer viewpoint that the information which Garry is seeking
might be the following:

   It appears that James's use of reference-counted smart-pointers
relies in part on pointing to a base class and in part on pointing to a
class derived from that base class.  To me it appears when he is using
boost::shared_ptr in a way which causes there to be two separate
reference counts: one count for each object of the derived class and
another different count which is being used by pointers to the base
class.  This could cause two failure modes:
   1) If there are no more boost::shared_ptr pointers to the base class
but there are boost::shared_ptr pointers to the derived class, the
object is polymorphically destroyed prematurely via deletion through the
base-class-typed pointer.
   2) If there are no more boost::shared_ptr pointers to the derived
class but there are boost::shared_ptr pointers to the base class, the
object is destroyed prematurely via deletion through the
derived-class-typed pointer.

   Intrusive smart-pointers (e.g., the Scott Meyers one via multiple
inheritance) could more easily design for having a single count in this
polymorphic situation and would then not suffer from the aforementioned
situation of: the base-hand doesn't know what the derived-hand is doing
and vice versa.  (A tinge of pun-humor there: in English, there is an
idiom for describing such situations as "The left hand didn't know what
the right hand was doing".)

   If I am off on the wrong track here or if this was a blatantly
obvious observation, please ignore this posting as I am just guessing
based on what has been written here, having seen neither the code nor
the design.  My motivation is to help reach convergence regarding
effective communication.


> It is possible to implement the boost::shared_ptr so that it works, by
> keeping the mappings between the objects and the counter in some sort
> of external data structure.  It isn't simple, however, since pointers
> to base objects don't always have the same address as pointers to
> derived objects.  And it does introduce a large degree of complexity.
> IMHO, this is too high a price to pay for being able to point to any
> object.  But opinions in this regard may vary.

[...snip...]
>>Well, if there is a particular point you don't understand, yet feel
>>is important, you could ask here.
>>
>
> I understand that the existing practice varies widely, and that there
> is no one universal solution.  I understand that at least one of the
> most widely used implementations doesn't work correctly, and results
> in the objects being prematurely destructed.
>
> What more do I have to understand in order to understand that the
> concept is not yet ripe for standardization?
[...snip...]

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

"Mike Schilling" <mscottschilling@hotmail.com> wrote...
> "Ken Alverson" <Ken@Alverson.com> wrote...
> > Now, the operating system isn't going to close our xml nodes on program
> > termination, but a finalizer might...
>
> I consider allowing xml to fall out of scope without being "close"d here
> pretty awful practice, as bad as lertting an open file objsct go out of
> scope. It is true that an open Java FileStream object is closed by its
> finalizer, but letting that happen is poor coding; a file (or an XML
> output mechanism) should be specifically closed when the program is
> done with it.

Don't get me wrong, the example was not meant to represent *good* code.  It
was just meant to represent code that would fail to operate as intended if
finalizers were not called.

If that example is too unbelievably bad for you, here's a somewhat more
passible one.  Say you have a long running server thread that writes a log
to disk, using a buffered stream, and that log is in some sort of structured
format.  At some point the server gets shut down, but the log is never
closed, so the buffer hasn't been flushed.  Since the buffer hasn't been
flushed, the log is in an inconsistant state (not only is it missing
entries, it's also cut off mid structured log entry).

Sure, you may say the server should have closed the log when it was shut
down, but sometimes things like that are missed...as far as I can tell that
is *the* reason for finalizers.  If you assume the developer always manually
cleans up all non-memory resources, what is the point of having finalizers
at all?

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                       ]

"Garry Lancaster" <glancaster@ntlworld.com> wrote in message news:<NSNN8.3745$69.136268@newsfep1-win.server.ntli.net>...

Concering garbage collection, I said...

> > It is part and parcel of g++.

> Interesting. I see the GCC's Objective-C compiler has a GC based on
> Boehm et al's, but I couldn't find any information about GC within
> g++ (gnu.org was being weird and Google didn't shed any light). One
> of the downsides of them being a non-commercial organization is that
> they do a lot of great stuff that you never hear about. Have you got
> a link for it?

Phil Edwards has suggested that it is actually there because it is
used for the Java.  I should have been clearer in my claims as well.
If you install gcc (with all of the compilers) normally, you will not
get garbage collection in C++ by default, or even with any of the
documented (or undocumented?) compiler switches.  But you do have a
copy of the Boehm collector, and unless they've somehow limited it,
you can use it with C++.  It *is* up to you to do the work to
configure it, however.

> > > When will you be submitting such a "GC" for evaluation by us
> > > all?

> > There was a proposal for the last round of standardization.  The
> > general feeling was that it came to late to be considered, and the
> > authors withdrew it.  Globally, it was a lot better formulated,
> > and a lot more detailed and precise, than many things that
> > actually made it into the final standard.  It was also based on
> > existing practice (the Boehm collector).

> Also interesting. I have seen the Stroustrup paper but if there is
> another one I'd appreciate a link or even just the paper number if I
> can still get it from the ISO site.

I've just changed jobs, and don't have all of my links handy here, but
I think if you do a search for "garbage collection C++ detlef ellis"
you should come up with something.  (Detlef and Ellis were the authors
of the proposal.)

More generally, you probably want to see David Chase's GC FAQ at
http://www.iecc.com/gclist/GC-faq.html.

--
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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.0206140554.62b38b1c@posting.google.com...

> > > What I said, however, was that it didn't work in real
> > > applications.

> "Garry Lancaster" <glancaster@ntlworld.com> wrote
> > Actually what you wrote originally was it "doesn't work in *quite a
> > number of* real programs" (my emphasis). What you just wrote makes
> > it sound like it doesn't work in *any*!
>
> "Quite a number" is more accurate.
>
> > That may not be what you intended it to mean, but that is the
> > inference that will be drawn when you write that something "doesn't
> > work". Had you just said it isn't suitable for all applications, we
> > wouldn't be having this (part of the) discussion.
>
> Doesn't work means simply that it doesn't work.  It reclaims the
> memory too early.

Isn't this a bit like saying that std::vector's elements disappear too
early, despite the fact that I've got pointers and references to them lying
about?

I could write "quite a number" of real programs using std::vector<> that
don't work. That doesn't mean std::vector<> can't be made to work in these
programs.

If you use any component in a way that contradicts its requirements, all
kinds of problems can result. I assert that Boost's shared_ptr can be made
to work in most of the cases you're referring to.

-Dave

P.S. I also understand the real dangers of manipulating raw pointers and
shared_ptrs in the same program -- that's why we have weak_ptr -- but I
think the way you're saying "doesn't work" is a bit linguistically skewed.


---
[ 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.0206140554.62b38b1c@posting.google.com...
> "Garry Lancaster" <glancaster@ntlworld.com> wrote in message
> news:<KZhM8.499$A62.65450@news11-gui.server.ntli.net>...
> > |>  James Kanze:
> > |>  > It depends on what you mean by a defect.
>
> > Garry Lancaster:
> > |>  A conservative definition could be: failure to meet
> > |>  specification or a self-inconsistent specification.  If you want
> > |>  to go a little further I won't quibble, but be explicit about
> > |>  what you mean. Saying it "doesn't work in quite a number of real
> > |>  programs" is too vague.
>
> > James Kanze:
> > > That's roughly what I would use for an implementation, and by that
> > > definition, the implementation of boost::shared_ptr doesn't have a
> > > defect.
>
> > > What I said, however, was that it didn't work in real
> > > applications.
>
> > Actually what you wrote originally was it "doesn't work in *quite a
> > number of* real programs" (my emphasis). What you just wrote makes
> > it sound like it doesn't work in *any*!
>
> "Quite a number" is more accurate.
>
> > > That doesn't necessarily mean the implementation is defective.
>
> > That may not be what you intended it to mean, but that is the
> > inference that will be drawn when you write that something "doesn't
> > work". Had you just said it isn't suitable for all applications, we
> > wouldn't be having this (part of the) discussion.
>
> Doesn't work means simply that it doesn't work.  It reclaims the
> memory too early.
>
> >From what I understand, the implementors are aware of this problem,
> and have decided that it isn't important.
>
> > If you don't wish to use shared_ptr,
>
> I'd rather use shared_ptr than some home built solution.  But it
> doesn't work in my applications.  It's not a question of what I want.
> If the thing deletes the object when there are still pointers to it,
> it doesn't work.
>
> > that is fine with me, but if you are going to imply that there is
> > some kind of problem with it you should be prepared to back up that
> > up with some kind of real example, preferably involving code, rather
> > than just vague or inaccurate generalizations.
>
> The examples are known.  I've presented them before, too.
>
> > (Who knows, someone might be able to solve the problem for you or it
> > might even help refine shared_ptr's design?)
>
> The solutions are known.  I don't know why they aren't used.
>
> Globally, however, after much experimenting, I've come to the
> conclusion that smart pointers don't really work in general, at least
> for memory management.  The *ONLY* more or less automatic solution
> which really works is garbage collection.
>
> > [snip]
>
> > > The problem is simple: my objects enrole themselves with other
> > > objects, e.g. for accepting events or for generating state change
> > > notifications.  In some cases (not all, of course), these other
> > > objects participate in the ownership of the object.
>
> > > This doesn't work with boost::shared_ptr.  It does work with every
> > > other reference counted pointer I've used.
>
> > On the contrary, what you describe is entirely possible with
> > boost::shared_ptr. Possibly there is some additional important
> > constraint that you have not disclosed. If you don't give a clear
> > example it is impossible to say.
>
> Try it, and you will find that the memory is freed too early.
>

I use boost::shared_ptr every day in basically the scenario you describe and
it works flawlessly. I seriously wonder what version of boost you are basing
your statements on.

> The situation occurs in many real programs.  The worst aspect of it is
> that the situation may only occur as a result of a modification, after
> the original program is fully committed to using shared_ptr.  For this
> reason, I strongly discourage any use of the boost::shared_ptr.
>
> Note that the reference counted pointer described in Scott Meyers
> doesn't have this problem.  It does require that the pointed to object
> derive from a special base class however.  This doesn't cause me any
> problems, but is unacceptable to others.
>
> It is possible to implement the boost::shared_ptr so that it works, by
> keeping the mappings between the objects and the counter in some sort
> of external data structure.  It isn't simple, however, since pointers
> to base objects don't always have the same address as pointers to
> derived objects.  And it does introduce a large degree of complexity.
> IMHO, this is too high a price to pay for being able to point to any
> object.  But opinions in this regard may vary.
>
> > |>  > But I'm not saying standardize my smart pointer, rather than
> > |>  > Boost's. I'm saying that the requirements on smart pointers
> > |>  > are complex enough that no one size fits all, and that they
> > |>  > probably shouldn't be standardized.
>
> > |>  This is not an argument against standardization: we don't say we
> > |>  shouldn't standardize vector because sometimes list is better,
> > |>  do we?
>
> > > The difference is that both vectors and lists are well understood
> > > concepts, with a large body of existing practice.  So it is pretty
> > > clear what is and is not needed.
>
> > > This is still far from being the case with regards to smart
> > > pointers.
>
> > Well, if there is a particular point you don't understand, yet feel
> > is important, you could ask here.
>
> I understand that the existing practice varies widely, and that there
> is no one universal solution.  I understand that at least one of the
> most widely used implementations doesn't work correctly, and results
> in the objects being prematurely destructed.
>
> What more do I have to understand in order to understand that the
> concept is not yet ripe for standardization?
>
> > As for not having a large body of existing practice, I would have
> > said the exact opposite is true: if there is one thing that the C++
> > world has no shortage of it is reference- counted smart pointer
> > implementations.
>
> Correct.  All different.  And none that really work for all, or even
> most of the cases.  Everyone is in favor of some sort of reference
> counted pointer, but no one agrees as to what sort.
>
> > > Do we really want to repeat the debacle of auto_ptr?
>
> > One of the problems that keeps cropping up with auto_ptr is that
> > people want to put them in the standard containers.  Their needs
> > would actually be satisfied much better by a reference-counted
> > pointer like shared_ptr.
>
> Just don't try and put a raw pointer into two containers of
> boost::shared_ptr:-).  Sounds a lot like the problem with auto_ptr.
>

I use boost::shared_ptr as part of a polymorphic xml node class hierarchy
and the pointers wind up in many standard containers when subtrees are
copied or moved between trees. I have never had any problem.

<snippage>

I find that smart pointers are useful for solving complex problems of
dynamically allocated object lifetime while still managing resources
correctly while GC ( primarily Java's but others I've seen as well ) is a
waste of clock cycles in an attempt to protect programmers from dangling
pointers. I use dtors to release all kinds of resources including memory,
database connections, thread locks, and file handles. In Java I have to
explicitly code some cleanup function that I must manually call to handle
this. In truly complicated cases of object ownership I wind up uses
reference counts inside the objects to control when to actually release the
acquired resources.

Let me state in the strongest possible terms what a mistake it would be to
not standardize at least 1 smart pointer and what a disaster it would be to
standardize any form of infinite memory GC.

Ken Shaw
Programming Manager
Computer Innovations
Chicago IL.


---
[ 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:
> Just don't try and put a raw pointer into two containers of
> boost::shared_ptr:-).

A-ha, finally all is clear. This is the source of your problems
with boost::shared_ptr. You must never do what you just
described. What you are supposed to do is something like this:

boost::shared_ptr<foo> p( new foo );

All subsequent shared_ptrs to the same object must be
direct or indirect copies of that shared_ptr without any
intervening raw pointer stage. Raw pointers to a shared_ptr-
controlled object should only be used as temporaries and
never to construct a new shared_ptr. For example, this is
very bad:

boost::shared_ptr<foo> p2( p1.get() );    // Don't do this!

I think Boost should document this behaviour more clearly.
If you are going to use boost::shared_ptr successfully you
need to understand it. But once you know it, it is relatively
simple to avoid the issue: any time you find yourself
calling a shared_ptr constructor or reset() with a raw pointer
that hasn't just come from a new expression, stop, pause
and reflect.

The object registry design you described previously can
of course be implemented successfully with shared_ptr
without falling into this trap (as long as there are no
relevant additional requirements you have not mentioned).

If you want a reference-counted pointer that doesn't have
this characteristic, you need an intrusive one, or perhaps a
non-intrusive one that uses factories to create new shared
objects. Both of these of course bring up a whole different
set of issues, although I am increasingly in favour of the
latter.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

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

> The solutions are known.  I don't know why they aren't used.

They are.

> Globally, however, after much experimenting, I've come to the
> conclusion that smart pointers don't really work in general, at least
> for memory management.  The *ONLY* more or less automatic solution
> which really works is garbage collection.

I'm curious.  Can you expand on this.  I know there are definate issues with
smart pointers.  But they don't work?

> Try it, and you will find that the memory is freed too early.
>
> The situation occurs in many real programs.  The worst aspect of it is
> that the situation may only occur as a result of a modification, after
> the original program is fully committed to using shared_ptr.  For this
> reason, I strongly discourage any use of the boost::shared_ptr.
>
> Note that the reference counted pointer described in Scott Meyers
> doesn't have this problem.  It does require that the pointed to object
> derive from a special base class however.  This doesn't cause me any
> problems, but is unacceptable to others.

This is what I referred to above when I said "They are."  This is a
relatively recent change, but check out the counted_base stuff in the
current Boost release.

> Maybe that's my problem with reference counted pointers.  They are a
> form of garbage collection.  A form that is hopelessly broken.

That's a bit harsh.  Such smart pointers have restrictions in their usage,
but that hardly makes them "hopelessly broken".

> Other than that, used judiciously, in a limited manner, they can
> sometimes be useful.  But their merits have been largely oversold.
> And of course, garbage collection solves all of the problems reference
> counted pointers do, only better.

But provide different tradeoffs that make the solution suboptimal in some
use cases.  Smart pointers aren't going to be replaced by GC, even if C++
gains a standard GC.

> This is probably where it will be most difficult to define what the
> standard should say.  IMHO, it would be very silly if a system
> supported garbage collection, and e.g. std::string and std::vector
> didn't use it for their own, internal memory management.  Except that
> there may be a very few, special cases, where I need the destructors
> of my object called immediately, when the vector is destructed.  (This
> is a non-issue for std::string, since the character type cannot have a
> non-trivial destructor.)

Since GC would be an optional part of C++, use in implementations would have
to be optional.  And a lot of users would refuse to use implementations that
use GC in their implementations of such standard components, and probably
with good reason.

Ignoring that, though, even if an implementation used GC for these
containers, I think the destructors for the contained objects would have to
be called (well, for containers of built in types, such as string and
wstring, specializations could avoid the overhead).  All that would be
garbage collected would be the raw memory allocated (which makes you wonder
if there'd be any reason to use GC in the implementation).

Bill Kempf

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

James Kanze [on GC in g++]:
> Phil Edwards has suggested that it is actually there because it is
> used for the Java.  I should have been clearer in my claims as well.
> If you install gcc (with all of the compilers) normally, you will not
> get garbage collection in C++ by default, or even with any of the
> documented (or undocumented?) compiler switches.  But you do have a
> copy of the Boehm collector, and unless they've somehow limited it,
> you can use it with C++.  It *is* up to you to do the work to
> configure it, however.

OK. Thanks for clarifying.

James Kanze [on a previous GC proposal]:
> I've just changed jobs, and don't have all of my links handy here, but
> I think if you do a search for "garbage collection C++ detlef ellis"
> you should come up with something.  (Detlef and Ellis were the authors
> of the proposal.)

Thanks. I actually already read this but I never realised
it was submitted as an ISO proposal.

> More generally, you probably want to see David Chase's GC FAQ at
> http://www.iecc.com/gclist/GC-faq.html.

Yes, good source.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---
[ 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 [on GC in g++]:
> Phil Edwards has suggested that it is actually there because it is
> used for the Java.  I should have been clearer in my claims as well.
> If you install gcc (with all of the compilers) normally, you will not
> get garbage collection in C++ by default, or even with any of the
> documented (or undocumented?) compiler switches.  But you do have a
> copy of the Boehm collector, and unless they've somehow limited it,
> you can use it with C++.  It *is* up to you to do the work to
> configure it, however.

OK. Thanks for clarifying.

James Kanze [on a previous GC proposal]:
> I've just changed jobs, and don't have all of my links handy here, but
> I think if you do a search for "garbage collection C++ detlef ellis"
> you should come up with something.  (Detlef and Ellis were the authors
> of the proposal.)

Thanks. I actually already read this but I never realised
it was submitted as an ISO proposal.

> More generally, you probably want to see David Chase's GC FAQ at
> http://www.iecc.com/gclist/GC-faq.html.

Yes, good source.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

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

"Daniel Miller" <daniel.miller@tellabs.com> wrote in message
news:3D04CCA2.3@tellabs.com...
>    I suspect that you are not requesting that I educate you about what a
> "destructor" or a "finalizer" is, nor about what "deterministism" versus
> "nondeterminism" is, but I will answer your question that way by
> decomposing your question into its piecemeal parts briefly.  If you
> truly are requesting an education, I suggest that you study up on those
> four terms outside of this newsgroup.

What I have problems with is your definitions of deterministic and
nondeterministic.

>    Definition of dtor: I am using the Standard C++ definition of
> "destructor".
>
>    definition of finalizer: I am using the Boehm collector's definition
> of "finalizer".
>
>    "deterministic [invocation]" in the context of this discussion:
> Guaranteed invocation as a direct by-product of certain stimuli defined
> in C++98

Which stimuli in C++98?  Since the Boehm collector is implemented using C++,
with the only non-standard extension of consequence being multiple-thread
support, it seems to me that the collection that most of us define as
nondeterministic with that collector occurs "as a direct by-product of
certain stimuli defined in C++98".

>    "nondeterministic [invocation]" in the context of this discussion:
> the lack of guarantees regarding invocation as a direct by-product of
> stimuli.  In lieu of guarantees, a statement is made that the
> invocations *might* occur at a later arbitrary time (or might not).

The emphasis on *might* is disengenious.  I think we're all in agreement
that the Java form of GC is, basically, broken and that finalizers must
*always* be invoked.  The question is when.  And with the presence of
ref-counting smart pointers and other memory management schemes in prevelant
use in C++ today, the definition of "deterministic" and "nondeterministic"
is at least a little bit in the grey area.  I think I know the proper
definition for both, but with the above mentioned schemes employed today I
can't see how true nondeterministic collection is any less problematic in
the domain you're discussing.

So, I *do* need an education.  Why, precisely, is GC such a terrible thing
to add to C++, especially as an optional library, even for embedded systems.
I can certainly see why you might choose not to use GC for certain things
(and the embedded arena would emphasise this greatly), but that's something
entirely different from what you appear to be arguing here.

Bill Kempf
>    The presence versus absence of guarantees is a clear cut difference.
>
> ---
> [ 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                       ]
>

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

William E. Kempf wrote:

> "Daniel Miller" <daniel.miller@tellabs.com> wrote in message
> news:3D013DC5.1090109@tellabs.com...
>
>>William E. Kempf wrote:
>>
>>
>>>"Garry Lancaster" <glancaster@ntlworld.com> wrote in message
>>>news:Rl5M8.4756$L66.620702@news6-win.server.ntlworld.com...
>>>
>>>
>>>>Alex Oren:
>>>>
>>[...snip...]
>>
>>>I'd agree with this as well, though it depends on circumstances.  If
>>>
> file
>
>>>handles are scarce, but still number in the 100s, a text editor can
>>>
> probably
>
>>>get away with having the handles collected when finalizers are run.
>>>
> This is
>
>>>especially true if we can tell the GC to start a collection phase if we
>>>
> fail
>
>>>to acquire a file handle.  On systems described by Daniel, however, I
>>>
> don't
>
>>>think I'd ever trust the GC to collect such resources in the finalizers.
>>>That's simply not an argument for not including GC, however.
>>>
>>   If a GC based on nondeterministic-invocation of finalizers were to be
>>standardized in C++0x, then concerns such as mine are important enough
>>to adopt such GC with certain rules in place that no standard library
>>require GC and that no portion of the standard require GC to be present
>>on a particular platform.  Specifically, I vigorously recommend that if
>>such GC is adopted into C++0x, that it be optional, capable of being
>>absent on certain platforms without causing major portions of the
>>standard libraries to go away too.  Numerous other standards have such
>>optional features and compliance is tracked via a PICS proforma.
>>
>
> I agree 100% that GC should be an optional feature.  That doesn't exactly
> equate to "no portion of the standard require GC to be present on a
> particular platform".  It may well be possible that some other *optional*
> portion of the standard could also depend on the presence of the optional GC
> system.  Threading support is going to result in the same thing here.
> Threading must be an optional library in the standard, but I can definately
> envision other libraries that *require* this optional library that may well
> be added to some future revision of the standard.  I don't disagree with
> what your saying, I just think you're stating it to strictly and with too
> much finality.

   I now see that I was sloppy with my wording.  I do not intend to
prohibit some library (say, hypothetically, some Standard Neural Network
Library) from using GC based on nondeterministically-invoked finalizers,
assuming that like the optional GC, this SNNL were also marked as
optional.  Permission of this cascade of conditionality is not fully
explicitly given dispensation in the wording "no portion of the standard
require GC to be present on a particular platform".

   Conversely, I stand by my original wording in this hypothetical
example.  No portion (e.g., SNNL which hypothetically uses GC) of the
standard shall require GC to be present on a particular platform.  The
cascade is implicitly handled even in the existing wording, but still I
should have stated it explicitly.

   I reword, not as proposed standards content, but as communicating an
expectation which C++0x can live up to or fail to live up to:  GC shall
not be required on a particular platform for any reason.  If GC is
required directly or indirectly by a set S of other components of the
standard, then each member of S shall not be required on a particular
platform for any reason.  Or more generally, for each optional portion o
of the standard, every portion of the standard which depends on o shall
also be optional and o shall not be interesting in general to embedded
realtime systems.

   (I.e., I think that we can safely assume that this hypothetical SNNL
is outside the embedded realtime space in current industrial practice.
But any threading library must not depend on GC, because MT is the forte
of realtime embedded software design.  Likewise, any protocol library
must not depend on GC, because protocols are widely used in embedded
systems composed of 2 or more processors.)

   In this posting I strictly limit the term "GC" to those
deallocation/reallocation systems which have finalizers invoked as part
of collection.  As usual in my postings, any smart-pointer technique
which invokes dtors only as a direct by-product of the app-domain
stimuli falls outside of my definition of 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                       ]

William E. Kempf wrote:

> "Daniel Miller" <daniel.miller@tellabs.com> wrote in message
> news:3D04CCA2.3@tellabs.com...
[...snip...]
>>   Definition of dtor: I am using the Standard C++ definition of
>>"destructor".
>>
>>   definition of finalizer: I am using the Boehm collector's definition
>>of "finalizer".
>>
>>   "deterministic [invocation]" in the context of this discussion:
>>Guaranteed invocation as a direct by-product of certain stimuli defined
>>in C++98
>>
>
> Which stimuli in C++98?


   Dtors are guaranteed to be invoked as a direct by-product of:
     1) end of scope
     2) invocation of delete
     3) throwing an exception

   The emphasis in my statements is on "direct by-product of".

>  Since the Boehm collector is implemented using C++,
> with the only non-standard


   The emphasis in my statements is not on nonstandard behavior.

> extension of consequence being multiple-thread
> support, it seems to me that the collection that most of us define as
> nondeterministic with that collector occurs "as a direct by-product of
> certain stimuli defined in C++98".


   Collection is a direct by-product of one stimulus in the Boehm
collector: invocation of the function requesting an immediate
collection.  But explicitly requesting a collection is not the typical
mode of operation.  The typical mode of operation is that collection
sweep occurs asynchronously from the app-domain marking stimuli.

> So, I *do* need an education.  Why, precisely, is GC such a terrible thing
> to add to C++, especially as an optional library, even for embedded systems.


   Remember that I define the term "GC" to be applicable to
finalizer-based collectors.  By retrofitting different end-of-lifetime
semantics via finalizers into a language which has since its early years
revolved around dtors for its end-of-lifetime semantics, there is much
opportunity for C++0x standardization to dangerously fly by the seat of
the pants (in auto_ptr style or in export keyword style or in
internationalization/locale/wchar_t style) with just-in-time incomplete
research, rather than standardize long-standing time-honored practices.

   We definitely do not need another incompletely thought-out auto_ptr,
nor another 6-year-and-running export keyword debate/debacle, nor
another incomplete/half-baked internationalization scheme.

   When jerking around an axiom system on which a school of thought is
founded, one must be prepared 1) for a house of cards falling down or 2)
a large amount of investigative analysis to decide whether the house of
cards might fall down.  When introducing a feature (either via the core
language or via libraries) such as finalizers which directly displace
certain invocations of dtors which are an extremely fundamental portion
of the C++ language and of the C++ culture, then one is grabbing the
house of cards by its axiom system and shaking hard.  Don't be surprised
if there are unintended consequences.  In short finalizers jerk around
the axioms on which my use of XAOP is founded: dtor invocation.

   During the C++98 standardization process, it was obvious that we in
the C++ community needed to standardize some form of containers library
because nearly every C++ source code base in the world either rolled
their own or bought RogueWave's Tools.h++ or used some other
Smalltalk-influenced container library for C++.  There was obvious
pent-up demand as witnessed by nearly every source code base in the
world.  Also, there was much pent-up criticism about needing to downcast
the void* (or Top*) pointer in the Smalltalk-style container classes.
More research was needed into containers.  That research was STL which
synthesized a new C++-centric view to containers, rather than merely
standardizing Smalltalk-style containers warts & all before that
research came to full fruition.

   This is the case for smart pointers which invoke dtors (i.e., without
finalizers).  Many C++ source-code bases in the world are once again
either rolling their own, using Loki's, using Boost's, or using GNU's.
There is obvious pent-up demand for smart pointers without finalizers.
Also, there is much pent-up criticism of a canonical smart-pointer's
inability to deal with cycles.  More research is now needed into
cycle-capable dtor-invoking smart-pointers.  We must not jump too
quickly to standardizing a finalizer philosophy which is foreign to C++
(which would have been analogous to standardizing Smalltalk-style
containers, pinching off STL research too soon).

   The case for finalizer-based GC is much weaker than C++'s containers
and much weaker than smart pointers.  Not every C++ source code base in
the world is rolling their own conservative garbage collector.  Not
every C++ source code base in the world is obtaining the Boehm
collector.  Not every C++ community is saying "Dang, these smart
pointers are an okay-but-broken prototype, but what they lack are
finalizers!"

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

Garry Lancaster wrote:

> Alex Oren:
>>   In the context of Boehm collector GC being discussed along various
>>branches of this thread,
>>
>
> On this branch, now, we are discussing possible
> C++ GC systems. Boehm's is just one example of
> prior art.


   The Boehm collector is a "possible C++ GC system" and thus very much
worthwhile discussing/critiquing despite any dismissiveness.


> [snip]
>
> Daniel Miller:
>
>>>>  GC applies only to pure-memory classes!  And then only those
>>>>pure-memory classes which by design strictly have no cascading RAII
>>>>impact on other objects, lest those cascading impacts in dtors never be
>>>>invoked, due to nondeterministic "finalization".
>>>>
>>[...snip...]
>>
>>
>>>>And then only if GC cooperates with VM in VM-equipped OSes.
>>>>
>>>>
>
>>>Can you explain what you mean by that?
>>>
>
>>   The posting to which you are responding provided that explanation in
>>#6 & #6's supporting paragraph which you might have missed while you
>>too-easily-dismissed it all as a "misconception".  Search for the
>>paragraph which contained the clause "Unless the VM layer can explicitly
>>reach out and prompt the GC mechanism to perform a garbage-collection at
>>the VM layer's volition".  And remember that I am discussing GC based on
>>nondeterministrically-invoked "finalizers", not about smart pointers &
>>allied techniques.
>>
>
> I'm afraid I still don't understand what you mean.


   What portions of GC vis-a-vis VM do you not understand?

>>>>Concurring with Alex's statements, I consider GC thoroughly
>>>>unacceptable for any class other than pure-memory classes
>>>>with trivial dtors.
>>>>
>>>>
>>>Whilst you are on the right track, I disagree with the
>>>absoluteness of this. Whilst I suspect many classes
>>>suitable for GC will fit this description, perhaps the
>>>majority, the C++ spirit has always been to let the
>>>programmer decide in cases where other
>>>languages might enforce draconian restrictions.
>>>
>>
>>   The C++ spirit has been to emphasize efficiency over automagical
>>features like GC.
>>
>
> Some people find virtual functions "automagical".


   Exceptions & virtual functions clearly have deterministic behavior in
that they are a direct by-product of an app-domain stimuli.
Nondeterministic finalizer-based GC does not have that property.

> Or exceptions. Many C++ features, including these
> two, have been accused of inefficiency.


   not by me.

> These views
> have often turned out to rest on a very narrow
> definition of efficiency. With GC, I am not one of those
> that claim it has generally superior run-time execution
> speed compared with non-GC memory management,
> although I am sure this is true for certain programs and
> a good GC algorithm. What I am thoroughly convinced
> of is that for a large set of programs it greatly improves
> development efficiency. And, provided it be optional,
> it therefore gives the developer more freedom to optimize
> for whichever kind of efficiency is most important to them.
>
>
>>The C++ spirit has been to be applicable to realtime
>>embedded systems, such as at telecommunications equipment manufacturers,
>>such as AT&T, which was an telecom equipment manufacturer Bjarne
>>Stroustrup's employer during the advent of C++.
>>
>
> As far as I am aware, he still works for them.


   Where "them" is AT&T, now a telecom service provider and cablecom
service provider, yes, he still works for them.  But where "them" is a
telecom equipment manufacturer as I was discussing, for the most part,
no, AT&T spun off Lucent as a separate company years ago as part of a
corporate strategy of focusing entire on the service-provider space by
exiting the equipment manufacturing (i.e., Lucent) space and by exiting
the general-purpose computer (i.e., NCR) space.

   I reiterate:  The C++ spirit is to specify a language which is
applicable to realtime embedded systems such as in the telecom
equipment-manufacturing industry.

> More relevantly,
> C++'s suitability for these kind of projects will not be
> altered by optional garbage collection. (For what it's
> worth, Stroustrup himself wrote a paper on how optional
> GC might be added to the language.)


   It will be most unfortunate if finalizer-based GC is added to C++, no
matter who the driving force is.  I shall continue to hope that the
resource-deallocation strategy of C++ will continue to not be based on
finalizers, but rather on dtors which are a direct by-product of
app-domain stimuli.


> [snip]
>
>
>>>>  XAOP = transaction-oriented programming: strict RAII plus C++
>>>>exceptions as a transaction-abort mechanism
>>>>
>>>>
>>>In a future C++ that supports optional GC, you would still
>>>be able to use all the transaction processing idioms you
>>>can use today. See misconception #1 again.
>>>
>>
>>   XAOP would be drastically eroded if dtor invocation is not
>>deterministic such as in nondeterministic Boehm collector finalizers.
>>
>
> You are still propagating misconception #1.


   And you are still mislabeling what I am saying a misconception
instead of harvesting & appreciating the pearl of wisdom which I am
sharing with you as a colleague.

> Whatever
> model of GC various people favour, no-one has suggested
> removing the existing memory management systems - those
> that support XAOP so well - from the language. Even in the
> (in my opinion, unlikely) scenario that Boehm's GC was
> adopted as the standard GC exactly as it is today, you would
> still be free to turn it off.


   I have never claimed that anything would be *removed*.  I am stating
that the distracting presence of finalizers as a competitor to &
displacer of dtors clouds RAII to the point that XAOP is eroded.


> Face it: an optional GC system is going to give you more
> memory management flexibility, not less.


   I don't want finalizer-based GC.  The presence of something which I
prohibit does not give me more flexibility.

   Likewise, I don't want cars made by manufacturer X because I find my
viewpoints aligned with the time-proven quality of car manufacturer Y.
If X adds a model which I find ugly or unsafe, my flexibility of choices
is not increased in any way.  Oh, great, yet another car from X which I
won't consider buying just like I wouldn't consider buying any of X's
other cars.  Matters become worse as X's unsafe vehicles are on the same
road along with my Y-manufactured car.  No matter how well-made my Y car
is and no matter how carefully I drive my Y-manufactured car, the
X-manufactured cars can run me off the road.
   This applies to software architectural principles as well.  If
finalizer-based GC is inappropriate for realtime embedded systems, its
normative presence in some C++ standard does not increase my flexibility
in any way.  Matters become worse as finalizer-base GC is
inappropriately used in commercial off-the-shelf software which is
admitted into the embedded system.  No matter how well-thought-out my
realtime embedded system is, lack of availability of nonGC alternatives
for certain COTS software impose further and further GC-based COTS
software on embedded systems.  It is a slippery slope indeed.

   Face it: finalizer-based garbage collectors are bleeding-edge
research where the impact of interaction between finalizers & dtors is
not well understood.
   In Hans Boehm's own words:  "It's not at all clear to me that
finalizers should be a language feature in the same sense that
destructors are.  ...  I have mixed feelings about whether objects
should be finalized by invoking the destructor or something else."

   If the standardized resource-deallocation technique is
finalizer-based GC (instead of dtor-invoking smart pointer):

   1) we have another analogue of incompletely-thought-out auto_ptr on
our hands.

   2) we have another analogue of export keyword on our hands.

   3) we have another analogue of half-baked
internationalization/locale/wchar_t on our hands.

   Each of which are cases where the standardization process performed
something akin to fly-by-the-seat-of-one's-pants academic research,
rather than culminating demonstrated existing practice in industry or
allowing existing practice to mature via ever-more-wise research.  The
existing C++ practice in industry is to use dtor-invoking smart pointers
instead of introducing another non-dtor lifetime-ending mechanism:
finalizers.

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

Garry Lancaster:
> > Whatever
> > model of GC various people favour, no-one has suggested
> > removing the existing memory management systems - those
> > that support XAOP so well - from the language. Even in the
> > (in my opinion, unlikely) scenario that Boehm's GC was
> > adopted as the standard GC exactly as it is today, you would
> > still be free to turn it off.

Daniel Miller:
>    I have never claimed that anything would be *removed*.  I am stating
> that the distracting presence of finalizers as a competitor to &
> displacer of dtors clouds RAII to the point that XAOP is eroded.

Let me get this straight: you wish to prevent other C++
programmers from having the choice of GC because,
even though you won't have to use it yourself, you would
be somehow "distracted" by it?

> > Face it: an optional GC system is going to give you more
> > memory management flexibility, not less.
>
>
>    I don't want finalizer-based GC.  The presence of something which I
> prohibit does not give me more flexibility.

You are not the only C++ programmer in the world.
Some of us would find GC useful. It would increase
flexibility for us, and it would not decrease it for you.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

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

Daniel Miller wrote:

[...contra/anti-GC-stuff...]

>    1) we have another analogue of incompletely-thought-out auto_ptr on
> our hands.

Uhmm. Y'know, I'd personally probably be quite happy to have a
couple of NEW standard auto_ptr-like things ["another analogue"]
with 'move' semantics in addition to the current "incompletely-
thought-out auto_ptr on our hands"; e.g.:

1. auto_ptr-like thing with UNLOCK 'release-ownership' semantics
   instead of the standard 'delete'-thing. This one is supposed to
   be used as 'purely' thread-private thing that, I guess, could be
   quite useful with regards to e.g. mutable lazy singletons, I think.

2. auto_ptr-like thing with UNREF 'release-ownership' semantics
   instead of the standard 'delete'-thing with something like
   'blahblah_ptr<X> clone()' method (or something like that) that
   could be used for explicit ADDREFs to share ownership with someone
   else. This one might be quite helpful with regards to f.ex.
   minimization of the number of 'intermediate' addref/unrefs calls
   using 'classic' shared_ptrs -- somewhat expensive thing with
   THREADS added into play and w/o having some 'optimizations' like
   that, I think. Well, I'm somewhat aware of various 'move'-things
   like src_shared_ptr.swap( dst_shared_ptr ).reset(); [etc.], but
   I'd probably prefer to have 'move' semantics made as the 'default'
   [operator=(T&)+T(T&)+T(blahblah_ref<T>)] for *ALL* standard smart
   ptrs -- including 'shared-ownership' ones... issues w.r.t. the
   *standard* library containers aside, though. ;-)

Or am I just missing something -- some others even more useful
auto_ptr like  'additions' or perhaps some subtle reasons why
that should NOT be done?

regards,
alexander.

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

Daniel Miller:
> >>   Definition of dtor: I am using the Standard C++ definition of
> >>"destructor".
> >>
> >>   definition of finalizer: I am using the Boehm collector's definition
> >>of "finalizer".
> >>
> >>   "deterministic [invocation]" in the context of this discussion:
> >>Guaranteed invocation as a direct by-product of certain stimuli defined
> >>in C++98

William E. Kempf:
> > Which stimuli in C++98?

Daniel Miller:
>    Dtors are guaranteed to be invoked as a direct by-product of:
>      1) end of scope
>      2) invocation of delete
>      3) throwing an exception
>
>    The emphasis in my statements is on "direct by-product of".

You missed out explicit calls of destructors and, for globals,
normal program exit.

> >  Since the Boehm collector is implemented using C++,
> > with the only non-standard
>
>
>    The emphasis in my statements is not on nonstandard behavior.
>
> > extension of consequence being multiple-thread
> > support, it seems to me that the collection that most of us define as
> > nondeterministic with that collector occurs "as a direct by-product of
> > certain stimuli defined in C++98".
>
>
>    Collection is a direct by-product of one stimulus in the Boehm
> collector: invocation of the function requesting an immediate
> collection.
>
> But explicitly requesting a collection is not the typical
> mode of operation.  The typical mode of operation is that collection
> sweep occurs asynchronously from the app-domain marking stimuli.

Even Boehm's collector calls delete (or moral equivalent) internally.
And large parts of most well-written C++ applications do not call
delete directly, but rather rely on encapsulated library code to do
the job. In practice the actual application level stimulus that
causes the destructor to run can be equally obscure in non-GC
and GC cases. You can only be assured of seeing the direct
stimulus if you look into the libraries, and in that case, you can
see it for GC too. There is no clear-cut difference here.

> > So, I *do* need an education.  Why, precisely, is GC such a terrible
thing
> > to add to C++, especially as an optional library, even for embedded
systems.
>
>
>    Remember that I define the term "GC" to be applicable to
> finalizer-based collectors.

This doesn't make sense. Earlier you wrote:

'definition of finalizer: I am using the Boehm collector's definition
of "finalizer"'

So, it seems that any system that doesn't follow Boehm's
definition of finalizer is not to be considered, by you, to
be a GC system!

The main problem here is that when adding optional
GC to C++ is suggested, people automatically jump to
the conclusion that it will be a copy of some existing
well-known kind of GC. Usually it's Java, but Boehm
seems to be another popular chioce.

Boehm's system is good, but it is not a particularly great
fit for C++ standardization as it was originally designed for use in
C without any special compiler support. The finalizer system
is a case in point. It is set up using global function pointers, so
some jiggery-pokery is required to get it to call a destructor or
other member function. Moreover, as both Bill Kempf and I
have said, we want a C++ system that guarantees all destructors
be called eventually, and it seems that Boehm's system may
not offer this guarantee

To summarise, to be acceptable to me a C++ GC must be:

1. Optional in the sense that programmers can choose to
use it or not use it as they see fit. (Ideally, I would like to
be able to mix GC and non-GC heap allocation in the same
program.)

2. Does not remove any existing memory management
techniques from the language.

3. Capable of collecting data structures containing cyclic
references (without requiring additional programmer
intervention e.g. weak back pointers).

4. Guarantees that all destructors of GC objects are called
eventually (except in the case of abnormal program termination).

Using *that* definition of GC, what is wrong with it?

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

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

"Daniel Miller" <daniel.miller@tellabs.com> wrote in message
news:3D052272.7060302@tellabs.com...
> William E. Kempf wrote:
>
> > "Daniel Miller" <daniel.miller@tellabs.com> wrote in message
> > news:3D04CCA2.3@tellabs.com...
> [...snip...]
> >>   Definition of dtor: I am using the Standard C++ definition of
> >>"destructor".
> >>
> >>   definition of finalizer: I am using the Boehm collector's definition
> >>of "finalizer".
> >>
> >>   "deterministic [invocation]" in the context of this discussion:
> >>Guaranteed invocation as a direct by-product of certain stimuli defined
> >>in C++98
> >>
> >
> > Which stimuli in C++98?
>
>
>    Dtors are guaranteed to be invoked as a direct by-product of:
>      1) end of scope
>      2) invocation of delete
>      3) throwing an exception
>
>    The emphasis in my statements is on "direct by-product of".

Yes, but we're discussing heap allocated objects, for which only (2)
applies.  RAII wrappers, such as std::auto_ptr<> can invoke delete for you,
but whether or not it does so in a manner that's easily deterministic is
completely dependent on the design of the wrapper.  The boost::shared_ptr<>,
though technically deterministic since you know it will be deleted
immediately when the last reference goes away, is still close enough to
non-deterministic to be problematic in XAOP uses.  I've created a gc_ptr<>
that goes even further to remove the determinism here.  These are pure, 100%
C++98 conformant, solutions.  So, as I've said in this thread before, I
don't see how adding GC to the C++ language changes things for you in any
way.

> >  Since the Boehm collector is implemented using C++,
> > with the only non-standard
>
>    The emphasis in my statements is not on nonstandard behavior.

I realize that.  The point, however, is that with heap based objects only
(2) applies, and when conformant code calls delete is not necessarily
deterministic.  It's only careful (though simple and common) usage patterns
that can insure the deletions are deterministic in your applications.  The
presence of GC won't change this.

> > extension of consequence being multiple-thread
> > support, it seems to me that the collection that most of us define as
> > nondeterministic with that collector occurs "as a direct by-product of
> > certain stimuli defined in C++98".
>
>    Collection is a direct by-product of one stimulus in the Boehm
> collector: invocation of the function requesting an immediate
> collection.  But explicitly requesting a collection is not the typical
> mode of operation.  The typical mode of operation is that collection
> sweep occurs asynchronously from the app-domain marking stimuli.

The collection occurs based on stimulus (2) (well, at least with the same
sort of stimulus since the implementation replaces new/delete, but this
replacement is no different then the replacement of new/delete with an
allocator... so your (2) above was a little too strictly defined).  The
stimulus is "sort of" taken out of the control of the application developer,
but it's the same stimulus.  I say "sort of" for three reasons:  you can
chose to use the stack or the uncollected heap instead of the collected
heap, you can call delete on objects put on the collected heap which causes
an immediate collection of that object and is no different then if the
object had been on the uncollected heap, and finally you can call
GC_gcollect (hope I've got that right... I'm only superficially familiar
with the Boehm collector) to cause the collector to run at specific points
in the code.

So, again, I fail to see why GC is so problematic in your eyes that you'll
strictly forbid its use universally.

> > So, I *do* need an education.  Why, precisely, is GC such a terrible
thing
> > to add to C++, especially as an optional library, even for embedded
systems.
>
>    Remember that I define the term "GC" to be applicable to
> finalizer-based collectors.

Then define "finalizer-based collectors".  My view point is that any GC
system that does not invoke finalizers is broken.  Just as broken as an
application based on XAOP design that relies on the non-deterministic
finalization of such a system.  But this does not mean that GC is bad, nor
that GC can't be used even in XAOP designed systems.

>  By retrofitting different end-of-lifetime
> semantics via finalizers into a language which has since its early years
> revolved around dtors for its end-of-lifetime semantics, there is much
> opportunity for C++0x standardization to dangerously fly by the seat of
> the pants (in auto_ptr style or in export keyword style or in
> internationalization/locale/wchar_t style) with just-in-time incomplete
> research, rather than standardize long-standing time-honored practices.

GC is a long-standing and time-honored practice, even in C++, thanks to the
Boehm collector and others.  I really don't think it can be compared to
auto_ptr/export/internationalization support additions.

>    We definitely do not need another incompletely thought-out auto_ptr,
> nor another 6-year-and-running export keyword debate/debacle, nor
> another incomplete/half-baked internationalization scheme.

And I don't believe the addition of GC would be in the same league.

>    When jerking around an axiom system on which a school of thought is
> founded, one must be prepared 1) for a house of cards falling down or 2)
> a large amount of investigative analysis to decide whether the house of
> cards might fall down.  When introducing a feature (either via the core
> language or via libraries) such as finalizers which directly displace
> certain invocations of dtors which are an extremely fundamental portion
> of the C++ language and of the C++ culture, then one is grabbing the
> house of cards by its axiom system and shaking hard.  Don't be surprised
> if there are unintended consequences.  In short finalizers jerk around
> the axioms on which my use of XAOP is founded: dtor invocation.

I don't agree with this analysis, and don't think the years of existing
practice bear you out on this.  Unless there's something specific you see
that you've not articulated well in this discussion, I can't understand your
fear.

>    During the C++98 standardization process, it was obvious that we in
> the C++ community needed to standardize some form of containers library
> because nearly every C++ source code base in the world either rolled
> their own or bought RogueWave's Tools.h++ or used some other
> Smalltalk-influenced container library for C++.  There was obvious
> pent-up demand as witnessed by nearly every source code base in the
> world.  Also, there was much pent-up criticism about needing to downcast
> the void* (or Top*) pointer in the Smalltalk-style container classes.
> More research was needed into containers.  That research was STL which
> synthesized a new C++-centric view to containers, rather than merely
> standardizing Smalltalk-style containers warts & all before that
> research came to full fruition.

Again, I don't see the point you're trying to make.  GC is as well
understood as containers, and there are several C++ collectors that have had
more use then the STL had at the time the standard adopted it.  So, taking
this paragraph as is (i.e. out of context with the fears you've given
elsewhere), it would appear that the analogy is an argument *FOR* the
adoption of a GC system by the C++ standard.

>    This is the case for smart pointers which invoke dtors (i.e., without
> finalizers).  Many C++ source-code bases in the world are once again
> either rolling their own, using Loki's, using Boost's, or using GNU's.
> There is obvious pent-up demand for smart pointers without finalizers.
> Also, there is much pent-up criticism of a canonical smart-pointer's
> inability to deal with cycles.  More research is now needed into
> cycle-capable dtor-invoking smart-pointers.  We must not jump too
> quickly to standardizing a finalizer philosophy which is foreign to C++
> (which would have been analogous to standardizing Smalltalk-style
> containers, pinching off STL research too soon).

I can point you to at least 3 smart pointer implementations that can deal
with cycles.  Most of them are fairly new, and there are tradeoffs that
exist when using smart pointers instead of a full GC system.  On the other
hand, I can point you to several GC systems in C++, many of which have been
around for years and have been used in real applications, and for which we
have a lot of research into the pros and cons of the implementations and
designs.  I must also point out that the MC++ compiler for .NET provides
garbage collection which uses the destructor as the finalizer.  We have a
lot more existing practice here then we did for, say, std::auto_ptr.

>    The case for finalizer-based GC is much weaker than C++'s containers
> and much weaker than smart pointers.  Not every C++ source code base in
> the world is rolling their own conservative garbage collector.  Not
> every C++ source code base in the world is obtaining the Boehm
> collector.  Not every C++ community is saying "Dang, these smart
> pointers are an okay-but-broken prototype, but what they lack are
> finalizers!"

I don't agree.  Most people I know have struggled at least once with using a
smart pointer that didn't handle cycles.  The solutions (such as careful use
of weak pointers) have often resulted in code that was at least as complex
as developing a mark-and-sweep collector.  This has lead to many people
rolling smart pointers that use mark-and-sweep (or other) algorithms.  Then
use of such smart pointers usually leads to the conclusion that there are
tradeoffs between such concepts and full conservative garbage collectors,
and for some use cases the smart pointer is not "good enough".

I also note that most of these developers are talented C++ programmers that
understand RAII and refuse to give it up for languages that only provide GC,
such as Java.  But just as large of a segment of C++ developers are those
that see it is a serious deficiency that C++ lacks GC while most modern
languages do not.  Whether they are right or wrong (it's a little of both,
IMHO) is irrelevant... the C++ standards committee must at least consider GC
for the next revision, at least in part because of this attitude of such a
large base of users.

Bill Kempf

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

"Daniel Miller" <daniel.miller@tellabs.com> wrote in message
news:3D0531FC.7040803@tellabs.com...

>    I have never claimed that anything would be *removed*.  I am stating
> that the distracting presence of finalizers as a competitor to &
> displacer of dtors clouds RAII to the point that XAOP is eroded.

This is the crux of the disagreement, I think.  The above is FUD, with no
data to back it up.  Is it possible that this fear may turn out to be
correct?  Yes, but I doubt it.  Especially in domains such as yours where
XAOP is so important and RAII provides a cleaner solution then those
employed by other GCed languages.  Just because I have a fancy new
screwdriver in my toolbox does not mean I choose to use it over the rusty
old hammer I have when the job at hand is to drive a nail.  (Note:  I
exagerated this analogy for illustration purposes... I don't view GC as a
shiny new tool and RAII as a rusty old one.  In practice, I, like most other
C++ developers I believe, will normally choose the more traditional C++
memory management options, reserving GC for those cases where cycles are
prevelant.)

In another part of this thread you've carried this fear to the extreme, with
concern that the standard will require unrelated concepts, such as
threading, to rely on the optional GC system.  Even if there's a chance that
the general programmer base is naive enough to "cloud RAII to the point that
XAOP is eroded", I think there's no chance the committee will allow GC to
unduly influence concepts that do not require it.

Bill Kempf

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

Craig Powers wrote:
>>A second thing that bugs me about it is the fact that the
>>implementations are no longer nice little concrete classes. Instead
>>they're templates: the set of C++ implementations that handle templates
>>is still smaller than the set of all C++ implementations. What's more,
>>they have inheritance baggage (a vtable). That means that if you write
>>an app to use one and only one implementation, you either pay for the
>>unneeded structure or you perform the unnatural act of deriving it from
>>an empty class.
>
>
> Well, when we're discussing additional things going into the
> standard, I'm not so sure we need to consider implementations that
> don't handle (this subset of) template functionality.  Is it realistic
> to expect that an implementation would, in the future, support the
> extension you proposed but not templates?

Probably not.

What's important to me, though, is being able to create and use the very
primitive (simple and portable) concrete version of the class, then
being able to recycle the work that it represents in a more mature
(intricate and flexible) scheme.

As things sit now, the primitive version is likely to contain the real
work, while the mature version is just a bunch of annoying forwarding
functions. If the feature gets adopted, the mature version will be far
easier to create.

>
> Regarding the the vtable - Interface has a virtual function, so
> Realization will wind up with a vtable regardless.  Does having a
> vtable in Implementation increase the size of the vtable in
> Realization?
>

It's not the size of the vtable that can be an issue, but its very
existence. In the approach that this feature would directly support, the
simple concrete classes have no vtable at all.

>
>>The third thing that bugs me about is the fact that the structure has to
>>have been known at the time that the implementation was created. That
>>makes the approach unsuitable as a retrofit. I first stumbled on this
>>technique while salvaging a trusty old communications library.
>>Everything about that library was "right" except that there was no sane
>>way to extend it.
>
>
> This is a definite drawback to the template method and a spot where the
> new language feature appears to have a definite advantage.

I agree.

Let me try to sell you on some of the other advantages though.

class Abstract_Interface {...}
class Concrete_Implementation {...}
class Realization
:
   public Abstract_Interface,
   public Concrete_Implementation
{
}

In an impoverished environment, or one in which the virtual function
call overhead is not acceptable, the user sticks to the
Concrete_Implementation. Since it's the Concrete_Implementation that
contains the real work, there is utility in reusing the code.

In other environments, the user can exercise the full structure.
Factories are aware of the various available Realizations, and they are
responsible for selecting the correct one: the rest of the system simply
relies on the Abstract_Interface.

As things sit, a library creator has these options:

1) Support only the impoverished or high performance situations. Least
common denominator. Makes evolution of the code more difficult because
inheritance and templates are deliberately avoided.

2) Support only the richer or less performance intensive situation.
Makes library unusable in impoverished situations, and unsuitable in
high performance situations.

3) Support both situations. Requires the creation of a bunch of annoying
forwarding functions.

If the new feature were added, choice three would be easier and
therefore more common. I think it's an important piece of the code reuse
puzzle that has been missing to date, and that adding it would be a real
boon to code reuse (including some legacy code).

--
I <3 Comeau C++: http://www.comeaucomputing.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                       ]

Garry Lancaster wrote:

[...snip...]
> Boehm's system is good, but it is not a particularly great
> fit for C++ standardization as it was originally designed for use in
> C without any special compiler support. The finalizer system
> is a case in point. It is set up using global function pointers, so
> some jiggery-pokery is required to get it to call a destructor or
> other member function. Moreover, as both Bill Kempf and I
> have said, we want a C++ system that guarantees all destructors
> be called eventually, and it seems that Boehm's system may
> not offer this guarantee
>
> To summarise, to be acceptable to me a C++ GC must be:
>
> 1. Optional in the sense that programmers can choose to
> use it or not use it as they see fit. (Ideally, I would like to
> be able to mix GC and non-GC heap allocation in the same
> program.)
>
> 2. Does not remove any existing memory management
> techniques from the language.
>
> 3. Capable of collecting data structures containing cyclic
> references (without requiring additional programmer
> intervention e.g. weak back pointers).
>
> 4. Guarantees that all destructors of GC objects are called
> eventually (except in the case of abnormal program termination).
>
> Using *that* definition of GC, what is wrong with it?


   i.e., Using THAT DEFINITION OF A DESIRED-STATE FOR A *HYPOTHETICAL*
GC WHICH HAS NO EXISTIHNG INSTANTIATION YET, what is wrong with it?

   The most obvious thing wrong is that such a utopian GC does not yet
exist or, if it does exist for C++, it is not yet widely-known.  When
will you be submitting such a "GC" for evaluation by us all?  If not
from you, then from whom instead?  There darned well better be such a
technique used in practice for multiple years before standardization,
lest we have another repeat of the export keyword fiasco, regarding
something which was standardized 4 years before its first existence
which still has yet to receive any industrial experience for evaluation
of merit.

   Because the term "finalizer" is absent and because dtors would
apparently serve as the sole end-of-lifetime dismantling mechanism, I
would be very much interested in evaluating such a technique before
judging it.  Until such a utopian GC exists, I will continue using the
Boehm collector as the referent for my criticisms of GC.

   By the way, #1 is a red herring (i.e., merely pretty-sounding words
which distract us from the primary deleterious ramification) if the
popularity/frequency of (mis)application of GC is so great that a design
cannot prohibit it without also prohibiting the vast majority of COTS
libraries & infrastructure.  When one has a hammer (i.e., GC) in one's
hand, everything looks like a nail to some habit-minded people.  I
predict that GC will be overused and misapplied, displacing what has
been one of the greatest strengths of the C++ community for nearly 2
decades (of the C community for longer than that): overt design
attention paid to resource deallocation & lifetime.

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

William E. Kempf wrote:

> "Daniel Miller" <daniel.miller@tellabs.com> wrote in message
> news:3D0531FC.7040803@tellabs.com...
>
>
>>   I have never claimed that anything would be *removed*.  I am stating
>>that the distracting presence of finalizers as a competitor to &
>>displacer of dtors clouds RAII to the point that XAOP is eroded.
>>
>
> This is the crux of the disagreement, I think.  The above is FUD, with no
> data to back it up.


   Oh, so do you in fact have a utopian GC which would like to recommend
to us all which is today demonstrating the entire desired-state of the
GC feature-set in industrial practice?  Where may I obtain today this
existing utopian GC for evaluation?  Where may J16/WG21 obtain today
this existing utopian GC for standardization by evaluating its
established industrial practice?

>  Is it possible that this fear may turn out to be
> correct?

 > Yes, but I doubt it.
[...snip...]

   Is it possible that a utopian GC will be able to balance all of the
trade-offs perfectly to achieve every one of its lofty goals?  Maybe,
maybe not.  Time will tell, as would observation of the industrial
practice of using that utopian GC prior to standardization.

   Aren't we both (rightfully) out on a limb here predicting the future?
  Aren't we both (rightfully) discussing a spectrum of possible futures?
  I know that I am trying to point out the undesirable states so that we
steer clear of them.  You and Garry Lancaster are describing the desired
state and especially the benefits of a hypothetical desired-state GC.
Both positive & negative viewpoints (as well as proponent & contrarian
viewpoints) must be presented in public forums to let the community know
1) the expectations of GC to be satisfied as a goal and 2) the fears of
GC to be avoided as a goal.  Such diversity of free speech is the nature
of public forums (as well as the benefit).

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

Daniel Miller <daniel.miller@tellabs.com> writes:

|>     I am very much in favor of pushing the envelope of research
|>  into smart pointers and allied techniques---either library-based
|>  ones or core-language compiler-implemented ones.  I don't like to
|>  use the term "GC" for smart pointers & allied techniques because
|>  "GC" often implies nondeterministic-invocation of finalizers
|>  instead of smart-pointers' deterministic-invocation of dtors.

The smart pointers I've used do NOT imply deterministic invocation of
destructors in the general case, at least no more so than GC.  (There
is a certain sense in which everything in the program is
deterministic, of course.)  It's true that std::auto_ptr is relatively
deterministic; if the auto_ptr owns the object, the object is
destructed when the auto_ptr is destructed.  But such is not the case
of booch::shared_ptr, nor of any other reference counted pointer --
the object may or may not be destructed when the pointer is
destructed, and in the general case, you can't know which it will be.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

"Garry Lancaster" <glancaster@ntlworld.com> wrote in message
news:9BiN8.5804$lQ.29730@newsfep1-win.server.ntli.net...
>
> To summarise, to be acceptable to me a C++ GC must be:
>
> 1. Optional in the sense that programmers can choose to
> use it or not use it as they see fit. (Ideally, I would like to
> be able to mix GC and non-GC heap allocation in the same
> program.)
>
> 2. Does not remove any existing memory management
> techniques from the language.
>
> 3. Capable of collecting data structures containing cyclic
> references (without requiring additional programmer
> intervention e.g. weak back pointers).
>
> 4. Guarantees that all destructors of GC objects are called
> eventually (except in the case of abnormal program termination).
>

Can you exaplin the reasoning behind number 4?   What are you picturing a
finalizer doing that program termination wouldn't do?

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

"Mike Schilling" <mscottschilling@hotmail.com> wrote in message
news:8YAN8.6432$rG6.507512155@newssvr13.news.prodigy.com...
> "Garry Lancaster" <glancaster@ntlworld.com> wrote in message
> news:9BiN8.5804$lQ.29730@newsfep1-win.server.ntli.net...
> >
> > 4. Guarantees that all destructors of GC objects are called
> > eventually (except in the case of abnormal program termination).
>
> Can you exaplin the reasoning behind number 4?   What are you picturing a
> finalizer doing that program termination wouldn't do?

That's easy...any non operating system cleanup.  Simple example:

hypothetical_xml_output_mechanism* xml = foo();
xml.BeginNode("mynode");
  xml.CreateAttribute("bar","baz");
  xml.BeginNode("subnode");
    xml.CreateText("hum de dum dum");
// xml falls out of scope

Now, the operating system isn't going to close our xml nodes on program
termination, but a finalizer might...

Another example?  The OS isn't going to flush non-OS file buffers (like a
stream buffer that is managed by the usermode code)

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                       ]

Garry Lancaster wrote:
>
> To summarise, to be acceptable to me a C++ GC must be:
>
> 1. Optional in the sense that programmers can choose to
> use it or not use it as they see fit. (Ideally, I would like to
> be able to mix GC and non-GC heap allocation in the same
> program.)
>
> 2. Does not remove any existing memory management
> techniques from the language.
>
> 3. Capable of collecting data structures containing cyclic
> references (without requiring additional programmer
> intervention e.g. weak back pointers).
>
> 4. Guarantees that all destructors of GC objects are called
> eventually (except in the case of abnormal program termination).
>
> Using *that* definition of GC, what is wrong with it?

(1) It adds a completely unnecessary feature to the language, wasting
compiler developers' time and effort in implementing it. We already
have a perfectly good resource management method: RAII. Adding GC would
add gratuitous complexity to the language to absolutely no advantage.

(2) Programmers being what they are, I can predict with absolute 100%
rock solid certainty that we will end up with a hell of a lot of 3rd
party libraries that gratuitously require GC. This means that we will
either be forced to use GC whether we want to or not (to the
accompaniment of a nosedive in software reliability as resource
management becomes far more difficult), or those of us who won't
compromise quality to follow the fad will be locked out of using all
those libraries.

(3) If the C++ standard puts its "stamp of approval" on GC, it will be
helping to mislead yet another generation of programmers into thinking
it's a good idea. A philosophy of "assume the programmer knows what
they're doing" is one thing, and not trying to prevent bad code is one
of C++'s greatest strengths. Actively _encouraging_ bad code is quite
another thing.

--
Ross Smith ..................................... Auckland, New Zealand
r-smith@ihug.co.nz ...................................................

  "Never underestimate the power of stupid things in large numbers."
                                                      -- Serious Sam

---
[ 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 wrote:
>
> "Mike Schilling" <mscottschilling@hotmail.com> wrote in message
> news:8YAN8.6432$rG6.507512155@newssvr13.news.prodigy.com...
> > "Garry Lancaster" <glancaster@ntlworld.com> wrote in message
> > news:9BiN8.5804$lQ.29730@newsfep1-win.server.ntli.net...
> > >
> > > 4. Guarantees that all destructors of GC objects are called
> > > eventually (except in the case of abnormal program termination).
> >
> > Can you exaplin the reasoning behind number 4?   What are you picturing a
> > finalizer doing that program termination wouldn't do?
>
> That's easy...any non operating system cleanup.  Simple example:
>
> hypothetical_xml_output_mechanism* xml = foo();
> xml.BeginNode("mynode");
>   xml.CreateAttribute("bar","baz");
>   xml.BeginNode("subnode");
>     xml.CreateText("hum de dum dum");
> // xml falls out of scope
>
> Now, the operating system isn't going to close our xml nodes on program
> termination, but a finalizer might...
>
> Another example?  The OS isn't going to flush non-OS file buffers (like a
> stream buffer that is managed by the usermode code)

http://groups.google.com/groups?selm=3CB18FDE.93636516%40web.de
(Subject: Re: C++ and threads)

"....
 http://www.opengroup.org/onlinepubs/007904975/xrat/xsh_chap02.html#tag_03_02_09

 "It was suggested that the cancelation cleanup handlers
  should also be called when the process exits or calls
  the exec function. This was rejected partly due to the
  performance problem caused by having to call the cancelation
  cleanup handlers of every thread before the operation could
  continue. The other reason was that the only state expected
  to be cleaned up by the cancelation cleanup handlers would
  be the intraprocess state. Any handlers that are to
  clean up the interprocess state would be registered with
  atexit ()."

 And, BTW, C++ provides a mechanism for *EMERGENCY* cleanup
 as well... that's *terminate handlers*, ...."

regards,
alexander.

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

Daniel Miller <daniel.miller@tellabs.com> wrote in message
news:<3D065552.5070603@tellabs.com>...
> William E. Kempf wrote:

> > "Daniel Miller" <daniel.miller@tellabs.com> wrote in message
> > news:3D0531FC.7040803@tellabs.com...

> >>   I have never claimed that anything would be *removed*.  I am
> >>stating that the distracting presence of finalizers as a
> >>competitor to & displacer of dtors clouds RAII to the point that
> >>XAOP is eroded.

> > This is the crux of the disagreement, I think.  The above is FUD,
> > with no data to back it up.

>    Oh, so do you in fact have a utopian GC which would like to
> recommend to us all which is today demonstrating the entire
> desired-state of the GC feature-set in industrial practice?  Where
> may I obtain today this existing utopian GC for evaluation?  Where
> may J16/WG21 obtain today this existing utopian GC for
> standardization by evaluating its established industrial practice?

Nothing is utopian where C++ is concerned, but if you want a fully
working garbage collection for C++, which meets most or all of the
expressed requirements, all you have to do is download the current
version of g++.  Because g++ comes with an optional garbage collector.

On a completely different tact, what you have said about XAOP has me
very interested.  A web search with Google, however, failed to turn up
anything interesting.  Could you please post a few URL's to get me
started.

--
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

Alex Oren <response@myrealbox.com> writes:

|>  On Tue, 4 Jun 2002 15:56:39 GMT, James Kanze wrote in
|>  <86hekjjcte.fsf@alex.gabi-soft.de>:

|>  > My conclusion, for the moment, is that you still have to think
|>  > about what you are doing, that a variety of smart pointers are
|>  > necessary, as well as some use of raw pointers, and that as a
|>  > result, I really don't think we should standardize any smart
|>  > pointer.

|>  I respectfully disagree.

|>  As long as we have a standardized auto_ptr, a lot programmers are
|>  going to try to use it whether it is the most appropriate smart
|>  pointer for the problem or not.

Well, I certainly agree with that.  I just don't know of any way we
can get rid of auto_ptr.

|>  I think that the standard should include several smart pointer
|>  types that are appropriate for different types of problems.

|>  I don't know whether Boost [scoped_ptr, scoped_array, shared_ptr,
|>  shared_array, weak_ptr] are the best implementations but something
|>  similar to that set should be in the standard.

And therein lies the crux of the problem.  Unless it is eminently
clear, based on existing practice, what is needed, we shouldn't
standardize.  Because you can't change the standard if what you decide
turns out to be a mistake.  For the moment, there is not sufficient
existing practice with regards to smart pointers to know what is
really needed.  I use two, regularly: a reference counted pointer
based on Scott Meyers, and a managed pointer which works more or less
in reverse (destructing the pointed to object sets the pointer to
null).  I've also talked with people who make significant use of weak
pointers -- I'm not sure how they fit in, and I am sure that I don't
have enough experience with the option to judge it one way or another.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

> > > > Garry Lancaster:
> > > > > > As far as I know the same is true in Java and C#.
> > > > > > (Although I've heard it said that Java doesn't always
> > > > > > call finalizers which is worrying if true, but in my
> > > > > > experience fans of one language tend to overstate
> > > > > > the problems of other languages. When people say
> > > > > > Java leaks memory I confess that baffles me too.)

Bill Kempf:
> Some quotes from "Java in a Nutshell".  Not as authoratative
> as the Java Spec, obviously, but one would hope this book
> would not get the things said here so glaringly wrong.
> (Typos and spelling mistakes, if found, are likely mine.)

[snip quotes]

> This makes it sound like not only is it possible for finalizers
> to not be run during shutdown, but like it's very likely they
> won't be in most (all?) implementations.
>
> So it seems there's a reason for the claims, besides
> language advocacy.

And more from an official Sun source, this time the Java
*Virtual Machine* Specification:

"2.17.9 Virtual Machine Exit
....By default finalizers are not run on exit..."

Pretty conclusive I'd say. So I'm convinced.

Anyone know why Java's runFinalizersOnExit is deprecated?
The docs say "This method is inherently unsafe. It may result
in finalizers being called on live objects while other threads
are concurrently manipulating those objects, resulting in
erratic behavior or deadlock." which seems to raise as more
questions than it answers -in particular, why is program exit
running the finalizers before the other threads have stopped?
Maybe this is a question better asked on a Java newsgroup,
however it may have implications for any C++ GC system.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

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

"Garry Lancaster" <glancaster@ntlworld.com> writes:

|>  James Kanze:
|>  > It depends on what you mean by a defect.

|>  A conservative definition could be: failure to meet specification
|>  or a self-inconsistent specification.  If you want to go a little
|>  further I won't quibble, but be explicit about what you
|>  mean. Saying it "doesn't work in quite a number of real programs"
|>  is too vague.

That's roughly what I would use for an implementation, and by that
definition, the implementation of boost::shared_ptr doesn't have a
defect.

What I said, however, was that it didn't work in real applications.
That doesn't necessarily mean the implementation is defective.  In
fact, since boost::shared_ptr is, first and foremost in my mind, a
specification, I thought it would be obvious that it is the
specification (and not the implementation) that doesn't work. =20

I don't like the word "defect" in this context, because it suggests
something unintentional.  In this case, I think that it is more a case
of the wrong trade-offs -- there are certainly cases where shared_ptr
can be used, but they are the exception, and perhaps more important,
it is easy to unintentionally driff from a case where it can be used
to one where it cannot.

|>  > shared_ptr is quite error prone,

|>  I have not found it so.

All I can say is that in *every* case I've tried to use it, it
resulted in errors (premature object destruction) in the code.

|>  > and doesn't work when an object needs to register itself
|>  > somewhere else.

|>  This just isn't true in general, although I'm sure both of us
|>  could show scenarios where shared_ptr isn't suitable. Perhaps you
|>  should show your exact problem in code.

The problem is simple: my objects enrole themselves with other
objects, e.g. for accepting events or for generating state change
notifications.  In some cases (not all, of course), these other
objects participate in the ownership of the object.

This doesn't work with boost::shared_ptr.  It does work with every
other reference counted pointer I've used.

|>  > But I'm not saying standardize my smart pointer, rather than
|>  > Boost's. I'm saying that the requirements on smart pointers are
|>  > complex enough that no one size fits all, and that they probably
|>  > shouldn't be standardized.

|>  This is not an argument against standardization: we don't say we
|>  shouldn't standardize vector because sometimes list is better, do
|>  we?

The difference is that both vectors and lists are well understood
concepts, with a large body of existing practice.  So it is pretty
clear what is and is not needed.

This is still far from being the case with regards to smart pointers.

Do we really want to repeat the debacle of auto_ptr?

    [...]
|>  |>  This may not be permitted. If I recall correctly neither the Java
|>  |>  or C# GC system permit it nor does shared_ptr.

|>  > The Boehm collector (for C++) does.

|>  So it seems fair to say that some do and some don't.

We're talking about C++.  (Asking whether the destructor is called on
local variables, or whether you can explicitly call delete, in Java,
is nonsense.)  What other collectors do you know?  Which ones don't
allow calling delete explicitly?  (Agreed, you could call shared_ptr a
garbage collector.  In that case, some do, and some don't.  But if the
goal is true garbage collection, all of the reference counted pointers
I've seen in C++ are seriously broken.)

    [...]
|>  What you appear to be saying is that unless the timing of
|>  destruction/finalization can be determined without inspecting
|>  certain portions of the run-time system which you do not wish to
|>  inspect, you don't believe we should have it at all. I would like
|>  to see you explain *why* you make this linkage.

Quite simply because I don't have any desire to add the complexity
unless there is a real use for it.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

"Alex Oren" <response@myrealbox.com> wrote...
>
> What exactly are the reasons that the new version of the standard cannot
> include compile time checking of exception specifications (a-la Java)?

Templates.

No-one can think of a good way in which the declaration of a templated
function can indicate the exceptions that it might throw. It clearly
depends, in general, on the template arguments but the details won't be
known at compile time unless the function is inline. Function templates
needn't be inline, and might even be supplied by a shared library, in
which case they aren't visible to the linker either.

Note that I said "good way". It is clearly possible to invent syntax such
as...

    template<class A> void f() throw( +A::A(A const&), -std::bad_alloc)

...to mean "this throws anything that might be thrown by A's copy
constructor except for bad_alloc, which it presumably catches internally
and handles". The problem is that this exposes rather more of the
implementation than we perhaps would like. Indeed, the technique of
writing all templates inline (and eschewing export) is merely this
idea taken to an extreme and there are certainly people who don't like
having to inline all their templates.


---
[ 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 Wed,  5 Jun 2002 16:18:17 GMT, Garry Lancaster wrote in
<b0pL8.54111$wd3.8911722@news6-win.server.ntlworld.com>:

> > > Alex Oren:
> > > > A finalizer is invoked when an object is garbage
> > > > collected but there is no guarantee it will ever be
> > > > (e.g., when you have heaps of memory and a
> > > > small number of objects).
>
> Garry Lancaster:
> > > Do you mean if an object is still uncollected at program
> > > shutdown, the finalizer is not run before the memory
> > > is returned to the system?  If so, could you supply the
> > > official Sun reference for that?
>
> Alex Oren:
> > Here is what Sun says about finalization (heavily snipped):
>
> (This is from the Java Language Specification. Version 2.0
> I think.)
>
> > | The Java programming language does not specify how soon a finalizer will
> > | be invoked, except to say that it will happen before the storage for the
> > | object is reused.
>
> That last sentence is crucial. It bans reuse of memory
> unless or until the finalizer is called. Finalization can
> only be avoided for memory that is never reused.
>
> > | Also, the language does not specify which thread will
> > | invoke the finalizer for any given object. It is guaranteed, however,
> > | that the thread that invokes the finalizer will not be holding any
> > | user-visible synchronization locks when the finalizer is invoked. If an
> > | uncaught exception is thrown during the finalization, the exception is
> > | ignored and finalization of that object terminates.
> >
> > * A program is not required to "shutdown".  It may
> > continue running for eternity.
>
> I suggest that for all practical purposes the
> situation where a program runs forever is not
> worth discussing.

Most mission critical programs are supposed to run continuously.  Air
traffic control systems, for example, can not afford a lot of downtime.
Ditto software that monitors that nuclear reactor.

The problem with finalizers (Java or otherwise) is that they are not
invoked deterministically.  You have no idea when the GC will decide to
collect the item.  Immediately, in 1 second, in 10 hours, sometime in
the next decade or (if enough memory is available) never.

Specifically, relying on finalizers to free resources that are more
scarce than memory (e.g., file handles on some systems) is a
particularly bad idea.


Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

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

Alex Oren wrote:

> On Wed,  5 Jun 2002 16:18:17 GMT, Garry Lancaster wrote in
> <b0pL8.54111$wd3.8911722@news6-win.server.ntlworld.com>:
[...snip...]
>>>* A program is not required to "shutdown".  It may
>>>continue running for eternity.
>>>
>>I suggest that for all practical purposes the
>>situation where a program runs forever is not
>>worth discussing.
>>
>
> Most mission critical programs are supposed to run continuously.  Air
> traffic control systems, for example, can not afford a lot of downtime.
> Ditto software that monitors that nuclear reactor.


   Much embedded telecom software is permitted 5.26 total minutes of
nonvisibility per year with no episode of nonvisibility lasting for more
than 30 seconds and with zero permitted system-wide hardware
loss-of-service downtime.  And a lot of things fall into nonvisibility,
including software upgrades and any bugs which would cause a
lock-up/deadlock/livelock.  If these regulations were to be violated too
excessively, FCC and U.S. Congressional investigations could ensue,
resulting in harsh legal penalties.

   When working on embedded systems, one must be very conscious of
software which is designed to run for as much as 20 years with the goal
of not ever shutting down or reinitializing until the underlying
hardware fails.


> The problem with finalizers (Java or otherwise) is that they are not
> invoked deterministically.  You have no idea when the GC will decide to
> collect the item.  Immediately, in 1 second, in 10 hours, sometime in
> the next decade or (if enough memory is available) never.
>
> Specifically, relying on finalizers to free resources that are more
> scarce than memory (e.g., file handles on some systems) is a
> particularly bad idea.


   Amen, I wholeheartedly agree, especially in the following cases which
apply to realtime embedded systems (except #6 which is applicable to
general-purpose operating systems with virtual memory)

   1) if these resources have a lifetime longer than than the execution
of the "program"/process/address-space.

   OR

   2) if these resources are costly to deallocate.

   OR

   3) if these resources experience wear & tear when allocated which is
lessened or nonexistent when dormant.

   OR

   4) if the expense (measured in some metric) of "finalization"
followed by reallocation is higher than some budget and where allocation
alone is within budget.

   OR

   5) resource-usage estimates are harvested for predictive purposes.

   OR

   6) resource-activeness during periods of dormancy has no on-going cost.

   In #1 such resources if GCed would not necessarily be
released/"finalized" if the GC worked as Java's does, leaving them
allocated, possibly indefinitely.

   In #2 such resources if GCed would be better deallocated at
low-priority during idle times instead of deallocated/"finalized" when
reallocation is demanded, possibly demanded in during high-priority
tight-time-budget times.

   In #3 such resources if GCed would have an artificially shortened
lifetime.  Many physical & electrical devices may fall into this
category of having a longer lifetime if placed into a dormant state when
not in use.  Without deterministic deallocation/"finalization", GC
leaves the resource in an artificially in-use state when in fact it is
not in use in the application-domain.

   In #4 such resources if GCed could cause meticulously-controlled
budgets to be overflowed.

   In #5 GC leaves such a resource in an artificially in-use state when
in fact it is not in use in the application-domain.  If statistical data
is collected regarding which resources are in use during lull periods as
well as in use during peak periods, then GC could disrupt such
statistical methods by artificially raising the apparent usage of the
resources during the supposed lulls.  The valleys would be filled in.

   #6 is especially applicable on all of the general-purpose operating
systems which have demand-paged virtual memory.  Even if the GCed class
is pure-memory with no nonmemory resources but has cascading RAII effect
to other pure-memory objects, there is a cost of keeping instances
allocated too long in VM-equipped OSes.  If a block of memory is no
longer used, the block of memory can be freed so that the VM system no
longer needs to manage it.  Unless the VM layer can explicitly reach out
and prompt the GC mechanism to perform a garbage-collection at the VM
layer's volition, the cascading RAII effect to those other pure-memory
objects may not be invoked for long stretches of time, artificially
increasing VM usage.

   GC applies only to pure-memory classes!  And then only those
pure-memory classes which by design strictly have no cascading RAII
impact on other objects, lest those cascading impacts in dtors never be
invoked, due to nondeterministic "finalization".  And then only if GC
cooperates with VM in VM-equipped OSes.  Concurring with Alex's
statements, I consider GC thoroughly unacceptable for any class other
than pure-memory classes with trivial dtors.

   The only way that I can see GC being a good thing in C++ is if
somehow GC is permitted only in classes where there is a trivial dtor
(e.g., the one implicitly generated when no dtor is explicit provided in
a class).  When there is a nontrivial dtor, then the nontrivial behavior
of that dtor might never be invoked in GC systems where "finalization"
does not invoke dtors or might never be invoked in GC systems which
avoid "finalization" in certain circumstances (e.g., if there are always
enough resources; or when the program/process exits).  By definition a
trivial dtor (as defined here) would certainly be a class without any
RAII and thus eligible for GC.

   If GC were a library outside of the core langage, then I do not see a
way that a library could interrogate to see if the GC-equipped
application-domain class's dtor was trivial or nontrivial.  If GC were
in the core language, then maybe the compiler could discover triviality
versus nontriviality of dtor based on whether the compiler provided a
dtor inherently (i.e., trivial dtor) or whether a dtor was explicitly
provided (i.e., assumed to be nontrivial dtor---a more-complex variation
would be that a nontrivial dtor would contain at least one statement of
certain categories in an explicitly provided dtor: e.g., function
invocations, delete).

   If "finalization" (quoted for purjorative-disdain reasons) could
displace dtor invocation in GCed classes, how about we invent something
called "commencement" which displaces ctor invocation in certain cases,
so that we thoroughly complicate & erode C++'s entire currently-clean &
beneficial & deterministic construction-destruction
initialization-termination allocation-deallocation conceptual model.

   I already have a way for an object to reach a "final"
terminal/dormant state.  They are called: destructors which are
deterministically invoked as C++'s conceptual-internal-transactions are
successfully closed or aborted.  I don't want a nondeterministic
competitor to deterministically-invoked dtors that I must rail hard
against on a daily basis as people abuse GC for not-pure-memory classes
or for pure-memory classes with nontrivial dtors.  If GC is permitted in
C++, equipping a class for GC must be harshly limited to the
pure-memory-class-with-trivial-dtor case so that it is not deleterious
to RAII and XAOP designs.

   Likewise, GC shall never be used in any standard library (or any
Boost library or *any* library for that matter) where that library is
intended for use in realtime embedded systems, because each realtime
embedded development team (and realtime compiler vendor) must have the
option of completely prohibiting GC without any ill-effect (e.g.,
without losing the ability to use that library which otherwise would
have been useful).

   XAOP = transaction-oriented programming: strict RAII plus C++
exceptions as a transaction-abort mechanism

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

Alex Oren:
> >>>* A program is not required to "shutdown".  It may
> >>>continue running for eternity.

Garry Lancaster:
> >>I suggest that for all practical purposes the
> >>situation where a program runs forever is not
> >>worth discussing.

[snip examples of systems that run for a number of
years]

I was replying to was the suggestion that some
software might run for eternity, made by Alex Oren.
You and Alex both responded with examples of
software that runs uninterruptedly for a number of
years. The two are not the same so the examples
are irrelevant.

> > The problem with finalizers (Java or otherwise) is that they are not
> > invoked deterministically.

What is your language-independent definition of
"invoked deterministically"?

> > You have no idea when the GC will decide to
> > collect the item.  Immediately, in 1 second, in 10 hours, sometime in
> > the next decade or (if enough memory is available) never.

That "never" relies on misconception #2 and would
not be acceptable in C++ I think. Otherwise, it
depends on the GC collection strategy.

> > Specifically, relying on finalizers to free resources that are more
> > scarce than memory (e.g., file handles on some systems) is a
> > particularly bad idea.

It depends. If the resource is only slightly scarcer than
memory or the GC is collecting aggressively, I would
suggest more leeway is appropriate. In C++ when
a blanket language design decision would be unduly
restrictive, we tend to let the programmer decide.

>    Amen, I wholeheartedly agree, especially in the following cases which
> apply to realtime embedded systems (except #6 which is applicable to
> general-purpose operating systems with virtual memory)
>
>    1) if these resources have a lifetime longer than than the execution
> of the "program"/process/address-space.
>
>    OR
>
>    2) if these resources are costly to deallocate.
>
>    OR
>
>    3) if these resources experience wear & tear when allocated which is
> lessened or nonexistent when dormant.
>
>    OR
>
>    4) if the expense (measured in some metric) of "finalization"
> followed by reallocation is higher than some budget and where allocation
> alone is within budget.
>
>    OR
>
>    5) resource-usage estimates are harvested for predictive purposes.
>
>    OR
>
>    6) resource-activeness during periods of dormancy has no on-going cost.

If I might be rude enough to summarize many objections
to GC in C++, including the post I am replying to, I would say
they all propagate to a lesser or greater extent the following
misconceptions.

Misconception #1: That adding a standard GC to C++
means removing the existing memory management idioms
from the language.

Misconception #2: That adding a standard GC to C++
means adding a GC system that works identically to the
one in Java.

All of the 6 points above rest on misconception #1.

>    In #1 such resources if GCed would not necessarily be
> released/"finalized" if the GC worked as Java's does, leaving them
> allocated, possibly indefinitely.

Misconception #2.

[snip]

>    GC applies only to pure-memory classes!  And then only those
> pure-memory classes which by design strictly have no cascading RAII
> impact on other objects, lest those cascading impacts in dtors never be
> invoked, due to nondeterministic "finalization".

GC can be sensibly used for any resources whose
collection timing is appropriate for the collection
strategy used by the collector. Some collectors hold
off collection as long as possible. I believe this is
a mistake and any C++ GC system would do better
to have a more aggressive collection policy. This
would allow a greater variety of resource management
classes to benefit from GC.

> And then only if GC cooperates with VM in VM-equipped OSes.

Can you explain what you mean by that?

> Concurring with Alex's statements, I consider GC thoroughly
> unacceptable for any class other than pure-memory classes
> with trivial dtors.

Whilst you are on the right track, I disagree with the
absoluteness of this. Whilst I suspect many classes
suitable for GC will fit this description, perhaps the
majority, the C++ spirit has always been to let the
programmer decide in cases where other
languages might enforce draconian restrictions.
There are plenty of classes out there already, with
non-trivial dtors, objects of which could sensibly
be garbage collected.

>    The only way that I can see GC being a good thing in C++ is if
> somehow GC is permitted only in classes where there is a trivial dtor
> (e.g., the one implicitly generated when no dtor is explicit provided in
> a class).  When there is a nontrivial dtor, then the nontrivial behavior
> of that dtor might never be invoked in GC systems where "finalization"
> does not invoke dtors or might never be invoked in GC systems which
> avoid "finalization" in certain circumstances (e.g., if there are always
> enough resources; or when the program/process exits).

I would only want a GC system that always invoked
dtors. Avoid misconception #2.

> By definition a trivial dtor (as defined here) would certainly be a
> class without any RAII and thus eligible for GC.

Whilst I don't agree this limitation on the use of GC
is necessary or desirable, nonetheless what you are
saying contains a useful distinction for the purposes
of optimization: a class whose destruction causes
no non-trivial dtors to run, either directly or indirectly
through data members, can skip the finalization/destruction
stage of collection.

>    If GC were a library outside of the core langage, then I do not see a
> way that a library could interrogate to see if the GC-equipped
> application-domain class's dtor was trivial or nontrivial.  If GC were
> in the core language, then maybe the compiler could discover triviality
> versus nontriviality of dtor based on whether the compiler provided a
> dtor inherently (i.e., trivial dtor) or whether a dtor was explicitly
> provided (i.e., assumed to be nontrivial dtor---a more-complex variation
> would be that a nontrivial dtor would contain at least one statement of
> certain categories in an explicitly provided dtor: e.g., function
> invocations, delete).

Indeed. GC efficiency can really benefit from certain kinds
of type information that are not currently available from a
compiler, at least not as standard. A good argument for
integrating GC with the core, or at least providing the
appropriate hooks.

[snip]

>    Likewise, GC shall never be used in any standard library (or any
> Boost library or *any* library for that matter) where that library is
> intended for use in realtime embedded systems, because each realtime
> embedded development team (and realtime compiler vendor) must have the
> option of completely prohibiting GC without any ill-effect (e.g.,
> without losing the ability to use that library which otherwise would
> have been useful).

Actually, you can use GC in std and Boost today if
you so wish thanks to Hans-J. Boehm's third party
collector. It just isn't standardized. But you don't have
to use GC there and that is unlikely to change (see
misconception #1)

>    XAOP = transaction-oriented programming: strict RAII plus C++
> exceptions as a transaction-abort mechanism

In a future C++ that supports optional GC, you would still
be able to use all the transaction processing idioms you
can use today. See misconception #1 again.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

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

"Garry Lancaster" <glancaster@ntlworld.com> wrote in message
news:Rl5M8.4756$L66.620702@news6-win.server.ntlworld.com...
> Alex Oren:
> > > You have no idea when the GC will decide to
> > > collect the item.  Immediately, in 1 second, in 10 hours, sometime in
> > > the next decade or (if enough memory is available) never.
>
> That "never" relies on misconception #2 and would
> not be acceptable in C++ I think. Otherwise, it
> depends on the GC collection strategy.

I agree that adding "never" to the list of possibilities is pointless.
However, I must agree that in systems like they've talked about GC is
entirely inappropriate.  Even if there were some way to put some gaurantee
on the amount of lapsed time allowed, let's say within 1 minute of the last
root pointer going away, the non-determinism involved in GC would still make
it problematic at best for such systems.

However, I must again point out that every language I've seen that uses GC
provides some way to deterministically deal with the recollection of
non-memory resources.  Java's mechanism (finally blocks) may not be ideal
and may lead to bugs, but it *CAN* be employed in XAOP style programming.
The C# "using" keyword is even better yet.  C++0x with GC (assuming that
happens) will have our familiar RAII mechanism that can still be employed.
So I don't see any real drawbacks to adding GC to the standard, and see
several benefits (including the fact that compiler support for GC may go a
long way to reducing some problems involved with implementing GC in a
library).

> > > Specifically, relying on finalizers to free resources that are more
> > > scarce than memory (e.g., file handles on some systems) is a
> > > particularly bad idea.
>
> It depends. If the resource is only slightly scarcer than
> memory or the GC is collecting aggressively, I would
> suggest more leeway is appropriate. In C++ when
> a blanket language design decision would be unduly
> restrictive, we tend to let the programmer decide.

I'd agree with this as well, though it depends on circumstances.  If file
handles are scarce, but still number in the 100s, a text editor can probably
get away with having the handles collected when finalizers are run.  This is
especially true if we can tell the GC to start a collection phase if we fail
to acquire a file handle.  On systems described by Daniel, however, I don't
think I'd ever trust the GC to collect such resources in the finalizers.
That's simply not an argument for not including GC, however.

> If I might be rude enough to summarize many objections
> to GC in C++, including the post I am replying to, I would say
> they all propagate to a lesser or greater extent the following
> misconceptions.
>
> Misconception #1: That adding a standard GC to C++
> means removing the existing memory management idioms
> from the language.

That's the big one I see.  If C++ only had Java like GC memory management
I'd have to find another language.  That won't be the case, however, even if
the reason were only because such a change would break existing code.

> Misconception #2: That adding a standard GC to C++
> means adding a GC system that works identically to the
> one in Java.

I hope not.  At the very least, we must gaurantee that finalizers are
invoked even at application shut down.  That's important even if, in
general, finalizers are a questionable mechanism for many programs because
of their non-deterministic nature.

> >    GC applies only to pure-memory classes!  And then only those
> > pure-memory classes which by design strictly have no cascading RAII
> > impact on other objects, lest those cascading impacts in dtors never be
> > invoked, due to nondeterministic "finalization".
>
> GC can be sensibly used for any resources whose
> collection timing is appropriate for the collection
> strategy used by the collector. Some collectors hold
> off collection as long as possible. I believe this is
> a mistake and any C++ GC system would do better
> to have a more aggressive collection policy. This
> would allow a greater variety of resource management
> classes to benefit from GC.

I'm not sure I agree.  Hopefully Mr. Boehm will way in here, but I think
putting collection off as long as possible is in general the correct
startegy to take.  However, to be useful this means we must have a mechanism
to force a collection at certain points.

> >    The only way that I can see GC being a good thing in C++ is if
> > somehow GC is permitted only in classes where there is a trivial dtor
> > (e.g., the one implicitly generated when no dtor is explicit provided in
> > a class).  When there is a nontrivial dtor, then the nontrivial behavior
> > of that dtor might never be invoked in GC systems where "finalization"
> > does not invoke dtors or might never be invoked in GC systems which
> > avoid "finalization" in certain circumstances (e.g., if there are always
> > enough resources; or when the program/process exits).
>
> I would only want a GC system that always invoked
> dtors. Avoid misconception #2.

Here here!  (Well, I can see some debate as to whether or not destructors
should be finalizers, even if I don't agree with the argument for not using
destructors as finalizers.)

> > By definition a trivial dtor (as defined here) would certainly be a
> > class without any RAII and thus eligible for GC.

How can a compiler detect RAII?  RAII is an idiom of use, not something
tangible in a class.

> >    Likewise, GC shall never be used in any standard library (or any
> > Boost library or *any* library for that matter) where that library is
> > intended for use in realtime embedded systems, because each realtime
> > embedded development team (and realtime compiler vendor) must have the
> > option of completely prohibiting GC without any ill-effect (e.g.,
> > without losing the ability to use that library which otherwise would
> > have been useful).
>
> Actually, you can use GC in std and Boost today if
> you so wish thanks to Hans-J. Boehm's third party
> collector. It just isn't standardized. But you don't have
> to use GC there and that is unlikely to change (see
> misconception #1)

There have also been a number of classes proposed for Boost that provide GC
through smart pointers.

> >    XAOP = transaction-oriented programming: strict RAII plus C++
> > exceptions as a transaction-abort mechanism
>
> In a future C++ that supports optional GC, you would still
> be able to use all the transaction processing idioms you
> can use today. See misconception #1 again.

Actually, this is misconception #3 as well.  XAOP is possible in every GCed
language I'm aware of (well, provided they have some form of exception
handling).

Bill Kempf

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

William E. Kempf wrote:

> "Garry Lancaster" <glancaster@ntlworld.com> wrote in message
> news:Rl5M8.4756$L66.620702@news6-win.server.ntlworld.com...
>
>>Alex Oren:
[...snip...]
>>>>Specifically, relying on finalizers to free resources that are more
>>>>scarce than memory (e.g., file handles on some systems) is a
>>>>particularly bad idea.
>>>>
>>It depends. If the resource is only slightly scarcer than
>>memory or the GC is collecting aggressively, I would
>>suggest more leeway is appropriate. In C++ when
>>a blanket language design decision would be unduly
>>restrictive, we tend to let the programmer decide.
>>
>
> I'd agree with this as well, though it depends on circumstances.  If file
> handles are scarce, but still number in the 100s, a text editor can probably
> get away with having the handles collected when finalizers are run.  This is
> especially true if we can tell the GC to start a collection phase if we fail
> to acquire a file handle.  On systems described by Daniel, however, I don't
> think I'd ever trust the GC to collect such resources in the finalizers.
> That's simply not an argument for not including GC, however.


   If a GC based on nondeterministic-invocation of finalizers were to be
standardized in C++0x, then concerns such as mine are important enough
to adopt such GC with certain rules in place that no standard library
require GC and that no portion of the standard require GC to be present
on a particular platform.  Specifically, I vigorously recommend that if
such GC is adopted into C++0x, that it be optional, capable of being
absent on certain platforms without causing major portions of the
standard libraries to go away too.  Numerous other standards have such
optional features and compliance is tracked via a PICS proforma.

>>Misconception #2: That adding a standard GC to C++
>>means adding a GC system that works identically to the
>>one in Java.
>>
>
> I hope not.  At the very least, we must gaurantee that finalizers are
> invoked even at application shut down.  That's important even if, in
> general, finalizers are a questionable mechanism for many programs because
> of their non-deterministic nature.


   I agree.

[...snip...]

>>>By definition a trivial dtor (as defined here) would certainly be a
>>>class without any RAII and thus eligible for GC.
>>>
>
> How can a compiler detect RAII?  RAII is an idiom of use, not something
> tangible in a class.


   The definitions of trivial and nontrivial dtor which I gave were not
detecting RAII per se, but rather the converse.  The trivial dtor test
detected nonRAII.  "A implies B" does not imply "B implies A".  Trivial
dtor implies nonRAII.  A nonRAII class implies 100% safe for GC based on
nondeterministically-invoked finalizers (except for the lingering lack
of deallocation causing bloated memory usage in VM systems).

>>>   Likewise, GC shall never be used in any standard library (or any
>>>Boost library or *any* library for that matter) where that library is
>>>intended for use in realtime embedded systems, because each realtime
>>>embedded development team (and realtime compiler vendor) must have the
>>>option of completely prohibiting GC without any ill-effect (e.g.,
>>>without losing the ability to use that library which otherwise would
>>>have been useful).
>>>
>>Actually, you can use GC in std and Boost today if
>>you so wish thanks to Hans-J. Boehm's third party
>>collector. It just isn't standardized. But you don't have
>>to use GC there and that is unlikely to change (see
>>misconception #1)
>>
>
> There have also been a number of classes proposed for Boost that provide GC
> through smart pointers.


   I am very much in favor of pushing the envelope of research into
smart pointers and allied techniques---either library-based ones or
core-language compiler-implemented ones.  I don't like to use the term
"GC" for smart pointers & allied techniques because "GC" often implies
nondeterministic-invocation of finalizers instead of smart-pointers'
deterministic-invocation of dtors.

---
[ 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 <ds6rfuo56r3me677irrrgpgfc3cs9ja27o@4ax.com>, Steve Heller
<steve@steveheller.com> writes
>>Going on a tangent, I would appreciate a change in the standard that
>>will require a mandatory diagnostic for every undefined or
>>implementation-defined behaviour.
>
>  I agree as far as undefined behavior. Implementation-defined
>behavior, I'm not so sure about: such code may be perfectly valid,
>whereas code that produces undefined behavior can never be valid as I
>understand it.

We cannot mandate diagnosing something that cannot be reasonably
diagnosed. E.g.

In file1.cpp

void foo(int & a, int & b){
  a = ++b;
}

Note the compiler has no reason to diagnose a problem with that code and
most development teams would be apoplectic at having a required
diagnostic applied because of a potential aliasing problem.

In file2.cpp

void foo(int &, int &);
void bar(){
  int i;
  foo(i, i);
}

And yes, I know that no one would write code like that, but the problem
it exhibits is widespread.

UB serves at least two main purposes:
1) Exhonerate compilers from having to deal with cross TU code analysis
(not least because that is incompatible with separate compilation)
2) To provide wriggle room to allow hardware specific solutions.

The first is essentially not diagnosable. The second (which is also a
reason for unspecified and implementation defined behaviours) could be
diagnosed. As we intend to try to reduce undefined behaviour in the next
version of C++ perhaps some of these cases could be converted to
requiring a diagnostic which might be of the form:

'Congratulations on using xyz platform where this behaviour is fully
specified.'

However we hit another problem in that the Standard only requires (and
in general can only require) at least one diagnostic per TU in which
there is code requiring a diagnostic. Any more is a QoI issue.


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

"Alex Oren" <response@myrealbox.com> wrote in message
news:lh7vfu8c8h7n38a5gtb054pmcdr9coj5sn@4ax.com...
> The problem with finalizers (Java or otherwise) is that they are not
> invoked deterministically.  You have no idea when the GC will decide to
> collect the item.  Immediately, in 1 second, in 10 hours, sometime in
> the next decade or (if enough memory is available) never.
>
> Specifically, relying on finalizers to free resources that are more
> scarce than memory (e.g., file handles on some systems) is a
> particularly bad idea.

No one advocates using (only) finalizers to "free resources that are more
scarce than memory".  Even in languages that support only GC based memory
management finalizers are not used exclusively for reclamation of such
resources.  For example, Java classes all include some specific method that
will reclaim such resources, such as a close method on a File class, and
you're expected to call such methods explicitly.  The finalizer is used only
as a gaurantee that if the programmer mistakenly forgets to call such
methods the resource will still eventual be freed.

The problem is in how languages help the programmer to call such methods
reliably.  Java supplies a finally block for this, which works but is not as
safe as the RAII idiom employed in C++ through destructors.  In C# (speaking
only from rough knowledge, so this may not be 100% accurate) the IDispose
interface is used in conjunction with the using keyword to get something
similar to RAII (and IMHO is superior to finally blocks because the code
required for reclaiming the resources need be coded in only one place).  In
Ruby "blocks" (lambda functions) are used with a special programming idiom
to get RAII like support.

AFAIK, every GCed language gives you a mechanism for deterministic
reclamation of such resources.  The difference between them and C++ is that
by default the reclamation is non-deterministic and special code is required
for deterministic reclamation, while in C++ deterministic reclamation is the
default (and there's no standard mechanism given for the non-determistic
reclamation).  I'd not want to give up that characteristic of C++, but I'd
sure like to be able to use GC for the reclamation of memory, at least in
certain cases.

Bill Kempf

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

Alex Oren wrote:

> On Wed, 29 May 2002 22:22:38 GMT, David Abrahams wrote in
> <ad3jsc$le2$1@bob.news.rcn.net>:
>
>>"Brad Settlemyer" <bws_news@deepcopy_remove_.org> wrote in message
>>news:2_bJ8.11514$ib4.487622@news1.east.cox.net...
>>
>>>, but I can definitely think of behavior that leads to bugs.
>>>
>>Programming leads to bugs.


     But good language design leads to bug damage containment.
There are languages for which you can say "No matter what
module A does, it can't affect module B".  C++ is not one
of those languages.

     John Nagle

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

Garry Lancaster wrote:

> Alex Oren:
>
>>>>>* A program is not required to "shutdown".  It may
>>>>>continue running for eternity.
>>>>>
>
> Garry Lancaster:
>
>>>>I suggest that for all practical purposes the
>>>>situation where a program runs forever is not
>>>>worth discussing.
>>>>
>
> [snip examples of systems that run for a number of
> years]
>
> I was replying to was the suggestion that some
> software might run for eternity, made by Alex Oren.
> You and Alex both responded with examples of
> software that runs uninterruptedly for a number of
> years. The two are not the same so the examples
> are irrelevant.
>
>
>>>The problem with finalizers (Java or otherwise) is that they are not
>>>invoked deterministically.
>>>
>
> What is your language-independent definition of
> "invoked deterministically"?


   Are you claiming that all finalizers in all languages with GC are
invoked deterministically?  If you are not, then the definition is
existential generalization of each observed language which has
non-deterministically-invoked finalizers, rather than the axiomatic
definition which apparently are seeking for universal generalization.

   Or are you claiming that one person's/language's determinism is
another person's/language's nondeterminism?  i.e., that determinism is
in the eye of the beholder?


>>>You have no idea when the GC will decide to
>>>collect the item.  Immediately, in 1 second, in 10 hours, sometime in
>>>the next decade or (if enough memory is available) never.
>>>
>
> That "never" relies on misconception #2 and would
> not be acceptable in C++ I think. Otherwise, it
> depends on the GC collection strategy.


   If the GC is based on "finalizers" which are invoked at time of
*re*allocation, then Alex was correct: finalizers might *never* be invoked.


>>>Specifically, relying on finalizers to free resources that are more
>>>scarce than memory (e.g., file handles on some systems) is a
>>>particularly bad idea.
>>>
>
> It depends. If the resource is only slightly scarcer than
> memory or the GC is collecting aggressively, I would
> suggest more leeway is appropriate. In C++ when
> a blanket language design decision would be unduly
> restrictive, we tend to let the programmer decide.


   This engineer wants to decide to never have a GC based on
nondeterministically-invoked finalizers.  This engineer wants to decide
to never use a library which uses such GC.  If that result is possible
by complete absence of GC based on nondeterministically-invoked
finalizers in Standard C++, then that is fine.  If that result is
possible by some sort of global turn-off-GC flag, then that is fine.

>>   Amen, I wholeheartedly agree, especially in the following cases which
>>apply to realtime embedded systems (except #6 which is applicable to
>>general-purpose operating systems with virtual memory)
>>
>>   1) if these resources have a lifetime longer than than the execution
>>of the "program"/process/address-space.
>>
>>   OR
>>
>>   2) if these resources are costly to deallocate.
>>
>>   OR
>>
>>   3) if these resources experience wear & tear when allocated which is
>>lessened or nonexistent when dormant.
>>
>>   OR
>>
>>   4) if the expense (measured in some metric) of "finalization"
>>followed by reallocation is higher than some budget and where allocation
>>alone is within budget.
>>
>>   OR
>>
>>   5) resource-usage estimates are harvested for predictive purposes.
>>
>>   OR
>>
>>   6) resource-activeness during periods of dormancy has no on-going cost.
>>
>
> If I might be rude enough to summarize many objections
> to GC in C++,


   Speaking one's mind frankly at a technological level is what I think
is best.

> including the post I am replying to, I would say
> they all propagate to a lesser or greater extent the following
> misconceptions.
>
> Misconception #1: That adding a standard GC to C++
> means removing the existing memory management idioms
> from the language.


   In the context of Boehm collector GC being discussed along various
branches of this thread, the Boehm collector's nondeterministic
invocation of finalizers does constitute an significant/nontrivial
erosion of C++ memory management idioms.  The Boehm collector leaves two
implications:

   defect#1) finalizers might not be invoked in certain circumstances

   AND

   defect#2) dtors might not ever be invoked for BoehmGCed classes.

   These two defects are what I am referring to about GC based on
nondeterministically-invoked finalizers.  This state of affairs is not a
misconception and it is not the canonical C++ memory management idiom of
deterministic invocation of dtors.


> Misconception #2: That adding a standard GC to C++
> means adding a GC system that works identically to the
> one in Java.


   I agree with you that those people who hold misconception #2 are in
fact wrong.  I do not hold that viewpoint in general toward all implicit
deallocation mechanisms (e.g., smart pointers & allied techniques).
Implicit release of resources in C++ need not be performed by GC based
on nondeterministically-invoked finalizers, such as the Boehm collector.
  C++ should emphasize smart pointers and allied techniques.  As soon as
the word "finalizer" or the phrase "invocation of
finalizer/insert-noun-phrase at *re*allocation" appears, then we have
crossed the line, leaving smart pointers and allied techniques into the
automagical garbage collectors which I find thoroughly unacceptable,
like Boehm's and Java's.

   The Boehm collector has enough of the undesirable properties in
common with Java to at least look at how these undesirable properties
play out in Java.  Independent of Java, my position is based on
"finalizers" such as the Boehm collector for C++ has.

   I do not consider reference-counting smart-pointers to be automatic
garbage collection or "GC" for short.


> All of the 6 points above rest on misconception #1.


   Since what you call "misconception", I have shown to be a factual
state of affairs in the Boehm collector in C++, my 6 points stand as
criticisms against nondeterministically invoked "finalizers".

>>   In #1 such resources if GCed would not necessarily be
>>released/"finalized" if the GC worked as Java's does, leaving them
>>allocated, possibly indefinitely.
>>
>
> Misconception #2.


   Because of defect#1 & defect#2, my statements reflect a factual state
of affairs regarding the Boehm collector.  The only misconception would
be if one were to ignore these facts.


> [snip]
>
>
>>   GC applies only to pure-memory classes!  And then only those
>>pure-memory classes which by design strictly have no cascading RAII
>>impact on other objects, lest those cascading impacts in dtors never be
>>invoked, due to nondeterministic "finalization".

[...snip...]

>>And then only if GC cooperates with VM in VM-equipped OSes.
>>
>
> Can you explain what you mean by that?


   The posting to which you are responding provided that explanation in
#6 & #6's supporting paragraph which you might have missed while you
too-easily-dismissed it all as a "misconception".  Search for the
paragraph which contained the clause "Unless the VM layer can explicitly
reach out and prompt the GC mechanism to perform a garbage-collection at
the VM layer's volition".  And remember that I am discussing GC based on
nondeterministrically-invoked "finalizers", not about smart pointers &
allied techniques.

>>Concurring with Alex's statements, I consider GC thoroughly
>>unacceptable for any class other than pure-memory classes
>>with trivial dtors.
>>
>
> Whilst you are on the right track, I disagree with the
> absoluteness of this. Whilst I suspect many classes
> suitable for GC will fit this description, perhaps the
> majority, the C++ spirit has always been to let the
> programmer decide in cases where other
> languages might enforce draconian restrictions.


   The C++ spirit has been to emphasize efficiency over automagical
features like GC.  The C++ spirit has been to be applicable to realtime
embedded systems, such as at telecommunications equipment manufacturers,
such as AT&T, which was an telecom equipment manufacturer Bjarne
Stroustrup's employer during the advent of C++.


> There are plenty of classes out there already, with
> non-trivial dtors, objects of which could sensibly
> be garbage collected.


   But alas, those nontrivial dtors would not necessarily be invoked in
a Boehm collector.

>>   The only way that I can see GC being a good thing in C++ is if
>>somehow GC is permitted only in classes where there is a trivial dtor
>>(e.g., the one implicitly generated when no dtor is explicit provided in
>>a class).  When there is a nontrivial dtor, then the nontrivial behavior
>>of that dtor might never be invoked in GC systems where "finalization"
>>does not invoke dtors or might never be invoked in GC systems which
>>avoid "finalization" in certain circumstances (e.g., if there are always
>>enough resources; or when the program/process exits).
>>
>
> I would only want a GC system that always invoked
> dtors. Avoid misconception #2.


   I wholeheartedly agree.  If the GC has nondeterministically-invoked
"finalizers" instead of deterministically-invoked dtors, then that GC is
thoroughly unacceptable unless strictly limited to pure-memory classes
with trivial dtors (where "trivial dtor" is defined in my prior posting).


[...snip...]


>>   XAOP = transaction-oriented programming: strict RAII plus C++
>>exceptions as a transaction-abort mechanism
>>
>
> In a future C++ that supports optional GC, you would still
> be able to use all the transaction processing idioms you
> can use today. See misconception #1 again.


   XAOP would be drastically eroded if dtor invocation is not
deterministic such as in nondeterministic Boehm collector finalizers.

---
[ 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:
|>  > It depends on what you mean by a defect.

Garry Lancaster:
|>  A conservative definition could be: failure to meet specification
|>  or a self-inconsistent specification.  If you want to go a little
|>  further I won't quibble, but be explicit about what you
|>  mean. Saying it "doesn't work in quite a number of real programs"
|>  is too vague.

James Kanze:
> That's roughly what I would use for an implementation, and by that
> definition, the implementation of boost::shared_ptr doesn't have a
> defect.

> What I said, however, was that it didn't work in real applications.

Actually what you wrote originally was it "doesn't work in
*quite a number of* real programs" (my emphasis). What you
just wrote makes it sound like it doesn't work in *any*!

> That doesn't necessarily mean the implementation is defective.

That may not be what you intended it to mean, but that
is the inference that will be drawn when you write
that something "doesn't work". Had you just said it isn't
suitable for all applications, we wouldn't be having this
(part of the) discussion.

If you don't wish to use shared_ptr, that is fine with me,
but if you are going to imply that there is some kind of
problem with it you should be prepared to back up that
up with some kind of real example, preferably involving
code, rather than just vague or inaccurate generalizations.

(Who knows, someone might be able to solve the
problem for you or it might even help refine shared_ptr's
design?)

[snip]

> The problem is simple: my objects enrole themselves with other
> objects, e.g. for accepting events or for generating state change
> notifications.  In some cases (not all, of course), these other
> objects participate in the ownership of the object.

> This doesn't work with boost::shared_ptr.
> It does work with every other reference counted pointer I've used.

On the contrary, what you describe is entirely possible with
boost::shared_ptr. Possibly there is some additional
important constraint that you have not disclosed. If you
don't give a clear example it is impossible to say.

|>  > But I'm not saying standardize my smart pointer, rather than
|>  > Boost's. I'm saying that the requirements on smart pointers are
|>  > complex enough that no one size fits all, and that they probably
|>  > shouldn't be standardized.

|>  This is not an argument against standardization: we don't say we
|>  shouldn't standardize vector because sometimes list is better, do
|>  we?

> The difference is that both vectors and lists are well understood
> concepts, with a large body of existing practice.  So it is pretty
> clear what is and is not needed.
>
> This is still far from being the case with regards to smart pointers.

Well, if there is a particular point you don't understand, yet
feel is important, you could ask here.

As for not having a large body of existing practice, I would
have said the exact opposite is true: if there is one thing
that the C++ world has no shortage of it is reference-
counted smart pointer implementations.

> Do we really want to repeat the debacle of auto_ptr?

One of the problems that keeps cropping up with auto_ptr
is that people want to put them in the standard containers.
Their needs would actually be satisfied much better by a
reference-counted pointer like shared_ptr. A reference-
counted smart pointer is such a must have in modern
C++ development that it would be far better to standardize
one than to have everyone invent their own slightly different
incompatible, and usually not-as-good-as-shared_ptr,
version.

James Kanze:
>>>> [C++ destructors must be run] when delete is explicitly
>>>> invoked.

Garry Lancaster:
|>  |>  This may not be permitted. If I recall correctly neither the Java
|>  |>  or C# GC system permit it nor does shared_ptr.

James Kanze:
|>  > The Boehm collector (for C++) does.

|>  So it seems fair to say that some do and some don't.

> We're talking about C++.  (Asking whether the destructor is called on
> local variables, or whether you can explicitly call delete, in Java,
> is nonsense.)

No-one mentioned destroying local variables
in Java. However, when devising a GC system for C++
it is eminently sensible to look at all prior art. Including,
but not limited to, Java. The fact that Java does not have
a keyword called delete is irrelevant but the fact
that it has no *equivalent* of delete is entirely relevant.

> What other collectors do you know?  Which ones don't
> allow calling delete explicitly?

Just taking the Boehm collector with which I think we are
both at least vaguely familiar, the docs seem to indicate
explicit delete is permitted in some cases but not all.
While allowing explicit delete on all GC objects is perfectly
possible generally, it can be a source of complexity
without much advantage over normal manual memory
management i.e. deciding you will call explicit delete
before object allocation rather than sometime afterwards.
So, I wouldn't necessarily assume, as you do, that it
would be a feature of any standard C++ GC.

There are a number of other GC systems available for
C++. Look at

http://www.hpl.hp.com/personal/Hans_Boehm/gc/

for some links or try Google.

> (Agreed, you could call shared_ptr a garbage collector.

I would, just. Some do, some don't ;-)

> In that case, some do, and some don't.  But if the
> goal is true garbage collection, all of the reference counted pointers
> I've seen in C++ are seriously broken.

They wouldn't collect cyclic references without additional
fiddling (nor are they specified to), if that's what you mean
by "seriously broken".

[...]

|>  What you appear to be saying is that unless the timing of
|>  destruction/finalization can be determined without inspecting
|>  certain portions of the run-time system which you do not wish to
|>  inspect, you don't believe we should have it at all. I would like
|>  to see you explain *why* you make this linkage.

> Quite simply because I don't have any desire to add the
> complexity unless there is a real use for it.

The #1 real use is with classes that are already written
and perhaps use non-GC memory management internally.
If you ban non-trivial destruction for objects that are garbage
collected, you will not be able to garbage collect objects of
these classes, nor will you be able to have such objects as
data members of GC objects. So, no garbage collected
vectors or basic_strings, for example.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

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

Daniel Miller:
>    If a GC based on nondeterministic-invocation of finalizers were to be
> standardized in C++0x, then concerns such as mine are important enough
> to adopt such GC with certain rules in place .that no standard library
> require GC and that no portion of the standard require GC to be present
> on a particular platform.  Specifically, I vigorously recommend that if
> such GC is adopted into C++0x, that it be optional, capable of being
> absent on certain platforms without causing major portions of the
> standard libraries to go away too.  Numerous other standards have such
> optional features and compliance is tracked via a PICS proforma.

Whilst I'm not sure what a PICS proforma is nor which
important concerns you have raised that weren't actually
based on misconceptions, the form of optionality you
describe seems to be a reasonable option. Certain C99
features are already optional in the sense you describe and
C++0x looks likely to inherit at least some of these. Plus,
there's threading which wouldn't be required on single-threaded
systems. However, there is another sense of optional: required
to be supported by a compiler but not required to be used by
the programmer and this is the option I favour for GC.

Garry Lancaster:
> >>Misconception #2: That adding a standard GC to C++
> >>means adding a GC system that works identically to the
> >>one in Java.

Bill Kempf:
> > I hope not.  At the very least, we must gaurantee that finalizers are
> > invoked even at application shut down.  That's important even if, in
> > general, finalizers are a questionable mechanism for many programs
because
> > of their non-deterministic nature.

Daniel Miller:
>    I agree.

I'm glad that we are all in agreement that this is a
misconception.

> [...snip...]

Daniel Miller:
> >>>    The only way that I can see GC being a good thing in C++ is if
> >>> somehow GC is permitted only in classes where there is a trivial dtor
> >>> (e.g., the one implicitly generated when no dtor is explicit provided
in
> >>> a class).

[snip]

> >>>By definition a trivial dtor (as defined here) would certainly be a
> >>>class without any RAII and thus eligible for GC.

Bill Kempf:
> > How can a compiler detect RAII?  RAII is an idiom of use, not something
> > tangible in a class.

>    The definitions of trivial and nontrivial dtor which I gave were not
> detecting RAII per se, but rather the converse.  The trivial dtor test
> detected nonRAII.  "A implies B" does not imply "B implies A".  Trivial
> dtor implies nonRAII.  A nonRAII class implies 100% safe for GC based on
> nondeterministically-invoked finalizers (except for the lingering lack
> of deallocation causing bloated memory usage in VM systems).

Actually, your exact definition of trvial dtor fails to tell
the difference either way because it ignores data
members which have a non-trivial dtor. In other words
you are saying std::vector objects are not permitted to
be garbage collected, but it would be OK for some
classes with std::vectors as data members. I'm not
sure why you wish to ban either, but I'm certain that
what you propose is inconsistent.

[snip]

Daniel Miller:
>    I am very much in favor of pushing the envelope of research into
> smart pointers and allied techniques---either library-based ones or
> core-language compiler-implemented ones.  I don't like to use the term
> "GC" for smart pointers & allied techniques because "GC" often implies
> nondeterministic-invocation of finalizers instead of smart-pointers'
> deterministic-invocation of dtors.

It is possible to create GC smart pointers that deal
transparently with cyclic dependencies using a
mark-sweep algorithm.

What exactly do you think is the clear-cut difference
between "nondeterministic-invocation of finalizers"
and "deterministic-invocation of dtors"?

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---
[ 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:
> The second is more difficult: I have a number of cases
> where I represent sets of characters using a bit map.  It is obvious
> that a bit map is NOT an appropriate representation when the domain
> contains over a million elements -- each bit map would require more
> that 128 K bytes.  But what is the appropriate representation?
 IMHO some kind of hashing could really help. Say, (tailored) hash_map.
--
         With all respect, Sergey.          http://cpp3.virtualave.net/
         mailto : ders at skeptik.net

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

"Daniel Miller" <daniel.miller@tellabs.com> wrote in message
news:3D013DC5.1090109@tellabs.com...
> William E. Kempf wrote:
>
> > "Garry Lancaster" <glancaster@ntlworld.com> wrote in message
> > news:Rl5M8.4756$L66.620702@news6-win.server.ntlworld.com...
> >
> >>Alex Oren:
> [...snip...]
> > I'd agree with this as well, though it depends on circumstances.  If
file
> > handles are scarce, but still number in the 100s, a text editor can
probably
> > get away with having the handles collected when finalizers are run.
This is
> > especially true if we can tell the GC to start a collection phase if we
fail
> > to acquire a file handle.  On systems described by Daniel, however, I
don't
> > think I'd ever trust the GC to collect such resources in the finalizers.
> > That's simply not an argument for not including GC, however.
>
>    If a GC based on nondeterministic-invocation of finalizers were to be
> standardized in C++0x, then concerns such as mine are important enough
> to adopt such GC with certain rules in place that no standard library
> require GC and that no portion of the standard require GC to be present
> on a particular platform.  Specifically, I vigorously recommend that if
> such GC is adopted into C++0x, that it be optional, capable of being
> absent on certain platforms without causing major portions of the
> standard libraries to go away too.  Numerous other standards have such
> optional features and compliance is tracked via a PICS proforma.

I agree 100% that GC should be an optional feature.  That doesn't exactly
equate to "no portion of the standard require GC to be present on a
particular platform".  It may well be possible that some other *optional*
portion of the standard could also depend on the presence of the optional GC
system.  Threading support is going to result in the same thing here.
Threading must be an optional library in the standard, but I can definately
envision other libraries that *require* this optional library that may well
be added to some future revision of the standard.  I don't disagree with
what your saying, I just think you're stating it to strictly and with too
much finality.

> >>>By definition a trivial dtor (as defined here) would certainly be a
> >>>class without any RAII and thus eligible for GC.
> >
> > How can a compiler detect RAII?  RAII is an idiom of use, not something
> > tangible in a class.
>
>    The definitions of trivial and nontrivial dtor which I gave were not
> detecting RAII per se, but rather the converse.  The trivial dtor test
> detected nonRAII.  "A implies B" does not imply "B implies A".  Trivial
> dtor implies nonRAII.  A nonRAII class implies 100% safe for GC based on
> nondeterministically-invoked finalizers (except for the lingering lack
> of deallocation causing bloated memory usage in VM systems).

Well, I still don't think I agree with the definition and the restriction.
The std::fstream class performs RAII operations, in that the destructor
closes the external file handle.  However, this is classic usage of
finalization in every GCed language I'm aware of.  Adding a restriction that
prevents this in C++ because of a vague notion that file handles are too
scarce to be safely used in any manner other than in RAII idioms just seems
wrong, and is going to place a very large burden on developers.  I think a
larger burden then is going to exist with allowing the finalization even
when you can prove that the resources are so scarce as to require strict
usage patterns.  It also seems that such a restriction means that the GC
system simply must not have an finalizers at all.  Further, even with out GC
you have to pay attention to this sort of thing in C++ today.  Allocation on
the heap can cause the lifetime of such scarce resources to be extended to a
point of being problematic, and ref-counting idioms can cause a form of
non-determinism that's nearly as bad as GC in this regard.

> > There have also been a number of classes proposed for Boost that provide
GC
> > through smart pointers.
>
>    I am very much in favor of pushing the envelope of research into
> smart pointers and allied techniques---either library-based ones or
> core-language compiler-implemented ones.  I don't like to use the term
> "GC" for smart pointers & allied techniques because "GC" often implies
> nondeterministic-invocation of finalizers instead of smart-pointers'
> deterministic-invocation of dtors.

There's nothing that says a smart pointer implementation need create
deterministic finalization.  In fact, a smart pointer that can collect
cycles is very likely to be non-determistic in nature.  Further, the smart
pointers that do GC that I've seen all provide non-determistic finalizers...
some even with the option to run the collector entirely in it's own thread.
All that smart pointers add to the equation is an ability to track root
pointers with out the need for non-portable memory scanning techniques which
may "misread" some memory locations as pointers and thus fail to collect
objects which truly are free for collection.

Bill Kempf

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

Alex Oren:
> >>>The problem with finalizers (Java or otherwise) is that they are not
> >>>invoked deterministically.

Garry Lancaster:
> > What is your language-independent definition of
> > "invoked deterministically"?

Daniel Miller:
>    Are you claiming that all finalizers in all languages with GC are
> invoked deterministically?  If you are not, then the definition is
> existential generalization of each observed language which has
> non-deterministically-invoked finalizers, rather than the axiomatic
> definition which apparently are seeking for universal generalization.
>
>    Or are you claiming that one person's/language's determinism is
> another person's/language's nondeterminism?  i.e., that determinism is
> in the eye of the beholder?

I'm not claiming anything. I was asking a question. Although
I was asking it of Alex initially, I think it would be a good idea
were you to answer it also, if you are going to continue to
use the words "deterministically" and "nondeterministically"
in the discussion. As it is, I am not sure *exactly* what kind
of distinction you mean to make: whether is is based upon
timing of destruction, certainty of destruction, or location
of destruction (vendor-supplied runtime library vs. other
library vs. application code).

[snip]

>    This engineer wants to decide to never have a GC based on
> nondeterministically-invoked finalizers.  This engineer wants to decide
> to never use a library which uses such GC.  If that result is possible
> by complete absence of GC based on nondeterministically-invoked
> finalizers in Standard C++, then that is fine.  If that result is
> possible by some sort of global turn-off-GC flag, then that is fine.

I think we agree on at least this one point: C++ GC
must be optional, not mandatory.

[snip]

>    In the context of Boehm collector GC being discussed along various
> branches of this thread,

On this branch, now, we are discussing possible
C++ GC systems. Boehm's is just one example of
prior art.

[snip]

Daniel Miller:
> >>   GC applies only to pure-memory classes!  And then only those
> >>pure-memory classes which by design strictly have no cascading RAII
> >>impact on other objects, lest those cascading impacts in dtors never be
> >>invoked, due to nondeterministic "finalization".
>
> [...snip...]
>
> >>And then only if GC cooperates with VM in VM-equipped OSes.
> >>

> > Can you explain what you mean by that?

>    The posting to which you are responding provided that explanation in
> #6 & #6's supporting paragraph which you might have missed while you
> too-easily-dismissed it all as a "misconception".  Search for the
> paragraph which contained the clause "Unless the VM layer can explicitly
> reach out and prompt the GC mechanism to perform a garbage-collection at
> the VM layer's volition".  And remember that I am discussing GC based on
> nondeterministrically-invoked "finalizers", not about smart pointers &
> allied techniques.

I'm afraid I still don't understand what you mean.

> >>Concurring with Alex's statements, I consider GC thoroughly
> >>unacceptable for any class other than pure-memory classes
> >>with trivial dtors.
> >>
> >
> > Whilst you are on the right track, I disagree with the
> > absoluteness of this. Whilst I suspect many classes
> > suitable for GC will fit this description, perhaps the
> > majority, the C++ spirit has always been to let the
> > programmer decide in cases where other
> > languages might enforce draconian restrictions.
>
>
>    The C++ spirit has been to emphasize efficiency over automagical
> features like GC.

Some people find virtual functions "automagical".
Or exceptions. Many C++ features, including these
two, have been accused of inefficiency. These views
have often turned out to rest on a very narrow
definition of efficiency. With GC, I am not one of those
that claim it has generally superior run-time execution
speed compared with non-GC memory management,
although I am sure this is true for certain programs and
a good GC algorithm. What I am thoroughly convinced
of is that for a large set of programs it greatly improves
development efficiency. And, provided it be optional,
it therefore gives the developer more freedom to optimize
for whichever kind of efficiency is most important to them.

> The C++ spirit has been to be applicable to realtime
> embedded systems, such as at telecommunications equipment manufacturers,
> such as AT&T, which was an telecom equipment manufacturer Bjarne
> Stroustrup's employer during the advent of C++.

As far as I am aware, he still works for them. More relevantly,
C++'s suitability for these kind of projects will not be
altered by optional garbage collection. (For what it's
worth, Stroustrup himself wrote a paper on how optional
GC might be added to the language.)

[snip]

> >>   XAOP = transaction-oriented programming: strict RAII plus C++
> >>exceptions as a transaction-abort mechanism
> >>
> >
> > In a future C++ that supports optional GC, you would still
> > be able to use all the transaction processing idioms you
> > can use today. See misconception #1 again.
>
>
>    XAOP would be drastically eroded if dtor invocation is not
> deterministic such as in nondeterministic Boehm collector finalizers.

You are still propagating misconception #1. Whatever
model of GC various people favour, no-one has suggested
removing the existing memory management systems - those
that support XAOP so well - from the language. Even in the
(in my opinion, unlikely) scenario that Boehm's GC was
adopted as the standard GC exactly as it is today, you would
still be free to turn it off.

Face it: an optional GC system is going to give you more
memory management flexibility, not less.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

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

Garry Lancaster wrote:

> Daniel Miller:
>
>>   If a GC based on nondeterministic-invocation of finalizers were to be
>>standardized in C++0x, then concerns such as mine are important enough
>>to adopt such GC with certain rules in place .that no standard library
>>require GC and that no portion of the standard require GC to be present
>>on a particular platform.  Specifically, I vigorously recommend that if
>>such GC is adopted into C++0x, that it be optional, capable of being
>>absent on certain platforms without causing major portions of the
>>standard libraries to go away too.  Numerous other standards have such
>>optional features and compliance is tracked via a PICS proforma.
>>
>
> Whilst I'm not sure what a PICS proforma is


   They are commonly used in ITU & Telcordia standards.  To all readers
of this newsgroup who are active in standardization, please learn about
them.  They provide a standard-defined way for an implementation to
reveal normatively which conditional portions that an implementation
complies with.  Maybe more importantly, they provide expressivity for a
standard-defined mesh of logical-inference which gives the prerequisites
& corequisites, because a conditional portion may depend on the presence
of other conditional portions.

> nor which
> important concerns you have raised that weren't actually
> based on misconceptions,


   As I have demonstrated, my stance is not based on misconceptions.  I
cannot force any single individual to listen.  Ignoring wisdom is a
choice which each individual must make oneself.

> the form of optionality you
> describe seems to be a reasonable option. Certain C99
> features are already optional in the sense you describe and
> C++0x looks likely to inherit at least some of these. Plus,
> there's threading which wouldn't be required on single-threaded
> systems. However, there is another sense of optional: required
> to be supported by a compiler but not required to be used by
> the programmer and this is the option I favour for GC.


   Both forms have their place in C++0x.  Finalizer-based GC must not be
imposed on C++ compiler vendors in realtime embedded systems.

[...snip...]

> Daniel Miller:
>
>>   I agree.
>>
>
> I'm glad that we are all in agreement that this is a
> misconception.


   What we are not in agreement about is whether finalizer-based GC has
an erosionary effect on XAOP due 1) to not destructing objects
participating in the transaction as a direct by-product of the
app-domain successfully ending the transaction (either
destructing/finalizing late or not at all) and 2) to not destructing
objects participating in the transaction as a direct by-product of
aborting the transaction (either destructing/finalizing late or not at
all) .  Rather than focusing on winning the argument in the small today
using some clever loophole in argumentation style, let's focus on
establishing a set of C++ language behaviors which apply equally well to
atomic-transaction-oriented realtime embedded systems which wish to
reject nondeterministic finalizer-based GC as well as to general-purpose
software.

>>[...snip...]
>>
>
> Daniel Miller:
>
>>>>>   The only way that I can see GC being a good thing in C++ is if
>>>>>somehow GC is permitted only in classes where there is a trivial dtor
>>>>>(e.g., the one implicitly generated when no dtor is explicit provided
>>>>>
> in
>
>>>>>a class).
>>>>>
>
> [snip]
>
>
>>>>>By definition a trivial dtor (as defined here) would certainly be a
>>>>>class without any RAII and thus eligible for GC.
>>>>>
>
> Bill Kempf:
>
>>>How can a compiler detect RAII?  RAII is an idiom of use, not something
>>>tangible in a class.
>>>
>
>>   The definitions of trivial and nontrivial dtor which I gave were not
>>detecting RAII per se, but rather the converse.  The trivial dtor test
>>detected nonRAII.  "A implies B" does not imply "B implies A".  Trivial
>>dtor implies nonRAII.  A nonRAII class implies 100% safe for GC based on
>>nondeterministically-invoked finalizers (except for the lingering lack
>>of deallocation causing bloated memory usage in VM systems).
>>
>
> Actually, your exact definition of trvial dtor fails to tell
> the difference either way because it ignores data
> members which have a non-trivial dtor. In other words
> you are saying std::vector objects are not permitted to
> be garbage collected, but it would be OK for some
> classes with std::vectors as data members. I'm not
> sure why you wish to ban either, but I'm certain that
> what you propose is inconsistent.


   Excellent.  Thank you for improving my description of reality.  I
shall now modify my definition to account for this cascade into the
member-data.  This is an excellent example of working together.

   By the way, this is not a proposal.  What I describe along these
GC-related branches are expectations which C++0x can live up to or fail
to live up to.


> [snip]
>
> Daniel Miller:
>
>>   I am very much in favor of pushing the envelope of research into
>>smart pointers and allied techniques---either library-based ones or
>>core-language compiler-implemented ones.  I don't like to use the term
>>"GC" for smart pointers & allied techniques because "GC" often implies
>>nondeterministic-invocation of finalizers instead of smart-pointers'
>>deterministic-invocation of dtors.
>>
>
> It is possible to create GC smart pointers that deal
> transparently with cyclic dependencies using a
> mark-sweep algorithm.


   Excellent.  If such a technique does not have
nondeterministically-invoked "finalizers", then that would be an
excellent smart pointer which might erode/divert interest in
finalizer-based GC.


> What exactly do you think is the clear-cut difference
> between "nondeterministic-invocation of finalizers"
> and "deterministic-invocation of dtors"?


   Whichever whims any individual human being invents in the fiction of
his/her imagination are disgusting & repulsive to me.  Only reality
independent of human existence matters.

   I suspect that you are not requesting that I educate you about what a
"destructor" or a "finalizer" is, nor about what "deterministism" versus
"nondeterminism" is, but I will answer your question that way by
decomposing your question into its piecemeal parts briefly.  If you
truly are requesting an education, I suggest that you study up on those
four terms outside of this newsgroup.

   Definition of dtor: I am using the Standard C++ definition of
"destructor".

   definition of finalizer: I am using the Boehm collector's definition
of "finalizer".

   "deterministic [invocation]" in the context of this discussion:
Guaranteed invocation as a direct by-product of certain stimuli defined
in C++98

   "nondeterministic [invocation]" in the context of this discussion:
the lack of guarantees regarding invocation as a direct by-product of
stimuli.  In lieu of guarantees, a statement is made that the
invocations *might* occur at a later arbitrary time (or might not).

   The presence versus absence of guarantees is a clear cut difference.

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

Ross Smith <r-smith@ihug.co.nz> wrote in message news:<ada0jk$kkm$1@lust.ihug.co.nz>...
> Hans-J. Boehm wrote:
>
...
> > So would you care to propose a smart pointer scheme that
> >
> > a) Doesn't complicate the user's job, e.g. by requiring that I have
> > enough global understanding of the whole program to avoid pointer
> > cycles,
>
> The presence of ownership cycles (_not_ pointer cycles; conflating those
> two very different concepts is one of the standard pro-GC propaganda
> tricks) is always trivially obvious from the nature of the problem.
So let's say I need a doubly linked list, which happens to be
referenced exclusively by a pointer to the current insertion point,
which is somewhere in the middle.  What are the owning pointers and
what are the non-owning pointers?

Granted, this is a contrived example.  But I don't know of any real 10
or 100 line programs that require nontrivial memory management, much
less GC.  So small examples in this area are bound to be contrived.
And in my experience, it does become an issue with more complicated
data structures.
>
> > or requiring me to understand lots of extra usage rules that
> > don't apply to regular pointers.
>
> No idea what you're talking about here.
For example a rule that objects must remain reachable via owning
pointers so long as they are reachable at all.
>
> > b) Is performance competitive with either a good conservative GC, or a
> > good Java GC, particularly for multithreaded code?
>
> Irrelevant. No amount of performance makes up for lack of correctness
> (failing to execute destructors at the right moment). I could get a
> performance improvement by replacing all my floating point variables
> with integers, too, but I don't think that would justify it.
But that's not a correctness issue.  It depends on what the
specification says about destructor invocations for heap objects
managed by the collector that are not explicitly deleted.  Currently
for uncollected objects with raw pointers, the destructors are never
invoked.  I don't think that's a bug in the language implementation.

More importantly I claim that, unlike for stack allocated objects,
running destructors for heap objects synchronously can lead to very
unexpected behaviour and intermittent program failures.  A more
detailed discussion of this is at
http://www.hpl.hp.com/personal/Hans_Boehm/gc/det_destr.html .
Thus I claim you should insist on asynchronous destruction for heap
objects (e.g. by a separate thread), so that the destructors can
safely acquire locks.  (The Java specification had this part right
from the beginning, though I think it took years before any of the
implementations did.)

Reference counting potentially still allows you to run destructors
more promptly than a tracing collector.  But if you do things right,
this has to be a quantitiative difference, not a qualitative one.

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                       ]

"Alex Oren" <response@myrealbox.com> wrote in message
news:6k1nfuk6k4e9tqiggn12i23k9nibahs039@4ax.com...
> > > Sometimes (e.g., Win32 API) one needs to cast between pointers to data
> > > and pointers to functions.  I find the following too unwieldy:
> > >
> > >     pFunc = reinterpret_cast<PFUNC>(reinterpret_cast<int>(pData));
>
> [...]
>
> > template<class R, class T>
> > inline R function_cast(T* p) {
> >     static_assert<is_ptr<R>::value>("error: non-pointer type");
> >     return *reinterpret_cast<R*>(&p);
> > }
> >
> > pFunc = function_cast<PFUNC>(pData);
>
> In other words, you're saying that one can substitute (using C
> terminology):
>
> *(T*)(&p)
>
> for:
>
> (T)p
>
> It does look like it will work (except for string literals but then I
> can imagine no reason to convert them to function pointers).
>
> Or are there other caveats that I missed?

I'm simply saying that you can encapsulate the 'unwieldy' syntax of a double
reinterpret_cast with an inline function template.  As far as using 'int' is
concerned, I just dislike it.  In any case, the pointer to a pointer-to-function
is just a normal function and can be reinterpreted directly into a pointer to
pointer to object.  Dereferencing that pointer will yield a pointer to an
object--whether that is safe or not depends on the situation.  The Win32 API,
passes function-pointers around all the time as void*, which, in Standard C++,
requires an indirect cast of some type--so I made my own.

By the way, you can't take the address of any literal, but the 'function_cast'
above will still work because it is taking the address of a formal parameter not
a literal.

Paul Mensonides

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

Daniel Miller <daniel.miller@tellabs.com> writes:

|>  Hans-J. Boehm wrote:

|>  > Gabriel Dos Reis <gdr@merlin.nerim.net> wrote in message
|>  > news:<m36615bqsu.fsf@merlin.nerim.net>...

|>  >>Ross Smith <r-smith@ihug.co.nz> writes:

|>  >> > Well, the mere presence of GC in the language wouldn't break
|>  >> > anything, provided nobody actually used it. Perhaps I should
|>  >> > have said, _using_ GC would break RAII, because GC could only
|>  >> > be used on classes with trivial destructors.

|>  >>Why? Could you elaborate on that?  I'm unclear with yoru assertions.

|>  > I'm not sure what Ross Smith had in mind, but I believe the
|>  > standard argument is that garbage collectors generally can't
|>  > invoke a destructor immediately when an object is dropped.
|>  > Instead they usually substitute an asynchronous finalization
|>  > facility.  These "finalizers" are invoked asynchronously at some
|>  > later point.  In contrast, if you used something like reference
|>  > counted smart pointers (which is the minimum you would need in
|>  > cases in which GC is otherwise useful), you could invoke
|>  > destructors immediately.  Although this is indeed a
|>  > characteristic of garbage collectors, the rest of the argument
|>  > is wrong.  This is easiest to see in the multithreaded case,
|>  > where heap destructors often need to lock, and synchronous, but
|>  > hidden, invocation of heap destructors clearly leads to
|>  > deadlocks.  Asynchronous invocation is the only thing that makes
|>  > sense.  For a more detailed justification of this claim, see
|>  > http://www.hpl.hp.com/personal/Hans_Boehm/gc/det_destr.html .
|>  > It's also worth remembering that in pure garbage collected code
|>  > destructors/finalizers tend to be very rare.  In my experience,
|>  > perhaps 0.1% of objects need to be finalized.  Most resources
|>  > managed by heap objects are really memory.

|>    Experience in other languages/cultures/axiom-systems might not
|>  apply to C++ broadly or might not apply to certain C++
|>  schools-of-thought.

Hans Boehm has experience with garbage collection in C++, as well as
with other languages.

|>  This is due to the 100%-of-resource-allocation-in-ctor and
|>  100%-of-resource-deallocation-in-dtor rules which are preferred in
|>  the C++ community.  These rules form the basis of being able to
|>  use C++ as a form of transaction-programming system, where try is
|>  begin-transaction and throw (with its stack unwinding) is the
|>  abort-transaction mechanism.

The transaction processing idiom that I know is slightly different.
The transaction starts with a constructor, and is aborted with the
destructor, assuming it has not already been committed.

I'm not quite sure what this has to do with garbage collection or Hans
Boehm's assertions.  The classes which define a transaction represent
a very small percent of all classes in the application -- perhaps
0.1%.  And they are almost always allocated on the stack, so they work
exactly the same as they always have, regardless of garbage
collection.

|>  The set of objects on which garbage-collection would be performed
|>  would not only be releasing memory, but also directly or
|>  indirectly/ultimately incrementing semaphores, closing files,
|>  releasing mutexes, closing connection-oriented networking
|>  connections, and so forth, especially in large (multithreaded,
|>  multiprocessor) realtime embedded systems which are focused on
|>  interacting with the outside world which is full of resources (or
|>  software-model representations of resources).

I've done a lot of work on large embedded systems.  There was
generally one class for managing each of the resources you mention.
For a total of less than 10 classes out of close to a hundred
thousand.  Not all of these classes could be completely based on RAII,
either -- you certainly don't want to close a network connection or a
file you are writing to in a destructor unless a previous error means
that you can't do anything with it anyway.  And every time I've
allocated one of these classes dynamically, it has been in the context
of a larger (generally static or singleton) object, which did explicit
new and delete, and would continue to do so in the presence of garbage
collection.

|>  Any garbage collection system which does not call dtors in certain
|>  cases during "normal operations" erodes the integrity of C++'s XP
|>  capabilities to the point that such GC would need to be strictly
|>  prohibited from realtime embedded systems, so that
|>  resource-releasing (i.e., the 100%-of-resources-released-in-dtor
|>  rule) is not undermined or compromised during transaction-abortion
|>  in XP.

In critical hard real time systems, dynamic memory is out, so of
course, garbage collection won't be used:-).

The role of garbage collection is to collect memory that is no longer
in use.  It should not be used to manage other resources.  (Although
from what I have heard, Java uses it for file descripters as well --
any time it runs out of file descripters, it garbage collects, with
the hope that some of the finalizers will free one or more.)


--=20
James Kanze                                mailto:kanze@gabi-soft.de
Do you need real expertise in C++? in Java? in OO design?
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

"William E. Kempf" <williamkempf@hotmail.com> writes:

|>  "James Kanze" <kanze@alex.gabi-soft.de> wrote in message
|>  news:868z62t0vo.fsf@alex.gabi-soft.de...
|>  >"Garry Lancaster" <glancaster@ntlworld.com> writes:

|>  >|>  People looking for a C++ GC system shouldn't overlook
|>  >|>  boost::shared_ptr. It can't easily cope with cyclic
|>  >|>  references (although at a pinch there are various ways to
|>  >|>  break the cycle) but if you can live with that limitation it
|>  >|>  may do everything you want.

|>  >Not really.  It doesn't work in quite a number of real programs.
|>  >The problem is simple: in C++, you *have* raw pointers.  You
|>  >can't avoid it, because "this" is a raw pointer.  So you
|>  >inevitably end up with some raw pointers that are involved in
|>  >ownership.  With some counted pointers, you can convert these
|>  >into a counted pointer without problems, but with the Boost
|>  >shared_ptr, you must convert the raw pointer exactly once;
|>  >converting it a second time will lead to prematurely freeing the
|>  >memory.

|>  It's true that boost::shared_ptr doesn't do this directly, but I
|>  think that's the proper decision given the design constraints.
|>  There are options, however.  You can opt instead for a Loki style
|>  smart pointer where you can change the policy here.  You can use
|>  the new facilities that allow for intrusive ref-counting which
|>  eliminates this problem.  You can use the new weak_ptr to
|>  externalize your own mapping of raw pointers to shared_ptrs.

|>  I know you are aware of this and your criticisms are justified
|>  when looking at whether or not to standardize boost::shared_ptr,
|>  but I don't think they apply to the claim made above.

The only claim I made is that boost::shared_ptr doesn't work in quite
a number of real programs.  I then pointed out why.  There are quite a
number of real programs where boost::shared_ptr does not solve the
memory management problem (i.e. doesn't work).

I'll admit that this is something I'm not happy about.  I would like
to be able to create some sort of coding guideline saying "always use
boost::shared_ptr" (or any other smart pointer).  From my experience,
however, this doesn't work.  My own smart pointer (much like that in
Scott Meyers) doesn't have one particular problem that the boost
pointer does, but it doesn't solve all of the problems either.  My
conclusion, for the moment, is that you still have to think about what
you are doing, that a variety of smart pointers are necessary, as well
as some use of raw pointers, and that as a result, I really don't
think we should standardize any smart pointer.

|>  >|>  As for destructors !=3D finalizers, I think the existance of
|>  >|>  increasingly GC-like smart pointers in C++ means the line is
|>  >|>  now very blurred. I'm not sure it is a useful distinction any
|>  >|>  more.

|>  >The problem is perhaps one of vocabulary, but C++ destructors are
|>  >totally unrelated to Java finalizers.

|>  >Even with garbage collection, C++ destructors must be run when
|>  >local variables go out of scope, at the end of program on static
|>  >variables, and when delete is explicitly invoked.  It is less
|>  >obvious what should happen when an object is collected; my
|>  >personal feeling is that destructors should NOT be called in this
|>  >case.

|>  A valid opinion, but I don't agree.  If they aren't called you'll
|>  have to expose a seperate finalizer mechanism for objects any way,
|>  and to me it makes sense to simply "reuse" the destructor for
|>  this.  There may be issues with doing this, since there are some
|>  things that are natural to do in destructors that are dangerous to
|>  do in finalizers, but in my mind it's only corner cases where a
|>  destructor might be used both for deterministic destruction of
|>  objects in the "unmanaged" space (to borrow from .NET) and for
|>  finalization in the "managed" space in such a way that it's
|>  unsafe.

Maybe.  For the moment, I've not found any real use for Java's
finalizers, so I don't see any real reason to run the destructors.  I
pretty much agree with the rest of you analysis, but since I don't see
any need for any finalization mechanism...

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Do you need real expertise in C++? in Java? in OO design?
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

"Alex Oren" <response@myrealbox.com> wrote in message
news:memnfugqblnu694q7t6s7upnfliav5eqp6@4ax.com...
> On Fri, 31 May 2002 13:36:17 CST, William E. Kempf wrote in
> <newscache$yckzwg$r8j$1@frodo.bagend.com>:
>
> > * Event queues.  I believe this concept to be higher level then the
scope of
> > Boost.Threads.  I also believe it to not be a thread specific concept (I
> > know others disagree about this, so there may well be something I'm not
> > understanding here).  Despite this I think it an important concept, and
one
> > that probably should be standardized.  So I don't think it's exclusion
> > should rule out Boost.Threads, RTOS/embedded systems or no.
>
> I'm not very familiar with RTOSes but here's my point of view with
> regard to the Win32 environments.

I'm a Win32 programmer, so all of this is very well known by myself.

> In Win32, threads work together with Synchronization Objects.  A thread
> can wait on Events, Mutexes, Semaphores and Waitable Timers (as well as
> on other objects that are used mainly for other purposes.

Boost.Threads has Mutexes.  Events are generally considered unsafe (please,
let's not start that thread here... look for the other threads that discuss
this if you want more info or want to argue this point) and can be totally
eliminated through the safe use of condition variables.  I talked about
Semaphores above, but again, they aren't necessarily gone for good (though
it's likely they will be).

> There are also Critical Sections (which are lightweight, do not work
> across processes and have a different "interface) and Interlocked...()
> functions that allow atomic operations on shared variables.

The interface isn't really that different for Critical Sections.  Granted,
you call very different Win32 APIs, but the actual operations performed by
the APIs are identical to Mutexes.  The Boost.Threads implementation uses
critical sections when it can for the Mutex classes, but this is an
implementation detail that's not relevant to the discussion.  The
Interlocked family of functions existed in an initial prototype, but there's
issues with atomic integer operations (they are very low level with some
tricky consequences that many users aren't aware of), so they were removed.
I suspect they'll find their way back in before things are said and done,
but that's a decision for later.

> A standard C++ thread/synchronization library should be able to express
> all these paradigms in the most efficient way.  Otherwise, I will just
> use (or encapsulate) the OS APIs instead.

Most of what you listed either exists in Boost.Threads, has a safer
equivalent, or is still under consideration.

Bill Kempf

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

On Mon,  3 Jun 2002 23:43:16 GMT, Steve Clamage <clamage@eng.sun.com>
wrote:

> On Mon, 3 Jun 2002, Francis Glassborow wrote:

> > Let me give you a simple example:

> > void foo(int &a, int &b){
> >   a=b++;
> > }

> > has a potential for UB but only a full code analysis will detect if it
> > actually manifests.

> It's worse than that. It is impossible (isomorphic to the Halting
> Problem) to determine whether some UB conditions occur in a program.

> For your function foo example, consider this trivial example:

> extern int a, b;
> int main()
> {
>     int ar = rand()%2 ? a : b;
>     foo(ar, b);
>     // ... defined or undefined behavior?
> }

I think it is well defined.  Did you mean int& ar, or am I missing
something?  I agree that it is undecidable with int&.

I don't think that I want a warning for any function with two reference
parameters of the same type which does something which could be UB.

John

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

Hyman Rosen wrote:
> template<typename T, T Low, T High>
> struct Ranged
> ...
This is the basic principle. But actually it was a little bit more than
that. I could publish the paper at a well hidden WWW site, but even then
not in it's current state. I'd have to correct some points and comment
others. Time is limited.
Multiple ranges may be introduced by using typelists. But it turned out
that this approach quickly reached academic dimensions and neither my
family nor my employer would be glad about this.


Best regards
Olaf Krzikalla

---
[ 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,  3 Jun 2002 04:11:43 GMT, Francis Glassborow wrote in
<tB76JKCeNK+8Ew86@robinton.demon.co.uk>:

> In article <rbcdfug6in0utggkc80pcpeul8s47unhji@4ax.com>, Alex Oren
> <response@myrealbox.com> writes
> >On Wed, 29 May 2002 14:55:53 GMT, Francis Glassborow wrote in
> ><rxX7FNShKO98EwGL@robinton.demon.co.uk>:
> >
> >> Why do you assume that those of us working on the evolution of C++ are
> >> going to ignore the desirability of making things simpler where that can
> >> be done without much cost. I think what you call strong enums are a bad
> >> example because whatever that may mean can be provided fairly simply
> >> within the current language, they are just not provided by the keyword
> >> enum.
> >
> >OK, I'll bite.
> >
> >How do you "fairly simply" implement strong enums that can be used in
> >if/switch/for/while statements but cannot be automatically converted to
> >integers?
>
> Sorry, I had lost track of this sub-thread (coupled with a substantial
> discussion within the UK C++ Panel about strong typedefs and the
> discussion here of providing a scope for an enum)
>
> Nonetheless by encapsulating your enum in a class/struct you can provide
> a conversion operator that throws when the value is out of range. Not
> ideal, but workable. In fact you can apply strong constraints to your
> enum as long as you have a class/struct scope within which to work.

This only addresses the range checking issue, not the strong(er) typing
and conversions.

Please see: http://groups.google.com/groups?threadm=25740@cornell.UUCP


Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

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

"Garry Lancaster" <glancaster@ntlworld.com> writes:

|>  Garry Lancaster:
|>  |>  People looking for a C++ GC system shouldn't overlook
|>  |>  boost::shared_ptr. It can't easily cope with cyclic references
|>  |>  (although at a pinch there are various ways to break the
|>  |>  cycle) but if you can live with that limitation it may do
|>  |>  everything you want.

|>  James Kanze:
|>  > Not really.  It doesn't work in quite a number of real programs.
|>  > The problem is simple: in C++, you *have* raw pointers.  You
|>  > can't avoid it, because "this" is a raw pointer.  So you
|>  > inevitably end up with some raw pointers that are involved in
|>  > ownership.  With some counted pointers, you can convert these
|>  > into a counted pointer without problems, but with the Boost
|>  > shared_ptr, you must convert the raw pointer exactly once;
|>  > converting it a second time will lead to prematurely freeing the
|>  > memory.

|>  I'm not sure what you're saying here. If you've found a defect in
|>  shared_ptr I'd be quite surprised. If you just mean there are some
|>  problems it isn't designed to solve then I agree, but it's the
|>  same with everything.

It depends on what you mean by a defect.  shared_ptr is quite error
prone, and doesn't work when an object needs to register itself
somewhere else.

But I'm not saying standardize my smart pointer, rather than Boost's.
I'm saying that the requirements on smart pointers are complex enough
that no one size fits all, and that they probably shouldn't be
standardized.

|>  |>  As for destructors !=3D finalizers, I think the existance of
|>  |>  increasingly GC-like smart pointers in C++ means the line is
|>  |>  now very blurred. I'm not sure it is a useful distinction any
|>  |>  more.

|>  > The problem is perhaps one of vocabulary, but C++ destructors
|>  > are totally unrelated to Java finalizers.

|>  An overstatement. They are different, but related.  They are both
|>  special member functions used to clean up objects before their
|>  memory is reused.

Not really.  The objects are presumably already "clean", in some way.

Perhaps I should state it differently: C++ destructors are one of the
most useful features of the language, while I've yet to find any use
for Java finalizers.

|>  Java isn't the only platform to have finalizers and C++ isn't the
|>  only language to have destructors. Most interestingly, a C#
|>  destructor compiles into a .Net finalizer. How's that for blurring
|>  the line?

|>  > Even with garbage collection, C++ destructors must be run when
|>  > local variables go out of scope, at the end of program on static
|>  > variables,

|>  Agreed. And there is no problem with this except when people
|>  equate GC with GC-just-like-the-one- in-Java. We can study the
|>  Java model, but we shouldn't copy it.

|>  > and when delete is explicitly invoked.

|>  This may not be permitted. If I recall correctly neither the Java
|>  or C# GC system permit it nor does shared_ptr.

The Boehm collector (for C++) does.

|>  > It is less obvious what should happen when an object is
|>  > collected; my personal feeling is that destructors should NOT be
|>  > called in this case.

|>  I say call them: keep the ability to clean-up other resources,
|>  even including non-GC memory. What's the thinking behind your
|>  position?

Simply that destructors are deterministic, and finalizers aren't.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Do you need real expertise in C++? in Java? in OO design?
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

Olaf Krzikalla wrote:
> Hyman Rosen wrote:
>>template<typename T, T Low, T High>
>>struct Ranged
>
> This is the basic principle. But actually it
 > was a little bit more than that.

Sure. For one thing, I would add templated copy
constructors and assignment operators so that
range checks which must succeed are elided, and
range checks which cannot succeed fail to compile.

I might also want to have a version which holds a
reference, and allow a templated copy cinstructor
to one with a narrower range.

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

> Daniel Miller <daniel.miller@tellabs.com> writes:
[...snip...]
> |>  This is due to the 100%-of-resource-allocation-in-ctor and
> |>  100%-of-resource-deallocation-in-dtor rules which are preferred in
> |>  the C++ community.  These rules form the basis of being able to
> |>  use C++ as a form of transaction-programming system, where try is
> |>  begin-transaction and throw (with its stack unwinding) is the
> |>  abort-transaction mechanism.
>
> The transaction processing idiom that I know is slightly different.


   Well, as the saying states, one learns something new every day.  I am
glad that I could make your day a bit better & brighter in this regard.

> The transaction starts with a constructor, and is aborted with the
> destructor, assuming it has not already been committed.


   You appear to be discussing a class whose mission it is to wrap a
transaction---a class whose design exists independent of C++, outside of
C++: a class which would exist even if the software were written in a
language other than C++.  Conversely, I am talking about the programming
paradigm on which C++ exceptions are founded.  The representation of
transactions which you discuss exists due to an OOP model of the
transaction which C++ just happens to be the OOP language du jour to
implement that OOP-transaction design.  The representation of
transactions which I discuss exists due to an XAOP model which
intimately leverages C++ exceptions and call-stack to implement.

   Unlike Ada which has resumptive exceptions, C++ has abortive
exceptions.  "Aborting what?" one might ask, because one normally speaks
of "aborting" a "transaction" (or aborting some specifically-named
transaction such as pregnancy).  Rhetorical question: do C++ exceptions
abort merely the execution of a sequence of instructions along with raw
truncation of the call-stack?  I think not.  If C++ exceptions'
semantics were exactly congruent to the semantics of C's setjmp/longjmp
idiom, then C++'s abortive exceptions would be merely aborting the
execution of a sequence of instructions along with raw truncation of the
call-stack.  But such a hypothetical raw truncation of the call-stack is
not the case in C++ exceptions.

   By definition of "abort", abortive C++ exceptions abort a
*transaction* (within the C++ execution model itself).  Once one sees
the rich transactional semantics within abortive C++ exceptions, one can
directly represent the transactions of one's design in C++ syntax &
semantics, teaching to compiler to perform the abortive behavior for the
engineer, freeing the engineer to focus on positive functionality and to
focus on finding every transaction inherent in the design or required by
the system's requirements/expectations.  Once all of the transactions
have been explicitly found and explicitly designed, then RAII is
possible throughout the design.  Bucking against RAII erodes XAOP.
Bucking against XAOP erodes RAII.

   1) Each try statement is the begin boundary of a transaction.

   2) The try's block-statement is the set of behaviors contained within
the transaction.

   3) As execution of the try's block-statement progresses, the
call-stack forms a transaction log of resources which must be torn down
(i.e., rolled back) as part of aborting the transaction---i.e., as part
of unwinding the stack.  The objects/resources on the
call-stack/transaction-log may very well be lightweight guards which
hold permission to access a resource.  As these guards are
rolled-back/destructed as the transaction-log/call-stack is
rolled-back/unwound, they may cause cascading effect on other resources
whose corresponding object is not present on the call-stack, including
as a subset: pool-allocated resources, which in turn include as a
subset: pool-allocated RAM.

   4) A decision to throw an exception is a decision to abort the
transaction.

   5) From the point of throwing the exception to the point of matching
catch which does not rethrow, the abortion's (i.e., exception's)
transaction-log (i.e., call-stack) rollback (i.e., unwinding) occurred,
including the invocation of destructors (i.e., clean up of lightweight
resources used in modeling the transaction & its permissions) which in
turn may cause cascading effect on other heavier-weight resources whose
lifetime spans multiple transactions or whose lifetime spans all
transactions.

   6) Conversely if the transaction were to be successful instead of
aborting, then the closing } of the try's block-statement represents the
successful completion of the transaction.

   7) Nested transactions are supported when try statements are
encountered during the execution of some other try's block-statement.


> I'm not quite sure what this has to do with garbage collection or Hans
> Boehm's assertions.


   See the attempt-to-get-something-for-nothing/genie-out-of-the-bottle
statements far below.

>  The classes which define a transaction represent
> a very small percent of all classes in the application -- perhaps
> 0.1%.  And they are almost always allocated on the stack, so they work
> exactly the same as they always have, regardless of garbage
> collection.
>
> |>  The set of objects on which garbage-collection would be performed
> |>  would not only be releasing memory, but also directly or
> |>  indirectly/ultimately incrementing semaphores, closing files,
> |>  releasing mutexes, closing connection-oriented networking
> |>  connections, and so forth, especially in large (multithreaded,
> |>  multiprocessor) realtime embedded systems which are focused on
> |>  interacting with the outside world which is full of resources (or
> |>  software-model representations of resources).
>
> I've done a lot of work on large embedded systems.  There was
> generally one class for managing each of the resources you mention.
> For a total of less than 10 classes out of close to a hundred
> thousand.  Not all of these classes could be completely based on RAII,
> either -- you certainly don't want to close a network connection or a
> file you are writing to in a destructor unless a previous error means
> that you can't do anything with it anyway.


   It sounds as though such software on which you have worked was not
fully & explicitly identifying its transaction boundaries along with its
transaction-abortion semantics to a level which would live up to my
expectations.  I expect that all transactions be identified during
design-time, including begin-transaction boundary, end-transaction
boundary, and conscious characterization of transaction-abortion, just
as a database-engine/RDBMS vendor would characterize these transactional
semantics in their database-engine's/RDBMS's design.

>  And every time I've
> allocated one of these classes dynamically, it has been in the context
> of a larger (generally static or singleton) object, which did explicit
> new and delete, and would continue to do so in the presence of garbage
> collection.


   It sounds as though such software on which you have worked has not
used XAOP (the transaction-oriented programming paradigm) or if it has
at all, it did not use it to its fullest benefit.  I am curious: how
prevalent are C++ exceptions (i.e., try, catch, throw statements) in
this software of which you speak?

> |>  Any garbage collection system which does not call dtors in certain
> |>  cases during "normal operations" erodes the integrity of C++'s XP
> |>  capabilities to the point that such GC would need to be strictly
> |>  prohibited from realtime embedded systems, so that
> |>  resource-releasing (i.e., the 100%-of-resources-released-in-dtor
> |>  rule) is not undermined or compromised during transaction-abortion
> |>  in XP.
>
> In critical hard real time systems, dynamic memory


   Allocation from a heap may be prohibited, but dynamic allocation from
one or more fixed-size pools of predetermined meticulously-calcuated
worst-case-fixed-size is definitely not prohibited at all.  Such pools
are allocated at boot-time to ensure that the embedded realtime system
has enough resources to operate indefinitely.

> is out, so of
> course, garbage collection won't be used:-).
>
> The role of garbage collection is to collect memory


   Classes are more than memory.  In XAOP 1) they represent
resources/nouns/permissions-to-access and 2) they represent units of
work within a transaction which was began by a try statement and
optionally aborted via throwing an exception.

> that is no longer
> in use.  It should not be used to manage other resources.


   But once the genie is out of the bottle, GC will be horribly abused,
because human nature is to try to get something for nothing.  Throughout
the 1990s, I witnessed from afar a slow-motion train-wreck of sorts (at
another employer than my current one).  An entire telecom network
element, each capable of carrying over a half-million telephone calls
concurrently, was written in interpreted Smalltalk instead of C++
because (in part) Smalltalk had automatic garbage-collection which could
(misguidedly) be blithely forgotten about.  (Independent of GC, of
course, interpreted Smalltalk proved to be quite the grotesque disaster
on such a large embedded real-time system.)

   The reason that I mention this unwise choice to fervently pursue
Smalltalk's GC despite blatantly-obvious inappropriateness is that the
inevitable attraction of certain software architects & managers to avoid
the responsibility of deallocation as part of a transaction abortion is
powerful, since deallocation of resources, as well as transactions for
that matter, are not a saleable feature on the glamorous glossy sales
brochures in the vast majority of products on which C++-compiled
software is embedded.  When certain software architects & managers can
think that they can focus entirely on the positive feature-for-sale
functionality 1) without considering the deallocation of
resources/memory/objects and 2) without properly aborting errant
transactions including the implied deallocation of resources as part of
the transaction abortion, then of course GC will be quite
inappropriately popular.  Once any form of GC is officially endorsed as
a standard feature of C++ and available in the majority of C++ compiler
tool-suites, it will be (ab)used for everything under the sun regardless
of your scope-of-applicability recommendation above on a newsgroup
thread made years prior.

>  (Although
> from what I have heard, Java uses it for file descripters as well --
> any time it runs out of file descripters, it garbage collects, with
> the hope that some of the finalizers will free one or more.)

   My point moreover: once the genie is out of the bottle, GC will be
abused because human nature is to attempt to get something for nothing
instead of proactively account for it in their designs.

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

|>  Garry Lancaster:
|>  |>  People looking for a C++ GC system shouldn't overlook
|>  |>  boost::shared_ptr. It can't easily cope with cyclic references
|>  |>  (although at a pinch there are various ways to break the
|>  |>  cycle) but if you can live with that limitation it may do
|>  |>  everything you want.

|>  James Kanze:
|>  > Not really.  It doesn't work in quite a number of real programs.
|>  > The problem is simple: in C++, you *have* raw pointers.  You
|>  > can't avoid it, because "this" is a raw pointer.  So you
|>  > inevitably end up with some raw pointers that are involved in
|>  > ownership.  With some counted pointers, you can convert these
|>  > into a counted pointer without problems, but with the Boost
|>  > shared_ptr, you must convert the raw pointer exactly once;
|>  > converting it a second time will lead to prematurely freeing the
|>  > memory.

Garry Lancaster:
|>  I'm not sure what you're saying here. If you've found a defect in
|>  shared_ptr I'd be quite surprised. If you just mean there are some
|>  problems it isn't designed to solve then I agree, but it's the
|>  same with everything.

James Kanze:
> It depends on what you mean by a defect.

A conservative definition could be: failure to meet
specification or a self-inconsistent specification.
If you want to go a little further I won't quibble, but
be explicit about what you mean. Saying it "doesn't
work in quite a number of real programs" is too vague.

> shared_ptr is quite error prone,

I have not found it so.

> and doesn't work when an object needs to register itself
> somewhere else.

This just isn't true in general, although I'm sure both
of us could show scenarios where shared_ptr isn't
suitable. Perhaps you should show your exact problem
in code.

> But I'm not saying standardize my smart pointer,
> rather than Boost's. I'm saying that the requirements
> on smart pointers are complex enough
> that no one size fits all, and that they probably shouldn't be
> standardized.

This is not an argument against standardization: we
don't say we shouldn't standardize vector because
sometimes list is better, do we?

|>  |>  As for destructors != finalizers, I think the existance of
|>  |>  increasingly GC-like smart pointers in C++ means the line is
|>  |>  now very blurred. I'm not sure it is a useful distinction any
|>  |>  more.

|>  > The problem is perhaps one of vocabulary, but C++ destructors
|>  > are totally unrelated to Java finalizers.

|>  An overstatement. They are different, but related.  They are both
|>  special member functions used to clean up objects before their
|>  memory is reused.

> Not really.  The objects are presumably already "clean",
> in some way.

They maybe clean in some way, but they are not clean in
the same way they will be once the destructor/finalizer
has run.

> Perhaps I should state it differently: C++ destructors are
> one of the most useful features of the language, while I've
> yet to find any use for Java finalizers.

OK. But that's a much milder statement than saying that
they are "totally unrelated".

|>  Java isn't the only platform to have finalizers and C++ isn't the
|>  only language to have destructors. Most interestingly, a C#
|>  destructor compiles into a .Net finalizer. How's that for blurring
|>  the line?

|>  > Even with garbage collection, C++ destructors must be run when
|>  > local variables go out of scope, at the end of program on static
|>  > variables,

|>  Agreed. And there is no problem with this except when people
|>  equate GC with GC-just-like-the-one- in-Java. We can study the
|>  Java model, but we shouldn't copy it.

|>  > and when delete is explicitly invoked.

|>  This may not be permitted. If I recall correctly neither the Java
|>  or C# GC system permit it nor does shared_ptr.

> The Boehm collector (for C++) does.

So it seems fair to say that some do and some don't.

|>  > It is less obvious what should happen when an object is
|>  > collected; my personal feeling is that destructors should NOT be
|>  > called in this case.

|>  I say call them: keep the ability to clean-up other resources,
|>  even including non-GC memory. What's the thinking behind your
|>  position?

> Simply that destructors are deterministic, and finalizers aren't.

Meaning you can predict when destructors run, but
not when finalizers run? This is another area where
the line between destructor and finalizer is blurred
beyond recognition. If you enlarge the scope of your
inspection widely enough all systems are
deterministic (barring quantum effects ;-). Leaving
physics to one side, if you compare for instance
the behaviour of C++ destructors and
Java finalizers your statement will only be true if
you bias your analysis by choosing to include any
C++ library that is involved with memory management,
but choose to exclude the Java VM which does the
equivalent job in that language. In practice when
the destructor/finalizer is called can be equally
obscure in the two cases. If you look at C# under .Net
there is *no difference* between destructors and
finalizers.

What you appear to be saying is that unless the
timing of destruction/finalization can be determined
without inspecting certain portions of the run-time
system which you do not wish to inspect, you don't
believe we should have it at all. I would like to see
you explain *why* you make this linkage.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---
[ 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 Tue,  4 Jun 2002 15:56:39 GMT, James Kanze wrote in
<86hekjjcte.fsf@alex.gabi-soft.de>:

> My
> conclusion, for the moment, is that you still have to think about what
> you are doing, that a variety of smart pointers are necessary, as well
> as some use of raw pointers, and that as a result, I really don't
> think we should standardize any smart pointer.

I respectfully disagree.

As long as we have a standardized auto_ptr, a lot programmers are going
to try to use it whether it is the most appropriate smart pointer for
the problem or not.

I think that the standard should include several smart pointer types
that are appropriate for different types of problems.

I don't know whether Boost [scoped_ptr, scoped_array, shared_ptr,
shared_array, weak_ptr] are the best implementations but something
similar to that set should be in the standard.


Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

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

Daniel Miller <daniel.miller@tellabs.com> writes:

|>  James Kanze wrote:

    [...]
|>     You appear to be discussing a class whose mission it is to wrap
|>  a transaction---a class whose design exists independent of C++,
|>  outside of C++: a class which would exist even if the software
|>  were written in a language other than C++.  Conversely, I am
|>  talking about the programming paradigm on which C++ exceptions are
|>  founded.  The representation of transactions which you discuss
|>  exists due to an OOP model of the transaction which C++ just
|>  happens to be the OOP language du jour to implement that
|>  OOP-transaction design.  The representation of transactions which
|>  I discuss exists due to an XAOP model which intimately leverages
|>  C++ exceptions and call-stack to implement.

That is, in fact, what I was thinking of.  A transaction as something
which can be committed or rolled back, and which is managed by a
specific object.

|>     Unlike Ada which has resumptive exceptions, C++ has abortive
|>  exceptions.  "Aborting what?" one might ask, because one normally
|>  speaks of "aborting" a "transaction" (or aborting some
|>  specifically-named transaction such as pregnancy).

I'm not familiar with the use of "transaction" in this sense.  The
function "abort", for example, aborts a process or a task (depending
to the vocabulary of the system).  And the word "abort" is being used
fairly loosely, without consideration of what is being aborted.

|>  Rhetorical question: do C++ exceptions abort merely the execution
|>  of a sequence of instructions along with raw truncation of the
|>  call-stack?  I think not.  If C++ exceptions' semantics were
|>  exactly congruent to the semantics of C's setjmp/longjmp idiom,
|>  then C++'s abortive exceptions would be merely aborting the
|>  execution of a sequence of instructions along with raw truncation
|>  of the call-stack.  But such a hypothetical raw truncation of the
|>  call-stack is not the case in C++ exceptions.

|>     By definition of "abort", abortive C++ exceptions abort a
|>  *transaction* (within the C++ execution model itself).  Once one
|>  sees the rich transactional semantics within abortive C++
|>  exceptions, one can directly represent the transactions of one's
|>  design in C++ syntax & semantics, teaching to compiler to perform
|>  the abortive behavior for the engineer, freeing the engineer to
|>  focus on positive functionality and to focus on finding every
|>  transaction inherent in the design or required by the system's
|>  requirements/expectations.  Once all of the transactions have been
|>  explicitly found and explicitly designed, then RAII is possible
|>  throughout the design.  Bucking against RAII erodes XAOP. Bucking
|>  against XAOP erodes RAII.

OK.  I'm not familiar with XAOP, but it sounds like something I've
been looking for.  A way to ensure program correctness in the presence
of exceptions.

I've cut most of your explination of XAOP, but I very much appreciated
it.

|>     But once the genie is out of the bottle, GC will be horribly
|>  abused, because human nature is to try to get something for
|>  nothing.

This is, regretfully, true of everything.  You should have seen the
way operator overloading was abused when it was first introduced.  And
far too many Java programmers appear to expect more of GC than it can
give.

But is the fact that something can be abused a valid justification for
not allowing it.  Especially when it can reduce programmer effort
significantly (at least if used correctly).

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Do you need real expertise in C++? in Java? in OO design?
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

> > Garry Lancaster:
> > > > As far as I know the same is true in Java and C#.
> > > > (Although I've heard it said that Java doesn't always
> > > > call finalizers which is worrying if true, but in my
> > > > experience fans of one language tend to overstate
> > > > the problems of other languages. When people say
> > > > Java leaks memory I confess that baffles me too.)
> >
> > Alex Oren:
> > > A finalizer is invoked when an object is garbage
> > > collected but there is no guarantee it will ever be
> > > (e.g., when you have heaps of memory and a
> > > small number of objects).

Garry Lancaster:
> > Do you mean if an object is still uncollected at program
> > shutdown, the finalizer is not run before the memory
> > is returned to the system?  If so, could you supply the
> > official Sun reference for that?

Alex Oren:
> Here is what Sun says about finalization (heavily snipped):

(This is from the Java Language Specification. Version 2.0
I think.)

> | The Java programming language does not specify how soon a finalizer will
> | be invoked, except to say that it will happen before the storage for the
> | object is reused.

That last sentence is crucial. It bans reuse of memory
unless or until the finalizer is called. Finalization can
only be avoided for memory that is never reused.

> | Also, the language does not specify which thread will
> | invoke the finalizer for any given object. It is guaranteed, however,
> | that the thread that invokes the finalizer will not be holding any
> | user-visible synchronization locks when the finalizer is invoked. If an
> | uncaught exception is thrown during the finalization, the exception is
> | ignored and finalization of that object terminates.
>
> My comments:
> * When a program is "shutdown", is its storage "reused"?

Similarly, once a program is shutdown how can the
Java VM *prevent* the storage being reused? Or does
"reuse" mean, as I suspect, reuse-within-the-same-
Java-program-runtime? That's vague.

> * A program is not required to "shutdown".  It may
> continue running for eternity.

So, you are not one of these pessimists who
believe the universe will eventually come to an
end then? ;-)

I suggest that for all practical purposes the
situation where a program runs forever is not
worth discussing.

> Some more:
>
> | If the Java virtual machine detects that an unfinalized object has
> | become finalizer-reachable or unreachable, it may label the object
> | finalizable [...].
> |
> | If the Java virtual machine detects that a finalized object has become
> | unreachable, it may reclaim the storage occupied by the object because
> | the object will never again become reachable [...]
> |
> | At any time, a Java virtual machine may take any finalizable object,
> | label it finalized, and then invoke its finalize method in some thread.
> | [...]
>
> Notice the heavy usage of the word "may"?

Indeed. The vagueness of the specification arguably
allows a Java Virtual Machine to skip finalization of
objects that have not been finalized before program
exit. (If I had anything to do with this spec at all, I'd want
it to state unambiguously one way or the other what
should happen.) This finalizer skipping is certainly
*not* what we want in any C++ GC system. (Nor do
we want to import the vagueness, for that matter.)

[snip]

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---
[ 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@alex.gabi-soft.de> wrote in message news:<86d6v7jck7.fsf@alex.gabi-soft.de>...

> Perhaps I should state it differently: C++ destructors are one of the
> most useful features of the language, while I've yet to find any use
> for Java finalizers.
>
But you shouldn't conclude that finalizers are useless.  They're
needed, for example, if a garbage collected object references
uncollectable memory that must be explicitly deallocated.  When you do
need them, the only alternative is generally to redo the work of the
garbage collector in user code, which tends to be even more painful
than it would be to work around a missing destructor facility.

It's not at all clear to me that finalizers should be a language
feature in the same sense that destructors are.  A garbage collector
does need to support them. But a simple library interface to the
facility seems fine.  I have mixed feelings about whether objects
should be finalized by invoking the destructor or something else.

There are specific issues with Java finalizers in early
implementations that make them even less useful than they should be.
Locking in finalizers was problematic due to buggy implementations.
Some implementations intentionally, but in my opinion misguidedly,
delayed finalization as long as they could.  But I don't think anyone
is arguing for reproducing that behavior, so I don't think it's
relevant to this discussion.

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                       ]

"Garry Lancaster" <glancaster@ntlworld.com> wrote in message
news:b0pL8.54111$wd3.8911722@news6-win.server.ntlworld.com...
> > > Garry Lancaster:
> > > > > As far as I know the same is true in Java and C#.
> > > > > (Although I've heard it said that Java doesn't always
> > > > > call finalizers which is worrying if true, but in my
> > > > > experience fans of one language tend to overstate
> > > > > the problems of other languages. When people say
> > > > > Java leaks memory I confess that baffles me too.)

Some quotes from "Java in a Nutshell".  Not as authoratative as the Java
Spec, obviously, but one would hope this book would not get the things said
here so glaringly wrong.  (Typos and spelling mistakes, if found, are likely
mine.)

"Java makes no guarantees about when garbage collection will occur or in
what order objects will be collected.  Therefore, Java can make no
guarantees about when (or even whether) a finalizer will be invoked, in what
order finalizers will be invoked, or what thread will execute finalizers."

The "or even whether" part is telling here.

"The Java interpreter can exit without garbage collecting all outstanding
objects, so some finalizers may never be invoked.  In this case, though, any
outstanding resources are usually freed by the operating system.  In Java
1.1, the Runtime method runFinalizersOnExit() can force the virtual machine
to run finalizers before exiting.  Unfortunately, however, this method can
cause deadlock and is inherently unsafe; it has been deprecated as of Java
1.2.  In Java 1.3, the Runtime method addShutdownHook() can safely execute
arbitray code before the Java interpreter exits."

This makes it sound like not only is it possible for finalizers to not be
run during shutdown, but like it's very likely they won't be in most (all?)
implementations.

So it seems there's a reason for the claims, besides language advocacy.

Bill Kempf

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

Garry Lancaster wrote:
[...]
> If you look at C# under .Net there is *no difference* between
> destructors and finalizers.

Yeah, but if you look MORE closely at C# under .Net, you'll find out
'using'
["A using statement is translated into three parts: acquisition, usage,
and
disposal."]-'auto'-RAII-like-thing and Dispose() calls --
System.IDisposable
interface:

http://groups.google.com/groups?selm=3C84C7A9.5D14CF8D%40web.de
(Subject: Re: C++ for Java Programmers?)

regards,
alexander.

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

Alex Oren <response@myrealbox.com> wrote:

>On Wed, 29 May 2002 20:21:48 GMT, Brad Settlemyer wrote in
><qraJ8.9873$ib4.447387@news1.east.cox.net>:
>
>> Arrrggh!  Please not more undefined behaviour!  It seems possible to me to
>> throw an exception if an object is available for GC (tho now I guess I have
>> to go read all the Boehm stuff to find out).  Of course exceptions result
>> in  undefined behavior about half the time they are used as well, so
>> perhaps we could shore up some of those areas as well.  Please!  (I'm
>> begging, exceptions are really a pandora's box type of thing, but hope is
>> still in the box, and I'm still hoping that exceptions can be a little less
>> undefined).
>
>Going on a tangent, I would appreciate a change in the standard that
>will require a mandatory diagnostic for every undefined or
>implementation-defined behaviour.

  I agree as far as undefined behavior. Implementation-defined
behavior, I'm not so sure about: such code may be perfectly valid,
whereas code that produces undefined behavior can never be valid as I
understand it.

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt

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

Daniel Miller wrote:
>   Unlike Ada which has resumptive exceptions, C++ has abortive
> exceptions.

Ada does not have resumptive exceptions. Ada exceptions behave
just like C++ ones (except that they cannot be of arbitrary type).

---
[ 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@alex.gabi-soft.de> wrote in message
news:868z5vjbta.fsf@alex.gabi-soft.de...

>The role of garbage collection is to collect memory that is no longer
>in use.  It should not be used to manage other resources.  (Although
>from what I have heard, Java uses it for file descripters as well --
>any time it runs out of file descripters, it garbage collects, with
>the hope that some of the finalizers will free one or more.)

There may be Java implementations which do this; it isn't documented
behavior or part of the API definition.  It *is* part of the definition that
finalizers close files, but that's purely intended as a fail-safe mechanism.


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

"David Abrahams" <david.abrahams@rcn.com> writes:

|>  "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in messa=
ge
|>  news:YGjHIgK1y$88Ewaj@robinton.demon.co.uk...
|>  > In article <3CF3E5CE.2010809@tellabs.com>, Daniel Miller
|>  > <daniel.miller@tellabs.com> writes
|>  > >  I might put it another way: The Library Working Group & WG21
|>  > >& J16 must judge each entrant library unbiasedly unprejudicedly
|>  > >based on that library's merits & deficiencies regardless of
|>  > >whether that library was enterred into the competition by Boost
|>  > >or by any other person or organization.

|>  > The very large majority of those on the LWG are also members of
|>  > Boost, they are also human beings. The result is that most
|>  > things they might consider for the Standard Library will be
|>  > implemented by Boost, if only as proof of concept.

|>  Ehh, I wouldn't say that; we're also all busy human beings - there
|>  are a lot more potentially useful library ideas out there than the
|>  Boost contributors are able to code, document, review, approve,
|>  and maintain. Even if we happen to dabble in some area it's a long
|>  way from a proof-of-concept to something appropriate for
|>  standardization.

I think that there's another point that is worth pointing out.  Boost
was originally founded by members of the standards committee, and it
was certainly in the back of their heads that Boost should prepare
some of the future library.  But Boost is much more than that; it has
become *the* repository for reusable code.  Thus, while I don't think
that something like CRC should become part of the standard (and I
suspect that a number of Boost members would agree with me that it is
too specialized), I still appreciate the fact that Boost makes it
available.  Any time I need something that is not 100% specific to my
application, my first stop is Boost.  I don't always find what I need,
but generally, if I don't find it there, I don't find it elsewhere,
either -- at least not with adequate quality.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Do you need real expertise in C++? in Java? in OO design?
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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 Hagan wrote:
> "David Rasmussen" <pinkfloydhomer@yahoo.com> wrote...
>
>>Ken Hagan wrote:
>>
>>>C++ is full of design errors, many of which were inherited from C.
>>
>>Indeed. Let's remove them.
>
>
> [snip, quite a lot, including]
>
>
>>Anytime I hear the "expert" defense, I always want to ask: "Yes, but on
>>the other hand, what would you lose by giving up this old way of doing
>>things?".
>
>
> I get the impression that you assume C compatibility is the only problem
> here. It is probably the main problem, hence my use of "many", but one
> shouldn't neglect problems of C++ compatibility.
>

C compatibility isn't the only problem. But it is the core of many problems.

> Anytime you ban dangerous constructs, or change the semantics, you break
> existing code. Your suggestion to tighten up the scoping on enums would
> break any code that has learned to live with the existing brain-death.
>

I know that, but if language can never change to break existing code, it
is doomed. The semi-strong enums of C++ broke with C's enums. When
strstreams were deprecated and stringstreams were standardized, it broke
a lot of existing code. This is inevitable, and a good thing, IMO. If we
can't change the language for the better because it breaks badly
designed code, then it is doomed.

> Also, most people are programming for operating systems that have no C++
> API, but instead force us to use C headers. There's a *lot* of stuff in
> <windows.h> that I wouldn't want to see in my own company's code, but I
> wouldn't want my compiler to start rejecting it.

C++ isn't compatible with C anyway. And the two languages are diverging
anyway.

/David

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

"David Rasmussen" <pinkfloydhomer@yahoo.com> wrote...
>
> If the programmer really wants an integer type that will always be
> within 0..100, it is very valuable to be able to state so.

If you want the value to always be within 0..100 you need to be careful
what values you assign to it.

A compiler can insert code automatically to check this on the customer's
machine (sorry, at run-time), and throw an exception, but this doesn't
strike me as very useful moment to discover your logic error. If you
disagree, and are happy to discover these things whenever they choose
to crop up, you can write the code yourself.

If you are prepared to do some "whole program" analysis, you might be
able to *prove* that the value never falls outside the range. I don't
think a compiler should be required to do that.

Until then, you have an integer type that will merely be presumed to be
within 0..100. That's much less useful.

I wouldn't mind a language feature that told me when I was at risk of
arithmetic overflow. However, I don't think simply adding ranges to
the type meets this goal. I think it runs into exactly the same problems
as exception specifications did when they are used with templates.
Without whole program analysis you can't prove whether they've been
violated or not.


---
[ 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 Fri, 31 May 2002 16:59:33 +0100, "Ken Hagan"
<K.Hagan@thermoteknix.co.uk> wrote:
[snip]
> If you are prepared to do some "whole program" analysis, you might be
> able to *prove* that the value never falls outside the range. I don't
> think a compiler should be required to do that.
>
> Until then, you have an integer type that will merely be presumed to be
> within 0..100. That's much less useful.

I think there might be some use for a ranged type, as long as it didn't
freely convert from the basic type. If any such conversion has to be
explicit, the compiler would be able to prevent you from assigning a
potentially out-of-range value unless you specificly request it. There is
still the problem that the programmer has to deal with potential
out-of-range exceptions at these points in the code, but a ranged type
would help to narrow down these places, I would have thought.

I've been working on a template for representing natural numbers, which is
much simpler but has similar advantages.Actually, the natural number class
is probably more useful than general ranged types, because you know that
if you add two natural numbers the result is a natural number (so no need
to worry about out-of-range exceptions). So you can have this:

natural<int> n1(10), n2(5), n3(0);

n3 = n1 + n2;
n3 = n1 - n2; // doesn't compile, because the result might be negative
n3 = natural<int>(n1 - n2); // compiles, but may throw an exception

For a general ranged type, though, all the mathematical operations could
yield a result outside the range (I think), so the value of such a type
might be much more limited.

--
"Mr I V Lenin, the Lenin of love"

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

"Daniel Miller" <daniel.miller@tellabs.com> wrote in message
news:3CF4F979.4030101@tellabs.com...
> Ross Smith wrote:
>
> > Daniel Miller wrote:
> >
> >>   Instead so far I see statements in postings which indicate that
> >> Boost would
> >> in fact receive some form of preferrential treatment over competing
> >> entrants in
> >> the competition for standardization.
> >>
> >
> > That was more or less the whole point of Boost. I don't understand why
> > you see it as a bad thing.
>
>
>    I would hope that all members of LWG, WG21, and J16 have the goal of
doing
> the best job possible, which includes standardizing the best libraries
possible,
> regardless of who submitted them.  If an inferior entrant from Boost were
to be
> submitted for standardization consideration and 1 or 2 or 3 superior
libraries
> covering that same topic are also submitted for consideration, I would
hope that
> LWG or WG21/J16 would perform some sort of bake-off allowing a fair &
equal
> direct apples-to-apples comparison between the various entrants,
measurement of
> simplicity/directness of expressing a concept in code, assessment of
reliability
> of behavior, measurement of various efficiencies, and measurement of
> expressivity & extensibility as a solution-space for all of the major
> problem-spaces.

I see no evidence that this won't be the case.

>    One such major problem-space for multithreaded software is realtime
embedded
> systems, portability to RTOSes, and support of realtime embedded system
idioms.
>   Boost.threads (in its current form as well as what has been revealed as
> Boost.threads' intended future form) ignores:

Not entirely fair, though this perception is likely more my fault than
anything else.  I've got a very focused plan for Boost.Threads, which I have
to have to get the library into a form that's usable and a good basis.
There's some things that are missing for RTOSes that I'm aware of, and those
*ARE* planned today.  Of course this may not be obvious since they mostly
fall under the category I've labeled as "thread parameters" when I've talked
about this on public lists.  Beyond this there are only two other things
brought to my attention that is need by RTOSes, and they are at least
somewhat debatable:

* Semaphores.  As I've said publicly, I've not counted semaphores out
entirely.  So this criticism, though possibly valid, is not evidence that
Boost.Threads will (or has) made the wrong decision in this regard,
RTOS/embedded systems or no.

* Event queues.  I believe this concept to be higher level then the scope of
Boost.Threads.  I also believe it to not be a thread specific concept (I
know others disagree about this, so there may well be something I'm not
understanding here).  Despite this I think it an important concept, and one
that probably should be standardized.  So I don't think it's exclusion
should rule out Boost.Threads, RTOS/embedded systems or no.

My plans are to finish development of Phase 2, which I'm working on now,
which will bring Boost.Threads to the point of being usable and a good
basis.  At that time I'll want several folks, such as yourself, to look at
it very critically and voice all your concerns about what's wrong or missing
from your standpoint (this means the standpoint of RTOS/embedded systems for
you, I guess).  I will listen very actively to what is said at that time,
and hopefully Boost.Threads will become (if it isn't already by the time
Phase 2 is complete) something that you aren't so critical of.

In any event, whether or not I succeed, if you propose an alternative
library I would fully expect the committee to evaluate both equally, and I
see no evidence that this wouldn't be the case.

>    1) many of the needs of realtime embedded systems,
>    2) the multithreaded idioms which the realtime embedded software
industry has
> built up over the past 2+ decades of using multithreaded software in
industrial
> practice,
>    3) portability to RTOSes.
>
>    http://www.boost.org/status/compiler_status.html
>
>    As further evidence, Boost (especially Boost.threads) does not even
list
> *any* RTOSes as the platforms to which it ports.  To even *consider*
submitting
> a
threads/interthread-synchronization/interthread-asynchronous-communication
> library for standardization which ignores (in part or in full) the RTOSes
& the
> embedded realtime software industry:
>    1) is embarrassing (for the C++ community at large) and
>    2) is a tragedy (for humankind which is becoming increasingly dependent
on
> realtime embedded software for safety and survival).

Boost is a volunteer effort.  I'm not an RTOS/embedded programmer, and have
not claimed to be.  I can't do the port, or evaluate trouble areas in the
design in regards to this (at least as fully as a domain expert can).
What's needed is for volunteers, such as yourself, to do this legwork.
Everyone would welcome such an effort.

In any event, assuming that just because this work has not occured in Boost
yet that it won't, or that if it never does the committee wouldn't take that
into consideration (and either find someone to do the legwork or reject the
library because of this), is, simply, unfair.  There's no evidence that this
will be the case.  Using strong emotional language such as "embarassing" and
"tragedy" just promotes FUD, and doesn't help either the Boost effort, or
the future standard, which *ARE* seperate things no matter what some want to
think.

>    I and others in the realtime embedded software industry must ask
ourselves:
> Is Boost.org functioning as a community where the needs of the realtime
embedded
> software industry are well-respected & welcomed?

Why must you ask that?  Have you seen any evidence of hostility or
disrespect?  Have you volunteered to get any of Boost to work in this area?
Just because there's not been any volunteers with the ability to do this is
not an indication that Boost is hostile to it.  In fact, the opposite is
true.

>  If Boost.org in the large (and
> Boost.threads in particular) does not fully address the needs of the
portion of
> the realtime embedded software industry whose software is based on C++,
then the
> realtime embedded software industry must look elsewhere for a voice into
the
> C++0x library standardization effort.

Again, Boost is a volunteer effort.  If the embedded folks want Boost's
voice to speak for them, they must volunteer to be part of that voice.

As for Boost.Threads specifically, I know I have a PR problem.  I've taken
on a very large project with Boost.Threads, and the only help I've received
is criticism.  (Not totally accurate... Mac Murrett has provided a port to
the Macintosh Carbon platform and Dave Moore has provided many of the new
classes that will be included in Phase 2.)  Though this criticism is helpful
and very welcome, since I'm the only one doing the effort I have to make
some decisions that I know are short sighted and may not be the proper final
solution, in order to be able to get a complete usable basis that I can
safely explore some of the trickier criticisms with.  All I can ask is that
you hold off final judgement until after Phase 2 is complete and we enter
Phase 3 (criticism and exploration of areas that are lacking or need
redesign).

>    GLOSSARY
>
>    interthread asynchronous-communication = the
(multi)producer-(multi)consumer
> message-queue idiom, such as in pSOS.  In this idiom one or more threads
can
> post to a message-queue which is read by one *or* *more* threads which
pend on
> that message-queue.  The threads which all pend on the same message-queue
> comprise a lightweight thread-pool which is scheduled by the kernel, not
by the
> application-domain.  The RTOS-style multiproducer-*multi*consumer
message-queue
> idiom is omitted from Boost.threads.
>
>    RTOS = realtime operating systems, e.g., pSOS, VxWorks, QNX, LynxOS

Just an FYI, I do plan to check out pSOS to see if I really am missing
something in my evaluation of whether or not a "message queue" is a) within
the scope of Boost.Threads (note that pSOS isn't part of pthreads, so
there's at least some evidence that my belief is likely correct) and b) a
multi-threading specific idiom.  I just have too many other things on my
plate to do this immediately.

In conclusion, I welcome your criticism of Boost.Threads, and most of it is
probably warranted today, but hopefully it won't be once we reach Phase 3.
However, the criticism being targeted at Boost and the committee does not
seem warranted in the slightest, and I find it disheartening that it's being
done because of the perceptions people have of Boost.Threads.

Bill Kempf

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

"James Kanze" <kanze@alex.gabi-soft.de> wrote in message
news:868z62t0vo.fsf@alex.gabi-soft.de...
>"Garry Lancaster" <glancaster@ntlworld.com> writes:

>|>  People looking for a C++ GC system shouldn't overlook
>|>  boost::shared_ptr. It can't easily cope with cyclic references
>|>  (although at a pinch there are various ways to break the cycle)
>|>  but if you can live with that limitation it may do everything you
>|>  want.

>Not really.  It doesn't work in quite a number of real programs.  The
>problem is simple: in C++, you *have* raw pointers.  You can't avoid
>it, because "this" is a raw pointer.  So you inevitably end up with
>some raw pointers that are involved in ownership.  With some counted
>pointers, you can convert these into a counted pointer without
>problems, but with the Boost shared_ptr, you must convert the raw
>pointer exactly once; converting it a second time will lead to
>prematurely freeing the memory.

It's true that boost::shared_ptr doesn't do this directly, but I think
that's the proper decision given the design constraints.  There are options,
however.  You can opt instead for a Loki style smart pointer where you can
change the policy here.  You can use the new facilities that allow for
intrusive ref-counting which eliminates this problem.  You can use the new
weak_ptr to externalize your own mapping of raw pointers to shared_ptrs.

I know you are aware of this and your criticisms are justified when looking
at whether or not to standardize boost::shared_ptr, but I don't think they
apply to the claim made above.

>|>  As for destructors != finalizers, I think the existance of
>|>  increasingly GC-like smart pointers in C++ means the line is now
>|>  very blurred. I'm not sure it is a useful distinction any more.

>The problem is perhaps one of vocabulary, but C++ destructors are
>totally unrelated to Java finalizers.

>Even with garbage collection, C++ destructors must be run when local
>variables go out of scope, at the end of program on static variables,
>and when delete is explicitly invoked.  It is less obvious what should
>happen when an object is collected; my personal feeling is that
>destructors should NOT be called in this case.

A valid opinion, but I don't agree.  If they aren't called you'll have to
expose a seperate finalizer mechanism for objects any way, and to me it
makes sense to simply "reuse" the destructor for this.  There may be issues
with doing this, since there are some things that are natural to do in
destructors that are dangerous to do in finalizers, but in my mind it's only
corner cases where a destructor might be used both for deterministic
destruction of objects in the "unmanaged" space (to borrow from .NET) and
for finalization in the "managed" space in such a way that it's unsafe.

Just for a real world example, the C++ binding for the Boehm collector uses
the destructor for finalization (at least it does by "default" if the type
derives from "gc_cleanup" or contains a member derived from "gc_cleanup"...
it's not obvious from the documentation if the destructor is called for
other "collectable" objects, and I've not had the oportunity to use it in
real code).

Bill Kempf

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

Gabriel Dos Reis <gdr@merlin.nerim.net> wrote in message news:<m36615bqsu.fsf@merlin.nerim.net>...
> Ross Smith <r-smith@ihug.co.nz> writes:
>
>
> | Well, the mere presence of GC in the language wouldn't break anything,
> | provided nobody actually used it. Perhaps I should have said, _using_
> | GC would break RAII, because GC could only be used on classes with
> | trivial destructors.
>
>
> Why? Could you elaborate on that?  I'm unclear with yoru assertions.

I'm not sure what Ross Smith had in mind, but I believe the standard
argument is that garbage collectors generally can't invoke a
destructor immediately when an object is dropped.  Instead they
usually substitute an asynchronous finalization facility.  These
"finalizers" are invoked asynchronously at some later point.  In
contrast, if you used something like reference counted smart pointers
(which is the minimum you would need in cases in which GC is otherwise
useful), you could invoke destructors immediately.

Although this is indeed a characteristic of garbage collectors, the
rest of the argument is wrong.  This is easiest to see in the
multithreaded case, where heap destructors often need to lock, and
synchronous, but hidden, invocation of heap destructors clearly leads
to deadlocks.  Asynchronous invocation is the only thing that makes
sense.  For a more detailed justification of this claim, see
http://www.hpl.hp.com/personal/Hans_Boehm/gc/det_destr.html .

It's also worth remembering that in pure garbage collected code
destructors/finalizers tend to be very rare.  In my experience,
perhaps 0.1% of objects need to be finalized.  Most resources managed
by heap objects are really memory.


Hans-J. Boehm

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

Ross Smith <r-smith@ihug.co.nz> wrote in message news:<ad4ls5$3b3$1@lust.ihug.co.nz>...

> So why bother with GC, when we have all that already? Nobody sane ever
> writes an explicit call to delete any more, except on the very rare
> occasions when they're actually implementing a smart pointer (and the
> addition of a good smart pointer library to the standard will do away
> with most of those occasions too). GC adds nothing except gratuitous
> compiler complexity.
>
So would you care to propose a smart pointer scheme that

a) Doesn't complicate the user's job, e.g. by requiring that I have
enough global understanding of the whole program to avoid pointer
cycles, or requiring me to understand lots of extra usage rules that
don't apply to regular pointers.

b) Is performance competitive with either a good conservative GC, or a
good Java GC, particularly for multithreaded code?  You might find the
performance measurements in
http://www.hpl.hp.com/techreports/2000/HPL-2000-165.html and
http://www.hpl.hp.com/personal/Hans_Boehm/gc/myths.ps useful to look
at as a starting point.

c) Allows me to acquire locks in destructors without spurious
deadlocks.  (See my previous message.)

?

Hans-J. Boehm

---
[ 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@alex.gabi-soft.de> wrote in message news:<861ybut0fi.fsf@alex.gabi-soft.de>...
> Dan Smart <cppdan@dansmart.com> writes:
>
> |>  I have also been reliably informed that thread context switches in
> |>  Java are more expensive than in C++.
>
> That's possible.  But if you're context switching enough for it to
> make a difference, you probably aren't using threads correctly anyway.
>
I doubt this is true for (e.g. involuntary) context switching itself.
There are issues with the Java synchronization primitives, which may
sometimes add some overhead.

Modern Java implementations of which I'm aware generally either:

1) Use the standard thread library for the platform.  ("Native
threads")  There is no difference between Java and C++ thread
switches.  Sun's HotSpot, gcj, and I believe IBMs JVMs all do this.
It makes inter-language calls much easier/efficient.  (And sometimes
more correct.)

2) They use a Java-specific threads mechanism which is believed to be
faster.  I think NaturalBridge and the IBM Jikes Research VM (formerly
known as Jalapeno) both do this.

I'm personally a great believer in option (1).  There are sometimes
good reasons for (2).  I haven't a clue as to why you would invent a
special slower context-switch mechanism for Java, except possibly if
that accelerated other frequent operations.

Hans-J. Boehm

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

It would be good if you took a look at Ada to see how its
tasking model works. There's a lot of good design there
that has withstood the test of time.

See <http://www.ada-auth.org/~acats/arm-html/RM-9.html>.

(Just make sure you *don't* implement Asynchronous Transfer
of Control :-)

Also, the Ada95 Rationale explains some of the design decisions in
quite a bit of detail, and is worth perusing to see what bases
they tried to cover. In particular, changes were made to the Ada83
tasking model in response to the needs of the Real-Time community.

See <http://www.adapower.com/rationale/rat95-p2-9.html>.

---
[ 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 Tue, 28 May 2002 20:10:45 GMT, Christopher Eltschka wrote in
<ad0n4d$kj6$1@news.tuwien.ac.at>:

> Hyman Rosen <hyrosen@mail.com> writes:
>
> > Strong typedefs should have the following syntax:
> >  typedef new declaration;
> > eg.,
> >  typedef new unsigned char byte;
> >  typedef new void (*vfp)();
>
> I like that syntax.
>
> >
> > These new types have no automatic conversion to or from their
> > source type, but can be converted using static or functional
> > cast, eg.,
> >  unsigned char c;
> >  byte b = c; // illegal
> >  byte b = byte(c); // ok
> >  byte b = static_cast<byte>(c); // ok
> > They should have automatic conversion from literals of their type, eg.
> >  typedef new long nl;
> >  nl an_nl = 17L; // ok
> >  nl an_nl = 17;  // illegal
> >
> > All types will need to have a defined set of primitive operations.
> > Then a new type receives a set of these primitive operations. For
> > the arithmetic types, this includes the usual operators, for pointer
> > types this includes indirection and subtraction, and so forth. This
> > prevents mixed arithmetic. Eg.,
> >  typedef new int my_int;
> >  // my_int operator+(my_int, my_int);
> >  // my_int operator*(my_int, my_int);
> >  // ad nauseum
>
> I'd like to be able to avoid certain operators. For example, I'd like
> to be able to do
>
>   typedef new double Temperature;
>
> and disallow multiplication of two temperatures (whatever that product
> may be, it's for sure not a temperature).

Looks like an overkill to me.  It is not a big problem to create a class
that will only implement certain operators.

What about automatic conversion from Temperature to double?  Should it
be allowed?  If not, how will we pass to external functions?

Hmmm...  This brings another question.

Given some class T, how can we disallow automatic conversion now?
E.g.:
 T t;
 int i;
 i = t; // Error
 i = static_cast<int>(t) // OK


Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

---
[ 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-J. Boehm wrote:

> Gabriel Dos Reis <gdr@merlin.nerim.net> wrote in message news:<m36615bqsu.fsf@merlin.nerim.net>...
>
>>Ross Smith <r-smith@ihug.co.nz> writes:
>>
>>
>>| Well, the mere presence of GC in the language wouldn't break anything,
>>| provided nobody actually used it. Perhaps I should have said, _using_
>>| GC would break RAII, because GC could only be used on classes with
>>| trivial destructors.
>>
>>
>>Why? Could you elaborate on that?  I'm unclear with yoru assertions.
>>
>
> I'm not sure what Ross Smith had in mind, but I believe the standard
> argument is that garbage collectors generally can't invoke a
> destructor immediately when an object is dropped.  Instead they
> usually substitute an asynchronous finalization facility.  These
> "finalizers" are invoked asynchronously at some later point.  In
> contrast, if you used something like reference counted smart pointers
> (which is the minimum you would need in cases in which GC is otherwise
> useful), you could invoke destructors immediately.
>
> Although this is indeed a characteristic of garbage collectors, the
> rest of the argument is wrong.  This is easiest to see in the
> multithreaded case, where heap destructors often need to lock, and
> synchronous, but hidden, invocation of heap destructors clearly leads
> to deadlocks.  Asynchronous invocation is the only thing that makes
> sense.  For a more detailed justification of this claim, see
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/det_destr.html .
>
> It's also worth remembering that in pure garbage collected code
> destructors/finalizers tend to be very rare.  In my experience,
> perhaps 0.1% of objects need to be finalized.  Most resources managed
> by heap objects are really memory.

  Experience in other languages/cultures/axiom-systems might not apply to C++ broadly or might not apply to certain C++ schools-of-thought.  This is due to the 100%-of-resource-allocation-in-ctor and 100%-of-resource-deallocation-in-dtor rules which are preferred in the C++ community.  These rules form the basis of being able to use C++ as a form of transaction-programming system, where try is begin-transaction and throw (with its stack unwinding) is the abort-transaction mechanism.  The set of objects on which garbage-collection would be performed would not only be releasing memory, but also directly or indirectly/ultimately incrementing semaphores, closing files, releasing mutexes, closing connection-oriented networking connections, and so forth, especially in large (multithreaded, multiprocessor) realtime embedded systems which are focused on interacting with the outside world which is full of resources (or software-model representations of resources).  Any garbage collec
tion system which does not call dtors in certain cases during "normal operations" erodes the integrity of C++'s XP capabilities to the point that such GC would need to be strictly prohibited from realtime embedded systems, so that resource-releasing (i.e., the 100%-of-resources-released-in-dtor rule) is not undermined or compromised during transaction-abortion in XP.


   Note my statements here are part of the larger viewpoint that C++ is
not merely some garden-variety OOP language.  C++ is first & foremost by
its design & mission: a *multiparadigm* language.  The multiple
paradigms supported in C++98 are:

   POP: procedure-oriented programming

   OOP: object-oriented programming

   GP: generic programming

   XAOP: transaction-oriented programming

   In Ada95 one can *directly* express POP, OOP, and GP, but not XAOP
due to Ada's resumptive exceptions instead of C++'s abortive.

   In Java one can *directly* express POP, OOP, and XAOP to some degree,
but not GP due to Java's lack of parameterized-types.

   We must strictly guard against eroding this primary & fundamental
mission of C++ of being a multiparadigm language (e.g., eroding XAOP by
relaxation of dtor-invocation guarantees) in the interests of me-too
feature-creep pressure from other languages which have automatic
general-purpose GC.  Preserving the *multi* of multiparadigm is vastly
more important in C++ than achieving ultimate perfection within any one
paradigm (e.g., an attempt keep up with the neighboring Jones-language's
automatic general-purpose GC in nontransactional/canonical OOP) at the
cost of another paradigm (e.g., damaging XAOP by treating
dtor-invocation lightly).  Quite honestly C++ is not the best/most-pure
OOP language, nor should it be if such OOP perfection erodes the other
POP, XAOP, or GP paradigms.  Conversely, any proposed feature which both
   1) does not disrupt any of the multiple paradigms and
   2) adds value to at least two or more paradigms
is likely to be a decent or good or excellent feature.  (For the most
part the content of C++98 fully meets these 2 criteria, because the
people responsible for the C++98 standardization ensured that POP, OOP,
GP, and XAOP work properly, not only in paradigm-isolation, but also
work properly *together* as a cooperating interwoven multiparadigm
system of programming).

   C++ is the only mainstream multiparadigm language which has 4 of the
past few decades' major programming paradigms: POP, OOP, GP, and XAOP.
C++ is not merely a tool; C++ is an entire toolbox, an entire unified
system of thought.  Since C++98 is an achievement for humankind in its
largely-successful support for 4 interwoven & mutually-cooperating
programming-paradigms, this great achievement must be preserved without
corruption and without erosion as new proposed features are evaluated.

   The "garbage collection" techniques which rely on a programmer's
elective use of one or more smart pointers does in fact mesh well with
POP, OOP, GP, and XAOP.  This is especially true if the smart pointers
which would be eventually standardized as part of C++0x are:
   1) extensible and
   2) somehow handle the multithreaded situations well and
   3) somehow handle the cycle-of-dependencies situations well.

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

Daniel Miller wrote:
[...snip...]

> erodes the integrity of C++'s XP capabilities to the point
> that such GC would need to be strictly prohibited from realtime embedded
> systems, so that resource-releasing (i.e., the
> 100%-of-resources-released-in-dtor rule) is not undermined or
> compromised during transaction-abortion in XP.


   By the way, these "XP"s should have been XAOP.  I am not referring to
the XP = Extreme Programming methodology.

[...snip...]

>   XAOP: transaction-oriented programming

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

Howard Gardner wrote:
>
> Craig Powers wrote:

[...]

> > I'm thinking I wind up doing something not unlike this in COM
> > programming, only I skip the forwarding entirely.
> >
> > template <typename Itf>
> > struct Implementation_One : public Itf
> > // etc.
> >
> > template <typename Itf>
> > struct Implementation_Two : public Itf
> > // etc.
> >
> > template <typename Implementation>
> > struct Realization : public Implementation
> > {
> > };
> >
> > typedef Realization<Implementation_One<Interface> > Realization_One;
> > typedef Realization<Implementation_Two<Interface> > Realization_Two;
> >
> > The devil being in the details, I'm not 100% sure I've done the
> > translation from what I have to do to what you have to do correctly.
>
> There's tho obvious difference in the inheritance structure. In your
> version, Implementation_One and Implementation_Two are derived from
> Interface: in mine they aren't derived from anything. In your version,
> Realization is derived from Implementation: in mine, it's derived from
> Interface.

That's true.

>From the side of Realization, this isn't an issue for me.  It gets to
Interface eventually, and it doesn't matter if there's an extra step
(or, in some cases, two) in the way.  I don't know, offhand, what sort
of issues there would be with this difference, if you are aware of any
can you enlighten me?

>From the side of the Implementation classes, I can understand, in an
abstract sort of way, that adding the base class might cause problems,
but there aren't any practical problems that present themselves to me.
Do you have any practical problems in mind?

> One thing that bugs me about that is the fact that Realization may or
> may not end up being derived from Interface: the choice is made by
> Implementation_XX.

True.  Not an issue in the problem set where I work.  It is possible
that someone will make a Realization that does not, in fact, inherit
from Interface.  I guess whether the increased flexibility is a good
thing or a bad thing really depends on the context where you're
using it.

> A second thing that bugs me about it is the fact that the
> implementations are no longer nice little concrete classes. Instead
> they're templates: the set of C++ implementations that handle templates
> is still smaller than the set of all C++ implementations. What's more,
> they have inheritance baggage (a vtable). That means that if you write
> an app to use one and only one implementation, you either pay for the
> unneeded structure or you perform the unnatural act of deriving it from
> an empty class.

Well, when we're discussing additional things going into the
standard, I'm not so sure we need to consider implementations that
don't handle (this subset of) template functionality.  Is it realistic
to expect that an implementation would, in the future, support the
extension you proposed but not templates?

Regarding the the vtable - Interface has a virtual function, so
Realization will wind up with a vtable regardless.  Does having a
vtable in Implementation increase the size of the vtable in
Realization?

> The third thing that bugs me about is the fact that the structure has to
> have been known at the time that the implementation was created. That
> makes the approach unsuitable as a retrofit. I first stumbled on this
> technique while salvaging a trusty old communications library.
> Everything about that library was "right" except that there was no sane
> way to extend it.

This is a definite drawback to the template method and a spot where the
new language feature appears to have a definite advantage.

> > Now, since it's COM, the usage is pretty limited (things should get
> > called only through Interface, except in the same project, in my
> > usage), so it's entirely possible I'm glossing over some pitfalls.
> > Also, I expect that there's some pretty nasty code bloat with the way
> > the templates are used, but since it's COM, that's not an issue for
> > me -- the code would be bloated anyway since there's no effective
> > binary re-use (I'd otherwise have to copy all of the code, making it
> > a maintenance nightmare).
>
> I don't think there's any bloat factor difference unless someone
> actually exercises the option you give them to have more than one
> kind of Interface. Since that option isn't real (it seems to me that LSP
> implies that varying the Interface would require varying Implementations
> too) it's not an issue.

I have a set of COM CoClasses that implement their own interfaces as
well as a common interface, with a set of functionality in common
between the two.  In this case, a varying interface does make sense.
The template method is convenient because it allows me to re-use a
large amount of common code and keep it in one place.

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

Gabriel Dos Reis <gdr@merlin.nerim.net> writes:

|>  James Kanze <kanze@alex.gabi-soft.de> writes:

|>  [...]

|>  | The first is addressing memory mapped IO -- the IO ports are at
|>  | fixed addresses, so you typically want to do something like:

|>  |     *static_cast< unsigned char* >( 0xffffffe0 ) =3D 0x21 ;

|>  | This doesn't bother garbage collection (the address 0xffffffe0
|>  | doesn't interest garbage collection), and I would not like it
|>  | being removed from the language, even if 99% of the applications
|>  | never need it (or can't even use it, because such things don't
|>  | work in user mode under Unix, Windows, or any other real
|>  | multi-user OS).

|>  I didn't see any wording to remove the above feature from the
|>  language.

|>  If I recall correctly, the idea was to have a GC and being able to
|>  register specific objects as GC-able. Naturally, some restrictions
|>  will be imposed of the sort of things you can do with the
|>  addresses of such objects.

Two postings earlier in this thread, Francis said:

    More precisely, providing an optional mechanism that will allow
    compilers to reject code that is unsave in a GC environment. For
    example, converting integer types to pointers (because that allows
    programmers to use idioms that hide pointers)

All I'm saying is that there is no need to ban this for garbage
collection to work. In fact, for garbage collection to work, I don't
think that anything really useful needs to be banned at the user
level -- while it is currently legal to "hide" pointers by writing
them to disk, etc., I don't see any real utility in it (but I could be
mistaken).

Of course, the compiler must be garbage collection aware, since it is
possible to "hide" pointers in the generated code, even if they aren't
hidden in the source.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Do you need real expertise in C++? in Java? in OO design?
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

"David Abrahams" <david.abrahams@rcn.com> writes:

|>  "Ross Smith" <r-smith@ihug.co.nz> wrote in message
|>  news:ad24ic$i92$1@lust.ihug.co.nz...
|>  > Daniel Miller wrote:

|>  > >    Instead so far I see statements in postings which indicate
|>  > > that Boost would in fact receive some form of preferrential
|>  > > treatment over competing entrants in the competition for
|>  > > standardization.

|>  > That was more or less the whole point of Boost. I don't
|>  > understand why you see it as a bad thing.

|>  Sorry, I can't tell precisely what meaning was intended above, but
|>  just to be clear: the point of Boost was never to get
|>  preferrential treatment "over competing entrants in the
|>  competition" for standardization. The point of Boost with respect
|>  to the standard is/was always to make sure that some libraries
|>  appropriate for standardization would exist *at all*. In fact, the
|>  field of candidate libraries is so small that there's little or no
|>  opportunity for actual competition.

I think that the simplest explination is that the people in Boost are
doing their homework.  Some people seem to be upset because it has
been suggested that people doing their homework might get better
grades.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Do you need real expertise in C++? in Java? in OO design?
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

John Nagle <nagle@animats.com> writes:

|>  Garry Lancaster wrote:

|>  > John Nagle:

|>  >>    Some assistance on the storage management front is useful,
|>  >>but garbage collection and destructors don't play well together.
|>  >>The semantics get wierd.  Look at Microsoft's "managed storage"
|>  >>system for C++.  Painful.

|>  >>A destructor is not a finalizer, and vice
|>  >>versa.

|>  >>    GC works better with Java semantics.

|>  > What's the problem? As far as I understand it the golden rule is
|>  > not to touch any GC pointers in a destructor. If you follow that
|>  > simple rule, there is no problem.

|>       You don't know when the destructor will be called, if ever.
|>  So file closing, window closing, socket closing, database closing,
|>  and related operations may not happen when wanted.

So don't use garbage collection for objects which do these sort of
things in the destructor.  (Note that most of the examples given have
a return code which must be handled, so cannot be deferred to the
destructor anyway, except in special cases.)

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Do you need real expertise in C++? in Java? in OO design?
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

David Abrahams wrote:
[...]
> You must have a very odd definition of "safe" if you think that's so. What
> do you think is unsafe about throwing in a destructor when the destructor
> contains a catch(...) clause?

See below/please answer the question that Mr. Sutter chose to
ignore (thus far/yet).

> I have no defense for the design of exception specifications; they're not
> terribly useful anyway so it's just as well that you don't feel compelled to
> use them. However, there are no opportunities for undefined behavior with
> exception-specifications AFAIK.

They ARE terribly useful already (NOT terribly useful unwinding up-to
'simulated' catch(...)-thing aside; that's somewhat 'brain-dead'-thing,
in general [w/o ES protection] IMO) and COULD be made even MORE useful,
I think; see "fencing the parms/args: foo( *...PARMS...* ) throw()" bit
below... and, perhaps someone could also comment on "// throw() ;-)" bit
here as well:

T& T::operator=(T temp) // throw() ;-)
{ return this->swap( temp ); /* nothrow */ }

http://groups.google.com/groups?selm=3CE695E1.29E4EEDB%40web.de
(Subject: Re: stack size vs. thread stack size)

[quote]

Newsgroups: comp.programming.threads, comp.lang.c++
Date: 2002-05-18 11:08:04 PST

< cross-posted to comp.lang.c++ >

"Hillel Y. Sims" wrote:
>
> "David Butenhof" <David.Butenhof@compaq.com> wrote in message
> news:EKME8.14$ns3.344208@cacnews.cac.cpqcorp.net...
> >
> > The "yellow zone" is an attempt to improve on all that. It's essentially
> > another red zone to start with. Except that when the zone is "violated" by
> > stack incursion, it's changed to "green". This gives an extra page (or two,
> > or whatever is necessary) for the thread to handle the situation, either by
> > delivering a signal or raising an exception. Ideally, if the event is
> > cleanly handled, the yellow page(s) will be automatically "painted red"
> > again by the OS when the stack is unwound into the green zone. (Tru64 UNIX
> > works this way; OpenVMS, which also has yellow zone, doesn't convert a used
> > yellow page back to red.)
>
> What kind of exception is thrown when you hit the yellow/red zone?

Whatever[1] is thrown, personally, I can't really COMPREHEND
how to deal with it... if it happens to occur invoking/inside
some NOTHROW call, I mean.

Perhaps someone could help me. PLEASE. TIA.

[...]

[1]
http://groups.google.com/groups?selm=c29b5e33.0202161451.2ef75f1f%40posting.google.com

"Herb Sutter <hsutter@acm.org> wrote in message
 news:<jtas6uggftq6lt2o3uhn8halcpg1ae6g7c@4ax.com>...
 [...]
 > Yes, but you can have the nothrow guarantee whether the exception
 > specification says so or not. In fact, I usually write declarations for such
 > functions like this: "X f( Y ) // throw()".

 And who is protecting your clients from really bad
 things (exceptions/faults) along the lines of:


http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51_HTML/ARH9RBTE/DOCU0011.HTM#excep_defs
 ...."

< NO answer from Mr. Sutter... yet.. here is @ *MICROSOFT* now, BTW >

>From the URL above:

"....
 pthread_stackovf_e  Attempted stack overflow was detected
 ...."

http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51A_PDF/ARH9RBTE.PDF
("Tru64 UNIX|Guide to the POSIX Threads Library")

"....
 A guard area, with its associated overflow warning area,
 can help a multithreaded program detect overflow of a
 thread's stack. A guard area is a region of no-access
 memory that the Threads Library allocates at the overflow
 end of the thread's stack, following the thread's overflow
 warning area. If the thread attempts to write in the
 overflow warning area, a stack overflow exception occurs.
 Your program can catch this exception and continue
 processing as long as the thread does not attempt to
 write in the guard area. When any thread attempts to
 access a memory location within the guard area, a memory
 addressing violation occurs without the possibility of
 recovery.
 ...."

Well, I'm surely missing something here... but without
C++-like EXCEPTION SPECIFICATIONS "fences" (especially
for NOTHROW calls -- throw(), I mean... and *including/
fencing the parms/args: foo( *...PARMS...* ) throw(),
I guess, BTW), "blind" unwinding on stack overflow fault
is just an invitation for even more troubles, I'm afraid.

Unless it is known for sure that a) stack overflow
exception could indeed be thrown from the point of fault
and b) it's really EXPECTED -- there is some matching
catch handler "waiting" for it... invoking C++ terminate()
handlers instead at "throw" point (for emergency inter-
process cleanup stuff) would seem MUCH more reasonable
to me...

Or am I wrong, folks?

[end quote]

regards,
alexander.

---
[ 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 <3CF4F979.4030101@tellabs.com>, Daniel Miller
> <daniel.miller@tellabs.com> writes
>
>>  I would hope that all members of LWG, WG21, and J16 have the goal of
>> doing the best job possible, which includes standardizing the best
>> libraries possible, regardless of who submitted them.  If an inferior
>> entrant from Boost were to be submitted for standardization
>> consideration and 1 or 2 or 3 superior libraries covering that same
>> topic are also submitted for consideration, I would hope that LWG or
>> WG21/J16 would perform some sort of bake-off allowing a fair & equal
>> direct apples-to-apples comparison between the various entrants,
>> measurement of simplicity/directness of expressing a concept in code,
>> assessment of reliability of behavior, measurement of various
>> efficiencies, and measurement of expressivity & extensibility as a
>> solution-space for all of the major problem-spaces.
>
>
> I think you misunderstand the process. WG21 & J16 LWG would use any
> valid starting point, but it is very unlikely that what went into the
> standard would be exactly what was originally submitted. OTOH it would
> be likely that (particularly in view of prior experience) that what went
> into the standard would be tested first and one of the obvious test
> sites is, IMO, Boost. Or are you saying that we must create some other
> forum in which LWG proposed libraries should be exposed for testing on a
> wide basis?


   I am saying what I said about fair & open competition without prejudice.


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

David Rasmussen wrote:
> I would very much like to see that. Where can I read about it?

I suppose it would look roughly looks like this -

template<typename T, T Low, T High>
struct Ranged
{
 struct out_of_range : out_of_range_base { }
 static T check(T v)
 {
  if (v < Low || v > High)
  {
   std::ostringstream o;
   o << typeid(Ranged).name() << '(' << v << ')';
   throw std::out_of_range(o.str());
  }
  return v;
 }
 Ranged(T v) : value(check(v)) { }
 operator T() { return value; }

private:
 T value;
};

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

Garry Lancaster:
> > As far as I know the same is true in Java and C#.
> > (Although I've heard it said that Java doesn't always
> > call finalizers which is worrying if true, but in my
> > experience fans of one language tend to overstate
> > the problems of other languages. When people say
> > Java leaks memory I confess that baffles me too.)

Alex Oren:
> A finalizer is invoked when an object is garbage collected but there is
> no guarantee it will ever be (e.g., when you have heaps of memory an a
> small number of objects).

Do you mean if an object is still uncollected at program
shutdown, the finalizer is not run before the memory
is returned to the system? If so, could you supply the
official Sun reference for that?

[snip]

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net



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

Garry Lancaster:
|>  People looking for a C++ GC system shouldn't overlook
|>  boost::shared_ptr. It can't easily cope with cyclic references
|>  (although at a pinch there are various ways to break the cycle)
|>  but if you can live with that limitation it may do everything you
|>  want.

James Kanze:
> Not really.  It doesn't work in quite a number of real programs.
> The problem is simple: in C++, you *have* raw pointers.
> You can't avoid it, because "this" is a raw pointer.  So you
> inevitably end up with some raw pointers that are involved
> in ownership.  With some counted pointers, you can convert
> these into a counted pointer without problems, but with the
> Boost shared_ptr, you must convert the raw pointer exactly
> once; converting it a second time will lead to prematurely
> freeing the memory.

I'm not sure what you're saying here. If you've found
a defect in shared_ptr I'd be quite surprised. If you
just mean there are some problems it isn't designed
to solve then I agree, but it's the same with everything.

|>  As for destructors != finalizers, I think the existance of
|>  increasingly GC-like smart pointers in C++ means the line is now
|>  very blurred. I'm not sure it is a useful distinction any more.

> The problem is perhaps one of vocabulary, but C++
> destructors are totally unrelated to Java finalizers.

An overstatement. They are different, but related.
They are both special member functions used to
clean up objects before their memory is reused.

Java isn't the only platform to have finalizers and C++
isn't the only language to have destructors. Most
interestingly, a C# destructor compiles into a .Net
finalizer. How's that for blurring the line?

> Even with garbage collection, C++ destructors must
> be run when local variables go out of scope, at the
> end of program on static variables,

Agreed. And there is no problem with this except
when people equate GC with GC-just-like-the-one-
in-Java. We can study the Java model, but we
shouldn't copy it.

> and when delete is explicitly invoked.

This may not be permitted. If I recall correctly neither
the Java or C# GC system permit it nor does
shared_ptr.

> It is less obvious what should happen when an
> object is collected; my personal feeling is that
> destructors should NOT be called in this case.

I say call them: keep the ability to clean-up other resources,
even including non-GC memory. What's the thinking
behind your position?

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net



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

Daniel Miller wrote:

 >   I and others in the realtime embedded software industry must ask
 > ourselves: Is Boost.org functioning as a community where the needs of
 > the realtime embedded software industry are well-respected & welcomed?
 > If Boost.org in the large (and Boost.threads in particular) does not
 > fully address the needs of the portion of the realtime embedded software
 > industry whose software is based on C++, then the realtime embedded
 > software industry must look elsewhere for a voice into the C++0x library
 > standardization effort.

Nobody prevents you or others in the realtime embedded software industry
to join boost and do something constructive.

Sincerely,

fres


---
[ 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 Wed, 29 May 2002 14:55:53 GMT, Francis Glassborow wrote in
<rxX7FNShKO98EwGL@robinton.demon.co.uk>:

> Why do you assume that those of us working on the evolution of C++ are
> going to ignore the desirability of making things simpler where that can
> be done without much cost. I think what you call strong enums are a bad
> example because whatever that may mean can be provided fairly simply
> within the current language, they are just not provided by the keyword
> enum.

OK, I'll bite.

How do you "fairly simply" implement strong enums that can be used in
if/switch/for/while statements but cannot be automatically converted to
integers?


Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

---
[ 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@alex.gabi-soft.de> writes:

> "Markus Mauhart" <markus.mauhart@chello.at> writes:
>
> |>  "James Kanze" <kanze@alex.gabi-soft.de> wrote ...
>
> |>  > "Markus Mauhart" <markus.mauhart@chello.at> writes:
>
> |>  > |>  "James Kanze" <kanze@alex.gabi-soft.de> wrote ...
>
> |>  > |>  > I've about had it with untried experiments.)
>
> |>  > |>  Btw, what about your efforts to understand/use/reimplement
> |>  > |>  streams, strings, and locales ?-)
>
> |>  > It's about so-so for the moment.  I'm still very much at the
> |>  > experimentation phase, which means that most of what I do, I end
> |>  > up redoing when I try to extend it, because I find that I've
> |>  > done it wrong.
>
> |>  So I'm looking foreward for your further contributions on this
> |>  issues, cause IMHO there is a need for hard earned expertise to
> |>  get improvements here.
>
> Thanks.
>
> There are in fact two problems.  The first is conceptually simple, but
> is costing a lot of programming time, and that is getting everything
> standards conform (when it isn't always very clear what the standard
> requires).  The second is more difficult: I have a number of cases
> where I represent sets of characters using a bit map.  It is obvious
> that a bit map is NOT an appropriate representation when the domain
> contains over a million elements -- each bit map would require more
> that 128 K bytes.  But what is the appropriate representation?  For
> the moment, I'm using a list of ranges.  But there are certain
> functions, e.g. in my regular expression handling, that have become
> inordinately slow.  I'm sure that they can be improved, doubtlessly by
> using some knowledge of the representation, but that will take some
> thinging to achieve.

[...]

> Anyhow, if anyone has any ideas about other representations, I'm all
> ears.  If anyone has any ideas about how to speed up the regular

What about doing a combination of both methods? That is, have ranges
with optional associated bitmaps. If the bitmap pointer is null, then
all characters in the range are considered to be part of the set,
otherwise only those where the corresponding bit is set.

This would probably be useful mostly if characters in the sets tend to
group (i.e. it's likely to have large regions where no character of
the set is found, and not too many regions where many characters are
found, ideally as sequence).

OTOH it will complicate the logic if you have to do set
operations. Especially there is the possibility that due to
manipulation a large set of zeros appears in the middle of a bit set,
so that breaking the corresponding range into two short ranges with a
gap in between may be an advantage. To detect or avoid this situation
might be complicated. Also, if there's a large range of 1s, it may be
better to split that range off, too, since an all-1 bitmap is
represented by a null pointer.

[...]

---
[ 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-J. Boehm wrote:
>
> It's also worth remembering that in pure garbage collected code
> destructors/finalizers tend to be very rare.  In my experience,
> perhaps 0.1% of objects need to be finalized.  Most resources managed
> by heap objects are really memory.

This certainly doesn't match my experience. I think your statistics are
biased by the fact that the code was written for GC systems, so of
course it doesn't rely on RAII and is forced to fall back on more
complicated and error-prone manual resource management. In the absence
of that artificial constraint, resource management in destructors is
very common.

--
Ross Smith ...................................... Auckland, New Zealand
r-smith@ihug.co.nz ....................................................
       "...and to destroy the earth, type 'make destroy_earth'"
                                            -- ClanLib makefile

---
[ 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 <rbcdfug6in0utggkc80pcpeul8s47unhji@4ax.com>, Alex Oren
<response@myrealbox.com> writes
>On Wed, 29 May 2002 14:55:53 GMT, Francis Glassborow wrote in
><rxX7FNShKO98EwGL@robinton.demon.co.uk>:
>
>> Why do you assume that those of us working on the evolution of C++ are
>> going to ignore the desirability of making things simpler where that can
>> be done without much cost. I think what you call strong enums are a bad
>> example because whatever that may mean can be provided fairly simply
>> within the current language, they are just not provided by the keyword
>> enum.
>
>OK, I'll bite.
>
>How do you "fairly simply" implement strong enums that can be used in
>if/switch/for/while statements but cannot be automatically converted to
>integers?

Sorry, I had lost track of this sub-thread (coupled with a substantial
discussion within the UK C++ Panel about strong typedefs and the
discussion here of providing a scope for an enum)

Nonetheless by encapsulating your enum in a class/struct you can provide
a conversion operator that throws when the value is out of range. Not
ideal, but workable. In fact you can apply strong constraints to your
enum as long as you have a class/struct scope within which to work.


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

"Ross Smith" <r-smith@ihug.co.nz> wrote in message
news:ada0rf$kkm$2@lust.ihug.co.nz...
> Hans-J. Boehm wrote:
> >
> > It's also worth remembering that in pure garbage collected code
> > destructors/finalizers tend to be very rare.  In my experience,
> > perhaps 0.1% of objects need to be finalized.  Most resources managed
> > by heap objects are really memory.
>
> This certainly doesn't match my experience. I think your statistics are
> biased by the fact that the code was written for GC systems, so of
> course it doesn't rely on RAII and is forced to fall back on more
> complicated and error-prone manual resource management. In the absence
> of that artificial constraint, resource management in destructors is
> very common.

Hans said "heap memory".  Agreed that RAII is very common with block-scoped
objects, but it's used much less frequently with dynamically allocated ones.

---
[ 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 Wed, 29 May 2002 20:21:48 GMT, Brad Settlemyer wrote in
<qraJ8.9873$ib4.447387@news1.east.cox.net>:

> Arrrggh!  Please not more undefined behaviour!  It seems possible to me to
> throw an exception if an object is available for GC (tho now I guess I have
> to go read all the Boehm stuff to find out).  Of course exceptions result
> in  undefined behavior about half the time they are used as well, so
> perhaps we could shore up some of those areas as well.  Please!  (I'm
> begging, exceptions are really a pandora's box type of thing, but hope is
> still in the box, and I'm still hoping that exceptions can be a little less
> undefined).

Going on a tangent, I would appreciate a change in the standard that
will require a mandatory diagnostic for every undefined or
implementation-defined behaviour.


Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

---
[ 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 <5ksmfu0352bnr7ots0j7hbb0tjvcb7eqtu@4ax.com>, Alex Oren
<response@myrealbox.com> writes
>Going on a tangent, I would appreciate a change in the standard that
>will require a mandatory diagnostic for every undefined or
>implementation-defined behaviour.

And the whole point of about 50% of undefined behaviour is that it
cannot be diagnosed (at least without quite heroic efforts which would
make a compiler unusable). yes I would like to see compilers do better
at producing diagnostics but there are things that we simply cannot
require even if we would like to encourage.
Let me give you a simple example:

void foo(int &a, int &b){
  a=b++;
}

has a potential for UB but only a full code analysis will detect if it
actually manifests.

In effect you have to abandon separate compilation if you want to
diagnose all UB.



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

Hans-J. Boehm wrote:

> Ross Smith <r-smith@ihug.co.nz> wrote in message
> news:<ad4ls5$3b3$1@lust.ihug.co.nz>...
>
>> So why bother with GC, when we have all that already? Nobody sane
>> ever writes an explicit call to delete any more, except on the very
>> rare occasions when they're actually implementing a smart pointer
>> (and the addition of a good smart pointer library to the standard
>> will do away with most of those occasions too). GC adds nothing
>> except gratuitous compiler complexity.
>>
> So would you care to propose a smart pointer scheme that
>
> a) Doesn't complicate the user's job, e.g. by requiring that I have
> enough global understanding of the whole program to avoid pointer
> cycles,

The presence of ownership cycles (_not_ pointer cycles; conflating those
two very different concepts is one of the standard pro-GC propaganda
tricks) is always trivially obvious from the nature of the problem.

> or requiring me to understand lots of extra usage rules that
> don't apply to regular pointers.

No idea what you're talking about here.

> b) Is performance competitive with either a good conservative GC, or a
> good Java GC, particularly for multithreaded code?

Irrelevant. No amount of performance makes up for lack of correctness
(failing to execute destructors at the right moment). I could get a
performance improvement by replacing all my floating point variables
with integers, too, but I don't think that would justify it.

> c) Allows me to acquire locks in destructors without spurious
> deadlocks.  (See my previous message.)

No idea what you're talking about here either. (Are you under the
impression every news server delivers messages in the same order?)

--
Ross Smith ...................................... Auckland, New Zealand
r-smith@ihug.co.nz ....................................................
       "...and to destroy the earth, type 'make destroy_earth'"
                                            -- ClanLib makefile

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

"Alexander Terekhov" <terekhov@web.de> wrote in message
news:3CF773E9.9B556272@web.de...
>
> David Abrahams wrote:
> [...]
> > You must have a very odd definition of "safe" if you think that's so.
What
> > do you think is unsafe about throwing in a destructor when the
destructor
> > contains a catch(...) clause?
>
> See below/please answer the question that Mr. Sutter chose to
> ignore (thus far/yet).

<snip>

>From investing a few seconds reading your post I can't see what question it
is that you want answered, sorry.

-Dave




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

> Nonetheless by encapsulating your enum in a class/struct you can provide
> a conversion operator that throws when the value is out of range. Not
> ideal, but workable. In fact you can apply strong constraints to your
> enum as long as you have a class/struct scope within which to work.

Couldn't you also provide an implicit operator which would convert the
struct
to an enum? That would allow you to use this "strong" enum as a normal enum,
but since only one implicit conversion is done, there would be no conversion
to
int...


---
[ 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 Wed, 29 May 2002 22:22:38 GMT, David Abrahams wrote in
<ad3jsc$le2$1@bob.news.rcn.net>:

> "Brad Settlemyer" <bws_news@deepcopy_remove_.org> wrote in message
> news:2_bJ8.11514$ib4.487622@news1.east.cox.net...
>
> > , but I can definitely think of behavior that leads to bugs.
>
> Programming leads to bugs.

Truer (and funnier) words of wisdom are rarely spoken!

> > Exceptions Specifications
> > and templates is even more troublesome, but as they are so rare, and don't
> > have a viable recovery mechanism (that I am aware of), I don't use them at
> > all, so they result in no problems.
>
> I have no defense for the design of exception specifications; they're not
> terribly useful anyway so it's just as well that you don't feel compelled to
> use them. However, there are no opportunities for undefined behavior with
> exception-specifications AFAIK.

What exactly are the reasons that the new version of the standard cannot
include compile time checking of exception specifications (a-la Java)?

If the reason is "backward compatibility", it is possible to use a
different syntax (yet another overload of the "static" keyword?)

> It can launch a missile legally. I'm suggesting that there may well be room
> for legitimate complaint about undefined behaviors in the standard, but if
> so you're looking in the wrong place for them. The exception-handling
> support is actually very tightly specified.

I already mentioned it in another post but why cannot the standard
require that the compiler issue a diagnostic when it encounters
undefined (or implementation-defined) behaviour?


Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

---
[ 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, 30 May 2002 20:42:53 CST, Paul Mensonides wrote in
<BZzJ8.70647$352.4099@sccrnsc02>:

> "Alex Oren" <response@myrealbox.com> wrote in message
> news:vqt9fusge9rari6lph2ffq1hja3thhpkim@4ax.com...
>
> > Sometimes (e.g., Win32 API) one needs to cast between pointers to data
> > and pointers to functions.  I find the following too unwieldy:
> >
> >     pFunc = reinterpret_cast<PFUNC>(reinterpret_cast<int>(pData));

[...]

> template<class R, class T>
> inline R function_cast(T* p) {
>     static_assert<is_ptr<R>::value>("error: non-pointer type");
>     return *reinterpret_cast<R*>(&p);
> }
>
> pFunc = function_cast<PFUNC>(pData);

In other words, you're saying that one can substitute (using C
terminology):

 *(T*)(&p)

for:

 (T)p

It does look like it will work (except for string literals but then I
can imagine no reason to convert them to function pointers).

Or are there other caveats that I missed?



Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

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

"Daniel Miller" <daniel.miller@tellabs.com> wrote in message
news:3CF7FF8D.6090905@tellabs.com...
> Hans-J. Boehm wrote:
> > It's also worth remembering that in pure garbage collected code
> > destructors/finalizers tend to be very rare.  In my experience,
> > perhaps 0.1% of objects need to be finalized.  Most resources managed
> > by heap objects are really memory.
>
>   Experience in other languages/cultures/axiom-systems might not apply to
C++ broadly or might not apply >to certain C++ schools-of-thought.  This is
due to the 100%-of-resource-allocation-in-ctor and
100%-of->resource-deallocation-in-dtor rules which are preferred in the C++
community.  These rules form the basis >of being able to use C++ as a form
of transaction-programming system, where try is begin-transaction and >throw
(with its stack unwinding) is the abort-transaction mechanism.  The set of
objects on which garbage->collection would be performed would not only be
releasing memory, but also directly or indirectly/ultimately >incrementing
semaphores, closing files, releasing mutexes, closing connection-oriented
networking >connections, and so forth, especially in large (multithreaded,
multiprocessor) realtime embedded systems >which are focused on interacting
with the outside world which is full of resources (or software-model
>representations of resources).  Any garbage collection system which does
not call dtors in certain cases >during "normal operations" erodes the
integrity of C++'s XP capabilities to the point that such GC would >need to
be strictly prohibited from realtime embedded systems, so that
resource-releasing (i.e., the 100%->of-resources-released-in-dtor rule) is
not undermined or compromised during transaction-abortion in XP.

[snip]

>    The "garbage collection" techniques which rely on a programmer's
> elective use of one or more smart pointers does in fact mesh well with
> POP, OOP, GP, and XAOP.

We don't need smart pointers to retain XAOP capabilities in a GCed C++.  We
only need two categories of object:  "unmanaged" or "uncollectable" objects
which must be manually destroyed and can be auto variables or allocated on
free store (i.e. what we have today in C++) and "managed" or "collectable"
objects which will be collected by the GC system.  Using a smart pointer is
one way in which you can seperate these two categories.  Boost has had
several such proposals, such as the cyclic_ptr I think is still in the file
archives.  But this isn't the only way to seperate these two categories.
The Boehm GC system allows you to seperate "collectable" objects by either
deriving from class gc or by using an overloaded placement new passing GC or
UseGC (example: new (GC) int;).  The C++ binding for .NET does the same
thing, though "managed" and "unmanaged" means more then just whether or not
the object is collectable.

I don't believe anyone is suggesting that C++ should be a fully GCed
language (I hope not).  I also think that Mr. Boehm's statement above is
still valid.  Most objects that are meant to be GCed in a system that allows
both managed and unmanaged objects will likely not have a
destructor/finalizer.  After all, such objects are obviously not intended
for use in an XAOP manner.  Granted the figure of 0.1% will likely be off by
a lot in C++ usage, where the majority of existing classes are designed for
XAOP usage and those objects will be used in GCed objects, if not allocated
for GC usage directly.  But I think the point is still valid and worth
paying attention to while discussing GC for C++.

Bill Kempf


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

Mike Schilling wrote:

> "Ross Smith" <r-smith@ihug.co.nz> wrote in message
> news:ada0rf$kkm$2@lust.ihug.co.nz...
>
>>Hans-J. Boehm wrote:
>>
>>>It's also worth remembering that in pure garbage collected code
>>>destructors/finalizers tend to be very rare.  In my experience,
>>>perhaps 0.1% of objects need to be finalized.  Most resources managed
>>>by heap objects are really memory.
>>>
>>This certainly doesn't match my experience. I think your statistics are
>>biased by the fact that the code was written for GC systems, so of
>>course it doesn't rely on RAII and is forced to fall back on more
>>complicated and error-prone manual resource management. In the absence
>>of that artificial constraint, resource management in destructors is
>>very common.
>>
>
> Hans said "heap memory".  Agreed that RAII is very common with block-scoped
> objects, but it's used much less frequently with dynamically allocated ones.


   I strongly disagree.  The lifetime of an object has nothing special
to do with what is excepted at birth and (more importantly) at death.  A
class whose objects typically have a short lifetime of one block-scope
does not imply an automatic destruction at time-of-death which is more
complex than a class whose objects typically have a longer lifetime on
the heap.

   Scoping in the language is completely independent of & orthogonal to
the expectations of what automatic destruction at time-of-death is to occur.

---
[ 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 <adfdp9$kje$1@pegasus.csx.cam.ac.uk>, Tom Puverle
<tp225@cam.ac.uk> writes
>> Nonetheless by encapsulating your enum in a class/struct you can provide
>> a conversion operator that throws when the value is out of range. Not
>> ideal, but workable. In fact you can apply strong constraints to your
>> enum as long as you have a class/struct scope within which to work.
>
>Couldn't you also provide an implicit operator which would convert the
>struct
>to an enum? That would allow you to use this "strong" enum as a normal enum,
>but since only one implicit conversion is done, there would be no conversion
>to
>int...

One or other of us misunderstands the rule. There is no prohibition on
multiple implicit conversions, the prohibition is on more than one user
defined conversion.

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

On Sat,  1 Jun 2002 00:00:44 GMT, Garry Lancaster wrote in
<tLPJ8.14722$g63.2648574@news11-gui.server.ntli.net>:

> Garry Lancaster:
> > > As far as I know the same is true in Java and C#.
> > > (Although I've heard it said that Java doesn't always
> > > call finalizers which is worrying if true, but in my
> > > experience fans of one language tend to overstate
> > > the problems of other languages. When people say
> > > Java leaks memory I confess that baffles me too.)
>
> Alex Oren:
> > A finalizer is invoked when an object is garbage collected but there is
> > no guarantee it will ever be (e.g., when you have heaps of memory and a
> > small number of objects).
>
> Do you mean if an object is still uncollected at program
> shutdown, the finalizer is not run before the memory
> is returned to the system?  If so, could you supply the
> official Sun reference for that?

Here is what Sun says about finalization (heavily snipped):

| The Java programming language does not specify how soon a finalizer will
| be invoked, except to say that it will happen before the storage for the
| object is reused. Also, the language does not specify which thread will
| invoke the finalizer for any given object. It is guaranteed, however,
| that the thread that invokes the finalizer will not be holding any
| user-visible synchronization locks when the finalizer is invoked. If an
| uncaught exception is thrown during the finalization, the exception is
| ignored and finalization of that object terminates.

My comments:
* When a program is "shutdown", is its storage "reused"?
* A program is not required to "shutdown".  It may continue running
  for eternity.

Some more:

| If the Java virtual machine detects that an unfinalized object has
| become finalizer-reachable or unreachable, it may label the object
| finalizable [...].
|
| If the Java virtual machine detects that a finalized object has become
| unreachable, it may reclaim the storage occupied by the object because
| the object will never again become reachable [...]
|
| At any time, a Java virtual machine may take any finalizable object,
| label it finalized, and then invoke its finalize method in some thread.
| [...]

Notice the heavy usage of the word "may"?

Some more:

| The Java programming language imposes no ordering on finalize method
| calls. Finalizers may be called in any order, or even concurrently.
|
| As an example, if a circularly linked group of unfinalized objects
| becomes unreachable (or finalizer-reachable), then all the objects may
| become finalizable together. Eventually, the finalizers for these
| objects may be invoked, in any order, or even concurrently using
| multiple threads. If the automatic storage manager later finds that the
| objects are unreachable, then their storage can be reclaimed.

Bottom line: finalizers are not deterministic.


Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

---
[ 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 Fri, 31 May 2002 13:36:17 CST, William E. Kempf wrote in
<newscache$yckzwg$r8j$1@frodo.bagend.com>:

> I've got a very focused plan for Boost.Threads, which I have
> to have to get the library into a form that's usable and a good basis.
> There's some things that are missing for RTOSes that I'm aware of, and those
> *ARE* planned today.  Of course this may not be obvious since they mostly
> fall under the category I've labeled as "thread parameters" when I've talked
> about this on public lists.  Beyond this there are only two other things
> brought to my attention that is need by RTOSes, and they are at least
> somewhat debatable:
>
> * Semaphores.  As I've said publicly, I've not counted semaphores out
> entirely.  So this criticism, though possibly valid, is not evidence that
> Boost.Threads will (or has) made the wrong decision in this regard,
> RTOS/embedded systems or no.
>
> * Event queues.  I believe this concept to be higher level then the scope of
> Boost.Threads.  I also believe it to not be a thread specific concept (I
> know others disagree about this, so there may well be something I'm not
> understanding here).  Despite this I think it an important concept, and one
> that probably should be standardized.  So I don't think it's exclusion
> should rule out Boost.Threads, RTOS/embedded systems or no.

I'm not very familiar with RTOSes but here's my point of view with
regard to the Win32 environments.

In Win32, threads work together with Synchronization Objects.  A thread
can wait on Events, Mutexes, Semaphores and Waitable Timers (as well as
on other objects that are used mainly for other purposes.

There are also Critical Sections (which are lightweight, do not work
across processes and have a different "interface) and Interlocked...()
functions that allow atomic operations on shared variables.

A standard C++ thread/synchronization library should be able to express
all these paradigms in the most efficient way.  Otherwise, I will just
use (or encapsulate) the OS APIs instead.


Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

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

> One or other of us misunderstands the rule. There is no prohibition on
> multiple implicit conversions, the prohibition is on more than one user
> defined conversion.

And what's the chance it's you? :)
I am mistaken, the standard says:
"For userdefined
types, userdefined
conversions are considered as well; see 12.3. In general, an
implicit conversion sequence (13.3.3.1) consists of a standard
conversion sequence followed by a userdefined
conversion followed by another standard conversion sequence."


---
[ 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, 3 Jun 2002, Francis Glassborow wrote:

>
> In article <5ksmfu0352bnr7ots0j7hbb0tjvcb7eqtu@4ax.com>, Alex Oren
> <response@myrealbox.com> writes
> >Going on a tangent, I would appreciate a change in the standard that
> >will require a mandatory diagnostic for every undefined or
> >implementation-defined behaviour.
>
> And the whole point of about 50% of undefined behaviour is that it
> cannot be diagnosed (at least without quite heroic efforts which would
> make a compiler unusable).
>
> Let me give you a simple example:
>
> void foo(int &a, int &b){
>   a=b++;
> }
>
> has a potential for UB but only a full code analysis will detect if it
> actually manifests.

It's worse than that. It is impossible (isomorphic to the Halting
Problem) to determine whether some UB conditions occur in a program.

For your function foo example, consider this trivial example:

extern int a, b;
int main()
{
    int ar = rand()%2 ? a : b;
    foo(ar, b);
    // ... defined or undefined behavior?
}

If you revise the requirement to diagnose only the cases that can
be determined, you somehow must specify how clever the compiler
must be, or what heroic measures must be employed.

BigNum N = ...;    // hundred-digit number
bool fact(BigNum); // number has exactly 2 prime factors
extern int a, b;
int main()
{
    int ar = fact(N) ? a : b;
    foo(ar, b);
    // ... defined or undefined behavior?
}

--
Steve Clamage, stephen.clamage@sun.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                       ]

"Alex Oren" <response@myrealbox.com> wrote in message
news:6k1nfuk6k4e9tqiggn12i23k9nibahs039@4ax.com...
> > > Sometimes (e.g., Win32 API) one needs to cast between pointers to data
> > > and pointers to functions.  I find the following too unwieldy:
> > >
> > >     pFunc = reinterpret_cast<PFUNC>(reinterpret_cast<int>(pData));
>
> [...]
>
> > template<class R, class T>
> > inline R function_cast(T* p) {
> >     static_assert<is_ptr<R>::value>("error: non-pointer type");
> >     return *reinterpret_cast<R*>(&p);
> > }
> >
> > pFunc = function_cast<PFUNC>(pData);
>
> In other words, you're saying that one can substitute (using C
> terminology):
>
> *(T*)(&p)
>
> for:
>
> (T)p
>
> It does look like it will work (except for string literals but then I
> can imagine no reason to convert them to function pointers).
>
> Or are there other caveats that I missed?

I'm simply saying that you can encapsulate the 'unwieldy' syntax of a double
reinterpret_cast with an inline function template.  As far as using 'int' is
concerned, I just dislike it.  In any case, the pointer to a pointer-to-function
is just a normal function and can be reinterpreted directly into a pointer to
pointer to object.  Dereferencing that pointer will yield a pointer to an
object--whether that is safe or not depends on the situation.  The Win32 API,
passes function-pointers around all the time as void*, which, in Standard C++,
requires an indirect cast of some type--so I made my own.

By the way, you can't take the address of any literal, but the 'function_cast'
above will still work because it is taking the address of a formal parameter not
a literal.

Paul Mensonides

---
[ 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 <86hekqt1kf.fsf@alex.gabi-soft.de>, James Kanze
<kanze@alex.gabi-soft.de> writes
>|>  More precisely, providing an optional mechanism that will allow
>|>  compilers to reject code that is unsave in a GC environment. For
>|>  example, converting integer types to pointers (because that allows
>|>  programmers to use idioms that hide pointers)
>
>Is that just on a wish list, or was that a concrete proposal.
>
>(And BTW: for various reasons, C++ must continue to support the
>conversion of integers to pointers.  You might be able to ban the
>reverse, but I think that the only real requirements are statements
>with regards to what you can do with those int's, or maybe the
>requirement that at least one actual pointer remain in scope.)

As I recall, the idea was that there should be a standard way that a
programmer could inform the compiler of his intent to use GC so that the
compiler could then issue diagnostics for dangerous code.

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

Sungbom Kim <musiphil@bawi.org> writes:

> Christopher Eltschka wrote:
> >
> > I'd like to be able to avoid certain operators. For example, I'd like
> > to be able to do
> >
> >   typedef new double Temperature;
> >
> > and disallow multiplication of two temperatures (whatever that product
> > may be, it's for sure not a temperature).
> >
> > Maybe one can define groups of operators, such as logical, additive,
> > multiplicative, etc., and on definition of the new type tell which
> > group should be inherited by the new type.
> >
> > For example, the variable Temperature could be declared as
> >
> >   typedef new[std::additive] double Temperature;
> >
> > where std::additive is an operator group containing operator+ and
> > operator- (both unary and binary) for the new type (and maybe
> > multiplication with the old type, in this example double). Ideally,
> > one could define such operator groups oneself (with the most often
> > used predefined in std).
>
> If you're thinking of going that far, why don't you just make
> Temperature a class? You already have enough to do it.

Well, it's a lot of boiler-plate code to do this: you'd not only have
to declare they are to be used, you have to define them, that is, you
end up with lots of trivial code where operators on the type are
implemented as corresponding operators on the sole element.

However, thinking about it, one might use the Curiously Recurring
Template pattern for defining those groups once, and then forget about
the boilerplating; one could even embed the value in the base class:

template<class Derived, class BaseType> class additive
{
  friend Derived operator+(Derived const& x) { return x; }
  friend Derived operator+(Derived const& x, Derived const& y)
  {
    return Derived(x.value+y.value);
  }
  // ...
protected:
  additive() {}
  explicit additive(BaseType x): value(x) {}
  ~additive() {} // prevent delete through base class
  double get() { return value; }
  BaseType value;
};

struct Temperature: additive<Temperature, double>
{
  Temperature() {}
  explicit Temperature(double T): additive<Temperature, double>(T) {}
  using additive<Temperature, double>::get();
};

struct Length: additive<Length, double>
{
  Length() {}
  explicit Length(double l): additive<Temperature, double>(l) {}
  using additive<Temperature, double>::get();
};

Still a lot to write per new type, but at least considerably less.

One could further reduce this using the preprocessor:

#define MAKETYPE(oldtype, operations, newtype) \
  struct newtype: operations<newtype, oldtype> \
  {                                            \
    newtype() {}                               \
    explicit newtype(oldtype x):               \
      operations<newtype, oldtype>(x) {}       \
    using operations<newtype, oldtype>::get(); \
  }

Now one could write

MAKETYPE(double, additive, Temperature);
MAKETYPE(double, additive, Length);

However, wasn't one goal of C++ to make the preprocessor to be used as
little as possible by providing appropriate language constructs?

BTW, native "typedef new" would have another advantage: You would
still get PODs derived from PODs (not possible in this case, since you
need the constructor to enable constructing with natural syntax).

---
[ 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 <F%YI8.4463$ib4.227505@news1.east.cox.net>, Brad Settlemyer
> <bws_news@deepcopy_remove_.org> writes
>>Francis Glassborow wrote:
>>
>>>
>>> More precisely, providing an optional mechanism that will allow
>>> compilers to reject code that is unsave in a GC environment. For
>>> example, converting integer types to pointers (because that allows
>>> programmers to use idioms that hide pointers)
>>>
>>
>>Does use of a union eliminate the need for this conversion, or is there a
>>case unions cannot handle (I don't ever do this kind of stuff, so I have
>>no idea what programmers who do it need)?
>
> How will that cure the problem? I store a pointer in a union, extract it
> as an array of unsigned char and once again GC has potential problems.
> For GC to efficiently work you must not hide pointers. This is so easy
> to do that some language support is probably desirable.
>

My thought was, if the conversion is done as part of the union, it should
still be able to be garbage collected when no one is referring to a value
in the union (it would require some (hopefully) transparent changes to
union, and there are a few difficulties with how it would work, but I
imagine that is always the case with gc).  Conversion operators seem more
problematic, tho perhaps they are 2 sides of the same coin.
--
Brad Settlemyer
http://deepcopy.org/
Progamming in the trenches

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

"Edward Diener" <eldiener@earthlink.net> writes:

> "Eric Niebler" <ericne@microsoft.com> wrote in message
> news:3cdb0a06$1@news.microsoft.com...
> >
> > "Pete Becker" <petebecker@acm.org> wrote in message
> > news:3CDA7DBA.8343B482@acm.org...
> > > Instead of asking about language
> > > features, put together a list of problems that aren't easily solved in
> > > the language as it exists today.
> >
> > Good suggestion.
> >
> > Not too long ago, this code appeared in a column by a well-respected C++
> > guru.
> >
> >      template<class CharT, class Traits>
> >      basic_ostream<CharT, Traits>& operator<<
> >        ( basic_ostream<CharT, Traits>& o, const Num& n )
> >      {
> >        long value = n.Value();
> >        basic_string<CharT, Traits> s;
> >
> >        CharT digits []
> >          = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
> >
> > <snip>
> >
> > The code compiles fine when CharT==char, but if it is anything else the
> > compile breaks on the declaration of the digits array.  Basically, string
> > literals and template code don't mix.  The fact that this error slips into
> > the code of even the most seasoned experts demonstrated that it's a real
> > problem.
> >
> > In the past, I have hacked around the problem like this:
> >
> >     CharT digits [] = { '0', '1', '2', ... };
> >
> > but this is (a) tedius, (b) verbose, and (c) wrong.  It's wrong becuase if
> > CharT==wchar_t, then there is no guarantee that assigning a char to a
> > wchar_t yields anything meaningful.
> >
> > Of course, I could defer the string conversion to run-time and use a
> locale,
> > but that's not guaranteed to yield the same results as if the compiler did
> > the conversion, as it would have to for L"..." wide string literals.
> >
> > Does anybody have a solution for this?
>
> Since I have run into situations which are the same as yours, I don't have a
> solution but I have a proposal which will allow the use of string literals
> in template classes. Instead of L"literal string" to signify wide character
> literals and L'literal character' to signify a wide character literal, we
> should add the notation:
>
> <character-type>"literal string" and
> <character-type>'literal character'
>
> where character type will be any built-in language character type, of which
> we currently have two, "char" and "wchar_t", but of which C++ may add more
> in the future. Thus the notation can expand in the future to include other
> character types in our string literals. This would solve your problem above
> by allowing you to specify,
>
> CharT digits [] = <CharT>"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
>
> and you would have the correct type of string literal.

Now, it would be even nicer if you'd be able to define your own
encoding and create literals in that encoding. Say

encoding mychar       // I'm lazy, so I don'u use a real one ;-)
: int                 // this is the type to store the characters in
{
   0 "\0",            // code point 0 represents '\0' character
   1 "\r",            // code point 1 is carriage return
   2 "\n",            // code point 2 is newline
   16 "0123456789",   // code points 16 to 25 represent digits
   26 "ABCDEFGHIJKLMNOPQRSTUVWXYZ",
   52 "abcdefghijklmnopqrstuvwxyz",
 1024 "\u0950"        // it's an esoteric character set ;-)
}

Note that the "string literals" here are not really string literals
(with type char), but can contain any character (as demonstrated with
\u0950, which probably on no system is in the char-range), even those
which are neither allowed in normal nor in wide string literals.
Probably one should also provide some syntax for unicode ranges, so
f.ex. latin1 could be encoded simply as

encoding latin1: unsigned char
{
  0 "\0" ... "\u00ff"
    // the first 256 Unicode letters match the latin1 ones
}

and the alphabetic ranges could be specified by "A"..."Z" and
"a"..."z" (interpreted as ranges in Unicode encoding, therefore
working even on EBCDIC systems).

Code points not assigned as above would be undefined, and characters
not included would be disallowed (my limited character set above would
therefore only allow sequences of letters, digits, \r, \n, \u0950 and
the \0 character - the latter would be required for any encoding,
since it's automatically appended for string literals).

The definition above would now do three things:

1. Define a new character type named mychar, with int as underlying
   type (i.e. mychar variables have the same representation as int;
   the underlying type would probably be required to be an integral
   type).

2. Associate the character encoding denoted below to it. That is,
   using the proposed string literal extension above, the literal
   <mychar>"ABCD1234" would result in a literal of type mychar[9]
   containing the numbers 26, 27, 28, 29, 17, 18, 19, 20, 0.

3. Define conversions (either implicit or explicit, I'm not sure
   which would be better) which are character-preserving (instead of
   numerical value preserving) between those user-defined types as
   well as between user-defined types and char/wchar_t. If the source
   string contains characters which are not in the destination
   character set, the behaviour could simply be undefined (but there
   should be a way to determine if a character could be converted),
   or maybe each encoding in addition specifies a default character
   (which may, but need not, lie in the range of the assigned
   character code points) which is then the result of the conversion.
   That is, "char s = <mychar>'a';" would result in s being 'a'. To
   get the code point (52), one would use (int)<mychar>'a'.

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

William E. Kempf wrote:

> "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
> news:Zx73FmBRCK98EwB0@robinton.demon.co.uk...
>> In article <F%YI8.4463$ib4.227505@news1.east.cox.net>, Brad Settlemyer
>> <bws_news@deepcopy_remove_.org> writes
>> >Francis Glassborow wrote:
>> >
>> >>
>> >> More precisely, providing an optional mechanism that will allow
>> >> compilers to reject code that is unsave in a GC environment. For
>> >> example, converting integer types to pointers (because that allows
>> >> programmers to use idioms that hide pointers)
>> >>
>> >
>> >Does use of a union eliminate the need for this conversion, or is there
>> >a case unions cannot handle (I don't ever do this kind of stuff, so I
>> >have
> no
>> >idea what programmers who do it need)?
>>
>> How will that cure the problem? I store a pointer in a union, extract it
>> as an array of unsigned char and once again GC has potential problems.
>> For GC to efficiently work you must not hide pointers. This is so easy
>> to do that some language support is probably desirable.
>
> I'm not sure this is a problem.  Hiding the pointer behind an int can be
> viewed as simply a less safe "weak pointer" (less safe because there's no
> convenient way to throw an exception when you try and convert it back to a
> "strong pointer"), and we all know that "weak pointers" in GC systems are
> useful.  Yes, it does leave room for abuse of the system, but I think many
> of us could live with this simply resulting in undefined behavior if there
> are no "strong pointers" left pointing to the allocated memory.
>

Arrrggh!  Please not more undefined behaviour!  It seems possible to me to
throw an exception if an object is available for GC (tho now I guess I have
to go read all the Boehm stuff to find out).  Of course exceptions result
in  undefined behavior about half the time they are used as well, so
perhaps we could shore up some of those areas as well.  Please!  (I'm
begging, exceptions are really a pandora's box type of thing, but hope is
still in the box, and I'm still hoping that exceptions can be a little less
undefined).
--
Brad Settlemyer
http://deepcopy.org/
Progamming in the trenches

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

Garry Lancaster wrote:

> John Nagle:
>
>>    Some assistance on the storage management front is useful,
>>but garbage collection and destructors don't play well together.
>>The semantics get wierd.  Look at Microsoft's "managed storage"
>>system for C++.  Painful.
>>
>>A destructor is not a finalizer, and vice
>>versa.
>>
>>    GC works better with Java semantics.
>>
>
> What's the problem? As far as I understand it the
> golden rule is not to touch any GC pointers in a
> destructor. If you follow that simple rule, there is
> no problem.


     You don't know when the destructor will be called, if ever.
So file closing, window closing, socket closing, database
closing, and related operations may not happen when wanted.

     There's also the fact that calling destructors from GC
introduces a form of concurrency.  What if a destructor
does something that blocks?

    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                       ]

"Brad Settlemyer" <bws_news@deepcopy_remove_.org> wrote in message
news:qraJ8.9873$ib4.447387@news1.east.cox.net...

> Of course exceptions result
> in  undefined behavior about half the time they are used as well, so
> perhaps we could shore up some of those areas as well.  Please!  (I'm
> begging, exceptions are really a pandora's box type of thing, but hope is
> still in the box, and I'm still hoping that exceptions can be a little
less
> undefined).

Care to justify these remarks? There's very little room in the standard for
undefined behavior where exceptions are concerned, AFAICT. If you want to
attack something, why not go after the really insidious stuff like the
copying of an uninitialized int?

-Dave



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

Brad Settlemyer wrote:

>> I'm not sure this is a problem.  Hiding the pointer behind an int can be
>> viewed as simply a less safe "weak pointer" (less safe because there's no
>> convenient way to throw an exception when you try and convert it back to
>> a "strong pointer"), and we all know that "weak pointers" in GC systems
>> are
>> useful.  Yes, it does leave room for abuse of the system, but I think
>> many of us could live with this simply resulting in undefined behavior if
>> there are no "strong pointers" left pointing to the allocated memory.
>>
>
> Arrrggh!  Please not more undefined behaviour!  It seems possible to me to
> throw an exception if an object is available for GC (tho now I guess I
> have to go read all the Boehm stuff to find out).

After a bit more thought, this is the same old undefined behavior that
already exists -- so it can't really be fixed.  But still, I assume that
GC'ed objects will live on a different part of the heap, it would be nice
if the safer nature of that heap would allow for safer pointer semantics,
but I've got to read the GC stuff before I can be certain what extra safety
could be provided (which is unfortunate because I'll have to interrupt
reading A Timeless Way of Building, and that's really much more fun I
suspect :( ).
--
Brad Settlemyer
http://deepcopy.org/
Progamming in the trenches

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

"John Nagle" <nagle@animats.com> wrote in message
news:3CF53B88.2040804@animats.com...
>
>      You don't know when the destructor will be called, if ever.
> So file closing, window closing, socket closing, database
> closing, and related operations may not happen when wanted.

That's a little strong...While such things won't happen when the object goes
out of scope, there's nothing to say these things can't be executed
manually, like they were before destructors.

You're not losing the ability to do these things, you're losing the
*automatic* execution of that cleanup code.  It's not much unlike forgetting
to delete a pointer to a class, except in that case the destructor is
*never* called, whereas a finalizer may not be called immediately, but it
will (ignoring certain exceptions) be called eventually.

C# mitigates this by introducing a construct for scoping objects that need
to be cleaned up.  An example would be:

using (FileStream f = new FileStream("...")) {
  // use f
} // f.Dispose() gets called here, even if an exception is thrown

which is basically just shorthand for

FileStream f = null;
try {
  f = new FileStream("...");
  // use f
} finally {
  if (f != null) f.Dispose();
}

Don't get me wrong, I like destructors better than finalizers/dispose
idioms; destructors are more concise and less error prone than the
alternatives.  But you make it sound like garbage collection throws all
determinism out the window, which isn't true.

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                       ]

David Abrahams wrote:

>
> "Brad Settlemyer" <bws_news@deepcopy_remove_.org> wrote in message
> news:qraJ8.9873$ib4.447387@news1.east.cox.net...
>
>> Of course exceptions result
>> in  undefined behavior about half the time they are used as well, so
>> perhaps we could shore up some of those areas as well.  Please!  (I'm
>> begging, exceptions are really a pandora's box type of thing, but hope is
>> still in the box, and I'm still hoping that exceptions can be a little
> less
>> undefined).
>
> Care to justify these remarks? There's very little room in the standard
> for undefined behavior where exceptions are concerned, AFAICT. If you want
> to attack something, why not go after the really insidious stuff like the
> copying of an uninitialized int?
>
> -Dave
>
I don't want to attack anything, I want to stop having to spend money on
books that explain the caveats of C++ (they are really quite expensive).

What do I do if an exceptional condition occurs while I am destroying an
object?  Why is it never safe to ever call a function that may throw an
exception in a destructor (even if I'm willing to catch it and clean up
myself)?  These are a very small part of the standard I am certain, but
unfortunately these are exactly the kind of nasty things that happen when I
use libraries that use exceptions (the Xerces SAX2 XML parser being a quick
example, the standard library would be another example, but all the
operating systems I use play nice, so fstreams have never been a problem,
they illustrate the buggy behavior, rather than the undefined kind of
course).  Additionally, exceptions and templates don't play nice, tho I
can't think of any undefined behavior off the top of my head, but I can
definitely think of behavior that leads to bugs.  Exceptions Specifications
and templates is even more troublesome, but as they are so rare, and don't
have a viable recovery mechanism (that I am aware of), I don't use them at
all, so they result in no problems.

I've never tried to copy an uninitialized int, so I'm not familiar with the
behavior, but if that can result in a core dump legally, that's
disappointing.

--
Brad Settlemyer
http://deepcopy.org/
Progamming in the trenches

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

"Brad Settlemyer" <bws_news@deepcopy_remove_.org> wrote in message
news:2_bJ8.11514$ib4.487622@news1.east.cox.net...
> David Abrahams wrote:
>
> >
> > "Brad Settlemyer" <bws_news@deepcopy_remove_.org> wrote in message
> > news:qraJ8.9873$ib4.447387@news1.east.cox.net...
> >
> >> Of course exceptions result
> >> in  undefined behavior about half the time they are used as well, so
> >> perhaps we could shore up some of those areas as well.  Please!  (I'm
> >> begging, exceptions are really a pandora's box type of thing, but hope
is
> >> still in the box, and I'm still hoping that exceptions can be a little
> > less
> >> undefined).
> >
> > Care to justify these remarks? There's very little room in the standard
> > for undefined behavior where exceptions are concerned, AFAICT. If you
want
> > to attack something, why not go after the really insidious stuff like
the
> > copying of an uninitialized int?
> >
> > -Dave
> >
> I don't want to attack anything, I want to stop having to spend money on
> books that explain the caveats of C++ (they are really quite expensive).

Maybe you should just familiarize yourself with what the language standard
actually says about those features...

> What do I do if an exceptional condition occurs while I am destroying an
> object?

It's up to you, but if you throw the results are well-defined.

> Why is it never safe to ever call a function that may throw an
> exception in a destructor (even if I'm willing to catch it and clean up
> myself)?

You must have a very odd definition of "safe" if you think that's so. What
do you think is unsafe about throwing in a destructor when the destructor
contains a catch(...) clause?

> These are a very small part of the standard I am certain, but
> unfortunately these are exactly the kind of nasty things that happen when
I
> use libraries that use exceptions (the Xerces SAX2 XML parser being a
quick
> example, the standard library would be another example, but all the
> operating systems I use play nice, so fstreams have never been a problem,
> they illustrate the buggy behavior, rather than the undefined kind of
> course).

You still haven't pointed to a single instance of undefined behavior.

> Additionally, exceptions and templates don't play nice,

Gosh, I thought I had completely dispelled that FUD mythology by now. In
what way do you think they "don't play nice"?

> tho I can't think of any undefined behavior off the top of my head

There might be a good reason for that.

> , but I can definitely think of behavior that leads to bugs.

Programming leads to bugs.

> Exceptions Specifications
> and templates is even more troublesome, but as they are so rare, and don't
> have a viable recovery mechanism (that I am aware of), I don't use them at
> all, so they result in no problems.

I have no defense for the design of exception specifications; they're not
terribly useful anyway so it's just as well that you don't feel compelled to
use them. However, there are no opportunities for undefined behavior with
exception-specifications AFAIK.

> I've never tried to copy an uninitialized int, so I'm not familiar with
the
> behavior, but if that can result in a core dump legally, that's
> disappointing.

It can launch a missile legally. I'm suggesting that there may well be room
for legitimate complaint about undefined behaviors in the standard, but if
so you're looking in the wrong place for them. The exception-handling
support is actually very tightly specified.

-Dave


---
[ 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:
> David Rasmussen wrote:
>
>> If you want strong enums, you can probably do them with a class,
>
>  > but what is benefit of not having a simple way of doing it?
>
> I have a book written in the late 19th century arguing against the
> adoption of the metric system in the US. The very valid point made
> by the book is that although the metric system is conceptually
> simpler, the English system would remain in place regardless, with
> the net result of requiring that people learn twice as many obscure
> conversions as before.
>
> The benefit of not having a simple way to do it is having only one
> way to do it, since the old way is here to stay.
>

If that was true, there would be no progress in history at all.

>> The general case of limiting built-in types.
>
>  > Why shouldn't C++ have such features?
>
> Because those features have to fit smoothly into the existing
> language as a whole. For fundamental numeric types, this means
> prowling through the entire standard to determine the effects
> on various structures. Given that this feature is not essential
> (after all C and C++ are successful languages which have never
> had it), the only way it's going to get in is if someone really
> motivated does the work.
>
> Here are examples of the complexity involved. What is the effect
> of ranged types on functions and templates? Does a ranged parameter
> affect overloading? Can a template recover the range of a ranged
> type parameter?
>
> If you really want this, get out your copy of the standard
> and start analyzing and designing.

I am probably not going to do the work. But that doesn't mean it isn't
needed/wanted/simple/possible/a good idea/feasible/clever/whatever.

/David

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

Mondo snippage throughout
David Rasmussen <pinkfloydhomer@yahoo.com> wrote in
news:3CF558CA.5070002@yahoo.com:
> Hyman Rosen wrote:
>>
>> The benefit of not having a simple way to do it is having only one
>> way to do it, since the old way is here to stay.
>>
>
> If that was true, there would be no progress in history at all.
>
Progress in general is a product of obstreperous people who (a) will not
shut up, and (b) will do the work to make things happen. There is a "rule"
in science that radical changes in thinking only happen when all the old
scientists die, this is because radical new theories are either (a)
obviously stupid; or (b) directly contradict some portion of their world
view. Old scientists become old scientists because most radical new
theories fall into camp (a) rather than camp (b). This is worth
considering...
>> Here are examples of the complexity involved. What is the effect
>> of ranged types on functions and templates? Does a ranged parameter
>> affect overloading? Can a template recover the range of a ranged
>> type parameter?
>>
>> If you really want this, get out your copy of the standard
>> and start analyzing and designing.
>
> I am probably not going to do the work. But that doesn't mean it isn't
> needed/wanted/simple/possible/a good idea/feasible/clever/whatever.
>
> /David
>
If it is needed/wanted/simple enough, someone will do the work.

Dan "Good ideas never die, unfortunately neither do bad ones" Smart
PS I think ranged types/strong enums are a good idea, I just do not think
they are valuable enough, I'd be happy if someone proved me wrong...
--
Dan Smart. C++ Programming and Mentoring.
cppdan@dansmart.com
ADDvantaged

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

> Ross Smith <r-smith@ihug.co.nz> writes:
>
> |>  Tom Puverle wrote:
>
> |>  > In response to some of the posts here, can I ask this: Could
> |>  > people indicate whether or not they would find it desirable if
> |>  > C++ had automatic garbage collection. Just a little poll,
> |>  > nothing more.
>
> |>  Absolutely not. It would break RAII, and that would be the end of
> |>  the world.
>
> Could you please explain how it would break RAII.  RAII generally uses
> local variables, which would be unchanged by garbage collection.

Well, the mere presence of GC in the language wouldn't break anything,
provided nobody actually used it. Perhaps I should have said, _using_
GC would break RAII, because GC could only be used on classes with
trivial destructors. That means that every class that is GCed is
forever constrained to have no code added to its destructor. I see that
as a gratuitous implementation constraint on the same order as having
public data members.

> |>  The whole concept of garbage collection is a massive technological
> |>  dead end that far too many people have wasted their time on. The
> |>  absence of GC is one of C++'s greatest strengths.
>
> This doubtlessly explains why practically all new languages include
> garbage collection, and many of the best C++ experts I know favor it
> in some form or another.

The former is because "practically all new languages" are proprietary
languages designed by companies who know a good deal more about
high-pressure marketing than technical realities. They include GC
because "everyone knows" it's a good idea so they have to mark it off
on their feature checklist, not because it actually _is_ a good idea.

The latter has always been a baffling mystery to me.

> |>  As far as I know, C++ is the _only_ language -- certainly the only
> |>  widely used one -- that has deterministic destructors. Doing away
> |>  with that would drop the number of languages in which it's
> |>  possible to do reliable resource management from one to zero.
>
> No one is proposing doing away with deterministic destructors.  When a
> local variable goes out of scope, its destructor is called.  When you
> invoke delete on a pointer, the destructor of the pointed to object is
> called.  And on exit, the destructors of the static objects are
> called, in the reverse order of construction.

So why bother with GC, when we have all that already? Nobody sane ever
writes an explicit call to delete any more, except on the very rare
occasions when they're actually implementing a smart pointer (and the
addition of a good smart pointer library to the standard will do away
with most of those occasions too). GC adds nothing except gratuitous
compiler complexity.

--
Ross Smith ...................................... Auckland, New Zealand
r-smith@ihug.co.nz ....................................................
       "...and to destroy the earth, type 'make destroy_earth'"
                                            -- ClanLib makefile

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

"David Rasmussen" <pinkfloydhomer@yahoo.com> wrote...
> Ken Hagan wrote:
> >
> > C++ is full of design errors, many of which were inherited from C.
>
> Indeed. Let's remove them.

[snip, quite a lot, including]

> Anytime I hear the "expert" defense, I always want to ask: "Yes, but on
> the other hand, what would you lose by giving up this old way of doing
> things?".

I get the impression that you assume C compatibility is the only problem
here. It is probably the main problem, hence my use of "many", but one
shouldn't neglect problems of C++ compatibility.

Anytime you ban dangerous constructs, or change the semantics, you break
existing code. Your suggestion to tighten up the scoping on enums would
break any code that has learned to live with the existing brain-death.

Also, most people are programming for operating systems that have no C++
API, but instead force us to use C headers. There's a *lot* of stuff in
<windows.h> that I wouldn't want to see in my own company's code, but I
wouldn't want my compiler to start rejecting it.


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

> > John Nagle:
> >>    Some assistance on the storage management front is useful,
> >>but garbage collection and destructors don't play well together.
> >>The semantics get wierd.  Look at Microsoft's "managed storage"
> >>system for C++.  Painful.
> >>
> >>A destructor is not a finalizer, and vice
> >>versa.
> >>
> >>    GC works better with Java semantics.

Garry Lancaster:
> > What's the problem? As far as I understand it the
> > golden rule is not to touch any GC pointers in a
> > destructor. If you follow that simple rule, there is
> > no problem.
>
>
>      You don't know when the destructor will be called, if ever.

First, I take issue with that "if ever". A decent GC system
will always call destructors/finalizers/whatever-you-want-
to-call-them eventually, unless the program explicitly
requests not to (e.g. it calls the abort() function) or the
program crashes. In that respect there is no real difference
from current popular C++ memory management
techniques. I've heard it said that Java's GC sometimes
neglects to call finalizers. I don't know if this is true or
not (although it strikes me as language war FUD), but
even if it is it tells you nothing about GC systems in
general.

So, barring certain borderline cases which C++ already
has, destructors will always be called. The fact that you don't
know exactly when the destructor will be called is both a
disadvantage and an advantage. When phrased in a
positive way we say: you don't have to worry about when
the destructor is called.

> So file closing, window closing, socket closing, database
> closing, and related operations may not happen when wanted.

Even for a Java/C# monolithic-type GC, this criticism is
a bit out of date. Both languages support immediate
cleanup idioms. As well as finally blocks, which aren't
particularly elegant I agree, there is the Execute Around
idiom for Java and using statements in C#. If the more
sophisticated approaches are hardly racing off the
fingertips of most Java/C# programmers, this tells you
more about how often they are really needed in those
languages [1].

However, I'm not suggesting a monolithic Java/C# GC
for C++. I'd like to see a system of smart pointers.
When you want GC you use it, when you don't you
use normal stack-based allocation or some other
dynamic memory management strategy. You can mix
and match within the same program as you see fit.
So, for those objects where you require more control
over destruction, you still have it.

I think there is a general misunderstanding that when
people suggest GC for C++, they mean a GC just like
Java's or maybe C#'s. I haven't seen anyone involved
in standardization propose this. Once this misunderstanding
is dealt with I think everyone will be a lot happier about
at least exploring the idea.

>      There's also the fact that calling destructors from GC
> introduces a form of concurrency.  What if a destructor
> does something that blocks?

All this would depend on the kind of GC in place. Different
multi-threaded GCs (and not all are, or need to be, multi-
threaded) offer all sorts of threading stategies. In general,
blocking destructors don't sound particularly edifying even
without GC. (What are they blocking on? Why are they so
confident that whatever it is will actually happen, even in
the face of exceptions?) If blocking destructors turn out
to be the biggest problem for GC in C++, it will be a
relatively easy sale, I think.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

NOTES:

1. Maybe it also tells us something about  the mean level of
expertise throughout the software industry. This isn't just a
dig at Java programmers. Present company excepted, in
my experience most C++ programmers have no idea what
RAII is or even what problem it is there to solve.

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

Ross Smith <r-smith@ihug.co.nz> writes:

| James Kanze wrote:
|
| > Ross Smith <r-smith@ihug.co.nz> writes:
| >
| > |>  Tom Puverle wrote:
| >
| > |>  > In response to some of the posts here, can I ask this: Could
| > |>  > people indicate whether or not they would find it desirable if
| > |>  > C++ had automatic garbage collection. Just a little poll,
| > |>  > nothing more.
| >
| > |>  Absolutely not. It would break RAII, and that would be the end of
| > |>  the world.
| >
| > Could you please explain how it would break RAII.  RAII generally uses
| > local variables, which would be unchanged by garbage collection.
|
| Well, the mere presence of GC in the language wouldn't break anything,
| provided nobody actually used it. Perhaps I should have said, _using_
| GC would break RAII, because GC could only be used on classes with
| trivial destructors.


Why? Could you elaborate on that?  I'm unclear with yoru assertions.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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 Tue, 28 May 2002 21:33:40 GMT, Garry Lancaster wrote in
<inOI8.2652$C72.143159@newsfep1-win.server.ntli.net>:

> As far as I know the same is true in Java and C#.
> (Although I've heard it said that Java doesn't always
> call finalizers which is worrying if true, but in my
> experience fans of one language tend to overstate
> the problems of other languages. When people say
> Java leaks memory I confess that baffles me too.)

A finalizer is invoked when an object is garbage collected but there is
no guarantee it will ever be (e.g., when you have heaps of memory an a
small number of objects).

> As for destructors != finalizers, I think the existance of
> increasingly GC-like smart pointers in C++ means the
> line is now very blurred. I'm not sure it is a useful
> distinction any more.

???

Please elaborate which smart pointers do you consider "GC-like" and in
what ways?


Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

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

Ross Smith wrote:

> Daniel Miller wrote:
>
>>   Instead so far I see statements in postings which indicate that
>> Boost would
>> in fact receive some form of preferrential treatment over competing
>> entrants in
>> the competition for standardization.
>>
>
> That was more or less the whole point of Boost. I don't understand why
> you see it as a bad thing.


   I would hope that all members of LWG, WG21, and J16 have the goal of doing
the best job possible, which includes standardizing the best libraries possible,
regardless of who submitted them.  If an inferior entrant from Boost were to be
submitted for standardization consideration and 1 or 2 or 3 superior libraries
covering that same topic are also submitted for consideration, I would hope that
LWG or WG21/J16 would perform some sort of bake-off allowing a fair & equal
direct apples-to-apples comparison between the various entrants, measurement of
simplicity/directness of expressing a concept in code, assessment of reliability
of behavior, measurement of various efficiencies, and measurement of
expressivity & extensibility as a solution-space for all of the major
problem-spaces.

   One such major problem-space for multithreaded software is realtime embedded
systems, portability to RTOSes, and support of realtime embedded system idioms.
  Boost.threads (in its current form as well as what has been revealed as
Boost.threads' intended future form) ignores:
   1) many of the needs of realtime embedded systems,
   2) the multithreaded idioms which the realtime embedded software industry has
built up over the past 2+ decades of using multithreaded software in industrial
practice,
   3) portability to RTOSes.

   http://www.boost.org/status/compiler_status.html

   As further evidence, Boost (especially Boost.threads) does not even list
*any* RTOSes as the platforms to which it ports.  To even *consider* submitting
a threads/interthread-synchronization/interthread-asynchronous-communication
library for standardization which ignores (in part or in full) the RTOSes & the
embedded realtime software industry:
   1) is embarrassing (for the C++ community at large) and
   2) is a tragedy (for humankind which is becoming increasingly dependent on
realtime embedded software for safety and survival).

   I and others in the realtime embedded software industry must ask ourselves:
Is Boost.org functioning as a community where the needs of the realtime embedded
software industry are well-respected & welcomed?  If Boost.org in the large (and
Boost.threads in particular) does not fully address the needs of the portion of
the realtime embedded software industry whose software is based on C++, then the
realtime embedded software industry must look elsewhere for a voice into the
C++0x library standardization effort.


   GLOSSARY

   interthread asynchronous-communication = the (multi)producer-(multi)consumer
message-queue idiom, such as in pSOS.  In this idiom one or more threads can
post to a message-queue which is read by one *or* *more* threads which pend on
that message-queue.  The threads which all pend on the same message-queue
comprise a lightweight thread-pool which is scheduled by the kernel, not by the
application-domain.  The RTOS-style multiproducer-*multi*consumer message-queue
idiom is omitted from Boost.threads.

   RTOS = realtime operating systems, e.g., pSOS, VxWorks, QNX, LynxOS

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

David Abrahams wrote:

>> I don't want to attack anything, I want to stop having to spend money on
>> books that explain the caveats of C++ (they are really quite expensive).
>
> Maybe you should just familiarize yourself with what the language standard
> actually says about those features...
>
>> What do I do if an exceptional condition occurs while I am destroying an
>> object?
>
> It's up to you, but if you throw the results are well-defined.
>
>> Why is it never safe to ever call a function that may throw an
>> exception in a destructor (even if I'm willing to catch it and clean up
>> myself)?
>
> You must have a very odd definition of "safe" if you think that's so. What
> do you think is unsafe about throwing in a destructor when the destructor
> contains a catch(...) clause?
>

Yep, you're right I am wrong.  I was mistaken about what was and was not
allowed with respect to multiple active exceptions (I've got to reread it
to be sure of exactly what is and is not legal (and probably write some
code).  And there is no undefined behavior, it calls terminate.  In fact
this is exactly the kind of thing I would like to see for much of the
undefined behavior (well, I'd like some of it to be more forgiving, but
that is beside the point, this behavior is well specified, and nice).  I'm
sorry about the confusion.

--
Brad Settlemyer
http://deepcopy.org/
Progamming in the trenches

---
[ 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 <3CF4F0BA.2040405@yahoo.com>, David Rasmussen
<pinkfloydhomer@yahoo.com> writes
>>   Why do you assume that those of us working on the evolution of C++
>>are  going to ignore the desirability of making things simpler where
>>that can  be done without much cost.
>
>I don't assume it. I experience it.

Extraordinary claim. The evolution working group has only just drafted
its terms of reference (this April) so I cannot imagine where you get
this experience from. Perhaps you confuse some of the statements you see
here as official WG21 policy.


--
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:
>
> I have a number of cases
> where I represent sets of characters using a bit map.  It is obvious
> that a bit map is NOT an appropriate representation when the domain
> contains over a million elements -- each bit map would require more
> that 128 K bytes.  But what is the appropriate representation?  For
> the moment, I'm using a list of ranges.  But there are certain
> functions, e.g. in my regular expression handling, that have become
> inordinately slow.  I'm sure that they can be improved, doubtlessly by
> using some knowledge of the representation, but that will take some
> thinging to achieve.
>
> [...]
>
> Anyhow, if anyone has any ideas about other representations, I'm all
> ears.

Any one document tends to be written mostly or entirely in one language,
and thus use characters from only one or two of the Unicode script
blocks (Latin 1, Greek, Cyrillic, etc.). Perhaps representing a set of
characters as a (small) set of block identifiers, and then a bitset for
each block, might be a net win? (At least with alphabetic scripts; it
may not work so well with CJK, which doesn't tend to divide into such
conveniently sized blocks.)

--
Ross Smith ...................................... Auckland, New Zealand
r-smith@ihug.co.nz ....................................................
       "...and to destroy the earth, type 'make destroy_earth'"
                                            -- ClanLib makefile

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

Hyman Rosen wrote:
> Ranged types can be created by allowing constant ranges after
> simple type specifiers, eg.,
>         typedef char 'a' .. 'z' lc;
>         typedef int 0 .. 100 pct;
> Ranged types interconvert freely like their unranged sources,
> but the compiler will insert checks so that an exceptions is
> thrown on attempt to set a value that's out of range.=20
Note, that this is already possible using templates. As a side effect
you get static checks, whenever possible. A year ago I wrote a paper
about this topic for the template workshop. Unfortunately it wasn't
accepted due to some errors and a second -=E4=E4hm- experimental part and=
 so
I haven't spent much further work on it. But I think, it's possible to
extend it, so it can also handle multiple ranges or exclude ranges (e.g.
exclude 0 for a divisor). =20


Best regards
Olaf Krzikalla


BTW: Does the template workshop still exist?

---
[ 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 Sun, 26 May 2002 16:00:43 GMT, Dan Smart wrote in
<Xns921AEB5F3A3BMe@167.206.112.134>:

> There are things in C++ that need fixing, although strangely garbage
> collection is not actually on my list. My list is:
> Elimination of C style casts.

Sometimes (e.g., Win32 API) one needs to cast between pointers to data
and pointers to functions.  I find the following too unwieldy:

    pFunc = reinterpret_cast<PFUNC>(reinterpret_cast<int>(pData));

> Strong typedefs.

..., strong enums, (more) portable sized data types, ...

> Rationalisation of template syntax.

???

> A decent low level thread library, just the primitives thanks.

Plus optional thread safety mechanisms for the standard library.
Perhaps wrappers

> Closed namespaces.

> In place initialisation of non-int const static members.

Yes please.

> I'd like the interfaces to parts of the STL tidied up as well, but it isn't
> going to happen unfortunately (what is the difference between list.empty()
> and list.clear() ?).

Some sort of lambda functionality will make the standard algorithms
friendlier.

> Dan "A computer without Java is like chocolate cake without mustard" Smart

Java is a tool.  Would you disparage a saw just because you find a
hammer more suitable for your needs?


Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

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

"Garry Lancaster" <glancaster@ntlworld.com> writes:

|>  People looking for a C++ GC system shouldn't overlook
|>  boost::shared_ptr. It can't easily cope with cyclic references
|>  (although at a pinch there are various ways to break the cycle)
|>  but if you can live with that limitation it may do everything you
|>  want.

Not really.  It doesn't work in quite a number of real programs.  The
problem is simple: in C++, you *have* raw pointers.  You can't avoid
it, because "this" is a raw pointer.  So you inevitably end up with
some raw pointers that are involved in ownership.  With some counted
pointers, you can convert these into a counted pointer without
problems, but with the Boost shared_ptr, you must convert the raw
pointer exactly once; converting it a second time will lead to
prematurely freeing the memory.

|>  As for destructors !=3D finalizers, I think the existance of
|>  increasingly GC-like smart pointers in C++ means the line is now
|>  very blurred. I'm not sure it is a useful distinction any more.

The problem is perhaps one of vocabulary, but C++ destructors are
totally unrelated to Java finalizers.

Even with garbage collection, C++ destructors must be run when local
variables go out of scope, at the end of program on static variables,
and when delete is explicitly invoked.  It is less obvious what should
happen when an object is collected; my personal feeling is that
destructors should NOT be called in this case.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

"Alex Oren" <response@myrealbox.com> wrote in message
news:vqt9fusge9rari6lph2ffq1hja3thhpkim@4ax.com...

> Sometimes (e.g., Win32 API) one needs to cast between pointers to data
> and pointers to functions.  I find the following too unwieldy:
>
>     pFunc = reinterpret_cast<PFUNC>(reinterpret_cast<int>(pData));

// static_assert

template<bool> struct static_assert;

template<> sturct static_assert<true> {
    inline static_assert(const char* = 0) {
        return;
    }
};

// is_ptr

template<class T> struct is_ptr {
    enum { value = 0 };
};

template<class T> struct is_ptr<T*> {
    enum {v value = 1 };
};

// function_cast

template<class R, class T>
inline R function_cast(T* p) {
    static_assert<is_ptr<R>::value>("error: non-pointer type");
    return *reinterpret_cast<R*>(&p);
}

pFunc = function_cast<PFUNC>(pData);

Paul Mensonides

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

Olaf Krzikalla wrote:
> Hi,
>
> Hyman Rosen wrote:
>
>>Ranged types can be created by allowing constant ranges after
>>simple type specifiers, eg.,
>>        typedef char 'a' .. 'z' lc;
>>        typedef int 0 .. 100 pct;
>>Ranged types interconvert freely like their unranged sources,
>>but the compiler will insert checks so that an exceptions is
>>thrown on attempt to set a value that's out of range.
>
> Note, that this is already possible using templates. As a side effect
> you get static checks, whenever possible. A year ago I wrote a paper
> about this topic for the template workshop. Unfortunately it wasn't

I would very much like to see that. Where can I read about it?

/David

---
[ 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 <3CF4F979.4030101@tellabs.com>, Daniel Miller
<daniel.miller@tellabs.com> writes
>  I would hope that all members of LWG, WG21, and J16 have the goal of
>doing the best job possible, which includes standardizing the best
>libraries possible, regardless of who submitted them.  If an inferior
>entrant from Boost were to be submitted for standardization
>consideration and 1 or 2 or 3 superior libraries covering that same
>topic are also submitted for consideration, I would hope that LWG or
>WG21/J16 would perform some sort of bake-off allowing a fair & equal
>direct apples-to-apples comparison between the various entrants,
>measurement of simplicity/directness of expressing a concept in code,
>assessment of reliability of behavior, measurement of various
>efficiencies, and measurement of expressivity & extensibility as a
>solution-space for all of the major problem-spaces.

I think you misunderstand the process. WG21 & J16 LWG would use any
valid starting point, but it is very unlikely that what went into the
standard would be exactly what was originally submitted. OTOH it would
be likely that (particularly in view of prior experience) that what went
into the standard would be tested first and one of the obvious test
sites is, IMO, Boost. Or are you saying that we must create some other
forum in which LWG proposed libraries should be exposed for testing on a
wide basis?


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

Francis Glassborow wrote:
> In article <3CF4F0BA.2040405@yahoo.com>, David Rasmussen
> <pinkfloydhomer@yahoo.com> writes
>
>>>   Why do you assume that those of us working on the evolution of C++
>>> are  going to ignore the desirability of making things simpler where
>>> that can  be done without much cost.
>>
>>
>> I don't assume it. I experience it.
>
>
> Extraordinary claim. The evolution working group has only just drafted
> its terms of reference (this April) so I cannot imagine where you get
> this experience from. Perhaps you confuse some of the statements you see
> here as official WG21 policy.
>

I was talking about the reaction from members of this group.

/David

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

Ross Smith <r-smith@ihug.co.nz> writes:

|>  James Kanze wrote:

|>  > I have a number of cases where I represent sets of characters
|>  > using a bit map.  It is obvious that a bit map is NOT an
|>  > appropriate representation when the domain contains over a
|>  > million elements -- each bit map would require more that 128 K
|>  > bytes.  But what is the appropriate representation?  For the
|>  > moment, I'm using a list of ranges.  But there are certain
|>  > functions, e.g. in my regular expression handling, that have
|>  > become inordinately slow.  I'm sure that they can be improved,
|>  > doubtlessly by using some knowledge of the representation, but
|>  > that will take some thinging to achieve.

|>  > [...]

|>  > Anyhow, if anyone has any ideas about other representations, I'm
|>  > all ears.

|>  Any one document tends to be written mostly or entirely in one
|>  language, and thus use characters from only one or two of the
|>  Unicode script blocks (Latin 1, Greek, Cyrillic, etc.). Perhaps
|>  representing a set of characters as a (small) set of block
|>  identifiers, and then a bitset for each block, might be a net win?
|>  (At least with alphabetic scripts; it may not work so well with
|>  CJK, which doesn't tend to divide into such conveniently sized
|>  blocks.)

You mean embedding knowledge of the coding semantics into my
representations?  I'm not sure I like that.  And I don't want to have
different code according to the type of document.

One idea did occur to me: instead of ranges, use some sort of sparse
array for the bytes in a bit map.  This would certainly help for
things like the set of all lower case letters; the range table
currently contains more than 400 ranges, many with just a single
character.  (In many blocks, the characters alternate between upper
and lower.)  But I'm not sure that this would be a win globally -- the
range tables for upper and lower seem to be the exceptions.

--
James Kanze                                mailto:kanze@gabi-soft.de
Do you need real expertise in C++? in Java? in OO design?
                       I am available, see my CV at www.gabi-soft.de
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

Dan Smart wrote:
>
> If it is needed/wanted/simple enough, someone will do the work.
>
> Dan "Good ideas never die, unfortunately neither do bad ones" Smart
> PS I think ranged types/strong enums are a good idea, I just do not think
> they are valuable enough, I'd be happy if someone proved me wrong...

It's difficult to prove the value of such basic things as ranged types
and strong enums in a short paragraph. But look at Ada's way of doing
this. The fundamental point is that the programmer should be able to
express all aspects of a design as directly and as precisely as
possible. If the programmer really wants an integer type that will
always be within 0..100, it is very valuable to be able to state so. For
readability, for optimizing by the compiler, for optional runtime checks
of the type bounds etc. The value of this is universal. Now, they can
maybe be implemented within the current language (although direct
language support will surely help the compiler with optimization). But
it is not as simple as saying typedef new int(1..100) percent or
something. Fundamental, and conceptually simple and frequently recurring
design concepts such as bounded types or strong enums, should not be
hard to express for the programmer.

I agree that it takes a lot of work to find a good way of doing it and
to know exactly where it impacts on the "old" language. But that doesn't
make it less important.

/David

---
[ 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, 27 May 2002, David Rasmussen wrote:

> The good thing about a garbage collector for C++, is that one can start
> with just using the garbage collector, which _is_ simpler, and less
> error-prone. Then, if it turns out to be a hotspot or a bottleneck, you
> could turn to manual destruction.

I don't think that is true. I don't think you can migrate from a GC
model to an explicit memory management model very easily.

If you write for GC, you need have no thought for ownership policies.
You create objects when you need them, and they go away eventually.
If "eventually" isn't good enough, maybe you insert explicit delete
operations. But with no prior thought to an ownership policy,
how do you determine when it is appropriate to delete an object,
that is, whether other live objects are retaining a pointer to the
object you intend to delete?

--
Steve Clamage, stephen.clamage@sun.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                       ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote:

>In article <3CF1EF58.1060301@yahoo.com>, David Rasmussen
><pinkfloydhomer@yahoo.com> writes
>>The good thing about a garbage collector for C++, is that one can start
>>with just using the garbage collector, which _is_ simpler, and less
>>error-prone. Then, if it turns out to be a hotspot or a bottleneck, you
>>could turn to manual destruction. Also, garbage collection in
>>conjunction with manual destruction can be used for finding memory
>>leaks and other bugs. Research shows that for most applications,
>>garbage collection isn't a performance problem at all. The myths of the
>>garbage collector halting the application for seconds, were true 10-20
>>years ago, but seldom today, unless your application is non-typical.
>
>True, but so is the myth that it is necessary to do manual resource
>management in C++. A competent programmer knows how to avoid explicit
>calls to delete except inside properly designed components.
>Learning to do that gets you much more than memory management.

  Yes, it does. And the similar issue of learning how to do
polymorphism without exposing pointers to the application layer(s) is
just as valuable. Too bad this isn't very widely taught.

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt

---
[ 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:Vz9Ul7FPJp88EwYr@robinton.demon.co.uk...
> Of course not, but the point is that misuse is not only possible in both
> languages but rife in both.
If there's a language in which misuse isn't rife, please tell me what it is.
Privately, so this knowledge becomes a competitive advantage:-)

> Java simply has not lived up to its claims
> to fix the problems, indeed memory leaks in Java are even harder to fix
> if and when you discover them.

Largely because garbage collection has already eliminated the simpler sort
of leak.

I find it interesting that C++ problems can be dismissed with "No one
knowledgeable would do that", while Java problems caused by lack of
expertise are a fatal flaw.

---
[ 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@alex.gabi-soft.de> writes:

[about garbage collection]
> You should always start with a design, and the lifetime of an object
> is an element of that design, and should be resolved according to
> the design, before you start coding.
>
> Where garbage collection comes in is much later, when you start
> coding.  Using an existing garbage collection is a magnitude of
> order easier and less error prone when used to *implement* the
> design, when appropriate.

I agree but I want to point out that if you know that a garbage
collection is available, the design space is greater.

For example, if I know that a garbage collector is available, I may
use a data structure with shared ownership and cyclic references.  If
no garbage collector is available, I'll probably try to break the
cyclic references or not use the shared ownership, even if that imply
a more complicated design.

--
Jean-Marc

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

"David Rasmussen" <pinkfloydhomer@yahoo.com> wrote...
>
> Many of the suggestions of additions/changes to the C++ language that I
> have proposed or that I agree with, are often met by experts like you
> with an argument along the lines of "an expert would know how to do that
> /avoid that". But my point is that if it takes an expert to do something
> quite simple, it is probably not a good idea, and it seems to indicate a
> design error.

C++ is full of design errors, many of which were inherited from C.
The question is how to remove them. You have two choices.

 1 You can force a compiler error. This appears to have the advantage
   that novices can't make the error even if they want to. However,
   in practice, compiler vendors will offer a "backwards compatibility"
   option so that a billion lines of existing code is not lost. The
   novices will use that option and carry on as before.

 2 You can issue a compiler warning. (You can use other tools for this
   too, of course.) The advantages are that no change to the standard
   is required and the experts can continue to use the feature when
   they believe it is justified. The disadvantage is that novices
   generally switch off all the warnings because "it is too hard to
   write code that avoids them".

Either way, the novices will carry on writing duff code if they want to.
A better measure for a feature is whether it helps experts avoid errors.
An expert, in this context, is anyone whose desire to write good code
has driven them to read some of the books that discuss the various gotchas
and how to avoid them.


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

Alex Oren <response@myrealbox.com> writes:

|>  On Fri, 24 May 2002 15:14:53 GMT, James Kanze wrote in
|>  <86off6qa32.fsf@alex.gabi-soft.de>:

|>  > Do you mean dead, like Fortran and Cobol?  (I think that there
|>  > is still more new code written in Cobol than in any other
|>  > language.  And I certainly wouldn't say that all, or even any,
|>  > of the design errors in Cobol have been corrected.)

|>  But is there a lot of *new* code written in COBOL?

At least in some places, yes.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

"Markus Mauhart" <markus.mauhart@chello.at> writes:

|>  "James Kanze" <kanze@alex.gabi-soft.de> wrote ...

|>  > I've about had it with untried experiments.)

|>  Btw, what about your efforts to understand/use/reimplement
|>  streams, strings, and locales ?-)

It's about so-so for the moment.  I'm still very much at the
experimentation phase, which means that most of what I do, I end up
redoing when I try to extend it, because I find that I've done it
wrong.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

David Rasmussen <pinkfloydhomer@yahoo.com> writes:

|>  Bo Persson wrote:

|>  > Garbage collection was *very* useful in C++'s ancestor Simula,
|>  > because that language had (sort of) constructors but no
|>  > destructors. That made it difficult to clean up after the
|>  > objects!  Using a constructor/destructor pair in an object, I
|>  > think we get a nice symmetry for allocating/deallocating
|>  > resources. I have never had any problems with this. Remember
|>  > also that there might be a lot of other resources an object
|>  > aquires, which would all be reallocated anyway. Why would memory
|>  > be treated differently?

|>  The good thing about a garbage collector for C++, is that one can
|>  start with just using the garbage collector, which _is_ simpler,
|>  and less error-prone. Then, if it turns out to be a hotspot or a
|>  bottleneck, you could turn to manual destruction.

I think you've missed the point.  The goal is to use garbage
collection when garbage collection is appropriate, and other
techniques when other techniques are appropriate.  I can't imagine a
case where garbage collection is slower than other techniques, but
there are definitly times when it isn't appropriate.

Of course, you need to do that analysis to know when it is
appropriate, and when not.  But you have to do that regardless of the
memory management techniques you are using.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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:
>
> I so often wish that the C++ designer(s) had learned from Ada,

I very much agree!!

> which has all of the above and more. Ranged integers would be
> great, too. So let me contribute to the wishing frenzy by
> suggesting some syntax and semantics.
>
> Strong typedefs should have the following syntax:
>     typedef new declaration;
> eg.,
>     typedef new unsigned char byte;
>     typedef new void (*vfp)();
>
> These new types have no automatic conversion to or from their
> source type, but can be converted using static or functional
> cast, eg.,
>     unsigned char c;
>     byte b = c; // illegal
>     byte b = byte(c); // ok
>     byte b = static_cast<byte>(c); // ok
> They should have automatic conversion from literals of their type, eg.
>     typedef new long nl;
>     nl an_nl = 17L; // ok
>     nl an_nl = 17;  // illegal
>
> All types will need to have a defined set of primitive operations.
> Then a new type receives a set of these primitive operations. For
> the arithmetic types, this includes the usual operators, for pointer
> types this includes indirection and subtraction, and so forth. This
> prevents mixed arithmetic. Eg.,
>     typedef new int my_int;
>     // my_int operator+(my_int, my_int);
>     // my_int operator*(my_int, my_int);
>     // ad nauseum
>
> We can combine this with permitting an enum type to be defined
> in such a typedef, eg.,
>     typedef new enum { a, b, c } letters;
> and removing the automatic conversion to integer from literals
> so defined.
>

Very good ideas. I agree.

> Ranged types can be created by allowing constant ranges after
> simple type specifiers, eg.,
>     typedef char 'a' .. 'z' lc;
>     typedef int 0 .. 100 pct;
> Ranged types interconvert freely like their unranged sources,
> but the compiler will insert checks so that an exceptions is
> thrown on attempt to set a value that's out of range. References

I know that most compilers implementing this would probably have an
option of removing these checks. But I think it is very important that a
language gives the programmer the power to choose. So the compiler
should be forced to provide the ability to turn on and off such checks
(which are not only checks but also can be used for optimizing), perhaps
even via some language constructs, not only by compiler switches.

> to ranged types may be initialized from unranged or wider-ranged
> types. There is a check on initialization, and it is undefined
> behavior for a side effect to modify such a referenced variable
> to be outside the range of any existing ranged reference. Eg.,
>     typedef char 'a' .. 'z' lc;
>     typedef char 'a' .. 'f' hex;
>     lc c = 'A'; // exception
>     void f(hex &h);
>     lc d = 'b';
>     f(d); // ok
>     lc e = 'g';
>     f(e); // exception
>     void side_effect() { d = 'z'; }
>     void f(hex &h) { side_effect(); }
>     f(d); // undefined behavior
>
> Then we add a new syntax for 'for' loops:
>     for(declaration)
> where the declaartion declares a single variable of integral or
> enumeration type, ranged or not. The loop will iterate over the
> range of the variable, and the variable is considered const in
> the loop. Eg.,
>     for (char c)    // loop over all characters
>     for (lc c)    // loop over lower-case letters
>     enum e { a = 7, b = 3, c = 7 };
>     for (e x)    // loop three times: x = 7, x = 3, x = 7
>

Again, I agree. Very elegant, and btw. very Ada-like.

/David

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

Tom Puverle wrote:

> In response to some of the posts here, can I ask this:
> Could people indicate whether or not they would find it desirable if
C++ had
> automatic garbage collection. Just a little poll, nothing more.

Absolutely not. It would break RAII, and that would be the end of the
world. The whole concept of garbage collection is a massive
technological dead end that far too many people have wasted their time
on. The absence of GC is one of C++'s greatest strengths.

As far as I know, C++ is the _only_ language -- certainly the only
widely used one -- that has deterministic destructors. Doing away with
that would drop the number of languages in which it's possible to do
reliable resource management from one to zero.

--
Ross Smith ...................................... Auckland, New Zealand
r-smith@ihug.co.nz ....................................................
       "...and to destroy the earth, type 'make destroy_earth'"
                                            -- ClanLib makefile

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

Pete Becker <petebecker@acm.org> writes:

|>  James Kanze wrote:

|>  > Java's threading isn't any slower than anyone else's.  Writing
|>  > thread safe programs is more difficult than writing single
|>  > threaded programs.  Regardless of whether the language is Java
|>  > or C++.  What is happening is that a lot of applications in Java
|>  > are multithreaded when they shouldn't be, because it is much
|>  > more difficult to avoid threading in Java.

|>  I think it's the other way around: Java makes it too easy to write
|>  multi-threaded programs, so too many programmers who don't know
|>  what they're doing are writing them.

I think we're saying the same thing.  Java programs *are*
multithreaded, almost by default, and even when they shouldn't be.
Java makes it easy to end up multi-threaded.

It doesn't make it easier to write correct multi-threaded programs.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

Steve Clamage <clamage@eng.sun.com> writes:

|>  On Mon, 27 May 2002, David Rasmussen wrote:

|>  > The good thing about a garbage collector for C++, is that one
|>  > can start with just using the garbage collector, which _is_
|>  > simpler, and less error-prone. Then, if it turns out to be a
|>  > hotspot or a bottleneck, you could turn to manual destruction.

|>  I don't think that is true. I don't think you can migrate from a
|>  GC model to an explicit memory management model very easily.

|>  If you write for GC, you need have no thought for ownership
|>  policies.

That's not quite true, and that attitude explains many of the memory
leaks in Swing.

In many cases, ownership isn't important in itself, and in such cases,
garbage collection saves a lot of work.  But you still have to think
about ownership enough to determine which cases are one of these, and
which ones aren't.

|>  You create objects when you need them, and they go away
|>  eventually.  If "eventually" isn't good enough, maybe you insert
|>  explicit delete operations.

Exactly.  You have to analyse enough to determine when "eventually" is
good enough.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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 <86u1osy1d7.fsf@alex.gabi-soft.de>, James Kanze
<kanze@alex.gabi-soft.de> writes
>In practice, given the situation on the ground, if Boost covers the
>issue, I suspect that alternatives will have a much more difficult
>time of it.  But I doubt that that is an absolute.

I might put it another way, if Boost is not interested then those on
WG21 are not likely to be (note, I wrote 'likely) and if WG21 is
interested Boost will probably work on a design/implementation.

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

"John Nagle" <nagle@animats.com> wrote...
>      Every day, thousands of programs and systems crash
> because C++ hasn't fixed this problem.  This is unnecessary,
> and perhaps irresponsible.

In contrast, the Java and C# programs bash on and give the wrong
answer. I assume we are running these programs on a proper operating
system, so it hardly matters whether we crash or write garbage
results. In both cases the user loses their data.

The cause in both cases is poor programming. The choice of language
only alters how the poor programming manifests itself. There's not
much that compilers can, or should, do about poor programming, but
other tools can perform deeper analysis (either static or dynamic)
if only programmers could be persuaded to use them.

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

"Bo Persson" <bop2@telia.com> wrote in
news:o3bI8.9247$p56.2683671@newsb.telia.net:
> "Dan Smart" <cppdan@dansmart.com> skrev i meddelandet
> news:Xns921AEB5F3A3BMe@167.206.112.134...
> (snip)
>> Of course memory leaks in Java are impossible. Which means the leaks
>> in Swing don't exist.
>
> But that is only because the JVM is written in C/C++, and is leaking
> memory! As soon as someone rewrites the JVM in pure Java, this problem
> will disappear. :-)
>
No, it is because GC doesn't relieve you of the requirement to tidy up. If
you stick something in a collection, and never remove it, it won't ever get
GCed. Swing used to do this everywhere, and still does it in some places.
>> Fortran is of course the picture of a healthy language, every company
>> I know is moving all their development effort to Fortran.
>
>:-)
>
> Actually, we are using COBOL.
>
I'm just about to start working on a system written in APL (or at least a
derivative thereof).

>> Elimination of C style casts.
>
> Great. In the mean time we could ask our favorite compiler writer to
> just add a warning.
>
Or even some of our less favourite compiler writers :->

>> Closed namespaces.
>
> Which means?
>
Given foo.h
     struct Foo {
          void bar(int);
     };
and foo.cpp
     void
     Foo::bar(unsigned int) { }

you will get an error at compile time. Do the samething with a namespace,
and you will get an error at link time. Frequently in my code, link time is
also run time, which is a pain.
Closed namespaces means two things to me:
1) Non-extensibility, a closed namespace has a single definition
(presumably in a header file). Nothing may be added to that namespace in
any other namespace blocks.
2) Which implies that defining something in an implementation file that
hasn't been previously declared would be an error.

>> I'd like the interfaces to parts of the STL tidied up as well, but it
> isn't
>> going to happen unfortunately (what is the difference between
>> list.empty() and list.clear() ?).
>
> I can learn to live with that.
>
We are going to have to.

Dan "Who knows a thing or two about not tidying up" Smart
--
Dan Smart. C++ Programming and Mentoring.
cppdan@dansmart.com
ADDvantaged

---
[ 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 Hagan wrote:
>
> C++ is full of design errors, many of which were inherited from C.

Indeed. Let's remove them.

> The question is how to remove them. You have two choices.
>
>  1 You can force a compiler error. This appears to have the advantage
>    that novices can't make the error even if they want to. However,
>    in practice, compiler vendors will offer a "backwards compatibility"
>    option so that a billion lines of existing code is not lost. The
>    novices will use that option and carry on as before.
>
>  2 You can issue a compiler warning. (You can use other tools for this
>    too, of course.) The advantages are that no change to the standard
>    is required and the experts can continue to use the feature when
>    they believe it is justified. The disadvantage is that novices
>    generally switch off all the warnings because "it is too hard to
>    write code that avoids them".
>
> Either way, the novices will carry on writing duff code if they want to.
> A better measure for a feature is whether it helps experts avoid errors.

It is a good point. But first of all, I think there my be more
possibilities than these two. Secondly, just because something _can_ be
done by an expert, it doesn't mean that there isn't need for a cleaner
and better way of doing things. Even the expert will gain from this.
Anytime I hear the "expert" defense, I always want to ask: "Yes, but on
the other hand, what would you lose by giving up this old way of doing
things?". Just because something _can_ be done, doesn't mean it isn't a
good thing to make it possible to do it easier, simpler, cleaner, better
etc. Of course, really radical changes will hurt old code, and language
changes always hit (but also pay) compiler vendors.

As I see it, the C++ community is becoming aware of all the problems
with C++ that stems from it's C heritage in these years. With C99 and
the current state of C++, I don't think it is very likely that the two
languages can continue two develop together. Bjarne Stroustrup would
very much like to see the two languages still being "compatible". But I
think the two languages are diverging. I sure hope so. All we have now
is a language that allows an old and a new style, but recommends the new
style and preaches that the old style should not be used. So why have
the old style? Of couse, all the old C code will still have to compile
somehow, but lo and behold! we have C compilers for that. C++ is a nice
language as it is now, but it's potential is being held back by all it's
C drawbacks. Why not just seperate the two languages? If people want C
they can use C. What is the _advantage_ of having C++ enums being weak
types, for instance? There is _no_ advantage. Compatibility with C is
not an advantage here. It's only a drawback. Let C++ mature to it's full
potential. I am not talking all sorts of complex additions whose
advantages have to be proved. I am talking about removing all the
wellknown problematic things that C gives to C++, and adding obvious
features that only lack in C++ because of it's C heritage.

/David

---
[ 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 <hyrosen@mail.com> writes:

> David Rasmussen wrote:
> > Francis Glassborow wrote:
> >> I think we need some mechanism for strong typedefs
> > I agree 100%. Also, the possibility of defining strongly typed enums
> > that are _not_ ints, but their own type. Somehow we would have to find a
> > way to use them in for() loops. Both of these features could be added
> > without wrecking existing code.
>
> I so often wish that the C++ designer(s) had learned from Ada,
> which has all of the above and more. Ranged integers would be
> great, too. So let me contribute to the wishing frenzy by
> suggesting some syntax and semantics.
>
> Strong typedefs should have the following syntax:
>  typedef new declaration;
> eg.,
>  typedef new unsigned char byte;
>  typedef new void (*vfp)();

I like that syntax.

>
> These new types have no automatic conversion to or from their
> source type, but can be converted using static or functional
> cast, eg.,
>  unsigned char c;
>  byte b = c; // illegal
>  byte b = byte(c); // ok
>  byte b = static_cast<byte>(c); // ok
> They should have automatic conversion from literals of their type, eg.
>  typedef new long nl;
>  nl an_nl = 17L; // ok
>  nl an_nl = 17;  // illegal
>
> All types will need to have a defined set of primitive operations.
> Then a new type receives a set of these primitive operations. For
> the arithmetic types, this includes the usual operators, for pointer
> types this includes indirection and subtraction, and so forth. This
> prevents mixed arithmetic. Eg.,
>  typedef new int my_int;
>  // my_int operator+(my_int, my_int);
>  // my_int operator*(my_int, my_int);
>  // ad nauseum

I'd like to be able to avoid certain operators. For example, I'd like
to be able to do

  typedef new double Temperature;

and disallow multiplication of two temperatures (whatever that product
may be, it's for sure not a temperature).

Maybe one can define groups of operators, such as logical, additive,
multiplicative, etc., and on definition of the new type tell which
group should be inherited by the new type.

For example, the variable Temperature could be declared as

  typedef new[std::additive] double Temperature;

where std::additive is an operator group containing operator+ and
operator- (both unary and binary) for the new type (and maybe
multiplication with the old type, in this example double). Ideally,
one could define such operator groups oneself (with the most often
used predefined in std).

>
> We can combine this with permitting an enum type to be defined
> in such a typedef, eg.,
>  typedef new enum { a, b, c } letters;
> and removing the automatic conversion to integer from literals
> so defined.

Nice.

>
> Ranged types can be created by allowing constant ranges after
> simple type specifiers, eg.,
>  typedef char 'a' .. 'z' lc;
>  typedef int 0 .. 100 pct;
> Ranged types interconvert freely like their unranged sources,
> but the compiler will insert checks so that an exceptions is
> thrown on attempt to set a value that's out of range. References
> to ranged types may be initialized from unranged or wider-ranged
> types. There is a check on initialization, and it is undefined
> behavior for a side effect to modify such a referenced variable
> to be outside the range of any existing ranged reference. Eg.,
>  typedef char 'a' .. 'z' lc;
>  typedef char 'a' .. 'f' hex;
>  lc c = 'A'; // exception
>  void f(hex &h);
>  lc d = 'b';
>  f(d); // ok
>  lc e = 'g';
>  f(e); // exception
>  void side_effect() { d = 'z'; }
>  void f(hex &h) { side_effect(); }
>  f(d); // undefined behavior
>
> Then we add a new syntax for 'for' loops:
>  for(declaration)
> where the declaartion declares a single variable of integral or
> enumeration type, ranged or not. The loop will iterate over the
> range of the variable, and the variable is considered const in
> the loop. Eg.,
>  for (char c) // loop over all characters
>  for (lc c) // loop over lower-case letters
>  enum e { a = 7, b = 3, c = 7 };
>  for (e x) // loop three times: x = 7, x = 3, x = 7

The last probably should read: x=a(=c), x=b, x=c(=a)

After all, an e is not a number.

BTW, whemn already extending for, what about making it know about the
iterator idiom? For example, one could make the code

  for (iter = v.begin(); v.end())
  {
    ...
  }

equivalent to

  for (typeof(v.begin()) iter = v.begin, __end = v.end();
       __ifhaslessthen(iter < __end, iter != __end);
       ++iter)
  {
    __make_const_in_local_scope(iter);
    ...
  }

Note that this would also allow more concise loop syntax for "normal"
loops:

  for (i = 0; n)
  {
    ...
  }

Also by making sure the loop variable cannot be changed from inside
the loop (changing it via const_cast could be made undefined
behaviour), it might help the compiler optimizing code like this:

  void f(int const&);

  for (int i=0; i<100; ++i)
  {
    f(i); // may legally change i through const_cast !
    // do more
  }

  for (i=0; 100)
  {
    f(i); // would be disallowed changing i
    // do more
  }

[...]

---
[ 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 <86u1osy1d7.fsf@alex.gabi-soft.de>, James Kanze
> <kanze@alex.gabi-soft.de> writes
>
>> In practice, given the situation on the ground, if Boost covers the
>> issue, I suspect that alternatives will have a much more difficult
>> time of it.  But I doubt that that is an absolute.
>
>
> I might put it another way, if Boost is not interested then those on
> WG21 are not likely to be (note, I wrote 'likely) and if WG21 is
> interested Boost will probably work on a design/implementation.


   I might put it another way: The Library Working Group & WG21 & J16 must judge
each entrant library unbiasedly unprejudicedly based on that library's merits &
deficiencies regardless of whether that library was enterred into the
competition by Boost or by any other person or organization.

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

"Christopher Eltschka" <celtschk@web.de> wrote in message
news:ad0n4d$kj6$1@news.tuwien.ac.at...
> I'd like to be able to avoid certain operators. For example, I'd like
> to be able to do
>
>   typedef new double Temperature;
>
> and disallow multiplication of two temperatures (whatever that product
> may be, it's for sure not a temperature).

You could just allow operator overloading for strong typedefs of built-in-types.
You could then disable an operator with absolute granularity:

Temperature operator*(Temperature, Temperature); // no definition

inline Temperature operator+(Temperature lhs, Temperature rhs) {
    return static_cast<double>(lhs) + static_cast<double>(rhs);
}

Paul Mensonides

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

Christopher Eltschka wrote:
> I'd like to be able to avoid certain operators. For example, I'd like
> to be able to do
>
>   typedef new double Temperature;
>
> and disallow multiplication of two temperatures (whatever that product
> may be, it's for sure not a temperature).

This gets into units, which is a whole other kettle of fish.
Ada actually has a way to do what you ask, which is to say

    function "*"(a, b : Temp) return Temp is abstract;

Such abstract operators then do not participate in overload
resolution, effectively removing the operation from existence.
I don't know how important this is to C++; units can already
be handled very effectively using Barton & Nackman's techniques
from _Scientific and Engineering C++_, gussied up even more with
member templates, which they didn't have.

> BTW, whemn already extending for, what about making it know about the
> iterator idiom?
>
>   for (iter = v.begin(); v.end())
>   for (i = 0; n)

Nope, don't like this at all.

---
[ 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> writes:

|>  In article <3CF1EF58.1060301@yahoo.com>, David Rasmussen
|>  <pinkfloydhomer@yahoo.com> writes
|>  > The good thing about a garbage collector for C++, is that one
|>  > can start with just using the garbage collector, which _is_
|>  > simpler, and less error-prone. Then, if it turns out to be a
|>  > hotspot or a bottleneck, you could turn to manual
|>  > destruction. Also, garbage collection in conjunction with manual
|>  > destruction can be used for finding memory leaks and other
|>  > bugs. Research shows that for most applications, garbage
|>  > collection isn't a performance problem at all. The myths of the
|>  > garbage collector halting the application for seconds, were true
|>  > 10-20 years ago, but seldom today, unless your application is
|>  > non-typical.

|>  True, but so is the myth that it is necessary to do manual
|>  resource management in C++. A competent programmer knows how to
|>  avoid explicit calls to delete except inside properly designed
|>  components.  Learning to do that gets you much more than memory
|>  management.

But it still means more work (and more chance for errors) when you
don't need more than memory management.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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 <m3znymzxqh.fsf@merlin.nerim.net>, Gabriel Dos Reis
<gdr@codesourcery.com> writes
>"Tom Puverle" <tp225@cam.ac.uk> writes:
>
>> In response to some of the posts here, can I ask this:
>> Could people indicate whether or not they would find it desirable if C++ had
>> automatic garbage collection. Just a little poll, nothing more.
>
>Making use of a garbage collector *optional* is one the item I've been
>seeing on wishlist of some influencal members of the C++ standards
>committee.

More precisely, providing an optional mechanism that will allow
compilers to reject code that is unsave in a GC environment. For
example, converting integer types to pointers (because that allows
programmers to use idioms that hide pointers)

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

Steve Heller wrote:
> Howard Gardner <usenet@hgardner.com> wrote:
>>The problem would go away if the following worked.
>>
>>// Realizes the interface using Implementation_One
>>struct Realization_One
>>:
>>  public Abstract,
>>  using Implementation_One
>>{
>>};
>>
>>// Realizes the interface using Implementation_Two
>>struct Realization_Two
>>:
>>  public Abstract,
>>  using Implementation_Two
>>{
>>};
>>
>>int main(void)
>>{
>>  Realization_One r_1;
>>  Realization_Two r_2;
>>
>>  r_1.function(); // Calls Implementation_One::function
>>  r_2.function(); // Calls Implementation_Two::function
>>
>>  return 0;
>>}
>>It's very approachable.
>>
>>Most people are surprised and disappointed that there's no way to do it
>>now, short of typing the forwarding functions.
>
>
>   Yes, that is a disappointing aspect of C++. I'm glad to see that my
> proposal is so easily used to improve the usability of the language in
> ways I hadn't foreseen. Isn't that the mark of a good idea?
>

I think it's a great idea, especially if it works like this. I wonder if
it would be difficult for compiler writers to implement. Any compiler
writers following this thread?

--
I <3 Comeau C++: http://www.comeaucomputing.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                       ]

Jean-Marc Bourguet <jm@bourguet.org> writes:

|>  James Kanze <kanze@alex.gabi-soft.de> writes:

|>  [about garbage collection]
|>  > You should always start with a design, and the lifetime of an
|>  > object is an element of that design, and should be resolved
|>  > according to the design, before you start coding.

|>  > Where garbage collection comes in is much later, when you start
|>  > coding.  Using an existing garbage collection is a magnitude of
|>  > order easier and less error prone when used to *implement* the
|>  > design, when appropriate.

|>  I agree but I want to point out that if you know that a garbage
|>  collection is available, the design space is greater.

Maybe.

|>  For example, if I know that a garbage collector is available, I
|>  may use a data structure with shared ownership and cyclic
|>  references.  If no garbage collector is available, I'll probably
|>  try to break the cyclic references or not use the shared
|>  ownership, even if that imply a more complicated design.

I think we agree, sort of.  The choice of which smart pointer(s) to
use, and how to break the cycle, is IMHO an implementation, or at the
most a very low level design choice.  I've designed cyclic structures
fully knowing that I had to implement them in C++, without garbage
collection.  In that sense, it doesn't affect design.  On the other
hand, knowing that the implementation may be more difficult could
affect my design decisions.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

John Nagle:
>     Some assistance on the storage management front is useful,
> but garbage collection and destructors don't play well together.
> The semantics get wierd.  Look at Microsoft's "managed storage"
> system for C++.  Painful.
>
> A destructor is not a finalizer, and vice
> versa.
>
>     GC works better with Java semantics.

What's the problem? As far as I understand it the
golden rule is not to touch any GC pointers in a
destructor. If you follow that simple rule, there is
no problem.

As far as I know the same is true in Java and C#.
(Although I've heard it said that Java doesn't always
call finalizers which is worrying if true, but in my
experience fans of one language tend to overstate
the problems of other languages. When people say
Java leaks memory I confess that baffles me too.)

By the way, I'd be in favour of an optional GC in C++ -
one that could co-operate with other memory management
systems in the same program. I see it more as a library
feature which would benefit from some core language
tweaks. I don't think there is any chance of a monolithic
Java or C#-type GC being adopted as standard. And I
think creating an efficient non-monolithic type of GC is
an enormous challenge.

People looking for a C++ GC system shouldn't overlook
boost::shared_ptr. It can't easily cope with cyclic references
(although at a pinch there are various ways to break
the cycle) but if you can live with that limitation it may do
everything you want.

As for destructors != finalizers, I think the existance of
increasingly GC-like smart pointers in C++ means the
line is now very blurred. I'm not sure it is a useful
distinction any more.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---
[ 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@alex.gabi-soft.de> wrote in
news:86lma4xzge.fsf@alex.gabi-soft.de:

> Dan Smart <cppdan@dansmart.com> writes:
>
>|>  Of course memory leaks in Java are impossible. Which means the
>|>  leaks in Swing don't exist. Java makes threading easy and
>|>  safe. Amazingly slow, but safe and easy. Garbage collection is
>|>  less of an overhead than managing memory manually. Please ignore
>|>  the 15 second pauses in execution.
>
> Let's stick to the facts.
>
Indeed, amazingly slow is exageration, but...
> Java's threading isn't any slower than anyone else's.  Writing thread
> safe programs is more difficult than writing single threaded programs.
> Regardless of whether the language is Java or C++.
By attempting to make multi-threading easy, Java is slower than it needs to
be. Way to many things in Java are sychronized, when as a developer I know
that they are going to be protected by higher level synchronization.
Acquiring an uncontested mutex can be made extremely low cost, but it will
never be free. There is a lot of talk about how in the future optimizing
compilers will be able to eliminate extraneous synchronization, but this is
non-trivial. It is worth noting that GC as implemented by Java also implies
a synchronization overhead (and it is difficult to see how it could be
otherwise).
I have also been reliably informed that thread context switches in Java are
more expensive than in C++.

>  What is happening
> is that a lot of applications in Java are multithreaded when they
> shouldn't be, because it is much more difficult to avoid threading in
> Java.
>
True. In fact Java encourages the view that multi-threading is easy and a
global panacea. Swing should be an event driven architecture, but isn't.

> And all of the real benchmarks I've seen concerning garbage collection
> in C++ have shown it to be as fast, if not faster, than manual memory
> management.
My comment was about GC in Java. What I want to see in C++ is
standardisation of GC hooks, rather than GC. I want the enabling
technology. GC (like memory allocation itself) involves numerous trade-
offs. GC systems that can move objects can destroy locality of reference,
on the other hand GC systems that can't move objects suffer badly from
fragmentation in the presence of objects with wildly differing lifespans.
No one GC algorithm is appropiate to all problem domains, and all have
costs (frequently significant costs) when used in an inappropiate domain.

>  It's been years since I've seen pauses in execution due
> to garbage collection (in Emacs, at any rate), and the difference
> isn't just due to improved processor speed.
>
I frequently see pauses in execution in Emacs (and XEmacs) due to GC.
And Emacs is a simple case, as it is single threaded. My comment about 15
second pauses is not hyperbole, I've seen it in 1.2 JVM's, and it is
relatively easy to provoke. It is much harder to provoke significant delays
in 1.3 JVM's, but not impossible.

>|>  Proof please. It is as easy to say that every day thousands of
>|>  programs and systems crash because the programmers were taking
>|>  hard drugs. This is of course unecessary and irresponsible.
>
> Well, there are a lot of programs that crash.  Think of the Ariane,
> for example.  Of course, that program was written in Ada.  But I'm
> sure that the crash would also have occured if the program had been
> written in C++.  To date, I know of no language which can do anything
> about faulty management.
My point.
>
> This is a point that I can't stress enough.  If your organization
> cannot write robust, reliable software in C++, then it can't write it
> in Java, nor in Ada, nor in any other language.  This isn't to say
> that all languages are equal, or that C++ cannot be improved upon --
> if your organization can write robust software in C++, it might be
> able to write it more cheaply in Ada, of some other language
> (depending on the application domain and hundreds of other factors, of
> course).  But writing robust software is first and foremost a question
> of good engineering, and that is independant of the language.
>
I left this in because I agree 110%.

>|>  There are things in C++ that need fixing, although strangely
>|>  garbage collection is not actually on my list. My list is:
>|>  Elimination of C style casts.
>|>  Strong typedefs.
>|>  Rationalisation of template syntax.
>|>  A decent low level thread library, just the primitives thanks.
>|>  Closed namespaces.
>|>  In place initialisation of non-int const static members.
>
>|>  I'd like the interfaces to parts of the STL tidied up as well, but
>|>  it isn't going to happen unfortunately (what is the difference
>|>  between list.empty() and list.clear() ?).
>
> IMHO, right now, the most important thing that needs fixing in C++ is
> the compilers.  So that I can write code that will continue to work
> with the next version.
>
Agreed, and before I want any effort expended of GC, I'd like O/S and
compiler vendors to fix plain simple memory allocation so that it is not a
significant bottleneck for multi-threaded programs. SmartHeap/hoard etc has
proved it can be done.

Dan "who likes violent agreement" Smart


--
Dan Smart. C++ Programming and Mentoring.
cppdan@dansmart.com
ADDvantaged

---
[ 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 <BWAI8.1060$h74.107861139@newssvr14.news.prodigy.com>, Mike
Schilling <mscottschilling@hotmail.com> writes
>I find it interesting that C++ problems can be dismissed with "No one
>knowledgeable would do that", while Java problems caused by lack of
>expertise are a fatal flaw.

No, it is the Java experts who say that fixing memory leaks is hard or
at least that is what some have told me.

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

In article <3CF3E5CE.2010809@tellabs.com>, Daniel Miller
<daniel.miller@tellabs.com> writes
>  I might put it another way: The Library Working Group & WG21 & J16
>must judge each entrant library unbiasedly unprejudicedly based on that
>library's merits & deficiencies regardless of whether that library was
>enterred into the competition by Boost or by any other person or
>organization.

The very large majority of those on the LWG are also members of Boost,
they are also human beings. The result is that most things they might
consider for the Standard Library will be implemented by Boost, if only
as proof of concept.

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

Francis Glassborow wrote:

>> In article <86u1osy1d7.fsf@alex.gabi-soft.de>, James Kanze
>> <kanze@alex.gabi-soft.de> writes
>>
>>> In practice, given the situation on the ground, if Boost covers the
>>> issue, I suspect that alternatives will have a much more difficult
>>> time of it.  But I doubt that that is an absolute.

 >

> In article <3CF3E5CE.2010809@tellabs.com>, Daniel Miller
> <daniel.miller@tellabs.com> writes
>
>>  I might put it another way: The Library Working Group & WG21 & J16
>> must judge each entrant library unbiasedly unprejudicedly based on
>> that library's merits & deficiencies regardless of whether that
>> library was enterred into the competition by Boost or by any other
>> person or organization.
>
>
> The very large majority of those on the LWG are also members of Boost,
> they are also human beings. The result is that most things they might
> consider for the Standard Library will be implemented by Boost, if only
> as proof of concept.


   On this branch of this thread there have been multiple opportunities for LWG
members to deny that there is some sort of predetermined manifest destiny for
fast-track standardization of certain Boost libraries.

   I had expected that a few such statements of balance & fairness & equitable
consideration of nonBoost libraries for standardization would have been posted.

   Instead so far I see statements in postings which indicate that Boost would
in fact receive some form of preferrential treatment over competing entrants in
the competition for standardization.  So far this has been a missed opportunity
for LWG members to deny preferential treatment of Boost libraries over would-be
competitors.

---
[ 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 <1022575240.2674.0.nnrp-14.3e31ffea@news.demon.co.uk>, Ken
Hagan <K.Hagan@thermoteknix.co.uk> writes
>Either way, the novices will carry on writing duff code if they want to.
>A better measure for a feature is whether it helps experts avoid errors.
>An expert, in this context, is anyone whose desire to write good code
>has driven them to read some of the books that discuss the various gotchas
>and how to avoid them.

And can we easily teach well motivated students to avoid the problem.
Complicated solutions are only acceptable until simpler ones become
available. However in many cases the right way to do it is no more
complicated than the wrong way (like use vector for dynamically sized
arrays)

>

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

Francis Glassborow wrote:

>
> More precisely, providing an optional mechanism that will allow
> compilers to reject code that is unsave in a GC environment. For
> example, converting integer types to pointers (because that allows
> programmers to use idioms that hide pointers)
>

Does use of a union eliminate the need for this conversion, or is there a
case unions cannot handle (I don't ever do this kind of stuff, so I have no
idea what programmers who do it need)?

--
Brad Settlemyer
http://deepcopy.org/
Progamming in the trenches

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

Christopher Eltschka wrote:
>
> I'd like to be able to avoid certain operators. For example, I'd like
> to be able to do
>
>   typedef new double Temperature;
>
> and disallow multiplication of two temperatures (whatever that product
> may be, it's for sure not a temperature).
>
> Maybe one can define groups of operators, such as logical, additive,
> multiplicative, etc., and on definition of the new type tell which
> group should be inherited by the new type.
>
> For example, the variable Temperature could be declared as
>
>   typedef new[std::additive] double Temperature;
>
> where std::additive is an operator group containing operator+ and
> operator- (both unary and binary) for the new type (and maybe
> multiplication with the old type, in this example double). Ideally,
> one could define such operator groups oneself (with the most often
> used predefined in std).

If you're thinking of going that far, why don't you just make
Temperature a class? You already have enough to do it.

--
Sungbom Kim <musiphil@bawi.org>

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

Daniel Miller wrote:
>
>    Instead so far I see statements in postings which indicate that
Boost would
> in fact receive some form of preferrential treatment over competing
entrants in
> the competition for standardization.

That was more or less the whole point of Boost. I don't understand why
you see it as a bad thing.

--
Ross Smith ...................................... Auckland, New Zealand
r-smith@ihug.co.nz ....................................................
       "...and to destroy the earth, type 'make destroy_earth'"
                                            -- ClanLib makefile

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

Ross Smith <r-smith@ihug.co.nz> writes:

|>  Tom Puverle wrote:

|>  > In response to some of the posts here, can I ask this: Could
|>  > people indicate whether or not they would find it desirable if
|>  > C++ had automatic garbage collection. Just a little poll,
|>  > nothing more.

|>  Absolutely not. It would break RAII, and that would be the end of
|>  the world.

Could you please explain how it would break RAII.  RAII generally uses
local variables, which would be unchanged by garbage collection.

|>  The whole concept of garbage collection is a massive technological
|>  dead end that far too many people have wasted their time on. The
|>  absence of GC is one of C++'s greatest strengths.

This doubtlessly explains why practically all new languages include
garbage collection, and many of the best C++ experts I know favor it
in some form or another.

|>  As far as I know, C++ is the _only_ language -- certainly the only
|>  widely used one -- that has deterministic destructors. Doing away
|>  with that would drop the number of languages in which it's
|>  possible to do reliable resource management from one to zero.

No one is proposing doing away with deterministic destructors.  When a
local variable goes out of scope, its destructor is called.  When you
invoke delete on a pointer, the destructor of the pointed to object is
called.  And on exit, the destructors of the static objects are
called, in the reverse order of construction.

But I fail to see what any of this has to do with garbage collection.

--
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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> writes:

|>  In article <86u1osy1d7.fsf@alex.gabi-soft.de>, James Kanze
|>  <kanze@alex.gabi-soft.de> writes
|>  >In practice, given the situation on the ground, if Boost covers
|>  >the issue, I suspect that alternatives will have a much more
|>  >difficult time of it.  But I doubt that that is an absolute.

|>  I might put it another way, if Boost is not interested then those
|>  on WG21 are not likely to be (note, I wrote 'likely) and if WG21
|>  is interested Boost will probably work on a design/implementation.

I wouldn't go that far.  Suppose, for example, that Boost isn't
interested because they think that an already existing solution is
possible.  For that matter, the people I know at Boost aren't so
sectarian as to think that they are the only source of good ideas.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

Daniel Miller <daniel.miller@tellabs.com> writes:

|>  Francis Glassborow wrote:

|>  >> In article <86u1osy1d7.fsf@alex.gabi-soft.de>, James Kanze
|>  >> <kanze@alex.gabi-soft.de> writes
|>  >>> In practice, given the situation on the ground, if Boost
|>  >>> covers the issue, I suspect that alternatives will have a much
|>  >>> more difficult time of it.  But I doubt that that is an
|>  >>> absolute.

|>  > In article <3CF3E5CE.2010809@tellabs.com>, Daniel Miller
|>  > <daniel.miller@tellabs.com> writes
|>  >>  I might put it another way: The Library Working Group & WG21 &
|>  >> J16 must judge each entrant library unbiasedly unprejudicedly
|>  >> based on that library's merits & deficiencies regardless of
|>  >> whether that library was enterred into the competition by Boost
|>  >> or by any other person or organization.

|>  > The very large majority of those on the LWG are also members of
|>  > Boost, they are also human beings. The result is that most
|>  > things they might consider for the Standard Library will be
|>  > implemented by Boost, if only as proof of concept.

|>     On this branch of this thread there have been multiple
|>  opportunities for LWG members to deny that there is some sort of
|>  predetermined manifest destiny for fast-track standardization of
|>  certain Boost libraries.

Why should they deny something that no one has claimed, and that is
self evident?  ISO sets the rules, and those rules will be followed.
There is no fast-track standardization of anything as far as C++ is
concerned.

|>     I had expected that a few such statements of balance & fairness
|>  & equitable consideration of nonBoost libraries for
|>  standardization would have been posted.

No need for statements.  That's the way the ISO process works.

Obviously, human considerations are involved -- a random proposal from
John Doe will probably not have the same chance as a proposal from
members of the working group.  Not because of any formal bias, but
it's pretty sure that he is aware of exactly what is needed to
convince the committee, and he is there to answer any questions.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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 <F%YI8.4463$ib4.227505@news1.east.cox.net>, Brad Settlemyer
<bws_news@deepcopy_remove_.org> writes
>Francis Glassborow wrote:
>
>>
>> More precisely, providing an optional mechanism that will allow
>> compilers to reject code that is unsave in a GC environment. For
>> example, converting integer types to pointers (because that allows
>> programmers to use idioms that hide pointers)
>>
>
>Does use of a union eliminate the need for this conversion, or is there a
>case unions cannot handle (I don't ever do this kind of stuff, so I have no
>idea what programmers who do it need)?

How will that cure the problem? I store a pointer in a union, extract it
as an array of unsigned char and once again GC has potential problems.
For GC to efficiently work you must not hide pointers. This is so easy
to do that some language support is probably desirable.

--
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" <kanze@alex.gabi-soft.de> wrote ...
>
> "Markus Mauhart" <markus.mauhart@chello.at> writes:
>
> |>  "James Kanze" <kanze@alex.gabi-soft.de> wrote ...
>
> |>  > I've about had it with untried experiments.)
>
> |>  Btw, what about your efforts to understand/use/reimplement
> |>  streams, strings, and locales ?-)
>
> It's about so-so for the moment.  I'm still very much at the
> experimentation phase, which means that most of what I do, I end up
> redoing when I try to extend it, because I find that I've done it
> wrong.

So I'm looking foreward for your further contributions on this
issues, cause IMHO there is a need for hard earned expertise
to get improvements here.



---
[ 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 <1022575240.2674.0.nnrp-14.3e31ffea@news.demon.co.uk>, Ken
> Hagan <K.Hagan@thermoteknix.co.uk> writes
>
>> Either way, the novices will carry on writing duff code if they want to.
>> A better measure for a feature is whether it helps experts avoid errors.
>> An expert, in this context, is anyone whose desire to write good code
>> has driven them to read some of the books that discuss the various
>> gotchas
>> and how to avoid them.
>
>
> And can we easily teach well motivated students to avoid the problem.
> Complicated solutions are only acceptable until simpler ones become
> available. However in many cases the right way to do it is no more
> complicated than the wrong way (like use vector for dynamically sized
> arrays)

But the point is that some conceptually really simple things are hard to
express in C++. It can be done by experts, but will be very elaborate.
There are obvious simpler ways of doing it, so what's the problem? What
do get for _not_ adding such features?

Examples:

If you want strong enums, you can probably do them with a class, but
what is benefit of not having a simple way of doing it?

The general case of limiting built-in types. Many obvious concepts (that
is, would-be types) are directly derived from built-in types. Sometimes
you want an integer type that can only hold values from 0 to 42.
Sometimes you want a floating point type without multiplication. And
often you want these types to be strong, and not have any relationship
with their ancestor types. Sometimes you want strong enums. Ada has
great built-in support for all these kinds of things, which helps
optimization, but more importantly it reduces bugs and compared to C++,
it makes development time shorter. Why shouldn't C++ have such features?
These are very simple conceptual things. The more properties the
programmer is able to express and specify from the domain and the
design, the better. In a huge amount of naturally occuring problems, you
really want the kind of types that were mentioned above. But in C++ you
either go with the underspecified (use a plain float for a temperature,
or a plain int for indexing a chessboard with only values 0..63 making
sense etc.) or you go out of your way to make a class that does sort of
the same thing. Give the programmer as much expressibility and the power
to precisely specify what he needs. These are _basic_ language features,
not complex ones. They were in Ada over 20 years ago.

/David

---
[ 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 Hagan" <K.Hagan@thermoteknix.co.uk> writes:

|>  "John Nagle" <nagle@animats.com> wrote...
|>  >      Every day, thousands of programs and systems crash because
|>  > C++ hasn't fixed this problem.  This is unnecessary, and perhaps
|>  > irresponsible.

|>  In contrast, the Java and C# programs bash on and give the wrong
|>  answer. I assume we are running these programs on a proper
|>  operating system, so it hardly matters whether we crash or write
|>  garbage results.

Actually, it matters a lot.  I've never heard of anyone making a
business decision on the basis of a core dump, but a business decision
on the basis of wrong answers could be very expensive.

The problem isn't that C++ might core dump.  The problem is that all
too often, it just gives a wrong answer as well.  In some cases
(bounds error on an array, for example), where Java might stop
(although not necessarily -- some of the basic librarys catch and drop
exceptions).

|>  In both cases the user loses their data.

|>  The cause in both cases is poor programming. The choice of
|>  language only alters how the poor programming manifests
|>  itself. There's not much that compilers can, or should, do about
|>  poor programming, but other tools can perform deeper analysis
|>  (either static or dynamic) if only programmers could be persuaded
|>  to use them.

Much of the "deeper analysis" necessary to catch undefined behavior
(in C++) could also be used to improve optimization.  I suspect that
the long term evolution will be in this direction.  I don't think it
will happen tomorrow, but what I'd like to see is bounds checking
replaced by a static check; if there is *any* path by which an array
bounds error can occur, the compiler will tell you.  (Obviously, the
won't work for totally separate compilation.)

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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> writes:

|>  In article <m3znymzxqh.fsf@merlin.nerim.net>, Gabriel Dos Reis
|>  <gdr@codesourcery.com> writes
|>  >"Tom Puverle" <tp225@cam.ac.uk> writes:

|>  >> In response to some of the posts here, can I ask this: Could
|>  >> people indicate whether or not they would find it desirable if
|>  >> C++ had automatic garbage collection. Just a little poll,
|>  >> nothing more.

|>  >Making use of a garbage collector *optional* is one the item I've
|>  >been seeing on wishlist of some influencal members of the C++
|>  >standards committee.

|>  More precisely, providing an optional mechanism that will allow
|>  compilers to reject code that is unsave in a GC environment. For
|>  example, converting integer types to pointers (because that allows
|>  programmers to use idioms that hide pointers)

Is that just on a wish list, or was that a concrete proposal.

(And BTW: for various reasons, C++ must continue to support the
conversion of integers to pointers.  You might be able to ban the
reverse, but I think that the only real requirements are statements
with regards to what you can do with those int's, or maybe the
requirement that at least one actual pointer remain in scope.)

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

Brad Settlemyer <bws_news@deepcopy_remove_.org> writes:

|>  Francis Glassborow wrote:

|>  > More precisely, providing an optional mechanism that will allow
|>  > compilers to reject code that is unsave in a GC environment. For
|>  > example, converting integer types to pointers (because that
|>  > allows programmers to use idioms that hide pointers)

|>  Does use of a union eliminate the need for this conversion, or is
|>  there a case unions cannot handle (I don't ever do this kind of
|>  stuff, so I have no idea what programmers who do it need)?

There are two real uses that I've seen, and I don't think that unions
should be required for either.

The first is addressing memory mapped IO -- the IO ports are at fixed
addresses, so you typically want to do something like:

    *static_cast< unsigned char* >( 0xffffffe0 ) =3D 0x21 ;

This doesn't bother garbage collection (the address 0xffffffe0 doesn't
interest garbage collection), and I would not like it being removed
from the language, even if 99% of the applications never need it (or
can't even use it, because such things don't work in user mode under
Unix, Windows, or any other real multi-user OS).

The other case I've seen is a space optimization -- in contexts where
addresses must be aligned, the bit 0 of the actual address is known to
be 0, so the bit can be used as a boolean in the pointer.  This
requires some very non-transparent programming, but with the help of
inline functions, etc., it can be made fairly readable.  And there are
cases where it can be more than useful -- implementing garbage
collection comes to mind.  I can't really see it being used above
garbage collection, but at least with the garbage collectors I know
of, it doesn't cause a problem anyway.

What must be banned, of course, is loosing all addresses into the
object.  Writing the address to disk (or to another process), then
reading it later, is currently guaranteed to work, even if no actual
copies of the address remain in memory in the meantime.  As is
memcpy'ing it to an array of char and encrypting it.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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:
> More precisely, providing an optional mechanism that will allow
> compilers to reject code that is unsave in a GC environment. For
> example, converting integer types to pointers (because that allows
> programmers to use idioms that hide pointers)

I see a C++ GC system being implemented with
smart pointers (probably with some core tweaks
behind the scenes). There will be the usual tension
between flexibility of use and safety that we always get
with smart pointers, but whatever compromise is decided
upon will be enforced by the smart pointer interface. It
would be very much in the spirit of C++ to allow the
programmer to shoot themselves in the foot if they
really want to, but to use the interface design to make
it as difficult as possible. For example, we would
probably have to provide a get() member function to
return the raw pointer, but we wouldn't provide an
implicit conversion.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

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

"Daniel Miller" <daniel.miller@tellabs.com> wrote in message
news:3CF408F6.3000908@tellabs.com...


>    On this branch of this thread there have been multiple opportunities
for LWG
> members to deny that there is some sort of predetermined manifest destiny
for
> fast-track standardization of certain Boost libraries.

Please consider it denied.



---
[ 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 <3CF4A2C2.7050504@yahoo.com>, David Rasmussen
<pinkfloydhomer@yahoo.com> writes
>But the point is that some conceptually really simple things are hard
>to express in C++. It can be done by experts, but will be very
>elaborate. There are obvious simpler ways of doing it, so what's the
>problem? What do get for _not_ adding such features?

Why do you assume that those of us working on the evolution of C++ are
going to ignore the desirability of making things simpler where that can
be done without much cost. I think what you call strong enums are a bad
example because whatever that may mean can be provided fairly simply
within the current language, they are just not provided by the keyword
enum.


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

On Tue, 28 May 2002, Daniel Miller wrote:
>
>    On this branch of this thread there have been multiple opportunities for LWG
> members to deny that there is some sort of predetermined manifest destiny for
> fast-track standardization of certain Boost libraries.
>
>    I had expected that a few such statements of balance & fairness & equitable
> consideration of nonBoost libraries for standardization would have been posted.
>
>    Instead so far I see statements in postings which indicate that Boost would
> in fact receive some form of preferrential treatment over competing entrants in
> the competition for standardization.  So far this has been a missed opportunity
> for LWG members to deny preferential treatment of Boost libraries over would-be
> competitors.

A Boost proposal typically brings to the table
- a problem statement,
- a complete specification, syntax and semantics,
- a working implementation,
- anecdotal evidence of its utility.

And I mean "brings to the table" quite literally:  The proposal is
accompanied by one or more persons present at the meeting who can
speak knowledgeably about the proposal and answer questions.

A proposal with those properties from any source would receive
equal consideration.

A proposal (from any source, including Boost) failing in any of these
elements would require that some Committee member take on the proposal
as a personal project to see that the missing parts are provided.

I'd also like to point out that some Boost proposals have been rejected
on various grounds.

Boost does not have an "inside track" in the sense of being preferred
over other submitters. But Boost submitters do enough work before
submitting a proposal to ensure that the proposal will be reviewed.

--
Steve Clamage, stephen.clamage@sun.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 <86hekqt1kf.fsf@alex.gabi-soft.de>, James Kanze
<kanze@alex.gabi-soft.de> writes
>|>  More precisely, providing an optional mechanism that will allow
>|>  compilers to reject code that is unsave in a GC environment. For
>|>  example, converting integer types to pointers (because that allows
>|>  programmers to use idioms that hide pointers)
>
>Is that just on a wish list, or was that a concrete proposal.
>
>(And BTW: for various reasons, C++ must continue to support the
>conversion of integers to pointers.  You might be able to ban the
>reverse, but I think that the only real requirements are statements
>with regards to what you can do with those int's, or maybe the
>requirement that at least one actual pointer remain in scope.)

As I recall the idea was to provide a standard mechanism whereby the
programmer could state that he was intending his code to use GC

--
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 <kanze@alex.gabi-soft.de> writes:

[...]

| The first is addressing memory mapped IO -- the IO ports are at fixed
| addresses, so you typically want to do something like:
|
|     *static_cast< unsigned char* >( 0xffffffe0 ) = 0x21 ;
|
| This doesn't bother garbage collection (the address 0xffffffe0 doesn't
| interest garbage collection), and I would not like it being removed
| from the language, even if 99% of the applications never need it (or
| can't even use it, because such things don't work in user mode under
| Unix, Windows, or any other real multi-user OS).

I didn't see any wording to remove the above feature from the language.

If I recall correctly, the idea was to have a GC and being able to
register specific objects as GC-able.  Naturally, some restrictions
will be imposed of the sort of things you can do with the addresses of
such objects.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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> writes:

|>  In article <3CF3E5CE.2010809@tellabs.com>, Daniel Miller
|>  <daniel.miller@tellabs.com> writes
|>  >  I might put it another way: The Library Working Group & WG21 &
|>  > J16 must judge each entrant library unbiasedly unprejudicedly
|>  > based on that library's merits & deficiencies regardless of
|>  > whether that library was enterred into the competition by Boost
|>  > or by any other person or organization.

|>  The very large majority of those on the LWG are also members of
|>  Boost, they are also human beings. The result is that most things
|>  they might consider for the Standard Library will be implemented
|>  by Boost, if only as proof of concept.

Maybe.  More importantly, perhaps, they will already be aware of many
of the arguments for and against before the proposal is made.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

"Ross Smith" <r-smith@ihug.co.nz> wrote in message
news:ad24ic$i92$1@lust.ihug.co.nz...
> Daniel Miller wrote:
> >
> >    Instead so far I see statements in postings which indicate that
> Boost would
> > in fact receive some form of preferrential treatment over competing
> entrants in
> > the competition for standardization.
>
> That was more or less the whole point of Boost. I don't understand why
> you see it as a bad thing.

Sorry, I can't tell precisely what meaning was intended above, but just to
be clear: the point of Boost was never to get preferrential treatment "over
competing entrants in the competition" for standardization. The point of
Boost with respect to the standard is/was always to make sure that some
libraries appropriate for standardization would exist *at all*. In fact, the
field of candidate libraries is so small that there's little or no
opportunity for actual competition.

-Dave



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

Dan Smart <cppdan@dansmart.com> writes:

|>  James Kanze <kanze@alex.gabi-soft.de> wrote in
|>  news:86lma4xzge.fsf@alex.gabi-soft.de:

|>  > Dan Smart <cppdan@dansmart.com> writes:

|>  >|>  Of course memory leaks in Java are impossible. Which means
|>  >|>  the leaks in Swing don't exist. Java makes threading easy and
|>  >|>  safe. Amazingly slow, but safe and easy. Garbage collection
|>  >|>  is less of an overhead than managing memory manually. Please
|>  >|>  ignore the 15 second pauses in execution.

|>  > Let's stick to the facts. =20

|>  Indeed, amazingly slow is exageration, but...

|>  > Java's threading isn't any slower than anyone else's.  Writing
|>  > thread safe programs is more difficult than writing single
|>  > threaded programs.  Regardless of whether the language is Java
|>  > or C++.

|>  By attempting to make multi-threading easy, Java is slower than it
|>  needs to be. Way to many things in Java are sychronized, when as a
|>  developer I know that they are going to be protected by higher
|>  level synchronization.  Acquiring an uncontested mutex can be made
|>  extremely low cost, but it will never be free. There is a lot of
|>  talk about how in the future optimizing compilers will be able to
|>  eliminate extraneous synchronization, but this is non-trivial. It
|>  is worth noting that GC as implemented by Java also implies a
|>  synchronization overhead (and it is difficult to see how it could
|>  be otherwise).

OK.  This is a library issue, not a language issue.  And the Javaites
seem to have learned -- Swing and Collections don't have the problem,
although AWT and the earlier containers did.

|>  I have also been reliably informed that thread context switches in
|>  Java are more expensive than in C++.

That's possible.  But if you're context switching enough for it to
make a difference, you probably aren't using threads correctly anyway.

|>  >  What is happening is that a lot of applications in Java are
|>  > multithreaded when they shouldn't be, because it is much more
|>  > difficult to avoid threading in Java.

|>  True. In fact Java encourages the view that multi-threading is
|>  easy and a global panacea. Swing should be an event driven
|>  architecture, but isn't.

I'm not sure about Swing, but overall, the problem with Java isn't so
much the features, but the fact that the features are sold as a silver
bullet.  I'm very much in favor of garbage collection, but it
certainly doesn't mean that you can ignore lifetime of object issues.
There are certainly applications where threading is appropriate (and I
suspect that when GUI components become as slow as Swing's, a GUI is
one), but there are also a lot where it isn't.

|>  > And all of the real benchmarks I've seen concerning garbage
|>  > collection in C++ have shown it to be as fast, if not faster,
|>  > than manual memory management.

|>  My comment was about GC in Java.=20

I've not found it to be a particular problem with regards to
performance, even in Java.  But of course, supposing GC in C++, a high
quality implementation should make several different implementations
available, or at least make it possible to use different
implementations, just as is currently the case with malloc.

|>  What I want to see in C++ is standardisation of GC hooks, rather
|>  than GC. I want the enabling technology. GC (like memory
|>  allocation itself) involves numerous trade- offs. GC systems that
|>  can move objects can destroy locality of reference, on the other
|>  hand GC systems that can't move objects suffer badly from
|>  fragmentation in the presence of objects with wildly differing
|>  lifespans.  No one GC algorithm is appropiate to all problem
|>  domains, and all have costs (frequently significant costs) when
|>  used in an inappropiate domain.

|>  >  It's been years since I've seen pauses in execution due to
|>  > garbage collection (in Emacs, at any rate), and the difference
|>  > isn't just due to improved processor speed.

|>  I frequently see pauses in execution in Emacs (and XEmacs) due to
|>  GC.  And Emacs is a simple case, as it is single threaded.

What version are you using?  I've not looked at the source, but my
emacs is certainly capable of doing a number of things in parallel.
And it never pauses for garbage collection, at least not that I can
see.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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:YGjHIgK1y$88Ewaj@robinton.demon.co.uk...
> In article <3CF3E5CE.2010809@tellabs.com>, Daniel Miller
> <daniel.miller@tellabs.com> writes
> >  I might put it another way: The Library Working Group & WG21 & J16
> >must judge each entrant library unbiasedly unprejudicedly based on that
> >library's merits & deficiencies regardless of whether that library was
> >enterred into the competition by Boost or by any other person or
> >organization.
>
> The very large majority of those on the LWG are also members of Boost,
> they are also human beings. The result is that most things they might
> consider for the Standard Library will be implemented by Boost, if only
> as proof of concept.

Ehh, I wouldn't say that; we're also all busy human beings - there are a lot
more potentially useful library ideas out there than the Boost contributors
are able to code, document, review, approve, and maintain. Even if we happen
to dabble in some area it's a long way from a proof-of-concept to something
appropriate for standardization.

-Dave


---
[ 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:Zx73FmBRCK98EwB0@robinton.demon.co.uk...
> In article <F%YI8.4463$ib4.227505@news1.east.cox.net>, Brad Settlemyer
> <bws_news@deepcopy_remove_.org> writes
> >Francis Glassborow wrote:
> >
> >>
> >> More precisely, providing an optional mechanism that will allow
> >> compilers to reject code that is unsave in a GC environment. For
> >> example, converting integer types to pointers (because that allows
> >> programmers to use idioms that hide pointers)
> >>
> >
> >Does use of a union eliminate the need for this conversion, or is there a
> >case unions cannot handle (I don't ever do this kind of stuff, so I have
no
> >idea what programmers who do it need)?
>
> How will that cure the problem? I store a pointer in a union, extract it
> as an array of unsigned char and once again GC has potential problems.
> For GC to efficiently work you must not hide pointers. This is so easy
> to do that some language support is probably desirable.

I'm not sure this is a problem.  Hiding the pointer behind an int can be
viewed as simply a less safe "weak pointer" (less safe because there's no
convenient way to throw an exception when you try and convert it back to a
"strong pointer"), and we all know that "weak pointers" in GC systems are
useful.  Yes, it does leave room for abuse of the system, but I think many
of us could live with this simply resulting in undefined behavior if there
are no "strong pointers" left pointing to the allocated memory.

Bill Kempf

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

David Rasmussen wrote:
> If you want strong enums, you can probably do them with a class,
 > but what is benefit of not having a simple way of doing it?

I have a book written in the late 19th century arguing against the
adoption of the metric system in the US. The very valid point made
by the book is that although the metric system is conceptually
simpler, the English system would remain in place regardless, with
the net result of requiring that people learn twice as many obscure
conversions as before.

The benefit of not having a simple way to do it is having only one
way to do it, since the old way is here to stay.

> The general case of limiting built-in types.
 > Why shouldn't C++ have such features?

Because those features have to fit smoothly into the existing
language as a whole. For fundamental numeric types, this means
prowling through the entire standard to determine the effects
on various structures. Given that this feature is not essential
(after all C and C++ are successful languages which have never
had it), the only way it's going to get in is if someone really
motivated does the work.

Here are examples of the complexity involved. What is the effect
of ranged types on functions and templates? Does a ranged parameter
affect overloading? Can a template recover the range of a ranged
type parameter?

If you really want this, get out your copy of the standard
and start analyzing and designing.

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

"Markus Mauhart" <markus.mauhart@chello.at> writes:

|>  "James Kanze" <kanze@alex.gabi-soft.de> wrote ...

|>  > "Markus Mauhart" <markus.mauhart@chello.at> writes:

|>  > |>  "James Kanze" <kanze@alex.gabi-soft.de> wrote ...

|>  > |>  > I've about had it with untried experiments.)

|>  > |>  Btw, what about your efforts to understand/use/reimplement
|>  > |>  streams, strings, and locales ?-)

|>  > It's about so-so for the moment.  I'm still very much at the
|>  > experimentation phase, which means that most of what I do, I end
|>  > up redoing when I try to extend it, because I find that I've
|>  > done it wrong.

|>  So I'm looking foreward for your further contributions on this
|>  issues, cause IMHO there is a need for hard earned expertise to
|>  get improvements here.

Thanks.

There are in fact two problems.  The first is conceptually simple, but
is costing a lot of programming time, and that is getting everything
standards conform (when it isn't always very clear what the standard
requires).  The second is more difficult: I have a number of cases
where I represent sets of characters using a bit map.  It is obvious
that a bit map is NOT an appropriate representation when the domain
contains over a million elements -- each bit map would require more
that 128 K bytes.  But what is the appropriate representation?  For
the moment, I'm using a list of ranges.  But there are certain
functions, e.g. in my regular expression handling, that have become
inordinately slow.  I'm sure that they can be improved, doubtlessly by
using some knowledge of the representation, but that will take some
thinging to achieve. =20

The current implementation for char also uses some optimizations here.
For example, the iterators over my bitmap know that it is a bit map,
and scan bytes first, before trying to look at the individual bits.
In this case, the new representation actually works faster.  But in
the case of building the DFA for the regular expression, I just looped
over all of the possible characters.  After all, there are only 256 of
them, and this isn't normally a critical function.  Change 256 to over
a million, however, and things slow down very noticeably -- about 90
seconds to build a DFA which previously built in no perceivable time.

Anyhow, if anyone has any ideas about other representations, I'm all
ears.  If anyone has any ideas about how to speed up the regular
expression handling, I'm interested as well, but I suspect that you
would have to see the code to really be able to suggest something;
when the base classes are ready, I'll post the regular expression
parser as it is, and wait for suggestions.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design?
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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 <3CF4A2C2.7050504@yahoo.com>, David Rasmussen
> <pinkfloydhomer@yahoo.com> writes
>
>> But the point is that some conceptually really simple things are hard
>> to express in C++. It can be done by experts, but will be very
>> elaborate. There are obvious simpler ways of doing it, so what's the
>> problem? What do get for _not_ adding such features?
>
>
> Why do you assume that those of us working on the evolution of C++ are
> going to ignore the desirability of making things simpler where that can
> be done without much cost.

I don't assume it. I experience it.

> I think what you call strong enums are a bad
> example because whatever that may mean can be provided fairly simply
> within the current language, they are just not provided by the keyword
> enum.
>
>

How can they be implemented simply? In a lot of languages this is a
one-liner, because it maps to such a basic concept. In C++, it will take
many many lines.

/David

---
[ 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 response to some of the posts here, can I ask this:
Could people indicate whether or not they would find it desirable if C++ had
automatic garbage collection. Just a little poll, nothing more.
Thanks.


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

John Nagle <nagle@animats.com> wrote:

>Francis Glassborow wrote:
>
>> In article <3CEBF357.2090109@yahoo.com>, David Rasmussen
>> <pinkfloydhomer@yahoo.com> writes
>>
>>> OK. That's too bad, since the language needs dramatic changes. What
>>> will it gain discussing minor changes and ratifying them in 2008? Why
>>> not make major changes where major changes are neeeded? Our knowledge
>>> of programming languages and design paradigms is growing rapidly in
>>> these years. What is C++'s ambition? What role will C++ have in 2010
>>> if only small insignificant changes have been made, while the rest of
>>> the world have gained a lot of insight in the meantime? Will present
>>> day C++ be the most modern C++-like thing imaginable in 2010? Probably
>>> not...
>>
>>  This paragraph is entirely your characterisation of what will happen.
>> We certainly have not ruled out major enhancements but the barrier is
>> certainly higher for those. You have to demonstrate that there will be a
>> commensurate gain to justify the pain of making such extensions. You
>> must also demonstrate that that pain does not include breaking large
>> amounts of existing code (and very definitely not silently changing the
>> meaning of existing code.)
>
>
>     C++ is in more trouble than the C++
>committee realizes.  Without some substantial improvements, C++
>may go the way of the Pascal/Modula/Ada family of languages,
>marginalized and nearly forgotten.  C++ is losing market share.

  Really? That's news to me. Do you have sources for this?

>     The move to Java and C# is fueled by the reliability
>problems of programs written in the C/C++ family of languages.
>I see nothing being done to remedy this.

  Quite a bit has been done, but the programming community hasn't
caught up with the state of the art. See below.

>     The question for the C++ community is "how can the stability
>of C/C++ programs be increased to that of Java/C# programs."
>Nobody seems to be working seriously on this, other than
>the "bolt on garbage collection" people.  I did some work
>in that direction (look at my "strict C++" proposals), but
>there may be a better way.

  There's no cure for the reliability problems of C, other than to
move to C++.
  To fix the most common cause of reliability problems in C++, confine
pointers and dynamic allocation to infrastructure classes. Don't use
them in application code.
  This makes polymorphism more difficult, but not impossible. I
suggest you read about the "polymorphic object" idiom, which allows
reliable code to be written in the presence of polymorphism.

>     Every day, thousands of programs and systems crash
>because C++ hasn't fixed this problem.  This is unnecessary,
>and perhaps irresponsible.

  It's been fixed, but most programmers don't know how to implement
the correct idioms. This is an educational problem, not a technical
one.

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt

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

John Nagle <nagle@animats.com> wrote in
news:3CEFD282.9010106@animats.com:
>      C++ is in more trouble than the C++
> committee realizes.  Without some substantial improvements, C++
> may go the way of the Pascal/Modula/Ada family of languages,
> marginalized and nearly forgotten.  C++ is losing market share.
>
Which is why the number of vacancies for C++ programmers has increased over
the last year, while the number of vacancies for Java programmers is in
sharp decline?
Please provide concrete figures to back up this FUD.
>      The move to Java and C# is fueled by the reliability
> problems of programs written in the C/C++ family of languages.
> I see nothing being done to remedy this.
>
The move back to C++ is being fueled by the reliability problems and
unmaintainability of Java. C# is barely out of diapers, the run time
crashes 3 times before breakfast.
>      The question for the C++ community is "how can the stability
> of C/C++ programs be increased to that of Java/C# programs."
I'd rather no one decreased the reliability of my code that far thanks.
> Nobody seems to be working seriously on this, other than
> the "bolt on garbage collection" people.  I did some work
> in that direction (look at my "strict C++" proposals), but
> there may be a better way.
>
Of course memory leaks in Java are impossible. Which means the leaks in
Swing don't exist. Java makes threading easy and safe. Amazingly slow, but
safe and easy. Garbage collection is less of an overhead than managing
memory manually. Please ignore the 15 second pauses in execution.
>      Every day, thousands of programs and systems crash
> because C++ hasn't fixed this problem.  This is unnecessary,
> and perhaps irresponsible.
>
Proof please. It is as easy to say that every day thousands of programs and
systems crash because the programmers were taking hard drugs. This is of
course unecessary and irresponsible.
>      It's not impossble to make a big change.  Look at FORTRAN.
> It's had two major incompatible modernizations, in 1977 and 1995.
> That's why it's still around.
>
Fortran is of course the picture of a healthy language, every company I
know is moving all their development effort to Fortran.

There are things in C++ that need fixing, although strangely garbage
collection is not actually on my list. My list is:
Elimination of C style casts.
Strong typedefs.
Rationalisation of template syntax.
A decent low level thread library, just the primitives thanks.
Closed namespaces.
In place initialisation of non-int const static members.

I'd like the interfaces to parts of the STL tidied up as well, but it isn't
going to happen unfortunately (what is the difference between list.empty()
and list.clear() ?).

>                          John Nagle
>                          Animats
>
Dan "A computer without Java is like chocolate cake without mustard" Smart


--
Dan Smart. C++ Programming and Mentoring.
cppdan@dansmart.com
ADDvantaged

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

nagle@animats.com (John Nagle) wrote (abridged):
>      It's not impossble to make a big change.  Look at FORTRAN.
> It's had two major incompatible modernizations, in 1977 and 1995.
> That's why it's still around.

Yes. And look at the dates. 17 years between Fortran 60 and 1977. Another
18 years between 1977 and 1995. By that precedent, we should not be
considering incompatible changes to C++ for another 10 years.

  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                       ]

Tom Puverle wrote:
> In response to some of the posts here, can I ask this:
> Could people indicate whether or not they would find it desirable if C++ had
> automatic garbage collection. Just a little poll, nothing more.
> Thanks.
>

I would find it very useful if C++ had the _possibility_ of garbage
collection. It does already, you can just use Hans Boehms garbage
collector for C++. But possibly some things could be better if this
possibility was standardized.

/David

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

Dan Smart wrote:
>
> There are things in C++ that need fixing, although strangely garbage
> collection is not actually on my list. My list is:
> Elimination of C style casts.
> Strong typedefs.
> Rationalisation of template syntax.
> A decent low level thread library, just the primitives thanks.
> Closed namespaces.
> In place initialisation of non-int const static members.
>

Most of those are on my list too. I also would very much like strong enums.

/David

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

"Tom Puverle" <tp225@cam.ac.uk> wrote in
news:acpfco$2ha$1@pegasus.csx.cam.ac.uk...
> In response to some of the posts here, can I ask this:
> Could people indicate whether or not they would find it desirable if C++
had
> automatic garbage collection. Just a little poll, nothing more.
> Thanks.
>

Not really.

Garbage collection was *very* useful in C++'s ancestor Simula, because that
language had (sort of) constructors but no destructors. That made it
difficult to clean up after the objects!

Using a constructor/destructor pair in an object, I think we get a nice
symmetry for allocating/deallocating resources. I have never had any
problems with this. Remember also that there might be a lot of other
resources an object aquires, which would all be reallocated anyway. Why
would memory be treated differently?


Bo Persson
bop2@telia.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                       ]

"Dan Smart" <cppdan@dansmart.com> skrev i meddelandet
news:Xns921AEB5F3A3BMe@167.206.112.134...
> John Nagle <nagle@animats.com> wrote in
> news:3CEFD282.9010106@animats.com:
(snip)
> >      The question for the C++ community is "how can the stability
> > of C/C++ programs be increased to that of Java/C# programs."
> I'd rather no one decreased the reliability of my code that far thanks.
> > Nobody seems to be working seriously on this, other than
> > the "bolt on garbage collection" people.  I did some work
> > in that direction (look at my "strict C++" proposals), but
> > there may be a better way.
> >
> Of course memory leaks in Java are impossible. Which means the leaks in
> Swing don't exist.

But that is only because the JVM is written in C/C++, and is leaking memory!
As soon as someone rewrites the JVM in pure Java, this problem will
disappear. :-)

> Java makes threading easy and safe. Amazingly slow, but
> safe and easy. Garbage collection is less of an overhead than managing
> memory manually. Please ignore the 15 second pauses in execution.
> >      Every day, thousands of programs and systems crash
> > because C++ hasn't fixed this problem.  This is unnecessary,
> > and perhaps irresponsible.
> >
> Proof please. It is as easy to say that every day thousands of programs
and
> systems crash because the programmers were taking hard drugs. This is of
> course unecessary and irresponsible.
> >      It's not impossble to make a big change.  Look at FORTRAN.
> > It's had two major incompatible modernizations, in 1977 and 1995.
> > That's why it's still around.
> >
> Fortran is of course the picture of a healthy language, every company I
> know is moving all their development effort to Fortran.

:-)

Actually, we are using COBOL.

> There are things in C++ that need fixing, although strangely garbage
> collection is not actually on my list. My list is:
> Elimination of C style casts.

Great. In the mean time we could ask our favorite compiler writer to just
add a warning.

> Strong typedefs.
> Rationalisation of template syntax.
> A decent low level thread library, just the primitives thanks.

Great.

> Closed namespaces.

Which means?

> In place initialisation of non-int const static members.

Would be good as well.

> I'd like the interfaces to parts of the STL tidied up as well, but it
isn't
> going to happen unfortunately (what is the difference between list.empty()
> and list.clear() ?).

I can learn to live with that.

>

Bo Persson
bop2@telia.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                       ]

Bo Persson wrote:
>
> Not really.
>
> Garbage collection was *very* useful in C++'s ancestor Simula, because that
> language had (sort of) constructors but no destructors. That made it
> difficult to clean up after the objects!
>
> Using a constructor/destructor pair in an object, I think we get a nice
> symmetry for allocating/deallocating resources. I have never had any
> problems with this. Remember also that there might be a lot of other
> resources an object aquires, which would all be reallocated anyway. Why
> would memory be treated differently?
>

The good thing about a garbage collector for C++, is that one can start
with just using the garbage collector, which _is_ simpler, and less
error-prone. Then, if it turns out to be a hotspot or a bottleneck, you
could turn to manual destruction. Also, garbage collection in
conjunction with manual destruction can be used for finding memory leaks
and other bugs. Research shows that for most applications, garbage
collection isn't a performance problem at all. The myths of the garbage
collector halting the application for seconds, were true 10-20 years
ago, but seldom today, unless your application is non-typical.

/David

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

 David Rasmussen <pinkfloydhomer@yahoo.com> wrote:
>For example, if I think old-style casts should be removed, it would be
 >nice if the language itself (and of course the compilers that
 >implemented it) supported some sort of mechanism where I could say
>"Please give me a compilation error, if I use an old-style cast".

"Steve Heller" <steve@steveheller.com> wrote...
>   I would like this feature a great deal. I try to avoid error-prone
> constructs, but language support would make it easier to do so.

It doesn't get my vote because I use lint so I already have it. On
principle, I wouldn't want the standard to require any warnings.
I'm a minimalist and I think the job of the standard is to specify
how source gets turned into executable code.

An ISO standard for LINT would be nice, especially if it provided
an alternative way of writing lint directives. I find lint's use of
comments rather depressing. It reminds me of the way browser vendors
added scripting to HTML by stealing the comment syntax -- a filthy
hack if ever there was one.

Perhaps the next C++ standard could offer a syntax for adding "markup"
to source code that could be extracted and used by other tools. (I
suggested only the other week how one might sneak IDL attributes
past a compiler to support RPC better.)


---
[ 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:Xhd0hzCM5K88Ewo2@robinton.demon.co.uk...

> It is in the nature of things that people see the good side of new
> things quickly (or they fail immediately) but take time to discover the
> down side of them. The instability of Java more than compensates for any
> putative reliability gains in programmes written in it. The size of its
> libraries coupled with the poor quality of quite a few of them causes
> its own problems.
> ...
> Read 'Bitter Java' by Bruce Tate
I looked at some sample chapters online.  The one on memory management, for
instance, says:

    For some low-level languages,like C++, the manager is a very thin layer.
The programmer is responsible for explicitly
    requesting a block of memory (with new or malloc) and explicitly freeing
the block (with free) when it's no longer
    required. C++ also forces the programmer to track individual addresses
of memory blocks through pointers. This
    implementation makes C++ very flexible, but also tedious and
problematic.

> I think you might then find that good Java programmers know that all is
not well.

The book gives many examples of how to misuse Java and ways to avoid them.
Surely you are not saying that it's impossible to misuse C++.

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

    Some assistance on the storage management front is useful,
but garbage collection and destructors don't play well together.
The semantics get wierd.  Look at Microsoft's "managed storage"
system for C++.  Painful.  A destructor is not a finalizer, and vice
versa.

    GC works better with Java semantics.

    John Nagle
    Animats

David Rasmussen wrote:

> Tom Puverle wrote:
>
>> In response to some of the posts here, can I ask this:
>> Could people indicate whether or not they would find it desirable if
>> C++ had
>> automatic garbage collection. Just a little poll, nothing more.
>> Thanks.
>>
>
> I would find it very useful if C++ had the _possibility_ of garbage
> collection. It does already, you can just use Hans Boehms garbage
> collector for C++. But possibly some things could be better if this
> possibility was standardized.
>
> /David
>
> ---
> [ 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                       ]
>

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

John Nagle <nagle@animats.com> writes:

|>       C++ is in more trouble than the C++ committee realizes.
|>  Without some substantial improvements, C++ may go the way of the
|>  Pascal/Modula/Ada family of languages, marginalized and nearly
|>  forgotten.  C++ is losing market share.

I've not noticed that.  The demand for C++ programmers seems to be
just as strong as that for Java programmers, and in more varied
markets.  My impression, in fact, is that the demand for Java has
largely peaked, and that the language is gradually becoming a
"specialty language" for Web applications, and is no longer being used
for general programming.  At least, all of the job offers for Java
seem to want something like WebSphere as well.  (As "niche markets"
go, of course, it is a very big niche.)

|>       The move to Java and C# is fueled by the reliability problems
|>  of programs written in the C/C++ family of languages.  I see
|>  nothing being done to remedy this.

The move to Java and C# is being fueled by people looking for a silver
bullet.  Once they find that these languages don't offer one, they
will look elsewhere.  (That doesn't mean that C++ can't be improved,
of course.)

|>       The question for the C++ community is "how can the stability
|>  of C/C++ programs be increased to that of Java/C# programs."

The question is more one of "how can we overcome the marketing hype,
so that people realize the facts: that C++ programs are as stable, if
not more stable, than Java programs?"

|>  Nobody seems to be working seriously on this, other than the "bolt
|>  on garbage collection" people.  I did some work in that direction
|>  (look at my "strict C++" proposals), but there may be a better
|>  way.

|>       Every day, thousands of programs and systems crash because
|>  C++ hasn't fixed this problem.  This is unnecessary, and perhaps
|>  irresponsible.

Every day, thousands of programs and systems written in other
languages crash as well.

There is a real problem, but it is with software engineering, and not
C++.  (C++ has some problems as well, of course, and if good software
engineering practices had been wide spread 20 years ago, C probably
would never have become successful, and we'd be arguing about how to
improve Modula or some other Pascal derivate today.)

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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

Dan Smart <cppdan@dansmart.com> writes:

|>  Of course memory leaks in Java are impossible. Which means the
|>  leaks in Swing don't exist. Java makes threading easy and
|>  safe. Amazingly slow, but safe and easy. Garbage collection is
|>  less of an overhead than managing memory manually. Please ignore
|>  the 15 second pauses in execution.

Let's stick to the facts. =20

Java's threading isn't any slower than anyone else's.  Writing thread
safe programs is more difficult than writing single threaded programs.
Regardless of whether the language is Java or C++.  What is happening
is that a lot of applications in Java are multithreaded when they
shouldn't be, because it is much more difficult to avoid threading in
Java.

And all of the real benchmarks I've seen concerning garbage collection
in C++ have shown it to be as fast, if not faster, than manual memory
management.  It's been years since I've seen pauses in execution due
to garbage collection (in Emacs, at any rate), and the difference
isn't just due to improved processor speed.

|>  >      Every day, thousands of programs and systems crash because
|>  > C++ hasn't fixed this problem.  This is unnecessary, and perhaps
|>  > irresponsible.

|>  Proof please. It is as easy to say that every day thousands of
|>  programs and systems crash because the programmers were taking
|>  hard drugs. This is of course unecessary and irresponsible.

Well, there are a lot of programs that crash.  Think of the Ariane,
for example.  Of course, that program was written in Ada.  But I'm
sure that the crash would also have occured if the program had been
written in C++.  To date, I know of no language which can do anything
about faulty management.

This is a point that I can't stress enough.  If your organization
cannot write robust, reliable software in C++, then it can't write it
in Java, nor in Ada, nor in any other language.  This isn't to say
that all languages are equal, or that C++ cannot be improved upon --
if your organization can write robust software in C++, it might be
able to write it more cheaply in Ada, of some other language
(depending on the application domain and hundreds of other factors, of
course).  But writing robust software is first and foremost a question
of good engineering, and that is independant of the language.

|>  >      It's not impossble to make a big change.  Look at FORTRAN.
|>  > It's had two major incompatible modernizations, in 1977 and
|>  > 1995.  That's why it's still around.

|>  Fortran is of course the picture of a healthy language, every
|>  company I know is moving all their development effort to Fortran.

|>  There are things in C++ that need fixing, although strangely
|>  garbage collection is not actually on my list. My list is:
|>  Elimination of C style casts.
|>  Strong typedefs.
|>  Rationalisation of template syntax.
|>  A decent low level thread library, just the primitives thanks.
|>  Closed namespaces.
|>  In place initialisation of non-int const static members.

|>  I'd like the interfaces to parts of the STL tidied up as well, but
|>  it isn't going to happen unfortunately (what is the difference
|>  between list.empty() and list.clear() ?).

IMHO, right now, the most important thing that needs fixing in C++ is
the compilers.  So that I can write code that will continue to work
with the next version.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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 <3CF1EF58.1060301@yahoo.com>, David Rasmussen
<pinkfloydhomer@yahoo.com> writes
>The good thing about a garbage collector for C++, is that one can start
>with just using the garbage collector, which _is_ simpler, and less
>error-prone. Then, if it turns out to be a hotspot or a bottleneck, you
>could turn to manual destruction. Also, garbage collection in
>conjunction with manual destruction can be used for finding memory
>leaks and other bugs. Research shows that for most applications,
>garbage collection isn't a performance problem at all. The myths of the
>garbage collector halting the application for seconds, were true 10-20
>years ago, but seldom today, unless your application is non-typical.

True, but so is the myth that it is necessary to do manual resource
management in C++. A competent programmer knows how to avoid explicit
calls to delete except inside properly designed components.
Learning to do that gets you much more than memory management.

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

David Rasmussen <pinkfloydhomer@yahoo.com> writes:

|>  The good thing about a garbage collector for C++, is that one can
|>  start with just using the garbage collector, which _is_ simpler,
|>  and less error-prone.

That's doing things backwards, and is very error prone.  (Regard all
of the memory leaks we see in Java.)

You should always start with a design, and the lifetime of an object
is an element of that design, and should be resolved according to the
design, before you start coding.

Where garbage collection comes in is much later, when you start
coding.  Using an existing garbage collection is a magnitude of order
easier and less error prone when used to *implement* the design, when
appropriate.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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:
>
> True, but so is the myth that it is necessary to do manual resource
> management in C++. A competent programmer knows how to avoid explicit
> calls to delete except inside properly designed components.
> Learning to do that gets you much more than memory management.
>

Many of the suggestions of additions/changes to the C++ language that I
have proposed or that I agree with, are often met by experts like you
with an argument along the lines of "an expert would know how to do that
/avoid that". But my point is that if it takes an expert to do something
quite simple, it is probably not a good idea, and it seems to indicate a
design error. If it takes what you call a "competent programmer", it is
probably a rich source of bugs and confusion in practical real life. Of
course any tool and any programming language will require some level of
competence for it to be used well. But C++ has a lot of features and
design solutions that makes somethings unnecesarily hard to achieve and
some bugs unnecesarily easy to make.

/David

---
[ 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:
>
> Java's threading isn't any slower than anyone else's.  Writing thread
> safe programs is more difficult than writing single threaded programs.
> Regardless of whether the language is Java or C++.  What is happening
> is that a lot of applications in Java are multithreaded when they
> shouldn't be, because it is much more difficult to avoid threading in
> Java.
>

I think it's the other way around: Java makes it too easy to write
multi-threaded programs, so too many programmers who don't know what
they're doing are writing them.

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

In article <PYiI8.919$SF6.89241840@newssvr14.news.prodigy.com>, Mike
Schilling <mscottschilling@hotmail.com> writes
>> Read 'Bitter Java' by Bruce Tate
>I looked at some sample chapters online.  The one on memory management, for
>instance, says:
>
>    For some low-level languages,like C++, the manager is a very thin layer.
>The programmer is responsible for explicitly
>    requesting a block of memory (with new or malloc) and explicitly freeing
>the block (with free) when it's no longer
>    required. C++ also forces the programmer to track individual addresses
>of memory blocks through pointers. This
>    implementation makes C++ very flexible, but also tedious and
>problematic.

And that is an example of where I think he understands C++ tools very
poorly.
>
>> I think you might then find that good Java programmers know that all is
>not well.
>
>The book gives many examples of how to misuse Java and ways to avoid them.
>Surely you are not saying that it's impossible to misuse C++.

Of course not, but the point is that misuse is not only possible in both
languages but rife in both. Java simply has not lived up to its claims
to fix the problems, indeed memory leaks in Java are even harder to fix
if and when you discover them.


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

Steve Clamage wrote:
> On Fri, 24 May 2002, Steve Heller wrote:
>
>>David Rasmussen <pinkfloydhomer@yahoo.com> wrote:
>>
>>
>>>Francis Glassborow wrote:
>>>
>>>>I think we need some
>>>>mechanism for strong typedefs
>>>
>>>I agree 100%. Also, the possibility of defining strongly typed enums
>>>that are _not_ ints, but their own type. Somehow we would have to find a
>>>way to use them in for() loops. Both of these features could be added
>>>without wrecking existing code.
>>
>>  Add my vote for all of these proposals.
>
>
> IMHO, "me, too" postings are pointless. Nothing is being voted on,
> and when votes occur, this is not the forum. How about submitting
> a concrete proposal? So far we don't have one.
>

So is "IMHO, "me too" postings.... blah blah blah...." postings.

What do you need for a concrete proposal?? It is very concrete. Some
details need to be resolved like what to do with for loops (I cant think
of anything else). So it is illegal to propose anything that haven't
been thought out in full and is a complete proposal? At the same time
someone replies to ones message, the proposal is deprecated, because it
generated a reply and wasn't perfect.

Seriously, you wont get language change proposals more concrete than this.

Let me ask: What do you want to know? What do you miss?

/David

---
[ 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 <3CEDFACB.2060006@yahoo.com>, David Rasmussen
> <pinkfloydhomer@yahoo.com> writes
>
>> All this could be added without creating problems for existing code.
>
>
> Adding 1000 other things would certainly create problems for the
> implementors if no one else. And a surprising number of apparently
> clean, pure extensions turn out to interact with existing features in
> less than pleasant ways.
>
>

So let't go back to assembler. C++ is probably perfect as it is.

/David

---
[ 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@alex.gabi-soft.de> wrote ...
>
> I've about had it with untried experiments.)

Btw, what about your efforts to understand/use/reimplement
streams, strings,  and locales ?-)



---
[ 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" <hyrosen@mail.com> wrote ...
>
> Ranged types can be created by allowing constant ranges after
> simple type specifiers, eg.,
> typedef char 'a' .. 'z' lc;
> typedef int 0 .. 100 pct;
> Ranged types interconvert freely like their unranged sources,
> but the compiler will insert checks so that an exceptions is
> thrown on attempt to set a value that's out of range. References
> to ranged types may be initialized from unranged or wider-ranged
> types. There is a check on initialization, and it is undefined
> behavior for a side effect to modify such a referenced variable
> to be outside the range of any existing ranged reference. Eg.,

In theory I support that feature request, but one
should keep in mind the possibility that during the
next years some compiler vendor succeeds in defining
and implementing additional support for general kinds
of post/pre/xxx-conditions mandatory to be checked
at build and/or load time and optionally enforced
at runtime; for me this would be a killer feature
for any derivative of current c++.
Then we would have this ranged types automatically.


Markus.



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

"Tom Puverle" <tp225@cam.ac.uk> writes:

| In response to some of the posts here, can I ask this:
| Could people indicate whether or not they would find it desirable if C++ had
| automatic garbage collection. Just a little poll, nothing more.

Making use of a garbage collector *optional* is one the item I've been
seeing on wishlist of some influencal members of the C++ standards
committee.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

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

"John Nagle" <nagle@animats.com> wrote in message
news:3CEFD282.9010106@animats.com...
> Francis Glassborow wrote:
>
> > In article <3CEBF357.2090109@yahoo.com>, David Rasmussen
> > <pinkfloydhomer@yahoo.com> writes
> >
> >> OK. That's too bad, since the language needs dramatic changes. What
> >> will it gain discussing minor changes and ratifying them in 2008? Why
> >> not make major changes where major changes are neeeded? Our knowledge
> >> of programming languages and design paradigms is growing rapidly in
> >> these years. What is C++'s ambition? What role will C++ have in 2010
> >> if only small insignificant changes have been made, while the rest of
> >> the world have gained a lot of insight in the meantime? Will present
> >> day C++ be the most modern C++-like thing imaginable in 2010? Probably
> >> not...
> >
> >  This paragraph is entirely your characterisation of what will happen.
> > We certainly have not ruled out major enhancements but the barrier is
> > certainly higher for those. You have to demonstrate that there will be a
> > commensurate gain to justify the pain of making such extensions. You
> > must also demonstrate that that pain does not include breaking large
> > amounts of existing code (and very definitely not silently changing the
> > meaning of existing code.)
>
>
>      C++ is in more trouble than the C++
> committee realizes.  Without some substantial improvements, C++
> may go the way of the Pascal/Modula/Ada family of languages,
> marginalized and nearly forgotten.  C++ is losing market share.

Market share should not be the determinant of how a language evolves to meet
the needs of its programmers. Quantity does not mean quality and a language
should be concerned with quality of features and usage and not how many
people use it. Ideally the best technical quality leads to the greatest
number of adherents but this is not always the case.

>
>      The move to Java and C# is fueled by the reliability
> problems of programs written in the C/C++ family of languages.
> I see nothing being done to remedy this.

I think it is fueled by the strength of the marketing machines of Microsoft
and Sun respectively, by the willingness of programmers to choose the easier
but more limiting programming routes, and by the hype and perceived,
although not real, notions of what a programming language should entail.

>
>      The question for the C++ community is "how can the stability
> of C/C++ programs be increased to that of Java/C# programs."
> Nobody seems to be working seriously on this, other than
> the "bolt on garbage collection" people.  I did some work
> in that direction (look at my "strict C++" proposals), but
> there may be a better way.

C++ has library constructs which increase stability greatly. You want
guarantees of stability to be placed in the language itself. Are you aware
of the overhead in run-time costs of both Java and C# in order to provide
this stability and the limitations placed on those languages in order to do
so ( as an example of the latter, ask a Java or C# programmer how they
insure that objects which hold resources free them at the appropriate
times ).

>
>      Every day, thousands of programs and systems crash
> because C++ hasn't fixed this problem.  This is unnecessary,
> and perhaps irresponsible.

Do you really expect a language to fix the problem of poorly written
programs ? That is a very naive attitude to take. C++ has provided modern
constructs which deal very smoothly with the problems of memory allocation
and memory overrun errors in the guise of smart pointers and containers, but
if programmers do not want to use these library constructs and insist on
using more error prone techniques which may lead to crashes and other
problems, it is not the responsibility of a computer language to protect
these programmers to the detriment of others who do not need, and do not
want to be impeded, by such language additions.

>
>      It's not impossble to make a big change.  Look at FORTRAN.
> It's had two major incompatible modernizations, in 1977 and 1995.
> That's why it's still around.

The big change has to be justified by an equally big problem which that
change resolves. So far I have not seen anything in your post regarding what
that problem is and what the big change is. Would you like to explain these
things. Just saying that C++ has to change without saying what you
specifically believe the changes should be and why, does little good in
promoting a better 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                       ]

Daniel Miller <daniel.miller@tellabs.com> writes:

|>  James Kanze wrote:
|>  > Francis Glassborow <francis.glassborow@ntlworld.com> writes:
|>  > |>  In article <ach3u8$lug$1@knossos.btinternet.com>, Mark Jordan
|>  > |>  <Mark_Jordan@nospam.btinternet.com> writes
|>  > |>  >All I am after is some information on potential new C++
|>  > |>  >features. Is there a central website we can go to look at
|>  > |>  >current proposals and ideas?
|>  > |>  At the moment? No. From the library aspect, looking at Boost
|>  > |>  will cover much of the ground.

|>  > And a lot more.  I certainly hope that there are no plans for
|>  > creating a standard CRC class, for example.  (On the other hand,
|>  > I suspect or hope that if it isn't in Boost, it won't be in the
|>  > next standard.  I've about had it with untried experiments.)

|>     Absolutely not!  That is tantamount to making Boost the de
|>  facto standards body, usurping ISO, ANSI, DIN, BSI, and every
|>  participating body's role in J16!

Not at all.  Just a sort of an antechamber.

|>  Boost should not and must not be the only orifice through which
|>  one can introduce libraries to be considered for standardization.

Not necessarily.  But I would argue that we need existing practice.
And one of the major goals of Boost is to give us just that.

|>  Take for example Boost.threads.  A number of us consider
|>  Boost.threads drastically deficient in its current form.  A number
|>  of us consider the stated-intended direction Boost.threads as
|>  being off the mark for multithreaded embedded realtime software.

|>     There must be nonBoost ways of bringing libraries to the
|>  standardization process if the Boost community were to ever make
|>  mistakes.

And then a non-standard way if ever the committee makes mistakes:-).

Seriously, Boost has no official status.  Anyone can present a
proposal for anything.  On the other hand, it is doubtlessly worth
remembering that existing practice and a proof of concept
implementation are strong plus points, and that many of the same
people involved most strongly with Boost are also very active in the
standardization effort.

|>     If you intend for there to be a fully-working portable
|>  properly-licensed library which is publically available (not
|>  necessarily distributed as part of Boost) as a prerequisite to
|>  standards consideration, then I agree.  But that generality was
|>  not present in your narrower wording.  Taking your wording as
|>  tendered at face-value, then I firmly & vigorously disagree.

The part to take at its literal face value is: "I've about had it with
untried experiements."  If someone else has a fully working portable
proof of concept to show, why not.

In practice, given the situation on the ground, if Boost covers the
issue, I suspect that alternatives will have a much more difficult
time of it.  But I doubt that that is an absolute.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Need real expertise in C++, Java, OO design
                       I am available, see my CV at www.gabi-soft.de
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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 Fri, 24 May 2002 15:14:53 GMT, James Kanze wrote in
<86off6qa32.fsf@alex.gabi-soft.de>:

> |>  Sure. C++ could use a dictator that singlehandedly cleaned up the
> |>  language, instead of a slooooooow commitee that can't decide
> |>  anything. Slow and careful development of a language, like the
> |>  commitee is doing, is important, but only when the language have
> |>  reached a certain level of maturity and the most obvious design
> |>  errors have been corrected. If C++ is nearly frozen now, with only
> |>  insignificant changes every 10 years or so, it's dead.
>
> Do you mean dead, like Fortran and Cobol?  (I think that there is
> still more new code written in Cobol than in any other language.  And
> I certainly wouldn't say that all, or even any, of the design errors
> in Cobol have been corrected.)

But is there a lot of *new* code written in COBOL?  IMHO, most (if not
all) COBOL code that is written today is maintanance of 30 year old data
processing applications.

Surely that is not the future you envision for C++ in 10 years.


Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

---
[ 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 Hagan wrote:
>  David Rasmussen <pinkfloydhomer@yahoo.com> wrote:
>
>>For example, if I think old-style casts should be removed, it would be
>
>  >nice if the language itself (and of course the compilers that
>  >implemented it) supported some sort of mechanism where I could say
>
>>"Please give me a compilation error, if I use an old-style cast".
>
>
> "Steve Heller" <steve@steveheller.com> wrote...
>
>>  I would like this feature a great deal. I try to avoid error-prone
>>constructs, but language support would make it easier to do so.
>
>
> It doesn't get my vote because I use lint so I already have it. On

LINT costs money. Which means it is a no go for me.

> principle, I wouldn't want the standard to require any warnings.
> I'm a minimalist and I think the job of the standard is to specify
> how source gets turned into executable code.
>

I agree with that. But I am not talking about a warning here. I am
talking about an error. This is not just adding some lint-like features
to the language. This is about the language being expressive enough for
you as a programmer to state exactly what you want and don't want. It is
an integral part of a good design to specify exactly what the bounds of
your types and concepts are. In C++, there are many simple things that
you can't specify. For example, you can't specify such an incredibly
useful thing as this: I want an enum, and _don't_ _ever_ convert it
automatically into an int, because that does not make sense at all. I am
never interested in the underlying int, I am only interested in making a
new type. This is easy to specify in Ada and Pascal and ML and...
I agree that the language should not need the kind of thing I am
proposing, if it was expressive and flexible enough for the programmer
to specify such constraints. But since C++ is a joke in general for
this, _something_ is needed.

/David

/David

---
[ 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:
> Hyman Rosen <hyrosen@mail.com> writes:
>
> |>  David Rasmussen wrote:
> |>  > OK. That's too bad, since the language needs dramatic changes.
>
> |>  C++ is what it is. Even assuming that you are correct, those
> |>  changes have to be thoroughly specified, with impact on the whole
> |>  language spelled out. Otherwise, if you want to use a different
> |>  language, do so, and if the language you want to use doesn't exist
> |>  yet, create it.
>
> The most important point here is that C++ is.  Already.  Any changes
> better not break my code.
>

There are loads and loads and loads and loads of obvious changes (or
rather additions) that would NOT wreck existing code. These would just
be _possibilities_, not mandatory features. Strong typedefs, strong
enums, contracts, all preprocessor-tasks have alternative solutions,
specifically the #include mechanism of connection compilation units is
too crude and create problems in large projects and hurt performance.
There could be a better developed module/package system that made the
compiler deal with all the nasty details, so multiple inclusion wouldn't
be a problem, and constants from other units could be used directly in
other compilation units, and functions from other units could be inlined
automatically etc. etc. etc. etc. And 1000 other things

All this could be added without creating problems for existing code.

/David

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

> Hyman Rosen <hyrosen@mail.com> writes:
>
> |>  David Rasmussen wrote:
> |>  > OK. That's too bad, since the language needs dramatic changes.
>
> |>  C++ is what it is. Even assuming that you are correct, those
> |>  changes have to be thoroughly specified, with impact on the whole
> |>  language spelled out. Otherwise, if you want to use a different
> |>  language, do so, and if the language you want to use doesn't exist
> |>  yet, create it.
>
> The most important point here is that C++ is.  Already.  Any changes
> better not break my code.
>

I disagree with this I think.  C++98 will still be completely compatible
with your code, so you shouldn't really have an problems.  That situation
may not be entirely true for C++0x (which has historically been the case
when the first standard came out with things such as namespaces).  I don't
understand how that is a problem.  If  you need C++98, just use that
instead.

  But if C++0x were to simply add strong typing for the portions of the
language coming from C (like its already done for structs) and remove the
notion of undefined behavior (including the C portions of the standard
library), I think I would consider that a nice step in the right direction,
tho it would certainly break existing code (again, just like the 98
standard did).  The library facilities would still need to be extended to
add some more recent developments (and auto_ptr should be deprecated, imo),
but really you would have dramatically improved the language, with very
little risk (risk here equating to adding multiple new features that turn
out not to work well together, with exceptions and destructors, exception
specifications, containers of auto_ptrs, containers of references being
several examples where things perhaps didn't fit together exactly how a
working C++ programmer might have hoped -- in fact namespaces could
probably be added to this category, and as I've noted, they broke
everyone's of code).

--
Brad Settlemyer
http://deepcopy.org/
Progamming in the trenches

---
[ 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> writes:

|>  In article <ach3u8$lug$1@knossos.btinternet.com>, Mark Jordan
|>  <Mark_Jordan@nospam.btinternet.com> writes
|>  >All I am after is some information on potential new C++
|>  >features. Is there a central website we can go to look at current
|>  >proposals and ideas?

|>  At the moment? No. From the library aspect, looking at Boost will
|>  cover much of the ground.

And a lot more.  I certainly hope that there are no plans for creating
a standard CRC class, for example.  (On the other hand, I suspect or
hope that if it isn't in Boost, it won't be in the next standard.
I've about had it with untried experiments.)

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

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

David Rasmussen wrote:
> Francis Glassborow wrote:
>> I think we need some mechanism for strong typedefs
> I agree 100%. Also, the possibility of defining strongly typed enums
> that are _not_ ints, but their own type. Somehow we would have to find a
> way to use them in for() loops. Both of these features could be added
> without wrecking existing code.

I so often wish that the C++ designer(s) had learned from Ada,
which has all of the above and more. Ranged integers would be
great, too. So let me contribute to the wishing frenzy by
suggesting some syntax and semantics.

Strong typedefs should have the following syntax:
 typedef new declaration;
eg.,
 typedef new unsigned char byte;
 typedef new void (*vfp)();

These new types have no automatic conversion to or from their
source type, but can be converted using static or functional
cast, eg.,
 unsigned char c;
 byte b = c; // illegal
 byte b = byte(c); // ok
 byte b = static_cast<byte>(c); // ok
They should have automatic conversion from literals of their type, eg.
 typedef new long nl;
 nl an_nl = 17L; // ok
 nl an_nl = 17;  // illegal

All types will need to have a defined set of primitive operations.
Then a new type receives a set of these primitive operations. For
the arithmetic types, this includes the usual operators, for pointer
types this includes indirection and subtraction, and so forth. This
prevents mixed arithmetic. Eg.,
 typedef new int my_int;
 // my_int operator+(my_int, my_int);
 // my_int operator*(my_int, my_int);
 // ad nauseum

We can combine this with permitting an enum type to be defined
in such a typedef, eg.,
 typedef new enum { a, b, c } letters;
and removing the automatic conversion to integer from literals
so defined.

Ranged types can be created by allowing constant ranges after
simple type specifiers, eg.,
 typedef char 'a' .. 'z' lc;
 typedef int 0 .. 100 pct;
Ranged types interconvert freely like their unranged sources,
but the compiler will insert checks so that an exceptions is
thrown on attempt to set a value that's out of range. References
to ranged types may be initialized from unranged or wider-ranged
types. There is a check on initialization, and it is undefined
behavior for a side effect to modify such a referenced variable
to be outside the range of any existing ranged reference. Eg.,
 typedef char 'a' .. 'z' lc;
 typedef char 'a' .. 'f' hex;
 lc c = 'A'; // exception
 void f(hex &h);
 lc d = 'b';
 f(d); // ok
 lc e = 'g';
 f(e); // exception
 void side_effect() { d = 'z'; }
 void f(hex &h) { side_effect(); }
 f(d); // undefined behavior

Then we add a new syntax for 'for' loops:
 for(declaration)
where the declaartion declares a single variable of integral or
enumeration type, ranged or not. The loop will iterate over the
range of the variable, and the variable is considered const in
the loop. Eg.,
 for (char c) // loop over all characters
 for (lc c) // loop over lower-case letters
 enum e { a = 7, b = 3, c = 7 };
 for (e x) // loop three times: x = 7, x = 3, x = 7

All of this fails to be a serious proposal, because it does not
fully examine the impact of changes on the entire language, but
I'll propose it anyway.

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

Steve Heller wrote:
> ros0230@iperbole.bologna.it (Natale Fietta) wrote:
>
>
>>On Tue, 21 May 2002 18:36:53 GMT, Steve Heller <steve@steveheller.com>
>>wrote:
>>
>>
>>> My proposal has nothing to do with namespaces. In the grand old
>>>tradition of C++ keyword overloading, I'm reusing the keyword "using"
>>>to mean something almost, but not quite, completely unlike its current
>>>uses.
>>
>>Are you sure ?
>>
>>If i understand it correctly the "using derivation" proposal mean that
>>having this base class:
>>
>>class Base
>>{
>>public:
>>   Base(some_params);
>>   void publicFunc();
>>protected:
>>   void protectedFunc();
>>private:
>>   void privateFunc();
>>};
>>
>>then this derivation:
>>
>>class Derived : using Base
>>{
>>};
>>
>>it is a short-hand for this:
>>
>>class Derived : private Base
>>{
>>public:
>>   Derived(some_params) : Base(some_params) {}
>>   using Base::publicFunc;
>>protected:
>>   using Base::protectedFunc;
>>};
>>
>>so i see it as a natural extension of a current use of "using", not a
>>totally (not even partially) unrelated new use of the same keyword.
>
>
>   Sounds good to me, although I did not have that in mind (at least
> consciously) when proposing "using" as the keyword for this type of
> derivation. I guess my unconscious is smarter than my conscious!

Here's something that I often find necessary:

// Defines an interface
struct Interface
{
   virtual void function(void) = 0;
};

// Mimics the interface
struct Implementation_One
{
   void function(void){}
};

// Mimics the interface
struct Implementation_Two
{
   void function(void){}
};

template <class Implementation>
struct Realization
:
   public Abstract
{
   void function(void) { implementation.function(); }
private:
   Implementation implementation;
};

typedef Realization<Implementation_One> Realization_One;
typedef Realization<Implementation_Two> Realization_Two;

int main(void)
{
   Realization_One r_1;
   Realization_Two r_2;

   r_1.function(); // Calls Implementation_One::function
   r_2.function(); // Calls Implementation_Two::function

   return 0;
}

Typing the forwarding functions is annoying. In one circumstance, it is
also bug-prone. The buggy circumstance is, roughly, a large interface
whose member functions differ in name but which are otherwise the same, ie:

struct Trouble
{
   void funtion_a(void);
   void funtion_b(void);
   void funtion_c(void);
   void funtion_d(void);
   void funtion_e(void);
   ...
};

The problem would go away if the following worked.

// Realizes the interface using Implementation_One
struct Realization_One
:
   public Abstract,
   using Implementation_One
{
};

// Realizes the interface using Implementation_Two
struct Realization_Two
:
   public Abstract,
   using Implementation_Two
{
};

int main(void)
{
   Realization_One r_1;
   Realization_Two r_2;

   r_1.function(); // Calls Implementation_One::function
   r_2.function(); // Calls Implementation_Two::function

   return 0;
}

I've noticed over the years that programmers are singularly unwilling to
write all of those annoying forwarding functions. The very notion is
sure to produce the glazed eye effect. This would make the pristine
implementation so EASY that people might actually do it right!

It's very approachable.

Most people are surprised and disappointed that there's no way to do it
now, short of typing the forwarding functions.

--
I <3 Comeau C++: http://www.comeaucomputing.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 <3CEDFACB.2060006@yahoo.com>, David Rasmussen
<pinkfloydhomer@yahoo.com> writes
>All this could be added without creating problems for existing code.

Adding 1000 other things would certainly create problems for the
implementors if no one else. And a surprising number of apparently
clean, pure extensions turn out to interact with existing features in
less than pleasant ways.


--
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:

> Francis Glassborow <francis.glassborow@ntlworld.com> writes:
>
> |>  In article <ach3u8$lug$1@knossos.btinternet.com>, Mark Jordan
> |>  <Mark_Jordan@nospam.btinternet.com> writes
> |>  >All I am after is some information on potential new C++
> |>  >features. Is there a central website we can go to look at current
> |>  >proposals and ideas?
>
> |>  At the moment? No. From the library aspect, looking at Boost will
> |>  cover much of the ground.
>
> And a lot more.  I certainly hope that there are no plans for creating
> a standard CRC class, for example.  (On the other hand, I suspect or
> hope that if it isn't in Boost, it won't be in the next standard.
> I've about had it with untried experiments.)


   Absolutely not!  That is tantamount to making Boost the de facto standards
body, usurping ISO, ANSI, DIN, BSI, and every participating body's role in J16!

Boost should not and must not be the only orifice through which one can
introduce libraries to be considered for standardization.  Take for example
Boost.threads.  A number of us consider Boost.threads drastically deficient in
its current form.  A number of us consider the stated-intended direction
Boost.threads as being off the mark for multithreaded embedded realtime software.

   There must be nonBoost ways of bringing libraries to the standardization
process if the Boost community were to ever make mistakes.

   If you intend for there to be a fully-working portable properly-licensed
library which is publically available (not necessarily distributed as part of
Boost) as a prerequisite to standards consideration, then I agree.  But that
generality was not present in your narrower wording.  Taking your wording as
tendered at face-value, then I firmly & vigorously disagree.

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

Howard Gardner wrote:
>
> Here's something that I often find necessary:
>
> // Defines an interface
> struct Interface
> {
>    virtual void function(void) = 0;
> };
>
> // Mimics the interface
> struct Implementation_One
> {
>    void function(void){}
> };
>
> // Mimics the interface
> struct Implementation_Two
> {
>    void function(void){}
> };
>
> template <class Implementation>
> struct Realization
> :
>    public Abstract

Did you mean, public Interface, here?

> {
>    void function(void) { implementation.function(); }
> private:
>    Implementation implementation;
> };

I'm thinking I wind up doing something not unlike this in COM
programming, only I skip the forwarding entirely.

template <typename Itf>
struct Implementation_One : public Itf
// etc.

template <typename Itf>
struct Implementation_Two : public Itf
// etc.

template <typename Implementation>
struct Realization : public Implementation
{
};

typedef Realization<Implementation_One<Interface> > Realization_One;
typedef Realization<Implementation_Two<Interface> > Realization_Two;

The devil being in the details, I'm not 100% sure I've done the
translation from what I have to do to what you have to do correctly.


Now, since it's COM, the usage is pretty limited (things should get
called only through Interface, except in the same project, in my
usage), so it's entirely possible I'm glossing over some pitfalls.
Also, I expect that there's some pretty nasty code bloat with the way
the templates are used, but since it's COM, that's not an issue for
me -- the code would be bloated anyway since there's no effective
binary re-use (I'd otherwise have to copy all of the code, making it
a maintenance nightmare).

Anyway, the upshot is, I'm not convinced there isn't a better way
(than what you currently use) to do it now, making it unnecessary to
add a new feature.


Side note: I wound up extending (and replacing) an interface, which
resulted in really ugly template names but code that still compiles
(only I haven't tested it yet):

template <typename Itf>
struct Extended_Implementation : public Itf
// etc.

typedef Implementation_One<Interface>     ItfImpl1;
typedef Extended_Implementation<ItfImpl1> ExtendedItfImpl1;

typedef Realization<ExtendedItfImpl1> Realization_extended;

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

Howard Gardner <usenet@hgardner.com> wrote:

>Steve Heller wrote:
>> ros0230@iperbole.bologna.it (Natale Fietta) wrote:
>>
>>
>>>On Tue, 21 May 2002 18:36:53 GMT, Steve Heller <steve@steveheller.com>
>>>wrote:
>>>
>>>
>>>> My proposal has nothing to do with namespaces. In the grand old
>>>>tradition of C++ keyword overloading, I'm reusing the keyword "using"
>>>>to mean something almost, but not quite, completely unlike its current
>>>>uses.
>>>
>>>Are you sure ?
>>>
>>>If i understand it correctly the "using derivation" proposal mean that
>>>having this base class:
>>>
>>>class Base
>>>{
>>>public:
>>>   Base(some_params);
>>>   void publicFunc();
>>>protected:
>>>   void protectedFunc();
>>>private:
>>>   void privateFunc();
>>>};
>>>
>>>then this derivation:
>>>
>>>class Derived : using Base
>>>{
>>>};
>>>
>>>it is a short-hand for this:
>>>
>>>class Derived : private Base
>>>{
>>>public:
>>>   Derived(some_params) : Base(some_params) {}
>>>   using Base::publicFunc;
>>>protected:
>>>   using Base::protectedFunc;
>>>};
>>>
>>>so i see it as a natural extension of a current use of "using", not a
>>>totally (not even partially) unrelated new use of the same keyword.
>>
>>
>>   Sounds good to me, although I did not have that in mind (at least
>> consciously) when proposing "using" as the keyword for this type of
>> derivation. I guess my unconscious is smarter than my conscious!
>
>Here's something that I often find necessary:
>
>// Defines an interface
>struct Interface
>{
>   virtual void function(void) = 0;
>};
>
>// Mimics the interface
>struct Implementation_One
>{
>   void function(void){}
>};
>
>// Mimics the interface
>struct Implementation_Two
>{
>   void function(void){}
>};
>
>template <class Implementation>
>struct Realization
>:
>   public Abstract
>{
>   void function(void) { implementation.function(); }
>private:
>   Implementation implementation;
>};
>
>typedef Realization<Implementation_One> Realization_One;
>typedef Realization<Implementation_Two> Realization_Two;
>
>int main(void)
>{
>   Realization_One r_1;
>   Realization_Two r_2;
>
>   r_1.function(); // Calls Implementation_One::function
>   r_2.function(); // Calls Implementation_Two::function
>
>   return 0;
>}
>
>Typing the forwarding functions is annoying. In one circumstance, it is
>also bug-prone. The buggy circumstance is, roughly, a large interface
>whose member functions differ in name but which are otherwise the same, ie:
>
>struct Trouble
>{
>   void funtion_a(void);
>   void funtion_b(void);
>   void funtion_c(void);
>   void funtion_d(void);
>   void funtion_e(void);
>   ...
>};
>
>The problem would go away if the following worked.
>
>// Realizes the interface using Implementation_One
>struct Realization_One
>:
>   public Abstract,
>   using Implementation_One
>{
>};
>
>// Realizes the interface using Implementation_Two
>struct Realization_Two
>:
>   public Abstract,
>   using Implementation_Two
>{
>};
>
>int main(void)
>{
>   Realization_One r_1;
>   Realization_Two r_2;
>
>   r_1.function(); // Calls Implementation_One::function
>   r_2.function(); // Calls Implementation_Two::function
>
>   return 0;
>}
>
>I've noticed over the years that programmers are singularly unwilling to
>write all of those annoying forwarding functions. The very notion is
>sure to produce the glazed eye effect. This would make the pristine
>implementation so EASY that people might actually do it right!
>
>It's very approachable.
>
>Most people are surprised and disappointed that there's no way to do it
>now, short of typing the forwarding functions.

  Yes, that is a disappointing aspect of C++. I'm glad to see that my
proposal is so easily used to improve the usability of the language in
ways I hadn't foreseen. Isn't that the mark of a good idea?

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt

---
[ 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 Fri, 24 May 2002, Steve Heller wrote:
>
> David Rasmussen <pinkfloydhomer@yahoo.com> wrote:
>
> >Francis Glassborow wrote:
> >> I think we need some
> >> mechanism for strong typedefs
> >
> >I agree 100%. Also, the possibility of defining strongly typed enums
> >that are _not_ ints, but their own type. Somehow we would have to find a
> >way to use them in for() loops. Both of these features could be added
> >without wrecking existing code.
>
>   Add my vote for all of these proposals.

IMHO, "me, too" postings are pointless. Nothing is being voted on,
and when votes occur, this is not the forum. How about submitting
a concrete proposal? So far we don't have one.

--
Steve Clamage, stephen.clamage@sun.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                       ]

Craig Powers wrote:
> Howard Gardner wrote:
>
>>
>>template <class Implementation>
>>struct Realization
>>:
>>   public Abstract
>
>
> Did you mean, public Interface, here?

Yes.

> I'm thinking I wind up doing something not unlike this in COM
> programming, only I skip the forwarding entirely.
>
> template <typename Itf>
> struct Implementation_One : public Itf
> // etc.
>
> template <typename Itf>
> struct Implementation_Two : public Itf
> // etc.
>
> template <typename Implementation>
> struct Realization : public Implementation
> {
> };
>
> typedef Realization<Implementation_One<Interface> > Realization_One;
> typedef Realization<Implementation_Two<Interface> > Realization_Two;
>
> The devil being in the details, I'm not 100% sure I've done the
> translation from what I have to do to what you have to do correctly.

There's tho obvious difference in the inheritance structure. In your
version, Implementation_One and Implementation_Two are derived from
Interface: in mine they aren't derived from anything. In your version,
Realization is derived from Implementation: in mine, it's derived from
Interface.

One thing that bugs me about that is the fact that Realization may or
may not end up being derived from Interface: the choice is made by
Implementation_XX.

A second thing that bugs me about it is the fact that the
implementations are no longer nice little concrete classes. Instead
they're templates: the set of C++ implementations that handle templates
is still smaller than the set of all C++ implementations. What's more,
they have inheritance baggage (a vtable). That means that if you write
an app to use one and only one implementation, you either pay for the
unneeded structure or you perform the unnatural act of deriving it from
an empty class.

The third thing that bugs me about is the fact that the structure has to
have been known at the time that the implementation was created. That
makes the approach unsuitable as a retrofit. I first stumbled on this
technique while salvaging a trusty old communications library.
Everything about that library was "right" except that there was no sane
way to extend it.

> Now, since it's COM, the usage is pretty limited (things should get
> called only through Interface, except in the same project, in my
> usage), so it's entirely possible I'm glossing over some pitfalls.
> Also, I expect that there's some pretty nasty code bloat with the way
> the templates are used, but since it's COM, that's not an issue for
> me -- the code would be bloated anyway since there's no effective
> binary re-use (I'd otherwise have to copy all of the code, making it
> a maintenance nightmare).

I don't think there's any bloat factor difference unless someone
actually exercises the option you give them to have more than one
kind of Interface. Since that option isn't real (it seems to me that LSP
implies that varying the Interface would require varying Implementations
too) it's not an issue.

> Anyway, the upshot is, I'm not convinced there isn't a better way
> (than what you currently use) to do it now, making it unnecessary to
> add a new feature.

"Better" is context sensitive.

If there's a way to cover all of the cases that the approach I outlined
covers without the tedious forwarding, I would really really (REALLY!)
like to know what it is.

--
I <3 Comeau C++: http://www.comeaucomputing.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 <Pine.SOL.4.33.0205241609410.6021-100000@taumet>, Steve
Clamage <clamage@eng.sun.com> writes
>On Fri, 24 May 2002, Steve Heller wrote:
>>
>> David Rasmussen <pinkfloydhomer@yahoo.com> wrote:
>>
>> >Francis Glassborow wrote:
>>> > I think we need some
>>> > mechanism for strong typedefs
>> >
>> >I agree 100%. Also, the possibility of defining strongly typed enums
>> >that are _not_ ints, but their own type. Somehow we would have to find a
>> >way to use them in for() loops. Both of these features could be added
>> >without wrecking existing code.
>>
>>   Add my vote for all of these proposals.
>
>IMHO, "me, too" postings are pointless. Nothing is being voted on,
>and when votes occur, this is not the forum. How about submitting
>a concrete proposal? So far we don't have one.

Nor for anything else for C++0x. At this stage I want input to see if it
is worth pursuing and to help me provide a better formulation if it is.
'Me too' even if just in email helps me because I know that I have a
constituency, even if small.


--
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:
> David Rasmussen <pinkfloydhomer@yahoo.com> writes:
>
> |>  >> The good ideas can easily come from the users
> |>  > It's the "good ideas coming from users" that have turned C++
> |>  > into the crufty syntactic mess that it is now. Contrast it
>
> |>  No it isn't. Most of the very bad things of C++ comes from the
> |>  fact that Bjarne Stroustrup decided to base C++ on C. This had
> |>  some short-term positive implications (that he have described
> |>  himself), but it has loads of long-term negative implications. And
> |>  now that compiler vendors and writers have C++ compilers and are
> |>  willing to follow language changes, why not change the language?
> |>  Most ideas coming from users are not of the nature "lets add all
> |>  these features without thinking", but rather like "let's restrict
> |>  or remove this old feature that leads to errors and complicated
> |>  syntax etc." or "let's add this feature that is totally
> |>  orthorgonal and non-mandatory, and thus won't affect old work"
> |>  (like the _possibility_ of contracts etc.)
>
> I've *never* found a user who wanted to remove an old feature.  In
> practice, when a language standard removes a feature that corresponds
> to existing practice, that part of the standard is ignored, and
> implementations continue to support the old practice.  Users have
> existing code, and none of them can afford to rewrite all of their
> applications just because the committee decides that what they had
> done before wasn't clean.
>

That is exactly my point.

A very good way of "removing" an unwanted feature, is to not remove it,
because it would wreck existing code, but to be able to define within
the language, that this or that feature is unwanted in this program.
For example, if I think old-style casts should be removed, it would be
nice if the language itself (and of course the compilers that
implemented it) supported some sort of mechanism where I could say
"Please give me a compilation error, if I use an old-style cast". That
way, C++ could retain all the bad features it wants, but users could
decide what strictness level to adhere to, by choosing some standard
profile of features to retain and to "remove". Such a mechanism would be
very nice. And shouldn't be too hard to implement.

> |>  Explain to me why it is better to do the kind of hacking found in
> |>  Modern C++ Design, rather than just having the language supporting
> |>  these kinds of things more naturally. Is it because you love
> |>  obsurities and bugs?
>
> Why support the kind of hacking found in Modern C++ Design at all, in
> any way, shape form or fashion?  I've been writing C++ for years
> without it, and always managed to make things work.
>

When I read MC++D, I thought of many different applications for
compile-time programming in general, so for me it would be very useful.
But I agree that it's uses should definitely be examined more thoroughly
before even thinking about how to construct language support for it.

> There is a middle road, and I think C++, for all its warts, has found
> it.  There are a lot of potentially good things that the language
> doesn't support directly.  But the language doesn't prevent "hacking"
> them, as Andrei as shown.  Now, I certainly don't need these things in
> my existing code, and I can easily continue as I have, without them.
> More importantly, I don't have any real experience with them, to know
> just how good they really are -- the ideas sound very good, but how
> well do they work in practice.
>

I agree.

> Well, thanks to Andrei's experimentation, and the freedom the language
> gives, I can experiment with the ideas, and find out.  Maybe some of
> the ideas won't turn out to be so good in practice.  Maybe others will
> turn out to be even better than we thought.  But once we have some
> concrete experience, to really know, we can talk about incorporating
> them in some way in the language.  Not before.
>

I agree.

> For the moment, what I, as a user, miss most in C++ is stability and
> portability.  And radical changes in the core language aren't the way
> to achieve this.
>

I miss a lot more.

> |>  > with Ada, whose language design was essentially the work of a
> |>  > single language designer (Jean Ichbiah).
>
> |>  Sure. C++ could use a dictator that singlehandedly cleaned up the
> |>  language, instead of a slooooooow commitee that can't decide
> |>  anything. Slow and careful development of a language, like the
> |>  commitee is doing, is important, but only when the language have
> |>  reached a certain level of maturity and the most obvious design
> |>  errors have been corrected. If C++ is nearly frozen now, with only
> |>  insignificant changes every 10 years or so, it's dead.
>
> Do you mean dead, like Fortran and Cobol?  (I think that there is
> still more new code written in Cobol than in any other language.  And
> I certainly wouldn't say that all, or even any, of the design errors
> in Cobol have been corrected.)
>

No. I mean that there seems to be a convergence in, on one hand,
expressibility, abstraction, design, generality etc., and on the other
hand, effective compiled languages that can be used for systems and low
level programming, and have performance comparable to hand-coded assembler.
Very different languages like ML, Lisp and Python have more immediate
expressibility than C++, thing are usually much shorter to code. But
speed sucks. Looking at C++'s development, it seems to be a good
candidate for a language that could represent such a convergence. But it
is not at all there yet. I feel sure that in 10-30 years, we will have
the expressibility of, say, Python with the performance of assembler. If
C++ stays like it is now, it will just be another low-level programming
language with some support of different design paradigms. And it could
be so much more.

/David

---
[ 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 <3CEDFACB.2060006@yahoo.com>, David Rasmussen
> <pinkfloydhomer@yahoo.com> writes
>
>> All this could be added without creating problems for existing code.
>
>
> Adding 1000 other things would certainly create problems for the
> implementors if no one else.

Cool! That's the way it should be.
Of course, all else being equal, the implementors job should be as easy
as possible. But with todays knowledge and resources, there is a whole
lot more a compiler could do, that would increase productivity and
decrease costly bugs etc.

 > And a surprising number of apparently
> clean, pure extensions turn out to interact with existing features in
> less than pleasant ways.
>
>

I am sure that a lot of such extensions exist. But I can't see why the
ones that I proposed could ever do that, if implemented cleanly, with
new keywords.

/David

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

David Rasmussen <pinkfloydhomer@yahoo.com> wrote:

>A very good way of "removing" an unwanted feature, is to not remove it,
>because it would wreck existing code, but to be able to define within
>the language, that this or that feature is unwanted in this program.
>For example, if I think old-style casts should be removed, it would be
>nice if the language itself (and of course the compilers that
>implemented it) supported some sort of mechanism where I could say
>"Please give me a compilation error, if I use an old-style cast". That
>way, C++ could retain all the bad features it wants, but users could
>decide what strictness level to adhere to, by choosing some standard
>profile of features to retain and to "remove". Such a mechanism would be
>very nice. And shouldn't be too hard to implement.

  I would like this feature a great deal. I try to avoid error-prone
constructs, but language support would make it easier to do so.

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt

---
[ 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 <3CEBF357.2090109@yahoo.com>, David Rasmussen
> <pinkfloydhomer@yahoo.com> writes
>
>> OK. That's too bad, since the language needs dramatic changes. What
>> will it gain discussing minor changes and ratifying them in 2008? Why
>> not make major changes where major changes are neeeded? Our knowledge
>> of programming languages and design paradigms is growing rapidly in
>> these years. What is C++'s ambition? What role will C++ have in 2010
>> if only small insignificant changes have been made, while the rest of
>> the world have gained a lot of insight in the meantime? Will present
>> day C++ be the most modern C++-like thing imaginable in 2010? Probably
>> not...
>
>  This paragraph is entirely your characterisation of what will happen.
> We certainly have not ruled out major enhancements but the barrier is
> certainly higher for those. You have to demonstrate that there will be a
> commensurate gain to justify the pain of making such extensions. You
> must also demonstrate that that pain does not include breaking large
> amounts of existing code (and very definitely not silently changing the
> meaning of existing code.)


     C++ is in more trouble than the C++
committee realizes.  Without some substantial improvements, C++
may go the way of the Pascal/Modula/Ada family of languages,
marginalized and nearly forgotten.  C++ is losing market share.

     The move to Java and C# is fueled by the reliability
problems of programs written in the C/C++ family of languages.
I see nothing being done to remedy this.

     The question for the C++ community is "how can the stability
of C/C++ programs be increased to that of Java/C# programs."
Nobody seems to be working seriously on this, other than
the "bolt on garbage collection" people.  I did some work
in that direction (look at my "strict C++" proposals), but
there may be a better way.

     Every day, thousands of programs and systems crash
because C++ hasn't fixed this problem.  This is unnecessary,
and perhaps irresponsible.

     It's not impossble to make a big change.  Look at FORTRAN.
It's had two major incompatible modernizations, in 1977 and 1995.
That's why it's still around.

     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                       ]

John Nagle <nagle@animats.com> writes:

[...]

|      Every day, thousands of programs and systems crash
| because C++ hasn't fixed this problem.  This is unnecessary,
| and perhaps irresponsible.

Those are strong words.  Undoubtely, it would help to have some idea
of what is actually happening if you could give a list of those
thousands of programs and systems that crash because C++ hasn't fixed
this problem.  Thanks.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

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

John Nagle wrote:
> Francis Glassborow wrote:
>
>> In article <3CEBF357.2090109@yahoo.com>, David Rasmussen
>> <pinkfloydhomer@yahoo.com> writes
>>
>>> OK. That's too bad, since the language needs dramatic changes. What
>>> will it gain discussing minor changes and ratifying them in 2008? Why
>>> not make major changes where major changes are neeeded? Our knowledge
>>> of programming languages and design paradigms is growing rapidly in
>>> these years. What is C++'s ambition? What role will C++ have in 2010
>>> if only small insignificant changes have been made, while the rest of
>>> the world have gained a lot of insight in the meantime? Will present
>>> day C++ be the most modern C++-like thing imaginable in 2010?
>>> Probably not...
>>
>>
>>  This paragraph is entirely your characterisation of what will happen.
>> We certainly have not ruled out major enhancements but the barrier is
>> certainly higher for those. You have to demonstrate that there will be
>> a commensurate gain to justify the pain of making such extensions. You
>> must also demonstrate that that pain does not include breaking large
>> amounts of existing code (and very definitely not silently changing
>> the meaning of existing code.)
>
>
>
>     C++ is in more trouble than the C++
> committee realizes.  Without some substantial improvements, C++
> may go the way of the Pascal/Modula/Ada family of languages,
> marginalized and nearly forgotten.  C++ is losing market share.
>
>     The move to Java and C# is fueled by the reliability
> problems of programs written in the C/C++ family of languages.
> I see nothing being done to remedy this.
>

I agree.

>     The question for the C++ community is "how can the stability
> of C/C++ programs be increased to that of Java/C# programs."
> Nobody seems to be working seriously on this, other than
> the "bolt on garbage collection" people.  I did some work
> in that direction (look at my "strict C++" proposals), but

Where can I read about those?

> there may be a better way.
>
>     Every day, thousands of programs and systems crash
> because C++ hasn't fixed this problem.  This is unnecessary,
> and perhaps irresponsible.
>

Agreed.

>     It's not impossble to make a big change.  Look at FORTRAN.
> It's had two major incompatible modernizations, in 1977 and 1995. That's
> why it's still around.
>

Exactly.

/David

---
[ 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 <3CEFD282.9010106@animats.com>, John Nagle
<nagle@animats.com> writes
>    C++ is in more trouble than the C++
>committee realizes.  Without some substantial improvements, C++
>may go the way of the Pascal/Modula/Ada family of languages,
>marginalized and nearly forgotten.  C++ is losing market share.
a) That is your opinion but where is your research
b) Those that move to Java or C# do so because those languages meet
certain needs. Those that stay with C++ do so because they need the
things C++ provides. Computer languages are just tools and though a
craftsman may value an old tool that is not a reason for not using a
newer one. It is a reason for not destroying the old tool in an attempt
at making it more like a newer one.

>    The move to Java and C# is fueled by the reliability
>problems of programs written in the C/C++ family of languages.
>I see nothing being done to remedy this.

It is in the nature of things that people see the good side of new
things quickly (or they fail immediately) but take time to discover the
down side of them. The instability of Java more than compensates for any
putative reliability gains in programmes written in it. The size of its
libraries coupled with the poor quality of quite a few of them causes
its own problems.

>
>    The question for the C++ community is "how can the stability
>of C/C++ programs be increased to that of Java/C# programs."
>Nobody seems to be working seriously on this, other than
>the "bolt on garbage collection" people.  I did some work
>in that direction (look at my "strict C++" proposals), but
>there may be a better way.

Read 'Bitter Java' by Bruce Tate, I think you might then find that good
Java programmers know that all is not well.

>
>    Every day, thousands of programs and systems crash
>because C++ hasn't fixed this problem.  This is unnecessary,
>and perhaps irresponsible.

No, do not blame the tool blame the tool user.
>
>    It's not impossble to make a big change.  Look at FORTRAN.
>It's had two major incompatible modernizations, in 1977 and 1995.
>That's why it's still around.

And over that period of time it fell from being a widely used general
purpose language to one mainly used for computationally intense
programs. Fortran now has a major advantage in that it is only used by
those who actually know their problem domain and have more than a little
understanding of how to use Fortran in it. It would be very much easier
of C++ programmers were similarly skilled.



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

Hyman Rosen wrote:
> David Rasmussen wrote:
>
>> While the idea of keeping the problem/solution relationship in mind
>> while proposing new language features is a good idea, I can't
>> understand this religious insisting on lack of generality.
>
>
> He's not insisting on a lack of generality. He's saying that the next
> version of C++ is going to be concentrating on solving problems within
> current C++, not making dramatic changes to the language. That means
> that your favorite feature from another language is unlikely to be
> added.

OK. That's too bad, since the language needs dramatic changes. What will
it gain discussing minor changes and ratifying them in 2008? Why not
make major changes where major changes are neeeded? Our knowledge of
programming languages and design paradigms is growing rapidly in these
years. What is C++'s ambition? What role will C++ have in 2010 if only
small insignificant changes have been made, while the rest of the world
have gained a lot of insight in the meantime? Will present day C++ be
the most modern C++-like thing imaginable in 2010? Probably not...

> Furthermore, most of the "proposals" that show up are poorly thought-out.
> They seek to scratch some specific itch, but they seldom include a
> proper analysis of how the feature interacts with C++ as a whole. They
> are mostly requests for someone else to do the hard work, so it's not
> surprising that the someone elses are saying "no".
>

I can understand that. Still, it is valuable in itself to point out a
good idea, even if you don't implement it. I am not saying that every
idea here is brilliant. But some ideas are so important that the
"community" should see the importance of doing the hard work anyway.

>  > For instance, if you are proposing a well thought-out, well-designed
>  > general compile-time language on top of C++
>
> If you could actually provide this, somone might listen.

That's what I am talking about. I could be a very experienced designer
and programmer that sees the need for such a thing in C++ for very good
reasons, but at that doesn't make me an expert on language design. There
is a difference between the language user and the language designer. The
good ideas can easily come from the users, while the development of the
language is done by the designers. If a language was developed only
by language designers (people with knowledge of language design) ,
or only by language users, it will have problems (like most languages
have).
If I were to develop a language, I would round up a lot of good language
designers and a lot of experienced language users. Then I would let all
the users brainstorm and hear all there complaints and wishes. That's
what _they're_ good at. Then I would let the language designer discuss
how to generalize and synthesize all this information, and come up with
solutions, that's what _they're_ good at. I am a language user. I can
easily see defects in languages, and have wishes about languages, but
that doesn't mean that I am especially good at make language design
decisions.

/David

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

ros0230@iperbole.bologna.it (Natale Fietta) wrote:

>On Tue, 21 May 2002 18:36:53 GMT, Steve Heller <steve@steveheller.com>
>wrote:
>
>>  My proposal has nothing to do with namespaces. In the grand old
>>tradition of C++ keyword overloading, I'm reusing the keyword "using"
>>to mean something almost, but not quite, completely unlike its current
>>uses.
>
>Are you sure ?
>
>If i understand it correctly the "using derivation" proposal mean that
>having this base class:
>
>class Base
>{
>public:
>    Base(some_params);
>    void publicFunc();
>protected:
>    void protectedFunc();
>private:
>    void privateFunc();
>};
>
>then this derivation:
>
>class Derived : using Base
>{
>};
>
>it is a short-hand for this:
>
>class Derived : private Base
>{
>public:
>    Derived(some_params) : Base(some_params) {}
>    using Base::publicFunc;
>protected:
>    using Base::protectedFunc;
>};
>
>so i see it as a natural extension of a current use of "using", not a
>totally (not even partially) unrelated new use of the same keyword.

  Sounds good to me, although I did not have that in mind (at least
consciously) when proposing "using" as the keyword for this type of
derivation. I guess my unconscious is smarter than my conscious!

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt

---
[ 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:K3CTUUBrds68Ew6o@robinton.demon.co.uk...
> In article <ace1in$ho1$1@paris.btinternet.com>, Mark Jordan
> <Mark_Jordan@nospam.btinternet.com> writes
> >"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message >
> ><Mark_Jordan@nospam.btinternet.com> writes
> >> >> >
> >> >> >What we need is some kind of higher level "wrap" operator to automatically
> >> >> >generate inline forwarding functions.
> >> >> >
> >> >Where's the draft proposal outlining a better solution?
> >>
> >> Be patient. I certainly want to look at all the options before producing
> >> a specific proposal.
> >
> >Can you at least enumerate the options then?
>
> Not easily. We have varying concepts of using directives either applied
> to private base or to a member, we have Steve Heller's using
> inheritance, we have strong typedefs with extensions just to mention the
> ones that come to mind. The point is that each possibility meets the
> central issue but has different utility and side benefits as well as
> problems. If you want to write a paper detailing the problem, proposing
> a solution and examining its implications to the rest of the language,
> please do so. OTOH if you just want to pick holes in someone else's
> work, you will have to wait. Some of us have a lot of different things
> to do :-)

All I am after is some information on potential new
C++ features. Is there a central website we can go to
look at current proposals and ideas?

I'm certainly not going to come up with my own paper
and ideas without reading others thoughts on the same
issue beforehand!


---
[ 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 Fri, 17 May 2002 17:02:03 GMT, Garry Lancaster <glancaster@ntlworld.com> wrote:
[...]
> Garry Lancaster:
> > >I'm not sure what you mean by that. You need much more than
> > >consistent type names for portable code and producing portable
> > >serialised objects, but it's one step in the right direction.
>
> > If it is then I cannot see any solution that could be put into an
> > ISO standard. It would need an identifier registration scheme,
> > something like the registration scheme for URL domain names (enter
> > lawyers, stage right).
>
>  Before moving to a more exotic scheme we need to thoroughly examine
>  the more obvious alternatives. What is wrong with std::vector<int>
>  being known as "std::vector<int>"?

What do you do with

   std::vector<int32_t>

where on platform A you have

   typedef int int32_t;

while on platform B you have

   typedef long int32_t;

?

Being known on platform A as "std::vector<int>" and on platform B as
"std::vector<long>" won't result in portable serialised objects.

The other seemlingly obvious alternative, namely being known as
"std::vector<int32_t>" on both platforms, is not viable, because
e.g. on platform A std::vector<int> and std::vector<int32_t> are
really the same type, and therefore need to have the same type name.

-- Niklas Matthies
--
"Daddy, why doesn't this magnet pick up this floppy disk?"

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

David Rasmussen wrote:
> OK. That's too bad, since the language needs dramatic changes.

C++ is what it is. Even assuming that you are correct, those
changes have to be thoroughly specified, with impact on the
whole language spelled out. Otherwise, if you want to use a
different language, do so, and if the language you want to
use doesn't exist yet, create it.

> But some ideas are so important that the "community" should
 > see the importance of doing the hard work anyway.

I am reminded that professional authors are not infrequently
approached by amateurs who claim to have a terrific idea for
a book, and are willing to split the proceeds 50-50 if the
author will write it.

> The good ideas can easily come from the users

It's the "good ideas coming from users" that have turned C++
into the crufty syntactic mess that it is now. Contrast it
with Ada, whose language design was essentially the work of
a single language designer (Jean Ichbiah).

---
[ 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 <ach3u8$lug$1@knossos.btinternet.com>, Mark Jordan
<Mark_Jordan@nospam.btinternet.com> writes
>All I am after is some information on potential new
>C++ features. Is there a central website we can go to
>look at current proposals and ideas?

At the moment? No. From the library aspect, looking at Boost will cover
much of the ground. For core aspects we are in the process of refining
schema for proposals and also half a dozen of us are tasked with writing
sample proposals. These should become available in the Autumn (Fall).


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

In article <3CEBF357.2090109@yahoo.com>, David Rasmussen
<pinkfloydhomer@yahoo.com> writes
>OK. That's too bad, since the language needs dramatic changes. What
>will it gain discussing minor changes and ratifying them in 2008? Why
>not make major changes where major changes are neeeded? Our knowledge
>of programming languages and design paradigms is growing rapidly in
>these years. What is C++'s ambition? What role will C++ have in 2010 if
>only small insignificant changes have been made, while the rest of the
>world have gained a lot of insight in the meantime? Will present day
>C++ be the most modern C++-like thing imaginable in 2010? Probably not...
  This paragraph is entirely your characterisation of what will happen.
We certainly have not ruled out major enhancements but the barrier is
certainly higher for those. You have to demonstrate that there will be a
commensurate gain to justify the pain of making such extensions. You
must also demonstrate that that pain does not include breaking large
amounts of existing code (and very definitely not silently changing the
meaning of existing code.)

I very much doubt if all the changes will be insignificant, they just
might not be the ones that strongly impact on your code.

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

David Rasmussen <pinkfloydhomer@yahoo.com> writes:

|>  Hyman Rosen wrote:
|>  > David Rasmussen wrote:

|>  >> While the idea of keeping the problem/solution relationship in
|>  >> mind while proposing new language features is a good idea, I
|>  >> can't understand this religious insisting on lack of
|>  >> generality. |> > He's not insisting on a lack of generality.
|>  >> He's saying that the next |> > version of C++ is going to be
|>  >> concentrating on solving problems within |> > current C++, not
|>  >> making dramatic changes to the language. That means |> > that
|>  >> your favorite feature from another language is unlikely to be
|>  >> |> > added.

|>  OK. That's too bad, since the language needs dramatic changes.

The language needs a lot of things. Like stability, and compilers that
implement it correctly.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

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

David Rasmussen <pinkfloydhomer@yahoo.com> wrote in message news:<3CEB5473.2090403@yahoo.com>...
> Francis Glassborow wrote:
> > In article <acde3b$msi$1@pegasus.csx.cam.ac.uk>, Mark Jordan
> > <markj@mrc-lmb.cam.ac.uk> writes

> While the idea of keeping the problem/solution relationship in mind
> while proposing new language features is a good idea, I can't understand
> this religious insisting on lack of generality. Sometimes, a good way to
> do such things, is to step back and look at the bigger picture, and just
> brainstorm away. For instance, if you are proposing a well thought-out,
> well-designed general compile-time language on top of C++, instead of
> the template hacking, how can you possibly express that with an example
> solution? Of course, you could give some examples where this could be
> useful, but the point of such a general thing is that it is... well,
> general.

The point isn't even that feature X isn't useful. There's an unbounded
set of useful thing, from which an infinitely small subset will make it
into C++ (or any other language, for that matter).

What does matter in the selection is what features help programmers.
Features help programmers in only one way: to make solving their
real-world problems easier. Therefore the benefits should be judged
by a presentation of such problems.

Even so, benefits alone do not mean a feature makes it into C++0x;
there are also costs, both to compiler writers and language users.

To take your point: if your proposal is well thought out, you could
present an alternative implementation of Loki using your features,
showing that it is easier to understand, and compiles with your
patches to GCC.

Regards,
--
Michiel Salters

---
[ 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:
> David Rasmussen wrote:
>
>> OK. That's too bad, since the language needs dramatic changes.
>
>
> C++ is what it is. Even assuming that you are correct, those
> changes have to be thoroughly specified, with impact on the
> whole language spelled out. Otherwise, if you want to use a
> different language, do so, and if the language you want to
> use doesn't exist yet, create it.
>

I want to, but I am not a language designer. And if I did, my starting
point would be C++, which I would repair.

>> But some ideas are so important that the "community" should
>
>  > see the importance of doing the hard work anyway.
>
> I am reminded that professional authors are not infrequently
> approached by amateurs who claim to have a terrific idea for
> a book, and are willing to split the proceeds 50-50 if the
> author will write it.
>

There are no proceeds here. Just people who want a language that takes
advantage of the knowledge we have today, and not 20 years ago.

>> The good ideas can easily come from the users
>
>
> It's the "good ideas coming from users" that have turned C++
> into the crufty syntactic mess that it is now. Contrast it

No it isn't. Most of the very bad things of C++ comes from the fact that
Bjarne Stroustrup decided to base C++ on C. This had some short-term
positive implications (that he have described himself), but it has loads
of long-term negative implications. And now that compiler vendors and
writers have C++ compilers and are willing to follow language changes,
why not change the language? Most ideas coming from users are not of the
nature "lets add all these features without thinking", but rather like
"let's restrict or remove this old feature that leads to errors and
complicated syntax etc." or "let's add this feature that is totally
orthorgonal and non-mandatory, and thus won't affect old work" (like the
_possibility_ of contracts etc.)


Explain to me why it is better to do the kind of hacking found in Modern
C++ Design, rather than just having the language supporting these kinds
of things more naturally. Is it because you love obsurities and bugs?

> with Ada, whose language design was essentially the work of
> a single language designer (Jean Ichbiah).

Sure. C++ could use a dictator that singlehandedly cleaned up the
language, instead of a slooooooow commitee that can't decide anything.
Slow and careful development of a language, like the commitee is doing,
is important, but only when the language have reached a certain level of
maturity and the most obvious design errors have been corrected. If C++
is nearly frozen now, with only insignificant changes every 10 years or
so, it's dead.

/David

---
[ 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
<slrnaeo4l3.s3.news_comp.std.c++_expires-2002-07-01@nightrunner.nmhq.net>
, Niklas Matthies <news_comp.std.c++_expires-2002-07-01@nmhq.net> writes
>The other seemlingly obvious alternative, namely being known as
>"std::vector<int32_t>" on both platforms, is not viable, because
>e.g. on platform A std::vector<int> and std::vector<int32_t> are
>really the same type, and therefore need to have the same type name.

I doubt it. The problem with typedefs used this way is that they break
portability. If we need a 32-bit integer type, we almost certainly need
(in C++ rather than C) a real 32-bit integer type. I think we need some
mechanism for strong typedefs (i.e. ones that don't just alias existing
types, but create new ones) Unfortunately the conversion rules for
integer types are complicated so that it can matter whether a type
behaves like a long or behaves like an int.


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

> There are no proceeds here. Just people who want a language that takes
> advantage of the knowledge we have today, and not 20 years ago.

Just what I was saying - C++ in some ways is still stuck in the 70's.

> Explain to me why it is better to do the kind of hacking found in Modern
> C++ Design, rather than just having the language supporting these kinds
> of things more naturally. Is it because you love obsurities and bugs?

In some ways, people (well I do, anyway) find it a challenge to come up with
solutions that initialilly
seemed impossible in the language. But the question is whether such "heroic"
programming belongs in
production code...

> Sure. C++ could use a dictator that singlehandedly cleaned up the
> language, instead of a slooooooow commitee that can't decide anything.
> Slow and careful development of a language, like the commitee is doing,
> is important, but only when the language have reached a certain level of
> maturity and the most obvious design errors have been corrected. If C++
> is nearly frozen now, with only insignificant changes every 10 years or
> so, it's dead.

Agreed.
It is hard to decide to break existing code. In my opinion it's like the
x86 - no matter what,
P4 is still nothing but a glorified 80x86... It supports the latest hardware
idioms, but in fact
is still in the 80's.





---
[ 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:
> I think we need some
> mechanism for strong typedefs

I agree 100%. Also, the possibility of defining strongly typed enums
that are _not_ ints, but their own type. Somehow we would have to find a
way to use them in for() loops. Both of these features could be added
without wrecking existing code.

/David

---
[ 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 <hyrosen@mail.com> writes:

|>  David Rasmussen wrote:
|>  > OK. That's too bad, since the language needs dramatic changes.

|>  C++ is what it is. Even assuming that you are correct, those
|>  changes have to be thoroughly specified, with impact on the whole
|>  language spelled out. Otherwise, if you want to use a different
|>  language, do so, and if the language you want to use doesn't exist
|>  yet, create it.

The most important point here is that C++ is.  Already.  Any changes
better not break my code.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

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

> > Garry Lancaster:
> >  Before moving to a more exotic scheme we need to thoroughly examine
> >  the more obvious alternatives. What is wrong with std::vector<int>
> >  being known as "std::vector<int>"?

Niklas Matthies:
> What do you do with
>
>    std::vector<int32_t>
>
> where on platform A you have
>
>    typedef int int32_t;
>
> while on platform B you have
>
>    typedef long int32_t;
>
> ?
>
> Being known on platform A as "std::vector<int>" and on platform B as
> "std::vector<long>" won't result in portable serialised objects.

That's a bit strong, but certainly it requires more
sophisticated serialization code in order to behave
appropriately. Simpler solutions are best.

There are really two points here:

First, what to do with typedef-ed names in general? I don't
think there is much choice but to ignore them (and use
the real underlying type name) given the way RTTI works,
but this is probably the choice I'd make anyway.

Second, what to do about the C99 fixed size types? I'm quite
happy to support these, but from the point of view of
portable type names and overloading (neither of which
are a problem in C of course) implementing them as
typedefs for the built-ins, as C99 requires, is a poor idea.

By the way, one idea floating about the British C++ panel
at the moment is to add strong typedefs (that actually
create a new type) to the language. This may give us
some new options for dealing with this situation.

[snip]

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

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

David Rasmussen <pinkfloydhomer@yahoo.com> wrote:

>Francis Glassborow wrote:
>> I think we need some
>> mechanism for strong typedefs
>
>I agree 100%. Also, the possibility of defining strongly typed enums
>that are _not_ ints, but their own type. Somehow we would have to find a
>way to use them in for() loops. Both of these features could be added
>without wrecking existing code.

  Add my vote for all of these proposals.

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt

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

Michiel.Salters@cmg.nl (Michiel Salters) writes:

|>  David Rasmussen <pinkfloydhomer@yahoo.com> wrote in message
|>  news:<3CEB5473.2090403@yahoo.com>...
|>  > Francis Glassborow wrote:
|>  > > In article <acde3b$msi$1@pegasus.csx.cam.ac.uk>, Mark Jordan
|>  > > <markj@mrc-lmb.cam.ac.uk> writes
|>  > While the idea of keeping the problem/solution relationship in
|>  > mind while proposing new language features is a good idea, I
|>  > can't understand this religious insisting on lack of
|>  > generality. Sometimes, a good way to do such things, is to step
|>  > back and look at the bigger picture, and just brainstorm
|>  > away. For instance, if you are proposing a well thought-out,
|>  > well-designed general compile-time language on top of C++,
|>  > instead of the template hacking, how can you possibly express
|>  > that with an example solution? Of course, you could give some
|>  > examples where this could be useful, but the point of such a
|>  > general thing is that it is... well, general.

|>  The point isn't even that feature X isn't useful. There's an
|>  unbounded set of useful thing, from which an infinitely small
|>  subset will make it into C++ (or any other language, for that
|>  matter).

More importantly, perhaps, there is a distinction between useful, and
generally useful.  I've mentionned, for example, that the CRC classes
of Boost probably aren't candidates for standardization.  There are
definitly useful, if you need to calculate a CRC, but they aren't
generally useful -- most programs don't need to calculate CRC.

Some thing like threading is more generally useful -- while not every
application needs it, a lot of applications, in different application
domains, do.  So I would guess that it is a very good candidate for
standardization.

Finally, in addition to general usefulness, some consideration must be
given to the alternatives.  If there is no way to implement something
portably in the language, it is a good candidate for standardization,
even if it isn't generaly useful.  A lot of numerics come under this
category, I think -- more programs probably don't have to fiddle with
rounding modes, but unless the standard specifies an interface to do
it, there is no portable solution.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

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

David Rasmussen <pinkfloydhomer@yahoo.com> writes:

|>  >> The good ideas can easily come from the users
|>  > It's the "good ideas coming from users" that have turned C++
|>  > into the crufty syntactic mess that it is now. Contrast it

|>  No it isn't. Most of the very bad things of C++ comes from the
|>  fact that Bjarne Stroustrup decided to base C++ on C. This had
|>  some short-term positive implications (that he have described
|>  himself), but it has loads of long-term negative implications. And
|>  now that compiler vendors and writers have C++ compilers and are
|>  willing to follow language changes, why not change the language?
|>  Most ideas coming from users are not of the nature "lets add all
|>  these features without thinking", but rather like "let's restrict
|>  or remove this old feature that leads to errors and complicated
|>  syntax etc." or "let's add this feature that is totally
|>  orthorgonal and non-mandatory, and thus won't affect old work"
|>  (like the _possibility_ of contracts etc.)

I've *never* found a user who wanted to remove an old feature.  In
practice, when a language standard removes a feature that corresponds
to existing practice, that part of the standard is ignored, and
implementations continue to support the old practice.  Users have
existing code, and none of them can afford to rewrite all of their
applications just because the committee decides that what they had
done before wasn't clean.

|>  Explain to me why it is better to do the kind of hacking found in
|>  Modern C++ Design, rather than just having the language supporting
|>  these kinds of things more naturally. Is it because you love
|>  obsurities and bugs?

Why support the kind of hacking found in Modern C++ Design at all, in
any way, shape form or fashion?  I've been writing C++ for years
without it, and always managed to make things work.

There is a middle road, and I think C++, for all its warts, has found
it.  There are a lot of potentially good things that the language
doesn't support directly.  But the language doesn't prevent "hacking"
them, as Andrei as shown.  Now, I certainly don't need these things in
my existing code, and I can easily continue as I have, without them.
More importantly, I don't have any real experience with them, to know
just how good they really are -- the ideas sound very good, but how
well do they work in practice.

Well, thanks to Andrei's experimentation, and the freedom the language
gives, I can experiment with the ideas, and find out.  Maybe some of
the ideas won't turn out to be so good in practice.  Maybe others will
turn out to be even better than we thought.  But once we have some
concrete experience, to really know, we can talk about incorporating
them in some way in the language.  Not before.

For the moment, what I, as a user, miss most in C++ is stability and
portability.  And radical changes in the core language aren't the way
to achieve this.

|>  > with Ada, whose language design was essentially the work of a
|>  > single language designer (Jean Ichbiah).

|>  Sure. C++ could use a dictator that singlehandedly cleaned up the
|>  language, instead of a slooooooow commitee that can't decide
|>  anything. Slow and careful development of a language, like the
|>  commitee is doing, is important, but only when the language have
|>  reached a certain level of maturity and the most obvious design
|>  errors have been corrected. If C++ is nearly frozen now, with only
|>  insignificant changes every 10 years or so, it's dead.

Do you mean dead, like Fortran and Cobol?  (I think that there is
still more new code written in Cobol than in any other language.  And
I certainly wouldn't say that all, or even any, of the design errors
in Cobol have been corrected.)

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

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

Mark Jordan wrote:
> "John Nagle" <nagle@animats.com> wrote in message
> news:3CDF5E87.6050704@animats.com...
>
>>     The "include" approach to interfaces fosters too
>>much unwanted interdependency in large projects.  Changing
>>the private part of a class forces a recompile of the
>>class's users.  On large projects, this generates
>>huge amounts of irrelevant recompile activity, and then
>>trying to avoid those recompiles warps designs out of shape.
>
>
> I second this. It's my biggest gripe about C++. I'd really like a clean
> physical separation of interface from implementation to avoid the
> issues above. Other languages have had it for decades!

C++ offers it to you in multiple ways, either with a "pimpl"
(or whatever the latest name for envelope-letter or handle-body
in its general form is), or by using inheritance from an
interface.  The fact that it allows you to avoid the (maybe
small) overhead that this layer of abstraction gives does
not mean that you are forced into tight coupling.  Are you
wanting to take features away from C++ because people use
C++ to implement their bad designs, or because they use it
to implement their designs badly?

I agree that I'd prefer C++ to have a model for using separately
compiled code which is rather more sophisticated than "#include",
but I don't think that this is one of the reasons for doing so.

--
James Dennett <jdennett@acm.org>

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

"Mark Jordan" <markj@mrc-lmb.cam.ac.uk> wrote:

>"Pete Becker" <petebecker@acm.org> wrote in message
>news:3CDA7DBA.8343B482@acm.org...
>> Tom Puverle wrote:
>> >
>> > I am trying to put together a wish list of language extensions that
>people
>> > would like to see in C++0x.
>>
>> Let me suggest a different approach. Instead of asking about language
>> features, put together a list of problems that aren't easily solved in
>> the language as it exists today. Language features aren't an end in
>> themselves, but are a way of solving problems. Focusing initially on
>> problems rather than solutions will lead to a better set of solutions.
>
>OK, here's one problem, there's too much tedius typing required for
>assembling components via composition.
>
>What we need is some kind of higher level "wrap" operator to automatically
>generate inline forwarding functions.
>
>class A
>{
>   public:
>    int foo1();
>    int foo2();
>};
>
>class B
>{
> public:
>   int foo0();
>
>  private:
>   wrap A a;     // Exports interface of A straight through to interface of
>B, but don't expose 'a' itself.
>};
>
>int main()
>{
>   B b;
>   b.foo0();
>   b.foo1();
>   b.foo2();
>   return 0;
>}
>
>It should work for pointer members too. Any comments?

  This accomplishes essentially the same result as my "using"
inheritance proposal.

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt


======================================= MODERATOR'S COMMENT:
 Please do not quote the complete text of a significantly
sized message in order to just add one sentence, but rather trim
down the material to only what is needed for context.  Thanks.


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

Felix Shvaiger wrote:
>
> I DO NOT WONT TO RESTRICT how implementors of derived classes provide some
> capability,
> but I DO WANT to give him a BOLD HINT that implementation of virtual method
> in base class
> probably (or almost sure) WOLL NOT WORK CORRECT in derived class -
> so it is highly recommended to provide another implementation specific for
> derived class.
>
> You are quite right - keyword 'noinherit' ( or may be 'explicit' is good
> enough) must be repeated
> in derived class in order to continue this noinherit behavior. So your
> example has to be rewrited:
>
> class Base
> {
> public:
> virtual string getClassName() = MUST_OVERRIDE { ..... };
> };
>
> class Intermediate : public Base
> {
> public:
> string getClassName() { return getRealName(); }
> virtual string getRealName() = MUST_OVERRIDE { ..... };
> };
>
> class Derived : public Intermediate
> {
> public:
> virtual string getRealName() = MUST_OVERRIDE { ..... };
> };
>

I misunderstood your example. Replace 'MUST_OVERRIDE' with '= 0'. It's
already in the language.

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

"Steve Heller" <steve@steveheller.com> wrote in message
> >
> >What we need is some kind of higher level "wrap" operator to automatically
> >generate inline forwarding functions.
> >
>
>   This accomplishes essentially the same result as my "using"
> inheritance proposal.

References please Steve?
Isn't "using" already rather overloaded for namespaces?

Cheers,
Mark.



---
[ 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
> >
> >What we need is some kind of higher level "wrap" operator to automatically
> >generate inline forwarding functions.
> >
> Quite a few of us understand the problem but I suspect we can do better
> for a solution.

Great!
Where's the draft proposal outlining a better solution?

Cheers,
Mark.



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

"Mark Jordan" <Mark_Jordan@nospam.btinternet.com> wrote:

>"Steve Heller" <steve@steveheller.com> wrote in message
>> >
>> >What we need is some kind of higher level "wrap" operator to automatically
>> >generate inline forwarding functions.
>> >
>>
>>   This accomplishes essentially the same result as my "using"
>> inheritance proposal.
>
>References please Steve?
>Isn't "using" already rather overloaded for namespaces?

  Not in the way I've suggested, e.g.,

class A : using B

would mean that objects of type A could be called with functions
declared in B, but A objects could not be substituted for B objects.

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt

---
[ 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 Dennett" <jdennett@acm.org> wrote in message news:3CE9510C.9080603@acm.org...
> Mark Jordan wrote:
> > "John Nagle" <nagle@animats.com> wrote in message
> > news:3CDF5E87.6050704@animats.com...
> >
> >>     The "include" approach to interfaces fosters too
> >>much unwanted interdependency in large projects.  Changing
> >>the private part of a class forces a recompile of the
> >>class's users.  On large projects, this generates
> >>huge amounts of irrelevant recompile activity, and then
> >>trying to avoid those recompiles warps designs out of shape.
> >
> > I second this. It's my biggest gripe about C++. I'd really like a clean
> > physical separation of interface from implementation to avoid the
> > issues above. Other languages have had it for decades!
>
> C++ offers it to you in multiple ways, either with a "pimpl"
> (or whatever the latest name for envelope-letter or handle-body
> in its general form is), or by using inheritance from an
> interface.

Yes, I know this, but I don't see why I should have to
write all those forwarding functions to achieve something
so fundamental. Do you enjoy writing code in assembly
language? ;-)

> Are you
> wanting to take features away from C++ because people use
> C++ to implement their bad designs, or because they use it
> to implement their designs badly?

I don't understand what you are saying. What features
would such a proposal take away?

> I agree that I'd prefer C++ to have a model for using separately
> compiled code which is rather more sophisticated than "#include",
> but I don't think that this is one of the reasons for doing so.

Not alone, but one of many nails in the coffin ;-)

Cheers,
Mark.


---
[ 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 <acc6o6$rf1$1@knossos.btinternet.com>, Mark Jordan
<Mark_Jordan@nospam.btinternet.com> writes
>"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
>> >
>> >What we need is some kind of higher level "wrap" operator to automatically
>> >generate inline forwarding functions.
>> >
>> Quite a few of us understand the problem but I suspect we can do better
>> for a solution.
>
>Great!
>Where's the draft proposal outlining a better solution?

Be patient. I certainly want to look at all the options before producing
a specific proposal.


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

"Pete Becker" <petebecker@acm.org> wrote in message
news:3CE98786.1EE2B373@acm.org...
> Felix Shvaiger wrote:
> >
> > I DO NOT WONT TO RESTRICT how implementors of derived classes provide
some
> > capability,
> > but I DO WANT to give him a BOLD HINT that implementation of virtual
method
> > in base class
> > probably (or almost sure) WOLL NOT WORK CORRECT in derived class -
> > so it is highly recommended to provide another implementation specific
for
> > derived class.
> >
> > You are quite right - keyword 'noinherit' ( or may be 'explicit' is good
> > enough) must be repeated
> > in derived class in order to continue this noinherit behavior. So your
> > example has to be rewrited:
> >
> > class Base
> > {
> > public:
> > virtual string getClassName() = MUST_OVERRIDE { ..... };
> > };
> >
> > class Intermediate : public Base
> > {
> > public:
> > string getClassName() { return getRealName(); }
> > virtual string getRealName() = MUST_OVERRIDE { ..... };
> > };
> >
> > class Derived : public Intermediate
> > {
> > public:
> > virtual string getRealName() = MUST_OVERRIDE { ..... };
> > };
> >
>
> I misunderstood your example. Replace 'MUST_OVERRIDE' with '= 0'. It's
> already in the language.

It will prevent class Base from being instantiated.
I want class Base be able to produce instances
(not abstract) because Base::getClassName
works correct for class Base and
objects of class Base will work just fine.
But I want to prevent class Intermediate from being
instantiated if it doesn't override getClassName because
Base::getClassName works incorrect for class Intermediate
and therefore objects of such class will be broken.

The same for Intermediate::getRealName
and Derived::getRealName.

==============
Felix Shvaiger
fshvaige@cisco.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                       ]

"Steve Heller" <steve@steveheller.com> wrote in message
news:lhjjeu8nfdm6pllacl6cjtsbms7rgjurfs@4ax.com...
> "Mark Jordan" <Mark_Jordan@nospam.btinternet.com> wrote:
>
> >"Steve Heller" <steve@steveheller.com> wrote in message
> >> >
> >> >What we need is some kind of higher level "wrap" operator to
automatically
> >> >generate inline forwarding functions.
> >>
> >>   This accomplishes essentially the same result as my "using"
> >> inheritance proposal.
> >
> >References please Steve?
> >Isn't "using" already rather overloaded for namespaces?
>
>   Not in the way I've suggested, e.g.,
>
> class A : using B
>
> would mean that objects of type A could be called with functions
> declared in B, but A objects could not be substituted for B objects.

Does "using" have finer granularity, ie at member function level?

For example, I would commonly want to make the constructors
destructors and operators invisible to clients of A. Would there be
any clash with namespaces then?

Cheers,
Mark.


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

> Tom Puverle wrote:
> > I am trying to put together a wish list of language extensions that
people
> > would like to see in C++0x.

Slap me down again, but I have yet more wishes ;-)

1.
Integral language support for preconditions/postconditions and
invariants to help writing more formal and correct software
components.

2.
You know how we have a "this" pointer, well I'd like to see
a "parent" pointer for nested classes. I needed this a while ago
for implementing "attribute-style" member objects. I'm sure
there are many other uses.

class A
{
    public:
      virtual void foo();

 private:
     class B
     {
         void dofoo() { parent->foo(); }
     };
};


3.
The other thing that would be nice is a real compile-time meta-language
built on top of C++. This would help enormously with the generation of
differerent variants of library components at compile time. Using templates
for this is really an ugly hack IMO!

Cheers,
Mark.


---
[ 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 >
<Mark_Jordan@nospam.btinternet.com> writes
> >> >
> >> >What we need is some kind of higher level "wrap" operator to automatically
> >> >generate inline forwarding functions.
> >> >
> >Where's the draft proposal outlining a better solution?
>
> Be patient. I certainly want to look at all the options before producing
> a specific proposal.

Can you at least enumerate the options then?

Thanks,
Mark.



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

"Mark Jordan" <markj@mrc-lmb.cam.ac.uk> wrote:

>"Steve Heller" <steve@steveheller.com> wrote in message
>news:lhjjeu8nfdm6pllacl6cjtsbms7rgjurfs@4ax.com...
>> "Mark Jordan" <Mark_Jordan@nospam.btinternet.com> wrote:
>>
>> >"Steve Heller" <steve@steveheller.com> wrote in message
>> >> >
>> >> >What we need is some kind of higher level "wrap" operator to
>automatically
>> >> >generate inline forwarding functions.
>> >>
>> >>   This accomplishes essentially the same result as my "using"
>> >> inheritance proposal.
>> >
>> >References please Steve?
>> >Isn't "using" already rather overloaded for namespaces?
>>
>>   Not in the way I've suggested, e.g.,
>>
>> class A : using B
>>
>> would mean that objects of type A could be called with functions
>> declared in B, but A objects could not be substituted for B objects.
>
>Does "using" have finer granularity, ie at member function level?
>
>For example, I would commonly want to make the constructors
>destructors and operators invisible to clients of A. Would there be
>any clash with namespaces then?

  My proposal has nothing to do with namespaces. In the grand old
tradition of C++ keyword overloading, I'm reusing the keyword "using"
to mean something almost, but not quite, completely unlike its current
uses.

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt

---
[ 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 <acde3b$msi$1@pegasus.csx.cam.ac.uk>, Mark Jordan
<markj@mrc-lmb.cam.ac.uk> writes
>Slap me down again, but I have yet more wishes ;-)

You still have it the wrong way round. Committee members are not going
to look at feature proposals, only at proposed solutions to problems so
first you have to identify and explain the problem. If you want Eiffel,
use it.



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

Mark Jordan wrote:
>
> 2.
> You know how we have a "this" pointer, well I'd like to see
> a "parent" pointer for nested classes. I needed this a while ago
> for implementing "attribute-style" member objects. I'm sure
> there are many other uses.
>
> class A
> {
>     public:
>       virtual void foo();
>
>  private:
>      class B
>      {
>          void dofoo() { parent->foo(); }
>      };
> };

I'm afraid it's not well defined.

void A::static_member_function()
{
    B b;
    b.dofoo();
}

Now, to which A should the parent pointer of B point?

The situation is worse when B is defined in the public area of A;
anyone could instantiate A::B, in which case B has no parent of type A!

A possible workaround is to initialise B with a pointer or reference
to A through B's constructor:

class A::B
{
    A* parent;
public:
    B(A* a) : parent(a) { }
    void dofoo() { parent->foo(); }
};

A::A(/*...*/) : member_B(this), /*...*/ { /*...*/ }

--
Sungbom Kim <musiphil@bawi.org>

---
[ 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 <acde3b$msi$1@pegasus.csx.cam.ac.uk>, Mark Jordan
> <markj@mrc-lmb.cam.ac.uk> writes
>
>> Slap me down again, but I have yet more wishes ;-)
>
>
> You still have it the wrong way round. Committee members are not going
> to look at feature proposals, only at proposed solutions to problems so
> first you have to identify and explain the problem. If you want Eiffel,
> use it.
>

While the idea of keeping the problem/solution relationship in mind
while proposing new language features is a good idea, I can't understand
this religious insisting on lack of generality. Sometimes, a good way to
do such things, is to step back and look at the bigger picture, and just
brainstorm away. For instance, if you are proposing a well thought-out,
well-designed general compile-time language on top of C++, instead of
the template hacking, how can you possibly express that with an example
solution? Of course, you could give some examples where this could be
useful, but the point of such a general thing is that it is... well,
general. If people in the standards comittee can't see the potential
usefulness of such a general thing, then there's no hope.

Also, a comment like "If you want Eiffel, use it" is not very wise I
think. Why shouldn't C++ have some feature if it makes the language
better, even if the feature comes from another language? Most features
in C++ are stolen from other languages.

I think many of his proposals are very much to the point.

/David

---
[ 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 Tue, 21 May 2002 18:36:53 GMT, Steve Heller <steve@steveheller.com>
wrote:

>  My proposal has nothing to do with namespaces. In the grand old
>tradition of C++ keyword overloading, I'm reusing the keyword "using"
>to mean something almost, but not quite, completely unlike its current
>uses.

Are you sure ?

If i understand it correctly the "using derivation" proposal mean that
having this base class:

class Base
{
public:
    Base(some_params);
    void publicFunc();
protected:
    void protectedFunc();
private:
    void privateFunc();
};

then this derivation:

class Derived : using Base
{
};

it is a short-hand for this:

class Derived : private Base
{
public:
    Derived(some_params) : Base(some_params) {}
    using Base::publicFunc;
protected:
    using Base::protectedFunc;
};

so i see it as a natural extension of a current use of "using", not a
totally (not even partially) unrelated new use of the same keyword.

Regards,
Natale Fietta

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

David Rasmussen wrote:
> While the idea of keeping the problem/solution relationship in mind
> while proposing new language features is a good idea, I can't understand
> this religious insisting on lack of generality.

He's not insisting on a lack of generality. He's saying that the next
version of C++ is going to be concentrating on solving problems within
current C++, not making dramatic changes to the language. That means
that your favorite feature from another language is unlikely to be
added.

Furthermore, most of the "proposals" that show up are poorly thought-out.
They seek to scratch some specific itch, but they seldom include a
proper analysis of how the feature interacts with C++ as a whole. They
are mostly requests for someone else to do the hard work, so it's not
surprising that the someone elses are saying "no".

 > For instance, if you are proposing a well thought-out, well-designed
 > general compile-time language on top of C++

If you could actually provide this, somone might listen.
If you are saying somebody *should* provide this, forget it.
I have not seen any such thing, so I think we're in case two.

---
[ 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 <ace1in$ho1$1@paris.btinternet.com>, Mark Jordan
<Mark_Jordan@nospam.btinternet.com> writes
>"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message >
><Mark_Jordan@nospam.btinternet.com> writes
>> >> >
>> >> >What we need is some kind of higher level "wrap" operator to automatically
>> >> >generate inline forwarding functions.
>> >> >
>> >Where's the draft proposal outlining a better solution?
>>
>> Be patient. I certainly want to look at all the options before producing
>> a specific proposal.
>
>Can you at least enumerate the options then?

Not easily. We have varying concepts of using directives either applied
to private base or to a member, we have Steve Heller's using
inheritance, we have strong typedefs with extensions just to mention the
ones that come to mind. The point is that each possibility meets the
central issue but has different utility and side benefits as well as
problems. If you want to write a paper detailing the problem, proposing
a solution and examining its implications to the rest of the language,
please do so. OTOH if you just want to pick holes in someone else's
work, you will have to wait. Some of us have a lot of different things
to do :-)



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

"Sungbom Kim" <musiphil@bawi.org> wrote in message
news:3CEAF3C2.16698F1E@bawi.org...
> Mark Jordan wrote:
>
> > You know how we have a "this" pointer, well I'd like to see
> > a "parent" pointer for nested classes.
>
> I'm afraid it's not well defined.
>
> The situation is worse when B is defined in the public area of A;
> anyone could instantiate A::B, in which case B has no parent of type A!

Hmm, I see the problem. But maybe the simplest and most logical
solution is just to have parent=0 if there is no parent?

I guess the next question is, is there any way for the compiler to figure
that out?

Cheers,
Mark.


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

> 2.
> You know how we have a "this" pointer, well I'd like to see
> a "parent" pointer for nested classes. I needed this a while ago
> for implementing "attribute-style" member objects. I'm sure
> there are many other uses.
>
> class A
> {
>     public:
>       virtual void foo();
>
>  private:
>      class B
>      {
>          void dofoo() { parent->foo(); }
>      };
> };
>

I don't think this will work in the general case, IMHO. In C++ you can
instantiate inner classes without instantiating the outer class. What object
is "parent" going to refer to then? And how about static instances of inner
classes? Will they have no parent pointer, just like static functions have
no this pointer?



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

"John Nagle" <nagle@animats.com> wrote...
>
>      Marshalling - it's hard to hook up C++ to any of the
> many marshalled calling conventions (DCOM/CORBA/RMI/.NET/etc.)
> without a stub generator or too much manual work.

I wouldn't want to invent "yet another IDL" and require it to be
built into every C++ compiler. On the other hand, it might be
possible permit custom attributes that the compiler ignores but
which another compiler (for your favourite IDL) uses.

Ideally, the C++ compiler would perform the task of "parsing out"
all the difficult C++ syntax, leaving only the declarations needed
to pass on all the attributes. This would simplify the "other"
compiler, perhaps to the point at which existing implementations
could be used. We'd probably need some way of "quoting" text that
isn't a declaration, so that things like tool-specific pragmas
could be included as well.

This isn't very different from how such tools are used today. The
basic problem is how to maintain two sets of declarations that have
to be consistent. The two languages in question, C++ and IDL, are
broadly similar and IDL minus its attributes is almost a subset.

Today I write IDL and try to auto-generate C++, the richer language.
This inevitably leads to loads of "C++ markup" in my IDL, and in
fact I've found it impossible to persuade MIDL (Microsoft's IDL
compiler to generate clean C++ with inline helpers, proper use of
const and the convenience of overloaded names, so I'm reduced to
using the preprocessor and maintaining parallel sets of declarations.
(Either that or I could compromise on my use of C++, but hey, we
don't need yet another reason to avoid all those nice C++ features.)

In future, I'd like to write C++ and auto-generate IDL, a near-
subset. My belief (hope) is that the conversion from C++ to IDL is
mostly a matter of stripping out stuff, rather than transforming.

Example:

    typedef wchar_t const* LPCOLESTR;
    struct "[attribs]" MailRules
    {
        long Add2Killfile("[in,string]" LPCOLESTR s);
        long IsInKillfile("[in,string]" LPCOLESTR s) const;
    };

The compiler would generate the usual code output, but also spit out
a post-processed file containing...

    typedef wchar_t const* LPCOLESTR;
    struct [attribs] MailRules
    {
        long Add2Killfile([in,string] LPCOLESTR s);
        long IsInKillfile([in,string] LPCOLESTR s) const;
    };

Notice that LPCOLESTR is emitted as well, since it is used by MailRules,
even though it carries no attributes.

I dare say my proposed syntax is unworkably cute, but something like
__idl("[attribs]") would probably work, and __idl("[attribs]",tag)
with different values for "tag" could generate files for several other
tools, not just one. Both of these could be hidden by brutal macros
for those with delicate fingers and strong stomachs.

    #define IN __idl("[in]")
    #define STRING __idl("[string]")
    ...
    typedef STRING wchar_t const* LPCOLESTR;
    long IsInKillfile(IN LPCOLESTR s) const;



---
[ 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 article <cinmdukfbf408nnolf8lq6nqrkctmq014g@4ax.com>, Steve Heller
><steve@steveheller.com> writes
>>  I would like the standard to guarantee that deleting a derived class
>>object through a base class pointer will work even if the destructor
>>is not virtual, so long as the derived class adds no data members.
>
>Sorry, but in the context of multiple inheritance and virtual bases that
>does not work. (It is possible to change the layout of a class without
>adding data:
>
>struct X {
>virtual ~X();
>
>// whatever
>};
>
>struct Y {
>
>// whatever
>};
>
>struct Z {
>// whatever
>};
>
>struct A: public Y, virtual public X{
>
>// whatever
>};
>
>struct B: public Z {
>// whatever
>};
>
>
>struct C: public A, public B {
>// whatever
>};
>
>
>Now I believe that in many compilers:
>
>struct D: virtual public X, public C {
>};
>
>Has the same semantics as C but will have a different layout so you
>better not delete either C or D through Y* or Z* variables.

  Ok, then how about this:

"If the derived class does not add any data members, and does not have
multiple base classes, then deletion through the base class pointer
will delete the base class part properly"

or words to that effect?

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt

---
[ 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 Hagan wrote:

> "John Nagle" <nagle@animats.com> wrote...
>
>>     Marshalling - it's hard to hook up C++ to any of the
>>many marshalled calling conventions (DCOM/CORBA/RMI/.NET/etc.)
>>without a stub generator or too much manual work.
>>
>
> I wouldn't want to invent "yet another IDL" and require it to be
> built into every C++ compiler. On the other hand, it might be
> possible permit custom attributes that the compiler ignores but
> which another compiler (for your favourite IDL) uses.


    I was thinking more in terms of "introspection", the ability
of a class to enumerate its own members.  Suppose there was
a built-in function that returned something like an array of
typeinfo for all the data members of a class.  And
one which attempted to apply a specified template function to member
N, with all the necessary checking at compile time.  Then you
could just derive your class from some class that supported
the marshalling operations, and get a "dump as string",
"dump as XML", or "dump as CORBA params" generated.

    That way, C++ doesn't have to understand the marshalling
mechanism.

     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                       ]

>>From: Felix Shvaiger [mailto:fshvaige@cisco.com]
>>Sent: 14 May 2002 09:28
>>To: Tom Puverle
>>Subject: Re: C++0x Wish list

> Some keyword like 'noinherit' which mean,
> that virtual method could not be inherited by
> derived class, but rather must be overrided
> in each direct or undirect derived class.


    I'm not entirely sure what that means.

    I suggest simply prohibiting the overriding of non-virtual functions.
That would seem to provide the functionality requested.  It's almost
always an error when someone overrides a non-virtual function.
On the rare occasions that you really want to do that, you can
use a different function name.

     John Nagle

---
[ 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 <aRNC8.11900$xb4.1931805@news6-win.server.ntlworld.com>,
Garry Lancaster <glancaster@ntlworld.com> writes
>[snip discussion of  making the result of type_info.name()
>compiler independent]
>
>John G. Harris:
>> There may be extra considerations, depending on what is being wished
>> for.
>>
>> - If the application is spread over thousands of computers do we want my
>> mumble::Thing class and your mumble::Thing class in different computers
>> to have different identifiers?
>
>If the classes have the same name (and, although
>this is jumping the gun a bit on whether namespaces
>should be part of the name, assuming they are in
>the same namespace) their type_info.name() should
>be the same. If you wish to add a computer identifier
>to the resulting string, there are plenty of ways of doing
>this. In a serialized representation of an object model
>you'd probably want a computer identifier zero or one
>times rather than repeated as part of every class name.
  <snip>

If having the same identifier doesn't guarantee that interworking is
possible then I don't understand why an ISO-defined identifier would
benefit anyone.

  John
--
John Harris
  mailto:john@jgharris.demon.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                       ]

Howard Gardner <usenet@hgardner.com> wrote:

>Pete Becker wrote:
>> Tom Puverle wrote:
>>
>>>I am trying to put together a wish list of language extensions that people
>>>would like to see in C++0x.
>>
>>
>> Let me suggest a different approach. Instead of asking about language
>> features, put together a list of problems that aren't easily solved in
>> the language as it exists today. Language features aren't an end in
>> themselves, but are a way of solving problems. Focusing initially on
>> problems rather than solutions will lead to a better set of solutions.
>>
>
>Ok, here's one.
>
>Publicly deriving from std::string risks a delete through a base class
>pointer, and so it risks undefined behavior and is a nono. Same is true
>for the containers.
>
>I've seen arguments for and against subclassing those things at all, and
>I've seen arguments for and against adding virtual destructors to them
>in order to support the subclassing. What I haven't seen is a proposal
>to end the argument.
>
>It seems to me that this should do the trick. In fact, it's so glaringly
>obvious that I wonder if I just missed the discussion.
>
>struct no_virtual_destructor{};
>
>struct virtual_destructor{ virtual ~virtual_destructor(){} };
>
>template<..., class destructor_policy = no_virtual_destructor>
>   class basic_string : public destructor_policy {...};
>
>The default case is unchanged, so it shouldn't break anything.
>
>Someone who wants to subclass it can just change the destructor policy
>and be on their merry way.
>
>It will also let people who want to "abuse" the mechanism and make other
>functions virtual.
>
>It doesn't change the argument about subclassing at all, but it sure
>makes it less interesting.

  I'll go for this solution, assuming I understand it. Can you give an
example where the "virtual_destructor" struct is used?

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt

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

Steve Heller <steve@steveheller.com> writes:

|>  >Has the same semantics as C but will have a different layout so
|>  >you better not delete either C or D through Y* or Z* variables.

|>    Ok, then how about this:

|>  "If the derived class does not add any data members, and does not
|>  have multiple base classes, then deletion through the base class
|>  pointer will delete the base class part properly"

A safer solution would be to list what the derived class *can* do and
still have the guarantee. If you forget something, it is trivial to
add it later, whereas you generally can't add restrictions once you've
allowed something.

Off-hand, I'd start with only allowing non-virtual member functions,
although 1) things like typedef's, enum etc. certainly shouldn't pose
a problem, and 2) nor should new static members.

Anyhow, as I've said, I think it is doable, but I'm not convinced that
it is worth it. What I'd suggest is that you write up some sort of a
proposal just allowing additional non-virtual member functions and
single, non-virtual inheritance, but with a very good rationale
section -- why this is needed.  If the rationale is convincing, we can
think about what else can be allowed, but discussing the details
before having convinced people that the extension is in any way useful
is not particularly productive.

(I know you think it is useful, but I'm not sure you've convinced
anyone else yet.  I think that it could be slightly useful, but not
useful enought to warrent additional special cases which have to be
taught -- the language is complicated enough as is.)

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

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

"Edward Diener" <eldiener@earthlink.net> wrote in message
news:INSD8.7768$Nt3.660708@newsread2.prod.itd.earthlink.net...
> > struct something { };
> >
> > template<class T> inline std::basic_ostream<T>&
> > operator<<(std::basic_ostream<T>& os, something) {
> >     return os << LOCAL_OF(T, "something");
> > }
>
> Yes, a neat solution.
>
> Of course if more character types are added to the language and your
> template function accepts another one, then you have to change your
> solution. Whereas my proposal for a syntax change would take care of that at
> the compiler level.
>
> template<class T> inline std::basic_ostream<T>&
> operator<<(std::basic_ostream<T>& os, something) {
>     return os << <T>"something";
>
> Of course this doesn't presently exist but illustrates my proposal.

I would rather have it at a language level also, however I don't really like the
use of angle-brackets at the beginning of an expression.  Of course, that is not
a serious issue.

Paul Mensonides

---
[ 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> writes:

>David Sachs <sachs@fnal.gov> writes
>>2) A way to use placement operator delete and operator delete[] for memory
>>allocated with a placement operator new.
>
>That is much harder than it seems. First off, it would necessary to
>track how dynamic objects have been created (the only case that that is
>currently required is during construction which is relatively
>inexpensive)

I don't understand your objection here.  Could you elaborate?

Do you mean that the compiler would need to track this, or the user?
If the former, why?  If the latter, why would this be a problem?

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

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

Wish 2:
Static virtual methods.
Now I implement this some way like:

class SomeClassProperty;

class BaseClass {
public:
  static SomeClassProperty staticGetSomeClassProperty ();
  virtual SomeClassProperty virtualGetSomeClassProperty () {
    return staticGetSomeClassProperty ();
  };
};

class DerivedClass :public BaseClass {
public:
  static SomeClassProperty staticGetSomeClassProperty ();
  SomeClassProperty virtualGetSomeClassProperty () {
    return staticGetSomeClassProperty ();
  };
};

This is only one example, there are others.
But I do not understand, why is it problem to keep pointer to
static function in virtual method table.
I can't just move implementation of static method to virtual method
or remove virtual method because in some place I want

prop = ptr->virtualGetSomeClassProperty (); /* we have instance and want to
get its exact class's property */

and some other place:

prop = MyClass::staticGetSomeClassProperty (); /* we have no instance */

Why can't I write

class BaseClass {
public:
  static virtual ();
};

class DerivedClass :public BaseClass {
public:
  getSomeClassProperty (); /* note: 'static' behavior is 'inherited' from
BaseClass::getSomeClassProperty() like 'virtual' behavior */
};

When called via pointer such function will be found in virtual method table,
but will be called without 'this' pointer.

What do You say ?


==============
Felix Shvaiger
fshvaige@cisco.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                       ]

usenet@hgardner.com (Howard Gardner) wrote (abridged):
> Publicly deriving from std::string risks a delete through a base class
> pointer, and so it risks undefined behavior and is a nono. Same is true
> for the containers.

I think there's more to it than just deletion.

For example, I have found myself wanting an "owning vector", which holds
pointers and deletes them when they are erased. In order to guarantee my
semantics, I have to catch every function which does erasure - off the top
of my head that's erase() (2 versions), clear() and the destructor. Having
a virtual destructor doesn't help me unless erase() and clear() are also
virtual (or the 2-argument erase() is virtual and the others are defined
in terms of it).

I would rather see ways to make private inheritance, and/or delegation,
safer and easier to use. For example, a using-declaration which can select
just the const version of begin() and end(). Or contrariwise, a
using-declaration which can select the entire base class public interface.
A way of inheriting constructors would be nice, too. A better forwarding
mechanism.

  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                       ]

On Thu,  9 May 2002 16:55:33 GMT, Pete Becker wrote in
<3CDA7DBA.8343B482@acm.org>:

> Tom Puverle wrote:
> >
> > I am trying to put together a wish list of language extensions that people
> > would like to see in C++0x.
>
> Let me suggest a different approach. Instead of asking about language
> features, put together a list of problems that aren't easily solved in
> the language as it exists today. Language features aren't an end in
> themselves, but are a way of solving problems. Focusing initially on
> problems rather than solutions will lead to a better set of solutions.

There is something that, admittedly, can be easily solved but the
solution is very inelegant (IMHO).

Several standard library algorithms require functions (or functors) as
arguments.  A separate, single-use function or functor to be used in
such an algorithm makes the code more cumbersome, less readable and less
maintainable (again, IMHO).

While adding full-blown lambda functions to C++ is probably not going to
happen (I can think of persistence issues), some kind of restricted
"lambda light" can be useful.

Consider the following trivial example (modulo syntax):

  struct Item { int i; }
  std::vector<Item> a;
  // ...

  std::sort(a.begin(),
            a.end(),
            bool (const Item& a, const Item& b) { return a.i > b.i; });

Hey, could be an opportunity to overload the "auto" keyword...


Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

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

Steve Heller wrote:
> Howard Gardner <usenet@hgardner.com> wrote:
>
>>struct no_virtual_destructor{};
>>
>>struct virtual_destructor{ virtual ~virtual_destructor(){} };
>>
>>template<..., class destructor_policy = no_virtual_destructor>
>>  class basic_string : public destructor_policy {...};
>>
>>The default case is unchanged, so it shouldn't break anything.
>>
>>Someone who wants to subclass it can just change the destructor policy
>>and be on their merry way.
>>
>>It will also let people who want to "abuse" the mechanism and make other
>>functions virtual.
>>
>>It doesn't change the argument about subclassing at all, but it sure
>>makes it less interesting.
>
>
>   I'll go for this solution, assuming I understand it. Can you give an
> example where the "virtual_destructor" struct is used?
>

Yes, there's one in Steve Heller's upcoming book, in the section titled
"Extending the functionality of strings." ;)

It would allow this to work without the potential for violation of LSP
or undefined behavior:

class xstring : public basic_string <..., virtual_destructor> {...};

The full behavior of basic string is inherited safely.

--
I <3 Comeau C++: http://www.comeaucomputing.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                       ]

John G. Harris:
> If having the same identifier doesn't guarantee that interworking is
> possible then I don't understand why an ISO-defined identifier would
> benefit anyone.

I'm not sure what you mean by that. You need much
more than consistent type names for portable
code and producing portable serialised objects, but
it's one step in the right direction.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

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

Dave Harris wrote:
> usenet@hgardner.com (Howard Gardner) wrote (abridged):
>
>>Publicly deriving from std::string risks a delete through a base class
>>pointer, and so it risks undefined behavior and is a nono. Same is true
>>for the containers.
>
>
> I think there's more to it than just deletion.

Yes there is. There's an ongoing argument. I think that there are valid
points on both sides.

> For example, I have found myself wanting an "owning vector", which holds
> pointers and deletes them when they are erased. In order to guarantee my
> semantics, I have to catch every function which does erasure - off the top
> of my head that's erase() (2 versions), clear() and the destructor. Having
> a virtual destructor doesn't help me unless erase() and clear() are also
> virtual (or the 2-argument erase() is virtual and the others are defined
> in terms of it).

The solution that I proposed would, in fact, let you make those
functions virtual:

template <...>
struct virtualize_erase
{
  virtual ... erase (...);
  virtual ... erase (...);
  virtual ... clear (...);
  virtual ~virtualize_erase();
};

class my_string
   : public basic_string <..., virtualize_erase<...>>
{...};

As long as the signatures of the functions match, the functions in
basic_string will become virtual.

This may be a bad thing because it might make implementations of
std::basic_string harder. I've implemented templates that work like
this. It can be a scary world when the question "Is this function
virtual?" has for an answer "I don't know." Even where it does no harm
it changes the appropriate mindset for code inspection. It's like
exception handling in that regard, though not quite so perilous.

Andrei Alexandrescu's policies have the same strength/weakness:
inheriting from a template parameter allows users to "virtualize" any
function(s) they choose. It seems to me that exercising that power would
violate the spirit of the thing. I'm reading his book now, but I haven't
encountered a discussion of the topic yet.

There's a pretty clean solution to your particular need that doesn't
involve virtual functions at all. I haven't tested this implementation,
but I have used similar code many times:

template <class Object>
class deep_pointer
{
public:
   deep_pointer(const Object & f_object = Object())
     : m_ptr( new Object(f_object) )
   {
   }

   deep_pointer(const deep_pointer & f_deep_pointer)
     : m_ptr( new Object( *(f_deep_pointer.m_ptr) ) )
   {
   }

   deep_pointer & operator = (const deep_pointer & f_deep_pointer)
   {
     Object * f_ptr = new Object( *(f_deep_pointer.m_ptr) );
     delete m_ptr;
     m_ptr = f_ptr;
     return *this;
   }

   ~deep_pointer()
   {
     delete m_ptr;
   }

   // whatever interface you want to give it for accessing the
   // indicated Object.
private:
   Object * m_ptr;
};

>
> I would rather see ways to make private inheritance, and/or delegation,
> safer and easier to use. For example, a using-declaration which can select
> just the const version of begin() and end(). Or contrariwise, a
> using-declaration which can select the entire base class public interface.
> A way of inheriting constructors would be nice, too. A better forwarding
> mechanism.

A better forwarding mechanism might be useful, but it's not actually
necessary to solve this particular problem.

--
I <3 Comeau C++: http://www.comeaucomputing.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 <abpv7d$sr7$1@mulga.cs.mu.OZ.AU>, Fergus Henderson
<fjh@cs.mu.OZ.AU> writes
>Francis Glassborow <francis.glassborow@ntlworld.com> writes:
>
>>David Sachs <sachs@fnal.gov> writes
>>>2) A way to use placement operator delete and operator delete[] for memory
>>>allocated with a placement operator new.
>>
>>That is much harder than it seems. First off, it would necessary to
>>track how dynamic objects have been created (the only case that that is
>>currently required is during construction which is relatively
>>inexpensive)
>
>I don't understand your objection here.  Could you elaborate?
>
>Do you mean that the compiler would need to track this, or the user?
>If the former, why?  If the latter, why would this be a problem?

Sorry, I was thinking of something else (distracted by the thread on
overloaded 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                       ]

nagle@animats.com (John Nagle) wrote (abridged):
>     I suggest simply prohibiting the overriding of non-virtual
> functions.

Unless they are private. I don't think there's anything wrong with
overriding a private non-virtual, and indeed this is a necessary
facility. Otherwise base classes become even more fragile than they
already are.

  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                       ]

"Paul Mensonides" <pmenso57@attbi.com> wrote in message
news:Y8XD8.508$Bw6.75@rwcrnsc51.ops.asp.att.net...
> "Edward Diener" <eldiener@earthlink.net> wrote in message
> news:INSD8.7768$Nt3.660708@newsread2.prod.itd.earthlink.net...
> > > struct something { };
> > >
> > > template<class T> inline std::basic_ostream<T>&
> > > operator<<(std::basic_ostream<T>& os, something) {
> > >     return os << LOCAL_OF(T, "something");
> > > }
> >
> > Yes, a neat solution.
> >
> > Of course if more character types are added to the language and your
> > template function accepts another one, then you have to change your
> > solution. Whereas my proposal for a syntax change would take care of
that at
> > the compiler level.
> >
> > template<class T> inline std::basic_ostream<T>&
> > operator<<(std::basic_ostream<T>& os, something) {
> >     return os << <T>"something";
> >
> > Of course this doesn't presently exist but illustrates my proposal.
>
> I would rather have it at a language level also, however I don't really
like the
> use of angle-brackets at the beginning of an expression.  Of course, that
is not
> a serious issue.

I choose the angle brackets for two reasons:

1) "<type>literal" does not seem, at first thought, as something that can be
used in any other situation and I want the parser for a C++ compiler
implementation to be able to pick it up easily.
2) It mimics the C++ casting operations and I see my solution as sort of a
cast. Of course I am not really casting a literal to another type, but just
telling the compiler to treat my literal as a specific type, but the concept
of specifying a type is similar.

Of course in order to not break existing code, the current methods of
specifying literals of various types should still be supported, so I see my
proposal as an addition and not a replacement. Obviously the addition makes
using literals in templated functions and classes easier.

I agree the exact syntax for this idea is not a serious issue and I would
defer to another syntax which would make it easy to specify and which would
cause the C++ compiler parser few problems. But I do like my syntax for the
reasons above.

---
[ 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@alex.gabi-soft.de> wrote:

>Steve Heller <steve@steveheller.com> writes:
>
>|>  >Has the same semantics as C but will have a different layout so
>|>  >you better not delete either C or D through Y* or Z* variables.
>
>|>    Ok, then how about this:
>
>|>  "If the derived class does not add any data members, and does not
>|>  have multiple base classes, then deletion through the base class
>|>  pointer will delete the base class part properly"
>
>A safer solution would be to list what the derived class *can* do and
>still have the guarantee. If you forget something, it is trivial to
>add it later, whereas you generally can't add restrictions once you've
>allowed something.
>
>Off-hand, I'd start with only allowing non-virtual member functions,
>although 1) things like typedef's, enum etc. certainly shouldn't pose
>a problem, and 2) nor should new static members.

  Sounds good to me.

>Anyhow, as I've said, I think it is doable, but I'm not convinced that
>it is worth it. What I'd suggest is that you write up some sort of a
>proposal just allowing additional non-virtual member functions and
>single, non-virtual inheritance, but with a very good rationale
>section -- why this is needed.  If the rationale is convincing, we can
>think about what else can be allowed, but discussing the details
>before having convinced people that the extension is in any way useful
>is not particularly productive.
>
>(I know you think it is useful, but I'm not sure you've convinced
>anyone else yet.  I think that it could be slightly useful, but not
>useful enought to warrent additional special cases which have to be
>taught -- the language is complicated enough as is.)

  Okay, I'll write up a proposal with a rationale as to why this is
useful, and post it here. Thanks for the feedback!

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt

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

kanze@alex.gabi-soft.de (James Kanze) wrote (abridged):
> Off-hand, I'd start with only allowing non-virtual member functions,
> although 1) things like typedef's, enum etc. certainly shouldn't pose
> a problem, and 2) nor should new static members.

How valuable are the implementation freedoms that would be lost by this?
I am thinking here of an implementation which chooses to make PODs
compatible with C, but uses a wacky scheme for all non-PODs. For
example, non-PODs could always have a vtable which stores extra
information for debugging or profiling or something.

I don't know of any implementation which does this, but I wouldn't want
to rule it out. Contemporary implementations are usually optimised for
efficiency over safety. Perhaps in another 5 or 10 years that fashion
will reverse. Maybe we will start to see "managed C++" execution models,
similar in spirit to C# and Java. Who knows?

It seems to me that the proposal amounts to saying that a class which
inherits from a POD, and satisfies your restrictions, is a kind of
quasi-POD. If we go this route maybe we should make it a full POD
instead. For example, allowing it to be copied with memcopy() as well as
deleted via a pointer to its base class.


> Anyhow, as I've said, I think it is doable, but I'm not convinced that
> it is worth it.

Me neither. Wouldn't it lead to fragile designs? Suppose I publish a
base class for you to derive from, but which doesn't have a virtual
destructor and which I want to delete via pointers to the base. You are
allowed to add member functions but not to add instance variables. Is
this set of constraints really useful? How long before some maintenance
programmer forgets and adds an instance variable anyway?

  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                       ]

> I choose the angle brackets for two reasons:
>
> 1) "<type>literal" does not seem, at first thought, as something that can be
> used in any other situation and I want the parser for a C++ compiler
> implementation to be able to pick it up easily.
> 2) It mimics the C++ casting operations and I see my solution as sort of a
> cast. Of course I am not really casting a literal to another type, but just
> telling the compiler to treat my literal as a specific type, but the concept
> of specifying a type is similar.
>
> Of course in order to not break existing code, the current methods of
> specifying literals of various types should still be supported, so I see my
> proposal as an addition and not a replacement. Obviously the addition makes
> using literals in templated functions and classes easier.
>
> I agree the exact syntax for this idea is not a serious issue and I would
> defer to another syntax which would make it easy to specify and which would
> cause the C++ compiler parser few problems. But I do like my syntax for the
> reasons above.

You don't really need any brackets.  You could simply prefix it with a type.  In
the case of literals, this wouldn't break anything either.  And it would be
somewhat similar to the existing L"string" notation (except whitespace wouldn't
matter).

template<class T> const T* f() {
    return T "some text"
}

Either way would be okay with me.  I just think we have enough parenthesis and
brackets of various kinds already--and I hate counting parenthesis, etc.. :)

Paul Mensonides

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

"John Nagle" <nagle@animats.com> wrote in message
news:3CE15DDD.70405@animats.com...
> >>From: Felix Shvaiger [mailto:fshvaige@cisco.com]
> >>Sent: 14 May 2002 09:28
> >>To: Tom Puverle
> >>Subject: Re: C++0x Wish list
>
> > Some keyword like 'noinherit' which mean,
> > that virtual method could not be inherited by
> > derived class, but rather must be overrided
> > in each direct or undirect derived class.
>
>
>     I'm not entirely sure what that means.
>
>     I suggest simply prohibiting the overriding of non-virtual functions.
> That would seem to provide the functionality requested.  It's almost
> always an error when someone overrides a non-virtual function.
> On the rare occasions that you really want to do that, you can
> use a different function name.
>
> John Nagle
>

No. No. No. See example in original post.
The idea is to make it clear to compiler and user that
some VIRTAUL (but not abstract) method MUST BE OVERRIDED
in every derived class.
For example method 'getClassName' MUST BE VIRTUAL and
MUST BE OVERRIDED in each and every derived class
in order to return different names for each and every class.
It will be error if objects of two different classes will return same
ClassName.

Felix Shvaiger


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

"Edward Diener" <eldiener@earthlink.net> wrote...
>
> I choose the angle brackets for two reasons:
>
> 1) "<type>literal" does not seem, at first thought, as something that can
be
> used in any other situation and I want the parser for a C++ compiler
> implementation to be able to pick it up easily.
> 2) It mimics the C++ casting operations and I see my solution as sort of a
> cast.

You will almost certainly find that

    literal_cast<T>("string")

is easiest to parse. It is possibly also the easiest to teach. Yes it
is a little verbose, how often do you expect to use it? The motivation
so far appears to be mostly for writing industrial strength templates,
which is a sufficiently "guru" activity that the verbosity might be
tolerated.

> Of course I am not really casting a literal to another type, but just
> telling the compiler to treat my literal as a specific type, but the
> concept of specifying a type is similar.

I'm not sure reinterpret_cast does _much_ more than "tell the compiler
to treat something as something else.


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

Pete Becker wrote:

> Let me suggest a different approach. Instead of asking about language
> features, put together a list of problems that aren't easily solved in
> the language as it exists today. ..................................

Good suggestion. Here is the pet peeves of mine:

1). A simple way of deriving classes without having to re-specify the
    constructors of the parent class.

    Often you derive from a base class only to add one or two methods.
    If the parent class has a lot of constructors and if you wan't to
    keep those constructors in your derived class you have no other
    option than re-specifying those constructors in your derived class.

    This could be solved by allowing constructors to be inherited iff
    the derived class adds no new (data-) members. Anonymous classes
    would also come handy in some situations.

2). A simple way of declaring function objects close to their usage.

    Defining your own one-off STL compatible algorithms often displaces
    the implementation of the algorithm far from the often singular usage
    of the algorithm and thus obscuring the intention of the program.

    Compare

        list<int> l;
        for (list::iterator i = l.begin(); i != l.end(); ++i)
            // do some computation

    and

        struct do_some_compuation {
            void operator()(int i) const { // do something }
        };

        // ...

        for_each(l.begin(), l.end(), do_some_computation);

    The first example makes it clear to the reader of the code what the
    intention is while the second version would often require the reader
    to scroll some pages back to find the implementation of the algorithm.

    A solution could be to standardize the Boost lambda library or to
    augment the language with facilities for such lambda constructs. IMO
    the last solution is preferred.

3). Objects in containers

    The STL containers are not well-suited for object-orientated
    programming when the objects in question don't have a reasonable
    copy-semantics. This forces you to use pointers in your containers
    and results in cumbersome indirections whenever you wan't to use
    an algorithm over those objects in the container.

    This could be solved by making references assignable (but could
    possibly open for a lot of other problems too).

4). Clean-up of std::string

    The string interface is horribly bloated. This is a problem when
    you wan't to create a std::string lookalike class - like a class
    based on variable sized UTF-8 characters.

5). Addition of UCS-2 or UCS-4 string classes

    The support for internationalized strings is almost absent from the
    standard.


Yours

        -Claus

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

Howard Gardner <usenet@hgardner.com> wrote:

>Steve Heller wrote:
>> Howard Gardner <usenet@hgardner.com> wrote:
>>
>>>struct no_virtual_destructor{};
>>>
>>>struct virtual_destructor{ virtual ~virtual_destructor(){} };
>>>
>>>template<..., class destructor_policy = no_virtual_destructor>
>>>  class basic_string : public destructor_policy {...};
>>>
>>>The default case is unchanged, so it shouldn't break anything.
>>>
>>>Someone who wants to subclass it can just change the destructor policy
>>>and be on their merry way.
>>>
>>>It will also let people who want to "abuse" the mechanism and make other
>>>functions virtual.
>>>
>>>It doesn't change the argument about subclassing at all, but it sure
>>>makes it less interesting.
>>
>>
>>   I'll go for this solution, assuming I understand it. Can you give an
>> example where the "virtual_destructor" struct is used?
>>
>
>Yes, there's one in Steve Heller's upcoming book, in the section titled
>"Extending the functionality of strings." ;)
>
>It would allow this to work without the potential for violation of LSP
>or undefined behavior:
>
>class xstring : public basic_string <..., virtual_destructor> {...};
>
>The full behavior of basic string is inherited safely.

  So "virtual_destructor" would specify a policy for a specific
instantiation of basic_string?

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt

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

Felix Shvaiger wrote:
>
> No. No. No. See example in original post.
> The idea is to make it clear to compiler and user that
> some VIRTAUL (but not abstract) method MUST BE OVERRIDED
> in every derived class.
> For example method 'getClassName' MUST BE VIRTUAL and
> MUST BE OVERRIDED in each and every derived class
> in order to return different names for each and every class.
> It will be error if objects of two different classes will return same
> ClassName.
>

Why do you wnt to restrict how implementors of derived classes provide
this capability? In particular, this construct would prohibit the
following:

class Base
{
public:
 virtual string getClassName() = MUST_OVERRIDE { ..... };
};

class Intermediate : public Base
{
public:
 string getClassName() { return getRealName(); }
 virtual string getRealName() { ..... };
};

As the designer of Base, it's your job to ensure that Base works
correctly, and that includes specifying what a call to
Derived::getClassName should do. It is not your job to specify how
Derived::getClassName does its job.

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

Dave Harris:
> Maybe we will start to see "managed C++" execution models,
> similar in spirit to C# and Java. Who knows?

There's one already in Visual Studio.net. It will be interesting to
see if it takes off.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

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

brangdon@cix.co.uk (Dave Harris) writes:

|>  kanze@alex.gabi-soft.de (James Kanze) wrote (abridged):
|>  > Off-hand, I'd start with only allowing non-virtual member
|>  > functions, although 1) things like typedef's, enum
|>  > etc. certainly shouldn't pose a problem, and 2) nor should new
|>  > static members.

|>  How valuable are the implementation freedoms that would be lost by
|>  this?  I am thinking here of an implementation which chooses to
|>  make PODs compatible with C, but uses a wacky scheme for all
|>  non-PODs. For example, non-PODs could always have a vtable which
|>  stores extra information for debugging or profiling or something.

I don't think that that would pose a problem.  The freedom that is
lost is to do something radically different in the derived class than
what one does in the base class.

Generally speaking, the freedom for the implementation seems a minimal
issue in this case.  The loss of freedom is very small.  (On the other
hand, for the moment, the benefits also seem exceedingly small.)

|>  I don't know of any implementation which does this, but I wouldn't
|>  want to rule it out. Contemporary implementations are usually
|>  optimised for efficiency over safety. Perhaps in another 5 or 10
|>  years that fashion will reverse. Maybe we will start to see
|>  "managed C++" execution models, similar in spirit to C# and
|>  Java. Who knows?

|>  It seems to me that the proposal amounts to saying that a class
|>  which inherits from a POD, and satisfies your restrictions, is a
|>  kind of quasi-POD. If we go this route maybe we should make it a
|>  full POD instead. For example, allowing it to be copied with
|>  memcopy() as well as deleted via a pointer to its base class.

Iteresting idea.  No comment.  (As I said, I don't think that this is
important.  But since the original poster apparently did, I thought
I'd give some food for thought.)

|>  > Anyhow, as I've said, I think it is doable, but I'm not
|>  > convinced that it is worth it.

|>  Me neither. Wouldn't it lead to fragile designs? Suppose I publish
|>  a base class for you to derive from, but which doesn't have a
|>  virtual destructor and which I want to delete via pointers to the
|>  base. You are allowed to add member functions but not to add
|>  instance variables. Is this set of constraints really useful? How
|>  long before some maintenance programmer forgets and adds an
|>  instance variable anyway?

The one case where I thought it might be useful is in the case of
arrays.  There have been one or two times where I thought it might be
useful to derive in order to provide a constructor with special
initialization, then treat the allocated array as an array of the base
class.  A stupid example:

    struct InitializedString : public std::string
    {
        InitializedString() : std::string( "Big deal" ) {}
    }

    std::string* array =3D new InitializedString[ 200 ] ;

My proposal, at the time, would have been to allow nothing but
constructors in the derived class -- what I would have called trivial
derivation.

As I say, it's doable, but after thinging about it, I decided that it
wasn't worth it.  The gain really isn't that much, and it is one more
rule to learn.  (It's not as if C++ were too simple otherwise.)

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ 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 <cnOE8.641$Fs2.41618@news8-gui.server.ntli.net>, Garry
Lancaster <glancaster@ntlworld.com> writes
>Dave Harris:
>> Maybe we will start to see "managed C++" execution models,
>> similar in spirit to C# and Java. Who knows?
>
>There's one already in Visual Studio.net. It will be interesting to
>see if it takes off.

True, but as Stan Lippman pointed out at the ACCU Spring Conference, it
is only the first version and a great deal of work needs to be done to
make it close to a genuine implementation of C++ (work that he is
committed to seeing done)


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

In article <ac02ii$5dv$1@sunsite.dk>, Claus Rasmussen
<clr@cc-consult.dk> writes
>1). A simple way of deriving classes without having to re-specify the
>    constructors of the parent class.
>
>    Often you derive from a base class only to add one or two methods.
>    If the parent class has a lot of constructors and if you wan't to
>    keep those constructors in your derived class you have no other
>    option than re-specifying those constructors in your derived class.
>
>    This could be solved by allowing constructors to be inherited iff
>    the derived class adds no new (data-) members. Anonymous classes
>    would also come handy in some situations.

This is under consideration but it isn't that simple. What about the
assignment operator, the dtor, other member functions that return the
class type by value, reference or pointer, parameters of those types
etc.

>
>2). A simple way of declaring function objects close to their usage.
>
>    Defining your own one-off STL compatible algorithms often displaces
>    the implementation of the algorithm far from the often singular usage
>    of the algorithm and thus obscuring the intention of the program.

I don't think you meant what you wrote, these aren't algorithms but
functions or functors being used by STL 'algorithms'.
>
>    Compare
>
>        list<int> l;
>        for (list::iterator i = l.begin(); i != l.end(); ++i)
>            // do some computation
>
>    and
>
>        struct do_some_compuation {
>            void operator()(int i) const { // do something }
>        };
>
>        // ...
>
>        for_each(l.begin(), l.end(), do_some_computation);
>
>    The first example makes it clear to the reader of the code what the
>    intention is while the second version would often require the reader
>    to scroll some pages back to find the implementation of the algorithm.
>
>    A solution could be to standardize the Boost lambda library or to
>    augment the language with facilities for such lambda constructs. IMO
>    the last solution is preferred.
>
>3). Objects in containers
>
>    The STL containers are not well-suited for object-orientated
>    programming when the objects in question don't have a reasonable
>    copy-semantics. This forces you to use pointers in your containers
>    and results in cumbersome indirections whenever you wan't to use
>    an algorithm over those objects in the container.
>
>    This could be solved by making references assignable (but could
>    possibly open for a lot of other problems too).

I think that is not a suitable solution for C++. What is wrong with a
suitable smart pointer or some other form of proxy object.  Perhaps
someone could come up with some containers that work through their own
smart pointer.

>
>4). Clean-up of std::string
>
>    The string interface is horribly bloated. This is a problem when
>    you wan't to create a std::string lookalike class - like a class
>    based on variable sized UTF-8 characters.

Well i think this is much more than a cleanup. We need a radical
redesign (something I have been mumbling about for a long time.

>
>5). Addition of UCS-2 or UCS-4 string classes
>
>    The support for internationalized strings is almost absent from the
>    standard.

Yes, but they keep changing the ground and there is much more to
internationalisation than just characters. I do not know of any language
that gets even close to getting it right.



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

In article <02yE8.2313$UL2.132812@newsfep1-win.server.ntli.net>, Garry
Lancaster <glancaster@ntlworld.com> writes
>John G. Harris:
>> If having the same identifier doesn't guarantee that interworking is
>> possible then I don't understand why an ISO-defined identifier would
>> benefit anyone.
>
>I'm not sure what you mean by that. You need much
>more than consistent type names for portable
>code and producing portable serialised objects,

Is this the problem the proposal is aimed at ?

>but
>it's one step in the right direction.

If it is then I cannot see any solution that could be put into an ISO
standard. It would need an identifier registration scheme, something
like the registration scheme for URL domain names (enter lawyers, stage
right).

  John
--
John Harris
  mailto:john@jgharris.demon.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                       ]

Steve Heller wrote:
> Howard Gardner <usenet@hgardner.com> wrote:
>
>
>>Steve Heller wrote:
>>
>>>Howard Gardner <usenet@hgardner.com> wrote:
>>>
>>>
>>>>struct no_virtual_destructor{};
>>>>
>>>>struct virtual_destructor{ virtual ~virtual_destructor(){} };
>>>>
>>>>template<..., class destructor_policy = no_virtual_destructor>
>>>> class basic_string : public destructor_policy {...};
>>>>
>>>>The default case is unchanged, so it shouldn't break anything.
>>>>
>>>>Someone who wants to subclass it can just change the destructor policy
>>>>and be on their merry way.
>>>>
>>>>It will also let people who want to "abuse" the mechanism and make other
>>>>functions virtual.
>>>>
>>>>It doesn't change the argument about subclassing at all, but it sure
>>>>makes it less interesting.
>>>
>>>
>>>  I'll go for this solution, assuming I understand it. Can you give an
>>>example where the "virtual_destructor" struct is used?
>>>
>>
>>Yes, there's one in Steve Heller's upcoming book, in the section titled
>>"Extending the functionality of strings." ;)
>>
>>It would allow this to work without the potential for violation of LSP
>>or undefined behavior:
>>
>>class xstring : public basic_string <..., virtual_destructor> {...};
>>
>>The full behavior of basic string is inherited safely.
>
>
>   So "virtual_destructor" would specify a policy for a specific
> instantiation of basic_string?
>

Exactly.

It works for the same reason that this works:

struct no_virtual_destructor{};

struct virtual_destructor{ virtual ~virtual_destructor(){} };

template <class destructor_policy>
class some_class
:
   public destructor_policy
{
public:
   void func(void) {}
};

some_class< no_virtual_destructor > does not have a virtual destructor.

some_class< virtual_destructor > has a virtual destructor.

The only potential pitfall that I see in the context of the standard
library is that it might be abuesed. This also works, and accounting for
the possibility might complicate implementations of the containers and
strings:

struct abusive
{
   virtual ~virtual_destructor(){}
   virtual void func(void){}
};

some_class< abusive > has a virtual destructor, which is what we meant
to allow. func is virtual too, though, and that could be problematic.

I've played with this idea (inheriting from a template parameter) a lot.
It's amusing.

--
I <3 Comeau C++: http://www.comeaucomputing.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                       ]

> >John G. Harris:
> >> If having the same identifier doesn't guarantee that interworking is
> >> possible then I don't understand why an ISO-defined identifier would
> >> benefit anyone.

Garry Lancaster:
> >I'm not sure what you mean by that. You need much
> >more than consistent type names for portable
> >code and producing portable serialised objects,

John G. Harris:
> Is this the problem the proposal is aimed at ?

I would say so, although I didn't make the original
suggestion.

> >but
> >it's one step in the right direction.

> If it is then I cannot see any solution that could be put into an ISO
> standard. It would need an identifier registration scheme, something
> like the registration scheme for URL domain names (enter lawyers, stage
> right).

Before moving to a more exotic scheme we need
to thoroughly examine the more obvious alternatives.
What is wrong with std::vector<int> being known as
"std::vector<int>"?

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net



---
[ 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, 16 May 2002 21:16:42 GMT, Howard Gardner <usenet@hgardner.com>
wrote:

>The only potential pitfall that I see in the context of the standard
>library is that it might be abuesed. This also works, and accounting for
>the possibility might complicate implementations of the containers and
>strings:
>
>struct abusive
>{
>   virtual ~virtual_destructor(){}
>   virtual void func(void){}
>};
>
>some_class< abusive > has a virtual destructor, which is what we meant
>to allow. func is virtual too, though, and that could be problematic.

Another little pitfall is the fact that some_class<virtual_destructor>
and some_class<no_virtual_destructor> are unrelated class, but i
suppose this is not a serious problem.

Instead the described abuse is more annoying (maybe "dangerous" is a
more precise word), what about this instead ?

template <bool>
struct destructor {};

template<>
struct destructor<true> { virtual ~destructor() {} };

template <bool virtual_destructor_policy>
class some_class : public destructor<virtual_destructor_policy>
{
public:
   void func(void) {}
};

This give us the freedom of select virtual or not virtual destructor,
whitout the backdoor for "virtualize" other member functions.

>I've played with this idea (inheriting from a template parameter) a lot.
>It's amusing.

Yes, very interesting.

Regards,
Natale Fietta

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

kanze@alex.gabi-soft.de (James Kanze) wrote (abridged):
> I don't think that that would pose a problem.  The freedom that is
> lost is to do something radically different in the derived class than
> what one does in the base class.

Yes. I am thinking of the case where the base class is a POD, and
therefore heavily restricted. Currently a derived class is never a POD so
not subject to the same restrictions. For example, it doesn't have to be
in contiguous memory.

I am not sure what can currently be done with this. For example, is it
possible to implement inheritance using pointers, like:

    class Derived {
        Base __*pBase;
    };

rather than by embedding a Base subobject. In effect, a kind of automatic
pImpl idiom. Sizeof(Derived) would be independent of sizeof(Base),
avoiding some of the fragile base class problems.

As another example, in another thread Fergus Henderson just wrote:

    The C++ committee wanted to permit implementations in which
    all method calls were implemented in essentially the same
    way as virtual method calls,

This kind of thing might lead to wanting a vtable in Derived even though
Derived does not add any virtual functions.

I don't know of any implementation which takes advantages of these
freedoms, so I wonder if they are still taken seriously by the standards
committee.

  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                       ]

"Ken Hagan" <K.Hagan@thermoteknix.co.uk> wrote in message
news:1021541084.24205.0.nnrp-14.3e31ffea@news.demon.co.uk...
> "Edward Diener" <eldiener@earthlink.net> wrote...
> >
> > I choose the angle brackets for two reasons:
> >
> > 1) "<type>literal" does not seem, at first thought, as something that
can
> be
> > used in any other situation and I want the parser for a C++ compiler
> > implementation to be able to pick it up easily.
> > 2) It mimics the C++ casting operations and I see my solution as sort of
a
> > cast.
>
> You will almost certainly find that
>
>     literal_cast<T>("string")
>
> is easiest to parse. It is possibly also the easiest to teach. Yes it
> is a little verbose, how often do you expect to use it? The motivation
> so far appears to be mostly for writing industrial strength templates,
> which is a sufficiently "guru" activity that the verbosity might be
> tolerated.

I like your idea of using "literal cast" very much. It is certainly clearer
to the compiler than just <T>"string" and also follows the syntax of other
C++ casting operations. The extra verbosity is mostly irrelevant compared to
the clearness of the syntax.

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

Natale Fietta wrote:
> On Thu, 16 May 2002 21:16:42 GMT, Howard Gardner <usenet@hgardner.com>
> wrote:
>
> Another little pitfall is the fact that some_class<virtual_destructor>
> and some_class<no_virtual_destructor> are unrelated class, but i
> suppose this is not a serious problem.

Yet another paragraph or subsection in tutorials on the STL. At least
the explanation would be shorter than the "publicly inheriting from a
standard container is perilous" discussion.

>
> Instead the described abuse is more annoying (maybe "dangerous" is a
> more precise word), what about this instead ?

Yes. Maybe. No.

It's never actually caused me a problem. It worries me because I don't
think the world has a lot of experience with the technique. At least, I
haven't seen much discussion of it.

My personal adventure in mastering exception safety has made me much
more cautious. The warts in the standard library--which exist despite
the fact that so many masters of our art payed so much attention to
them--have made me much more cautious.

It's a wonder that I can bring myself to attempt to write code at all ;)

> template <bool>
> struct destructor {};
>
> template<>
> struct destructor<true> { virtual ~destructor() {} };
>
> template <bool virtual_destructor_policy>
> class some_class : public destructor<virtual_destructor_policy>
> {
> public:
>    void func(void) {}
> };
>
> This give us the freedom of select virtual or not virtual destructor,
> whitout the backdoor for "virtualize" other member functions.

Yes, that would plug the hole.

I'm not certain that the hole should be plugged. If string and the
containers can be implemented in such a way that they can tolerate the
flexibility--and my experiments with the technique lead me to suspect
that they can--then users might benefit from it.

--
I <3 Comeau C++: http://www.comeaucomputing.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                       ]

On Fri, 17 May 2002 18:49:26 GMT, Howard Gardner <usenet@hgardner.com>
wrote:

>Yet another paragraph or subsection in tutorials on the STL. At least
>the explanation would be shorter than the "publicly inheriting from a
>standard container is perilous" discussion.

Before reading this thread i was thinking of a totally different
solution, to add a language feature to specificate that a class is a
leaf class, so prohibiting further derivation from it.

something similar to this:

class Base {...};

class Leaf : public Base, underivable {...};
                                  // ^ hypothetical new keyword

class Abuse : public Leaf {...};
// hypothetic compile time error: deriving from underivable class Leaf

Happily this is no more necessary for std::string/containers (if the
proposed template derivation trick is used), but maybe can be useful
for other pourposes...

>> Instead the described abuse is more annoying (maybe "dangerous" is a
>> more precise word), what about this instead ?
>
>Yes. Maybe. No.

I like decise answers ;-)

>It's never actually caused me a problem. It worries me because I don't
>think the world has a lot of experience with the technique. At least, I
>haven't seen much discussion of it.

I definitively do not have ANY experience with this idiom (i read it
the first time in this thread), so i have a lot to learn from this
discussion.

>> This give us the freedom of select virtual or not virtual destructor,
>> whitout the backdoor for "virtualize" other member functions.
>
>Yes, that would plug the hole.
>
>I'm not certain that the hole should be plugged.

Agree, probably the usefulness is more than the danger, at least in
the hand of a competent programmer...

Regards,
Natale Fietta

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

"John Nagle" <nagle@animats.com> wrote in message
news:3CDF5E87.6050704@animats.com...
>
>      The "include" approach to interfaces fosters too
> much unwanted interdependency in large projects.  Changing
> the private part of a class forces a recompile of the
> class's users.  On large projects, this generates
> huge amounts of irrelevant recompile activity, and then
> trying to avoid those recompiles warps designs out of shape.

I second this. It's my biggest gripe about C++. I'd really like a clean
physical separation of interface from implementation to avoid the
issues above. Other languages have had it for decades!

Cheers,
Mark.



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

"Pete Becker" <petebecker@acm.org> wrote in message
news:3CDA7DBA.8343B482@acm.org...
> Tom Puverle wrote:
> >
> > I am trying to put together a wish list of language extensions that
people
> > would like to see in C++0x.
>
> Let me suggest a different approach. Instead of asking about language
> features, put together a list of problems that aren't easily solved in
> the language as it exists today. Language features aren't an end in
> themselves, but are a way of solving problems. Focusing initially on
> problems rather than solutions will lead to a better set of solutions.

OK, here's one problem, there's too much tedius typing required for
assembling components via composition.

What we need is some kind of higher level "wrap" operator to automatically
generate inline forwarding functions.

class A
{
   public:
    int foo1();
    int foo2();
};

class B
{
 public:
   int foo0();

  private:
   wrap A a;     // Exports interface of A straight through to interface of
B, but don't expose 'a' itself.
};

int main()
{
   B b;
   b.foo0();
   b.foo1();
   b.foo2();
   return 0;
}

It should work for pointer members too. Any comments?

Cheers,
Mark.


---
[ 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 <acb8qk$f9u$1@pegasus.csx.cam.ac.uk>, Mark Jordan
<markj@mrc-lmb.cam.ac.uk> writes
>> the language as it exists today. Language features aren't an end in
>> themselves, but are a way of solving problems. Focusing initially on
>> problems rather than solutions will lead to a better set of solutions.
>
>OK, here's one problem, there's too much tedius typing required for
>assembling components via composition.
>
>What we need is some kind of higher level "wrap" operator to automatically
>generate inline forwarding functions.
>
>class A
>{
>   public:
>    int foo1();
>    int foo2();
>};
>
>class B
>{
> public:
>   int foo0();
>
>  private:
>   wrap A a;     // Exports interface of A straight through to interface of
>B, but don't expose 'a' itself.
>};
>
>int main()
>{
>   B b;
>   b.foo0();
>   b.foo1();
>   b.foo2();
>   return 0;
>}
>
>It should work for pointer members too. Any comments?

Quite a few of us understand the problem but I suspect we can do better
for a solution.


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

On Fri, 10 May 2002 08:35:10 UTC, "Eric Niebler" <ericne@microsoft.com> w=
rote: WEEKDAY

>
>"Pete Becker" <petebecker@acm.org> wrote in message
>news:3CDA7DBA.8343B482@acm.org...
>> Instead of asking about language
>> features, put together a list of problems that aren't easily solved in
>> the language as it exists today.
>
>Good suggestion.
>
>Not too long ago, this code appeared in a column by a well-respected C++
>guru.
>
>     template<class CharT, class Traits>
>     basic_ostream<CharT, Traits>& operator<<
>       ( basic_ostream<CharT, Traits>& o, const Num& n )
>     {
>       long value =3D n.Value();
>       basic_string<CharT, Traits> s;
>
>       CharT digits []
>         =3D "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
>
><snip>
>
>The code compiles fine when CharT=3D=3Dchar, but if it is anything else =
the
>compile breaks on the declaration of the digits array.  Basically, strin=
g
>literals and template code don't mix.  The fact that this error slips in=
to
>the code of even the most seasoned experts demonstrated that it's a real
>problem.
>
>In the past, I have hacked around the problem like this:
>
>    CharT digits [] =3D { '0', '1', '2', ... };
>
>but this is (a) tedius, (b) verbose, and (c) wrong.  It's wrong becuase =
if
>CharT=3D=3Dwchar_t, then there is no guarantee that assigning a char to =
a
>wchar_t yields anything meaningful.
>
>Of course, I could defer the string conversion to run-time and use a loc=
ale,
>but that's not guaranteed to yield the same results as if the compiler d=
id
>the conversion, as it would have to for L"..." wide string literals.
>
>Does anybody have a solution for this?
>
I have concluded long ago that constants should be of universal
type.
I should be able to write:
 int I =3D 123456789;
 long L =3D 123456789;
 short S =3D 123456789;
 char c =3D 'a';
 wchar_t =3D 'a';
 float f =3D 123456789.987654321;
 double d =3D 123456789.987654321;

without needing to specify to the compiler the type of the constant.
Constants start out at the maximum precision and only produce
an error/warning if truncation actually happens at compile time.
Only if the programmer gives a specific type suffix is it forced to=20
a lesser type.
All string/character constants should start out in full UNICODE
and be implicitly converted to the desired target type at compile time.

>Thanks,
>Eric
>
>
>
>---
>[ 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                       =
]
>


--=20
=FF
=FF
Remove -zamboni to reply
All the above is hearsay and the opinion of no one in particular

---
[ 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 <cinmdukfbf408nnolf8lq6nqrkctmq014g@4ax.com>, Steve Heller
<steve@steveheller.com> writes
>  I would like the standard to guarantee that deleting a derived class
>object through a base class pointer will work even if the destructor
>is not virtual, so long as the derived class adds no data members.

Sorry, but in the context of multiple inheritance and virtual bases that
does not work. (It is possible to change the layout of a class without
adding data:

struct X {
virtual ~X();

// whatever
};

struct Y {

// whatever
};

struct Z {
// whatever
};

struct A: public Y, virtual public X{

// whatever
};

struct B: public Z {
// whatever
};


struct C: public A, public B {
// whatever
};


Now I believe that in many compilers:

struct D: virtual public X, public C {
};

Has the same semantics as C but will have a different layout so you
better not delete either C or D through Y* or Z* variables.

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

On Fri, 10 May 2002, Steve Heller wrote:
>
>   I would like the standard to guarantee that deleting a derived class
> object through a base class pointer will work even if the destructor
> is not virtual, so long as the derived class adds no data members.

file Base.h:
---------------
class Base { };


file Derived.h:
-----------------
void foo(); // function foo has a user-visible effect

class Derived : public Base {
public:
 ~Derived() { foo(); }
];


file bar.cc:
--------------
#include "Base.h"

void bar(Base* bp) { delete bp; }


If Base does not have a virtual destructor, and you pass a Derived*
to bar, what mechanism do you propose for the Derived destructor
to be called?

--
Steve Clamage, stephen.clamage@sun.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                       ]

Francis Glassborow wrote:
> This is part of the more extensive problem of providing full support for
> literals which is one of the problems that the evolution workgroup has
> already identified as needing consideration.

As usual, you may want to look at Ada, which has already neatly
solved the problem. In Ada, literals of an enumeration type can
be character literals (and you can mix regular and character
literals in the same type) of the form 'x'. String literals are
arrays of the corresponding character literals. The types of
these literals are determined from context, so the literals
don't need any weird prefixes to distinguish between character,
wide character, or user-defined character tpes.

See <http://adahome.com/rm95/rm9x-03-05-02.html>.

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

 "Pete Becker" <petebecker@acm.org> wrote in message
 news:3CDA7DBA.8343B482@acm.org...
 > Instead of asking about language
 > features, put together a list of problems that aren't easily solved in
 > the language as it exists today.

Two things come to mind:

   1)  We need typeof() so that we can declare variables whose type is some
function of one or more other variables.  For instance,  suppose you had a
template class polynomial<X>.  If you wanted to declare a function to return
the sum of two polynomials of different types, the return type would have to
be something like polynomial<typeof(X() + Y())>.  There's no good way to do
this now without manually defining and maintaining some sort of traits
class, which is clumsy and error-prone.

   2)  If a class contains an STL container of some sort, it is likely to
have several pairs of functions looking like the following:
        iterator foo() { // some code}
        const_iterator foo() const {// the same code as above }

For maintainability, it would be nice if it were possible to define one of
these functions in terms of the other, but currently it is impossible.  The
const version cannot call the non-const version because const functions can
only call other const functions.  The non-const version cannot call the
const version because it generally is not possible to convert a
const_iterator to a plain iterator.

Joe Gottman




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

Scott Robert Ladd wrote:

> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3CDA7DBA.8343B482@acm.org...
>
>>Let me suggest a different approach. Instead of asking about language
>>features, put together a list of problems that aren't easily solved in
>>the language as it exists today.


     OK.

     Memory/pointer safety, or lack thereof - the big one.
Cause of more bugs than all the other problems put together.
Yes, I know all the usual arguments.  But as C# and Java
gain market share, C++ can't ignore this problem any more.

     Concurrency - the language needs to know about threads
and locking.  Maybe it doesn't need to know much, but ignoring
the problem doesn't make it go away.

     Marshalling - it's hard to hook up C++ to any of the
many marshalled calling conventions (DCOM/CORBA/RMI/.NET/etc.)
without a stub generator or too much manual work.

     The "include" approach to interfaces fosters too
much unwanted interdependency in large projects.  Changing
the private part of a class forces a recompile of the
class's users.  On large projects, this generates
huge amounts of irrelevant recompile activity, and then
trying to avoid those recompiles warps designs out of shape.

     It's possible to fix all these problems without going
to an interpretive environment like .NET or Java.  Is
the C++ community up to the job?

     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                       ]

Steve Heller <steve@steveheller.com> writes:

|>    I would like the standard to guarantee that deleting a derived
|>  class object through a base class pointer will work even if the
|>  destructor is not virtual, so long as the derived class adds no
|>  data members.

And what if the derived class has virtual functions, and the base
class not?  Or if the derived class derives from two base classes?  Or
virtual inheritance?

The question isn't simple.  I'd also like to see something along the
lines of "trivial inheritance", which would allow an array of Derived
to work like an array of Base.  But I recognize that defining "trivial
inheritance" isn't trivial, and I don't know if the effort is really
worth the gain.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

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

"Paul Mensonides" <pmenso57@attbi.com> wrote in message
news:shjD8.13429$1B.435@rwcrnsc51.ops.asp.att.net...
> "Edward Diener" <eldiener@earthlink.net> wrote in message
> news:DlhD8.4159$Nt3.321152@newsread2.prod.itd.earthlink.net...
>
> [snip]
>
> > <character-type>"literal string" and
> > <character-type>'literal character'
>
> [snip]
>
> > CharT digits [] = <CharT>"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
>
> If you use a pointer (rather than an array), this might help:

Something like ?::

CharT * digits = <CharT>"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";

However one is allowed to write:

char digits[] = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";

or

wchar_t digits[] = L"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";

I was just illustrating my proposal, using the original example which Eric
Niebler presented, for extending the literal types to use templated syntax,
ie. <type>literal, so that they can be used more easily in template classes
and functions.

> --------------------
>
> template<class T> inline T local_of(const char*, const wchar_t*);
>
> template<> inline const char* local_of(const char* used, const wchar_t*) {
>     return used;
> }
>
> template<> inline const wchar_t* local_of(const char*, const wchar_t*
used) {
>     return used;
> }
>
> #define LOCAL_OF(type, sz) local_of<type>(sz, L ## sz)
>
> --------------------
>
> This is what I ended up using.  The problem is that you cannot initialize
an
> array this way, like you can with a normal string literal--thereby making
it
> non-modifiable.

Yes, it has that limitation.

>
> e.g....
>
> struct something { };
>
> template<class T> inline std::basic_ostream<T>&
> operator<<(std::basic_ostream<T>& os, something) {
>     return os << LOCAL_OF(T, "something");
> }

Yes, a neat solution.

Of course if more character types are added to the language and your
template function accepts another one, then you have to change your
solution. Whereas my proposal for a syntax change would take care of that at
the compiler level.

template<class T> inline std::basic_ostream<T>&
operator<<(std::basic_ostream<T>& os, something) {
    return os << <T>"something";

Of course this doesn't presently exist but illustrates my proposal.


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

David Rasmussen <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> writes:

>Making a language better is not always about adding normal language
>features. One of the things I would like very much in C++, that is
>impossible now, is to be able to disable a language feature. That is, I
>would like to be able to state somehow in my program, that old-style
>casts are not allowed.

FWIW, there is some prior art for this in Ada.
Ada 95 has a `pragma Restrictions' declaration for this,
with a large number of standard restrictions, e.g. `No_Exceptions',
`No_Floating_Point', `No_Recursion', `No_IO', `No_Unchecked_Conversion',
etc.

See sections 13.12, H.4, and D.7 in the Ada Reference Manual for details.

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

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

Steve Clamage wrote:
> If Base does not have a virtual destructor, and you pass a Derived*
> to bar, what mechanism do you propose for the Derived destructor
> to be called?

None. He wants this to act just like deleting an actual Base
object, and not have undefined behavior. It's an unworkable
proposal for a number of reasons.

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

> When suggesting a new feature giving a brief
> recap of the rationale would, even if nothing else,
> make the thread more accessible to those who
> haven't seen previous relevant discussions.
>
> I also think there's something to be said for
> dreaming out loud about features even if they
> don't have immediately obvious applications.
> As long as the two ends meet up eventually it
> doesn't really matter in which order they were
> first thought of.

That is exactly the reason why I started the thread:

    - I was trying to find out if anyone had any insider info on
      any of the new proposals/additions
    - wanted to learn what other "unsolved/unsolvable" C++ problems there
are.
        (because I always enjoy trying to come up with a solution with the
current language
         features)

Anyway, all the things that were mentioned in the original post are being
considered
by the C++ committee, AFAIK. (Btw. is there a complete summary of proposed
extensions
anywhere on the net? I know about the papers on WG11 website btw... )

Since we are in the middle of feature creep, why not carry on: Here's a
feature and a rationale:

Allow specialisation of member templates without specialising the outer
template first.

Here's an example:
Remember Andrei's book and the Conversion<> template? He says he finds it
difficult
to remember which way the conversion is going, and hence the SUPERSUBCLASS
macro.
Now imagine this:

template<typename T>
struct ConversionFrom
{
    template<typename U>
    struct To
    {
        //..ConversionHelper stuff...
        static const bool exists = //conversion Helper stuff...
        static const bool exists2Way = exists && ConversionFrom<U>::template
To<T>::exists;
        static const bool sameType = false;
     };
};

Now I could write:
ConversionFrom<Type1>::To<Type2>::exists
IMHO this is more readable and has also the added advantage of being
namespace scoped (unlike macros)

if only I could do this:

template<>
template<class T>
struct ConversionFrom<T>::To<T>
{
        exists = true;
        static const bool exists2Way = true;
        static const bool sameType = true;

};

Now I could use partial specialisation on To<> but why should something so
simple be
so "complicated" to do?
This can be resolved by having a SameType<> template with two parameters...

Some other things (apart from the ones I already mentioned):
    - Why not allow forward declarations of inner classes/classes in
namespaces? There isn't a way to
         do the first and it is extremely irritating having to reopen a
namespace (especially if it is nested)
        just to create a forward declaration.

These are a few of my gripes.

Tom








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

Pete Becker wrote:
> Tom Puverle wrote:
>
>>I am trying to put together a wish list of language extensions that people
>>would like to see in C++0x.
>
>
> Let me suggest a different approach. Instead of asking about language
> features, put together a list of problems that aren't easily solved in
> the language as it exists today. Language features aren't an end in
> themselves, but are a way of solving problems. Focusing initially on
> problems rather than solutions will lead to a better set of solutions.
>

Ok, here's one.

Publicly deriving from std::string risks a delete through a base class
pointer, and so it risks undefined behavior and is a nono. Same is true
for the containers.

I've seen arguments for and against subclassing those things at all, and
I've seen arguments for and against adding virtual destructors to them
in order to support the subclassing. What I haven't seen is a proposal
to end the argument.

It seems to me that this should do the trick. In fact, it's so glaringly
obvious that I wonder if I just missed the discussion.

struct no_virtual_destructor{};

struct virtual_destructor{ virtual ~virtual_destructor(){} };

template<..., class destructor_policy = no_virtual_destructor>
   class basic_string : public destructor_policy {...};

The default case is unchanged, so it shouldn't break anything.

Someone who wants to subclass it can just change the destructor policy
and be on their merry way.

It will also let people who want to "abuse" the mechanism and make other
functions virtual.

It doesn't change the argument about subclassing at all, but it sure
makes it less interesting.

--
I <3 Comeau C++: http://www.comeaucomputing.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                       ]

[ Moderator - this was sent to my private address, I expect the sender
replied to me rather than the group by accident. Could you put it on the
newsgroup under his name please ]

> -----Original Message-----
> From: Felix Shvaiger [mailto:fshvaige@cisco.com]
> Sent: 14 May 2002 09:28
> To: Tom Puverle
> Subject: Re: C++0x Wish list
]

Wish 1:
Some keyword like 'noinherit' which mean,
that virtual method could not be inherited by
derived class, but rather must be overrided
in each direct or undirect derived class.
This will persuade the author of derived class
to do not forget to override such method every time.
Example:
class ClassUID;
class BaseClass {
public:
virtual noinherit ClassUID get_class_uid ();
};
class DerivedClass1 :public BaseClass {
public:
ClassUID get_class_uid ();
};
class DerivedClass2 :public BaseClass {
public:
int a;
};
class DerivedClass3 :public BaseClass {
public:
ClassUID get_class_uid ();
};
BaseClass v; /* OK */
DerivedClass1 v1; /* OK */
DerivedClass2 v2; /* Compilation Error: method "ClassUID get_class_uid
()" must be defined in DerivedClass2 in order to instantiate it (like
abstract method) */
DerivedClass3 v3; /* OK */


---
[ 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 <a7qC8.4520$xb4.730873@news6-win.server.ntlworld.com>, Garry
Lancaster <glancaster@ntlworld.com> writes
>Tom Puverle:
  <snip>
>>                     RTTI:
>>                            - add a "class()" member function to type_info
>> that returns a compiler independent unique identifier for the class of the
>> object
  <snip>
>Off
>the top of my head we would have to consider:
>
>- namespaces. Is the namespace of a type part
>of its name? If so, how is membership of the
>anonymous namespace signified?
>
>- typedefs. Presumably we use the original name
>of the class not any typedef-alias in use? (Or, for
>that matter any namespace-alias.)
>
>- Templates. How to specify template parameters
>used for a class template instantiation.
>
>None of this is rocket science. You would think
>a consensus could be reached. Still, maybe I'm
>missing something.

There may be extra considerations, depending on what is being wished
for.

- If the application is spread over thousands of computers do we want my
mumble::Thing class and your mumble::Thing class in different computers
to have different identifiers?

- What about the standard library? Does vector<int> always have the same
identifier, or does it depend on whose library it comes from?

  John
--
John Harris
  mailto:john@jgharris.demon.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                       ]

Here are some extensions that I would like to see in a future version of the
C++ language.

1) Improved numeric limits such as the smallest and largest number of each
floating point type, whose inverse is also valid and normalized.

2) A way to use placement operator delete and operator delete[] for memory
allocated with a placement operator new.

3) A way to directly specify in a class declaration, that the class cannot
be used as a base class. This would permit treating all the class's methods
as non-virtual and improve code that uses the class.



--
The Klingons' favorite food was named by the first Earthling to see it.
"Pete Becker" <petebecker@acm.org> wrote in message
news:3CDA7DBA.8343B482@acm.org...


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

"Pete Becker" <petebecker@acm.org> wrote in message
news:3CDA7DBA.8343B482@acm.org...
> Let me suggest a different approach. Instead of asking about language
> features, put together a list of problems that aren't easily solved in
> the language as it exists today.


Bravo, Pete!

It seems like people want to throw in the kitchen sink without figuring out
if we need one -- or if, perhaps, we can put one together with the existing
plumbing.

--
Scott Robert Ladd
Coyote Gulch Productions -- http://www.coyotegulch.com
No ads. Just very free (and unusual) code and articles


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

"Pete Becker" <petebecker@acm.org> wrote in message
news:3CDA7DBA.8343B482@acm.org...
> Instead of asking about language
> features, put together a list of problems that aren't easily solved in
> the language as it exists today.

Good suggestion.

Not too long ago, this code appeared in a column by a well-respected C++
guru.

     template<class CharT, class Traits>
     basic_ostream<CharT, Traits>& operator<<
       ( basic_ostream<CharT, Traits>& o, const Num& n )
     {
       long value = n.Value();
       basic_string<CharT, Traits> s;

       CharT digits []
         = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";

<snip>

The code compiles fine when CharT==char, but if it is anything else the
compile breaks on the declaration of the digits array.  Basically, string
literals and template code don't mix.  The fact that this error slips into
the code of even the most seasoned experts demonstrated that it's a real
problem.

In the past, I have hacked around the problem like this:

    CharT digits [] = { '0', '1', '2', ... };

but this is (a) tedius, (b) verbose, and (c) wrong.  It's wrong becuase if
CharT==wchar_t, then there is no guarantee that assigning a char to a
wchar_t yields anything meaningful.

Of course, I could defer the string conversion to run-time and use a locale,
but that's not guaranteed to yield the same results as if the compiler did
the conversion, as it would have to for L"..." wide string literals.

Does anybody have a solution for this?

Thanks,
Eric



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

Scott Robert Ladd wrote:
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3CDA7DBA.8343B482@acm.org...
>
>>Let me suggest a different approach. Instead of asking about language
>>features, put together a list of problems that aren't easily solved in
>>the language as it exists today.
>
>
>
> Bravo, Pete!
>
> It seems like people want to throw in the kitchen sink without figuring out
> if we need one -- or if, perhaps, we can put one together with the existing
> plumbing.
>

I agree that the approach Pete suggests is good. But whether something
can be done with the existing language or not, is not a good measure of
anything IMO. A very good example that always spring to mind when I'm
thinking about the future of C++, is Alexandrescu's Loki library. When I
read Modern C++ Design, I was first impressed (I still am). But then I
began to think: Why should it be so hard to express something as useful
and natural as these concepts? In my opinion Loki is only scratching the
surface of techniques that need much more language support. I am of the
view that as much work as possible, should be left to the compiler
implementor. And there are many many examples of things that can be done
today, but that really shouldn't be done my programmers but by compiler
implementors. The modularity on file level in C++ is based on something
as trivial as a preprocessor and header files. Why? A programmer should
only need to state the concepts and their interfaces, and the interface
of a module. No need to deal with header files, guards etc. Another
example is forward declaration. Why should the programmer go out of his
way to help the compiler, instead of focussing on the problem at hand? A
compiler could easily deal with this.

Generally, there are a lot of useful things that the language and the
compilers could support, while still maintaining the zero-overhead
principle, static type safety etc. The entire concept of "compile-time
programming" as done in Loki and Modern C++ Design, could have much more
language support.

Making a language better is not always about adding normal language
features. One of the things I would like very much in C++, that is
impossible now, is to be able to disable a language feature. That is, I
would like to be able to state somehow in my program, that old-style
casts are not allowed. I have had bugs that came from the fact that
Identifier(something) can be a cast, but also a function or macro call.
Of course, this is all my fault, but it would be nice if the language
had features for helping me not make such a bug, without me having to
resort to complex abstraction features when they aren't needed. In
general, if C++ was able to specify what features and constructs were
allowed or not, there could be defined strictness-levels, as in other
transitional languages that have to be backward-compatible, but also
wants to suggest a new and better way of doing things (like XHTML, no
comparison BTW). This way, there could simply be a strictness level that
I as a programmer was able choose. Sometimes it is a very good thing to
be restricted, if it means that you're restricted from making bugs.

I know this post is a little disorganized, but I am not trough thinking
about this (who is?). All I'm saying is, that C++ could have a lot more
features that would make the programmer focus on the job, and the
compiler on the technicalities, while still retaining it's zero-overhead
principle, typechecking and native compilation features.

/David

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

"David Sachs" <sachs@fnal.gov> wrote:

>Here are some extensions that I would like to see in a future version of the
>C++ language.
>
>1) Improved numeric limits such as the smallest and largest number of each
>floating point type, whose inverse is also valid and normalized.
>
>2) A way to use placement operator delete and operator delete[] for memory
>allocated with a placement operator new.
>
>3) A way to directly specify in a class declaration, that the class cannot
>be used as a base class. This would permit treating all the class's methods
>as non-virtual and improve code that uses the class.

  I would like the standard to guarantee that deleting a derived class
object through a base class pointer will work even if the destructor
is not virtual, so long as the derived class adds no data members.

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt

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

Scott Robert Ladd wrote:
>=20
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3CDA7DBA.8343B482@acm.org...
> > Let me suggest a different approach. Instead of asking about language
> > features, put together a list of problems that aren't easily solved i=
n
> > the language as it exists today.
>=20
> Bravo, Pete!

Are things meant to provide MORE convenience/result in LESS=20
"convoluted"/weird C++ "solutions" (and I'm NOT talking about=20
templates/"generic-meta-programming", BTW ;-)) also meant to=20
be among the "problems that aren't easily solved in the=20
language as it exists today"?

Oh! BTW, Folks, is THIS "a problem":=20

ISO/IEC 14882:1998(E) =A9 ISO/IEC Pg. 642:

"~sentry();

 4 If ((os.flags() & ios_base::unitbuf) && !uncaught_exception())=20
   is true, calls os.flush()."

<?> ;-) ;-)

regards,
alexander.

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

David Sachs wrote:
>
> Here are some extensions that I would like to see in a future version of the
> C++ language.
....
> 2) A way to use placement operator delete and operator delete[] for memory
> allocated with a placement operator new.

That issue doesn't come up; there's no such thing as "memory allocated
with a placement operator new". That's what makes it a placement
operator new - the memory has already been allocated by the time that
you use the 'new' operator to construct an object in it.

---
[ 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 <0QGC8.244555$nc.36284525@typhoon.tampabay.rr.com>, Scott
Robert Ladd <scott@coyotegulch.com> writes
>"Pete Becker" <petebecker@acm.org> wrote in message
>news:3CDA7DBA.8343B482@acm.org...
>> Let me suggest a different approach. Instead of asking about language
>> features, put together a list of problems that aren't easily solved in
>> the language as it exists today.
>
>
>Bravo, Pete!
>
>It seems like people want to throw in the kitchen sink without figuring out
>if we need one -- or if, perhaps, we can put one together with the existing
>plumbing.

Actually the evolution work group of WG21 is drafting a format for
submissions which does exactly this, requires that a proposal includes
the problem it is intended to solve. Hopefully by autumn we will both
guidelines and examples available.


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

In article <3cdb0a06$1@news.microsoft.com>, Eric Niebler
<ericne@microsoft.com> writes
>In the past, I have hacked around the problem like this:
>
>    CharT digits [] = { '0', '1', '2', ... };
>
>but this is (a) tedius, (b) verbose, and (c) wrong.  It's wrong becuase if
>CharT==wchar_t, then there is no guarantee that assigning a char to a
>wchar_t yields anything meaningful.
>
>Of course, I could defer the string conversion to run-time and use a locale,
>but that's not guaranteed to yield the same results as if the compiler did
>the conversion, as it would have to for L"..." wide string literals.
>
>Does anybody have a solution for this?

This is part of the more extensive problem of providing full support for
literals which is one of the problems that the evolution workgroup has
already identified as needing consideration.


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

In article <3CDB847F.3000907@gmx.spam.egg.sausage.and.spam.net>, David
Rasmussen <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> writes
>I agree that the approach Pete suggests is good. But whether something
>can be done with the existing language or not, is not a good measure of
>anything IMO. A very good example that always spring to mind when I'm
>thinking about the future of C++, is Alexandrescu's Loki library. When
>I read Modern C++ Design, I was first impressed (I still am). But then
>I began to think: Why should it be so hard to express something as
>useful and natural as these concepts? In my opinion Loki is only
>scratching the surface of techniques that need much more language
>support. I am of the view that as much work as possible, should be left
>to the compiler implementor. And there are many many examples of things
>that can be done today, but that really shouldn't be done my
>programmers but by compiler implementors.

It is possible to do OOP in C but it is hard work because C provides
inadequate support. In the same way, it is possible to do
meta-programming in C++ but it is hard work because currently C++ does
not provide adequate support. What the work of people like Andrei shows
is the value of meta-programming. Now the question should be whether
this value is high enough to require direct support from the language.

Note that there are no problems that cannot be solved in assembler but
there are quite a few that we would not want to. When we think that an
enhancement of C++ must be targeted at programming problems we need to
understand that we should be considering both the ease of solving a
problem and the portability of the solution.


--
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 Kuyper Jr. wrote:
> David Sachs wrote:
>
>>Here are some extensions that I would like to see in a future version of the
>>C++ language.
>
> ....
>
>>2) A way to use placement operator delete and operator delete[] for memory
>>allocated with a placement operator new.
>
>
> That issue doesn't come up; there's no such thing as "memory allocated
> with a placement operator new". That's what makes it a placement
> operator new - the memory has already been allocated by the time that
> you use the 'new' operator to construct an object in it.

I think last time this was discussed to death, we concluded
that "placement operator new" is ambiguous: to some it means the
trivial standard-supplied form which takes a void* and returns
the value it is given, while to others (also reasonably) it
means any form which has more arguments than just a std::size_t.
For the latter group, placement new may well allocate memory.

--
James Dennett <jdennett@acm.org>

---
[ 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 Dennett wrote:
>
> James Kuyper Jr. wrote:
> > David Sachs wrote:
> >
> >>Here are some extensions that I would like to see in a future version of the
> >>C++ language.
> >
> > ....
> >
> >>2) A way to use placement operator delete and operator delete[] for memory
> >>allocated with a placement operator new.
> >
> >
> > That issue doesn't come up; there's no such thing as "memory allocated
> > with a placement operator new". That's what makes it a placement
> > operator new - the memory has already been allocated by the time that
> > you use the 'new' operator to construct an object in it.
>
> I think last time this was discussed to death, we concluded
> that "placement operator new" is ambiguous: to some it means the
> trivial standard-supplied form which takes a void* and returns
> the value it is given, while to others (also reasonably) it
> means any form which has more arguments than just a std::size_t.
> For the latter group, placement new may well allocate memory.

I don't believe that's ambigous; the standard quite clearly defines
placement new as including forms of overloading other than the one
supplied by the standard. I just wasn't thinking about that when I wrote
that paragraph.

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

"Eric Niebler" <ericne@microsoft.com> wrote in message
news:3cdb0a06$1@news.microsoft.com...
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3CDA7DBA.8343B482@acm.org...
> > Instead of asking about language
> > features, put together a list of problems that aren't easily solved in
> > the language as it exists today.
>
> Good suggestion.
>
> Not too long ago, this code appeared in a column by a well-respected C++
> guru.
>
>      template<class CharT, class Traits>
>      basic_ostream<CharT, Traits>& operator<<
>        ( basic_ostream<CharT, Traits>& o, const Num& n )
>      {
>        long value = n.Value();
>        basic_string<CharT, Traits> s;
>
>        CharT digits []
>          = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
>
> <snip>
>
> The code compiles fine when CharT==char, but if it is anything else the
> compile breaks on the declaration of the digits array.  Basically, string
> literals and template code don't mix.  The fact that this error slips into
> the code of even the most seasoned experts demonstrated that it's a real
> problem.
>
> In the past, I have hacked around the problem like this:
>
>     CharT digits [] = { '0', '1', '2', ... };
>
> but this is (a) tedius, (b) verbose, and (c) wrong.  It's wrong becuase if
> CharT==wchar_t, then there is no guarantee that assigning a char to a
> wchar_t yields anything meaningful.
>
> Of course, I could defer the string conversion to run-time and use a
locale,
> but that's not guaranteed to yield the same results as if the compiler did
> the conversion, as it would have to for L"..." wide string literals.
>
> Does anybody have a solution for this?

Since I have run into situations which are the same as yours, I don't have a
solution but I have a proposal which will allow the use of string literals
in template classes. Instead of L"literal string" to signify wide character
literals and L'literal character' to signify a wide character literal, we
should add the notation:

<character-type>"literal string" and
<character-type>'literal character'

where character type will be any built-in language character type, of which
we currently have two, "char" and "wchar_t", but of which C++ may add more
in the future. Thus the notation can expand in the future to include other
character types in our string literals. This would solve your problem above
by allowing you to specify,

CharT digits [] = <CharT>"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";

and you would have the correct type of string literal.

This same type of notation should be extended to numeric literals. So
instead of writing "46L" to signify a long integer literal value, we should
be allowed to write "<long>46" instead, and once again this would solve the
problem of class templates parameterized on numeric types having to
represent numeric literal values based on the type. Although of course I
recognize that class templates parameterized on numeric types are much less
common than those parameterized on character types, the notational concept
is just as easily adapted to numeric literal values. The proposal for
numeric types would similarly be allowing this notation:

<numeric type>numeric-literal-value

and could just as easily be extended to new futures numeric types and
numeric literal values.

I have chosen putting the type of the literal in front of the literal
because of the syntactical similarity to the C++ cast expressions (
dynamic_cast, static_cast etc.), but if others feel that this would
introduce parsing difficulties, putting the type in back of the literal
might be just as acceptable.


---
[ 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:
>
> It is possible to do OOP in C but it is hard work because C provides
> inadequate support. In the same way, it is possible to do
> meta-programming in C++ but it is hard work because currently C++ does
> not provide adequate support. What the work of people like Andrei shows

Exactly.

> is the value of meta-programming. Now the question should be whether
> this value is high enough to require direct support from the language.
>

Sure. I think the real question is: What is missing that makes this so
hard? I think it would be a bad idea to make changes to the language
that target just these cases. Instead, we could ask ourselves: What is
the most general extension to the language, that would allow to do
things of this _class_, and does it make sense to make this change. In
the case of meta-programming, I don't see why it shouldn't be easier to
do. There is a whole class of concepts and problems that naturally could
use this.

> Note that there are no problems that cannot be solved in assembler but
> there are quite a few that we would not want to. When we think that an

Exactly. Ideally, C++ should allow/provide everything a programmer
wants, as long as it doesn't violate the zero-overhead principle etc. I
often find myself thinking: Grrr, this idea is simple, but it is really
difficult to express in C++, or: This idea _could_ really be done in a
static no-overhead fashion, if the language had the features, but
instead, I have to settle with a more dynamic version, or resort to
simple typographical endavours such as copying and pasting etc.

> enhancement of C++ must be targeted at programming problems we need to
> understand that we should be considering both the ease of solving a
> problem and the portability of the solution.
>

Sure, but all of the things I am talking about are portable "front-end"
stuff, not detailed platform-dependant back-end stuff. The only thing
that will get more difficult, would be the writing of the compiler. As I
said, there is no reason why I should have to make forward declarations
or use a preprocessor. It is only there to make life easier for the
compiler implementor. These are just simple examples.

/David

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

> > Let me suggest a different approach. Instead of asking about language
> > features, put together a list of problems that aren't easily solved in
> > the language as it exists today.

1) I didn't say I wanted to add any features. I asked about the features
"people would like to see" in C++0x, sort of a conversation starter.

> Bravo, Pete!
>
> It seems like people want to throw in the kitchen sink without figuring
out
> if we need one -- or if, perhaps, we can put one together with the
existing
> plumbing.

I agree completely. However, why should the plumber have to bend a metal
pipe when he could use a plastic one? Also there is only as much bending as
a pipe will take. And sometimes it is not possible at all.


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

"Edward Diener" <eldiener@earthlink.net> wrote in message
news:DlhD8.4159$Nt3.321152@newsread2.prod.itd.earthlink.net...

[snip]

> <character-type>"literal string" and
> <character-type>'literal character'

[snip]

> CharT digits [] = <CharT>"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";

If you use a pointer (rather than an array), this might help:

--------------------

template<class T> inline T local_of(const char*, const wchar_t*);

template<> inline const char* local_of(const char* used, const wchar_t*) {
    return used;
}

template<> inline const wchar_t* local_of(const char*, const wchar_t* used) {
    return used;
}

#define LOCAL_OF(type, sz) local_of<type>(sz, L ## sz)

--------------------

This is what I ended up using.  The problem is that you cannot initialize an
array this way, like you can with a normal string literal--thereby making it
non-modifiable.

e.g....

struct something { };

template<class T> inline std::basic_ostream<T>&
operator<<(std::basic_ostream<T>& os, something) {
    return os << LOCAL_OF(T, "something");
}

Paul Mensonides

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

[snip discussion of  making the result of type_info.name()
compiler independent]

John G. Harris:
> There may be extra considerations, depending on what is being wished
> for.
>
> - If the application is spread over thousands of computers do we want my
> mumble::Thing class and your mumble::Thing class in different computers
> to have different identifiers?

If the classes have the same name (and, although
this is jumping the gun a bit on whether namespaces
should be part of the name, assuming they are in
the same namespace) their type_info.name() should
be the same. If you wish to add a computer identifier
to the resulting string, there are plenty of ways of doing
this. In a serialized representation of an object model
you'd probably want a computer identifier zero or one
times rather than repeated as part of every class name.

> - What about the standard library? Does vector<int> always have the same
> identifier, or does it depend on whose library it comes from?

It should always have the same name I think. And
that name should probably be "std::vector<int>".

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---
[ 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 <abf15l$8t2$1@info1.fnal.gov>, David Sachs <sachs@fnal.gov>
writes
>2) A way to use placement operator delete and operator delete[] for memory
>allocated with a placement operator new.

That is much harder than it seems. First off, it would necessary to
track how dynamic objects have been created (the only case that that is
currently required is during construction which is relatively
inexpensive)

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

Pete Becker:
> > Let me suggest a different approach. Instead of asking
> > about language features, put together a list of problems
> > that aren't easily solved in the language as it exists today.

Scott Robert Ladd:
> Bravo, Pete!
>
> It seems like people want to throw in the kitchen sink
> without figuring out if we need one -- or if, perhaps,
> we can put one together with the existing plumbing.

Just because we don't see the problem-related
groundwork in a particular discussion of a feature,
doesn't mean it never happened elsewhere.

When suggesting a new feature giving a brief
recap of the rationale would, even if nothing else,
make the thread more accessible to those who
haven't seen previous relevant discussions.

I also think there's something to be said for
dreaming out loud about features even if they
don't have immediately obvious applications.
As long as the two ends meet up eventually it
doesn't really matter in which order they were
first thought of.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---
[ 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 trying to put together a wish list of language extensions that people
would like to see in C++0x.
Any contributions and opinions on what is likely to make it into the new
standard would be greatly appreciated...
Let me set the ball rolling:

                    TEMPLATES:
                            - templatized typedef
                            - typeof()
                            - function template partial specialisation

                    RTTI:
                           - add a "class()" member function to type_info
that returns a compiler independent unique identifier for the class of the
object

Thanks.







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

Tom Puverle wrote:
>
> I am trying to put together a wish list of language extensions that people
> would like to see in C++0x.

Let me suggest a different approach. Instead of asking about language
features, put together a list of problems that aren't easily solved in
the language as it exists today. Language features aren't an end in
themselves, but are a way of solving problems. Focusing initially on
problems rather than solutions will lead to a better set of solutions.

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

Tom Puverle:
>                     TEMPLATES:
>                             - templatized typedef
>                             - typeof()
>                             - function template partial specialisation

These have all been pretty well discussed both on this
newsgroup and elsewhere.

>                     RTTI:
>                            - add a "class()" member function to type_info
> that returns a compiler independent unique identifier for the class of the
> object

You know that there's already a type_info::name()
member function? Its value isn't compiler independent
though and it would be nice if it were (particularly
for things like serialization frameworks) It isn't
quite as straightforward as it seems though. Off
the top of my head we would have to consider:

- namespaces. Is the namespace of a type part
of its name? If so, how is membership of the
anonymous namespace signified?

- typedefs. Presumably we use the original name
of the class not any typedef-alias in use? (Or, for
that matter any namespace-alias.)

- Templates. How to specify template parameters
used for a class template instantiation.

None of this is rocket science. You would think
a consensus could be reached. Still, maybe I'm
missing something.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

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