Revision: 403
Author: roman_yakovenko
Date: 2006-08-14 23:49:56 -0700 (Mon, 14 Aug 2006)
ViewCVS: http://svn.sourceforge.net/pygccxml/?rev=403&view=rev
Log Message:
-----------
updating documentation
Modified Paths:
--------------
pyplusplus_dev/docs/documentation/architecture.rest
Modified: pyplusplus_dev/docs/documentation/architecture.rest
===================================================================
--- pyplusplus_dev/docs/documentation/architecture.rest 2006-08-14 19:47:23 UTC (rev 402)
+++ pyplusplus_dev/docs/documentation/architecture.rest 2006-08-15 06:49:56 UTC (rev 403)
@@ -10,15 +10,18 @@
This document will describe an architecture behind `Py++`_.
----
+---------------------------
+Py++ & pygccxml integration
+---------------------------
+
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. Lets say that I've managed to do it. It is not enough. 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.
+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.
@@ -46,13 +49,13 @@
* ...
-Py++ & pygccxml integration
----------------------------
+Integration details
+-------------------
`Py++`_ uses different approaches to expose these services to the user.
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.
@@ -60,7 +63,7 @@
Declarations tree integration
------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Declarations tree API consists from 3 parts:
@@ -76,10 +79,11 @@
The user should be familiar with these parts and relevant API. In my opinion,
-wrapping\\hidding\\modifying the API will not provide an additonal value. The
-interface of all those services is pretty simple and well polished.
+wrapping or hidding the API will not provide an additonal value. The interface
+of all those services is pretty simple and well polished.
-Please take a look on next source code:
+Before I explain how these services are integrated, take a look on next source
+code:
::
@@ -116,13 +120,13 @@
2. ``pyplusplus.decl_wrappers`` package defines classes, that derive from
``pygccxml.declarations`` classes and defines the factory.
-The implemented solution is not the simplest one, it provides an additional value
-to the project:
+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
coupled
-* all functionality provided by ``pygccxml.declarations`` and ``pygccxml.parser``
+* 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
@@ -139,8 +143,8 @@
Code generation engine
----------------------
-Code generation for `Boost.Python`_ library is a difficult process. After small
-analizes I understood, that there are 2 different problems the engine should solve:
+Code generation for `Boost.Python`_ library is a difficult process. There are two
+different problems the engine should solve:
.. _`divide and conquer` : http://en.wikipedia.org/wiki/Divide_and_conquer_algorithm
@@ -151,36 +155,36 @@
Remember, `Py++`_ is targeting big projects. It can not generate all code
in one file - this will not work, not at all.
-Code creators and file writers provides solution to both problems.
-
+``Code creators`` and file writers provides solution for both problems.
Code creators
-------------
-Do you know how many ways exist to export member function? It is up to you to
-find the answer to the question. Please consider next function properties and
-their mix:
+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:
-* function is non virtual, virtual or pure virtual
+* virtuality( non virtual, virtual or pure virtual )
-* function is public, protected or private
+* access level( public, protected or private )
-* function could be static
+* static\\non static
-* function could be an ``operator()`` or an ``operator[]``
+* overloads
-* function could be overloaded
+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 does ``code creator``'s solve the
-problem? There is almost a direct mapping between ``code creator``'s and use cases.
-``Code creator`` knows what code should be created, in order to export a
-declaration. That is the only job of ``code creator``. For example:
+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.
+
+Example of ``code creators``:
+
* ``code_creators.enum_t`` generates registration code for an enumeration
-* ``code_creators.indexing_suite2_t`` generates registration code for an stl
- containers
-
* ``code_creators.mem_fun_pv_t`` generates registration code for public, pure
virtual function
@@ -192,14 +196,17 @@
* ``code_creators.custom_text_t`` adds some custom( read user ) text\\code to
the generated code
-As you can see, there are primary 2 kinds of ``code creator``'s: declaration
-based and others. Declaration based creator generates code, that is needed to
-export the declaration. There a lot of use cases, where in order to export a
-declaration, `Py++`_ builds more then one ``code creator``. For example:
-in order to export virtual function 2 ``code creator``'s are built:
+There are primary two groups of ``code creators``: declaration based and others.
-( I will reuse example from `Boost.Python`_ `tutorials`__.)
+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
+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
@@ -209,16 +216,8 @@
code creator also keeps reference to the relevant instance of
``code_creators.mem_fun_v_wrapper_t`` class.
-
-Declaration based ``code creator`` keeps reference to the declaration (
-``pyplusplus.decl_wrapper.*`` class instance ). During code creation process,
-``code creator`` reads its settings( the code generation engine instructions )
-from the declaration.
-
-``Code creator``'s are the only classes, that generate the code!
-
Composite ``code creator`` is a creator, that contains other creators. Composite
-``code creator`` embeds the code, created by internal ``code creator``'s, within
+``code creator`` embeds the code, created by internal ``code creators``, within
the code it creates. For example:
* ``code_creators.class_t``:
@@ -243,9 +242,8 @@
Code creators tree
~~~~~~~~~~~~~~~~~~
-``code_creators.module_t`` code creator is a top level code creator. It is a
-composite ``code creator`` too. Take a look on next possible "snapshot" of the
-``code creators tree``:
+``code_creators.module_t`` class is a top level ``code creator``. Take a look on
+next possible "snapshot" of the ``code creators tree``:
::
@@ -264,52 +262,53 @@
<free_function_t ...>
<...>
-I hope, now you understand the termine ``code creators tree``. You can think
-about code creator's 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
Code creators tree construction
-------------------------------
+
+``pyplusplus.module_creator`` package is responsible for the tree construction.
+``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.
+2. It sort the set. `Boost.Python`_ has few rules, that forces the user to export
+ a declaration before another one.
+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.
-``pyplusplus.module_creator.creator_t`` class is responsible for the task. As
-input it gets whole declarations tree. Extracts all declarations that should be
-exported and sorts them. After this it constructs ``code creators tree``.
+Another responsibility of ``creator_t`` class, is to analize declarations and
+their dependency graphs. As a result, this class can:
-Another responsibility of the class, is to analize declarations and their
-dependency graphs. Today, only limited subset of the functionality is implemented:
-
* find out a class ``HeldType``
* find out smart pointers conversion, that should be registered
* find out std containers, that should be exported
+
+* warn user, if some declaration is not exported and it used somewhere in
+ exported declarations ( **to be implemented pretty soon** )
-Next functionality is still missing: if some declaration is not exported and
-it used somewhere in exported declarations, `Py++`_ will warn user.
-
-
+
File writers
------------
-``File writer``'s classes is responcible for writting `code creators tree`` into
-files. Lets take a look on few lines of code from ``file_writers.single_file_t``
-class.
-
-::
-
- ...
- #write_file will write the code to file only if needed.
- #extmodule is an instance of code_creators.module_t class
- self.write_file( self.file_name, self.extmodule.create() )
- # ^^^^^^^^^^^^^^^^^^^^^^^
-
-``single_file_t`` does not know any ``code creator``, except the ``module_t``!
-
-``File writer``'s do not know and will not know all ``code creator``'s.
+``File writers`` classes are responsible for writting ``code creators tree`` into
+files. `Py++`_ implements few strategies of writting ``code creators tree``
+into file(s):
+* all source code will be written in single file
+* all source code will be written in multiple files
+ * huge classes will be written in multiple files
+
+
+
+
+
.. _`Py++` : ./../pyplusplus.html
.. _`pygccxml` : ./../../pygccxml/pygccxml.html
.. _`Boost.Python`: http://www.boost.org/libs/python/doc/index.html
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|