Как я понимаю, Windows #defines TCHAR как правильный тип символа для вашего приложения на основе сборки - так что это wchar_t в сборках UNICODE и char в противном случае.
Из-за этого я подумал, будет ли std::basic_string<TCHAR> предпочтительнее std::wstring, так как первый теоретически будет соответствовать типу символа приложения, тогда как второй всегда будет широким.
Итак, мой вопрос по существу: был бы std::basic_string<TCHAR> предпочтительнее std::wstring в Windows? И есть ли какие-либо оговорки (например, неожиданное поведение или побочные эффекты) при использовании std::basic_string<TCHAR>? Или, должен ли я просто использовать std::wstring в Windows и забыть об этом?
Я считаю, что время, когда было целесообразно выпускать не-юникодные версии вашего приложения (для поддержки Win95 или для сохранения КБ или двух), давно прошло: в настоящее время базовая система Windows, которую вы будете поддерживать, будет на основе unicode (поэтому использование системных интерфейсов на основе char фактически усложнит код, помещая слой прокладки из библиотеки), и вряд ли вы сохраните любое пространство вообще. Иди std::wstring, молодой человек! -)
Я сделал это на очень больших проектах, и он отлично работает:
namespace std
{
#ifdef _UNICODE
typedef wstring tstring;
#else
typedef string tstring;
#endif
}
Вы можете использовать wstring везде, но если хотите, если вам не нужно компилироваться с использованием многобайтовой символьной строки. Я не думаю, что вам нужно поддерживать многобайтовые символьные строки, хотя в любом современном приложении.
Примечание. Пространство имен std должно быть отключено, но у меня не было проблем с указанным выше методом в течение нескольких лет.
Одна вещь, о которой нужно помнить. Если вы решите полностью использовать std:: wstring в своей программе, вам все равно придется использовать std::string, если вы общаетесь с другими системами, использующими UTF8.