I've found some weird C++ preprocessor clauses, like:
#define COMPILER_FLOAT_ENTRIES_DO(template)
and
#define COMPILER_FLOAT_ENTRIES_DO(template) \
template(jvm_fadd) \
template(jvm_fsub) \
template(jvm_f2d)
What does passing "template" reserved word to a #define, and calling template(something) mean? I couldn't find anything at Google; probably because "#define" and "template" are really common words.
The entire code is at https://phoneme.dev.java.net/source/browse/phoneme/components/cldc/trunk/src/vm/share/ROM/ROMWriter.hpp?rev=19839&view=markup.
The word "template" is a coincidence here. The preprocessor isn't sensitive to reserved words in this way, as it largely just does text operations.
That is a standard macro that takes a function name as its argument and calls that function three times with those arguments. The first version of it with nothing after looks like a debug version or some other version designed to make it a no-op in some context.
#define COMPILER_FLOAT_ENTRIES_DO(template)
so COMPILER_FLOAT_ENTRIES_DO(x) gets replaced with with ''. In other words, it removes that macro from the code.
#define COMPILER_FLOAT_ENTRIES_DO(template) \
template(jvm_fadd) \
template(jvm_fsub) \
template(jvm_f2d)
so COMPILER_FLOAT_ENTRIES_DO(x) gets replaced with x(jvm_fadd) x(jvm_fsub) x(jvm_f2d).
If all else fails, you can see what is happening with macros by using g++ -E -o foo.cpp to leave the output of macro preprocessing in foo.cpp. Of course you'll need all the other compilation flags passed in by command line as well (especially -D and -I flags).
You often find this type of coding in Data-Driven Programming design patterns.
This is handy when you want to include several times the same file (the Data) but where macros are substituted with different code or other data.
Let's assume some attributes and there respective types:
/// #file data.h
my_attribute(color, int)
my_attribute(volume, float)
The coding part can use data without even needing to know the quantity.
As an example, let's print some information.
/// #file main.c
void help()
{
#define my_attibute(name,type) cout << #name << ": " << #type << endl;
cout << "available attributes:" << endl;
#include "data.h"
#undef my_attribute
}
(note the #name is used to get the text string "color" instead of a value color)
This way your code is independent from data.
Edit: fix typo and english sentence according to #RBerteig
Related
Presuming that your C++ compiler supports them, is there any particular reason not to use __FILE__, __LINE__ and __FUNCTION__ for logging and debugging purposes?
I'm primarily concerned with giving the user misleading data—for example, reporting the incorrect line number or function as a result of optimization—or taking a performance hit as a result.
Basically, can I trust __FILE__, __LINE__ and __FUNCTION__ to always do the right thing?
__FUNCTION__ is non standard, __func__ exists in C99 / C++11. The others (__LINE__ and __FILE__) are just fine.
It will always report the right file and line (and function if you choose to use __FUNCTION__/__func__). Optimization is a non-factor since it is a compile time macro expansion; it will never affect performance in any way.
In rare cases, it can be useful to change the line that is given by __LINE__ to something else. I've seen GNU configure does that for some tests to report appropriate line numbers after it inserted some voodoo between lines that do not appear in original source files. For example:
#line 100
Will make the following lines start with __LINE__ 100. You can optionally add a new file-name
#line 100 "file.c"
It's only rarely useful. But if it is needed, there are no alternatives I know of. Actually, instead of the line, a macro can be used too which must result in any of the above two forms. Using the boost preprocessor library, you can increment the current line by 50:
#line BOOST_PP_ADD(__LINE__, 50)
I thought it's useful to mention it since you asked about the usage of __LINE__ and __FILE__. One never gets enough surprises out of C++ :)
Edit: #Jonathan Leffler provides some more good use-cases in the comments:
Messing with #line is very useful for pre-processors that want to keep errors reported in the user's C code in line with the user's source file. Yacc, Lex, and (more at home to me) ESQL/C preprocessors do that.
FYI: g++ offers the non-standard __PRETTY_FUNCTION__ macro. Until just now I did not know about C99 __func__ (thanks Evan!). I think I still prefer __PRETTY_FUNCTION__ when it's available for the extra class scoping.
PS:
static string getScopedClassMethod( string thePrettyFunction )
{
size_t index = thePrettyFunction . find( "(" );
if ( index == string::npos )
return thePrettyFunction; /* Degenerate case */
thePrettyFunction . erase( index );
index = thePrettyFunction . rfind( " " );
if ( index == string::npos )
return thePrettyFunction; /* Degenerate case */
thePrettyFunction . erase( 0, index + 1 );
return thePrettyFunction; /* The scoped class name. */
}
C++20 std::source_location
C++ has finally added a non-macro option, and it will likely dominate at some point in the future when C++20 becomes widespread:
https://en.cppreference.com/w/cpp/utility/source_location
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1208r5.pdf
The documentation says:
constexpr const char* function_name() const noexcept;
6 Returns: If this object represents a position in the body of a function,
returns an implementation-defined NTBS that should correspond to the
function name. Otherwise, returns an empty string.
where NTBS means "Null Terminated Byte String".
The feature is present on GCC 11.2 Ubuntu 21.10 with -std=c++20. It was not on GCC 9.1.0 with g++-9 -std=c++2a.
https://en.cppreference.com/w/cpp/utility/source_location shows usage is:
main.cpp
#include <iostream>
#include <string_view>
#include <source_location>
void log(std::string_view message,
const std::source_location& location = std::source_location::current()
) {
std::cout << "info:"
<< location.file_name() << ":"
<< location.line() << ":"
<< location.function_name() << " "
<< message << '\n';
}
int main() {
log("Hello world!");
}
Compile and run:
g++ -std=c++20 -Wall -Wextra -pedantic -o main.out main.cpp
./main.out
Output:
info:main.cpp:17:int main() Hello world!
__PRETTY_FUNCTION__ vs __FUNCTION__ vs __func__ vs std::source_location::function_name
Answered at: What's the difference between __PRETTY_FUNCTION__, __FUNCTION__, __func__?
Personally, I'm reluctant to use these for anything but debugging messages. I have done it, but I try not to show that kind of information to customers or end users. My customers are not engineers and are sometimes not computer savvy. I might log this info to the console, but, as I said, reluctantly except for debug builds or for internal tools. I suppose it does depend on the customer base you have, though.
I use them all the time. The only thing I worry about is giving away IP in log files. If your function names are really good you might be making a trade secret easier to uncover. It's sort of like shipping with debug symbols, only more difficult to find things. In 99.999% of the cases nothing bad will come of it.
In my VC++ project I use a macro for debugging and logging purpose.
calling:
Logger(LogLevel::Info, "logging started");
macro:
#ifdef DEBUG
#define Logger(level, input) \
{ \
cerr << "[" << level << "] " << input << endl; \
};
#else
#define Logger();
#endif
When compiling this I get the following warning (but it still compiles):
warning C4002: too many actual parameters for macro 'Logger'
I am wondering how the compiler handles this situation.
Are the macro parameters still used for compiling? E.g. will one be able to see the "logging started" string on reverse engeneering?
I am wondering how the compiler handles this situation. Are the macro parameters still used for compiling?
Macros are processed in the pre-processing stage. If the pre-processor is able to deal with the extra arguments used in the usage of the macro, the only thing it can do is drop those parameters in the macro expansion.
E.g. will one be able to see the "logging started" string on reverse engeneering?
No, the code processed by the compiler will not have that line at all.
If you have the option to change those lines of code, I would recommend changing the non-debug definition of the macro to be a noop expansion. E.g.:
#define Logger(level, input) (void)level;
As per the law, a macro function must declare as many parameters as you call it with.
So calling your macro
#define Logger()
as Logger(LogLevel::Info, "logging started") results in an error. MSVC probably allows it because it isn't standard-compliant. There's not much to reason further (which is my answer to the actual question).
You either
#define Logger(unused,unused2)
and leave the replacement part empty or
#define Logger(...)
and suffer the consequences of being able to call with any number of arguments. [Hint: First one is recommended.]
When I'm trying to compile this code, it shows error:
main.cpp:19:3: error: invalid operands of types 'void' and 'int' to binary 'operator!='
This is the file:
#include <iostream>
#include <cstdio>
using namespace std;
#define $ DEBUG
#define DEBUG 1
#define _(out) do{ std::cout << __FILE__ << ":" << __LINE__ \
<< " " << out << '\n';}while(0)
#define _(out) printf(out);
int main(){
#ifdef LOCAL_PROJECT
#define DEBUG 0
#endif
$ && ({
_("eeeeewe");
});//line 19
return 0;
}
$ is simple name of DEBUG, in runtime it's 0 or 1.
The compilation error is for this source file.
how to get rid of this and compile?
There are some things you're doing here that are inadvisable, and some that are illegal. But I gave you an upvote for at least alerting me to a gcc extension I hadn't seen:
#include <iostream>
int main() {
int x = ({std::cout << "I'm surprised this prints "; 10 + 20;});
std::cout << x << "\n";
}
That does indeed output on IDEone I'm surprised this prints 30, even under C++14 settings. On coliru, though you get:
main.cpp:4:17: warning: ISO C++ forbids braced-groups within expressions [-Wpedantic]
Yet now that we've had our learning moment together, avoid non-standard extensions. Partly because people on StackOverflow will yell at you. But mostly for the reasons that life is hard enough trying to find terra firma in language development, education and usage when you stick to the subset that has been agreed upon and vetted by a large number of people who thought through the issues.
(The "language feature that one guy added that time for that project" is probably a bad idea--for any definition of "that one guy" or "that project".)
Also, something like that--being rarely used--probably has all kinds of lack of attention in the optimizer about getting that expression out. Which means at best it's slower than other ways, and at worst it has random bugs.
Moving on:
The use of $ in identifier names is apparently "implementation-defined behavior". Meaning there's nothing in the spec disallowing it...but nothing saying that a compiler has to implement it either. It's probably not something you want to be inventing new creative uses of, and only using if you're stuck in a situation bridging with old code on a VAX or something.
On the other hand, you simply you can't name any global variables or macros starting with an underscore. They are reserved for compiler implementations to use themselves. (If you read all that you'll see other unusual nuances, such as that you can't have identifiers beginning with an underscore and followed by a capital letter in ANY scope, although if the letter is lowercase you can define them locally. Often people use this for member variables but have to be careful to follow the rule.)
It's possible to use printf for purposes of compatibility...because of the explicit design to enable taking old C programs and slowly upgrade them to C++. But you shouldn't be writing new constructs or code using it, and if you want some basic philosophy on why then read the short paper Learning Standard C++ as a New Language. It's an old paper in its own right, but it's from Bjarne Stroustrup and works through that particular point pretty well.
Yet the "biggest" issue of why the approach is generally wrong is that there are much more reliable ways of doing this than trying to grab textual swaths of code into a macro. Many topics to study on that, such as the use of lambdas in C++11. But more generally you should focus on what appears to be your desire here, which is the subject area of logging. A quick search into a tag intersection could get you good advice on that:
Search Query for [c++] [logging] __FILE__
how to get rid of this and compile?
Introduce intermediate steps into the process.
Get rid of this...(code!)
Read through the links I've provided.
Look at approaches used to achieve this goal and assess what you like or don't like about them.
Write new code that uses better practices, or borrow from others.
...and compile. :-)
Remove the semicolon after the call to the macro, or just change the macro to remove the semicolon after printf(out).
Macros are especially inconvenient when they cause bugs like this. Because macros are directly substituted like a find+copy+paste, it can sometimes cause results that don't make sense.
#include <iostream>
#include <cstdio>
using namespace std;
#define $ DEBUG
#define DEBUG 1
#define _(out) do{ std::cout << __FILE__ << ":" << __LINE__ \
<< " " << out << '\n';}while(0)
#define _(out) printf(out);
int main(){
#ifdef LOCAL_PROJECT
#define DEBUG 0
#endif
$ && ({
_("eeeeewe")
});//line 19
return 0;
}
Is there a "best practice" or similar for coding in a debug-mode in one's code?
For example,
#include <iostream>
int main()
{
#ifdef MY_DEBUG_DEF
std::cout << "This is only printed if MY_DEBUG_DEF is defined\n";
#endif
return 0;
}
Or is this considered bad practice because the code gets bit messier?
I have noticed some libraries (for example libcurl, which is a large and well-known library) have this feature; if you define VERBOSE with libcurl you get basically a debug mode
Thank you.
A more usual way is to follow conventions from assert(3): wrap with #ifndef NDEBUG .... #endifcode which is only useful for debugging, and without any significant side effects.
You could even add some debug-printing macro like
extern bool wantdebug;
#ifndef NDEBUG
#define OUTDEBUG(Out) do { if (wantdebug) \
std::cerr << __FILE__ << ":" << __LINE__ \
<< " " << Out << std::endl; \
} while(0)
#else
#define OUTDEBUG(Out) do {}while(0)
#endif
and use something like OUTDEBUG("x=" << x) at appropriate places in your code. Then wantdebug flag would be set thru the debugger, or thru some program arguments. You probably want to emit a newline and flush cerr (or cout, or your own debug output stream) -using std::endl ...- to get the debug output displayed immediately (so a future crash of your program would still give sensible debug outputs).
That is an acceptable method. Yes, it gets messy, but it makes it a lot easier to debug as well. Plus you can normally collapse those kinds of things, thus removing the messiness.
As you've mentioned, libcurl uses the method. I also used to have a teacher who works for HP on their printer software, and they used the same method.
I personally prefer runtime enabled logging. That means that you don't have to recompile to get the "debug output". So I have a command-line argument -v=n, where n defaults to zero, and gets stored in the variable verbosity in the actual program. With -v=1 I get basic tracing (basic flow of the code), with -v=2 I get "more stuff" (such as dumps of internal state in selected functions). Two levels is often enough, but three levels may be good at times. An alternative is to make verbosity a bit-pattern, and enable/disable certain functionality based on which bits are set - so set bit 0 for basic trace, bit 1 gives extra info in some module, bit 2 gives extra trace in another module, etc. If you want to be REALLY fancy, you have names, such as -trace=all_basic, -trace=detailed, -trace=module_A, -trace=all_basic,module_A,module_B or some such.
Combine this with a macro along the lines of:
#define TRACE do { if (verbosity > 0) \
std::cout << __FILE__ << ":" << __LINE__ << ":" \
<< __PRETTY_FUNCTION__ << std::endl; } while(0)
For things that may take a substantial amount of extra time, such as verifying the correctness of a large and complex data structure (tree, linked list, etc), then using #ifndef NDEBUG around that code would be a good thing. Assuming of course you believe that you'll never mess that up in a release build.
Real livig code here:
https://github.com/Leporacanthicus/lacsap/blob/master/trace.h
https://github.com/Leporacanthicus/lacsap/blob/master/trace.cpp
being use here for example:
https://github.com/Leporacanthicus/lacsap/blob/master/expr.cpp
(Note that some simple functions that get called a lot don't have "TRACE" - it just clutters up the trace and makes it far too long)
Using logger may be better, e.g.
log4cxx
log4cpp
ACE_Log_Msg: It is in ACE
Boost.Log:
The above are very flexible, but heavyweight. You can also implement some simple macros instead:
#ifdef NDEBUG
#define DBG(FMT, ...)
#else // !NDEBUG
#define DBG(FMT, ...) fprintf (stderr, FMT, ## __VA_ARGS__)
#endif // NDEBUG
The above is GCC syntax from Macros with a Variable Number of Arguments.
For VC, please see also How to make a variadic macro (variable number of arguments)
Reading some C++ code I came across what I'll call a "functional" use of function Macros roughly as follows (this is a totally stylized example to make the point):
#define TOP_LEVEL(ARG1) \
ARG1("foo1","bar1") \
ARG1("foo2","bar2")
#define NEXT_LEVEL(ARG2A, ARG2B) \
cout << ARG2A << " and " << ARG2B;
TOP_LEVEL(NEXT_LEVEL)
I'm relatively new to the language and at first I couldn't figure this out, but then I ran it through just the preprocessor (g++ -E) and lo and behold it resolves to:
cout << "foo1" << " and " << "bar1"; cout << "foo2" << " and " << "bar2";
Do you see what it did there? It passed the Macro NEXT_LEVEL like a function pointer to the Macro TOP_LEVEL. Seeing how useful this could potentially be, I wanted to learn more about it: passing around functions to other functions is pretty sophisticated stuff and there must be at least something more to say about the technique.
Yet despite a ton of Googling I can't find evidence that this feature of the preprocessor even exists, let alone anything approaching documentation: here, here, here and here are just four examples of Macro tutorials that skip right past this; the last even has a section called "Advanced Macro tricks" - surely this qualifies!?
(Please note this is totally different than simply calling a function macro with another evaluated function macro as an argument- FOO(BAR(2)) is much more straightforward.)
My questions are:
Is there an actual name for this behavior?
Is it documented anywhere?
It is commonly used, or are there well known pitfalls, etc.?
The idea is coined "X-Macro". Some definitions won't include your particular example (X-macros generally are a bit more involved, with a file being included), but any relevant info. about this will fall under that term when searching.
As chris mentioned in the comments, Boost.Preprocessor uses this idea to great effect. Popular uses are: BOOST_PP_REPEAT, BOOST_PP_LIST_FOR_EACH, and most powerfully: BOOST_PP_ITERATE.
BOOST_PP_ITERATE is a "true" X-Macro; including a single file is expands to something dependent on a macro defined just prior. I show a more "proper" skeleton framework in this other answer, but an example would be:
// in xyz_data.def
DEFINE_XYZ(foo, 1, "Description A")
DEFINE_XYZ(bar, 5, "Description B")
DEFINE_XYZ(baz, 7, "Description C")
Then later when I just want column 1 I can do:
#define DEFINE_XYZ(name, number, desc) some_func(name)
#include "xyz_data.def"
And somewhere else where I want to generate some function for each one, I can do:
#define DEFINE_XYZ(name, number, desc) \
int BOOST_PP_CAT(get_number_for_, name)() \
{ \
std::clog << "Getting number, which is: " desc << std::endl; \
\
return number; \
}
#include "xyz_data.def"
You can then generate an enum where the name equals the number, etc.
The power is that when I want to add a new xyz, I just add it in one spot and it magically shows up everywhere it needs to be. I have done something like this in a very large codebase to keep some bookmarking data in one central place, but the various attributes were used differently in various locations.
Note that there is often no way around this; what I have are syntactically different, so no other language feature will generalize it for me to that level, only macros. Macros are not evil.
What you have is effectively an X-macro where the .def file is self-contained enough to be a #define. In other words, #include "xyz_data.def" is just TOP_LEVEL.
There is only one large downside to this, and ironically it's not the use of X-macros themselves but the effect they have on C and C++ compilers. The problem is that the preprocessor has allowed us to change the preprocessed result of a file every time its included, even if the file contents are exactly the same.
You may have heard that C and C++ are slow to compile compared to modern languages, this is one of the reasons why. It has no proper module/packaging system, just ad-hoc inclusion of other files. And we just learned, in general this cannot be avoided. Oops. (That said, compilers are smart and will note when you have include guards around a file, for example, and avoid processing it multiple times. But this is situational.)
That said, using X-Macros themselves shouldn't be a huge contributor to the compilation time of a real program. It's just that their mere potential existence reaches out into the real word and screws with compiler's heads.
Here is a few lectures : C is purely functionnal,
I suggest you take a look at libpp, macrofun,