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

[Steven T. Hatton]

Frederick Gotham wrote:

Steven T. Hatton:

>"Among the facilities, techniques, and ideas C++ inherited from C was the
C
preprocessor , Cpp. I didn't like Cpp at all, and I still don't like it.
The character and file orientation of the preprocessor is fundamentally
at odds with a programming language designed around the notions of
scopes, types, and interfaces." Bjarne Stroustrup

Did you see the macros I wrote recently in another thread:

POST_IN_TERMS_O F
OP_IN_TERMS_OF
NON_CONST_IN_TE RMS_OF

These macros are very handy, and they cut down on programmer time and
error.

What happens when somebody just happens to define something in a library you
include in your code that breaks your macros? It happens. I recently
spent many hours trying to figure out what was wrong with code I wrote
using macros from a library provider. I started out with a working
prototype based on example code. I modified the design making reasonable
changes which one should expect a programmer to make. 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. When I tried to compile the code, I got errors
telling me the macro wasn't being expanded. I located the macro definitions
in a header file with a name which seemed appropriate and included that in
my code. I could see the bloody macro definition right in front of my
eyes, and it was there in a file which I was pulling into the translation
unit. Nonetheless, the macro would not expand. After many hours of trying
reasonable approaches, I tried the brute force approach of simply copying
everything from the original working prototype I could possibly put in the
modified code. Among those elements was a header file which *should* *not*
have made a difference. Nonetheless, it *did* make a difference.

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!

I just checked a major project I was working with about a year ago because I
was going to use it as an example of what is wrong with macro madness.
Much to my pleasant surprise the macros are GONE! In many (dozens, perhaps
hundreds of) cases they have been replaced with templates.

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

This represents one of the most elegant (if the term can even be applied to
macros) uses of Cpp I've ever seen. I once took the entire thing and
turned it into normal source code with about 25 keystrokes using Emacs
regexp search and replace.

http://www.kdevelop.org/HEAD/doc/api...8h-source.html

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

[Bo Persson]

kwikius wrote:

>
All I can say is that Microsoft moves in mysterious ways their
wonders to perform.

I am intrigued as to why Microsoft released VC8.0 Express for free
though. I don't know why but speculating and first saying that
VC8.0 is a very capable C++ compiler with a lovely optimiser.

1) They want to introduce C++ coders to .Net.

They want to introduce everyone to .Net, so all the the Express compilers
are free.

2) They've given up on C++ and basically chucked VC8.0 like garbage
as their last C++ compiler.

No, they have really learned a lesson from their earlier free editions -
those without an optimizer. That earned them a "Microsoft compilers suck"
verdict.

3) gcc is free so they decided to compete on the same playing field.

Perhaps.
Bo Persson

[Steven T. Hatton]

Frederick Gotham wrote:

Steven T. Hatton:

>The one major flaw in C++ is '#'.

Are you five years old? '#' doesn't mean "preprocess or", never has and
never will. It's nothing more than a symbol which has different names in
different languages and dialects -- I myself call it the hash symbol.

From now on, when I say that there's a problem with '~', you can take it
to mean the mid-Atlantic currents.

Other than the one OOP programming course I took over a decade ago, and one
course in C I took even longer ago, I taught myself C++ starting about two
years ago. I believe I know it fairly well by now. I can say with
confidence and conviction that problems relating to Cpp were by far the
biggest obstacle, followed by problems related to linking. What I am
trying to tell anybody who is interested in what makes C++ hard to learn is
that the "real" language isn't the problem. Cpp is.

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

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

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

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.

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.

2) Turn the wheel while releasing the brake in a coordinated manner so
the turning force takes up where the braking force leaves off.

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

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.

There are some nuances to this to get even better performance once one
gets smooth at it. It takes a fair amount of practice to do it right,
though. Probably less than 0.1% of drivers can do it. That's why race
car drivers get paid the big bucks <g>.

[kwikius]

Walter Bright wrote:

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

Unless of course, its an electric car. In which case the most efficient
way to brake is to use the motor as a dynamo to charge the batteries.
The software for which should obviously be written in C++ . And of
course the best way to save fuel is to drive sensibly, anticipating the
bend ahead well before you reach it. This saves both fuel and brake
wear. Again some suitable C++ software could be used to monitor the
optimum rate of decceleration for economy or even connected the cars
automatic navigation system to a satnav, so I can just sit back and
work on my C++ applications while my electric car automatically takes
me where I need to go.

BTW did you know we missed wombat day this year? :-(

regards
Andy Little

[kwikius]

kwikius wrote:

BTW did you know we missed wombat day this year? :-(

Just so everyone doesnt forget next years wombat day:

http://www.wombania.com/wombats/index.htm

regards
Andy Little

[Frederick Gotham]

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? It
slows the car down at an appropriate rate without using any energy. The
breaks, on the other hand, use energy.

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.

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

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.

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_, then yes.
This method is a little extreme though if you're driving through a
neighourhood.

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

2) Turn the wheel while releasing the brake in a coordinated manner so
the turning force takes up where the braking force leaves off.

Sounds good.

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

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 :)

There are some nuances to this to get even better performance once one
gets smooth at it. It takes a fair amount of practice to do it right,
though. Probably less than 0.1% of drivers can do it. That's why race
car drivers get paid the big bucks <g>.

I don't think race car drivers do heal-toe or double-clutching anymore. As
far as I'm aware, it's best to take advantage of synchromeshes if they're
there.

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,
plus you'll be at a nice rev-rate when leaving the turn.

That said though, double-clutching is good fun. I used to do it... until I
needed a new clutch. I tried heal-toe braking one time but I nearly caused
an "accident".

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

--

Frederick Gotham

[Frederick Gotham]

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?

I recently spent many hours trying to figure out what was wrong with code
I wrote using macros from a library provider. I started out with a
working prototype based on example code. I modified the design making
reasonable changes which one should expect a programmer to make. 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?

When I tried to compile the
code, I got errors telling me the macro wasn't being expanded. I located
the macro definitions in a header file with a name which seemed
appropriate and included that in my code. I could see the bloody macro
definition right in front of my eyes, and it was there in a file which I
was pulling into the translation unit. Nonetheless, the macro would not
expand. After many hours of trying reasonable approaches, I tried the
brute force approach of simply copying everything from the original
working prototype I could possibly put in the modified code. 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

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 just checked a major project I was working with about a year ago
because I was going to use it as an example of what is wrong with macro
madness. Much to my pleasant surprise the macros are GONE! In many
(dozens, perhaps hundreds of) cases they have been replaced with
templates.

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.

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.

This represents one of the most elegant (if the term can even be applied
to macros) uses of Cpp I've ever seen. I once took the entire thing and
turned it into normal source code with about 25 keystrokes using Emacs
regexp search and replace.

http://www.kdevelop.org/HEAD/doc/api...8h-source.html

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

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.

--

Frederick Gotham

[Tony]

"kwikius" <an**@servocomm .freeserve.co.u kwrote in message
news:11******** *************@j 44g2000cwa.goog legroups.com...

>

From: "kwikius" <an**@servocomm .freeserve.co.u k>
Newsgroups: comp.lang.c++
Subject: Re: The Future of C++ ?
Date: Tue, 28 Nov 2006 04:42:40 -0800
Tony wrote:

>"kwikius" <an**@servocomm .freeserve.co.u kwrote in message
news:11******* **************@ l39g2000cwd.goo glegroups.com.. .

>
Tony wrote:
"kwikius" <an**@servocomm .freeserve.co.u kwrote in message
news:11******* *************** @l39g2000cwd.go oglegroups.com. ..

There is no money behind C++ except from companies and maybe many of
their interests lie elsewhere.

Whatever that means.

Its the lack of good libraies that will kill C++ AFAICS.

Example please. What area is missing "good libraries" and what would,
for you, make it a "good" library? (Perhaps FREE?)

"Standard". GUI, graphics, dlls, IPC, concurrency.

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.

All I can say is that Microsoft moves in mysterious ways their wonders
to perform.

I am intrigued as to why Microsoft released VC8.0 Express for free
though.

Because they released it as cripple-ware in hopes that you'd upgrade to the
fully featured version.

Beyond the limited horizons of 'implementation defined' C++ though, I
have a funny feeling that the idea of a virtual machine is the way of
the future. Ultimately this is the power of Java and the Microsoft .Net
languages. and its attractive to me and its a standard with cross
platform and cross language libraries... and and.... ;-)

..Net standard and cross-platform??

Tony

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

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

Tony