Thread: convert from int to cstring

I see what you mean. But I also have to draw a line somewhere. I won't use unsafe functions, because they can compromise security and stability.
Macros, however, are compile-time, and if a macro works, good for me, than I can use it. There's no "unsafe" I see in using macros, even if they're served.
But as you point out, I could just make an own macro, __T(?) or ___T(?) and just map it to _T, or if it does not exist, someone else will have to remap that macro into something else that works. Or just redefine it so it works.

Function or macro names that start with an underscore are reserved for compilers.

Edit: I wouldn't redefine a compiler macro tbh.... especially for something like this.

But T is too generic, and TEXT may be too generic and I don't want to type CONVER_THIS_TO_ASCII_OR_UTF.

But TEXT is what the Win32 API uses. Can't be too generic.

THIS IS A TEXT!
...Or so I'd like say -> but if I type that in my app, what will happen, I wonder? That's why I use _T. That and it's shorter too.
That's why it's maybe too generic.

but if I type that in my app, what will happen, I wonder?

You mean in a text field during runtime or something like that?

Yes, something like that.
It's just that it will be replaced by the TEXT macro which is something you'd want to avoid.

Here's a good question: is there any platform that is ASCII only or ASCII specific?

Originally Posted by Elysia

Yes, something like that.
It's just that it will be replaced by the TEXT macro which is something you'd want to avoid.

You really need to review the compilation model of C++. What you fear is utterly impossible.

Yeah, I can't help thinking that the issue isn't being clarified properly. Typing in "TEXT" as input into a program doesn't invoke a macro of the same name, and I can't imagine they actually think that.

If everyone were experts, we wouldn't need experts. You don't know everything and you will never do. You learn something every day as they say.
I didn't know, of course.

Macros are handled the by (C) preprocessor at compile time. I had thought you even previously had said that they were handled at compile time.

To be slightly pedantic, they are handled before compile time..... An example:

Code:

#define SIZE 10

....

int array[SIZE];

....

The preprocessor actually runs through the code and replaces all instances of SIZE with 10, so that before the code is actually even really compiled, SIZE is replaced with 10.

So the code is really looked at by the compiler is this:

Code:

....

int array[10];

....

That's all #define does for you, whether implemented as _T() or whatever else.

The special stuff is that the _T() macro checks if Unicode is define or not and if so then it makes the string a wide one (with L). Otherwise, it doesn't do anything. The source code is changed in memory before it actually gets compiled, though. There's no need to worry about it after that.

On a slightly different topic, I read an article, though, that said that _T() and TEXT() are actually different. Some are implemented to handle something to do with the C library and another is to handle something different with Windows API functions or something. I'd have to look it up again to see exactly what the difference is.

Strictly speaking, the _T macro doesn't check. There's actually two _T macros, but only one is ever defined.

The definitions of the two _Ts, of the two _TEXTs and the two TEXT macros are:
In <tchar.h> (MS CRT extension)

Code:

#if defined(_UNICODE)
#define _T(x) L ## x
#define _TEXT(x) L ## x
#else
#define _T(x) x
#define _TEXT(x) x
#endif

In <windows.h> (Win32 API)

Code:

#if defined(UNICODE)
#define TEXT(x) L ## x
#else
#define TEXT(x) x
#endif

As you can see, the CRT and the Win32 versions are identical, except for the macro they test against.

Originally Posted by CornedBee

Strictly speaking, the _T macro doesn't check.

Sorry, you are correct.