Почему 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 нет хорошего места для этих небольших утилит. Однажды я надеялся, что эти небольшие утилит, которые мне нужны для библиотеки сериализации, перейдут на базу повышения. Но я был обескуражен этой идеей.