[boost] Re: [BoostBook] Guinea pig request
On Thu, 27 Mar 2003 10:40:26 -0600 (CST), William E. Kempf [EMAIL PROTECTED] wrote:
Problems building:
* On Mandrake 9.1 I had no issues.
* On Cygwin, I get the result:
xslt-xsltproc bin\gcc\debug\boost.docbook
'XML_CATALOG_FILES' is not recognized as an internal or external command,
operable program or batch file.
XML_CATALOG_FILES=catalog.xml xsltproc --xinclude -o
bin\gcc\debug\boost.docbook
C:\cygwin\home\wekempf\boost/tools/boostbook/xsl/docbook.xsl
src\boost.xml
XML_CATALOG_FILES={something} xsltproc ...
This is bash syntax for temporarily setting an environment variable for
the duration of the xsltproc program run. Are you using bash on Cygwin,
or the normal cmd.exe shell? The latter probably doesn't understand this
syntax.
.failed xslt-xsltproc bin\gcc\debug\boost.docbook...
I have the following installed under cygwin:
libxml2 2.4.23-1
libxslt 1.0.13-1
At this point, I have no clue how to diagnose the problem.
Probably not related to any of these.
HTH,
-- Remy
Remove anti-spam sequence in reply address for a timely response.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: any_cast issues
On Fri, 31 Jan 2003 10:12:42 +0200, Greg Dehaas [EMAIL PROTECTED] wrote:
Hi All,
I'm probably being stoopid, but if someone could point me in the right
direction, thanks :)
I've got this:
boost::any test = Test Me;
boost::any test = std::string(Test Me);
int nTest=0;
try
{
nTest = boost::any_castint(test);
}
catch(const boost::bad_any_cast )
{
MessageBox(NULL,Bad Cast,Bad Cast,0);
}
And the error message is:
c:\dev\boost\boost\any.hpp(105) : error C2536: 'boost::any::holderchar
[8]::held' : cannot specify explicit initializer for arrays
c:\dev\boost\boost\any.hpp(122) : see declaration of 'held'
c:\dev\boost\boost\any.hpp(103) : while compiling class-template
member function '__thiscall boost::any::holderchar
[8]::boost::any::holderchar [8](const char ()[8])'
HTH,
--Remy
Remove anti-spam sequence in reply address for a timely response.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Implicit conversions in dynamic_any / extract
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?
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.
But there has to be a better way, hasn't it?
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
[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
[boost] Re: Re: Implicit conversions in dynamic_any / extract
On Fri, 22 Nov 2002 11:10:19 -0500, David Abrahams [EMAIL PROTECTED] wrote: Remy Blank [EMAIL PROTECTED] writes: 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. This is not what I meant. The word subset was badly chosen. Sorry for the confusion. As I understand, Boost.Python features a class description and object management framework, which allows to describe the type of a class, its inheritance, the members it contains, and to instantiate, access and modify objects of these classes. This can be called an introspection and object management facility, can't it? That was the goal of the library I am trying to develop. Looking at Boost.Python, I saw that much (if not all) I needed was already there, and much more. So my question was: could the introspection and object management parts be separated from the Python-specific code? Agreed, my question was badly formulated. 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++. I haven't yet looked at inheritance.cpp, but your comment confirms that there is some very generic, not Python-dependent, code in Boost.Python that provides the functionality needed for an introspection framework. Anyway, I'll dive into inheritance.cpp and friends, and if positive, I'll come back with a proposal. Thanks for your answers! 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
