Re: todo.txt "Implement type_info streaming for GCC"
A while ago, David Abrahams wrote:
There are a few places where error reporting in Boost.Python depends on being able to show users a reasonable representation of a C++ type name. Currently, we use typeid(x).name() to get the name. Most compilers produce a good result, however g++ does not. I just ran a small experiment to see if the type encoding scheme used by G++ could easily be deciphered, and it appears that it can. If we want to improve error reporting with G++, it should be relatively easy.
I seem to recall that the g++ typeid().name() gives you the type's mangled name, in which case the supplied c++filt will decode it for you (maybe modulo one leading underscore?). If so, I think a simple system() call would probably suffice for what David is describing. Or am I missing some more info on the difficulties involved? The source to the demangler is GPL'd, of course (in gcc/libiberty/cp-demangle.c) and is also including in gdb, AFAIK. It's currently >3000 lines of code, so I wouldn't recommend trying to reimplement it for Boost.Python! -- Raoul Gough "Let there be one measure for wine throughout our kingdom, and one measure for ale, and one measure for corn" - Magna Carta
Raoul Gough <RaoulGough@yahoo.co.uk> writes:
A while ago, David Abrahams wrote:
There are a few places where error reporting in Boost.Python depends on being able to show users a reasonable representation of a C++ type name. Currently, we use typeid(x).name() to get the name. Most compilers produce a good result, however g++ does not. I just ran a small experiment to see if the type encoding scheme used by G++ could easily be deciphered, and it appears that it can. If we want to improve error reporting with G++, it should be relatively easy.
I seem to recall that the g++ typeid().name() gives you the type's mangled name, in which case the supplied c++filt will decode it for you (maybe modulo one leading underscore?). If so, I think a simple system() call would probably suffice for what David is describing. Or am I missing some more info on the difficulties involved?
The source to the demangler is GPL'd, of course (in gcc/libiberty/cp-demangle.c) and is also including in gdb, AFAIK. It's currently >3000 lines of code, so I wouldn't recommend trying to
It's even easier than that; GCC supplies a library with a function you can call to demangle these names. I've forgotten the name, of course :( -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hello, Say I have an abstract base class A, an implementation class B, and a function, void foo(A* a); If I do a normal boost::python binding, then I can call foo (from python) with instances of B... (at least, I think I can?). The problem I am having is that we are using boost::intrusive_ptr all over our project already. (We could change this perhaps, but that's the way it is now). When I expose my classes to boost, it looks like: class_<A, boost::intrusive_ptr<A> >("A").....; class_<B, boost::intrusive_ptr<B> >("B").....; In this case, when I have an python object which wraps an instance of B, I can't call my foo(A*); function. How can I make it so that the "polymorphic search" succeeds, in matching intrusive_ptr<B> against A* parameters?
"DL" == Dusty Leary <dleary@ttlc.net> writes: [snip]
DL> class_<A, boost::intrusive_ptr<A> >("A").....; class_<B, DL> boost::intrusive_ptr<B> >("B").....; DL> How can I make it so that the "polymorphic search" succeeds, DL> in matching intrusive_ptr<B> against A* parameters? AFAIK, class_<B, bases<A>, boost::intrusive_ptr<B> >("B").....; should do the trick. But note that if you want to subclass these in Python and have your C++ code use the overriden virtual functions from Python you'll need to create a wrapper for the classes as described here: http://www.boost.org/libs/python/doc/tutorial/doc/class_virtual_functions.ht... The intrusive_ptr should be handled automatically by Boost.Python. Look here: http://www.boost.org/libs/python/doc/v2/class.html#class_-spec for more details. HTH, prabhu
"Dusty Leary" <dleary@ttlc.net> writes:
Say I have an abstract base class A, an implementation class B, and a function, void foo(A* a); If I do a normal boost::python binding, then I can call foo (from python) with instances of B... (at least, I think I can?).
The problem I am having is that we are using boost::intrusive_ptr all over our project already. (We could change this perhaps, but that's the way it is now). When I expose my classes to boost, it looks like:
class_<A, boost::intrusive_ptr<A> >("A").....; class_<B, boost::intrusive_ptr<B> >("B").....;
In this case, when I have an python object which wraps an instance of B, I can't call my foo(A*); function.
How can I make it so that the "polymorphic search" succeeds, in matching intrusive_ptr<B> against A* parameters?
class_<A, boost::intrusive_ptr<A> >("A").....; class_<B, boost::intrusive_ptr<B>, bases<A> >("B").....; ^^^^^^^^ ?? -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Thu, Jul 10, 2003 at 05:18:58PM -0400, David Abrahams wrote:
It's even easier than that; GCC supplies a library with a function you can call to demangle these names. I've forgotten the name, of course :(
See http://aspn.activestate.com/ASPN/Mail/Message/1441745 -Adam
Adam Hupp <hupp@cs.wisc.edu> writes:
On Thu, Jul 10, 2003 at 05:18:58PM -0400, David Abrahams wrote:
It's even easier than that; GCC supplies a library with a function you can call to demangle these names. I've forgotten the name, of course :(
Of course, we still have the GPL problem if we link to that :( -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Adam Hupp <hupp@cs.wisc.edu> writes:
On Thu, Jul 10, 2003 at 05:18:58PM -0400, David Abrahams wrote:
It's even easier than that; GCC supplies a library with a function you can call to demangle these names. I've forgotten the name, of course :(
Of course, we still have the GPL problem if we link to that :(
I don't get it - would you be releasing binaries which include __cxa_demangle but no other (L)GPL'd code? I mean, if the binary came out of g++ then you've probably got LGPL'd libstdc++ code already. -- Raoul Gough "Let there be one measure for wine throughout our kingdom, and one measure for ale, and one measure for corn" - Magna Carta
Raoul Gough <RaoulGough@yahoo.co.uk> writes:
David Abrahams <dave@boost-consulting.com> writes:
Adam Hupp <hupp@cs.wisc.edu> writes:
On Thu, Jul 10, 2003 at 05:18:58PM -0400, David Abrahams wrote:
It's even easier than that; GCC supplies a library with a function you can call to demangle these names. I've forgotten the name, of course :(
Of course, we still have the GPL problem if we link to that :(
I don't get it - would you be releasing binaries which include __cxa_demangle but no other (L)GPL'd code? I mean, if the binary came out of g++ then you've probably got LGPL'd libstdc++ code already.
What about MinGW? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Raoul Gough <RaoulGough@yahoo.co.uk> writes:
David Abrahams <dave@boost-consulting.com> writes:
Of course, we still have the GPL problem if we link to that :(
I don't get it - would you be releasing binaries which include __cxa_demangle but no other (L)GPL'd code? I mean, if the binary came out of g++ then you've probably got LGPL'd libstdc++ code already.
What about MinGW?
Not sure what you mean - I was already thinking about MinGW :-) Well, seriously, I mostly use the MinGW version of g++, so my comment inherently comes from within that context. As I understand it (although I'm no (L)GPL expert) I can freely redistribute binaries that include libstdc++ in compiled form. Contrast this with cygwin1.dll which is covered by the full GPL, so binaries that use it import the GPL onto all sources for the binary (obviously not desirable for Boost). This is certainly something to be aware of if you're distributing binaries at all. Actually, now that I look at some libstdc++ sources, they seem to be covered by the normal GPL but with a special exemption along the lines "...this file does not by itself cause the resulting executable to be covered by the GNU General Public License...". Oh, wait a second - here's some possibly relevant info from cp-demangle.c (which contains __cxa_demangle): In addition to the permissions in the GNU General Public License, the Free Software Foundation gives you unlimited permission to link the compiled version of this file into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into a combined executable.) I didn't think that you would be distributing any binaries, anyway. Now, cutting and pasting the demangler code, that would be a different story :-) -- Raoul Gough "Let there be one measure for wine throughout our kingdom, and one measure for ale, and one measure for corn" - Magna Carta
Raoul Gough <RaoulGough@yahoo.co.uk> writes: [snip]
Contrast this with cygwin1.dll which is covered by the full GPL, so binaries that use it import the GPL onto all sources for the binary (obviously not desirable for Boost). This is certainly something to be aware of if you're distributing binaries at all.
I really shouldn't have started commenting on legal issues! I just looked at the Cygwin license info (http://www.cygwin.com/licensing.html) and it looks like any "license that complies with the Open Source definition" is acceptable for binaries that use libcygwin.a, not just the GPL. IANAL, etc... -- Raoul Gough "Let there be one measure for wine throughout our kingdom, and one measure for ale, and one measure for corn" - Magna Carta
Raoul Gough <RaoulGough@yahoo.co.uk> writes:
The source to the demangler is GPL'd, of course (in gcc/libiberty/cp-demangle.c) and is also including in gdb, AFAIK. It's currently >3000 lines of code, so I wouldn't recommend trying to reimplement it for Boost.Python!
Well, that might just be because it's bad code or written in C with insufficient abstraction. From http://mail.python.org/pipermail/c++-sig/2002-June/001277.html it doesn't look all that hard. (famous last words). -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Raoul Gough <RaoulGough@yahoo.co.uk> writes:
The source to the demangler is GPL'd, of course (in gcc/libiberty/cp-demangle.c) and is also including in gdb, AFAIK. It's currently >3000 lines of code, so I wouldn't recommend trying to reimplement it for Boost.Python!
Well, that might just be because it's bad code or written in C with insufficient abstraction. From http://mail.python.org/pipermail/c++-sig/2002-June/001277.html it doesn't look all that hard.
(famous last words).
I once tried to look into cp-demangle.c with the naive aim of fixing a bug I'd found (ha! poor demented fool that I was) but quickly put it in my too hard basket. I hadn't heard of the __cxa_demangle routine before (thanks to Adam Hupp for the info). It seems to add about 20kB of code to an executable (on i386, mingw) which is not bad in the context of Boost.Python. What about backwards compatability, if the demangle routine is only available in >=3.1 gcc? c++filt (AFAIK) has always been available as a command-line tool. -- Raoul Gough "Let there be one measure for wine throughout our kingdom, and one measure for ale, and one measure for corn" - Magna Carta
participants (5)
-
Adam Hupp -
David Abrahams -
Dusty Leary -
Prabhu Ramachandran -
Raoul Gough