Смешивание multi_array boost и необязательно с C++ 11 unique_ptr не работает

Я собрал передовую установку с G++ 4.7 (хотя на данный момент я все еще использую boost 1.48, поставляемый с sudo apt-get boost-all-dev на Debian Wheezy).

Мой код настроен таким образом, что используемая логическая структура данных представляет собой многомерные массивы unique_ptr. Но multi_array, похоже, не может построить даже пустой одноэлементный массив, если в нем есть unique_ptr. Таким образом, это работает:

boost::multi_array<int, 1> arrWorks (boost::extents[1]);

Но это не так:

boost::multi_array< unique_ptr<int>, 1> arrFails (boost::extents[1]);

Я предполагаю, что соответствующая жалоба от компилятора:

/usr/include/c++/4.7/bits/stl_uninitialized.h:225: требуется от ‘void std::uninitialized_fill_n(_ForwardIterator, _Size, const _Tp&) [с _ForwardIterator = std::unique_ptr*; _Size = целое число без знака; _Tp = std::unique_ptr]’

У меня тоже проблемы с optional< unique_ptr<...> >, хотя я применил предложенный здесь патч:

https://svn.boost.org/trac/boost/ticket/1841

(Примечание: найдено через Можно ли переместить boost::Optional ? )

Так, например:

boost::optional< unique_ptr<int> > optWorks (new int);

// Fails
boost::optional< unique_ptr<int> > optFails (std::move(optWorks));

Я чувствую, что то, что я делаю, законно. На самом деле я уже нашел несколько ошибок с точки зрения семантики передачи права собственности, включив в этот проект unique_ptr. Так что мне не хотелось бы говорить "о, это слишком сложно, просто используйте необработанные указатели".

Это что-то в повестке дня Boost для поддержки? Есть ли сроки для этого? Есть ли какие-нибудь простые обходные пути, которые я могу использовать?


person HostileFork says dont trust SE    schedule 17.06.2012    source источник
comment
Зачем вам необязательный unique_ptr? Просто введите туда NULL. Вот как вы делаете необязательные с указателями; вы используете NULL.   -  person Nicol Bolas    schedule 18.06.2012
comment
@NicolBolas Что касается указания контрактов интерфейса ... Я предпочитаю использовать необязательное для указателей, которые действительно являются необязательными, потому что их тип может быть проверен во время компиляции как отличающийся от подпрограмм, чем ожидается значение указателя. Использование null не предлагает этого, и нулевой указатель может даже иметь другое семантическое значение. Кроме того, это может быть optional< vector< unique_ptr<int> > и иметь ту же проблему при использовании std::move для создания необязательного (и по аналогичным причинам я не думаю, что вектор нулевой длины является хорошей заменой для необязательного вектора... )   -  person HostileFork says dont trust SE    schedule 18.06.2012
comment
Вот интересный разговор об использовании необязательных типов указателей. . Они не упоминают технику, которую я использую для документирования подпрограмм, которые возвращают необработанные указатели, которые могут быть нулевыми, то есть заканчивать имя метода на MaybeNull. (getWidgetMaybeNull подсказывает исходному кодировщику и последующим читателям о необходимой обработке, которой не будет в простом комментарии к getWidget). В любом случае, на самом деле это multi_array, который сейчас больше всего мешает шоу... но я полагаю, что необязательную проблему легче исправить. :-/   -  person HostileFork says dont trust SE    schedule 18.06.2012
comment
Я думаю, что это будет решено, когда поддержка MultiArray и Optinal переместится. Я не думаю, что это сложно, хотя я думаю, что нужно сломать некоторое (всегда странное) поведение MultiArray.   -  person alfC    schedule 10.01.2015