Deleting an object if the constructor failed.

Hi guys, I want to ask you about how to delete an object if its constructor failed to initialize one of its members. I tried it like below but failed:

Code:

---

B* A:CreateB(std::string paramStr)
{
    B* pB= NULL;
    try
    {
        pB = new pB (paramStr);
    }
    catch (int result)
    {
        if (result == OK) // OK == 1
        {
                m_VectorB.push_back(pB);
        }
          else if (result == FAILED)
        {
                delete pB;
                pB = NULL;
        }
    }
    return pB;
}

B::B(std::string paramStr)
{
    int result = initMembers (paramStr); //returns OK / 1 if successful or FAILED / 0 if failed
    throw result ;
}

---

Now, FYI, I have never ever ever used exception in my entire life as a programmer. All my error handlings are either by return value or assertion. I know that it is not a good habit but I still don't have a good understanding about it. So, how can I solve this problem? Thanks in advance.

First let's clarify what 'delete' means: to invoke the destructor and then release the memory (internally, usually done using free()) associated with the object. Furthermore, only the 'owner' of the object calls 'delete' on an object. If you're assigning the result of 'new' to a raw pointer (very bad idea) then that would be you. Otherwise, it's whatever container you're using to manage it with.

So then I suppose the question is "does a destructor get invoked on a partially constructed object?" (eg: when an exception is thrown, but not caught, during the constructor). The answer is 'no' (it will, however, be called on whatever class members were fully constructed up to that point).

As far as throwing integers as return values, IMO, the is a very bad design. There are a lot of differing opinions on the matter, but the general consensus is that exceptions should only be thrown from an object in the most extreme situations (eg: 'fatal' errors). On the other hand, exceptions thrown and caught from within the same object is often a useful technique for overcoming complicated control-flow situations, but that's a different matter entirely.

new does two things: a) allocate memory, b) call constructor. delete does the opposite: a) call destructor, b) deallocate memory.

Now if the constructor throws an error, new deallocates the memory and rethrows the exception. Also, when the constructor throws, the object never comes to existence (members initialized so far are destroyed) and therefore it would be an error to invoke the destructor on the zombie.

So your attempt to signal success by throwing an exception from a constructor couldn't possibly work.

Correct way:

Code:

---

B* A::CreateB(std::string paramStr)
{
  //no special error handling needed here
  //some caller handles allocation/construction failures
    B* pB = new pB (paramStr);

    //if the previous line didn't throw (= if we get this far in the first place), everything's OK
    m_VectorB.push_back(pB);
       
    return pB;
}

B::B(std::string paramStr)
{
    int result = initMembers (paramStr); //returns OK / 1 if successful or FAILED / 0 if failed
    if (!result) throw some_exception("something is wrong"); //only throw in case of failure
}

---

Of course, even better would be to have each member initializer in turn use exceptions to signal errors, because the entire point of exceptions is that they propagate upwards automatically.

I suggest that you read GotW #66: Constructor Failures.

Thanks for the reply guys

@Sebastiani: Well, I know that the 'new' method mallocs and then calls the constructor and 'delete' calls the destructor and then free the memory. What I don't know is how exception works in general. And I thought that the object will be fully created even if I throw an exception in the constructor. I guess I'm wrong.

About passing int as an exception, yeah, I know that it's not a good idea. But it is sufficient as of now.

BTW, as for assigning 'new' to a raw pointer, I've seen lots of open source libraries do that also. So i thought, why can't I?

@anon: OIC, I thought we can throw anything at anytime. My mistake then. BTW, your code didn;t work. I tried this one though and it worked:

Code:

---

B* A:CreateB(std::string paramStr)
{
    B* pB= NULL;
    try
    {
        pB = new pB (paramStr);
    }
    catch (int result)
    {
          pB = NULL;
    }

    m_VectorB.push_back(pB);
    return pB;
}

B::B(std::string paramStr)
{
    int result = initMembers (paramStr); //returns OK / 1 if successful or FAILED / 0 if failed
    if (result == FAILED)
                  throw result ;
}

---

@CornedBee: Well I would if there's no time constraint. Heck, I will rewrite the entire code with exceptions if there's time. But for now, it's okay to do this quick hack. :P

@laserlight: Thanks. Another source of information is always good.

Quote:

---

BTW, as for assigning 'new' to a raw pointer, I've seen lots of open source libraries do that also. So i thought, why can't I?

---

Yes, unfortunately it's fairly common, actually. There are numerous good articles on the subject (ie: RAII), but briefly, consider this bit of code:

Code:

---

struct fatal
{    };

struct object
{
    object( bool chaos )
    {
        if( chaos )
            throw fatal( );
        cout << "object( )" << endl;   
    }
   
    virtual ~object( void )
    {
        cout << "~object( )" << endl;   
    }   
};

void test( void )
{
    object*
        ptr = new object( false );
    object
        obj( true );
}

int main( void )
try
{
    test( );
}
catch( ... )
{    }

---

Output:

Quote:

---

object( )

---

Here, 'ptr' is not 'protected' by a destructor, so when/if an exception is thrown, it never gets cleaned up. You might be tempted to do something like this:

Code:

---

void test( void )
{
    object*
        ptr;
    try
    {
        ptr = new object( true );
        object
            obj( true );
    }
    catch( ... )
    {
        delete ptr; // whoops!
    }
}

---

But that isn't correct either. In this case, the exception was thrown while allocating 'ptr', so an invalid delete is applied!

You might think you could simply call delete if the exception isn't an std::bad_alloc, but unfortunately, that won't work since it could have originated from anywhere between the try block.

The solution, of course, is to follow the RAII strategy:

Code:

---

void test( void )
{
    std::auto_ptr< object >
        ptr( new object( false ) );
    object
        obj( true );
}

---

Output:

Quote:

---

object( )
~object( )

---

Perfect!

Doing exceptions without strictly following RAII principles is just setting yourself up for lots and lots of headaches, and bugs in code paths that are very rarely tested.

Quote:

---

Originally Posted by g4j31a5

BTW, as for assigning 'new' to a raw pointer, I've seen lots of open source libraries do that also. So i thought, why can't I?

---

I commonly assign new to LPVOID when I am abstracting a class to hide internal details when distributing a closed source middelware library. This way I can have a header with only the public methods and data showing, enforcing privatization and at the same time protecting trade secrets.

e.g.

Code:

---


class Public_Class {
  LPVOID pObject;

  // public functions and data go here

---

then in the actual constructor

Code:

---

Public_Class::Public_Class(){

  this->pObject = (LPVOID) new ActualClass();

  return;
  }

---

Since my public class functions will have access tot he ActualClass header they can manipulate the object by recasting pObject to (ActualClass*), but the end user only gets the compiled library and the Public_Class header, so they do not have access to the ActualClass member functions or variables and can only access it through the methods I allow.

But why not do this?

Code:

---

class Public_Class {
  class Impl;
  boost::scoped_ptr<Impl> m_impl; // or equivalent to scoped_ptr

public:
  Public_Class();
  ~Public_Class();
};

// implementation:
class Public_Class::Impl
{
  // ...
};

Public_Class::Public_Class()
  : m_impl(new Impl)
{}
Public_Class::~Public_Class()
{} // Empty. It's only out-of-line to force an instantiation location for scoped_ptr's destructor.

---

No casting, no chance of exception unsafety. You have to implement copying if you want it, of course, but you have to do that anyway.

Not my intention to hijack the topic - but the reason you shouldn't be using new directly with raw pointers with custom objects is more or less because it never goes out of scope, due to the simple fact that it's not allocated on the stack? And using std::auto_ptr solves this for us because when it goes out of scope, it destroys the objects it is encapsulating?

Very informative post - still learning how to write proper code in C++.

Quote:

---

but the reason you shouldn't be using new directly with raw pointers with custom objects is more or less because it never goes out of scope, due to the simple fact that it's not allocated on the stack?

---

More generally, you shouldn't do it because you have to explicitly control (and document) the lifetime and ownership of the object, whereas smart pointers automate, enforce and document a specific ownership and lifetime model. For example, scoped_ptr enforces single, local ownership with scoped lifetime. If you see a scoped_ptr, you know that this is the case. If you see a raw pointer, you always have to wonder.

Quote:

---

Originally Posted by CornedBee

More generally, you shouldn't do it because you have to explicitly control (and document) the lifetime and ownership of the object, whereas smart pointers automate, enforce and document a specific ownership and lifetime model. For example, scoped_ptr enforces single, local ownership with scoped lifetime. If you see a scoped_ptr, you know that this is the case. If you see a raw pointer, you always have to wonder.

---

I see. Thanks =)

I was actually wondering how I should go about solving a problem, and by surfing this forum, not looking for the solution at all, I stumbled upon it, heh.

@Sebastiani & CornedBee: RAII? what's that? sorry that's still new to my ear. I swear, the profs have never mentioned that word when I was in college. -_-a

@abachler: LPVOID is the same as void*, right? Although it's doable, it's too much of a hassle IMHO. I rarely use void* so that the code can be read better. :P

You know, I've also never used auto_ptr. It's not portable IIRC. Maybe I'll try it in the future. As for passing pointers out of scope, I usually does that and control them strictly by myself. So I have to make sure if the object is still alive or not before doing anything to it on different objects. I usually code what came up first in my head. I confess, I suck at designing my codes. :P

Quote:

---

Originally Posted by g4j31a5

You know, I've also never used auto_ptr. It's not portable IIRC.

---

It is part of the C++ standard library.

RAII.

Quote:

---

Originally Posted by g4j31a5

@Sebastiani & CornedBee: RAII? what's that? sorry that's still new to my ear. I swear, the profs have never mentioned that word when I was in college. -_-a

@abachler: LPVOID is the same as void*, right? Although it's doable, it's too much of a hassle IMHO. I rarely use void* so that the code can be read better. :P

You know, I've also never used auto_ptr. It's not portable IIRC. Maybe I'll try it in the future. As for passing pointers out of scope, I usually does that and control them strictly by myself. So I have to make sure if the object is still alive or not before doing anything to it on different objects. I usually code what came up first in my head. I confess, I suck at designing my codes. :P

---

#include <memory>

using std::auto_ptr;

Sorry for the late reply...

@laserlight: you know, I never consider STL to be a standard library. I guess I was wrong.

@CornedBee: OIC. Well, I think that's what I usually do. I always think that the object that created another object should be the one deleting it. Didn't know it had a name. :P

I don't get my almamater. I guess Informatics is different with Computer Science. There are only 2 programming subjects, "Programming Language" where we were taught the basics with the modular C programming using Turbo C, and "Advanced Programming Language" where we were taught OOP, MFC, and COM programming all in one subject, a little bit of everything. Oh yeah, there is also "Algorithm and Data Structures". The professors have never even mention C++ Faq Lite or even Bjarne Stroustrup's book (the Holy Bible of us C++ programmers) yet they go thoroughly with Data Mining / Warehousing, DFD, UML, etc. We don't even have a copy of Stroustrup's book in the library. Or is it something that you should learn autodidactly?

@IceDane: err... I actually know about auto_ptr but has never used it. I don't feel secure with using something that automatically deletes itself like auto_ptr and any garbage collector.

Quote:

---

I don't feel secure with using something that automatically deletes itself like auto_ptr and any garbage collector.

---

auto_ptr doesn't delete itself. It deletes the objects it manages. It's a very simple management strategy that says, "When I die, I take my pointee with me. Unless you take it away first."
*Not* using RAII objects like auto_ptr to manage memory is what I don't feel secure with. I completely rely on the type system to document and enforce my ownership assumptions.

>> Well, I think that's what I usually do. I always think that the object that created another object should be the one deleting it. Didn't know it had a name. :P

More specifically, anything allocated by new should be immediately assigned to an object that can properly manage the memory. And note that it must be able to do so not just within it's destructor but in assignment, etc.

>> I actually know about auto_ptr but has never used it. I don't feel secure with using something that automatically deletes itself like auto_ptr and any garbage collector.

That's basically saying that you aren't comfortable with the idea of using RAII. In fact, you should convince yourself that it's the only way to go! ;)

Anyway, just keep in mind that std::auto_ptr is a 'greedy' manager - if assigned to another std::auto_ptr it will take over ownership of the data. Here's a more friendly variant:

Code:

---

/*
        A simple memory manager.
        Note:
        DO NOT use this to manage dynamically-allocated
        arrays (use std::vector or similar for that)
*/
template < typename Type >
class managed
{
        public:
 
        managed( Type* ptr = 0 )
        : m_ptr_( ptr )
        {        }

        managed( managed const& rhs )
        : m_ptr_( 0 )
        {       
                reset( rhs );
        }
       
        managed& reset( Type* ptr = 0 )
        {
                delete m_ptr_;
                m_ptr_ = ptr;
                return *this;
        }
 
        inline managed& operator = ( Type* ptr )
        {
                return reset( ptr );
        }
 
        inline managed& reset( managed const& rhs )
        {
                return reset( new Type( *rhs ) );
        }

        inline managed& operator = ( managed const& rhs )
        {       
                return reset( rhs );
        }
       
        inline operator Type* ( void )
        {
                return m_ptr_;
        }

        inline operator Type const* ( void ) const
        {
                return m_ptr_;
        }
       
        inline Type* operator -> ( void )
        {
                return m_ptr_;
        }

        inline Type const* operator -> ( void ) const
        {
                return m_ptr_;
        }
       
        virtual ~managed( void )
        {
                reset( );
        }
 
        protected:

        Type* m_ptr_;
};

// Example usage
       
#include <iostream>

class test
{
        public:
       
        test( void )
        {
                std::cout << "test( )" << std::endl;       
        }

        test( test const& )
        {
                std::cout << "test( test const& )" << std::endl;       
        }
       
        virtual ~test( void )
        {
                std::cout << "~test( )" << std::endl;       
        }       
};

int main( void )
{
        managed< test >
                mt1 = new test( ),
                mt2( mt1 ),
                mt3( mt2 );
/*
        Fine, memory managed by 'mt3' is cleaned up in assignment
*/
        mt3 = mt1;
/*
        Fine, all memory is cleaned up when objects go out of scope
*/
        return 0;       
}

---

Code:

---

        inline operator Type* ( void )
        {
                return m_ptr_;
        }

        inline operator Type const* ( void ) const
        {
                return m_ptr_;
        }
       
        inline Type* operator -> ( void )
        {
                return m_ptr_;
        }

        inline Type const* operator -> ( void ) const
        {
                return m_ptr_;
        }

---

The first two are better implemented as operator*

Code:

---

inline Type& operator*() { return *m_ptr_; }
inline const Type& operator*() const { return *m_ptr_; }

---

If you want to give user access to the pointer itself, provide a get method.

I also suspect it might need quite a bit more to be truly useful (think about storing pointers to polymorphic objects). And if you can always make a copy of the object, why use a pointer and dynamic allocation in the first place?

Hmm, this managed() has incorrect behavior for polymorphic objects, and an implicit conversion to the underlying pointer type. Dangerous.
Not that auto_ptr isn't dangerous, especially on MSVC 2005, where there's a very, very nasty bug.

You really want a nice unique_ptr implementation. Experimental C++0x compilers provide one (GCC 4.3+, MSVC 10). There's also an emulated C++03 version floating around on the Boost mailing list.

>> If you want to give user access to the pointer itself, provide a get method.

I disagree. While the example I posted is technically more error-prone (ie: the user might try to manually delete the memory), in practice this is a non-issue. Using this particular idiom allows you to pass the object to functions expecting a plain vanilla pointer transparently. If that's just too much flexibility/freedom for you, then by all means define a manager that doesn't allow that. But from my experience the necessity for this is effectively nil.

>> I also suspect it might need quite a bit more to be truly useful (think about storing pointers to polymorphic objects). And if you can always make a copy of the object, why use a pointer and dynamic allocation in the first place?

There's no reason why this would not be compatible for polymorphic types unless the base class is purely abtract. As long as a fully constructed object of the base type is in a stable state, everything works fine. In that respect, it might even just serve as a placeholder that simply throws an exception if any actual methods are invoked. At any rate, what you're describing is exactly what std::auto_ptr was designed for - to manage objects that cannot be copy-constructed in their templated form.

Quote:

---

There's no reason why this would not be compatible for polymorphic types unless the base class is purely abtract. As long as a fully constructed object of the base type is in a stable state, everything works fine. In that respect, it might even just serve as a placeholder that simply throws an exception if any actual methods are invoked. At any rate, what you're describing is exactly what std::auto_ptr was designed for - to manage objects that cannot be copy-constructed in their templated form.

---

It just causes object splicing on copy. If that is what I wanted, I wouldn't even bother to allocate anything dynamically.

Code:

---

Base b = Derived();

---

This is just as useful as your smart pointer (for polymorphic types).

For other types it would seem that you get the overhead of both dynamic allocation and copying. (And objects too large to fit onto stack (?) would probably be noncopyable anyway.)

Quote:

---

Not that auto_ptr isn't dangerous, especially on MSVC 2005, where there's a very, very nasty bug.

---

...and it's copy semantics make it less of a smart pointer than one would think.

If you really want a great treatment of smart pointers I would go with boost. It works and it's simple to 'boost-ize' existing code which makes it a win win situation in my book. The only downside to using boost is that the MSVC debugger is often too stupid to peer into templated code and it will cause Intellisense to sit there scratching its head. Sometimes Intellisense works on boost or templates in general but most of the time it doesn't have a clue. Clearly this is a problem with the debugger and Intellisense and not boost so I cannot really blame boost for the issues. I've been using boost a lot in my code now and am beginning to wonder how I ever survived without it. Boost is far more than just a smart pointer library which also is a big plus. Boost is huge and I'm just beginning to explore some of it a bit more. I highly recommend it.

>> It just causes object splicing on copy. If that is what I wanted, I wouldn't even bother to allocate anything dynamically.

Well, in that case you'd need a smarter (and, of course, more 'expensive') pointer. I didn't test this much, but it should be pretty close:

Code:

---



/*
        A simple memory manager.
        Note:
        - This class will not prevent 'slicing' on copy.
        - DO NOT use this to manage dynamically-allocated
        arrays (use std::vector or similar for that)
*/
namespace shallow {

template < typename Type >
class managed
{
        public:
 
        managed( Type* ptr = 0 )
        : m_ptr_( ptr )
        {        }

        managed( managed const& rhs )
        : m_ptr_( 0 )
        {       
                reset( rhs );
        }
       
        managed& reset( Type* ptr = 0 )
        {
                delete m_ptr_;
                m_ptr_ = ptr;
                return *this;
        }
 
        inline managed& operator = ( Type* ptr )
        {
                return reset( ptr );
        }
 
        inline managed& reset( managed const& rhs )
        {
                return reset( new Type( *rhs ) );
        }

        inline managed& operator = ( managed const& rhs )
        {       
                return reset( rhs );
        }
       
        inline operator Type* ( void )
        {
                return m_ptr_;
        }

        inline operator Type const* ( void ) const
        {
                return m_ptr_;
        }
       
        inline Type* operator -> ( void )
        {
                return m_ptr_;
        }

        inline Type const* operator -> ( void ) const
        {
                return m_ptr_;
        }
       
        virtual ~managed( void )
        {
                reset( );
        }
 
        protected:

        Type* m_ptr_;
};

} // namespace shallow

/*
        A simple memory manager.
        Note:
        DO NOT use this to manage dynamically-allocated
        arrays (use std::vector or similar for that)
*/
template < typename Type >
class managed
{
        protected:
       
        struct generator_base
        {
                virtual Type* clone( Type const* ) const = 0;
               
                virtual generator_base* clone( void ) const = 0;
        };
       
        template < typename Derived >
        struct generator : generator_base
        {
                virtual Type* clone( Type const* ptr ) const
                {
                        return ptr ? new Derived
                        (
                                *static_cast< Derived const* >( ptr )
                        )
                        : 0;
                }
               
                virtual generator_base* clone( void ) const
                {
                        return new generator( );
                }               
        };

        public:

        managed( Type* ptr = 0 )
        {       
                reset( ptr );
        }

        template < typename Derived >
        managed( Derived* ptr )
        {       
                reset( ptr );
        }

        managed( managed const& rhs )
        {       
                reset( rhs );
        }

        inline managed& reset( Type* ptr = 0 )
        {
                return reset< Type >( ptr );
        }
       
        template < typename Derived >
        managed& reset( Derived* ptr )
        {
                m_ptr_ = ptr;
                m_gen_ = new generator< Derived >( );
                return *this;
        }

        template < typename Derived >
        inline managed& operator = ( Derived* ptr )
        {
                return reset( ptr );
        }
 
        inline managed& operator = ( Type* ptr )
        {
                return reset< Type >( ptr );
        }
       
        managed& reset( managed const& rhs )
        {
                m_ptr_ = rhs.m_gen_->clone( rhs.m_ptr_ );
                m_gen_ = rhs.m_gen_->clone( );
                return *this;
        }

        inline managed& operator = ( managed const& rhs )
        {       
                return reset( rhs );
        }
       
        inline operator Type* ( void )
        {
                return m_ptr_;
        }

        inline operator Type const* ( void ) const
        {
                return m_ptr_;
        }
       
        inline Type* operator -> ( void )
        {
                return m_ptr_;
        }

        inline Type const* operator -> ( void ) const
        {
                return m_ptr_;
        }
 
        protected:

        shallow::managed< generator_base >
                m_gen_;
        shallow::managed< Type >
                m_ptr_;
};

// Example usage
       
#include <iostream>

struct base
{
        virtual void test( void )
        {
                std::cout << "base::test( )" << std::endl;       
        }
};

struct derived : base
{
        virtual void test( void )
        {
                std::cout << "derived::test( )" << std::endl;       
        }
};

int main( void )
{
        managed< base >
                mb1 = new derived( ),
/*
        Fine, pointer to a derived object is constructed
*/               
                mb2( mb1 );
        mb1->test( );
        mb2->test( );
        return 0;       
}

---

EDIT: Fixed minor bug.

EDIT#2: Added minor functionality.

EDIT#3: Streamlined some things.

EDIT#4: Minor bug-fix.

Cool, well I've figured out a much simpler design that eliminates the extra allocation altogether. What do you guys think?

Code:

---




/*
        A simple memory manager.
        Note:
        DO NOT use this to manage dynamically-allocated
        arrays (use std::vector or similar for that)
*/
template < typename Type >
class managed
{
        protected:
       
        struct generator_base
        {
                virtual Type* clone( Type const* ) const = 0;
        };
       
        template < typename Derived >
        struct generator : generator_base
        {
                virtual Type* clone( Type const* ptr ) const
                {
                        return ptr ? new Derived
                        (
                                *static_cast< Derived const* >( ptr )
                        )
                        : 0;
                }
               
                static generator
                        global;
        };

        public:

        managed( Type* ptr = 0 )
        : m_ptr_( 0 )
        {       
                reset( ptr );
        }

        template < typename Derived >
        managed( Derived* ptr )
        : m_ptr_( 0 )
        {       
                reset( ptr );
        }

        managed( managed const& rhs )
        : m_ptr_( 0 )
        {       
                reset( rhs );
        }

        inline managed& reset( Type* ptr = 0 )
        {
                return reset< Type >( ptr );
        }
       
        template < typename Derived >
        inline managed& reset( Derived* ptr )
        {
                internal_reset( ptr );
                m_gen_ = &generator< Derived >::global;
                return *this;
        }

        template < typename Derived >
        inline managed& operator = ( Derived* ptr )
        {
                return reset( ptr );
        }
 
        inline managed& operator = ( Type* ptr )
        {
                return reset< Type >( ptr );
        }
       
        inline managed& reset( managed const& rhs )
        {               
                internal_reset( rhs.m_gen_->clone( rhs.m_ptr_ ) );               
                m_gen_ = rhs.m_gen_;
                return *this;
        }

        inline managed& operator = ( managed const& rhs )
        {       
                return reset( rhs );
        }
       
        inline operator Type* ( void )
        {
                return m_ptr_;
        }

        inline operator Type const* ( void ) const
        {
                return m_ptr_;
        }
       
        inline Type* operator -> ( void )
        {
                return m_ptr_;
        }

        inline Type const* operator -> ( void ) const
        {
                return m_ptr_;
        }

        inline friend bool operator == ( managed< Type > const& lhs, Type const* rhs )
        {
                return lhs.m_ptr_ == rhs;
        }

        inline friend bool operator == ( Type const* lhs, managed< Type > const& rhs )
        {
                return rhs.m_ptr_ == lhs;
        }

        inline friend bool operator != ( managed< Type > const& lhs, Type const* rhs )
        {
                return lhs.m_ptr_ != rhs;
        }

        inline friend bool operator != ( Type const* lhs, managed< Type > const& rhs )
        {
                return rhs.m_ptr_ != lhs;
        }
       
        virtual ~managed( void )
        {
                reset( );
        }
 
        protected:
       
        void internal_reset( Type* ptr )
        {
        /*
                The temporary may be a bit overkill, but it ensures
                that if the 'current' data's destructor throws an
                exception, the 'new' memory will still be cleaned up.
        */       
                Type*
                        saved = m_ptr_;
                m_ptr_ = ptr;
                delete saved;
        }

        Type*
                m_ptr_;
        generator_base*
                m_gen_;
};

template < typename Type >
template < typename Derived >
managed< Type >::generator< Derived >
        managed< Type >::generator< Derived >::global
        = managed< Type >::generator< Derived >( );

// Example usage
       
#include <iostream>

struct base
{
        virtual void test( void )
        {
                std::cout << "base::test( )" << std::endl;       
        }
};

struct derived : base
{
        virtual void test( void )
        {
                std::cout << "derived::test( )" << std::endl;       
        }
};

int main( void )
{
        managed< base >
                mb1 = new derived( ),
/*
        Fine, pointer to a derived object is constructed
*/               
                mb2( mb1 );
        mb1->test( );
        mb2->test( );
        return 0;       
}

---

EDIT: Fixed some really silly bugs. :p

EDIT#2: Minor restructure

EDIT#3: Added comparison operators

Quote:

---

Originally Posted by g4j31a5

@anon: OIC, I thought we can throw anything at anytime. My mistake then. BTW, your code didn;t work. I tried this one though and it worked:

Code:

---

B* A:CreateB(std::string paramStr)
{
    B* pB= NULL;
    try
    {
        pB = new pB (paramStr);
    }
    catch (int result)
    {
          pB = NULL;
    }

    m_VectorB.push_back(pB);
    return pB;
}

B::B(std::string paramStr)
{
    int result = initMembers (paramStr); //returns OK / 1 if successful or FAILED / 0 if failed
    if (result == FAILED)
                  throw result ;
}

---

---

It's not that anon's code "didn't work". It's that his code propagates the exception to the caller of CreateB rather than catching it internally and returning NULL, thus emmulating the behaviour of new (which is a good thing). Your code instead more closely emmulates the behviour of new no-throw. However it also has what is probably a bug, in that it pushes NULL onto the vector!
You also don't need to set pB to NULL in the catch block. If the new statement threw an exception then it hasn't gotten around to assigning anything to pB, thus it will still be NULL.

It is rather cool. Wouldn't the use of a static variable mean though, that this class is automatically not thread-safe, even if I don't visibly share any managed instance between threads?

Now it only remains to find a good use case for it. Treating polymorphic objects as value types? :)

>> It is rather cool.

Thanks!

>> Wouldn't the use of a static variable mean though, that this class is automatically not thread-safe, even if I don't visibly share any managed instance between threads?

Thread-safety isn't an issue here since the static doesn't have any data associated with it. So it should be fine.

>> Now it only remains to find a good use case for it. Treating polymorphic objects as value types?

Hehe, yep, I'm actually trying some things out right now. I can't believe I hadn't thought of this sooner. Funny, the things you figure out on a lazy Saturday afternoon. :p

That seems similar in some ways to MrEdd's valur_ptr, but with move-semantics instead.

Quote:

---

Originally Posted by iMalc

That seems similar in some ways to MrEdd's valur_ptr, but with move-semantics instead.

---

Interesting. I'm still going through his code trying to figure out how it works. :p Cool site, by the way.