Thread: text to LPTSTR?

c_str() of a std::string should give you a C style string.


--
Mats

Originally Posted by h3ro

Thank you fr your reply, but I have already tried that. It does not give an error, but it does not work (no file is saved)

Here is what I am "using"

Code:

std::string path = "C:\\Users\\Ole\\Documents\\test_";
std::stringstream temp;
temp << iter++;
path += temp.str();
path += ".bmp";

capFileSaveDIB(hWndC1, path.c_str());

more efficient to build the whole string with stringstream:

Code:

std::stringstream temp;
temp <<  "C:\\Users\\Ole\\Documents\\test_" <<  iter++ << ".bmp";
std::string path (temp.str());

LPTSTR - is pointer to buffer of TCHAR
so when compiling in UNICODE - you get the wrong string...

you could use
std::wstringstream and std::wstring in this case

or if you want to have a code compilable two ways - use template version
basic_stringstream <TCHAR> and basic_string<TCHAR>

Originally Posted by kcpilot

Simply because they can --- they are the big dog on the block!

I'd say it's more to do with the multiple language support. Unicode (in it's 16-bit character form) is much more suitable to asian, cyrillic and arabic languages [to give but a few examples], whilst the standard ANSI/ASCII is just barely able to support most European languages.

--
Mats

Originally Posted by matsp

I'd say it's more to do with the multiple language support. Unicode (in it's 16-bit character form) is much more suitable to Asian, Cyrillic and Arabic languages [to give but a few examples], whilst the standard ANSI/ASCII is just barely able to support most European languages.

Exactly, while you might not care that your software can run on any PC, no matter what language, for real businesses this is often essential. Plus it's a real pain to convert to Unicode later on, when you suddenly realize that you need it after all.

QuantumPete

In this case, it's not a new variable type. It's a typedef (or #define) for char* or wchar*, depending on the UNICODE flag. This way, you can compile your program in UNICODE or ANSI, by just setting a single flag. Imagine the amount of work if you had to replace every single instance of "char" in your code with "wchar".

I don't think Microsoft created unicode, and I don't know if Microsoft was the one to set a "de facto" standard for mapping wide -> unicode in compilers targeting PC x86/x64, so the blame is misplaced.
I really think the lack is for teaching who tend to teach char by default, when they really should be teaching students to use wchar.