[C++-sig] Best practices for C++ project preparation
roman.yakovenko at gmail.com
Tue Feb 12 14:52:43 CET 2008
On Feb 12, 2008 1:30 PM, Oliver Schweitzer <oschweitzer at mac.com> wrote:
> I'm using Py++ to Boost.Python-wrap several medium-scale projects/
> libraries. So far I'm having a good time doing this, learning a lot
> about advanced C++, Boost and Python in the process. A key to Py++ is
> reading the available documentation carefully, there is a lot in it.
> Great stuff.
> My questions:
> Call policies: There is the odd "deeper" problem popping up, but most
> of my current work at wrapping classes seems to come from having to
> explicitly prescribe Call Policies for several dozen classes. Is there
> a way to adapt design/implementation on the C++ to "help" Py++ at
> guessing a good call policy?
Any coding convetion should be good enough. Ogre project, for example,
has a lot of functions which return "pointer" to some object. Almost
all of them return reference to existing object.
Python-Ogre code for setting call policies:
def Set_DefaultCall_Policies( mb ):
mem_funs = mb.calldefs ()
mem_funs.create_with_signature = True #Generated code will not compile on
for mem_fun in mem_funs:
if not mem_fun.call_policies and (declarations.is_reference
(mem_fun.return_type) or declarations.is_pointer (mem_fun.return_type)
mem_fun.call_policies = call_policies.return_value_policy(
Another idea is to change the source code:
* You can add gccxml attributes to the code:
* You can embed call policies within the code and parse it. Every
declaration has location information ( full file name and line number
). Some comment, near the function, could solve the problem.
Also be aware of call policies defaults:
> Granularity of Wrapper projects: Having several dozen classes to wrap/
> expose, what is your experience with organizing wrapper projects/
> libraries? Close to the source C++ project/namespaces?
There is no policy here. Do what ever you think is best. By the way
new version of Py++ contains very good support for multi-module
> How many Headers/Classes into one Module/Module-Builder?
Take a look on this document:
. The new version of Py++ supports 4 different "split module"
* single file
* multiple files
* fixed set of multiple files
* multiple files, where single class code is split to few files
I believe you will find "the only one".
>Working exclusive or inclusive, i.e. exposing only carefully selected
> try to expose all and everything?
Both :-): exclude everything, and than include declarations from
specific namespaces. Thus when you add "implementation details" you
will not have to change the script code.
> One goal is having not ever to touch the Py++-generated code, just work in Python and the wrappee lib.
It should be possible.
C++ Python language binding
More information about the Cplusplus-sig