The Future of C++ ?

[blangela]

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.

I do believe that C++ is more difficult to learn than many of these
other languages. Despite my best efforts to make them exciting, I see
the eyes of my students start to glaze over when I start explaining
pointers. When I ask them to tokenize an english sentence (using the
strtok() function) and print the token in reverse order (they need to
declare an array of type char * and save the addresses of the tokens in
this array), I experience near panic from many of my students. But
these concepts need to be taught in a responsible C++ course. As was
pointed out to me recently, Microsoft still requires applicants to
demonstrate a very good knowledge of string manipulation using C-style
strings (none of these fancy string class objects!) when recruiting C++
programmers.

The ironic part is there is still a large demand for C++ developers
here in Vancouver. In fact, the company that I believe employs the
most developers here in Vancouver, employs almost entirely C++
programmers. This company, Electronic Arts (if you have not heard of
them, I guarantee that your kids have -- they create video games) is
only one of several gaming companies here in Vancouver that employ
primarily C++ programmers. Other companies like Kodak, MDSA, Nokia,
MDSI, etc. also employ large numbers of C++ programmers. Not
surprisingly, I have talked to several companies here in Vancouver who
are complaining that they are having difficulty finding C++ developers
and are looking at trying to recruit from abroad (eastern Europe
primarily).

I believe that many of these companies will be forced to migrate away
from C++ in the near future, simply because they will not be able to
find C++ programmers in the future. Soon the baby boomer C++
programmers will begin to retire, then the proverbial @@@@ will really
start to hit the fan!

Please tell me I am wrong, and paint me a view of the future which
includes C++.

[Tony]

"gn" <gn******@web.d ewrote in message
news:11******** **************@ k70g2000cwa.goo glegroups.com.. .

>
Kai-Uwe Bux schrieb:

>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.

I hope not. Sigh.

Yes, I believe templates are overused and cause a lot of "bad" programming.
Because, very few people know how to use templates judiciously and
sparingly. I guess that's because the STIL isn't very good at teaching good
template usage. Many view it as a mechanism as common as the 'for loop'.
I wouldn't teach anyone templates until they've programmed a few years.
(Just a tad facetious to make the point in that last sentence).

Tony

[Tony]

"Phlip" <ph******@yahoo .comwrote in message
news:K2******** *********@newss vr14.news.prodi gy.com...

gn wrote:

>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.

Better to keep the syntax as ugly as possible to disuade usage of it as much
as
possible (IMO).

Tony

[gn]

Earl Purple schrieb:

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 ...

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

Well - The problem here is that there is one java against many
different C++ compilers. Normally one should think that if you are
programming C++ conform to the standard (and of course capsulating (I
still don't know the right word here in english) system functions) your
programs should compile at every platform where you have a C++
compiler. In reality thats not the case because many compilers are not
conform with the standard, especially concerning templates.
Additionally people who are using things like visual C++ or Borland C++
Builder are often not aware of using non standard libraries. You are
also right with the different GNU versions where I had some problems
with my template syntax.
But all this is not a problem of C++, but of the compiler developers
(let's see what the next standard brings and how fast they are in
implementing it to all compilers). There are also many other things
that I am missing in current compilers (e.g. return value optimization
for recursive functions). I really think that C++ will become much
faster in the future because there are many such things to optimize
that is to complicated for todays compilers.

In the end everything depends on the specific tasks. For my field of
work (computational chemistry) it's simply no question to use anythingh
else than C++ or Fortran, because those quantum chemical calculations
are still to slow even on huge clusters and even for small molecules. I
also think for bigger projects in the software companies it should be
no problem to have C++ and java programmers working on the same
project. It's no problem if you have a good design.

Best regards,
gn

[gn]

Tony schrieb:

"gn" <gn******@web.d ewrote in message
news:11******** **************@ k70g2000cwa.goo glegroups.com.. .

Kai-Uwe Bux schrieb:

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.

I hope not. Sigh.

Yes, I believe templates are overused and cause a lot of "bad" programming.
Because, very few people know how to use templates judiciously and
sparingly. I guess that's because the STIL isn't very good at teaching good
template usage. Many view it as a mechanism as common as the 'for loop'.
I wouldn't teach anyone templates until they've programmed a few years.
(Just a tad facetious to make the point in that last sentence).

Ok - perhaps I don't have the right to talk about this because I'm
definitly no expert on programming and relativly new to C++. But in my
projects the template part is perhaps 0.5%. I'm only using them for
speed critical parts as libraries for matrix calculations and for those
parts I'm spending much more time than for other parts in planning and
implementing it, to be sure that it really works in an optimal way. So
I really don't think I'm overusing this concept. Of course, if you also
count the usage of the STL then I am overusing it.

Best regards,
gn

[Earl Purple]

Actually the C library we have to link against has no such issues. We
can link against that with any C++ code we like. If they provided a C++
wrapper it would mean we didn't have to write our own but at least we
didn't have the same issues.

One solution would be a standard C++ runtime library (per machine), so
that vendors can write C++ libraries which would simply link against
the standard C++ runtime library installed on the system, the same way
that C code links against the native C runtime library.

On UNIX machines this should include any POSIX extensions (which were
often in the headers like <time.hand are now in <ctime>).

Standard name-mangling (per platform) would also help.

[peter koch]

Kai-Uwe Bux skrev:
[snip]

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

Am I the only one failing to see whats wrong with

template<typena me A>
void f() {
A a;
...
}

What problems does the above function have which your solution solves?

/Peter

[gn]

peter koch schrieb:

Kai-Uwe Bux skrev:
[snip]

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

Am I the only one failing to see whats wrong with

template<typena me A>
void f() {
A a;
...
}

What problems does the above function have which your solution solves?

There is no problem with the above function!
But for constructs like:

template<templa te<class foo1class foo2>
class foo3 : public foo2<inst1>
{...};

and more complicated expressions I'd really like to have a more
readable syntax. In fact I have no good idea how to simplify this in
the best way.

Best regards,
gn

[swelef]

Tony wrote:

Yes, I believe templates are overused and cause a lot of "bad" programming.
Because, very few people know how to use templates judiciously and
sparingly. I guess that's because the STIL isn't very good at teaching good
template usage. Many view it as a mechanism as common as the 'for loop'.
I wouldn't teach anyone templates until they've programmed a few years.
(Just a tad facetious to make the point in that last sentence).

Tony

I believe that developers are using templates too few.

The book I suggest to C++ beginners is Accelerated C++. I didn't
actually read it because by the time I found out about it I didn't need
it anymore. But I had a quick look through it to evaluate whether it's
good for my less experienced [ex]colleagues. And I think that Bob
Langelaan could use it to improve the course too, following the
suggestion of Alf P. Steinbach to start with standard library classes.

One of the more remarkable facts about the book is that template
functions are introduced in chapter 8 while classes are left for the
chapter 9. I think it's not because they are more important than
classes, but rather because they are easier to learn and they can
simplify your code.

In your OOP orientation you fail to see that you often need helper
functions to simplify the code and improve its readability. Otherwise
you end up with the classic spaghetti code. If these functions do not
use the object's data, making them private member functions seems
wrong to me as this exposes the class's implementation details to the
user of the class and introduces unwanted dependencies. (And the Pimpl
idiom is not suitable for all situations.)

Template functions have the additional advantage of avoiding the
copy-paste bugs and reducing the amount of code in general.
Less code means less opportunities to make bugs, doesn't it?
And template classes are even better in this regard, you don't
need to rewrite std::vector for each type you use it with. And
that's just the beginning.

Bluntly put, if you avoid using templates, you avoid one of the best
features of C++. You can work around that to some degree using
inheritance and virtual function overriding, but this introduces
unwanted dependencies, some (usually unimportant) performance
hit and you also lose some advantages of the static typing in the
process.

Regards,
Vladimir Marko

[Bo Persson]

Earl Purple wrote:

Bo Persson wrote:

>>
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.

I suggest that Sun puts a lot more effort into their Java implementation
than into their C++.

At the same time, they seem to have to resort to using an amazing amount of
C++ code in their HotSpot VM.

https://openjdk.dev.java.net/

Wonder why? How do they manage to port that to new machines?
Bo Persson

[APNelson.L]

blangela wrote:

I have been teaching C++ at a local polytechnical school here in
Vancouver, Canada for approximately 8 years.

I think it is important to note that because a C++ course is becoming
smaller in Vancouver, Canada does not mean that the C++ language as a
whole is dying. Who knows, it could be that the University has less
students as a whole. Also, this is an introductory course so people
may be taking other languages to start out and then moving up to C++
later.