C++ std :: tuple порядок уничтожения

Question

Есть ли правило, в котором указано, в каком порядке уничтожены члены std :: tuple?

Например, если Function1 возвращает std::tuple<std::unique_ptr<ClassA>, std::unique_ptr<ClassB>> к Function2, то можно быть уверенным, что (когда объем Function2 находится слева) экземпляр ClassB, упомянутые во втором элементе разрушается до экземпляра ClassA, на которые ссылаются первый член?

std::tuple< std::unique_ptr<ClassA>, std::unique_ptr<ClassB> > Function1() 
{ 
    std::tuple< std::unique_ptr<ClassA>, std::unique_ptr<ClassB> > garbage; 
    get<0>(garbage).reset(/* ... */); 
    get<1>(garbage).reset(/* ... */); 
    return garbage; 
} 

void Function2() 
{ 
    auto to_be_destroyed = Function1(); 
    // ... do something else 

    // to_be_destroyed leaves scope 
    // Is the instance of ClassB destroyed before the instance of ClassA? 
} 

Answer 1

В стандарте не указывается порядок разрушения для std::tuple. Тот факт, что §20.4.1/p1 указывает, что:

Конкретизация кортеж с двумя аргументами похожа на конкретизации пары с теми же двумя аргументами.

Подобные здесь не интерпретируется как идентичного и, следовательно, это не подразумевает, что std::tuple должна иметь порядок обратного уничтожения своих аргументов.

Учитывая рекурсивный характер std::tuple, наиболее вероятным является то, что порядок разрушения упорядочен с порядком его аргументов.

Я также основываю свои предположения на отчете об ошибке для GCC BUG 66699, где в обсуждении мои предположения выше оправданы.

Таким образом, порядок уничтожения для std::tuple не указан.

Answer 2

С Clang 3.4 я получаю тот же порядок уничтожения для обоих std::pair и 2 элемента std::tuple и с г ++ 5.3 я получаю противоположный порядок, который может быть в основном за счет рекурсивной реализации std::tuple в libstd ++.

Итак, это в основном сводится к тому, что я сказал в комментарии, это реализация определена.

Из отчета о BUG:

Комментарий от Martin Sebor

Поскольку расположение элементов стандов :: паров полностью определен, поэтому является порядком их инициализации и уничтожения. Результат этого теста отражает этот порядок.

Порядок инициализации (и уничтожения) субобъектов std: stup менее четко определен. По крайней мере, это не сразу видно из моего чтения спецификации, если требуется какой-либо конкретный заказ.

Причины, почему выход для станд :: кортежа с libstdC++ обратная из станд :: пара, потому что реализация, которая опирается на рекурсивном наследования, магазины и конструкции кортежа элементов в обратном порядке: т.е. базовый класс, в котором хранится последний элемент, хранится и строится первым, за которым следует каждый производный класс (каждый из которых хранит последний - N-й элемент).

цитата из стандартного [раздела 20.4.1] которой ошибка репортер со ссылкой на

1 В этом подразделе описана библиотека кортежа, который обеспечивает кортеж типа в качестве шаблона класса кортежа, который может быть экземпляр с любым количеством аргументов . Каждый аргумент шаблона указывает тип элемента в кортеже. Следовательно, кортежи неоднородны, коллекции значений фиксированного размера. Репликация кортежа с двумя аргументами похожа на экземпляр пары с теми же двумя аргументами . См. 20.3.

Аргумент против этого сделано в связанном баге:

описывается как похоже, не означает, что они идентичны во всех деталях. std :: pair и std :: tuple - это разные классы с различными требованиями к каждому.Если вы считаете, что необходимо вести себя точно в этом отношении (т. Е. Иметь свои подобъекты, определенные в , в том же порядке), вам необходимо указать на определенную формулировку, которую это гарантирует .

Answer 3

Я предложу жизненный урок я узнал, а не прямой ответ, в ответ на ваш вопрос:

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

В контексте кортежей - пожалуйста, будьте любезны для людей, поддерживающих ваш код, и не позволяйте порядку уничтожения элементов кортежа потенциально испортить уничтожение других элементов. Это просто зло ... представьте себе несчастного программиста, которому нужно будет отлаживать эту вещь. Фактически, эта бедная душа может быть собой через несколько лет, когда вы уже забыли о своем умном уловке извне в день.

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