Преамбула:
Я программировал в основном на Windows последние 20 лет.За это время я разработал обширные механизмы преобразования строк, ведения журналов и отчетов об исключениях, которые полагаются на Windows API для средств преобразования строк utf-16le и базовые службы ввода-вывода для захвата контекста исключений во время выполнения для отладки, ведения журнала, создания отчетов и т. Д.
Мне пришлось просто сделать выбор, когда мы какое-то время назад обратились к собственному коду Windows utf-16le, чтобы изменить большинство этих фундаментальных сервисов, чтобы выразить их все в основах wchar_t (или std :: wstring, который является utf-16le на винде).Я говорю «пришлось», потому что все это довольно хорошо сочетается - достигается высокая степень согласованности между самим WinAPI, файловым вводом / выводом и консольным вводом / выводом, и все они могут работать хорошо в utf-16le.
Windows обеспечивает узкий строковый ввод / вывод и поддержку текущей кодовой страницы - но это никогда не работает так же хорошо, как хранение всего в utf-16le, который затем переносится на различные системы и остается согласованным - ничего не теряется в транскрипции."
Цели:
Я пытаюсь обобщить свои библиотеки, но я сбит с толку этим фундаментальным несоответствием между тем, что было легко (э) в Windows: использование wstring для всехданные журналов и исключений, которые гарантируют, что мои записи трассировки и ошибки, которые содержат строки, зависящие от локали (например, имена файлов, специфичные для локали или элементы с именами пользователей), остаются в своих собственных строках и не страдают от деградации при загрузке в моей английской системе - противLinux-системы, которые предпочитают utf-8 в качестве основной строковой кодировки, которая часто болееmpact - но который очень трудно заставить работать для приложений на базе Windows (это сложная тема - но достаточно сказать, что Windows не поддерживает должным образом utf-8 для консольного ввода-вывода или любого другого файлового ввода-вывода ивам все равно придется постоянно преобразовывать в utf-16le для вызовов WinAPI - что для приложений на основе графического интерфейса - абсолютно постоянно - так что проще выбрать utf-16le в качестве «стандартного» строкового типа и построить изтам).
Тем не менее, я хотел бы иметь отличный дружественный для программистов набор классов исключений, которые захватывают контекст таким же «естественным» и удобным для программиста c ++ как на Unix, так и наWindows.
Так что это создает некоторые трудные для ответа вопросы, тем более что мне не хватает знаний по программированию на c ++ для Linux:
Вопросы:
- Предоставляю ли я базовые данные?классы исключений, которые всегда перехватывают utf-16le в Windows, но utf-8 в Unix?
- Как конвертировать между API, которые позволяютстроковый тип (ну, технически, я бы хотел предоставить std :: string и std :: wstring - это может быть utf-16le или utf-32 в Windows против Linux).
Дополнительные соображения:
Для # 2 я вижу, что тело стандартов c ++ 11 создало std::wstring_convert<std::codecvt_utf8_utf16<char16_t>>, но устарело для c ++ 17.
Я, конечно, мог полагаться на API Windows при компиляциидля этой платформы, но я действительно хочу что-то столь же фундаментальное, как иерархия классов исключений - вся цель которой состоит в том, чтобы облегчить захват контекста времени выполнения для программиста - чтобы он опирался на нативные сервисы.Я действительно хочу, чтобы эта базовая часть моей библиотеки опиралась только на библиотечные сервисы C ++ std - я бы предпочел избегать библиотечных сервисов времени выполнения C (примечание: я не против, если библиотека std зависит от времени выполнения C под капотом).- это не имеет отношения к моим проблемам и будет проблемой для конкретной платформы, а не для зависимости, созданной моей библиотекой).
Итак, мне любопытно, что другие профессионалы C ++, имеющие больше опыта работы с Linux иСистемы, основанные на Mac OS, полагают, что легче всего совместить собственное удобство написания исключения и возможность легко захватывать и обрабатывать файлы трассировки и журналов или другие диагностические операции ввода-вывода?
Исправление: C ++ 11 введенконвертер и C ++ 17 устарели.