LPCTSTR to std::string

  • Thread starter Thread starter Lucy Ludmiller
  • Start date Start date
L

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
 
Lucy said:
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
Click to expand...

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
 
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
Click to expand...

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"
 
Bruno said:
Just make sure that ptsz is different from NULL before you do this.
Click to expand...

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
 
Ray said:
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?
Click to expand...

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
 
Carl said:
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.
Click to expand...

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.
Click to expand...

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
 
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.
Click to expand...

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).
 
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.
 
Mihajlo said:
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.
Click to expand...

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

Ray
 
r said:
"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.
Click to expand...

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
 
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
Click to expand...

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!
 
Back
Top