STLPort конструктор неоднозначных копий в VS2008 с классом интеллектуальных указателей

Question

Мы написали класс интеллектуального указателя и с большим успехом используем его во встроенной реализации Visual Studio STL.

Проблема в том, что мы поняли, что наши узкие места в производительности находятся в библиотеке STL в коде, перенесенном из Linux (где STL значительно быстрее, чем мы его используем). Поэтому я пытаюсь связаться с STLPort, чтобы посмотреть, имеет ли он отношение к нашим проблемам с производительностью.

Однако при использовании STLPort 5.2.1 я получаю очень странные ошибки сборки, связанные с неоднозначными конструкторами копирования. Я сократил его до 50-строчной программы C++

#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;
}

Ошибка, которую я получаю от VS2008SP1:

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>
        ]

Я вроде застрял в том, как действовать здесь, кто-нибудь есть какие-либо идеи, что происходит с этим?

Answer 1

Это на самом деле ваш operator& это вызывает двусмысленность. В g++ неоднозначность скорее в разрушении, чем в построении, но я предполагаю, что это аналогичная проблема.

Компилятор пытается взять адрес вашего T, чтобы построить / уничтожить его, и возвращает T** вместо CRefCountPtr<T>*, вызывая замешательство.

Могу поспорить, что вы могли бы создать свой собственный конкретный распределитель, который знает, как с этим справиться (он же не шаблон), и заставить его скомпилировать.

Вероятно, лучше в долгосрочной перспективе, чтобы избавиться от operator& поскольку это только вызовет замешательство.