Потому что implementation
как раз для этого: он говорит, что ProjectA необходим для того, чтобы код ProjectB работал (внутренне), но не является частью его API (т.е. вы не хотите, чтобы клиенты ProjectB полагались на факт, что он использует ProjectA внутри).
Если вы хотите, чтобы ProjectA был частью API или ProjectB, используйте конфигурацию api
, а не реализацию.
См. руководство для более подробной информации.
В C++ 0x, char16_t
и char32_t
будет использоваться для хранения UTF-16 и UTF-32 и нет wchar_t
.
Из проекта n2798:
22.2.1.4 Шаблон класса codecvt
2 класс codecvt для использования при преобразовании от одного кодового набора до другого, такой как от широких символов до многобайтовых символов или между расширенными кодировками символов, такими как Unicode и EUC.
3 специализации, требуемые в Таблице 76 (22.1.1.1.1), преобразовывают реализацию - определенный собственный набор символов. codecvt реализует вырожденное преобразование; это не преобразовывает вообще. Специализация
codecvt<char16_t, char, mbstate_t>
преобразовывает между UTF-16 и схемами кодировок UTF-8 и специализациейcodecvt <char32_t, char, mbstate_t>
преобразовывает между схемами кодировок UTF-8 и UTF-32.codecvt<wchar_t,char,mbstate_t>
преобразовывает между собственными наборами символов для узких и широких символов. Специализации наmbstate_t
выполните преобразование между кодировкой, известной конструктору библиотеки.Другая кодировка может быть преобразована путем специализации на пользовательском типе stateT. Объект stateT может содержать любое состояние, которое полезно для передачи с или от специализированного do_in или do_out участников.
Вещь о wchar_t
это, это не дает Вам гарантий об используемом кодировании. Это - тип, который может содержать многобайтовый символ. Период. Если Вы собираетесь записать программное обеспечение теперь, необходимо жить с этим компромиссом. C++ 0x совместимые компиляторы является все же большой разницей. Можно всегда давать VC2010 CTP и g ++ компиляторы попытка если это имеет значение. Кроме того, wchar_t
имеет различные размеры на различных платформах, который является другой вещью не упустить (2 байта на VS/Windows, 4 байта на GCC/Mac и так далее). Существуют затем опции как -fshort-wchar
чтобы GCC далее усложнил проблему.
Лучшее решение поэтому состоит в том, чтобы пользоваться существующей библиотекой. Преследование ошибок UNICODE вокруг не является самым лучшим использованием усилия/времени. Я предложил бы, чтобы Вы смотрели на:
Больше на C++ 0x строковые литералы Unicode здесь
Спасибо dirkgently. Я еще не регистрируюсь, таким образом, я не могу upvote или отвечать непосредственно как комментарий.
Я изучил что-то с codecvt. Я знал о библиотеках, которые Вы предлагаете, и следующим ресурсом может также быть полезный http://www.unicode.org/Public/PROGRAMS/CVTUTF/.
Проект для библиотеки, которая должна быть открытым исходным кодом. Я предпочел бы минимизировать зависимости с внешними библиотеками. У меня уже есть зависимость с libgc и повышением, хотя для позже я только использую потоки. Я действительно предпочел бы придерживаться стандарта C++, и я немного разочарован, что поддерживаемый GC был так или иначе отброшен.
По-видимому, VC ++ выражает 2008, как, говорят, поддерживает большую часть C++ 0x стандарт, а также ICC. Так как я в настоящее время разрабатываю с VC ++, и он все еще займет время, пока библиотека не была бы выпущена, я хотел бы дать попытку использовать строки char32_t и codecvt.
Кто-либо знает, как сделать это? Я должен отправить другой вопрос?