Advertisement Jump to content
Sign in to follow this  

Lambda overload problem

This topic is 1178 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ran into a little problem now. I have a function that can be used to register a callback for an object by providing it with a function, and it's meant to be used using lambdas of course. However, the function has two signatures, each accepting slightly different lambda signatures. The lambda signatures are as follows (these are not their actual names, tho, which I'll be getting to in a bit):


  • void fMutable(Component @)
  • void fConstant(const Component @)


This is because certain callbacks are restricted to constant components and others may modify them. My function to register callbacks has two overloads, one taking the mutable lambda signature and one taking the other. The lambda signatures have of course been registered as funcdefs as is necessary.


However, since lambdas won't actually allow me to specify the types of the arguments, this creates an ambiguity which I cannot manually resolve by explicitly specifying them:

Multiple matching signatures to 'Collider::event(const string, $func@const)'

Collider@ Collider::event(const string&inout, karhuAS_Callback_Component_event@)

Collider@ Collider::event(const string&inout, karhuAS_Callback_Component_eventConst@)
Here you can see the real names of the funcdefs. These have been generated by my engine when registering the function event() and for my own convenience I'm not supposed to know the exact names of funcdefs, so I can't manually specify the signature by, say, casting the lambda to either of these (if that's even possible).
Would it be possible to make it so that we can explicitly specify lambda parameter types if necessary for disambiguation, or is there some other way I can resolve this based on what I've said about my particular situation (i.e. not casting, and I'd rather not have to give the two functions different names either, because it would clash with the C++ interface and the general naming convention of my engine)?

Share this post

Link to post
Share on other sites

With the restrictions you defined for yourself, there is currently no way to resolve the ambiguity. You'll have to loosen your restrictions a bit. Either allow the script writer to know the name of the funcdefs so an explicit cast to the desired funcdef can be done, or register the two methods with different names so no ambiguity will exist.



I've already planned to continue improving the anonymous functions by adding support for explicitly defining the signature. However I'm not sure when I'll get to implement this.

Share this post

Link to post
Share on other sites

Well, there's no rush. I can ad-hoc it in the meantime. Good to know it's on the list at least. Thanks!

Edited by Prinsessa

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!