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]]

Lucy Ludmiller wrote:

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<TCHARtstring;

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

>to finda nyting (that dosen't blab on for several pages) on the net
about how to do this

typedef std::basic_string<TCHARtstring;

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
br**********************@hotmail.com
Remove only "_nos_pam"

[Ray]

Bruno van Dooren [MVP VC++] wrote:

>>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<TCHARtstring;

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

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]]

Ray wrote:

Bruno van Dooren [MVP VC++] wrote:

>>>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<TCHARtstring;

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

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?

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]

Carl Daniel [VC++ MVP] wrote:

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

>
-cd

[r norman]

On Tue, 05 Sep 2006 20:49:27 +0800, Ray <ra********@yahoo.comwrote:

>Carl Daniel [VC++ MVP] wrote:

>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.

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).

[Mihajlo Cvetanović]

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]

Mihajlo Cvetanović wrote:

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]

r norman wrote:

"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]

On Wed, 20 Sep 2006 11:15:07 -0700, Tamas Demjen <td*****@yahoo.com>
wrote:

>r norman wrote:

>"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

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!