 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
John Nagle
Guest
|
 Posted: Tue Aug 23, 2005 3:17 am Post subject: C++ standard life cycle |
 |
|
I just came across this note from the Pascal ISO standards committee:
Annual Report for J9, Pascal
June 2003 through June 2004
1. Executive Summary
For the 5-year maintenance review for the U.S. Extended Pascal Standard,
INCITS/ISO/IEC 10206 :1991 [1999], Information Technology - Programming
languages - Extended Pascal, the committee voted unanimously (4-0-0)
that the standard should be reaffirmed for another 5-year period.
The status of the Pascal committee is in “Maintenance”. This corresponds
with the Pascal and Extended Pascal standards projects, which are in
maintenance mode. No meetings were held in 2003 and to date in 2004. All
committee business is conducted via e-mail, telephone calls, and post.
The last committee meeting was in April of 1995.
Membership remains stable, as it has been for years, at four principal
members. The positions of Vice Chairman, International Representative,
and Vocabulary Representative remain vacant.
No new work is anticipated at this time.
===
The first ISO standard for Pascal was issued in 1983. The Pascal
working group was wound up on April 30, 1995, and there has been
no new work since then. So that standards activity had a life of
12 years, a surprisingly short period for what was once a major
language.
ALGOL was first described in 1960, and standards activity began
in 1962, under the auspices of IFIP. The ALGOL Bulletin ceased
publication in 1976, so that standards effort had a life of 14 years.
The Common LISP standards effort began in 1983, and appears to have
ceased operations in 1994. So that effort had a lifetime of
11 years.
FORTRAN and COBOL still have ongoing standards efforts, 40 years on.
(COBOL is adding a "<>" operator, support for ISO 8601:2000 dates
(a bit late for Y2K), and, surprisingly, method overloading.)
But the rate of change is very low.
The first ISO standard for ANSI C was issued in 1990, and continues,
so that effort is at year 14.
So, with the exception of FORTRAN and COBOL, the earliest of major
languages, the active lifespan of a language standards effort seems to
be in the range of 11 to 15 years.
The first ISO standard for C++ was issued in 1997, so we are now at
year 8 with C++. This gives us a sense of where we are in the
life cycle. There's probably one more major revision cycle
left in the lifespan.
John Nagle
Animats
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
 |
P.J. Plauger
Guest
|
| Posted: Tue Aug 23, 2005 1:50 pm Post subject: Re: C++ standard life cycle |
|
|
"John Nagle" <nagle (AT) animats (DOT) com> wrote
| Quote: | The first ISO standard for Pascal was issued in 1983. The Pascal
working group was wound up on April 30, 1995, and there has been
no new work since then. So that standards activity had a life of
12 years, a surprisingly short period for what was once a major
language.
ALGOL was first described in 1960, and standards activity began
in 1962, under the auspices of IFIP. The ALGOL Bulletin ceased
publication in 1976, so that standards effort had a life of 14 years.
The Common LISP standards effort began in 1983, and appears to have
ceased operations in 1994. So that effort had a lifetime of
11 years.
FORTRAN and COBOL still have ongoing standards efforts, 40 years on.
(COBOL is adding a "<>" operator, support for ISO 8601:2000 dates
(a bit late for Y2K), and, surprisingly, method overloading.)
But the rate of change is very low.
The first ISO standard for ANSI C was issued in 1990, and continues,
so that effort is at year 14.
So, with the exception of FORTRAN and COBOL, the earliest of major
languages, the active lifespan of a language standards effort seems to
be in the range of 11 to 15 years.
The first ISO standard for C++ was issued in 1997, so we are now at
year 8 with C++. This gives us a sense of where we are in the
life cycle. There's probably one more major revision cycle
left in the lifespan.
|
Averages don't mean much when you have a lumpy distribution. What
this data reaffirms to me is that about half of all programming
language standards are failures -- they are ignored in the
marketplace. Since few failures slink away quietly, they appear as
documents that nobody feels the need to change. (And yes, I know
that the C committee recently voted to reaffirm C99 unchanged.)
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Jaap Versteegh
Guest
|
| Posted: Tue Aug 23, 2005 2:19 pm Post subject: Re: C++ standard life cycle |
|
|
Why would no work on the standard mean an end of life cycle ? Pascal and C
are still in active use and therefore their standard is. I'd rather say that
these languages are apparently mature.
Jaap
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Tue Aug 23, 2005 2:21 pm Post subject: Re: C++ standard life cycle |
|
|
In article <X5fOe.178$dw4.134 (AT) newssvr29 (DOT) news.prodigy.net>, John Nagle
<nagle (AT) animats (DOT) com> writes
| Quote: | The first ISO standard for Pascal was issued in 1983. The Pascal
working group was wound up on April 30, 1995, and there has been
no new work since then. So that standards activity had a life of
12 years, a surprisingly short period for what was once a major
language.
ALGOL was first described in 1960, and standards activity began
in 1962, under the auspices of IFIP. The ALGOL Bulletin ceased
publication in 1976, so that standards effort had a life of 14 years.
The Common LISP standards effort began in 1983, and appears to have
ceased operations in 1994. So that effort had a lifetime of
11 years.
FORTRAN and COBOL still have ongoing standards efforts, 40 years on.
(COBOL is adding a "<>" operator, support for ISO 8601:2000 dates
(a bit late for Y2K), and, surprisingly, method overloading.)
But the rate of change is very low.
The first ISO standard for ANSI C was issued in 1990, and continues,
so that effort is at year 14.
So, with the exception of FORTRAN and COBOL, the earliest of major
languages, the active lifespan of a language standards effort seems to
be in the range of 11 to 15 years.
The first ISO standard for C++ was issued in 1997, so we are now at
year 8 with C++. This gives us a sense of where we are in the
life cycle. There's probably one more major revision cycle
left in the lifespan.
|
You are being inconsistent in the way you count. In some cases you
measure from the start of Standards activity and in others from the
first Standard release. C is in about year 23 from the start of
standardisation, C++ in year 16. And where is Ada in your list?
I think all your data demonstrates is that some languages become so
important to some communities that they are willing to fund ongoing
work. If I were a betting man, I would lay good odds that C++ will still
be around and under continued development in 2020.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Jerry Coffin
Guest
|
| Posted: Wed Aug 24, 2005 6:34 am Post subject: Re: C++ standard life cycle |
|
|
Jaap Versteegh wrote:
| Quote: | Why would no work on the standard mean an end of life cycle ?
|
Because the programming environment changes enough, quickly enough,
that almost anything that doesn't adapt quickly becomes obsolete.
Granted, some areas change more quickly than others, but even Fortran
(arguably in the most stable area there is) has changed substantially
over the years.
| Quote: | Pascal and C are still in active use and therefore their standard is.
|
As standardized, Pascal has never really been actively used -- I'm only
aware of one Pascal compiler that ever really even tried to implement a
standard, and TTBOMK, it never saw much use. A conforming
implementation of Pascal would be required to reject nearly everything
most people currently write as Pascal.
| Quote: | I'd rather say that these languages are apparently mature.
|
While C has certainly matured, it's also stagnated to an extent -- or
at least the area in which it's the language of choice has narrowed
considerably over time.
--
Later,
Jerry.
The universe is a figment of its own imagination.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
msalters
Guest
|
| Posted: Thu Aug 25, 2005 3:43 am Post subject: Re: C++ standard life cycle |
|
|
John Nagle schreef:
| Quote: |
The first ISO standard for Pascal was issued in 1983. The Pascal
working group was wound up on April 30, 1995, and there has been
no new work since then. So that standards activity had a life of
12 years, a surprisingly short period for what was once a major
language.
ALGOL was first described in 1960, and standards activity began
in 1962, under the auspices of IFIP. The ALGOL Bulletin ceased
publication in 1976, so that standards effort had a life of 14 years.
The Common LISP standards effort began in 1983, and appears to have
ceased operations in 1994. So that effort had a lifetime of
11 years.
FORTRAN and COBOL still have ongoing standards efforts, 40 years on.
(COBOL is adding a "<>" operator, support for ISO 8601:2000 dates
(a bit late for Y2K), and, surprisingly, method overloading.)
But the rate of change is very low.
The first ISO standard for ANSI C was issued in 1990, and continues,
so that effort is at year 14.
So, with the exception of FORTRAN and COBOL, the earliest of major
languages, the active lifespan of a language standards effort seems to
be in the range of 11 to 15 years.
The first ISO standard for C++ was issued in 1997, so we are now at
year 8 with C++. This gives us a sense of where we are in the
life cycle. There's probably one more major revision cycle
left in the lifespan.
|
At least. However, I'd like to suggest an explanation. The number of
revisions is probably strongly related to both the number of LOCs
in production use, and the rate of change. Certainly, FORTRAN and
COBOL score high in the 'LOCs in production' category. Pascal most
certainly doesn't. If I'd have to estimate the lifespan of C++ based
on this, I'd give it at least 25 years (i.e. we'll see C++1x and C++2x
too, although I do suspect these will be even more library-oriented.)
Regards,
Michiel Salters
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Thu Aug 25, 2005 3:45 pm Post subject: Re: C++ standard life cycle |
|
|
Francis Glassborow wrote:
| Quote: | In article <X5fOe.178$dw4.134 (AT) newssvr29 (DOT) news.prodigy.net>,
John Nagle <nagle (AT) animats (DOT) com> writes
|
[...]
| Quote: | I think all your data demonstrates is that some languages
become so important to some communities that they are willing
to fund ongoing work. If I were a betting man, I would lay
good odds that C++ will still be around and under continued
development in 2020.
|
I think that Plauger hit the nail on the head when he pointed
out that averages don't mean much when there is a strong
variance. Note that in some African countries, the "average"
lifespan is something like 45; the difference, when compared to
North America or Europe, isn't that a lot of people die in their
fourties; the difference is that there are a lot more infant
deaths -- if half of the population dies in their first year,
and the other half lives to 90, that makes an average of 45.
I suspect that there is a similar phenomenon in programming
languages. Some languages fail to attain a critical volume of
code, and for all intents and purposes die. Once the critical
volume is reached (e.g. the case of Fortran or Cobol), however,
the language effectively lives forever. (At least in name --
modern Fortran has very little resemblance to Fortran IV.) In
the case of C++, I don't think that there is any doubt that the
critical volume has been reached.
The case of C is an interesting one. There, too, I don't think
that there can be any doubt that the critical volume was
reached. If C dies, it will basically be because C++ has been
able to subsume it -- the C compatibility of C++ means that much
C code is almost C++ code, migrating it to C++ (and thus
reducing the effective volume) is affordable. So C could
conceivably be an exception to the above.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Tony Delroy
Guest
|
| Posted: Fri Aug 26, 2005 4:15 pm Post subject: Re: C++ standard life cycle |
|
|
| Quote: | There's probably one more major revision cycle left in [C++] the lifespan.
|
COBOL and FORTRAN stand out as having been core parts of corporate and
governmental financial and engineering systems, while in my experience
Pascal is typically employed in Universities and PCs. Bigger systems
take more effort to displace, and the dependency makes organisations
place huge pressure on standards bodies form a bridge between companies
desparately trying to continue to use critical systems and vendors
who'd be reluctant to enhance an old language if only one customer was
demanding the change.
This mirrors hardware, where VAX computers are still available and
support promised despite several changes to the ownership of
OpenVMS/VAX/Alpha technology. There are enough telcos, defense
projects etc with no practical way off the technologies that pressure
and entice the vendors.
As for C++... I think John's probably onto something. It's inevitable
that in the next couple years someone will release a C++ system with
full compile-time introspection, and what we now call C++ will be to
that "C++ with introspection" what C is to C++. I've written such a
system for a previous client, and plan to do something similar again
for public release. From a programming perspective, it's actually
relatively simple, and existing systems like OpenC++ illustrate the
larger techniques, without yet hitting on the necessary blend of
flexibilitiy, practicality, usability, and productivity.
Cheers,
Tony
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
John Nagle
Guest
|
| Posted: Fri Aug 26, 2005 5:23 pm Post subject: Re: C++ standard life cycle |
|
|
Tony Delroy wrote:
| Quote: | There's probably one more major revision cycle left in [C++] the lifespan.
COBOL and FORTRAN stand out as having been core parts of corporate and
governmental financial and engineering systems, while in my experience
Pascal is typically employed in Universities and PCs.
|
Pascal was the first major language in microcomputing. The
personal computer revolution was powered by Pascal. The DOS
machines used Borland's Turbo Pascal (which, significantly,
was nothing like the ISO standard), and Lisa/Macintosh machines
used several varieties of Pascal, some with object-oriented
extensions.
The standards community was never able to get together on
a usable version of Pascal for systems programming. Wirth
was off doing Modula and Oberon, the ISO standarized version
was too restrictive (it couldn't even handle an I/O error),
and no organization took on the standards effort.
And that killed the language. It wasn't a technical problem.
To some extent, this is happening to C++. Microsoft is
going off in their own direction (extra keywords, "managed C++",
".NET", and now "C#"). AT&T is no longer a factor in computing.
The Linux community is staying with C. (That, incidentally,
needs to be thoroughly studied by those working on the C++
standard. It's worth understanding why a sizable community
has looked at and firmly rejected C++.) Application-level
programming is transitioning to other, safer, languages.
Issues like this need more attention in the standards
process. This is more important than adding cool features
to templates that very few people will ever use.
John Nagle
Animats
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Thorsten Ottosen
Guest
|
| Posted: Fri Aug 26, 2005 9:28 pm Post subject: Re: C++ standard life cycle |
|
|
"John Nagle" <nagle (AT) animats (DOT) com> wrote
| Quote: | The Linux community is staying with C. (That, incidentally,
needs to be thoroughly studied by those working on the C++
standard. It's worth understanding why a sizable community
has looked at and firmly rejected C++.) Application-level
|
How can one reject something one does not understand
nor care to understand?
best regards
-Thorsten
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Marc Mutz
Guest
|
| Posted: Sat Aug 27, 2005 5:52 am Post subject: Re: C++ standard life cycle |
|
|
Thorsten Ottosen wrote:
<snip>
| Quote: | The Linux community is staying with C. (That,
incidentally, needs to be thoroughly studied by those
working on the C++ standard. It's worth understanding
why a sizable community has looked at and firmly
rejected C++.) Application-level
How can one reject something one does not understand
nor care to understand?
snip |
Thorsten, as a member of said community that happens to be
in one of the few camps (KDE) that uses almost only C++
as it's programming language I feel strongly insulted by
your comment.
John, I agree with you that the C++ community should think
about why the majority of Free Software developers refuse
to use C++. Complexity is the prime argument I hear[1].
My personal feeling (which might be completely off) is
that this complexity is for threefold reasons, two of
which involve the language's class library, and the last
one the core language efford.
First, all levels of 'core' C++ libraries (boost, tr1, the
'old' standard library and to a lesser extend the C
library) present themselves as a conglomerate of
independantly designed components that are thrown into a
pot without stirring. It seems to me that large,
extensive, 'single-source' class libraries like .net, the
Java class library, and - if I may add this - Qt provide
_a lot_ more uniform APIs and also have the ability to
dump dead ends over board, something that C++ refuses or
is unable to do. API consistency is very important for
the ease-of-use of a language, and C++ fares very badly
in this regard.
Second, the C++ standardized (even when including boost
here) libraries are way too low-level. We don't even have
a standardized xml parser library, although both SAX and
DOM could be trivially adapted and standardized almost
as-is. We don't have classes for common network
protocols, or even socket programming in general. And I
won't even start thinking about GUIs. I know this is
mostly due to the way the standardisation process works.
No-one gets paid for working on the standard, and I guess
that's the major drawback of C++.
Third, the reluctance to change the core langauge. Sure,
C++ compilers are complex beasts, and further
complexification of the core language might reduce the
number available high-quality C++ compilers, but other
langauges demonstrate that langauge support for e.g.
properties, delegates/signals-slots/callbacks (whatever
you want to call them) are welcome in the developer
community.
Considering that the C++ community itself only came to
terms in the last few years with the 'monster' it created
back in the nineties (TMP, exception-safety guidelines,
export), it shouldn't be of any wonder if people not on
the C++ research bleeding egde have trouble groking all
the little details of C++. In the same vein, as the
communitiy learns what C++ is all about, it might be a
good idea to revise the standard to accomodate what we
have learned. After all, all software rots and needs to
be kept up-to-date with the growing knowledge about the
problem domain and implementation techniques, and why
should the standard class library be any different. The
STL written in the boost era would look vastly different.
But due to backwards compatibility and lack-of-manpower,
local fixes (bind, function) need to ba added instead of
a putting up a coordinated efford to design an STLv2 that
looked like this:
std::vector<int> v = ...;
std::vector<int> r = ...;
std::transform( v, r, std::bind( plus(), _1, 42 ) );
Another example: Everyone seems to agree that exception
specifications are a failure. Why not re-create them to
do what most people new to C++ expect them to do: To make
the compiler enforce the specifications at compile time.
Make void foo() throw() { throw 5; } ill-formed:
error: function 'foo()' is not allowed to throw 'int'.
Or language support for lamba functors:
std::for_each( v, x->{ x += 42; } ); //whatever syntax
std::transform( v1, v2, (x,y)->{ x+y; } );
It's amazing that you can add lambda functions without
explicit language support and I consider the authors or
such libraries ingenious scientists that further the
understanding of a language that is showing a most
curious manifestation of emergent behaviour (TMP). But
apart from very simple cases, the syntax is not exactly
readable. Or maybe the need for a lambda library just
shows that C++ badly lacks a foreach keyword.
Let me stress that I'm awestruck at the power of modern
C++ template libraries like Spirit or Boost.Lambda and
that I fully understand that to shoulder large redesigns
of the standard library, the committee simply lacks the
man power, but we must ask why the industry lets this
happen. Maybe the turn-around times for the ISO process
is too long for companies to submit their stuff and get
involved.
Just my 2 cents. Sorry for the long post. You probably
know all of the above already.
Marc
[1] Personally, I think that younger languages like
Python, C# or Java will also become more complex as they
add features C++ has had for the last decade already.
These features are needed to write robust code and I'm
looking forward to see new lean language effords like
python was when it was invented pop up with a
functionality set to rival C++ and but with a leaner,
more consistent, less-dark-corner design.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Thorsten Ottosen
Guest
|
| Posted: Sat Aug 27, 2005 5:56 pm Post subject: Re: C++ standard life cycle |
|
|
"Marc Mutz" <marc (AT) klaralvdalens-datakonsult (DOT) se> wrote
Thorsten Ottosen wrote:
<snip>
| Quote: | The Linux community is staying with C. (That,
incidentally, needs to be thoroughly studied by those
working on the C++ standard. It's worth understanding
why a sizable community has looked at and firmly
rejected C++.) Application-level
How can one reject something one does not understand
nor care to understand?
snip |
Thorsten, as a member of said community that happens to be
in one of the few camps (KDE) that uses almost only C++
as it's programming language I feel strongly insulted by
your comment.
You shouldn't. Obviously you don't fall into that camp I'm talking about.
I've meat some really important FreeBSD guys...really smart people
working on OS cores. But they don't understand the power of C++
and how it might help them. One of them said, he had given up
on C++ a long time ago. He's relunctant to change, even if it
could help him enourmously.
John, I agree with you that the C++ community should think
about why the majority of Free Software developers refuse
to use C++. Complexity is the prime argument I hear[1].
right, an that is often because they don't know how modern C++
works.
pot without stirring. It seems to me that large,
extensive, 'single-source' class libraries like .net, the
Java class library, and
The quality of the .Net class linbraries is not exactly
great. For example, I've never seen a weak container library before.
The remoting API is way to complex compare to what it should be
Second, the C++ standardized (even when including boost
here) libraries are way too low-level. We don't even have
a standardized xml parser library, although both SAX and
DOM could be trivially adapted and standardized almost
as-is. We don't have classes for common network
protocols, or even socket programming in general. And I
won't even start thinking about GUIs. I know this is
mostly due to the way the standardisation process works.
No-one gets paid for working on the standard, and I guess
that's the major drawback of C++.
right. we can't standardize everything. but C++ needs a
more of these libraries...and I'm pretty sure that they will
appear in boost within two years.
Third, the reluctance to change the core langauge.
what reluctance?
Sure,
C++ compilers are complex beasts, and further
complexification of the core language might reduce the
number available high-quality C++ compilers, but other
langauges demonstrate that langauge support for e.g.
properties, delegates/signals-slots/callbacks (whatever
you want to call them) are welcome in the developer
community.
properties are not really useful, except maybe for embedded domain
specific languages. signals/slots will be added as a library,
there is no need to make a core change for that.
Considering that the C++ community itself only came to
terms in the last few years with the 'monster' it created
back in the nineties (TMP, exception-safety guidelines,
export), it shouldn't be of any wonder if people not on
the C++ research bleeding egde have trouble groking all
the little details of C++.
right, they shoul have to. And C++0x will be much easier
to use. count on it.
should the standard class library be any different. The
STL written in the boost era would look vastly different.
But due to backwards compatibility and lack-of-manpower,
local fixes (bind, function) need to ba added instead of
a putting up a coordinated efford to design an STLv2 that
looked like this:
std::vector<int> v = ...;
std::vector<int> r = ...;
std::transform( v, r, std::bind( plus(), _1, 42 ) );
I have a proposal about this for C++0x in the next mailing.
(available in a week)
Another example: Everyone seems to agree that exception
specifications are a failure. Why not re-create them to
do what most people new to C++ expect them to do: To make
the compiler enforce the specifications at compile time.
Alisdair M. is working in this area. I think what everybody
don't expect is that it can terminate the program. whether we need
to detect it a compile time is another issue. I don't think
exception-specs are that useful, though.
readable. Or maybe the need for a lambda library just
shows that C++ badly lacks a foreach keyword.
Also described in one of my new papers. You may find the old version
here (it contains a few errors, though)
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1796.html
happen. Maybe the turn-around times for the ISO process
is too long for companies to submit their stuff and get
involved.
hear, hear.
Anyway, be sure that C+0x is going to be much easier to
use and and much more pleasant ride for everyone.
best regards
Thorsten
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Marc Schoolderman
Guest
|
| Posted: Sat Aug 27, 2005 7:25 pm Post subject: Re: C++ standard life cycle |
|
|
Marc Mutz wrote:
| Quote: | First, (...) API consistency is very important for the ease-of-use of a
language, and C++ fares very badly in this regard.
|
In any case, the standard C library is much worse. I also don't think
popular scripting languages like Python and perl are exemplary in this
regard.
| Quote: | Second, the C++ standardized (even when including boost
here) libraries are way too low-level.
|
I agree, but on the oter hand, ISO C also has a weak standard library,
but there you have external standards (POSIX/SUSv3) which build on it,
and a lot of widely available libraries.
IMHO, C++ is missing those external bindings. Even if I just want to use
C++ simply as a better C and not bother with templates and classes, e.g.
by just using 'string', namespaces and function overloading, I run into
issues, since a lot of interfaces are designed for pure C.
Many people wouldn't care that the C++ Standard doesn't have sockets or
threads if there were an external standard "POSIX/C++" or whatever.
| Quote: | Third, the reluctance to change the core langauge. (...)
Or maybe the need for a lambda library just
shows that C++ badly lacks a foreach keyword.
|
Personally, I'd rather see C++ adding support for nested functions (or
closures, or whatever you want to call them) since this is a more
general solution, and easy to learn. Lambda abstractions and "foreach"
serve pretty specialised needs.
But I doubt just changing or adding to the language like this would
convince people to 'ditch' C in favor of C++.
And actually; *Has* the free software community 'firmly rejected' C++?
Aren't there lots and lots of Qt apps and isn't KDE the default desktop
environment in most Linux distributions?
~Marc.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Chris Hills
Guest
|
| Posted: Sat Aug 27, 2005 10:16 pm Post subject: Re: C++ standard life cycle |
|
|
In article <gDpnOxSDAxCDFwzP (AT) robinton (DOT) demon.co.uk>, Francis Glassborow
<francis (AT) robinton (DOT) demon.co.uk> writes
| Quote: | In article <X5fOe.178$dw4.134 (AT) newssvr29 (DOT) news.prodigy.net>, John Nagle
[email]nagle (AT) animats (DOT) com[/email]> writes
The first ISO standard for Pascal was issued in 1983. The Pascal
working group was wound up on April 30, 1995, and there has been
no new work since then. So that standards activity had a life of
12 years, a surprisingly short period for what was once a major
language.
ALGOL was first described in 1960, and standards activity began
in 1962, under the auspices of IFIP. The ALGOL Bulletin ceased
publication in 1976, so that standards effort had a life of 14 years.
The Common LISP standards effort began in 1983, and appears to have
ceased operations in 1994. So that effort had a lifetime of
11 years.
FORTRAN and COBOL still have ongoing standards efforts, 40 years on.
(COBOL is adding a "<>" operator, support for ISO 8601:2000 dates
(a bit late for Y2K), and, surprisingly, method overloading.)
But the rate of change is very low.
The first ISO standard for ANSI C was issued in 1990, and continues,
so that effort is at year 14.
So, with the exception of FORTRAN and COBOL, the earliest of major
languages, the active lifespan of a language standards effort seems to
be in the range of 11 to 15 years.
The first ISO standard for C++ was issued in 1997, so we are now at
year 8 with C++. This gives us a sense of where we are in the
life cycle. There's probably one more major revision cycle
left in the lifespan.
You are being inconsistent in the way you count. In some cases you
measure from the start of Standards activity and in others from the
first Standard release. C is in about year 23 from the start of
standardisation, C++ in year 16. And where is Ada in your list?
|
I think it might be work re-doing the list in a more consistent from and
with some more of the languages to see if there is any correlation. Some
of it will depend on dates as well as time as I am sure modern working
with the Internet (ie web, ftp and email) has and a dramatic change of
the work flow etc in producing standards documents
| Quote: | I think all your data demonstrates is that some languages become so
important to some communities that they are willing to fund ongoing
work.
|
However that work is not always in the ISO standards area. Sometimes the
ISO standards meander off in a direction that differs from industry. C
and Basic are two I can think of.
| Quote: | If I were a betting man, I would lay good odds that C++ will still
be around and under continued development in 2020.
|
Not looking for an argument here I am just curious as to what grounds
you base that on and see if they apply to other languages. Ie is this
just a gut feeling or something that can be applied to other languages?
There must be some rules or equation that will cover the life of a
language. Perhaps redoing the list as you suggest in a more consistent
manner might yield some answers?
--
////////////////////////
//// Chris Hills Staffs England /////
/// [email]chris (AT) phaedsys (DOT) org[/email] www.phaedsys.org //
//////////////////////////
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Chris Hills
Guest
|
| Posted: Sat Aug 27, 2005 10:17 pm Post subject: Re: C++ standard life cycle |
|
|
In article <1124962740.444680.27940 (AT) g47g2000cwa (DOT) googlegroups.com>,
[email]kanze (AT) gabi-soft (DOT) fr[/email] writes
| Quote: |
The case of C is an interesting one. There, too, I don't think
that there can be any doubt that the critical volume was
reached. If C dies, it will basically be because C++ has been
able to subsume it -- the C compatibility of C++ means that much
C code is almost C++ code, migrating it to C++ (and thus
reducing the effective volume) is affordable. So C could
conceivably be an exception to the above.
|
C is interesting as it has a life of it's own, like (visual) Basic
outside the ISO standardisation. There is a lot of work going on with
it but mainly based around C90.
In the embedded world they use C for the vast a majority (assembler
comes next I think) and it is no way a sub set of C++. Actually it is
usually "almost" C90 + some extensions. As for migrating it to C++. this
is not possible as the most common platforms do not have C++ compilers
or debug tools.
C is not likely to die and is more likely to outlive C++. C based
languages are used in ASICS and FPGA's as well. IT is the lowest level
of high level language and thus makes sense for embedded work.
--
////////////////////////
//// Chris Hills Staffs England /////
/// [email]chris (AT) phaedsys (DOT) org[/email] www.phaedsys.org //
//////////////////////////
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
