LPTSTR burp = _T("Fffurrp!");
std::cout << (CHAR*)burp << endl;Is there a way to use std::cout with a LPTSTR?
Author
I'm trying to output a string to the console, where the string came from a function that returned a LPTSTR. So basically:
Sounds like you're compiling in Unicode mode, where LPTSTR represents strings in UTF-16 format. The second byte of your data, then, is zero, and gets interpreted as the end of the string by std::cout. Try std::wcout instead:
LPTSTR burp = _T("Fffurrp!");std::wcout << burp << std::endl;
Author
Wahey that works.. but the 'w' functions only handle Unicode right? I've been using the 't' conversions and functions so it can handle ascii, unicode, or multibyte characters as well.
I can't find something like "tcout". With sprintf you have a _stprintf, which just uses sprintf for multibyte characters anyway. Just that cout I need.
I can't find something like "tcout". With sprintf you have a _stprintf, which just uses sprintf for multibyte characters anyway. Just that cout I need.
You'll need to define it yourself. The C++ Standard library components don't come with generic text mapping aliases.
#ifdef UNICODEostream& tcout = wcout;#elseostream& tcout = cout;#endifShould work (and without evil #define) :)
EDIT: Yes, it was the wrong way around before. Doh :)
[Edited by - Zahlman on January 4, 2006 4:28:16 PM]
Author
Ah, thank you. Should have thought of defining my own one sooner.
But now I'm curious about these new things mentioned... #define is evil? Actually I'm getting linker errors using the ostream& way.. using #define does get it to compile.
And what is the difference between UNICODE and _UNICODE? (I think you got your cout and wcout around the wrong way there too.)
But now I'm curious about these new things mentioned... #define is evil? Actually I'm getting linker errors using the ostream& way.. using #define does get it to compile.
And what is the difference between UNICODE and _UNICODE? (I think you got your cout and wcout around the wrong way there too.)
The difference between UNICODE and _UNICODE is mostly historical. All well behaved programs that define either should define both.
To be completely honest, I don't think there's any point in using T-strings these days. T-strings seem primarily designed to allow you to write for Unicode while still allowing you to compile a separate ANSI-string version for the older Windows versions that don't have sufficient Unicode support (95, 98 and ME). However, since the Microsoft Layer for Unicode was released, your Unicode version will work on the older Windows versions as well. I'd rather just assume Unicode support and be done with it. :-)
Quote:Original post by Defend
Ah, thank you. Should have thought of defining my own one sooner.
But now I'm curious about these new things mentioned... #define is evil? Actually I'm getting linker errors using the ostream& way.. using #define does get it to compile.
#define should not be used when there is a way to accomplish the same goal using compiler constructs, and not preprocessor constructs. Consider the case of using #define TWO 2 vs. const int TWO = 2. They accomplish nearly the same goal but the latter is definately better.
I wouldn't go so far as to say #define is always evil...it has its uses.
evil (but do understand "evil").
As for the reference, I don't know why it wouldn't be working for you. It looks OK to me but I've had problems trying to work with ostream references before... :(
As for the reference, I don't know why it wouldn't be working for you. It looks OK to me but I've had problems trying to work with ostream references before... :(
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement