Open b-macdonald opened 2 years ago
Problem even runs a bit deeper ... The obvious thing to do would be obj = g.TemplatedClass["Status_E"](g.ON)
(note the use of "
), but that fails in the generation of the wrapper function.
I love enums. :}
I see there was a commit added to the 3.0.0
release here with the message "test for unnamed but typedef'ed enums"
Is that related to this issue? Just made a conda env & installed 3.0.0
, but the above MRE still considers Status_E
to be an int
Happy to dig into this issue if you have any tips on where to start (i.e. cppyy-cling
, cppyy-backend
, copy
...)
@wlav Has this issue been resolved in recent Cppyy releases?
No, it doesn't look like it: it still fails.
I'm running into an issue where C-style anonymous enums, like in the code snippet below, are considered to be objects of class
int
, rather than real enums.If I make them non-anonymous, like the next snippet, then I can access the
Status_E
enum incppyy
as a real type:This is important for a project of mine where we do something similar to the following (smallest MRE I could make 😄):
By default, this will lead to a traceback:
This is because
g.Status_E
is an integer, so the overload fails (print_function(TemplatedClass<int>)
doesn't exist). If you usetypedef enum Status_E
instead oftypedef enum
, it will work fine.Sadly, my codebase is too large and divided between too many teams to make a replacing all instances of
typedef enum
with the more verbose form viable. Is there an alternate solution, or would it be possible to makecppyy
point to the right class type to begin with?Thanks!