This has been bugging me for some time, I came across this while solving some objective type questions in C.
#define SWAP(a,b,c) c t;t=a;a=b;b=t;
int main() {
int x=10,y=20;
SWAP(x,y,int);
}
The code gives the correct answer:
Working code
In C are we supposed to pass just a data type as an argument.This supposedly works here but I want to know how.Also two more questions related to this:
If I want to swap using pointers, will it work
Will this work if SWAP is defined as a function instead of a macro.
Macros are pre-processed before compilation and you can virtually write anything in macros that would be replaced. In function arguments, you can not pass data types as arguments.
Side note:
#define SWAP(a,b,c) do { c t;t=a;a=b;b=t; } while(0)
is a safer macro implementation than the one mentioned by you. Moreover name t is quite common. If either of the argument name is t, this won't work as expected, so better choose some rare name. Capital letters are usually preferred in macro definition.
for ex: #define SWAP(a,b,c) do { c MACRO_TEMP_;MACRO_TEMP_=a;a=b;b=MACRO_TEMP_; } while(0)
SWAP(x,y,int); Becomes c t;t=a;a=b;b=t; where all occurances of c are replaced with int, a with x and b with y. Resulting in: ìnt t; t = x; x = y; y = t;
To understand the macros better, you can see the pre-processed output of your code. Output on my computer:
$ cat q26727935.c
#define SWAP(a,b,c) c t;t=a;a=b;b=t;
int main() {
int x=10,y=20;
SWAP(x,y,int);
}
$ gcc -E q26727935.c
# 1 "q26727935.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "q26727935.c"
int main() {
int x=10,y=20;
int t;t=x;x=y;y=t;;
}
$
Macro is replacement at pre-processor stage, so swap will work even with pointers, although this is superfluous.
In function you can not pass data type as arguments, so it won't work.
Yes.
No.
First of all, you have to know that when you are using macros, the argument will be replaced as they are. So, if you call SWAP(a, b, int*), it will be replace with
int* t;t=a;a=b;b=t;
and then the code will be compiled.
But when you're using functions, that won't happen and you're unable to pass data type as an argument to a function.
Related
I have a function which executes a bunch of tests. Whenever a new test is created, the function gets one or two more lines. And - the result is pushed back into an array. So it goes something like this (simplified):
void foo(int *results) {
auto index { 0 };
results[i++] = test_1(some, args, here);
results[i++] = test_1(some, other_args, here);
results[i++] = test_2(some, args, here);
results[i++] = test_3(some, args, here);
// etc. etc.
}
void bar() {
auto results = new int/* magic */];
foo(results);
}
I want to use the number of statements in this function to allocate space for the results (the line in bar()). I cannot use a dynamically-reallocated structure like an std::vector or a list etc. - since I am precluded from allocating any memory due to hardware restrictions.
Now, I could just manually count the lines - and this would work. But then whenever I add another test I would have to remember to update the magical constant.
Is there some way to do the counting with the result usable for the "magic" expression?
Note: Since I'm a scrupulous man with no dignity, I am willing to stoop to the use of macros.
Speaking of macro hackery:
#include <iostream>
#define ADD_TEST(X) do { results[i++] = (X); (void)__COUNTER__; } while (0)
const int foo_start = __COUNTER__;
void foo(int *results) {
int i = 0;
ADD_TEST(100);
ADD_TEST(200);
ADD_TEST(300);
}
const int foo_end = __COUNTER__;
int main() {
int results[foo_end - foo_start - 1];
foo(results);
for (int i : results) {
std::cout << i << '\n';
}
}
It's slightly awful and __COUNTER__ is a non-standard extension in GCC and other compilers, but hey, it works.
The advantage is that it doesn't use any fancy C++ features, so in principle it should be compatible with older compilers and even C.
As you haven't specified any language version, though, did tag it with constexpr, I've solved this making use of C++17. This without any dirty macros. Instead, I'm relying on CTAD (Constructor template argument deduction).
First of all, I've assumed your functions are constexpr. That way, everything can be done at compile-time. (In the resulting code, you don't even see memory being used for the array.
constexpr int test_1(int a, int b, int c)
{
return a + b + c;
}
constexpr int test_2(int a, int b, int c)
{
return a * b * c;
}
This isn't strictly needed, however, it can move unneeded calculations to compile time. It also allows propagating constexpr upto the final variable. That way, you could guarantee that none of the calculations will happen at run-time.
static constexpr auto myArr = createFilledArray();
However, the most important part is CTAD. A new C++17 feature that allows deducing the template arguments of your class based on the values that are passed at the constructor.
Instead of first creating an array, I create the array directly with all the different values that you pass to it. Since you haven't provided any arguments in your example, I assume they are known at compile time, which is again required for the constexpr waterfall. However, more importantly, I assume the number of elements is known at compile time.
By constructing all arguments when calling the constructor of std::array, there is no need for specifying its template arguments (note also the auto as return type). This gets deduced as std::array<int, 3> for this example.
constexpr auto createFilledArray(){
std::array a
{
test_1(1, 2, 3),
test_1(4, 5, 6),
test_2(7, 8, 9),
};
return a;
}
int main(int, char**)
{
return myArr.size(); // Returns 3
}
Code at compiler explorer
From what I'm aware, there is a proposal for C++20 that is intended to make std::vector constexpr. However, none of the compilers I've tested at compiler explorer support this. This will most likely allow you to write code based on std::vector and use that at compile time. In other words, the allocated memory that represents your data, will be part of your executable.
A quick attempt of what your code could look like can be found here at compiler explorer. (However, it ain't compiling at this point)
I have been trying to use variadic macros to reduce redundant code in some SFINAE patterns I am using. Specifically, I would like to generate function definitions using variadic macros. (This question is not about SFINAE). For my application, I would like write a wrapper function that calls an existing member function. The actual application requires that I produce a templated struct with SFINAE specialization so there is some repetitive stuff that would be great to just have a macro take care of generating the struct and function. OK that is the motivation.
The following example dispenses with all of the SFINAE stuff and simply defines a struct with three static functions (f0, f1, f2) with different parameter lists, and tries to call these functions through global macro generated function. Why would you want to do this?? You wouldn't. But this is just to illustrate the problem that I was having for the SFINAE application.
#include<iostream>
struct Foo
{
static void f0()
{
std::cout<<"f0() called"<<std::endl;
}
static void f1(int a)
{
std::cout<<"f1("<<a<<") called"<<std::endl;
}
static double f2(int a, double b)
{
std::cout<<"f2("<<a<<","<<b<<") called"<<std::endl;
return a*b;
}
};
#define VA_LIST(...) __VA_ARGS__
#define FUNCTION_WRAPPER(NAME,RTYPE,PARAMS,ARGS)\
RTYPE NAME(PARAMS)\
{\
return Foo::NAME(ARGS);\
}
FUNCTION_WRAPPER(f0,void,VA_LIST(),VA_LIST())
FUNCTION_WRAPPER(f1,void,VA_LIST(int a),VA_LIST(a))
FUNCTION_WRAPPER(f2,double,VA_LIST(int a, double b), VA_LIST(a, b))
int main()
{
f0();
f1(1);
f2(1,4.2);
return 0;
}
OK. So the VA_LIST(...) __VA_ARGS__ enables the creation of a single variable list. The call:
FUNCTION_WRAPPER(f2,double,VA_LIST(int a, double b), VA_LIST(a, b))
utilizes to variable lists as argument 3 and 3. Note that the Parameter list and the Argument list have to be consistent with each other (i.e. variables passed in the Argument list better be declared in the Parameter list.
This seems to work for this example, although there are issues if we were to try to add an fixed argument to beginning of the call (e.g. Foo::NAME(fixedArg, ARGS) ). It appears that the ##__VA_ARGS trick to swallow the comma if the variable list is empty doesn't work with this approach.
So the questions I have is:
While this approach seems to work properly on both gcc and clang, I can't find any similar examples that uses multiple variable lists in this manner...which makes me a little nervous. Is this a valid approach?
So what is actually happening in this approach? How is the FUNCTION_WRAPPER macro able to handle two variable lists? Are the PARAMS and ARGS macro arguments simply being expanded in the body of the macro, or is there something more complex happening here?
Is there a way to use the ## trick to swallow preceding commas? Placing the ## preceding the PARAMS and ARGS values in the macro body result in a compilation error, as does placing the ## in the VA_LIST.
Sample code for this last case is:
#define VA_LIST2(...) __VA_ARGS__
#define FUNCTION_WRAPPER2(NAME,RTYPE,PARAMS,ARGS)\
RTYPE NAME##_2(PARAMS)\
{\
return Foo::NAME(1,ARGS);\
}
FUNCTION_WRAPPER2(f2,double,VA_LIST2(double b), VA_LIST2(b))
The error for the insertion of ## into the FUNCTION_WRAPPER body is
error: pasting "," and "VA_LIST" does not give a valid preprocessing token
return Foo::NAME(1,##ARGS);\
The compilation error for the insertion of ## into the VA_LIST macro body is:
error: '##' cannot appear at either end of a macro expansion
#define VA_LIST2(...) ##__VA_ARGS__
^
How is the FUNCTION_WRAPPER macro able to handle two variable lists?
C preprocessor first recognizes arguments of a macro, then expands the arguments, then replaces the body of the macro with the expansion of arguments.
Because macro arguments are first "recognized" before expanded, macro expansion inside arguments resulting in a comma doesn't change the count of arguments.
Is there a way to use the ## trick to swallow preceding commas?
Be aware that it is still a GNU extension. Standard alternative to GCC's ##__VA_ARGS__ trick?
Yes, just make them to VA_ARGS so you can ## them.
#define VA_LIST2(...) __VA_ARGS__
#define ADD_ONE(...) 1,##__VA_ARGS__
#define FUNCTION_WRAPPER2(NAME,RTYPE,PARAMS,ARGS)\
RTYPE NAME##_2(PARAMS)\
{\
return Foo::NAME(ADD_ONE(ARGS));\
}
FUNCTION_WRAPPER2(f2,double,VA_LIST2(), VA_LIST2())
FUNCTION_WRAPPER2(f2,double,VA_LIST2(double b), VA_LIST2(b))
Is this a valid approach?
Sure, it's great. I would drop VA_LIST from the call. Lists in preprocessor are just done with (...). Then, just apply VA_LIST on the (...) argument.
#define VA_LIST(...) __VA_ARGS__
#define FUNCTION_WRAPPER(NAME,RTYPE,PARAMS,ARGS)\
RTYPE NAME(VA_LIST PARAMS) \
{ \
return Foo::NAME(VA_LIST ARGS); \
}
FUNCTION_WRAPPER(f0,void,(),())
FUNCTION_WRAPPER(f1,void,(int a),(a))
FUNCTION_WRAPPER(f2,double,(int a, double b), (a, b))
#define ADD_ONE(...) 1,##__VA_ARGS__
#define FUNCTION_WRAPPER2(NAME,RTYPE,PARAMS,ARGS)\
RTYPE NAME##_2(VA_LIST PARAMS) \
{ \
return Foo::NAME(ADD_ONE ARGS); \
}
FUNCTION_WRAPPER2(f2,double,(), ())
FUNCTION_WRAPPER2(f2,double,(double b), (b))
Anyway, double b .... b you are repeating yourself, however it is very clean and very flexible. You might want to see How to use variadic macro arguments in both a function definition and a function call? , c++ variadic macro: how to retrieve arguments values where I'm passing types and variable names as separate tokens and splitting them later differently depending on if it's function parameter list or call parameters.
Lets say I have a function
void doStuff(vector<int> &a, int b, vector<int> &c> {
c = vector<int>(a.size());
for (int i = 0; i < a.size(); i++) {
c[i] = a[i] + b;
}
}
obviously, upon seeing the function, we know that "c" is the output.
For anybody who hasn't seen the function definition though, it remains a mystery unless i name c something like "output_c". Maybe I'm just being vein but I don't like naming things "ouput_xxx", is there any syntax candy for letting the user of the function know that its supposed to be the output?
Syntax, by itself, can be a guide to indicate which one is an input argument and which one is an output argument. However, an output argument can also serve as an input argument too. You cannot tell that by just looking at the signature.
Examples:
int foo(int arg); // The argument is copy by value. It can only be an input argument.
void foo(std::vector<int> const& arg); // The argument is by const&.
// It can only be an input argument.
void foo(std::vector<int>& arg); // The argument is by &. It can be:
// 1) an output argument.
// 2) an input and output argument.
// 3) an input argument (bad practice)
You could add a preprocessor directive:
#define OUT
and put it in the parameter list like so:
void doStuff(vector<int> &a, int b, OUT vector<int> &c) ...
I think I've seen some APIs do something like this. That way it is explicitly stated in the function signature but you don't have to modify the variable names. The code is also unchanged at compile time since OUT is not defined to be anything, it is just a defined symbol.
I think, though, I would rely on your own documentation when writing the function and/or return-by-value instead of doing something like this. You could also make use of the const keyword to flag a parameter that is guaranteed not to change - that's what the syntax is designed for.
I've got some code written in C (specifically targeted to gcc) that needs to also compile as C++ (g++). I've run into a construct I'm having difficulty dealing with.
There are some macros used in a lot of places which basically take the address of a constant, although they also work on non-constants. The construct winds up looking something like this:
int *iptr = (&(int){5});
What this essentially lets happen is a constant be specified, and then a pointer to that constant can be taken for use in a function that requires an int pointer, but only a constant is specified. Multiple values can also be specified inside the curley braces to construct an actual temporary array, too. And it works great.
Problem in, g++ does not like this at all, throwing
error: non-lvalue in unary `&'
Update: Looks like I can take the address of a constant in C++ by doing something like:
const int & ref = 5;
So that's the starting point for the direction I'm trying to take.
The following appears to work in both C and C++, although it only compiles under C++11, not C++03.
#ifdef __cplusplus
#define A(type,x) (&(const type &)(type)x)
#define Of(...) { __VA_ARGS__ }
#else
#define A(type,x) (&(type){x})
#define Of(...) __VA_ARGS__
#endif
Test Code:
int test(const void *ptr,int len) {
char *str = (char *)ptr;
int i;
for (i=0;i<len;i++) {
printf("%02X ",str[i]);
}
printf("\n");
return 0;
}
int main() {
test(A(int,5),4);
test(A(x,Of(5,6)),8);
int i=1,j=2;
test(A(x,Of(i,j)),8);
}
Edit: Whoops, not quite there. Doesn't work if the type is a pointer!
test(A(char *,9),4);
=>
error: invalid cast of an rvalue expression of type 'char*' to type 'const char*&'
Note: I'm abandoning this approach in favor of a different approach (compiling C code as C and linking it via C++) but will keep this answer up in case it is useful to somebody.
Suppose I have a macro defined as this:
#define FOO(x,y) \
do {
int a,b;
a = f(x);
b = g(x);
y = a+b;
} while (0)
When expanding the macro, does GCC "guarantee" any sort of uniqueness to a,b? I mean in the sense that if I use FOO in the following manner:
int a = 1, b = 2;
FOO(a,b);
After, preprocessing this will be:
int a = 1, b = 2;
do {
int a,b;
a = f(a);
b = g(b);
b = a+b;
} while (0)
Can/will the compiler distinguish between the a outside the do{} and the a inside the do? What tricks can I use to guarantee any sort of uniqueness (besides making the variables inside have a garbled name that makes it unlikely that someone else will use the same name)?
(Ideally functions would be more useful for this, but my particular circumstance doesn't permit that)
If we consider scoping of variables, it is guaranteed that a,b inside the do..while() will be different from the ones defined outside.
For your case, the a,b defined outside will not exist inside the do..while().
There are lots of things to watch out for when using MACROs.
Macros perform just string substitution. The semantic is low and the the compiler have a limited knowledge of the preprocessor (essentially #pragma which in fact is not a preprocessor keyword, and source line info).
In your case a and b are not initialized local value. Behavior is unpredictible.
Your expanded code is equivalent to the following one.
int a = 1, b = 2;
do {
int a___,b___;
a___ = f(a___);
b___ = g(b___);
b___ = a___+b___;
} while (0)
To avoid such case in c++ prefer the use of inline function or template.
If you use a c 1999 compliant compiler, you can use inline in c language.
http://en.wikipedia.org/wiki/Inline_function
In c you can make safer macro by defining longer variable and surrounding parameter by () :
#define FOO(x,y) \
do {
int FOO__a,FOO__b;
FOO__a = f(x);
FOO__b = g(x);
y = FOO__a+FOO__b + (y)*(y);
} while (0)
Note : I changed your example by adding a (y)*(y) to illustrate the case
It is also a good practice to use only once macro parameter.
This prevent side effects like that:
#define max(a,b) a>b?a:b
max(i++,--y)
Max will not return what you want.
Variables a and b are treated just as any local variables inside a local scope.
The C language guarantees that if those variables happen to have the same names as outer scope variables, the local variables will be the ones updated.
Here is an example to illustrate:
#include <stdio.h>
#define FOO(x) \
{ \
int a; \
a = x; \
printf("%d\n", a); \
}
int main()
{
int a = 1;
{
int a = 2;
printf("%d\n", a); // 2
FOO(3); // 3
printf("%d\n", a); // 2
}
printf("%d\n", a); // 1
getchar();
}
Now, of course it might be a bright idea to not name every single variable in your program "a" just because C guarantees that local variables take precedence. But technically there is nothing stopping you from it.
Btw MISRA-C bans naming like this, it require each variable no matter scope to have an unique name, for readability and maintenance reasons.
(As a sidenote, function-like macros is incredibly poor programming style and shouldn't be used. Use real functions instead, and inline them if performance is critical.)
There is no tricks other than garbling. The C and C++ preprocessors do not have the equivalent of lisp gensym or hygienic macros.
Nope, there is no guarantee of uniqueness.
Infact, your code is about to fail.
Macros are just like replacement of text.
I usually use crazy variable names if I am inside a macro, like this:
#define FOO(x,y) \
do {
int FOO_MACRO_a, FOO_MACRO_b;
FOO_MACRO_a = f(x);
FOO_MACRO_b = g(x);
y = FOO_MACRO_a + FOO_MACRO_b;
} while (0)
If you are targeting gcc and/or g++ then you can use their special macro block feature:
#define max(x, y) ({ typeof(x) a_ = (x); \
typeof(y) b_ = (y); \
(a_ > b_) ? a_ : b_ })
This allows you to create unique local variables, very much the same as writing a function.
Of course, for portability, it's not recommended. On the other hand, if you only plan to work on systems that offer gcc/g++, it will work on all of those.
Source: http://gcc.gnu.org/onlinedocs/gcc-3.0.1/cpp_3.html#SEC30
Further, with gcc / g++ you can use the -Wshadow command line option. In the event you inadvertently reuse a local variable with the same name, it will warn you. You can further use -Werror to transform those warnings in error. Now you can't compile if there is the possibility of a mixed up variable. You need to make sure to use a block, though. A do/while() as others have presented would do the job.
int a;
// code from macro;
do { int a = 5; ... } while(false);
With the combo I just described (-Wshadow + -Werror), you get an error when you do int a = 5.
You can actually make sure that regardless of what x and y are you won't have this problem by doing the following:
#define FOO(x,y) \
do\
{\
int x##y##a,x##y##b;\
x##y##a = f(x);\
x##y##b = g(x);\
y = x##y##a + x##y##b;\
} while (0)
By making sure a and b names contains x and y names you know they are different. But that's a really bad code and you probably shouldn't code like this.
Macros are textually expanded as is, modulo parameter replacement, so there's nothing the compiler can do to provide the sort of guarantee you're asking for -- as you can see in the expansion, the a parameter will refer to the inner a, not the outer one. The solution is indeed to use "garbled" names, e.g. int FOO_a, FOO_b;
In your macro that is indeed a danger and so is the possible reuse of x which is not guaranteed to be an l-value and could change by being used in the macro twice.
Even if you do need a macro, it can still be a light wrapper around an inline function, and one such that will take x and give you both f(x) and g(x) without possibly having to re-evaluate x would certainly be safe.
In your case something like:
template< typename T >
struct Foo
{
T& x;
explicit Foo(T&x_) : x(x_)
{
}
int f();
int g();
};
template<typename T>
Foo<T> makeFoo(T& x)
{
return Foo<T>(x);
}
#define FOO(x,y)
{
Foo FOO_VAR(x);
y = FOO_VAR.f() + FOO_VAR.g();
}
would be a safer way to do things. Of course if you don't need the macro at all, do away with it.