jens at unwesen.de
Thu Feb 23 00:10:09 CET 2006
> Which is why my idea was to provide such a converter for boost::any.
> But I don't know if a 'generic' converter (ie using automaticaly the
> specialised ones) is possible.
Well, you could build a converter that converts boost::any to some
Python type, but inside that converter you would have to check the
typeid of the held object to decide what kind of Python object to
convert to. And you'd have to adapt that converter to every type of
object you later decide to put into that boost::any.
As far as I recall, boost::python uses templates to let some of those
decisions happen at compile time. For that, you need distinct C++ types
that map to corresponding Python types, and as boost::any can hold,
well, any type you can't use that technique.
> Yes, but as far as I understand, the type_id of the c++ types is used to
> determine how to convert them from/to python objects. And this type_id
> being available on boost::any, I am hoping that implementing such
> converters is possible (if not easy enough for me).
> It's an easy workaround. It seems to me that it's almost equivalent as to
> hand-code a converter for boost::any which knows a finished set of types.
> Does it make sense ?
I think it does ;)
The difference is, as I tried to point out above, that a hand-coded
converter for boost::any moves some decisions to run-time which can be
handled at compile-time. And (again, my memory might be wrong on this)
boost::python tries to handle them at compile time. So basically with a
hand-coded converter you would render some optimizations pointless that
boost::python offers you for free.
Both is possible.
Hope that cleared up what I meant to say!
More information about the Cplusplus-sig