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]

"Earl Purple" <ea********@gma il.comwrote in message
news:11******** **************@ l12g2000cwl.goo glegroups.com.. .

>
Tony wrote:

>OK, so you just want them to be standard. That assumes that the
proprietary
vendors would give up control of those things though. I can't imagine MS
giving up its cash cow by adhering to a standard GUI API.

That's like saying you can't have proprietary databases because they
have to support standard SQL.

Not really, because the multi-billion dollar proprietary cow is pre-existing
and standardizing a GUI API threatens its existence. Other products based
upon the standard API would probably have to be successful in taking away
market share before MS would change Windows.

Tony

[Tony]

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

A C++ course is neither a substitute for an
introduction to computer architecture nor a class on data structures and
algorithms.

The topics need not be taught separately though. It's up to the course
designer to decide what the scope will be. It could be a lot of C++ with
data structure examples sprinkled in (may as well learn something useful
while learning syntax) or it could be a lot of design with a little C++
as the implementation language. The latter being similar to books on
OO that give C++ examples but don't implement production-level code
because they are more concerned with the patterns than the language
idiosyncracies.

Tony

[Tony]

"Chris Thomasson" <cr*****@comcas t.netwrote in message
news:-N************** *************** *@comcast.com.. .

>Student: I hear the C++ Standard has a nice vector template?

Teacher: Well, yes it does. And you will learn exactly how to create a
Standard C++ vector template from scratch. This class will teach you how
to implement useful parts of the C++ Standard. The class uses the
namespace myclass_std for the minimalist Standard C++ template library
you will be creating.

Sound good to me, no?

That might be a good name for a book...
"Implementi ng Standard C++"

"Accelerate d C++" is a book that already works the vector problem above.

Tony

[Walter Bright]

Frederick Gotham wrote:

Walter Bright:

>Frederick Gotham wrote:

>>For instance, let's say I'm driving fast, but there's a bend up ahead.
I want to get through that bend as quickly as possible. Driving an
automatic, I'll break as I approach the bend, then turn, then
accelerate once I'm through the turn. Driving a manual, I'll drop a
gear as I approach the bend, then the car will slow as I re-engage the
engine dragging the revs up, then I'll turn, then when I'm through the
turn, I'll slip the clutch and acclerate. The automatic method is
certainly simpler, but the manual method is far more efficient.

Using the engine to slow down the car is not efficient.

Not efficient in terms of what? Racing performance or car maintenance?

Not efficient in terms of fuel usage, performance, dollars, or maintenance.

It
slows the car down at an appropriate rate without using any energy. The
breaks, on the other hand, use energy.

The brakes don't use energy, they disperse it.

>It puts excessive wear on the engine as unburned fuel in the cylinders
will wash the oil off the cylinder walls, causing more wear. It wastes
fuel.

Actually, I think most cars cut off the petrol supply when they sense that:

(1) The accelerator isn't depressed.
(2) The revs are falling below minimum.

Maybe some do. Most do not. Certainly, carbureted ones do not.

I've never heard of "cluth-engage braking" wearing the engine, no more so
than simply reving the engine.

Now you have <g>.

>Use the brakes. That's what the darned things are for! They're a lot
cheaper to replace than the engine is.

Actually, people who have driven both manual and automatic argue the exact
opposite:
Breaks wear quicker in an automatic, and they're more expensive
to replace than a clutch. My own father drove an automatic for about a
decade, then a manual for about five years, and now he's back in an
automatic. He says that he spent much more money on maintenance for the
automatics, particularly the brakes.

Brake pads are $25 each, and you need 4. You can't touch a clutch job
for that. How you drive can also have a big impact on brake wear and
clutch wear. I usually get twice the life out of a clutch that "normal"
people do.

>Proper maximum performance turning technique is:

1) Brake as late as possible, and as hard as possible (just up to
locking, but not actually locking, the tires), just before turning the
wheel.

If the objective is to slow down _as_ _fast_ _as_ _possible_,

No, the objective is to get around the track as fast as possible.
Braking later and harder means your average speed is higher.

then yes.
This method is a little extreme though if you're driving through a
neighourhood.

Generally, you shouldn't be using maximum performance driving techniques
where kids are playing in the street.

>1.5) While braking, heel-toe double clutch to insert the transmission
into the right gear for the turn exit. Engage the clutch *before*
finishing braking, which also means 'feeling' the engine revs to match
up with the transmission speed so there is no slipping.

If I'm not mistaken, not even competitive drivers double-clutch anymore,
ever since the advent of synchromeshes in the gear box.

A lot of racing trannies do not have synchros, as they are not needed
for competent drivers, and they are more complex and prone to failure.

I belive the "drop
a gear and engage the clutch dragging up the revs" braking method is
superior, as the revs are just at the right rate when you want to
accelerate out of the turn. If you need more stopping power, then you can
always push the brake at the same time.

You can believe whatever you want. But my information comes from:

1) mechanics who work on professional race cars
2) professional race car drivers
3) (1) and (2) who took the time to explain the physics of it to me
4) I have an undergraduate degree in mechanical engineering
5) I have taken cars completely apart and reassembled them, so I am very
familiar with how they work.

Your belief is a common one, but it is simply wrong. For one thing, the
engine does not add to the "stopping power". The stopping power is
limited by the grip of the tires on the pavement. The brakes can
*easily* exceed this. Using the engine in addition to the brakes causes
problems because the engine braking only happens on the rear wheels.
Brake pressures are very carefully 'biased' front to rear, throwing in
engine braking just on the rear will upset that, most likely causing the
back end to slide out from under you.

>3) Keep constant pressure on the gas, adding or releasing pressure will
cause a slide.

Not too sure on this one. I did a race course there a little while ago, and
all I did was brake in a straight line, then release the brake and turn the
wheel. When through the apex of the turn, I hit the accelerator hard. (I
didn't hold on the accelerator going through the turn.)

The problem is called "lift throttle oversteer", and I've done it. You
get a nice spin doing it.

>4) After the apex, gradually straighten the wheel applying pressure to
the gas, again in a coordinated manner to keep constant pressure on the
wheels at just short of skidding.

I take it you don't do drifting :)

Drifting is something entirely different, and it is not about maximum
speed through a turn. Drifting is more of an art form. Drift cars are
deliberately set up to minimize weight on the back tires so they'll
slide easily.

In normal driving, the main advantages of "clutch-engage-drag-up-revs
braking" is that the brakes don't get worn, and that you're at a nice rev-
rate when you're exiting the turn.

In race driving, use of this braking method will help keep the brakes cool,

Brake overheating can be a problem with race cars, but this problem has
been solved by building better heat dispersing brakes.

plus you'll be at a nice rev-rate when leaving the turn.

Um, you put the car in the right gear to get the right rpms on turn
exit. That has nothing to do with using the engine to slow the car down.

That said though, double-clutching is good fun. I used to do it... until I
needed a new clutch.

Double clutching properly actually reduces the wear on the clutch (and
transmission).

I tried heal-toe braking one time but I nearly caused
an "accident".

Few can do it properly, and it takes a lot of practice. You shouldn't
practice it in traffic.

I don't know the exact physics behind it, but I find that intentionally
slipping the clutch upon exiting a turn gives that extra little bit of
acceleration (might be something to do with torque but I don't know).

Probably because your engine doesn't pull well at low revs, and slipping
the clutch gives you more revs. That's hard on the clutch, though, and
you might consider dropping a gear.

[Howard Hinnant]

In article <66************ *************** ***@comcast.com >,
Walter Bright <wa****@digital mars-nospamm.comwrot e:

Frederick Gotham wrote:

Walter Bright:

Frederick Gotham wrote:
For instance, let's say I'm driving fast, but there's a bend up ahead.
I want to get through that bend as quickly as possible. Driving an
automatic, I'll break as I approach the bend, then turn, then
accelerate once I'm through the turn. Driving a manual, I'll drop a
gear as I approach the bend, then the car will slow as I re-engage the
engine dragging the revs up, then I'll turn, then when I'm through the
turn, I'll slip the clutch and acclerate. The automatic method is
certainly simpler, but the manual method is far more efficient.
Using the engine to slow down the car is not efficient.

Not efficient in terms of what? Racing performance or car maintenance?

Not efficient in terms of fuel usage, performance, dollars, or maintenance.

It
slows the car down at an appropriate rate without using any energy. The
breaks, on the other hand, use energy.

The brakes don't use energy, they disperse it.

<snip>

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. Such a statement isn't what I would personally call rational,
but hey, everyone is entitled to their opinion. And it happens daily
here at comp.lang.c++. Over the years I've come to actually enjoy
reading such posts in a somewhat warped and twisted way. I've become
amused at what the next self-appointed moderator will claim as off
topic. Ok it's cheap entertainment, but better than reality TV.

Then I see this "future of C++" thread. Gee, that thread has been going
on forever. What could they possibly be discussing over there?!

Cars.

Not software in cars. Just driving techniques. :-)

This isn't a flame on Walter. Walter is a great guy who I've personally
met (Hi Walter!). I'm just chuckling at the irony, and being off topic
myself. :-)

-Howard

[Alf P. Steinbach]

* Tony:

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

>>Exceptions just solve the problem of how to handle errors in those
functions.

No, that problem is not a problem that can be solved by other known means.

So how do you handle a constructor error without exceptions?

You don't: you transform it to something else.

E.g., you can transform it to a fatal error (aborting the program), or
to a silent failure (ignoring further operations), or to a recurring
nightmare (e.g. popping up an error dialog box for every attempted
operation on the object), or most likely, you'll either transform it to
an initialization failure by using two-phase construction, where the
constructor no longer has a role to play, or, which may arise naturally
with two-phase construction, to a nest of bugs.

No matter which such course is taken the problem persists.

>>Constructor s weren't created as a result of exception handling, EH was
created as a result of constructors.

No, that's incorrect. Exceptions were adopted late in the standardization
process, that's true. But first, they weren't invented to support
constructors , nor vice versa, and second, they weren't invented in C++.
Experience with exceptions had been gained from Ada and other languages,
as well as at a low level in e.g. Windows NT. They fitted the
requirements of constructors, and no other scheme did.

I meant the reason why they were implemented in C++ (context counts).

There were many reasons. In his paper "What is "Object-Oriented
Programming?"", mid 1986, Bjarne Stroustrup wrote

As programs grow, and especially when libraries are used extensively,
standards for handling errors (or more generally: "exceptiona l
circumstances") become important. Ada, Algol68, and Clu each support a
standard way of handling exceptions. Unfortunately, C++ does not.
Where needed exceptions are "faked" using pointers to functions,
"exception objects," "error states", and the C library signal and
longjmp facilities. This is not satisfactory in general and fails even
to provide a standard framework for error handling.

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

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

[Steven T. Hatton]

Frederick Gotham wrote:

Steven T. Hatton:

>What happens when somebody just happens to define something in a library
you include in your code that breaks your macros? It happens.

What happens when someone hits their finger with a hammer? Do we stop
selling hammers?

If someone else hits my thumb with a hammer, that becomes a different story.
If I get hit by the head of a hammer because it fell off the handle, I'm
going to look into why that happened. If it happens repeatedly with the
same make of hammer, I'm going to go looking for a new kind of hammer.

>Among
those changes was to remove certain header files which appeared to be
superfluous, and were not indicated in the documentation as essential to
the feature I was trying to implement.

So why did you have these header files included in the first place?

Because it was part of the sample code, and it is an "include everything"
file the library provider has taken to using in their implementation files.
It may be due to a suggestions in the Template book by van de Voorde and
Josuttis. Something I am now convinced was bad advice. I took it out
because I only want what is necessary to make my code work. That avoids
introducing hidden dependencies such as the one I discovered.

> Among
those elements was a header file which *should* *not* have made a
difference. Nonetheless, it *did* make a difference.

It didn't by any chance have:

#undef MY_SPECIAL_MACR O

The fix was not taking it out. It was putting it in. I really don't know
what it had in it. Ironically, I had opted for not going with the
bleedingest edge stuff for a change - reasoning that such problems would be
less likely. Well, they seem to have corrected it in the development
branch. They now have header files with sane names that work.

>

>What is even more bizarre is that at one point, explicitly adding a
default constructor signature to a pure abstract base class caused the
damn thing to work!

Sounds a little odd, I'd have to look at the code to see what's happening.

I wouldn't try to reproduce the problem if my life depended on it at this
point.

>I believe there is a place for "cookie cutter" code. What Cpp provides
is a means of crossing the boundary between code text, and compiled
code.

And it's very handy, as shown by my IN_TERMS_OF macros.

I like to see code written out in C++. I can understand that. Even if I
don't see everything relevant to the situation, I can usually get a pretty
good idea of what the possibilities are directly from the immediate code.
That simply doesn't work with Cpp.

>It is a form of recursive self-reference, if you will pardon the
redundancy. That is actually a very powerful ability. Unfortunately
it's provided by a very weak tool.

The preprocessor is just fine as far as I'm concerned. I just hope we get
Variable Length Argument List macros also.

You probably also think vi should be used for more than fixing an emacs
build script in a pinch.

You should see some of the works of genius they churn out over on
comp.lang.c. Ever heard of IMAX_BITS?

I've attempted to read the GCC code. Some people might find it wonderful.
I found it painful. I can read Roberto's parser. I even wrote an XML tree
walker over it that dumped the AST to XML tags. I can't imagine there is
something significantly faster.

>

>When I see macros, I consider the time I have spent trying to fix Cpp
related problems, and they never seem to have the potential for saving
that much time.

I think they're great, C++ would be less of a language without them.

I _know_ they make creating versatile and powerful development tools more
difficult. I also know that they cause a lot of problems for me and for
other people. It's often not even the number of problems they create that
incurs the real cost. It's the difficulty in identifying and solving the
problems they create. The make the language significantly harder to learn,
and they make it less pleasant to work with. Much of what is done with
macros can be done with templates, or native code. What I enjoy doing with
C++ is finding the one-liner that is both expressive to the human reader,
and ideal for solving a problem for which someone - perhaps me - has
written several lines of code.

If often take a fair amount of thinking and investigating what the
capabilities of the available constructs are. But I have found that I can
often reduce the size of a program significantly, while at the same time
make it more maintainable and flexible.

--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/

[Tony]

"Alf P. Steinbach" <al***@start.no wrote in message
news:45******** ******@start.no ...

>* Tony:

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

>>>Exceptions just solve the problem of how to handle errors in those
functions.
No, that problem is not a problem that can be solved by other known
means.

So how do you handle a constructor error without exceptions?

You don't: you transform it to something else.

E.g., you can transform it to a fatal error (aborting the program), or to
a silent failure (ignoring further operations), or to a recurring
nightmare (e.g. popping up an error dialog box for every attempted
operation on the object), or most likely, you'll either transform it to an
initialization failure by using two-phase construction, where the
constructor no longer has a role to play, or, which may arise naturally
with two-phase construction, to a nest of bugs.

No matter which such course is taken the problem persists.

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

>

>>>Constructo rs weren't created as a result of exception handling, EH was
created as a result of constructors.
No, that's incorrect. Exceptions were adopted late in the
standardizati on process, that's true. But first, they weren't invented
to support constructors, nor vice versa, and second, they weren't
invented in C++. Experience with exceptions had been gained from Ada and
other languages, as well as at a low level in e.g. Windows NT. They
fitted the requirements of constructors, and no other scheme did.

I meant the reason why they were implemented in C++ (context counts).

There were many reasons. In his paper "What is "Object-Oriented
Programming?"", mid 1986, Bjarne Stroustrup wrote

[...]

Well why they were deemed most necessary then rather than all the
potential benefits.

Tony

[Alf P. Steinbach]

* Tony:

"Alf P. Steinbach" <al***@start.no wrote in message
news:45******** ******@start.no ...

>* Tony:

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

Exception s just solve the problem of how to handle errors in those
functions .
No, that problem is not a problem that can be solved by other known
means.
So how do you handle a constructor error without exceptions?

You don't: you transform it to something else.

E.g., you can transform it to a fatal error (aborting the program), or to
a silent failure (ignoring further operations), or to a recurring
nightmare (e.g. popping up an error dialog box for every attempted
operation on the object), or most likely, you'll either transform it to an
initializati on failure by using two-phase construction, where the
constructor no longer has a role to play, or, which may arise naturally
with two-phase construction, to a nest of bugs.

No matter which such course is taken the problem persists.

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

Try to do your own research.

>>>>Constructor s weren't created as a result of exception handling, EH was
created as a result of constructors.
No, that's incorrect. Exceptions were adopted late in the
standardizat ion process, that's true. But first, they weren't invented
to support constructors, nor vice versa, and second, they weren't
invented in C++. Experience with exceptions had been gained from Ada and
other languages, as well as at a low level in e.g. Windows NT. They
fitted the requirements of constructors, and no other scheme did.
I meant the reason why they were implemented in C++ (context counts).

There were many reasons. In his paper "What is "Object-Oriented
Programming?"" , mid 1986, Bjarne Stroustrup wrote

[...]

Well why they were deemed most necessary then rather than all the
potential benefits.

Try to do your own research. I can suggest the D&E book. But I haven't
read it.
--
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?

[Tony]

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

>* Tony:

>"Alf P. Steinbach" <al***@start.no wrote in message
news:45******* *******@start.n o...

>>* Tony:
"Alf P. Steinbach" <al***@start.no wrote in message
news:4t***** *******@mid.ind ividual.net...

>Exceptio ns just solve the problem of how to handle errors in those
>function s.
No, that problem is not a problem that can be solved by other known
means.
So how do you handle a constructor error without exceptions?
You don't: you transform it to something else.

E.g., you can transform it to a fatal error (aborting the program), or
to a silent failure (ignoring further operations), or to a recurring
nightmare (e.g. popping up an error dialog box for every attempted
operation on the object), or most likely, you'll either transform it to
an initialization failure by using two-phase construction, where the
constructor no longer has a role to play, or, which may arise naturally
with two-phase construction, to a nest of bugs.

No matter which such course is taken the problem persists.

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

Try to do your own research.

The question was rhetorical.

>

>>>>>Constructo rs weren't created as a result of exception handling, EH
>was
>created as a result of constructors.
No, that's incorrect. Exceptions were adopted late in the
standardiza tion process, that's true. But first, they weren't
invented to support constructors, nor vice versa, and second, they
weren't invented in C++. Experience with exceptions had been gained
from Ada and other languages, as well as at a low level in e.g.
Windows NT. They fitted the requirements of constructors, and no
other scheme did.
I meant the reason why they were implemented in C++ (context counts).
There were many reasons. In his paper "What is "Object-Oriented
Programming?" ", mid 1986, Bjarne Stroustrup wrote

[...]

Well why they were deemed most necessary then rather than all the
potential benefits.

Try to do your own research. I can suggest the D&E book. But I haven't
read it.

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

Tony