c ++ 0x std :: shared_ptr против boost :: shared_ptr - PullRequest
Новая
       5

c ++ 0x std :: shared_ptr против boost :: shared_ptr

8 голосов
/ 04 июля 2011

У меня есть код C ++, который интенсивно использует shared_ptr и STL. Общий заголовок гласит 

#include<boost/shared_ptr.hpp>
using boost::shared_ptr;  // for shared_ptr
using namespace std;      // for STL

Я хотел перейти на c ++ 0x, чтобы использовать языковые функции, используя gcc 4.6 с -std=c++0x. Однако теперь существует std::shared_ptr, что приводит к неоднозначности для неопределенных shared_ptr (boost::shared_ptr против std::shared_ptr).

При переключении на std::shared_ptr вместо этого, вот так: 

#include<memory>
using namespace std;      // for STL; also imports std::shared_ptr

тогда у меня проблемы с boost::python, который работает только с boost::shared_ptr (по крайней мере, без дальнейших действий): 

/usr/include/boost/python/object/make_ptr_instance.hpp:30:52: error: no matching function for call to 'get_pointer(const std::shared_ptr<Cell>&)'

Поэтому мой вопрос

  • , если существует простое решение для устранения неоднозначности между boost::shared_ptr и std::shared_ptr (кроме использования c ++ 0x на данный момент), а также
  • если boost::shared_ptr в конечном итоге будет просто псевдонимом для std::shared_ptr; это решило бы мою проблему автоматически.

Спасибо!

1 Ответ

2 голосов
/ 04 июля 2011

Вам необходимо определить автономную функцию 'get_pointer' для вашего класса общего указателя, чтобы он работал с Boost Python. (обратите внимание, что это позволяет вам написать собственный разделяемый указатель и по-прежнему работать с Boost Python: это сознательное проектное усилие по предотвращению тесного связывания различных библиотек Boost) .

Вы можете получить это, используя заголовки совместимости boost tr1, но я не пробовал.

http://boost.cowic.de/rc/pdf/tr1.pdf

Когда Boost.TR1 сконфигурирован для использования собственной реализации TR1 вашей стандартной библиотеки, тогда он мало что делает: просто включает соответствующий заголовок.

Когда Boost.TR1 использует реализацию Boost конкретного компонента, он включает в себя соответствующие заголовки (и) Boost и импортирует необходимые объявления в пространстве имен std :: tr1 с помощью объявлений. Обратите внимание, что только те объявления, которые являются частью стандарта импортируются: реализация намеренно довольно строгая, чтобы не включать какие-либо специфичные для Boost расширения в Пространство имен std :: tr1, чтобы отследить любые ошибки переносимости в пользовательском коде. Если вам действительно нужно использовать специфичные для Boost расширения, Вы должны включить заголовки Boost напрямую и вместо этого использовать объявления в пространстве имен boost ::. Обратите внимание, что этот стиль реализации не полностью соответствует стандартам, в частности, невозможно добавить пользовательские шаблоны специализаций Компоненты TR1 в пространство имен std :: tr1. Есть также одна или две библиотеки Boost, которые еще не полностью соответствуют стандартам, любые такие несоответствия документируются в TR1 по предметному разделу. Надеемся, что случаи нестандартного поведения должны однако на практике быть крайне редким.

Если вы используете стандартный соответствующий заголовок включает (в boost / tr1 / tr1), то эти имена заголовков могут иногда конфликтовать с существующими заголовки стандартной библиотеки (например, shared_ptr добавляется в существующий заголовок стандартной библиотеки, а не собственный заголовок). Эти заголовки перенаправляются в существующий заголовок стандартной библиотеки одним из двух способов: для gcc он использует #include_next, а для других компиляторов он использует макрос BOOST_TR1_STD_HEADER (заголовок) (определенный в boost / tr1 / detail / config.hpp), который оценивает #include <../ include / header>. Это должно работать "прямо из коробки" для большинства компиляторов, но это означает, что они Заголовки никогда не должны помещаться в каталог с именем «include», который уже находится в пути поиска вашего компилятора.

...