C++ inheritence for on-stack objects

Question

I have a base class, Token. It has no implementation and as such acts as a marker interface. This is the type that will be used by callers.

{
    Token t = startJob(jobId);
    // ... (tasks)
    // t falls out of scope, destructors are called
}

I have a derived class, LockToken. It wraps around a mutex and insures the lock is acquired during construction and released during destruction. The startJob method is a factory method in the sense that it decides whether to return a Token (providing no locking) or a LockToken (providing locking).

Token startJob(int jobId)
{
    return (jobId>0) ? LockToken() : Token() ;
}

When startJob would return a base instance (a Token), everything works well. In the other case (jobId>0), there is a copy made of the derived instance to the base instance. In other workds, a different Token is copy-constructed from the LockToken and the original LockToken falls out of scope too soon, releasing the lock inside the scope of startJob.

How do I get out of this? Can I change startJob so that it returns or outputs a truly covariant Token (meaning it may be a LockToken)?

Answer 1

You should return a pointer from startJob() - either a raw pointer or a suitable smart pointer. For example:

Token* startJob(int jobId) 
{ 
    return (jobId>0) ? new LockToken() : new Token(); 
} 

{ 
    std::auto_ptr<Token> t = startJob(jobId); 
    // ... (tasks) 
    // t falls out of scope, destructors are called 
}

When auto_ptr goes out of scope it calls delete on the wrapped pointer.

The above solution is a direct rewrite of yours. As mentioned in another answer to this question you don't need the dummy Token class at all - you can just return a null pointer:

LockToken* startJob(int jobId) 
{ 
    return (jobId>0) ? new LockToken() : 0; 
} 

{ 
    std::auto_ptr<LockToken> t = startJob(jobId); 
    // ... (tasks) 
    // t falls out of scope, destructors are called 
}

auto_ptr can be safely assigned a null pointer - it's destructor will handle this.

Answer 2

One fairly typical approach would be to declare your Token / LockToken objects on the heap using pointers.

Token* startJob(int jobID)
{
    Token* t;
    if (jobID >0)
    {
        t = new LockToken();
    }
    else
    {
        t = new Token();
    }

    return t;
}

Of course, then you have to be responsible for deleting the returned value when you're done with it. Alternatively, you could use smart pointers, which manage their own destruction.

Answer 3

You are returning a Token by value. That means that you are not returning a LockToken, but rather a Token copy constructed from your LockToken instance.

A much better approach would be to use boost::shared_ptr. That way your clients can copy things around without needing to worry about deletion. Something like this:

#include <boost/shared_ptr.hpp>

typedef boost::shared_ptr<void> Token;

Token startJob(int jobId)
{
    if (jobId < 1) return shared_ptr<void>();
    return shared_ptr<void>(new LockToken);
}

void use_it()
{
    Token t = startJob(jobId);
    // ....
    // Destructors are called
}

Note that you no longer need a Token class that does nothing, and the LockToken class is now an implementation detail that is entirely hidden from clients, giving you scope for doing all kinds of other things when the Token goes out of scope.

Answer 4

In C++, to get polymophic behavior you need to use either pointers or references. In your particular case, as the lifetime of the Token must expand beyond the function startJob you cannot return a reference into an internal stack allocated object, since at the place of use (caller of startJob) it would be a dangling reference.

So you are left with dynamically allocated memory, and at this point you can choose how you want to deal with the heap allocated object lifetime. I would advise against using raw pointers as they are inherently exception unsafe, there are already different fine answers using raw pointers as return value and managing the pointer inside a smart pointer, or already returning an smart pointer.

The disadvantage of returning a raw pointer and externally managing it in a smart pointer is that it is a little more fragile for user code. The caller can use smart pointers, or can use raw pointers (or ignore the returned object) and it will loose memory. Using a shared_ptr in your user interface imposes the use of that smart pointer in caller code (the user cannot decide to change to another smart pointer type).

Using a good old std::auto_ptr as return type seems like the most flexible approach at this point:

std::auto_ptr<Token> startJob( int jobId );

void user_code()
{
   std::auto_ptr<Token> job1 = startJob(1);
   boost::shared_ptr<Token> job2( startJob(2) ); // shared_ptr has a constructor taking auto_ptr
   startJob(3); // fine: the temporary auto_ptr dies and releases the memory
   boost::scoped_ptr<Token> job4( startJob(4).release() ); // cumbersome, but feasible
}

(scoped_ptr reference)

If the returned type was another type of smart pointer as the return type, then you would not be able to make it yield the resource to use in another type of smart pointer. If you returned a raw pointer job 3 token will not be released.

I have not considered unique_ptr for the discussion. It seems as a good alternative to auto_ptr, but I have never used it so I cannot tell from experience.

Answer 5

Thanks for all the replies! I have chosen to go with janm's solution with the exception that I will be using a std::auto_ptr instead of a boost::shared_ptr. Note that this makes the solution also similar to sharptooth's answer (with Matthieu M's comment). I have prototyped it and also integrated it with the rest of the application and am happy to report that it works well.