Hi,
I'm wondering how the L macro (or whatever it is) works?
It works fine with text in quotes like: L"Hello world", but if I want to apply it to another macro like this: L__FILE__ the compiler can't figure out what I'm trying to do.
I can get it to work using: _T( __FILE__ ), but that's a little ugly and non-standard.
I tried: L( __FILE__ ), but then the compiler doesn't know what L is...
Is there a way to make it work with L?
I just did a quick google, and I found that the L macro is for making string literals into unicode.
How do you logically justify prefixing __FILE__ with the L macro?
What is that supposed to do?
__FILE__ is an ASCII string, but I'm passing it to a function that takes UNICODE strings, so I need something like the L or _T() macro to do it...Originally Posted by IceDane
L isn't a macro, it's a grammatical prefix (just like 1.0f -- the f isn't a macro), so it can only appear before a string literal. There may be a way to do some preprocessor trickery here, but I'm not seeing anything good off the top of my head.
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
Why not just put a space:
Or does that not work?Code:L __FILE__
The preprocessor will recognize __FILE__ now, but you can't have a space between L and "xyz" to have a long string.
So then why not a macro:
That would allow for the two-stage expansion of __FILE__ to "blah.c" and then L##"blah.c" --> L"blah.c"Code:#define MY_L(x) L##x
EDIT: Doh, that's basically what Dave posted a link to (except the linked way actually works)
Last edited by brewbuck; 04-07-2008 at 10:26 AM.
So I need 2 macros... strange. OK thanks.
Yes, the first macro serves to "resolve" __FILE__ into "blah.c" or such, then the second does L + "blah.c".
It's a "classic" trick.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
