I know that the _T(x) macro converts a string literal to a unicode/multibyte
string based on a define, however I find it very annoying that I must make a
underscore and the parenthesis, it really confuses me, I'm not quiet fluent with
macros so I don't know, is there a way to detect all string literals and convert
them to a proper unicode/multibyte string?
No, there isn't a way to avoid the macro completely if you want your code to be portable on Windows. You can of course define your own macro like #define t(x) whatever_T_does if you want to save yourself some keystrokes, but this will probably anger future maintainers of your code.
_T() and _TEXT() are C runtime macros, not Win32 macros. TEXT() (no underscore) is the Win32 macro. Even though they essentially do the same thing, you should use C runtime macros only with C functions, and Win32 macros with Win32 functions. Don't mix them.
Do you really need the ability to compile for both multibyte and Unicode? You don't need any macro if you want multibyte. In a Unicode app it is easier to use L"literal string", which does not need the underscore or the parentheses.
Related
Is it possible to have the preprocessor turn something like ... this is my comment into // this is my comment?
If not, is there it possible to put something in my make file to do this?
No, the preprocessor only recognizes the same symbol set as C, which means macros has to start with either an underscore or a letter, followed by underscores, letters and digits.
With the C preprocessor: no, it recognizes the same kinds of tokens as C does; you can't introduce new ones.
With your own preprocessor: technically yes, but unless your preprocessor can accurately parse C and make sure that it only does the substitution in the exact right contexts, you will very likely run into problems where it accidentally corrupts your source. Besides, you will be creating an extra learning curve for new developers getting into the code. Overall, I wouldn't recommend it.
I am making a parser currently which aims to be able to input data in a program.
The syntax used is greatly inspired from C.
I would enjoy to reproduct a kind of preprocessor inline substitution into it.
for example
#define HELLO ((variable1 + variable2 + variable3))
int variable1 = 37;
int variable2 = 82;
int variable3 = 928;
Thing is... I'm actually using C. I'm also using standard functions from stdio.h to parse through my files.
So... what techniques I could use to make this work correctly and efficiently?
Does the standard compilers substitute the text by re-copying the stream buffer and making the substitution there as the re-copying occurs or what? Is there more efficient techniques?
I guess we say preprocessor because it first substitutes everything until theres no preproc directives (recursive approach maybe?), and then, it starts doing the real compile job?
Excuse my lack of knowledge!
Thanks!
No, modern C compilers don't implement the preprocessor as a text processor, but they have the different compiler phases (preprocessing being one of them) tangled. This is particularly important for the efficiency of the compiler itself and to be able to track errors back into the original source code.
Also implementing a preprocessor by yourself is a tedious task. Think twice before you start such a project.
Yes, you are right about preprocessors. It has the job of bringing together all files which are requires for the execution of the program to 1 file for eg. stdio.h. Then it allows the compiler to compile the program. The file you want to compile is given as argument to the compiler and the techniques used by the compiler may vary according to the os and the compiler itself
The C preprocessor works on tokens not text. In particular, macro expansion cannot contain preprocessor directives. Other preprocessors, such as m4, work differently.
What's the best way to concatenate a string using Win32? If Understand correctly, the normal C approach would be to use strcat, but since Win32 now deals with Unicode strings (aka LPWSTR), I can't think of a way for strcat to work with this.
Is there a function for this, or should I just write my own?
lstrcat comes in ANSI and Unicode variants. Actually lstrcat is simply a macro defined as either lstrcatA or lstrcatW.
These functions are available by importing kernel32.dll. Useful if you're trying to completely avoid the C runtime library. In most cases you can just use wcscat or _tcscat as roy commented.
Also consider the strsafe.h functions, such as StringCchCat These come in ANSI and Unicode variants as well, but they help protect against buffer overflow.
At the moment, I have a path_concat(char* path_fragment_a, char* path_fragment_b) function, which simply concatenates together path_fragment_a, PATH_DIVIDER, and path_fragment_b. (PATH_DIVIDER is #defined in an #ifdef block, so it's \ on Windows and / everywhere else.)
But I can't help thinking this seems:
a bit of a kludge.
something which must surely be covered by a fairly common library, which would be better to use if available, so I'm not reinventing the wheel.
Googling it just turned up a lot of results about Python's os.path.join (which would be ideal, except it's Python, not C), so I was wondering if anyone was aware of a cleaner/more standard solution.
First of all, you should use snprintf, not concatenation operations, to construct a string all at once. This is the safe and efficient way. Concatenation may be idiomatic in script languages but it's inefficient and harmful (prone to dangerous errors) in C.
With that said, ever since the first version of DOS that had directories (2 or 3; I forget which it was), '/' has been valid as a path separator on DOS, and it has always been valid on Windows as well. The only reason it was not used is that many legacy command line programs designed before DOS supported directories interpret '/' as a "switch" (option) character in their command line parsing. The only real-world system in the past 20 years not to support '/' as a path separator is pre-OSX MacOS, and I don't think that's a viable target anymore, so in my opinion, you should simply always use '/', and avoid polluting your code with gratuitous "portability".
Unfortunately, there is no such function in the Standard C library to join file paths. You'll have to do it manually.
Apparently GLib has some functions (like g_build_path) and macros (G_DIR_SEPARATOR_S and others) for this.
In gcc, how can I check what C preprocessor definitions are in place during the compilation of a C program, in particular what standard or platform-specific macro definitions are defined?
Predefined macros depend on the standard and the way the compiler implements it.
For GCC: http://gcc.gnu.org/onlinedocs/cpp/Predefined-Macros.html
For Microsoft Visual Studio 8: http://msdn.microsoft.com/en-us/library/b0084kay(VS.80).aspx
This Wikipedia page http://en.wikipedia.org/wiki/C_preprocessor#Compiler-specific_predefined_macros lists how to dump at some of the predefined macros
A likely source of the predefined macros for a specific combination of compiler and platform is the Predef project at Sourceforge. They are attempting to maintain a catalog of all predefined macros in all C and C++ compilers on all platforms. In practice, they have coverage of a fair number of platforms for GCC, and a smattering of other compilers.
They achieved this through a combination of careful reading of documentation, as well as a shell script that figures out what macros are predefined the hard way: it tries them. My understanding is that it actually tries every string it can find in the executable image of the compiler and/or preprocessor to see if it has a predefined meaning.
They will happily add any info they don't have yet to their database.
A program may define a macro at one
point, remove that definition later,
and then provide a different
definition after that. Thus, at
different points in the program, a
macro may have different definitions,
or have no definition at all.