The Future of C++ ?

[Tony]

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]

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]

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]

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.h> and 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<typename A>
void f() {
A a;
...
}

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

/Peter

 

[gn]

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<typename 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<template<class foo1> class 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]

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]

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]

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.

 

[Greg]

blangela:



I think that a prerequisite to being a decent programmer is to have above
average intelligence. A minority of people have above average intelligence,
and so a minorty of people aspire to be an actual bonafide programmer
programming in languages such as C and C++.

There is no question that programming in C++ requires above average
intelligence. What is very much open to question, however, is whether
that intelligence is needed for programming per se, or whether the
additional intelligence is needed solely to master the complexities of
C++ itself. In other words, is programming difficult, or is it just
that C++ makes it so? The fact that individuals are able to program
productively in other languages that lack C++'s complexity does lend
support to the latter point of view.

Moreover, isn't it possible that the complexity is self-perpetuating -
that it is in no one's interest for C++ to be any less complicated than
it is? Doesn't the complexity of C++ really work to the economic
benefit of professional C++ programmers? After all, the degree of
intelligence needed to become a C++ programmer presents a significant
barrier to entry into the profession. Therefore one could argue that
the supply of C++ programmers is being constrained to such a degree
that the number of C++ programmers cannot meet the demand. Such a
shortfall in the marketplace, the thinking goes, allows C++ programmers
to command higher salaries than their work is worth economically - and
they can thank C++'s complexity for the entire difference.

It may be instructive to draw some parallels between programming
languages and car transmissions. Programming in C++ is a lot like
driving a car with a manual transmission - both require "above average"
skill than the alternative available technology requires: be it
programming in a managed language or driving a car with an automatic
transmission.

Both automatic transmissions and managed languages are viewed as
alternatives that came along only after the original technology had
been developed. The first generation of cars had only manual
transmissions - meaning that only those skilled enough to shift gears
by hand were able to drive a car. Now the question asked about C++
above can also be asked here: was it the case that driving required
such skills or was it simply that the manual transmission made driving
more difficult than it otherwise had to be?

Similarly, was the development of the automatic transmission a good or
bad development? One could criticize the automatic transmission because
it put a great number of "less skilled" drivers on the road -
individuals who would otherwise not be driving. Certainly, the
higher-skilled drivers would likely see it that way. But for those
driving around in cars with automatic transmissions, the development of
the automatic transmission would have to be seens as an unalloyed good.
The automatic transmission gave these individuals the freedom to drive
themselves and to do so at less cost than hiring a driver.

The tradeoffs involved in both technologies also have similarities.
Like a program written in a managed language versus one written in C++,
a car with an automatic transmissions tends to be less efficient and
not go as fast as one with a manual transmission. But even though an
automatic transmission simplifies driving, the automatic transimission
itself is much more complicated than the manual transmission.
Similarly, the greater simplicity of programming in a managed language
derives from the greater complexity of the underlying "virtual machine"
or "runtime" that enables the simplification. The fundamental
difference here - whether it be programming languages or car
transmissions - is how best to apply advances in technology (or how
best to apply increases in processor speed).

With C++ the philosophy is simple: every increase in a computer's
processing power goes directly toward making the C++ program run
faster. If C++ built cars, every technological advance would go
directly into the car. Managed languages for their part take a more
nuanced approach and invest some portion the increased processing power
not just to run the program faster but to make programming in that
language easier as well. An automatic transmission is an example of
technological advancements applied to the benefit the driver (even to
the detriment of the car), C++ is an example of the opposite:
advancements benefit only the C++ program directly, and the C++
programmer benefits only indirectly (by having a faster, more efficient
- but no less dangerous or any easier to drive - car than they had
before.

Neither approach is necessarily "wrong" and in fact both make sense in
their own way. A C++ programmer does not need a simpler language in
order to program, just as someone who can drive a manual transmission
does not need an automatic transmission in order to drive. So both the
C++ programmer and the skilled driver are likely to prefer to have a
faster program (or a faster car). Whereas everyone else - those who
lack the skills to program in C++ or to drive with a stick shift -
would prefer that technological advances be used to produce a
programming language they could program in - or car they could actually
drive.

Greg

 

[kwikius]

Moreover, isn't it possible that the complexity is self-perpetuating -
that it is in no one's interest for C++ to be any less complicated than
it is?

I'm sure you don't mean nobodies interest. It is certainly in the
interest of newcomers trying to get to grips with the language. Its
stated somewhere in the C++ committee manifesto that we encourage
libraies designed to make programming easier or something For example
Concepts should in theory provide useful error messages and help
debugging. Of course OTOH when you read the Concepts proposals:

http://www.generic-programming.org/languages/conceptcpp/

you can also argue that in fact this is just yet another layer of
complexity, and so the only way to make the language simpler is to
write another language, extracting the 'useful' parts of C++.. hence
Java and C#.

At the language level, there is only one way for C++ to go and that is
to become even more complicated as you can't remove features of course.
Eventually it will become so complicated that no one will be able to
write a compiler for it.

A big problem is the libraries. There are often questions on
comp.lang.c++ regarding Graphics and a GUI on the one hand and also
vehement responses on the other that C++ doesnt need a standard GUI or
graphics libraries There seems to be powerful interests at work. It is
surely in some peoples interests that C++ does become ever more
complicated with out any actual usability features (e.g libraries for
common tasks) and more and more newcomers will simply stick with Java
and C# and so on, where they can get the libraies off the nearest
shelf.

Every programming language has a prime life time and every programming
language is eventaully superceded. C++ is no exception to the rule. C++
did it to C after all.

There is no money behind C++ except from companies and maybe many of
their interests lie elsewhere. Its the lack of good libraies that will
kill C++ AFAICS.

And BTW. I am putting my time where my mouth is and currently working
on a C++ GUI library to fill the gap. I'm not making any code public as
babykilling is too simple of a pastime.

regards
Andy Little

 

[Frederick Gotham]

Greg:

Such a shortfall in the marketplace, the thinking goes, allows C++
programmers to command higher salaries than their work is worth
economically - and they can thank C++'s complexity for the entire
difference.

But that's how all professions work! If just anyone could design space
shuttles, then NASA would pay peanuts.

It may be instructive to draw some parallels between programming
languages and car transmissions. Programming in C++ is a lot like
driving a car with a manual transmission - both require "above average"
skill than the alternative available technology requires: be it
programming in a managed language or driving a car with an automatic
transmission.

I live in Ireland and 99% of cars here are manual transmission. There's a
learning curve to it, sure, but even the most stupid person can learn to
drive manual transmission (and yes I've seen some utterly dumb people drive
a manual transmission car just fine).

Both automatic transmissions and managed languages are viewed as
alternatives that came along only after the original technology had
been developed. The first generation of cars had only manual
transmissions - meaning that only those skilled enough to shift gears
by hand were able to drive a car. Now the question asked about C++
above can also be asked here: was it the case that driving required
such skills or was it simply that the manual transmission made driving
more difficult than it otherwise had to be?

One more thing: You have to consider how comfortable people are with manual
transmission. I've often thought that the most difficult things I've ever
had to learn are walking and talking. There must have been a _massive_
learning curve. Now though, they're second nature to me.

I've been driving manual transmission for about three years now, and it's
second nature to me now. Of course, there was a learning curve at first,
but I got the hang of it.

In my part of the world, people are perfectly happy with manual
transmission. In fact, most people don't like automatic transmission over
here -- if you've driven manual for a while, then you feel as though you've
been deprived of power and control which you once had. Of course though,
there's the ease and simplicity of driving automatic, but, for me, it
doesn't make up for the loss of control.

I myself hate automatic -- give me manual any day of the week.

Similarly, was the development of the automatic transmission a good or
bad development? One could criticize the automatic transmission because
it put a great number of "less skilled" drivers on the road -
individuals who would otherwise not be driving. Certainly, the
higher-skilled drivers would likely see it that way. But for those
driving around in cars with automatic transmissions, the development of
the automatic transmission would have to be seens as an unalloyed good.
The automatic transmission gave these individuals the freedom to drive
themselves and to do so at less cost than hiring a driver.

Ah yes, but if all they know is automatic transmission, then they haven't
experienced the brilliance of driving manual transmission.

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.

The tradeoffs involved in both technologies also have similarities.
Like a program written in a managed language versus one written in C++,
a car with an automatic transmissions tends to be less efficient and
not go as fast as one with a manual transmission.

Hear Hear!

But even though an automatic transmission simplifies driving, the
automatic transimission itself is much more complicated than the manual
transmission. Similarly, the greater simplicity of programming in a
managed language derives from the greater complexity of the underlying
"virtual machine" or "runtime" that enables the simplification. The
fundamental difference here - whether it be programming languages or car
transmissions - is how best to apply advances in technology (or how best
to apply increases in processor speed).

With C++ the philosophy is simple: every increase in a computer's
processing power goes directly toward making the C++ program run
faster. If C++ built cars, every technological advance would go
directly into the car. Managed languages for their part take a more
nuanced approach and invest some portion the increased processing power
not just to run the program faster but to make programming in that
language easier as well. An automatic transmission is an example of
technological advancements applied to the benefit the driver (even to
the detriment of the car), C++ is an example of the opposite:
advancements benefit only the C++ program directly, and the C++
programmer benefits only indirectly (by having a faster, more efficient
- but no less dangerous or any easier to drive - car than they had
before.

Neither approach is necessarily "wrong" and in fact both make sense in
their own way. A C++ programmer does not need a simpler language in
order to program, just as someone who can drive a manual transmission
does not need an automatic transmission in order to drive. So both the
C++ programmer and the skilled driver are likely to prefer to have a
faster program (or a faster car). Whereas everyone else - those who
lack the skills to program in C++ or to drive with a stick shift -
would prefer that technological advances be used to produce a
programming language they could program in - or car they could actually
drive.

If I couldn't drive, and if I was given the choice of an automatic or a
manual, then I'd stop a think: "Hmm, I could get driving the automatic
straight-away, but then I wouldn't experience the brilliance of manual".
Being an elitist, I go for the superior method from Day 1.

Maybe we can categorise people as follows:

(1) They go for manual transmission from Day 1.
(2) They start off with automatic transmission, then move on to manual
transmission.
(3) They start off with automatic transmission and stay with it their whole
life.

I'm firmly placed in Category 1. Give me C++.

 

[Bo Persson]

Greg:



Hear Hear!

If we leave the cars behind, and instead compare programmers to other
skilled craftsmen, tools like a nailgun or a chainsaw are very productive in
the hands of someone who can handle them. The fact that a newbie doesn't
immediately see how to use them properly, isn't a reason to remove them
from the toolbox of a professional.

Even if the hardware store sells more hammers, that only means that it is
more popular, not that it is the best tool for everyone.


Bo Persson

 

[blangela]

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.

I notice that I have not seen a single post in this thread from an
instructor stating that their C++ classes are increasing in size, or
even maintaining their size. I know that I get students from UBC (one
of the 2 large local uniiversites, the other being SFU) who want to
learn C++. They complain that it is no longer available at UBC. Also,
when I first started teaching C++, there were several other local
colleges doing the same. Now I believe only BCIT (where I teach) is
still doing so.

Bob

 

[Frederick Gotham]

blangela:

I notice that I have not seen a single post in this thread from an
instructor stating that their C++ classes are increasing in size, or
even maintaining their size.

Programming instructors don't tend to be of the highest proficiency.

 

[blangela]

blangela:



Programming instructors don't tend to be of the highest proficiency.

They are usually able to read and write! That's all it takes to post
on this forum.

 

[Tony]

Frederick Gotham wrote:

One could criticize the automatic transmission because
it put a great number of "less skilled" drivers on the road -
individuals who would otherwise not be driving.

Anyone so criticizing is not very smart: the less one has to do during
driving
the better. Your example is akin to saying that those who can drive and
talk and dial on their cellphones are "safer" since they can/are doing more
things at once (unecessary things), which of course is opposite of the
truth. "less skilled", perhaps, but "less skilled in unecessary tedium and
therefore more attentive to the driving task" is more correct.

I think you just took your analogy too far and tried to draw too many
parallels.

Tony

(P.S. Not to even mention that the "4 on the floor" crowd are the hotrodders
on
the street! So if safety is the goal, I'd opt for more of the auto-trans
people on
the roads.)

 

[Tony]

Frederick Gotham wrote:

It may be instructive to draw some parallels between programming
languages and car transmissions.

And maybe not!

Tony

 

[Tony]

Frederick Gotham wrote:

Doesn't the complexity of C++ really work to the economic
benefit of professional C++ programmers?

And don't forget the tool builders!

Tony