The following code snippet:
#include <iostream>
void does() { std::cout << "do" << std::endl; }
void does(bool b = false) { std::cout << "do(bool)" << std::endl; }
void fwd(void (*func)(bool))
{
func(false);
}
int main(int, char**)
{
fwd(&does);
fwd(does);
fwd(*does);
}
understandably produces the following error:
test.cpp:15:10: error: overloaded function with no contextual type information
The compiler cannot discern which of the functions I intend to use.
What I don't understand is why the code will correctly run when I comment out the line that reads:
fwd(*does)
Why can the compiler suddenly resolve the ambiguousness?
int main(int, char**)
{
fwd(&does);
fwd(does);
}
Also, without overloading does the snippet will correctly run with all 3 calls.
This snippet runs fine...
#include <iostream>
void does(bool b = false) { std::cout << "do(bool)" << std::endl; }
void fwd(void (*func)(bool))
{
func(false);
}
int main(int, char**)
{
fwd(&does);
fwd(does);
fwd(*does);
}
I'm compiling this with gcc 4.6.3 on a Linux box.
Thanks for the help!
The answer to your question is in the overload-resolution rules for functions.
Specifically, there is an exception for using & before the function-name (once) not breaking overload-resolution, but none for using *.
Also see that only one of those two functions accept that single argument:
13.4 Address of overloaded function [over.over]
1 A use of an overloaded function name without arguments is resolved in certain contexts to a function, a pointer to function or a pointer to member function for a specific function from the overload set. A function template name is considered to name a set of overloaded functions in such contexts. The function selected is the one whose type is identical to the function type of the target type required in the context. [ Note: That is, the class of which the function is a member is ignored when matching a pointer-to-member-function type. —end note ] The target can be
an object or reference being initialized (8.5, 8.5.3),
the left side of an assignment (5.17),
a parameter of a function (5.2.2),
a parameter of a user-defined operator (13.5),
the return value of a function, operator function, or conversion (6.6.3),
an explicit type conversion (5.2.3, 5.2.9, 5.4), or
a non-type template-parameter (14.3.2).
The overloaded function name can be preceded by the & operator. An overloaded function name shall not be used without arguments in contexts other than those listed.
Quote is from n3242 (c++11), with bold by me.
fwd expects a function that takes a boolean parameter; you only have one such version of does, so there is no confusion. In effect, does and &does are considered the same (because functions cannot be values, one of these two should technically be incorrect if not impossible to represent, but the language has to chosen to instead just treat them as the same thing).
But when you try to use fwd(*does), you would need a definition of does that dereferences to such a function, and you don't have anything like that -- in fact, as I have been recently schooled, you can't have anything like that.
Related
When the function is called it's clear how name-lookup and overload resolution is performed. But what happens when the funtion is not being called? E.g.
#include <iostream>
using std::cout;
using std::endl;
void foo(int){ cout << "foo(int)" << endl; }
void foo(int, int){ cout << "foo(int, int)" << endl; }
void (*baz)(int, int);
int main()
{
baz = foo; //1
baz(1, 1);
}
DEMO
In that case we have two functions with the name foo and formally, the unqualified name lookup finds both them. The clause 13 of the Standard doesn't cover that case because it's concerned only in the function call context N3797:13.3/2 [over.match]:
Overload resolution selects the function to call in seven distinct
contexts within the language:
The behavior in this case is governed by this verbiage in the C++11 standard (there is a similar section in N3797):
A use of an overloaded function name without arguments is resolved in certain contexts to a function, a pointer to function or a pointer to member function for a specific function from the overload set. ... The function selected
is the one whose type is identical to the function type of the target type required in the context. -- ISO/IEC 14882:2011(E) §13.4 [over.over] (emphasis mine)
The standard overload resolution rules aren't used here because you are assigning to a function pointer type, so the compiler will simply select the function overload that exactly matches the type of the function pointer.
What do the characters in bold mean in this sentence extracted from paragraph §5.2.2/1 of the C++11 Standard?
There are two kinds of function call: ordinary function call and member function (9.3) call. A function call is a postfix expression followed by parentheses containing a possibly empty, comma-separated list of expressions which constitute the arguments to the function. For an ordinary function call, the postfix expression shall be either an lvalue that refers to a function (in which case the function-to-pointer standard conversion (4.3) is suppressed on the postfix expression), or it shall have pointer to function type.
Edit
Basically what I'm asking is: when the Standard says "(in which case the function-to-pointer standard conversion is suppressed on the postfix expression)" does it mean that this suppression is for good or that it will be revoked later (e.g. after function overloading)?
Edit1
In my opinion the word "suppressed" above is misleading since it gives the impression that the conversion from function name to a function pointer might never be done by the compiler. I believe that's not the case. This conversion will always occur after the function overloading process is finished, since only at this point, the compiler knows exactly which function to call. That's not the case when the program initializes a function pointer. In this situation, the compiler knows the function to be called, so there will be no overloading, as the example below shows.
#include <iostream>
int foo(int i) { std::cout << "int" << '\n'; return i * i; }
double foo(double d) { std::cout << "double" << '\n'; return d * d; }
int main()
{
int(*pf)(int) = foo; // no overloading here!
std::cout << pf(10.) << '\n'; // calls foo(int)
std::cout << foo(10.) << '\n'; // call foo(double) after function overloading. Therefore, only after function
// overloading is finished, the function name foo() is converted into a function-pointer.
}
The code prints:
int
100
double
100
Absent any statement in the Standard to the contrary, the suppression is presumably permanent. I think the conversion is suppressed because (i) overload resolution needs to take place and (ii) it is not necessary in this situation. Indeed, it would be impossible to convert to a pointer before we knew exactly which function is being called. After overload resolution, we know we are directly calling the function, so a conversion would be pointless.
What are all the possible types of valid expressions for a default argument in a function or member function?
Anything that is correct within context of assignment to a variable of function parameter's type.
Edit
The default arguments during compilation are evaluated in terms of type correctness etc, but they are not calculated and no assignment takes place until run-time. You can specify a constructor of a yet to be defined class as a default argument and it's fine, as long as class is defined at the point of function use... The actual calculation/assignment takes place during function call, not at the point of function declaration/definition.
Example:
#include <iostream>
void foo( int a = std::rand())
{
std::cout << a << std::endl;
}
int main( void )
{
foo();
return( 0 );
}
Program output on ideone.com:
1804289383
This is detailed in section 8.3.6 of the C++03 standard. It basically amounts to any expression that doesn't depend on anything in local scope, so any expression which depends on local variables, parameters to a function, or on "this" are excluded.
My previous question concluded that a distasteful "double cast" might be necessary to use the POSIX makecontext with a C++ lambda function (i.e. function object). Moving on, I'm now faced with a compilation error relating to the following minimal code:
#include <iostream>
#include <ucontext.h>
using namespace std;
template <typename T> void foo() {
ucontext_t c;
auto f = [=](int i){ cout << i << endl; };
makecontext(&c, (void (*) (void)) (void (*)(int)) f, 1, 12345);
}
int main(int argc, char *argv[]) {
foo<int>();
return 0;
}
The error is:
error: invalid cast from type ‘foo() [with T = int]::<lambda(int)>’ to type ‘void (*)(int)’
However, if I remove the unused (in this example) template argument from the foo function, so it becomes void foo();, and change the call to foo() the error disappears. Could someone tell me why? I'm using G++ 4.6.
Edit:
From the comments below, it seems the [=] in the code above causes the lambda to be a "capturing" lambda, regardless of the fact that it doesn't actually capture anything. The [=] is not necessary in my code, alas replacing with [] in GCC 4.6 does not remove the error. I am installing GCC 4.6.1 now...
If you use [=] to induce your lambda, you will not get a function pointer (or an object that is convertible to one). You will get a function object. And no amount of casting is going to allow you to pass that to makecontext. Not in any way that actually works.
According to N3291, the most recent working draft of C++0x:
The closure type for a lambda-expression with no lambda-capture has a public non-virtual non-explicit const conversion function to pointer to function having the same parameter and return types as the closure type’s function call operator. The value returned by this conversion function shall be the address of a function that, when invoked, has the same effect as invoking the closure type’s function call operator.
This is the only place where the specification allows conversion to a function pointer. Therefore, if recent versions of GCC do allow conversion to function pointers for [=], that not in accord with the specification.
Only captureless lambdas are convertible to function pointers; while f technically does not capture anything, it does have a default capture mode of capturing by value (for no apparent reason).
Change [=] to [] in the declaration of f and it should work as expected.
EDIT: The fact that this compiles with more recent versions of GCC (as noted by Kerrek) gives a strong indication that this is merely a compiler bug in the version you're using.
Why my VS2010 can't compile this code:
#include <functional>
#include <vector>
int main()
{
std::vector<int> vec;
std::bind(&std::vector<int>::push_back, std::ref(vec), 1)();
return 0;
}
You should be more specific why this doesn't seem to work for you.
#include <iostream>
#include <tr1/functional>
#include <vector>
int main(int argc, char* argv[]) {
std::vector<int> vec;
std::tr1::bind(&std::vector<int>::push_back, std::tr1::ref(vec), 1)();
std::cout << "vec.size = " << vec.size() << std::endl;
std::cout << "vec[0] = " << vec[0] << std::endl;
return 0;
}
$ gcc -o test -lstdc++ test.cpp && ./test
vec.size = 1
vec[0] = 1
Update: Luc Danton is right, the issue here is the overloaded push_back. See question Are there boost::bind issues with VS2010 ?. Also, note that the issue is not limited to push_back, see Visual Studio 2010 and boost::bind.
The bottom line is that what you're trying to do isn't possible in portable C++. std::vector<>::push_back is guaranteed to be overloaded in C++11 compilers, as at a minimum there must be an overload for lvalues and an overload for rvalues.
Usually, when taking the address of an overloaded member function, §13.4/1 in the C++11 FDIS tells us that we can control which overload we're taking the address of thusly:
A use of an overloaded function name without arguments is resolved in certain contexts to a function, a pointer to function or a pointer to member function for a specific function from the overload set. A function template name is considered to name a set of overloaded functions in such contexts. The function selected is the one whose type is identical to the function type of the target type required in the context. [ Note: That is, the class of which the function is a member is ignored when matching a pointer-to-member-function type. —end note ] The target can be
an object or reference being initialized,
the left side of an assignment,
a parameter of a function,
a parameter of a user-defined operator,
the return value of a function, operator function, or conversion,
an explicit type conversion, or
a non-type template-parameter.
The overloaded function name can be preceded by the & operator. An overloaded function name shall not be used without arguments in contexts other than those listed. [ Note: Any redundant set of parentheses surrounding the overloaded function name is ignored. —end note ]
The problem comes from §17.6.5.5/2:
An implementation may declare additional non-virtual member function signatures within a class by adding arguments with default values to a member function signature; hence, the address of a member function of a class in the C++ standard library has an unspecified type.
Consequently, it is not portable to ever take the address of a standard library class member function, as the type of such an expression is by definition unknowable except on an implementation-by-implementation basis.
Luc Danton's proposed workaround (specifically, using a lambda) is also what I would recommend:
std::vector<int> vec;
[&](){ vec.push_back(1); }();
Try this:
struct push_back {
void
operator()(std::vector<int>& vector, int i) const
{
vector.push_back(i);
}
};
// somewhere else:
std::vector<int> vec;
std::tr1::bind(push_back(), std::tr1::ref(vec), 1)();
With C++03 note that push_back cannot be a local type; with C++11 it can but it would be more idiomatic (and completely equivalent) to use a lambda.
In all likeliness your implementation provides overloads for std::vector<T>::push_back and thus its address would have to be disambiguated. If this is what happened, your compiler should have provided you with an appropriate error message. In all cases, you should explain what you mean by "it's not possible".
The point is not to use such helper
functions. – magenta
Then why didn't you put it in the question? I can't read your mind.
You can also try this:
std::vector<int> vec;
void (std::vector<int>::*push_back)(int const&) = &std::vector<int>::push_back;
std::tr1::bind(push_back(), std::tr1::ref(vec), 1)();
Which I believe is not guaranteed to success.
It should propably lok like this:
std::vector<int> vec;
std::tr1::bind(&std::vector<int>::push_back, std::tr1::ref(vec), _1)(1);