[pygccxml-commit] SF.net SVN: pygccxml:[1382]
Brought to you by:
mbaas,
roman_yakovenko
|
From: <rom...@us...> - 2008-08-05 15:40:21
|
Revision: 1382
http://pygccxml.svn.sourceforge.net/pygccxml/?rev=1382&view=rev
Author: roman_yakovenko
Date: 2008-08-05 15:40:28 +0000 (Tue, 05 Aug 2008)
Log Message:
-----------
updating history
Modified Paths:
--------------
pygccxml_dev/docs/history/history.rest
pyplusplus_dev/docs/history/history.rest
Modified: pygccxml_dev/docs/history/history.rest
===================================================================
--- pygccxml_dev/docs/history/history.rest 2008-08-05 15:31:48 UTC (rev 1381)
+++ pygccxml_dev/docs/history/history.rest 2008-08-05 15:40:28 UTC (rev 1382)
@@ -25,7 +25,7 @@
-----------
-Version SVN
+Version 1.0
-----------
1. Support for ellipsis was added.
@@ -53,12 +53,15 @@
4. The recomended `GCC-XML`_ version to use with this release is CVS revision 123.
This revision introduces small, but very important feature. `GCC-XML`_
started to dump artificial declarations (constructor, destructor, operator=).
- ``pygccxml.declarations.type_traits`` functions were updated to use new
+ ``pygccxml.declarations.type_traits`` functions were updated to use the new
information.
5. ``declarations.decl_printer_t`` class dumps almost all available information
about a declaration.
+6. ``declarations.is_same_function`` was fixed and now it treats
+ "covariant returns" right.
+
-------------
Version 0.9.5
-------------
Modified: pyplusplus_dev/docs/history/history.rest
===================================================================
--- pyplusplus_dev/docs/history/history.rest 2008-08-05 15:31:48 UTC (rev 1381)
+++ pyplusplus_dev/docs/history/history.rest 2008-08-05 15:40:28 UTC (rev 1382)
@@ -27,10 +27,10 @@
Version SVN
-----------
-1. The algorithm, which calculates what member functions should be redefined in
+1. The algorithm, which calculates what member functions should be redefined in
derived class wrappers, was improved. Many thanks to Julian Scheid for the bug
fix.
-
+
The change explanation.
.. code-block:: C++
@@ -41,9 +41,9 @@
class B: public A{
};
-
- Previous version of `Py++`_ didn't generate wrapper for class ``B``, even
- though ``B`` inherits ``A``'s virtual function. Now if you have the following
+
+ Previous version of `Py++`_ didn't generate wrapper for class ``B``, even
+ though ``B`` inherits ``A``'s virtual function. Now if you have the following
Python code:
.. code-block:: Python
@@ -54,13 +54,13 @@
def foo(self):
print "C.foo"
- then when ``foo`` is invoked on this instance on the C++ side of things, the
+ then when ``foo`` is invoked on this instance on the C++ side of things, the
Python code won't be executed as the wrapper was missing.
**Warning!** **There is a possibility that your generated code will not work!**
**Keep reading.**
- If you use "function transformation" functionality, than it is possible the
+ If you use "function transformation" functionality, than it is possible the
generated code will **NOT** work. Consider next example:
.. code-block:: C++
@@ -89,31 +89,31 @@
.. code-block:: C++
namespace bp = boost::python;
-
+
struct B_wrapper : B, bp::wrapper< B > {
virtual void foo( int & i ) const { ... }
-
+
static boost::python::tuple default_foo( ::B const & inst )
{ ... }
-
- virtual void foo( int & i ) const
+
+ virtual void foo( int & i ) const
{ ... }
-
+
static boost::python::object default_foo( ::A const & inst )
{ ... }
};
...
- bp::class_< B_wrapper, bp::bases< A > >( "B" )
+ bp::class_< B_wrapper, bp::bases< A > >( "B" )
.def( "foo", (boost::python::tuple (*)( ::B const & ))( &B_wrapper::default_foo ) )
.def( "foo", (boost::python::object (*)( ::A const & ))( &B_wrapper::default_foo ) );
- As you can see, after applying the transformation both functions have same
- signature. Do you know what function will be called in some situation? I do -
+ As you can see, after applying the transformation both functions have same
+ signature. Do you know what function will be called in some situation? I do -
the wrong one :-(.
- Unfortunately, there is no easy work around or some trick that you can use,
+ Unfortunately, there is no easy work around or some trick that you can use,
which will not break the existing code. I see few solutions to the problem:
-
+
* change the alias of the functions
.. code-block:: Python
@@ -129,15 +129,21 @@
* `Py++`_ can introduce a configuration, that will preserve the previous behaviour.
I think this is a wrong way to go and doing the API changes is the 'right'
longer term solution.
-
+
If you **absolutely need** to preserve API backward compatible, contact me
and I will introduce such configuration option.
Sorry for inconvenience.
-2. Few bugs, related to Indeing Suite 2, were fixed. Many thanks to Oliver Schweitzer
+2. Few bugs, related to Indexing Suite 2, were fixed. Many thanks to Oliver Schweitzer
for reporting them.
+3. New and highly experimental feature was introduced -
+ `Boost.Python and ctypes integration`_.
+ ../documentation/ctypes_integration.html
+
+.. _`Boost.Python and ctypes integration` : ../documentation/ctypes_integration.html
+
-------------
Version 0.9.5
-------------
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|