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

[Alf P. Steinbach]

* Tony:

>
The question was rhetorical.

That wasn't a question (note the absence of any question mark).

Conceptual PLONK.

That means, I'll not be responding to your articles except perhaps to
resque others from misunderstandin gs.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Noah Roberts]

Howard Hinnant wrote:

Ok, I have to put this into perspective.

I just got through reading a post here complaining that discussing
hash_map was off topic for comp.lang.c++ because it isn't in the
standard.

I think if you go back and reread what was said you'll find that nobody
said what you are saying was said.

[Chris Thomasson]

"Kai-Uwe Bux" <jk********@gmx .netwrote in message
news:ek******** **@murdoch.acc. Virginia.EDU...

Chris Thomasson wrote:

>"Earl Purple" <ea********@gma il.comwrote in message

[snip]

>>Course in Java: [...]

>>And we can process concurrently...
C++ is very useful because

I can use it with Assembly Language to create a high-end synchronization
algorithms. I can use to create a full blown Java VM... I can use C++ to
prototype virtually anything for that matter. Can't use Java for any of
that.

I would like to see the C++ course completion of which will enable you to
create a full blown Java VM. Do you seriously suggest that, say, as a term
paper?

I think I could put together a couple of courses that would teach a student
how to make use of lock-free data-structures' in the context of a virtual
machine. The course would have a prerequisite for basic SPARC or IA-32
Assembly Language skills and fairly advanced knowledge in data-structures
and C or C++; I suggest a course that teaches how to implement the Standard
C++ template library. The virtual machine would of course have a weak cache
coherency, and a very clear memory model... I could go on and on, but it off
topic.

;^)

[Tony]

"Alf P. Steinbach" <al***@start.no wrote in message
news:4t******** *****@mid.indiv idual.net...

>* Tony:

>>
The question was rhetorical.

That wasn't a question (note the absence of any question mark).

Conceptual PLONK.

That means, I'll not be responding to your articles

Thanks.

Tony

[Earl Purple]

Alf P. Steinbach wrote:

I pulled that quote from <url:
http://www.research.at t.com/~bs/hopl2.pdf>, where he further writes that
"Exceptions were considered in the original design of C++, but were
postponed because there wasn't time to do a thorough job of exploring
the design and implementation issues. Exceptions were considered
essential for error handling in programs composed out of separately
designed libraries. The actual design of the C++ exception mechanism
stretched from 1984 to 1989."

Now go do your own research... ;-)

I agree we need exceptions in the language and they are a useful
feature. But do we really need exceptions to be type-oriented ?
Couldn't we all manage with just one exception class?

We do try..catch somewhere and where we catch we can examine the
exception if appropriate and take the right action, possibly rethrowing
it or throwing a new one.

Most of the time I have seen developers who write their own exception
classes tend to put in a numeric value as well as text. I sometimes
embed the numeric value into the string with a tab separator to have
that effect, but I find on the whole I am throwing only standard
exceptions and that runtime_error actually suffices.

If the one exception class used a code as well as text, some of the
error codes could be standard.

Now, I ask, what would be the difference in overhead to having one
exception class and typed exceptions with regards to the compiler and
the code generated etc. Would the systems that currently reject C++
exceptions start using the one class?

For the sake of portable code, we could employ the current syntax and
have this one exception class derive from std::runtime_er ror.

Compilers on the smaller system would probably give an error if the
detected any type being thrown other than the one exception class.

[Earl Purple]

Tony wrote:

>
What percentage of exceptions get handled anyway (that is, in a way other than abort)?

I don't know about percentages but in applications I write, many are
handled by logging the error. The task in hand is usually aborted but
the task isn't necessarily the whole program. You can't shutdown a
server every time a task fails.

A typical example might be a broken link to a remote server. If the
remote server is down, you log the exception and then subsequently you
might be able to reconnect. Perhaps not every action you do uses that
server anyway.

[Noah Roberts]

Earl Purple wrote:

Alf P. Steinbach wrote:

I pulled that quote from <url:
http://www.research.at t.com/~bs/hopl2.pdf>, where he further writes that
"Exceptions were considered in the original design of C++, but were
postponed because there wasn't time to do a thorough job of exploring
the design and implementation issues. Exceptions were considered
essential for error handling in programs composed out of separately
designed libraries. The actual design of the C++ exception mechanism
stretched from 1984 to 1989."

Now go do your own research... ;-)

I agree we need exceptions in the language and they are a useful
feature. But do we really need exceptions to be type-oriented ?
Couldn't we all manage with just one exception class?

We do try..catch somewhere and where we catch we can examine the
exception if appropriate and take the right action, possibly rethrowing
it or throwing a new one.

I suspect that allowing the compiler to create a table based on type
and jumping to the correct handler instead of comparing to a string to
find out what error condition you are dealing with is faster. I have
no real numbers to back up that claim though...only an assumption based
on the O().

>
Most of the time I have seen developers who write their own exception
classes tend to put in a numeric value as well as text. I sometimes
embed the numeric value into the string with a tab separator to have
that effect, but I find on the whole I am throwing only standard
exceptions and that runtime_error actually suffices.

Certainly deriving from a standard exception is appropriate and usually
allows you to create your own with a minimum of extra code and no
changes to the interface.

>
If the one exception class used a code as well as text, some of the
error codes could be standard.

I still suspect that the static typing jump is faster than a runtime
comparison of exception codes.

>
Now, I ask, what would be the difference in overhead to having one
exception class and typed exceptions with regards to the compiler and
the code generated etc. Would the systems that currently reject C++
exceptions start using the one class?

You might get a little space savings in your executable at the cost of
some speed overhead created by checking error codes. I don't expect a
really great difference either way though. Might be worth testing...

[Ramon F Herrera]

blangela wrote:

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

Here we have some opinions from the horse's mouth.

http://www.technologyreview.com/InfoTech/17831/

-Ramon

[Earl Purple]

Noah Roberts wrote:

Earl Purple wrote:

We do try..catch somewhere and where we catch we can examine the
exception if appropriate and take the right action, possibly rethrowing
it or throwing a new one.

I suspect that allowing the compiler to create a table based on type
and jumping to the correct handler instead of comparing to a string to
find out what error condition you are dealing with is faster. I have
no real numbers to back up that claim though...only an assumption based
on the O().

It may or may not be faster. If the standard exception has an
enumerated code as well as text though, you can do a switch on the code
or on bits set in the code, which is a lot faster than parsing strings.

Much of the time, you don't care what exception happened though. You
want to log the text as a task failure and continue. You might already
know what to do by when it was thrown rather than what was thrown.

In addition, it is important to note that exception throwing should be
rare and it is unlikely that you are going to performance test based on
it, especially if the extra action is a minor one such as parsing a
string or checking the bits of an integer.

If the one exception class used a code as well as text, some of the
error codes could be standard.

I still suspect that the static typing jump is faster than a runtime
comparison of exception codes.

I doubt it is, and even if so, it is probably not enough to justify the
overhead.

Now, I ask, what would be the difference in overhead to having one
exception class and typed exceptions with regards to the compiler and
the code generated etc. Would the systems that currently reject C++
exceptions start using the one class?

You might get a little space savings in your executable at the cost of
some speed overhead created by checking error codes. I don't expect a
really great difference either way though. Might be worth testing...

Just a little space savings? We are talking about a whole community
here that does not use exceptions at all because of the enormous
overhead. I am just wondering how much of this overhead is
type-checking based. Remember that the types are checked at the time
the exceptions are thrown and caught, not at compile time.

Having just the one exception still gives you the advantage over having
none at all, i.e. it will jump out of the block at the point the error
occurs, thus you can be sure that, at a point in a block of code, that
no error has occurred up to this point. It will mean there is no need
to create objects in a "zombie" state because you couldn't throw from
its constructor.

[Chris Thomasson]

"Mirek Fidler" <cx*@ntllib.org wrote in message
news:11******** **************@ j44g2000cwa.goo glegroups.com.. .

>
Chris Thomasson wrote:

>Well, you can't use it as a 100% drop in replacement right now because
the
interface is a little different. However, it does provides two smart
pointers:

Well, before going into details....

Have you found a way how to implement lock-free reference counting
usable e.g. for COW string? (with "weak" guarantee for string itself)?

If yes, what is the idea, if you are willing to share?

http://groups.google.com/group/comp....8aa9fe4d0d823e

In order for this to work I have to add CAS to the library... Humm, Well,
here is the source code for the CAS functions:
(mingw-gas)
--------------
..align 16
# int refcount_ia32_c as(
# refcount_ia32_t * volatile*,
# refcount_ia32_t *,
# refcount_ia32_t *)
..globl _refcount_ia32_ cas
_refcount_ia32_ cas:
MOVL 4(%ESP), %ECX
TESTL %ECX, %ECX
JE refcount_ia32_c as_failed
MOVL 8(%ESP), %EAX
MOVL 12(%ESP), %EDX
LOCK CMPXCHGL %EDX, (%ECX)
CMPL %EAX, 8(%ESP)
JNE refcount_ia32_c as_failed
MOVL $1, %EAX
RETL

refcount_ia32_c as_failed:
XORl %EAX, %EAX
RETL


..align 16
# int refcount_ia32_a dd_cas_weak(
# refcount_ia32_t * volatile*,
# refcount_ia32_t *,
# refcount_ia32_t *,
# int)
..globl _refcount_ia32_ add_cas_weak
_refcount_ia32_ add_cas_weak:
MOVL 4(%ESP), %ECX
TESTL %ECX, %ECX
JE refcount_ia32_c as_failed

MOVL 12(%ESP), %EDX
TESTL %EDX, %EDX
JE refcount_ia32_a dd_cas_weak_exe cute
MOVL 16(%ESP), %EAX
CMPL $0, %EAX
JLE refcount_ia32_a dd_cas_weak_exe cute
LOCK XADDL %EAX, (%EDX)

refcount_ia32_a dd_cas_weak_exe cute:
MOVL 8(%ESP), %EAX
LOCK CMPXCHG %EDX, (%ECX)
CMPL %EAX, 8(%ESP)
JNE refcount_ia32_a dd_cas_weak_dec
MOVL $1, %EAX
RETL

refcount_ia32_a dd_cas_weak_dec :
TESTL %EDX, %EDX
JE refcount_ia32_a dd_cas_weak_fai led

CMPL $0, 16(%ESP)
JLE refcount_ia32_a dd_cas_weak_fai led
LOCK DECL (%EDX)

refcount_ia32_a dd_cas_weak_fai led:
XORL %EAX, %EAX
RETL
If you want to use CAS with my refcount library now, just stick the posted
source code in the refcount-ia32-mingw.asm file and assemble... Then create
the declarations in the refcount-ia32.h file, and add the proper member
functions to the refcount-sys.hpp and refcount.hpp files... Simple...

;^)
I am going to add the CAS to my library very soon, I will definitely keep
you posted. Okay?
:^)