The whole question of character encoding combined with wide characters
is much more complicated than it would seem to be. The current library
defines in 3 formats (text, binary, and XML), wide and narrow characters,
and attempts to be portable between compiler libraries. The results of
a rather long consideration of all these factors has been to set
default encoding according to the following rules.
All text archives (i.e. text_?archive) will produce
text output in the current stream locale. Generally this will
produce no changes in string data.
To produce binary output with Microsoft compilers, the stream
will have to be opened with mode ios::binary.
Failure to do so will result in 0x0d characters (carriage-return)
characters being removed from the input stream if they are followed
by a 0x0a character (line-feed). This could corrupt the input
and make the file unreadable. On UNIX systems the ios::binary
is not required and is ignored if used.
character XML archives (i.e. xml_oarchive) will produce XML output
with characters encoded according to the current stream locale.
wide character XML archives (i.e. xml_woarchive) will produce
files encoded in UTF-8.
This character encoding is implemented by changing the locale of the
i/o stream used by an archive when the archive is constructed, the stream
locale is changed back to its original value. This action can be overridden
by specifying boost::archive::no_codecvt
when the archive is opened. In this case, the stream locale will
not be changed by the serialization library.
Обратите внимание, что преобразование кода, включаемое в текст с широкими символами и XML-архивы, может изменить<std::string>данные, хранящиеся в архивах. Предположим, что обычная (многобайтная) строка символов записывается в широкий поток символов. Наша система использует ток<locale>, чтобы перевести его на широкую строку символов перед его написанием. После прочтения переводится обратно на (многобайтную) строку. Если<locale>на платформе, которая считывает архив, отличается от<locale>на платформе, которая написала поток, фактические данные строки могут быть изменены процессом сериализации. Чтобы избежать этого, либо избегайте использования<locale>зависимых многобайтовых строк, либо убедитесь, что<locale>установлен правильно перед чтением архива.
Чтобы получить широкий вывод текста символов (т.е. 16 битовых символов в системах Win32), сделайте следующее.
Откройте широкий поток символов.
Изменить поток<locale>, чтобы использовать<boost::archive::codecvt_null<OStream::char_type>>
Создайте архив с флагом<no_codecvt>.
Естественно, процесс ввода должен быть симметричным.
GCC версии для Cygwin и MinGW не поддерживают широкий характер ввода/вывода. Таким образом, все тесты с использованием широкоугольного ввода/вывода терпят неудачу. Обратите внимание, что если с STLPort добавлена широкая поддержка ввода/вывода символов, все тесты успешно завершаются.
Этот компилятор генерирует длинные предупреждающие сообщения, связанные с использованием невиртуальных деструкторов в полиморфных классах. Эти предупреждения были тщательно рассмотрены, и код, который генерирует эти предупреждения, не изменился. В этом случае предупреждение должно быть проигнорировано, так как в некоторых случаях использование библиотеки может привести к проблемам. В качестве альтернативы, деструкторы базового класса были сделаны «защищенными» для решения проблем, которые мотивируют эти предупреждающие сообщения. При построении библиотеки сериализации и тестировании с помощью bjam эти предупреждения подавляются. При создании собственных приложений эти предупреждения можно подавить, добавив в командную строку компилятора следующее:<
Этот компилятор выдает предупреждения для вызовов функций из стандартной библиотеки, которые считаются рисками безопасности. Сериализация зависит от выполнения некоторых из этих вызовов, поэтому программы, использующие библиотеку сериализации, получат предупреждающие сообщения. Эти сообщения могут быть подавлены из командной строки путем включения следующего переключателя:<
Выход из класса архива, определенного в DLL, как описано в ... не будет работать. Это связано с тем, как VC++ обрабатывает шаблонный код с __decl(dllexport) и __decl(dllimport) спецификациями. По сути, этот компилятор требует, чтобы все инстанциации имели одну и ту же спецификацию, даже если они имеют разные аргументы шаблона. Пример<
demo_portable_iarchive.cpp>должен быть переформулирован как библиотека или dll, аналогичная заранее определенным архивам, чтобы функционировать.
Этот компилятор по умолчанию не включает RTTI или обработку исключений. Хотя они не являются строго необходимыми для использования пакета сериализации, примеры и тестовые программы предполагают, что они включены. Поэтому убедитесь, что настройки командной строки или IDE включают эти функции, если вы хотите создавать и запускать эти программы.
Этот компилятор может рассматривать<wchar_t>как либо короткое целое число, либо внутренний тип. Если</Zc:wchar_t>указан в командной строке компиляции,<wchar_t>будет считаться внутренним типом — в противном случае он будет рассматриваться как синоним 16-битного целого числа. Библиотека может быть использована в любом случае -НО- оба librayиприложение должно быть составлено с теми же настройками переключателя. Обратите внимание, что<BJAM>включает этот переключатель по умолчанию. Поэтому, если вы хотите использовать библиотеки, которые<BJAM>создает, вы должны включить этот переключатель при компиляции своих собственных приложений.
Использование Visual C++ IDE
Библиотека содержит VC++ 7.1 «Решение» —<BoostSerializationLibrary>вместе с набором файлов проекта — по одному для каждой демо- и тестовой версии. Рассмотрим следующее, если вы решите использовать эти конфигурации.
Проекты предполагают, что тесты были построены с использованием бьямов по умолчанию. Это приведет к созданию<bin>подкаталога в главном каталоге повышения. Ниже находится целая структура, которая поддерживает объектные и библиотечные файлы в соответствии с типом сборки. Самый простой способ создать это - вызвать скрипт Runtest, который использует bjam (см. Ниже). Если библиотеки не находятся в этих местах, проекты должны быть соответствующим образом изменены.
Существуют конфигурации проектов для всех комбинаций вариантов сборки, которые повышают поддержку. То есть для выпуска, отладки, статического, статического многопоточного и т.д.
Если вы хотите использовать/отлаживать версии библиотек DLL и соответствующие тесты, измените файл проекта, чтобы определить<BOOST_ALL_DYN_LINK=1>. Обратите внимание, что для запуска исполняемых файлов переменная<PATH>окружающей среды должна включать каталоги, содержащие версии DLL библиотек повышения.
Если у вас возникли трудности с созданием собственных проектов и связью с библиотеками бустеров, сравните настройки проектов ваших собственных проектов с теми, которые здесь. VC иногда требует согласованных настроек между проектами и библиотеками, которые они используют для правильной связи. В частности, проверьте поддержку исключений, типизацию во время выполнения (RTTI) и внутреннюю поддержку широких символов. Стандартная версия этой библиотеки предполагает, что эти средства включены. Проекты, созданные мастером IDE, по умолчанию не имеют этих функций.
Часто при попытке построить проект или просмотреть свойства проекта появляется поле с сообщением «неопределенная ошибка». Это происходит, когда меняется выбор конфигурации сборки. Оказывается, это можно «исправить», перейдя в пункт меню «Строить», выбрав «Менеджер конфигурации» и выбрав конфигурацию сборки для проекта, с которым вы работаете.
Чтобы проверить правильность построения бустерных библиотек, можно построить и протестировать их так, как это делаем мы. Это влечет за собой:
загрузку копии bjam.exe
building process_jam_log
building compiler_status
вызов runtest.bat
Это позволит создать библиотеку сериализации и запустить тесты в вашей системе. Если будет больше, чем пара неудачных тестов, вы, вероятно, не сможете заставить работать свои собственные проекты. Если большинство тестов пройдут, вы можете быть уверены, что ваши собственные проекты будут работать, как только вы получите настройки проекта в синхронизации с включенными здесь.
Несколько компиляторов, включая Visual C++ 6.0, используют более старую библиотеку Dinkumware. Эти платформы имеют несколько проблем:
Библиотека dinkumware, поставляемая с этим компилятором, не изменяет локальную грань потока i/o, если только функция<imbue>не вызывается до открытия потока. Чтобы использовать эту библиотеку с этой средой для создания файлов UTF-8, нельзя полагаться на «автоматическую» настройку локализации, которую реализуют архивы. Локальность потока должна быть явно установлена на потоке до того, как на нем откроется архив. Архив должен быть открыт флагом<no_codecvt>. Обратите внимание, что эта проблема будет возникать на всех компиляторах, поставляемых с этой библиотекой.
В архиве были проработаны и другие вопросы.dinkumware.hpp
при построении с использованием динамических связывающих версий кода времени выполнения C++динамика все тесты не удается связать. Это связано с отсутствием символа в библиотеке stlport, связанного с пользовательскими аспектами кодеков.
Тест не работает правильно. Похоже, что итератор хешированных настроек неправильно реализует оператор ++. Это приводит к провалу теста, потребляя всю доступную память. Учитывая это, данный тест комментируется.
