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

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

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

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

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

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

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

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

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

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

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

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


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

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

Именно