If I have this

Will lpString be null terminated?

Yes.

I know that if i had a pointer to a TCHAR it would be null terminated



but why is TCHAR lpString[9] = TEXT("MainMenu"); null terminated too?
Is it because i'm using TEXT()?



What if I had this without TEXT()

Would this be null terminated too?

Yes. String literals are null-terminated.

On a side note, I hate whenever I see someone using TCHARs. It's 2014, not 1995. What purpose do TCHAR's serve anymore?

It's better to use unicode when possible and ansi when necessary. Explicitly call the unicode versions of functions and ignore TCHARs altogether. There are two good reasons that I know of why you should do this: 1) when you call an ansi function all it does is convert your string to unicode and call the unicode version of the function, and 2) modern API's in windows use COM, and COM uses unicode exclusively.

Yes. String literals are null-terminated.

This.

Using the TEXT macro has nothing to do with it. It's because you are using "double quotes". Anything in double quotes is null terminated.

What if my program is running on a version of windows that's not using unicode?

I could code the program in ANSI and windows will convert it to unicode.
But the question is: does this conversion take place at compile time or while program is running?

Cause if it takes place while program is running, then that will slow down my program and I want it to be as fast as possible

On a side note:
My project is unicode. Since I'm using TCHAR, when does the conversion to unicode take place, at compile time or run time?

Anything inside double quotes is going to be null terminated. Always.

It doesn't matter if it's by itself... with a 'L' prefix, or inside a TEXT macro. If it has double quotes, it is null terminated.

What if my program is running on a version of windows that's not using unicode?

Windows has been using Unicode under the hood since WinNT. Unless you are targetting Win9x machines I wouldn't worry about it.

But the question is: does this conversion take place at compile time or while program is running?

That depends on you.

If you have UNICODE/_UNICODE defined, then it's compile time. If not, then it'll be converted at runtime after you pass the ANSI string to any WinAPI function.

Cause if it takes place while program is running, then that will slow down my program and I want it to be as fast as possible

It won't slow down your program in any noticeable way unless you are doing TONS of conversions. Don't sweat the small stuff.

Besides... working with wide characters might be slower because it means using more memory and moving more memory around. It's not always as simple as "Unicode is faster" or "Unicode is slower". There are lots of other factors.

Since I'm using TCHAR

TCHARs are retarded. But if you must use them... then they are effectively a typedef of either char or wchar_t depending on whether or not UNICODE/_UNICODE macros are defined.

If you are "using Unicode" (meaning you have UNICODE/_UNICODE defined), then TCHAR==wchar_t... and MessageBox==MessageBoxW, etc. IE: it's all UTF-16 and the conversion is done at compile time.

I could code the program in ANSI and windows will convert it to unicode. But the question is: does this conversion take place at compile time or while program is running?

Like I said, whenever you call an ANSI function(MessageBoxA(), CreateWindowA(), etc) there is a conversion to unicode, and this happens at run-time because that's how those functions are implemented(in Vista and later): they do nothing except convert your ANSI strings to Unicode and call the unicode functions(MessageBoxW(), CreateWindowW()).

Here's a quote from the book Windows via C/C++:

Microsoft's source code for CreateWindowExA is simply a translation layer that allocates memory to convert ANSI strings to Unicode strings; the code then calls CreateWindowExW, passing the converted strings. When CreateWindowExW returns, CreateWindowExA frees its memory buffers and returns the window handle to you. So, for functions that fill buffers with strings, the system must convert from Unicode to non-Unicode equivalents before your application can process the string. Because the system must perform all these conversions, your application requires more memory and runs slower. You can make your application perform more efficiently by developing your application using Unicode from the start. Also, Windows has been known to have some bugs in these translation functions, so avoiding them also eliminates some potential bugs.

I agree with what disch says here. I too think the conversion takes place at compile time

If you are "using Unicode" (meaning you have UNICODE/_UNICODE defined), then TCHAR==wchar_t... and MessageBox==MessageBoxW, etc. IE: it's all UTF-16 and the conversion is done at compile time.

But knn9 you say it takes place at compile time. Is that only in vista and later?
Why are you introducing confusion knn9?

Me and Disch are talking about different things. What's confusing about it?