Diving into the .NET framework 2.0, I found today one of those amazing conceptual articles that make me venerate some people at Microsoft.
All this knowledge of the language implementation and whereabouts always make me feel small in front of a huge building.
Well so, the article is called "Cast Notation and Introduction of safe_cast<>" in the "Visual C++ Concepts: Porting and Upgrading" section.
It really interested me and clarified plenty of things that had stayed fuzzy until now.
Among these I now know exactly how the RTTI works, and so I finally understand what's underneath the dynamic_cast operation. Congratulations on the explanation. ;-)
There's however one thing at the very end of the article I didn't exactly get.
The author mentions two C programmer pitfalls about performance overhead, and I don't see them 8-|
The first one is the following :
// pitfall # 1:
// initialization can remove a temporary class object,
// assignment cannot
Matrix m;
m = another_matrix;
I guess what is at stake here is the comparison with an initialization like :
Matrix m = another_matrix;
where the compiler could optimize the code with using directly the copy constructor, instead of creating a temporary object and then calling the affectation operator.
For the second one I didn't see the point at all. The only code/comment given is :
// pitfall # 2: declaration of class objects far from their use
Matrix m( 2000, 2000 ), n( 2000, 2000 );
if ( ! mumble ) return;
Could somebody put some light on these
Thanks.

Cast Notation and Introduction of safe_cast<>
Dave the Zionist
Thank you.
codemanwa
Both of these issues are about your program doing extra work.
Imagine that the Matrix class as has a really expensive default constructor: then the code in the first example calls the default constructor (which is expensive) and then immediately invalidates all that work by assigning a different object to the object you have just created.
Matrix m = another_matrix;
is exactly equivalent to:
Matrix m(another_matrix);
And in this case, as you correctly stated, only the copy-constructor will be invoked.
The second case is less obvious (and unlikely). Again imagine that the constructors for Matrix are expensive: in this case you initialize two matrix objects and then if a certain condition is correct your exit the function. The solution to this problem is to move the declaration of the objects until after return from the function.
Both these issues are common pitfalls that C programmers make when they move to C. Programmers who have only learnt C++ (or learnt C++ first) rarely make these mistakes.