I come not to bury C++, but to praise it...

[Derek]

"Cameron Laird" wrote:
>
> >I also use C++ and Python as my main languages and I agree
> >with your comments.  However, I don't agree that Python is
> >inherently "safer" than C++.  At best I see it as a tie.
> >For example, C++ let's you corrupt memory among other
> >"unsafe" things, most of which can be avoided by using
> >standard containers, smart pointers, etc.  Python lets you
> >do "unsafe" things such as passing an object to a function
> >when it makes no sense to do so, which can lead to nasty
> >runtime surprises.
>
> We disagree on some matters.
>
> I *do* regard Python as inherently safer than C++, and
> much more so.  My aim for now is not to persuade you to my
> view, but only to make it explicit.  Memory management, and
> mismanagement, as mundane as it is, is so poorly applied
> in so much of the C++ code I see, that it swamps all other
> dimensions of comparison between the two languages.  I
> quite agree with you that competent C++ programmers should
> exploit smart pointers and so on.  My experience is that,
> somehow, C++ as it's generally practiced appears to have
> barriers to their use.

I see your point and -- despite my original post -- I agree with it.
Reflecting on my own experience with C++, I agree that C++ does not
seem to make writing safe code as easy as it should, at least for the
uninitiated.  Standard containers (eg, vector, list, map, etc.) don't
get used as much as they should.  Robust smart pointers (eg,
boost::shared_ptr) seem to get used even less.  In terms of memory
management, Python does seem safer.

> I don't understand your last sentence, and, given my own
> focus on reliability, I very much want to understand it.
> Are you alluding precisely to Python's dynamic typing, and
> observing that, as earlier is better, C++'s compile-type
> checks beat Python's run-time checks?

Yes, I prefer compile-time checks to run-time checks.  I don't know
which method is "better" by any objective measure, but I prefer to
know if there is a problem as early as possible.  It's not hard to
make a change in Python that will go unnoticed until much later, and
in the real world test suites often don't have enough coverage to
catch every runtime error up front.