wlav

That workaround may provide a clue as the symbol lookup probably occurs at different times for the static initializer v.s. the function call. I can dig into that.

This is Windows, right? I've been having trouble with some STL classes (in particular algorithms) where Cling (or Clang, rather) is not correctly mangling the names when doing symbol lookups....

Issue is that a function pointer isn't represented as a function pointer b/c Cling doesn't track it as a `Type` but as a `FunctionDecl`. I've never dug into it to...

Changed in repo: a nullptr return now gives an `std::function` object that is uncallable and evaluates to `False`.

Using `const char*` is difficult b/c ownership isn't clear from reflection only and b/c Python's strings are unicode, not single byte chars. Thus, for example, using `std::string_view` like above has...

Well, I'm not exactly following. If the declaration of `entity` is simply as above, than it should "just work". Example: ``` import cppyy cppyy.cppdef(r"""\ class World { public: template std::string...

I pushed some fixes to the repo to make both usage of `world.entity["const char*"]("Bob")` and `world.entity(ctypes.c_char_p(bytes("Bob","ascii")))` behave as expected.

The fixes mentioned above a released with cppyy 3.0.0 and its dependencies.

For some reason the typedef resolution when applied to `std::function` produces complete gobbledygook. Then, the resulting type can no longer be decomposed it the parts necessary to wrap up the...

Yes, I was thinking along similar lines. The following exemplifies a similar workaround that can be removed once cppyy is fixed: ``` import cppyy import cppyy.gbl as cpp cppyy.cppdef(r"""\ std::vector...