I'm working with very large integer literal defines eg:
#define X 999999999999
To improve readability I tried changing this to:
#define X 999/**/999/**/999/**/999
But the compiler was like "nah bru.."
Is there any way to make these more readable?
Just to clarify, this question is asking only about the appearance of the values in the source code. I'm not asking how to format these values in a printf or anything.
You can do this in a define (but not outside of a define):
#define X 999##111##333##444
I'm not sure that I'd recommend it, but it's legal. (## is the preprocessor token concatenation operator.)
You explicitly didn't ask about output formatting, so you're probably not interested in input formatting either, but both of them can be made locale-aware, which includes allowing locale-specific grouping characters.
You could do this:
#include <boost/preprocessor.hpp>
BOOST_PP_SEQ_CAT((345)(678)(901))
Which would show up in source code as:
345678901
Related
Using Tornado 2.2.1 GNU
at C/C++ compiler options I'm trying to define string as follow:
-DHELLO="Hello" and it doesn't work (it also failed for -DHELLO=\"Hello\" and for -DHELLO=\\"Hello\\" which works in other platforms)
define value -DVALUE=12 works without issue.
does anybody know to proper way to define string in Tornado?
The problem with such a macro is, that it normally isn't a string (in the C/C++ sense), just a preprocessor symbol. With numbers it works indeed, because preprocessor number can be used in C/C++ as is, but with string symbols, if you want to convert them to C/C++ strings (besides adding the escaped quotes) you need to "stringize" them.
So, this should work (without extra escaped quotes):
#define _STRINGIZE(x) #x
#define STRINGIZE(x) _STRINGIZE(x)
string s = STRINGIZE(HELLO)
(note the double expansion to get the value of the macro stringized, i.e. "Hello", instead of the macro name itself, i.e. "HELLO")
I'm making a wrapper for the string parser, which converts string to primitive types. I'm writing unit tests for it, so I need the string representation of the extreme values of these primitive types, so it is needed to stringify the standard macros such as INT_MIN and INT_MAX.
The normal stringify macros look like this:
#define STRINGIFY(content) #content
#define EXPAND_AND_STRINGIFY(input) STRINGIFY(input)
It works well for EXPAND_AND_STRINGIFY(SHRT_MAX), which will be expanded to "32767".
However, when it going to work with EXPAND_AND_STRINGIFY(SHRT_MIN), it will be expanded to "(-32767 -1)", because #define SHRT_MIN (-SHRT_MAX - 1). This is not what I want. Is there any possible workarounds for it?
No, there is no way to get a preprocessor macro to evaluate an arithmetic expression.
You can get the preprocessor to do arithmetic evaluate, but only in the context of #if, which allows you to evaluate a boolean expression. You can use that feature to rather laboriously output a number, but only by using preprocessor input in #included files, since you cannot put #if inside a macro.
You don't mention why you want to stringify INT_MIN, so I'm not in a position to offer an alternative, if indeed one exists.
However, it's most likely that your best bet is to simply produce the string at run-time, using snprintf.
I would like to do some debugging of my crazy macros, but there's no way to do it because macros generate code, not strings. I'd have to change the macros to emit strings in order for my program to print out the code that it would otherwise produce.
New in C++11 are R"delim("Raw Strings")delim", and I was hoping that there is some way to interpolate code-macros inside of one of these to turn that code into a string literal.
Raw string literals concatenate the same way as normal string literals.
#define MYMACRO "hello"
std::string blah = R"(first part -)" MYMACRO R"(- second part)";
std::cout << blah;
will output first part -hello- second part
If you want to debug your crazy macros, you'd probably get more mileage out of directly examining the preprocessed output. Any C/C++ compiler will have an option for this. In GCC it's -E; for MSVC, I don't recall where it is exactly, but one of the properties sections has "keep preprocessed output". When you do this, keep your #includes to a minimum, especially standard-library #includes; these can add hundreds or thousands of lines of code to the top of the preprocessed output.
I'm working on a project and have a problem that I believe can be solved with macros, but given the nature of the issue I don't have the experience to write one myself.
Here's what I would expect as input and output of the #define macro:
Inputting code such as this
printf(foobar(Hello World.));
Should result in the preprocessor producing code that reads:
printf((char *)(std::string("")+'H'+'e'+'l'+'l'+'o'+' '+'W'+'o'+'r'+'l'+'d'+'.').c_str());
I'm assuming something this complicated is possible, and I hope one of you guys can help me out.
I NEED IT TO BE A MACRO, I DO NOT want a string constant anywhere.
The only solution I can think of is to run your code through a suitable script (probably just some light awk), that does the substitution before your code reaches the pre-compiler.
Depending on your environment you could do this as a "Pre-Build Event" in Visual Studio, or just add a step directly into your makefile.
Uh, I fear it is impossible (unless I don't know something).
I believe there is no macro to split a given input token (e.g. Hello) into characters building it (H e l l o)
There were some attempts to do such thing, but I fear it is not exactly what you need:
C++: Can a macro expand "abc" into 'a', 'b', 'c'?
"More powerful precompiler" ?
Try this topic: Replacements for the C preprocessor
Macros are basically substitution or addition of strings.
You could do this with a pre-processor of your own, but the standard pre-processor won't split strings into component parts.
How about this:
Put all these (assuming there is more than one) 'macros' in a separate file. Write a program that translates them into the expansion you require and then include THAT file in your c program? You could then make the expansion program part of your make file so it's always up to date.
Using a separate file makes the expansion program much easier than parsing a c/c++ file.
Since you're looking for a narrow, direct answer to your question and without suggestions, here goes:
This is impossible. You must find a different solution to whatever it is you're trying to achieve.
Have you tried:
#define toString(x) #x
You can use it after like this:
printf("%s", toString(hello world));
Don't try to use printf directly with the string because you can have format specifier in the string.
printf(toString(hello world)); //wrong, you can have for example %d in the string
I'm trying to make a simple preprocessor loop. (I realize this is a horrible idea, but oh well.)
// Preprocessor.h
#ifndef PREPROCESSOR_LOOP_ITERATION
#define MAX_LOOP_ITERATION 16 // This can be changed.
#define PREPROCESSOR_LOOP_ITERATION 0
#endif
#if (PREPROCESSOR_LOOP_ITERATION < MAX_LOOP_ITERATION)
#define PREPROCESSOR_LOOP_ITERATION (PREPROCESSOR_LOOP_ITERATION + 1) // Increment PREPROCESSOR_LOOP_ITERATION.
#include "Preprocessor.h"
#endif
The issue is that it doesn't look like PREPROCESSOR_LOOP_ITERATION is being incremented, so it just keeps including itself infinitely. If I change the line to an actual integer (like 17), the preprocessor skips over the #include directive properly.
What am I doing incorrectly?
The "problem" is that macros are lazily evaluated. Consider your macro definition:
#define PREPROCESSOR_LOOP_ITERATION (PREPROCESSOR_LOOP_ITERATION + 1)
This defines a macro named PREPROCESSOR_LOOP_ITERATION and its replacement list is the sequence of five preprocessing tokens (, PREPROCESSOR_LOOP_ITERATION, +, 1, and ). The macro is not expanded in the replacement list when the macro is defined. Macro replacement only takes place when you invoke the macro. Consider a simpler example:
#define A X
#define B A
B // this expands to the token X
#undef A
#define A Y
B // this expands to the token Y
There is an additional rule that if the name of a macro being replaced is encountered in a replacement list, it is not treated as a macro and thus is not replaced (this effectively prohibits recursion during macro replacement). So, in your case, any time you invoke the PREPROCESSOR_LOOP_ITERATION macro, it gets replaced with
( PREPROCESSOR_LOOP_ITERATION + 1 )
then macro replacement stops and preprocessing continues with the next token.
You can perform limited arithmetic with the preprocessor by defining a sequence of macros and making use of the concatenation (##) operator, but it's quite tedious. You should consider using the Boost.Preprocessor library to help you with this. It will work with both C and C++ code. It allows for limited iteration, but what it does allow is extraordinarily useful. The closest feature that matches your use case is likely BOOST_PP_ITERATE. Other facilities like the sequence (BOOST_PP_SEQ) handlers are very helpful for writing generative code.
EDIT: As James pointed out, my original solution did not work due to lazy evaluation of macros. If your compiler supports it, the macro __COUNTER__ increments by one every time it is called, and you can use it to do a simple preprocessor loop like this:
// Preprocessor.h
#define MAX_LOOP_ITERATION 16 // Be careful of off-by-one
// do stuff
#if (__COUNTER__ < MAX_LOOP_ITERATION)
#include "Preprocessor.h"
#endif
I verified this in Visual C by running cl /P Preprocessor.h.
Seriously, find another way to do this.
The preprocessor should be relegated to include guards and simple conditional compilations.
Everything else it was ever useful for has a better way to do it in C++ (inlining, templates and so forth).
The fact that you state I realize this is a horrible idea ... should be a dead giveaway that you should rethink what you're doing :-)
What I would suggest is that you step back and tell us the real problem that you're trying to solve. I suspect that implementing recursive macros isn't the problem, it's a means to solve a problem you're having. Knowing the root problem will open up all sorts of other wondrous possibilities.