[C++-sig] Best practices for C++ project preparation

Roman Yakovenko 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:
> Hi,
>
> 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.

Thank you!

> 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 mem_fun.call_policies:
            continue
        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(
call_policies.reference_existing_object )

Another idea is to change the source code:
* You can add gccxml attributes to the code:
http://gccxml.org/HTML/Running.html
* 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:
http://language-binding.net/pyplusplus/documentation/functions/call_policies.html#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
development:

http://language-binding.net/pyplusplus/documentation/multi_module_development.html

> How many Headers/Classes into one Module/Module-Builder?

Take a look on this document:
http://language-binding.net/pyplusplus/documentation/split_module.html
. The new version of Py++ supports 4 different "split module"
strategies:
    * 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
classes/members or
> 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.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/



More information about the Cplusplus-sig mailing list