[pygccxml-commit] SF.net SVN: pygccxml: [797] pyplusplus_dev/docs
Brought to you by:
mbaas,
roman_yakovenko
From: <rom...@us...> - 2006-12-13 22:12:03
|
Revision: 797 http://svn.sourceforge.net/pygccxml/?rev=797&view=rev Author: roman_yakovenko Date: 2006-12-13 14:12:02 -0800 (Wed, 13 Dec 2006) Log Message: ----------- fixing spelling errors Modified Paths: -------------- pyplusplus_dev/docs/bpl_lessons_learned/lessons_learned.rest pyplusplus_dev/docs/documentation/architecture.rest pyplusplus_dev/docs/documentation/best_practices.rest pyplusplus_dev/docs/documentation/containers.rest pyplusplus_dev/docs/documentation/feedback.rest pyplusplus_dev/docs/documentation/functions/call_policies.rest pyplusplus_dev/docs/documentation/functions/default_args.rest pyplusplus_dev/docs/documentation/functions/overloading.rest pyplusplus_dev/docs/documentation/functions/registration_order.rest pyplusplus_dev/docs/documentation/functions/transformation/built_in/built_in.rest pyplusplus_dev/docs/documentation/functions/transformation/built_in/inout.rest pyplusplus_dev/docs/documentation/functions/transformation/built_in/input.rest pyplusplus_dev/docs/documentation/functions/transformation/built_in/input_static_array.rest pyplusplus_dev/docs/documentation/functions/transformation/built_in/output.rest pyplusplus_dev/docs/documentation/functions/transformation/built_in/output_static_array.rest pyplusplus_dev/docs/documentation/functions/transformation/custom/custom.rest pyplusplus_dev/docs/documentation/functions/transformation/name_mangling.rest pyplusplus_dev/docs/documentation/how_to.rest pyplusplus_dev/docs/documentation/index.rest pyplusplus_dev/docs/documentation/inserting_code.rest pyplusplus_dev/docs/documentation/properties.rest pyplusplus_dev/docs/documentation/tutorials/module_builder/module_builder.rest pyplusplus_dev/docs/download.rest pyplusplus_dev/docs/examples/easybmp/easybmp.rest pyplusplus_dev/docs/history/history.rest pyplusplus_dev/docs/links.rest pyplusplus_dev/docs/peps/dsl_challenge.rest pyplusplus_dev/docs/peps/peps_index.rest pyplusplus_dev/docs/pyplusplus.rest pyplusplus_dev/docs/quotes.rest Modified: pyplusplus_dev/docs/bpl_lessons_learned/lessons_learned.rest =================================================================== --- pyplusplus_dev/docs/bpl_lessons_learned/lessons_learned.rest 2006-12-13 08:16:21 UTC (rev 796) +++ pyplusplus_dev/docs/bpl_lessons_learned/lessons_learned.rest 2006-12-13 22:12:02 UTC (rev 797) @@ -25,7 +25,7 @@ .. include:: ./shared_ptr/definition.rest .. _`boost::shared_ptr< const T>` : ./shared_ptr/shared_ptr.html - + .. _`Py++` : ./../pyplusplus.html .. _`pygccxml` : http://www.language-binding.net/pygccxml/pygccxml.html .. _`SourceForge`: http://sourceforge.net/index.php Modified: pyplusplus_dev/docs/documentation/architecture.rest =================================================================== --- pyplusplus_dev/docs/documentation/architecture.rest 2006-12-13 08:16:21 UTC (rev 796) +++ pyplusplus_dev/docs/documentation/architecture.rest 2006-12-13 22:12:02 UTC (rev 797) @@ -8,7 +8,7 @@ Introduction ------------ -This document will describe an architecture behind `Py++`_. +This document will describe an architecture behind `Py++`_. --------------------------- Py++ & pygccxml integration @@ -17,18 +17,18 @@ C++ --- -C++ is very powerful programming language. The power brings complexity. It is -not an easy task to parse C++ source files and to create in memory representation -of declarations tree. The declarations tree is worth nothing, if a user is not -able to explorer it, to run queries against it or to find out traits of a +C++ is very powerful programming language. The power brings complexity. It is +not an easy task to parse C++ source files and to create in memory representation +of declarations tree. The declarations tree is worth nothing, if a user is not +able to explorer it, to run queries against it or to find out traits of a declaration or a type. -On the earlier stage of the development, I realized, that all this functionality -does not belong to code generator and should be implemented out side of it. -`pygccxml`_ project was born. `pygccxml`_ made the code generator to be smaller +On the earlier stage of the development, I realized, that all this functionality +does not belong to code generator and should be implemented out side of it. +`pygccxml`_ project was born. `pygccxml`_ made the code generator to be smaller and C++ parser independent. It provides next services: -* definition of classes, that describe C++ declaration and types, and their +* definition of classes, that describe C++ declaration and types, and their analyzers ( type traits ) * C++ source files parsing and caching functionality @@ -45,7 +45,7 @@ * indexing suite parameters * generate warnings/hints - + * ... @@ -57,8 +57,8 @@ Parsing integration ~~~~~~~~~~~~~~~~~~~ -`Py++`_ provides it's own "API" to configure `pygccxml`_ parsing services. The -"API" I am talking about, is arguments to ``module_builder.__init__`` method. +`Py++`_ provides it's own "API" to configure `pygccxml`_ parsing services. The +"API" I am talking about, is arguments to ``module_builder.__init__`` method. We think, that exposing those services via `Py++`_ simplifies its usage. @@ -78,11 +78,11 @@ * query engine API -The user should be familiar with these parts and relevant API. In my opinion, -wrapping or hiding the API will not provide an additional value. The interface +The user should be familiar with these parts and relevant API. In my opinion, +wrapping or hiding the API will not provide an additional value. The interface of all those services is pretty simple and well polished. -Before I explain how these services are integrated, take a look on next source +Before I explain how these services are integrated, take a look on next source code: .. code-block:: Python @@ -100,43 +100,43 @@ my_class.rename("MyClass") -What you see here, is a common pattern, that will appear in all projects, that +What you see here, is a common pattern, that will appear in all projects, that use `Py++`_: * find the declaration(s) * give the instruction(s) to the code generator engine -What is the point of this example? From the user point of view it is perfectly -good, it makes a lot of sense to configure the code generation engine, using -the declarations tree. How does `Py++`_ add missing functionality to -``pygccxml.declarations`` classes? There were few possible solutions to the +What is the point of this example? From the user point of view it is perfectly +good, it makes a lot of sense to configure the code generation engine, using +the declarations tree. How does `Py++`_ add missing functionality to +``pygccxml.declarations`` classes? There were few possible solutions to the problem. The next one was implemented: 1. ``pygccxml.parser`` package interface was extended. Instead of creating - a concrete instance of declaration classes, ``pygccxml.parser`` package uses + a concrete instance of declaration classes, ``pygccxml.parser`` package uses a factory. - + 2. ``pyplusplus.decl_wrappers`` package defines classes, which derive from ``pygccxml.declarations`` classes and defines the factory. -The implemented solution is not the simplest one, but it provides an additional +The implemented solution is not the simplest one, but it provides an additional value to the project: -* the code generation engine configuration and declarations tree are tightly +* the code generation engine configuration and declarations tree are tightly coupled * the functionality provided by ``pygccxml.declarations`` and ``pygccxml.parser`` packages is available for ``pyplusplus.decl_wrappers`` classes -* classes defined in ``pyplusplus.decl_wrappers`` package implement next +* classes defined in ``pyplusplus.decl_wrappers`` package implement next functionality: - - * setting reasonable defaults for the code generation engine( call policies, + + * setting reasonable defaults for the code generation engine( call policies, indexing suite, ... ) - + * provides user with additional information( warnings and hints ) - + * as a bonus, `pygccxml`_ remained to be stand-alone project ---------------------- @@ -160,7 +160,7 @@ ``Code creators`` ----------------- -Do you know how many ways exist to export member function? If you will try to +Do you know how many ways exist to export member function? If you will try to answer the question, consider next function characteristics and their mix: * virtuality( non virtual, virtual or pure virtual ) @@ -171,59 +171,59 @@ * overloads -As you see, there are a lot of use cases. How do ``code creators`` solve the problem? +As you see, there are a lot of use cases. How do ``code creators`` solve the problem? Definition ~~~~~~~~~~ ``Code creator`` is an in-memory fragment of a C++ code. -Also, ``code creator`` can represent an arbitrary C++ code, in practice it -represents logically complete block. +Also, ``code creator`` can represent an arbitrary C++ code, in practice it +represents logically complete block. Example of ``code creators``: * ``code_creators.enum_t`` generates registration code for an enumeration - -* ``code_creators.mem_fun_pv_t`` generates registration code for public, pure + +* ``code_creators.mem_fun_pv_t`` generates registration code for public, pure virtual function - -* ``code_creators.mem_fun_pv_wrapper_t`` generates declaration code for public, + +* ``code_creators.mem_fun_pv_wrapper_t`` generates declaration code for public, pure virtual function - + * ``code_creators.include_t`` generates include directives -* ``code_creators.custom_text_t`` adds some custom( read user ) text\\code to +* ``code_creators.custom_text_t`` adds some custom( read user ) text\\code to the generated code -There are primary two groups of ``code creators``: declaration based and others. +There are primary two groups of ``code creators``: declaration based and others. Declaration based ``code creator`` keeps reference to the declaration ( ``pyplusplus.decl_wrapper.*`` class instance ). During code generation process, -it reads its settings( the code generation engine instructions ) from the -declaration. Declaration based ``code creators`` also divided into two groups. -The first group creates registration code, where the second one creates +it reads its settings( the code generation engine instructions ) from the +declaration. Declaration based ``code creators`` also divided into two groups. +The first group creates registration code, where the second one creates wrapper\\helper declaration code. I will reuse `this example`__, from `Boost.Python`_ tutorials. .. __ : http://boost.org/libs/python/doc/tutorial/doc/html/python/exposing.html#python.virtual_functions_with_default_implementations -1. ``BaseWrap::f``, ``BaseWrap::default_f`` - declaration code is created by +1. ``BaseWrap::f``, ``BaseWrap::default_f`` - declaration code is created by ``code_creators.mem_fun_v_wrapper_t`` 2. ``f`` registration code is created by ``code_creators.mem_fun_v_t``. This - code creator also keeps reference to the relevant instance of + code creator also keeps reference to the relevant instance of ``code_creators.mem_fun_v_wrapper_t`` class. -Composite ``code creator`` is a creator, which contains other creators. Composite -``code creator`` embeds the code, created by internal ``code creators``, within +Composite ``code creator`` is a creator, which contains other creators. Composite +``code creator`` embeds the code, created by internal ``code creators``, within the code it creates. For example: * ``code_creators.class_t``: - First of all it creates class registration code ( ``class_<...>`` ), after - this it appends to it code generated by internal creators. + First of all it creates class registration code ( ``class_<...>`` ), after + this it appends to it code generated by internal creators. * ``code_creators.module_body_t``: @@ -242,7 +242,7 @@ ``Code creators tree`` ~~~~~~~~~~~~~~~~~~~~~~ -``code_creators.module_t`` class is a top level ``code creator``. Take a look on +``code_creators.module_t`` class is a top level ``code creator``. Take a look on next possible "snapshot" of the ``code creators tree``: :: @@ -262,7 +262,7 @@ <free_function_t ...> <...> -You can think about ``code creators tree`` as some kind of `AST`_. +You can think about ``code creators tree`` as some kind of `AST`_. .. _`AST`: http://en.wikipedia.org/wiki/Abstract_syntax_tree @@ -270,7 +270,7 @@ ----------------------------------- ``pyplusplus.module_creator`` package is responsible for the tree construction. -``pyplusplus.module_creator.creator_t`` is the main class of the package. It +``pyplusplus.module_creator.creator_t`` is the main class of the package. It creates the tree in few steps: 1. It builds set of exposed declarations. @@ -279,7 +279,7 @@ 3. It creates ``code creators`` and put them into the right place within the tree. 4. If a declaration describes C++ class, it applies these steps to it. -Another responsibility of ``creator_t`` class, is to analyze declarations and +Another responsibility of ``creator_t`` class, is to analyze declarations and their dependency graphs. As a result, this class can: * find out a class ``HeldType`` @@ -288,15 +288,15 @@ * find out STD containers, which should be exported -* warn user, if some declaration is not exported and it used somewhere in +* warn user, if some declaration is not exported and it used somewhere in exported declarations ( **not implemented** ) ``File writers`` ---------------- -``File writers`` classes are responsible for writing ``code creators tree`` into -the files. `Py++`_ implements next strategies of writing ``code creators tree`` +``File writers`` classes are responsible for writing ``code creators tree`` into +the files. `Py++`_ implements next strategies of writing ``code creators tree`` into files: * single file @@ -307,7 +307,7 @@ * multiple files, with huge classes are written into multiple files - provides a solution for `compiler limit`_ problem. - + .. _`compiler limit` : http://www.boost.org/libs/python/doc/v2/faq.html#c1204 The more sophisticated approach, the better understanding of ``code creators`` Modified: pyplusplus_dev/docs/documentation/best_practices.rest =================================================================== --- pyplusplus_dev/docs/documentation/best_practices.rest 2006-12-13 08:16:21 UTC (rev 796) +++ pyplusplus_dev/docs/documentation/best_practices.rest 2006-12-13 22:12:02 UTC (rev 797) @@ -115,7 +115,7 @@ for those declarations that are actually used within your library). In the ``pygccxml`` package you can set the value for the ``-fxml-start`` - option using the ``start_with_declarations`` attribute of the + option using the ``start_with_declarations`` attribute of the ``pygccxml.parser.config_t`` object that you are passing to the parser. Modified: pyplusplus_dev/docs/documentation/containers.rest =================================================================== --- pyplusplus_dev/docs/documentation/containers.rest 2006-12-13 08:16:21 UTC (rev 796) +++ pyplusplus_dev/docs/documentation/containers.rest 2006-12-13 22:12:02 UTC (rev 797) @@ -25,7 +25,7 @@ * multiset * hash_multiset -It is not a trivial task to expose C++ container to Python. Boost.Python has +It is not a trivial task to expose C++ container to Python. Boost.Python has a functionality that will help you to expose some of STL containers to `Python`_. This functionality called - "indexing suite". If you want, you can read more about indexing suite `here`__. @@ -33,15 +33,15 @@ .. __ : http://boost.org/libs/python/doc/v2/indexing.html Boost.Python, out of the box, supports only ``vector``, ``map`` and ``hash_map`` -containers. In October 2003, Raoul Gough implemented support for the rest of -containers. Well, actually he did much more - he implemented new framework. -This framework provides support for almost all C++ containers and also an easy -way to add support for custom ones. You'd better read his `post`_ to +containers. In October 2003, Raoul Gough implemented support for the rest of +containers. Well, actually he did much more - he implemented new framework. +This framework provides support for almost all C++ containers and also an easy +way to add support for custom ones. You'd better read his `post`_ to `Boost.Python`_ mailing list or `documentation`_ for the new indexing suite. Now, I am sure you have next question: if this suite is so good, why it is not -in the main branch? The short answer is that this suite has some problems on +in the main branch? The short answer is that this suite has some problems on MSVC 6.0 compiler and there are few users, that still use that compiler. The long answer is here: @@ -57,10 +57,10 @@ Py++ and indexing suites ------------------------ -`Py++`_ implements support for both indexing suites. More over, you can +`Py++`_ implements support for both indexing suites. More over, you can freely mix indexing suites. For example you can expose ``std::vector<int>`` using `Boost.Python`_ built-in indexing suite and ``std::map< int, std::string>`` using -Raoul Gough's indexing suite. +Raoul Gough's indexing suite. ----------------- How does it work? @@ -69,7 +69,7 @@ In both cases, `Py++`_ provides almost "hands free" solution. `Py++`_ keeps track of all exported functions and variables, and if it sees that there is a usage of stl container, it exports the container. In both cases, `Py++`_ -analyzes the container ``value_type`` ( or in case of mapping container +analyzes the container ``value_type`` ( or in case of mapping container ``mapped_type`` ), in order to set reasonable defaults, when it generates the code. ------------------- @@ -84,16 +84,16 @@ mb = module_builder_t( ..., indexing_suite_version=2 ) -Every declared class has ``indexing_suite`` property. If the class is an +Every declared class has ``indexing_suite`` property. If the class is an instantiation of STL container, this property contains reference to an instance -of ``indexing_suite1_t`` or ``indexing_suite2_t`` class. +of ``indexing_suite1_t`` or ``indexing_suite2_t`` class. -How does `Py++`_ know, that a class represents STL container instantiation? -Well, it uses ``pygccxml.declarations.container_traits`` to find out this. -``pygccxml.declarations.container_traits`` class, provides all functionality +How does `Py++`_ know, that a class represents STL container instantiation? +Well, it uses ``pygccxml.declarations.container_traits`` to find out this. +``pygccxml.declarations.container_traits`` class, provides all functionality needed to identify container and to find out its ``value_type`` -( ``mapped_type`` ). +( ``mapped_type`` ). Built-in indexing suite API @@ -105,13 +105,13 @@ * ``no_proxy`` - a boolean, if ``value_type`` is one of the next types * fundamental type - + * enumeration * std::string or std::wstring * boost::shared_ptr<?> - + then, ``no_proxy`` will be set to ``True``, otherwise to ``False``. * ``derived_policies`` - a string, that will be added as is to generated code @@ -128,28 +128,28 @@ .. code-block:: C++ struct item{ - ... + ... private: bool operator==( const item& ) const; bool operator<( const item& ) const; }; - + struct my_data{ std::vector<item> items; std::map< std::string, item > name2item_mapping; }; -`Py++`_ declarations tree will contains ``item``, ``my_data``, -``vector<item>`` and ``map<string,item>`` class declarations. +`Py++`_ declarations tree will contains ``item``, ``my_data``, +``vector<item>`` and ``map<string,item>`` class declarations. -If ``value_type`` does not support "equal" or "less than" functionality, sort +If ``value_type`` does not support "equal" or "less than" functionality, sort and search functionality could not be exported. -`Py++`_ class declaration has two properties: ``equality_comparable`` and -``less_than_comparable``. The value of those properties is calculated on first -invocation. If `Py++`_ can find ``operator==``, that works on ``value_type``, -then, ``equality_comparable`` property value will be set to ``True``, otherwise +`Py++`_ class declaration has two properties: ``equality_comparable`` and +``less_than_comparable``. The value of those properties is calculated on first +invocation. If `Py++`_ can find ``operator==``, that works on ``value_type``, +then, ``equality_comparable`` property value will be set to ``True``, otherwise to ``False``. Same process is applied on ``less_than_comparable`` property. In our case, `Py++`_ will set both properties to ``False``, thus sort and @@ -159,36 +159,36 @@ * ``container_class`` - read only property, returns reference to container class declaration - + * ``container_traits`` - read only property, returns reference to the relevant - container traits class. Container traits classes are defined in + container traits class. Container traits classes are defined in ``pygccxml.declarations`` package. - + * ``element_type`` - is a reference to container ``value_type`` or ``mapped_type``. -* ``call_policies`` - read/write property, in near future I will add code to - `Py++`_ that will analize container ``value_type`` and will decide about +* ``call_policies`` - read/write property, in near future I will add code to + `Py++`_ that will analyze container ``value_type`` and will decide about default call policies. Just an example: for non-copy constructable classes - ``call_policies`` should be set to ``return_internal_reference``. - -* ``[disable|enable]_method`` - new indexing suite, allows to configure + ``call_policies`` should be set to ``return_internal_reference``. + +* ``[disable|enable]_method`` - new indexing suite, allows to configure functionality exported to Python, using simple bitwise operations on predefined flags. `Py++`_ allows you to specify what methods you want to disable or enable. ``indexing_suite2_t.METHODS`` contains names of all supported methods. - + * ``[disable|enable]_methods_group`` - almost same as above, but allows you - to specify what group of methods you want to disable or enable. + to specify what group of methods you want to disable or enable. ``indexing_suite2_t.METHOD_GROUPS`` contains names of all supported groups. Small tips/hints ---------------- 1. If you set ``equality_comparable`` or ``less_than_comparable`` to ``False``. - The indexing suite will disable relevant functionality. You don't have + The indexing suite will disable relevant functionality. You don't have explicitly to disable method or mothods group. -2. The documentation of new indexing suite contains few small mistakes. - I hope, I will have time to fix them. Any way, `Py++`_ generates +2. The documentation of new indexing suite contains few small mistakes. + I hope, I will have time to fix them. Any way, `Py++`_ generates correct code. Modified: pyplusplus_dev/docs/documentation/feedback.rest =================================================================== --- pyplusplus_dev/docs/documentation/feedback.rest 2006-12-13 08:16:21 UTC (rev 796) +++ pyplusplus_dev/docs/documentation/feedback.rest 2006-12-13 22:12:02 UTC (rev 797) @@ -19,8 +19,8 @@ Those goals all have something in common. In order to achieve them, `Py++`_ must -give useful feedback to the user. Because `Py++`_ understands the -declarations it exports, it can scan declarations for potential problems, report +give useful feedback to the user. Because `Py++`_ understands the +declarations it exports, it can scan declarations for potential problems, report them and in some cases provide hints about how to resolve the problem. Few examples: * @@ -42,11 +42,11 @@ struct window{ ... - void get_size( int& heght, int& widht ) const; + void get_size( int& height, int& width ) const; }; Member function ``get_size`` can be exposed to Python, but it will not be callable because [FILL IN HERE]. - + * In order to expose free/member function that takes more than 10 arguments user should define ``BOOST_PYTHON_MAX_ARITY`` macro. @@ -56,12 +56,12 @@ struct X{ ... }; - + void do_smth( X x ); - + If you expose ``do_smth`` function and don't expose struct ``X``, `Py++`_ will tell you that struct ``X`` is used in exported declaration, but was not - exposed. + exposed. For these problems and many other `Py++`_ gives a nice explanation and sometimes a link to the relevant information on the Internet. @@ -78,7 +78,7 @@ important messages to ``stdout``. More over it prints them only for declarations that are going to be exported. -`Py++`_ uses the python `logging`_ package to write all user messages. By +`Py++`_ uses the python `logging`_ package to write all user messages. By default, messages with ``DEBUG`` level will be skipped, all other messages will be reported. @@ -99,7 +99,7 @@ * warning unique identifier: "W1020" -* short explanation of the problem: "Py++ will generate class wrapper - hand +* short explanation of the problem: "Py++ will generate class wrapper - hand written code should be added to the wrapper class" --------------- @@ -109,20 +109,20 @@ How to disable warning(s)? -------------------------- -Every warning has unique identifier. In the example I gave it was ``W1020``. +Every warning has unique identifier. In the example I gave it was ``W1020``. .. code-block:: Python from pyplusplus import messages from pyplusplus import module_builder - + mb = module_builder.module_builder_t( ... ) xyz = mb.class_( XYZ ) xyz.disable_warnings( messages.W1020 ) It is also possible to disable warnings for all declarations. ``pyplusplus.messages`` package defines ``DISABLE_MESSAGES`` variable. This variable( ``list`` ) keeps -all warnings, which should not be reported. Use ``messages.disable`` function to +all warnings, which should not be reported. Use ``messages.disable`` function to edit it: .. code-block:: Python @@ -134,7 +134,7 @@ ----------- If you are here, it probably means that you are not pleased with default configuration -and want to change it, right? +and want to change it, right? 1. If you simply want to change the logging message level: @@ -149,38 +149,38 @@ 2. But what if you want to disable some messages and leave others? This is also possible. - `Py++`_ and `pygccxml`_ do not use a single logger. Almost every internal + `Py++`_ and `pygccxml`_ do not use a single logger. Almost every internal package has its own logger. So you can enable one logger and disable another one. - + The `pygccxml`_ package defines all loggers in the ``pygccxml.utils`` package. - + The `Py++`_ package defines all loggers in the ``pyplusplus._logging_`` package. - - Both packages define a ``loggers`` class. Those classes keep references to + + Both packages define a ``loggers`` class. Those classes keep references to different loggers. The ``loggers`` classes look very similar to the next class: .. code-block:: Python import logging #standard Python package - + def _create_logger_( name ): logger = logging.getLogger(name) ... return logger - + class loggers: file_writer = _create_logger_( 'pyplusplus.file_writer' ) declarations = _create_logger_( 'pyplusplus.declarations' ) - module_builder = _create_logger_( 'pyplusplus.module_builder' ) + module_builder = _create_logger_( 'pyplusplus.module_builder' ) root = logging.getLogger( 'pyplusplus' ) all = [ root, file_writer, module_builder, declarations ] You can use these references in the ``logging`` package to complete your task of adjusting individual loggers. - - One more thing, `Py++`_ automatically splits long message, where line + + One more thing, `Py++`_ automatically splits long message, where line length defaults to 70 characters. Thus it is very convenient to read them on your screen. - If you want to use different tools to monitor those messages, consider to use + If you want to use different tools to monitor those messages, consider to use standard `Formatter`_ class, instead of ``multi_line_formatter_t`` one. @@ -191,17 +191,17 @@ * ``why_not_exportable( self )`` - This method explains why a declaration could not be exported. The return value + This method explains why a declaration could not be exported. The return value is a string or ``None``. ``None`` is returned if the declaration is exportable. - Property ``exportable`` will be set to ``True`` if declaration is exportable, - and to ``False`` otherwise. + Property ``exportable`` will be set to ``True`` if declaration is exportable, + and to ``False`` otherwise. * ``readme( self )`` This method gives you access to all tips/hints/warnings `Py++`_ has about - the declaration. This methods returns a list of strings. If the declaration is - not exportable, than first message within the list is an explanation, why it + the declaration. This methods returns a list of strings. If the declaration is + not exportable, than first message within the list is an explanation, why it is not exportable. Modified: pyplusplus_dev/docs/documentation/functions/call_policies.rest =================================================================== --- pyplusplus_dev/docs/documentation/functions/call_policies.rest 2006-12-13 08:16:21 UTC (rev 796) +++ pyplusplus_dev/docs/documentation/functions/call_policies.rest 2006-12-13 22:12:02 UTC (rev 797) @@ -18,7 +18,7 @@ Syntax ------ -The call policies in `Py++`_ are named exactly as in `Boost.Python`_, only the +The call policies in `Py++`_ are named exactly as in `Boost.Python`_, only the syntax is slightly different. For instance, this call policy: .. code-block:: C++ @@ -37,7 +37,7 @@ Usage example ------------- -Every "callable" object in `Py++`_ has ``call_policies`` property. +Every "callable" object in `Py++`_ has ``call_policies`` property. C++ code: @@ -45,9 +45,9 @@ struct data{...}; const data& do_smth( const data& d, int x ); - + void return_second_arg( int x, int y ); - + typedef struct opaque_ *opaque_pointer; opaque_pointer get_opaque(); @@ -57,15 +57,15 @@ from pyplusplus import module_builder from pyplusplus.module_builder import call_policies - + mb = module_builder.module_builder_t( ... ) mb.free_function( 'return_second_arg' ).call_policies = call_policies.return_arg( 2 ) #---------------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - + mb.member_function( 'do_smth' ).call_policies = call_policies.return_self() #-------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - mb.calldef( 'get_opaque' ).call_policies + + mb.calldef( 'get_opaque' ).call_policies = call_policies.return_value_policy( call_policies.return_opaque_pointer ) -------- @@ -78,41 +78,41 @@ * ``default_call_policies``: * `Python`_ immutable type returned by value: C++ fundamental types, ``std::string``, enumerations - + * user-defined type ( class ) returned by value - + * return type is ``const char*`` * ``return_value_policy`` - + * ``return_opaque_pointer`` - - * return type is ``void*`` - + + * return type is ``void*`` + * return type is ``const void*`` - + * return type is ``T*`` and ``T`` is a user defined opaque type - - ``class_t`` and ``class_declaration_t`` classes have ``opaque`` property. - You have to set it to ``True``, if you want `Py++`_ to create this call - policy automaticly for all functions, that use ``T*`` as return type. - + + ``class_t`` and ``class_declaration_t`` classes have ``opaque`` property. + You have to set it to ``True``, if you want `Py++`_ to create this call + policy automatically for all functions, that use ``T*`` as return type. + * ``copy_const_reference`` * return type is ``const T&`` - + * for member ``operator[]`` that returns const reference to immutable type - + * ``return_by_value`` * return type is ``const wchar_t*`` - + * ``copy_non_const_reference`` - + * return type is ``T&``, for member ``operator[]`` that returns reference to immutable type - + * ``return_internal_reference`` - + * return type is ``T&``, for member ``operator[]`` --------------------- @@ -124,13 +124,13 @@ * `Py++`_ prints a warning message -* `Py++`_ generates code with - +* `Py++`_ generates code with + .. code-block:: C++ - + /* undefined call policies */ - - comment, in place of call policy. If `Py++`_ was wrong and function doesn't + + comment, in place of call policy. If `Py++`_ was wrong and function doesn't need call policy the generate code will compile fine, otherwise you will get a compilation error. @@ -142,13 +142,13 @@ Before you read this paragraph consider to read `Boost.Python`_ `return_opaque_pointer documentation`_. ``return_value_policy( return_opaque_pointer )`` is a special policy for `Boost.Python`_. -In this case, it requieres from you to define specialization for the -``boost::python::type_id`` function on the type pointed to by returned pointer. -`Py++`_ will generate the required code. +In this case, it requires from you to define specialization for the +``boost::python::type_id`` function on the type pointed to by returned pointer. +`Py++`_ will generate the required code. Actually you should define ``boost::python::type_id`` specialization also in case -a function takes the opaque type as an argument. `Py++`_ can do it for you, all +a function takes the opaque type as an argument. `Py++`_ can do it for you, all you need is to say to mark a declaration as opaque. Example: @@ -157,13 +157,13 @@ struct identity_impl_t{}; typedef identity_impl_t* identity; - + struct world_t{ - + world_t( identity id ); - + identity get_id() const; - + ... }; @@ -175,7 +175,7 @@ mb.class_( 'identity_impl_t' ).opaque = True -.. _`return_opaque_pointer documentation` : http://boost.org/libs/python/doc/v2/return_opaque_pointer.html +.. _`return_opaque_pointer documentation` : http://boost.org/libs/python/doc/v2/return_opaque_pointer.html -------------------------- Py++ defined call policies @@ -184,7 +184,7 @@ return_pointee_value -------------------- -Class ``return_pointee_value`` is a model of `ResultConverterGenerator`_ which +Class ``return_pointee_value`` is a model of `ResultConverterGenerator`_ which can be used to wrap C++ functions returning any pointer, such that the pointee of return value is copied into a new Python object. @@ -197,11 +197,11 @@ static float value = 0.5; return &value; } - + float* get_null_value(){ return (float*)( 0 ); } - + namespace bpl = boost::python; BOOST_PYTHON_MODULE(my_module){ def( "get_value" @@ -217,7 +217,7 @@ from pyplusplus import module_builder from pyplusplus.module_builder import call_policies - + mb = module_builder.module_builder_t( ... ) mb.free_function( return_type='float *' ).call_policies \ = call_policies.return_value_policy( call_policies.return_pointee_value ) @@ -227,7 +227,7 @@ .. code-block:: Python import my_module - + assert 0.5 == my_module.get_value() assert None is my_module.get_null_value() Modified: pyplusplus_dev/docs/documentation/functions/default_args.rest =================================================================== --- pyplusplus_dev/docs/documentation/functions/default_args.rest 2006-12-13 08:16:21 UTC (rev 796) +++ pyplusplus_dev/docs/documentation/functions/default_args.rest 2006-12-13 22:12:02 UTC (rev 797) @@ -8,7 +8,7 @@ Introduction ------------ -There is more than one way to export function with default arguments. Before we +There is more than one way to export function with default arguments. Before we proceed, please take a look on next class: .. code-block:: C++ @@ -18,7 +18,7 @@ bool f(int a=12) { return true; - } + } }; ------------------- @@ -30,16 +30,16 @@ .. code-block:: C++ namespace bp = boost::python; - + BOOST_PYTHON_MODULE(pyplusplus){ - bp::class_< X >( "X" ) - .def( + bp::class_< X >( "X" ) + .def( "f" , &::X::f - , ( bp::arg("a")=(int)(12) ) ); + , ( bp::arg("a")=(int)(12) ) ); } -The additional value of the approach is keyword arguments. You will be able to +The additional value of the approach is keyword arguments. You will be able to call function ``f`` like this: .. code-block:: Python @@ -58,7 +58,7 @@ .. code-block:: Python import module_builder - + mb = module_builder.module_builder_t( ... ) x = mb.class_( "X" ) x.member_function( "f" ).use_overload_macro = True @@ -75,36 +75,36 @@ struct S1; struct S2; - + struct S1{ void do_smth( S2* s2=0 ); }; - + struct S2{ void do_smth( S1 s1=S1() ); }; - + BOOST_PYTHON_MODULE( ... ){ using namespace boost::python; - + class_< S2 >( "S2" ) .def( "do_smth", &S2::do_smth, ( arg("s1")=S1() ) ); - + class_< S1 >( "S1" ) .def( "do_smth", &S1::do_smth, ( arg("s2")=object() ) ); - + } -The good news is that it is very easy to identify the problem: the module could -not be loaded. The main reason is that expression ``arg("s1")=S1()`` requires -``S1`` struct to be registered. `GCC-XML`_ reports default arguments as strings. -`Py++`_ doesn't have enough information to generate code with the right class +The good news is that it is very easy to identify the problem: the module could +not be loaded. The main reason is that expression ``arg("s1")=S1()`` requires +``S1`` struct to be registered. `GCC-XML`_ reports default arguments as strings. +`Py++`_ doesn't have enough information to generate code with the right class registration order. In this case you have to instruct `Py++`_ to use macros: .. code-block:: Python - import module_builde - + import module_builder + mb = module_builder.module_builder_t( ... ) s2 = mb.class_( "S2" ) s2.member_function( "do_smth" ).use_overload_macro = True @@ -126,11 +126,11 @@ struct S1; struct S2; - + struct S1{ S1( S2* s2=0 ); }; - + struct S2{ S2( S1 s1=S1() ); }; Modified: pyplusplus_dev/docs/documentation/functions/overloading.rest =================================================================== --- pyplusplus_dev/docs/documentation/functions/overloading.rest 2006-12-13 08:16:21 UTC (rev 796) +++ pyplusplus_dev/docs/documentation/functions/overloading.rest 2006-12-13 22:12:02 UTC (rev 797) @@ -21,12 +21,12 @@ { return true; } - + bool f(int a, double b) { return true; } - + bool f(int a, double b, char c) { return true; @@ -49,18 +49,18 @@ .. code-block:: C++ namespace bp = boost::python; - + BOOST_PYTHON_MODULE(pyplusplus){ - bp::class_< X >( "X" ) - .def( + bp::class_< X >( "X" ) + .def( "f" , (bool ( ::X::* )( int ) )( &::X::f ) - , ( bp::arg("a") ) ) - .def( + , ( bp::arg("a") ) ) + .def( "f" , (bool ( ::X::* )( int,double ) )( &::X::f ) - , ( bp::arg("a"), bp::arg("b") ) ) - .def( + , ( bp::arg("a"), bp::arg("b") ) ) + .def( "f" , (bool ( ::X::* )( int,double,char ) )( &::X::f ) , ( bp::arg("a"), bp::arg("b"), bp::arg("c") ) ); @@ -85,45 +85,45 @@ .. code-block:: C++ struct Y{ - + void do_smth( int ); - + template< class T> void do_smth( T t ); - + }; If you didn't instantiate( use ) ``do_smth`` member function, than `GCC-XML`_ -will not report it. As a result, `Py++`_ will not be aware of the fact that +will not report it. As a result, `Py++`_ will not be aware of the fact that ``do_smth`` is an overloaded function. To make the long story short, the generated -code will not compile. You have to instruct `Py++`_ to generate code, which +code will not compile. You have to instruct `Py++`_ to generate code, which contains function type: .. code-block:: Python from pyplusplus import module_builder - + mb = module_builder.module_builder_t( ... ) y = mb.class_( 'Y' ) y.member_function( 'do_smth' ).create_with_signature = True #------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Every `Py++`_ class, which describes C++ function\\operator has ``create_with_signature`` -property. You have to set it to ``True``. Default value of the property is +property. You have to set it to ``True``. Default value of the property is computed. If the exported function is overloaded, then its value is ``True`` otherwise it will be ``False``. Do nothing approach weakness ---------------------------- -Code modification - the weakness of the "do nothing" approach. We live in the -dynamic world. You can create bindings for a project, but a month letter, the -project developers will add a new function to the exported class. Lets assume -that the new function will introduce overloading. If ``create_with_signature`` -has ``False`` as a value, than the previously generated code will not compile -and you will have to run code generator one more time. +Code modification - the weakness of the "do nothing" approach. We live in the +dynamic world. You can create bindings for a project, but a month letter, the +project developers will add a new function to the exported class. Lets assume +that the new function will introduce overloading. If ``create_with_signature`` +has ``False`` as a value, than the previously generated code will not compile +and you will have to run code generator one more time. -Consider to explicitly set ``create_with_signature`` to ``True``. It will save +Consider to explicitly set ``create_with_signature`` to ``True``. It will save your and your users time in future. .. code-block:: Python @@ -136,7 +136,7 @@ Overloading using macros ------------------------ -`Boost.Python`_ provides two macros, which help you to deal with overloaded +`Boost.Python`_ provides two macros, which help you to deal with overloaded functions: * ``BOOST_PYTHON_FUNCTION_OVERLOADS`` @@ -152,12 +152,12 @@ .. code-block:: Python import module_builder - + mb = module_builder.module_builder_t( ... ) x = mb.class_( "X" ) x.member_functions( "f" ).use_overload_macro = True #-------------------------^^^^^^^^^^^^^^^^^^^^^^^^^ - + Member and free functions declaration classes have ``use_overload_macro`` property. The default value of the property is ``False``. Modified: pyplusplus_dev/docs/documentation/functions/registration_order.rest =================================================================== --- pyplusplus_dev/docs/documentation/functions/registration_order.rest 2006-12-13 08:16:21 UTC (rev 796) +++ pyplusplus_dev/docs/documentation/functions/registration_order.rest 2006-12-13 22:12:02 UTC (rev 797) @@ -8,10 +8,10 @@ Introduction ------------ -"... I would very much like to pass bools from Python to C++ and have them -accepted as bools. However I cannot seem to do this. ..." +"... I would very much like to pass booleans from Python to C++ and have them +accepted as boils. However I cannot seem to do this. ..." -"... My class has 2 "append" functions. The first one, has single argument with +"... My class has 2 "append" functions. The first one, has single argument with type "const char*", the second one also has single argument with type "char". It seems, that I am not able to call the first function. ..." @@ -26,30 +26,30 @@ struct tester_t{ tester_t() {} - + const char* append(const char*) { return "append(const char *)"; } - + const char* append(const char) { return "append(const char)"; } - + const char* do_smth( bool ) { return "do_smth( bool )"; } - + const char* do_smth( int ) { return "do_smth( int )"; } }; -`Py++`_ generates code, that register functions in the order they apper in the +`Py++`_ generates code, that register functions in the order they appear in the source code: .. code-block:: C++ namespace bp = boost::python; - + BOOST_PYTHON_MODULE(my_module){ - bp::class_< tester_t >( "tester_t" ) - .def( bp::init< >() ) + bp::class_< tester_t >( "tester_t" ) + .def( bp::init< >() ) .def( "append" , (char const * ( ::tester_t::* )( char const * ) )( &::tester_t::append ) ) .def( "append" @@ -73,7 +73,7 @@ print tester.do_smth( True ) print tester.do_smth( 10 ) print tester.append( "Hello world!" ) - + ? The output is: @@ -84,8 +84,8 @@ append(const char) -Unexpected, right? The registration order of exposed overloaded functions is -important. `Boost.Python`_ tries overloads in reverse order of definition. +Unexpected, right? The registration order of exposed overloaded functions is +important. `Boost.Python`_ tries overloads in reverse order of definition. If I understand right, `Boost.Python`_ tries to match in reverse order the overloaded functions, if it can convert `Python`_ arguments to C++ ones, it does @@ -94,7 +94,7 @@ Now, when you understand the behaviour, it should be pretty simple to provide a correct functionality: -1. You can change alias of the function, by mangling the type of the argument +1. You can change alias of the function, by mangling the type of the argument into it: .. code-block:: Python @@ -105,38 +105,38 @@ 2. You can reorder the declarations within the source file. -3. You can ask `Py++`_ to generate code, which takes into account the order of +3. You can ask `Py++`_ to generate code, which takes into account the order of declarations: - + .. code-block:: Python - + from pyplusplus.module_creator import sort_algorithms - + sort_algorithms.USE_CALLDEF_ORGANIZER = True # The functionality is available from version 0.8.3 - + 4. The last and the perfect solution. `Py++`_ will let you know, when your code - has such problem. The functionality is available from version 0.8.3. After - this you can change the aliases of the functions. The third step is to create + has such problem. The functionality is available from version 0.8.3. After + this you can change the aliases of the functions. The third step is to create small "dispatch" function in Python: - + .. code-block:: Python - + import my_module - + def tester_t_do_smth( self, value ): if isinstance( value, bool ): self.do_smth_bool( value ): else: self.do_smth_int( value ) - + tester_t.do_smth = tester_t_do_smth - The tehnique showen here described pretty good in `Boost.Python`_ + The technique shown here described pretty good in `Boost.Python`_ `Extending Wrapped Objects in Python tutorials`_ . May be in future, `Py++`_ will generate this code for you. Anyway, if you have - a lot of use cases like this consider to generate `Python`_ code and not to + a lot of use cases like this consider to generate `Python`_ code and not to write it manually. .. _`Extending Wrapped Objects in Python tutorials` : http://boost.org/libs/python/doc/tutorial/doc/html/python/techniques.html#python.extending_wrapped_objects_in_python Modified: pyplusplus_dev/docs/documentation/functions/transformation/built_in/built_in.rest =================================================================== --- pyplusplus_dev/docs/documentation/functions/transformation/built_in/built_in.rest 2006-12-13 08:16:21 UTC (rev 796) +++ pyplusplus_dev/docs/documentation/functions/transformation/built_in/built_in.rest 2006-12-13 22:12:02 UTC (rev 797) @@ -20,11 +20,11 @@ * ``output_static_array`` -The set doesn't cover all common use cases, but it will grow with every new -version of `Py++`_. If you created your own transformer consider to contribute +The set doesn't cover all common use cases, but it will grow with every new +version of `Py++`_. If you created your own transformer consider to contribute it to the project. -I suggest you to start reading `output`_ transformer. It is pretty simple and +I suggest you to start reading `output`_ transformer. It is pretty simple and well explained. .. _`output` : ./output.html @@ -32,10 +32,10 @@ All built-in transformers could be applied on any function, except constructors and pure virtual functions. The support for them be added in future releases. -You don't have to warry about call policies. You can set the call policy and +You don't have to worry about call policies. You can set the call policy and `Py++`_ will generate the correct code. -You don't have to warry about the number of arguments, transformers or return +You don't have to worry about the number of arguments, transformers or return value. `Py++`_ handles pretty well such use cases. Modified: pyplusplus_dev/docs/documentation/functions/transformation/built_in/inout.rest =================================================================== --- pyplusplus_dev/docs/documentation/functions/transformation/built_in/inout.rest 2006-12-13 08:16:21 UTC (rev 796) +++ pyplusplus_dev/docs/documentation/functions/transformation/built_in/inout.rest 2006-12-13 22:12:02 UTC (rev 797) @@ -9,8 +9,8 @@ ---------- ``inout`` transformer is a combination of `input`_ and `output`_ transformers. -It removes a "reference" type from the function argument and then adds the -"returned", by the original function, value to the return statement of the +It removes a "reference" type from the function argument and then adds the +"returned", by the original function, value to the return statement of the function-wrapper. ``inout`` transformer takes as argument name or index of the original function @@ -27,20 +27,20 @@ .. code-block:: C++ #include <string> - + inline void hello_world( std::string& hw ){ hw = "hello world!"; } Lets say that you need to expose ``hello_world`` function. As you know -``std::string`` is mapped to `Python`_ string, which is immutable type, so you +``std::string`` is mapped to `Python`_ string, which is immutable type, so you have to create small wrapper for the function. Next `Py++`_ code does it for you: .. code-block:: Python from pyplusplus import module_builder from pyplusplus import function_transformers as FT - + mb = module_builder.module_builder_t( ... ) hw = mb.mem_fun( 'hello_world' ) hw.add_transformation( FT.inout(0) ) @@ -50,11 +50,11 @@ .. code-block:: C++ namespace bp = boost::python; - + static boost::python::object hello_world_a3478182294a057b61508c30b1361318( ::std::string hw ){ ::hello_world(hw); return bp::object( hw ); - } + } BOOST_PYTHON_MODULE(...){ ... Modified: pyplusplus_dev/docs/documentation/functions/transformation/built_in/input.rest =================================================================== --- pyplusplus_dev/docs/documentation/functions/transformation/built_in/input.rest 2006-12-13 08:16:21 UTC (rev 796) +++ pyplusplus_dev/docs/documentation/functions/transformation/built_in/input.rest 2006-12-13 22:12:02 UTC (rev 797) @@ -21,20 +21,20 @@ .. code-block:: C++ #include <string> - + inline void hello_world( std::string& hw ){ hw = "hello world!"; } Lets say that you need to expose ``hello_world`` function. As you know -``std::string`` is mapped to `Python`_ string, which is immutable type, so you +``std::string`` is mapped to `Python`_ string, which is immutable type, so you have to create small wrapper for the function. Next `Py++`_ code does it for you: .. code-block:: Python from pyplusplus import module_builder from pyplusplus import function_transformers as FT - + mb = module_builder.module_builder_t( ... ) hw = mb.mem_fun( 'hello_world' ) hw.add_transformation( FT.input(0) ) @@ -44,7 +44,7 @@ .. code-block:: C++ namespace bp = boost::python; - + static void hello_world_a3478182294a057b61508c30b1361318( ::std::string hw ){ ::hello_world(hw); } Modified: pyplusplus_dev/docs/documentation/functions/transformation/built_in/input_static_array.rest =================================================================== --- pyplusplus_dev/docs/documentation/functions/transformation/built_in/input_static_array.rest 2006-12-13 08:16:21 UTC (rev 796) +++ pyplusplus_dev/docs/documentation/functions/transformation/built_in/input_static_array.rest 2006-12-13 22:12:02 UTC (rev 797) @@ -8,12 +8,12 @@ Definition ---------- -"input_static_array" transformer works on native static arrays. It handles the -translation between `Python`_ object, passed as argument that represent a sequence, +"input_static_array" transformer works on native static arrays. It handles the +translation between `Python`_ object, passed as argument that represent a sequence, and the array. Size of array should be predefined. -"input_static_array" transformer takes as first argument name or index of the -original function argument. The argument should have "array" or "pointer" type. +"input_static_array" transformer takes as first argument name or index of the +original function argument. The argument should have "array" or "pointer" type. The second argument should an integer value, that represents array size. ------- @@ -23,13 +23,13 @@ .. code-block:: C++ struct vector3{ - + void init( int values[3] ){ x = values[0]; y = values[1]; z = values[2]; } - + int x,y,z; }; @@ -40,7 +40,7 @@ from pyplusplus import module_builder from pyplusplus import function_transformers as FT - + mb = module_builder.module_builder_t( ... ) v3 = mb.class_( 'vector3' ) v3.mem_fun( 'init' ).add_transformation( FT.input_static_array( 0, 3 ) ) @@ -50,24 +50,24 @@ .. code-block:: C++ #include "__convenience.pypp.hpp" //Py++ header file, which contains few convenience function - + namespace bp = boost::python; - + static void init_418e52f4a347efa6b7e123b96f32a73c( ::ft::vector3 & inst, boost::python::object values ){ int native_values[3]; pyplus_conv::ensure_uniform_sequence< int >( values, 3 ); pyplus_conv::copy_sequence( values, pyplus_conv::array_inserter( native_values, 3 ) ); inst.init(native_values); } - + BOOST_PYTHON_MODULE(...){ ... - bp::class_< ft::vector3 >( "vector3", "documentation" ) + bp::class_< ft::vector3 >( "vector3", "documentation" ) .def( "init" , &init_418e52f4a347efa6b7e123b96f32a73c , ( bp::arg("inst"), bp::arg("values") ) ) - .def_readwrite( "x", &ft::vector3::x ) - .def_readwrite( "y", &ft::vector3::y ) + .def_readwrite( "x", &ft::vector3::x ) + .def_readwrite( "y", &ft::vector3::y ) .def_readwrite( "z", &ft::vector3::z ); } Modified: pyplusplus_dev/docs/documentation/functions/transformation/built_in/output.rest =================================================================== --- pyplusplus_dev/docs/documentation/functions/transformation/built_in/output.rest 2006-12-13 08:16:21 UTC (rev 796) +++ pyplusplus_dev/docs/documentation/functions/transformation/built_in/output.rest 2006-12-13 22:12:02 UTC (rev 797) @@ -9,7 +9,7 @@ ---------- "output" transformer removes an argument from the function definition and adds -the "returned", by the original function, value to the return statement of the +the "returned", by the original function, value to the return statement of the function-wrapper. "output" transformer takes as argument name or index of the original function @@ -23,20 +23,20 @@ .. code-block:: C++ #include <string> - + inline void hello_world( std::string& hw ){ hw = "hello world!"; } Lets say that you need to expose ``hello_world`` function. As you know -``std::string`` is mapped to `Python`_ string, which is immutable type, so you +``std::string`` is mapped to `Python`_ string, which is immutable type, so you have to create small wrapper for the function. Next `Py++`_ code does it for you: .. code-block:: Python from pyplusplus import module_builder from pyplusplus import function_transformers as FT - + mb = module_builder.module_builder_t( ... ) hw = mb.mem_fun( 'hello_world' ) hw.add_transformation( FT.output(0) ) @@ -46,13 +46,13 @@ .. code-block:: C++ namespace bp = boost::python; - + static boost::python::object hello_world_a3478182294a057b61508c30b1361318( ){ std::string hw2; ::hello_world(hw2); return bp::object( hw2 ); } - + BOOST_PYTHON_MODULE(...){ ... bp::def( "hello_world", &hello_world_a3478182294a057b61508c30b1361318 ); Modified: pyplusplus_dev/docs/documentation/functions/transformation/built_in/output_static_array.rest =================================================================== --- pyplusplus_dev/docs/documentation/functions/transformation/built_in/output_static_array.rest 2006-12-13 08:16:21 UTC (rev 796) +++ pyplusplus_dev/docs/documentation/functions/transformation/built_in/output_static_array.rest 2006-12-13 22:12:02 UTC (rev 797) @@ -8,11 +8,11 @@ Definition ---------- -"output_static_array" transformer works on native static arrays. It handles the +"output_static_array" transformer works on native static arrays. It handles the translation between array and `Python`_ list object. Size of array should be predefined. -"output_static_array" transformer takes as first argument name or index of the -original function argument. The argument should have "array" or "pointer" type. +"output_static_array" transformer takes as first argument name or index of the +original function argument. The argument should have "array" or "pointer" type. The second argument should an integer value, that represents array size. ------- @@ -22,13 +22,13 @@ .. code-block:: C++ struct vector3{ - + void get_values( int values[3] ){ values[0] = x; values[1] = y; values[2] = z; - } - + } + int x,y,z; }; @@ -39,7 +39,7 @@ from pyplusplus import module_builder from pyplusplus import function_transformers as FT - + mb = module_builder.module_builder_t( ... ) v3 = mb.class_( 'vector3' ) v3.mem_fun( 'get_values' ).add_transformation( FT.output_static_array( 0, 3 ) ) @@ -49,9 +49,9 @@ .. code-block:: C++ #include "__convenience.pypp.hpp" //Py++ header file, which contains few convenience function - + namespace bp = boost::python; - + static boost::python::object get_values_22786c66e5973b70f714e7662e2aecd2( ::ft::vector3 & inst ){ int native_values[3]; boost::python::list py_values; @@ -59,15 +59,15 @@ pyplus_conv::copy_container( native_values, native_values + 3, pyplus_conv::list_inserter( py_values ) ); return bp::object( py_values ); } - + ... [truncated message content] |