The Future of C++ ?

[E. Robert Tisdale]

Both Java and .NET have large companies behind them,
using millions and millions for promotion.
Of course they are popular,
"the best thing since sliced bread".

Bjarne can never compete with that. Even though he is right!

Bjarne certainly could compete.
But he has moved on to bigger and better things.

The first big problem with Java and .NET is that
they are not publicly owned standards like C++.
The language definitions can (and do) change without notiece.
This usually isn't a problem because the typical application
written in Java (or the Microsoft equivalent) has a very short life.

A better question is, "What is the future of Java?"
Computer programming languages tend to become more complex
in order to deal with ever more complex applications.
Eventually, Java may be as complex as C++
and the advantages will disappear.

 

[BobR]

Both Java and .NET have large companies behind them, using millions and
millions for promotion.

.....and suppression. Buy the competition, and shut it down!
[ goodbye Tex Murpjy. ;-{ ]

Fortunately, GNU ain't for sale.

 

[Tony]

After learning "high level" C++, teach [students] in a separate course
about the C subset.

Ha! As if that was even a possibility considering the first thing they
encounter is main()!

Tony

 

[Noah Roberts]

If you had asked me 5 years ago about the future of C++, I would have
told you that its future was assured for many years to come. Recently,
I have been starting to wonder.

I have been teaching C++ at a local polytechnical school here in
Vancouver, Canada for approximately 8 years. Six years ago, at the
height (or should I say volume?) of the internet bubble, I had 80+
students per semester in my C++ course. Now I am fortunate to have 15
students per semester. What has changed? I believe that students are
no longer interested in learning C++. They would rather learn .NET
languages or Java (my colleages who teach these courses seem to be very
busy!). I believe it is because these other languages are easier to
learn and/or are perceived to be more relevant today.

Hey, that's great news. Less cheap labor competition makes me a more
expensive commodity. It also makes my life easier when I don't have to
deal with the bozos comming out of college these days. Let them write
horrible crap in C# or Java. I win either way...I can't loose, no way
is C++ going away any time soon, so this can only be good news.

I say make your course tougher. Weed out the idiots for us.

 

[Paul M. Dubuc]

...
The Java designers realized that most applications didn't require
the performance and efficiency offered by C (and C++) and very carefully
calculated the trade-offs for simplicity and convenience.
The success of Java (and C#) have vindicated these trade-offs.
...

I think Java may have become harder to learn than C++
http://tinyurl.com/yaxr9p
So much for simplicity.

 

[Noah Roberts]

I think Java may have become harder to learn than C++
http://tinyurl.com/yaxr9p
So much for simplicity.

That "article" doesn't offer anything but hearsay. It's like an
article quoting Bob Villa saying, "Pine sucks."

 

[gn]

Hi,

First of all I have to excuse my very bad english, but I hope
everything comes clear.
In my opinion C++ has a very safe future. Important points like speed
and the possibility of low-level manipulations were already mentioned,
but not the main advantage of C++.
It is the possibility of generic programming using Templates and
Template-Metaprogramming (As an introduction to this topic I read
"Modern C++ Design" by Andrei Alexandrescu -- a book that no C++
Programmer should miss!). People getting used with it will realize that
these programming techniques are just at the very beginning and will
develop over the next years.
A main problem talking about C++ is that still most of todays C++
programmers have started with C and that they still do not understand
that a C++ program using things like makros or printf is a bad C++
programm. There is of course still a need of low-level C-functions but
they should always be capsuled (I don't know the correct term here in
english) in a generic library. Coming from other languages I just
started learning C++ in 2005. But it's my daily work now since one
year and even for trivial little things I am no longer using other
languages. As an introduction I had a course at our university (Marburg
- Germany) together with about 35 other computer scientists. Here in
Germany Java is a mandatory topic in the first semester of each
computer scientist, but all of them who are planning to become a
programmer will take a facultative C++ course. If you ask one of them
why, everybody would answer that java is a nice thing to play around a
little bit, but real programmers use C++.
I think it will take some years until people are really programming C++
(and not C with classes like most people currently do). There is also
much to do in the compiler development (but that is another topic).
Another point is that I absolutely don't think that C++ is a
complicated or hard to learn language. There are of course some things
that seem to be a bit confusing. In that case read Bjarne's book "The
C++ programming language". You will fastly learn to think like Bjarne
thinks and everything will come clear.

Best regards,
gn

 

[Phlip]

First of all I have to excuse my very bad english, but I hope
everything comes clear.
In my opinion C++ has a very safe future. Important points like speed
and the possibility of low-level manipulations were already mentioned,
but not the main advantage of C++.
It is the possibility of generic programming using Templates and
Template-Metaprogramming (As an introduction to this topic I read
"Modern C++ Design" by Andrei Alexandrescu -- a book that no C++
Programmer should miss!). People getting used with it will realize that
these programming techniques are just at the very beginning and will
develop over the next years.

The part of template-metaprogramming that will never go away is the
incredible optimizations it provides.

However, template-metaprogramming should never be considered a programmer
convenience. A program often must use templates to achieve "duck typing" -
if it waddles like a duck and quacks like a duck, it's a duck.

Other languages provide that in their basic object model, without the need
for a whole new syntax superimposed on top of the existing system. So
template's edge in optimization only represents the compilers for these
languages catching up to C++.

...If you ask one of them
why, everybody would answer that java is a nice thing to play around a
little bit, but real programmers use C++.

And Java is not the "other languages" I have in mind. Java was invented to
take market share from C++ class libraries - such as MFC. So the language's
marketing pitch is it's safer than C++ - you can't run off the end of an
array, for example.

Actually, it's just harder to run off the end of the array. It's also harder
to get work done, because Java takes much away from C++ while adding almost
nothing back.

 

[gn]

gn wrote: ....
The part of template-metaprogramming that will never go away is the
incredible optimizations it provides.

However, template-metaprogramming should never be considered a programmer
convenience. A program often must use templates to achieve "duck typing" -
if it waddles like a duck and quacks like a duck, it's a duck.

Other languages provide that in their basic object model, without the need
for a whole new syntax superimposed on top of the existing system. So
template's edge in optimization only represents the compilers for these
languages catching up to C++.

Yes, you are absolutely right if you say that the template concept
could be realized with a much easier synthax. But that kind of
programming can only be done by a language using a real compiler (the
thing with templates is to be generic without loosing speed --
therefore the costs of being generic are shifted to compile time). So I
would agree that a language providing these powers with an easier
synthax might be the language of the future.
But the other languages discussed here were java and .net languages
which can principly not provide this feature.

And Java is not the "other languages" I have in mind. Java was invented to
take market share from C++ class libraries - such as MFC. So the language's
marketing pitch is it's safer than C++ - you can't run off the end of an
array, for example.

I am just interested -- do you have a special language in mind, that
also maybe a candidate for future standards?
Actually I am not using normal arrays very often. Real C++ is a very
safe language if you have a good design. If I make a mistake I am
realizing it instantly. Things like memory leaks are not possible if
you follow some simple rules. (In had them more often in python than in
C++).

 

[Tony]

Other languages provide that in their basic object model, without the need
for a whole new syntax superimposed on top of the existing system.

Now there's something interesting. Would you please expound a bit on that
and offer up the languages you had in mind?

And Java is not the "other languages" I have in mind. Java was invented to
take market share from C++ class libraries - such as MFC.

And I thought it was invented so that application programs could be
delivered
on demand via a web browser! Silly me.

Tony

 

[Phlip]

Now there's something interesting. Would you please expound a bit on
that and offer up the languages you had in mind?

See my other post - use one method to pass arguments to functions, not two.
Some arguments are classes.

And I thought it was invented so that application programs could be
delivered
on demand via a web browser! Silly me.

That's the only reason it became popular and got notice. The reason everyone
tries to use it for "enterprise" stuff is the "management by magazine"
effect; defeating the specter of C++'s bugs.

And it doesn't seem dominant in the

 

[Phlip]

Yes, you are absolutely right if you say that the template concept
could be realized with a much easier synthax.

I mean an easier syntax can eliminate the need for the entire concept of
generics. If everything is an object, including classes, then you can pass a
class name into a function: foo(MyClass). Then you declare the function as
foo(klass), and to get an object you use MyClass.new(). This provides the
entire Prototype Pattern, built-into the language.

That's a little better than having two different systems to pass arguments
into functions: template<typename aClass> int foo(Object & anObject).

That is redundancy and cruft. Why can't we just write int foo(typename
aClass, Object & anObject)?

But that kind of
programming can only be done by a language using a real compiler (the
thing with templates is to be generic without loosing speed --
therefore the costs of being generic are shifted to compile time). So I
would agree that a language providing these powers with an easier
synthax might be the language of the future.

We allow our compilers to have an easy time of optimizing because we
over-specify everything, so all static types resolve at compile time. Yet
this is nothing but coddling our compiler. A more powerful compiler wouldn't
need it, and 'template' may someday just get in the way, the same as
'register' just gets in the way now.

But the other languages discussed here were java and .net languages
which can principly not provide this feature.

That's because some people want to compare C++ to other languages and the
first thing they think of is Java and its derivatives. Java may be the
competition with respect to business, but it's not the competition with
respect to technology.

I am just interested -- do you have a special language in mind, that
also maybe a candidate for future standards?

Uh, Python, Ruby, and Smalltalk?

(I think Smalltalk is the language of the future, and it always will be!)

Actually I am not using normal arrays very often. Real C++ is a very
safe language if you have a good design. If I make a mistake I am
realizing it instantly. Things like memory leaks are not possible if
you follow some simple rules. (In had them more often in python than in
C++).

Right. But every programmers' boss you will ever meet has bad memories of
losing millions of dollars, and programmers blaming crufty C++ code that's
full of memory-corrupting bugs. That's where the Java marketing machine
starts. (And .NET is nothing but a clone.)

 

[Kai-Uwe Bux]

I mean an easier syntax can eliminate the need for the entire concept of
generics. If everything is an object, including classes, then you can pass
a
class name into a function: foo(MyClass). Then you declare the function
as foo(klass), and to get an object you use MyClass.new(). This provides
the entire Prototype Pattern, built-into the language.

That's a little better than having two different systems to pass arguments
into functions: template<typename aClass> int foo(Object & anObject).

That is redundancy and cruft. Why can't we just write int foo(typename
aClass, Object & anObject)?

I take it that you then have template-classes take a type object as a
parameter during construction?

How would you mimmick partial specialization?


Best

Kai-Uwe Bux

 

[Phlip]

How would you mimmick partial specialization?

The point: You just don't need to.

Partial specialization fixes a symptom, not the root cause...

 

[Kai-Uwe Bux]

The point: You just don't need to.

I don't buy that.

Partial specialization fixes a symptom, not the root cause...

And in addition, it open new venues for programming.

Don't get me wrong. I have oftentimes missed being able to do

void f ( type A ) {
A a;
...
}

and I would welcome an extension of C++ in this direction (although
overloading the dot operator should have priority). However, such an
extension would be by and large unrelated to the C++ template mechanism and
by no means a substitute. There are areas where both methods could compete,
but not every use of templates is of that type.


Best

Kai-Uwe Bux

 

[gn]

I mean an easier syntax can eliminate the need for the entire concept of
generics. If everything is an object, including classes, then you can pass a
class name into a function: foo(MyClass). Then you declare the function as
foo(klass), and to get an object you use MyClass.new(). This provides the
entire Prototype Pattern, built-into the language.

So far -- yes.
But again --- Each type of language may have a easy syntax providing
the ability to be generic, but the point is to be generic without
loosing speed and that is only possible with a compiler language not
with interpreters or just in time compilers. Of course there are
examples where templates are just used to compensate the insufficiency
of C++. First a popular example for that. For vectors a,b,c,d you may
write: a = b + c + d
The main reason why e.g. Fortran is faster on that than C++ (without
templates) is that Fortran is just summing up the vector components and
assigns them to a. In contrast C++ creates an object for c+d and then
adds the components of this temporary object to b leading to a new
temporary object whose components are assigned to a. Using templates it
is possible to get the same behavior for C++ as in Fortran and in fact
to get the same speed (there are publications on that). So this is as I
said an example where templates are used to cure insufficiencies of
C++, but thats not always the case. Also a simple example for that: In
my daily work I am often using a class for n-dimensional grids (with
variable size for each dimension), where I need several different
iterator-classes e.g. for iterating over a specific grid-shell. Of
course there are mathematical rules to calculate the step the iterator
must take from one grid-point to the next one depending on the number
of dimensions and the size of each dimension. But these values (the
step-size) are calculated at compile time giving an advantage in speed
that could not be realized by an interpreter. You can't build in
specializations for such specific tasks into a language.

Uh, Python, Ruby, and Smalltalk?

(I think Smalltalk is the language of the future, and it always will be!)

Smalltalk is something I definitly have to try out (I never had a look
on a smalltalk program until now.).
But Python is something I am really used with (I have heard that they
solved the huge bugs in the garbage collection for version 2.5 -- is
this right?). But I encountered the frontiers of python very early that
forced me to switch to C++ (today I am very happy that I have
switched). I still think it's a nice language to do little tasks if you
have not much time. In fact it doesn't take a week to learn Python -
that's a feature. Of course for me it is now principly unsufficient,
because I am doing scientific programming and there speed matters. My
programs that I ported from Python to C++ are faster by a factor
between 160 and 220. So for me it's just a 2 days calculation what
needs one year in python.

Best regards,
gn

 

[gn]

And in addition, it open new venues for programming.

I'd just like to say it again here. I think we are just at the
beginning to understand what is possible with the template concept.
"Modern C++ Design" broadened my horizon concerning this topic

Best regards,
gn

 

[Earl Purple]

The first big problem with Java and .NET is that
they are not publicly owned standards like C++.
The language definitions can (and do) change without notiece.
This usually isn't a problem because the typical application
written in Java (or the Microsoft equivalent) has a very short life.

Not necessarily.

And most applications written in C++ more than 5 years ago look very
dated. Especially anything written pre-1998.

A better question is, "What is the future of Java?"
Computer programming languages tend to become more complex
in order to deal with ever more complex applications.
Eventually, Java may be as complex as C++
and the advantages will disappear.

No I will tell you a problem I have had that is not a problem in Java.

I have an application that has to link with a 3rd party library, and
this 3rd party produces binaries for C++ in the form of shared object
libraries or DLLs. For Java they produce .jar files.

Now their .jar files work anywhere. The shared objects and DLLs do not,
so they have to build for each platform.

If that's not enough, their build for Solaris requires your own client
code to be compiled with the Sun Solaris compiler. Which is a problem
because it's non-standard - certain amounts of my code failed to
compile due to their disabling of template member functions in STL, a
major problem with std:air's constructors for one thing. I had to
replace a (probably more efficient) vector.insert() with a std::copy
using back_inserter. (vector.insert is far more likely to optimise).

Then of course I need slightly different makefiles when we finally port
this to Linux where I will be using gnu compiler because that's the
standard there.

Even if everyone builds for GNU only (unlikely to happen) it still
means that you might have a problem keeping up with the versions.

 

[Bo Persson]

No I will tell you a problem I have had that is not a problem in
Java.

I have an application that has to link with a 3rd party library, and
this 3rd party produces binaries for C++ in the form of shared
object libraries or DLLs. For Java they produce .jar files.

Now their .jar files work anywhere. The shared objects and DLLs do
not, so they have to build for each platform.

If that's not enough, their build for Solaris requires your own
client code to be compiled with the Sun Solaris compiler. Which is
a problem because it's non-standard - certain amounts of my code
failed to compile due to their disabling of template member
functions in STL, a major problem with std:air's constructors for
one thing. I had to replace a (probably more efficient)
vector.insert() with a std::copy using back_inserter.
(vector.insert is far more likely to optimise).

So you are telling us that Sun's Java works better than Sun's C++?

And that that is a language problem?


Bo Persson

 

[Earl Purple]

So you are telling us that Sun's Java works better than Sun's C++?

And that that is a language problem?

So you're suggesting that Solaris are refusing to change their C++ to
be compliant by default to push more people into Java? Wouldn't put it
past them.

It's the issue that library vendors only need to make one build of a
..jar and it runs anywhere that has a VM.

Anyway, where I work, which is actually a fairly big company that
you've probably heard of, most of the development has switched from C++
to Java over the last few years, particularly servers, and with the
issues I have had I can clearly see why.