C++... is it dying?

[James Kanze]

The new kids we hired (about 20 in the last 3 months) don't
know the STL, so your reasoning is quite speacious.

I know. It's a problem. I once had a candidate who didn't know
the meaning of virtual. There are a lot of Basic or C
programmers out there who claim C++, because it is what the
market is asking for.

That's why you vet candidates, and don't take their CV too
literally until you've actually talked to them.

Most people learning C++ still learn "from the ground up",
they have barely touched on the standard containers and
algorithms (if at all,) and routinely use raw pointers and
loops, because that was what they learned in school.

What school? There are some professors who are out of date, but
on the whole, the situation is no where near as bad as you seem
to indicate.

I've seen a lot more of the opposite: the people coming out of
school are all eager to show what they've learned, and throw in
template metaprogramming and who knows what all else, when all
that is needed is a simple for loop.

I'll spell it out, C++ (indeed any language that has been
growing for a while) has a bunch of "standard features" that
people don't use, and more is being added, while it also has a
bunch of "warts" that people have to use.

As you say, that's a penalty which comes with being mature. C++
certainly can't be accused of being overly simple or to
abstractly elegant. In the case of C++, in addition, the
language tries (and largely succeeds) in being usable for
everything. But it's clear that the features you need to
implement an OS kernel or a low level library (like the standard
library) aren't generally of much use in application code. And
vice versa.

Please understand, I love the language and know it well, but I
find that isn't the case for most users of it.

The problem I sometimes find is that while the older users and
the youngers both know the language well, and love it, it's not
always the same language they know and love. (The other problem
I find is that most practitionners seem to go to extremes. It's
either STL and TMP everywhere, or no where. You need balance:
my job as an applications programmer isn't to stress test the
compilers, but you also do have to evolve.)

 

[James Kanze]

Just take a look at the libraries from Rogue Wave or Qt.

Experience with the early Rogue Wave libraries is *why* people
felt that value semantics were so important. (To its credit,
Rogue Wave moved over to supporting value semantics very
quickly, too.)

The STL allocators literally multiply the length of compiler error
messages.

Which may be indicative that there could be some improvement in
compilers, particularly when it comes to generating error
messages.

Moreover, you don't need user-defined allocators when the
library merely uses value semantics (values and copies of
values). Even if there were a need for allocators they
wouldn't have to be template parameters.

Allocators are a misfeature. IIUC, Stepanov introduced them to
support different pointer models (small, medium, large, etc.).
Why they lived on after this need died, I can't fathom myself.

 

[Roland Pibinger]

Experience with the early Rogue Wave libraries is *why* people
felt that value semantics were so important. (To its credit,
Rogue Wave moved over to supporting value semantics very
quickly, too.)

I don't know which 'early' versions you are referring. From a
pragmatic point of view Rogue Wave libraries, esp. (formerly known as)
Tools.h++ and DbTools.h++ are the best C++ libraries I've seen so far.
Stepanov's use of 'value semantics' is the same as in functional
programming languages. It means stateless programming without
references and pointers (the only permitted 'pointers' for STL
programming are the iterators).

Which may be indicative that there could be some improvement in
compilers, particularly when it comes to generating error
messages.

Compiler error messages have not improvend since the mid 90ies. They
are pimarily determined by the nature of templates as code generators.

Allocators are a misfeature. , Stepanov introduced them to
support different pointer models (small, medium, large, etc.).
Why they lived on after this need died, I can't fathom myself.

AFAIK, allocators were not part of the original STL. According to this
paper Stroustrup introduced them into STL:
www.research.att.com/~bs/DnE2005.pdf

 

[ian-news]

The new kids we hired (about 20 in the last 3 months) don't know the
STL, so your reasoning is quite speacious. Most people learning C++
still learn "from the ground up", they have barely touched on the
standard containers and algorithms (if at all,) and routinely use raw
pointers and loops, because that was what they learned in school.

Then they aren't C++ programmers.

No one who lacks an understanding of a core component of the language
can calim to be a C++ (or any other language) programmer. The stadard
library is at the core of the language.

Ian.

 

[ian-news]

Thank you for answering James Kanze's question about when a language is
dead.

If only software written with the STL as a core component is "C++
software" then I expect the popularity of the language is far smaller
than the raw numbers let on.

That is not what I said.

One can write C++ code using whatever subset of the language one
chooses. Anyone claiming to be programmer in any language should be
familiar with that language's core libraries. The C++ standard
library is over half of the language standard, or any decent textbook.

Ian.

 

[ian-news]

Why build a new one when we already have one that works quite well, and
has already been ported to five different architectures? Why would
someone start a new project from scratch and not take advantage of any
of the libraries in existence (many of which *don't* use the STL because
they are older than the STL?)

Why use electricity when we have gas lamps?

What happens when you have to use a new compiler or platform where
your libraries don't build? If you use the standard libraries,
porting is someone else's problem.

Why use STL constructs when a majority of the programmers in the
software house don't know them? Talk about maintenance nightmare!

Time to book some training. It sounds like your staff are going
stales.

I like the STL and I think that many of the solutions it embodies are
better than the ones my company uses, but why should I write code that
only I understand? Why should I have to deal with the extra complexity
of converting from STL classes to the in-house classes and back again?

Try pairing and collective code ownership for a while, your team's
skills will improve considerably.

Ian

 

[Chris Thomasson]

Not to me, it sounds realistic. If you don't think you are dying, you
are in denial.

LOL! :^D

 

[ian-news]

So now you are suggesting that I stop a productive company in the middle
of several projects to train people how to do... What exactly? Use a
library that implements a bunch of stuff we already have implemented?
Why would I do that?

To be more productive? Unless you have implemeted your own version of
the complete standard library.

In my last job we spent quite a bit of time replacing (my) libraries
with the standard library, mainly help get new developers up to speed
faster. Mind you, I did make sure they knew their stuff before
employing them!

Ian.

 

[puzzlecracker]

What would comprise a good education for to be a good C++ developer,
especially for someone who has a passion for the language. Please
don't just list C++ books; there's more to programming than c++.
Rather something that goes well with C++, and of course C++ books,
technologies, applications, etc. I will think tonight about my
repertories.

 

[Chris Thomasson]

What would comprise a good education for to be a good C++ developer,
especially for someone who has a passion for the language. Please
don't just list C++ books; there's more to programming than c++.
Rather something that goes well with C++, and of course C++ books,
technologies, applications, etc. I will think tonight about my
repertories.

If I were teaching a college course of C++:

http://groups.google.com/group/comp.lang.c++.moderated/msg/ecdb4d22c2cd4f40

http://groups.google.com/group/comp.lang.c++/msg/18d7db52e9fc4a57

Any thoughts?

 

[Chris Thomasson]

Why build a new one when we already have one that works quite well, and
has already been ported to five different architectures?

Im am curious as to why you had to port your libraries to specific
architectures? If you use pure Standard C++, this is not necessary. Are you
using arch-specific material in your existing framework?

[...]

 

[Chris Thomasson]

"puzzlecracker" blew my mind thusly:


Hardly. Only people who have never tried STL talk like
that.

At my last job, our primary software product contained
maps of structs which contained deques of structs. Try
implimenting THAT with C-style C++! You could do it,
but it would take you a very long time, and you'd end
up just reimplimenting the STL, badly.

Why badly? You don't think that there are any STL algorihtms out there which
are implemented in a suboptimal fashion?

Complete waste
of time! It's already written. Why not just use it?

Here is a VERY contrived case indeed:

Well, what happens if you needed the maps and deques to run in a
multi-threaded environment, and you wanted a full-blown non-blocking
implementation? Yes, there are wait/lock-free deques. Yes, there are
lock-free maps. The STL does not provide them. So be it.

 

[tony_in_da_uk]

This is a recurring and entrenched permeating this group... hence
treat it as such

I have recently started a new job, and to my surprise, we still write
a fairly traditional c++ code, still using raw pointers, and still in
market with our products.

How popular is this scenario?

What's the future for C++, other than ceasing years of
maintainance ?

Will new standardization create new markets for c++ developers and
applications, will it expand the application domain?

These are broad questions, seeking some reassurance, hope... well,
perhaps not so dramatic, but am genuinely curious what other think
about.

PuzzleCrakcer!

C++ isn't dying. It's already a great language, and is evolving at a
slow but significant pace. Interestingly, the C++0x features will
help to address some of the complexity issues discussed in this
thread: for example, concepts - while making the language more complex
- allow cleaner demarcation and layering between libraries and users
with better diagnostics of usage violations. So, complexity of
language and complexity of typical usage shouldn't be confused.
Another example: lambdas might be confusing to implement, but the
concept is relatively simple (if abstract), and can massively simplify
and enable client code. It's a big mistake to think that the people
directing C++ evolution aren't smart enough to see through many of the
common usage issues and address them with surgical precision.

Also, C++ users are typically divided between those who're keen, able
and experienced users and those inexperienced or doing just enough to
get paid. Particularly in larger cities supporting both industries
that pay exceptionally well and critical masses of C++ developers,
both expectations and actual standards of use are often high. In less
"hot" locations, that critical mass may not be reached or sustained.
Individual developers may, however, still do excellent work on smaller
projects. Online forums like this, and open source projects, provide
a distributed development model where people can cooperate
irrespective of distance, and are important if you aspire to become an
expert but don't have other experts to mix with.

People like Walter with his D language have streaked off ahead to
explore some of the territory that I hope C++ grows into, hopefully
without becoming too eccentric. There is a lot of scope there,
particularly - in my mind - in the areas of introspection and a
guaranteed interpreter/virtual-machine, such that a future C++ may
allow freer mixing of compile-time and run-time techniques.

Tony

 

[Ian Collins]

What would comprise a good education for to be a good C++ developer,
especially for someone who has a passion for the language. Please
don't just list C++ books; there's more to programming than c++.
Rather something that goes well with C++, and of course C++ books,
technologies, applications, etc. I will think tonight about my
repertories.

The best education is a balanced mix of book work and practical
experience. Work with good people and read all you can.

 

[James Kanze]

[...]

So now you are suggesting that I stop a productive company in
the middle of several projects to train people how to do...
What exactly? Use a library that implements a bunch of stuff
we already have implemented? Why would I do that?

Continuous training is necessary. Regardless. Independantly of
STL or not.

The STL is nice, but it came too late for my company. By the
time reliable implementations existed, we already had our own
code written and deployed in several products.

Now a "new version" of C++ is coming out. Once again full of
solutions to problems we have already solved...

I'm sorry to sound so negative. I tried years ago to push my
company into using more of the standard library, but I still
can't answer the simple question... "Why switch?"

As I said, because it is standard. And because any new hire who
claims to know C++ and isn't at least vaguely familiar with the
STL is lying. In the same sense that someone who claims to know
C++ and doesn't know what a virtual function is is lying. (They
may be unconsciously lying, of course.)

I don't know where you're recruiting your programmers, but the
problem we see with new hires is just the opposite. Having just
learned C++, they know all of the latest techniques, and have to
be constrained from making everything a template, and doing
everything with the standard library, even when it isn't
appropriate (e.g. writing a completely new class, requiring
significant local context to be passed to its constructor, in
order to replace a three line for loop with std::for_each).

 

[shablool]

AFAIK, allocators were not part of the original STL. According to this
paper Stroustrup introduced them into STL:www.research.att.com/~bs/DnE2005.pdf

STL allocators does not enable the user to associate a container
instance with specific memory-pool. As a matter of fact, multiple
instances of various STL containers would typically use the same
memory-storage (i.e., malloc/new). Performance benchmark shows that
pool-based containers may be more then twice faster then STL
containers, particularly in modern multi-threaded environments (see:
http://strinx.sourceforge.net/docs/strinx.html).

Nevertheless, the STL is a remarkable library, whose influence on the
world of software programming will last for many years, and should be
part of every C++ developer's toolbox.

S.

 

[Daniel T.]

Im am curious as to why you had to port your libraries to specific
architectures? If you use pure Standard C++, this is not necessary. Are
you using arch-specific material in your existing framework?

There is an underlying set of classes that actually connects the
framework to the OS in question. We have ported our framework to
several versions of Windows and MacOS, XBox, Wii, GBA, and NintendoDS.

 

[Brad]

"puzzlecracker" blew my mind thusly:


Hardly. Only people who have never tried STL talk like
that.

We use a lot of STL for small cross-platform applications programming.
It's quite handy for solving everyday problems. A good book to read when
learning C++ is "Accelerated C++" it gets into the STL right away. The
older C ways are still doable if/when one prefers them... that's what I
like most about C++. It's very flexible. I don't see it going away soon.

 

[Ian Collins]

The new developers that have interviewed with our company don't know the
STL much more than they know our containers, and don't know algorithms
at all.

Ah, so they don't know C++.

 

[shablool]

First, let's be clear about the origin: they were, indeed, originally
used to mask the differences between different pointer types under
Windows, which had near (DS-relative) and far (absolute, loosely
speaking) pointers and references.

Second, the reason that STL allocators do not support specifying
per-container memory pools is only the design compromise that allows
but doesn't require containers to treat allocators of the same type as
equal. Several STL implementations don't rely on this assumption, and
you can, in fact, have per-instance allocators. This support will be
required in C++0x.

Interesting! Thank you very much for this clarification.

S.