Recent changes to bugs

#45 GCC 4.7.2 Compatibility

Alex Leach — Mon, 08 Jul 2013 11:46:55 -0000

Hi,

Sorry I've taken so long to report back. It is a gccxml problem, and as I needed it to work, I spent quite a lot of time looking into gccxml's source code...

I went so far as to remove the internal GCC 4.2. compiler, and turned gccxml into a GCC plugin, compatible with GCC 4.7+. It doesn't work on Windows, however, essentially due to a lack of interest by GCC core maintainers.

Although I had to make a couple of edits to the pygccxml source code, it seems to work well. I've upgraded the py++ script I attached above, to recursively create Boost Python bindings from a given directory, and ended up with over 2,000 Boost Python source code files, from a subset of a complete library I'd like to use from python. Although I haven't tried compiling or running it, the code looks good, so it seems to work well..

I guess you'll be interested in what patches I needed to implement:-

Changed the logic in parser.source_reader.source_reader_t.create_xml_file, so that it prints all output from GCC, and doesn't raise an exception when warning messages are printed. A patch is attached.
There's a missing fundamental type. IIRC: uint128_t. I just hacked a fix, (returned from a function instead of raising an error) I'm afraid, although I saw an example of where someone had submitted a similar set of patches.. I should have time to send patches in a few months, but just don't atm I'm afraid...

I do have a couple of questions, however. I was looking through the generated source files, and noticed that all includes use absolute paths, and every source file includes the umbrella header python.hpp>.

I was planning on using sed to replace the prefix component (e.g. /usr/include/) from the include paths, but can pyplusplus do that already, given some include paths?

Replacing #include <boost/python.hpp> with separate includes would be a lot more work to implement, I guess, but it'd probably be less work than doing it manually for over 2,000 header files, which was only a subset of a library I'd like to use from Python... That'll take forever to compile!

Again, I don't have the time to look into this now, but I would be willing to look into this in a few months time (ie. after completing my PhD). If you've any thoughts, I'd appreciate suggestions on where in the code to look...

Another couple of places I'd be interested in working on / using sed for:

Automatically change case convention from whatever it is, to something a bit more PEP7/8-like, for all class, function, method and attribute names exposed to Python. e.g. convert function and method names to snake_case.
If a method name starts with 'get' or 'Get', use add_property instead of def. If a corresponding setFoo method is declared, use that as well.
I was planning on using sphinx, sphinx-breathe and doxygen to document the C++ code, and started doing so with manually exposed code. I'd like to automate that process as much as possible... e.g. add a lot of either @sa or @copydoc directives to inline code comments.

I've got to say, I think you've made a great package here! It must have taken a lot of time to get it where it is now! Thanks for sharing!

Kind regards,
Alex

#45 GCC 4.7.2 Compatibility

Alex Leach — Wed, 15 May 2013 16:41:02 -0000

No, not yet... I've been hand-writing my Boost Python wrappers since then, but I do need to have a look at the gccxml updates, as I did some work on the gccxml build system and could have done with these changes, by the look of them. Thanks for letting me know; I'll check it out when I get a chance

#45 GCC 4.7.2 Compatibility

Jason Kankiewicz — Wed, 15 May 2013 16:21:17 -0000

Have you tried using the latest version of GCC_XML?
The comment on its latest commit reads:

Update GCC 4.8 headers to work with gccxml's GCC 4.2 parser

Transcription error with Boost.Function template parameter

Jason Kankiewicz — Wed, 15 May 2013 16:11:27 -0000

The Boost.Python code creator for member functions doesn't correctly transcribe the preferred syntax of a Boost.Function instantiation's template argument because it inserts an extra pair of parentheses between the return type and the arguments in the function signature.

For example, when binding the member function

void A::f(boost::function<W (X x, Y y, Z z)>)

Py++ will output

typedef void ( ::A::*f_function_type )( ::boost::function< W ()(X, Y, Z) > ) ;

instead of

typedef void ( ::A::*f_function_type )( ::boost::function< W (X, Y, Z) > ) ;

and this causes a compilation error with a message like

"function returning function is not allowed".

This bug was encountered with r1856.

No value traits header for abstract base class

Jason Kankiewicz — Wed, 27 Mar 2013 19:23:31 -0000

If a class ABC contains at least one pure virtual member function then Py++ will not generate an _ABC__value_traits.pypp.hpp header for it. This header's absence causes compilation errors when Py++ exposes STL containers using the Boost.Python Indexing Suite v2.

GCC 4.7.2 Compatibility

Alex Leach — Fri, 01 Feb 2013 01:32:27 -0000

Hi,
I'm trying to use Py++ to help generate wrappers for this C++ library I had started wrapping with Boost. I thought this could save me a LOT of time and as I've only just started learning Boost.Python, figured this could give me a real head start!

Unfortunately, I'm having some problems, I think because gccxml only officially supports the c++98 standard, whereas the library I'm wrapping conforms to the C++11 standard.

Before realising this, I went ahead and wrote a simple command line utility to use Py++, as the headers I am wrapping are installed in a system-wide folder, and the GUI tries to write there, even though my user doesn't have write-permissions.

I attach it for anyone else who'd like a simple command-line interface to PyPlusPlus.

An "explicit" qualifier on a constructor is ignored

Jason Kankiewicz — Sat, 19 Jan 2013 01:14:14 -0000

The pyplusplus.decl_wrappers.calldef_wrapper.constructor_t.does_define_implicit_conversion method doesn't take the presence of an "explicit" qualifier on the constructor into account thereby enabling in Python a type conversion that is forbidden in C++.

This bug was encountered in revision 1856.

Bad keyword argument in transformed method's signature

Jason Kankiewicz — Wed, 02 Jan 2013 22:14:42 -0000

The list of keyword arguments i.e. '( bp::arg("first"), bp::arg("second"). ... )' that Py++ generates for a transformed member function includes its corresponding wrapper function's instance argument i.e. '( bp::arg("inst"), bp::arg("first"), bp::arg("second"), ... )'.

The "inst" argument should not be included in the keyword arguments because it is not an argument of the original member function and it would not be there if the member function's signature had not been transformed.

This bug was encountered in revision 1856.

Wrapper for abstract base class won't compile

Jason Kankiewicz — Wed, 19 Dec 2012 16:54:34 -0000

If one excludes a pure virtual member function of an abstract base class then Py++ will generate a wrapper class for it that won't compile because it doesn't contain an override for the excluded pure virtual function.

For example:

namespace example
{

class Interface
{
public:

virtual void ignoreMe() const = 0;

}

} // namespace example

example = mb.global_ns.namespace('example')
Interface = example.class_('Interface')
Interface.member_function('ignoreMe').exclude()

boost-1.46.1/boost/python/object/value_holder.hpp(66): error: object of abstract class type "Interface_wrapper" is not allowed:
pure virtual function "example::Interface::ignoreMe(...) const" has no overrider
Value m_held;
^boost/python/object/value_holder.hpp(66): error: object of abstract class type "Interface_wrapper" is not allowed:
pure virtual function "example::Interface::ignoreMe(...) const" has no overrider
Value m_held;
^

This bug was encountered in revision 1856.

Syntax error in Boost.Python Indexing Suite V2

Jason Kankiewicz — Wed, 25 Jan 2012 00:16:35 -0000

The ICC compiler reports the following syntax error:
.../indexing_suite/workaround.hpp:25: Problem during constant expression evaluation: syntax error

None of the other BOOST_WORKAROUND invocations in that header file are enclosed in parentheses.
Removing the enclosing parentheses prevents the syntax error report.

This bug was encountered in revision 1856.