Как считать из объекта типа stringstream в буфер TCHAR

[8Observer8]

Доброго времени суток! Как считать из объекта типа stringstream в буфер TCHAR при использовании опции проекта "Использовать Юникод кодировку"?

#include <sstream>
#include <tchar.h>
using namespace std;

#define BSIZE 20

int main ()
{
    TCHAR buf[BSIZE];
    stringstream s;

    s << "hello, world!" << endl;

    s.getline(buf, BSIZE);

    return 0;
}

[zvoronz]

Используй объекты для широких строк. Добавляй w спереди.
wstringstream s;

[_Bers]

када то мудохолся с подобной темой. Не придумал ничего умнее топора:

void CWinDisplay::PrintText(const std::string& text)
{
    ...
    #ifdef UNICODE
        #pragma message("CWinDisplay::PrintText(): UNICODE")
        wchar_t *buf = new wchar_t[text.length() + 1];
        MultiByteToWideChar(CP_ACP, 0, text.c_str(), -1, buf, text.length() + 1);
        std::wstring tmp(buf);
        delete [] buf;
    #else
        #pragma message("CWinDisplay::PrintText(): multibyte")
        const std::string& tmp = text;
    #endif 
    ...

Зато извне функции не нужно пасти, юникод у тебя, или мультибайт. Никакие диррективы, и никакие макросы снаружи не нужны

[8Observer8]

Спасибо, _Bers! То что нужно!

Сообщение от zvoronz

Используй объекты для широких строк. Добавляй w спереди.
wstringstream s;

Моя вина. В своём вопросе я забыл добавить, что и при использовании опции: "Использовать многобайтовую кодировку", тоже должно работать. Всё-равно спасибо! Такой вариант может пригодиться, плюсую!

[8Observer8]

Вот такой вариант нашёл:

#include <sstream>
#include <tchar.h>
using namespace std;

#define BSIZE 20

#ifdef _UNICODE
    typedef std::wstring tstring;
    typedef std::wstringstream tstringstream;
#else
    typedef std::string tstring;
    typedef std::stringstream tstringstream;
#endif

int main ()
{
    TCHAR buf[BSIZE];
    tstringstream  s;

    s << _T("hello, world!") << endl;

    s.getline(buf, BSIZE);

    return 0;
}

[_Bers]

Там видишь, в чем сложность то: литерные константы в исходном коде виндузятные компили воспринимают исключительно как мультибайт (если ничего не путаю), что в условиях, когда нужно поддерживать юникод, вынуждает, нас пасти эти ситуации и юзать всякие макросы аля _T(), или L(), и тп.

Фейлы начинаются, когда хочется единообразно пихать в функцию и литерную константу, и готовый объект.

Я привык к моральному std::string, и к тому, что char весит 1 байт, а не "хрен пойми чего в зависимости от чего-то там"

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

int main ()
{
    char buf[BSIZE];
    stringstream  s;

    s << "hello, world!" << endl;

    s.getline(buf, BSIZE);

    return 0;
}

stringstream пусть сам ловит геммор с кодировками. Я привык писать просто.
А если он это не умеет, значит нужно вызывать такой механизм, который умеет. И сам будет всем рулить.

А вот здесь очень доступно и замечательно описаны дрязги с юникодом под форточками:

http://wm-help.net/books-online/prin.../59464-13.html

[8Observer8]

А если он это не умеет, значит нужно вызывать такой механизм, который умеет. И сам будет всем рулить.

Внешний механизм нужен надёжный, простой и продуманный. Для этого нужно хорошенько в нюансы въехать. Жаль нет готовых решений. За изложение позиции и ссылку - большое спасибо!

[_Bers]

Сообщение от 8Observer8

Внешний механизм нужен надёжный, простой и продуманный. Для этого нужно хорошенько в нюансы въехать. Жаль нет готовых решений. За изложение позиции и ссылку - большое спасибо!

Политика корпорации Зла


Однако деление на мультибайт/юникод критично только при дерганье модулей, которые взаимодействуют с системой (дергают winapi, либо готовят материалы для тех, кто будет дергать winapi).

Моя идея заключается в том, что в рамках собственного приложения не используются никакие макросы вообще. Используется обычный std::string and char.

мы не пишем вот так:

Foo(_T("trololo"));

мы пишем просто:

Foo("trololo");

При взаимодействии с системой, материалы передаются на вход специальным функциям, которые уже внутри себя сами подготовят материалы так, что бы их могло прожевать winapi, и толкнуть их дальше.

Тогда получается: что внутри своего приложения чар стабильно весит 1 байт. А что именно будет скормлено winapi меня (моё приложение) вообще не заботит.

Профит тут ещё в том, что используя стандартные std::string and char в коде целевого приложения, можно не просто обеспечить поддержку кодировок, но и совместимость кода msc/mingw/gcc

То бишь, код, учитывающий политику Зла может взлететь и под Linux