[boost] Re: Implicit conversions in dynamic_any / extract
Remy Blank wrote: I checked out dynamic_any from CVS but the function... syntax seems to be missing, so I replaced it by function1 Is there something missing in the repository? Yes, you are right, it's missing. I have not enough time to implement all features. Currently only functionN (N=1,...10) are available. After some trimming, this works perfectly! dynamic_any is truly awesome! Thanks for the advice. Best regards. --Remy It's nice for me to see these words! I'm waiting with bated breath when this library becomes available to many people. Some of them can apply dynamic_any in a way that I can't even imagine. It promises to be very interesting time. -- Alexander Nasonov Remove -nospam from my e-mail address for timely response ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Implicit conversions in dynamic_any / extract
Alexander Nasonov wrote:
You can create your own framework for dynamic_any using
dynamic_any::function. In a combination with simple and typesafe interface
it could make great library. Basic idea is here:
namespace your_framework
{
// ...
namespace detail
{
// ...
struct raw_convert
: boost::dynamic_any::function
convert,
void * (boost::dynamic_any::arg )
Oops, here is a typo. Should be
struct raw_convert
: boost::dynamic_any::function
raw_convert, // typo was here
void * (boost::dynamic_any::arg )
--
Alexander Nasonov
Remove -nospam from my e-mail address for timely response
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Implicit conversions in dynamic_any / extract
On Fri, 22 Nov 2002 07:17:24 -0500, David Abrahams [EMAIL PROTECTED] wrote:
Remy Blank [EMAIL PROTECTED] writes:
Hello Boosters,
I am trying to use dynamic_any to store either objects or pointers to
(polymorphic) objects.
I am able to extract a pointer to the base class of a contained object:
class B { };
class D: public B { };
void Test()
{
any d(D());
B* pb = extractB(d);
}
This is alread quite useful. However the following code does not work:
void Test2()
{
D d;
any pd(d);
B* pb = extractB*(pd);// pb = 0
char c;
any AnyChar(c);
int i = extractint(AnyChar); // bad_extract
}
So I have to know the exact type of the contained object and cannot
rely on implicit conversions (D* - B* or char - int) to work.
This is quite understandable from the fact that any wraps non-class
types into unrelated classes.
Now my question: is there a way to make these implicit conversions work?
Heh. Boost.Python does it with a complicated class registry and
upcast/downcast system. I don't know if you want to pay for that.
Yes, if there's no better way.
My best answer at the moment: explicitly register conversion functions
from one type to the other in a mappairtype_info const, type_info const,
void* (*)(void*)
and look up the right function based on the type contained and the
type requested.
Oh, well, if you're willing to do that...
I didn't say that. I said that that was my best current answer. I'm not
satisfied with it, though.
But there has to be a better way, hasn't it?
Yes**. The mechanism in Boost.Python allows you to register just the
relationships between adjacent base and derived classes, and it fills
in the rest of the graph. Maybe it's time to refactor this code for
general use in Boost...
This sounds good. I'm trying to develop an introspection framework for
C++ classes (and later dynamically created classes), so I will already
have the inheritance information. I expect your implementation makes
heavy use of typeid() and dynamic_cast?
Other conversions would have to be registered explicitly (char - int,
char const* - std::string, ...), possibly half-automated by using
typelists and mpl algorithms.
It's too bad that we have to replicate at runtime what the compiler
already knows how to do at compile time (namely navigating inheritance
hierarchies)...
I have looked at Boost.Python, and it is very similar to what I had in
mind. Would it be possible to make Boost.Python more general to describe
C++ class information for runtime use, and have Boost.Python be a subset?
I don't have a lot of time on my hands, but if you think this would be a
good idea, I would love to give it a try (except that I'm a little scared
by Boost.Python's complexity, and I don't know Python (yet)).
BTW, how does Boost.Python compare to SWIG (http://www.swig.org/) ?
It seems to supports Python, amongst others.
The code is in libs/python/src/object/inheritance.cpp.
I'll look into that. Thanks for the pointer.
Best regards.
--Remy
Remove anti-spam sequence in reply address for a timely response.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Implicit conversions in dynamic_any / extract
Remy Blank [EMAIL PROTECTED] writes: But there has to be a better way, hasn't it? Yes**. The mechanism in Boost.Python allows you to register just the relationships between adjacent base and derived classes, and it fills in the rest of the graph. Maybe it's time to refactor this code for general use in Boost... This sounds good. I'm trying to develop an introspection framework for C++ classes (and later dynamically created classes), so I will already have the inheritance information. I expect your implementation makes heavy use of typeid() and dynamic_cast? Yes. Other conversions would have to be registered explicitly (char - int, char const* - std::string, ...), possibly half-automated by using typelists and mpl algorithms. That's a whole different beast, since it involves creating a new object. It's too bad that we have to replicate at runtime what the compiler already knows how to do at compile time (namely navigating inheritance hierarchies)... I have looked at Boost.Python, and it is very similar to what I had in mind. Would it be possible to make Boost.Python more general to describe C++ class information for runtime use, and have Boost.Python be a subset? ?? There's no way that Boost.Python could be a subset of the facility we're talking about. It does way, way more than casting around an inheritance hierarchy. IOW, it's already way more general. I don't have a lot of time on my hands, but if you think this would be a good idea, I would love to give it a try (except that I'm a little scared by Boost.Python's complexity, and I don't know Python (yet)). I don't understand. The stuff in inheritance.cpp doesn't touch Python at all. It's pure C++. BTW, how does Boost.Python compare to SWIG (http://www.swig.org/) ? It seems to supports Python, amongst others. There's an outdated comparisons page at http://www.boost.org/libs/python/doc/comparisons.html. SWIG and Boost.Python are both much better now than when that was written. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
