In article <92glhb$88s$1@nnrp1.deja.com>, AllanW <allan_w@my-deja.com> wrote:
>But now, ask yourself -- when these people (or companies)
>decide to make a "new, better" language, why do they almost
>always start by making changes to C++? For instance, why did
>Sun make Java so very "C++ - like" using the same keywords
>and so on? And why did Microsoft call their new language C#
>and base it on C++, instead of calling it called Basic# and
>basing it on Visual Basic, or calling it FoxPro# and basing
>it on FoxPro?

With Java, one felt that C++'s multiparadigm philosophy was making that
language C++ too difficult, so one deliberately constructed a simplified
version.

With C#, Microsoft has the publically expressed policy of "improving on
every standard", thus making it incompatible, only able to run under their
operative system. -- Perhaps that's why they created C# , what do I know?
:-)

These are not really attempts of finding future replacements for C++ (or
at least the Java approach).

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <S7q26.5669$7f3.435131@bgtnsc07-news.ops.worldnet.att.net>,
"Tony" <tony@my.isp.net> wrote:
>> What is this "generic.h" file?
>
>generic.h was supplied with compilers (probably and hopefully still is)

Not on mine; I would not have asked if it was.

>before templates were
>introduced. It contains macros that facilitate the development of generic
>classes using macros and the
>preprocessor.

Oh, I thought you meant a header for creating a polymorphic variable (a
root class which other classes can derive from and a class maintaining the
polymorphic root class pointer).

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Hans Aberg" <remove.haberg@matematik.su.se> wrote in message
news:remove.haberg-0401012034240001@du132-226.ppp.su-anst.tninet.se...
> In article <92glhb$88s$1@nnrp1.deja.com>, AllanW <allan_w@my-deja.com>
wrote:
> >But now, ask yourself -- when these people (or companies)
> >decide to make a "new, better" language, why do they almost
> >always start by making changes to C++? For instance, why did
> >Sun make Java so very "C++ - like" using the same keywords
> >and so on? And why did Microsoft call their new language C#
> >and base it on C++, instead of calling it called Basic# and
> >basing it on Visual Basic, or calling it FoxPro# and basing
> >it on FoxPro?
>
> With Java, one felt that C++'s multiparadigm philosophy was making that
> language C++ too difficult, so one deliberately constructed a simplified
> version.
>
> With C#, Microsoft has the publically expressed policy of "improving on
> every standard", thus making it incompatible, only able to run under their
> operative system. -- Perhaps that's why they created C# , what do I know?
> :-)
>
> These are not really attempts of finding future replacements for C++ (or
> at least the Java approach).

I agree. They appear to be attempts to create proprietary products in place
of
widely accepted open standards. The same thing seems to be happening with
IRC
and "Instant Messaging".

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Hans Aberg" <remove.haberg@matematik.su.se> wrote in message
news:remove.haberg-0401012028480001@du132-226.ppp.su-anst.tninet.se...
> In article <S7q26.5669$7f3.435131@bgtnsc07-news.ops.worldnet.att.net>,
> "Tony" <tony@my.isp.net> wrote:
> >> What is this "generic.h" file?
> >
> >generic.h was supplied with compilers (probably and hopefully still is)
>
> Not on mine; I would not have asked if it was.

I thought it was a standard thing. Perhaps it was a vendor thing. My
compiler
is Borland 5.02.

> >before templates were
> >introduced. It contains macros that facilitate the development of generic
> >classes using macros and the
> >preprocessor.
>
> Oh, I thought you meant a header for creating a polymorphic variable (a
> root class which other classes can derive from and a class maintaining the
> polymorphic root class pointer).

Nope, just an alternative to using template mechanisms.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Tony" <tony@my.isp.net> writes:

|>  "Hans Aberg" <remove.haberg@matematik.su.se> wrote in message
|>  news:remove.haberg-0401012028480001@du132-226.ppp.su-anst.tninet.se...
|>  > In article <S7q26.5669$7f3.435131@bgtnsc07-news.ops.worldnet.att.ne=
t>,
|>  > "Tony" <tony@my.isp.net> wrote:
|>  > >> What is this "generic.h" file?

|>  > >generic.h was supplied with compilers (probably and hopefully
|>  > >still is)

|>  > Not on mine; I would not have asked if it was.

|>  I thought it was a standard thing. Perhaps it was a vendor thing. My
|>  compiler is Borland 5.02.

It's not in the standard.  It was pretty much a defacto standard 10
years ago, however, and I would expect any quality compiler to furnish
it, for reasons of backward compatibility.  (I last used it about four
years ago.)

--=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(069)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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <DYcVKIAmYLU6EwBJ@ntlworld.com>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <memo.20001231184334.21243E@a.btinternet.com>, Dave Harris
> <brangdon@cix.compulink.co.uk> writes
> >A C++ programmer can look at Java code and understand what it is
> >doing, much more immediately than with, eg, Smalltalk or Lisp code.

> I do not agree, the different semantics of Java make this. IMO. an
> illusion.

Maybe, but the C++ programmer will have the impression that he
understands it, and when you're selling, it is the impressions that
count, not the reality.

--
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(069)63198627


Sent via Deja.com
http://www.deja.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James.Kanze@dresdner-bank.com wrote:
>
> In article <3A312034.4DCA25D8@evtechnology.com>,
>   James Dennett <james@evtechnology.com> wrote:
>
> > As each of the messages on this thread have passed by at least one
> > of us, I guess we're "in the loop" even if only fairly passively :)
>
> The "us" gives the impression that you are also a moderator of
> comp.std.c++.

Can't get anything past you, can I... you're right, I have the pleasure
of helping to moderate comp.std.c++.

> I know that at least one other person was added since
> the group was founded.  But the FAQ and the moderation policy still
> only mention the original three.  Wouldn't it be a good idea to update
> them?

Matt Austern has now updated the HTML documents to reflect the
current moderation panel, which also includes Phil Edwards.  Thanks
for pointing this out.

-- 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Hans Aberg" <remove.haberg@matematik.su.se> wrote in message
news:remove.haberg-2012002256180001@du148-226.ppp.su-anst.tninet.se...
> In article <x5S%5.973$rn6.92581@bgtnsc06-news.ops.worldnet.att.net>,
> "Tony" <tony@my.isp.net> wrote:
> >  For instance, I
> >just
> >may go back to generic.h to replace the need for templates.
>
> What is this "generic.h" file?

generic.h was supplied with compilers (probably and hopefully still is)
before templates were
introduced. It contains macros that facilitate the development of generic
classes using macros and the
preprocessor.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hans Aberg wrote:
> So the next question is really, what will replace C++? Perhaps there
> should be a group comp.c++.replacement...

Perhaps there should be a group comp.c++.replacement-of-the-month,
with subgroups .gnu, .java, .sea, .c#, and so on.

The inventors of these languages obviously feel that there's
something they want out of a programming language that they
can't get from any other language that they know of, not even
from C++. So they decide to invent a new language. This is a
laudable goal; every new language attempt adds to the global
understanding of what computer languages ought to do.

(The practice of announcing "major new" languages before
they're even fully designed is another story. If this is
what's required for a language to be successful, then we can
be sure that all new successful languages will be created by
large corporations. That's a pity.)

But now, ask yourself -- when these people (or companies)
decide to make a "new, better" language, why do they almost
always start by making changes to C++? For instance, why did
Sun make Java so very "C++ - like" using the same keywords
and so on? And why did Microsoft call their new language C#
and base it on C++, instead of calling it called Basic# and
basing it on Visual Basic, or calling it FoxPro# and basing
it on FoxPro?

One possible explanation is that they feel that C++
programmers are most likely to appreciate the new features,
because they have had to "suffer" without them. (Sun seems
to have this mindset; most of the documentation of their
"improvements" is based on the removal of dangerous features,
such as pointers and multiple inheritance.)

Another explanation is that they feel that C++ is the closest
thing to their "ideal" language. (I think that Microsoft feels
this way; their documentation focuses on new capabilities
inherited from the "Common Language Facility," and not all but
most of the "removed" C++ features are available by using a
keyword.)

I await other ideas.

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com
http://www.deja.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <92glhb$88s$1@nnrp1.deja.com>, AllanW <allan_w@my-deja.com>
writes
>Another explanation is that they feel that C++ is the closest
>thing to their "ideal" language. (I think that Microsoft feels
>this way; their documentation focuses on new capabilities
>inherited from the "Common Language Facility," and not all but
>most of the "removed" C++ features are available by using a
>keyword.)

Yet, curiously, I believe that C# is not a new project but a
reincarnation of one from the late 1980's. Indeed much of the
documentation seems to come from that time.

Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

allan_w@my-deja.com (AllanW) wrote (abridged):
> But now, ask yourself -- when these people (or companies)
> decide to make a "new, better" language, why do they almost
> always start by making changes to C++? For instance, why did
> Sun make Java so very "C++ - like" using the same keywords
> and so on?
> [...]
> I await other ideas.

C++ has a great many existing programmers. A new language that tried to
"steal" programmers from, eg, Smalltalk, will tend to do less well simply
because there are fewer Smalltalk programmers than C++ programmers.

I'm not sure I agree that Java is "C++ - like" in other than a very
superficial, syntactic way. It uses similar syntax partly to make the
transition from C++ to Java easier. A C++ programmer can look at Java
code and understand what it is doing, much more immediately than with,
eg, Smalltalk or Lisp code.

Likewise with C#, except that C# can now draw on the Java programmer pool
as well.

I think cosmetic issues are of great practical importance here. An
initial hurdle such as syntax, though easily overcome by someone willing
to try, will prevent many people even considering the new language.


> One possible explanation is that they feel that C++
> programmers are most likely to appreciate the new features,
> because they have had to "suffer" without them.

Certainly there is an element of this. I imagine it would be very hard to
persuade a Smalltalk, Lisp or Eiffel programmer to switch to Java (or C#)
for technical reasons.

  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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <memo.20001231184334.21243E@a.btinternet.com>, Dave Harris
<brangdon@cix.compulink.co.uk> writes
>A C++ programmer can look at Java
>code and understand what it is doing, much more immediately than with,
>eg, Smalltalk or Lisp code.

I do not agree, the different semantics of Java make this. IMO. an
illusion.



Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Well, one must always be suspicious of major IT tool vendors proposing
and providing new "languages". Mostly, like jave for instance, these are
more products than they are in the spirit of "language". I believe a good
standard (ideal spec) for a language can only come from those who don't
have monetary stake in the vendor arena. Vendors are probably
over-represented and too influential in standards groups and hence
"good" standards are probably prevented from surfacing.

So, I believe, that vendors are afraid of C++ because it is not proprietary
and people are using it. They see the C++ user as the potential buyer of
their proprietary product if they can lure them to their product. Of course
most language products fail for this very reason: a developer doesn't want
to build things with external bindings if it isn't necessary. But the
marketing
people keep trying anyway: java, C#, smalltalk and on and on. (Investors:
note the high risk). Why not Visual Basic improvement? Ans: because
the focus is on getting _new_ customer's into a lock-in technology and not
cannibalizing any existing product customer bases.

As far as "inventors" really creating something better, those incidents are
really
far and few in between. Mostly it's just trying to make money via a language
product.  (Note that C++ was one of those far and few in betweens.. thanks
Bjarne!).

In short, no one trusts a vendor with any kind of proprietary language
product
offering to be a leader (money is the root of all evil yada...) but the lure
of money
will keep these guys trying to sell you something.

Tony

"AllanW" <allan_w@my-deja.com> wrote in message
news:92glhb$88s$1@nnrp1.deja.com...
> Hans Aberg wrote:
> > So the next question is really, what will replace C++? Perhaps there
> > should be a group comp.c++.replacement...
>
> Perhaps there should be a group comp.c++.replacement-of-the-month,
> with subgroups .gnu, .java, .sea, .c#, and so on.
>
> The inventors of these languages obviously feel that there's
> something they want out of a programming language that they
> can't get from any other language that they know of, not even
> from C++. So they decide to invent a new language. This is a
> laudable goal; every new language attempt adds to the global
> understanding of what computer languages ought to do.
>
> (The practice of announcing "major new" languages before
> they're even fully designed is another story. If this is
> what's required for a language to be successful, then we can
> be sure that all new successful languages will be created by
> large corporations. That's a pity.)
>
> But now, ask yourself -- when these people (or companies)
> decide to make a "new, better" language, why do they almost
> always start by making changes to C++? For instance, why did
> Sun make Java so very "C++ - like" using the same keywords
> and so on? And why did Microsoft call their new language C#
> and base it on C++, instead of calling it called Basic# and
> basing it on Visual Basic, or calling it FoxPro# and basing
> it on FoxPro?
>
> One possible explanation is that they feel that C++
> programmers are most likely to appreciate the new features,
> because they have had to "suffer" without them. (Sun seems
> to have this mindset; most of the documentation of their
> "improvements" is based on the removal of dangerous features,
> such as pointers and multiple inheritance.)
>
> Another explanation is that they feel that C++ is the closest
> thing to their "ideal" language. (I think that Microsoft feels
> this way; their documentation focuses on new capabilities
> inherited from the "Common Language Facility," and not all but
> most of the "removed" C++ features are available by using a
> keyword.)
>
> I await other ideas.
>
> --
> Allan_W@my-deja.com is a "Spam Magnet," never read.
> Please reply in newsgroups only, sorry.
>
>
> Sent via Deja.com
> http://www.deja.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.research.att.com/~austern/csc/faq.html                ]
> [ Note that the FAQ URL has changed!  Please update your bookmarks.     ]
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

francis.glassborow@ntlworld.com (Francis Glassborow) wrote (abridged):
> > A C++ programmer can look at Java code and understand what it
> > is doing, much more immediately than with, eg, Smalltalk or Lisp
> > code.
>
> I do not agree, the different semantics of Java make this. IMO. an
> illusion.

They would get the gist of it, enough not to be scared and probably
enough to know (eg) whether the code they are looking at is the code they
need to edit.

It's not perfect but it is much closer than with the other languages I
mention. For example, Java gives its operators the same precedence as C++
(even where that precedence is not ideal). In both languages 2+3*4 yields
14. In Smalltalk it yields 20. In Lisp it would be a syntax error.

  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."


======================================= MODERATOR'S COMMENT:
 The direction this discussion is taking makes it less
relevant to comp.std.c++.  Please do ensure that any followups
are on-topic.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Hans Aberg" <remove.haberg@matematik.su.se> wrote in message
news:remove.haberg-1412002050520001@du153-226.ppp.su-anst.tninet.se...
> In article <3A36E6CA.6F7BE6B4@wizard.net>, James Kuyper
> <kuyper@wizard.net> wrote:

> A new C++ revision may not be able to be implemented in full on every
> platform. Possibly C++ needs a way to isolate components suitable for
> different types of applications. With this approach one could add modules
> for graphics, distributed programming, threads, etc without offending the
> EC++ people which want to be able to cut out the extras in order to
> squeeze the program into a low-capacity computer.

The things you listed seem like userland things (libraries) anyway. What
needs to be
kept isolated are the advanced core features that are optional such as
templates, EH,
RTTI etc. so that implementors and users have the freedom to choose whether
or not
to include or use those mechanisms.

Tony


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <jbA_5.843$GQ1.25343@bgtnsc06-news.ops.worldnet.att.net>,
"Tony" <tony@my.isp.net> wrote:
>> A new C++ revision may not be able to be implemented in full on every
>> platform. Possibly C++ needs a way to isolate components suitable for
>> different types of applications. With this approach one could add modules
>> for graphics, distributed programming, threads, etc without offending the
>> EC++ people which want to be able to cut out the extras in order to
>> squeeze the program into a low-capacity computer.
>
>The things you listed seem like userland things (libraries) anyway. What
>needs to be
>kept isolated are the advanced core features that are optional such as
>templates, EH,
>RTTI etc. so that implementors and users have the freedom to choose whether
>or not
>to include or use those mechanisms.

Yes, but I think one problem is that a conforming compiler implementation
is supposed to have all the features listed in a standard. What about a
C++ compiler specialized solely for embedded platforms, which probably
would not implement dynamic features? -- It would be listed as
non-conforming.

A similar problem concerns graphics: C++ has standard streams cin, cout,
etc, because most platforms have them (even though not for example MacOS).
Most platforms do not anymore use these kind of simple consoles, but a
graphics window. But if one adds support for that in C++ in some or other
forms, the compilers that do not have become non-conforming.

I do not draw any conclusions here -- input from others are welcome.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Hans Aberg" <remove.haberg@matematik.su.se> wrote in message
news:remove.haberg-1812002135270001@du153-226.ppp.su-anst.tninet.se...
> In article <jbA_5.843$GQ1.25343@bgtnsc06-news.ops.worldnet.att.net>,
> "Tony" <tony@my.isp.net> wrote:
> >> A new C++ revision may not be able to be implemented in full on every
> >> platform. Possibly C++ needs a way to isolate components suitable for
> >> different types of applications. With this approach one could add
modules
> >> for graphics, distributed programming, threads, etc without offending
the
> >> EC++ people which want to be able to cut out the extras in order to
> >> squeeze the program into a low-capacity computer.
> >
> >The things you listed seem like userland things (libraries) anyway. What
> >needs to be
> >kept isolated are the advanced core features that are optional such as
> >templates, EH,
> >RTTI etc. so that implementors and users have the freedom to choose
whether
> >or not
> >to include or use those mechanisms.
>
> Yes, but I think one problem is that a conforming compiler implementation
> is supposed to have all the features listed in a standard. What about a
> C++ compiler specialized solely for embedded platforms, which probably
> would not implement dynamic features? -- It would be listed as
> non-conforming.

Being able to turn off those things though would probably be the way a large
vendor would do it (Borland for example). Further, if you don't need those
things that make a compiler "conforming", why pay for it?  For instance, I
just
may go back to generic.h to replace the need for templates.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <x5S%5.973$rn6.92581@bgtnsc06-news.ops.worldnet.att.net>,
"Tony" <tony@my.isp.net> wrote:
>Being able to turn off those things though would probably be the way a large
>vendor would do it (Borland for example). Further, if you don't need those
>things that make a compiler "conforming", why pay for it?

I think that there must be a C++ core that compilers "must" have (whatever
that now means in practise) in order to be conforming, but which also
makes it easy to for compiler developers to add the extra stuff.

Support for more GUI oriented programming need not mean support for a full
scale GUI implementation, but, for example, it could mean that instead of
the line-oriented cout & cin, one supplies support for writing on GUI
consoles, because that is what most computers use anyway these days.

>  For instance, I
>just
>may go back to generic.h to replace the need for templates.

What is this "generic.h" file?

I do believe that C++, instead of hoping of making templates indefinitely
more complicated (even though the template system probably needs some
completions), will need some such support for a polymorphic variable
running over a class hierarchy. -- I am writing on such a hierarchy
myself, with one point being that it understands lambda calculus.

But there are several different variations of such class hierarchies, so
it could be difficult singling out one variation for inclusion in a C++
library.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3ARYc3A2jTN6Ewu9@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>I think it might help if is a CVS archive, as the one in use at GNU
>>subversions.gnu.org (snapshots at ftp://alpha.gnu.org/gnu/cvs/). Revisons
>>can then be easily entered.
>
>I am not sure. The idea is to have something simple like the C++ issues
>lists.

Whatever, if it is only easy to maintain for whoever runs the archive,
which I surmise will be you. :-) If Fergus Henderson can set up so that
articles with "Feature Request" in the title is automatically forwarded to
you, he could probably add a time stamp to the subject title as well, if
you so wish.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <VG9wdoBFWlN6Ewrv@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>If you select a specific standard, such as the C++ standard
>>ISO+IEC+14882-1998, it is molded, inanimate, and therefore a non-living
>>language. If there is any life to C++ as _language_, that life belongs to
>>the parts of C++ that are changeable.
...
>I think you have chosen a specific view of what it means to be a living
>language, under that view and standard language is dead, publishing a
>standard kills it.

The quote above refers to what I arrived at when applying the concept of a
human "living language" (as defined by a dictionary) to computer
languages: In linguistics, one is evidently quite accustomed
distinguishing between artificial and natural languages. By contrast, all
computer languages are artificial, even they can have parts that appear to
be natural.

>My view of language is very different, life is in how a language is
>used. New ideas, idioms etc. breath life into standard C++ (as they do
>for any language)

If one should apply this linguistics definition of a "living language" to
C++, then C++ will be living when everybody can make their own version of
it. :-) It is pretty much the opposite of standardization.

Just because something is inanimate, or "dead", it does not mean that one
cannot do animate, or "living", things with it: Take your favorite tool in
your hardware toolbox.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A3183B0.4D4EBAD@wizard.net>, James Kuyper <kuyper@wizard.net>
wrote:
>> I think you confuse the life of the computer language with the life of
>> what is doing with the computer language. Something being "living" somehow
>> implies that it is animate, capable of inherent motion.
>>
>> If you select a specific standard, such as the C++ standard
>> ISO+IEC+14882-1998, it is molded, inanimate, and therefore a non-living
>> language. If there is any life to C++ as _language_, that life belongs to
>> the parts of C++ that are changeable.
>
>It was real C++ that I said was living language, not standard C++.

Right, one needs to keep these two, the C++ standard and the C++ concept
people collectively and individually have in their minds, apart.

> Most
>compilers I'm familiar with come out with new releases fairly
>frequently, sometime several times a year; GNU is much worse, or so I've
>heard. Each release typically defines a slightly different version of
>the language. When a language changes form on a time scale comparable to
>the time it takes to learn the language, that strikes me as a fairly
>"animate" language. There are people out there who still are learning
>the differences between ARM C++ and Standard C++. Please given them a
>little more time to adjust before the language roars onward toward a new
>horizon. I write code that I expect to still be in use two decades from
>now; I'd like to think my successors will spend more time adding
>features to it than they spend re-writing it to cope with changes to the
>standard.

One should note that personal computers have an average life-span of two
years, so your code will not survive that long without a recompilation.
:-)

Further, as computers seem to be able to double the capacity every year or
so for at least the next fifty years, programming techniques will probably
shift considerable the next decade only: For example, programming with a
polymorphic variable will then be increasingly feasible, and is
considerably easier than C++'s complicated template system.

So, there are different issues at hand, one is how programmers should be
able to keep up with the changing C++. But the other problem is how C++
should be able to keep up with the changing times. The current C++ is not
at all suited for meeting the demands of the computers with increasing
capacity of handling dynamic data.

So if C++ does not solves that latter hurdle, it will crash as a language.

Clearly, the two aspects somehow must balance. But it seems me it is not
so difficult to make C++ backwards compatible; one simply allows the old
stuff remain for compatibility reasons. Then one simply adds the new
features.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

james@evtechnology.com (James Dennett) wrote (abridged):
> As each of the messages on this thread have passed by at least one of
> us, I guess we're "in the loop" even if only fairly passively :)
>
> [much snippage]

Thanks; that was the kind of reassurance that I was looking for.

I've expanded the enum suggestion and reposted it with a "Feature
Request:" title. Comments welcomed, either on the proposal itself or on
the general format. (I suspect I've made it longer than it really needs
to be.)

  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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hans Aberg wrote:
>
> In article <3A3183B0.4D4EBAD@wizard.net>, James Kuyper <kuyper@wizard.net>
> wrote:
...
> > Most
> >compilers I'm familiar with come out with new releases fairly
> >frequently, sometime several times a year; GNU is much worse, or so I've
> >heard. Each release typically defines a slightly different version of
> >the language. When a language changes form on a time scale comparable to
> >the time it takes to learn the language, that strikes me as a fairly
> >"animate" language. There are people out there who still are learning
> >the differences between ARM C++ and Standard C++. Please given them a
> >little more time to adjust before the language roars onward toward a new
> >horizon. I write code that I expect to still be in use two decades from
> >now; I'd like to think my successors will spend more time adding
> >features to it than they spend re-writing it to cope with changes to the
> >standard.
>
> One should note that personal computers have an average life-span of two
> years, so your code will not survive that long without a recompilation.
> :-)

My programs don't normally run on personal computers, so that's not an
issue in itself.

However, I don't expect my code to go any significant length of time
without being recompiled. We depend simultaeously on four different
libraries, each of which gets updated frequently. The sysadmins update
both the operating system and the compiler almost as frequently.
Recompilation twice a year has been fairly typical. Our instrument is
only flying on two different satellites, with the second due to be
launched early next year; possibly after they've both been flying for a
few years the system will settle down and require less frequent updates,
but I don't expect that to happen any time soon.

What I'm talking about is not recompilation, but rewrites. I have to do
rewrites to add new features, and to cope with changes to the libraries
we use. I don't want to add to that any significant amount of re-writes
due to backward incompatibilities in the language itself. Changes to
libraries only tend to force rewrites of the code that calls the
functions that have changed. Adding new features is the main thing I get
paid for, and usually also requires only fairly small and isolated
changes. Significant changes in the language, on the other hand, could
force us to review every single module for the possibility that it might
have to be rewritten, and we don't have the resources to perform that
review.

> Further, as computers seem to be able to double the capacity every year or
> so for at least the next fifty years, programming techniques will probably
> shift considerable the next decade only: For example, programming with a
> polymorphic variable will then be increasingly feasible, and is
> considerably easier than C++'s complicated template system.

That's a backward compatible change; it doesn't invalidate previous
code. What worries me are proposed changes that ignore or at least deny
the importance of backward compatibility.

...
> Clearly, the two aspects somehow must balance. But it seems me it is not
> so difficult to make C++ backwards compatible; one simply allows the old
> stuff remain for compatibility reasons. Then one simply adds the new
> features.

Unfortunately, it seldom works out quite that cleanly. Maintaining
backward compatibility is significantly more difficult than you seem to
imagine.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A36E6CA.6F7BE6B4@wizard.net>, James Kuyper
<kuyper@wizard.net> wrote:
> Our instrument is
>only flying on two different satellites, with the second due to be
>launched early next year; possibly after they've both been flying for a
>few years the system will settle down and require less frequent updates,
>but I don't expect that to happen any time soon.

Computers in space have traditionally been slower in updating hardware,
that is true -- like the space shuttle having a computer form the
seventies or something.

>What I'm talking about is not recompilation, but rewrites. I have to do
>rewrites to add new features, and to cope with changes to the libraries
>we use. I don't want to add to that any significant amount of re-writes
>due to backward incompatibilities in the language itself. Changes to
>libraries only tend to force rewrites of the code that calls the
>functions that have changed. Adding new features is the main thing I get
>paid for, and usually also requires only fairly small and isolated
>changes. Significant changes in the language, on the other hand, could
>force us to review every single module for the possibility that it might
>have to be rewritten, and we don't have the resources to perform that
>review.

So then there are two opposite choices then, that somehow must balance:
Saying that this old code must be able to run without significant changes,
and molding the language itself into a standard on the one hand, and
accepting changes and risking breaking old code. The first choice will
risk killing off the language, and the second will risk killing off
backwards compatibility and business-as-usual programming which requires a
reliable programming environment.

>> Further, as computers seem to be able to double the capacity every year or
>> so for at least the next fifty years, programming techniques will probably
>> shift considerable the next decade only: For example, programming with a
>> polymorphic variable will then be increasingly feasible, and is
>> considerably easier than C++'s complicated template system.
>
>That's a backward compatible change; it doesn't invalidate previous
>code. What worries me are proposed changes that ignore or at least deny
>the importance of backward compatibility.
>
>...
>> Clearly, the two aspects somehow must balance. But it seems me it is not
>> so difficult to make C++ backwards compatible; one simply allows the old
>> stuff remain for compatibility reasons. Then one simply adds the new
>> features.
>
>Unfortunately, it seldom works out quite that cleanly. Maintaining
>backward compatibility is significantly more difficult than you seem to
>imagine.

I think it might be simpler when computer become more powerful, because
traditional reasons for lessening backwards compatibility is the time and
effort it takes to implement such features into the compiler, the space
they may occupy on the computer, etc. However with more power computers,
space is not a problem clearly, and one might write a kernel which the
other features might be added as a general structure library.

For example, if STL is considered not good enough, one might add a whole
version if it still is not time-consuming or difficult to get the old STL
compile under the new system. New compilers are better at optimization,
which makes it easier to add C-like backwards compatibility features, even
if one decides that the core of the new C++ should no longer be based on
C. A traditional view is that one should keep libraries limited, but what
does it matter if the libraries are whole encyclopedias if they are added
on top of a kernel structure which does not need separate implementation
for each compiler and platform. Etc.

A new C++ revision may not be able to be implemented in full on every
platform. Possibly C++ needs a way to isolate components suitable for
different types of applications. With this approach one could add modules
for graphics, distributed programming, threads, etc without offending the
EC++ people which want to be able to cut out the extras in order to
squeeze the program into a low-capacity computer.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hans Aberg wrote:
>
> In article <3A2EDB72.E0970794@wizard.net>, James Kuyper
> <kuyper@wizard.net> wrote:
...
> I think you confuse the life of the computer language with the life of
> what is doing with the computer language. Something being "living" somehow
> implies that it is animate, capable of inherent motion.
>
> If you select a specific standard, such as the C++ standard
> ISO+IEC+14882-1998, it is molded, inanimate, and therefore a non-living
> language. If there is any life to C++ as _language_, that life belongs to
> the parts of C++ that are changeable.

It was real C++ that I said was living language, not standard C++. Most
compilers I'm familiar with come out with new releases fairly
frequently, sometime several times a year; GNU is much worse, or so I've
heard. Each release typically defines a slightly different version of
the language. When a language changes form on a time scale comparable to
the time it takes to learn the language, that strikes me as a fairly
"animate" language. There are people out there who still are learning
the differences between ARM C++ and Standard C++. Please given them a
little more time to adjust before the language roars onward toward a new
horizon. I write code that I expect to still be in use two decades from
now; I'd like to think my successors will spend more time adding
features to it than they spend re-writing it to cope with changes to the
standard.

...
> > The
> >C++ standard hasn't had time yet to track the changes, but ISO
> >procedures are intended to guarantee that it does so.
>
> Well, there are good intentions, but there is a lot of inertia in
> developing new standards, and a big ballast is the earlier revisions. So
> one might surmise that this inertia will cause the demise of C++
> _eventually_.

Surmise away, but don't take it as proven, much less given.

> If one wants to decrease the inertia, one can decrease the inertia in

I can't think of any reason why I'd want that. The standard is the bones
of the language; it's the part of the language you can rely on, no
matter which implementation you use. The actual implementations are the
flesh of the language. They build outward from the standard, and change
rapidly at need. A backbone that bends too easily under an applied force
is useless; one that bends not at all is too brittle. I've seen no
indications to justify your worry that the standard is too inflexible
for it's role. Rather, I've seen worries based upon a misunderstanding
of it's role. It's like hearing someone complain about the design of
their thigh bone, calling it defective because it's not flexible enough
to tie a knot in it. That's not what a thigh bone is for, and that's not
what a language standard is for, either.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A312034.4DCA25D8@evtechnology.com>,
  James Dennett <james@evtechnology.com> wrote:

> As each of the messages on this thread have passed by at least one
> of us, I guess we're "in the loop" even if only fairly passively :)

The "us" gives the impression that you are also a moderator of
comp.std.c++.  I know that at least one other person was added since
the group was founded.  But the FAQ and the moderation policy still
only mention the original three.  Wouldn't it be a good idea to update
them?

--
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(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <9119nl$q31$1@mulga.cs.mu.OZ.AU>, Fergus Henderson
<fjh@cs.mu.OZ.AU> writes
>I can arrange for a copy of articles whose subject line starts with
>"Feature Request:" to be automatically forwarded to someone for
>archiving, if you want.

Yes that was what I meant. I would like to future proof any arrangement
so if, for any reason I am no longer doing it the material can be sent
to my successor.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-0912002027010001@du131-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>I think it might help if is a CVS archive, as the one in use at GNU
>subversions.gnu.org (snapshots at ftp://alpha.gnu.org/gnu/cvs/). Revisons
>can then be easily entered.

I am not sure. The idea is to have something simple like the C++ issues
lists.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-0712001956390001@du137-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>If you select a specific standard, such as the C++ standard
>ISO+IEC+14882-1998, it is molded, inanimate, and therefore a non-living
>language. If there is any life to C++ as _language_, that life belongs to
>the parts of C++ that are changeable.



I think you have chosen a specific view of what it means to be a living
language, under that view and standard language is dead, publishing a
standard kills it.

My view of language is very different, life is in how a language is
used. New ideas, idioms etc. breath life into standard C++ (as they do
for any language) There is always a potential for change when it is
needed, but there is no value in change for the sake of it. I think we
still have a great deal of exploration of the potential of C++ without
changing anything but the way we use it to express solutions. The
vitality is in its use.

As we have such differing views of what it means to be a living
language, I do not think we will ever agree.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

celtschk@physik.tu-muenchen.de (Christopher Eltschka) wrote (abridged):
> If this group is used for input, there should be something in the
> subject line, which allows to find/identify the submissions easily,
> like the "Defect Report:" subject line start.
>
> What about: "Feature Request:"?

Sounds good to me.

What is the next step forward? How do we get the moderator's agreement?
Should I resubmit the enums request?

  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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A2EDB72.E0970794@wizard.net>, James Kuyper
<kuyper@wizard.net> wrote:
>> So it seems that if this normal definition of a "living language" should
>> be used in the context of computer languages, it excludes any standardized
>> language, as it is no longer developed by their users. The definition also
>> excludes rather artificial scholarly definitions of computer languages.
>
>By that argument, Standard English (by which I mean the idealized,
>dialect-neutral form of English that is supposed to be taught in
>elementary schools) is just as "dead" as  Standard C++, for precisely
>the same reason - they don't change (very often).

Right, this what how I interpret the linguistic definition of the notion
of a "living language":  If a body scholars define something such as
Standard English, that is not a living language but a scholarly or
artificial language. -- However, note that there are several different
definitions of "Standard English", several characteristic of non-living
languages, such as what is taught in schools, derived from a dictionary,
or something but also what is considered generally accepted, in which case
it would indicate the presence of a living language.

There is nothing in general positive or negative in being a living or
non-living language.

>However, real C++ is
>just as alive as real English - both of them change constantly as
>they're being used, and in both cases the standard changes slowly to
>track, and to some extent, anticipate changes in the real language.

I think you confuse the life of the computer language with the life of
what is doing with the computer language. Something being "living" somehow
implies that it is animate, capable of inherent motion.

If you select a specific standard, such as the C++ standard
ISO+IEC+14882-1998, it is molded, inanimate, and therefore a non-living
language. If there is any life to C++ as _language_, that life belongs to
the parts of C++ that are changeable.

> The
>C++ standard hasn't had time yet to track the changes, but ISO
>procedures are intended to guarantee that it does so.

Well, there are good intentions, but there is a lot of inertia in
developing new standards, and a big ballast is the earlier revisions. So
one might surmise that this inertia will cause the demise of C++
_eventually_.

If one wants to decrease the inertia, one can decrease the inertia in
developing the standard somehow, perhaps switching away from ISO which is
labelled as a fairly heavy trod organization. And one could in the new C++
revision lop off big chunks that are outdated, only keeping them for
backward compatibility. For example, if STL is deemed flawed, one write an
entirely new library. Or one could drop the attempts by C++ to be
compatible with C, only via "extern "C" ..." directives, in order to get
rid of the problems that C++ inherited from C.

This would have the effect of successively creating an entirely new
language by a sequence of transformations, the revisions.

> In both cases, the
>Standard form of the language provides a guideline, and individual users
>decide for themselves how much attention to pay to the standard. In
>neither case does the standardization of the language kill the real
>language.

If one does not overcome that inertia somehow, the standardization surely
will kill it off in the _long_term_.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A245C80.DA27B114@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> Valentin Bonnard wrote:
> ...
> > The C standard was the standardization of common practice, plus
> > some inventions. Its library includes almost only pointless,
> > unusable functions.

> Like printf(), sin(), fopen(), fwrite(), memcpy(), etc?

Well, some of the I18n functions are pretty unusable.  But then, that
was the innovative part of the standard:-).

Seriously, I find the C standard an almost perfect compromise (for a
standard) between innovation and existing practice.  The main points
of innovation was where there was extensive conflicting existing
practice (e.g. the preprocessor).  The conflicting practices at least
gave some good indications as to 1) what was needed, and 2) what to
avoid.

Other "innovative" aspects were lifted directly from C++; function
prototypes are the most noticeable.  In this case, there was definitly
existing practice (C++), but it took the standard to provide the
motivation for the vast majority of the vendors.

Like many people, of course, I would have preferred that they drop
gets, existing practice or not.  The case of sprintf is a bit more
difficult -- at the time, there was no reasonable alternative.

> > The C++ standard is based on innovation, and integration of
> > ``young'' ideas like the STL (young compared to the history of
> > C++, not ``the last idea we had at lunch this morning''). It
> > possesses many very usefull functions, together with a few almost
> > useless ones.

> > I don't know if this comparison proves anything except that C++ is
> > superior, but at least it shows that innovation in a committee
> > isn't a receipt for disaster -- at least no more that pure
> > standardization of existing practice.

> In the course of standardizing STL, many questions popped up that
> the committee had to resolve, because the library was so new that no
> one else had actually considered some of those issues yet.

Even worse, there were a lot of questions that weren't asked, because
no one had enough experience with the STL to know to ask them.
Witness the threads here concerning what is or is not allowed in a
predicate or a functional object.  These are things that must be
settled *before* the functionality is standardized.

> Some of the decisions the committee had to make were
> controversial. They shouldn't have been: this stuff shouldn't be
> cast in stone until they're reasonably certain it's OK for it to be
> cast in stone. Remember, it's almost impossible to reverse a
> decision once it's made it into an officially released standard.

That's not totally true, although in the cases you're thinking of, it
likely is.  A later version of the standard can easily define
previously undefined behavior, for example, or loosen restrictions.
The reverse is, of course, almost impossible.  (This is why
Stroustrup, at the very end, proposed making certain pointer
operations undefined behavior.  *If* C++ ever gets garbage collection,
it will probably be necessary for them to be undefined behavior, and
since they aren't undefined now, this means that formally correct and
working programs will be broken.)

With regards to STL (or the string class, or anything else in the
library), if nothing else, the fact that it is in a namepace makes it
easier to change, if it really turns out that we need to.  So a bit
more innovation than usual is probably acceptable.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <memo.20001207181047.42553A@a.btinternet.com>, Dave Harris
<brangdon@cix.compulink.co.uk> writes
>Sounds good to me.
>
>What is the next step forward? How do we get the moderator's agreement?
>Should I resubmit the enums request?

OK. Let me make a suggestion.

A feature request should consist of:

A sensible title

A synopsis of what is being suggested.

The motivation, preferably with examples.

If an impact analysis can be added, so much the better. For example,
correctly describing something as a pure extension (cannot impact
current code) and simple to implement would be good motives for
providing it. However this must be done carefully. Providing cv
qualified ctors might seem to be a pure extension but would impact on
quite a few clauses in the standard and might have affects on legacy
code  if new versions of libraries started using it.

Perhaps we could go through a two stage process:

1) Submit something with Feature Request in the subject line. At that
stage I will place it in an archive marked as provisional.

2) If the request generates much discussion, then the author of the
original should revise the submission. now it could go in the archive as
'refined' (or some other term if someone can think of a better one)

As I follow this group, we can work this way without moderator
intervention (though it would be nice if they were in the loop)


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"James Kuyper" <kuyper@wizard.net> wrote in message
news:3A245C80.DA27B114@wizard.net...
> Valentin Bonnard wrote:

> If something has become a de-facto standard, then that implies it's a
> prime candidate to become part of the next release of the formal
> standard. What's the problem?

The way the thing became a de facto standard. Was it technological
appropriateness or just power of marketing?

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:
>
> In article <memo.20001207181047.42553A@a.btinternet.com>, Dave Harris
> <brangdon@cix.compulink.co.uk> writes
> >Sounds good to me.
> >
> >What is the next step forward? How do we get the moderator's agreement?
> >Should I resubmit the enums request?
>
> OK. Let me make a suggestion.
>
> A feature request should consist of:
>
> A sensible title
>
> A synopsis of what is being suggested.
>
> The motivation, preferably with examples.
>
> If an impact analysis can be added, so much the better. For example,
> correctly describing something as a pure extension (cannot impact
> current code) and simple to implement would be good motives for
> providing it. However this must be done carefully. Providing cv
> qualified ctors might seem to be a pure extension but would impact on
> quite a few clauses in the standard and might have affects on legacy
> code  if new versions of libraries started using it.
>
> Perhaps we could go through a two stage process:
>
> 1) Submit something with Feature Request in the subject line. At that
> stage I will place it in an archive marked as provisional.
>
> 2) If the request generates much discussion, then the author of the
> original should revise the submission. now it could go in the archive as
> 'refined' (or some other term if someone can think of a better one)
>
> As I follow this group, we can work this way without moderator
> intervention (though it would be nice if they were in the loop)

As each of the messages on this thread have passed by at least one of
us, I guess we're "in the loop" even if only fairly passively :)

Clearly the charter of comp.std.c++ means that discussion of ideas
about design and standardisation of C++ both in the past and in the
future are on-topic, and so "Feature Request:" articles would be
accepted as a matter of course.

(The charter is at http://www.research.att.com/~austern/csc/charter.html
for those who don't know it.  It's pleasingly simple.)

Defect Reports are dealt with more carefully by the moderators than
regular posts; apart from checking that they're on-topic for the group,
a rough quality check is performced, and one of several moderators will
manually forward the DR to the appropriate person if needed.

It might be reasonable for us to discuss the possibility of applying
some similar checks to Feature Requests, but to get something up and
running quickly I think that this is not necessary.

If special case handling for Feature Requests was needed then changes
may be needed to the moderation system which is maintained, I believe,
by Fergus Henderson.  If, however, you [Francis] are willing to scrape
the messages from a news server, then it seems that this is workable
with no change to how moderation works at present.

-- James Dennett

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A312034.4DCA25D8@evtechnology.com>, James Dennett
<james@evtechnology.com> writes
>If special case handling for Feature Requests was needed then changes
>may be needed to the moderation system which is maintained, I believe,
>by Fergus Henderson.  If, however, you [Francis] are willing to scrape
>the messages from a news server, then it seems that this is workable
>with no change to how moderation works at present.

Fine by me, all I meant by the moderators being in the loop is that it
would increase the reliability if 'feature requests were copied to me,
possibly via an accu job address (so if someone else took over from me
it could be simply redirected)

Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Dave Harris <brangdon@cix.compulink.co.uk> writes
>What is the next step forward? How do we get the moderator's agreement?

I don't know about the other moderators, but speaking for myself,
I have no objection to this scheme.

(The other currently active moderators, who do the bulk of the actual
moderation work, are Matt Austern <matt@research.att.com>,
James Dennett <jdennett@acm.org>, and Phil Edwards <pedwards@jaj.com>.)

Francis Glassborow <francis.glassborow@ntlworld.com> writes:
>As I follow this group, we can work this way without moderator
>intervention (though it would be nice if they were in the loop)

What exactly do you mean by the moderators being "in the loop"?

I can arrange for a copy of articles whose subject line starts with
"Feature Request:" to be automatically forwarded to someone for
archiving, if you want.

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


======================================= MODERATOR'S COMMENT:
 Works for me!  -pme

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <wuu5nEBN4NM6Ewlq@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>Perhaps we could go through a two stage process:
>
>1) Submit something with Feature Request in the subject line. At that
>stage I will place it in an archive marked as provisional.
>
>2) If the request generates much discussion, then the author of the
>original should revise the submission. now it could go in the archive as
>'refined' (or some other term if someone can think of a better one)

I think it might help if is a CVS archive, as the one in use at GNU
subversions.gnu.org (snapshots at ftp://alpha.gnu.org/gnu/cvs/). Revisons
can then be easily entered.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Tony" <tony@my.isp.net> wrote in message
news:_r8Y5.10281$2P3.738179@bgtnsc06-news.ops.worldnet.att.net...
>
> "James Kuyper" <kuyper@wizard.net> wrote in message
> news:3A245C80.DA27B114@wizard.net...
> > Valentin Bonnard wrote:
>
> > If something has become a de-facto standard, then that implies it's a
> > prime candidate to become part of the next release of the formal
> > standard. What's the problem?
>
> The way the thing became a de facto standard. Was it technological
> appropriateness or just power of marketing?

Does it matter?

There's actually very little evidence that marketing (or pricing) has a very
large impact on something selling so well that it becomes a de facto
standard.  That may be bad news to marketroids, but is very good news for
engineers...

Before you all start screaming 'QWERTY,' 'VHS,' or 'Microsoft' at me, I
suggest you look at the book 'Winners, Losers and Microsoft,' by Stan J.
Liebowitz and Stephen E. Margolis, published by The Independent Institute in
1999.  Specifically with respect to keyboards, and why there's no really
compelling reason for us all to use Dvorak layouts, look at chapter 2 or the
authors' article "The Fable of the Keys," from the October 1990 issue of
"Journal of Law and Economics."

If two technologies are very similar in terms of cost/benefit, then
marketing may push the balance towards or away from a particular product.
But in the main, it appears that consumers are much better at choosing
between competing technological standards than they are usually given credit
for by economics professors (and Justice Departments :) .

Nevertheless (bringing this article back onto topic), the standards
committee will give _any_ submission serious consideration, and probably a
chance for many other vendors to implement it, before making a judgement as
to whether it should be added.  The existence of a popular viable
implementation of a feature might sway them a little, but the committee does
contain a fair few technical people.

It's unlikely that something technically appropriate and with a small impact
on existing code, and that fits in with C++'s philosophy would be rejected.
Likewise, a popular extension with a major impact on existing code and that
does not fit in with the philosophy or the semantics of the language would
most likely not be accepted.  The vendor of that extension will most likely
leave it as an extension to their compiler, which is not a problem so long
as they follow the conventions for extensions, that is, two leading
underscores before whatever-it-is.[1]

--
Mike Dimmick

[1]  Microsoft have been generally good at this, but their __asm doesn't fit
in with the rest of the syntax (terminates at end-of-line, not with a ';'),
and their .NET extensions overload the use of [ ] at block scope.  GNU's
'typeof' operator could easily conflict with user code written for a
platform without such a keyword.  The general rule adopted is that a single
leading underscore is reserved for a C implementation, while a double
underscore is reserved for a C++ implementation.  The name can be used as a
keyword or within a library.  Therefore, user code should not use such an
identifier.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <1y$4wsAUnBL6Ew8V@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>So when a language is created, standardization, just as it helps it for a
>>time, also paves the way for its demise. So, one better be create some new
>>languages in the which can stand by and take over whne the time is right.
>
>Well you are entitled to your opinion, I just happen to think it is
>wrong. Name one language that has survived more than 25 years in regular
>use other than for mainly academic purposes that has not been
>standardised through at least two iterations. Yes I can name a couple
>but they are both even more rigidly controlled by their inventors.

I really don't understand your comment here, because I clearly said
standardization, and revisions helps for a while, even though it also
causes rigidity.

So the question is not whether one should standardize -- one should
normally do this, in order to enable for people to "business as usual"
work with it.

But on the same time, one should be aware that one is paving the way (in
the long term) for its demise. So on the same time, one should create some
suitable candidates for replacements when the time is due.

I see this very clearly in the language Haskell <http://haskell.org/>,
which for a long period was entirely experimental, and non-standardized.
At some point, however, a number of people complained about the constant
changes, making it impossible to even simple things, like writing a book
using the language, because when the book comes out, the language has
changed.

So eventually a standardization, Haskell 98, was created. Since that
standardization, a number of have popped up, using it for all sorts of
day-to-day tasks. But the interesting, experimental parts are not of part
of Haskell 98. As a language, Haskell 98 is dead, and will never change,
even though it will appear to be very alive to those that use it to do
day-to-day programming. The life in Haskell lies in the parts that are
without Haskell 98.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A2C3F7B.7DA65E98@wizard.net>, James Kuyper
<kuyper@wizard.net> wrote:
>> In article <3A2A9A47.489A1D11@wizard.net>, James Kuyper
>> <kuyper@wizard.net> wrote:
>...
>> I am not interested in nit-picking over whether this or that language is
>> to be considered dead. The queston was whether a standardizatioon would
>> have any effect to kill off a language, and this is indeed so.
>
>You were given a list of three languages that had been standardized
>without dying, as counterexamples to your claim.

I thought also posts said that even though the languages so named are not
fully dead in the sense that there are still a number of dedicated users,
they are clearly showing sense of dying in every sense.

>In any event, if, as you claim, there are only a few such people, then
>that would make Latin a lousy analogy for Fortran. A better analogy
>would be Swahili, or Basque, or Hindi, or some other language with a
>fair number of native speakers.

My guess is that more people speak any of those languages than those that
speak FORTRAN, but personally I do not thing that numbers is a good
criterion of defining a living language.

My Merriam "Webster's Third New International Dictionary" defines a
"living language" as "a language in use as a vernacular", and component of
the meaning of the word "vernacular" is that it is not only spoken but
also developed by a certain group of people, as opposed to literary,
cultured, foreign and otherwise artificial languages.

So it seems that if this normal definition of a "living language" should
be used in the context of computer languages, it excludes any standardized
language, as it is no longer developed by their users. The definition also
excludes rather artificial scholarly definitions of computer languages.

So it seems that C++, even though it is a fairly living language in view
of all inputs that have been made in order to shape it up, the standard
ISO+IEC+14882-1998 is of course stone dead as language, as it is not
changing anymore: If there is any life in standardized C++, that life
belongs to the revision. :-)

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:
>
> In article <memo.20001130130713.23763A@a.btinternet.com>, Dave Harris
> <brangdon@cix.compulink.co.uk> writes
> >I don't think I expect thread-mining. However, wouldn't it be nice if
> >submissions could be made in public, through this newsgroup, in the same
> >official manner as Defect Reports? The difference between a Defect Report
> >and a request for a new feature is small enough that sometimes one may be
> >mistaken for the other.
>
> Let us try it that way, if the moderators agree. I will try to get some
> kind of charter, but do not expect it quickly because I am up to my ears
> with deadlines at present.

If this group is used for input, there should be something in the
subject line, which allows to find/identify the submissions easily,
like the "Defect Report:" subject line start.

What about: "Feature Request:"?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:

| Francis Glassborow wrote:
| >
| > In article <memo.20001130130713.23763A@a.btinternet.com>, Dave Harris
| > <brangdon@cix.compulink.co.uk> writes
| > >I don't think I expect thread-mining. However, wouldn't it be nice if
| > >submissions could be made in public, through this newsgroup, in the same
| > >official manner as Defect Reports? The difference between a Defect Report
| > >and a request for a new feature is small enough that sometimes one may be
| > >mistaken for the other.
| >
| > Let us try it that way, if the moderators agree. I will try to get some
| > kind of charter, but do not expect it quickly because I am up to my ears
| > with deadlines at present.
|
| If this group is used for input, there should be something in the
| subject line, which allows to find/identify the submissions easily,
| like the "Defect Report:" subject line start.
|
| What about: "Feature Request:"?

Seconded.

--
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Valentin Bonnard wrote:
...
> If you wait until you are absolutly sure nothing will be
> discovered in a scientific field, then you might wait
> forever (and how do you know when things are frozen ?).

Luckily, that's not the way that standardization works. You can
standardize the parts that are well enough tested, while leaving
conforming implementations free to work out the bugs in the parts that
are still uncertain.

> If you don't want to call writing C++ code ``science'',

I don't - it's engineering, not science (not that it matters).

...
> If you standardize much later after the technology is well
> understoud, well accepted, you risk to standardize things
> which won't ever be used, because deep understanding and
> wide acceptance implies common use, and it's very difficult
> to undo something which is a de-facto standard.

If something has become a de-facto standard, then that implies it's a
prime candidate to become part of the next release of the formal
standard. What's the problem?

...
> The C standard was the standardization of common practice,
> plus some inventions. Its library includes almost only
> pointless, unusable functions.

Like printf(), sin(), fopen(), fwrite(), memcpy(), etc?

> The C++ standard is based on innovation, and integration of
> ``young'' ideas like the STL (young compared to the
> history of C++, not ``the last idea we had at lunch this
> morning''). It possesses many very usefull functions,
> together with a few almost useless ones.
>
> I don't know if this comparison proves anything except that
> C++ is superior, but at least it shows that innovation in a
> committee isn't a receipt for disaster -- at least no more
> that pure standardization of existing practice.

In the course of standardizing STL, many questions popped up that the
committee had to resolve, because the library was so new that no one
else had actually considered some of those issues yet. Some of the
decisions the committee had to make were controversial. They shouldn't
have been: this stuff shouldn't be cast in stone until they're
reasonably certain it's OK for it to be cast in stone. Remember, it's
almost impossible to reverse a decision once it's made it into an
officially released standard. When the committee asked itself "what
should we do in this case?", someone should usually have been able to
answer, "our experience with vendor XYZ has shown that this is the best
solution to that problem".

...
> Is innovation by a misguided compiler writter any better ?

Certainly; the misguided compiler writer only harms his customers. If
his mistake is bad enough, he'll quickly lose his customers - end of
problem. A bad decision in a language standard harms all future users of
the 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article
<remove.haberg-0512001955250001@du137-226.ppp.su-anst.tninet.se>,
  remove.haberg@matematik.su.se (Hans Aberg) wrote:

> So it seems that if this normal definition of a "living language"
> should be used in the context of computer languages, it excludes any
> standardized language, as it is no longer developed by their
> users. The definition also excludes rather artificial scholarly
> definitions of computer languages.

Both Fortran and COBOL have regular revisions of the standard.  We
have Fortran 66, Fortran 77 and Fortran 90.  The last version of the
COBOL standard is 95, I think.  Presumably, there will be still more,
for both languages.  That sounds very much conform to the definition
of a living language.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hans Aberg wrote:
>
> In article <3A2C3F7B.7DA65E98@wizard.net>, James Kuyper
> <kuyper@wizard.net> wrote:
...
> >In any event, if, as you claim, there are only a few such people, then
> >that would make Latin a lousy analogy for Fortran. A better analogy
> >would be Swahili, or Basque, or Hindi, or some other language with a
> >fair number of native speakers.
>
> My guess is that more people speak any of those languages than those that
> speak FORTRAN, ...

There's billions of people who speak at least one language; the number
of people who can program in as least one language is enourmously
smaller. Therefore, it's not fair to compare the numbers in absolute
terms, but only in relative terms. I suspect that the fraction of all
programmers that know Fortran is far greater than the fraction of all
human beings that know Swahili, and that the statement remains true if
you replace "know" with "use regularly"; but I've no idea how to prove
that claim. However, the newsgroup message counts I referred to earlier
are consistent with that claim.

> ... but personally I do not thing that numbers is a good
> criterion of defining a living language.

True, and by any criteria that doesn't penalize a langauage for
declining popularity, Fortran is a living computer language. Declining
popularity is a sign (though not a reliable one) of approaching death,
but it's not a sign that death has already occurred. Fortran is changing
as vendors come up with new ideas for it. It has people who learn the
language as their first computer programming language, and people who
spend all or most of their careers programming in it. There are people
who choose it, on it's merits, as the language they prefer for a given
task.

> So it seems that if this normal definition of a "living language" should
> be used in the context of computer languages, it excludes any standardized
> language, as it is no longer developed by their users. The definition also
> excludes rather artificial scholarly definitions of computer languages.

By that argument, Standard English (by which I mean the idealized,
dialect-neutral form of English that is supposed to be taught in
elementary schools) is just as "dead" as  Standard C++, for precisely
the same reason - they don't change (very often). However, real C++ is
just as alive as real English - both of them change constantly as
they're being used, and in both cases the standard changes slowly to
track, and to some extent, anticipate changes in the real language. The
C++ standard hasn't had time yet to track the changes, but ISO
procedures are intended to guarantee that it does so. In both cases, the
Standard form of the language provides a guideline, and individual users
decide for themselves how much attention to pay to the standard. In
neither case does the standardization of the language kill the real
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <900nic$vup$1@nnrp1.deja.com>,
 <James.Kanze@dresdner-bank.com> wrote:
>In article <tq6+mVAPxpI6Ewmb@ntlworld.com>,
>  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
>> In article <_NZT5.7957$2s1.536172@bgtnsc06-news.ops.worldnet.att.net>,
>> Tony <tony@my.isp.net> writes
>> >ARM version of C++ rather than introducing all those permeating
>> >concepts (templates, EH, others)
>
>> Which are both described in the ARM. You would be surprised by how
>> little was actually added to the language rather than honing what
>> was already there in the design.
>
>Come now, namespaces, RTTI, and a standard library isn't just a
>little.  What was added is more than what was there to begin with.
>Although that is an unfair comparison.  The ARM explicitly ignored
>libraries, but nobody (I hope) ever really considered the idea of a
>standard C++ without any standard IO.

Certainly the SL was a whopper, but namespaces, RTTI, and template
additions were discussed even before the ARM (which means before
the committee too).

>Still, the thing that bothers me the most about the standard is the
>feature they dropped from the ARM: true separate compilation of
>templates.

vs false separate compilation? :)

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <900nic$vup$1@nnrp1.deja.com>, James.Kanze@dresdner-bank.com
writes
>Come now, namespaces, RTTI,

Neither of those is that big and the later was in response to developing
practice (close to 'existing practice')

> and a standard library isn't just a
>little.

Yes, but the library isn't the language as such, even though it is very
important.

>What was added is more than what was there to begin with.

?? really, that is a matter of opinion and not one that I share. What
was left out was a factor of ten larger than what was added. And many of
the things left out were good ideas in themselves, but contrary to
common opinion, the Standards Committees were not in the business of
writing a port manteau language.

>Although that is an unfair comparison.  The ARM explicitly ignored
>libraries, but nobody (I hope) ever really considered the idea of a
>standard C++ without any standard IO.
>
>Still, the thing that bothers me the most about the standard is the
>feature they dropped from the ARM: true separate compilation of
>templates.

And that was because no one could actually figure out how to do it for
real code rather than the small experimental (almost macro substitution)
templates. You cannot keep a feature in the language when the most
optimistic comment from any compiler developer was 'Yes, we could put it
in, but no one would ever use it because the result would be several
orders of magnitude too slow, and need vastly more space.'

I am pretty certain that if any compiler implementor could figure out
how to do it you would have it tomorrow.



Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:conS2uA7OrI6Ewg8@ntlworld.com...
> In article <8vu671$3at$1@nnrp1.deja.com>, James.Kanze@dresdner-bank.com
> writes
> >That would have been my preference.  But it would mean that C++ would
> >have continued for at least five, maybe ten years longer without a
> >standard vector class.  Which has a number of other disadvantages.  In
> >the end, no matter what the committee did would be wrong by some
> >standard.  I wouldn't be too critical of the committee; they had a
> >very difficult job.
>
> And we were already seeing a proliferation of home brewed solutions
> causing potential portability problems.

It's always going to be more difficult to achieve "standardization" at
higher [than the
language proper] levels because at some point, you move away from "well
defined
and accepted" and on to stylistic preferences (I'm doing my best to evolve
error
handling that doesn't involve EH in my own codebase for instance).

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

<James.Kanze@dresdner-bank.com> wrote in message
news:900nic$vup$1@nnrp1.deja.com...
> In article <tq6+mVAPxpI6Ewmb@ntlworld.com>,
>   Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> > In article <_NZT5.7957$2s1.536172@bgtnsc06-news.ops.worldnet.att.net>,
> > Tony <tony@my.isp.net> writes

> The ARM explicitly ignored
> libraries, but nobody (I hope) ever really considered the idea of a
> standard C++ without any standard IO.

This cowboy still uses printf()! :)

Tony



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Tony wrote:
>
> <James.Kanze@dresdner-bank.com> wrote in message
> news:8vu671$3at$1@nnrp1.deja.com...
...
> > There's certainly a part of truth in it.  If you standardize before
> > the technology is understood, you risk to standardize errors.  And it
> > is very difficult to undo something once it has been standardized.
>
> My thought was more along the lines that a standards body, e.g., has a
> better perspective to even SEE a potential for standardization even if it
> hasn't yet caught on in industry-specific offerings.

If it hasn't caught on yet in any industry-specific offering, then its
likely to be the case that it ISN'T a good candidate for
standardization. You seem to be stuck in the mode of thinking of
"standard C" as a product, out there competing with Borland C, Microsoft
C, GNU C, etc. It isn't. Standard C is a standard, not a product. It
marks the common ground that you can count on between many different
implementations. It's not in any sense competing with those
vendor-specific implementations. If nobody's making any significant use
of a proposed new feature yet (as a language extension, of course), then
it's probably not sufficiently widely useful or well-enough understood
to justify standardizing 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Tony wrote:
>
> <James.Kanze@dresdner-bank.com> wrote in message
> news:900nic$vup$1@nnrp1.deja.com...
...
> > The ARM explicitly ignored
> > libraries, but nobody (I hope) ever really considered the idea of a
> > standard C++ without any standard IO.
>
> This cowboy still uses printf()! :)

Ah! So you do use the standard library's IO functions! I was beginning
to wonder, judging from the nasty things you've said about the
libraries; particularly the C standard library.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <901lo8$1prn$1@nef.ens.fr>,
  Valentin.Bonnard@free.fr (Valentin Bonnard) wrote:
> James.Kanze@dresdner-bank.com wrote:

> > Still, the thing that bothers me the most about the standard is
> > the feature they dropped from the ARM: true separate compilation
> > of templates.

> Please tell me how ``export'' supports a fake separate compilation
> of templates.

For the moment, export doesn't support anything.  The standard gives
implementations quite a bit of leeway, but words like "an
implementation may require that a translation unit containing the
definition of an exported template be compiled before any translation
unit containing an instantiation of that template" certainly don't do
anything to encourage implementers to do it right.

Technically speaking, of course, the words don't given any freedom
that wasn't there already, and would be equally valid for non-template
code.  The standard doesn't say anything about the compilation model,
and an implementation is free to impose any constraints it likes.
Most do in fact impose some constraints -- the files must be in a
readable directory, or the source filenames must end in one of a
certain subset of endings.

However, it has always been understood that the intent was for
classical separate compilation to work; that is, that I can compile
two translation units completely separately one from the other.
Adding words that insist on the fact that this is not required for one
specific case sounds like an encouragement not to support it for this
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(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

francis.glassborow@ntlworld.com (Francis Glassborow) wrote (abridged):
> >Does this archive exist? How does one make submissions?
>
> Sort of chicken and egg problem. Does an archive exist if it is empty?
> (Now that sounds like a question well suited to Bishop Berkly sp!)

Perhaps the enum proposal could form an initial seed (after reworking, if
necessary). Also there could be meta-material about the archive itself, a
submission guide and the like.


> At a minimum a submission should contain a clear statement of the
> proposal and the motivation for it.

So does the enum submission qualify? The motivation is in the paragraph
beginning, "The advantage is...". I hope the rest of the proposal is
clear enough.


> Send such to me. However do not expect me to go and mine threads to
> tidy up ideas that get flung around.

I don't think I expect thread-mining. However, wouldn't it be nice if
submissions could be made in public, through this newsgroup, in the same
official manner as Defect Reports? The difference between a Defect Report
and a request for a new feature is small enough that sometimes one may be
mistaken for the other.

I've not checked the newsgroup charter, but I imagine future C++
standards may be discussed as well as the current one. I would hope the
archive would become a kind of FAQ, to which people asking questions
(like, "Why can't enums be forward-declared?") could be referred. The
more visible it is, the more likely to be used and added to.

  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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A245CE3.DA11E40F@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> James.Kanze@dresdner-bank.com wrote:
> ...
> > Still, the thing that bothers me the most about the standard is
> > the feature they dropped from the ARM: true separate compilation
> > of templates.

> I'm unfamiliar with the ARM. How did "true seperate compilation"
> differ from the "export" keyword?

It existed:-).  It didn't use the word "export":-).

Seriously, the ARM didn't describe a particular compilation model for
templates.  It also didn't make any particular exceptions for them, so
defining a non-inline function more than once was an error, even if
the function was a template.  (This is also what CFront implemented.)
In the absense of any other specification (and some words to the
effect that implicite instantiation was the intent), the implication
was that templates were exactly like anything else:
  - you specified the class definition in every translation unit which
    used it (typically via a header file), and
  - you specified a function definition exactly once, in a single
    translation unit, then
  - you compiled the translation units which contained the templates,
    and made the resulting object files available, possibly in a
    library.
No compiler ever actually implemented this; CFront required the
sources to be available at link time, for example.  (Sun's CFront
based compilers faked it for some Sun provided libraries -- the
"object" files for the library consisted of encrypted source code, and
nothing else.)

In the end, the problem isn't the template sources.  Getting the
necessary information from them into an object file isn't a problem;
Sun's fake would be perfectly legal.  The problem is the instantiation
context.  In the case of "true separate compilation", the object files
would only be needed at link time.  (This is the CFront model, except
that CFront required the source files, rather than object files.)
Which means that there must be some means of reconstituating the
instantiation context.  CFront used a clever hack involving which
preprocessor files things were defined in, but this raises havoc with
the phases of compilation.  It was also ungodly slow, since the
headers ended up being reparsed during link time, for each function
instantiated, and often had problems determining when these
instantiations needed to be regenerated.  The alternatives require the
compiler to somehow dump the context into the object file, in the same
way that compilation of the template must somehow dump the "source"
into the object file.  Several of the implementors (and not the worst)
claimed it couldn't be done, or at least, that they weren't sure that
they could do it and still give acceptable compile and link times.

Export avoids the problem by explicitly permitting implementations to
require the compilation of the template implementation *before* the
compilation of the files that use it.  The idea, I think, is that the
compiler can use the object file and the current context to
instantiate the template immediately during compilation, and thus to
avoid the requirement of somehow communicating the instantiation
context to a later instantiation phase.

--
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(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <901dvp$g9d$1@panix3.panix.com>,
  comeau@comeaucomputing.com wrote:

> Certainly the SL was a whopper, but namespaces, RTTI, and template
> additions were discussed even before the ARM (which means before the
> committee too).

You forgot exceptions:-).  The ARM presented both templates and
exceptions as "comments", in this case, as a future direction for the
language.  The request for standardization (from HP, I believe) cited
templates, exceptions and garbage collections as extensions the
committee should look into.  I don't remember having heard about RTTI
or namespaces before.  But I'll grant you that a lot of people were
implementing an error-prone RTTI by hand.  On the other hand, a lot of
people are still implementing error-prone RTTI's by hand, because some
of the major uses of RTTI (transportable objects, for example) aren't
addressed by the standard.

> >Still, the thing that bothers me the most about the standard is the
> >feature they dropped from the ARM: true separate compilation of
> >templates.

> vs false separate compilation? :)

Vs. no separate compilation.  According to the ARM, *AND* with the
prototype implementation in CFront, I could compile clients of the
template before the implementation was written.  It's an important
issue in large projects; see some of my comments in the C++ vs. Eiffel
thread in comp.lang.c++.moderated.

I suppose I shouldn't complain too much.  Separate compilation of
templates is a difficult issue, and the C++ solution, for all its
warts, is better than the Java solution (which is the Java solution
for any difficult problem: remove language capabilities until the
problem goes away).  Still, it doesn't make life any simpler.

--
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(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <aDGjsuA7IAJ6EwbV@ntlworld.com>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <900nic$vup$1@nnrp1.deja.com>,
James.Kanze@dresdner-bank.com
> writes
> >Come now, namespaces, RTTI,

> Neither of those is that big and the later was in response to
> developing practice (close to 'existing practice')

Not big?  Changing the way name lookup occurs isn't a major change?

The fact that RTTI was introduced to avoid having everyone doing the
same thing in a different way doesn't affect its size.  In fact, I'd
say that the motivations for a change and the size of the change are
pretty much orthogonal issues.

Just how big does an addition have to before you call it big.  I'm
sure we could have thought of even bigger changes than these, that
weren't adopted.  But they aren't minor, either.

> > and a standard library isn't just a little.

> Yes, but the library isn't the language as such, even though it is
> very important.

The *standard* library is part of the C++ language.  Or are you trying
to say that I can have a conforming implementation without the
library?

> >What was added is more than what was there to begin with.

> ?? really, that is a matter of opinion and not one that I share.

It's not, really.  It's quite measurable.  How many pages are there in
the ARM?  How many pages in the standard?

> What was left out was a factor of ten larger than what was added.

What could have been added but wasn't is certainly larger than what
was actually added.

> And many of the things left out were good ideas in themselves, but
> contrary to common opinion, the Standards Committees were not in the
> business of writing a port manteau language.

Some of the things that were left out might have been good ideas.
Many probably weren't.  The only thing from the ARM that got left out
was a usable model for templates.

> >Although that is an unfair comparison.  The ARM explicitly ignored
> >libraries, but nobody (I hope) ever really considered the idea of a
> >standard C++ without any standard IO.

> >Still, the thing that bothers me the most about the standard is the
> >feature they dropped from the ARM: true separate compilation of
> >templates.

> And that was because no one could actually figure out how to do it
> for real code rather than the small experimental (almost macro
> substitution) templates. You cannot keep a feature in the language
> when the most optimistic comment from any compiler developer was
> 'Yes, we could put it in, but no one would ever use it because the
> result would be several orders of magnitude too slow, and need
> vastly more space.'

> I am pretty certain that if any compiler implementor could figure
> out how to do it you would have it tomorrow.

You mean that if any compiler implementor knew how to do what all of
the Ada compilers do?  Or even what CFront did, after a sort?

I know that some compiler implementers had there doubts.  I also know
that some of the people who were in favor of keeping separate
compilation are not particularly stupid, and not without experience in
writing compilers.

Of course, in the end, it doesn't matter.  The market was apparently
accepting the Windows version of templates, even if it wasn't conform
to the de facto standard.  And if templates ever do turn out to be
useful for anything more than simple containers and basic algorithms
(and the work in generic programming shows much promise that they
will), then the market will force independant compile.  Becase as
specified, templates are pretty much unusable in a large project
environment because of the dependancies they introduce.  (About like
Java, actually.)

--
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(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James.Kanze@dresdner-bank.com wrote:
>
> In article <901lo8$1prn$1@nef.ens.fr>,
>   Valentin.Bonnard@free.fr (Valentin Bonnard) wrote:
> > James.Kanze@dresdner-bank.com wrote:
>
> > > Still, the thing that bothers me the most about the standard is
> > > the feature they dropped from the ARM: true separate compilation
> > > of templates.
>
> > Please tell me how ``export'' supports a fake separate compilation
> > of templates.
>
> For the moment, export doesn't support anything.  The standard gives
> implementations quite a bit of leeway, but words like "an
> implementation may require that a translation unit containing the
> definition of an exported template be compiled before any translation
> unit containing an instantiation of that template" certainly don't do
> anything to encourage implementers to do it right.
>
> Technically speaking, of course, the words don't given any freedom
> that wasn't there already, and would be equally valid for non-template
> code.  The standard doesn't say anything about the compilation model,
> and an implementation is free to impose any constraints it likes.
> Most do in fact impose some constraints -- the files must be in a
> readable directory, or the source filenames must end in one of a
> certain subset of endings.
>
> However, it has always been understood that the intent was for
> classical separate compilation to work; that is, that I can compile
> two translation units completely separately one from the other.
> Adding words that insist on the fact that this is not required for one
> specific case sounds like an encouragement not to support it for this
> case.

The standard allows that because it seems a necessary concession to
make, given the way templates work. You seem to be implying that there
was "true separate compilation of templates" under the ARM. How did that
work? I was under the impression that most C++ compilers during the ARM
period would produce C code as an intermediate step. What would the C
code for an unspecialized template look like?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James Kuyper <kuyper@wizard.net> writes:

[...]

| The standard allows that because it seems a necessary concession to
| make, given the way templates work. You seem to be implying that there
| was "true separate compilation of templates" under the ARM. How did that
| work?

CFront relied on file naming convention. Some CFront variants used
repository to hold specializations.

| ... I was under the impression that most C++ compilers during the ARM
| period would produce C code as an intermediate step. What would the C
| code for an unspecialized template look like?

I dunno.  But modern C++ program translators are not required to
produce C code. What prevent an implementation from using a well
chosen object format (e.e. ELF) to encode templates and like?

Personaly, I don't like to current trend: the headers are the
library.  It takes times to parse headers.

--
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <memo.20001127202744.59809A@a.btinternet.com>, Dave Harris
<brangdon@cix.compulink.co.uk> writes
>francis.glassborow@ntlworld.com (Francis Glassborow) wrote (abridged):
>> And several months ago I offered to arrange a public archive of worked
>> out proposals. There have been zero submissions so far.
>
>Does this archive exist? How does one make submissions?

Sort of chicken and egg problem. Does an archive exist if it is empty?
(Now that sounds like a question well suited to Bishop Berkly sp!)


At a minimum a submission should contain a clear statement of the
proposal and the motivation for it.

Send such to me. However do not expect me to go and mine threads to tidy
up ideas that get flung around. If the originator does not care enough
to write up a proposal why should anyone else?

>

Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James.Kanze@dresdner-bank.com wrote:

> If you standardize before
> the technology is understood, you risk to standardize errors.  And it
> is very difficult to undo something once it has been standardized.

If you wait until you are absolutly sure nothing will be
discovered in a scientific field, then you might wait
forever (and how do you know when things are frozen   ?).

If you don't want to call writing C++ code ``science'',
then just replace ``science'' with ``current technics''.

If you standardize much later after the technology is well
understoud, well accepted, you risk to standardize things
which won't ever be used, because deep understanding and
wide acceptance implies common use, and it's very difficult
to undo something which is a de-facto standard.

Consider the C 89 and the C++ standards.

The C standard was the standardization of common practice,
plus some inventions. Its library includes almost only
pointless, unusable functions.

The C++ standard is based on innovation, and integration of
``young'' ideas like the STL (young compared to the
history of C++, not ``the last idea we had at lunch this
morning''). It possesses many very usefull functions,
together with a few almost useless ones.

I don't know if this comparison proves anything except that
C++ is superior, but at least it shows that innovation in a
committee isn't a receipt for disaster -- at least no more
that pure standardization of existing practice.

Of course, some parts of the C++ library have an experimental
taste: the allocator abstract the ``memory model'', something
no one can define, and the codecvt facet isn't of much help
for encoded text manipulation. OTOH, even if the STL hasn't
found a sound, complete, readable specification language and
isn't well-specified in every cases (like many other libraries),
is usable, and widely used in portable programs.

Of course, just because the C++ committee created a great
language by innovation doesn't mean that creation in a
committee is always a good thing.

Is innovation by a misguided compiler writter any better   ?

--

Valentin Bonnard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <tq6+mVAPxpI6Ewmb@ntlworld.com>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <_NZT5.7957$2s1.536172@bgtnsc06-news.ops.worldnet.att.net>,
> Tony <tony@my.isp.net> writes
> >ARM version of C++ rather than introducing all those permeating
> >concepts (templates, EH, others)

> Which are both described in the ARM. You would be surprised by how
> little was actually added to the language rather than honing what
> was already there in the design.

Come now, namespaces, RTTI, and a standard library isn't just a
little.  What was added is more than what was there to begin with.
Although that is an unfair comparison.  The ARM explicitly ignored
libraries, but nobody (I hope) ever really considered the idea of a
standard C++ without any standard IO.

Still, the thing that bothers me the most about the standard is the
feature they dropped from the ARM: true separate compilation of
templates.

--
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(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James.Kanze@dresdner-bank.com wrote:

> Still, the thing that bothers me the most about the standard is the
> feature they dropped from the ARM: true separate compilation of
> templates.

Please tell me how ``export'' supports a fake separate compilation of
templates.

-- Valentin Bonnard, willing to be enlighted

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James.Kanze@dresdner-bank.com wrote:
...
> Still, the thing that bothers me the most about the standard is the
> feature they dropped from the ARM: true separate compilation of
> templates.

I'm unfamiliar with the ARM. How did "true seperate compilation" differ
from the "export" keyword?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

<James.Kanze@dresdner-bank.com> wrote in message
news:8vu671$3at$1@nnrp1.deja.com...
> In article <4OZT5.7959$2s1.537538@bgtnsc06-news.ops.worldnet.att.net>,
>   "Tony" <tony@my.isp.net> wrote:
>
> > <James.Kanze@dresdner-bank.com> wrote in message
> > news:8vgeu2$h1k$1@nnrp1.deja.com...
>
> > > Concerning standardization, I would recommend reading
> > > http://java.sun.com/people/jag/StandardsPhases/index.html.  In
> > > particular:
> > > "For a standard to be usefully formed, the technology
> > > needs to be understood: technological interest needs to be waning.
>
> > I don't believe that.
>
> There's certainly a part of truth in it.  If you standardize before
> the technology is understood, you risk to standardize errors.  And it
> is very difficult to undo something once it has been standardized.

My thought was more along the lines that a standards body, e.g., has a
better perspective to even SEE a potential for standardization even if it
hasn't yet caught on in industry-specific offerings.

>
> > > But
> > > if political interest in a standard becomes too large, the various
> > > parties have too much at stake in their own vested interest to be
> > > flexible enough to accommodate the unified view that a standard
> > >requires."
>
> > I do believe that.
>
> > > I don't know if there is a real solution.  Personally, I think
> > > that the STL wasn't ripe for the standard, and shouldn't have been
> > > included.
>
> > I agree.
>
> > >  But a C++ standard without *any* array class?  And if not
> > > the STL, then what?
>
> > Wait until technogical interest waned? It probably curbed
> > development of alternatives, stongly recommending it by virtue of
> > its inclusion in the standard. Too much emphasis on that 3rd
> > development paradigm (generic programming)? I think so, since the
> > jury is still out on it. Serving wine before its time? That happened
> > didn't it.
>
> That would have been my preference.  But it would mean that C++ would
> have continued for at least five, maybe ten years longer without a
> standard vector class.

I think those will continually be things that developers reinvent to some
extent.

>  Which has a number of other disadvantages.  In
> the end, no matter what the committee did would be wrong by some
> standard.  I wouldn't be too critical of the committee; they had a
> very difficult job.

Yeah, something was probably needed since most may not be inclined to start
development at the data structures and algorithms level. It gives many a
head start
for sure. I've always considered the library portion of the standards less
important
than the language though.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:tq6+mVAPxpI6Ewmb@ntlworld.com...
> In article <_NZT5.7957$2s1.536172@bgtnsc06-news.ops.worldnet.att.net>,
> Tony <tony@my.isp.net> writes
> >ARM version of C++ rather than introducing all those permeating concepts
> >(templates,
> >EH, others)
>
> Which are both described in the ARM. You would be surprised by how
> little was actually added to the language rather than honing what was
> already there in the design.

OK. I like the little subset then especially.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"J. Stephen Adamczyk" <jsa@edg.com> wrote in message
news:200012010205.VAA14881@edg1.edg.com...
> 3)  I can't speak for implementors in general, but we at EDG care a lot
> about implementing export template, we're working on it, and we expect to
> release it within a few months.  The problem is that it's astoundingly,
> mind-numbingly complex.  You have no idea.  I've been implementing
> compilers for 30 years, and C++ is an order of magnitude harder than
> any other language I've worked on.  And "export template" looks to be
> as hard or harder than every other feature we've implemented (and
> we've implemented all of the other ISO C++ features).

Thank you for reconfirming that staying away from templates is a good idea.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-0312001138450001@du128-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>But it does not change the basic fact that as for that life of a language,
>a standardization, just as it helps doing work with a language, it is also
>kills of its creative evolution which will be needed in order to keep it
>alive in the long run. -- Active and forward revisions may put that off
>for while.

For goodness sake, go and look up the standardisation histories of both
Fortran and COBOL. Both have been through multiple revisions because
there is an active group of users of both languages that want to evolve
their tools to do something more.

Now look at the history of Pascal and BASIC; in each case the first
standardisation was the last.

Standardisation neither kills a language nor causes it to survive, it
just supports its use in a portable way. I do not need to resort to
opinions, nor am I a language bigot, the facts refute your thesis.




Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

remove.haberg@matematik.su.se (Hans Aberg) writes:

| In article <rjTv0vAh5AK6Ewnz@ntlworld.com>, Francis Glassborow
| <francisG@robinton.demon.co.uk> wrote:
| >>My impression with FORTAN was that it was used for the same reason,
| >>backwards compatibility, not because it is an excellent language to
| >>preferred over other languages.
| >
| >Don't ever say that to a numerical specialist. And High Performance
| >Fortran continues to set targets that other languages aspire to, but
| >specifically in the field of computationally intense programming.
|
| Well, I have met some numerical specialists that used FORTRAN on
| supercomputers for performace reasons, but I was under the impression that
| the reason was not that they felt FORTRAN was a very alive language.

I'm working every day with numerical specialists and much of them do
stronglly feel that Fortran (not FORTRAN :-) is a very alive language.
But it practice, they end up programming in FORTRAN (pretty much for
the same reasons some C programmers will program in K&R style).
However, some of them feel that they could gain in efficiency had some
programming languages such as C++ had better support for numerics then
they currently do.

| Just because there are people using a language actively, perhaps
| dedicating their whole life to it, it does not mean that the language is
| alive. -- Latin is a very good example of this among human languages.

I'm not sure I agree with you: as a scientist FORTRAN has more impact
on my life than Latin does ;-)

--
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James.Kanze@dresdner-bank.com wrote:
>
> In article <200012010205.VAA14881@edg1.edg.com>,
>   "J. Stephen Adamczyk" <jsa@edg.com> wrote:
...
> > Some day soon, you will be able to get compilers that support
> > "export" on templates, and you will be able to decide for yourself
> > whether you find it useful.
>
> Just curious, but will it be real separate compilation, where I can
> actually compile client code before the template implementation is
> even written, or will it require that the template code be compiled
> before the client code (as the standard reminds us in a note is
> allowed).

According to <http://animal.ihug.co.nz/c++/compilers.html>, TenDRA is a
highly conforming implementation of C++ that even provides (minimal)
support for the 'export' keyword. I find this surprising, because the
best web links I've been able to find
<http://www.cse.unsw.edu.au/~patrykz/TenDRA/> suggest that TenDRA
predates the final C++ standard, and hasn't been updated since. I
couldn't figure out by following those links - does anyone know HOW
TenDRA implemented 'export', such as whether it imposed restrictions on
the compilation order?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <xaj8zq1b3zv.fsf@korrigan.inria.fr>,
  Gabriel Dos_Reis <gdosreis@korrigan.inria.fr> wrote:
> James.Kanze@dresdner-bank.com writes:

> [...]

> | ...  It was also ungodly slow, since the headers ended up being
> | reparsed during link time, for each function instantiated, and
> | often had problems determining when these instantiations needed to
> | be regenerated.

> How slow is slow?

Slow enough for people to complain about it.

> Compare that to the opposite models:  templates get
> parsed even if there are not needed.

That's what I would have thought.  I would have imagined that the
combination of having to parse the full implementation in each
translation unit, and potentially instantiating the same thing
hundreds of times, just to throw out the duplicates, would have made
the current solution slower than CFront.

Borland used the current solution, however, and had no complaints.
(Perhaps it was just used on smaller applications, I don't know.)  And
the two most skilled pratitioners that I know in the field claim that
the CFront model won't scale, but the Borland will.  Since I have no
actual experience with instantiating templates, I hesitate to
contradict those that do.

> Some popular implementations can't just compile some popular
> libraries -- try Blitz with GCC and you'll see what I mean.

Things are improving.  I don't push templates at all, but most of what
I write today wouldn't pass either CFront or g++ 2.7.2.  But I am glad
that my applications don't need anything really intensive, like Blitz.

--
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(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <90e2av$g29$1@mach.thp.univie.ac.at>,
jthorn@galileo.thp.univie.ac.at (Jonathan Thornburg) wrote:
>In article <remove.haberg-0312001138450001@du128-226.ppp.su-anst.tninet.se>,
>Hans Aberg <remove.haberg@matematik.su.se> wrote:
>> Well, I have met some numerical specialists that used FORTRAN on
>> supercomputers for performace reasons, but I was under the impression that
>> the reason was not that they felt FORTRAN was a very alive language.
>
>Your impression was and is false.

Who are you to give judgement about my impressions -- I thought I was the
guy. :-)

>  If I (as a computational scientist
>who uses a mixture of C, C++, Fortran, Maple, and Perl on a day-to-day
>basis) look at myself and my colleagues and ask those that use Fortran,
>"why?", there are basically 3 key reasons (these apply on all scales
>from PCs to supercomputers):
>* performance relative to C/C++
>* ease of learning relative to C/C++
>* compatability with other Fortran software
>All of these are important.

To me you are saying the exactly the same thing as me: None of the reasons
you give are any indication of that FORTRAN is a particularly alive
language, but one uses for backwards compatibility because inertia of
switching to something better.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <LPVnfiA5asK6EwBd@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>Standardisation neither kills a language nor causes it to survive, it
>just supports its use in a portable way. I do not need to resort to
>opinions, nor am I a language bigot, the facts refute your thesis.

Well, supporting its use in a portable way coflicts with being able to
change it in a creative way. This is very apparent phenonmenon in computer
language construction:

If one does not standardize, people will turn away from it, because it is
not to rely one on it due to constant changes. But the standardization
requires one to zip out creative parts. Most standards are also pretty
corny, even useable, for various reasons.

So when a language is created, standardization, just as it helps it for a
time, also paves the way for its demise. So, one better be create some new
languages in the which can stand by and take over whne the time is right.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A2A9A47.489A1D11@wizard.net>, James Kuyper
<kuyper@wizard.net> wrote:
>> Well, I have met some numerical specialists that used FORTRAN on
>> supercomputers for performace reasons, but I was under the impression that
>> the reason was not that they felt FORTRAN was a very alive language.
>
>You might want to question them more closely. Fortran might be a dying
>language (I certainly hope so), but it's a very long way from dead.

I think this exactly the point I wanted to bring out, but someow was
misinterpreted:

I am not interested in nit-picking over whether this or that language is
to be considered dead. The queston was whether a standardizatioon would
have any effect to kill off a language, and this is indeed so.

Is there anything wrong with it? While we now figure out proppoing up C++
for the next edition, we of course work opn suitable future replacements.

>There are still people reciting the mantra "I don't know what THE
>computer language of the next decade will look like, but it's name will
>be Fortran". I'll grant you, they're insane :-) but they are saying it.
>
>> Just because there are people using a language actively, perhaps
>> dedicating their whole life to it, it does not mean that the language is
>> alive. -- Latin is a very good example of this among human languages.
>
>On the contrary, I can't think of a better definition of a living
>language, than that there are people who use it for their everyday
>lives. The corresponding definition of a living computer language
>definitely applies to Fortran.

Well, Latin isn't a living alnguage, despite people using it in their
everyday lives, perhaps deicating all their lives to it. There has to be
something more than a dedicated group of fans.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <xajaeac77ex.fsf@korrigan.inria.fr>, Gabriel Dos_Reis
<gdosreis@sophia.inria.fr> wrote:
>| Well, I have met some numerical specialists that used FORTRAN on
>| supercomputers for performace reasons, but I was under the impression that
>| the reason was not that they felt FORTRAN was a very alive language.
>
>I'm working every day with numerical specialists and much of them do
>stronglly feel that Fortran (not FORTRAN :-) is a very alive language.
>But it practice, they end up programming in FORTRAN (pretty much for
>the same reasons some C programmers will program in K&R style).
>However, some of them feel that they could gain in efficiency had some
>programming languages such as C++ had better support for numerics then
>they currently do.

I think you say what I say: One uses FORTRAN not because it is a
particularly alive language, but because one other languages, such as C++,
yet have not lived  up to the promise.

C++ could be very suitable, but the standard (as I recall) gives no
guarantee for concurrency. -- I think that one useable thing in numerics
is to be able to use it on a parallel or distributed supercomputer.

>| Just because there are people using a language actively, perhaps
>| dedicating their whole life to it, it does not mean that the language is
>| alive. -- Latin is a very good example of this among human languages.
>
>I'm not sure I agree with you: as a scientist FORTRAN has more impact
>on my life than Latin does ;-)

Yes, life, but not on the life of a Latin scholar, or somebody in the
Vatican. :-)

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <90g106$o9k$1@nnrp1.deja.com>, James.Kanze@dresdner-bank.com wrote:
>> 1) I know the statement was labeled as "provocative", but it's
>> ridiculous to say that templates are only being used as toys.  There
>> are many, many very large projects using templates in amazingly
>> complex ways.  As baroque as they are, C++ templates provide
>> something that you can't get in any other language out there, and
>> people exploit that right up to the edge of the (significant)
>> capabilities of current implementations.
>
>To continue being provocative: in a certain way, large and toy are
>orthogonal.  I don't see templates being used for much other than the
>basic containers in commercial and industrial products.  Generally
>speaking, they *are* recognized as something without a real equivalent
>in other language.  But most commercial and industrial shops take a
>rather wait and see attitude.  In French, I'd say "laisser quelqu'un
>d'autre essuyer les pl   tres"; I can't think of a good English
>equivalent, but the basic idea is that no matter how good an idea,
>there will be problems with it when it is first used, and it is better
>to let others find them out.  If by "toy", you mean playing around or
>experimenting, then yes, most large applications which make extensive
>use of templates are "toy".

I tried to point that the main point with the templates is not whether
people out there use them in the sense that they sit and do template
programming, but that they allow people that understand abstractions like
generic programming built libraries that other and use in more special
circumstances.

Otherwise, there are circumstances where templates are needed, other than
for containers and the like, for example when making polymorphic function
pointers. Templates may need to be extended somewhat.

But in the long run, the right path is not to build more and more advanced
templates: They are too primitive for that. Instead, it is better building
a polymorphic variable that runs over all data types one is interested in
manipulating. This is slow, clearly, compared to templates, but in the
long run, as computers become more powerful, it will not be worth wasting
programmer time on the rather complex templates. By contrast, polymorphic
variables are easy to use. Templates are still needed in order to
implement efficient dynamic structures.

So apart from some extensions to templates, I see that C++ needs
extensions that the implementation of dynamic structures can be made easy.
(So this is not a question whether C++ should become dynamically typed so,
but merely that one should not need to write long and complex commands
just because the output is a dynamic structure.)

I can report an interesting experiment I have just started: As it is so
difficult to write down the code needed to implementing dynamic structures
in C++, I started to write my own language, using Flex and Bison, which
outputs C++ code.

I quickly realized it was complex to write C++ files, so for that purpose,
I first made "formatter", a program that from macro definitions and
building suitably nested lookup tables (written in C++ code) knows how to
output C++ files. This formatter dramatically simplifies the stuff I need
to put into the actions Bison grammar rules; in fact, most rules become
empty.

Perhaps C++ would benefit of a more advanced macro preprocessor other than
the old C-one, which could make similar work as the formatter I just
wrote.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-0412002057360001@du150-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>So when a language is created, standardization, just as it helps it for a
>time, also paves the way for its demise. So, one better be create some new
>languages in the which can stand by and take over whne the time is right.

Well you are entitled to your opinion, I just happen to think it is
wrong. Name one language that has survived more than 25 years in regular
use other than for mainly academic purposes that has not been
standardised through at least two iterations. Yes I can name a couple
but they are both even more rigidly controlled by their inventors.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hans Aberg wrote:
>
> In article <3A2A9A47.489A1D11@wizard.net>, James Kuyper
> <kuyper@wizard.net> wrote:
...
> I am not interested in nit-picking over whether this or that language is
> to be considered dead. The queston was whether a standardizatioon would
> have any effect to kill off a language, and this is indeed so.

You were given a list of three languages that had been standardized
without dying, as counterexamples to your claim. The ball's in your
court to provide some kind of support for your claim. You could try to
somehow justify calling three different very active languages "dead", or
come up with a convincing list of other languages that did actually die
as a results of standardization, or choose some other method. Simply
repeating your assertion that "standardization kills" proves nothing,
(except that if you truly believe that, then you're wasting your time
participating in a newsgroup devoted to standardization -
comp.lang.c++.moderated would be more appropriate).

...
> >On the contrary, I can't think of a better definition of a living
> >language, than that there are people who use it for their everyday
> >lives. The corresponding definition of a living computer language
> >definitely applies to Fortran.
>
> Well, Latin isn't a living alnguage, despite people using it in their
> everyday lives, perhaps deicating all their lives to it. There has to be
> something more than a dedicated group of fans.

If you know of people that are indeed living their everyday lives
speaking Latin, then I can't see any justification for calling it a dead
language. Church Latin is very much alive and evolving - it's not the
same as the Latin spoken in ancient times.

In any event, if, as you claim, there are only a few such people, then
that would make Latin a lousy analogy for Fortran. A better analogy
would be Swahili, or Basque, or Hindi, or some other language with a
fair number of native speakers.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <LPVnfiA5asK6EwBd@ntlworld.com>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <remove.haberg-0312001138450001@du128-226.ppp.su-
> anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
> >But it does not change the basic fact that as for that life of a
> >language, a standardization, just as it helps doing work with a
> >language, it is also kills of its creative evolution which will be
> >needed in order to keep it alive in the long run. -- Active and
> >forward revisions may put that off for while.

> For goodness sake, go and look up the standardisation histories of
> both Fortran and COBOL. Both have been through multiple revisions
> because there is an active group of users of both languages that
> want to evolve their tools to do something more.

> Now look at the history of Pascal and BASIC; in each case the first
> standardisation was the last.

> Standardisation neither kills a language nor causes it to survive,
> it just supports its use in a portable way. I do not need to resort
> to opinions, nor am I a language bigot, the facts refute your
> thesis.

In fact, in the case of Pascal and Basic, one of the things that
"killed" the language is the fact that the standard came too late.  By
the time standardization occured, there were already too many
incompatible implementations, each with too much existing code to
permit changing to conform to the standard.  (There are other issues
as well, of course, but in both cases, the *lack* of a standard early
enough played a role.)

--
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(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-0412002057360001@du150-226.ppp.su-anst.tninet.se>,
Hans Aberg <remove.haberg@matematik.su.se> wrote:
>In article <LPVnfiA5asK6EwBd@ntlworld.com>, Francis Glassborow
><francisG@robinton.demon.co.uk> wrote:
>>Standardisation neither kills a language nor causes it to survive, it
>>just supports its use in a portable way. I do not need to resort to
>>opinions, nor am I a language bigot, the facts refute your thesis.
>
>Well, supporting its use in a portable way coflicts with being able to
>change it in a creative way.

Although that's possible, it's certainly not a requirement,
as Francis pointed out.

>This is very apparent phenonmenon in computer
>language construction:
>
>If one does not standardize, people will turn away from it,

But as Francis pointed out, that doesn't always happen.

>because it is
>not to rely one on it due to constant changes.

Again, possible but not the only path.

>But the standardization
>requires one to zip out creative parts. Most standards are also pretty
>corny, even useable, for various reasons.

What?

>So when a language is created, standardization, just as it helps it for a
>time, also paves the way for its demise.

Therefore it follows that all standardardized languages have demised.
But as Francis has amply pointed out, that is not always the case.
So therefore your premise as a carte blance statement is wrong.

>So, one better be create some new
>languages in the which can stand by and take over whne the time is right.

In that case, better not standardize it.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

The potential bad thing about standardization as "standardization of current
practice"
may be that what gets standardized is complexity as it may be in the best
interests of
vendors to protect their technological turf by making it difficult for
others to tool up
and produce similar products. In that sense, standardization doesn't work
for the
larger group but rather only for the vendors. So the question is, what are
the missions
of the standards bodies and who do they serve in theory and in reality. "The
industry?",
(vague), "the vendors?", "the users?", "everyone?" etc.

Tony

"James Kuyper" <kuyper@wizard.net> wrote in message
news:3A25987D.740C7FE3@wizard.net...
> Tony wrote:
> >
> > <James.Kanze@dresdner-bank.com> wrote in message
> > news:8vu671$3at$1@nnrp1.deja.com...
> ...
> > > There's certainly a part of truth in it.  If you standardize before
> > > the technology is understood, you risk to standardize errors.  And it
> > > is very difficult to undo something once it has been standardized.
> >
> > My thought was more along the lines that a standards body, e.g., has a
> > better perspective to even SEE a potential for standardization even if
it
> > hasn't yet caught on in industry-specific offerings.
>
> If it hasn't caught on yet in any industry-specific offering, then its
> likely to be the case that it ISN'T a good candidate for
> standardization. You seem to be stuck in the mode of thinking of
> "standard C" as a product, out there competing with Borland C, Microsoft
> C, GNU C, etc. It isn't. Standard C is a standard, not a product. It
> marks the common ground that you can count on between many different
> implementations. It's not in any sense competing with those
> vendor-specific implementations. If nobody's making any significant use
> of a proposed new feature yet (as a language extension, of course), then
> it's probably not sufficiently widely useful or well-enough understood
> to justify standardizing 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.research.att.com/~austern/csc/faq.html                ]
> [ Note that the FAQ URL has changed!  Please update your bookmarks.     ]
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

I know that's what's been conveyed (that if it doesn't exist it can't be
standardized),
but I can't hardly believe that when working on standardizing pin point
items that
the range of available things doesn't become more appearant and that they
shouldn't
be considered as the standard (I think they should). I'm viewing the
standard more as
a reachable goal rather than just documenting current practice. And no, I
don't see the
standard as competing with vendor products but rather as a goal for vendors.
I think
you're assuming that the vendors are always the leaders and I'm assuming
that sometimes
they're not.

Tony

"James Kuyper" <kuyper@wizard.net> wrote in message
news:3A25987D.740C7FE3@wizard.net...
> Tony wrote:
> >
> > <James.Kanze@dresdner-bank.com> wrote in message
> > news:8vu671$3at$1@nnrp1.deja.com...
> ...
> > > There's certainly a part of truth in it.  If you standardize before
> > > the technology is understood, you risk to standardize errors.  And it
> > > is very difficult to undo something once it has been standardized.
> >
> > My thought was more along the lines that a standards body, e.g., has a
> > better perspective to even SEE a potential for standardization even if
it
> > hasn't yet caught on in industry-specific offerings.
>
> If it hasn't caught on yet in any industry-specific offering, then its
> likely to be the case that it ISN'T a good candidate for
> standardization. You seem to be stuck in the mode of thinking of
> "standard C" as a product, out there competing with Borland C, Microsoft
> C, GNU C, etc. It isn't. Standard C is a standard, not a product. It
> marks the common ground that you can count on between many different
> implementations. It's not in any sense competing with those
> vendor-specific implementations. If nobody's making any significant use
> of a proposed new feature yet (as a language extension, of course), then
> it's probably not sufficiently widely useful or well-enough understood
> to justify standardizing 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.research.att.com/~austern/csc/faq.html                ]
> [ Note that the FAQ URL has changed!  Please update your bookmarks.     ]
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Well mostly for debugging. The "printf()'s" mostly get conditionally removed
at preprocessing
time for "release" builds (where logging and such stuff replaces the
printf()'s). And before
you ask, no I don't use the std stream file functions. I use a lot more of
the library now than
I will in the future though for sure. I just haven't enough time to reinvent
everything in there at
this juncture. But it may be in my plans to do so. I'm still deciding on
some of these things.

Tony

"James Kuyper" <kuyper@wizard.net> wrote in message
news:3A259933.29EC27D7@wizard.net...
> Tony wrote:
> >
> > <James.Kanze@dresdner-bank.com> wrote in message
> > news:900nic$vup$1@nnrp1.deja.com...
> ...
> > > The ARM explicitly ignored
> > > libraries, but nobody (I hope) ever really considered the idea of a
> > > standard C++ without any standard IO.
> >
> > This cowboy still uses printf()! :)
>
> Ah! So you do use the standard library's IO functions! I was beginning
> to wonder, judging from the nasty things you've said about the
> libraries; particularly the C standard library.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow <francis.glassborow@ntlworld.com> writes:

[...]

| >Still, the thing that bothers me the most about the standard is the
| >feature they dropped from the ARM: true separate compilation of
| >templates.
|
| And that was because no one could actually figure out how to do it for
| real code rather than the small experimental (almost macro substitution)
| templates.

Wasn't CFront a proof of the concept?

[...]

| I am pretty certain that if any compiler implementor could figure out
| how to do it you would have it tomorrow.

Well, I'll put it as follows: no implementor provide export
because no one seems to care. Maybe it is because templates are still
being  -- well I'm being a bit provocative -- used as toys:  effort is
being much invested in syntax rather than in semantics.

My::template two<cents>().

--
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James.Kanze@dresdner-bank.com writes:

[...]

| > Yes, but the library isn't the language as such, even though it is
| > very important.
|
| The *standard* library is part of the C++ language.  Or are you trying
| to say that I can have a conforming implementation without the
| library?

Yes, just pick a free-standing implementation :-)

[...]

| Of course, in the end, it doesn't matter.  The market was apparently
| accepting the Windows version of templates, even if it wasn't conform
| to the de facto standard.

And excusing implementors for not doing the work won't help to improve
the situation :-(

--
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <xaj3dg9b3d0.fsf@korrigan.inria.fr>, Gabriel Dos_Reis
<gdosreis@korrigan.inria.fr> writes
>| And that was because no one could actually figure out how to do it for
>| real code rather than the small experimental (almost macro substitution)
>| templates.
>
>Wasn't CFront a proof of the concept?

Only in the sense that implementing a bubble sort on a list of ten might
be a proof of concept (and does not work reasonably in general, and
fails when a stable sort is needed) I know of no version of CFront that
attempted to handle templates as they are today (and that development
was driven by the 'needs' of library developers)


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James.Kanze@dresdner-bank.com writes:

[...]

| I suppose I shouldn't complain too much.  Separate compilation of
| templates is a difficult issue, and the C++ solution, for all its
| warts, is better than the Java solution (which is the Java solution
| for any difficult problem: remove language capabilities until the
| problem goes away).  Still, it doesn't make life any simpler.

Certainly, C++ solution sort-of is better; but excusing implementors
for not implementing export will bring us pretty much close to Java
solution :-)

--
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James.Kanze@dresdner-bank.com writes:

[...]

| ...  It was also ungodly slow, since the
| headers ended up being reparsed during link time, for each function
| instantiated, and often had problems determining when these
| instantiations needed to be regenerated.

How slow is slow?  Compare that to the opposite models:  templates get
parsed even if there are not needed.  Some popular implementations
can't just compile some popular libraries -- try Blitz with GCC and
you'll see what I mean.

--
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <memo.20001130130713.23763A@a.btinternet.com>, Dave Harris
<brangdon@cix.compulink.co.uk> writes
>I don't think I expect thread-mining. However, wouldn't it be nice if
>submissions could be made in public, through this newsgroup, in the same
>official manner as Defect Reports? The difference between a Defect Report
>and a request for a new feature is small enough that sometimes one may be
>mistaken for the other.

Let us try it that way, if the moderators agree. I will try to get some
kind of charter, but do not expect it quickly because I am up to my ears
with deadlines at present.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr writes
> Francis Glassborow <francis.glassborow@ntlworld.com> writes:
> | >Still, the thing that bothers me the most about the standard is the
> | >feature they dropped from the ARM: true separate compilation of
> | >templates.
> |
> | And that was because no one could actually figure out how to do it for
> | real code rather than the small experimental (almost macro substitution)
> | templates.
>
> Wasn't CFront a proof of the concept?
>
> | I am pretty certain that if any compiler implementor could figure out
> | how to do it you would have it tomorrow.
>
> Well, I'll put it as follows: no implementor provide export
> because no one seems to care. Maybe it is because templates are still
> being  -- well I'm being a bit provocative -- used as toys:  effort is
> being much invested in syntax rather than in semantics.

I have to respond to several items in this thread:

1)  I know the statement was labeled as "provocative", but it's ridiculous
to say that templates are only being used as toys.  There are many, many very
large projects using templates in amazingly complex ways.  As baroque
as they are, C++ templates provide something that you can't get in any
other language out there, and people exploit that right up to the edge
of the (significant) capabilities of current implementations.

2)  Pretty much every C++ compiler out there today (including those based
on the front end produced by my company, Edison Design Group) provides
some form of separate compilation of templates, and usually in a version
that is at least as sophisticated as the Cfront approach.  Cfront may
have been a proof of the concept, but in the same sense that Goddard's rockets
helped people believe that we could send rockets to the moon; Cfront's
implementation of templates bears about the same relationship to the
implementation required for full ISO C++ templates.

3)  I can't speak for implementors in general, but we at EDG care a lot
about implementing export template, we're working on it, and we expect to
release it within a few months.  The problem is that it's astoundingly,
mind-numbingly complex.  You have no idea.  I've been implementing
compilers for 30 years, and C++ is an order of magnitude harder than
any other language I've worked on.  And "export template" looks to be
as hard or harder than every other feature we've implemented (and
we've implemented all of the other ISO C++ features).

4)  No one disagrees with the basic idea that it would be great if
templates could be separately compiled just like external functions,
and just as efficiently.  But it's not the same kind of process:
a template instantiation occurs in a strange synthesized environment
that contains the lookup context of the point of definition of the
template, and types and values (and all the classes and namespaces etc.
that they are related to) from the template arguments at the point
of instantiation of the template.  It's a very different kind of
processing than the simple read tokens/look up some names/generate
some object code that applies when you compile a simple external
function.

Some day soon, you will be able to get compilers that support "export"
on templates, and you will be able to decide for yourself whether
you find it useful.

You don't have it yet because it's really hard, and not because
C++ implementors are lazy, incompetent, or perversely opposed
to giving programmers what they want. :-)

Steve Adamczyk
Edison Design Group

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"J. Stephen Adamczyk" <jsa@edg.com> writes:

| Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr writes
| > Francis Glassborow <francis.glassborow@ntlworld.com> writes:
| > | >Still, the thing that bothers me the most about the standard is the
| > | >feature they dropped from the ARM: true separate compilation of
| > | >templates.
| > |
| > | And that was because no one could actually figure out how to do it for
| > | real code rather than the small experimental (almost macro substitution)
| > | templates.
| >
| > Wasn't CFront a proof of the concept?
| >
| > | I am pretty certain that if any compiler implementor could figure out
| > | how to do it you would have it tomorrow.
| >
| > Well, I'll put it as follows: no implementor provide export
| > because no one seems to care. Maybe it is because templates are still
| > being  -- well I'm being a bit provocative -- used as toys:  effort is
| > being much invested in syntax rather than in semantics.
|
| I have to respond to several items in this thread:
|
| 1)  I know the statement was labeled as "provocative", but it's ridiculous
| to say that templates are only being used as toys.

Sure it is ridiculuous to say that template are *only* being used as
toys.  But that wasn't the point of that statement.

[...]

| 3)  I can't speak for implementors in general, but we at EDG care a lot
| about implementing export template, we're working on it, and we expect to
| release it within a few months.  The problem is that it's astoundingly,
| mind-numbingly complex.  You have no idea.

You have no idea that I have no idea ;-)
At CodeSourcery, we've been discussing the matter.  The most
compelling reason for which we've not been considering to implement it
is that our customers don't seem to make it an issue, or at least a
higher priority one.

[...]

| 4)  No one disagrees with the basic idea that it would be great if
| templates could be separately compiled just like external functions,
| and just as efficiently.  But it's not the same kind of process:
| a template instantiation occurs in a strange synthesized environment
| that contains the lookup context of the point of definition of the
| template, and types and values (and all the classes and namespaces etc.
| that they are related to) from the template arguments at the point
| of instantiation of the template.

Thanks, I'm certainly aware of that.  From time to time we happen to
discuss how to implement export in GCC, but so far there is no serious
project (e.g. funding from customers) to support a full-time work for
separate template compilation. But not just because we didn't provide
it means we aren't aware of technical details of template processing.

[...]

| Some day soon, you will be able to get compilers that support "export"
| on templates, and you will be able to decide for yourself whether
| you find it useful.

Well, I guess once one compiler has it then marketplace pressure will
probably push others to follow.

| You don't have it yet because it's really hard, and not because
| C++ implementors are lazy, incompetent, or perversely opposed
| to giving programmers what they want. :-)

I don't know where you gather all those qualifiers in this thread
but I never qualify implementors as being lazy, incompetent or
perversely opposed to giving programmers what they want.  In the
message you quote I said:

  Well, I'll put it as follows: no implementor provide export
  because no one seems to care.


Not just I happen to bear my user hat and say what I think about
current compiler supports means I'm ignorant, having no idea of how
template processing can be, qualifying implementors as being "lazy,
incompetent or perversely opposed to giving programmers what they
want."

--
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"J. Stephen Adamczyk" wrote:

[...]

> 3)  I can't speak for implementors in general, but we at EDG care a lot
> about implementing export template, we're working on it, and we expect to
> release it within a few months.  The problem is that it's astoundingly,
> mind-numbingly complex.  You have no idea.

[...]

Do you expect to get the #pragmas in the definition context to work with those in
the instantiation context?


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8qs6GACrFpH6Ewc0@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>But this does not mean that standardization is not supposed to be
>>leadership: In the past, a standardization of a programming language has
>>also been the first steps to the demise of that language. For this reason,
>>one has now revisions of the computer programming languages, to make them
>>survive somewhat longer, and this is what we discuss her in this thread.
>>
>Interesting:) When did COBOL and Fortran die? Both have been throught
>the standardisation process several times. And, AFAIK, C is still alive,
>well and prospering.

This is statement of the kind "sure there is a forest because I saw at
least one tree". One ends up with a discussion on how to define a forest
or how many users there should be of a language in order to view it to be
alive. Is Latin a live language; I mean it is spoken in the Vatican and by
scholars, so it is not to be considered dead then?

Simula is still used in the eduction at Swedish Universities. Is Simula
still alive then?

>ISO Pascal and BASIC never really took hold but that did not mean the
>languages died (look at Delphi, and VB)

I think that those that use COBOL and Fortran perhaps though Basic and
Pascal never really took hold. But Basic and Pascal was used extensive in
the educational sector. The MacOS was originally written in Pascal, so
TeX, and it is still used for backwards compatibility.

My impression with FORTAN was that it was used for the same reason,
backwards compatibility, not because it is an excellent language to
preferred over other languages.

>I think your premise is false, when a language is standardised it
>becomes less visible because real programmers are now using it to do
>real work (TM)

The premise means that once one has standardized a language one also mold
it in a way that makes further development needed to keep up with the
changes of time more difficult.

In article <8vu6hb$3g4$1@nnrp1.deja.com>, James.Kanze@dresdner-bank.com wrote:

>>> For
>> this reason, one has now revisions of the computer programming
>> languages, to make them survive somewhat longer, and this is what we
>> discuss her in this thread.
>
>The ISO process requires an evaluation of *every* standard on a
>periodic basis.  This is nothing new, and nothing to do with
>programming languages.

I recall that the old process was to slow, so that in the case of
programming languages, the process was speeded up. I do not know if this
was made to be general over all (non-PL) standards.

>> A great deal of leadership will be needed in order to keep C++ alive
>> in the new revision. Again, it needs not to select leading edge
>> technologies for inclusion in the C++ standard, but it needs to take
>> a good look at leading edge technologies and see what basic
>> techniques are needed there; then those basic components should be
>> included in the C++ standard.
>
>Typically, the first standard of a language enshrines existing
>practice.  The later versions can be a little bit more daring, as long
>as backward compatibility is maintained.

This sound good, because it will be needed:

If one does not like STL for example, it is possible to introduce a
completely new replacement, as long at it does not produces an excessive
burden on compiler developers, and as long as the old STL remains for
backwards compatibility.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hans Aberg wrote:
> In article <8qs6GACrFpH6Ewc0@ntlworld.com>, Francis Glassborow
> <francisG@robinton.demon.co.uk> wrote:
...
> >Interesting:) When did COBOL and Fortran die? Both have been throught
> >the standardisation process several times. And, AFAIK, C is still alive,
> >well and prospering.
>
> This is statement of the kind "sure there is a forest because I saw at
> least one tree". One ends up with a discussion on how to define a forest
> or how many users there should be of a language in order to view it to be
> alive. Is Latin a live language; I mean it is spoken in the Vatican and by
> scholars, so it is not to be considered dead then?

"one tree"? COBOL, Fortran, and C are all still far more alive than
Latin is. Just take a look at the comp.lang.* newsgroups, as a very
rough indicator of popularity. comp.lang.cobol and comp.lang.fortran are
both fairly active newsgroups, and comp.lang.c is one of the most active
newsgroups in that hierarchy, with 23073 messages the last time I
looked.

> My impression with FORTAN was that it was used for the same reason,
> backwards compatibility, not because it is an excellent language to
> preferred over other languages.

Backwards compatibility was certainly a factor, but it wasn't the only
one. Fortran would never be my language of choice, but I know a few of
the reasons why it was the language of choice for many others. Fortran's
popularity has historically been due at least in part to the fact that
its compilers have been among the best optimized ones available. It's a
simpler language than C, and correspondingly easier to learn and use.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-0112001122290001@du133-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>My impression with FORTAN was that it was used for the same reason,
>backwards compatibility, not because it is an excellent language to
>preferred over other languages.

Don't ever say that to a numerical specialist. And High Performance
Fortran continues to set targets that other languages aspire to, but
specifically in the field of computationally intense programming.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <rjTv0vAh5AK6Ewnz@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>My impression with FORTAN was that it was used for the same reason,
>>backwards compatibility, not because it is an excellent language to
>>preferred over other languages.
>
>Don't ever say that to a numerical specialist. And High Performance
>Fortran continues to set targets that other languages aspire to, but
>specifically in the field of computationally intense programming.

Well, I have met some numerical specialists that used FORTRAN on
supercomputers for performace reasons, but I was under the impression that
the reason was not that they felt FORTRAN was a very alive language.

Just because there are people using a language actively, perhaps
dedicating their whole life to it, it does not mean that the language is
alive. -- Latin is a very good example of this among human languages.

Pascal is probably just as alive as COBOL and FORTRAN to those that use
it. -- So when so select COBOL and FORTAN as alive and Pascal as dead, one
might guess you mean that you use COBOL and FORTRAN but not Pascal.

But it does not change the basic fact that as for that life of a language,
a standardization, just as it helps doing work with a language, it is also
kills of its creative evolution which will be needed in order to keep it
alive in the long run. -- Active and forward revisions may put that off
for while.

So the next question is really, what will replace C++? Perhaps there
should be a group comp.c++.replacement...

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

: My impression with FORTAN was that it was used for the same reason,
: backwards compatibility, not because it is an excellent language to
: preferred over other languages.

In article <rjTv0vAh5AK6Ewnz@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
@ Don't ever say that to a numerical specialist. And High Performance
@ Fortran continues to set targets that other languages aspire to, but
@ specifically in the field of computationally intense programming.

In article <remove.haberg-0312001138450001@du128-226.ppp.su-anst.tninet.se>,
Hans Aberg <remove.haberg@matematik.su.se> wrote:
> Well, I have met some numerical specialists that used FORTRAN on
> supercomputers for performace reasons, but I was under the impression that
> the reason was not that they felt FORTRAN was a very alive language.

Your impression was and is false.  If I (as a computational scientist
who uses a mixture of C, C++, Fortran, Maple, and Perl on a day-to-day
basis) look at myself and my colleagues and ask those that use Fortran,
"why?", there are basically 3 key reasons (these apply on all scales
from PCs to supercomputers):
* performance relative to C/C++
* ease of learning relative to C/C++
* compatability with other Fortran software
All of these are important.



An interesting sample of software is the SPEC2000 benchmark suite,
widely used to assess the performance of hardware/software.  A brief
perusal of
   http://www.specbench.org/osg/cpu2000/CINT2000/
   http://www.specbench.org/osg/cpu2000/CFP2000/
reveals the following distribution of languages:

  SPEC CPU2000 SPEC CPU2000
  integer  floating point
C  11  4
C++  1  0
Fortran 77 0  6
Fortran 90 0  4
Other  0  0

Two other interesting comparisons from very well-respected sources:

In article <85319g$mvr$1@porthos.nl.uu.net> (comp.arch, 6 Jan 2000),
Toon Moene <toon@moene.indiv.nluug.nl> wrote [[some lines rewrapped]]:
% Unfortunately, I'd wish I could find the posting some months ago to the
% mailing list comp-fortran-90 that compared the languages software was written
% in that was submitted to a well-known journal of computational science [
% yeah, right, I do not even recall which one ]
%
% Basically, the top two languages were Fortran 77 and Fortran 90,
% with a shift from  Fortran 77 to Fortran 90 of about 20 % on the
% 77 side to 100 % on the 90 side (i.e. something like 77 going from
% 50 to 40 and 90 going from 10 to 20 articles).
%
% All other languages came _long_ after those two.

In article <387A4287.28A5BFAF@austin.rr.com> (comp.arch, 10 Jan 2000),
John McCalpin <mccalpin@austin.rr.com> wrote:
$ When I last looked at commercial/ISV codes in the scientific/technical/
$ engineering area, roughly 75% were written in Fortran77, 20% in C, and
$ (IIRC) 5% in C++ (one code?).
$
$ The shift over the past 5 years has been toward C, but it has been
$ very slow and does not appear to be accelerating.



Finally, to return this discussion to something at least vaguely on-topic
for comp.std.c++, in previous threads on comp.arch and comp.benchmarks,
various SPEC members have stated that they tried to include more C++
benchmarks, but were defeated by a combination of lack of extant code,
and portability issues:

In article <3873F5AC.7EC7A18D@pac09.intel.com> (comp.arch, 5 Jan 2000),
"J. Reilly" <post1@pac09.intel.com> wrote
# There was a second candidate but C++ portability across compilers turned
# out to be a bigger issue that was expected.

Hopefully the widespread (well, apart from A Certain Large Vendor)
acceptance of the C++ standard will start improving portability.  But
we still have a long ways to go... especially in the numerical area,
where the standard is pretty weak.

An interesting question to ponder: what can we as a C++ community
learn from the Fortran community's long experience with portability
issues?

--
-- Jonathan Thornburg <jthorn@thp.univie.ac.at>
   http://www.thp.univie.ac.at/~jthorn/home.html
   Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
   "C++ is to programming as sex is to reproduction. Better ways might
    technically exist but they're not nearly as much fun." -- Nikolai Irgens

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hans Aberg wrote:
>
> In article <rjTv0vAh5AK6Ewnz@ntlworld.com>, Francis Glassborow
> <francisG@robinton.demon.co.uk> wrote:
...
> >Fortran continues to set targets that other languages aspire to, but
> >specifically in the field of computationally intense programming.
>
> Well, I have met some numerical specialists that used FORTRAN on
> supercomputers for performace reasons, but I was under the impression that
> the reason was not that they felt FORTRAN was a very alive language.

You might want to question them more closely. Fortran might be a dying
language (I certainly hope so), but it's a very long way from dead.
There are still people reciting the mantra "I don't know what THE
computer language of the next decade will look like, but it's name will
be Fortran". I'll grant you, they're insane :-) but they are saying it.

> Just because there are people using a language actively, perhaps
> dedicating their whole life to it, it does not mean that the language is
> alive. -- Latin is a very good example of this among human languages.

On the contrary, I can't think of a better definition of a living
language, than that there are people who use it for their everyday
lives. The corresponding definition of a living computer language
definitely applies to Fortran.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <200012010205.VAA14881@edg1.edg.com>,
  "J. Stephen Adamczyk" <jsa@edg.com> wrote:
> Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr writes
> > Francis Glassborow <francis.glassborow@ntlworld.com> writes:

> > | >Still, the thing that bothers me the most about the standard is
> > | >the feature they dropped from the ARM: true separate
> > | >compilation of templates.

> > | And that was because no one could actually figure out how to do
> > | it for real code rather than the small experimental (almost
> > | macro substitution) templates.

> > Wasn't CFront a proof of the concept?

> > | I am pretty certain that if any compiler implementor could
> > | figure out how to do it you would have it tomorrow.

> > Well, I'll put it as follows: no implementor provide export
> > because no one seems to care. Maybe it is because templates are
> > still being -- well I'm being a bit provocative -- used as toys:
> > effort is being much invested in syntax rather than in semantics.

> I have to respond to several items in this thread:

Generally, I would agree with most of Stephan's points...  One or two
small comments, however.

> 1) I know the statement was labeled as "provocative", but it's
> ridiculous to say that templates are only being used as toys.  There
> are many, many very large projects using templates in amazingly
> complex ways.  As baroque as they are, C++ templates provide
> something that you can't get in any other language out there, and
> people exploit that right up to the edge of the (significant)
> capabilities of current implementations.

To continue being provocative: in a certain way, large and toy are
orthogonal.  I don't see templates being used for much other than the
basic containers in commercial and industrial products.  Generally
speaking, they *are* recognized as something without a real equivalent
in other language.  But most commercial and industrial shops take a
rather wait and see attitude.  In French, I'd say "laisser quelqu'un
d'autre essuyer les pl   tres"; I can't think of a good English
equivalent, but the basic idea is that no matter how good an idea,
there will be problems with it when it is first used, and it is better
to let others find them out.  If by "toy", you mean playing around or
experimenting, then yes, most large applications which make extensive
use of templates are "toy".

    [...]
> Some day soon, you will be able to get compilers that support
> "export" on templates, and you will be able to decide for yourself
> whether you find it useful.

Just curious, but will it be real separate compilation, where I can
actually compile client code before the template implementation is
even written, or will it require that the template code be compiled
before the client code (as the standard reminds us in a note is
allowed).

--
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(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <xaj66l5b3ti.fsf@korrigan.inria.fr>,
  Gabriel Dos_Reis <gdosreis@korrigan.inria.fr> wrote:
> James.Kanze@dresdner-bank.com writes:

> [...]

> | I suppose I shouldn't complain too much.  Separate compilation of
> | templates is a difficult issue, and the C++ solution, for all its
> | warts, is better than the Java solution (which is the Java
> | solution for any difficult problem: remove language capabilities
> | until the problem goes away).  Still, it doesn't make life any
> | simpler.

> Certainly, C++ solution sort-of is better; but excusing implementors
> for not implementing export will bring us pretty much close to Java
> solution :-)

I'm not trying to excuse anybody, but the difference is more than just
sort-of better.  Consider the simple case of an expandable array
(std::vector).  In almost all cases of actual use, there is an
invariant concerning the types in the array: having the compiler
insist on this invariant is an enormous win, and even in the current
implementations, templates are several orders of magnitude easier than
<generic.h>.

I think the question is really: what role will templates have in C++
programming in the long term.  If it is only to define a few
ultra-stable containers and their iterators, the current model is
adequate.  The basic classes either come with the compiler, or are
bought in, and so are there before coding starts, and do not pose a
dependancy problem.  If templates are to find extensive use at the
application level, however, then export had better work exactly like
normal, non-templated classes normally do.

--
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(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A19F27C.BDDCAC6A@wizard.net>, James Kuyper
<kuyper@wizard.net> wrote:
>> Why ideally? Does it matter where the idea evolves or where the leadership
>> resides?
>
>Standardization is not supposed to be leadership. The main purpose of
>standardization is to provide guarantees. Innovation and guarantees are
>incompatible with each other. Leading edge technology is always
>unreliable; by the time it becomes reliable, it's not leading edge
>anymore, and that's precisely when it becomes appropriate to standardize
>it.

I think that the point that standardization is not leading edge a good
point: What I want to see with C++ is that it contains the tools I need in
order to develop my own ideas of OO & runtime models. I do not want to see
my ideas in those categories be a part of C++ itself, even though I think
everybody would be happy with whatever influence that would be picked up.
By the time a feature is a part of C++, it is probably not very
interesting from the point of view of leading edge technology.

But this does not mean that standardization is not supposed to be
leadership: In the past, a standardization of a programming language has
also been the first steps to the demise of that language. For this reason,
one has now revisions of the computer programming languages, to make them
survive somewhat longer, and this is what we discuss her in this thread.

A great deal of leadership will be needed in order to keep C++ alive in
the new revision. Again, it needs not to select leading edge technologies
for inclusion in the C++ standard, but it needs to take a good look at
leading edge technologies and see what basic techniques are needed there;
then those basic components should be included in the C++ standard.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Greg Comeau" <comeau@panix.com> wrote in message
news:8vh6up$gr5$1@panix3.panix.com...
> In article <zhPS5.1764$eU.110439@bgtnsc07-news.ops.worldnet.att.net>,
> Tony <tony@my.isp.net> wrote:
> >"Greg Comeau" <comeau@panix.com> wrote in message
> >news:8vet6f$d9k$1@panix3.panix.com...
> >> >Even though it's a contrived example, what if something like
> >> >C# completely obliterrated the need for complex standardization
> >> >(i.e. proved "built by committee" was an inferior way)?
> >>
> >> Since this is close to asking me why what if white was black,
> >> I find it impossible to answer and pointless to even ask.
> >
> >That's an interesting answer. Sounds like you'd prefer to bury your
> >head in the sand? (rhetorical).
>
> I have not answered your question because you have asked me
> a non-question.  Now you are giving _me_ flack for it.
> Ask me something real and I'll try the best I can.

No, it''s ok. Like I said, it was rhetorical.

> C# has not completely done anything yet, the least of which
> is negating committees in some way.  And I doubt it ever will.

I was just using it as an example. I could have used java too. The
fact that these things are continually appearing, to me says that
there's something still missing from C++. (Or something still needing
removal from the same).

> I hope for something better, but I don't see any great leaps
> of freedom or progress in C#'s tactics.

Nor do I.

> >> No one way is perfect.  Certainly the committee route isn't.
> >
> >But is it becoming obsolete though? I'm not suggesting it is
> >but rather just thinking aloud about it.
>
> I certainly hope other approaches can be taken when appropriate,
> but that's a FAR way from saying current ways are for ever more
> obsolete.

I didn't say that. I was just pondering its potential obsolescence and the
potential reasons for it.

> >> So, as I've said, a practical balance must be struck.
> >> And BTW, I say more power to C# if it can pull of whatever it might.
> >> It won't be the end of the world even if it turns out to be superior.
> >> So, in conclusion, all sides need all the help it can get.
> >> If you have some great insight into the process, then spew
> >> it forth.
> >
> >I'm more of a believer in cathedral rather than a bizar (when there's
> >someone good in the church that is). And I don't know the process.
> >
> >This is getting pretty abstract. Probably best to leave it here.
>
> That's an interesting answer. Sounds like you'd prefer to bury your
> head in the sand? (rhetorical).  Oops sorry, you said that.

No, not at all. I was just trying to save you from more of this "banter".
I've found that the tech groups like definitives more than abstractions.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

<James.Kanze@dresdner-bank.com> wrote in message
news:8vgeu2$h1k$1@nnrp1.deja.com...
> In article <3A19F27C.BDDCAC6A@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
> > Tony wrote:
>
> > Standardization is not supposed to be leadership. The main purpose
> > of standardization is to provide guarantees.  Innovation and
> > guarantees are incompatible with each other.  Leading edge
> > technology is always unreliable; by the time it becomes reliable,
> > it's not leading edge anymore, and that's precisely when it becomes
> > appropriate to standardize it.

The above is wrongly attributed to me. I didn't write the above.

> Concerning standardization, I would recommend reading
> http://java.sun.com/people/jag/StandardsPhases/index.html.  In
> particular:
> "For a standard to be usefully formed, the technology
> needs to be understood: technological interest needs to be waning.

I don't believe that.

> But
> if political interest in a standard becomes too large, the various
> parties have too much at stake in their own vested interest to be
> flexible enough to accommodate the unified view that a standard
>requires."

I do believe that.

> I don't know if there is a real solution.  Personally, I think that
> the STL wasn't ripe for the standard, and shouldn't have been
> included.

I agree.

>  But a C++ standard without *any* array class?  And if not
> the STL, then what?

Wait until technogical interest waned? It probably curbed development
of alternatives, stongly recommending it by virtue of its inclusion in the
standard. Too much emphasis on that 3rd development paradigm (generic
programming)? I think so, since the jury is still out on it. Serving wine
before its time? That happened didn't it.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Tony wrote:
>
> <James.Kanze@dresdner-bank.com> wrote in message
> news:8vgeu2$h1k$1@nnrp1.deja.com...
> > In article <3A19F27C.BDDCAC6A@wizard.net>,
> >   James Kuyper <kuyper@wizard.net> wrote:
> > > Tony wrote:
> >
> > > Standardization is not supposed to be leadership. The main purpose
> > > of standardization is to provide guarantees.  Innovation and
> > > guarantees are incompatible with each other.  Leading edge
> > > technology is always unreliable; by the time it becomes reliable,
> > > it's not leading edge anymore, and that's precisely when it becomes
> > > appropriate to standardize it.
>
> The above is wrongly attributed to me. I didn't write the above.

You're misreading the quotation syntax. Those lines are being attributed
to me, not to you; attributed lines are always indented by one level of
"> " from the attribution itself. The "Tony wrote:" line should not have
been retained once all of the lines attributed to you had been removed
(which occurred 2 messages back ); it's confusing, but not incorrect.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-2311002252410001@du161-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>But this does not mean that standardization is not supposed to be
>leadership: In the past, a standardization of a programming language has
>also been the first steps to the demise of that language. For this reason,
>one has now revisions of the computer programming languages, to make them
>survive somewhat longer, and this is what we discuss her in this thread.
>
Interesting:) When did COBOL and Fortran die? Both have been throught
the standardisation process several times. And, AFAIK, C is still alive,
well and prospering.

ISO Pascal and BASIC never really took hold but that did not mean the
languages died (look at Delphi, and VB)

I think your premise is false, when a language is standardised it
becomes less visible because real programmers are now using it to do
real work (TM)



Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

<James.Kanze@dresdner-bank.com> wrote in message
news:8vgfbo$hdh$1@nnrp1.deja.com...
> In article <IK1S5.2053$2s1.177966@bgtnsc06-news.ops.worldnet.att.net>,
>   "Tony" <tony@my.isp.net> wrote:
>
> > No, it just suggests that the popularity of C++ may be erroded by
> > things like java and C# e.g.  because the entities creating and
> > developing those kinds of things are proactive seekers.
>
> >From what I see, the problem is just the opposite.  Java's success is
> at least partially due to the perception that C++ wasn't stable; that
> the standards committee was innovating too much (being to proactive).

Yeah, you're right, in a way. There probably was too much quantity rather
than
quality focus. And to understand how I mean that, I mean that honing the
original
ARM version of C++ rather than introducing all those permeating concepts
(templates,
EH, others) I think would have been better.

(My trivial pet peave is "virtual void MyPureFunc()=0" rather than "pure
void MyPureFunc()".
Now THAT is ugly and enough to make people go to java. ;) )

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <4OZT5.7959$2s1.537538@bgtnsc06-news.ops.worldnet.att.net>,
  "Tony" <tony@my.isp.net> wrote:

> <James.Kanze@dresdner-bank.com> wrote in message
> news:8vgeu2$h1k$1@nnrp1.deja.com...

> > Concerning standardization, I would recommend reading
> > http://java.sun.com/people/jag/StandardsPhases/index.html.  In
> > particular:
> > "For a standard to be usefully formed, the technology
> > needs to be understood: technological interest needs to be waning.

> I don't believe that.

There's certainly a part of truth in it.  If you standardize before
the technology is understood, you risk to standardize errors.  And it
is very difficult to undo something once it has been standardized.

> > But
> > if political interest in a standard becomes too large, the various
> > parties have too much at stake in their own vested interest to be
> > flexible enough to accommodate the unified view that a standard
> >requires."

> I do believe that.

> > I don't know if there is a real solution.  Personally, I think
> > that the STL wasn't ripe for the standard, and shouldn't have been
> > included.

> I agree.

> >  But a C++ standard without *any* array class?  And if not
> > the STL, then what?

> Wait until technogical interest waned? It probably curbed
> development of alternatives, stongly recommending it by virtue of
> its inclusion in the standard. Too much emphasis on that 3rd
> development paradigm (generic programming)? I think so, since the
> jury is still out on it. Serving wine before its time? That happened
> didn't it.

That would have been my preference.  But it would mean that C++ would
have continued for at least five, maybe ten years longer without a
standard vector class.  Which has a number of other disadvantages.  In
the end, no matter what the committee did would be wrong by some
standard.  I wouldn't be too critical of the committee; they had a
very difficult job.

--
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(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <ZNZT5.7956$2s1.537538@bgtnsc06-news.ops.worldnet.att.net>,
Tony <tony@my.isp.net> wrote:
>"Greg Comeau" <comeau@panix.com> wrote in message
>news:8vh6up$gr5$1@panix3.panix.com...
>> In article <zhPS5.1764$eU.110439@bgtnsc07-news.ops.worldnet.att.net>,
>> Tony <tony@my.isp.net> wrote:
>> >"Greg Comeau" <comeau@panix.com> wrote in message
>> >news:8vet6f$d9k$1@panix3.panix.com...
>> >> >Even though it's a contrived example, what if something like
>> >> >C# completely obliterrated the need for complex standardization
>> >> >(i.e. proved "built by committee" was an inferior way)?
>> >>
>> C# has not completely done anything yet, the least of which
>> is negating committees in some way.  And I doubt it ever will.
>
>I was just using it as an example. I could have used java too. The
>fact that these things are continually appearing, to me says that
>there's something still missing from C++. (Or something still needing
>removal from the same).

I've always felt that somebody who says/feels that C++ is
perfect is either a fool, an idiot, or a con man, perhaps
all of them.  Given this, I think it's reasonable to say
that C++ is imperfect.  And I think that's just fine.
This is not to say I don't think there's room for additions
or removals, just that the language meets most of its goals.
It's also just fine to me that both competeing and non-competeing
languages "are continually appearing".  I would be alarmed
if they didn't.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <_NZT5.7957$2s1.536172@bgtnsc06-news.ops.worldnet.att.net>,
Tony <tony@my.isp.net> writes
>ARM version of C++ rather than introducing all those permeating concepts
>(templates,
>EH, others)

Which are both described in the ARM. You would be surprised by how
little was actually added to the language rather than honing what was
already there in the design.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article
<remove.haberg-2311002252410001@du161-226.ppp.su-anst.tninet.se>,
  remove.haberg@matematik.su.se (Hans Aberg) wrote:

> But this does not mean that standardization is not supposed to be
> leadership: In the past, a standardization of a programming language
> has also been the first steps to the demise of that language.

I've not been able to attest that.  Fortran and Cobol have been
standardized, and are still the predominant languages in many fields.
C seems to be holding its own as well.  And standardization may be the
only thing that saved Lisp from the 100's of Lisp-like dialects that
followed.

Pascal and Basic died because they got their standard too late, not
because they were standardized.

> For
> this reason, one has now revisions of the computer programming
> languages, to make them survive somewhat longer, and this is what we
> discuss her in this thread.

The ISO process requires an evaluation of *every* standard on a
periodic basis.  This is nothing new, and nothing to do with
programming languages.

> A great deal of leadership will be needed in order to keep C++ alive
> in the new revision. Again, it needs not to select leading edge
> technologies for inclusion in the C++ standard, but it needs to take
> a good look at leading edge technologies and see what basic
> techniques are needed there; then those basic components should be
> included in the C++ standard.

Typically, the first standard of a language enshrines existing
practice.  The later versions can be a little bit more daring, as long
as backward compatibility is maintained.

--
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(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8vu671$3at$1@nnrp1.deja.com>, James.Kanze@dresdner-bank.com
writes
>That would have been my preference.  But it would mean that C++ would
>have continued for at least five, maybe ten years longer without a
>standard vector class.  Which has a number of other disadvantages.  In
>the end, no matter what the committee did would be wrong by some
>standard.  I wouldn't be too critical of the committee; they had a
>very difficult job.

And we were already seeing a proliferation of home brewed solutions
causing potential portability problems.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

francis.glassborow@ntlworld.com (Francis Glassborow) wrote (abridged):
> And several months ago I offered to arrange a public archive of worked
> out proposals. There have been zero submissions so far.

Does this archive exist? How does one make submissions?


> If you seriously want new things in the next release of C++ it will
> be far too late to sit around until the Standards Committees start
> considering it (standards are supposed to be driven by existing
> practice) Get your ideas published and continually visible now. Get
> an implementor (even better get two) to support it as an extension.

Hmmm. I appreciate this work has to be done by someone, sometime. Still,
I would think it would be a good thing to keep track of less fully worked
out ideas. They might find a champion later, if they are not forgotten.

Here is an example. I think it would be nice if enums could be
forward-declared. The syntax and semantics would be analogous to that for
classes. Thus, currently:

    class MyClass;  // Forward declaration.

    void func1( MyClass c ); // OK.
    void func2( const MyClass &c ); // OK.
    typedef MyClass MyClass2;  // OK.

    // int s = sizeof MyClass; // Not OK.
    // struct S { MyClass c; }; // Not OK.
    // inline void func1( MyClass c ) {} // Not OK.
    // void func3() { MyClass c; } // Not OK.

Roughly, the first few lines are OK because they don't require the size
of the type to be known. The later ones are not OK because they do. I
propose:

    enum MyEnum;  // Forward declaration.

    void func1( MyEnum e ); // OK.
    void func2( const MyEnum &e ); // OK.
    typedef MyEnum MyEnum2;  // OK.

    // int s = sizeof MyEnum; // Not OK.
    // struct S { MyEnum e; }; // Not OK.
    // inline void func1( MyEnum e ) {} // Not OK.
    // void func3() { MyEnum e; } // Not OK.

The forward declaration would allow functions to be declared but not
defined or called, and you wouldn't be able to use sizeof or create
instances until the type was fully declared.

The advantage is better dependency management. It allows us to sometimes
avoid #including the header which fully declares the enum, which means we
can avoid some recompilations when that header changes. This is
especially important for large projects, when headers include many other
headers etc.

This would break no existing code. I don't believe there are any
fundamental problems with implementation, since partially-declared
classes are already part of the language. However, I don't have an
implementation myself. Nor am I likely to put very much more effort into
championing the idea than what I have put into this article.

Would this be sufficient to get a place in your archive? If not, perhaps
it should be. If it is sufficient, then perhaps the archive needs more
publicity. People may be discouraged from making proposals because they
think more work is required than actually is.

  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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Hans Aberg" <remove.haberg@matematik.su.se> wrote in message
news:remove.haberg-2311002252410001@du161-226.ppp.su-anst.tninet.se...
> In article <3A19F27C.BDDCAC6A@wizard.net>, James Kuyper
> <kuyper@wizard.net> wrote:
> >> Why ideally? Does it matter where the idea evolves or where the
leadership
> >> resides?
> >
> >Standardization is not supposed to be leadership.

No reason why it can't. You expressed it such that it would be bad if
it was. I would argue that, once a potential standard is apparent, the
leaders should
step up and do the standardization. Surely during that process, the
abstraction of
where the standard resides will evolve somewhat. In that respect,
standardization
SHOULD be leadership.

> The main purpose of
> >standardization is to provide guarantees. Innovation and guarantees are
> >incompatible with each other. Leading edge technology is always
> >unreliable; by the time it becomes reliable, it's not leading edge
> >anymore, and that's precisely when it becomes appropriate to standardize
> >it.
>
> I think that the point that standardization is not leading edge a good
> point:

"Leading edge" and "leadership" are different animals.

> What I want to see with C++ is that it contains the tools I need in
> order to develop my own ideas of OO & runtime models. I do not want to see
> my ideas in those categories be a part of C++ itself, even though I think
> everybody would be happy with whatever influence that would be picked up.

I agree. I don't want someone else drawing on my canvas before I begin to
paint.
(I feel exception handling is like that. I don't care that it's in there, I
just don't want
someone telling me I have to do it that way.).

> By the time a feature is a part of C++, it is probably not very
> interesting from the point of view of leading edge technology.

Personally, I don't find languages that interesting. Sometimes less is more
(less defined
paradigms = more freedom and creativity by the user to either create or
select).

> But this does not mean that standardization is not supposed to be
> leadership:

Thank you. :)

> In the past, a standardization of a programming language has
> also been the first steps to the demise of that language. For this reason,
> one has now revisions of the computer programming languages, to make them
> survive somewhat longer, and this is what we discuss her in this thread.

There's an interesting thread in the C std group where the real issue is
exactly this
and not really the feature proposal of that thread. It hinges on binary
(backward)
compatibility vs. langauge evolution.

> A great deal of leadership will be needed in order to keep C++ alive in
> the new revision.

Nope. Only marketing can save the new revision. When you don't have the best
of
breed product, you need expensive sales people.

> Again, it needs not to select leading edge technologies
> for inclusion in the C++ standard, but it needs to take a good look at
> leading edge technologies and see what basic techniques are needed there;
> then those basic components should be included in the C++ standard.

Or just solicite/gather those who already know and save on research
costs/time.
I'm not sure "standardization as leadership" is possible, I believe the
committee is
largely vendor influenced (I don't know that it is, I just believe that it
is). There's a
conflict of interests there in that case. I'm not sure just a user is well
represented.

Tony


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Greg Comeau" <comeau@panix.com> wrote in message
news:8vbleo$5ar$1@panix3.panix.com...
> In article <LK1S5.2055$2s1.177595@bgtnsc06-news.ops.worldnet.att.net>,
> Tony <tony@my.isp.net> wrote:
> >"James Kuyper" <kuyper@wizard.net> wrote in message
> >> The standard doesn't compete with proprietary solutions. If a
particular
> >> proprietary solution becomes widespread, it will be a strong candidate
> >> for inclusion (possibly with modifications) in the next release of the
> >> standard.
> >
> >Well if "wait and see" works for standards. I tend to think in terms of
> >products where you "just have to know" and take some level of risk.
>
> What you want to seek is some reasonable balance among
> the different ways.
>
> >> > ....If the expertise is external to the comittee, guess where
> >> > tomorrow's language of choice will come from?
> >>
> >> The language implementors, where it always has come from and always
will
> >> come from.
> >
> >And maybe not be a ANSI standard but rather a defacto standard?
>
> Compiler have always supported extensions.
> What's your point?


My point was that maybe leadership could come from the comittee side
occasionally, to
be picked up by industry rather than the other way around. Because "it" has
a general
overview (the big picture).  Even though it's a contrived example, what if
something
like C# completely obliterrated the need for complex standardization (i.e.
proved "built by committee"
was an inferior way)?

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <xyhS5.2778$2s1.224413@bgtnsc06-news.ops.worldnet.att.net>,
Tony <tony@my.isp.net> writes
>My point was that maybe leadership could come from the comittee side
>occasionally, to
>be picked up by industry rather than the other way around. Because "it" has
>a general
>overview (the big picture).  Even though it's a contrived example, what if
>something
>like C# completely obliterrated the need for complex standardization (i.e.
>proved "built by committee"
>was an inferior way)?

So who invented 'namespaces', new style casts, member templates etc...
Many people think the C++ Standards Committees are already too
inventive.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Tony wrote:
> "James Kuyper" <kuyper@wizard.net> wrote in message
> news:3A16BC9C.75034438@wizard.net...
...
> > The standard doesn't compete with proprietary solutions. If a particular
> > proprietary solution becomes widespread, it will be a strong candidate
> > for inclusion (possibly with modifications) in the next release of the
> > standard.
>
> Well if "wait and see" works for standards. I tend to think in terms of
> products where you
> "just have to know" and take some level of risk.

The standard is about removing risks, not about taking them on.
Implementors take risks; once they've proven that an idea works, that's
when it's time to standardize it.

...
> The language implementors, where it always has come from and always will
> come from.
>
> And maybe not be a ANSI standard but rather a defacto standard?

You've got some kind of idea that the ANSI/ISO standards are somehow
engaged in a competition with the vendors. That's not what it's about.
If a defacto standard arises, it will be entirely appropriate for the
next round of standardization to incorporate it into the next ISO
standard. There's no kind of race going on here to see who gets there
first. Standards are supposed to be far enough behind the leading edge
to be stable. A standard that rushes to incorporate a new idea
prematurely is violating the purpose of standardization.

>  Standardization is not the same as language creation (though
> > the standardization of C++ did involve rather more language creation
> > than is customary). Standardization is about defining a common ground
> > that everyone can count on. Innovation is (ideally) to be done by
> > implementors, not the committee.
>
> Why ideally? Does it matter where the idea evolves or where the leadership
> resides?

Standardization is not supposed to be leadership. The main purpose of
standardization is to provide guarantees. Innovation and guarantees are
incompatible with each other. Leading edge technology is always
unreliable; by the time it becomes reliable, it's not leading edge
anymore, and that's precisely when it becomes appropriate to standardize
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <xyhS5.2778$2s1.224413@bgtnsc06-news.ops.worldnet.att.net>,
Tony <tony@my.isp.net> wrote:
>"Greg Comeau" <comeau@panix.com> wrote in message
>news:8vbleo$5ar$1@panix3.panix.com...
>> In article <LK1S5.2055$2s1.177595@bgtnsc06-news.ops.worldnet.att.net>,
>> Tony <tony@my.isp.net> wrote:
>> >"James Kuyper" <kuyper@wizard.net> wrote in message
>> >> > ....If the expertise is external to the comittee, guess where
>> >> > tomorrow's language of choice will come from?
>> >>
>> >> The language implementors, where it always has come from and always
>> >> will come from.
>> >
>> >And maybe not be a ANSI standard but rather a defacto standard?
>>
>> Compiler have always supported extensions.
>> What's your point?
>
>My point was that maybe leadership could come from the comittee
>side occasionally, to be picked up by industry rather than the
>other way around.

I'm going to go on a limb and say I believe you are trolling,
since this flies exactly against a substantial amount of work
that the committee did in exactly that manner.

>Because "it" has a general overview (the big picture).

Perhaps.

>Even though it's a contrived example, what if something like
>C# completely obliterrated the need for complex standardization
>(i.e. proved "built by committee" was an inferior way)?

Since this is close to asking me why what if white was black,
I find it impossible to answer and pointless to even ask.

No one way is perfect.  Certainly the committee route isn't.
So, as I've said, a practical balance must be struck.
And BTW, I say more power to C# if it can pull of whatever it might.
It won't be the end of the world even if it turns out to be superior.
So, in conclusion, all sides need all the help it can get.
If you have some great insight into the process, then spew
it forth.

P.S.: Say, could you use shorter lines and/or tell your mailer
and/or tell your newsposter to do so.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <IK1S5.2053$2s1.177966@bgtnsc06-news.ops.worldnet.att.net>,
  "Tony" <tony@my.isp.net> wrote:

> No, it just suggests that the popularity of C++ may be erroded by
> things like java and C# e.g.  because the entities creating and
> developing those kinds of things are proactive seekers.

>From what I see, the problem is just the opposite.  Java's success is
at least partially due to the perception that C++ wasn't stable; that
the standards committee was innovating too much (being to proactive).
And I find more and more people souring on Java because it changes so
much from version to version.  "Write once, run anywhere" has become
"write once, run until the next version is released".

--
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(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A19F27C.BDDCAC6A@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> Tony wrote:

> Standardization is not supposed to be leadership. The main purpose
> of standardization is to provide guarantees.  Innovation and
> guarantees are incompatible with each other.  Leading edge
> technology is always unreliable; by the time it becomes reliable,
> it's not leading edge anymore, and that's precisely when it becomes
> appropriate to standardize it.

Concerning standardization, I would recommend reading
http://java.sun.com/people/jag/StandardsPhases/index.html.  In
particular: "For a standard to be usefully formed, the technology
needs to be understood: technological interest needs to be waning. But
if political interest in a standard becomes too large, the various
parties have too much at stake in their own vested interest to be
flexible enough to accommodate the unified view that a standard
requires."

This is a real problem for any language.  In the case of C++, for
example, we are (were?) hit at both ends: for many aspects, political
interest had already become too great (e.g. the deprecation of lossy
implicit conversions), for others (the STL comes to mind), the
technical interest hadn't waned.  I suspect that this is a problem for
any really complex language -- people will have a vested interest in
the status quo of some parts before the technology of other parts is
fully understood.

I don't know if there is a real solution.  Personally, I think that
the STL wasn't ripe for the standard, and shouldn't have been
included.  But a C++ standard without *any* array class?  And if not
the STL, then what?

--
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(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Greg Comeau" <comeau@panix.com> wrote in message
news:8vet6f$d9k$1@panix3.panix.com...
> In article <xyhS5.2778$2s1.224413@bgtnsc06-news.ops.worldnet.att.net>,
> Tony <tony@my.isp.net> wrote:
> >"Greg Comeau" <comeau@panix.com> wrote in message
> >news:8vbleo$5ar$1@panix3.panix.com...
> >> In article <LK1S5.2055$2s1.177595@bgtnsc06-news.ops.worldnet.att.net>,
> >> Tony <tony@my.isp.net> wrote:
> >> >"James Kuyper" <kuyper@wizard.net> wrote in message
> >> >> > ....If the expertise is external to the comittee, guess where
> >> >> > tomorrow's language of choice will come from?
> >> >>
> >> >> The language implementors, where it always has come from and always
> >> >> will come from.
> >> >
> >> >And maybe not be a ANSI standard but rather a defacto standard?
> >>
> >> Compiler have always supported extensions.
> >> What's your point?
> >
> >My point was that maybe leadership could come from the comittee
> >side occasionally, to be picked up by industry rather than the
> >other way around.
>
> I'm going to go on a limb and say I believe you are trolling,
> since this flies exactly against a substantial amount of work
> that the committee did in exactly that manner.
>
> >Because "it" has a general overview (the big picture).
>
> Perhaps.
>
> >Even though it's a contrived example, what if something like
> >C# completely obliterrated the need for complex standardization
> >(i.e. proved "built by committee" was an inferior way)?
>
> Since this is close to asking me why what if white was black,
> I find it impossible to answer and pointless to even ask.

That's an interesting answer. Sounds like you'd prefer to bury your
head in the sand? (rhetorical).

> No one way is perfect.  Certainly the committee route isn't.

But is it becoming obsolete though? I'm not suggesting it is but rather just
thinking aloud about it.

> So, as I've said, a practical balance must be struck.
> And BTW, I say more power to C# if it can pull of whatever it might.
> It won't be the end of the world even if it turns out to be superior.
> So, in conclusion, all sides need all the help it can get.
> If you have some great insight into the process, then spew
> it forth.

I'm more of a believer in cathedral rather than a bizar (when there's
someone
good in the church that is). And I don't know the process.

This is getting pretty abstract. Probably best to leave it here.

> P.S.: Say, could you use shorter lines and/or tell your mailer
> and/or tell your newsposter to do so.

A lot of times I've been letting the program wrap my lines. I'll start
putting
in the CR with the enter key then (I thought it was better the other way).

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <zhPS5.1764$eU.110439@bgtnsc07-news.ops.worldnet.att.net>,
Tony <tony@my.isp.net> wrote:
>"Greg Comeau" <comeau@panix.com> wrote in message
>news:8vet6f$d9k$1@panix3.panix.com...
>> >Even though it's a contrived example, what if something like
>> >C# completely obliterrated the need for complex standardization
>> >(i.e. proved "built by committee" was an inferior way)?
>>
>> Since this is close to asking me why what if white was black,
>> I find it impossible to answer and pointless to even ask.
>
>That's an interesting answer. Sounds like you'd prefer to bury your
>head in the sand? (rhetorical).

I have not answered your question because you have asked me
a non-question.  Now you are giving _me_ flack for it.
Ask me something real and I'll try the best I can.
C# has not completely done anything yet, the least of which
is negating committees in some way.  And I doubt it ever will.
I hope for something better, but I don't see any great leaps
of freedom or progress in C#'s tactics.

>> No one way is perfect.  Certainly the committee route isn't.
>
>But is it becoming obsolete though? I'm not suggesting it is
>but rather just thinking aloud about it.

I certainly hope other approaches can be taken when appropriate,
but that's a FAR way from saying current ways are for ever more
obsolete.

>> So, as I've said, a practical balance must be struck.
>> And BTW, I say more power to C# if it can pull of whatever it might.
>> It won't be the end of the world even if it turns out to be superior.
>> So, in conclusion, all sides need all the help it can get.
>> If you have some great insight into the process, then spew
>> it forth.
>
>I'm more of a believer in cathedral rather than a bizar (when there's
>someone good in the church that is). And I don't know the process.
>
>This is getting pretty abstract. Probably best to leave it here.

That's an interesting answer. Sounds like you'd prefer to bury your
head in the sand? (rhetorical).  Oops sorry, you said that.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

remove.haberg@matematik.su.se (Hans Aberg) writes:

|>  In article <z6f5yIA0oJD6Ewdh@ntlworld.com>, Francis Glassborow
|>  <francisG@robinton.demon.co.uk> wrote:
|>  >The resistance to adding the STL came from two main areas, those
|>  >who represented companies who had instructed their representatives
|>  >to oppose all changes, and those who personally believed that any
|>  >and all additions were to be resisted.

For personal reasons, I was not very active in the committee at the
time the STL was voted.  But I can easily imagine some very good reasons
for opposing it: adopting it meant either not doing it right, or
seriously delaying an already late standard (or both).  As anyone who
has developed software to deadlines can say, there comes a point where
you have to say no to improvements, no matter how good they are, and
just stabilize what you have.

With regards to the vote, I don't think it is really significant in that
sense.  As Francis no doubt knows, the real work of the committee takes
place in the working groups (in this case, the library working group),
and the goal for a full committee vote is consensus.  Presumably, any
opposition to the STL would have occurred in the library working
groups.  Ditto any compromizes, or decisions that it was not worth
continuing the opposition.

|>  >My memory is that the proposal to add the STL was accepted by a
|>  >very substantial majority at the meeting at which it was proposed
|>  >(no doubt someone can dig out the actual voting figures)

|>  I figure my memory refers (via some committee member expressing
|>  views) to those former groups you mention.

|>  The point I want to bring out though is that higher degrees of
|>  abstractions will be increasingly needed in all computer languages,
|>  because it saves programmers time. This need happen the way that a
|>  majority programmers use these abstractions directly, even though it
|>  may happen that a vast majority of programmers may benefit from it
|>  indirectly either by specializations of the abstractions (like an
|>  instantiation of a template library function), or using a library
|>  function using the abstractions (like using the string class which
|>  is STL derived, even though the user needs not knowing about
|>  templates), or something.

|>  By adding such a principle to the development of the C++ standard,
|>  one needs not be bothered by those groups you mention above as much
|>  as think happened at one point, even though the resistance finally
|>  was broken in the case of STL:

|>  For me, STL was right because it fell into that abstraction
|>  principle, and I think any other person accustomed working with
|>  abstractions would have made the same judgement.

The question remains as to whether it was the best abstraction, or even
a particularly good abstraction.  Independantly of the actual value of
STL, it was not subjected to the same scrutiny as most of the rest of
the standard.  Which leads to at least two problems:

  - It now seems, at least to me, apparent that there are at least two
    simple changes that would have increased its flexibility by an order
    of magnitude: using single iterators, instead of pairs, and passing
    functional objects by references.  In both cases, I don't think it
    to far off to speak of a design error in the STL.

    It's hard to say whether, given enough time, the committee would
    have noticed the problems.  And even if they had noticed them, there
    may have been other reasons preventing a change -- the C standard
    adopted gets fully aware of its problems.  But we'll never know,
    because the committee didn't have enough time. =20

    And I know, it's really an unsolvable problem.  The only way to
    really detect such design errors is for the library to be widely
    used.  And once it is widely used, compatibility problems lead to
    decisions like the one for gets.  I fully recognize that it is much
    easier for me to find the faults in the decision after the fact,
    than it is for the committee to make the decision.  I certainly
    DON'T consider this a criticism of the committee members.

  - The specification that the committee received was not of standards
    quality.  This is, in many ways, normal.  A single person, or a
    small group, cannot normally produce specifications of standards
    quality (one of the problems with the Java process, in fact).  This
    is why it takes so long for a standards committee to go from an
    initial specification like the ARM to a final standard.

    The result is that we still really don't know exactly what the STL
    is or should be in a number of cases.  And again, this is neither a
    criticism of Stepanov -- his specification is better than a lot one
    sees, nor of the committee, but of the process which lead to the STL
    being adopted without sufficient consideration or practical
    experience.

--=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(069)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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <863dgwgbii.fsf@gabi-soft.de>, kanze@gabi-soft.de wrote:
>|>  For me, STL was right because it fell into that abstraction
>|>  principle, and I think any other person accustomed working with
>|>  abstractions would have made the same judgement.
>
>The question remains as to whether it was the best abstraction, or even
>a particularly good abstraction.

Well, there are a lot of abstractioons, and none of them are perfect. The
example form math to quote the Grothendiecks stuff, which at the time used
different universes and such which now seem outdated.

>  Independantly of the actual value of
>STL, it was not subjected to the same scrutiny as most of the rest of
>the standard.

I think it is good it is there, because it gives the chance of providing
something better in the future. Also, C++ programmer now has some idea of
generic programming to an extent they would not have if STL would not have
been there.

>  Which leads to at least two problems:
>
>  - It now seems, at least to me, apparent that there are at least two
>    simple changes that would have increased its flexibility by an order
>    of magnitude: using single iterators, instead of pairs, and passing
>    functional objects by references.  In both cases, I don't think it
>    to far off to speak of a design error in the STL.

I think I can pick out some other problems. For example, if I use a
dynamic copy constructor clone(), then STL is bothersome the way it
initializes and copies elements. I just want my clone() be applied once by
the copy constructor of the container for each pointer it maintains.

On the other hand, I can write something quickly with the very useful
container classes, and not immediately bother about efficiency.

>    It's hard to say whether, given enough time, the committee would
>    have noticed the problems.  And even if they had noticed them, there
>    may have been other reasons preventing a change -- the C standard
>    adopted gets fully aware of its problems.

I think the timespace until the next revision is much better for detecting
such problems.

>    And I know, it's really an unsolvable problem.  The only way to
>    really detect such design errors is for the library to be widely
>    used.  And once it is widely used, compatibility problems lead to
>    decisions like the one for gets.  I fully recognize that it is much
>    easier for me to find the faults in the decision after the fact,
>    than it is for the committee to make the decision.

Right, this user feedback it the important factor in improving STL.

>  - The specification that the committee received was not of standards
>    quality.  This is, in many ways, normal.  A single person, or a
>    small group, cannot normally produce specifications of standards
>    quality (one of the problems with the Java process, in fact).
...
>    The result is that we still really don't know exactly what the STL
>    is or should be in a number of cases.

Well, I think the only way to figure that out is to that people try it out. So

>  And again, this is neither a
>    criticism of Stepanov -- his specification is better than a lot one
>    sees, nor of the committee, but of the process which lead to the STL
>    being adopted without sufficient consideration or practical
>    experience.

I don't think STL is that bad: The paradigm with semi-open interval is in
fact very good, not only because of C-compatibility, but an obvious
generalization in math is the use of ordinals, and then one always use
semi-open intervals.

The way around STL is to program a polymorhic variable, and then each
container needs only be implemented once. But often it is better to not
bother about that, and the STL comes in handy.

I think that a big asset with STL is it's relative simplicity. If one
wants do more complicated things, one build that on top of STL.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

> "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
> news:fvainJAsEcA6EwRW@ntlworld.com...
> > I am happy to act as the channel for such but it is not enough just to
> > have an idea, you have to consider how it will fit into the standard and
> > what impact it might have elsewhere.
>
 Personally, I think that if the comittee isn't proactive on "ideas" to
advance and evolve the standard into something better for the times, then I
believe the standard will die for favor of proprietary solutions. Many good
ideas are probably coming from users who don't have the intimate knowledge
of the issues and so aren't equipped to analyze, assess etc. an idea in
regards to incorporation into the standard. I think that's the comittee's
job by virtue of it's expertise to work on "ideas" (which are basically
charters). If the expertise is external to the comittee, guess where
tomorrow's language of choice will come from?

 Tony



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Tony wrote:
>
> > "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
> > news:fvainJAsEcA6EwRW@ntlworld.com...
> > > I am happy to act as the channel for such but it is not enough just to
> > > have an idea, you have to consider how it will fit into the standard and
> > > what impact it might have elsewhere.
> >
>  Personally, I think that if the comittee isn't proactive on "ideas" to
> advance and evolve the standard into something better for the times, then I
> believe the standard will die for favor of proprietary solutions. Many good

The standard doesn't compete with proprietary solutions. If a particular
proprietary solution becomes widespread, it will be a strong candidate
for inclusion (possibly with modifications) in the next release of the
standard.

> ideas are probably coming from users who don't have the intimate knowledge
> of the issues and so aren't equipped to analyze, assess etc. an idea in
> regards to incorporation into the standard. I think that's the comittee's
> job by virtue of it's expertise to work on "ideas" (which are basically
> charters). If the expertise is external to the comittee, guess where
> tomorrow's language of choice will come from?

The language implementors, where it always has come from and always will
come from. Standardization is not the same as language creation (though
the standardization of C++ did involve rather more language creation
than is customary). Standardization is about defining a common ground
that everyone can count on. Innovation is (ideally) to be done by
implementors, not the committee.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <9SfR5.13557$mq1.905951@bgtnsc04-news.ops.worldnet.att.net>,
Tony <tony@my.isp.net> writes
>> "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
>> news:fvainJAsEcA6EwRW@ntlworld.com...
>> > I am happy to act as the channel for such but it is not enough just to
>> > have an idea, you have to consider how it will fit into the standard and
>> > what impact it might have elsewhere.
>>
> Personally, I think that if the comittee isn't proactive on "ideas" to
>advance and evolve the standard into something better for the times, then I
>believe the standard will die for favor of proprietary solutions. Many good
>ideas are probably coming from users who don't have the intimate knowledge
>of the issues and so aren't equipped to analyze, assess etc. an idea in
>regards to incorporation into the standard. I think that's the comittee's
>job by virtue of it's expertise to work on "ideas" (which are basically
>charters). If the expertise is external to the comittee, guess where
>tomorrow's language of choice will come from?

Have you been around here long enough to know who is who? Such as which
respondents are, in fact, committee members?

BTW the only people who provide charters for the Committees are SC22 for
WG21 and what ever alphabet soup currently describes the parallel
organisation for ANSI vis a vis J16. Indeed, strictly speaking neither
committee can work on something just because they think it is a good
idea, though that grossly oversimplifies things.




Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <9SfR5.13557$mq1.905951@bgtnsc04-news.ops.worldnet.att.net>,
"Tony" <tony@my.isp.net> wrote:
>> > I am happy to act as the channel for such but it is not enough just to
>> > have an idea, you have to consider how it will fit into the standard and
>> > what impact it might have elsewhere.
>>
> Personally, I think that if the comittee isn't proactive on "ideas" to
>advance and evolve the standard into something better for the times, then I
>believe the standard will die for favor of proprietary solutions. Many good
>ideas are probably coming from users who don't have the intimate knowledge
>of the issues and so aren't equipped to analyze, assess etc. an idea in
>regards to incorporation into the standard. I think that's the comittee's
>job by virtue of it's expertise to work on "ideas" (which are basically
>charters). If the expertise is external to the comittee, guess where
>tomorrow's language of choice will come from?

Clearly, only those very familiar with the ideas of developing the C++
language can judge such things as how well a suggestion fits into the
standard.

I think though that the committee can help a lot, and thus relieving
itself from work-load in this respect, by publishing some general
principles on what one wants to see in the new C++ revision:

I think that one topic should be "completions" of the current C++: One
example of a completion is that one should be able to use C++ strings
without having to resort to C strings in some cases. One other question
that came up in this thread was STL improvements.

Another general topic could be to fill in the details needed for dynamic
programming. Here, support for a dynamic copy constructor, called clone(),
comes to my mind. Also a polymorphic function pointer. Support for various
types of garbage collectors falls into this category as well. STL needs
some improvements so that a dynamic clone() can be called directly for
containers maintaining pointers. Etc.

So by charting off some such general topics suitable for the new C++
revision, it would be much easier to figure out whether this or that
detailed feature fits into that picture.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <9SfR5.13557$mq1.905951@bgtnsc04-news.ops.worldnet.att.net>,
Tony <tony@my.isp.net> wrote:
>> "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
>> news:fvainJAsEcA6EwRW@ntlworld.com...
>> > I am happy to act as the channel for such but it is not enough just to
>> > have an idea, you have to consider how it will fit into the standard and
>> > what impact it might have elsewhere.
>>
> Personally, I think that if the comittee isn't proactive on "ideas" to
>advance and evolve the standard into something better for the times, then I
>believe the standard will die for favor of proprietary solutions. Many good
>ideas are probably coming from users who don't have the intimate knowledge
>of the issues and so aren't equipped to analyze, assess etc. an idea in
>regards to incorporation into the standard. I think that's the comittee's
>job by virtue of it's expertise to work on "ideas" (which are basically
>charters).

And that is one of the things that the committee does do.

>If the expertise is external to the comittee, guess where
>tomorrow's language of choice will come from?

This implies then that C++ in its current form could not exist,
because part of it came forth in that manner.  But that isn't
what happened.  So let's be careful in our doomsday statements :)

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:kvksHKAD$sF6EwfE@ntlworld.com...
> In article <9SfR5.13557$mq1.905951@bgtnsc04-news.ops.worldnet.att.net>,
> Tony <tony@my.isp.net> writes
> >> "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
> >> news:fvainJAsEcA6EwRW@ntlworld.com...
> >> > I am happy to act as the channel for such but it is not enough just
to
> >> > have an idea, you have to consider how it will fit into the standard
and
> >> > what impact it might have elsewhere.
> >>
> > Personally, I think that if the comittee isn't proactive on "ideas" to
> >advance and evolve the standard into something better for the times, then
I
> >believe the standard will die for favor of proprietary solutions. Many
good
> >ideas are probably coming from users who don't have the intimate
knowledge
> >of the issues and so aren't equipped to analyze, assess etc. an idea in
> >regards to incorporation into the standard. I think that's the comittee's
> >job by virtue of it's expertise to work on "ideas" (which are basically
> >charters). If the expertise is external to the comittee, guess where
> >tomorrow's language of choice will come from?
>
> Have you been around here long enough to know who is who? Such as which
> respondents are, in fact, committee members?

What's your point?

> BTW the only people who provide charters for the Committees are SC22 for
> WG21 and what ever alphabet soup currently describes the parallel
> organisation for ANSI vis a vis J16.

Well the idea's origination is at a higher level than the kind of charter
you are speaking of.
The idea is what all the gives ANSI, WG etc. purpose to do anything.

> Indeed, strictly speaking neither
> committee can work on something just because they think it is a good
> idea, though that grossly oversimplifies things.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Greg Comeau" <comeau@panix.com> wrote in message
news:8v7onq$ekn$1@panix3.panix.com...
> In article <9SfR5.13557$mq1.905951@bgtnsc04-news.ops.worldnet.att.net>,
> Tony <tony@my.isp.net> wrote:
> >> "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
> >> news:fvainJAsEcA6EwRW@ntlworld.com...
> >> > I am happy to act as the channel for such but it is not enough just
to
> >> > have an idea, you have to consider how it will fit into the standard
and
> >> > what impact it might have elsewhere.
> >>
> > Personally, I think that if the comittee isn't proactive on "ideas" to
> >advance and evolve the standard into something better for the times, then
I
> >believe the standard will die for favor of proprietary solutions. Many
good
> >ideas are probably coming from users who don't have the intimate
knowledge
> >of the issues and so aren't equipped to analyze, assess etc. an idea in
> >regards to incorporation into the standard. I think that's the comittee's
> >job by virtue of it's expertise to work on "ideas" (which are basically
> >charters).
>
> And that is one of the things that the committee does do.

Good then. Hopefully it (they) can recognize a good idea without getting too
caught up
in the formalities.

>
> >If the expertise is external to the comittee, guess where
> >tomorrow's language of choice will come from?
>
> This implies then that C++ in its current form could not exist,
> because part of it came forth in that manner.  But that isn't
> what happened.  So let's be careful in our doomsday statements :)

No, it just suggests that the popularity of C++ may be erroded by things
like java and C# e.g.
because the entities creating and developing those kinds of things are
proactive seekers.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"James Kuyper" <kuyper@wizard.net> wrote in message
news:3A16BC9C.75034438@wizard.net...
> Tony wrote:
> >
> > > "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in
message
> > > news:fvainJAsEcA6EwRW@ntlworld.com...
> > > > I am happy to act as the channel for such but it is not enough just
to
> > > > have an idea, you have to consider how it will fit into the standard
and
> > > > what impact it might have elsewhere.
> > >
> >  Personally, I think that if the comittee isn't proactive on "ideas" to
> > advance and evolve the standard into something better for the times,
then I
> > believe the standard will die for favor of proprietary solutions. Many
good
>
> The standard doesn't compete with proprietary solutions. If a particular
> proprietary solution becomes widespread, it will be a strong candidate
> for inclusion (possibly with modifications) in the next release of the
> standard.

Well if "wait and see" works for standards. I tend to think in terms of
products where you
"just have to know" and take some level of risk.

>
> > ideas are probably coming from users who don't have the intimate
knowledge
> > of the issues and so aren't equipped to analyze, assess etc. an idea in
> > regards to incorporation into the standard. I think that's the
comittee's
> > job by virtue of it's expertise to work on "ideas" (which are basically
> > charters). If the expertise is external to the comittee, guess where
> > tomorrow's language of choice will come from?
>
> The language implementors, where it always has come from and always will
> come from.

And maybe not be a ANSI standard but rather a defacto standard?

 Standardization is not the same as language creation (though
> the standardization of C++ did involve rather more language creation
> than is customary). Standardization is about defining a common ground
> that everyone can count on. Innovation is (ideally) to be done by
> implementors, not the committee.

Why ideally? Does it matter where the idea evolves or where the leadership
resides?

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <IK1S5.2053$2s1.177966@bgtnsc06-news.ops.worldnet.att.net>,
Tony <tony@my.isp.net> wrote:
>"Greg Comeau" <comeau@panix.com> wrote in message
>news:8v7onq$ekn$1@panix3.panix.com...
>> In article <9SfR5.13557$mq1.905951@bgtnsc04-news.ops.worldnet.att.net>,
>> Tony <tony@my.isp.net> wrote:
>> >> "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
>> >> news:fvainJAsEcA6EwRW@ntlworld.com...
>> >> > I am happy to act as the channel for such but it is not enough
>> >> > just to have an idea, you have to consider how it will fit into
>> >> > the standard and what impact it might have elsewhere.
>> >>
>> >Personally, I think that if the comittee isn't proactive on "ideas"
>> >to advance and evolve the standard into something better for the times,
>> >then I believe the standard will die for favor of proprietary solutions.
>> >Many good ideas are probably coming from users who don't have the
>> >intimate knowledge
>> >of the issues and so aren't equipped to analyze, assess etc. an idea in
>> >regards to incorporation into the standard. I think that's the comittee's
>> >job by virtue of it's expertise to work on "ideas" (which are basically
>> >charters).
>>
>> And that is one of the things that the committee does do.
>
>Good then. Hopefully it (they) can recognize a good idea without getting too
>caught up in the formalities.

Two remarks:
* Nothing is perfect.
* They have in the past.

>> >If the expertise is external to the comittee, guess where
>> >tomorrow's language of choice will come from?
>>
>> This implies then that C++ in its current form could not exist,
>> because part of it came forth in that manner.  But that isn't
>> what happened.  So let's be careful in our doomsday statements :)
>
>No, it just suggests that the popularity of C++ may be erroded by
>things like java and C# e.g. because the entities creating and
>developing those kinds of things are proactive seekers.

I have no idea how it suggests that, nor how the C++ committee
hasn't/isn't/won't be a proactive seeker.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <LK1S5.2055$2s1.177595@bgtnsc06-news.ops.worldnet.att.net>,
Tony <tony@my.isp.net> wrote:
>"James Kuyper" <kuyper@wizard.net> wrote in message
>> The standard doesn't compete with proprietary solutions. If a particular
>> proprietary solution becomes widespread, it will be a strong candidate
>> for inclusion (possibly with modifications) in the next release of the
>> standard.
>
>Well if "wait and see" works for standards. I tend to think in terms of
>products where you "just have to know" and take some level of risk.

What you want to seek is some reasonable balance among
the different ways.

>> > ....If the expertise is external to the comittee, guess where
>> > tomorrow's language of choice will come from?
>>
>> The language implementors, where it always has come from and always will
>> come from.
>
>And maybe not be a ANSI standard but rather a defacto standard?

Compiler have always supported extensions.
What's your point?

> Standardization is not the same as language creation (though
>> the standardization of C++ did involve rather more language creation
>> than is customary). Standardization is about defining a common ground
>> that everyone can count on. Innovation is (ideally) to be done by
>> implementors, not the committee.
>
>Why ideally? Does it matter where the idea evolves or where the leadership
>resides?

Sometimes it does.  As above, I think you need some practical
balance.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Greg Comeau" <comeau@panix.com> wrote in message
news:8vbl46$4qn$1@panix3.panix.com...
> In article <IK1S5.2053$2s1.177966@bgtnsc06-news.ops.worldnet.att.net>,
> Tony <tony@my.isp.net> wrote:
> >> >If the expertise is external to the comittee, guess where
> >> >tomorrow's language of choice will come from?
> >>
> >> This implies then that C++ in its current form could not exist,
> >> because part of it came forth in that manner.  But that isn't
> >> what happened.  So let's be careful in our doomsday statements :)
> >
> >No, it just suggests that the popularity of C++ may be erroded by
> >things like java and C# e.g. because the entities creating and
> >developing those kinds of things are proactive seekers.
>
> I have no idea how it suggests that, nor how the C++ committee
> hasn't/isn't/won't be a proactive seeker.

Well, I originally posted because someone was regurgitating that often heard
motto
in the standards groups when someone _just_ mentions a feature/idea, and I
was
wondering if that really indicated a deaf ear to anything but formalized
communications
via a standard proposal in standard format. That "motto" seems to be: "The
format and
process for submitting proposals to ANSI/ISO is blah, blah, blah...". Now if
the same
scenario were applied to a product, the vendor would be more likely to be
quite a bit
more wide-eyed about considering "just" an idea/feature without asking the
proposer to
develop the idea/feature.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Matthew Austern wrote:
>
> James Kuyper <kuyper@wizard.net> writes:
>
> > > But first things first. First finishing off the details in the current
> > > C++, and then let the new discussions come along. But startng in 1993
> >
> > The details are as finished as they'll ever be. If you think there's a
> > defect, you can file a report, but if you think it's merely missing
> > something it should have there's nothing more to be done until it's time
> > to start work on the next release.
>
> I wouldn't quite say that.  If you think something is missing, you
> should write up, in as much detail as possible, exactly what is
> missing, what would have to be changed in the standard to provide it,
> who would benefit from having it added, what would be required to
> implement it, and how it would affect the rest of the language/
> library.  Working code would be especially nice.
>
> Eventually the committee will consider new language/library features.
> (Probably it will consider new library features before it considers
> core language changes.)  We will be biased against incomplete
> proposals, and we will be biased in favor of proposals with prior art.

You're right, of course; there's lots of work that can be done in
preparation for making a proposal for the next release. I merely meant
that the current standard is closed, except for defect fixes. A missing
feature is a defect only if it's a necessary feature.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-1011002040530001@du141-226.ppp.su-anst.tninet.se>,
Hans Aberg <remove.haberg@matematik.su.se> wrote:
>Well, returning the original question, I do not think that it is necessary
>for a feature to somehow been implemented in a C++ compiler before it
>should be taken up as a suggestion for inclusion in the C++ standard:
>
>A lot of people out there have good ideas, and it would be bad to nip that
>input in the bud.

Nobody in the thread say it MUST be implemented first.
Just that if it is, it's probably a step forward for a few
reasons.

>However, before it can be accepted for inclusion in the C++ standard, it
>must surely have been implemented in some C++ compiler, tested and
>evaluated, because otherwise it can be difficult to understand the value
>of having that feature included in a C++ compiler.

As above, it's probably a very good idea, but certainly is
not a requirement.

>In addition, I do not see that the person come up with suggestion needs to
>be the included the group of people implementing, testing and evaluating
>the feature in C++ compilers:

Yet again, it's not a requirement.  BTW, the committee is not
made up of just people who write compilers (or standard libs).

>..But the problems of finding a good way to introduce this on the C++
>standard are enormous, due to the extremely technical nature of CGC's. In
>addition, when CGC's are introduced into the C++ standard, one must
>balance off the particular use I want against other uses. This will
>require dedicated experts on GC's.

Indeed.

>It is quite clear to me that unless dedicated GC experts are doing this
>stuff, suggestions as mine on the CGC issue will have no chance of finding
>their way into the C++ standard.

Maybe, maybe not.

>So let's keep things separate, and let people give the input they can do.

Perhaps.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-0311002122250001@du134-226.ppp.su-anst.tninet.se>,
Hans Aberg <remove.haberg@matematik.su.se> wrote:
>So what I am saying, the principles you use to develop the C++ standard
>did not (and still does not) admit you to add STL or templates to C++:
>Basically, you pragmatically decided to close your eyes in front of those
>flawed C++ principles and add it because you had a hunch it was right.

This trivializes things and so then is a mischaracterization IMO.
That said, certainly the committee wandered further and produced
various extensions vs say what the C committee did (at least for C89).
But that doesn't mean that it violated its principles.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <z6f5yIA0oJD6Ewdh@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>The resistance to adding the STL came from two main areas, those who
>represented companies who had instructed their representatives to oppose
>all changes, and those who personally believed that any and all
>additions were to be resisted. My memory is that the proposal to add the
>STL was accepted by a very substantial majority at the meeting at which
>it was proposed (no doubt someone can dig out the actual voting figures)

I figure my memory refers (via some committee member expressing views) to
those former groups you mention.

The point I want to bring out though is that higher degrees of
abstractions will be increasingly needed in all computer languages,
because it saves programmers time. This need happen the way that a
majority programmers use these abstractions directly, even though it may
happen that a vast majority of programmers may benefit from it indirectly
either by specializations of the abstractions (like an instantiation of a
template library function), or using a library function using the
abstractions (like using the string class which is STL derived, even
though the user needs not knowing about templates), or something.

By adding such a principle to the development of the C++ standard, one
needs not be bothered by those groups you mention above as much as think
happened at one point, even though the resistance finally was broken in
the case of STL:

For me, STL was right because it fell into that abstraction principle, and
I think any other person accustomed working with abstractions would have
made the same judgement.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <bcQTLnBHbfA6EwC4@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>In article <remove.haberg-0211002205420001@du141-226.ppp.su-
>anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>>I understand that the templates and STL combined was such a topic that
>>received hard resistance at the time, but which I myself when I first saw
>>it, as pure mathematician, immediately recognized as the first small step
>>towards greater generality.
>
>There was never any question in the minds of those working on the
>Standard that the STL needed to be part of it even though it meant a
>great deal of added work relatively late in the process. I think your
>sources of information about the Standardisation process are deeply
>flawed.

I got my information from another member of the committee, but I do not
remember whom. -- Perhaps different members felt different about it.

>>The underlying principle in this case, as I see it, is that the templates
>>codifies existing practises, but finds a more general umbrella under which
>>to do it, generic programming.
>
>Well that is a view, but not, I think, how we saw it.

I did claim this was your view, but I provide a principle that might be
used to explain it, which in its turn can be used for future, more
systematic extensions of C++. :-)

>>The C++ standardization process had problems to cope with that, the way I
>>interpret it, because it requires each added feature to be of general use.
>
>We never had the slightest problem with regards to the STL, those
>working on the C++ Library could be characterised as falling on it with
>delight because it demonstrated how C++ libraries might be written and
>generally developed.

What vaguely recall, the resistance clearly did not come from those that
worked on it and understood it, but from others.

>>But in the case of templates and STL, what matters is not how many uses
>>generic programming itself, but how many that uses specializations of it,
>>that is, pretty much everyone.
>
>I disagree.

You seem to say that a programmer using say std::string must also know
about template programming (and not merely learn how to use a library
based on templates), whereas I say that is not so. Using computer lingo, I
say STL has an implementation using template programming, whereas the
interface, even though it uses templates, does not really use template
_programming_, and as such the users are not forced into template
programming.

> The STL introduced a fundamental programming paradigm that
>>greatly extended programmers view of how the language could be used.

What I say is that if this was the reason you introduced it, STL should
not have been added to C++ according to the principles used for developing
the standard, because (or so I was told) a majority of the users must use
the feature for it to be added to the standard:

I recall I had a discussion where I suggested to add a numeric
multi-precision library to C++, and the fellow replied as there seemed to
not be feature to be used by a majority of programmers, it should not be
added to C++. (And of course Java has such a library...)

So what I am saying, the principles you use to develop the C++ standard
did not (and still does not) admit you to add STL or templates to C++:
Basically, you pragmatically decided to close your eyes in front of those
flawed C++ principles and add it because you had a hunch it was right.

I try to tell you, hey there is a principle explaining why that adding of
STL was right: It is not how many who use the generalities that counts,
but how many indirectly benefits form specializations of it.

Otherwise, while you were working on it, it must have been felt as
fundamentally bringing in new concepts to programmers, even though from
the generalities that is known in mathematics, it is a fairly small step
on that road.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-0311002122340001@du134-226.ppp.su-anst.tninet.se>,
Hans Aberg <remove.haberg@matematik.su.se> wrote:
>In article <8tt6bc$ibl$1@panix3.panix.com>, comeau@comeaucomputing.com wrote:
>>Hans Aberg <remove.haberg@matematik.su.se> wrote:
>>>You know, I have already given up the hope of seeing C++ show up with the
>>>feature I need, so I decided to write my own language. You and others out
>>>there are encouraged to do likewise.
>>
>>That may be acceptable for the particular programming universe
>>you live in, but in general, the problem with the above suggestion
>>is that it prescribes a solution that will suffer the same problem
>>it suggests to solve.
>
>Actually, it is not that difficult creating your own language:

I've been writing languages since 1979 or so, so I'm well aware of
what's what.  And some are easy and some are not.  I can't imagine
anybody disagreeing with this.

>Use tools
>such as Bison and Flex to output say C++ files. If you make sure your own
>language allows the inclusion of C++ code, you can do everything you can
>do in C++ plus your own stuff.

Oh yeah.  And it only takes about 15 minutes of work to do.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A07B94E.A02045DA@lucent.com>, Michiel Salters
<salters@lucent.com> wrote:
>>... given a runtime
>> string which has been encoded as if a C-string with \ escapes, translate
>> it onto a regular C or C++ string. -- In C this could nearly be done by
>> sprintf()
>
>I think you're trying to achieve things without practical value. The \n
>form is for the compiler. Your program will contain the OS-dependant string,
>and that's the only one it needs to handle.
>
>If you need the "\\n" two-character string for e.g. a C++ tutorial written in
>C++, a simple solution is map<char,string> escapes; escapes['\n']="\\n"; etc.
>I don't think we need anything shorter for that in the standard.

It shows up if one writes programs that outputs C/C++ code (say when using
Flex/Bison or otherwise). Then, clearly, the issue is not how to write
such stuff, if doing it by hand, but rather, whathever C/C++ uses as
standard of encoding strings (or perhaps some other commnly used feature),
I will able to use it without having to dig into the details of C/C++
encodings.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <vtXN5.14$lh.87@burlma1-snr2>, Barry Margolin
<barmar@genuity.net> wrote:
>>>... given a runtime
>>> string which has been encoded as if a C-string with \ escapes, translate
>>> it onto a regular C or C++ string. -- In C this could nearly be done by
>>> sprintf()
>>
>>I think you're trying to achieve things without practical value. The \n
>>form is for the compiler. Your program will contain the OS-dependant string,
>>and that's the only one it needs to handle.
>
>What if you're writing a program whose job is to process files that can
>contain escape sequences (perhaps an interpreter for a miniature language)?
>You'll read a line from the file into a string, and then you would like to
>go through that string, replacing \ escapes with the appropriate
>OS-dependent characters?

This issue is different from the one I was asking for: You discuss OS
dependant string encodings conversion, and I see no way a C++ standard
could support such. (If you want a library doing it for UNIX, perhaps
http://www.gnu.org has it.)

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8tvs8a$jcs$1@panix3.panix.com>, comeau@comeaucomputing.com wrote:
>>Actually, it is not that difficult creating your own language:
>
>I've been writing languages since 1979 or so, so I'm well aware of
>what's what.  And some are easy and some are not.  I can't imagine
>anybody disagreeing with this.
>
>>Use tools
>>such as Bison and Flex to output say C++ files. If you make sure your own
>>language allows the inclusion of C++ code, you can do everything you can
>>do in C++ plus your own stuff.
>
>Oh yeah.  And it only takes about 15 minutes of work to do.

Actually, I am writing on a tool, a formatter, which will make it possible
for one to do it in 15 minutes, once one have learned how Bison/Flex
works: The idea is that one defines a series of formatted macros with
variables, typically put in a file, and then via Bison produces a suitable
lookup table. The formatter then produces the C++ output files.

The thing is that many things are implementable in C++, but not really for
practical use, because it involves too much tedious and exact writing:

One example is the polymorphic copy operator called clone. In every class
derived form the root class Root (called "Object" in Java), I must put
  class A : virtual public Root {
  public:
      Root* clone() const   // Virtual copy constructor
      {   return new A(*this);   }
  };
and there seems to be no way of simplify this in C++.

And if one want to have Java classes, it is possible to implement this is
C++ by nested classes
  class A : public virtual Class {
  ...
    class Object {  // Actual Java style class named "A"
    ...
    };
  };
  // plus other stuff, like global class object, method look-up by name.

For such uses, the approach with Bison/Flex is suitable: It is not really
possible to expect that a writer of C++ should be able to write all this
stuff by hand for each class. So one can write a special language that
just implements this.

And for the C++ standard, I figure the approach would be really helpful,
because it becomes easy to evaluate the feature -- just look at the
output. (I ended up on this approach, because I work on a runtime model,
and needed it in order to better output consistent C++ code, while on the
same time being able to implement more complicated things. -- So, really,
I'm not doing it as a replacement of C++. :-) )

But this does not help some features, which are not really implementable
into C++ without language extensions.

One such question is the CGC (conservative garbage collector question).
Others are thread-safe implementations, support for locks and atomic
treatment of code segment (thread cannot stop in the middle of it). In
addition support for distributed programming, but that is perhaps possible
via library.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <p6qofzq9nt6.fsf@informatik.hu-berlin.de>, Martin von Loewis
<loewis@informatik.hu-berlin.de> wrote:
>> Very difficult to do unless one writes a C++ compiler, or works for
>> a company that produces a C++ compiler. I believe there are people
>> outside these categories who may still have good ideas regrading C++
>> language improvements.
>
>Yes, but they still need to defend against the claim that their
>proposal is unimplementable, or that implementing it would have
>undesirable side-effects on existing applications. What good is a
>language feature that nobody will implement?

Well, returning the original question, I do not think that it is necessary
for a feature to somehow been implemented in a C++ compiler before it
should be taken up as a suggestion for inclusion in the C++ standard:

A lot of people out there have good ideas, and it would be bad to nip that
input in the bud.

However, before it can be accepted for inclusion in the C++ standard, it
must surely have been implemented in some C++ compiler, tested and
evaluated, because otherwise it can be difficult to understand the value
of having that feature included in a C++ compiler.

In addition, I do not see that the person come up with suggestion needs to
be the included the group of people implementing, testing and evaluating
the feature in C++ compilers:

It is not difficult for me to single out a feature, where I can provide
input on suggestions of what I want, but where I could not participate in
the implementing, testing and evaluation in C++ compilers, namely the CGC
(conservative garbage collector) question:

I know that I want to be able implement a CGC with respect to a hierarchy,
as users of the runtime system the compiler can create circular structures
which otherwise cannot be removed. And for that I need a way to find the
root system, and a way to trace the pointers leading to objects in this
hierarchy.

But the problems of finding a good way to introduce this on the C++
standard are enormous, due to the extremely technical nature of CGC's. In
addition, when CGC's are introduced into the C++ standard, one must
balance off the particular use I want against other uses. This will
require dedicated experts on GC's.

It is quite clear to me that unless dedicated GC experts are doing this
stuff, suggestions as mine on the CGC issue will have no chance of finding
their way into the C++ standard.

So let's keep things separate, and let people give the input they can do.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-1011002040530001@du141-226.ppp.su-anst.tninet.se>,
Hans Aberg <remove.haberg@matematik.su.se> wrote:
>Well, returning the original question, I do not think that it is necessary
>for a feature to somehow been implemented in a C++ compiler before it
>should be taken up as a suggestion for inclusion in the C++ standard:

The person who mentioned providing an implementation said:

> Getting a proposal implemented and in use by real programmers
> is an excellent way of addressing these concerns.

Nothing about it being "necessary".  Just very helpful.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-0311002122250001@du134-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>So what I am saying, the principles you use to develop the C++ standard
>did not (and still does not) admit you to add STL or templates to C++:
>Basically, you pragmatically decided to close your eyes in front of those
>flawed C++ principles and add it because you had a hunch it was right.

1) The STL had been developed and tested for a substantial time
2) Almost every major compiler shipped with library extensions that
provided containers in some way or other.

Those two features placed the STL very firmly in the domain of things
that could/should be added to the Standard. Indeed there was more
justification for adding the STL than there was for complex numbers.

The resistance to adding the STL came from two main areas, those who
represented companies who had instructed their representatives to oppose
all changes, and those who personally believed that any and all
additions were to be resisted. My memory is that the proposal to add the
STL was accepted by a very substantial majority at the meeting at which
it was proposed (no doubt someone can dig out the actual voting figures)



Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hans Aberg wrote:

[ on missing features ]

>... given a runtime
> string which has been encoded as if a C-string with \ escapes, translate
> it onto a regular C or C++ string. -- In C this could nearly be done by
> sprintf()

I think you're trying to achieve things without practical value. The \n
form is for the compiler. Your program will contain the OS-dependant string,
and that's the only one it needs to handle.

If you need the "\\n" two-character string for e.g. a C++ tutorial written in
C++, a simple solution is map<char,string> escapes; escapes['\n']="\\n"; etc.
I don't think we need anything shorter for that in the standard.

--
Michiel Salters
Michiel.Salters@cmg.nl
salters@lucent.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A07B94E.A02045DA@lucent.com>,
Michiel Salters  <salters@lucent.com> wrote:
>Hans Aberg wrote:
>
>[ on missing features ]
>
>>... given a runtime
>> string which has been encoded as if a C-string with \ escapes, translate
>> it onto a regular C or C++ string. -- In C this could nearly be done by
>> sprintf()
>
>I think you're trying to achieve things without practical value. The \n
>form is for the compiler. Your program will contain the OS-dependant string,
>and that's the only one it needs to handle.

What if you're writing a program whose job is to process files that can
contain escape sequences (perhaps an interpreter for a miniature language)?
You'll read a line from the file into a string, and then you would like to
go through that string, replacing \ escapes with the appropriate
OS-dependent characters?

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Barry Margolin wrote:

> What if you're writing a program whose job is to process files that can
> contain escape sequences (perhaps an interpreter for a miniature language)?
> You'll read a line from the file into a string, and then you would like to
> go through that string, replacing \ escapes with the appropriate
> OS-dependent characters?

(Followup to clc++m - this getting off-topic)
You would have to read the file through a simple filtering streambuf,
which does the translation on each read of a '\'. You would need to read
another character and 'switch' on it:

if ( (read_char = get_next_char() ) =='\')
switch (get_next_char()) {
 case 'n' : read_char = '\n'; break;
 case 't' : read_char = '\t'; break;
 ...
}

Note that '\n ' is the C representation of the OS-dependant characters.

--
Michiel Salters
Michiel.Salters@cmg.nl
salters@lucent.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Edward Diener <eddielee@abraxis.com> writes:

> Very difficult to do unless one writes a C++ compiler, or works for
> a company that produces a C++ compiler. I believe there are people
> outside these categories who may still have good ideas regrading C++
> language improvements.

Yes, but they still need to defend against the claim that their
proposal is unimplementable, or that implementing it would have
undesirable side-effects on existing applications. What good is a
language feature that nobody will implement?

Regards,
Martin

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Edward Diener <eddielee@abraxis.com> writes:

> What I was alarmed by was the suggestion that I had to promote my
> idea in various ways to get any serious consideration from the
> Standards committee.

One of the suggested ways to promote it was to come up with a
reference implementation. I think that is not asked too much: Even
though your proposal may be consistent in itself, it may be very
difficult to implement, and nobody but you may be interested in the
feature.

So if the people in the standards committee are not convinced that it
is even implementable, it would be very reasonable to reject the
proposal, IMO.

> But I don't think that I or anyone should needs to play politics or
> cozy up to some committee member in order to get one's proposal
> seriously considered.

No, I trust the committee that proposals are evaluated based on their
own merits. However, part of that is: Is there prior art in
implementing the proposal? Is there any demonstrated need for the
feature being proposed? The wording alone is but a part of the proposal.

> I think very highly of the work done by the C++ standards committee
> but the proposal of changes to the C++ standard for the next
> revision should be open to everyone on an equal basis.

When it comes to voting, then ISO (as a UNO suborganization) has
specific procedures which won't be changed. If you want to participate
in voting, you should contact your national standards body.

Regards,
Martin

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A016BFE.50AC64EF@abraxis.com>,
Edward Diener  <eddielee@abraxis.com> wrote:
>I for one will be very disappointed if there is not a specific path set out for
>individuals to submit new ideas and worked out proposals for the next C++
>release to the Standards Committees.

What precisely could that plan possibly be?

>I don't believe that the individuals
>should have to promote and politic those proposals as you suggest, but instead
>hope that the proposal will be accepted or not accepted on the basis of its own
>merit.

A bit of both, and then some, needs to occur.

>Your suggestion otherwise is very dismaying, but perhaps the "it will be
>far too late" clause is purely your own belief and does not reflect the reality
>of the process. If the C++ language turns into a foray of promoted ideas rather
>than an attempt to make improvements to the language based on merit, I believe
>many others will feel the same way that I do in this matter.

It's exactly not dismaying.  Unless a proposal is as simple as
a missing semicolon in the grammar, an iterative feedback
cycle is necessarily.  The iteration then needs to occur
in the "invention" stage or in real implementations, and often
in both.  That takes time.  And that's how it reaches "its own merit".
If it doesn't take time, then it won't have merit, and so it will be
too late.

IOWs, proposal are rarely able to be perfect when first
presented.  Furthermore, their implications are rarely
fully understood.  This hence begs promotion et al.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote in message ...

>Change your view. The Standard provides a common base that should be
>supported by all implementations. Implementations are free to add
>extensions (some of us would even encourage them to do so). If the idea
>is good, why should it wait.

Note the contradiction in this schema. As soon as extensions are added, the
compiler turns non standard-compliant. So it will no longer compile all the
standard-compliant code immigrating. Also, everyone chosing to use the
extensions junps into a vendor lock-in. Also, if several compiler makers
decide to provide the same extension, they will not necessarily implement it
in the same way. I even see tendencies to specifically create all the
extensions as incompatible as possible, to force force that vendor lock-in.
(Anyone bothered with porting code between compilers probably noticed it was
much easies to port domething from a dos to unix, than between borland and
ms comilers on the same dos16 platform. That is something bad.)

The standard is there just to prevent the separation, and create a solid
base for portability.

Paul


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <fvainJAsEcA6EwRW@ntlworld.com>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>In article <8ts5qh$109i$1@news.hal-pc.org>, Greg Brewer
><nospam.greg@brewer.net> writes
>>So if you aren't willing to put the time, energy, and money into promoting
>>your idea, why should someone else.  Personally, I wish someone would
>>collect ideas grade them for ease of implementation and likely hood to break
>>existing code, then let the programmers vote on it.  Actually, egroups.com
>>provides software that could do the job.  Wouldn't it be great if someone
>>did it?  Of course, I think almost everyone is like me -- not enough time.
>
>ACCU is quite willing to host an area in which proposals (with adequate
>documentation) can be placed. Actually I am keen for this to happen so
>that good ideas are not lost, or insufficiently developed to be
>considered at Committee level.
>
>I am happy to act as the channel for such but it is not enough just to
>have an idea, you have to consider how it will fit into the standard and
>what impact it might have elsewhere.
>
>If properly approached I am sure the editor of Overload would be happy
>to provide exposure for well presented cases for change or extensions to
>C++. email him merrells@netscape.com

I'd be happy to provide some Comeau web resources to such an
endeavor as necessary/appropriate.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A01E1B0.6EEB208E@abraxis.com>,
Edward Diener  <eddielee@abraxis.com> wrote:
>My understanding of the next C++ revision circa 2002 is that it will be
>open to consideration of new ideas from anyone, and I hope I am not wrong
>in this.

That still needs to be decided.  However, there is no indication that
you are wrong and every indication that it will be the case.
In fact, at least week's meeting there was formal support for
considering a new work item for the library in the form of a technical
report, and I would not be surprised if similar action does not
occur for the language itself in the next meeting or the one after that.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <fvainJAsEcA6EwRW@ntlworld.com>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
>
> If properly approached I am sure the editor of Overload would be happy
> to provide exposure for well presented cases for change or extensions
to
> C++. email him merrells@netscape.com

Or better yet at Merrells@etimecapital.com - :)

--
Alan Griffiths                        http://www.octopull.demon.co.uk/
Senior Systems Consultant, Experian   tel: +44 115 968 5118
Chair, Association of C and C++ Users http://accu.org/


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Edward Diener wrote:
>
>  The issue to me is that there must be a specified way
> by which anyone with a serious idea for a change to C++ can present it to the
> Standards committee at the appropriate time when the next revision of C++ is
> considered, which I believe is circa 2002.

There are a variety of ways, none of them particularly formal. Other
responses in this thread have listed several.

> I just
> hate the idea that I would have to somehow get into some personal politicking just
> to have my idea considered. That smacks of an authoritarianism and an elitism which
> I personally despise.

The ANSI standardization process is open. Anyone can join the J16 committee.
The FAQ for this newsgroup (see below) has the details.  See also
Stroustrup's "Design and Evolution of C++" chapter 6 for a discussion of
how the committee operates and how proposals are typically handled.

--
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Edward Diener wrote:
>
> Francis Glassborow wrote:
>
> > If you have a choice between spending time on incorporating something
> > that has already been tried and found useful or something that has not,
> > to which do you give priority?
>
> This is Catch-22. If something has already been tried, then one can consider
> incorporating it, while since it has not been incorporated it will probably not
> be tried.

But that is not the case. Every compiler has some extenstions. G++ is
famous for experimenting with new language features. Extensions that
prove valuable have a good chance of making it into the standard.

A huge counterexample to your argument is the STL itself. The committee
tried for the first few years to come up with some sort of
standard library. In about 1993, Alex Stepanov proposed his STL
for inclusion in the C++ standard. After considerable work and
some modification, it was ultimately accepted, primarily because
it was in use and had been shown to be valuable.

--
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

# Getting a proposal implemented and in use by real programmers
# is an excellent way of addressing these concerns.

In article <3A01EA45.BB2D70B2@abraxis.com>,
Edward Diener  <eddielee@abraxis.com> wrote:
>Very difficult to do unless one writes a C++ compiler, or works for a company
>that produces a C++ compiler.

You need not write a whole C++ compiler -- you may instead start with
(the source code for) an existing C++ compiler, and modify it to implement
your proposal.  GCC, for example, is available as source code, and the
GCC mailing lists often discuss proposed not-in-the-standard modifications.

--
-- Jonathan Thornburg <jthorn@thp.univie.ac.at>
   http://www.thp.univie.ac.at/~jthorn/home.html
   Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
   Q: Only 7 countries have the death penalty for children.  Which are they?
   A: Congo, Iran, Nigeria, Pakistan[*], Saudi Arabia, United States, Yemen
      [*] Pakistan moved to end this in July 2000. -- Amnesty International,
                    http://www.amnesty.org/ailib/aipub/2000/AMR/25113900.htm

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Edward Diener" <eddielee@abraxis.com> wrote in message
news:3A01DFA6.FA314974@abraxis.com...
> get one's proposal seriously considered. I think very highly of the work
done by
> the C++ standards committee but the proposal of changes to the C++
standard for
> the next revision should be open to everyone on an equal basis.

I agree whole heartedly!

Greg

.                                                                         .
.                                                                         .
.                                                                         .
.                                                                         .



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <bcQTLnBHbfA6EwC4@ntlworld.com>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <remove.haberg-0211002205420001@du141-226.ppp.su-
> anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
> >I understand that the templates and STL combined was such a topic
> >that received hard resistance at the time, but which I myself when
> >I first saw it, as pure mathematician, immediately recognized as
> >the first small step towards greater generality.

> There was never any question in the minds of those working on the
> Standard that the STL needed to be part of it even though it meant a
> great deal of added work relatively late in the process.

This is not what I have heard.  There was never any question in the
minds of some of the people working on the standards, including
myself, that STL was trying to be too much, too late, and that it
would either end up fatally flawed, or delaying the standard too
much.  In the end, the committee did a better job of it than I would
have hoped, but I'd have still rather seen the standard a year or so
earlier, without STL, and no one can claim that the STL, as it is
enshrined in the standard, is really adequately specified.

> I think your sources of information about the Standardisation
> process are deeply flawed.

> >The underlying principle in this case, as I see it, is that the
> >templates codifies existing practises, but finds a more general
> >umbrella under which to do it, generic programming.

> Well that is a view, but not, I think, how we saw it.

> >The C++ standardization process had problems to cope with that, the
> >way I interpret it, because it requires each added feature to be of
> >general use.

> We never had the slightest problem with regards to the STL, those
> working on the C++ Library could be characterised as falling on it
> with delight because it demonstrated how C++ libraries might be
> written and generally developed.

Do you mean to say that there was never any disagreement in the
library group as to whether STL should be adopted or not?  Again,
that's not the way I heard it.

Where there may have been agreement is that the STL represented a new
idiom that was worthy of persuing.

--
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(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8u6qqo$j41$1@nnrp1.deja.com>, James.Kanze@dresdner-bank.com wrote:
>  There was never any question in the
>minds of some of the people working on the standards, including
>myself, that STL was trying to be too much, too late, and that it
>would either end up fatally flawed, or delaying the standard too
>much.  In the end, the committee did a better job of it than I would
>have hoped, but I'd have still rather seen the standard a year or so
>earlier, without STL, and no one can claim that the STL, as it is
>enshrined in the standard, is really adequately specified.

I noticed a spin-off of STL was that writers of compilers did better on
implementing templates. So even if one never will use STL itself, one
spin-off of its presence is better compiler template support.

Even though the current C++ standard is a big mungo-jumbo of features, the
presence of the jumble of features would make it easier to complete the
various paradigms: I have such things in my mind as making sure that one
can program always the new C++ features without having to resort to the
older C features.

One example of such a failing is that one cannot use C++ string or wstring
(and the personal computer OS's are already supporting Unicode filenames)
to open files. Another is that (I think) there is no convenient way to
parse a C-encoded string into a C++ string. (That is, if given a runtime
string which has been encoded as if a C-string with \ escapes, translate
it onto a regular C or C++ string. -- In C this could nearly be done by
sprintf() -- Just an example, I will not get into details.

So one question for the new C++ revision, I think, will be to make sure
that one _conveniently_ can program entirely with C++ features without
resorting to C programming. I would call this a "completion" fo the
current C++ standard. Other features may be amiss in the C++ standard
present as "holes", which should then perhaps be included in the idea of a
"completion".

Should not an archive for C++ revision suggest possibly distinguish
between "completions", "biggies", and new "smallies".

An biggie could be the CGC question: Is there any point for such an
archive to do anything else than to report that various GC's are
considered? -- I mean, this is an extremely technical issue that probably
need its own forum for discussions, and most likely will require dedicated
experts to resolve (even though everybody seems to have their own opinion
about it). It could hardly be a point to burden an archive with lots of
inputs here. Or perhaps I am wrong, one wants a lot of inputs on
everything, to browse.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Balog Pal (mh)" <pasa@lib.hu> wrote in message
news:3a02b5da@andromeda.datanet.hu...
> Francis Glassborow wrote in message ...
>
> Note the contradiction in this schema. As soon as extensions are added,
the
> compiler turns non standard-compliant. So it will no longer compile all
the
> standard-compliant code immigrating.

This should be untrue.  Any vendor adding extension should either make the
extensions a superset of the existing standard so that standard-compliant
will code.  At very least, there should be a compile option that turns off
the extensions.  In my limited experience, I have found this to be the case.

> Also, everyone chosing to use the
> extensions junps into a vendor lock-in. Also, if several compiler makers
> decide to provide the same extension, they will not necessarily implement
it
> in the same way. I even see tendencies to specifically create all the
> extensions as incompatible as possible, to force force that vendor
lock-in.

That has been my experience.

> (Anyone bothered with porting code between compilers probably noticed it
was
> much easies to port domething from a dos to unix, than between borland and
> ms comilers on the same dos16 platform. That is something bad.)

Absolutely.  I have libraries with headers for bot Borland & Microsoft.  The
number of #if/#else/#endif sections is excessive.  Based on behavior exposed
in court, I suspect MS purposely made some differences with other compilers
and coded the Win 95 documentation to do everything the MS way back in '95.

> The standard is there just to prevent the separation, and create a solid
> base for portability.

There a number of keywords (far, near, etc) that were commonly added to
dos16 platform compilers that might should have been added to the standard
as implementation defined "hints".  With segmented programming a thing of
the past, the need is so greatly deminished I don't see anyone doing it.

Greg


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Edward Diener wrote:
...
> think I should ever have to run around trying to convince individuals of my
> "idea" unless people showed an interest in what I might propose on a personal

Well, if you don't try to convince people, don't be surprised when they
remain unconvinced.

...
> would be glad to comply with their requests. But I don't think that I or anyone
> should needs to play politics or cozy up to some committee member in order to
> get one's proposal seriously considered. I think very highly of the work done by

You don't have to do anything inappropriate, as your words imply: "play
politics" or "cozy up". What you do have to do is to convince somebody
on the committee that your idea is worth pursuing. If your idea isn't
obviously good enough on it's own merits to convince them, you're going
to have to explain to someone the unobvious ways in which it is good
enough, or you can spend the rest of your life complaining that no one
spent the time needed to figure out those ways themselves. You'll be
amazed at how inobvious the merits of your idea can be to someone who
isn't you. They need explaining, often repeatedly and in detail.

...
> the C++ standards committee but the proposal of changes to the C++ standard for
> the next revision should be open to everyone on an equal basis.

I agree - just like the last one. There's things I'd change, if I could,
about how the last standard was handled, but not the ones relevant to
your complaint.

Incidentally, if you think the committee is insufficiently accessible,
there's an easy solution: join it. Set up whatever policies you want to
as to how people can send their ideas to you, and bring as many of them
as you can handle to the attention of the committee. I'll think you'll
quickly find that you have little time to spare for investigating ideas
who's proponents aren't willing to spend the time needed to promote
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8ts5qh$109i$1@news.hal-pc.org>, Greg Brewer
<nospam.greg@brewer.net> writes
>So if you aren't willing to put the time, energy, and money into promoting
>your idea, why should someone else.  Personally, I wish someone would
>collect ideas grade them for ease of implementation and likely hood to break
>existing code, then let the programmers vote on it.  Actually, egroups.com
>provides software that could do the job.  Wouldn't it be great if someone
>did it?  Of course, I think almost everyone is like me -- not enough time.
>
>Greg

ACCU is quite willing to host an area in which proposals (with adequate
documentation) can be placed. Actually I am keen for this to happen so
that good ideas are not lost, or insufficiently developed to be
considered at Committee level.

I am happy to act as the channel for such but it is not enough just to
have an idea, you have to consider how it will fit into the standard and
what impact it might have elsewhere.

If properly approached I am sure the editor of Overload would be happy
to provide exposure for well presented cases for change or extensions to
C++. email him merrells@netscape.com

Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A01863B.9F7253B6@artquest.net>, Pierre Baillargeon
<pb@artquest.net> wrote:
>That the eternal debate about standards: should it merely codify
>existign practice or forge ahead with new ideas? I do think that a first
>writing of a standard should be conservative but revisions should be
>more open to new ideas.
>In the case of C++, IMO, some people viewed the ARM as a kind of pseudo
>standard and thus had no problem with all the new ideas introduced by
>the real one. Some people thought otherwise.
...

I understand that the templates and STL combined was such a topic that
received hard resistance at the time, but which I myself when I first saw
it, as pure mathematician, immediately recognized as the first small step
towards greater generality.

The underlying principle in this case, as I see it, is that the templates
codifies existing practises, but finds a more general umbrella under which
to do it, generic programming.

The C++ standardization process had problems to cope with that, the way I
interpret it, because it requires each added feature to be of general use.

But in the case of templates and STL, what matters is not how many uses
generic programming itself, but how many that uses specializations of it,
that is, pretty much everyone.

One must also apply some foresightedness when deciding which new features
to add to C++: For example, the reason that really nobody is implementing
a CGC (conservative garbage collector) in C++ proper is that it is rather
hopeless to do so. So if one uses the principle of merely implementing
current programming techniques and their generalizations in C++, one will
strictly speaking cut out the CGC needed hooks.

So this is a rather conservative view. But C++ is the language that should
guarantee programming to be done, and not really be language of new
features. But still, a couple of needed general purpose programing
features need to be added to C++.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8ts5qh$109i$1@news.hal-pc.org>, "Greg Brewer"
<nospam.greg@brewer.net> wrote:
>Unfortunately, that is pretty much the way it is.  A few months ago, I aired
>out a few ideas.  I got a lot of response; mostly negative with some
>downright hostile.  For the most part, I had the feeling I was being shot
>down by a vocal minority.  But the experience left me bewildered and
>wondering how any changes get made to the language.
>
>I once sat on a committee for another language.  There were two proposals
>that came up.  Both looked somewhat useful; however, one looked really
>difficult to implement.  So I voted for one and against the other based on
>that.  Another member voted just the opposite and I asked about it.  The
>response on one was, "I wouldn't ever use that."  But for the other, "I
>wouldn't use it but someone else might."  I found the attitude
>disheartening.

I do not know much of the details of the voting procedure in the C++
standardization, but I believe it is flawed:

Compare with a representative democracy, where referendums are known to
generally suffer from the problem of shortsightedness. Instead, one votes
for people that are given more dictatorial powers under certain given
limitations.

So if one sits down and votes for these or those features independently,
one is going to end up with an incoherent mishmash, that is clear, just as
C++ is.

Instead one needs to select a few general topics, and branch off
sub-committees working these out. The general committee then should accept
these suggestions as a whole with the possibility.

One C++ success-story I think is STL: It was not a work of a committee,
but of one person or a few.

A topic that might work like that in the future is the GC (garbage
collecting) question: Clearly, this is something for dedicated experts to
consider, and I think they will do it, if they can with relatively free
hands, without risking a voting committee meddling on details.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Pierre Baillargeon wrote:

> Edward Diener wrote:
> >
> >
> > I for one will be very disappointed if there is not a specific path set out for
> > individuals to submit new ideas and worked out proposals for the next C++
> > release to the Standards Committees. I don't believe that the individuals
> > should have to promote and politic those proposals as you suggest, but instead
> > hope that the proposal will be accepted or not accepted on the basis of its own
> > merit. Your suggestion otherwise is very dismaying, but perhaps the "it will be
> > far too late" clause is purely your own belief and does not reflect the reality
> > of the process. If the C++ language turns into a foray of promoted ideas rather
> > than an attempt to make improvements to the language based on merit, I believe
> > many others will feel the same way that I do in this matter.
>
> That the eternal debate about standards: should it merely codify
> existign practice or forge ahead with new ideas? I do think that a first
> writing of a standard should be conservative but revisions should be
> more open to new ideas.

If the ideas are good ones and strengthen the language and the things that can be
done with it in order to make programming more effective and pleasurable, I don't see
why new ideas should ever be summarily refused at the proper time. A language is a
human invention, whether computer or otherwise, and not some frozen form which should
never be changed. I can understand the conservativeness of those who must decide to
make changes to a computer language such as C++, but if a language exists merely to
codify existing practices, then it can never change even if better ideas become
available. My understanding of the next C++ revision circa 2002 is that it will be
open to consideration of new ideas from anyone, and I hope I am not wrong in this.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:

> In article <3A016BFE.50AC64EF@abraxis.com>, Edward Diener
> <eddielee@abraxis.com> writes
> >I for one will be very disappointed if there is not a specific path set out for
> >individuals to submit new ideas and worked out proposals for the next C++
> >release to the Standards Committees. I don't believe that the individuals
> >should have to promote and politic those proposals as you suggest, but instead
> >hope that the proposal will be accepted or not accepted on the basis of its own
> >merit. Your suggestion otherwise is very dismaying, but perhaps the "it will be
> >far too late" clause is purely your own belief and does not reflect the reality
> >of the process. If the C++ language turns into a foray of promoted ideas rather
> >than an attempt to make improvements to the language based on merit, I believe
> >many others will feel the same way that I do in this matter.
>
> Of course there is a way for individuals to submit new ideas, join the
> committee or persuade a member of the committee to champion your
> idea(s). There are many good ideas that fall by the wayside simply
> because they do not meet enough needs to make it to the standard (read
> D&E).
>
> Even a well worked out idea with full specification for changes and
> additions to the standard takes time to be considered. Think in terms of
> a D.Phil thesis where you have to defend your ideas in a viva.

I have no problem with that. The issue to me is that there must be a specified way
by which anyone with a serious idea for a change to C++ can present it to the
Standards committee at the appropriate time when the next revision of C++ is
considered, which I believe is circa 2002. I think that it will also be important
that the manner in which this change is presented be specifically laid out by the
committee so that those who want to present their changes can do so in the correct
way. Beyond that the acceptance or rejection of the idea, or the need to get further
input from the presenter, is up to the committee and that's fine with me. I just
hate the idea that I would have to somehow get into some personal politicking just
to have my idea considered. That smacks of an authoritarianism and an elitism which
I personally despise.

> However, if you want changes you really must be willing to do some work,
> and be surprised by how much more work you then have to do.

I wouldn't have to be surprised by how much more ( more than what ? ) work I would
have to do, but I would certainly be willing to do the necessary work, as I think
should anyone who wants to propose a change to the language standard. I just want my
proposal to be considered  on an equal basis as anyone 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

wmm@fastdial.net wrote:

> In article <3A016BFE.50AC64EF@abraxis.com>,
>   eddielee@abraxis.com wrote:
> > Francis Glassborow wrote:
> >
> > > In article <remove.haberg-0111002236330001@du154-226.ppp.su-
> > > anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
> > > >If you look around some of the other posts, you will find some of
> them.
> > > >Apart from that, the classical ones, lack of finding the root
> system for a
> > > >CGC (conservative garbage collector), threading & distributed
> programming
> > > >support, portable assembler support, etc.
> > > >
> > > >-- But I realy thought to return that when those discussions for a
> new
> > > >C++ revision has been opened. :-)
> > >
> > > And several months ago I offered to arrange a public archive of
> worked
> > > out proposals. There have been zero submissions so far. If you
> seriously
> > > want new things in the next release of C++ it will be far too late
> to
> > > sit around until the Standards Committees start considering it
> > > (standards are supposed to be driven by existing practice) Get your
> > > ideas published and continually visible now. Get an implementor
> (even
> > > better get two) to support it as an extension.
> >
> > I for one will be very disappointed if there is not a specific path
> set out for
> > individuals to submit new ideas and worked out proposals for the next
> C++
> > release to the Standards Committees. I don't believe that the
> individuals
> > should have to promote and politic those proposals as you suggest,
> but instead
> > hope that the proposal will be accepted or not accepted on the basis
> of its own
> > merit. Your suggestion otherwise is very dismaying, but perhaps
> the "it will be
> > far too late" clause is purely your own belief and does not reflect
> the reality
> > of the process. If the C++ language turns into a foray of promoted
> ideas rather
> > than an attempt to make improvements to the language based on merit,
> I believe
> > many others will feel the same way that I do in this matter.
>
> I think you're taking a more negative view of this process than
> is warranted.  I may be naive in this, but I believe that the
> majority of extensions proposed during the drafting of the first
> Standard were evaluated on the basis of merit, not on the basis
> of political maneuvering.

Good. I didn't mean to sound negative. I was reacting to the suggestion that
there was not a straightforward, acceptable way for anyone to present a
proposal for the next revision of the C++ standard. I think it is very
important that there must be such a way and that the C++ Standards committee
explain in detail exactly how this is to be done and what is the timeframe in
which it must be done. I do realize the enormous amount od work necessary for
the committee to examine each proposal, but without that guarantee the
process becomes a form of elitism.

> Getting a proposal implemented and in use by real programmers
> is an excellent way of addressing these concerns.

Very difficult to do unless one writes a C++ compiler, or works for a company
that produces a C++ compiler. I believe there are people outside these
categories who may still have good ideas regrading C++ language improvements.

> All that said, Bjarne wrote a very widely-distributed article on
> how to submit a proposal to the Committee during the production
> of the first Standard.  I imagine a similar approach will be
> taken during the revision process.  We've actively solicited
> public involvement during the defect resolution stage, and I'd
> expect the same once we start the next revision.  All we're
> saying is that we're resource-limited and need to be very
> careful with what's approved, so if you have a proposal you
> think is worthwhile, you need to help us to do the due
> diligence on it.

I have no problem with this at all, and I imagine other proposers do not
either. All I personally would ask is that the path to making proposals at
the appropriate time be laid out very specifically by the C++ standards
committee so that anyone can make a valid proposal. Obviously putting this
information on a publicly accessible web site at the proper time would be a
good way, but any way which gets the attention of C++ programmers is fine.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A01E681.F389AD7B@abraxis.com>, Edward Diener
<eddielee@abraxis.com> writes
>I wouldn't have to be surprised by how much more ( more than what ? ) work I
>would
>have to do, but I would certainly be willing to do the necessary work, as I
>think
>should anyone who wants to propose a change to the language standard. I just
>want my
>proposal to be considered  on an equal basis as anyone else.

If you have to choose who to listen to, do you listen to those you know
or someone else? That is not politics it is just the way we poor humans
function.

If you have a choice between spending time on incorporating something
that has already been tried and found useful or something that has not,
to which do you give priority?

It isn't politics even with a small 'p' but an understanding of how
limited human resources will be used.

If you have one or more ideas explain them (here will do for starters)

You will need to explain

1) The motivation
2) What solution you are proposing
3) What impact it will have on the language

Read D&E where BS gives a pretty good summary of what qualifies an idea
for serious consideration as an extension. In addition there might be a
few places where C++ can be cleaned up and simplified.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A01EA45.BB2D70B2@abraxis.com>,
Edward Diener  <eddielee@abraxis.com> wrote:
>Good. I didn't mean to sound negative. I was reacting to the suggestion that
>there was not a straightforward, acceptable way for anyone to present a
>proposal for the next revision of the C++ standard.

The most obvious way is to join the committee.  Anyone can join.  Then not
only do you get to make proposals, you also get to vote down other people's
proposals. :;

>wmm@fastdial.net wrote:
>> Getting a proposal implemented and in use by real programmers
>> is an excellent way of addressing these concerns.
>
>Very difficult to do unless one writes a C++ compiler, or works for a company
>that produces a C++ compiler. I believe there are people outside these
>categories who may still have good ideas regrading C++ language improvements.

If you're not an implementor, then presumably you're a customer of one.
You should try to get *them* to implement what you need as an extension.
Hopefully they will have representation on the standard committee, and can
then try to get the feature adopted.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A01E1B0.6EEB208E@abraxis.com>, Edward Diener
<eddielee@abraxis.com> writes
>If the ideas are good ones and strengthen the language and the things that can
>be
>done with it in order to make programming more effective and pleasurable, I
>don't see
>why new ideas should ever be summarily refused at the proper time. A language is
>a
>human invention, whether computer or otherwise, and not some frozen form which
>should
>never be changed. I can understand the conservativeness of those who must decide
>to
>make changes to a computer language such as C++, but if a language exists merely
>to
>codify existing practices, then it can never change even if better ideas become
>available. My understanding of the next C++ revision circa 2002 is that it will
>be
>open to consideration of new ideas from anyone, and I hope I am not wrong in
>this.

Change your view. The Standard provides a common base that should be
supported by all implementations. Implementations are free to add
extensions (some of us would even encourage them to do so). If the idea
is good, why should it wait. The best way of identifying good ideas is
that they are being used. BTW, like it or not, but RTTI was introduced
into the language (after an explicit decision not to do so) because it
proved necessary and was being provided in various ways by third
parties.

If you have a good idea, bring it into the open now. If it is as good as
you believe someone will offer it as an extension (such things incrfease
sales)




Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A01EA45.BB2D70B2@abraxis.com>, Edward Diener
<eddielee@abraxis.com> writes
>I have no problem with this at all, and I imagine other proposers do not
>either. All I personally would ask is that the path to making proposals at
>the appropriate time be laid out very specifically by the C++ standards
>committee so that anyone can make a valid proposal. Obviously putting this
>information on a publicly accessible web site at the proper time would be a
>good way, but any way which gets the attention of C++ programmers is fine.

And the point I wish to make is that at that time (i.e. when we move to
work on the next revision) it will be largely too late to start creating
a proposal from scratch. Good ideas need to be shared, examined and
refined early so that they are mature when the more formal process
becomes available.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3a02b5da@andromeda.datanet.hu>, Balog Pal (mh) <pasa@lib.hu>
writes
>Note the contradiction in this schema. As soon as extensions are added, the
>compiler turns non standard-compliant.

Absolutely untrue. As long as the compiler issues at least one
diagnostic it can use as many extensions as it wishes to support.
> So it will no longer compile all the
>standard-compliant code immigrating.

Why do you think that? A compiler with genuine extensions can easily
(well as easily as any other compiler) compile standard compliant code,
it can also compile some non-compliant code.

>Also, everyone chosing to use the
>extensions junps into a vendor lock-in.
And if the idea is good (which is when good programmers will use the
extensions) both users and the implementor will want it in the next
standard release.

>Also, if several compiler makers
>decide to provide the same extension, they will not necessarily implement it
>in the same way.
True, but those that bother with standards will seek to do so, those
that do not care will do their own thing regardless.


>I even see tendencies to specifically create all the
>extensions as incompatible as possible, to force force that vendor lock-in.

You should not be quite so cynical. If you were right, why would any
compiler implementor bother with the Standard (many users could not care
anyway. Readers of this ng form a rather special, very small, minority)

>(Anyone bothered with porting code between compilers probably noticed it was
>much easies to port domething from a dos to unix, than between borland and
>ms comilers on the same dos16 platform. That is something bad.)

I do not accept your premise.

>
>The standard is there just to prevent the separation, and create a solid
>base for portability.

No, a language standard is to provide a common core and incidentally a
forum where issues of commonality can be thrashed out. It is not
supposed to limit what can be done, but to guarantee the minimum the
user can expect. Your view would cause stagnation.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:
>
> In article <8ts5qh$109i$1@news.hal-pc.org>, Greg Brewer
> <nospam.greg@brewer.net> writes
> >So if you aren't willing to put the time, energy, and money into promoting
> >your idea, why should someone else.  Personally, I wish someone would
> >collect ideas grade them for ease of implementation and likely hood to break
> >existing code, then let the programmers vote on it.  Actually, egroups.com
> >provides software that could do the job.  Wouldn't it be great if someone
> >did it?  Of course, I think almost everyone is like me -- not enough time.
> >
> >Greg
>
> ACCU is quite willing to host an area in which proposals (with adequate
> documentation) can be placed. Actually I am keen for this to happen so
> that good ideas are not lost, or insufficiently developed to be
> considered at Committee level.
>
> I am happy to act as the channel for such but it is not enough just to
> have an idea, you have to consider how it will fit into the standard and
> what impact it might have elsewhere.
>

I believe that there is some merit in having a repository even for ill-considered
ideas which don't make it to the "adequately documented" level.  This can be useful
so that people can see what hasn't made it, or what might make it if they are
prepared to put in the required effort.

In general, tracking rejects (ideally with reasons for rejections) is a valuable
form of documenting why a process/product is the way it is and not some other way.
It is regrettable (if understandable) that the C++ Committee didn't have the
resources to produce a "Rationale" document similar to that for C89 in which
more of the reasons why C++ is the way it is could have been enumerated.  Maybe
an update of D&E will do much of this some day.

If I can solve my home connectivity problems then I'd be prepared to help with
the work to maintain a repository of proposals, however vague they may be.  Not
expecting that the Committee will pay much attention to most of them, but for
completeness.

-- 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:

> In article <3A01E681.F389AD7B@abraxis.com>, Edward Diener
> <eddielee@abraxis.com> writes
> >I wouldn't have to be surprised by how much more ( more than what ? ) work I
> >would
> >have to do, but I would certainly be willing to do the necessary work, as I
> >think
> >should anyone who wants to propose a change to the language standard. I just
> >want my
> >proposal to be considered  on an equal basis as anyone else.
>
> If you have to choose who to listen to, do you listen to those you know
> or someone else? That is not politics it is just the way we poor humans
> function.

I think one listens ideally  to what is being said, not who is saying it. If you
are saying that we don't live in an ideal world, of course you are right but it
is we humans which make up part of this world and we should try to be as
impartial in our knowledge as possible.

> If you have a choice between spending time on incorporating something
> that has already been tried and found useful or something that has not,
> to which do you give priority?

This is Catch-22. If something has already been tried, then one can consider
incorporating it, while since it has not been incorporated it will probably not
be tried.

> It isn't politics even with a small 'p' but an understanding of how
> limited human resources will be used.
>
> If you have one or more ideas explain them (here will do for starters)

I never thought of this forum as a place to propose new ideas but if it is
partially that, I will do so in the future. Right now is impossible for me as I
will be separated from a computer for a period of time. But I will take you up
when I get back.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-0211002205420001@du141-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>I understand that the templates and STL combined was such a topic that
>received hard resistance at the time, but which I myself when I first saw
>it, as pure mathematician, immediately recognized as the first small step
>towards greater generality.

There was never any question in the minds of those working on the
Standard that the STL needed to be part of it even though it meant a
great deal of added work relatively late in the process. I think your
sources of information about the Standardisation process are deeply
flawed.

>
>The underlying principle in this case, as I see it, is that the templates
>codifies existing practises, but finds a more general umbrella under which
>to do it, generic programming.

Well that is a view, but not, I think, how we saw it.


>
>The C++ standardization process had problems to cope with that, the way I
>interpret it, because it requires each added feature to be of general use.

We never had the slightest problem with regards to the STL, those
working on the C++ Library could be characterised as falling on it with
delight because it demonstrated how C++ libraries might be written and
generally developed.

>
>But in the case of templates and STL, what matters is not how many uses
>generic programming itself, but how many that uses specializations of it,
>that is, pretty much everyone.

I disagree. The STL introduced a fundamental programming paradigm that
greatly extended programmers view of how the language could be used.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-0211002205270001@du141-226.ppp.su-anst.tninet.se>,
Hans Aberg <remove.haberg@matematik.su.se> wrote:
>You know, I have already given up the hope of seeing C++ show up with the
>feature I need, so I decided to write my own language. You and others out
>there are encouraged to do likewise.

That may be acceptable for the particular programming universe
you live in, but in general, the problem with the above suggestion
is that it prescribes a solution that will suffer the same problem
it suggests to solve.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

On Thu,  2 Nov 2000 22:28:44 GMT, Edward Diener <eddielee@abraxis.com>
wrote:
>> Getting a proposal implemented and in use by real programmers
>> is an excellent way of addressing these concerns.
>
>Very difficult to do unless one writes a C++ compiler, or works for a company
>that produces a C++ compiler. I believe there are people outside these
>categories who may still have good ideas regrading C++ language improvements.

This is only true if you have a language change. First of all, think
through your idea for problems (breaking old code, likely ease of
implementation, etc, etc). Then post it here to see what people think.
Someone may see a fatal flaw, or you might be persuaded that your idea
is not good enough to take the committee's time over other
submissions.

Then, if you still think your idea is good, go away and fix any
niggles with it and write it up a bit more formally. Then perhaps talk
to the gcc people (on their mailing lists), a compiler vendor from
here (the Metroworks people are to be found usually, along with Greg
Comeau (who probably has some influence with the EDG people who write
the c++ front end for a number of compilers), or perhaps one of the
powerful committee members (Bjarne Stroustrup, Andrew Koenig, etc), if
they show an interest. These are all good people who will want good
ideas to make it.

If you have a library extension (and many are needed to e.g.
<functional>), then www.boost.org (and their mailing lists) is an
excellent forum to test out your idea. I expect some of the library
extensions there to make it into the next standard.

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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-3110002046510001@du128-226.ppp.su-anst.tninet.se>,
Hans Aberg <remove.haberg@matematik.su.se> wrote:
>>From the little of what I have seen of the current C++ standard
>(ANSI/ISO/IEC 14882-1998), one needs to start the discussions on what
>should be in the new revision as soon as possible, because there are too
>many big holes in it.

If nothing else, certainly this is occuring informally.
And perhaps that is as it should be for now.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A01863B.9F7253B6@artquest.net>,
Pierre Baillargeon  <pb@artquest.net> wrote:
>As an aside: is there any guideline on how to format a proposition, what
>it should include, what it should discuss? I've posted some ideas of
>mine in the past (typegen, rethrow without catch, multiple exceptions)
>and wouldn't mind submitting them formally, after a lot of rework.

I seem to recall that there is a document somewhere, but
I can't recall where.  Too, checking Stroustrup's D&E covers
some aspects of this.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8ts5qh$109i$1@news.hal-pc.org>,
Greg Brewer <nospam.greg@brewer.net> wrote:
>"Edward Diener" <eddielee@abraxis.com> wrote in message
>news:3A016BFE.50AC64EF@abraxis.com...
>> Francis Glassborow wrote:
>> I for one will be very disappointed if there is not a specific path set
>out for
>> individuals to submit new ideas and worked out proposals for the next C++
>> release to the Standards Committees. I don't believe that the individuals
>> should have to promote and politic those proposals as you suggest, but
>instead
>
>Unfortunately, that is pretty much the way it is.  A few months ago, I aired
>out a few ideas.  I got a lot of response; mostly negative with some
>downright hostile.  For the most part, I had the feeling I was being shot
>down by a vocal minority.  But the experience left me bewildered and
>wondering how any changes get made to the language.

It is bewildering at times, among other things, but the nature of
the beast is that proposals must hold up to scrutiny, have one or more
champions, be within the culture, etc.

>I once sat on a committee for another language.  There were two proposals
>that came up.  Both looked somewhat useful; however, one looked really
>difficult to implement.  So I voted for one and against the other based on
>that.  Another member voted just the opposite and I asked about it.  The
>response on one was, "I wouldn't ever use that."  But for the other, "I
>wouldn't use it but someone else might."  I found the attitude
>disheartening.

For some things, those responses seem as appropriate as yours was.

>On the positive, I understand why it works the way it does.  Many of these
>suggestions would require a lot of work to implement and would break a lot
>of code.  The might also have hidden side effects.  A classic one I vaguely
>remember involves the reason behind disallowing a certain automatic cast
>from non-const to const.  Someone was able to demonstrate how a series of
>legal statements that would cast from const to non-const and the one cast
>was key to it working.  I wish I could remember it better.

This smells like http://www.comeaucomputing.com/techtalk/#deconstutoh

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3a02b5da@andromeda.datanet.hu>, Balog Pal (mh) <pasa@lib.hu> wrote:
>Francis Glassborow wrote in message ...
>>Change your view. The Standard provides a common base that should be
>>supported by all implementations. Implementations are free to add
>>extensions (some of us would even encourage them to do so). If the idea
>>is good, why should it wait.
>
>Note the contradiction in this schema. As soon as extensions are added, the
>compiler turns non standard-compliant. So it will no longer compile all the
>standard-compliant code immigrating. Also, everyone chosing to use the
>extensions junps into a vendor lock-in. Also, if several compiler makers
>decide to provide the same extension, they will not necessarily implement it
>in the same way. I even see tendencies to specifically create all the
>extensions as incompatible as possible, to force force that vendor lock-in.
>(Anyone bothered with porting code between compilers probably noticed it was
>much easies to port domething from a dos to unix, than between borland and
>ms comilers on the same dos16 platform. That is something bad.)
>
>The standard is there just to prevent the separation, and create a solid
>base for portability.

This might all be so to some degree, but too, the standard is NOT
a mechanism for stagnation.  Yup, we need stability, we need
conforming implementations, etc., but too, we need growth.  Since
this thread is about the latter, it can and will come about through
various forms, including (at the time) non-conforming extensions.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <sdpObVAgwuA6Ew18@ntlworld.com>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <3a02b5da@andromeda.datanet.hu>, Balog Pal (mh)
<pasa@lib.hu>
> writes
> >Note the contradiction in this schema. As soon as extensions are
added, the
> >compiler turns non standard-compliant.
>
> Absolutely untrue. As long as the compiler issues at least one
> diagnostic it can use as many extensions as it wishes to support.

One caveat: 1.4p8 gives the criteria for extensions that are
permitted by a conforming implementation, and one is that such
extensions "do not alter the behavior of any well-formed
program."

That doesn't mean that "extensions" that change the meaning of
or outlaw existing constructs can't be done; it just means that
the separation between standard and non-standard modes has to
be a bit more rigorous.  For instance, most compilers are able
to handle code that relies on the original scoping of init
declarations in a "for" statement.  Because that "extension"
changes the interpretation of the program, however, they must
be able to select the standard behavior by means of a command
line option, environment variable, configuration file, etc., in
order to be conforming.

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A01FA39.75E2E987@abraxis.com>,
Edward Diener  <eddielee@abraxis.com> wrote:
>Francis Glassborow wrote:
>>If you have a choice between spending time on incorporating something
>>that has already been tried and found useful or something that has not,
>>to which do you give priority?
>
>This is Catch-22. If something has already been tried, then one
>can consider incorporating it

One can also consider not incorp'ing it, and that's been so many times.

>while since it has not been incorporated it will probably not
>be tried.

And yet, many have been, so that's not always so.

So, one can call it catch-22, but it goes against historical proof
to the contrary.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8tu2ah$u6q$1@nnrp1.deja.com>, Alan Griffiths <alan.griffiths
@uk.experian.com> writes
>> If properly approached I am sure the editor of Overload would be happy
>> to provide exposure for well presented cases for change or extensions
>to
>> C++. email him merrells@netscape.com
>
>Or better yet at Merrells@etimecapital.com - :)

Sorry, I had forgotten that he had moved recently.



Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8tt6bc$ibl$1@panix3.panix.com>, comeau@comeaucomputing.com wrote:
>Hans Aberg <remove.haberg@matematik.su.se> wrote:
>>You know, I have already given up the hope of seeing C++ show up with the
>>feature I need, so I decided to write my own language. You and others out
>>there are encouraged to do likewise.
>
>That may be acceptable for the particular programming universe
>you live in, but in general, the problem with the above suggestion
>is that it prescribes a solution that will suffer the same problem
>it suggests to solve.

Actually, it is not that difficult creating your own language: Use tools
such as Bison and Flex to output say C++ files. If you make sure your own
language allows the inclusion of C++ code, you can do everything you can
do in C++ plus your own stuff.

You can then distribute the flawed-C++-standard output files, if somebody
happens to not like your extensions. :-)

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A02F339.F6B8F5@evtechnology.com>, James Dennett
<james@evtechnology.com> writes
>If I can solve my home connectivity problems then I'd be prepared to help with
>the work to maintain a repository of proposals, however vague they may be.  Not
>expecting that the Committee will pay much attention to most of them, but for
>completeness.

Indeed, those that have once been rejected can still have merit for
reconsideration, and poorly presented ideas with merit may find someone
with greater technical skills able to pick them up and run with them.

However I would want a little more than "I think C++ needs 'typeof'"

Perhaps some of you have time to recover some of the ideas we have
already had here so we can start an archive. Whether the archive is on
www.accu.org or elsewhere with a pointer from there makes no difference
as long as we get it going and well known.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

I have certainly come across some topics that I think at least be
considered for adding to C++. It would be could if there would be an
informal way to at least jot these down (beyond discussions in this
newsgroup) for further, later consideration: Perhaps the one who wrote it
will do it, perhaps somebody else.

In order tyo keep volume down, there should be some formal requirements,
briefly describing what change is wanted and why, etc.

Taken away biggies, such as the CGC (conservative garbage collector)
question and such I can give one example I came across, namely adding a
polymorhic function pointer in C++: Those can be implemented via C++
polymorhic pointers, but the point of adding it as a feature is that it
becomes fatser in exectuition, and the feature becomes more widely
available.

As I have implemented myself, I do not worry about anymore, but it is
akind of thing that I would want to write down for consideration without
having to get into heavy formal application writing stuff.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8tv1vj$p25$1@nnrp1.deja.com>, wmm@fastdial.net writes
>One caveat: 1.4p8 gives the criteria for extensions that are
>permitted by a conforming implementation, and one is that such
>extensions "do not alter the behavior of any well-formed
>program."

Thanks for that reminder. I forget that changes are also considered
extensions.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A01E681.F389AD7B@abraxis.com>,
  eddielee@abraxis.com wrote:
> I have no problem with that. The issue to me is that there must be a
specified way
> by which anyone with a serious idea for a change to C++ can present
it to the
> Standards committee at the appropriate time when the next revision of
C++ is
> considered, which I believe is circa 2002. I think that it will also
be important
> that the manner in which this change is presented be specifically
laid out by the
> committee so that those who want to present their changes can do so
in the correct
> way. Beyond that the acceptance or rejection of the idea, or the need
to get further
> input from the presenter, is up to the committee and that's fine with
me. I just
> hate the idea that I would have to somehow get into some personal
politicking just
> to have my idea considered. That smacks of an authoritarianism and an
elitism which
> I personally despise.

I think the suggestion Francis made about finding a Committee
member to "champion" a proposal may have been misunderstood.
The Committee is not like some secret society where you have to
have a member to sponsor you in order to join.  The reason for
having a member directly involved is much more pragmatic than
that.

One benefit is just having someone physically present at the
meeting who can answer questions.  It's one thing to confront
a 15-page document describing a proposal, and it's quite
another to have someone who can run through a few PowerPoint
slides, clarify points that people didn't understand, act as
a conduit to the principal author when (not "if") unanticipated
issues are brought up, etc.

Another point is the allocation of time during the meeting.  If
you have a dozen or more proposals on the agenda, you're likely
to spend more time on a proposal for which there is a
knowledgeable person physically available, simply because you
know that you will make more progress on that one.  Also, when
the question arises, "Which one of these dozen proposals will we
discuss next?", the answer will likely be one associated with
someone present because you'd like to take advantage of their
presence -- they might not be there at the next meeting.

These are simply pragmatic facts in the way committees in
general work, not some conspiracy to ignore "outsiders."  And
it's not guaranteed to work that way, either.  A poorly prepared
proposal, or one that doesn't seem very important, will be
ignored in favor of one that is well prepared and has obvious
major benefit, even if the former has an associated Committee
member and the latter is by someone who is unknown to the
Committee.

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hans Aberg wrote:
...
> > The Standards
> >Committees already have enough work to keep them fully occupied, and
> >many of those doing the work are 'lent' by companies who would not be
> >happy by the destabilising affect of starting a new standard revision.
>
> I have to finish off my own language too, first, which I just started
> writing. We all are so busy. :-)
>
> But first things first. First finishing off the details in the current
> C++, and then let the new discussions come along. But startng in 1993

The details are as finished as they'll ever be. If you think there's a
defect, you can file a report, but if you think it's merely missing
something it should have there's nothing more to be done until it's time
to start work on the next release.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hans Aberg wrote:
>
> In article <3a0019ff$0$19232$1dc6d6e3@news.corecomm.net>, "CC Ghost"
> <ccghst@erehwon.com> wrote:
...
> >Why rush to revise the standard *now* since
> >
> >1 - most compilers haven't implemented all
> >of the last revision
>
> Well, the new standard has to be there before the compilers can catch on. :-)

It's been there since 1998.

...
> for limiting C++. And the C99 is relatively minor, so catching onto that
> one should not really be so difficult.

The C99 changes are minor only by comparison with the changes between
pre-standard and post-standard C++. In themselves they're fairly
substantial. So substantial that I've yet to hear of a fully conforming
C99 implementation. I haven't even heard of an implementation that makes
a qualified claim to conformance, something that usually occurs long
before real conformance has been achieved.
If someone's heard otherwise, I'd like to know about 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-0111002236330001@du154-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>If you look around some of the other posts, you will find some of them.
>Apart from that, the classical ones, lack of finding the root system for a
>CGC (conservative garbage collector), threading & distributed programming
>support, portable assembler support, etc.
>
>-- But I realy thought to return that when those discussions for a new
>C++ revision has been opened. :-)

And several months ago I offered to arrange a public archive of worked
out proposals. There have been zero submissions so far. If you seriously
want new things in the next release of C++ it will be far too late to
sit around until the Standards Committees start considering it
(standards are supposed to be driven by existing practice) Get your
ideas published and continually visible now. Get an implementor (even
better get two) to support it as an extension.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:

> In article <remove.haberg-0111002236330001@du154-226.ppp.su-
> anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
> >If you look around some of the other posts, you will find some of them.
> >Apart from that, the classical ones, lack of finding the root system for a
> >CGC (conservative garbage collector), threading & distributed programming
> >support, portable assembler support, etc.
> >
> >-- But I realy thought to return that when those discussions for a new
> >C++ revision has been opened. :-)
>
> And several months ago I offered to arrange a public archive of worked
> out proposals. There have been zero submissions so far. If you seriously
> want new things in the next release of C++ it will be far too late to
> sit around until the Standards Committees start considering it
> (standards are supposed to be driven by existing practice) Get your
> ideas published and continually visible now. Get an implementor (even
> better get two) to support it as an extension.

I for one will be very disappointed if there is not a specific path set out for
individuals to submit new ideas and worked out proposals for the next C++
release to the Standards Committees. I don't believe that the individuals
should have to promote and politic those proposals as you suggest, but instead
hope that the proposal will be accepted or not accepted on the basis of its own
merit. Your suggestion otherwise is very dismaying, but perhaps the "it will be
far too late" clause is purely your own belief and does not reflect the reality
of the process. If the C++ language turns into a foray of promoted ideas rather
than an attempt to make improvements to the language based on merit, I believe
many others will feel the same way that I do in this matter.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Edward Diener" <eddielee@abraxis.com> wrote in message
news:3A016BFE.50AC64EF@abraxis.com...
> Francis Glassborow wrote:
> I for one will be very disappointed if there is not a specific path set
out for
> individuals to submit new ideas and worked out proposals for the next C++
> release to the Standards Committees. I don't believe that the individuals
> should have to promote and politic those proposals as you suggest, but
instead

Unfortunately, that is pretty much the way it is.  A few months ago, I aired
out a few ideas.  I got a lot of response; mostly negative with some
downright hostile.  For the most part, I had the feeling I was being shot
down by a vocal minority.  But the experience left me bewildered and
wondering how any changes get made to the language.

I once sat on a committee for another language.  There were two proposals
that came up.  Both looked somewhat useful; however, one looked really
difficult to implement.  So I voted for one and against the other based on
that.  Another member voted just the opposite and I asked about it.  The
response on one was, "I wouldn't ever use that."  But for the other, "I
wouldn't use it but someone else might."  I found the attitude
disheartening.

On the positive, I understand why it works the way it does.  Many of these
suggestions would require a lot of work to implement and would break a lot
of code.  The might also have hidden side effects.  A classic one I vaguely
remember involves the reason behind disallowing a certain automatic cast
from non-const to const.  Someone was able to demonstrate how a series of
legal statements that would cast from const to non-const and the one cast
was key to it working.  I wish I could remember it better.

So if you aren't willing to put the time, energy, and money into promoting
your idea, why should someone else.  Personally, I wish someone would
collect ideas grade them for ease of implementation and likely hood to break
existing code, then let the programmers vote on it.  Actually, egroups.com
provides software that could do the job.  Wouldn't it be great if someone
did it?  Of course, I think almost everyone is like me -- not enough time.

Greg


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Edward Diener wrote:
>
>
> I for one will be very disappointed if there is not a specific path set out for
> individuals to submit new ideas and worked out proposals for the next C++
> release to the Standards Committees. I don't believe that the individuals
> should have to promote and politic those proposals as you suggest, but instead
> hope that the proposal will be accepted or not accepted on the basis of its own
> merit. Your suggestion otherwise is very dismaying, but perhaps the "it will be
> far too late" clause is purely your own belief and does not reflect the reality
> of the process. If the C++ language turns into a foray of promoted ideas rather
> than an attempt to make improvements to the language based on merit, I believe
> many others will feel the same way that I do in this matter.

That the eternal debate about standards: should it merely codify
existign practice or forge ahead with new ideas? I do think that a first
writing of a standard should be conservative but revisions should be
more open to new ideas.
In the case of C++, IMO, some people viewed the ARM as a kind of pseudo
standard and thus had no problem with all the new ideas introduced by
the real one. Some people thought otherwise. Try a search on "Re:
Apology and a moderation policy question." in comp.lang.c++.moderated.

As an aside: is there any guideline on how to format a proposition, what
it should include, what it should discuss? I've posted some ideas of
mine in the past (typegen, rethrow without catch, multiple exceptions)
and wouldn't mind submitting them formally, after a lot of rework.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A016BFE.50AC64EF@abraxis.com>, Edward Diener
<eddielee@abraxis.com> writes
>I for one will be very disappointed if there is not a specific path set out for
>individuals to submit new ideas and worked out proposals for the next C++
>release to the Standards Committees. I don't believe that the individuals
>should have to promote and politic those proposals as you suggest, but instead
>hope that the proposal will be accepted or not accepted on the basis of its own
>merit. Your suggestion otherwise is very dismaying, but perhaps the "it will be
>far too late" clause is purely your own belief and does not reflect the reality
>of the process. If the C++ language turns into a foray of promoted ideas rather
>than an attempt to make improvements to the language based on merit, I believe
>many others will feel the same way that I do in this matter.

Of course there is a way for individuals to submit new ideas, join the
committee or persuade a member of the committee to champion your
idea(s). There are many good ideas that fall by the wayside simply
because they do not meet enough needs to make it to the standard (read
D&E).

Even a well worked out idea with full specification for changes and
additions to the standard takes time to be considered. Think in terms of
a D.Phil thesis where you have to defend your ideas in a viva.

Of course you will believe that you understand all the implications of
your idea, but believe me, the number of committee members who
understand all the implications of there carefully considered proposals
can be counted on the fingers of one hand.  The time consuming element
is that review and consideration of implications. What may appear
obviously a good idea to you may be far from obvious to others.  That is
why I made my proposal/offer for a public site where proposals can be
displayed and refinements, implications etc. considered.

However, if you want changes you really must be willing to do some work,
and be surprised by how much more work you then have to do.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A016BFE.50AC64EF@abraxis.com>,
  eddielee@abraxis.com wrote:
> Francis Glassborow wrote:
>
> > In article <remove.haberg-0111002236330001@du154-226.ppp.su-
> > anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
> > >If you look around some of the other posts, you will find some of
them.
> > >Apart from that, the classical ones, lack of finding the root
system for a
> > >CGC (conservative garbage collector), threading & distributed
programming
> > >support, portable assembler support, etc.
> > >
> > >-- But I realy thought to return that when those discussions for a
new
> > >C++ revision has been opened. :-)
> >
> > And several months ago I offered to arrange a public archive of
worked
> > out proposals. There have been zero submissions so far. If you
seriously
> > want new things in the next release of C++ it will be far too late
to
> > sit around until the Standards Committees start considering it
> > (standards are supposed to be driven by existing practice) Get your
> > ideas published and continually visible now. Get an implementor
(even
> > better get two) to support it as an extension.
>
> I for one will be very disappointed if there is not a specific path
set out for
> individuals to submit new ideas and worked out proposals for the next
C++
> release to the Standards Committees. I don't believe that the
individuals
> should have to promote and politic those proposals as you suggest,
but instead
> hope that the proposal will be accepted or not accepted on the basis
of its own
> merit. Your suggestion otherwise is very dismaying, but perhaps
the "it will be
> far too late" clause is purely your own belief and does not reflect
the reality
> of the process. If the C++ language turns into a foray of promoted
ideas rather
> than an attempt to make improvements to the language based on merit,
I believe
> many others will feel the same way that I do in this matter.

I think you're taking a more negative view of this process than
is warranted.  I may be naive in this, but I believe that the
majority of extensions proposed during the drafting of the first
Standard were evaluated on the basis of merit, not on the basis
of political maneuvering.

That said, however, there is a threshold that new proposals
must exceed in order to be seriously considered, and I think
that's appropriate.  The Standard Committee should be a
conservative body -- we're determining a specification that
will affect millions of people for a period of years or
decades, so a proposal must be very carefully considered before
it is adopted.  We have to be convinced that a proposal is
better than the alternatives (e.g., how bad are the workarounds,
could the functionality be provided in a library rather than as
a language change, etc.), that it's implementable, that it
solves a widespread need, that it doesn't penalize people who
don't use it (not only in terms of performance but in the
complexity of the specification, in unintuitive ways it might
impinge on other features, etc.), and so on.

Getting a proposal implemented and in use by real programmers
is an excellent way of addressing these concerns.  A number of
proposed language features sounded good but turned out to have
unanticipated consequences when used in real code.  (One feature
I'd still like to have -- in the abstract -- is delegation by
pointer, but when it was tried at AT&T it turned out that the
programmers who used it had frequent errors as a result, so it's
not part of the language.)  Short of that, a very thorough
analysis is required.

The Standard Committee is composed of people, nearly all of whom
have other responsibilities in addition to working on the
Standard.  As a result, 2-3 meetings a year for a week at a time
is all that's practical.  We're not trying to set an arbitrarily
high bar for submission of new features, but realistically if a
proposal comes along in the form, "It would be nice if C++
supported XXX," the response pretty much has to be "Thanks for
sharing your opinion."  Evaluating a proposed new feature is a
_lot_ of work, and proposals for which much of that work has
already been done will inevitably get a better reception than
those for which less has been done.

All that said, Bjarne wrote a very widely-distributed article on
how to submit a proposal to the Committee during the production
of the first Standard.  I imagine a similar approach will be
taken during the revision process.  We've actively solicited
public involvement during the defect resolution stage, and I'd
expect the same once we start the next revision.  All we're
saying is that we're resource-limited and need to be very
careful with what's approved, so if you have a proposal you
think is worthwhile, you need to help us to do the due
diligence on it.

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <TZRBaLACIKA6EwzL@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>-- But I realy thought to return that when those discussions for a new
>>C++ revision has been opened. :-)
>
>And several months ago I offered to arrange a public archive of worked
>out proposals.

This sounds like a good idea.

> There have been zero submissions so far. If you seriously
>want new things in the next release of C++ it will be far too late to
>sit around until the Standards Committees start considering it
>(standards are supposed to be driven by existing practice) Get your
>ideas published and continually visible now. Get an implementor (even
>better get two) to support it as an extension.

You know, I have already given up the hope of seeing C++ show up with the
feature I need, so I decided to write my own language. You and others out
there are encouraged to do likewise.

It will take a long time before one can do any decent programming in a
single language like C++: It would be better to be able to use a cluster
of languages; for my own needs, I think of C++, Java, and Haskell as a
basis.

C++ might play a role helping here, buy its "extern "<name>".." hook (see
other posts.

I merely graciously provide my observations from the point where I stand.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <XrVgWuARFIA6Eww6@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>In article <remove.haberg-0111001717550001@du137-226.ppp.su-
>anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>>Doubt it. :-)
>>
>>Please note that it will take some time filling those holes in C++, so
>>moving ahead soon will not really bother compiler developers too much.
>
>Are you volunteering to help with the work load?

Sure. I thought I was already helping a lot by this posts. :-)

> The Standards
>Committees already have enough work to keep them fully occupied, and
>many of those doing the work are 'lent' by companies who would not be
>happy by the destabilising affect of starting a new standard revision.

I have to finish off my own language too, first, which I just started
writing. We all are so busy. :-)

But first things first. First finishing off the details in the current
C++, and then let the new discussions come along. But startng in 1993
seems to be too far off, given the fast development of computers nowadays.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A016BFE.50AC64EF@abraxis.com>, eddielee@abraxis.com wrote:
>If the C++ language turns into a foray of promoted ideas rather
>than an attempt to make improvements to the language based on merit, I believe
>many others will feel the same way that I do in this matter.

Actually these are two entirely different processes. The current C++
suffers by too much of promoted ideas; the next task ahead is to first
"plug in holes".

In addition to that, one should seek to give C++ a coherent general
structure by a series of general umbrellas, which by specializations can
be of interests to many.

This process can be combined with the "plugging holes" process. For
example, C++ has a new (different from C) "string" paradigm. One would
then expect to be able to program new code in C++ without ever having to
revert to C strings, which is not possible in the case of opening files.
And it is not possible to open files with w_char strings, even though
there now are OS's admitting such filenames (by rumor, MacOS X & new
Windows).

The basic idea I want illustrate here though is that there is a general
concept, the C++ "string" paradigm, and it should be completed. Other such
general general concepts should identified, and made complete as well. New
additions to C++ should be added by adding a few such general concepts
which can be made complete.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Greg Brewer wrote:

> "Edward Diener" <eddielee@abraxis.com> wrote in message
> news:3A016BFE.50AC64EF@abraxis.com...
> > Francis Glassborow wrote:
> > I for one will be very disappointed if there is not a specific path set
> out for
> > individuals to submit new ideas and worked out proposals for the next C++
> > release to the Standards Committees. I don't believe that the individuals
> > should have to promote and politic those proposals as you suggest, but
> instead
>
> So if you aren't willing to put the time, energy, and money into promoting
> your idea, why should someone else.

I am willing to put the time and energy needed to present my "idea" and do the
work necessary to present my "proposal" to the Standards Committee when the time
rolls around to do so, through whatever accepted channel is specified. I don't
think I should ever have to run around trying to convince individuals of my
"idea" unless people showed an interest in what I might propose on a personal
basis. I realize that making a proposal is not the work of a sentence or two and
is a serious thing for others to scrutinize. What I was alarmed by was the
suggestion that I had to promote my idea in various ways to get any serious
consideration from the Standards committee. If the Standards committee were to
show no interest in my "idea" based on my "proposal", in whatever form they
decided I should submit it, it would not bother me greatly, and if they did show
interest in my "idea" but wanted further iunformation from me regarding it, I
would be glad to comply with their requests. But I don't think that I or anyone
should needs to play politics or cozy up to some committee member in order to
get one's proposal seriously considered. I think very highly of the work done by
the C++ standards committee but the proposal of changes to the C++ standard for
the next revision should be open to everyone on an equal basis.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3a0019ff$0$19232$1dc6d6e3@news.corecomm.net>, "CC Ghost"
<ccghst@erehwon.com> wrote:
>>>From the little of what I have seen of the current C++ standard
>>(ANSI/ISO/IEC 14882-1998), one needs to start the discussions on what
>>should be in the new revision as soon as possible, because there are too
>>many big holes in it.
>
>
>That's one way of looking at it. Here's
>another:
>
>Why rush to revise the standard *now* since
>
>1 - most compilers haven't implemented all
>of the last revision

Well, the new standard has to be there before the compilers can catch on. :-)

>2 - most vendors implement C and C++ is
>the same package (often the same compiler).
>Since they will also be working on compliance
>with C99, why not wait a bit, so we can deal
>with the inevitable problems this will cause.

Well, the development of other languages should really not be a concern
for limiting C++. And the C99 is relatively minor, so catching onto that
one should not really be so difficult.

>Patience is a virtue.

Doubt it. :-)

Please note that it will take some time filling those holes in C++, so
moving ahead soon will not really bother compiler developers too much.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Hans Aberg" <remove.haberg@matematik.su.se>:
> >From the little of what I have seen of the current C++ standard
> (ANSI/ISO/IEC 14882-1998), one needs to start the discussions on what
> should be in the new revision as soon as possible, because there are too
> many big holes in it.

Such as?

Sebastian Moleski
SurakWare
http://www.surakware.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8tpti9$407$06$1@news.t-online.com>, "Sebastian Moleski"
<smoleski@surakware.com> wrote:
>> >From the little of what I have seen of the current C++ standard
>> (ANSI/ISO/IEC 14882-1998), one needs to start the discussions on what
>> should be in the new revision as soon as possible, because there are too
>> many big holes in it.
>
>Such as?

If you look around some of the other posts, you will find some of them.
Apart from that, the classical ones, lack of finding the root system for a
CGC (conservative garbage collector), threading & distributed programming
support, portable assembler support, etc.

-- But I realy thought to return to that when those discussions for a new
C++ revision has been opened. :-)

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <remove.haberg-0111001717550001@du137-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>Doubt it. :-)
>
>Please note that it will take some time filling those holes in C++, so
>moving ahead soon will not really bother compiler developers too much.

Are you volunteering to help with the work load? The Standards
Committees already have enough work to keep them fully occupied, and
many of those doing the work are 'lent' by companies who would not be
happy by the destabilising affect of starting a new standard revision.


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

>From the little of what I have seen of the current C++ standard
(ANSI/ISO/IEC 14882-1998), one needs to start the discussions on what
should be in the new revision as soon as possible, because there are too
many big holes in it.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hans Aberg wrote in message ...
>>From the little of what I have seen of the current C++ standard
>(ANSI/ISO/IEC 14882-1998), one needs to start the discussions on what
>should be in the new revision as soon as possible, because there are too
>many big holes in it.


That's one way of looking at it. Here's
another:

Why rush to revise the standard *now* since

1 - most compilers haven't implemented all
of the last revision

2 - most vendors implement C and C++ is
the same package (often the same compiler).
Since they will also be working on compliance
with C99, why not wait a bit, so we can deal
with the inevitable problems this will cause.

Patience is a virtue.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]