Почему boost включает две разные версии strong_typedef.hpp?

Поскольку я недавно создавал проект, я заметил, что я получил предупреждение компилятора (обращено к ошибке) о переопределении макроса BOOST_STRONG_TYPEDEF. При дальнейшем исследовании я заметил, что в boost есть две разные версии strong_typedef.hpp: один на верхнем уровне и один внутри serialization/.

На самом деле существует разница между двумя версиями, а не только дублирующаяся версия макроса. В версии верхнего уровня явно не указано значение-init T, в то время как версия сериализации:

Сокращения кода:

boost/strong_typedef.hpp:

    T t;                                                        \
    explicit D(const T t_) : t(t_) {};                          \
    D(){};                                                      \
    D(const D & t_) : t(t_.t){}                                 \

boost/serialization/strong_typedef.hpp:

    T t;                                                        \
    explicit D(const T t_) : t(t_) {};                          \
    D(): t() {};                                                \
    D(const D & t_) : t(t_.t){}                                 \

Почему существуют две разные версии макроса, и какая из них имеет смысл в качестве реализации? Тот, который будет принудительно инициализироваться встроенными типами, или тот, который этого не делает (насколько это возможно, мимируя, чтобы базовый тип был сильно типизирован)?

Ответ 1

Похоже, что каталог boost/strong_typedef.hpp - это исторический артефакт.

Отсутствие явной инициализации члена t было ошибкой, зафиксированной в boost/serialization/strong_typedef.hpp пару лет назад в редакции 71183. svn. См. билет ошибки.

В Boost Subversion trunk boost/strong_typedef.hpp в основном пустой файл, в котором говорится:

#error "This header is deprecated. Please use: boost/serialization/strong_typedef.hpp"

Это изменение, r48575, было сделано еще в 2008 году - я не знаю, почему он никогда не сливался в выпуск. Может быть, потому что это сломает пользователей без большого роста или, может быть, надзора. Это же изменение (r48575) было тем, что создало boost/serialization/strong_typedef.hpp в стволе.

Если они не хотят разорвать существующих пользователей, то, возможно, устаревший файл должен просто включать файл в boost/serialization, чтобы там была единственная каноническая реализация. В любом случае, казалось бы, если вы можете избежать использования boost/strong_typedef.hpp в пользу использования одного в serialization, то я бы предложил.

В качестве примечания обратите внимание, что год назад автор Boost Serialization (и strong_typedef.hpp), Bob Ramey, опубликовал комментарий в другом битовом билете около strong_typedef.hpp, что может показаться вам интересным:

Я не думаю, что библиотека сериализации использует это больше. Конечно, он все еще там. Я понятия не имею, использует ли кто-нибудь его.

Ответ 2

Я являюсь автором обеих версий boost/strong_typedef.hpp.

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

Я просто посмотрел на библиотеку сериализации, и использование strong_typedef теперь минимально. Я догадываюсь, что я полностью его удалю. Тогда он полностью исчезнет.

Это действительно должна быть отдельная утилита. Но я не могу справиться со всем этим требованием (тесты, документы, сборка, просмотр). И у boost нет хорошего места для этих небольших утилит. Однажды я надеялся, что эти небольшие утилит, которые мне нужны для библиотеки сериализации, перейдут на базу повышения. Но я был обескуражен этой идеей.