What is the future of C++?

[Walter]

Some trends are also hard to ignore: newer languages typically run on
some form
of virtual machine.

What's the practical difference between a new language targetting a portable
VM and a new language that has portable semantics? I can't think of one.
What a VM actually does is put the back end of the compiler on the
customer's remote machine. The "write once, run everywhere" is just as
achievable with a language that has portable semantics and putting the whole
compiler on the customer's machine.

 

[Walter]

That's what is all about - backward compatibility and fast development.

Backward compatibility is an issue for maintaining or extending existing
apps. It isn't an issue when starting a new app. I don't suggest it would be
profitable to convert existing C++ apps to D. There is another area where
backward compatibility is an issue - not so much for being able to compile
the legacy code, but to lower the learning curve for writing new code. D is
close enough to C++ that experienced C++ developers will have little
difficulty transferring their knowledge and expertise.

Fast development is a big issue. I would venture that C++ is not known for
fast development, it is more known for efficient execution of the compiled
program.

Do you think the same 'farm thing' would not have happened to C# ?

It will eventually happen to C#, and any successful language. Languages that
aren't being extended and improved are dead languages.

Programming is an art and dealing with very complex issues is a gift.
IMHO thats why not everyone can be a programmer.

Of course. But anything the language can do to help mitigate the complexity
is good for productivity and reduced bugs. A language, however, has a
problem if it can only be mastered by gifted programmers.

Of course languages like VB/C# are great for other things but today
machines are still not so fast and programmers need some power backup tool.
Those weirdities can be avoided if you program an application properly
and that as I see doesn't happen very often.

We've all learned to deal with the potholes in C++, and many of us are so
used to dealing with them we've even forgotten that they're there! That
doesn't mean they still aren't costing us, however. One D programmer wrote
me, cursing (!) that after programming in D for a while, he couldn't go back
to C++. The potholes were suddenly visible to him.

Anyway C++ should definitely not be abandoned but carefuly improved.

C++ will continue to be supported and improved as long as programmers are
using it. For those looking for alternatives that offer equivalent
efficiency and power, but are much easier to use, there's D.

 

[GTO]

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

languages do you know?

Enough, I suppose. But why does it matter how much languages I know? How
many of them I really master is essential.

C++ is excellent and I think I picked up some good arguments for improving
this language from this thread and some of the URLs provided. Thank you.

I hope things will evolve slowly and I hope the standard is not driven by
what one single company would like to "standardize". I started to use .NET
1.1 and got a glimpse into their next incarnation. I still don't like it.
Interesting enough, when working at Bell Labs, I was just using C since
BLASR, our speaker independent speech recognizer, was written in C. After
several lectures by Andrew Koenig, I embraced C++. (I even remember some
occasions when Bjarne Stroustrup found time to visit us in this class. But
it was quite a while ago, 1995/1996.) So, I consider myself an early
adaptor, someone with a flare for new great inventions. But C# and C++/CLI
just seems not to spark my interest. But again, I have nothing against
Microsoft's new technologies, as long as they do not drive the C++ standard.

Gregor

 

[Phil Staite]

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

IMHO C# shares little more than part of it's name with C++. IMHO C# is
more "proprietary Java" than anything else. Granted, Java shares a fair
amount of syntax with C++.

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?

No, bulking up the standard library for the sake of bulking it up
wouldn't make sense.

Some oddball wild-hair ideas of what could be done/added to C++???

A modular standard. As in a baseline, maybe a full workstation/server
spec, a minimalist embedded spec (stripped down lib)... ???

Add a threading library. (eg. similar to Posix?)

A means of expressing parallelism.

Both of the above will be important as multi-CPU machines become more
common. Heck, even Intel has their HT Pentiums. (typing this on one
running Fedora Core 2 now).

Similarly, maybe formalize a networking library since just about every
widget seems to have an ethernet port on it now...

Forget a new standard, kick compiler vendors in their collective
backsides to catch up and be compliant with today's standard! ;-)

Define an abstract C++ virtual machine, maybe even a byte-code or
"portable C++" spec to compile C++ into bytecode that could run on a
JVM. (ie. beat the Java-ites at their own game by making C++ portable,
not just at the source level.)

Fill-in some nice-to-haves in STL, but don't get crazy...

Maybe introduce "compilable interfaces" or virtual headers. Similar to
how Ada lets you compile a package's interface and implementation
seperately.

Anything to help vendors with tool integration. (editors, compilers,
linkers, debuggers, profilers...)

Don't get carried away though - keep the lean/mean "C and then some"
attitude. Virtual function overhead and exception handling state
machines are about all the extra baggage I want to have carried around...

 

[Ufit]

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.

That's what is all about - backward compatibility and fast development.
Do you think the same 'farm thing' would not have happened to C# ?
Programming is an art and dealing with very complex issues is a gift.
IMHO thats why not everyone can be a programmer.
Of course languages like VB/C# are great for other things but today
machines are still not so fast and programmers need some power backup tool.
Those weirdities can be avoided if you program an application properly
and that as I see doesn't happen very often. Anyway C++ should definitely
not be abandoned but carefuly improved.

Uf

 

[Ioannis Vranos]

IMHO C# shares little more than part of it's name with C++. IMHO C# is
more "proprietary Java" than anything else. Granted, Java shares a fair
amount of syntax with C++.

Actually from a glimpse that I took in some C# code it looks like to me
like Pascal+VB in an OO-only style.

I think Java syntax resembles more to C++ than C#, which I think has not
any resemblance.

 

[Ioannis Vranos]

C++ will continue to be supported and improved as long as programmers are
using it. For those looking for alternatives that offer equivalent
efficiency and power, but are much easier to use, there's D.

At WinFX era, will there be an implementation of D supporting WinFX (CLI)?


Also has D a standard library of its own?


Also the comparison table is not technically correct.


C# has no garbage collection by itself for example. All languages in
..NET (CLI) have the same facilities available (while C++ with C++/CLI
has more, like 100% verifiable binaries while using templates, along
with generics of course).


So what is true for C# should also be true for C++ (and VB .NET, J#
..NET, Delphi .NET etc).


Also from that table I conclude that D itself is more like a framework
(like Java?). So for example how will it work under WinFX where there is
another GC and probably other constructs (the CLI constructs).


Two garbage collectors together?

 

[Walter]

At WinFX era, will there be an implementation of D supporting WinFX (CLI)?

There are people working on a CLI version of D.

Also has D a standard library of its own?
Yes.

Also the comparison table is not technically correct.
C# has no garbage collection by itself for example. All languages in
.NET (CLI) have the same facilities available (while C++ with C++/CLI
has more, like 100% verifiable binaries while using templates, along
with generics of course).

C#'s semantics rely on the existence of garbage collection. Whether it is
supplied by .net or by some other method is immaterial, it needs one.
Standard C++ neither needs one nor offers one (C++/CLI is not Standard C++).

Also from that table I conclude that D itself is more like a framework
(like Java?). So for example how will it work under WinFX where there is
another GC and probably other constructs (the CLI constructs).
Two garbage collectors together?

The garbage collector for D is provided by the runtime library. If that
runtime library is .net, then .net will be providing that service for D
programs. There needn't be two collectors.

 

[Dietmar Kuehl]

Check C++/CLI.

I have done so and posted in the past that I consider it a seriously
broken approach on all accounts, i.e. apart from technical objections
I have raised I also dislike the approach how it is created and the
attitude (at least some) people involved in C++/CLI specification react
to constructive criticism. However, Microsoft is obviously successful
with their marketing strategy and managed to find vocal proponents
outside their organization. Since none I could not verify any of their
claims e.g. about C++/CLI portability (e.g. that it is possible to compile
code with VC++.Net and run it on Mono) but have to support multiple
environments I'm not one of the proponents.

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

E.g. support by Intel's compiler for Linux is more interesting to me...
Anyway, I haven't read through the whole document but it does not seem
to address all issues. Personally, I think that something like the
memory model present in
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1738.pdf> is
necessary to address the future needs. I don't think that OpenMP does
address this issue (this paper are just the slides of a presentation
Andrei gave at the previous committee meeting in Redmond; I'm not aware
of any article which provides more details information but I hope that
someone follows up with a more details in a written document).

 

[Dietmar Kuehl]

What's the practical difference between a new language targetting a
portable VM and a new language that has portable semantics? I can't think
of one.

Note my careful wording of "some form of virtual machine": this is something
which executes something without the need of user interaction for installing
the software. How this is handled, i.e. what kind of abstraction is met by
the executable code is not restricted by that.

What a VM actually does is put the back end of the compiler on the
customer's remote machine. The "write once, run everywhere" is just as
achievable with a language that has portable semantics and putting the
whole compiler on the customer's machine.

Yes. The compiler plus the needed execution environment would then make up
the virtual machine. Actually, it is that way with some popular virtual
machines like the JVM or the CLR, although the language they execute is
not directly what the programmer writes but a transformation thereof.

 

[Dietmar Kuehl]

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 a blunt attempt to lure developers into an environment which
is non-portable. In particular, writing C++ code which interacts smoothly
with managed code (which is, after all the stated goal of the abominations
added to C++), like function templates, effectively forces you to write
code which makes heavy use of the C++/CLI extensions (notably, you need to
use the notation for managed references and pointers in function
declarations). Fair enough, C++/CLI is the best language for the CLI but
it is not C++ and it is at best hard to write code which possibly
interacts with managed features while also being usable on non-C++/CLI
platforms (and, IMO, the people involved in the C++/CLI specification made
it deliberately that way).

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

Obviously, we disagree strongly in our assessments of C++/CLI, as I don't
think I'm wrong (and, BTW, don't claim I'm essentially ignorant of C++/CLI:
I read the specification and tested quite a few things with their beta
version).

 

[Ioannis Vranos]

I have done so and posted in the past that I consider it a seriously
broken approach on all accounts, i.e. apart from technical objections
I have raised I also dislike the approach how it is created and the
attitude (at least some) people involved in C++/CLI specification react
to constructive criticism. However, Microsoft is obviously successful
with their marketing strategy and managed to find vocal proponents
outside their organization. Since none I could not verify any of their
claims e.g. about C++/CLI portability (e.g. that it is possible to compile
code with VC++.Net and run it on Mono)

I have done it myself with VC++ 2005 Express Beta 1 and Mono 1

(but C++/CLI is really for the upcoming CLI revision so I had to place a
..NET dll together with the exe, in order to run it under Mono in GNU/Linux).


However strictly speaking, binary portability can really be ensured only
for Console applications using the CLI defined facilities (that is few
facilities like System::String, System::Console, etc).

This applies both for C++/CLI and C#/CLI.


However Mono (and I guess DotGNU too) provides the same APIs (dlls) for
other things too, Windows Forms, GDI+, ADO .NET etc so a pure managed
(C++, C#, VB) binary using these APIs in .NET, can also run unchanged
under Mono in any OS.


Mono also provides other APIs of its own, like GTK#.

 

[Ioannis Vranos]

C++/CLI is a blunt attempt to lure developers into an environment which
is non-portable.

If you want to. For example I use std::string in my programs and will
not change that unless I want to achieve binary portability, and that if
there is not a C++ compiler in a target CLI environment.


It is up to you if you want to use managed facilities or unmanaged
facilities or both. C++ is the only language that is in fact two worlds
in one. The unmanaged and the managed.

So you can continue sticking with source code portability only.

In particular, writing C++ code which interacts smoothly
with managed code (which is, after all the stated goal of the abominations
added to C++), like function templates, effectively forces you to write
code which makes heavy use of the C++/CLI extensions (notably, you need to
use the notation for managed references and pointers in function
declarations). Fair enough, C++/CLI is the best language for the CLI but
it is not C++ and it is at best hard to write code which possibly
interacts with managed features while also being usable on non-C++/CLI
platforms (and, IMO, the people involved in the C++/CLI specification made
it deliberately that way).

Well, you can consider CLI as a portable VM system extension (that is
another pillar of portable source/binary VM code vs system dependent VM
code).


That is, think of it as another option.


You can continue writing ISO C++ code, and aim at source code
portability only.


ISO C++ compiles and works under a CLI VM, where a C++ compiler is
available.

Obviously, we disagree strongly in our assessments of C++/CLI, as I don't
think I'm wrong (and, BTW, don't claim I'm essentially ignorant of C++/CLI:
I read the specification and tested quite a few things with their beta
version).

To produce completely verified managed binaries (and binary portable to
other CLI environments when you use only the CLI specified facilities,
or the target CLI VM provides the additional APIs that you are using),
you have to use /clr:safe.

 

[EventHelix.com]

CLI itself is a standard. Mono and other CLI implementations
are already available for Linux and other platforms.

It is quite possible the CLI and C++/CLI might become
a cross platform architecture, quite independent of Microsoft.

Deepa

 

[Julie]

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

(All) Programming languages are /solutions looking for problems/.

It's not how 'good' the language is, but if there is any system support for it.

So, your question, as posed, has no answer, and should be rephrased:

"What is the future of C++ support on platform X"?

 

[Alexander Terekhov]

Dietmar Kuehl wrote:
[...]

<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1738.pdf> is
necessary to address the future needs. I don't think that OpenMP does
address this issue (this paper are just the slides of a presentation
Andrei gave at the previous committee meeting in Redmond; I'm not aware
of any article which provides more details information but I hope that
someone follows up with a more details in a written document).

http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
http://groups.google.de/[email protected]
http://groups.google.de/[email protected]

regards,
alexander.