Does C support optional null parameters?

Question

In Python, I'm used to things like

def send_command(command, modifier = None):

and then the modifier argument is optional, and the absence of the argument can be differentiated from an argument of 0. Is there similar functionality in C? I'm inexperienced with C, and Googling, but can't find a clear statement of how to use optional parameters in C. It seems you can assign them similarly, like this:

void send_command(uint8_t command, uint8_t modifier = 0) {

so the second argument is optional and defaults to 0 if not used? (Edit: No, this is invalid C anyway)

But can the function distinguish between send_command(SOMETHING) and send_command(SOMETHING, 0)? Ideally, the second parameter could be any uint8 value, including 0.

Maybe NULL is different from 0?

void send_command(uint8_t command, uint8_t modifier = NULL) {

Solution 1

C does not support optional parameters. Nor does it support function overloading which can often be used to similar effect.

Solution 2

Optional parameters are possible in C99 with variadic macros:

#define JUST3(a, b, c, ...) (a), (b), (c)
#define FUNC(...) func(JUST3(__VA_ARGS__, 0, 0))

Now FUNC(x) expands to func((x), (0), (0)), FUNC(x,y) expands to func((x), (y), (0)), etc.

Solution 3

As others have said, C does not have optional parameters.

As for the difference between NULL and 0, there isn't much of one.

Solution 4

As others said C doesn't support default arguments of functions directly. But there are ways to do this with macros. P99 has convenient "meta"-macros that make this feature relatively easy to specify. As an example to avoid to repeatedly have to specify the second argument of the pthread_mutex_init function:

P99_PROTOTYPE(int, pthread_mutex_init, pthread_mutex_t*, pthread_mutexattr_t const*);
#define pthread_mutex_init(...) P99_CALL_DEFARG(pthread_mutex_init, 2, __VA_ARGS__)
P99_DECLARE_DEFARG(pthread_mutex_init, , (pthread_mutexattr_t*)0);

and straight forward to use afterwards

pthread_mutex_init(&my_mutex);

The semantic of evaluation of the default argument here is the same as for C++, that is the evaluation context of the default argument is the context of the declaration. There is also the possibility to specify this in a way that the context of evaluation is the context of the macro invocation.

View more solutions

Comments

[endolith]

That might be why I'm having trouble finding it. So my example that assigns default value of 0 would only be valid in C++?

[David Heffernan]

Correct. That is known as a default argument in C++.

[pmg]

I don't whether to cry or laugh

[R.. GitHub STOP HELPING ICE]

You don't want to see overloading, do you? ;-)

[Steve Jessop]

And unfortunately, FUNC(x,y,z,t) expands to func((x), (y), (z)) instead of an error. The important thing, I feel, is to just slightly punish people who want overloading. When they least expect it.

[R.. GitHub STOP HELPING ICE]

Bonus points to whomever figures out how to make FUNC(x,y,z,t) generate an error. I suspect it's not too hard.

[R.. GitHub STOP HELPING ICE]

Totally reasonable. I think the best answer is "No, C doesn't have them [unless you like evil preprocessor hacks]."

[endolith]

This doesn't differentiate between missing argument and 0 anyway, does it?

[R.. GitHub STOP HELPING ICE]

The macros I gave cause the function to receive zeros for the remaining arguments if they're omitted. They could easily be changed to use a different default value if you prefer.

[Steve Jessop]

It'd be tricky to imitate void send_command(int command = 1; int modifier = 0), though, since whatever value you add immediately after __VA_ARGS__ will be used as the default for either parameter. This is a poor version of "default arguments" or "overloading". Obviously R.. knows that, this is presented mostly for interest. The warnings not to actually use this should probably be heeded!

[R.. GitHub STOP HELPING ICE]

Haha Steve you blew my cover. I was trying not to mention the fact that it won't work for the first argument. ;-)

[Tom Lint]

That depends. Defining NULL to mean (void *)0 will, with most compilers, result in a "conversion from pointer to integer without a cast" warning when passed in an integer argument. I find it rather odd that the C++ committee chose to go with a plain 0, which defeats even the most basic type checking that would've occurred had they retained the C definition.