Состояние строки при преобразовании кодировок при помощи libiconv в рамках codecvt.
Добрый день.
Прошу прощения, если тема уже поднималась... Искал, не нашел.
Я пишу миленький такой велосипед: фасет локали C++ с поддержкой перекодировки символов. При том перекодировка должна происходить с использованием libiconv.
Более того, предполагается реальным использование символьных наборов с символами не постоянной длинны (естественно, в качестве внешней кодировки). Как следствие должно использоваться смещение в строке (state_type aka mbstate_t).
При том фасет сей должен будет работать с несколькими строками одновременно (это уже заложено в системе и перестройка ее крайне не желательна).
Возможны следующие варианты:
(0) При каждом обращении к фасету создавать новый дескриптор преобразования libiconv. При этом мы вообще не нуждаемся в его хранении. Но при этом мы не сможем отслеживать смещения в внешнем представлении.
(1) Хранить дескриптор, непосредственно в фасете (однако, это может привести к нарушению смещений в строке во внешней кодировке, ибо при первом обращении будет преобразована одна строка, а при втором обращении будет начата работа с другой строкой, но сдвиг останется прежним).
(2) Хранить дескриптор в поле имеющегося типа mbstate_t. Однако, это уж совсем коряво, ибо тип этот зависит от реализации. И тогда единственный способ его использовать, это побитовая запись в него информации в обход системы контроля типов.
(3) Реализовать свой тип символов. Реализовать для него std::char_traits, в котором будет определяться подходящий state_type. Реализовать фасет на основе этого символа типов. Это пожалуй самый "правильный" вариант, но во первых это вызовет трудности при работе со строками встроенных типов, а во-вторых это слишком сложно для реализации.
В стандартах (C, C++) я не нашел никаких упоминаний о минимальных требованиях к mbstate_t. Т.е. это черный ящик. Вариант (2) можно было бы, скрепя сердцем, реализовать если бы хотя бы гарантировалось, что в любой системе sizeof(mbstate_t) >= sizeof(void*).
Вопрос собственно такой: может ли мне кто что-нибудь путное порекомендовать? Может я чего-то упустил...
Заранее спасибо.
Прошу прощения, если тема уже поднималась... Искал, не нашел.
Я пишу миленький такой велосипед: фасет локали C++ с поддержкой перекодировки символов. При том перекодировка должна происходить с использованием libiconv.
Более того, предполагается реальным использование символьных наборов с символами не постоянной длинны (естественно, в качестве внешней кодировки). Как следствие должно использоваться смещение в строке (state_type aka mbstate_t).
При том фасет сей должен будет работать с несколькими строками одновременно (это уже заложено в системе и перестройка ее крайне не желательна).
Возможны следующие варианты:
(0) При каждом обращении к фасету создавать новый дескриптор преобразования libiconv. При этом мы вообще не нуждаемся в его хранении. Но при этом мы не сможем отслеживать смещения в внешнем представлении.
(1) Хранить дескриптор, непосредственно в фасете (однако, это может привести к нарушению смещений в строке во внешней кодировке, ибо при первом обращении будет преобразована одна строка, а при втором обращении будет начата работа с другой строкой, но сдвиг останется прежним).
(2) Хранить дескриптор в поле имеющегося типа mbstate_t. Однако, это уж совсем коряво, ибо тип этот зависит от реализации. И тогда единственный способ его использовать, это побитовая запись в него информации в обход системы контроля типов.
(3) Реализовать свой тип символов. Реализовать для него std::char_traits, в котором будет определяться подходящий state_type. Реализовать фасет на основе этого символа типов. Это пожалуй самый "правильный" вариант, но во первых это вызовет трудности при работе со строками встроенных типов, а во-вторых это слишком сложно для реализации.
В стандартах (C, C++) я не нашел никаких упоминаний о минимальных требованиях к mbstate_t. Т.е. это черный ящик. Вариант (2) можно было бы, скрепя сердцем, реализовать если бы хотя бы гарантировалось, что в любой системе sizeof(mbstate_t) >= sizeof(void*).
Вопрос собственно такой: может ли мне кто что-нибудь путное порекомендовать? Может я чего-то упустил...
Заранее спасибо.