>>34
Not
>>33-chan here, but you can't just dismiss it as a semantic argument; the semantics are *extremely* important. In C++ lingo creation is synonymous with construction. The object is said to exist only when its constructor has successfully completed execution. If it does not successfully complete, the object never existed.
I feel it's erroneous to state that an object isn't created if an exception is thrown, as this implies there are absolutely zero side-effects if this occurs
It does not imply that at all. What sane rational person would expect no side effects from something that throws an exception??
Besides, it's extremely rare that you need to worry about the side effects, since allocated memory using new is automatically released (as are stack objects of course) which has effectively no side effects (certainly no performance issues comparable to propagating the resulting exception). You only need to worry about the side effects if you are writing an overloaded new operator, or using placement new on some manually allocated memory, or some other perversion of the allocation system.
I should point out that if you have allocated any memory in the constructor prior to the exception being thrown, you must make sure that that memory is reaped from inside the constructor.
Yes, this is unfortunately a common error. The resulting constructors are ass-ugly too if you try to do it with try/catch (it almost looks as bad as Java). The vast majority of these issues are solved with a simple smart pointer though; it only gets ugly if you are e.g. filling an array with allocated objects and one of them throws. Boost's pointer containers help.
This is honestly the biggest reason I am looking forward to sepplesox. With move semantics and perfect forwarding, there is now the universal unique_ptr for unique ownership. Finally a smart pointer with *zero* overhead of any kind which you can safely put in containers, return from functions, etc. There is no excuse to have an allocated bare pointer anymore.