Does anyone know of a tutorial or a lesson on Preprocessor Directives?
I looked at MSDN Visual C++ refrence material but it is written in such a way that I barely understand it. I am looking for something that explains it in plain english!
This is a discussion on Online Resources for Preprocessor Directives within the C++ Programming forums, part of the General Programming Boards category; Does anyone know of a tutorial or a lesson on Preprocessor Directives? I looked at MSDN Visual C++ refrence material ...
Does anyone know of a tutorial or a lesson on Preprocessor Directives?
I looked at MSDN Visual C++ refrence material but it is written in such a way that I barely understand it. I am looking for something that explains it in plain english!
We're all Fu##ed aren't we?
Here is one: http://www.cplusplus.com/doc/tutorial/preprocessor.html
There really aren't many preprocessor directives. The ones you will most likely use are:
Honestly, I never really used anything else but those.Code:#define #include #ifdef #else #endif #if #pragma
Founder and avid member of the Internationsl Typo Associateion
How much explaining does #include, #define and #if take?
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
I support http://www.ukip.org/ as the first necessary step to a free Europe.
#define is quite complex - macro substitution has some strange rules.
There's also #error, which is very simple.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
I've never used #line myself, but I've used tools which have (i.e. bison).
I've often used defined(), which isn't a preprocessor directive, but it is related. And what about #elif?
(Side question: are you supposed to put double-quotes around the text after a #error directive?)
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
(Side answer: no.)
defined() is a preprocessor keyword.
#if cond1
#elif cond2
#endif
==
#if cond1
#else
#if cond2
#endif
#endif
Some other preprocessors don't support #elif, by the way.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
(Aside: thank you.)
As far as I know, #elif is ANSI standard . . . are you referring to other types of preprocessors, or what?
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
Old, old, old preprocessors. But they still exist in some unices.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
I believe there is also #ifndef, #undef and the string-ify operation.
QuantumPete
"No-one else has reported this problem, you're either crazy or a liar" - Dogbert Technical Support
"Have you tried turning it off and on again?" - The IT Crowd
Stringify, yes, and token concatenation.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Don't forget the Preprocessor variables too, like __LINE__ and such, if you want to learn about the Preprocessor capabilities. I used __LINE__ just the other day writing a return code checker macro when writing a C program that uses a lot of the new "xxxx_s" safe functions.
Mac and Windows cross platform programmer. Ruby lover.
Quote of the Day
12/20: Mario F.:I never was, am not, and never will be, one to shut up in the face of something I think is fundamentally wrong.
Amen brother!