Is there a difference between foo(void) and foo() in C++ or C?

Question

Consider these two function definitions:

void foo() { }

void foo(void) { }

Is there any difference between these two? If not, why is the void argument there? Aesthetic reasons?

Solution 1

In C:

• void foo() means "a function foo taking an unspecified number of arguments of unspecified type"
• void foo(void) means "a function foo taking no arguments"

In C++:

• void foo() means "a function foo taking no arguments"
• void foo(void) means "a function foo taking no arguments"

By writing foo(void), therefore, we achieve the same interpretation across both languages and make our headers multilingual (though we usually need to do some more things to the headers to make them truly cross-language; namely, wrap them in an extern "C" if we're compiling C++).

Solution 2

I realize your question pertains to C++, but when it comes to C the answer can be found in K&R, pages 72-73:

Furthermore, if a function declaration does not include arguments, as in

double atof();

that too is taken to mean that nothing is to be assumed about the arguments of atof; all parameter checking is turned off. This special meaning of the empty argument list is intended to permit older C programs to compile with new compilers. But it's a bad idea to use it with new programs. If the function takes arguments, declare them; if it takes no arguments, use void.

Solution 3

C++11 N3337 standard draft

There is no difference.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf

Annex C "Compatibility" C.1.7 Clause 8: declarators says:

8.3.5 Change: In C ++ , a function declared with an empty parameter list takes no arguments. In C, an empty parameter list means that the number and type of the function arguments are unknown.

Example:

int f();
// means int f(void) in C ++
// int f( unknown ) in C

Rationale: This is to avoid erroneous function calls (i.e., function calls with the wrong number or type of arguments).

Effect on original feature: Change to semantics of well-defined feature. This feature was marked as “obsolescent” in C.

8.5.3 functions says:

4. The parameter-declaration-clause determines the arguments that can be specified, and their processing, when the function is called. [...] If the parameter-declaration-clause is empty, the function takes no arguments. The parameter list (void) is equivalent to the empty parameter list.

C99

As mentioned by C++11, int f() specifies nothing about the arguments, and is obsolescent.

It can either lead to working code or UB.

I have interpreted the C99 standard in detail at: https://stackoverflow.com/a/36292431/895245

Solution 4

In C, you use a void in an empty function reference so that the compiler has a prototype, and that prototype has "no arguments". In C++, you don't have to tell the compiler that you have a prototype because you can't leave out the prototype.

View more solutions

Comments

[Antti Haapala -- Слава Україні]

For C the Q/A is here

[Zan Lynx]

"prototype" means the argument list declaration and return type. I say this because "prototype" confused me as to what you meant at first.

[Adrian McCarthy]

But if C++ had required the void, then it could have avoided the "most vexing parse" problem.

[DrPizza]

True, but there are so many other crappy parses in C++ there's no real point in kvetching about any one of them.

[Matthieu M.]

On a recent question, @James Kanze posted an interesting tidbit. Repost here to avoid losing it: the first versions of C did not allow to specify the number of parameters a function might take, thus void foo() was the only syntax to declare a function. When signatures where introduced, the C committee had to disambiguate the no-parameter from the old syntax, and introduced the void foo(void) syntax. C++ took it for the sake of compatibility.

[chacham15]

Can you give me an example of C C90 and later where using void foo() instead of void foo(void) will produce a functional difference? I.e. I have been using the version without the void for many years and havent seen any problem, am I missing something?

[unresolved_external]

Ok, I understand a difference now, but what I will gain in C if I write void foo( void ) instead void foo() ? What is a practical reason to write void explicitly?

[DrPizza]

You'll receive warnings, if not errors, if you ever mistakenly try to pass args to a no-args function.

[Paul Renton]

I now understand why void might be placed in a non parameter accepting function. So would it be best practice to do so in all C++ functions that have no parameters?

[Lightness Races in Orbit]

@AdrianMcCarthy: MVP is hardly a "problem".

[Yam Marcovic]

@AdrianMcCarthy I don't think MVP would've been solved. What about std::vector<int> v(std::vector<int>()); or any combination of 2 types, constructing one directly in the constructor of the other.

[M.M]

@chacham15 void foo() { if ( rand() ) foo(5); } compiles and runs (causing undefined behaviour unless you're very lucky), whereas void foo(void) with the same body would cause a compilation error.

[JohnTortugo]

@MatthieuM. that is an interesting piece of information. I would love to have a link to read the question/text that you mention. Yeah, I know, 7 years later haha

[Sammy]

extern "C" void foo(void) is NOT required, since functions are extern by default and by the very nature of it :)

[DrPizza]

If you want your C++ compiler to apply C name mangling rules to C declarations--and you do, if you want the linker to know what you're talking about--then you need extern "C" around the C names.

[jinawee]

But the question is about definitions, in that case the relevant C rule is An empty list in a function declarator that is part of a definition of that function specifies that the function has no parameters.

[Asteroids With Wings]

@M.M You can't "cause" undefined behaviour. Either the program has well-defined behaviour, or it does not. It's a property, not an event. However, whether you see "strange things happening" as a result of executing a program whose behaviour is undefined is down to chance; perhaps that's what you meant?

[M.M]

@AsteroidsWithWings It can be both. Another similar example to the above is if (getchar() == 'x') 1/0; , the behaviour is only undefined if execution reaches this line, and certain input is given.

[Asteroids With Wings]

@M.M It's still a property of the program; it seemed you were conflating "undefined behaviour" with "possible strange symptoms of undefined behaviour", since you posited the idea that you could somehow avoid it by being "very lucky" (which isn't true in the given example unless the source code changes!)

[M.M]

@AsteroidsWithWings The "lucky" element depends on the return value of rand(); if it happens to return 0 then there is no undefined behaviour: having foo(5) in code that is never executed does not imply the program has UB. I'm not conflating UB with symptoms of UB. Maybe the getchar() example is better than the rand() example to demonstrate this point in order to avoid arguments about guarantees of the sequence of numbers generated by rand()

[Asteroids With Wings]

@M.M. Oh, fair :P

[Peter Mortensen]

The syntax highlighting is off near "means int". Can you fix it? For instance, turned off inside comments or "void" more like here.