J
James Kanze
James Kanze <[email protected]> wrote:
[...]
Someone "vaguely familiar with the STL" is going to fair no
worse with our container libraries (and I wouldn't expect such
a person to have much knowledge of the algorithms at all)...
So that isn't a good enough reason to invest in the switch.
Someone "vaguely familiar with the STL" will still know that to
declare an array of double, you write std::vector< double >.
And that to build it up, you use push_back(). That a standard
idiom is to declare it empty, and build it up (which isn't the
case with most of the other libraries I've seen). He will know
that you need two iterators to do anything, and that different
types of containers, iterators and algorithms exist; if he's any
good at all, he will know to check the list of algorithms to see
if one exists that will do what he needs (which doesn't always
help as much as you'd like, because the names aren't always
clear enough, and one of the most useful algorithms, accumulate,
isn't in the algorith section at all.
He won't know about allocators, of course, nor will he have
memorized all of the algorithms. And he'll his knowledge of
what invalidates an iterator will be limited to the vague notion
that as long as you only call const functions, you're safe. But
he still knows enough to be able to use them for everyday
purposes from the day one.
I'd hate to knock any particular school despite the fact
almost all of our new hires came from the same one... They
tend to wonder why they should bother with making member's
private, they don't seem to understand why its good to break
that two page function into smaller conceptual blocks, they
think a class with 30 member-variables is acceptable...
.
There are several issues, and I find schools (and even
professors in the same school) vary. I know that some schools
take their C++ seriously. And of course, many of the issues you
raise are more basic, software design issues. (Given the
choice, I'd hire someone who only knows Java, but is good at
software engineering, over someone who knows all the details of
C++, but writes two page functions and classes with 30 member
variables.) Regretfully, such issues do seem to get short
shrift in a lot of schools. And even less attention seems to be
given to the most fundamental software engineerig issues: things
like making a cost efficient choice among the available
solutions. (Whence the problem I cited: those that do know the
STL and TMP tend to overuse and abuse it, because it is cool.
But it's nothing new: today, I constantly see template classes
that are instantiated just once, for a single type; in earlier
days, it was abstract base classes with just a single derived
class. I've come to believe that premature genericity is a lot
like premature optimization.)