Null Object Pattern for STL Types
The first question is, why are you using pointers in the first place here? Allocation with new should only be used when required. Perhaps it is in this case, but I'd rethink your design. Are the errors polymorphic? If so, why? If not, why do you need to use pointers?

Many STL containers use either an error-code approach, that is, they return a std::pair&lt;T, bool&gt;, where the bool represents success/failure, or they deal
directly with iterators, and return an iterator to end() in the case of failure. Depending on the type of m_lstErrors, this could be a possibility (although obviously this won't work for a container adapter like std::stack).  

Though it is not contained in the C++ standard library at the moment (it is slated for inclusion in C++14), std::optional was basically made for this purpose. In fact, it can be written using only C++11 features (and there's a reference implementation you could use here). Boost also contains a boost::optional type, although this lacks things such as move semantics and safe (explicit) bool conversion (although other than that, it is very similar in nature). This would change the code to look like this:

std::optional&lt;std::tuple&lt;tstring, int, tstring&gt;&gt; CCOMErrorHandler::PopError()
{
    typedef std::tuple&lt;tstring, int, tstring&gt; tuple_type;
    std::optional&lt;tuple_type&gt; error;
    if(!m_lstErrors.empty()) {
        error = *m_lstErrors.front();
        m_lstError.pop_front();
    }
    return error;
}


cppreference has an API reference for std::optional. 

As for the complaint about template types, you can always wrap them in another namespace to help prevent pollution:

namespace mynamespace
{
namespace detail
{
    typedef std::tuple&lt;tstring, int, tstring&gt; error_type;
    typedef std::optional&lt;error_type&gt; optional_error;
}

detail::optional_error CCOMErrorHandler::PopError()
{
    //...
}