LPCTSTR vs const char* in Visual C++ 2005

[tony.y...@gmail.com]

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

[lallous]

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.y...@gmail.com> wrote in message
news:1144826944....@g10g2000cwb.googlegroups.com...

[Tony]

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

[JoeB]

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

[David Wilkinson]

tony.y...@gmail.com wrote:

Tony:

VS2005 enables Unicode build by default. While generally this is a good
idea, it seems kind of crazy to do it when converting a project from an
older version. You have to change your project settings to get back ANSI
build.

On the other hand, it really would be "better" to convert your code to
Unicode. This should be just a matter of inserting _T("") macro on all
strings. If you get it to compile in Unicode build, you can still go
back and make ANSI build in the short term.

David Wilkinson

[Tony]

David,

Thanks a lot! I tried and it works!

I added a line "#undef UNICODE". Because I have tens of projects that
need to work with, can I add only change the project setting to have
the same result?

Best Regards,
Tony

[David Wilkinson]

Tony wrote:

Tony:

I would think you need to "#undef _UNICODE" also. It is really better to
do this in the project settings. In VC7 (probably VC8 also) you can do
this on the Configuration Properties->General property page.

I think you will have to do this for every project. I doubt it is
possible to change default for entire VS2005 application (though it may
be, I really don't know).

David Wilkinson

[Heinz Ozwirk]

"Tony" <tony.y...@gmail.com> schrieb im Newsbeitrag news:1144828930.9...@j33g2000cwa.googlegroups.com...

> Thank you, Elias!
>
> My programs are all ANSI. To use LPCTSTR is because it looks better
> than const char* :-)

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.

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

No. Use the project's property settings and select Multi-Byte Characterset instead of Wide Characterset.

Heinz

[Tom Widmer [VC++ MVP]]

Tony wrote:
> Thank you, Elias!
>
> My programs are all ANSI. To use LPCTSTR is because it looks better
> than const char* :-)

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

[Alex Blekhman]

Tom Widmer [VC++ MVP] wrote:
> [...] 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?

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.

[Ajay Kalra]

> Does anyone actually build applications for both Unicode and ANSI now?

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

[Tom Serface]

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" <ajay...@yahoo.com> wrote in message
news:1144846798.8...@g10g2000cwb.googlegroups.com...

[Ajay Kalra]

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

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 Widmer [VC++ MVP]]

Tom Serface wrote:
> I agree with Ajay. You may not think you need Unicode right now, but
> eventually you will as your product grows.

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

Tom

[Ajay Kalra]

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

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

[Tom Serface]

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_u...@hotmail.com> wrote in message
news:uiGOvOkX...@TK2MSFTNGP02.phx.gbl...

[Tom Serface]

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" <ajay...@yahoo.com> wrote in message

news:1144855820.7...@i40g2000cwc.googlegroups.com...

[Tony]

Thank you, Heinz! My problem has been solved!