Board index » Visual Studio » LPCTSTR vs const char* in Visual C++ 2005

Visual Studio119
Greetings!



I'm converting programs written on Visual C++.NET 2003 to Visual C++

2005. While building them with Visual Studio 2005, I got hundreds of

errors like: "cannot convert parameter 1 from 'LPCTSTR' to 'const char

*'" or "cannot convert parameter 1 from 'const char *' to 'LPCTSTR'".

I wrote a simple application to duplicate it (see below):



#include "stdafx.h"

#include "windows.h"



int Work(LPCTSTR s)

{

return strlen(s);

}



int _tmain(int argc, _TCHAR* argv[])

{

Work("ABCDE");

return 0;

}



Does anyone know how to solve it? I don't want to add explicit

conversion because there are too many places in too many files.



Thanks in advance!



Tony


-

Hello Tony,



Maybe you're compiling as unicode?



Since you are declaring your function's parameter as LPCTSTR you have to

make sure you're passing correctly as ASCII or as UNICODE depending on your

build.



Replace all your string literals with _T("my string") this macro will ensure

proper declaration of strings.



Work(_T("ABCDE"));



Also include "tchar.h"



HTH

Elias

<tony.yi.zhou@gmail.com>wrote in message



-

Thank you, Elias!



My programs are all ANSI. To use LPCTSTR is because it looks better

than const char* :-)



Should I define a macro to tell the compiler to work in ANSI mode?



Best Regards,

Tony



-

Or add a capital 'L' in front of the string:

"my string" ->>L"my String"



Although _T("my string") is better practice.



Now all you need is someone to come up with a regex find/replace to do

it for you!







J









lallous wrote:

"Tony" <tony.yi.zhou@gmail.com>schrieb im Newsbeitrag =

How can something that is planly wrong look good? If your programs are =

ANSI and will never be unicode, use char const* (or const char*) or =

LPCSTR. LPCTSTR and LPTSTR are types that may be ansi or unicode, =

depending on the project's property settings.



No. Use the project's property settings and select Multi-Byte =

Characterset instead of Wide Characterset.



Heinz

-

Tony wrote:

If it is meant to be a const char*, you can use LPCSTR (without the T).

This T stuff was just there to cope with the problem with the Win9x

series not using unicode natively, which is now something of a non

issue. Does anyone actually build applications for both Unicode and ANSI

now?



As far as I'm concerned, if I want unicode (e.g. for the UI) I use

wchar_t, if not I use char (e.g. for logging).



Tom

-

Tom Widmer [VC++ MVP] wrote:

I think that most of vendors who actually would have

required to do both builds, figured out quite quickly that

they could get away with ANSI build only. Now we have tons

of [cripple] programs, which cannot manage Unicode input or

filenames. It can be especially infuriating when you're

using such program that should work with files a lot, like

DVD burning software, for example.





-

Even if you dont build apps for UNICODE and ANSI, its still a good

practice to use T. Its especailly meaningful if you are building with

ANSI as it will be easier to migrate to UNICODE if you choose to do so.

This is coming from personal painful experience.



---

Ajay



-

I agree with Ajay. You may not think you need Unicode right now, but

eventually you will as your product grows. It doesn't cost anything to use

the macros except a little discipline.



Tom



"Ajay Kalra" <ajaykalra@yahoo.com>wrote in message



-

Why? You add L only if you want a UNICODE string or you have a UNICODE

build. Typical use for prefix L in MBCS builds is when using COM

objects or some methods which take wide char strings. Otherwise you

should not use it in MBCS. _T is a perfect choice.



---

Ajay



-

Tom Serface wrote:

But in that case why not just use unicode from the start?



Tom

-

The short reason is wizards in VC++ prior to VS2005 generated MBCS code

(in MFC). A large majority (if not all) never touched this setting. You

had to make an effort to make it UNICODE.



In VS2005, UNICODE is the default setting as opposed to MBCS in earlier

versions, so you would expect it will be more popular. However, I am

not sure why this was needed. People still like to use strcpy etc and

suddenly they cannot use it anymore. I have used UNICODE for a very

long time. I recently moved to a app which is few years old is MBCS and

there are no issues. So I am not sure why should this be forced to

everybody. Every project has different requirement, most of these are

not UNICODE specific. My personal prefernce is to start with UNICODE

so as to avoid this issue later on. But that does not mean others feel

the same way.



---

Ajay



-

I can't argue with that unless you are worried about the extra string space.

I don't find Unicode any more difficult to work with internally most of the

time. You just have to remember that there are two bytes per character for

buffers for CFileDialogs and things like that, but... I agree and I've

started using Unicode all the time.



Tom



"Tom Widmer [VC++ MVP]" <tom_usenet@hotmail.com>wrote in message



-

Yeah, but 2005 makes it a snap to turn Unicode on and off in the properties.

I think this is a big improvement. That... and now you can have Unicode RC

files and that's a good thing too.



Tom



"Ajay Kalra" <ajaykalra@yahoo.com>wrote in message



-

Thank you, Heinz! My problem has been solved!



-

No, the _T() is required for compatibility of source between ANSI and Unicode and is

COMPLETELY UNRELATED TO WINDOWS 95. And yes, there are lots of apps that compile in both

modes.

joe



On Wed, 12 Apr 2006 10:52:49 +0100, "Tom Widmer [VC++ MVP]" <tom_usenet@hotmail.com>

wrote:



email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

--

NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth

-

Of course, if you are only compiling for Unicode you can forgoe it and just

use the L"" and wchar keys instead.



Tom



"Joseph M. Newcomer" <newcomer@flounder.com>wrote in message



-

Right. A lot of my client base wants both 8-bit and Unicode versions of apps.

joe



On Mon, 17 Apr 2006 08:32:14 -0700, "Tom Serface" <tserface@msn.com>wrote:



email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

--

NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth

-

I agree and I actually find TCHAR and _T() easier to right than the other

stuff even though I mostly only do Unicode applications these days. I think

the odds are that most applications will end up Unicode eventually so we may

as well plan ahead and do it right from the beginning.



Tom



"Joseph M. Newcomer" <newcomer@flounder.com>wrote in message



-

I tried for many months to keep my LocaleExplorer as a bimodal app, but after a while I

had to give up. There's no way to do a WM_SETTEXT (SetWindowText) of a Unicode string in

an ANSI app (there should have been WM_SETTEXTA and WM_SETTEXTW messages, but that seems

too much to expect...) So now it is a Unicode-only app. My usual experience is someone

who wants an ANSI-only app, then suddenly finds they have a market that requires Unicode,

which is why I always code "Unicode-aware", so I can give them "convert to Unicode" times

in hours, rather than weeks (localization is more effort, and they usually don't want that

effort expended until they need it).

joe

On Mon, 17 Apr 2006 12:32:06 -0700, "Tom Serface" <tserface@msn.com>wrote:



email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

--

NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth

-