C++ Weekly - Ep 437 - Pointers To Overloaded Functions

☟☟ Awesome T-Shirts! Sponsors! Books! ☟☟

T-SHIRTS AVAILABLE!

WANT MORE JASON?

SUPPORT THE CHANNEL

GET INVOLVED

JASON'S BOOKS

► C++23 Best Practices

► C++ Best Practices

JASON'S PUZZLE BOOKS

► Object Lifetime Puzzlers Book 1

► Object Lifetime Puzzlers Book 2

► Object Lifetime Puzzlers Book 3

► Copy and Reference Puzzlers Book 1

► Copy and Reference Puzzlers Book 2

► Copy and Reference Puzzlers Book 3

► OpCode Puzzlers Book 1


RECOMMENDED BOOKS

AWESOME PROJECTS

O'Reilly VIDEOS

[flamewingsonic]

7:18 Overload macro is referring directly to "callable" instead of the macro parameter.

[sadunozer]

This was an incredible episode! Why would it be disappointing. So good.

[Shakephobiaful]

This problem became more prevalent with C++20/23 views (namely transform) and the optional monadic operations, because they encorage us to pass function pointers to small things.
I worked around it by using template specializations instead of function overloads. The template is deleted for the general case, but specialized for the interesting cases. Then specifying the needed overload is easy.
For example, consider a function that translates a string to a type of integer. It would be `from_string<uint32_t>`.

[aniketbisht]

6:48 With reflections we would be able to replace this with a variable template which would take a reflection of a "function overload set" and turn that into a function object (lambda) which will forward it's arguments to that overload set. Basically we would be able to "objectify" any "free" function template and overload set Ex:
template<std::meta::info overload_set>
constexpr auto FuncObj = []<....>(...){....};

int main(){

}

[klausneda]

Good job Jason, you even got the phishing profiles with booty profile pictures interested in C++ :D

[avramlevitter]

I ended up with a similar situation when trying to make projections for use with std::ranges- did you know that taking the address of standard library functions or members of structs is not allowed? And sometimes, the type is very complicated in how it's derived. So I ended up writing macros for calling a member function or for returning a member field. Interesting to see that I'm not the only one with this idea.

[aniketbisht]

As soon as I read the title, I was like, "LAMBDAS!".

[weker]

I mean it makes sense that the compiler will complain that you are trying to use (but cannot instantiate yourself) a template with a template parameter that cannot be defined in another compilation unit. The current compilation unit would not even emit code for any call operator template of the lambda and no other CU can ever emit code for it as it is undefineable there.

It would compile if one defines a struct like you did with the Lambda, as this struct is something that theoretically could be defined in another CU. (For example if the Lambda struct was in a header). If it actually is still not known in any other CU or nobody instantiate use_callable with the Lambda struct than the linker would complain in the end.

[robikz]

I'm working with an older Qt, and the QNetworkReply there has an error() getter method and an error(Error) signal. I wanted to connect this signal to a slot using the "new" method pointer syntax, instead of the old Qt's SIGNAL macro, but the errors the compiler gave me made me end up using the SIGNAL macro anyway. So, now all the connects all around use the method pointers, but this one is the old SIGNAL / SLOT pair, haha. And this happened like two days ago.

[idiotsiuda]

I ask to make a video with overloaded member functions references in the same format as this video.

[dadisuperman]

--Consider the following case:
template<typename T >
void foo(int){}
--a simple function template.
--that doesn't use the template parameters anywhere in its arguments or return type.
Yet, If you try to pass it as a pointer, the compiler will complain about overload ambiguity.
-- so if you say for example
auto fooPtr = &foo;
-- this is a compiler error.
-- to correct it we write.
auto fooPtr = &foo<sometype>;
-- that means the template parameter participate in the overload resolution despite it is not used anywhere in the function signature!!!
Question for smart people here.
Imagine you have been passed a function pointer to foo, how can you tell which type was used in the template argument when instantiating the function??

[cmdlp]

The C++ Standard could do it much much better regarding functions. Namely, instead of "implicitly converting" the "function name" directly to a function pointer it could effectively create a lambda which contains all overloads of the function. This might be very useful for the standard algoritms/ranges. For example consider applying transform(abs) to a range, of course this should work with floats, ints and other number types. Usually the pattern with surrounding the function with a lambda (Like with the macro) achieves exactly what I would like to see implicitly in the standard. Optionally, the standard could add a syntax like using a special unary operator like transform(~sum), as a parallel to the + operator for lambdas

[ChristopherSamuelson]

Feels like an oversight. Any known efforts to help make this nicer to work with?

[paulfee]

I find this approach somewhat less disappointing as it avoids static casts.

void (*selected_overload)(double) = callable;

[rshell]

Interesting question follows from it: does &callable has value and type? Or is it quantum object? (:

[BenjaminWheeler]

I'm starting to think that compilers are secretly magic.

[toddfulton]

Any thoughts on P3312 R0 Overload Set Types?

It is strange that expressions like &callable(int) and &callable(double) are not allowed.

[kethernet]

Seems to me it would be trivial for the standard to allow an overload set to automatically translate into a lambda that has operator() overloads for everything in the overload set. I think this would be useful, or are there downsides I'm not seeing?

[AtomicAndi]

Raw function pointers are arguably a code smell