Почему в Boost :: объединении поддержки структурированных привязок отсутствует адаптация механизма структурированных привязок для boost :: tuples :: cons?

Question

Это не работает из коробки:

std::vector<int> a{1,2,3};
std::vector<int> b{2,3,4};

for (auto [f, s] : boost::combine(a, b)) {
    std::cout << f << ' ' << s << std::endl;
}

Но этот ответ содержит довольно маленький фрагмент кода C ++, который внезапно заставляет это работать.

namespace std {
    template <typename T, typename U>
    struct tuple_size<boost::tuples::cons<T, U>>
        : boost::tuples::length<boost::tuples::cons<T, U>>
    { };

    template <size_t I, typename T, typename U>
    struct tuple_element<I, boost::tuples::cons<T, U>>
        : boost::tuples::element<I, boost::tuples::cons<T, U>>
    { };
}

Автор, однако, советует не использовать его в производстве.

Может ли этот фрагмент создать sh мой код при любых обстоятельствах, или это просто какая-то организационная причина не использовать этот способ для перебора л oop

Answer 1

Может ли этот фрагмент взломать sh мой код при любых обстоятельствах, или это просто какая-то организационная причина не использовать этот способ для перебора l oop?

It может сделать это sh, но то, что он делает, - это указывает на то, что ваш код имеет неопределенное поведение. Вы не «владеете» бустом, поэтому не диктуете, что может обеспечить специализация вещей в стандартном бусте. Если в какой-то момент в будущем повышение решит добавить эту поддержку, что вполне может произойти, то теперь у вас есть два определения tuple_size и tuple_element, что является нарушением ODR. Мало того, что это неопределенное поведение, но и не требуется диагностика c, так что вы можете даже не знать, что что-то не так, пока это не проявится каким-то странным и неясным способом.

Answer 2

Может ли этот фрагмент взломать sh мой код при любых обстоятельствах, или это просто какая-то организационная причина не использовать этот способ для перебора l oop?

Если Обновление для повышения добавляет такие специализации, ваша программа может внезапно сломаться

Вероятный сценарий состоит в том, что boost добавляет эквивалентно специализированные специализации, а поломка - ошибка времени компиляции.

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

[temp.class.spec] / 1

Частичная специализация должна быть объявлено перед первым использованием специализации шаблона класса, которая будет использовать частичную специализацию в результате неявного или явного создания экземпляра в каждой единице перевода , в которой происходит такое использование; Диагностика не требуется c.

(выделено)