Topic: The Death of C++


Author: Dominic North <Dominic.North@ping.be>
Date: 1996/10/24
Raw View
In article <326B5276.696F@emultek.co.il> on 21 Oct 1996 10:21:29 PDT
Clive Bluston <clive@emultek.co.il> wrote:
>Does the fact that C++ is under the control of
>a standards committee mean that it is doomed
>to extinction ?

 (...comments about features and standardisation process elided...)

>
> While these arguments are raging programmers will be
> flocking to Java. C++ will slowly fade out and
> disappear.
>

In article <199610221554.IAA04648@taumet.eng.sun.com> on 22 Oct 1996
10:16:09 PDT clamage@taumet.Eng.Sun.COM (Steve Clamage) wrote:

> No. C++ is doomed to extinction whether or not it is standardized.
> Every programming language is doomed to extinction, eventually.
> (At least I hope so.)

 (...further good arguments elided...)

> A proposal to standardize Java is already making its way through ANSI.
>
> In its present definition, Java does not address the same set of
> programming problems as C++, although there is considerable overlap.
> Both are general-purpose programming languages, suitable for many
> purposes. Neither is ideal for every purpose.
>

I would add a corollary to Steve's arguments.

One of the main strengths of Java is its portability. In particular,
this is now being heavily emphasised in the context of the WWW. Since
this is currently the main argument for the use of Java, and since
such portability inevitably depends on Java applets adhering to
strict standards, it seems likely that Java's own continued success will
soon come to depend on its own standardisation, whether by ANSI, or some
other organisation.

This may seem somewhat ironic in the light of Clive's original posting.
However, I would suggest that standardisation is (or will be) a sign of
maturity, rather than of impending doom, for both C++ and Java.

Dominic
Bruxelles, Wed, 23 Oct 1996 09:44 +0100
also cis:106136,2400
using Virtual Access 3.51 build 159 (32-bit)
on WinNT build 1057 (3.51)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]





Author: boukanov@sentef1.fi.uib.no (Igor Boukanov)
Date: 1996/10/22
Raw View
Robert Rodgers (rsrodger@wam.umd.edu) wrote:
> It's also a little late to be adding real threads to C++.  One similar
> feature which I'd like to see, though, is support for non-pre-emptive
> threads of execution (e.g., like Windows NT 4.x fibers).  This can
> actually be very handy, can often be used to replace "real" threads,
> and could be added without sacrificing efficiency or requiring the
> addition of full-fledged thread support (like a sync. library) or
> ballooning code.

Indeed, the implementation of such library is not a problem and can be done
in the more or less portable way for example via setjump / longjump and
u will get all benefit from multitasking for the price of several yield()
calls in a code. Moreover all libraries will be thread safe and u do
not have to worry about this issue with say STL.
This is known for decades and often used in embedding systems
and I really wonder why it is out of the standard.

--
Regards, Igor Boukanov.
igor.boukanov@fi.uib.no
http://www.fi.uib.no/~boukanov/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]





Author: clamage@taumet.Eng.Sun.COM (Steve Clamage)
Date: 1996/10/22
Raw View
In article 696F@emultek.co.il, Clive Bluston <clive@emultek.co.il> writes:
>The Death of C++
>
>Does the fact that C++ is under the control of
>a standards committee mean that it is doomed
>to extinction ?

No. C++ is doomed to extinction whether or not it is standardized.
Every programming language is doomed to extinction, eventually.
(At least I hope so.)

>The problem is that standards committees are inherently
>slow at adopting changes. Arguments like "this can be done by
>some form of existing syntax" or "not every platform
>supports this facility" are be used to slow down or
>prevent change.

Slowing down change helps languages to survive and thrive. The languages
which are most widely-known and widely-used are standardized. If a
language does not have a standard form, it cannot be used in any
arena where stability matters. (How can you maintain a million-line
program if language changes require you to modify the code every
few months just to keep the existing program legal?)

>While these arguments are raging programmers will be
>flocking to Java. C++ will slowly fade out and
>disappear.

A proposal to standardize Java is already making its way through ANSI.

In its present definition, Java does not address the same set of
programming problems as C++, although there is considerable overlap.
Both are general-purpose programming languages, suitable for many
purposes. Neither is ideal for every purpose.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]





Author: davidb@datalytics.com (David Bradley)
Date: 1996/10/22
Raw View
Clive Bluston <clive@emultek.co.il> wrote:

>Take a look at Java. It has every language construct
>every C++ user has ever dreamed of. Most of these
>could be added to C++ without a second thought.

But it is also missing some major features of C++

>While these arguments are raging programmers will be
>flocking to Java. C++ will slowly fade out and
>disappear.

Personally I'd like to see us freeze what we have, set the standard in
stone and move on to the next revision.  I think we've spent way to
much time tweaking it.

--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]





Author: Andrew Koenig <ark@research.att.com>
Date: 1996/10/23
Raw View
> Take a look at Java. It has every language construct
> every C++ user has ever dreamed of. Most of these
> could be added to C++ without a second thought. For
> example "finally" and "break <label>". Others could
> be added to the standard library. For example a standard
> thread library.

C++ and Java have little in common aside from a superficial
similarity of syntax.  Once you peer beneath the surface,
Java is much closer to Smalltalk than it is to C++.

I don't expect anyone to believe such a statement without evidence,
so I will present some.  Consider the following, which is an
implementation of one of the standard C++ library functions:

 template<class Iter, class X>
   Iter find(Iter begin, Iter end, const X& x)
 {
   while (begin != end && *begin != x)
     ++begin;
   return begin;
 }

I invite you to try to translate this function into Java.

I claim that a direct translation is impossible.  It is easy to
produce quite a variety of programs that do similar things, but
when you actually try to use them, they will be considerably
different in detail.

Similarly, I believe that it is easy to find small programs in
Java that cannot be readily translated into C++.

The languages are just plain different, period.
--
    --Andrew Koenig
      ark@research.att.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]





Author: seurer@rchland.ibm.com (Bill Seurer)
Date: 1996/10/23
Raw View
In article <199610221554.IAA04648@taumet.eng.sun.com>, clamage@taumet.Eng.Sun.COM (Steve Clamage) writes:
|> In article 696F@emultek.co.il, Clive Bluston <clive@emultek.co.il> writes:
|> >The Death of C++
|> >
|> >Does the fact that C++ is under the control of
|> >a standards committee mean that it is doomed
|> >to extinction ?
|>
|> No. C++ is doomed to extinction whether or not it is standardized.
|> Every programming language is doomed to extinction, eventually.
|> (At least I hope so.)

Actually, we have no experience with the "extiction" of any major
computer languages.  Some are in decline but I don't think any have
been around long enough.

Certainly if the C++ standardization committee gets set on not making
ANY change the language will go into decline sooner than later.  But
I don't think that is too likely.

|> >The problem is that standards committees are inherently
|> >slow at adopting changes. Arguments like "this can be done by
|> >some form of existing syntax" or "not every platform
|> >supports this facility" are be used to slow down or
|> >prevent change.
|>
|> Slowing down change helps languages to survive and thrive. The languages
|> which are most widely-known and widely-used are standardized. If a
|> language does not have a standard form, it cannot be used in any
|> arena where stability matters. (How can you maintain a million-line
|> program if language changes require you to modify the code every
|> few months just to keep the existing program legal?)

Java will die if it isn't standardized.  One of its promises is that if I
write a program on my PC at home it will work fine on my AIX workstation
here at work or on my friend's Mac.  If the language isn't standardized
there's no way that will ever pan out.

At first you expect a lot of turbulence but it has to settle down.

|> >While these arguments are raging programmers will be
|> >flocking to Java. C++ will slowly fade out and
|> >disappear.
|>
|> A proposal to standardize Java is already making its way through ANSI.
|>
|> In its present definition, Java does not address the same set of
|> programming problems as C++, although there is considerable overlap.
|> Both are general-purpose programming languages, suitable for many
|> purposes. Neither is ideal for every purpose.

Yup.  This is true of most pairs of languages.  I wouldn't want to write
a compiler in Java and I wouldn't want to write some web stuff in C++.
--

- Bill Seurer     ID Tools and Compiler Development      IBM Rochester, MN
  Business: BillSeurer@vnet.ibm.com               Home: BillSeurer@aol.com
  WWW:  http://members.aol.com/BillSeurer
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]





Author: Clive Bluston <clive@emultek.co.il>
Date: 1996/10/21
Raw View
The Death of C++

Does the fact that C++ is under the control of
a standards committee mean that it is doomed
to extinction ?

Take a look at Java. It has every language construct
every C++ user has ever dreamed of. Most of these
could be added to C++ without a second thought. For
example "finally" and "break <label>". Others could
be added to the standard library. For example a standard
thread library.

The problem is that standards committees are inherently
slow at adopting changes. Arguments like "this can be done by
some form of existing syntax" or "not every platform
supports this facility" are be used to slow down or
prevent change.

While these arguments are raging programmers will be
flocking to Java. C++ will slowly fade out and
disappear.

Clive Bluston, Israel
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]





Author: rsrodger@wam.umd.edu (Robert Rodgers)
Date: 1996/10/21
Raw View
Clive Bluston <clive@emultek.co.il> wrote:
>Take a look at Java. It has every language construct
>every C++ user has ever dreamed of. Most of these
>could be added to C++ without a second thought. For
>example "finally" and "break <label>".

Both of these are very nice features.

>Others could
>be added to the standard library. For example a standard
>thread library.

I just have a small comment, here, coming from a Java perspective.

The main problem with the standard thread library concept is that some
platforms on which C++ must run just don't have threads.  And if they
do have threads, the threads may or may not be preemptively
multitasked.  And if they are multitasked, you need synchronization.

This may sound like a trivial objection, but it's not.  It's the
objection used _right now_ by Java programmers who are avoiding using
threads wherever possible because some Java implementations have
unbelievably wretchedly awful thread performance (like the Macintosh).
Even fully pre-emptive systems without lightweight threads can face
real problems (and the lack of callbacks sortof limits their utility,
e.g., for GUI functions a la NextSTEP).  There's just so much that you
can't guarantee* about how it will affect your runtime performance
that good Java programmers are using the fork() rule: don't do it if
you can avoid it.

It's also a little late to be adding real threads to C++.  One similar
feature which I'd like to see, though, is support for non-pre-emptive
threads of execution (e.g., like Windows NT 4.x fibers).  This can
actually be very handy, can often be used to replace "real" threads,
and could be added without sacrificing efficiency or requiring the
addition of full-fledged thread support (like a sync. library) or
ballooning code.

This is a very nifty feature of NT4 that really can make a performance
difference (positive) compared to programs using "real threads" and it
should be quite easy to implement elsewhere.

>While these arguments are raging programmers will be
>flocking to Java. C++ will slowly fade out and
>disappear.

Is this really a big deal?

If this results in better programs, that's a good thing.  The
investment C++ programmers are making in C++ shouldn't be so that
they're better C++ programmers, but so that they're better programmers
(first), better OO programmers (second) and better C++ programmers
(third).  You don't make a career around a programming language unless
you're a writer.  Java is a very easy migration from C++ (the lack of
templates and opoverloading is annoying as heck, as is the
exceptions-in-header verbiage).

It's good for users, too: Java has GC, something available for C++ but
used by pretty much no-one, and which would pretty much solve at least
two of the major problems that commercial ISVs seem unwilling or
unable to fix: bad pointers and memory leaks.  That'd be a first for
*any* programming language (a.k.a., "magic bullet of the week").

rsr

www.wam.umd.edu/~rsrodger                   b   a   l   a   n   c   e
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The often-heard comment "I'll never use this stuff in the real world"
is only true when measured in percentage time.  It's important! Why?
It gives you options."    - Jim Schuessler [ National Semiconductor ]



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]