void foo();
class Foomatic() {
void bar();
void baz()
{
std::thread a(foo); // this compiles
std::thread b(Foomatic::bar, this); // this doesn't
std::thread c(&Foomatic::bar, this); // and this compiles
// ...
}
};
I know that the correct syntax for the pointer to member function is &Foomatic::bar.
But why exactly is Foomatic::bar incorrect? What does that one return? And why exactly is the &Foomatic::bar the correct one? It seems counter-intuitive to me.
This is not a duplicate. The question you linked to answers what the correct syntax is, not explaining the reasons why.
I'm asking why C++ is so inconsistent here, I already know what the syntax is.
C++ inherited the conversion from functions to function pointers from C: in C you could just assigne a function name to a function pointer without the need to take the address. This "decay" of function names to function pointers seems somewhat ill-advised and did cause some confusion in C.
When pointers to members where introduced there was no need to be backward compatible with C: C doesn't have pointers to members. Thus, there was the option to not have an implicit conversion from a member name to a pointer to member. Since a facility can be added later if it feels necessary but hardly removed the choice was made to not have an implicit conversion from a member name to pointer to member.
Since there is a reasonably consistent interface to get pointers to functions, pointers to members, and pointers to objects there doesn't seem to be a need to have implicit conversions from member names to pointer to member pretty much as there is no implicit conversion from an object name to a pointer to an object.
Semantically, something like T::member is a reference to a member rather than pointer to a member. However, I don't think it is possible to formulate this type with the current specification. Possibly, a future standard defines someting for this syntax.
If &Foomatic::Bar is a pointer-to-member function (because you're taking the address of the function using the address-of operator &), then Foomatic::Bar is a member function, not a pointer-to-member function.
This is exactly the same with non-member functions: if &foo is a pointer to (non-member) function, then foo is a function.
Neither C++ nor C have functions as first-class objects, e.g., you can't have a variable whose type/value is a function --- only a pointer thereto.
As a syntactic sugar special case for non-member functions, you can call said function without having to deference it first explicitly, e.g, foo(42) is a short-hand for (*foo)(42) if foo is a pointer to (non-member) function.
Related
I've got this code snippet:
int x = 3;
auto fauto = [=](){ cout<<'x'; };
function<void()> func{fauto};
func();
void (*rawPf)() = fauto; // fail to compile
rawPf();
I knew the syntax that only non-capture lambda can be assigned to function pointer. But:
(1) Why std::function can hold capture-lambda?
(2) as both std::function and function pointers are callable, what's the core difference that makes std::function able to hold capture-lambda, while function pointer cannot?
Any detailed explanation on language design for this?
Why can a function pointer not hold a lambda with a capture : because a Lambda is NOT a function ,it's an object!
Why can a lambda without a capture be converted to a function pointer ?
A Lambda is just an ordinairy object (a piece of data) of a compiler generated class (with a unique classname that only the compiler knows) with a function-operator member (i.e. auto operator() ( ??? )) that the compiler defines for you with the parameter definitions (if any) you provide. The data-members of a lambda-object are defined by the capture-list and/or usage of variables of its enclosing scope.
All non-static member functions when called on an object get a implicit hidden argument called this. This is also the case when you 'call' the lambda.
Now ,when you don't capture something ,the lambda has no data (empty class) and the compiler doesn't have to generate an implicit this pointer for the call ,which makes the function operator just like an ordinairy function and the compiler can convert it to function pointer.
So it not the lambda that is converted to a function-pointer ,it's the lambda's function-operator that is converted.
Why can std::function hold both : because it's a template and with templates and specializations you can do almost anything.
There's no reason not to implement it in std::function<>, so it's implemented.
The reason a function pointer cannot hold a capture lambda is that the latter has a this pointer and there's no place to store that in the function pointer (well, unless you compile new code or assign it from a pool). However, std::function<> can allocate arbitrary amount of space, amongst these, the this pointer.
You can understand this better if you try to implement a function returning function pointers for lambdas (which, when called, by specification should call the lambda).
Today I got a problem. I am in the need of a static member function, const is not a must but a better. But, I didn't succeed in my efforts. Can anybody say why or how?
When you apply the const qualifier to a nonstatic member function, it affects the this pointer. For a const-qualified member function of class C, the this pointer is of type C const*, whereas for a member function that is not const-qualified, the this pointer is of type C*.
A static member function does not have a this pointer (such a function is not called on a particular instance of a class), so const qualification of a static member function doesn't make any sense.
I agree with your question, but unfortunately the C++ is designed that way. For example:
class A {
int i; //<--- accessed with 'this'
static int s; //<---- accessed without 'this'
public:
static void foo () const // <-- imaginary const
{}
};
As of today, the const is considered in context of this. In a way, it's narrow. It can be made broader by applying this const beyond this pointer.
i.e. the "proposed" const, which may also apply to static functions, will restrict the static members from any modification.
In the example code, if foo() can be made const, then in that function, A::s cannot be modified. I can't see any language side effects, if this rule is added to standard. On the contrary, it's amusing that why such rule doesn't exist!
It is unfortunate that C++ doesn't accept it as per design but logically there are few use cases in which it validates well.
A function which is class level valid(static) might not change any static data, may be it will just query data should be const.
May be it should be like
if(Object)
MakeThisConstant()
else
MakeStaticDataConstant() // Only in the scope but static data cannot be constant so may be it should in some scenarios
Without getting into the details, it's because there may or may not be an object modified by the function, so const is ambiguous to the compiler.
Recall that const keeps objects constant, but there may or may not be an object here to keep constant.
A 'const member function' is not
allowed to modify the object it is called on, but static member
functions are not called on any object.
It is used directly by scope resolution operator.
Thus having a const static member function makes no sense, hence it is illegal.
I am using the gtkmm library on linux to draw a simple menu for my GUI.
In the below code the compiler complained about unable to resolve address
sigc::mem_fun(*this, AppWindow::hide)));
^
appwindow.cpp:15:41: note: could not resolve address from overloaded function
But when I insert the & it compiles fine
m_menu_app.items().push_back(MenuElem("Quit",
sigc::mem_fun(*this, &AppWindow::hide)));
What difference does it make here? Isn't the hide function just an address in the first place?
This is the exact definition of the function-to-pointer conversion, [conv.func]:
An lvalue of function type T can be converted to a prvalue of type
“pointer to T.” The result is a pointer to the function.55
55) This conversion never applies to non-static member functions because an lvalue that refers to a non-static member function
cannot be obtained.
Thus the decay that we see with normal, non-member functions1 doesn't apply and you need to explicitly take the address.
I.e.
void f();
struct A {
void f();
static void g();
};
auto a = f; // Ok: auto deduced as void(*)()
auto b = A::f; // Error: A::f not an lvalue, auto cannot be deduced
auto c = A::g; // Ok: auto deduced as void(*)()
1 Or static member functions.
For global (non-member) functions, the name of the function evaluates to the address of that function except when passed to the & operator, so you can (for example) assign to a pointer to a function either with or without the & equivalently:
int f() {}
int (*pf1)() = f;
int (*pf2)() = &f;
So, in this case there's really no difference between the two.
For member functions1, however, the rules are a bit different. In this case, the & is required; if you attempt to omit the &, the code simply won't compile (assuming a properly functioning compiler, anyway).
There's no particular reason this would have to be the case--it's just how Bjarne decided things should be. If he'd decided he wanted the name of a member function to evaluate to a pointer to a member (equivalent to how things work for non-member functions) he could have done that.
1. Other than static member functions, which mostly act like non-member functions.
When a function is a non-static member function of a class, then it is necessary to use the form &ClassName::functionName when a pointer to the member function is expected in an expression.
When a function is a static member function of a class, both ClassName::functionName and &ClassName;:functionName can be used when a pointer to a function is expected in an expression.
When a function is a global, i.e. non-member, function, both functionName and &functionName can be used when a pointer to a function is expected in an expression.
One of my teachers use this type declaration:
typedef void (*SortFunction)(int a[], int n);
to create a type that can hold a pointer to a function
and that can be used to call that function later on in a program.
I also know that to pass a function as a parameter you have to
wrap the function name in parenthesis and wrap the function's
parameters in parenthesis after the function name as well like so
function someFunction( (anotherfunction)(type arg1, type arg2,...)){
...
}
What I want to know is why must you wrap a function in parenthesis like this? is this a built in function of most c++ compilers or is it simply a trick that we programmers use
in order to enable functions as arguments within our code? also, why does "SortFunction"
in the typedef statement need to be referenced, why can't the variable you use to utilize SortFunction just hold the function instead of pointing to it?
There's nothing special about function arguments. Whenever you declare a function pointer (as a local variable, global variable, class member variable, function parameter, typedef, etc.), it's always declared like so:
return_type (*var_name)(T1 param1, T2 param2, /* etc. */ );
// ^
// |
// This * is very important!
Where var_name is the name of the function pointer variable. The reason the parentheses are needed around *var_name is due to operator precedence: without the parentheses, the * (indicating that something's a pointer) would match with the function's return type, and instead you'd get something like a return type of int* (pointer to int) instead of plain int.
You can't pass a function as an argument because functions are not first-class objects in C and C++. The only way to pass a function is my passing a pointer to the function.
"I also know that to pass a function as a parameter you have to wrap the function name in parenthesis..." You "know " incorrectly.
In order to pass function pointer as a parameter you don't have to wrap the name in parentheses. For example, this will work perfectly fine
void foo(int i) {
}
void bar(void f(int)) {
f(5);
}
int main() {
bar();
}
In the above example function bar receives a pointer to function foo as a parameter and calls foo through that pointer, passing 5 as an argument. As you can see, function name f in the parameter declaration is not wrapped into parentheses.
In this case, once again, the type of parameter f is actually a pointer to a function, even though it is not explicitly declared as a pointer. When function type is used in function parameter declarations, it is automatically implicitly "replaced" with function pointer type by the compiler.
If you wanted to use the function pointer type explicitly, you have to declare bar as
void bar(void (*f)(int)) {
f(5);
}
In this case the parentheses in (*f) are necessary to assure that the * will get bound to f and not to void. Without parentheses the void *f(int) declaration would stand for "function returning void *" instead of the desired "pointer to function returning void".
It is a matter of syntax. Your first typedef defines a type which is a function receiving a vector of int and a int and returning nothing (void).
A variable of type SortFunction will be conceptually as any other variable, although it points to some function. The advantage is that you can change the function it points to and/or call the function dynamically.
What I want to know is why must you wrap a function in parenthesis like this?
Because there had to be some way to identify a function pointer to the compiler (or rather, the parser) and that way seemed as good as any. In C++11 land, you might use this instead: std::function<void(std::array<int>&)> instead.
is this a built in function of most c++ compilers or is it simply a trick that we programmers use in order to enable functions as arguments within our code?
Function pointers need a little bit of additional magic, and without compiler support they would be very, very inconvenient to use. I'm also reasonably certain that it is in the nature of programming that almost all programmer tricks are ultimately functions of the compiler!
also, why does "SortFunction" in the typedef statement need to be referenced, why can't the variable you use to utilize SortFunction just hold the function instead of pointing to it?
Hmm. Not totally sure what you mean here. Do you mean "why does this need to be a typedef at all... why couldn't I just write out the whole function pointer prototype in my function arguments"? Cos you can:
void foo(void(*funcptr)()) {}
If you meant "why do function pointers have to point at a function instead of having the code inline" then for that you need C++11 and lambdas:
#include <iostream>
#include <functional>
void foo(std::function<void(void)> bar) { bar(); }
int main(int argc, char* argv[])
{
foo([]() { std::cout << "hi!" << std::endl; });
}
(again, special syntax needed for lambdas, [](){}, just to tell the parser what is going on)
Today I got a problem. I am in the need of a static member function, const is not a must but a better. But, I didn't succeed in my efforts. Can anybody say why or how?
When you apply the const qualifier to a nonstatic member function, it affects the this pointer. For a const-qualified member function of class C, the this pointer is of type C const*, whereas for a member function that is not const-qualified, the this pointer is of type C*.
A static member function does not have a this pointer (such a function is not called on a particular instance of a class), so const qualification of a static member function doesn't make any sense.
I agree with your question, but unfortunately the C++ is designed that way. For example:
class A {
int i; //<--- accessed with 'this'
static int s; //<---- accessed without 'this'
public:
static void foo () const // <-- imaginary const
{}
};
As of today, the const is considered in context of this. In a way, it's narrow. It can be made broader by applying this const beyond this pointer.
i.e. the "proposed" const, which may also apply to static functions, will restrict the static members from any modification.
In the example code, if foo() can be made const, then in that function, A::s cannot be modified. I can't see any language side effects, if this rule is added to standard. On the contrary, it's amusing that why such rule doesn't exist!
It is unfortunate that C++ doesn't accept it as per design but logically there are few use cases in which it validates well.
A function which is class level valid(static) might not change any static data, may be it will just query data should be const.
May be it should be like
if(Object)
MakeThisConstant()
else
MakeStaticDataConstant() // Only in the scope but static data cannot be constant so may be it should in some scenarios
Without getting into the details, it's because there may or may not be an object modified by the function, so const is ambiguous to the compiler.
Recall that const keeps objects constant, but there may or may not be an object here to keep constant.
A 'const member function' is not
allowed to modify the object it is called on, but static member
functions are not called on any object.
It is used directly by scope resolution operator.
Thus having a const static member function makes no sense, hence it is illegal.