kindred/create
1
1
Fork 0
Code Issues 37 Pull Requests Actions Packages Projects 9 Releases 2 Wiki Activity

Base: fix indentation of documentation

Browse Source
This commit is contained in:
wmayer
2023-11-11 14:33:12 +01:00
committed by WandererFan
parent a42d6f815f
commit a776f8b333
1 changed files with 27 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
src/Base/PyExport.h
View File

@@ -55,38 +55,38 @@ namespace Base
class PyObjectBase;
/** The PyHandler class
* This class is the base class of all FreeCAD classes
* which exports into the python space. This class handles the
* creation referencing of the python export object.
* This class is the base class of all FreeCAD classes
* which exports into the python space. This class handles the
* creation referencing of the python export object.
*
* @remark GetPyObject() returns the associated Python object to any C++ subclasses. As we cannot
* determine for sure if we can increment the returned Python object from outside of GetPyObject()
* we have specified that GetPyObject() does already the increment of the reference counter
* if needed.
* @remark GetPyObject() returns the associated Python object to any C++ subclasses. As we cannot
* determine for sure if we can increment the returned Python object from outside of GetPyObject()
* we have specified that GetPyObject() does already the increment of the reference counter
* if needed.
*
* E.g. if GetPyObject() always returns a new Python object then no increment is necessary,
* because at construction time the reference counter is already set to 1. If the Python
* interpreter stores this object pointer into a local variable and destroys this variable
* then the reference counter gets decremented (to 0) and the object gets destroyed automatically.
* In case we didn't make this specification and increment the Python object from outside once
* E.g. if GetPyObject() always returns a new Python object then no increment is necessary,
* because at construction time the reference counter is already set to 1. If the Python
* interpreter stores this object pointer into a local variable and destroys this variable
* then the reference counter gets decremented (to 0) and the object gets destroyed automatically.
* In case we didn't make this specification and increment the Python object from outside once
* again then the reference counter would be set to 2 and there would be no chance to destroy the
* object again.
*
* The other case is that we have a member variable in our C++ class that holds the Python object
* then we either can create this Python in the constructor or create it the first time when
* The other case is that we have a member variable in our C++ class that holds the Python object
* then we either can create this Python in the constructor or create it the first time when
* GetPyObject() gets called. In the destructor then we must decrement the Python object to avoid a
* memory leak while GetPyObject() then increments the Python object every time it gets called.
*
* @remark One big consequence of this specification is that the programmer must know whether the
* @remark One big consequence of this specification is that the programmer must know whether the
* Python interpreter gets the Python object or not. If the interpreter gets the object then it
* decrements the counter later on when the internal variable is freed. In case the interpreter
* doesn't get this object then the programmer must do the decrement on their own.
*
* @note To not to undermine this specification the programmer must make sure to get the Python
* @note To not to undermine this specification the programmer must make sure to get the Python
* object always via GetPyObject().
*
* @see PyHandle
* @
* @see PyHandle
* @
*/
// class BaseExport PyHandler
//{
@@ -100,15 +100,15 @@ class PyObjectBase;
/** Python Object handle class
* Using pointers on classes derived from PyObjectBase would
* be potentionaly dangerous because you would have to take
* care of the reference counting of python by your self. Hence
* this class was designed. It takes care of references and
* as long as a object of this class exists the handled class get
* not destructed. That means a PyObjectBase derived object you can
* only destruct by destructing all FCPyHandle and all python
* references on it!
* @see PyObjectBase
* Using pointers on classes derived from PyObjectBase would
* be potentionaly dangerous because you would have to take
* care of the reference counting of python by your self. Hence
* this class was designed. It takes care of references and
* as long as a object of this class exists the handled class get
* not destructed. That means a PyObjectBase derived object you can
* only destruct by destructing all FCPyHandle and all python
* references on it!
* @see PyObjectBase
*/
template<class HandledType>
class PyHandle // NOLINT