Is there a way to evaluate an expression before stringification in c?
example:
#define stringify(x) #x
...
const char * thestring = stringify( 10 * 50 );
The problem is that I want to get
const char * thestring = "500";
And not:
const char * thestring = "10 * 50";
Can this be done?
The C preprocessor cannot do that, so use snprintf instead:
char *stringify(int n) {
char *res = malloc(12);
snprintf(res, 12, "%d", n);
return res;
}
Usage
const char *thestring = stringify(10 * 50);
NB
For simplicity's sake I've omitted error control and free.
You probably won't like the format in which the expression is going to be presented, yes, it is possible, but in a very eclectic way - you'd need to create a separate functional language that is being "run" by the preprocessor. The proof:
$ cvs -d:pserver:anonymous#chaos-pp.cvs.sourceforge.net:/cvsroot/chaos-pp login
$ cvs -z3 -d:pserver:anonymous#chaos-pp.cvs.sourceforge.net:/cvsroot/chaos-pp co -P chaos-pp
$ cvs -z3 -d:pserver:anonymous#chaos-pp.cvs.sourceforge.net:/cvsroot/chaos-pp co -P order-pp
$ cd order-pp/example
$ grep -A 6 'int main' fibonacci.c
int main(void) {
printf
("The 500th Fibonacci number is "
ORDER_PP(8stringize(8to_lit(8fib(8nat(5,0,0)))))
".\n");
return 0;
}
$ cpp -I../inc fibonacci.c 2>/dev/null | grep -A 6 'int main'
int main(void) {
printf
("The 500th Fibonacci number is "
"139423224561697880139724382870407283950070256587697307264108962948325571622863290691557658876222521294125"
".\n");
return 0;
}
In this example we have newly-made preprocessor-run purely functional language being used to calculate 500th Fibonacci number and then stringize it to give to C compiler.
Of course I very much doubt that this is something that you'd ever use in practice, and it is a very far stretched abuse of the preprocessor, but I consider it to be a very thought-provoking hack. (and yes, without the exotic theoretical twists like this one, it's not possible).
I'll take a wild guess that you have more experience in scripting languages than in C.
There are multiple phases you have to be aware of with a purely compiled language like C: Preproccesing, Compiling, Linking, and Running
First the preprocessor is run. That is where your macro gets expanded. At this point, its contents are "10 * 50". Not much to be done about that.
After the macro pre-processor completes, then the compiler converts the program into an object file
After the compiler finishes on every source file, the linker steps in and slaps them all together.
Finally, when your user is ready, they execute your program. Semanticly, this is when the 10 * 50 gets calculated. (In actuality, most compilers will recognize that this will always be the same value, and replace it with 500, but that's an implementation detail).
Scripting languages like to blur all these lines, so I can see where someone used to one of those might be confused.
Preprocessor macros are run before the compiler. It is, by definition, not possible to do exactly what you'retrying to do.
To convert a number into a string at runtime, call the itoa function, like this:
char thestring[8];
itoa(10 * 50, thestring, 10);
Note that this code declares thestring as an array, not a pointer. For more information, read about memory management in C.
You need to interpret the string. C doesn't do that by itself, look up a library that'll do it for you.
http://expreval.sourceforge.net/
http://www.codeproject.com/KB/library/expreval.aspx
There are others, just search google.
You could write a script (perl?) to use as preprocessor which recognizes the strings to evaluate, evaluates them and then it calls the true cpp on the "evaluated" file.
Maybe it could work.
As the other responses have said, this cannot be done with the C preprocessor. This is one of the many shortcomings of C that are solved by C++, This is the sort of thing that can be accomplished in a very elegant manner using Template Metaprogramming.
To calculate an arithmetic expression at compile time:
#include <boost/mpl/arithmetic.hpp>
namespace mpl = boost::mpl;
int main(int argc, char *argv[]) {
const int n = mpl::multiplies<mpl::int_<10>, mpl::int_<50> >::value;
return 0;
}
Here's a string formatting metafunction I found on the boost mailing list archives. This version will convert an int (like the one calculated above) into a string in a base of your choosing:
#include <boost/mpl/string.hpp>
#include <boost/mpl/vector_c.hpp>
#include <boost/mpl/at.hpp>
#include <boost/mpl/if.hpp>
#include <boost/mpl/int.hpp>
#include <boost/mpl/bool.hpp>
#include <boost/mpl/identity.hpp>
#include <boost/mpl/push_back.hpp>
namespace mpl = boost::mpl;
struct itoa_ct
{
// radix for _itoa() goes up to 36, but only bother with 16 here
typedef mpl::vector_c<char
,'0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'
> radix_t;
template <int Radix, unsigned int Quotient>
struct radix_convert
{
typedef typename mpl::push_back<
typename radix_convert<Radix, Quotient / Radix>::type
, mpl::char_<mpl::at_c<radix_t, Quotient % Radix>::type::value>
>::type type;
};
template <int Radix>
struct radix_convert<Radix, 0>
{
typedef mpl::string<> type;
};
template <int I, int Radix = 10>
struct apply
{
// All bases != 10 consider I as unsigned
typedef typename radix_convert<
Radix, static_cast<unsigned int>((Radix == 10 && I < 0) ? -I : I)
>::type converted_t;
// Prefix with '-' if negative and base 10
typedef typename mpl::if_<
mpl::bool_<(Radix == 10 && I < 0)>
, mpl::push_front<converted_t, mpl::char_<'-'> >
, mpl::identity<converted_t>
>::type::type type;
};
};
Putting the two together your expression becomes:
const char *thestring = mpl::c_str<itoa_ct::apply<mpl::multiplies<mpl::int_<10>, mpl::int_<50> >::value>::type>::value;
... and this all gets turned into nothing more than a constant string "500" at compile time :-)
Related
I am having a code which requires to concatenate strings as shown below:
#define CMD(A,B) CMD_##A_PROMPT##B
void main()
{
int a = 10, b = 5;
printf("%s\n", CMD(a, b));
}
the desired output is: CMD10_PROMPT5
Can this be achieved by any means?
I don't think that this can be done, because the macro you're looking for is a compile-time "stringification", an the parameters receive their values at run-time.
If you're looking for run-time "stringification", use sprintf and the like.
You can do it by replacing int a = 10, b = 5; with:
#define a 10
#define b 5
Otherwise it's not possible. C translation occurs in a series of phases defined in the standard, and preprocessing phase occurs before any object definitions are parsed. As far as the preprocessor is concerned, int a = 10 does not establish any relationship between the token a and the token 10.
If all you're after is the output, do it like this:
#define CMD_PATTERN "CMD_%d_PROMPT%d"
int main() {
int a = 10, b = 5;
printf(CMD_PATTERN "\n", a, b);
}
There's unfortunate requirement that the arguments are supplied in the same order that they appear in the pattern - this makes it difficult to change the order in future. For that reason, it might be better to define a formatting function rather than just a pattern.
At the end of the article here: http://www.learncpp.com/cpp-tutorial/45-enumerated-types/, it mentions the following:
Finally, as with constant variables, enumerated types show up in the debugger, making them more useful than #defined values in this regard.
How is the bold sentence above achieved?
Thanks.
Consider this code,
#define WIDTH 300
enum econst
{
eWidth=300
};
const int Width=300;
struct sample{};
int main()
{
sample s;
int x = eWidth * s; //error 1
int y = WIDTH * s; //error 2
int z = Width * s; //error 3
return 0;
}
Obviously each multiplication results in compilation-error, but see how the GCC generates the messages for each multiplication error:
prog.cpp:19: error: no match for
‘operator*’ in ‘eWidth * s’
prog.cpp:20: error: no match for
‘operator*’ in ‘300 * s’
prog.cpp:21: error: no match for
‘operator*’ in ‘Width * s’
In the error message, you don't see the macro WIDTH which you've #defined, right? That is because by the time GCC makes any attempt to compile the line corresponds to second error, it doesn't see WIDTH, all it sees only 300, as before GCC compiles the line, preprocessor has already replaced WIDTH with 300. On the other hand, there is no any such thing happens with enum eWidth and const Width.
See the error yourself here : http://www.ideone.com/naZ3P
Also, read Item 2 : Prefer consts, enums, and inlines to #defines from Effective C++ by Scott Meyers.
enum is compile time constant with debug info with no storage allocation.
const is allocated with a storage, depending on whether it is optimised away by the compiler with constant propagation.
#define has no storage allocation.
#define values are replaced by the pre-processor with the value they are declared as, so in the debugger, it only sees the value, not the #defined name, e.g. if you have #define NUMBER_OF_CATS 10, in the debugger you'll see only 10 (since the pre-processor has replaced every instance of NUMBER_OF_CATS in your code with 10.
An enumerated type is a type in itself and the values are constant instances of this type, and so the pre-processor leaves it alone and you'll see the symbolic description of the value in the debugger.
The compiler stores enum information in the binary when the program is compiled with certain options.
When a variable is of a enum type, a debugger can show the enum name. This is best shown with an example:
enum E {
ONE_E = 1,
};
int main(void)
{
enum E e = 1;
return 0;
}
If you compile that with gcc -g you can try out the following in gdb:
Reading symbols from test...done.
(gdb) b main
Breakpoint 1 at 0x804839a: file test.c, line 8.
(gdb) run
Starting program: test
Breakpoint 1, main () at test.c:7
7 enum E e = 1;
(gdb) next
9 return 0;
(gdb) print e
$1 = ONE_E
(gdb)
If you used a define, you would not have a proper type to give e, and would have to use an integer. In that case, the compiler would print 1 instead of ONE_E.
The -g flag asks gdb to add debugging information to the binary. You can even see that it is there by issuing:
xxd test | grep ONE_E
I don't think that this will work in all architectures, though.
At least for Visual Studio 2008 which I currently have at hand, this sentence is correct. If you have
#define X 3
enum MyEnum
{
MyX = 3
};
int main(int argc, char* argv[])
{
int i = X;
int j = (int)MyX;
return 0;
}
and you set a breakpont in main, you can hover your mouse over "MyX" and see that it evaluates to 3. You do not see anything useful if you hover over X.
But this is not a language property but rather IDE behavior. Next versions might do it differently, as well as others IDEs. So just check it out for your IDE to see if this sentence applies in your case.
I am answering too late but i feel i can add something -
enum vs. const vs. #define
enum -
Does not require assining values (if just want to have sequential values 0, 1, 2..) whereas in case of #defines you manually need to manage values which could cause human error sometime
It works just as variable to during online debugging the value of enum can be watched in watch window
You can have a variable of enum type to which you can assign an enum
typedef enum numbers
{
DFAULT,
CASE_TRUE,
CASE_OTHER,
};
int main(void)
{
numbers number = CASE_TRUE;
}
const -
It is constant stored in read only area of memory but can be accessed using address which is not possible in case of #define
You have type check in your hand if you use const rather than #define
defines are pre-processing directive but const is compile time
for example
const char *name = "vikas";
You can access the name and use its base address to read the such as vikas[3] to read 'a' etc.
#defines -
are dumb preprocessor directives which does textual replacement
Check the following article, nice summary
http://www.queryhome.com/26340/define-vs-enum-vs-constant
What should be done for DD ?
if
#define HEADING_TITLE_PROJECT_NAME "<= Version Maintenance Based On Compiled DateTime =>"
#define SIZE_OF_HEADER_FOR_DECORATION_PURPOSE sizeof(HEADING_TITLE_PROJECT_NAME)
#define DD ????
#define HEADING "\r\n"DD"\r\n"HEADING_TITLE_PROJECT_NAME"\r\n"DD"\r\n"
I want to get HEADING string literal as follows:
<==================================================>
<= Version Maintenance Based On Compiled DateTime =>
<==================================================>
The = sign or anything I put once will repeat within <== ... ==> to fill the HEADING_TITLE_PROJECT_NAME space.
Can it be done this way or other.
I only want to change the HEADING_TITLE_PROJECT_NAME in coding time and nothing else.
JUST THOUGHT IF IT CAN BE DONE
:)
<==Edit start==>
Something like
#define DD\
char * get()\
{\
char arr[100] = '\0';\
for (int i=0; i < SIZE_OF_HEADER_FOR_DECORATION_PURPOSE - 1; i++)\
{\
arr[i] = "=";\
}\
return arr;\
}
<==Edit ends==>
Unfortunately, there's no automatic way to generate DD in the standard C preprocessor, as long as you want to use it the way you use in the definition of HEADING macro.
As long as you insist of having that HEADING defined they way it is currently defined, I can only suggest using a semi-automatic approach :). Define DD manually, explicitly.
#define HEADING_TITLE_PROJECT_NAME "<= Version Maintenance Based On Compiled DateTime =>"
#define DD "<==================================================>"
And then just add
STATIC_ASSERT(sizeof HEADING_TITLE_PROJECT_NAME == sizeof DD);
right under it (with your favorite implementation of STATIC_ASSERT). That way any discrepancy in DD's length will immediately trigger an error and force the developer to update the DD.
This is impossible because of sizeof is evaluated after the preprocessor, rather than before.
If you knew the length of the string in advance, it would be.
Because the proprocessor doesn't have any looping constructs, you wind up creating them. Boost does it something like this
#define REPEAT_TIMES(macro, n) REPEAT##n(macro)
#define REPEAT1(macro) MACRO
#define REPEAT2(macro) REPEAT1(macro)MACRO
#define REPEAT3(macro) REPEAT2(macro)MACRO
....
You would then simply:
#define FILLER "="
#define DD "<"REPEAT_TIMES(FILLER, 34)">"
Your implementation of DD isn't a bad idea, though it suffers from some poor syntax and undefined behavior.
const char *DDD(void)
{
static char arr[] = HEADING_TITLE_PROJECT_NAME;
if(arr[2] == ' ')
for(size_t i = 2; i + 3 < sizeof arr; i++)
arr[i] = '=';
return arr;
}
#define DD DDD()
You can't return a pointer to stack data, so you have to use a static array. We can make sure it's the right size by having it automatically set to the #defined string, then checking if it's been filled with '=' yet and, if not, fill it. Then we return a const pointer to it so that no one tries to modify it.
Your macro defines a function, get, with unspecified arguments, and returning a modifiable char * to stack data. Unfortunately, this function will be defined everywhere you use the macro, which will result in many multiple definition errors.
You can't use this with raw string concatenation, but it will work for everything else you want.
I have code like
#define ONE 1
#define TWO 2
#define SUM (ONE+TWO)
How do I dump SUM as "3", the resolved value, in gcc 4.3+?
gcc -dM -E foo.h only seems to dump it as is. How do I get the actual value like it's inserted on compilation stage?
You can't. As far as the compiler is concerned, the line printf("%d\n", SUM) before preprocessing is indistinguishable from the line printf("%d\n", 1+2). The compiler just happens to perform an optimization called constant folding, even at the default optimization level (-O0), which turns the result into a constant 3 at runtime.
There's not really a good way to see the output of these optimizations. You could use the -S option to view the generated assembly code and see what that looks like, but if your program is anything larger than a toy, that will be a lot of manual effort. You could also look at the parse tree by using one of the -fdump-tree options (see the GCC man page).
You can't "dump" SUM as 3 because SUM isn't 3 in any meaningful sense, it's just a sequence of the three tokens ONE, + and TWO. What it turns into depends on the context where it is expanded.
Macros are expanded where they appear in the source, macro replacements are just strings of tokens until then.
You can test this like this.
#include <stdio.h>
#define ONE 1
#define TWO 2
#define SUM ONE+TWO
int a = SUM;
#undef ONE
#define ONE 2
int b = SUM;
int main()
{
printf("a = %d\nb = %d\n", a, b);
return 0;
}
Here's another example:
#include <stdio.h>
#define ONE 1
#define TWO 2
#define SUM ONE+TWO
int main()
{
/* prints 6, not 2 */
printf("5 - SUM = %d\n", 5 - SUM);
return 0;
}
With this example there's no way you can justify SUM being 3.
Contrary to the other answers, there's definitely a solution to this problem, especially with gcc extensions. Parse the output of gcc -dM and generate a C file containing lines of the form __typeof__(MACRO) foo = MACRO; and go from there. Without __typeof__ you could still handle all arithmetic types fairly well by just using long double.
One way is to stop at the precompiler stage (-E) and examine that output.
Is there any way to use a sizeof in a preprocessor macro?
For example, there have been a ton of situations over the years in which I wanted to do something like:
#if sizeof(someThing) != PAGE_SIZE
#error Data structure doesn't match page size
#endif
The exact thing I'm checking here is completely made up - the point is, I often like to put in these types of (size or alignment) compile-time checks to guard against someone modifying a data-structure which could misalign or re-size things which would break them.
Needless to say - I don't appear to be able to use a sizeof in the manner described above.
There are several ways of doing this.
Following snippets will produce no code if sizeof(someThing) equals PAGE_SIZE; otherwise they will produce a compile-time error.
1. C11 way
Starting with C11 you can use static_assert (requires #include <assert.h>).
Usage:
static_assert(sizeof(someThing) == PAGE_SIZE, "Data structure doesn't match page size");
2. Custom macro
If you just want to get a compile-time error when sizeof(something) is not what you expect, you can use following macro:
#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
Usage:
BUILD_BUG_ON( sizeof(someThing) != PAGE_SIZE );
This article explains in details why it works.
3. MS-specific
On Microsoft C++ compiler you can use C_ASSERT macro (requires #include <windows.h>), which uses a trick similar to the one described in section 2.
Usage:
C_ASSERT(sizeof(someThing) == PAGE_SIZE);
Is there anyway to use a "sizeof" in a pre-processor macro?
No. The conditional directives take a restricted set of conditional expressions; sizeof is one of the things not allowed.
Preprocessing directives are evaluated before the source is parsed (at least conceptually), so there aren't any types or variables yet to get their size.
However, there are techniques to getting compile-time assertions in C (for example, see this page).
I know it's a late answer, but to add on to Mike's version, here's a version we use that doesn't allocate any memory. I didn't come up with the original size check, I found it on the internet years ago and unfortunately can't reference the author. The other two are just extensions of the same idea.
Because they are typedef's, nothing is allocated. With the __LINE__ in the name, it's always a different name so it can be copied and pasted where needed. This works in MS Visual Studio C compilers, and GCC Arm compilers. It does not work in CodeWarrior, CW complains about redefinition, not making use of the __LINE__ preprocessor construct.
//Check overall structure size
typedef char p__LINE__[ (sizeof(PARS) == 4184) ? 1 : -1];
//check 8 byte alignment for flash write or similar
typedef char p__LINE__[ ((sizeof(PARS) % 8) == 0) ? 1 : 1];
//check offset in structure to ensure a piece didn't move
typedef char p__LINE__[ (offsetof(PARS, SUB_PARS) == 912) ? 1 : -1];
I know this thread is really old but...
My solution:
extern char __CHECK__[1/!(<<EXPRESSION THAT SHOULD COME TO ZERO>>)];
As long as that expression equates to zero, it compiles fine. Anything else and it blows up right there. Because the variable is extern'd it will take up no space, and as long as no-one references it (which they won't) it won't cause a link error.
Not as flexible as the assert macro, but I couldn't get that to compile in my version of GCC and this will... and I think it will compile just about anywhere.
The existing answers just show how to achieve the effect of "compile-time assertions" based on the size of a type. That may meet the OP's needs in this particular case, but there are other cases where you really need a preprocessor conditional based on the size of a type. Here's how to do it:
Write yourself a little C program like:
/* you could call this sizeof_int.c if you like... */
#include <stdio.h>
/* 'int' is just an example, it could be any other type */
int main(void) { printf("%zd", sizeof(int); }
Compile that. Write a script in your favorite scripting language, which runs the above C program and captures its output. Use that output to generate a C header file. For example, if you were using Ruby, it might look like:
sizeof_int = `./sizeof_int`
File.open('include/sizes.h','w') { |f| f.write(<<HEADER) }
/* COMPUTER-GENERATED, DO NOT EDIT BY HAND! */
#define SIZEOF_INT #{sizeof_int}
/* others can go here... */
HEADER
Then add a rule to your Makefile or other build script, which will make it run the above script to build sizes.h.
Include sizes.h wherever you need to use preprocessor conditionals based on sizes.
Done!
(Have you ever typed ./configure && make to build a program? What configure scripts do is basically just like the above...)
What about next macro:
/*
* Simple compile time assertion.
* Example: CT_ASSERT(sizeof foo <= 16, foo_can_not_exceed_16_bytes);
*/
#define CT_ASSERT(exp, message_identifier) \
struct compile_time_assertion { \
char message_identifier : 8 + !(exp); \
}
For example in comment MSVC tells something like:
test.c(42) : error C2034: 'foo_can_not_exceed_16_bytes' : type of bit field too small for number of bits
Just as a reference for this discussion, I report that some compilers get sizeof() ar pre-processor time.
JamesMcNellis answer is correct, but some compilers go through this limitation (this probably violates strict ansi c).
As a case of this, I refer to IAR C-compiler (probably the leading one for professional microcontroller/embedded programming).
#define SIZEOF(x) ((char*)(&(x) + 1) - (char*)&(x)) might work
In C11 _Static_assert keyword is added. It can be used like:
_Static_assert(sizeof(someThing) == PAGE_SIZE, "Data structure doesn't match page size")
In my portable c++ code ( http://www.starmessagesoftware.com/cpcclibrary/ ) wanted to put a safe guard on the sizes of some of my structs or classes.
Instead of finding a way for the preprocessor to throw an error ( which cannot work with sizeof() as it is stated here ), I found a solution here that causes the compiler to throw an error.
http://www.barrgroup.com/Embedded-Systems/How-To/C-Fixed-Width-Integers-C99
I had to adapt that code to make it throw an error in my compiler (xcode):
static union
{
char int8_t_incorrect[sizeof( int8_t) == 1 ? 1: -1];
char uint8_t_incorrect[sizeof( uint8_t) == 1 ? 1: -1];
char int16_t_incorrect[sizeof( int16_t) == 2 ? 1: -1];
char uint16_t_incorrect[sizeof(uint16_t) == 2 ? 1: -1];
char int32_t_incorrect[sizeof( int32_t) == 4 ? 1: -1];
char uint32_t_incorrect[sizeof(uint32_t) == 4 ? 1: -1];
};
After trying out the mentioned macro's, this fragment seems to produce the desired result (t.h):
#include <sys/cdefs.h>
#define STATIC_ASSERT(condition) typedef char __CONCAT(_static_assert_, __LINE__)[ (condition) ? 1 : -1]
STATIC_ASSERT(sizeof(int) == 4);
STATIC_ASSERT(sizeof(int) == 42);
Running cc -E t.h:
# 1 "t.h"
...
# 2 "t.h" 2
typedef char _static_assert_3[ (sizeof(int) == 4) ? 1 : -1];
typedef char _static_assert_4[ (sizeof(int) == 42) ? 1 : -1];
Running cc -o t.o t.h:
% cc -o t.o t.h
t.h:4:1: error: '_static_assert_4' declared as an array with a negative size
STATIC_ASSERT(sizeof(int) == 42);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
t.h:2:84: note: expanded from macro 'STATIC_ASSERT'
...typedef char __CONCAT(_static_assert_, __LINE__)[ (condition) ? 1 : -1]
^~~~~~~~~~~~~~~~~~~~
1 error generated.
42 isn't the answer to everything after all...
To check at compile time the size of data structures against their constraints I've used this trick.
#if defined(__GNUC__)
{ char c1[sizeof(x)-MAX_SIZEOF_X-1]; } // brakets limit c1's scope
#else
{ char c1[sizeof(x)-MAX_SIZEOF_X]; }
#endif
If x's size is greater or equal than it's limit MAX_SIZEOF_X, then the gcc wil complain with a 'size of array is too large' error. VC++ will issue either error C2148 ('total size of array must not exceed 0x7fffffff bytes') or C4266 'cannot allocate an array of constant size 0'.
The two definitions are needed because gcc will allow a zero-sized array to be defined this way (sizeof x - n).
The sizeof operator is not available for the preprocessor, but you can transfer sizeof to the compiler and check the condition in runtime:
#define elem_t double
#define compiler_size(x) sizeof(x)
elem_t n;
if (compiler_size(elem_t) == sizeof(int)) {
printf("%d",(int)n);
} else {
printf("%lf",(double)n);
}