wlav

The problem with a decorator approach would be that the decorator is executed after the class and its functions have been created. At that point, the dispatcher has to already...

If they always differ in the number of parameters, rather than the type of parameters, can do something like: ``` import cppyy cppyy.cppdef(""" class MyClass { public: virtual ~MyClass() {}...

Thanks for the nice reproducer! Two things are going wrong here: `uint8_t` resolves as an `unsigned char` (hence the appearance of `\x0E`) even as C++ intends it as a numeric...

The name printing appears to be deep in Clang; I'm going to leave that as-is for now. Repos have otherwise been updated with a fix for all the lookup problems....

I tried, but atm, I think not, as it appears to be a bit worse than simple Clang type printing. Yes, the declared type can show the integer numbers, but...

Upstream pointed to this recent possible GSoC proposal, which would be a step in the right direction: https://discourse.llvm.org/t/clang-extend-clang-ast-to-provide-information-for-the-type-as-written-in-template-instantiations/60323

The original problem is now fixed with release 2.3.0 and its dependencies.

Unfortunately, global overloads are difficult to handle (since they can be defined completely independently from the arguments they operate on), so their whole lookup is internal on the C++ side...

Yes, finding correct (non-string based, or at least on resolved types) matching isn't available yet.

Right now, the signature match is purely string based, see: https://github.com/wlav/CPyCppyy/blob/master/src/CPPOverload.cxx#L1085 This will have to be smarter, e.g. by resolving all typedefs first, or by finding the decls and comparing...