Re: C++... is it dying?
James Kanze <james.kanze@gmail.com> wrote:
"Daniel T." <danie...@earthlink.net> wrote:
ian-n...@hotmail.com wrote:
Daniel T." <danie...@earthlink.net> wrote:
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.
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.
Of course... We train in ways to do *new* things though, not in new ways
to do old things.
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.
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.
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).
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...