Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Общие вопросы > ANSI и Unicode

Автор: Любитель 23.9.2006, 10:49

Хотелось бы узнать ваше мнение, как лучше реализовать выбор между Анси и Юникодом в библиотеке, не предназначенной конкретно для работы со строками.

Имеем как минимум три классических решения:

Шаблоны и их специализации. Так поступает в частности стандартная библиотека C++, многие бустовские библиотеки.
Недостатки:
- невозможность нормального отделения интерфейса от реализации (export практически не один компилер не поддерживает на сегодня). Все остальные недостатки - в какой-то мере следствия этого.
- невозможность распространения библиотеки без исходного кода.
- увеличение времени компиляции
  Преимущества:
- классика
Макросы и игры с препроцессором (по выбору платформы). Так поступает, например MFC. Главных недостатков два: некрасиво выглядит (ИМХО) и засоряет всё препроцесерными определениями. Это ужасно мешает во многих сулчаях.
Отказ от одной из реализаций. От юникода ныне отказываться неразумно, поэтому выбираем его. Примеры: COM, Qt. Замечу, что Java и .Net также не реализуют Анси, ничего - все довольны.

Лично мне больше всего нравиться развитие полседнего варианта. Развитие заключается в использовании класса строк, коснтруирующегося из std::string и std::wstring, а также поддерживающего преобразование к std::string (с учётом локали, по дефолту - текущей) и std::wstring. Вероятно, наследник std::wstring. Для большей радости можно добавить шаблонные конструкторы из basic_string - для других char_trits или аллокаторов.

Автор: Daevaorn 23.9.2006, 11:10

Любитель,
2-ой вариант

Код


#if defined( USE_UNICODE )
    typedef std::wstring String;
#else
    typedef std::string String;
#endif//USE_UNICODE

Плюс несколько функций преобразования. И конечно два варианта библиотеки придется распространять, но это не особо страшно.

Автор: Любитель 23.9.2006, 16:12

Выбор не только между std::string и std::wstring. Через них всё не сделаешь (мне нужна не только обработка строк). В итоге подобных директив препроцессора будет не мало. Чем это плохо, я уже сказал. К тому же функции и пр. получаются не в неймспейсах, а глобально (причём на уровне препроцессора, что не гуд). Именно поэтому этот путь мне не нравиться.

ЗЫ Жду ещё мнений

Автор: Damarus 23.9.2006, 17:15

Цитата(Любитель @ 23.9.2006, 11:49

)

Автор: Daevaorn 23.9.2006, 20:10

Цитата(Любитель @ 23.9.2006, 17:12

)

Через них всё не сделаешь (мне нужна не только обработка строк).

Мне этого хватает. Ещё обертка для строковых литерал типа _TEXT() и больше ничего не надо.

Цитата(Любитель @ 23.9.2006, 17:12

)

В итоге подобных директив препроцессора будет не мало

В двух-трёх места. У меня по крайней мере.

Цитата(Любитель @ 23.9.2006, 17:12

)

К тому же функции и пр. получаются не в неймспейсах

Не понял. Функции и проxее вообще от этого не зависят. Они все дружно используют String

Автор: Любитель 23.9.2006, 20:39

Я не про то. 'Функции' которые объявляются как макросы. Вспомним, скажем WinAPI:

Код


#ifdef UNICODE
#define MessageBox  MessageBoxW
#else
#define MessageBox  MessageBoxA
#endif

Добавлено @ 20:40
Кстати, Damarus, твой пост означает типа 'согласен с этим вариантом'? smile

Автор: Daevaorn 23.9.2006, 20:43

Цитата(Любитель @ 23.9.2006, 21:39

)

Я не про то. 'Функции' которые объявляются как макросы. Вспомним, скажем WinAPI:

Ну а ты так не делай. Вобщем, проблема высосана из пальца. В одном месте (например в файле наподобии config.hpp) разрулить все дефайны, а потом спокойно юзать.

Автор: Damarus 24.9.2006, 06:06

Цитата(Любитель @ 23.9.2006, 21:39

)

Кстати, Damarus, твой пост означает типа 'согласен с этим вариантом'?

Именно