Quote:Original post by Sneftel
Er, you should probably read the rest of the thread. shared_ptr's solution to the problem of incomplete types has the side effect of removing the need for virtual destructors, as long as the initial shared_ptr is constructed correctly.

#include <iostream>#include <boost/intrusive_ptr.hpp>struct Data{	~Data() { std::cout << "I got destroyed" << std::endl; }};struct A{	void ref() { ++count; }	void unref()	{		--count;		if ( count == 0 )		{			delete this;		}	}	size_t count;	A() : count( 0 ) {}};void intrusive_ptr_add_ref( A* a ){	a->ref();}void intrusive_ptr_release( A* a ){	a->unref();}struct B : public A{    Data d;};int main( int argc, const char* argv[] ){	boost::intrusive_ptr< A > ptr( new B );}

Quote:Original post by Red Ant
Yes, and that's all good and well if you happen to be using shared_ptr, but try using intrusive_ptr without virtual d'tors and watch your application leak stuff all over the place.

Quote:in general I think it's better to be safe than sorry.

Quote:Original post by LionMX
I personally would do it like this:

//Your constructor
ClassOne::ClassOne()
{
//Stuff
if(error)
{
throw ErrorCode(DATA_PROBLEM)
}
}

//Global
ClassOne *p_myClassOne = NULL;
ClassTwo *p_myClassTwo = NULL;

int main(void)
{
try
{
*p_myClassOne = new ClassOne;
*p_myClassTwo = new ClassTwo;
}
}

Sorry about the mess above but no time to format it whilst im in work. Basically putting a throw in your constructor will give an error if an object fails to initialize (picked up by the try).

Quote:I think you far overestimate the limitations in flexibility that the use of smart pointers imposes (essentially none -- just because you don't use manual lifetime management doesn't mean you can't), and far underestimate the performance difference between refcount-based memory management and an actual GC

Quote:In what respect have I sacrificed flexibility? I haven't sacrificed any. In fact I've increased flexibility because I'm able to forget about micro-managing allocation.

Quote:I'm confused. Surely the upper rollback will only fail if it doesn't have the strong guarantee but the current context's does? In what respect does checking a parameter and throwing if it's invalid violate the strong exception guarantee? The guarantee is that either an exception is thrown and no state has changed, or the operation completed successfully.