What is the future of C++?

[GTO]

I do not believe that C# is the future of C++. I also do not believe that
adding two thousand new library functions to the standard library is the
future of C++. But what is the future of C++? Is it as good as a programming
language can get?

Like so many of you, I programmed speech recognizers, image recognition
systems, a portion of a chess program, lots of numeric code using STL, and
tons of other applications in C++, (even firmware for time critical
applications). Since 1997, I never missed even one feature in the language.
The poor implementation of C++ in various compilers however was certainly
outermost painful.

Anyway, is there a way to improve C++? - I think it's the perfect
programming language for our current computer architectures. I am even
tempted to believe that future "enhancements" can only negatively impact the
beauty of this language. No?

Gregor

 

[Jonathan Turkanis]

I do not believe that C# is the future of C++.

I don't think anyone does. Some people think that C++ is on its last legs, with
languages like C# as the languages of the future, or that C++/CLI is the future
of C++.

I also do not believe
that adding two thousand new library functions to the standard
library is the future of C++.

There will be lots of new library functions in the next version of the standard,
largely from C99. You don't have to use them if you don't want to.

New C++ libraries are mostly centered around new class templates.

But what is the future of C++? Is it as
good as a programming language can get?

Like so many of you, I programmed speech recognizers, image
recognition systems, a portion of a chess program, lots of numeric
code using STL, and tons of other applications in C++, (even firmware
for time critical applications). Since 1997, I never missed even one
feature in the language. The poor implementation of C++ in various
compilers however was certainly outermost painful.

Anyway, is there a way to improve C++? - I think it's the perfect
programming language for our current computer architectures. I am even
tempted to believe that future "enhancements" can only negatively
impact the beauty of this language. No?

It's certainly refreshing to hear this point of view in a message with the
current subject line. I was expecting someone compaining that C++ had fallen
behind the times and was doomed to extinction.

You shouldn't fear that C++ will be made worse, since the standards committee is
very sensitive to backward compatibility. If you don't like new feartures, you
can ignore them for the most part.

However, in addition to lots of additions to the standard library, there are
many exciting possibility for the next version of C++, including move semantics,
a module system and threading.

Gregor

Jonathan

 

[Dietmar Kuehl]

Anyway, is there a way to improve C++? - I think it's the perfect
programming language for our current computer architectures. I am even
tempted to believe that future "enhancements" can only negatively impact the
beauty of this language. No?

You might want to discuss this in comp.std.c++ where many of the C++
committee members hang out: this is the crowd which moves C++ forward
(and it is open, i.e. everybody can participate essentially by joining
a national standardization body).

I don't think that C++ is perfect, although I think it is the best
choice currently available. You said you were using templates but
apparently you weren't implementing them: in the context of templates
the most dire needs I have found arise but there are others not related
to templates, too. From my perspective there is a set of important
areas
which need fixing (and which aren't library issues at all):

- Concurrency needs to be integrated into the language. Much of this
will
be in form of a library but some essential stuff like an overhaul of
the C++ memory model has to be done in the core language.
- Templates and meta programming need fixing. There are various issues
like template typedefs, something like "typeof" (I the current
direction goes under the name of "decl_type"), possibly concept
support,
more structured type capability detection, and a whole bunch of other
stuff.
- Type Information, both at compile time (again for the use in
templates)
and at run time (i.e. something akin to reflection).
- Move semantics allowing non-POD objects to be moved efficiently
between
locations (e.g. when returning an object or when resizing a
'std::vector').

This is just which immediately pops to my head when thinking about
necessary changes to C++. Other may think of other stuff and consider
it
more important (e.g. optional garbage collection rates high for many
people). There is a host of proposals being made (have a look at the
"papers" section at <http://www.open-std.org/jtc1/sc22/wg21/> to get an
overview) and more halfbaked ideas being circulated amoung committee
members. The proposals and ideas range from more or less minor fixes to
rather major changes.

In any case, the C++ committee is well aware that some change is needed
to keep C++ attractive. For example, with multi-processors or
hyperthreaded
CPUs becoming common in the mainstream market (I'd guess that the
average
desktop computer in a decade will have more than just one CPU) support
for
multi-threading is essential. The next revision of the standard is
scheduled
to become available sometime in this decade - and it is more likely
that it
is 2009 than anything earlier...

 

[GTO]

Regarding "move semantics", I thought that C++ already supports some sort of
moving of "expensive" objects (see copy constructor etc.). But to further
optimize C++, it might come handy. Or should we not just leave it up to
optimizing compilers to do this kind of work?

Regarding "threading", do you mean support for multithreading (a la JAVA)?
If yes, I would rather not see this added to C++ since support for
multithreaded concepts are details of the system's architecture and not the
language. But maybe you were referring to something else.

Gregor

 

[GTO]

members. The proposals and ideas range from more or less minor fixes to

rather major changes.

I have read some of the "proposed" additions to C++, but I would like to see
minor fixes rather than major changes. For me JAVA has become a rather bad
example of how to move a language into the future. But you are right, the
standard committee might try everything possible to keep C++ "attractive".
Hyperthreaded CPUs or at least multiple CPUs are certainly in every box
until 2009. But what about FPGA's instead of CPU's? Would it not be easier
to have on-the-fly C++ compiler generate FPGA code rather than always run
everything on general purpose switches? In this case, the improvements would
be more in the compiler architecture rather than in the language.

Gregor

 

[Ioannis Vranos]

I do not believe that C# is the future of C++.

What has C# to do with C++?

I also do not believe that
adding two thousand new library functions to the standard library is the
future of C++. But what is the future of C++? Is it as good as a programming
language can get?

The future of C++ is to be one of the best practical programming
languages out there.

Anyway, is there a way to improve C++? - I think it's the perfect
programming language for our current computer architectures. I am even
tempted to believe that future "enhancements" can only negatively impact the
beauty of this language. No?

C++ will hopefully keep expanding by adopting new mainstream paradigms
and improving the existing supported ones.


Some library extensions will surely take place. For example check the
upcoming TR1:

http://www.open-std.org/jtc1/sc22/wg21/docs/library_technical_report.html

 

[Dietmar Kuehl]

Regarding "move semantics", I thought that C++ already supports some sort of
moving of "expensive" objects (see copy constructor etc.). But to further
optimize C++, it might come handy. Or should we not just leave it up to
optimizing compilers to do this kind of work?

Moving objects is not just a matter of optimization: some objects
cannot
be copied at all (e.g. streams) but it would be desirable to move them,
e.g. when returning them from a function. Also, it is desirable to have
guarantees about certain things rather than hoping all compilers your
system runs on implement a certain non-trivial optimization.

Regarding "threading", do you mean support for multithreading (a la JAVA)?
If yes, I would rather not see this added to C++ since support for
multithreaded concepts are details of the system's architecture and not the
language. But maybe you were referring to something else.

Some portions of multi-threading go beyond a system's architecture and
it is, again, necessary to have certain guarantees. Notably, it is
necessary to have guarantees about ordering read and write operations
relative to access of potentially shared resources, independent of the
underlying multi-threading architecture. For example, the compiler
shall
be prohibited to move read access before the statement acquiring a lock
(you might want to have a look at
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1738.pdf> for
a more thorough coverage; I'd hope for a more detailed discussion but
I'm not aware of any).

 

[Dietmar Kuehl]

I have read some of the "proposed" additions to C++, but I would like to see
minor fixes rather than major changes. For me JAVA has become a rather bad
example of how to move a language into the future. But you are right, the
standard committee might try everything possible to keep C++ "attractive".
Hyperthreaded CPUs or at least multiple CPUs are certainly in every box
until 2009. But what about FPGA's instead of CPU's? Would it not be easier
to have on-the-fly C++ compiler generate FPGA code rather than always run
everything on general purpose switches? In this case, the improvements would
be more in the compiler architecture rather than in the language.

I'm not sufficiently familiar with FPGAs but if these support some form
of multi-threading, some form of multi-threading aware memory model
would
still be necessary (and if they don't, I don't think they can solve the
whole problem) - in addition to improvements to the compiler back-end.

 

[EventHelix.com]

Microsoft has proposed C++/CLI. Among other things, it supports
a built-in garbage collector. It even supports STL as STL.NET.

Deepa

 

[Dietmar Kuehl]

Microsoft has proposed C++/CLI. Among other things, it supports
a built-in garbage collector. It even supports STL as STL.NET.

Nope, Microsoft has not proposed this as approach to C++. Nor
would C++/CLI stand any reasonable chance of becoming the
C++ standard!

C++/CLI is Microsoft's attempt to make something roughly
resembling C++ operational on a system which tries hard to
avoid integration of C++. Sure, you can run C++ on that
system but it doesn't integrate into the "managed" part of
it.

 

[Randy Yates]

/\
Exactly what I was thinking.
IMHO C# = VB with small changes.
Let me brighten the case up this way - I was developing custom fast databases
and tried VB.NET then C# and the code was SO big and slow. Still needed more speed.
So I looked in C++ applications and rewrote one program from VB to VC++.
I was amazed - code was smaller maybe 4times, program faster 10times and customer
happy as hell.) Just my app wasn't so fat in graphics as was C# one.
I totaly left VB\C# practicing and chose C++ - the best language out there.

I can't really speak to the issue since I've not used C#, but it sure SEEMS like
C# is a bad solution in search of a self-imposed problem. I've heard it said C#
is C++ with built-in overflow checking - is that true?

I agree with the general sentiment, though - we don't need another language that
essentially adds little value to C++ - let's stick with what we've got and improve
it and/or the libraries available for it.

 

[Dietmar Kuehl]

I agree with the general sentiment, though - we don't need another language that
essentially adds little value to C++ - let's stick with what we've got and improve
it and/or the libraries available for it.

The key reason I see for an entirely new language (probably created
with C++'s
mindset) is that C++ has acquired that much legacy that it is hard to
create
a C++ processor. As a result, there are few good C++ tools which help
in various
development settings (reverse engineering of code for documentation,
code analysis
for correctness, IDE navigation, code completion, etc.) and those which
exist are
often quite imperfect (e.g. they fail utterly if heavy template stuff
is used).
This lack of tools, including correct and fast compilers, is the major
problem of
C++. I don't think that it can be rectified while retaining the usual
amount of
backward compatibility.

I think that there will be a workable C++0x which is compatible with
the current
C++ in that current C++ is valid C++0x. However, evolution beyond this
step will
need to get rid of many aspects of C++ and loads of C++'s complexities.
I don't
think that we can simplify the language sufficiently without breaking
compatiblity.
However, simplification in various aspects is already necessary.

Some trends are also hard to ignore: newer languages typically run on
some form
of virtual machine. They typically support garbage collection which can
even be
a speed advantage e.g. in multi-threaded environments. ... and, of
course,
multi-threading support will be essentially with multi-processor or
hyper-threading machines becoming mainstream. C++ will have to change
to
accomodate future technology.

 

[Randy Yates]

The key reason I see for an entirely new language (probably created
with C++'s mindset) is that C++ has acquired that much legacy that
it is hard to create a C++ processor. As a result, there are few
good C++ tools which help in various development settings (reverse
engineering of code for documentation, code analysis for
correctness, IDE navigation, code completion, etc.)

xemacs foots two of those bills. Going to another language does not
implicitly guarantee either of the other two.

and those which
exist are often quite imperfect (e.g. they fail utterly if heavy
template stuff is used). This lack of tools, including correct and
fast compilers,

Huh? What's wrong with g++? It's certainly fast enough for me. If
I cranked out a few dozen lines of code per minute I might start
to think that compile time would be a signficant overhead, but
I don't.

is the major problem of C++. I don't think that it
can be rectified while retaining the usual amount of backward
compatibility.

I don't really even see the problem, so I don't see what needs to
be rectified.

I think that there will be a workable C++0x which is compatible with
the current C++ in that current C++ is valid C++0x.

What's "C++0x"?

However, evolution beyond this step will need to get rid of many
aspects of C++ and loads of C++'s complexities.

Why? Which ones?

I don't think that we can simplify the language sufficiently without
breaking compatiblity. However, simplification in various aspects
is already necessary.

Why do we need to simplify the language?

Some trends are also hard to ignore: newer languages typically run
on some form of virtual machine. They typically support garbage
collection which can even be a speed advantage e.g. in
multi-threaded environments. ... and, of course, multi-threading
support will be essentially with multi-processor or hyper-threading
machines becoming mainstream. C++ will have to change to accomodate
future technology. -- <mailto:[email protected]>
<http://www.dietmar-kuehl.de/> <http://www.contendix.com> - Software
Development & Consulting

I'll see you in the marketplace.

 

[Dietmar Kuehl]

xemacs foots two of those bills.

These must be IDE navigation and code completion. Actually, I doubt
that (x)emacs can do a perfect job on those two things and an
imperfect one does not really help: if you rely on code completion
and it does not provide you with appropriate template instantiations
or suppresses them in other contexts, it is somewhat unhelpful at
best. Likewise I doubt that (x) emacs is capable of navigating to
the appropriate [partial] specialization of a template. It surely
provides some help but it does not go all the way.

Going to another language does not implicitly guarantee either of
the other two.

We are in perfect agreement on this. However, a new language gives
the opportunity to add considerations like potential tool support
to the language design guidelines.

Huh? What's wrong with g++? It's certainly fast enough for me.

First of all, g++ is wrong in some cases and it does not support
standard C++. If you disagree, try to use the 'export' keyword.
Considering g++ speed, I think it is reasonable but I would prefer
it to be faster: I tend to run testsuites often and most of my
projects have bigger testsuites which take considerable amounts of
time. Compilation speed of g++ compared to e.g. VC++ is not really
favourable although this shows that C++ can be compiled faster than
what g++ does (but then, with other flows). Essentially, there is
still only one standard conforming C++ implementation: EDG's
front-end and just one compiler (AFAIK) which actually ships it
with the whole feature set (Comeau). However, this compiler is not
exactly fast either. Of course, other compilers (C, Java, C#, etc.)
don't have that much to do (e.g. no templates) but they are much
faster for comparable amounts of code.

If
I cranked out a few dozen lines of code per minute I might start
to think that compile time would be a signficant overhead, but
I don't.

You might think differently if most of your code were in testsuits
which get recompiled with each run.

I don't really even see the problem, so I don't see what needs to
be rectified.

The template mechanism is one of C++'s most powerful features but
it inherently broken: just have a look at all those funny ADL
discussions on comp.lang.c++.moderated or comp.std.c++. Correct
template support is pretty hard to get it right and except for
EDG's front-end nobody has made it (and even EDG's front-end seems
to be imperfect in some corner-cases).

What's "C++0x"?

The working title for the next C++ standard: the committee is
working on the next C++ revision and plans to finish it in this
decade. Most likely, the "x" will eventually be replaced by "9".

Why? Which ones?

Why? Because it is hard to get remember all issues even for C++
experts. Which ones? Well, the core language specification (i.e.
C++ without its standard library) takes roughly 250 pages. I'd
consider this to be more than most people can remember and I
actually doubt that there is anybody who does know all the details
without refering back to this document in all situations. This is
clearly too complex.

But don't get me wrong: I surely want to retain C++'s power. I
just want to get rid of all those special rules you need to
remember. It actually starts with the declaration syntax: it is
not really obvious that

| std::vector<int> vec(std::istream_iterator(in),
| std::isteram_iterator());

declares a function rather than defining an object, is it?

Why do we need to simplify the language?

Because it is too complex for both humans and machines!

I'll see you in the marketplace.

I have no trouble with that: I think I'm quite good at writing
C++ and C++ is clearly my preferred language. However, I also
see C++'s limitations and disadvantages, many of which are not
really necessary - once we accept certain changes.

 

[Ioannis Vranos]

I can't really speak to the issue since I've not used C#, but it sure SEEMS like
C# is a bad solution in search of a self-imposed problem. I've heard it said C#
is C++ with built-in overflow checking - is that true?

I agree with the general sentiment, though - we don't need another language that
essentially adds little value to C++ - let's stick with what we've got and improve
it and/or the libraries available for it.

C#/CLI which is its exact name, is just syntax (as C++/CLI) with few
binding descriptions with CLI (which is a standard of its own).


It doesn't provide anything more. However C# programmers (as well as VB
..NET programmers), think that all CLI (and .NET) is C#. That is, they
think the whole CLI/.NET library is C# (and VB respectively)!


They say for example, "System::String of C#, or System::StringBuilder
are far better than C++'s string", missing the fact that myself also use
System::String and System::StringBuilder in my own applications.


Also with C++/CLI, C++ becomes the systems programming language of .NET
with far more abilities than C#.


To name a few, templates together with generics, deterministic
destruction (stack semantics/delete), etc.


For example in the upcoming revision of CLI (.NET 2.0), in C#/CLI,
C++/CLI, and the rest languages it is not directly supported to pin ref
objects in the managed heap directly.


However in C++ you can cast a ref handle to some other value handle,
then use that handle to pin the object and then with another
reinterpret_cast casting to an unsigned char * and print out its
contents.

 

[Ioannis Vranos]

Some trends are also hard to ignore: newer languages typically run on
some form
of virtual machine. They typically support garbage collection which can
even be
a speed advantage e.g. in multi-threaded environments.

Check C++/CLI.

... and, of
course,
multi-threading support will be essentially with multi-processor or
hyper-threading machines becoming mainstream. C++ will have to change
to
accomodate future technology.

Check OpenMP (supported in VC++ 2005 along with others).

 

[Ioannis Vranos]

Nope, Microsoft has not proposed this as approach to C++. Nor
would C++/CLI stand any reasonable chance of becoming the
C++ standard!

C++/CLI is a standard of C++ extensions that helps programmers to take
*full advantage* of a CLI environment (actually it is the *systems
programming language* of CLI (and .NET).

C++/CLI is Microsoft's attempt to make something roughly
resembling C++ operational on a system which tries hard to
avoid integration of C++. Sure, you can run C++ on that
system but it doesn't integrate into the "managed" part of
it.

You are completely wrong. With C++/CLI you can write fully verifiable
..NET programs with more facilities and possibilities available than C#.

 

[Ufit]

What has C# to do with C++?

/\
Exactly what I was thinking.
IMHO C# = VB with small changes.
Let me brighten the case up this way - I was developing custom fast databases
and tried VB.NET then C# and the code was SO big and slow. Still needed more speed.
So I looked in C++ applications and rewrote one program from VB to VC++.
I was amazed - code was smaller maybe 4times, program faster 10times and customer
happy as hell.) Just my app wasn't so fat in graphics as was C# one.
I totaly left VB\C# practicing and chose C++ - the best language out there.
Greets

Uf

 

[seguso]

I do not believe that C# is the future of C++. I also do not believe that
adding two thousand new library functions to the standard library is the
future of C++. But what is the future of C++? Is it as good as a
programming language can get?

Maybe adding higher-order functions, lambdas and type inference would make
C++ at least a bit more readable and bearable. If you really want to shine,
you could also add transparent backtracking a-la Prolog. Also, adding the
possibility to program in a pure functional style would make it faster (due
to static garbage collection) and less error prone.

Anyway, is there a way to improve C++? - I think it's the perfect
programming language for our current computer architectures.

I suppose you don't know Mercury, Clean, Haskell, OCaml, Prolog. How many
languages do you know?

 

[Walter]

I do not believe that C# is the future of C++. I also do not believe that
adding two thousand new library functions to the standard library is the
future of C++.

I agree.

But what is the future of C++? Is it as good as a programming
language can get?

Not at all. C++ has evolved over decades, with new features evolving to fit
new ideas in how to write programs. Each feature was carefully grafted over
existing features to maintain backwards compatibility. As such, it resembles
a farm house that started out as a cabin, but as each successive family
owned it they added new rooms and repurposed existing ones, resulting in a
lot of odd compromises and weirdities.

Many of us have programmed in C++ for so many years that we no longer even
see what those compromises and weirdities are, we can drive around them in
our sleep. But they're still there, they still make the language hard to
learn, and make programming in C++ unnecessarilly tedious and error-prone.
(One small example is when tag names are sometimes in a separate name space,
and sometimes not. There's no reason for that nonsense other than backwards
compatibility, no sane language designer would design a new language that
way.)

C++ stands to gain a lot from being refactored, a process by which one looks
at what works and what doesn't, and engineers a new language to make what
works work in a straightforward, seemless manner.

Like so many of you, I programmed speech recognizers, image recognition
systems, a portion of a chess program, lots of numeric code using STL, and
tons of other applications in C++, (even firmware for time critical
applications). Since 1997, I never missed even one feature in the language.
The poor implementation of C++ in various compilers however was certainly
outermost painful.

The "poor implementation" is usually a consequence of the complexity,
inconsistencies and weirdities of the language. It's unlikely that C++ has

Anyway, is there a way to improve C++? - I think it's the perfect
programming language for our current computer architectures. I am even
tempted to believe that future "enhancements" can only negatively impact the
beauty of this language. No?

Check out the D programming language for an example of how one can have the
efficiency and power of C++ without the endless complexity.

-Walter
www.digitalmars.com/d/ the D Programming Language
"code of the nerds"