LPCTSTR to std::string

[Lucy Ludmiller]

Anyone knows how to convert a LPCTSTR to an STL striung?. Can't seem to
finda nyting (that dosen't blab on for several pages) on the net about
how to do this

 

[Carl Daniel [VC++ MVP]]

Anyone knows how to convert a LPCTSTR to an STL striung?. Can't seem
to finda nyting (that dosen't blab on for several pages) on the net
about how to do this

typedef std::basic_string<TCHAR> tstring;

LPCTSTR pstz;
// ...
tstring tstr(ptsz); // construct a tstring from an LPCTSTR
// ...

Now, if you always want a narrow string (std::string), regardless of whether
it's a Unicode build or not, then you'll have to insert a narrowing
conversion from TSTR to char*, e.g. using wcstombs or WideCharToMultiByte.

Generally though, what you want it a std::basic_string of the same
"wideness" as TCHAR, so the simple typedef will do the trick.

-cd

 

[Bruno van Dooren [MVP VC++]]

Anyone knows how to convert a LPCTSTR to an STL striung?. Can't seem

typedef std::basic_string<TCHAR> tstring;

LPCTSTR pstz;
// ...
tstring tstr(ptsz); // construct a tstring from an LPCTSTR

Just make sure that ptsz is different from NULL before you do this.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"

 

[Ray]

Just make sure that ptsz is different from NULL before you do this.

Hi Bruno,

Any idea why Windows developers (not people who develop apps for
Windows, but people who develop Windows + the SDK) likes doing a
misleading #define on pointer so much?

I've been doing this for sometime so it doesn't surprise me anymore, but
I've seen many cases of people who just started and don't realize that
LPCTSTR is a const TCHAR* and think that it's some non-pointer magic
string and as such no memory allocation necessary, etc. What's wrong
with const TCHAR*, really?

Thanks,
Ray

 

[Carl Daniel [VC++ MVP]]

Hi Bruno,

Any idea why Windows developers (not people who develop apps for
Windows, but people who develop Windows + the SDK) likes doing a
misleading #define on pointer so much?

I've been doing this for sometime so it doesn't surprise me anymore,
but I've seen many cases of people who just started and don't realize
that LPCTSTR is a const TCHAR* and think that it's some non-pointer
magic string and as such no memory allocation necessary, etc. What's
wrong with const TCHAR*, really?

In the days of different pointer sizes (near, far, huge, etc), it was
helpful to have typedefs. Even without those issues anymore, many C and C++
programmer prefer to use a typedef instead of retyping a compound type every
time.

As to why someone would think it's something special, or doesn't need the
same care for memory management that any other pointer deserves, I couldn't
say.

-cd

 

[Ray]

In the days of different pointer sizes (near, far, huge, etc), it was
helpful to have typedefs. Even without those issues anymore, many C and C++
programmer prefer to use a typedef instead of retyping a compound type every
time.

Oh... no wonder. That explains it. Thanks Carl

As to why someone would think it's something special, or doesn't need the
same care for memory management that any other pointer deserves, I couldn't
say.

Yeah... I suppose it's because one has expected a pointer to have a *
when you define it. e.g.: it's clearer to have

void blah(const TCHAR* b)

instead of

void blah(LPCTSTR b)

although after a while of Win programming it's kinda becomes a habit.

Cheers
Ray

 

[r norman]

Oh... no wonder. That explains it. Thanks Carl


Yeah... I suppose it's because one has expected a pointer to have a *
when you define it. e.g.: it's clearer to have

void blah(const TCHAR* b)

instead of

void blah(LPCTSTR b)

although after a while of Win programming it's kinda becomes a habit.

It all makes sense when you understand the naming conventions.

"LP" means "long pointer", the "long" referring as mentioned to the
days when Intel CPU's used either long (segment-offset) or short
(offset only) pointers. The "C" means constant. And, of course,
"TSTR" means string of TCHAR.

Virtually all Windows pointer types have LP or P names.

I know people rail against such naming conventions but I find it
useful (provided they are accurate).

 

[Guest]

While we're at it, I just found out that PTCHAR isn't the same as
LPTSTR. The following code won't compile:

#include <tchar.h>
#include <windows.h>

int _tmain(int argc, TCHAR* argv[])
{
PTCHAR p = 0;
}

If the two include directives change places, OR if LPTSTR stands instead
of PTCHAR then it will compile.

 

[Ray]

While we're at it, I just found out that PTCHAR isn't the same as
LPTSTR. The following code won't compile:

#include <tchar.h>
#include <windows.h>

int _tmain(int argc, TCHAR* argv[])
{
PTCHAR p = 0;
}

If the two include directives change places, OR if LPTSTR stands instead
of PTCHAR then it will compile.

Ugh... there you have another reason to have a simple TCHAR* instead of
these defines.

Ray

 

[Tamas Demjen]

"LP" means "long pointer", the "long" referring as mentioned to the
days when Intel CPU's used either long (segment-offset) or short
(offset only) pointers. The "C" means constant. And, of course,
"TSTR" means string of TCHAR.

Sure, one can learn how to decode this information, and be able to deal
with these typedefs. But the question is not whether you can do it or
not, but how long it takes.

It takes an instant to understand
const TCHAR* b

and 15-25 seconds to decrypt
LPCTSTR b

Tom

 

[r norman]

Sure, one can learn how to decode this information, and be able to deal
with these typedefs. But the question is not whether you can do it or
not, but how long it takes.

It takes an instant to understand
const TCHAR* b

and 15-25 seconds to decrypt
LPCTSTR b

Compared to learning all the esoterica of Windows and MFC and STL and
whatever, that is the least of the problems. If you use Microsoft
specific library functions you have to use Microsoft specific
terminology. If you use STL, you have to use STL terminology. If you
use standard C++ you have to use standard C++ terminology. It is not
easy. So don't use LPCTSTR's if you don't like them!