In article <5L9reUAtloH7EwKG@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>... it means that if the components of C++ are made sufficiently
>>independent of each other, then one probably can add a lot of features.
>>But if the components start to collide, then it may sink, like that ship
>>Vasa.
>
>And a horribly large number of components of C++ interact through name
>look-up problems:(

This is an interesting thought: If in the implementing of a C++ compiler
the components can be sufficiently independent (most likely via some good
theory), then the C++ language can grow a lot, because the implementation
complexity will be relatively low, and so the implementation cost will not
grow so fast. But if these compiler implementation components interact
badly, the complexity will be large, and it will sink the whole project.

So the Vasa ship in the before mentioned picture is not really the C++
language, but the implementation of the C++ compilers.

  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                ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3B1E6C1B.7977D9E@wizard.net>...
> Paul Mensonides wrote:
> ...
> > justification for the committee.  By the way, what exactly are the *major*
> > differences between C++98 and ARM C++?  -> *mostly* clarifications.  Which I
> > agree was a big job for the committee, and the committee did add some very
> > useful constructs to the language, but not that many.
>
> Namespaces, RTTI, the specialized casts, 'bool', 'explicit', and
> 'export' were all added in C++98. The implications of 'export' are so
> extensive that very few implementations even support it now, nearly 3
> full years after the standard was approved. The changes made to iostream
> were so extensive that it was felt better to give it an entirely
> different standard header, and not even include <iostream.h> as a
> deprecated part of the library, much less a fully supported one.
>
> Templates and exceptions changed from a essentially experimental
> features to a major part of the language. It's arguably the case that
> ARM C++ was mainly about polymorphism, while C++98 is mainly about
> generic programming. That's an exaggeration, of course, but there's a
> fair amount of truth behind it. The changes to template handling were so
> extensive that, last time I checked, almost no one is fully implementing
> them yet; the biggest sticking point being template template parameters
> (which I have to admit, is a fairly low priority feature). Partial
> specialization of templates and templated member functions are a far
> higher priority with me, and there's still a number of implementations
> that don't support them yet.
>
> The single biggest change was that STL was merged into the standard
> library. You may argue that this is the library, not the language, but
> that distinction did nothing to reduce the workload caused by that
> addition. STL was a great idea, but putting it into shape to be
> standardized was a major task, one so big that it wasn't quite complete
> in time for the actual release of the standard. That's part of the
> reason a few things didn't make it in, such as hash tables. Describing
> the part that did make it in occupies about half (!) the 776 pages of
> the C++ standard.
>
> That's a lot more than "just clarification" as far as I'm concerned.
>
> ...
> > But once again, *not about timeline.*  I would love to join the committee,
> > however.  I don't have the resources to fly all over the world at this point.
>
> It depends upon your national committee, of course. In the US, you can
> join the J16 under NCITS as an Associate member, and get all the
> benefits of membership without any resposibilities beyond paying your
> membership fees. Only Principal members have a duty to accept work
> assignments and attend 2 of the three annual meetings.
>
> Question to committee members: the FAQ page suggests that individuals
> can join representing only themselves, but when I followed the links
> over to NCITS, I got the distinct impression that Principal members, at
> least, have to represent an organization. Is that correct?

There are interesting arguments being discussed on this posting at
comp.std.c, the posting of Douglas A. Gwyn is worth reading. That's in
big contrast with what Bjarne is saying, and I guess that to be the
predominant viewpoint of C gurus.

Kiril

---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

"Andrei Iltchenko" <iltchenko@yahoo.com> writes:

> > > Not only that, they also pour a lot of false information on their
> > customers
> > > and various other C++ users. Below is an excerpt from their C++
> Reference
> > > (Not Visual C++ reference) that they've been hosting on their msdn site
> > > (http://msdn.microsoft.com/library/default.asp) :
> > >
> > > <<quoting>>
> > > Templates are not officially standardized and, as a result, different
> C++
> >
> > When you make an accusation like this you should really back it up. The
> link
> > you give is, of course, that of the home page of the MSDN site. A search
> on
> > that site for "Templates are not officially" returns zero hits.  This
> maybe
> > a problem with the search engine Microsoft are using, or maybe the text
> you
> > quoted doesn't appear on their site. Please could you post the URL or
> > article refernce number for the text you are quoting.
>
> Gladly:
> http://msdn.microsoft.com/library/default.asp
>
> then select:
> Visual Studio 6.0 Documentation
>     Visual C++ Documentation
>         Reference
>             C/C++ Language and C++ libraries
>                 C++ Language reference
>                     Declarations
>                         Template Specifications
>                             Differences from Other Implementations

Or, to get there in one step:
http://msdn.microsoft.com/library/devprods\vs6\visualc/vclang/_pluslang_differences_from_other_implementations.htm

The HTTP server says it was last modified in December '00, but that
may not mean anything.  This is part of the VC++ 6 reference, and I
don't remember when VC++ was released; this may be an ancient Web page
that was written before the C++ standard was officially released in
1998.

(Although it would be a bit misleading even so: the Final Draft
International Standard was completed in 1997, and, while the FDIS
didn't officially have the status of a standard, it was known and
publicized that the official standard would not differ from the FDIS
in any substandive way.)


---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

On Wed,  6 Jun 2001 20:15:01 GMT, Balog Pal (mh) <pasa@lib.hu> wrote:
[=B7=B7=B7]
> The "what is the element count of a C-style array" was the perfect exam=
ple
> to that, I think. C and C++ should have had a sizeof-like operator tell=
ing
> that from the very beginning, but C covered it with a common-used macro
> (probably one doing undefined behavior, but working for most cases, hm)=
,

This particular idiom actually has perfectly defined behavior.

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

Here's the most pertinent article from Microsoft's Knowledge Base:

    "INFO: C++ Standard Noncompliance Issues with Visual C++ 6.0"
    http://support.microsoft.com/support/kb/articles/Q243/4/51.ASP

This article was "last reviewed" on 4 May 2001, although I haven't noticed
any changes in it over the last years or so. While Microsoft has introduced
5 "service packs" for their compiler, little has been done to bring Visual
C++ into compliance with Standard C++. The compiler itself is now several
years old, and my experience with Visual Studio.NET suggests that compliance
with ISO/ANSI is not high on Microsoft's list of priorities.

For Wintel platforms, I prefer Intel C++ 5.0.

--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
http://www.coyotegulch.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                ]

In article <bkAT6.406282$o9.64115792@typhoon.tampabay.rr.com>
 "Scott Robert Ladd" <scott@coyotegulch.com> wrote:

> [...] The compiler itself is now several
> years old, and my experience with Visual Studio.NET suggests
> that compliance with ISO/ANSI is not high on Microsoft's list
> of priorities.
>
> For Wintel platforms, I prefer Intel C++ 5.0.

Producing correct code isn't high on Intel's list of priorities.

-- Barry

--
  One must sometimes choose between expressiveness, safety, and
  performance. But a scarcity of one isn't always excused by an
  abundance of another. - Thant Tessman
NNQ - Quoting Style in Newsgroup Postings
  http://web.infoave.net/~dcalhoun/nnq/nquote.html

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

"Matthew Austern" <austern@research.att.com> wrote in message
news:diln17lz2kf.fsf@isolde.research.att.com...
> "Andrei Iltchenko" <iltchenko@yahoo.com> writes:
>
> > > > Not only that, they also pour a lot of false information on their
> > > customers
> > > > and various other C++ users. Below is an excerpt from their C++
> > Reference
> > > > (Not Visual C++ reference) that they've been hosting on their msdn
site
> > > > (http://msdn.microsoft.com/library/default.asp) :
> > > >
> > > > <<quoting>>
> > > > Templates are not officially standardized and, as a result,
different
> > C++
> > >
> > > When you make an accusation like this you should really back it up.
The
> > link
> > > you give is, of course, that of the home page of the MSDN site. A
search
> > on
> > > that site for "Templates are not officially" returns zero hits.  This
> > maybe
> > > a problem with the search engine Microsoft are using, or maybe the
text
> > you
> > > quoted doesn't appear on their site. Please could you post the URL or
> > > article refernce number for the text you are quoting.
> >
> > Gladly:
> > http://msdn.microsoft.com/library/default.asp
> >
> > then select:
> > Visual Studio 6.0 Documentation
> >     Visual C++ Documentation
> >         Reference
> >             C/C++ Language and C++ libraries
> >                 C++ Language reference
> >                     Declarations
> >                         Template Specifications
> >                             Differences from Other Implementations
>
> Or, to get there in one step:
>
http://msdn.microsoft.com/library/devprods\vs6\visualc/vclang/_pluslang_diff
erences_from_other_implementations.htm
>
> The HTTP server says it was last modified in December '00, but that
> may not mean anything.  This is part of the VC++ 6 reference, and I
> don't remember when VC++ was released; this may be an ancient Web page
> that was written before the C++ standard was officially released in
> 1998.

VC 6.0 was released in the autumn of 1998, just a few weeks after the
international standard for C++ had been ratified and almost a year after it
had been adopted. Whatever way you choose to look at their phrase that
"Templates are not officially standardized", it is inaccurate and very
misleading, since it tacitly puts an uninformed reader off looking for a
better C++ implementation.


> (Although it would be a bit misleading even so: the Final Draft
> International Standard was completed in 1997, and, while the FDIS
> didn't officially have the status of a standard, it was known and
> publicized that the official standard would not differ from the FDIS
> in any substandive way.)


Andrei.



---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

"Bjarne Stroustrup" <bs@research.att.com> wrote in message
news:GEF7t1.MEz@research.att.com...
>
> I left these long quotes because I think the points made are interesting
> and worth re-reading. Like Steve, I recommend a visit to the Vasa - I find
> it both beautiful and thought provoking.
>
> However, we must always remember that proof by analogy is fraud.
>
> It is a simple fact that ships with many more guns and equal amount of
> decorative features ruled the seas during the 250 years that followed
> the Vasa. In particular, soon after the demise of the Vasa, no ship with
> fewer guns would be considered major.
>
> What was wrong with the Vasa was not the "features" as such, but that
> they were added on a on a foundation (hull) that was ever so slightly
> too short and narrow. I have been told that had the Vasa been one meter
> wider and a couple of meters longer to match, it would have been superbly
> seaworthy.
>
> Remember also, that in the context of 17th century "gun boat" politics,
> even the guilded statues had a real function - one important job of a
> top ship of the line was to be impressive when visiting a harbour and
> enhance the status of the dignitaries and diplomats it would often carry.
>
> In our Vasa/C++ analogy, this implies that we should not be scared of
> adding feature in general - some new features are useful. What is considered
> a "new feature" and a luxury can become essential. What we must do is to
> take great care not to add features without adding the fundamental support
> that such features require. I am particularly concerned that additions lead
> to a language that is easier to describe, teach, and debug (e.g. allow
> compilers to generate better error messages).

What about easier to use?  That is also a valid goal.  I disagree fundamentally
with those that say C++ is extremely hard to teach.  "Design" may be hard to
teach, but C++ is just a collection of tools and syntax to build elaborate
designs:  each of which is very different, though with a few similarities.  That
is what makes debugging harder--every program is different and, of course, must
be.  In this however, C++ is no different of significantly more complicated than
any other language.  Debugging and maintenance is further complicated by the
simple fact that so many people work only for their paychecks and not to take
pride in what the do or in the designs that they create.  Even when they do,
many times they don't care whether someone else later can understand what they
did.  They mostly just want to finish the task.  There is no "art" in that (or
elegance, to use your word, Bjarne) kind of attitude.  In some cases people are
even proud that other people can't understand what they did.  Therein lies the
biggest problem, as far as language complexity goes, not that C++ has n^2
operators or that C++ has 101 different types of delimiters {'(<["etc."]>)'},
but because people don't really care about how it works, just that it does work.
Obviously, this does not apply in every case.  Many of the people on this
newsgroup (and others) are here *because* they care.  Many of the people on the
committee are there *because* they care, but as far as teaching goes, people
don't learn well what they don't love.  It is as simple as that.  The greatest
problem of all is teaching programming ethics.  (lazy C-style casts and massive
macro use are unethical in my opinion, but I don't think that makes them *bad*
intrinsically, they should be used only when necessary)

> > Because C++ already exists, and has flourished, it won't die immediately
> > from addition of new features, particularly if the new features carry no
> > cost to those programs and programmers which don't use them. However,
> > most changes have more costs than their advocates realize.
>
> Exactly.

While this is true generally speaking, this leads to applying this ideal
unilaterally.  Those on the committee need to keep in mind that just because
some "idea" may cause problems in this area or that doesn't mean that a
variation of the idea won't work or that the idea itself is invalid or flawed
(in the context of C++ of course).

> > If nothing
> > else, each new feature adds to the options an analyst needs to consider
> > when designing a program, and adds to the number of things a coder must
> > be able to understand when reading code written by someone else. If too
> > many such changes are made, people will refuse to advance to the latest
> > version of C++, or will abandon it in favor of simpler languages.
>
> I don't think this scenario is likely given the number of changes that
> are likely to make it into a new standard - the process of acceptance
> is far more demanding than several paricipants of std.comp.c++ seem
> willing to believe.
>
> "Simpler languages" is a nice slogan for a new language, but once a language
> sees significant real-world use, abstract simplity is invariable sacrificed
> to "what it takes to get the job done".
>
> One could equally well argue that unless C++ evolves to meet new challenges
> it will die as people move to languages that provide the facilities needed
> for "modern programming". Naturally, we will hear both argument a lot over
> the coming years.
>

It is a balance, of course, between adding a lot and adding very little.  I
agree that can be a difficult, but not insurmountable, question.  If you add too
much too soon the language will decline.  Conversely, if you add too little too
late the language will also decline.

> > It
> > wouldn't be a quick death like that of the Vasa, but it would slowly die
> > off. The slowness of the death means that there would be time to
> > re-consider any given change, but it can be very difficult to retract a
> > change once it's been made official.
>
> Features in use are essentially impossible to remove. Even if officially
> banned, they live on in "backwards compatibility modes". What we can do
> is to provide alternatives to warts and discourage use of warts.
>
>
> > Agreed: new features should not be summarily disregarded. They should be
> > very carefully considered, and the fact that they are new should
> > properly be held against then. The burden of proof is on the proposer of
> > the change to show that the advantages of the change outweigh the
> > disadvantages, keeping in mind that any change carries, in addition to
> > any other disadvantages, the disadvantages of being a change.
>
> I recommend the list of concerns that I listed in the "Standardization"
> chapter of D&E. If anything the criteria that will be applied for C++0x
> will be stricter and more comprehensive.
>

Speaking of your book, I think that a lot of people outside the committee would
like to know *why* certain features were accepted or declined in more detail.
I'm not speaking to you personally, Bjarne, rather to the committee as a whole.
I think such a thing would be a learning experience for all of us and make us a
little more qualified to be arguing (good, healthy arguing, of course) over
these various issues.

> > Simplifying the language is one possible compensating advantage, but
> > "new features" almost never actually simplify something.
>
> People rarely bother to define what they mean when they say "simplify".
> I'd like to see simplifications in two areas:
>
> (1) making code for common problems cleaner, more direct, more
> maintainable (without loss of run-time efficiency).
> (2) making the description of language and library features
> more uniform, general, and regular.

I'd like to see simplifications more along the lines of orthogonality.  i.e. all
the different rules for template classes vs. template functions, etc.  I'd
donate a month's paycheck for overloading . and .* and an alternate semantics
for ->* similar to -> or closures. :) The same goes for assignment operators, if
one must be a member than all should have to be members or vice-versa.  I think
changes that make things more orthogonal significantly reduce the complexity of
the language.  main() should not have an implicit "return 0" or main() should be
able to return void.  You have more "general principals" rather than a whole
bunch of special cases.  Which is much easier to learn.

> (1) is likely to involve major extensions of the standard library and a few
> minor language extensions. (2) could in theory be achieved by removing
> rarely used features and making incompatible changes - however, I consider
> that most unlikely. Compatibility is - quite rightly - a major concern,
> so only very few incompatible changes will be made. However, generalizations
> of rules could lead to simulatanious simplification of the description and
> addition to the facilities offered.
>
>
> > C++ will never be finished. It will someday, like most things, die of
> > natural causes without ever having been completely finished, without
> > ever have been exactly perfect. However, it's at least as likely to die
> > from have been made over-complicated, as to die from not having been
> > changed frequently enough.
>
> Making changes is a balancing act. You can "fall off the wire" in either
> direction. I'm not going to guess which side is the more likely, but I
> do think that changes will happen and that some changes could be to the
> better.

I definitely agree with you here.

> I repeat: I see the standard library as the most promising area for
> extensions, rather than the core language.

Currently, I work with Visual C++ (aaah).  Nothing irritates me more daily that
Microsoft's lazy attitude toward conformance.  But some things are *guaranteed*.
If the committee only enhances the library and cleans up some of the wording in
the standard, companies like MS will move on without them.  This cannot be
underestimated as far the future of C++ is concerned.  For to many Windows
programmers, VC++ == C++, which is unfortunate but true.  I was one of the
stalwart few arguing with some of the developers and project managers of VC++ on
microsoft.public.dotnet.languages.vc.  Despite everything they say about how
much they *care* about conformance, VC7 still doesn't support template template
parameters.  Half of the ideas in Andrei's book I can't compile because MS went
its own way.  If the committee doesn't do enough (core language wise) this
situation will worsen.  Which, though I know you're a UNIX guy, Bjarne, is
extremely significant for the future of C++.  Most people don't walk around with
UNIX clones on their laptop computers.  When I was arguing with the VC team on
the newsgroup above, I (and a few others) repeatedly said, "Why don't you
support this or that part of the standard," and the response was generally some
derivative of "People want this more instead,..." "Because we implemented this
instead,..." and occasionally "But we'd have to overhaul our symbol table
mechanics!"  Obviously, Microsoft should not dictate what C++ should be become,
but that is what I foresee if C++ doesn't do "enough" by itself.

Say, for example that C++0x gives us a pattern matching library, a distributed
computing library (as opposed to "threads" :)), and maybe a few other library
facilities (which are all well and good, and I agree those features are
"library-like" features).  Lets say we even get "typeof" and vector<vector<int>>
with no space!  Nearly all of which is easy for Microsoft to implement for MS
Windows--since VC++ is only for Windows.  By that time, MS better actually have
implemented template template parameters, etc..  So what does MS do?  Extend C++
*even more than it already has* in ways that are even worse than those
"extensions" it already supports.  Given that (which WILL happen) there will be
two classes of C++:  Standard C++ and a dialect of C++ called "My C++" that half
the people on Earth use.  Then we'll get C++ compilers for other platforms such
as UNIX that support most or all of Microsoft's extensions.  Eventually, more
and more programmers and companies will be sucked into the proprietary Microsoft
abyss until "Standard C++" hardly exists, and if not MS than some other company.
That is the emminent doom of Standard C++ that I see as the most likely of all,
regardless of this extension or another.  Unfortunately, marketing (speaking of
something that is inherently unethical) cannot be underrated (need I mention
Java?).

The other plausible situation is that C++ is superceded by C3 and some other
standards body.  Are we then going to get separate C/C++/C3 languages, each with
their own standards committee.  Is the C++ committee going to keep hanging
around because it refuses to update?  That brings to mind the original topic of
this thread:  C vs. C++.  I agree that the committees should be merged, but it
won't happen because the C committee will refuse to change/acknowledge new (as
in, old, by this time) paradigms.  I forsee the same thing happening with the
C++ committee at some point down the road.

> The discussions here and elsewhere about the future of C++ are interesting
> and helpful - necessary, in fact - but try to maintain a perspective:
> Doing anything significant takes time, more time than we'd prefer, but
> we do have the time: C++ is not suddenly going to disappear.

I agree that change must be made over time, and that that is a product of
necessity rather than what we'd like.  But though C++ won't just disappear, many
of us will.  Unfortunately, for the rest of us, Bjarne, C++ isn't the brainchild
that will "live on after us," it is a tool that we use to design our own
"inventions" and legacies (however small they may be).  For those of who use it
with the "artistic" streak that I mentioned above, the tools that we use and the
enjoyment that we have using those tools to design becomes just as, if not more,
important than the finished product.

> - Bjarne
> Bjarne Stroustrup - http://www.research.att.com/~bs

By the way, any word on the ARM++?  I think that's something a lot of us want to
see. :)

Paul Mensonides

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

In article <rWUS6.109420$p33.2312036@news1.sttls1.wa.home.com>, Paul
Mensonides <pmenso57@home.com> writes
>My point is that C++ needs to
>be going somewhere *consistently* (whether that's every five years or ten)
>rather than statically remaining more-or-less where it is.  That would be the #1
>way to date the language and cause a minimization of use.

And that is where I would disagree with you. C++ does not need to be
going anywhere as such. If there are major improvements that we can
make, then we should do so (and probably will) but not making major
change is not in itself bad.

BTW, the point I was making is that one of the causes of slowness is
exactly that it takes time to consider changes and select those where
the cost-benefit comes out on the right side. If you never had to do
such a thing, change would be quick.


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

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

In article <GEGLJK.K1D@research.att.com>,
bs@research.att.com (Bjarne Stroustrup) writes:
|> "Scott Robert Ladd" <scott@coyotegulch.com> writes
|>
|> > > In which ways do two separate but closely related languages
|> > > maintaining divergent evolutions controlled by separate committees
|> > > help the C and C++ programming communities (or is that the C and
|> > > C++ programming community)?
|> >
|> > We have two distinct communities, for C and C++, divided more by tradition
|> > and philosophy than by any practical considerations. I think of this
|> > as a religious schism -- and for better or worse, we're stuck with it.
|>
|> Maybe. Do we really have two distinct communities?
|>
|> There are clearly many people who use C, but never C++. Some of those seem
|> to hate C++; I blame fear and ignorance.

That is my experience.  I certainly have heard rational arguments
why C++ is a bad idea, but most of those people will argue that C is
equally bad in slightly different ways :-)

I haven't yet learnt C++ - sorry! - but time, time ....

|> Similarly, there are clearly people who use C++, but never C. Some of those
|> seem to despise C; I blame arrogance.

That seems fair.

|> Who benefits from having C and C++ as separate languages controlled by
|> separate committees, and separately evolving to meet challenges?

Nobody that I can think of.  Quite a lot of people would benefit if
things were different, but they aren't.

|> I can think of one group only (though undoubtedly there must be more):
|> vendors of C implementations and C libraries who do not have a share in
|> the C++ market. Plus the vendors of competing languages, of course.

The former category would generally like C to be frozen, as they
usually want it for specific purposes, and the baggage added at C99
(and even quite a lot of that added at C90) is as much a disadvantage
for them as the C++ facilities.

|> One interesting question is: Does a forum exist where we can calmly discuss
|> the joint futures of C and C++. I think not - people with strong emotions
|> tend to drown out the cooler heads. Could such a forum exist? Probably, but
|> it would have to be smaller and consist of people with strong stakes in the
|> future of the language - or in a merged language.

I don't know.  There should be.

|> Don't forget the pressure for C++ to conform to whatever the C committee
|> votes into C. There are *many* who considers "it is in C99" a conclusive
|> argument for inclusion into C++0x. And even if you don't, the pressure it
|> there. There is a corresponding temptation to try to add features from C++
|> deemed useful into C.

God help me, there were several broken features that couldn't be
fixed because of a supposed compatibility problem with C++.  That
is NOT clever.

|> The problem is that C tends to provide specialized solutions to problems
|> for which C++ provides general solutions (e.g.
|>  new initializer facilities vs. constructors,
|>  atexit() vs. destructors,
|>  _Complex vs. the class mechanisms that allows C++ to provide complex,
|>  VLAs (and their associated pointers) vs. vector,
|>  void* with unsafe implicit conversions vs. void*).
|> Thus separate evolution leads to duplication of facilities and to complexity
|> for the users of both languages.

Yes and no.  I haven't looked at C++ recently, but I thought that
it had taken the Iliffe vector route for variable array types - and
that is BAD NEWS for HPC and inter-language compatibility.  There
are other, similar problems in other areas.  What USED to be the
advantage of C over C++ was that it was a stripped-down language,
suitable for uses when you needed to get pretty close to the bare
metal for efficiency, system control or because you needed to
interface to other languages.  It still is true, to some extent,
but much less so than it used to be.

|> Thus good will isn't enough. There has to be a framework in which such good
|> will can thrive. My view is that only a merged C and C++ committee can provide
|> such a forum and framework.

Yes, I agree.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

"Paul Mensonides" <pmenso57@home.com> wrote in message
news:6xWS6.109902$p33.2325943@news1.sttls1.wa.home.com...
>
> "Bjarne Stroustrup" <bs@research.att.com> wrote in message
> news:GEF7t1.MEz@research.att.com...
>
> Currently, I work with Visual C++ (aaah).  Nothing irritates me more daily
that
> Microsoft's lazy attitude toward conformance.  But some things are
*guaranteed*.
> If the committee only enhances the library and cleans up some of the
wording in
> the standard, companies like MS will move on without them.  This cannot be
> underestimated as far the future of C++ is concerned.  For to many Windows
> programmers, VC++ == C++, which is unfortunate but true.  I was one of the
> stalwart few arguing with some of the developers and project managers of
VC++ on
> microsoft.public.dotnet.languages.vc.  Despite everything they say about
how
> much they *care* about conformance, VC7 still doesn't support template
template
> parameters.

Not only that, they also pour a lot of false information on their customers
and various other C++ users. Below is an excerpt from their C++ Reference
(Not Visual C++ reference) that they've been hosting on their msdn site
(http://msdn.microsoft.com/library/default.asp) :

<<quoting>>
Templates are not officially standardized and, as a result, different C++
compiler vendors have implemented them differently. The following list shows
some differences between this version of Visual C++ and other compilers.
Note that this list will change in future versions of the compiler.

* The compiler cannot instantiate a template outside of the module in which
it is defined.
* Templates cannot be used with functions declared with __declspec
(dllimport) or __declspec (dllexport).
* All template arguments must be of an unambiguous type that exactly matches
that of the template parameter list. For example:
template< class T > T check( T );
template< class S > void watch( int (*)(S) );
watch( check );     //error

* The compiler should instantiate the check templated function in the form
int check( int ), but the inference can not be followed.
* Friend functions must be declared before they are used in a templated
class. You cannot have a friend function defined within a class definition.
This is because the friend function could be a templated function, which
would cause an illegal nested template definition.
<<end quoting>>

You see, according to them the the C++ ISO standardization committee hasn't
yet gone through with standardizing templates. I wonder why the committee
hasn't started a legal action.


Regards,

Andrei Iltchenko.


---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:s8heT$Ac6PH7Ewbl@ntlworld.com...
> In article <rWUS6.109420$p33.2312036@news1.sttls1.wa.home.com>, Paul
> Mensonides <pmenso57@home.com> writes
> >My point is that C++ needs to
> >be going somewhere *consistently* (whether that's every five years or ten)
> >rather than statically remaining more-or-less where it is.  That would be the
#1
> >way to date the language and cause a minimization of use.
>
> And that is where I would disagree with you. C++ does not need to be
> going anywhere as such. If there are major improvements that we can
> make, then we should do so (and probably will) but not making major
> change is not in itself bad.

My point is that C++ will be replaced as the predominate systems programming
language if it isn't going somewhere--i.e. improving.  I'm not talking about
being replaced by Java or something like that.  I'm talking about a C++front,
then full compiler/linkers, etc..

> BTW, the point I was making is that one of the causes of slowness is
> exactly that it takes time to consider changes and select those where
> the cost-benefit comes out on the right side. If you never had to do
> such a thing, change would be quick.

I've repeatedly reiterated that I'm not speaking in terms of any time scale.
Just so that we are clear, what "long" and "short" periods of time are you
referring to?  My major point is that C++ must be constantly (i.e. standard to
standard) improving.  Maybe C++0x should contain only minor new language
features, maybe it shouldn't.  That is not my point.  Complacency is far worse
that change.

Paul Mensonides

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

"James Kuyper Jr." <kuyper@wizard.net> wrote in message
news:3B1C3F1F.36356BFB@wizard.net...
> Paul Mensonides wrote:
> >
> > "James Kuyper Jr." <kuyper@wizard.net> wrote in message
> > news:3B1ABF7C.E27F7A45@wizard.net...
> > > Paul Mensonides wrote:
> ...
> > > What were you imaginging as the easily extendible foundation on which to
> > > build C++?
> >
> > You don't pay for what you don't use.  Rather than you don't get what you
don't
> > need.
>
> Well, I have to agree, the Vasa story is a horrible analogy for
> expressing that idea. Let's stick with mine interpretation, for which
> the Vasa story is a pretty good analogy.
>
> ...
> > That remains to be seen in C++0x, but it is far more likely to have very
minor
> > changes to the core language only.  In my opinion, the core language *is*
C++,
> > and the standard library is exactly what it is called a "standard library."
>
> We've had this discussion recently. The standard very clearly calls C++
> a language, but it also very clearly states that C++ has both a language
> and a library. I don't want to debate the question of what's the
> language and what's the library. The C++ standard defines both; it
> clearly distinguishes them, and yet simultaneously ties them together.
> There's not really a whole lot more that's worth saying about that
> relationship.
>
> ...
> > kind of modern editor).  Whether a change automatically defaults to a
negative
> > argument depends much more on the feature proposed than the fact that it is
new.
>
> Agreed, yet it should depend partly on the fact that it is new, and in a
> negative sense. Ignoring the very real costs of change is a serious
> mistake, overestimating them is another serious mistake.
>
> ...
> > Exactly, the analogy is extremely poor and doesn't relate to C++, which is
my
> > point.  C++ is *not* a ship.
>
> It doesn't have to be a ship, for the analogy to apply. Analogies are
> not identities, so showing that the identity doesn't hold doesn't
> invalidate the analogy. You've got to show that the analogy doesn't
> hold, then you can invalidate the conclusion drawn from it.

An analogy doesn't *apply* it just marks a noted commonality but doesn't prove
anything and shouldn't be used as an argument.

> In this particular case, the analogy is that C++ has many features, as
> did the Vasa, and that C++ needs to be understandable by it's users,
> just as the Vasa needed to be supportable by the water it displaced. If
> too many features are added to C++, it will cease to be understandable,
> and fail, just as the Vasa failed when too many features were added to
> it, so that was no longer supportable by the water it displaced. The
> analogy fails, in that you can increase the amount of water a ship
> displaces by making it bigger (within limits); there's no comparable way
> of significantly increasing the amount of complexity the average
> programmer can handle. That's hardly a difference that renders the
> conclusion invalid: that we must avoid making C++ so complex that it
> fails. If anything, that difference reinforces the conclusion - it
> removes one possible alternative strategy for dealing with the problem.
>
>
> ...
> > > You're advancing a "straw man" argument; no one's suggested that only
> > > "absolutely necessary" changes be made. I specifically said that the
> > > advantages must outweigh the disadvantages; a criterion that applies
> > > equally easily to new features or defect fixes.
> >
> > Oh really?  What about the great multiple inheritance example with two
virtual
> > functions from separate base classes with the same name?  The biggest reason
> > that the proposed resolution wasn't accepted was because it wasn't
"absolutely
> > necessary."
>
> Can you give me a URL for retrieving the relevant thread from Google? A
> search of comp.std.c++ for "absolutely necessary" turned up exactly 12
> messages, none of which seemed relevant to the issue you describe, all
> of which were actually from comp.std.c (just what we need - another
> search engine that can't tell the difference between c and c++!). So I
> assume you're summarizing their argument, rather than quoting it. My
> other searches turned up nothing particularly useful.

"The Design and Evolution of C++" --Bjarne Stroustrup (pg. 273-274)

> ...
> > If you don't understand how a hammer works (for another bad analogy :)) you
> > shouldn't be using one.  You don't have to be one of the extremely smart
few.
>
> I think you're bringing an attitude to C++, that if adopted into the
> standard, would condemn the language into the obscurity of a being a
> language only the elite can use. On the other hand, if I understand you
> correctly, you don't see that as a disadvantage. I do. The only things
> that need to be standardized are widely used things; I'm interested in
> the C++ standard precisely because I see C++ as a general purpose
> language. Combined with the right application-specific libraries, it can
> do just about anything.

That isn't what I'm saying at all.  C++ can be learned fairly easily.
"Programming" is not learned as easily, and that is where C++ is not much
different than any other language.  But the root difference is between those
that care to understand rather than don't.  Absolutely, I don't think C++ needs
everything under the sun that makes programming in other languages simpler, but
there are many things that could be added that *are* general purpose.  Consider
multi-methods, which open the door to non-member polymorphism which isn't
directly supported in C++ at all.  That is pretty general.  By the way, a design
that uses "faked" multi-methods (via a double dispatch or function pointer
tables) is significantly more complicated to understand than built-in
multi-methods.

> > You only have to care about it enough to *try* to learn it.  It is not that
> > complicated.  The real complication comes from the way various features can
be
> > used to create elaborate programs, which is something that you *cannot* get
away
> > from--no matter what language you use.
>
> There's a minimum unavoidable complexity of any algorithm; that
> complexity can only be shifted around (which might, however, be a very
> desirable thing to do!), but it can't be removed. However, an overly
> complex language can add enormously to that minimum complexity. For
> example, if a language provides five different ways of doing exactly the
> same thing, a programmer has to waste time recognizing (and learning to
> recognize!) all five. It's even worse if the five are not really exactly
> the same, but only almost the same.
> That's precisely why it's a significant problem when proposed new syntax
> provides nothing more than a minor convenience, at the cost of creating
> a whole new way of doing precisely the same thing.

I'm not talking specifically about algorithms.  I'm talking about program
structure as well.  Good design principles, etc., as well as a good dose of
ethics.

> ...
> > agree that C++ is a small part of a much larger computer world.  Yet C++, or
> > low-level programming in general, will have a very significant place for a
> > *long* time yet.
>
> I agree - that's why I said "someday"; I think it will be at least a
> couple of decades, which is a very long time by computer industry
> standards.
>
> > The "average" programmer uses VB because C++ (for them) is too complicated.
I
> > say, "good riddance."  That increases my value automatically.  The point of
C++
> > is not a competition for the largest number of "religious" users.  "C++ is a
> > general-purpose programming language with a bias toward systems
programming...."
> > Systems programming == complicated (in most cases).  C++ is not a language
for
> > *average* programmers, since it is already out of that league entirely.
>
> The primary focus of that statement is "general-purpose", the comment
> about "systems programming" was only a bias away from the the primary
> focus. "general-purpose" most definitely means that the language is
> intended for average programmers. I'll agree that it a little too
> complicated for that target audience, but I disagree that it's entirely
> "out of that league".

How much "average" programmers understand has declined.  I'm not talking about
what an "average" programmer should know or understand, but what they actually
do know and understand.  VB (for example) all by itself knocks that number down
quite a bit.  A language that is capable of low-level constructs is absolutely
"out of that league" if you consider that Visual Basic, Java, (etc.) programmers
are included in that "average" calculation.  On a side note, that is exactly why
new programmers should stay away from high-level languages at first.  They need
to understand what the *language* is doing for them behind the scenes.  What a
language does "behind the scenes" is becoming less and less understood by the
"average" programmer.

> ...
> > Once again, these are problems and ambiguities mostly in the standard
itself.
>
> My point was that if even experts disagree, ordinary users must surely
> be confused.
>
> > Also, they are problems that are not as generally important to real-world
> > problems as one might think, since overloading (and consequently name
lookup) is
> > also syntactic sugar.  Do you wish overloading never existed?  It doesn't
*do*
> > anything at all--except add complication.
>
> I like overloading, I find it a very useful feature of the language, but
> it does require overload resolution, and I don't see any good way to
> make the rules for overload resolution significantly simpler than they
> are. That's an unavoidable cost, but still a cost.

That is my point.  I like overloading too and think it's a neat feature.
However, given what seems to be the current state of mind of many of the more
well-known members of the committee, a feature like that would *never* be
accepted into C++ nowadays.

> > > The way in which an overly complex language manifests that fact is
> > > through people's misuse of it. You can always blame the programmer for
> > > not understanding, but if there are too many programmers failing to
> > > understand it, and too many other programmers avoiding failure by
> > > avoiding the language, then the language itself is too complex. I'm not
> > > saying that C++ is there yet, but if too many features are added in the
> > > next round of standardization, it will get there.
> ...
> > You cannot blame a language for that, no matter how complex it is.  Bad
design
> > is possible in any language--that is not the province of a standard
committee.
>
> Bad design is not just a problem of programs, it is also an issue for
> the language itself, and overly complex design is one of many forms that
> bad design takes. Excess complexity is just as bad an idea for a
> language as for a program, and for much the same reasons.

Yes, I agree, but it is *much*, *much* easier to make an incoherent program than
to add features to a well known language thereby making it incoherent.

> ...
> > or shouldn't be part of the language.  I'll put it a different way:  if the
> > committee only adds a few library features, very minor core language
> > enhancements, and a few clarifications/corrections to what is already
currently
> > in the standard, what is the point of me (or anyone else) caring about the
> > standard when it takes them so long to do very little?  It has to be *worth*
the
> > wait to justify its existence.  I'll give you an example that many people
want
>
> What justifies the language's existence is the current features. Updates
> to the standard require far less justification. If the current features
> of C++ aren't already pretty attractive to you, then you should be
> looking for a different language. The next release of the standard is
> going to be a matter of evolution, not revolution. That may be boring,
> just like it's boring to keep a car for no better reason that that
> there's nothing significantly wrong with it. It's certainly a lot more
> exciting to trade in your car every other year for a brand new one, as
> some people do. That doesn't mean its a good idea. I'm not saying that
> C++ doesn't need some fixing: it needs a lot more fixing than my car
> does. I'm just saying that the differences between C++0x and C++98
> should (and probably will) be smaller than the differences between C++98
> and ARM C++.

I am not talking about the justification for the language; I'm talking about the
justification for the committee.  By the way, what exactly are the *major*
differences between C++98 and ARM C++?  -> *mostly* clarifications.  Which I
agree was a big job for the committee, and the committee did add some very
useful constructs to the language, but not that many.

Bad analogies just keep piling up!  Take a computer instead of a car!
Typically, you'd like to upgrade that every year, and possibly even quicker if
you could.  Also, we are not talking about replacement here, we are talking
about "upgrading."  People that really care about cars often upgrade them (even
on a yearly basis).  By the way, C++98 wasn't a revolution either, or for that
matter really a huge evolution.

> Incidentally, one of the key things that seriously restricts the ability
> of the committee to consider rapid change to the language is a shortage
> of workers. If you think it should change faster, you should consider
> joining and volunteering for some of the work. See the FAQ link at the
> bottom of the page to find out how. The membership fees are a bit high,
> but most programmers shouldn't find them prohibitive, at least if you
> care that much about the language.

The most key thing that restricts the committee is that it is a committee!
But once again, *not about timeline.*  I would love to join the committee,
however.  I don't have the resources to fly all over the world at this point.
But maybe someday in the future I will--hopefully it won't be an extended C++
with a new name by then.

> > (which I only really want for a few reasons, this example being one of them
> > (orthagonalness <--is that a word?), the other being operator new.):
>
> orthogonality.

Yes. :)

Paul Mensonides

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

James Kuyper Jr. wrote in message <3B1A33E4.27D935E9@wizard.net>...

>This kind of mistake need not be restricted to the maiden voyage. Any
>time that you add to the load a ship must carry, you may end up
>overloading it. It's just more ironic when it happens that early in a
>ship's life.


A good thought. I just can't figure out if we're talking about the future or
the past connecting to C++.

Considering the number of "C++ compilers conforming the standard" this very
moment there must have been a problem with featires added to the standard.
The overall design, even if not turned out top-heavy apperas slipping by
implementors.

OTOH, we speak about not adding new featires for all those dangers. I see
quite an imbalance here. Quite a plenty of suggestions arrive that are
trivial to easy in the implementation, and are rejected. I may be completely
mistaken, but it seems like several dozens of tiny additions could be
implemented faster than the single export of templates, a feature impacting
just the build time, not the overall safety or clarity of the code to be
written.

That general "adding features is dangerous" stuff should not inhibit new
features being added, just work out a good scoring system, that can tell the
difference, whether the existing hacks that are used to circumwent tha lack
of it are better than having it solver with direct support, and what real
cost it invokes on the compiler makers and existing code maintainers.

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                ]

In article <axDS6.106141$p33.2245719@news1.sttls1.wa.home.com>, Paul
Mensonides <pmenso57@home.com> writes
>I'll put it a different way:  if the
>committee only adds a few library features, very minor core language
>enhancements, and a few clarifications/corrections to what is already currently
>in the standard, what is the point of me (or anyone else) caring about the
>standard when it takes them so long to do very little?  It has to be *worth* the
>wait to justify its existence.

It is easy, and quick to add lots of stuff. What takes time is
determining exactly what to add, and adding no more than is 'necessary'.
It is like the time it takes to write a short letter rather than a long
one.



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

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

Paul Mensonides wrote:
>
> "James Kuyper Jr." <kuyper@wizard.net> wrote in message
> news:3B1ABF7C.E27F7A45@wizard.net...
> > Paul Mensonides wrote:
...
> > What were you imaginging as the easily extendible foundation on which to
> > build C++?
>
> You don't pay for what you don't use.  Rather than you don't get what you don't
> need.

Well, I have to agree, the Vasa story is a horrible analogy for
expressing that idea. Let's stick with mine interpretation, for which
the Vasa story is a pretty good analogy.

...
> That remains to be seen in C++0x, but it is far more likely to have very minor
> changes to the core language only.  In my opinion, the core language *is* C++,
> and the standard library is exactly what it is called a "standard library."

We've had this discussion recently. The standard very clearly calls C++
a language, but it also very clearly states that C++ has both a language
and a library. I don't want to debate the question of what's the
language and what's the library. The C++ standard defines both; it
clearly distinguishes them, and yet simultaneously ties them together.
There's not really a whole lot more that's worth saying about that
relationship.

...
> kind of modern editor).  Whether a change automatically defaults to a negative
> argument depends much more on the feature proposed than the fact that it is new.

Agreed, yet it should depend partly on the fact that it is new, and in a
negative sense. Ignoring the very real costs of change is a serious
mistake, overestimating them is another serious mistake.

...
> Exactly, the analogy is extremely poor and doesn't relate to C++, which is my
> point.  C++ is *not* a ship.

It doesn't have to be a ship, for the analogy to apply. Analogies are
not identities, so showing that the identity doesn't hold doesn't
invalidate the analogy. You've got to show that the analogy doesn't
hold, then you can invalidate the conclusion drawn from it.

In this particular case, the analogy is that C++ has many features, as
did the Vasa, and that C++ needs to be understandable by it's users,
just as the Vasa needed to be supportable by the water it displaced. If
too many features are added to C++, it will cease to be understandable,
and fail, just as the Vasa failed when too many features were added to
it, so that was no longer supportable by the water it displaced. The
analogy fails, in that you can increase the amount of water a ship
displaces by making it bigger (within limits); there's no comparable way
of significantly increasing the amount of complexity the average
programmer can handle. That's hardly a difference that renders the
conclusion invalid: that we must avoid making C++ so complex that it
fails. If anything, that difference reinforces the conclusion - it
removes one possible alternative strategy for dealing with the problem.


...
> > You're advancing a "straw man" argument; no one's suggested that only
> > "absolutely necessary" changes be made. I specifically said that the
> > advantages must outweigh the disadvantages; a criterion that applies
> > equally easily to new features or defect fixes.
>
> Oh really?  What about the great multiple inheritance example with two virtual
> functions from separate base classes with the same name?  The biggest reason
> that the proposed resolution wasn't accepted was because it wasn't "absolutely
> necessary."

Can you give me a URL for retrieving the relevant thread from Google? A
search of comp.std.c++ for "absolutely necessary" turned up exactly 12
messages, none of which seemed relevant to the issue you describe, all
of which were actually from comp.std.c (just what we need - another
search engine that can't tell the difference between c and c++!). So I
assume you're summarizing their argument, rather than quoting it. My
other searches turned up nothing particularly useful.

...
> If you don't understand how a hammer works (for another bad analogy :)) you
> shouldn't be using one.  You don't have to be one of the extremely smart few.

I think you're bringing an attitude to C++, that if adopted into the
standard, would condemn the language into the obscurity of a being a
language only the elite can use. On the other hand, if I understand you
correctly, you don't see that as a disadvantage. I do. The only things
that need to be standardized are widely used things; I'm interested in
the C++ standard precisely because I see C++ as a general purpose
language. Combined with the right application-specific libraries, it can
do just about anything.

> You only have to care about it enough to *try* to learn it.  It is not that
> complicated.  The real complication comes from the way various features can be
> used to create elaborate programs, which is something that you *cannot* get away
> from--no matter what language you use.

There's a minimum unavoidable complexity of any algorithm; that
complexity can only be shifted around (which might, however, be a very
desirable thing to do!), but it can't be removed. However, an overly
complex language can add enormously to that minimum complexity. For
example, if a language provides five different ways of doing exactly the
same thing, a programmer has to waste time recognizing (and learning to
recognize!) all five. It's even worse if the five are not really exactly
the same, but only almost the same.
That's precisely why it's a significant problem when proposed new syntax
provides nothing more than a minor convenience, at the cost of creating
a whole new way of doing precisely the same thing.

...
> agree that C++ is a small part of a much larger computer world.  Yet C++, or
> low-level programming in general, will have a very significant place for a
> *long* time yet.

I agree - that's why I said "someday"; I think it will be at least a
couple of decades, which is a very long time by computer industry
standards.

> The "average" programmer uses VB because C++ (for them) is too complicated.  I
> say, "good riddance."  That increases my value automatically.  The point of C++
> is not a competition for the largest number of "religious" users.  "C++ is a
> general-purpose programming language with a bias toward systems programming...."
> Systems programming == complicated (in most cases).  C++ is not a language for
> *average* programmers, since it is already out of that league entirely.

The primary focus of that statement is "general-purpose", the comment
about "systems programming" was only a bias away from the the primary
focus. "general-purpose" most definitely means that the language is
intended for average programmers. I'll agree that it a little too
complicated for that target audience, but I disagree that it's entirely
"out of that league".

...
> Once again, these are problems and ambiguities mostly in the standard itself.

My point was that if even experts disagree, ordinary users must surely
be confused.

> Also, they are problems that are not as generally important to real-world
> problems as one might think, since overloading (and consequently name lookup) is
> also syntactic sugar.  Do you wish overloading never existed?  It doesn't *do*
> anything at all--except add complication.

I like overloading, I find it a very useful feature of the language, but
it does require overload resolution, and I don't see any good way to
make the rules for overload resolution significantly simpler than they
are. That's an unavoidable cost, but still a cost.

> > The way in which an overly complex language manifests that fact is
> > through people's misuse of it. You can always blame the programmer for
> > not understanding, but if there are too many programmers failing to
> > understand it, and too many other programmers avoiding failure by
> > avoiding the language, then the language itself is too complex. I'm not
> > saying that C++ is there yet, but if too many features are added in the
> > next round of standardization, it will get there.
...
> You cannot blame a language for that, no matter how complex it is.  Bad design
> is possible in any language--that is not the province of a standard committee.

Bad design is not just a problem of programs, it is also an issue for
the language itself, and overly complex design is one of many forms that
bad design takes. Excess complexity is just as bad an idea for a
language as for a program, and for much the same reasons.

...
> or shouldn't be part of the language.  I'll put it a different way:  if the
> committee only adds a few library features, very minor core language
> enhancements, and a few clarifications/corrections to what is already currently
> in the standard, what is the point of me (or anyone else) caring about the
> standard when it takes them so long to do very little?  It has to be *worth* the
> wait to justify its existence.  I'll give you an example that many people want

What justifies the language's existence is the current features. Updates
to the standard require far less justification. If the current features
of C++ aren't already pretty attractive to you, then you should be
looking for a different language. The next release of the standard is
going to be a matter of evolution, not revolution. That may be boring,
just like it's boring to keep a car for no better reason that that
there's nothing significantly wrong with it. It's certainly a lot more
exciting to trade in your car every other year for a brand new one, as
some people do. That doesn't mean its a good idea. I'm not saying that
C++ doesn't need some fixing: it needs a lot more fixing than my car
does. I'm just saying that the differences between C++0x and C++98
should (and probably will) be smaller than the differences between C++98
and ARM C++.

Incidentally, one of the key things that seriously restricts the ability
of the committee to consider rapid change to the language is a shortage
of workers. If you think it should change faster, you should consider
joining and volunteering for some of the work. See the FAQ link at the
bottom of the page to find out how. The membership fees are a bit high,
but most programmers shouldn't find them prohibitive, at least if you
care that much about the language.

> (which I only really want for a few reasons, this example being one of them
> (orthagonalness <--is that a word?), the other being operator new.):

orthogonality.

---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:jNQNPjAcy+G7EwAt@ntlworld.com...
> In article <axDS6.106141$p33.2245719@news1.sttls1.wa.home.com>, Paul
> Mensonides <pmenso57@home.com> writes
> >I'll put it a different way:  if the
> >committee only adds a few library features, very minor core language
> >enhancements, and a few clarifications/corrections to what is already
currently
> >in the standard, what is the point of me (or anyone else) caring about the
> >standard when it takes them so long to do very little?  It has to be *worth*
the
> >wait to justify its existence.
>
> It is easy, and quick to add lots of stuff. What takes time is
> determining exactly what to add, and adding no more than is 'necessary'.
> It is like the time it takes to write a short letter rather than a long
> one.

No, it is slow (committee-wise) to add anything.  I'll reiterate once again:  I
don't think that a ton of great new features should be added in C++0x
specifically.  I'm talking about the *long term* future of C++, and I don't
believe that the standard committee can *only* do slight "maintenance" on the
core language of C++ without causing people to simply not care (even more).
What makes the committee a better library designer that anyone else?  Obviously,
there are experts on the committee, but there are also experts *outside* the
committee that could design STL0x by themselves much more quickly.  By the way,
I'm not knocking the time it takes to produce a standard, nor the time required
to reach consensus (I've seen politics after all!).  The committee needs to be
more than a library designer to justify itself.  Also, (Francis) why do we need
C++0x at all if "no more than 'necessary'" should be added?  Nothing more *is
necessary*.  I'm also not arguing timeline here.  There are people (on the
committee) that know more than I whether we need to slow or speed up in certain
areas.  I don't think that C++ needs a new major feature every year (few could
keep up, much less the committee), but I do think that a major feature every TEN
years is reasonable (and C++08 is optimistic!).  My point is that C++ needs to
be going somewhere *consistently* (whether that's every five years or ten)
rather than statically remaining more-or-less where it is.  That would be the #1
way to date the language and cause a minimization of use.

Paul Mensonides

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

In article <E4dT6.115322$p33.2414502@news1.sttls1.wa.home.com>, Paul
Mensonides <pmenso57@home.com> writes
>I've repeatedly reiterated that I'm not speaking in terms of any time scale.
>Just so that we are clear, what "long" and "short" periods of time are you
>referring to?  My major point is that C++ must be constantly (i.e. standard to
>standard) improving.  Maybe C++0x should contain only minor new language
>features, maybe it shouldn't.  That is not my point.  Complacency is far worse
>that change.


And the problem is that one person's improvement is another person's
'over my dead body'.

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

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

In article <ZceT6.115856$p33.2420916@news1.sttls1.wa.home.com>, Paul
Mensonides <pmenso57@home.com> writes
>I am not talking about the justification for the language; I'm talking about the
>justification for the committee.  By the way, what exactly are the *major*
>differences between C++98 and ARM C++?  -> *mostly* clarifications.  Which I
>agree was a big job for the committee, and the committee did add some very
>useful constructs to the language, but not that many.

namespaces
RTTI
new style casts
templates (yes I know they are listed as experimental in the ARM, but
the final versions are very, very different from what was in the ARM)
Almost a totally different library.

Now if I listed the things that were rejected I would have a much longer
list.

When considering extensions we not only have to consider them
individually but how they interact. A classic example is that I think we
did not do a very good job with the interaction between templates,
namespaces and exceptions.



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

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

"Bjarne Stroustrup" <bs@research.att.com> wrote:
BS> Maybe. Do we really have two distinct communities?

Whether we agree with C-centric folk or not, they exist.

BS> Similarly, there are clearly people who use C++, but never C. Some
BS> of those seem to despise C; I blame arrogance.

And it makes C++ people look pretty arrogant if we suggest that a C standard
is a waste of time.

Don't get me wrong; I agree completely with your statement:

BS> A single merged language (call it C or C++) could be a major benefit
BS> to the community and a major spur for new developments in system
BS> building.

The real question is: Can the ideal of a single language be accomplished
given the political issues involved? In my experience, almost every
political argument has a solutions -- be it global warming, warfare, or
conflicting programming language standards. So why don't these issues get
resolved? Because some people benefit from the conflict, while others have
specific ideals that they are unwilling to change.

Who benefits from the C-C++ conflict? Pundits, the ignorati, and people
scared of change. Would C++ benefit from the conversion of such people?
Probably not. Therefore, let's stop worrying about people who make demands
on C++ from outside, and instead focus our energies on the future we believe
in.

For the purpose of philosophical clarity, we need to abandon backward
compatibility with C. Remove the C++98 dependence on C89, and incorporate
necessary elements directly into C++0x. Once C++ no longer says "based on
C", the pressure to follow C standards is reduced considerably. Ignore the
heretics and blasphemers (as exemplified by Slashdot), and move on to help
the faithful get their work done.

Basing C++ on C was a good way of bringing people into the fold; it reminds
me of how the early Christian church placed its festivals on or near pagan
holidays to facilitate conversions. Today, of course, few people equate
Christmas with Saturnalia, because most Christians started out *as*
Christians. Conversion is no longer needed -- and C++ could follow the same
pattern. Those who want to convert to C++ have likely done so by now; our
focus now is on the future of C++, and not on conversion. Therefore, C
compatibility is a lesser issue for C++0x.

In other words, solve the problem by eliminating it.


--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
http://www.coyotegulch.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                ]

"Bjarne Stroustrup" <bs@research.att.com> wrote in message
news:GEGLJK.K1D@research.att.com...

> Who benefits from having C and C++ as separate languages controlled by
> separate committees, and separately evolving to meet challenges?
>
> I can think of one group only (though undoubtedly there must be more):
> vendors of C implementations and C libraries who do not have a share in
> the C++ market. Plus the vendors of competing languages, of course.

I can think of others, unless you have some kind of subsetting in mind...
and I know you've opposed that in the past. There are vendors and users of
embedded systems for whom the time and cost of producing a 'C'
implementation is just barely tolerable, and for whom the time and cost of
producing a C++ implementation is completely out-of-the-question. There are
organizations who feel they must restrict themselves to 'C' because of the
sheer number of programmers they must hire - there is a feeling that this
lowers the standard of engineering ability enough that the power of C++
would be dangerous and unmanageable. I do not agree or disagree with these
points-of-view, but as long as they are held, the holders benefit from
separate 'C' and C++ language definitions.

-Dave

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

In article <E4dT6.115322$p33.2414502@news1.sttls1.wa.home.com>,
Paul Mensonides <pmenso57@home.com> wrote:
>
>"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
>news:s8heT$Ac6PH7Ewbl@ntlworld.com...
>> In article <rWUS6.109420$p33.2312036@news1.sttls1.wa.home.com>, Paul
>> Mensonides <pmenso57@home.com> writes
>> >My point is that C++ needs to
>> >be going somewhere *consistently* (whether that's every five years or ten)
>> >rather than statically remaining more-or-less where it is.  That would be the
>#1
>> >way to date the language and cause a minimization of use.
>>
>> And that is where I would disagree with you. C++ does not need to be
>> going anywhere as such. If there are major improvements that we can
>> make, then we should do so (and probably will) but not making major
>> change is not in itself bad.
>
>My point is that C++ will be replaced as the predominate systems programming
>language if it isn't going somewhere--i.e. improving.  I'm not talking about
>being replaced by Java or something like that.  I'm talking about a C++front,
>then full compiler/linkers, etc..

Don't assume that changes are necessarily improvements.  It isn't
uncommon for languages to lose their way, and end up being less
useful after an upgrade than they were before.  The key questions
to ask are "What are our objectives?" and "Is there something that
will provide significant benefit and no major drawbacks?"

Too many languages have said "We need to tackle area X", then grabbed
the first not-obviously rejectable proposal that came along, and then
shoehorned it into a model that it was not designed for.

Festina Lente.



Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

In article <GEF7t1.MEz@research.att.com>, Bjarne Stroustrup wrote:
> I recommend a visit to the Vasa - I find it both beautiful and
> thought provoking.

I recommend it too - and it's not such a bad analogy for C++, in many ways.

{OT, for those who don't know: The wreck of the Vasa was rediscovered in
the mud of Stockholm harbour a few decades ago, and was recovered and
preserved. The museum is not just dedicated to the ship, but was built
around it. It documents the building and the fateful maiden voyage of the
Vasa, and also many aspects of Swedish life and politics of the time.]

> What was wrong with the Vasa was not the "features" as such, but that
> they were added on a on a foundation (hull) that was ever so slightly
> too short and narrow. I have been told that had the Vasa been one meter
> wider and a couple of meters longer to match, it would have been superbly
> seaworthy.

The important word here is "added". The Vasa was designed as a two-deck
warship, but before it was completed the King of Sweden ordered that a
third deck should be added so that the ship would be more impressive and
would bring more prestige to Sweden. It was the extra height and weight of
a third deck on a hull that had been laid for a two-decker that caused the
instability.

If there is a lesson here for C++ it may be that any additions muct be
carefully considered in the context of the existing language. If the
comittee believe that a proposed change will be beneficial and will not
break existing code they should add it, but they should not be afraid to
reject a user's requests for features that cannot be accomodated within the
existing language without breaking it (even if the user is King of
somewhere).

I'm sure it's true that proof by analogy is fraud, but cautionary tales
like that of the Vasa may help us to restrain our eagerness to take the
language too far beyond it's original design without accepting that we're
really talking about a different language.

I think it's important to remember that although much of the 'technology'
we see in C++ is established and well-understood there are elements of C++
that we are still learning to understand and to use effectively (I'm
thinking in particular of the recent work by Andrei Alexandrescu which has
certainly made me think again about a lot af aspects of the language).

I think we need to take stock of Andrei's work and the stuff going on under
the Boost banner, and to consolidate our knowledge of C++ and find out what
we can do with it as it is before considering any major changes to the core
language. When the time comes to make those changes we will have a better
sense of what we want from a language - what language features are needed
to support the libraries that are truly useful - and can make
better-informed decisions than can probably be made today. Whether the
result is a new version of C++ or whether the changes we wish to make are
so far-reaching that we have to design a different language to carry on in
C++'s footsteps (er, wake?) I don't know.

Now I'm off to mix up a few more metaphors ...

Cheers,
 Daniel.


---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:sxrOwxC2ZiH7Ewrx@ntlworld.com...

>
> When considering extensions we not only have to consider them
> individually but how they interact. A classic example is that I think we
> did not do a very good job with the interaction between templates,
> namespaces and exceptions.

Care to explain that? I see how templates and namespaces interact a bit, but
AFAICT exceptions are entirely orthogonal to the other two.

-Dave

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

Paul Mensonides wrote:
...
> justification for the committee.  By the way, what exactly are the *major*
> differences between C++98 and ARM C++?  -> *mostly* clarifications.  Which I
> agree was a big job for the committee, and the committee did add some very
> useful constructs to the language, but not that many.

Namespaces, RTTI, the specialized casts, 'bool', 'explicit', and
'export' were all added in C++98. The implications of 'export' are so
extensive that very few implementations even support it now, nearly 3
full years after the standard was approved. The changes made to iostream
were so extensive that it was felt better to give it an entirely
different standard header, and not even include <iostream.h> as a
deprecated part of the library, much less a fully supported one.

Templates and exceptions changed from a essentially experimental
features to a major part of the language. It's arguably the case that
ARM C++ was mainly about polymorphism, while C++98 is mainly about
generic programming. That's an exaggeration, of course, but there's a
fair amount of truth behind it. The changes to template handling were so
extensive that, last time I checked, almost no one is fully implementing
them yet; the biggest sticking point being template template parameters
(which I have to admit, is a fairly low priority feature). Partial
specialization of templates and templated member functions are a far
higher priority with me, and there's still a number of implementations
that don't support them yet.

The single biggest change was that STL was merged into the standard
library. You may argue that this is the library, not the language, but
that distinction did nothing to reduce the workload caused by that
addition. STL was a great idea, but putting it into shape to be
standardized was a major task, one so big that it wasn't quite complete
in time for the actual release of the standard. That's part of the
reason a few things didn't make it in, such as hash tables. Describing
the part that did make it in occupies about half (!) the 776 pages of
the C++ standard.

That's a lot more than "just clarification" as far as I'm concerned.

...
> But once again, *not about timeline.*  I would love to join the committee,
> however.  I don't have the resources to fly all over the world at this point.

It depends upon your national committee, of course. In the US, you can
join the J16 under NCITS as an Associate member, and get all the
benefits of membership without any resposibilities beyond paying your
membership fees. Only Principal members have a duty to accept work
assignments and attend 2 of the three annual meetings.

Question to committee members: the FAQ page suggests that individuals
can join representing only themselves, but when I followed the links
over to NCITS, I got the distinct impression that Principal members, at
least, have to represent an organization. Is that correct?

---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

In article <GEF7t1.MEz@research.att.com>, Bjarne Stroustrup wrote:
> I recommend a visit to the Vasa - I find it both beautiful and
> thought provoking.

I like the analogy with Vasa much, because the ship is only about 541 rods
from where I am now.

In article <sxrOwxC2ZiH7Ewrx@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>When considering extensions we not only have to consider them
>individually but how they interact. A classic example is that I think we
>did not do a very good job with the interaction between templates,
>namespaces and exceptions.

However, a few years ago I conjured up a concept (which we here may call)
"interdependence complexity":

If when building say an airplane, every component is dependent on every
other component for the plane to safely being able to fly, then with n
components, the complexity will be O(n^2). If building a jumbo jet of a
million parts, the complexity will grow enormously, and one will soon hit
a practical limit on how big it can be, as the cost of building the
airplane will grow with the complexity and not the number of components.

On the other hand, a computer has the same basic structure regardless of
how many components that are added, and its complexity will only grow as
something closer to O(n).

So, if one makes a fly-by-wire airplane, one can start to decrease its
complexity, and then make more complicated airplanes.

Similarly, when writing a computer program, if one designs proper objects,
the complexity will grow something close to O(n), because one needs not
worry about the objects interact (as it is up to the one which combines
them to do that).

Now over to C++ language design: If one is able to design good components
that do not clash in the interaction (say via good theory about them),
then the complexity will grow as about O(n). However, if the design is
poor, one will end up with a complexity closer to O(n^2).

So from this purely empirical (and not mathematically very sensible :-) )
reasoning, it means that if the components of C++ are made sufficiently
independent of each other, then one probably can add a lot of features.
But if the components start to collide, then it may sink, like that ship
Vasa.

As it is not practically possible to check all configurations of component
interaction, one really needs to get hold of a good theory ensuring that
they do not clash.

  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                ]

"Andrei Iltchenko" <iltchenko@yahoo.com> wrote in message
news:9fjc56$4fvh1$1@ID-62495.news.dfncis.de...
> "Paul Mensonides" <pmenso57@home.com> wrote in message
> news:6xWS6.109902$p33.2325943@news1.sttls1.wa.home.com...
> >
> > "Bjarne Stroustrup" <bs@research.att.com> wrote in message
> > news:GEF7t1.MEz@research.att.com...
> >
> > Currently, I work with Visual C++ (aaah).  Nothing irritates me more
daily
> that
> > Microsoft's lazy attitude toward conformance.  But some things are
> *guaranteed*.
> > If the committee only enhances the library and cleans up some of the
> wording in
> > the standard, companies like MS will move on without them.  This cannot
be
> > underestimated as far the future of C++ is concerned.  For to many
Windows
> > programmers, VC++ == C++, which is unfortunate but true.  I was one of
the
> > stalwart few arguing with some of the developers and project managers of
> VC++ on
> > microsoft.public.dotnet.languages.vc.  Despite everything they say about
> how
> > much they *care* about conformance, VC7 still doesn't support template
> template
> > parameters.
>
> Not only that, they also pour a lot of false information on their
customers
> and various other C++ users. Below is an excerpt from their C++ Reference
> (Not Visual C++ reference) that they've been hosting on their msdn site
> (http://msdn.microsoft.com/library/default.asp) :
>
> <<quoting>>
> Templates are not officially standardized and, as a result, different C++

[snip]

When you make an accusation like this you should really back it up. The link
you give is, of course, that of the home page of the MSDN site. A search on
that site for "Templates are not officially" returns zero hits.  This maybe
a problem with the search engine Microsoft are using, or maybe the text you
quoted doesn't appear on their site. Please could you post the URL or
article refernce number for the text you are quoting.

NeilB




---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

> "Bjarne Stroustrup" <bs@research.att.com> wrote:


>One interesting question is: Does a forum exist where we can calmly discuss
>the joint futures of C and C++. I think not - people with strong emotions
>tend to drown out the cooler heads. Could such a forum exist? Probably, but
>it would have to be smaller and consist of people with strong stakes in the
>future of the language - or in a merged language.


I don't know if one exists, but it certainly could. Just like this forum, a
moderated forum can be anything you like, with all the cool people you can
imagine. :)  With the not-so-fine folk put on the auto-reject list.

The more interesting question is who would read such a forum.

And who should.

As those applicable to write it will hardly benefit much, while all the
others, on both ends of scale you mentioned -- are hardly interested in
herecies shout from the other camp. As you said, "ignorant and proud of it",
the very state one will mot mofe away from. Unless some divine intervention
happens.

>From the very old times I found there are multi-language programmers and
single language programmers. (Let's narrow the sope to those really capable
of producing any kind of useful output.)  Those in the first group appear to
catch the more general terms of programming, and see behind the syntax for
more abstraction. And they can learn programming languages to express their
ideas. Probably more easier with every new language coming.
The other group is stick to the schemas they could master the first (not
necessarily the first language they started to learn, but then it means the
other attempts were a failure).  Then, having one thing moving they can't go
a millimeter beyond it. As a matter of fact they reject even the new
featires added to the same language.

A somewhat special form of the latter is the programmer learning just enough
elements of the basic syntax of a new language, then writing assembly or
fortran programs in C or C++, C programs in C++, etc.   Those hiring
programmers should better be aware of this phenomnon, as it can wreak havoc
in a team work and going unrecognized for a plenty of time.

Growing old I tend to abandon hope, and recognize the fact: people think
differently, and you can't change the way a particular person think, not a
bit, however hard you try.  Can you make your wife check the tires? ;-)

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                ]

James Kuyper Jr. wrote in message <3B1ABF7C.E27F7A45@wizard.net>...

>I'm sorry - we're using the analogies differently - the thing I'm
>talking about possibly overloading is the capacity of the average
>adequately trained and reasonably experienced programmer to understand
>and use the language. That's a foundation that can NOT be easily
>extended. You can increase the capacity of the individual by education
>education and experience, but I'm talking about the average capacity
>over all programmers, after that's been done. That capacity will
>increase significantly only with radical improvements in teaching
>techniques, or perhaps with genetic engineering.


With that I completely agree. One more reason to drop all the usual
arguments saying "this can be implemented using the existing language -- see
this template", followed by a cute code that maybe 3 people besides AA could
create, and even gets 80% of compilers confused.

The "what is the element count of a C-style array" was the perfect example
to that, I think. C and C++ should have had a sizeof-like operator telling
that from the very beginning, but C covered it with a common-used macro
(probably one doing undefined behavior, but working for most cases, hm), and
for C++ it will just not be added. And certainly the question of how it can
be done, why the usual way is bad, how the template solution works, and why
it does not in practice will appear every two months on low-througput lists,
dayly on others, and keep the programmers' mind going. Instead of dong lots
of better things, and lust using a lnguage supported 'lengthof' or 'countof'
operator the bring forth next to no questions ever.

PLEASE note features like that not increase but decrease complexity of the
language. And let people concentrate on the main task.

(And the above is just en example, please do not start to convince me on how
lengthof can be implemented or not, and why C-style arrays are overall to be
avoided. As I mentiones, hundresd of articles already apperaed on the topic,
and other hundreds will appear.)

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                ]

"Balog Pal (mh)" wrote:
...
> That general "adding features is dangerous" stuff should not inhibit new
> features being added, just work out a good scoring system, that can tell the
> difference, whether the existing hacks that are used to circumwent tha lack
> of it are better than having it solver with direct support, and what real
> cost it invokes on the compiler makers and existing code maintainers.

Yes, that's exactly what I'm saying: compare the benefits and costs, and
remember that any change has a cost just because it's a change, on top
of any other costs it may impose. However, I'm not sure a concrete
scoring system would be feasible - the costs and benefits are seldom
quantifiable.

---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

In article <remove.haberg-0606012051550001@du130-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>So from this purely empirical (and not mathematically very sensible :-) )
>reasoning, it means that if the components of C++ are made sufficiently
>independent of each other, then one probably can add a lot of features.
>But if the components start to collide, then it may sink, like that ship
>Vasa.

And a horribly large number of components of C++ interact through name
look-up problems:(


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

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

In article <FktT6.17841$QP6.7308510@typhoon.ne.mediaone.net>, David
Abrahams <abrahams@mediaone.net> writes
>Care to explain that? I see how templates and namespaces interact a bit, but
>AFAICT exceptions are entirely orthogonal to the other two.

Exactly how do you use exception specification with templates?


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

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

"James Kuyper Jr." wrote:
>
> Question to committee members: the FAQ page suggests that individuals
> can join representing only themselves, but when I followed the links
> over to NCITS, I got the distinct impression that Principal members, at
> least, have to represent an organization. Is that correct?
>

There is an organization named "self" that seems to be exempt from the
one organization one vote rule. <g>

For those who don't attend committee meetings, there are many people
involved who "represent self", i.e. are not affiliated with any
organization.

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

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

"Neil Butterworth" <neil_butterworth@lineone.net> wrote in message
news:thqof9r774qe0f@corp.supernews.co.uk...
> "Andrei Iltchenko" <iltchenko@yahoo.com> wrote in message
> news:9fjc56$4fvh1$1@ID-62495.news.dfncis.de...
> > "Paul Mensonides" <pmenso57@home.com> wrote in message
> > news:6xWS6.109902$p33.2325943@news1.sttls1.wa.home.com...
> > >
> > > "Bjarne Stroustrup" <bs@research.att.com> wrote in message
> > > news:GEF7t1.MEz@research.att.com...
> > >
> > > Currently, I work with Visual C++ (aaah).  Nothing irritates me more
> daily
> > that
> > > Microsoft's lazy attitude toward conformance.  But some things are
> > *guaranteed*.
> > > If the committee only enhances the library and cleans up some of the
> > wording in
> > > the standard, companies like MS will move on without them.  This
cannot
> be
> > > underestimated as far the future of C++ is concerned.  For to many
> Windows
> > > programmers, VC++ == C++, which is unfortunate but true.  I was one of
> the
> > > stalwart few arguing with some of the developers and project managers
of
> > VC++ on
> > > microsoft.public.dotnet.languages.vc.  Despite everything they say
about
> > how
> > > much they *care* about conformance, VC7 still doesn't support template
> > template
> > > parameters.
> >
> > Not only that, they also pour a lot of false information on their
> customers
> > and various other C++ users. Below is an excerpt from their C++
Reference
> > (Not Visual C++ reference) that they've been hosting on their msdn site
> > (http://msdn.microsoft.com/library/default.asp) :
> >
> > <<quoting>>
> > Templates are not officially standardized and, as a result, different
C++
>
> When you make an accusation like this you should really back it up. The
link
> you give is, of course, that of the home page of the MSDN site. A search
on
> that site for "Templates are not officially" returns zero hits.  This
maybe
> a problem with the search engine Microsoft are using, or maybe the text
you
> quoted doesn't appear on their site. Please could you post the URL or
> article refernce number for the text you are quoting.

Gladly:
http://msdn.microsoft.com/library/default.asp

then select:
Visual Studio 6.0 Documentation
    Visual C++ Documentation
        Reference
            C/C++ Language and C++ libraries
                C++ Language reference
                    Declarations
                        Template Specifications
                            Differences from Other Implementations


Cheers,

Andrei Iltchenko.


---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

On Thu, 24 May 2001 19:44:13 GMT, "Scott Robert Ladd"
<scott@coyotegulch.com> wrote:

>As for the "solid ground" you seek: Since C++ encompasses the C90 standard,
>it stands to reason that C++ can not be "inferior" to C90.

Although I agree that C++ can be used as a better C, I don't agree
with your reasoning. It is possible to add so many features that a
thing ceases to be better, or even useable.

Consider the 17th-century Swedish Navy ship "Vasa". It must have been
the best fighting ship of the time. It had more of everything,
including many statues around the main deck. Unfortunately, it sank on
its maiden voyage across Stockholm harbor because it was top-heavy.

(There's a brief discussion of the Vasa in "Design and Evolution of
C++". There's a whole museum in Stockholm devoted to the ship. I
highly recommend a visit.)

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

"Stephen Clamage" <stephen.clamage@sun.com> wrote in message
news:75qihtgtcgrk5mdd1o3lep3f279ieotgt6@4ax.com...
> On Thu, 24 May 2001 19:44:13 GMT, "Scott Robert Ladd"
> <scott@coyotegulch.com> wrote:
>
> >As for the "solid ground" you seek: Since C++ encompasses the C90 standard,
> >it stands to reason that C++ can not be "inferior" to C90.
>
> Although I agree that C++ can be used as a better C, I don't agree
> with your reasoning. It is possible to add so many features that a
> thing ceases to be better, or even useable.
>
> Consider the 17th-century Swedish Navy ship "Vasa". It must have been
> the best fighting ship of the time. It had more of everything,
> including many statues around the main deck. Unfortunately, it sank on
> its maiden voyage across Stockholm harbor because it was top-heavy.
>
> (There's a brief discussion of the Vasa in "Design and Evolution of
> C++". There's a whole museum in Stockholm devoted to the ship. I
> highly recommend a visit.)
>
> ---
> Steve Clamage, stephen.clamage@sun.com

This is no longer the maiden voyage of C++.  Also, though an analogy may be
quaint, it is not an argument for a completely unrelated topic.  Consider an
equally unrelated analogy that shows just the opposite, Air Force One.  That
airplane gets "new features" all the time, and it doesn't fall out of the sky
because of them.  The truth behind the Vasa was not that the designers added so
many features, but that the designers didn't know how to "design" properly.  The
C++ language is not new anymore, and it is already mainstream.  It won't just go
away because of new features.

Don't misunderstand me; I am not advocating adding everything that has ever been
useful or neat to the language.  I am saying the Vasa is a bad analogy that has
no bearing on this situation other than to say "what is added must be properly
designed."  It may have been true that a "too complicated" language will never
make it out of the research departments, but this no longer applies.  I also
disagree that analogies like this one are cause for summarily disregarding all
proposals for new core language features.  C++ should not be considered
finished, as it is not yet perfect.

Paul Mensonides



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

Paul Mensonides wrote:
>
> "Stephen Clamage" <stephen.clamage@sun.com> wrote in message
> news:75qihtgtcgrk5mdd1o3lep3f279ieotgt6@4ax.com...
...
> > Although I agree that C++ can be used as a better C, I don't agree
> > with your reasoning. It is possible to add so many features that a
> > thing ceases to be better, or even useable.
> >
> > Consider the 17th-century Swedish Navy ship "Vasa". It must have been
> > the best fighting ship of the time. It had more of everything,
> > including many statues around the main deck. Unfortunately, it sank on
> > its maiden voyage across Stockholm harbor because it was top-heavy.
> >
> > (There's a brief discussion of the Vasa in "Design and Evolution of
> > C++". There's a whole museum in Stockholm devoted to the ship. I
> > highly recommend a visit.)
> >
> > ---
> > Steve Clamage, stephen.clamage@sun.com
>
> This is no longer the maiden voyage of C++.  Also, though an analogy may be

This kind of mistake need not be restricted to the maiden voyage. Any
time that you add to the load a ship must carry, you may end up
overloading it. It's just more ironic when it happens that early in a
ship's life.

> quaint, it is not an argument for a completely unrelated topic.  Consider an
> equally unrelated analogy that shows just the opposite, Air Force One.  That
> airplane gets "new features" all the time, and it doesn't fall out of the sky
> because of them. ...

It will fall, if too many new features are added, or the wrong ones.
There's a maximum load it can carry safely through the sky, and any
feature that adds to that load may make it no longer safe to fly.

> ...  The truth behind the Vasa was not that the designers added so
> many features, but that the designers didn't know how to "design" properly.  The

The Vasa was an example of bad design, but what was bad about the design
is that it added too many features, more than the ship was able to
support.

> C++ language is not new anymore, and it is already mainstream.  It won't just go
> away because of new features.
>
> Don't misunderstand me; I am not advocating adding everything that has ever been
> useful or neat to the language.  I am saying the Vasa is a bad analogy that has
> no bearing on this situation other than to say "what is added must be properly
> designed."  It may have been true that a "too complicated" language will never
> make it out of the research departments, but this no longer applies.  I also

Because C++ already exists, and has flourished, it won't die immediately
from addition of new features, particularly if the new features carry no
cost to those programs and programmers which don't use them. However,
most changes have more costs than their advocates realize. If nothing
else, each new feature adds to the options an analyst needs to consider
when designing a program, and adds to the number of things a coder must
be able to understand when reading code written by someone else. If too
many such changes are made, people will refuse to advance to the latest
version of C++, or will abandon it in favor of simpler languages. It
wouldn't be a quick death like that of the Vasa, but it would slowly die
off. The slowness of the death means that there would be time to
re-consider any given change, but it can be very difficult to retract a
change once it's been made official.

> disagree that analogies like this one are cause for summarily disregarding all
> proposals for new core language features.  C++ should not be considered
> finished, as it is not yet perfect.

Agreed: new features should not be summarily disregarded. They should be
very carefully considered, and the fact that they are new should
properly be held against then. The burden of proof is on the proposer of
the change to show that the advantages of the change outweigh the
disadvantages, keeping in mind that any change carries, in addition to
any other disadvantages, the disadvantages of being a change.
Simplifying the language is one possible compensating advantage, but
"new features" almost never actually simplify something.

C++ will never be finished. It will someday, like most things, die of
natural causes without ever having been completely finished, without
ever have been exactly perfect. However, it's at least as likely to die
from have been made over-complicated, as to die from not having been
changed frequently enough.

---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

inline...

"James Kuyper Jr." <kuyper@wizard.net> wrote in message
news:3B1A33E4.27D935E9@wizard.net...
> Paul Mensonides wrote:
> >
> > "Stephen Clamage" <stephen.clamage@sun.com> wrote in message
> > news:75qihtgtcgrk5mdd1o3lep3f279ieotgt6@4ax.com...
> ...
> > > Although I agree that C++ can be used as a better C, I don't agree
> > > with your reasoning. It is possible to add so many features that a
> > > thing ceases to be better, or even useable.
> > >
> > > Consider the 17th-century Swedish Navy ship "Vasa". It must have been
> > > the best fighting ship of the time. It had more of everything,
> > > including many statues around the main deck. Unfortunately, it sank on
> > > its maiden voyage across Stockholm harbor because it was top-heavy.
> > >
> > > (There's a brief discussion of the Vasa in "Design and Evolution of
> > > C++". There's a whole museum in Stockholm devoted to the ship. I
> > > highly recommend a visit.)
> > >
> > > ---
> > > Steve Clamage, stephen.clamage@sun.com
> >
> > This is no longer the maiden voyage of C++.  Also, though an analogy may be
>
> This kind of mistake need not be restricted to the maiden voyage. Any
> time that you add to the load a ship must carry, you may end up
> overloading it. It's just more ironic when it happens that early in a
> ship's life.

Unlike ships, a programming language is *much* more likely to fail on its maiden
voyage, and much more unlikely to fail on all subsequent voyages.  The analogy
that you can overload a language similarly to overloading a vessel fails simply
because the base of the language can be extended to support new features.  A
building, for example, has a fixed-size foundation, and, if you keep building it
higher and higher, it will eventually fall over.  The case is entirely different
with a programming language where the "foundation" is *not* fixed size.

> > quaint, it is not an argument for a completely unrelated topic.  Consider an
> > equally unrelated analogy that shows just the opposite, Air Force One.  That
> > airplane gets "new features" all the time, and it doesn't fall out of the
sky
> > because of them. ...
>
> It will fall, if too many new features are added, or the wrong ones.
> There's a maximum load it can carry safely through the sky, and any
> feature that adds to that load may make it no longer safe to fly.

The idea of Air Force One (for example) is not the specific airplane itself.
The individual plane may be replaced altogether with a new one that can support
more load, etc..  The analogy still fails as argument for anything to do with
C++.  Once again, I am not saying here that everything should be added; I am
saying that the Vasa is an extremely bad analogy--and is typical of those with a
so-called "religious" programming language viewpoint.  This analogy, and the
supposed motivation behind it, is followed way too religiously.  As many have
said (from the committee itself) a religious viewpoint with regards to
programming language is pointless.  I agree, however, that is exactly what many
of them do.

> > ...  The truth behind the Vasa was not that the designers added so
> > many features, but that the designers didn't know how to "design" properly.
The
>
> The Vasa was an example of bad design, but what was bad about the design
> is that it added too many features, more than the ship was able to
> support.

No, the bad design was that they didn't design the structure of the ship to hold
that much weight in certain areas.  The fault was not in adding more features
(statues, etc.) but in not adding necessary support to the design.

> > C++ language is not new anymore, and it is already mainstream.  It won't
just go
> > away because of new features.
> >
> > Don't misunderstand me; I am not advocating adding everything that has ever
been
> > useful or neat to the language.  I am saying the Vasa is a bad analogy that
has
> > no bearing on this situation other than to say "what is added must be
properly
> > designed."  It may have been true that a "too complicated" language will
never
> > make it out of the research departments, but this no longer applies.  I also
>
> Because C++ already exists, and has flourished, it won't die immediately
> from addition of new features, particularly if the new features carry no
> cost to those programs and programmers which don't use them. However,
> most changes have more costs than their advocates realize. If nothing
> else, each new feature adds to the options an analyst needs to consider
> when designing a program, and adds to the number of things a coder must
> be able to understand when reading code written by someone else. If too
> many such changes are made, people will refuse to advance to the latest
> version of C++, or will abandon it in favor of simpler languages. It
> wouldn't be a quick death like that of the Vasa, but it would slowly die
> off. The slowness of the death means that there would be time to
> re-consider any given change, but it can be very difficult to retract a
> change once it's been made official.

Ah, hah.  Here is the core of conformance problems.  If you add too much to the
language people just won't implement it.  I agree, *but* if you, conversely, add
to little to the language people won't implement it either and will instead
implement their own extensions.  Which, of course, causes fragmentation of the
language, etc..  Given that, the question is where the "happy medium" is.  There
are a lot of things that I'd like to see as part of C++, but I think they should
be integrated into C++ over time, as opposed to everything at once in C++0x.

> > disagree that analogies like this one are cause for summarily disregarding
all
> > proposals for new core language features.  C++ should not be considered
> > finished, as it is not yet perfect.
>
> Agreed: new features should not be summarily disregarded. They should be
> very carefully considered, and the fact that they are new should
> properly be held against then. The burden of proof is on the proposer of
> the change to show that the advantages of the change outweigh the
> disadvantages, keeping in mind that any change carries, in addition to
> any other disadvantages, the disadvantages of being a change.
> Simplifying the language is one possible compensating advantage, but
> "new features" almost never actually simplify something.

Whether a proposal is new is irrelevant.  Many language changes are proposed to
fix some part of C++ that *needs* fixing.  The question is simply:  is this
proposal good or bad, not is this absolutely necessary.  Given the "absolutely
necessary" argument, I point out that primary C++ facilities like oo and
templates serve only as syntactic convenience and overall source code structure.
There are no templates or member functions at runtime.  Everything that can be
done in C++ can be done in C or assembler.  Therefore what it the point of C++?
To make things easier.  Therefore, it could just as easily be said:  add
anything that makes programming easier rather than just "absolutely necessary."
Both these arguments fail as an end-all-and-be-all solution to language design.
The largest reason that C++ is considered too complicated is because those using
it don't care enough about it.  I find absolutely *no* language features too
complicated--including name-lookup, etc..  The people that don't understand
don't generally *care* to understand.  That is not the fault of the language but
of the individual using it.  The price of power and flexibility inheritently
causes complexity.  If there is a hundred ways to do something rather than one,
the language will be more complex--guaranteed.

> C++ will never be finished. It will someday, like most things, die of
> natural causes without ever having been completely finished, without
> ever have been exactly perfect. However, it's at least as likely to die
> from have been made over-complicated, as to die from not having been
> changed frequently enough.

C++ (or the idea of C++ by any name) will never die (more than likely, neither
will Cobol, Fortran, CLOS, etc., etc.), but its use may be minimized.  That will
only happen when C++ is replaced by a language that has everything C++ has and
more.  C++ should be for programmers that know what they are doing, and the fact
that so many people use higher-level languages is not an argument that C++
should be simpler.  Language complexity is what separates the "men from the
boys" (excuse me, ladies :)).  If you can't hack it, use VB, and thereby
extensively limit what you can do.  If computers were easy to program, can you
imagine what would happen to a computer in the hands of a "typical" person?  IT
and Technical Support nightmare!

In order to lend credence to your argument, give me an example of some part of
the core language that you don't understand.  With decent reference materials,
anything that you can think of you can learn just by looking it up while trying
to find it.  What is the most complicated part of C++ in your opinion?
Templates, maybe?  Much template code is only complicated because of a lack of
features and a somewhat half-baked template system (albeit the best one
currently available in any language).  Maybe name-lookup from within a template?
Why is that hard to grasp?  I'd really, for once, like to see some examples of
why C++ itself is too complicated rather than someone's misuses of it.

Paul Mensonides

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

Paul Mensonides wrote:
...
> Unlike ships, a programming language is *much* more likely to fail on its maiden
> voyage, and much more unlikely to fail on all subsequent voyages.  The analogy
> that you can overload a language similarly to overloading a vessel fails simply
> because the base of the language can be extended to support new features.  A
> building, for example, has a fixed-size foundation, and, if you keep building it
> higher and higher, it will eventually fall over.  The case is entirely different
> with a programming language where the "foundation" is *not* fixed size.

I'm sorry - we're using the analogies differently - the thing I'm
talking about possibly overloading is the capacity of the average
adequately trained and reasonably experienced programmer to understand
and use the language. That's a foundation that can NOT be easily
extended. You can increase the capacity of the individual by education
education and experience, but I'm talking about the average capacity
over all programmers, after that's been done. That capacity will
increase significantly only with radical improvements in teaching
techniques, or perhaps with genetic engineering.

What were you imaginging as the easily extendible foundation on which to
build C++?

...
> C++.  Once again, I am not saying here that everything should be added; I am
> saying that the Vasa is an extremely bad analogy--and is typical of those with a
> so-called "religious" programming language viewpoint.  This analogy, and the
> supposed motivation behind it, is followed way too religiously.  As many have
> said (from the committee itself) a religious viewpoint with regards to
> programming language is pointless.  I agree, however, that is exactly what many
> of them do.

Objecting to change isn't a sign of "religious" devotion to the current
text; it's the result of being aware of the costs of changing it. Some
people may be in the habit of overestimating those costs, but that
doesn't justify labelling their resistance to change "religious". They
are balanced by at least an equal number of people who are in the habit
of underestimating those costs.

...
> No, the bad design was that they didn't design the structure of the ship to hold
> that much weight in certain areas.  The fault was not in adding more features
> (statues, etc.) but in not adding necessary support to the design.

That's just another way of saying the same thing. They put on too much
weight for the size of the structure that supported it. One solution is
the extend the support available, the other is to reduce the amount of
support needed. The correct solution is NOT necessarily to increase the
support available. In the case of the Vasa, it might have been more
useful to have fewer guns, than to have more ship, because the extra
size would have made it slower, less maneuverable, more expensive and a
bigger target. Only a naval expert could be sure about which fix would
have been better.

In the case of language standards, as I've argued above, extending the
support is not an option.

...
> Whether a proposal is new is irrelevant.  Many language changes are proposed to

I was specifically responding to a comment about "new core features".

> fix some part of C++ that *needs* fixing.  The question is simply:  is this
> proposal good or bad, not is this absolutely necessary.  Given the "absolutely
> necessary" argument, I point out that primary C++ facilities like oo and

You're advancing a "straw man" argument; no one's suggested that only
"absolutely necessary" changes be made. I specifically said that the
advantages must outweigh the disadvantages; a criterion that applies
equally easily to new features or defect fixes.

> templates serve only as syntactic convenience and overall source code structure.
> There are no templates or member functions at runtime.  Everything that can be
> done in C++ can be done in C or assembler.  Therefore what it the point of C++?
> To make things easier.  Therefore, it could just as easily be said:  add
> anything that makes programming easier rather than just "absolutely necessary."

No - ease of programming is not the only criterion. Adding a feature to
C++ that makes it easier to program in would not necessarily be
acceptable if the cost of that feature is to make it harder to learn,
harder to compile, or harder to maintain. Backward compatibility is also
a legitimate concern. A change to the standard that made C++ twice as
easy to program, but would require a carefully considered redesign of
every C++ program ever written, would almost certainly never be
approved, and IMO rightly so. The cost of that re-design could easily
swamp the benefits  to new code by a factor of 10 or more - there's a
LOT of legacy code out there.

> Both these arguments fail as an end-all-and-be-all solution to language design.
> The largest reason that C++ is considered too complicated is because those using
> it don't care enough about it.  I find absolutely *no* language features too
> complicated--including name-lookup, etc..  The people that don't understand
> don't generally *care* to understand.  That is not the fault of the language but

I do care to understand. I love C++, and wish I could find someone
willing to pay me a decent salary to program in it in my chosen field
(non-military scientific programming - neither C++ nor a "decent salary"
are commonplace in that field). However, that doesn't blind me to how
complex the language is. Nor do I revel (much :-) in the glory of being
one of the people smart enough to understand it. The fact that I love
C++ is actually evidence of its complexity. I have a weakness for overly
complex things, as anyone who's read too many of my messages can attest.

...
> C++ (or the idea of C++ by any name) will never die (more than likely, neither
> will Cobol, Fortran, CLOS, etc., etc.), but its use may be minimized.  That will
> only happen when C++ is replaced by a language that has everything C++ has and
> more.  C++ should be for programmers that know what they are doing, and the fact
> that so many people use higher-level languages is not an argument that C++
> should be simpler.  Language complexity is what separates the "men from the
> boys" (excuse me, ladies :)).  If you can't hack it, use VB, and thereby
> extensively limit what you can do.  If computers were easy to program, can you
> imagine what would happen to a computer in the hands of a "typical" person?  IT
> and Technical Support nightmare!

I think the ideal for computer programming will be when computers are
smart enough that they CAN safely be programmed by the "typical" person.
I don't think that people who specialize in learning how best to use a
computer will ever be out of a job, but I think that programming by such
specialists will represent a steadily declining fraction of all the
programming being done. Already, in a typical 3GL language, most of the
programming is being done by the compiler itself; the C code we
programmers write represents only a small (but critical!) part of the
whole programming effort, and we do our part a whole lot slower than the
compiler does it's part. I won't be surprised if C++ programming someday
becomes as restricted a specialty as assembly language programming is
today.

> In order to lend credence to your argument, give me an example of some part of
> the core language that you don't understand.  With decent reference materials,

I can't give you any good examples of that. I've read the entire
standard many times over, and I actually claim to understand most of it.
All modesty aside (not that anyone's ever accused me of having any :-)
I'm an extremely intelligent person - a language that I had any
significant trouble understanding would be far too difficult for the
average programmer, and C++ comes closer to that limit than most
languages I know.

> anything that you can think of you can learn just by looking it up while trying
> to find it.  What is the most complicated part of C++ in your opinion?

Overloading, especially as a result of templates. Name lookup, overload
resolution, and template argument deduction are among the trickiest
features of the language. Even experts on the committee sometimes
disagree on the correct interpretation. The issues list for the C++
language <http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_toc.html> has
288 items on it, and the standard library
<http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-toc.html> has another
322, and a large fraction of the issues on either list have not yet been
resolved. That is not an indication of an easily understood language.

> Templates, maybe?  Much template code is only complicated because of a lack of
> features and a somewhat half-baked template system (albeit the best one
> currently available in any language).  Maybe name-lookup from within a template?
> Why is that hard to grasp?  I'd really, for once, like to see some examples of
> why C++ itself is too complicated rather than someone's misuses of it.

The way in which an overly complex language manifests that fact is
through people's misuse of it. You can always blame the programmer for
not understanding, but if there are too many programmers failing to
understand it, and too many other programmers avoiding failure by
avoiding the language, then the language itself is too complex. I'm not
saying that C++ is there yet, but if too many features are added in the
next round of standardization, it will get there.

---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message
news:3B1ABF7C.E27F7A45@wizard.net...
> Paul Mensonides wrote:
> ...
> > Unlike ships, a programming language is *much* more likely to fail on its
maiden
> > voyage, and much more unlikely to fail on all subsequent voyages.  The
analogy
> > that you can overload a language similarly to overloading a vessel fails
simply
> > because the base of the language can be extended to support new features.  A
> > building, for example, has a fixed-size foundation, and, if you keep
building it
> > higher and higher, it will eventually fall over.  The case is entirely
different
> > with a programming language where the "foundation" is *not* fixed size.
>
> I'm sorry - we're using the analogies differently - the thing I'm
> talking about possibly overloading is the capacity of the average
> adequately trained and reasonably experienced programmer to understand
> and use the language. That's a foundation that can NOT be easily
> extended. You can increase the capacity of the individual by education
> education and experience, but I'm talking about the average capacity
> over all programmers, after that's been done. That capacity will
> increase significantly only with radical improvements in teaching
> techniques, or perhaps with genetic engineering.
>
> What were you imaginging as the easily extendible foundation on which to
> build C++?

You don't pay for what you don't use.  Rather than you don't get what you don't
need.

> ...
> > C++.  Once again, I am not saying here that everything should be added; I am
> > saying that the Vasa is an extremely bad analogy--and is typical of those
with a
> > so-called "religious" programming language viewpoint.  This analogy, and the
> > supposed motivation behind it, is followed way too religiously.  As many
have
> > said (from the committee itself) a religious viewpoint with regards to
> > programming language is pointless.  I agree, however, that is exactly what
many
> > of them do.
>
> Objecting to change isn't a sign of "religious" devotion to the current
> text; it's the result of being aware of the costs of changing it. Some
> people may be in the habit of overestimating those costs, but that
> doesn't justify labelling their resistance to change "religious". They
> are balanced by at least an equal number of people who are in the habit
> of underestimating those costs.

That remains to be seen in C++0x, but it is far more likely to have very minor
changes to the core language only.  In my opinion, the core language *is* C++,
and the standard library is exactly what it is called a "standard library."
There are great many things that could be added without breaking any existing
code (other than possibly keywords, which is not really a serious issue with any
kind of modern editor).  Whether a change automatically defaults to a negative
argument depends much more on the feature proposed than the fact that it is new.

> ...
> > No, the bad design was that they didn't design the structure of the ship to
hold
> > that much weight in certain areas.  The fault was not in adding more
features
> > (statues, etc.) but in not adding necessary support to the design.
>
> That's just another way of saying the same thing. They put on too much
> weight for the size of the structure that supported it. One solution is
> the extend the support available, the other is to reduce the amount of
> support needed. The correct solution is NOT necessarily to increase the
> support available. In the case of the Vasa, it might have been more
> useful to have fewer guns, than to have more ship, because the extra
> size would have made it slower, less maneuverable, more expensive and a
> bigger target. Only a naval expert could be sure about which fix would
> have been better.

Exactly, the analogy is extremely poor and doesn't relate to C++, which is my
point.  C++ is *not* a ship.

> In the case of language standards, as I've argued above, extending the
> support is not an option.
>
> ...
> > Whether a proposal is new is irrelevant.  Many language changes are proposed
to
>
> I was specifically responding to a comment about "new core features".

Which is what I'm talking about as well.

> > fix some part of C++ that *needs* fixing.  The question is simply:  is this
> > proposal good or bad, not is this absolutely necessary.  Given the
"absolutely
> > necessary" argument, I point out that primary C++ facilities like oo and
>
> You're advancing a "straw man" argument; no one's suggested that only
> "absolutely necessary" changes be made. I specifically said that the
> advantages must outweigh the disadvantages; a criterion that applies
> equally easily to new features or defect fixes.

Oh really?  What about the great multiple inheritance example with two virtual
functions from separate base classes with the same name?  The biggest reason
that the proposed resolution wasn't accepted was because it wasn't "absolutely
necessary."

struct Base_A {
    virtual void f() = 0;
};

struct Base_B {
    virtual void f() = 0;
};

struct BS_Workaround_A : public Base_A {
    void f() { return A_f(); }
    virtual void A_f() = 0;
};

struct BS_Workaround_B : public Base_B {
    void f() { return B_f(); }
    virtual void B_f() = 0;
};

struct Finally : public BS_Workaround_A, public BS_Workaround_B {
    // note:  DON'T TOUCH f();
    void A_f();
    void B_f();
};

As opposed to:

struct Finally : public Base_A, public Base_B {
    void A_f() = Base_A::f();
    void B_f() = Base_B::f();
};

Which, by the way, would have broken *exactly* zero C++ code and been easy to
implement.

> > templates serve only as syntactic convenience and overall source code
structure.
> > There are no templates or member functions at runtime.  Everything that can
be
> > done in C++ can be done in C or assembler.  Therefore what it the point of
C++?
> > To make things easier.  Therefore, it could just as easily be said:  add
> > anything that makes programming easier rather than just "absolutely
necessary."
>
> No - ease of programming is not the only criterion. Adding a feature to
> C++ that makes it easier to program in would not necessarily be
> acceptable if the cost of that feature is to make it harder to learn,
> harder to compile, or harder to maintain. Backward compatibility is also
> a legitimate concern. A change to the standard that made C++ twice as
> easy to program, but would require a carefully considered redesign of
> every C++ program ever written, would almost certainly never be
> approved, and IMO rightly so. The cost of that re-design could easily
> swamp the benefits  to new code by a factor of 10 or more - there's a
> LOT of legacy code out there.

Of course not, but you are taking it to a (non-logical) extreme.  Obviously
backward compatibility is an issue.

> > Both these arguments fail as an end-all-and-be-all solution to language
design.
> > The largest reason that C++ is considered too complicated is because those
using
> > it don't care enough about it.  I find absolutely *no* language features too
> > complicated--including name-lookup, etc..  The people that don't understand
> > don't generally *care* to understand.  That is not the fault of the language
but
>
> I do care to understand. I love C++, and wish I could find someone
> willing to pay me a decent salary to program in it in my chosen field
> (non-military scientific programming - neither C++ nor a "decent salary"
> are commonplace in that field). However, that doesn't blind me to how
> complex the language is. Nor do I revel (much :-) in the glory of being
> one of the people smart enough to understand it. The fact that I love
> C++ is actually evidence of its complexity. I have a weakness for overly
> complex things, as anyone who's read too many of my messages can attest.

If you don't understand how a hammer works (for another bad analogy :)) you
shouldn't be using one.  You don't have to be one of the extremely smart few.
You only have to care about it enough to *try* to learn it.  It is not that
complicated.  The real complication comes from the way various features can be
used to create elaborate programs, which is something that you *cannot* get away
from--no matter what language you use.

> ...
> > C++ (or the idea of C++ by any name) will never die (more than likely,
neither
> > will Cobol, Fortran, CLOS, etc., etc.), but its use may be minimized.  That
will
> > only happen when C++ is replaced by a language that has everything C++ has
and
> > more.  C++ should be for programmers that know what they are doing, and the
fact
> > that so many people use higher-level languages is not an argument that C++
> > should be simpler.  Language complexity is what separates the "men from the
> > boys" (excuse me, ladies :)).  If you can't hack it, use VB, and thereby
> > extensively limit what you can do.  If computers were easy to program, can
you
> > imagine what would happen to a computer in the hands of a "typical" person?
IT
> > and Technical Support nightmare!
>
> I think the ideal for computer programming will be when computers are
> smart enough that they CAN safely be programmed by the "typical" person.
> I don't think that people who specialize in learning how best to use a
> computer will ever be out of a job, but I think that programming by such
> specialists will represent a steadily declining fraction of all the
> programming being done. Already, in a typical 3GL language, most of the
> programming is being done by the compiler itself; the C code we
> programmers write represents only a small (but critical!) part of the
> whole programming effort, and we do our part a whole lot slower than the
> compiler does it's part. I won't be surprised if C++ programming someday
> becomes as restricted a specialty as assembly language programming is
> today.

I am not so sure.  The growth in hardware speed is slowing.  Despite what many
people think, software is still out-pacing hardware (games for example).  I
agree that C++ is a small part of a much larger computer world.  Yet C++, or
low-level programming in general, will have a very significant place for a
*long* time yet.

> > In order to lend credence to your argument, give me an example of some part
of
> > the core language that you don't understand.  With decent reference
materials,
>
> I can't give you any good examples of that. I've read the entire
> standard many times over, and I actually claim to understand most of it.
> All modesty aside (not that anyone's ever accused me of having any :-)
> I'm an extremely intelligent person - a language that I had any
> significant trouble understanding would be far too difficult for the
> average programmer, and C++ comes closer to that limit than most
> languages I know.

The "average" programmer uses VB because C++ (for them) is too complicated.  I
say, "good riddance."  That increases my value automatically.  The point of C++
is not a competition for the largest number of "religious" users.  "C++ is a
general-purpose programming language with a bias toward systems programming...."
Systems programming == complicated (in most cases).  C++ is not a language for
*average* programmers, since it is already out of that league entirely.

> > anything that you can think of you can learn just by looking it up while
trying
> > to find it.  What is the most complicated part of C++ in your opinion?
>
> Overloading, especially as a result of templates. Name lookup, overload
> resolution, and template argument deduction are among the trickiest
> features of the language. Even experts on the committee sometimes
> disagree on the correct interpretation. The issues list for the C++
> language <http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_toc.html> has
> 288 items on it, and the standard library
> <http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-toc.html> has another
> 322, and a large fraction of the issues on either list have not yet been
> resolved. That is not an indication of an easily understood language.

Once again, these are problems and ambiguities mostly in the standard itself.
Also, they are problems that are not as generally important to real-world
problems as one might think, since overloading (and consequently name lookup) is
also syntactic sugar.  Do you wish overloading never existed?  It doesn't *do*
anything at all--except add complication.

> > Templates, maybe?  Much template code is only complicated because of a lack
of
> > features and a somewhat half-baked template system (albeit the best one
> > currently available in any language).  Maybe name-lookup from within a
template?
> > Why is that hard to grasp?  I'd really, for once, like to see some examples
of
> > why C++ itself is too complicated rather than someone's misuses of it.
>
> The way in which an overly complex language manifests that fact is
> through people's misuse of it. You can always blame the programmer for
> not understanding, but if there are too many programmers failing to
> understand it, and too many other programmers avoiding failure by
> avoiding the language, then the language itself is too complex. I'm not
> saying that C++ is there yet, but if too many features are added in the
> next round of standardization, it will get there.

No, there are too many programmers that don't care about whether someone else
can understand what they wrote.  There are too many programmers that don't care
whether they are using "good style."  They just want the quick and dirty fix.
You cannot blame a language for that, no matter how complex it is.  Bad design
is possible in any language--that is not the province of a standard committee.
Generally, people use bad designs because they only care about the end result,
not portability, compliance, maintenance, or elegance.  I agree that you can't
add too much too fast, but that is only a matter of timing not whether it should
or shouldn't be part of the language.  I'll put it a different way:  if the
committee only adds a few library features, very minor core language
enhancements, and a few clarifications/corrections to what is already currently
in the standard, what is the point of me (or anyone else) caring about the
standard when it takes them so long to do very little?  It has to be *worth* the
wait to justify its existence.  I'll give you an example that many people want
(which I only really want for a few reasons, this example being one of them
(orthagonalness <--is that a word?), the other being operator new.):
overloading based on return type, which has not been accepted primarily because
they don't want the function call to depend on context.  However:

typedef void (*pf)(int, int);

void f();
void f(int, int);

void g() {
    pf Context = &f; // which "f" depends on context anyway, the mechanism is
already mostly there!
}

How is that a whole lot different than this...?

int f();
void f();

void g() {
    int x = f();
}

This relies on the same amount of context as the previous example.  sizeof()
must already determine the type of an expression to evaluate its size.  The
mechanism is pretty much "self-implemented" already.  Of course, this could
break some programs, so you could make return type overloading only applicable
when parameter overloading is ambiguous.  That would break *no* programs because
the ambiguity wouldn't currently compile anyway.

I don't think that we disagree to the extent that it seems.  I don't think that
everything should be added at once, but things *should* be added over time.

Paul Mensonides

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

SB> Adding things to an existing good thing can in fact make it
SB> inferior.

Yes, it can; I should have been more explicit in presenting my reasoning.

SB> Consider a cherry pie, then the result of pouring a liter
SB> of vinegar over it. The result still encompasses the original
SB> cherry pie, but I think most people would agree that the result
SB> is markedly inferior.

Ah, but the *nature* of the cherry pie is changed by the addition of
vinegar! Once the vinegar is added, I cannot go back to the original cherry
pie. This differs from the C++/C issue, where C is completely intact and
available to me if I want to ignore the C++ additions. In other words, C++'s
additions did not prevent me from using "real" C, whereas the additional
vinegar *does* prevent me from eating a "real" cherry pie.

I'll bet I can get one of my kids to eat it, though... ;)

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
http://www.coyotegulch.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                ]

In article <MPG.157a07413bc0ea6498c2fd@news.mindspring.com>, Stan Brown
<brahms@mindspring.com> writes
>Adding things to an existing good thing can in fact make it
>inferior. Consider a cherry pie, then the result of pouring a liter
>of vinegar over it. The result still encompasses the original cherry
>pie, but I think most people would agree that the result is markedly
>inferior.

I once accidentally (while talking intensively about something trivial -
those that know me will understand that) poured hot syrup (I think the
connotation is similar both sides of the Atlantic, if not exactly the
same) over my meat and vegetables in the school dining hall. Both were
fine by themselves but the result was a little weird (I either ate it or
went hungry, and excellent motive for discovering the results of one's
errors)

Now, there are a substantial number of people who use C for small
programs (often less than a thousand lines) who firmly believe that all
the additions to C++ are overly sweet and result in something that is
weird in their work environments. Assertions that they are using an
inferior tool is not going to make friends.

Another analogy, if you were a master craftsman who used hand tools to
turn out miniature carvings, you might not think that a set of
electrical carpentry tools were better, though if you made furniture you
might feel very strongly that they were.

We should focus on making C++ as good as it can be and leave
proselytising to the religious nuts on crank TV. Initially C++ had to
carve out an estate from the overly extended domain of C. Large, even
moderately large programming almost certainly benefits from C++, but I
am yet to be convinced that that is true for the many small programs
that manage our lives via embedded controllers in such things as cars.



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


======================================= MODERATOR'S COMMENT:
 I was going to go eat lunch, but after approving these posts I've lost my appetite. :-)

---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

"Kiril Avdeiv" <kavdeiv@mail.ru> wrote:
> But the thing is that "the designer and original implementor of C++"
> blatantly says that "C++ is a better C" on his web-site.
> http://www.research.att.com/~bs/C++.html
>
> A lot of people see him as the first and the most trusted resource
> of information on C++...

I certainly agree. It was talking with Bjarne 12 years ago that convinced me
to move to C++. I've never looked back.

Although I did stray for a while into Java -- forgive me, for I have sinned!
;)

Bjarne is the father of C++ -- and not only is his opinion expected, it is
correct in *my* opinion. But it is still on opinion. After all, James
Gosling thinks Java is superior to C++, and I don't think many of us
slavishly agree with Gosling merely because he is Java's inventor...

> This is more plein fore thause with English as thei secont langooge

>From what I see on the web, I think English is a second language for most
Americans! :) God knows what they really speak...

....and I'm going back to "order" anyway, because it sounds cooler. ;)

--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
http://www.coyotegulch.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                ]

Kiril Avdeiv wrote:
...
> But the thing is that "the designer and original implementor of C++"
> blatantly says that "C++ is a better C" on his web-site.
> http://www.research.att.com/~bs/C++.html

Sure - it's an opinion that in many ways I agree with. It just has no
proper place in a language standard.

I suppose it could be taken as a specification :-) As such, it would
prohibit implementations that aren't better, in every possible way, than
any C implementation on the same platform; this might require
implementors to deliberately de-optimize their C compilers to make them
worse than their C++ compilers. :-)

> A lot of people see him as the first and the most trusted resource of
> information on C++...

First, certainly. However, with no disparagement intended, the standard
itself now supersedes him as a trusted source. If he says one thing, and
the standard says another, it's the standard that's right, by
definition. Of course, in such a case the standard should probably be
modified to match his statements. Despite his prestige, such a change
would not automatically be approved. Like it or not, standardization
means that the language is now being designed by a committee, not by a
single individual.

---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

"Bjarne Stroustrup" <bs@research.att.com> wrote:
> In which ways do two separate but closely related languages
> maintaining divergent evolutions controlled by separate committees
> help the C and C++ programming communities (or is that the C and
> C++ programming community)?

We have two distinct communities, for C and C++, divided more by tradition
and philosophy than by any practical considerations. I think of this
as a religious schism -- and for better or worse, we're stuck with it.

While C is not critically important to you, me, and many other members of
this forum, it is a popular choice for many people. C is not dead, not by a
long shot -- and converting many dedicated C programmers to C++ is a
daunting task. The Linux/Open Source/Free Software community is one of the
most important and dynamic areas of software development -- and as your
Slashdot experience demonstrated, there is considerable resistance to C++
from people who are quite comfortable with C.

I don't see an independent C standard as a threat to C++. Yes, C99 is bound
to cause some limited confusion in some areas (do I use _Complex or
complex<>?) -- but such issues are really rather trivial. I'll keep using
complex<>, and let the C programmers do whatever makes them happy.

Back in September of last year, we (the members of this newsgroup) were
involved in a hot-and-heavy discussion of C99 and its incompatibilities with
C. I'm one of those who feels that C99 made some exceptionally poor and
unnecessary decisions that cripple its compatibility with C++. Still, in the
end, we will continue to use C++, and others will use C99, and the future of
C++ is harmed very little (if at all) by a C99 standard.

Perhaps some people have an emotional stake in a conflict between C and C++;
I get the impression that it somehow affronts some C++ developers that C
people have not yet "seen the light." Me? I merely want the best tool for
the job (in my opinion, C++), and I let other people decide which tools work
best for them. The only way a C standard affects C++ is if we obsess about
their decision to follow a different road...

--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
http://www.coyotegulch.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                ]

"Scott Robert Ladd" <scott@coyotegulch.com> wrote in message news:<hYaP6.284713$fs3.48491196@typhoon.tampabay.rr.com>...
> "Better" is an entirely subjective term that can not be quantified by an
> explicit document (such as a standard). Anyone who says "C++ is a better C"
> is expressing an opinion, perhaps based in fact, but an opinion nonetheless.
> The purpose of the C++ Standard is to describe the language in detail --
> opinions have no place in such a document.
>
> As for the "solid ground" you seek: Since C++ encompasses the C90 standard,
> it stands to reason that C++ can not be "inferior" to C90. Since C++ extends
> C90 with numerous additions, it is quite reasonable to suppose that C++ is
> "better" than C90, since it allows a programmer to do more.
Well, be that as it may, but what's then the purpouse of running the
two commities in parallel? If one is clearly inferior to the other - a
kind of waste of resources, isn't it?

>
> Whether or not C++ should always be chosen over C is a matter based on
> practical considerations (what compilers do I have?) and personnel issues
> (do my programmers know C++ well-enough to use it effectively?). From a
> purely technical perspective, there is nothing I can do in C90 that I cannot
> accomplish in C++. And there are many things I can do in C++ that are beyond
> C90's abilities.
That's I agree with.

> --
> Scott Robert Ladd
> Master of Complexity, Destroyer of Order and Chaos
Please spare Order

Kiril

---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

> Well, be that as it may, but what's then the purpouse of running the
> two commities in parallel? If one is clearly inferior to the other - a
> kind of waste of resources, isn't it?

Well... some people have no interest in C++, and a vast segment of the
world's codebase is in C, so it seems logical to continue maintaining two
standards.

Again, we're talking opinion, not fact. Some people think C is superior to
C++ because the former is simpler and easier to implement. Others prefer
Java over C++ -- and then you have the heretics like myself, who regularly
work in many languages. While I prefer C++, I do not believe any one
programming language can (or should!) solve every development problem.

As for sparing Order... well, I'm using as the traditional opposite of
Chaos, where it means "stasis". That's one problem with English... many
words have so many meanings. How about the change I made below?

--
Scott Robert Ladd
Master of Complexity, Destroyer of Stasis and Chaos
http://www.coyotegulch.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                ]

"Scott Robert Ladd" <scott@coyotegulch.com> wrote in message
news:hYaP6.284713$fs3.48491196@typhoon.tampabay.rr.com...
> As for the "solid ground" you seek: Since C++ encompasses the C90
standard,
> it stands to reason that C++ can not be "inferior" to C90.

That would be the case if it did, but it does not.
Nor does it claim to.  And it's not just trivia like
new keywords clashing with variable names.



---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

"Scott Robert Ladd" <scott@coyotegulch.com> wrote in message news:<qHzP6.290370$fs3.49869436@typhoon.tampabay.rr.com>...
> > Well, be that as it may, but what's then the purpouse of running the
> > two commities in parallel? If one is clearly inferior to the other - a
> > kind of waste of resources, isn't it?
>
> Well... some people have no interest in C++, and a vast segment of the
> world's codebase is in C, so it seems logical to continue maintaining two
> standards.
>
> Again, we're talking opinion, not fact. Some people think C is superior to
> C++ because the former is simpler and easier to implement. Others prefer
> Java over C++ -- and then you have the heretics like myself, who regularly
> work in many languages. While I prefer C++, I do not believe any one
> programming language can (or should!) solve every development problem.
I agree with you fully saying that "C++ is a better C" may be
misleading as its just an opinion.

But the thing is that "the designer and original implementor of C++"
blatantly says that "C++ is a better C" on his web-site.
http://www.research.att.com/~bs/C++.html

A lot of people see him as the first and the most trusted resource of
information on C++...

> As for sparing Order... well, I'm using as the traditional opposite of
> Chaos, where it means "stasis". That's one problem with English... many
> words have so many meanings.
I have to apologize to you. I didn't know of that meaning of the noun
"order".

> How about the change I made below?
> --
> Scott Robert Ladd
> Master of Complexity, Destroyer of Stasis and Chaos
> http://www.coyotegulch.com
This is more plein fore thause with English as thei secont langooge
:o)

Kiril

---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

It seems Scott Robert Ladd <scott@coyotegulch.com> wrote in
comp.std.c++:
>As for the "solid ground" you seek: Since C++ encompasses the C90 standard,
>it stands to reason that C++ can not be "inferior" to C90.

While I agree with the conclusion (C++ is not inferior to C90), as a
matter of strict logic I don't think the above statement is a proper
inference.

Adding things to an existing good thing can in fact make it
inferior. Consider a cherry pie, then the result of pouring a liter
of vinegar over it. The result still encompasses the original cherry
pie, but I think most people would agree that the result is markedly
inferior.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
                                  http://oakroadsystems.com
C++ FAQ Lite: http://www.parashift.com/c++-faq-lite/
the C++ standard: http://webstore.ansi.org/
reserved C++ identifiers: http://oakroadsystems.com/tech/cppredef.htm
more FAQs: http://oakroadsystems.com/tech/faqget.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                ]

"Better" is an entirely subjective term that can not be quantified by an
explicit document (such as a standard). Anyone who says "C++ is a better C"
is expressing an opinion, perhaps based in fact, but an opinion nonetheless.
The purpose of the C++ Standard is to describe the language in detail --
opinions have no place in such a document.

As for the "solid ground" you seek: Since C++ encompasses the C90 standard,
it stands to reason that C++ can not be "inferior" to C90. Since C++ extends
C90 with numerous additions, it is quite reasonable to suppose that C++ is
"better" than C90, since it allows a programmer to do more.

Whether or not C++ should always be chosen over C is a matter based on
practical considerations (what compilers do I have?) and personnel issues
(do my programmers know C++ well-enough to use it effectively?). From a
purely technical perspective, there is nothing I can do in C90 that I cannot
accomplish in C++. And there are many things I can do in C++ that are beyond
C90's abilities.

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
http://www.coyotegulch.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                ]

Kiril Avdeiv wrote:
>
> I just wonder why the ISO 14882 International standard omits this
> ubiquitous phrase that "C++ is a better C" or, maybe, something like
> "ISO 14882:1998 Programming languages - C++ is a better ISO 9899:1990
> Programming languages - C"?
>
Why should it.  Standards aren't in the business of promoting the
languages they express or ranking themselves against others.  The
standard isn't designed for general instruction.

---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

Wed, 23 May 2001 13:41:59 GMT Kiril Avdeiv =CE=C1=D0=C9=D3=C1=CC:
>I just wonder why the ISO 14882 International standard omits this
>ubiquitous phrase that "C++ is a better C" or, maybe, something like
>"ISO 14882:1998 Programming languages - C++ is a better ISO 9899:1990
>Programming languages - C"?

>A good question, isn't it?

No, rather just good sense of humour :)

--=20
jk

---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]

I just wonder why the ISO 14882 International standard omits this
ubiquitous phrase that "C++ is a better C" or, maybe, something like
"ISO 14882:1998 Programming languages - C++ is a better ISO 9899:1990
Programming languages - C"?

Almost every writer on C++, including Bjarne Stroustroup, says so. The
absence of this statement in the standard makes me and a number of my
co-workers question the existance of any solid ground behind the
statement (the first one, of course).


A good question, isn't it?

Kiril

---
[ comp.std.c++ is moderated.  To submit articles, try just 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                ]