Pavel Minaev said:
On Jul 19, 4:36 pm, "Giovanni Dicanio" <gdicanio@_NOSPAM_email_DOT_it>
wrote:
[...]
Using tools like string classes, container classes and smart pointers makes
C++ code robust and easy to write and manage.
Well, sort of. Until you accidentially invalidate an iterator by
modifying the container - U.B. Or mix signed and unsigned integer
types in an arithmetic expression and get weird results because of the
silent signed->unsigned conversion rule (and it is very easy to do so,
since a lot of standard library functions return unsigned integers -
e.g. size() of any STL container is unsigned). Or forget that
assignment operator and "copy" constructor for auto_ptr are actually
move and not copy. Or put an auto_ptr into a container (and why not,
if it lets you do so without any compaints...). Or try to make sense
of three paragraphs of ISO C++ standard describing overload resolution
for template functions in presence of partial specializations (the one
where synthetic types are involved). The problem is, you have to be a C
++ expert to write good C++ code, and, not any less important, to be
able to understand advanced C++ code written by others that's thrown
at you.
I've looked at this list and I agree with the unsigned vs. signed
issue, everything else I don't agree with. I can't see how you can
implement a dynamic array that doesn't invalidate iterators upon
insertion (might be my limited imagination, though).
I don't think I've used 'std::auto_ptr' in the last five years. If
I needed a smart pointer (which is rather rare if you use the above
mentioned tools) I needed (and used) a ref-counting off-the-shelf
one. And there's no function template partial specialization, so it
can't mess with the overloading rules.
I agree that C++ is a huge and complex beast to deal with, but I
also agree with Giovanni that a modern use of it leads to save,
robust, and easily maintainable code. Unfortunately I also have to
agree that too few programmers are using it that way.
I think it all boils down to the old observation that C's heritage
is both a bless and a curse for C++. That's valid for teaching it,
too. C++ was taught as a better C for far too long and that still
hasn't changed enough. To many studentsare taught a style that begs
for subtle bugs, alltough there are better ways to make use of the
language.
My personal opinion is that most programmers would benefit a lot
from reading Koenig/Moo's "Accelerated C++" even though it's meant to
be for novices. I read it many years ago (because I teach C++) and
while I don't think it showed me anything I didn't know yet, it did
teach me that C++ has changed enough throughout the last 15 years to
make it possible to teach it to students in a way that makes them
programming the style Giovanni advertized from day one.
I have 15-20 lectures (90mins each) to teach C++ to students who had
one year of Java-only exposure and found that it's possible to go all
the way from "Hello, world!" to template meta-programming in that
time. I hammer a lot of rules of thumb into them and teach them a
style where C++ is a like big box of Lego bricks from which your can
safely build anything you need. I rarely ever have a semester where I
give an exercise where they have to write 'new', let alone 'delete',
but they see 'std::vector' in lesson two, along with 'std::string'
and IO. C++ is still more unsafe than other languages because it just
relies on programmers not to do stupid things, but given a modern
combination of compiler/RTL/std lib you get a lot of meaningful run-
time error messages in debug mode while still enjoying full speed in
release mode.
Don't get me wrong, C++ is a great language, and the time I've spent
writing in it was great. But from my experience, I would never let it
anywhere near domain logic except where it is spefically needed, when
I have the choice, because too many times I've witnessed how even
skilled and experienced (5+ years) C++ developers wrote some seemingy
trivial code which then broke things in subtle ways.
But that's really hard to do if you don't do manual memory and the
like. Mostly this happens because programmers only use C++ as a
better C -- which is exactly what Giovanni said would lead to subtle
bugs.
I once spent 2
whole work days in the debugger trying to find the code that lead to
"Heap corrupted" error which invariably manifested itself under
unclear conditions after the program was used for 2-3 hours. It's not
fun at all. It's also something that's much, much rarer in the
"managed code" land.
IME the crashs reported from testing tend to happen in certain parts
of the code and correlate with the style used in there. I rarely saw
more than one crash per year in my code /while testing on my machine/
and went years without having one checked in.
And that's not really hard to do if you write code the way Giovanni
suggests.
Schobi
