Python Productivity over C++

[Wim Lavrijsen]

Mike Steed <MSteed at altiris.com> writes:
>> From: wlav at atlas03.cern.ch [mailto:wlav at atlas03.cern.ch]

>> All that STL containers require is that your dtor and copy assignment
>> don't throw. The compiler generated members fullfill that requirement.

>True.  And although it's not required, it *is* a good idea to make sure that
>each class's copy constructor and assignment operator behave properly.

For that matter, it *is* a good idea to make sure that all your code
behaves properly. So?

>The default copy ctor often does not do what you want, e.g., if your class
>contains pointers to other objects.

If generated members are 'often' not good enough, then all red lights
should start flashing, as you have a design flaw. It is extremely hard to
make such code exception safe. Instead, you should encapsulate the code
that needs a specialized cctor and use it as member or private base.

I've done a quick scan through some of my code base and I have found 2
classes that need an explicit cctor.

>> Please inform yourself better before making such statements. Blindlessy
>> drawing conclusions based on the C++ implementation of one particular
>> vendor from Redmond isn't good for your credability.

>And assuming that I'm blindlessly drawing conclusions based on Microsoft's
>compiler is not good for your credibility.

It is the only compiler that comes with an STL that beeps at you when you
don't provide said members. If I may ask then, where did you find your
enligntment?

>The default copy ctor (regardless of the compiler) simply does a
>member-by-member copy, which is often the wrong thing to do.

Again, I strongly disagree with your 'often'.

>The point is that, even if the default is
>acceptable, the C++ programmer has to (or should) think about it.

There is such a thing as 'second nature'.

>This discussion illustrates the original point: these are details that the
>Python programmer does not need to deal with.

I fully agree that Python is far simpler, but STL is not so complex as you
seem to want it to be.

Best regards,
         Wim Lavrijsen