Кроссплатформенная работа со строками на C++

со строками в Линуксе нужно работать в кодировке UTF-8 и в типе std::string, а в Windows строки должны быть в Юникоде (тип std::wstring). Почему? Потому что это by design операционных систем. Хранить строки в std::wstring в Линуксе крайне накладно, поскольку один символ wchar_t занимает 4 байта (в Windows — 2 байта),

Разве это бидезигн? Можно и там и там как угодно работать, как сами ниже говорите — в линуксе строки можно же и в wchar_t хранить. В винде sdk/api он двухбайтовый, потому что там исторически сложилось так с древних времён ещё, хотя это неправильно. И там в этих двух байтах просто символы UTF-16 хранятся (либо если UTF-16 символ окажется четырёхбайтовым, то в двух wchar_t ). UTF-8 здесь и ниже по тексту — это же просто вопрос кодирования юникода, а выбор строки, чаров итд — вопрос хранения самих символов. Вы намеренно смешиваете понятия (ровно как и понятия «в винде строки в юникоде» и «в линуксе строки в utf-8»), либо я не понимаю чего-то тут?

Обычно для кроссплатформенной работы со строками на C++ используют какой-нибудь фреймворк. Например — Qt.

Выше уже предупредили об неточности в строке «Windows строки должны быть в Юникоде». По-моему стоит исправить статью, чтобы не распространялось.

А вообще к выбору кодировки стоит подходить осторожно. Никаких проблем в линуксе, utf-8 обеспечит работу программы с чем угодно. Проблемы начнутся, когда вы захотите применить utf-8 к сломанной кодировке utf-16 в представлении windows. Дело в том, что локализованные версии windows периодически мешают кодировки в именах файлов. В результате получаются пути вида www.graphicall.org/ftp/ideasman42/bad_utf8.txt (кодировка utf-8, открывать в редакторе типа SciTE, которые умеют работать с битыми кодировками). Я эту блядскую строку даже не могу на хабр добавить, поскольку здравомыслящие браузеры при копировании и вставке меняют битый символ на символ подстановки �. На самом деле за этим символом в данное случае скрывается символ с кодом 0xE9 (é) из однобайтовой кодировки Windows-1252. Такие строки нельзя преобразовать обратно в utf-16 так, чтобы получилась исходная битая строка. В связи с этим, с подобными файлами не смогут работать все программы в линуксе, а также программы, написанные по статье.

А если еще про мак вспомним и его NSString / CFStringRef? Или всяких там плагинов под кроссплатформенный пакет?

Бывает, что конертация строк, путей, и прочего — pain in ass еще тот.

Вот к примеру частенько приходится тягать с собой гору всяких platform dependent traits в виде UTF16Char, UTF8Char и прочих, и в нужных местах переконвертировать системозависимым способом между std::[w]string, UTF{16|8}Char*, char*, wchar_t* и пр.

Оно конечно не так чтобы сложно, по надцатому-то разу, но ведь еще и изобретать приходится вот такое

public class MyKewlInputStream(const std::wstring&) 
    defined by system-specific implementation 

что изрядно доставляет.

И не сказать чтобы такое счастье пишется один раз в пятилетку — большие старые пакеты предоставляют свои строки, свои стримы, свои конвертеры, и пр. и пр., которые как-то надо оборачивать. И из этих оберток — еще и системоспецифичные хэндлы, форки и дескрипторы торчат, как иголки из подушечки для булавок.

К примеру — адобовые PMString / WideString, PMStream.

Оборачивать приходится просто для того, чтобы не писать каждый раз нечто вроде такого

    WideString wsFileName(fileName.c_str());
    PMString pmFileName = PMString(wsFileName);

    IDFile idFileName;
    FileUtils::PMStringToIDFile(pmFileName, idFileName);
    InterfacePtr<IPMStream> stream(StreamUtil::CreateFileStreamWriteLazy(
                                                      idFileName, kOpenOut | kOpenTrunc));

    // Наконец-то у нас что-то system specific InDesign API и можно с этим работать

или такого (крестится)

#ifdef WINDOWS
    // клятый фотошоп нам подсунул под виндой UTF16Char*
    uint16* result = fSpec->mReference;
    numUtf16 = (uint32)wcslen((const wchar_t*)result);
    // для остроты ощущений это все еще в Java сунем
    jstring filePath = env->NewString(result, numUtf16);
    ...
#else
    // а под маком Fork aka FSIORefNum, добро пожаловать в отладчик
    CFStringRef path = FSRefToCFString(&fSpec->mReference);
    uint32 numUtf16 = (uint32)CFStringGetLength(path);
    UniChar* result = nil;
    if(numUtf16 > 0) {
        result = new UniChar[numUtf16+1]; 
	CFRange rangeToCopy; 
        rangeToCopy.location = 0; 
        rangeToCopy.length = numUtf16;
	CFStringGetCharacters(path, rangeToCopy, result);

        // для остроты ощущений это все еще в Java сунем
        jstring filePath = env->NewString(result, numUtf16);
        ...
    }
    CFRelease(path);
#endif

Или вспомним мозилловые nsString / nsCString и конертации туда-сюда, NS_CStringToUTF16 и NS_LITERAL, NS_UTF16ToCString и прочие. А их же SOA и do_GetService()?

nsresult GetAsText(
    const nsACString &aCharset, 
    const char* aData, 
    PRUint32 dataLength, 
    nsAString& aResult)
{
    nsresult rv;
    nsCAutoString charsetGuess = aCharset;

    nsCAutoString charset;
    nsCOMPtr<nsICharsetAlias> alias = do_GetService(NS_CHARSETALIAS_CONTRACTID, &rv);
    NS_ENSURE_SUCCESS(rv, rv);

    rv = alias->GetPreferred(charsetGuess, charset);
    NS_ENSURE_SUCCESS(rv, rv);
    ...
}

(обратите внимание — в 10-строчнике мы видим 3 разных ns*String и const char* до кучи)

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

Не Qt единым, что называется ;-)

Мне не нравится, когда текст в utf8-кодировке хранится в std::string в силу возникающей путаницы.
Я обычно использую для этого строковый класс, не приводящийся к std::string.

typedef char utf8_char;
class utf8_char_traits: public std::char_traits<utf8_char> {};
typedef std::basic_string<utf8_char, utf8_char_traits> utf8_string;

Один глупый вопрос — а почему бы не использовать UnicodeString из icu, раз уж эта библиотека применена? У меня в проекте (который очень сильно завязан на работу со строками) именно этот класс в основном и используется. Он использует какую-то UTF-16 кодировку. Из приятных особенностей — хранение коротких строк прямо в классе, copy-on-write со счетчиком ссылкок.