Preprocessor magic: Default Arguments in C(lefteris.realintelligence.net)
lefteris.realintelligence.net
Preprocessor magic: Default Arguments in C
http://lefteris.realintelligence.net/?p=593&
37 comments
The Linux kernel `container_of` and `offset_of` macros can be pretty handy when writing generic containers.
While those are both implemented as macros, I'd hardly call them "macro magic" at least not in the manner used by OP, or what I was talking about.
Both of those are actually rather simple macros doing what seems like a mess with pointers. The difference is subtle, but most strongly expressed in that the complexity is innate to the problem, and does not require mucking much with what is entirely weird macro behavior.
Both of those are actually rather simple macros doing what seems like a mess with pointers. The difference is subtle, but most strongly expressed in that the complexity is innate to the problem, and does not require mucking much with what is entirely weird macro behavior.
There are lots of magic in C and C++ that most people are unaware of or told never to do. But, that magic is used often by older programmers. For example, this is perfectly valid C++ (no compiler warnings or errors even with -Wall and -Wextra) it's roots are in C:
#include <iostream>
#include <boost/integer.hpp>
int main()
{
// Notice these signed types are going into unsigned types!
boost::uint64_t i = -9151314442815602945;
std::cout << i << std::endl;
unsigned int j = -327681234;
std::cout << j << std::endl;
return 0;
}Preprocessor magic is pretty much required if you want to write multiplatform code. I work on code for Solaris, Linux, and Windows, and makes life much easier to use #defines to standardize the OS calls.
"#define somefunc _someplatformfunc" isn't exactly preprocessor magic. That's just basic preprocessor functionality. "Magic" is the stuff that no one else looking at the code understands, and it's complicated and generally fragile and frankly unnecessary.
Or you write platform specific code in it's own files, and link it in conditionally.
port-linux.c
port-win32.c
port-solaris.c
myprog.c
In my experience this is a much better approach. Most modern compilers can inline across linker boundaries anyways, so it's not a real performance issue either.
Yes having platform specific code in its own header source and just #ifdef the includes provides much cleaner and nicer code
Don't even do that -- have one header that all the platform interfaces implement without ifdefs.
Keep the conditional compilation in the makefiles, not in the source.
Keep the conditional compilation in the makefiles, not in the source.
Hey all,
I am the author of the linked blog. Many nice comments in here, but may I start by a question of my own about hackernews itself. I had submitted this link myself 6 days ago after making the post. Can a link be resubmitted multiple times? The title was a bit different but the link was the same. I am new to the site and want to learn the way it works.
As for the comments by many people, it's a given that this will not appeal to all. Heck to most people especially C++ only programmers it will look ugly. The fact is that if for one reason or another you want to provide functions that have default arguments this is a neat and nice way that works for C99.
As for needing default arguments, well there might be cases where having them is just a way to spoil or even confuse the programmer. But consider an API. An API of a GUI library. Do you REALLY want to be giving all the customizations offered by the library for every single widget/element? Or do you want a TextBox of size(100,100) at position(200,50) and you are done by letting the default arguments handle all the rest?
I am the author of the linked blog. Many nice comments in here, but may I start by a question of my own about hackernews itself. I had submitted this link myself 6 days ago after making the post. Can a link be resubmitted multiple times? The title was a bit different but the link was the same. I am new to the site and want to learn the way it works.
As for the comments by many people, it's a given that this will not appeal to all. Heck to most people especially C++ only programmers it will look ugly. The fact is that if for one reason or another you want to provide functions that have default arguments this is a neat and nice way that works for C99.
As for needing default arguments, well there might be cases where having them is just a way to spoil or even confuse the programmer. But consider an API. An API of a GUI library. Do you REALLY want to be giving all the customizations offered by the library for every single widget/element? Or do you want a TextBox of size(100,100) at position(200,50) and you are done by letting the default arguments handle all the rest?
It looks like the submitter added a & to the end of the URL. This is generally considered to be cheating. I guess it worked out this time though... There are probably a few articles out there that will tell you the best time to submit a link. If you're really worried about getting karma/clicks, you should consult one of them.
No no, I don't care about karma, just discovered the site recently and wanted to learn how it works.
Exposure on the other hand is always a nice thing. I am actually really glad to the submitter since this generated a nice discussion in the blog itself and made me fix a few things I was wrong about.
> The advantages of having default arguments is not something that needs convincing. It's just very nice and convenient to have them.
The Google Style Guide disallows default arguments, and I find their rationale convincing enough that I never use default arguments in my own code: http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...
The Google Style Guide disallows default arguments, and I find their rationale convincing enough that I never use default arguments in my own code: http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...
I really don't find that convincing at all. Default arguments are one of the most effective ways of removing boilerplate and making code easier to read and write. Bad programmers will be bad programmers no matter what, and copy/pasted code that the coder doesn't understand will be fragile or broken no matter what.
The problem with this reasoning is contained in this:
> to force programmers to consider the API and the values they are passing for each argument rather than silently accepting defaults they may not be aware of.
All you will force poor coders to do will be to fudge the arguments until the code "works". This is actually worse than the default arguments scenario, because the defaults are more likely to be acceptable than the first value the coder stumbles upon that makes the function go.
The problem with this reasoning is contained in this:
> to force programmers to consider the API and the values they are passing for each argument rather than silently accepting defaults they may not be aware of.
All you will force poor coders to do will be to fudge the arguments until the code "works". This is actually worse than the default arguments scenario, because the defaults are more likely to be acceptable than the first value the coder stumbles upon that makes the function go.
For me it has nothing to do with bad programmers. It has to do with not having "hidden" input to a function. For example, consider a parsing function that has a boolean parameter indicating whether the parsing is "strict" or not. If you make this parameter have a default, it would be easy to use this function (or read code that uses it) without even realizing that the function can operate in more than one "mode." There is no indication at the call site what mode it is operating in, and indeed if the default value is flipped in the header file the caller could change behavior with no code change at the call site!
Taking a line from the Python philosophy: "explicit is better than implicit."
Taking a line from the Python philosophy: "explicit is better than implicit."
> It has to do with not having "hidden" input to a function.
Why would it be hidden? It's a default, customizable behavior. If you don't need to customize it you don't and there's no reason to task you with putting the method in the state which is going to be needed 9 times out of 10.
> and indeed if the default value is flipped in the header file the caller could change behavior with no code change at the call site!
And if the whole implementation is replaced by formatting your hard drive, the caller could change behavior with no code change at the call site!!
> Taking a line from the Python philosophy: "explicit is better than implicit."
You're probably misapplying/misunderstanding things, since Python is one of the languages making the most use out of default values and with extremely strong first-class support for them.
Why would it be hidden? It's a default, customizable behavior. If you don't need to customize it you don't and there's no reason to task you with putting the method in the state which is going to be needed 9 times out of 10.
> and indeed if the default value is flipped in the header file the caller could change behavior with no code change at the call site!
And if the whole implementation is replaced by formatting your hard drive, the caller could change behavior with no code change at the call site!!
> Taking a line from the Python philosophy: "explicit is better than implicit."
You're probably misapplying/misunderstanding things, since Python is one of the languages making the most use out of default values and with extremely strong first-class support for them.
> If you make this parameter have a default, it would be easy to use this function (or read code that uses it) without even realizing that the function can operate in more than one "mode."
So? I don't understand what the problem is. The very act of packaging code in a function is one that hides information about what that function does. And suppose you don't provide a default for the `strict` argument. Unless you're using a language with named function arguments (or an approximation thereof like Objective-C), you won't know that the `false` you see in the argument list means "don't use strict" anyway until you read the documentation. And once you're reading the documentation, this all becomes moot.
> There is no indication at the call site what mode it is operating in, and indeed if the default value is flipped in the header file the caller could change behavior with no code change at the call site!
Yeah, and if you reorder your function parameters, or rename your function, or change the "strict" argument to "lax", or an infinite number of other changes, you would also change behavior with no change at the call site. The solution in each case is "don't do that".
Again, the act of packaging code in a function is one that makes it so that changes in behavior can happen independent of the call site. Sometimes it works to your advantage. Sometimes it doesn't. That's just life.
So? I don't understand what the problem is. The very act of packaging code in a function is one that hides information about what that function does. And suppose you don't provide a default for the `strict` argument. Unless you're using a language with named function arguments (or an approximation thereof like Objective-C), you won't know that the `false` you see in the argument list means "don't use strict" anyway until you read the documentation. And once you're reading the documentation, this all becomes moot.
> There is no indication at the call site what mode it is operating in, and indeed if the default value is flipped in the header file the caller could change behavior with no code change at the call site!
Yeah, and if you reorder your function parameters, or rename your function, or change the "strict" argument to "lax", or an infinite number of other changes, you would also change behavior with no change at the call site. The solution in each case is "don't do that".
Again, the act of packaging code in a function is one that makes it so that changes in behavior can happen independent of the call site. Sometimes it works to your advantage. Sometimes it doesn't. That's just life.
> The very act of packaging code in a function is one that hides information about what that function does.
"What a function does" is encapsulated in that function's name. So for example you could have:
Once you have default parameters, the behavior of the function is no longer fully explicit, because some of the function's input comes from somewhere else:
Also, code itself is the most reliable documentation, but looking at the implementations of the functions involved won't reveal this extra input; only cross-referencing the header files will, which requires more mental effort for your reader.
"What a function does" is encapsulated in that function's name. So for example you could have:
GoToTheStore();
Go(store);
Once you have default parameters, the behavior of the function is no longer fully explicit, because some of the function's input comes from somewhere else:
Go(); // Goes to the store by default.
Also, code itself is the most reliable documentation, but looking at the implementations of the functions involved won't reveal this extra input; only cross-referencing the header files will, which requires more mental effort for your reader.
> "What a function does" is encapsulated in that function's name.
I would like to suggest that the function's name should tell you the result (going to the store) and not have anything to do with what the function does (walk, bike, drive, fly) to get that result. Parameters could restrict how the function gets the result. In which case, a default parameter of ANY means no restriction and makes perfect sense with actually less mental effort for the reader.
I would like to suggest that the function's name should tell you the result (going to the store) and not have anything to do with what the function does (walk, bike, drive, fly) to get that result. Parameters could restrict how the function gets the result. In which case, a default parameter of ANY means no restriction and makes perfect sense with actually less mental effort for the reader.
GoToTheStore(); /* get me to the store */
GoToTheStore(ANY); /* does ANY refer to any store? */
GoToTheStore(DRIVE); /* I'm feeling lazy, and don't want to walk. */C++ is filled with hidden input. The identity of the this pointer is hidden from the execution of the function. The identity of the function to be executed is hidden from the caller. If that's really your requirement, then you're using the wrong language, the ship sailed.
I agree with mistercow: default arguments are, on the whole, a Good Thing. Think of them as a restricted form of overloading which requires (much!) less code to be written.
Obviously they can be misused, but again, that's the nature of programming (and especially of C++). Sane default argument conventions make code easier to read and write.
I agree with mistercow: default arguments are, on the whole, a Good Thing. Think of them as a restricted form of overloading which requires (much!) less code to be written.
Obviously they can be misused, but again, that's the nature of programming (and especially of C++). Sane default argument conventions make code easier to read and write.
> The identity of the this pointer is hidden from the execution of the function.
Your argument makes no sense; the "this" pointer is just a function parameter, and the whole point of a function is that the arguments aren't fixed until the function is called. No part of this is implicit.
> The identity of the function to be executed is hidden from the caller.
The function is named at the call site along with all input to that function (unless you use default arguments). This also is not hiding: every part of the function and its input is explicit.
Much better arguments for your case would be overloaded operators and implicit conversions, both of which happen without an explicit information at the call site. But it's no coincidence that both of these are forbidden by the Google Style Guide also.
Your argument makes no sense; the "this" pointer is just a function parameter, and the whole point of a function is that the arguments aren't fixed until the function is called. No part of this is implicit.
> The identity of the function to be executed is hidden from the caller.
The function is named at the call site along with all input to that function (unless you use default arguments). This also is not hiding: every part of the function and its input is explicit.
Much better arguments for your case would be overloaded operators and implicit conversions, both of which happen without an explicit information at the call site. But it's no coincidence that both of these are forbidden by the Google Style Guide also.
I don't know, I think I find the Google Python Style Guide just as persuasive in the opposite direction.
http://google-styleguide.googlecode.com/svn/trunk/pyguide.ht...
The reason I would tend to use default arguments in Python and C but not in C++ would be that it can get confusing if you throw in C++'s function overloading. A function by its very nature can't help but have default behavior, and if someone realizes they need to override the defaults they'll probably end up in the documentation or function definition or some other place that will let them realize they can adjust the defaults.
The reason I would tend to use default arguments in Python and C but not in C++ would be that it can get confusing if you throw in C++'s function overloading. A function by its very nature can't help but have default behavior, and if someone realizes they need to override the defaults they'll probably end up in the documentation or function definition or some other place that will let them realize they can adjust the defaults.
Default parameters are more difficult to maintain because copy-and-paste from previous code may not reveal all the parameters
I am surprised this is an issue at Google.
I am surprised this is an issue at Google.
Why? Google, like most companies, Google is made up mostly ofretty standard. Most programmers enjoy referencing existing code to help understand how an interface works.
Just because they have more stringing hiring practices doesn't make their engineers some superhuman level of programmer.
Just because they have more stringing hiring practices doesn't make their engineers some superhuman level of programmer.
Referencing existing code is one thing. Copy/pasting that code, or writing new code based on it, without actually looking at the documentation to know what you're doing, is another thing entirely.
The issue is not what tends to be the correct way to properly code, but how in fact people end up coding.
It seems that many engineering decisions are made at google, to minimize the amount of damage a particular programmer can do. This suggests that while Google does/may have some very good people running the place, they also have quite a few programmers whom are mediocre at best.
These choices are about building an environment that forces a programmer to do things the right way, rather then expecting them to do such on their own.
It seems that many engineering decisions are made at google, to minimize the amount of damage a particular programmer can do. This suggests that while Google does/may have some very good people running the place, they also have quite a few programmers whom are mediocre at best.
These choices are about building an environment that forces a programmer to do things the right way, rather then expecting them to do such on their own.
One of the more typical ways to figure out how to use a complex API is usually "look at examples".
I think it is inconsistent with the idea of allowing the instantiation of classes with default constructors, classes whose member variables may be given default values by the constructors.
c99 makes this much, much easier than they think:
#define ARG_16(a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,...) q
#define COUNT(...) ARG_16(x,##__VA_ARGS__,15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0)
#define PASTE2(a,b) a ## b
#define CALLFN(name,nargs,...) PASTE2(name,nargs)(__VA_ARGS__)
#define FOO(...) CALLFN(foo,COUNT(__VA_ARGS__),__VA_ARGS__)As I told you inside the comments in the blog itself, what is x in the definition of COUNT(...) ?
Also it seems that you did not read the topic correctly because even if you tried to apply such a method it would fail for the no arguments case, which is a big part of the bulk of the first method.
If I don't get something please feel free to explain
Also it seems that you did not read the topic correctly because even if you tried to apply such a method it would fail for the no arguments case, which is a big part of the bulk of the first method.
If I don't get something please feel free to explain
Bah. I prefer poor man's currying instead, just wrap the function.
This is kind of neat to get named arguments in C as well.
Instead of calling:
Instead of calling:
foo_init(1, 'a', 1.0);
foo_init(.arg1=1, .arg3=1.0, .arg2='a');
foo_init(.arg3='c');
// etc
The combination of compound literals and variadic macros is indeed pretty neat. It can also be used to implement Java-style variadic functions (ie when the variadic parameters have a single type):
#define sum(...) \
sum_(sizeof ((int []){ __VA_ARGS__ }) / sizeof (int), (int []){ __VA_ARGS__ })
int sum_(size_t count, int values[])
{
int s = 0;
while(count--) s += values[count];
return s;
}
int s = sum(1, -32, 5);nice idea!
Hello,
I am the author of the linked blog. Your idea is indeed very neat too. Refer to the comment made in the blog by Jens Gustedt. It has lots of potential imo
[deleted]
Do yourself a favor, either write clean, portable, clear and concise C code, or use a real pre-processor. The only time you should be using pre processor magic anyways is in a large project that's not a library anyways. So at that point it's pretty trivial to just use a proper pre-processor.