Advertisement

Lambda overload problem

Started by October 26, 2015 09:10 PM
1 comment, last by Prinsessa 9 years, 1 month ago

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)?

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.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Advertisement

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

This topic is closed to new replies.

Advertisement