STLPort ambiguous copy constructor in VS2008 with smart pointer class

Question

We've written a smart pointer class and have been using it with great success with the built-in Visual Studio STL implementation.

The problem is we've realized our performance bottlenecks are in the STL library in code ported from Linux (where the STL is significantly faster the way we're using it). So I'm trying to link in STLPort to see if it deals with our performance problems.

When using STLPort 5.2.1 however I get very strange build errors related to ambigous copy constructors. I've stripped it down to a 50 line C++ program

#include "stdafx.h"
#include <set>

using namespace std;

template<class T>
class CRefCountPtr
{
public:
    CRefCountPtr(T* pT) : m_T(pT)
    {
    }

    T** operator&()
    {
        return &m_T;
    }

    operator T*() const
    {
        return (T*)m_T;
    }

    bool operator< (T* pT) const
    {
        return m_T < pT;
    }

    T* m_T;
};

class Example
{
    int example;
};


int _tmain(int argc, _TCHAR* argv[])
{

    set< CRefCountPtr<Example> > blah;
    Example ex;
    blah.insert(&ex);

    return 0;
}

The error I get back from VS2008SP1 is

stlport\stl\_tree.h(318) : error C2782: 'void stlp_std::_Copy_Construct(_Tp *,const _Tp &)' : template parameter '_Tp' is ambiguous
        stlport\stl\_construct.h(130) : see declaration of 'stlp_std::_Copy_Construct'
        could be 'CRefCountPtr<T>'
        with
        [
            T=Example
        ]
        or       'Example *'
        .....
        stlport_example.cpp(43) : see reference to class template instantiation 'stlp_std::set<_Key>' being compiled
        with
        [
            _Key=CRefCountPtr<Example>
        ]

I'm kind of stuck at how to proceed here, anybody have any idea what's going on with this one?

Answer 1

It's actually your operator& that's causing ambiguity. In g++ the ambiguity is in destruct rather than construct but I assume it's a similar problem.

The compiler tries to take the address of your T to construct/destruct it, and gets back a T** instead of a CRefCountPtr<T>* , causing confusion.

I bet you could create your own specific allocator that knows how to deal with this (aka not a template) and get it to compile.

Probably better long term is to get rid of the operator& as it'll only cause confusion.