Compare commits
1 Commits
boost-1.61
...
boost-1.34
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
bb69e7fdb7 |
203
build/Jamfile.v2
@@ -3,9 +3,7 @@
|
||||
# file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
|
||||
|
||||
import os ;
|
||||
import indirect ;
|
||||
import modules ;
|
||||
import feature ;
|
||||
|
||||
import python ;
|
||||
|
||||
@@ -14,138 +12,81 @@ if ! [ python.configured ] && ! ( --without-python in [ modules.peek : ARGV ] )
|
||||
# Attempt default configuration of python
|
||||
import toolset : using ;
|
||||
using python ;
|
||||
|
||||
if ! [ python.configured ]
|
||||
{
|
||||
ECHO "WARNING: No python installation configured and autoconfiguration" ;
|
||||
ECHO " failed. See http://www.boost.org/libs/python/doc/building.html" ;
|
||||
ECHO " for configuration instructions or pass --without-python to" ;
|
||||
ECHO " suppress this message and silently skip all Boost.Python targets" ;
|
||||
}
|
||||
}
|
||||
|
||||
if [ python.configured ] || ( --without-python in [ modules.peek : ARGV ] )
|
||||
{
|
||||
alias config-warning ;
|
||||
if [ python.configured ] {
|
||||
|
||||
project boost/python
|
||||
: source-location ../src
|
||||
;
|
||||
|
||||
lib boost_python
|
||||
: # sources
|
||||
numeric.cpp
|
||||
list.cpp
|
||||
long.cpp
|
||||
dict.cpp
|
||||
tuple.cpp
|
||||
str.cpp
|
||||
slice.cpp
|
||||
|
||||
converter/from_python.cpp
|
||||
converter/registry.cpp
|
||||
converter/type_id.cpp
|
||||
object/enum.cpp
|
||||
object/class.cpp
|
||||
object/function.cpp
|
||||
object/inheritance.cpp
|
||||
object/life_support.cpp
|
||||
object/pickle_support.cpp
|
||||
errors.cpp
|
||||
module.cpp
|
||||
converter/builtin_converters.cpp
|
||||
converter/arg_to_python_base.cpp
|
||||
object/iterator.cpp
|
||||
object/stl_iterator.cpp
|
||||
object_protocol.cpp
|
||||
object_operators.cpp
|
||||
wrapper.cpp
|
||||
import.cpp
|
||||
exec.cpp
|
||||
: # requirements
|
||||
<link>static:<define>BOOST_PYTHON_STATIC_LIB
|
||||
<define>BOOST_PYTHON_SOURCE
|
||||
|
||||
# On Windows, all code using Python has to link to the Python
|
||||
# import library.
|
||||
#
|
||||
# On *nix we never link libboost_python to libpython. When
|
||||
# extending Python, all Python symbols are provided by the
|
||||
# Python interpreter executable. When embedding Python, the
|
||||
# client executable is expected to explicitly link to
|
||||
# /python//python (the target representing libpython) itself.
|
||||
#
|
||||
# python_for_extensions is a target defined by Boost.Build to
|
||||
# provide the Python include paths, and on Windows, the Python
|
||||
# import library, as usage requirements.
|
||||
<library>/python//python_for_extensions
|
||||
|
||||
<python-debugging>on:<define>BOOST_DEBUG_PYTHON
|
||||
|
||||
: # default build
|
||||
<link>shared
|
||||
: # usage requirements
|
||||
<link>static:<define>BOOST_PYTHON_STATIC_LIB
|
||||
<python-debugging>on:<define>BOOST_DEBUG_PYTHON
|
||||
;
|
||||
}
|
||||
else
|
||||
{
|
||||
message config-warning
|
||||
: "warning: No python installation configured and autoconfiguration"
|
||||
: "note: failed. See http://www.boost.org/libs/python/doc/building.html"
|
||||
: "note: for configuration instructions or pass --without-python to"
|
||||
: "note: suppress this message and silently skip all Boost.Python targets"
|
||||
;
|
||||
}
|
||||
|
||||
rule find-py3-version
|
||||
{
|
||||
local versions = [ feature.values python ] ;
|
||||
local py3ver ;
|
||||
for local v in $(versions)
|
||||
{
|
||||
if $(v) >= 3.0
|
||||
{
|
||||
py3ver = $(v) ;
|
||||
}
|
||||
}
|
||||
return $(py3ver) ;
|
||||
}
|
||||
|
||||
py3-version = [ find-py3-version ] ;
|
||||
|
||||
project boost/python
|
||||
: source-location ../src
|
||||
: requirements
|
||||
-<tag>@$(BOOST_JAMROOT_MODULE)%$(BOOST_JAMROOT_MODULE).tag
|
||||
<tag>@$(__name__).tag
|
||||
;
|
||||
|
||||
rule tag ( name : type ? : property-set )
|
||||
{
|
||||
local result = $(name) ;
|
||||
if $(type) in STATIC_LIB SHARED_LIB IMPORT_LIB
|
||||
{
|
||||
if $(name) = boost_python && $(PYTHON_ID)
|
||||
{
|
||||
result = $(result)-$(PYTHON_ID) ;
|
||||
}
|
||||
}
|
||||
|
||||
# forward to the boost tagging rule
|
||||
return [ indirect.call $(BOOST_JAMROOT_MODULE)%$(BOOST_JAMROOT_MODULE).tag
|
||||
$(result) : $(type) : $(property-set) ] ;
|
||||
}
|
||||
|
||||
rule cond ( test ? : yes * : no * ) { if $(test) { return $(yes) ; } else { return $(no) ; } }
|
||||
rule unless ( test ? : yes * : no * ) { if ! $(test) { return $(yes) ; } else { return $(no) ; } }
|
||||
|
||||
rule lib_boost_python ( is-py3 ? )
|
||||
{
|
||||
|
||||
lib [ cond $(is-py3) : boost_python3 : boost_python ]
|
||||
: # sources
|
||||
numeric.cpp
|
||||
list.cpp
|
||||
long.cpp
|
||||
dict.cpp
|
||||
tuple.cpp
|
||||
str.cpp
|
||||
slice.cpp
|
||||
|
||||
converter/from_python.cpp
|
||||
converter/registry.cpp
|
||||
converter/type_id.cpp
|
||||
object/enum.cpp
|
||||
object/class.cpp
|
||||
object/function.cpp
|
||||
object/inheritance.cpp
|
||||
object/life_support.cpp
|
||||
object/pickle_support.cpp
|
||||
errors.cpp
|
||||
module.cpp
|
||||
converter/builtin_converters.cpp
|
||||
converter/arg_to_python_base.cpp
|
||||
object/iterator.cpp
|
||||
object/stl_iterator.cpp
|
||||
object_protocol.cpp
|
||||
object_operators.cpp
|
||||
wrapper.cpp
|
||||
import.cpp
|
||||
exec.cpp
|
||||
object/function_doc_signature.cpp
|
||||
: # requirements
|
||||
<link>static:<define>BOOST_PYTHON_STATIC_LIB
|
||||
<define>BOOST_PYTHON_SOURCE
|
||||
|
||||
# On Windows, all code using Python has to link to the Python
|
||||
# import library.
|
||||
#
|
||||
# On *nix we never link libboost_python to libpython. When
|
||||
# extending Python, all Python symbols are provided by the
|
||||
# Python interpreter executable. When embedding Python, the
|
||||
# client executable is expected to explicitly link to
|
||||
# /python//python (the target representing libpython) itself.
|
||||
#
|
||||
# python_for_extensions is a target defined by Boost.Build to
|
||||
# provide the Python include paths, and on Windows, the Python
|
||||
# import library, as usage requirements.
|
||||
[ cond [ python.configured ] : <library>/python//python_for_extensions ]
|
||||
|
||||
# we prevent building when there is no python available
|
||||
# as it's not possible anyway, and to cause dependents to
|
||||
# fail to build
|
||||
[ unless [ python.configured ] : <build>no ]
|
||||
<dependency>config-warning
|
||||
|
||||
<python-debugging>on:<define>BOOST_DEBUG_PYTHON
|
||||
[ cond $(is-py3) : <python>$(py3-version) ]
|
||||
: # default build
|
||||
<link>shared
|
||||
: # usage requirements
|
||||
<link>static:<define>BOOST_PYTHON_STATIC_LIB
|
||||
<python-debugging>on:<define>BOOST_DEBUG_PYTHON
|
||||
;
|
||||
|
||||
}
|
||||
|
||||
lib_boost_python ;
|
||||
boost-install boost_python ;
|
||||
|
||||
if $(py3-version)
|
||||
{
|
||||
lib_boost_python yes ;
|
||||
boost-install boost_python3 ;
|
||||
ECHO "warning: Python location is not configured" ;
|
||||
ECHO "warning: the Boost.Python library won't be built" ;
|
||||
}
|
||||
|
||||
902
build/VisualStudio/boost_python.dsp
Normal file
@@ -0,0 +1,902 @@
|
||||
# Microsoft Developer Studio Project File - Name="boost_python" - Package Owner=<4>
|
||||
# Microsoft Developer Studio Generated Build File, Format Version 6.00
|
||||
# ** DO NOT EDIT **
|
||||
|
||||
# TARGTYPE "Win32 (x86) Dynamic-Link Library" 0x0102
|
||||
|
||||
CFG=BOOST_PYTHON - WIN32 RELEASE
|
||||
!MESSAGE This is not a valid makefile. To build this project using NMAKE,
|
||||
!MESSAGE use the Export Makefile command and run
|
||||
!MESSAGE
|
||||
!MESSAGE NMAKE /f "boost_python.mak".
|
||||
!MESSAGE
|
||||
!MESSAGE You can specify a configuration when running NMAKE
|
||||
!MESSAGE by defining the macro CFG on the command line. For example:
|
||||
!MESSAGE
|
||||
!MESSAGE NMAKE /f "boost_python.mak" CFG="BOOST_PYTHON - WIN32 RELEASE"
|
||||
!MESSAGE
|
||||
!MESSAGE Possible choices for configuration are:
|
||||
!MESSAGE
|
||||
!MESSAGE "boost_python - Win32 Release" (based on "Win32 (x86) Dynamic-Link Library")
|
||||
!MESSAGE "boost_python - Win32 Debug" (based on "Win32 (x86) Dynamic-Link Library")
|
||||
!MESSAGE
|
||||
|
||||
# Begin Project
|
||||
# PROP AllowPerConfigDependencies 0
|
||||
# PROP Scc_ProjName ""
|
||||
# PROP Scc_LocalPath ""
|
||||
CPP=cl.exe
|
||||
MTL=midl.exe
|
||||
RSC=rc.exe
|
||||
|
||||
!IF "$(CFG)" == "boost_python - Win32 Release"
|
||||
|
||||
# PROP BASE Use_MFC 0
|
||||
# PROP BASE Use_Debug_Libraries 0
|
||||
# PROP BASE Output_Dir "Release"
|
||||
# PROP BASE Intermediate_Dir "Release"
|
||||
# PROP BASE Target_Dir ""
|
||||
# PROP Use_MFC 0
|
||||
# PROP Use_Debug_Libraries 0
|
||||
# PROP Output_Dir "../bin-stage"
|
||||
# PROP Intermediate_Dir "release-obj"
|
||||
# PROP Ignore_Export_Lib 0
|
||||
# PROP Target_Dir ""
|
||||
F90=df.exe
|
||||
# ADD BASE CPP /nologo /MT /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "BPL_EXPORTS" /YX /FD /Zm800 /Zm800 /Zm800 /c
|
||||
# ADD CPP /nologo /MD /W3 /GR /GX /O2 /I "../../../../" /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "BOOST_PYTHON_DYNAMIC_LIB" /D "BOOST_PYTHON_SOURCE" /FD /Zm800 /Zm800 /Zm800 /Zm800 /c
|
||||
# SUBTRACT CPP /YX
|
||||
# ADD BASE MTL /nologo /D "NDEBUG" /mktyplib203 /win32
|
||||
# ADD MTL /nologo /D "NDEBUG" /mktyplib203 /win32
|
||||
# ADD BASE RSC /l 0x1409 /d "NDEBUG"
|
||||
# ADD RSC /l 0x1409 /d "NDEBUG"
|
||||
BSC32=bscmake.exe
|
||||
# ADD BASE BSC32 /nologo
|
||||
# ADD BSC32 /nologo
|
||||
LINK32=link.exe
|
||||
# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386
|
||||
# ADD LINK32 kernel32.lib user32.lib /nologo /dll /machine:I386
|
||||
|
||||
!ELSEIF "$(CFG)" == "boost_python - Win32 Debug"
|
||||
|
||||
# PROP BASE Use_MFC 0
|
||||
# PROP BASE Use_Debug_Libraries 1
|
||||
# PROP BASE Output_Dir "Debug"
|
||||
# PROP BASE Intermediate_Dir "Debug"
|
||||
# PROP BASE Target_Dir ""
|
||||
# PROP Use_MFC 0
|
||||
# PROP Use_Debug_Libraries 1
|
||||
# PROP Output_Dir "../bin-stage"
|
||||
# PROP Intermediate_Dir "debug-obj"
|
||||
# PROP Ignore_Export_Lib 0
|
||||
# PROP Target_Dir ""
|
||||
F90=df.exe
|
||||
# ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "BPL_EXPORTS" /YX /FD /Zm800 /Zm800 /Zm800 /GZ /c
|
||||
# ADD CPP /nologo /MDd /W3 /GR /GX /Zi /Od /I "../../../../" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "BOOST_PYTHON_DYNAMIC_LIB" /D "BOOST_PYTHON_SOURCE" /FD /Zm800 /Zm800 /Zm800 /Zm800 /Zm800 /GZ /c
|
||||
# ADD BASE MTL /nologo /D "_DEBUG" /mktyplib203 /win32
|
||||
# ADD MTL /nologo /D "_DEBUG" /mktyplib203 /win32
|
||||
# ADD BASE RSC /l 0x1409 /d "_DEBUG"
|
||||
# ADD RSC /l 0x1409 /d "_DEBUG"
|
||||
BSC32=bscmake.exe
|
||||
# ADD BASE BSC32 /nologo
|
||||
# ADD BSC32 /nologo
|
||||
LINK32=link.exe
|
||||
# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept
|
||||
# ADD LINK32 kernel32.lib user32.lib /nologo /dll /incremental:no /debug /machine:I386 /out:"../bin-stage/boost_python_debug.dll" /pdbtype:sept
|
||||
|
||||
!ENDIF
|
||||
|
||||
# Begin Target
|
||||
|
||||
# Name "boost_python - Win32 Release"
|
||||
# Name "boost_python - Win32 Debug"
|
||||
# Begin Group "Source Files"
|
||||
|
||||
# PROP Default_Filter "cpp;c;cxx;rc;def;r;odl;idl;hpj;bat"
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\converter\arg_to_python_base.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\converter\builtin_converters.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\object\class.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\dict.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\object\enum.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\errors.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\converter\from_python.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\object\function.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\object\inheritance.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\object\iterator.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\object\life_support.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\list.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\long.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\module.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\numeric.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\object_operators.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\object_protocol.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\object\pickle_support.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\converter\registry.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\slice.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\object\stl_iterator.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\str.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\tuple.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\converter\type_id.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\wrapper.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\import.cpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\src\exec.cpp
|
||||
# End Source File
|
||||
# End Group
|
||||
# Begin Group "Header Files"
|
||||
|
||||
# PROP Default_Filter "h;hpp;hxx;hm;inl"
|
||||
# Begin Group "detail"
|
||||
|
||||
# PROP Default_Filter ""
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\api_placeholder.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\arg_tuple_size.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\borrowed_ptr.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\call_object.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\caller.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\char_array.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\config.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\construct.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\convertible.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\cv_category.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\decorated_type_id.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\def_helper.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\defaults_def.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\defaults_gen.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\dependent.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\destroy.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\exception_handler.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\force_instantiate.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\if_else.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\indirect_traits.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\make_keyword_range_fn.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\make_tuple.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\map_entry.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\member_function_cast.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\module_base.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\module_init.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\msvc_typeinfo.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\none.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\not_specified.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\operator_id.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\overloads_fwd.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\pointee.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\preprocessor.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\python22_fixed.h
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\raw_pyobject.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\referent_storage.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\result.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\returning.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\scope.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\string_literal.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\target.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\translate_exception.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\type_list.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\type_list_impl.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\type_list_impl_no_pts.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\type_list_utils.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\unwind_type.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\void_ptr.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\void_return.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\detail\wrap_python.hpp
|
||||
# End Source File
|
||||
# End Group
|
||||
# Begin Group "converter"
|
||||
|
||||
# PROP Default_Filter ""
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\arg_from_python.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\arg_to_python.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\arg_to_python_base.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\builtin_converters.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\constructor_function.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\convertible_function.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\from_python.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\implicit.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\obj_mgr_arg_from_python.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\object_manager.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\pointer_type_id.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\pyobject_traits.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\pyobject_type.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\pytype_arg_from_python.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\pytype_object_mgr_traits.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\registered.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\registered_pointee.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\registrations.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\registry.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\return_from_python.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\rvalue_from_python_data.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\converter\to_python_function_type.hpp
|
||||
# End Source File
|
||||
# End Group
|
||||
# Begin Group "object"
|
||||
|
||||
# PROP Default_Filter ""
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\add_to_namespace.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\class.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\class_converters.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\class_detail.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\class_wrapper.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\construct.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\enum_base.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\find_instance.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\forward.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\function.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\function_handle.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\function_object.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\inheritance.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\instance.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\iterator.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\iterator_core.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\life_support.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\make_holder.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\make_instance.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\pickle_support.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\pointer_holder.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\py_function.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\select_holder.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\stl_iterator_core.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\value_holder.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object\value_holder_fwd.hpp
|
||||
# End Source File
|
||||
# End Group
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\arg_from_python.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\args.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\args_fwd.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\back_reference.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\base_type_traits.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\bases.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\borrowed.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\call.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\call_method.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\cast.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\class.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\class_fwd.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\copy_const_reference.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\copy_non_const_reference.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\data_members.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\def.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\default_call_policies.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\dict.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\enum.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\errors.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\exception_translator.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\extract.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\handle.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\handle_fwd.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\has_back_reference.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\implicit.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\init.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\instance_holder.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\iterator.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\list.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\long.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\lvalue_from_pytype.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\make_function.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\manage_new_object.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\module.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\module_init.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\numeric.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object_attributes.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object_call.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object_core.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object_fwd.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object_items.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object_operators.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object_protocol.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object_protocol_core.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\object_slices.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\operators.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\operators2.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\other.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\overloads.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\pointee.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\proxy.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\ptr.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\refcount.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\reference_existing_object.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\return_internal_reference.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\return_value_policy.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\scope.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\self.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\signature.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\slice_nil.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\stl_iterator.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\str.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\tag.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\to_python_converter.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\to_python_indirect.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\to_python_value.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\tuple.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\type_id.hpp
|
||||
# End Source File
|
||||
# Begin Source File
|
||||
|
||||
SOURCE=..\..\..\..\boost\python\with_custodian_and_ward.hpp
|
||||
# End Source File
|
||||
# End Group
|
||||
# Begin Group "Resource Files"
|
||||
|
||||
# PROP Default_Filter "ico;cur;bmp;dlg;rc2;rct;bin;rgs;gif;jpg;jpeg;jpe"
|
||||
# End Group
|
||||
# End Target
|
||||
# End Project
|
||||
29
build/VisualStudio/boost_python.dsw
Normal file
@@ -0,0 +1,29 @@
|
||||
Microsoft Developer Studio Workspace File, Format Version 6.00
|
||||
# WARNING: DO NOT EDIT OR DELETE THIS WORKSPACE FILE!
|
||||
|
||||
###############################################################################
|
||||
|
||||
Project: "boost_python"=".\boost_python.dsp" - Package Owner=<4>
|
||||
|
||||
Package=<5>
|
||||
{{{
|
||||
}}}
|
||||
|
||||
Package=<4>
|
||||
{{{
|
||||
}}}
|
||||
|
||||
###############################################################################
|
||||
|
||||
Global:
|
||||
|
||||
Package=<5>
|
||||
{{{
|
||||
}}}
|
||||
|
||||
Package=<3>
|
||||
{{{
|
||||
}}}
|
||||
|
||||
###############################################################################
|
||||
|
||||
28
class.cpp
@@ -1,28 +0,0 @@
|
||||
// Distributed under the Boost Software License, Version 1.0. (See
|
||||
// accompanying file LICENSE_1_0.txt or copy at
|
||||
// http://www.boost.org/LICENSE_1_0.txt)
|
||||
#include <boost/python/module.hpp>
|
||||
#include <boost/python/def.hpp>
|
||||
#include <boost/python/object.hpp>
|
||||
#include <boost/python/class.hpp>
|
||||
|
||||
using namespace boost::python;
|
||||
|
||||
struct X
|
||||
{
|
||||
int x;
|
||||
X(int n) : x(n) { }
|
||||
};
|
||||
|
||||
int x_function(X& x)
|
||||
{ return x.x;
|
||||
}
|
||||
|
||||
|
||||
BOOST_PYTHON_MODULE(class_ext)
|
||||
{
|
||||
class_<X>("X", init<int>());
|
||||
def("x_function", x_function);
|
||||
}
|
||||
|
||||
#include "module_tail.cpp"
|
||||
62
doc/Jamfile
@@ -1,49 +1,23 @@
|
||||
# Copyright (c) 2006 Joel de Guzman
|
||||
# Copyright (c) 2015 Stefan Seefeld
|
||||
#
|
||||
# Distributed under the Boost Software License, Version 1.0. (See accompanying
|
||||
# Copyright David Abrahams 2006. Distributed under the Boost
|
||||
# Software License, Version 1.0. (See accompanying
|
||||
# file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
|
||||
|
||||
path-constant here : . ;
|
||||
path-constant images : html/images ;
|
||||
|
||||
|
||||
project python/doc
|
||||
: requirements
|
||||
-<xsl:param>boost.defaults=Boost
|
||||
<format>html:<xsl:param>boost.defaults=none
|
||||
<format>html:<xsl:param>toc.max.depth=3
|
||||
<format>html:<xsl:param>toc.section.depth=2
|
||||
<format>html:<xsl:param>chunk.section.depth=1
|
||||
;
|
||||
|
||||
import boostbook ;
|
||||
import quickbook ;
|
||||
import docutils ;
|
||||
|
||||
boostbook python : python.qbk
|
||||
: <format>html:<name>$(here)/html
|
||||
<format>html:<xsl:param>generate.toc="library nop; chapter toc; section toc;"
|
||||
<format>html:<xsl:param>html.stylesheet=boostbook.css
|
||||
<format>html:<xsl:param>boost.image.src=images/boost.png
|
||||
<format>html:<xsl:param>boost.graphics.root=images/
|
||||
;
|
||||
import path ;
|
||||
sources = building.rst ;
|
||||
bases = $(sources:S=) ;
|
||||
|
||||
# This is a path relative to the html/ subdirectory where the
|
||||
# generated output will eventually be moved.
|
||||
stylesheet = "--stylesheet=../../../rst.css" ;
|
||||
|
||||
boostbook tutorial : tutorial.qbk
|
||||
: <format>html:<name>$(here)/html/tutorial
|
||||
<format>html:<xsl:param>html.stylesheet=../boostbook.css
|
||||
<format>html:<xsl:param>boost.image.src=../images/boost.png
|
||||
<format>html:<xsl:param>boost.graphics.root=../images/
|
||||
;
|
||||
for local b in $(bases)
|
||||
{
|
||||
html $(b) : $(b).rst :
|
||||
|
||||
<docutils-html>"-gdt --source-url="./$(b).rst" --link-stylesheet --traceback --trim-footnote-reference-space --footnote-references=superscript "$(stylesheet)
|
||||
;
|
||||
}
|
||||
|
||||
boostbook reference : reference.qbk
|
||||
: <format>html:<name>$(here)/html/reference
|
||||
<format>html:<xsl:param>html.stylesheet=../boostbook.css
|
||||
<format>html:<xsl:param>boost.image.src=../images/boost.png
|
||||
<format>html:<xsl:param>boost.graphics.root=../images/
|
||||
;
|
||||
|
||||
html article : article.rst
|
||||
: <location>html
|
||||
<docutils-html>"--link-stylesheet --traceback --trim-footnote-reference-space --footnote-references=superscript --stylesheet=rst.css"
|
||||
;
|
||||
alias htmls : $(bases) ;
|
||||
stage . : $(bases) ;
|
||||
|
||||
22
doc/PyConDC_2003/bpl.html
Executable file
@@ -0,0 +1,22 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
|
||||
<!-- Copyright David Abrahams 2006. Distributed under the Boost -->
|
||||
<!-- Software License, Version 1.0. (See accompanying -->
|
||||
<!-- file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -->
|
||||
<!-- Copyright David Abrahams 2006. Distributed under the Boost -->
|
||||
<!-- Software License, Version 1.0. (See accompanying -->
|
||||
<!-- file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -->
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Windows (vers 1st August 2002), see www.w3.org">
|
||||
<meta http-equiv="refresh" content="0; URL=http://www.boost-consulting.com/writing/bpl.html">
|
||||
|
||||
<title>Loading: “Building Hybrid Systems With Boost.Python”</title>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
Loading...; if nothing happens, please go to <a href= "http://www.boost-consulting.com/writing/bpl.html">http://www.boost-consulting.com/writing/bpl.html</a>.
|
||||
</body>
|
||||
</html>
|
||||
|
||||
BIN
doc/PyConDC_2003/bpl.pdf
Executable file
5
doc/PyConDC_2003/bpl.txt
Normal file
@@ -0,0 +1,5 @@
|
||||
.. Copyright David Abrahams 2006. Distributed under the Boost
|
||||
.. Software License, Version 1.0. (See accompanying
|
||||
.. file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
|
||||
|
||||
This file has been moved to http://www.boost-consulting.com/writing/bpl.txt.
|
||||
912
doc/PyConDC_2003/bpl_mods.txt
Normal file
@@ -0,0 +1,912 @@
|
||||
Copyright David Abrahams 2006. Distributed under the Boost
|
||||
Software License, Version 1.0. (See accompanying
|
||||
file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
|
||||
|
||||
.. This is a comment. Note how any initial comments are moved by
|
||||
transforms to after the document title, subtitle, and docinfo.
|
||||
|
||||
.. Need intro and conclusion
|
||||
.. Exposing classes
|
||||
.. Constructors
|
||||
.. Overloading
|
||||
.. Properties and data members
|
||||
.. Inheritance
|
||||
.. Operators and Special Functions
|
||||
.. Virtual Functions
|
||||
.. Call Policies
|
||||
|
||||
++++++++++++++++++++++++++++++++++++++++++++++
|
||||
Introducing Boost.Python (Extended Abstract)
|
||||
++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
|
||||
.. bibliographic fields (which also require a transform):
|
||||
|
||||
:Author: David Abrahams
|
||||
:Address: 45 Walnut Street
|
||||
Somerville, MA 02143
|
||||
:Contact: dave@boost-consulting.com
|
||||
:organization: `Boost Consulting`_
|
||||
:date: $Date$
|
||||
:status: This is a "work in progress"
|
||||
:version: 1
|
||||
:copyright: Copyright David Abrahams 2002. All rights reserved
|
||||
|
||||
:Dedication:
|
||||
|
||||
For my girlfriend, wife, and partner Luann
|
||||
|
||||
:abstract:
|
||||
|
||||
This paper describes the Boost.Python library, a system for
|
||||
C++/Python interoperability.
|
||||
|
||||
.. meta::
|
||||
:keywords: Boost,python,Boost.Python,C++
|
||||
:description lang=en: C++/Python interoperability with Boost.Python
|
||||
|
||||
.. contents:: Table of Contents
|
||||
.. section-numbering::
|
||||
|
||||
|
||||
.. _`Boost Consulting`: http://www.boost-consulting.com
|
||||
|
||||
==============
|
||||
Introduction
|
||||
==============
|
||||
|
||||
Python and C++ are in many ways as different as two languages could
|
||||
be: while C++ is usually compiled to machine-code, Python is
|
||||
interpreted. Python's dynamic type system is often cited as the
|
||||
foundation of its flexibility, while in C++ static typing is the
|
||||
cornerstone of its efficiency. C++ has an intricate and difficult
|
||||
meta-language to support compile-time polymorphism, while Python is
|
||||
a uniform language with convenient runtime polymorphism.
|
||||
|
||||
Yet for many programmers, these very differences mean that Python and
|
||||
C++ complement one another perfectly. Performance bottlenecks in
|
||||
Python programs can be rewritten in C++ for maximal speed, and
|
||||
authors of powerful C++ libraries choose Python as a middleware
|
||||
language for its flexible system integration capabilities.
|
||||
Furthermore, the surface differences mask some strong similarities:
|
||||
|
||||
* 'C'-family control structures (if, while, for...)
|
||||
|
||||
* Support for object-orientation, functional programming, and generic
|
||||
programming (these are both *multi-paradigm* programming languages.)
|
||||
|
||||
* Comprehensive operator overloading facilities, recognizing the
|
||||
importance of syntactic variability for readability and
|
||||
expressivity.
|
||||
|
||||
* High-level concepts such as collections and iterators.
|
||||
|
||||
* High-level encapsulation facilities (C++: namespaces, Python: modules)
|
||||
to support the design of re-usable libraries.
|
||||
|
||||
* Exception-handling for effective management of error conditions.
|
||||
|
||||
* C++ idioms in common use, such as handle/body classes and
|
||||
reference-counted smart pointers mirror Python reference semantics.
|
||||
|
||||
Python provides a rich 'C' API for writers of 'C' extension modules.
|
||||
Unfortunately, using this API directly for exposing C++ type and
|
||||
function interfaces to Python is much more tedious than it should be.
|
||||
This is mainly due to the limitations of the 'C' language. Compared to
|
||||
C++ and Python, 'C' has only very rudimentary abstraction facilities.
|
||||
Support for exception-handling is completely missing. One important
|
||||
undesirable consequence is that 'C' extension module writers are
|
||||
required to manually manage Python reference counts. Another unpleasant
|
||||
consequence is a very high degree of repetition of similar code in 'C'
|
||||
extension modules. Of course highly redundant code does not only cause
|
||||
frustration for the module writer, but is also very difficult to
|
||||
maintain.
|
||||
|
||||
The limitations of the 'C' API have lead to the development of a
|
||||
variety of wrapping systems. SWIG_ is probably the most popular package
|
||||
for the integration of C/C++ and Python. A more recent development is
|
||||
the SIP_ package, which is specifically designed for interfacing Python
|
||||
with the Qt_ graphical user interface library. Both SWIG and SIP
|
||||
introduce a new specialized language for defining the inter-language
|
||||
bindings. Of course being able to use a specialized language has
|
||||
advantages, but having to deal with three different languages (Python,
|
||||
C/C++ and the interface language) also introduces practical and mental
|
||||
difficulties. The CXX_ package demonstrates an interesting alternative.
|
||||
It shows that at least some parts of Python's 'C' API can be wrapped
|
||||
and presented through a much more user-friendly C++ interface. However,
|
||||
unlike SWIG and SIP, CXX does not include support for wrapping C++
|
||||
classes as new Python types. CXX is also no longer actively developed.
|
||||
|
||||
In some respects Boost.Python combines ideas from SWIG and SIP with
|
||||
ideas from CXX. Like SWIG and SIP, Boost.Python is a system for
|
||||
wrapping C++ classes as new Python "built-in" types, and C/C++
|
||||
functions as Python functions. Like CXX, Boost.Python presents Python's
|
||||
'C' API through a C++ interface. Boost.Python goes beyond the scope of
|
||||
other systems with the unique support for C++ virtual functions that
|
||||
are overrideable in Python, support for organizing extensions as Python
|
||||
packages with a central registry for inter-language type conversions,
|
||||
and a convenient mechanism for tying into Python's serialization engine
|
||||
(pickle). Importantly, all this is achieved without introducing a new
|
||||
syntax. Boost.Python leverages the power of C++ meta-programming
|
||||
techniques to introspect about the C++ type system, and presents a
|
||||
simple, IDL-like C++ interface for exposing C/C++ code in extension
|
||||
modules. Boost.Python is a pure C++ library, the inter-language
|
||||
bindings are defined in pure C++, and other than a C++ compiler only
|
||||
Python itself is required to get started with Boost.Python. Last but
|
||||
not least, Boost.Python is an unrestricted open source library. There
|
||||
are no strings attached even for commercial applications.
|
||||
|
||||
.. _SWIG: http://www.swig.org/
|
||||
.. _SIP: http://www.riverbankcomputing.co.uk/sip/index.php
|
||||
.. _Qt: http://www.trolltech.com/
|
||||
.. _CXX: http://cxx.sourceforge.net/
|
||||
|
||||
===========================
|
||||
Boost.Python Design Goals
|
||||
===========================
|
||||
|
||||
The primary goal of Boost.Python is to allow users to expose C++
|
||||
classes and functions to Python using nothing more than a C++
|
||||
compiler. In broad strokes, the user experience should be one of
|
||||
directly manipulating C++ objects from Python.
|
||||
|
||||
However, it's also important not to translate all interfaces *too*
|
||||
literally: the idioms of each language must be respected. For
|
||||
example, though C++ and Python both have an iterator concept, they are
|
||||
expressed very differently. Boost.Python has to be able to bridge the
|
||||
interface gap.
|
||||
|
||||
It must be possible to insulate Python users from crashes resulting
|
||||
from trivial misuses of C++ interfaces, such as accessing
|
||||
already-deleted objects. By the same token the library should
|
||||
insulate C++ users from low-level Python 'C' API, replacing
|
||||
error-prone 'C' interfaces like manual reference-count management and
|
||||
raw ``PyObject`` pointers with more-robust alternatives.
|
||||
|
||||
Support for component-based development is crucial, so that C++ types
|
||||
exposed in one extension module can be passed to functions exposed in
|
||||
another without loss of crucial information like C++ inheritance
|
||||
relationships.
|
||||
|
||||
Finally, all wrapping must be *non-intrusive*, without modifying or
|
||||
even seeing the original C++ source code. Existing C++ libraries have
|
||||
to be wrappable by third parties who only have access to header files
|
||||
and binaries.
|
||||
|
||||
==========================
|
||||
Hello Boost.Python World
|
||||
==========================
|
||||
|
||||
And now for a preview of Boost.Python, and how it improves on the raw
|
||||
facilities offered by Python. Here's a function we might want to
|
||||
expose::
|
||||
|
||||
char const* greet(unsigned x)
|
||||
{
|
||||
static char const* const msgs[] = { "hello", "Boost.Python", "world!" };
|
||||
|
||||
if (x > 2)
|
||||
throw std::range_error("greet: index out of range");
|
||||
|
||||
return msgs[x];
|
||||
}
|
||||
|
||||
To wrap this function in standard C++ using the Python 'C' API, we'd
|
||||
need something like this::
|
||||
|
||||
extern "C" // all Python interactions use 'C' linkage and calling convention
|
||||
{
|
||||
// Wrapper to handle argument/result conversion and checking
|
||||
PyObject* greet_wrap(PyObject* args, PyObject * keywords)
|
||||
{
|
||||
int x;
|
||||
if (PyArg_ParseTuple(args, "i", &x)) // extract/check arguments
|
||||
{
|
||||
char const* result = greet(x); // invoke wrapped function
|
||||
return PyString_FromString(result); // convert result to Python
|
||||
}
|
||||
return 0; // error occurred
|
||||
}
|
||||
|
||||
// Table of wrapped functions to be exposed by the module
|
||||
static PyMethodDef methods[] = {
|
||||
{ "greet", greet_wrap, METH_VARARGS, "return one of 3 parts of a greeting" }
|
||||
, { NULL, NULL, 0, NULL } // sentinel
|
||||
};
|
||||
|
||||
// module initialization function
|
||||
DL_EXPORT init_hello()
|
||||
{
|
||||
(void) Py_InitModule("hello", methods); // add the methods to the module
|
||||
}
|
||||
}
|
||||
|
||||
Now here's the wrapping code we'd use to expose it with Boost.Python::
|
||||
|
||||
#include <boost/python.hpp>
|
||||
using namespace boost::python;
|
||||
BOOST_PYTHON_MODULE(hello)
|
||||
{
|
||||
def("greet", greet, "return one of 3 parts of a greeting");
|
||||
}
|
||||
|
||||
and here it is in action::
|
||||
|
||||
>>> import hello
|
||||
>>> for x in range(3):
|
||||
... print hello.greet(x)
|
||||
...
|
||||
hello
|
||||
Boost.Python
|
||||
world!
|
||||
|
||||
Aside from the fact that the 'C' API version is much more verbose than
|
||||
the BPL one, it's worth noting that it doesn't handle a few things
|
||||
correctly:
|
||||
|
||||
* The original function accepts an unsigned integer, and the Python
|
||||
'C' API only gives us a way of extracting signed integers. The
|
||||
Boost.Python version will raise a Python exception if we try to pass
|
||||
a negative number to ``hello.greet``, but the other one will proceed
|
||||
to do whatever the C++ implementation does when converting an
|
||||
negative integer to unsigned (usually wrapping to some very large
|
||||
number), and pass the incorrect translation on to the wrapped
|
||||
function.
|
||||
|
||||
* That brings us to the second problem: if the C++ ``greet()``
|
||||
function is called with a number greater than 2, it will throw an
|
||||
exception. Typically, if a C++ exception propagates across the
|
||||
boundary with code generated by a 'C' compiler, it will cause a
|
||||
crash. As you can see in the first version, there's no C++
|
||||
scaffolding there to prevent this from happening. Functions wrapped
|
||||
by Boost.Python automatically include an exception-handling layer
|
||||
which protects Python users by translating unhandled C++ exceptions
|
||||
into a corresponding Python exception.
|
||||
|
||||
* A slightly more-subtle limitation is that the argument conversion
|
||||
used in the Python 'C' API case can only get that integer ``x`` in
|
||||
*one way*. PyArg_ParseTuple can't convert Python ``long`` objects
|
||||
(arbitrary-precision integers) which happen to fit in an ``unsigned
|
||||
int`` but not in a ``signed long``, nor will it ever handle a
|
||||
wrapped C++ class with a user-defined implicit ``operator unsigned
|
||||
int()`` conversion. The BPL's dynamic type conversion registry
|
||||
allows users to add arbitrary conversion methods.
|
||||
|
||||
==================
|
||||
Library Overview
|
||||
==================
|
||||
|
||||
This section outlines some of the library's major features. Except as
|
||||
necessary to avoid confusion, details of library implementation are
|
||||
omitted.
|
||||
|
||||
-------------------------------------------
|
||||
The fundamental type-conversion mechanism
|
||||
-------------------------------------------
|
||||
|
||||
XXX This needs to be rewritten.
|
||||
|
||||
Every argument of every wrapped function requires some kind of
|
||||
extraction code to convert it from Python to C++. Likewise, the
|
||||
function return value has to be converted from C++ to Python.
|
||||
Appropriate Python exceptions must be raised if the conversion fails.
|
||||
Argument and return types are part of the function's type, and much of
|
||||
this tedium can be relieved if the wrapping system can extract that
|
||||
information through introspection.
|
||||
|
||||
Passing a wrapped C++ derived class instance to a C++ function
|
||||
accepting a pointer or reference to a base class requires knowledge of
|
||||
the inheritance relationship and how to translate the address of a base
|
||||
class into that of a derived class.
|
||||
|
||||
------------------
|
||||
Exposing Classes
|
||||
------------------
|
||||
|
||||
C++ classes and structs are exposed with a similarly-terse interface.
|
||||
Given::
|
||||
|
||||
struct World
|
||||
{
|
||||
void set(std::string msg) { this->msg = msg; }
|
||||
std::string greet() { return msg; }
|
||||
std::string msg;
|
||||
};
|
||||
|
||||
The following code will expose it in our extension module::
|
||||
|
||||
#include <boost/python.hpp>
|
||||
BOOST_PYTHON_MODULE(hello)
|
||||
{
|
||||
class_<World>("World")
|
||||
.def("greet", &World::greet)
|
||||
.def("set", &World::set)
|
||||
;
|
||||
}
|
||||
|
||||
Although this code has a certain pythonic familiarity, people
|
||||
sometimes find the syntax bit confusing because it doesn't look like
|
||||
most of the C++ code they're used to. All the same, this is just
|
||||
standard C++. Because of their flexible syntax and operator
|
||||
overloading, C++ and Python are great for defining domain-specific
|
||||
(sub)languages
|
||||
(DSLs), and that's what we've done in BPL. To break it down::
|
||||
|
||||
class_<World>("World")
|
||||
|
||||
constructs an unnamed object of type ``class_<World>`` and passes
|
||||
``"World"`` to its constructor. This creates a new-style Python class
|
||||
called ``World`` in the extension module, and associates it with the
|
||||
C++ type ``World`` in the BPL type conversion registry. We might have
|
||||
also written::
|
||||
|
||||
class_<World> w("World");
|
||||
|
||||
but that would've been more verbose, since we'd have to name ``w``
|
||||
again to invoke its ``def()`` member function::
|
||||
|
||||
w.def("greet", &World::greet)
|
||||
|
||||
There's nothing special about the location of the dot for member
|
||||
access in the original example: C++ allows any amount of whitespace on
|
||||
either side of a token, and placing the dot at the beginning of each
|
||||
line allows us to chain as many successive calls to member functions
|
||||
as we like with a uniform syntax. The other key fact that allows
|
||||
chaining is that ``class_<>`` member functions all return a reference
|
||||
to ``*this``.
|
||||
|
||||
So the example is equivalent to::
|
||||
|
||||
class_<World> w("World");
|
||||
w.def("greet", &World::greet);
|
||||
w.def("set", &World::set);
|
||||
|
||||
It's occasionally useful to be able to break down the components of a
|
||||
Boost.Python class wrapper in this way, but the rest of this paper
|
||||
will tend to stick to the terse syntax.
|
||||
|
||||
For completeness, here's the wrapped class in use:
|
||||
|
||||
>>> import hello
|
||||
>>> planet = hello.World()
|
||||
>>> planet.set('howdy')
|
||||
>>> planet.greet()
|
||||
'howdy'
|
||||
|
||||
Constructors
|
||||
============
|
||||
|
||||
Since our ``World`` class is just a plain ``struct``, it has an
|
||||
implicit no-argument (nullary) constructor. Boost.Python exposes the
|
||||
nullary constructor by default, which is why we were able to write:
|
||||
|
||||
>>> planet = hello.World()
|
||||
|
||||
However, well-designed classes in any language may require constructor
|
||||
arguments in order to establish their invariants. Unlike Python,
|
||||
where ``__init__`` is just a specially-named method, In C++
|
||||
constructors cannot be handled like ordinary member functions. In
|
||||
particular, we can't take their address: ``&World::World`` is an
|
||||
error. The library provides a different interface for specifying
|
||||
constructors. Given::
|
||||
|
||||
struct World
|
||||
{
|
||||
World(std::string msg); // added constructor
|
||||
...
|
||||
|
||||
we can modify our wrapping code as follows::
|
||||
|
||||
class_<World>("World", init<std::string>())
|
||||
...
|
||||
|
||||
of course, a C++ class may have additional constructors, and we can
|
||||
expose those as well by passing more instances of ``init<...>`` to
|
||||
``def()``::
|
||||
|
||||
class_<World>("World", init<std::string>())
|
||||
.def(init<double, double>())
|
||||
...
|
||||
|
||||
Boost.Python allows wrapped functions, member functions, and
|
||||
constructors to be overloaded to mirror C++ overloading.
|
||||
|
||||
Data Members and Properties
|
||||
===========================
|
||||
|
||||
Any publicly-accessible data members in a C++ class can be easily
|
||||
exposed as either ``readonly`` or ``readwrite`` attributes::
|
||||
|
||||
class_<World>("World", init<std::string>())
|
||||
.def_readonly("msg", &World::msg)
|
||||
...
|
||||
|
||||
and can be used directly in Python:
|
||||
|
||||
>>> planet = hello.World('howdy')
|
||||
>>> planet.msg
|
||||
'howdy'
|
||||
|
||||
This does *not* result in adding attributes to the ``World`` instance
|
||||
``__dict__``, which can result in substantial memory savings when
|
||||
wrapping large data structures. In fact, no instance ``__dict__``
|
||||
will be created at all unless attributes are explicitly added from
|
||||
Python. BPL owes this capability to the new Python 2.2 type system,
|
||||
in particular the descriptor interface and ``property`` type.
|
||||
|
||||
In C++, publicly-accessible data members are considered a sign of poor
|
||||
design because they break encapsulation, and style guides usually
|
||||
dictate the use of "getter" and "setter" functions instead. In
|
||||
Python, however, ``__getattr__``, ``__setattr__``, and since 2.2,
|
||||
``property`` mean that attribute access is just one more
|
||||
well-encapsulated syntactic tool at the programmer's disposal. BPL
|
||||
bridges this idiomatic gap by making Python ``property`` creation
|
||||
directly available to users. So if ``msg`` were private, we could
|
||||
still expose it as attribute in Python as follows::
|
||||
|
||||
class_<World>("World", init<std::string>())
|
||||
.add_property("msg", &World::greet, &World::set)
|
||||
...
|
||||
|
||||
The example above mirrors the familiar usage of properties in Python
|
||||
2.2+:
|
||||
|
||||
>>> class World(object):
|
||||
... __init__(self, msg):
|
||||
... self.__msg = msg
|
||||
... def greet(self):
|
||||
... return self.__msg
|
||||
... def set(self, msg):
|
||||
... self.__msg = msg
|
||||
... msg = property(greet, set)
|
||||
|
||||
Operators and Special Functions
|
||||
===============================
|
||||
|
||||
The ability to write arithmetic operators for user-defined types that
|
||||
C++ and Python both allow the definition of has been a major factor in
|
||||
the popularity of both languages for scientific computing. The
|
||||
success of packages like NumPy attests to the power of exposing
|
||||
operators in extension modules. In this example we'll wrap a class
|
||||
representing a position in a large file::
|
||||
|
||||
class FilePos { /*...*/ };
|
||||
|
||||
// Linear offset
|
||||
FilePos operator+(FilePos, int);
|
||||
FilePos operator+(int, FilePos);
|
||||
FilePos operator-(FilePos, int);
|
||||
|
||||
// Distance between two FilePos objects
|
||||
int operator-(FilePos, FilePos);
|
||||
|
||||
// Offset with assignment
|
||||
FilePos& operator+=(FilePos&, int);
|
||||
FilePos& operator-=(FilePos&, int);
|
||||
|
||||
// Comparison
|
||||
bool operator<(FilePos, FilePos);
|
||||
|
||||
The wrapping code looks like this::
|
||||
|
||||
class_<FilePos>("FilePos")
|
||||
.def(self + int()) // __add__
|
||||
.def(int() + self) // __radd__
|
||||
.def(self - int()) // __sub__
|
||||
|
||||
.def(self - self) // __sub__
|
||||
|
||||
.def(self += int()) // __iadd__
|
||||
.def(self -= int()) // __isub__
|
||||
|
||||
.def(self < self); // __lt__
|
||||
;
|
||||
|
||||
The magic is performed using a simplified application of "expression
|
||||
templates" [VELD1995]_, a technique originally developed by for
|
||||
optimization of high-performance matrix algebra expressions. The
|
||||
essence is that instead of performing the computation immediately,
|
||||
operators are overloaded to construct a type *representing* the
|
||||
computation. In matrix algebra, dramatic optimizations are often
|
||||
available when the structure of an entire expression can be taken into
|
||||
account, rather than processing each operation "greedily".
|
||||
Boost.Python uses the same technique to build an appropriate Python
|
||||
callable object based on an expression involving ``self``, which is
|
||||
then added to the class.
|
||||
|
||||
Inheritance
|
||||
===========
|
||||
|
||||
C++ inheritance relationships can be represented to Boost.Python by adding
|
||||
an optional ``bases<...>`` argument to the ``class_<...>`` template
|
||||
parameter list as follows::
|
||||
|
||||
class_<Derived, bases<Base1,Base2> >("Derived")
|
||||
...
|
||||
|
||||
This has two effects:
|
||||
|
||||
1. When the ``class_<...>`` is created, Python type objects
|
||||
corresponding to ``Base1`` and ``Base2`` are looked up in the BPL
|
||||
registry, and are used as bases for the new Python ``Derived`` type
|
||||
object [#mi]_, so methods exposed for the Python ``Base1`` and
|
||||
``Base2`` types are automatically members of the ``Derived`` type.
|
||||
Because the registry is global, this works correctly even if
|
||||
``Derived`` is exposed in a different module from either of its
|
||||
bases.
|
||||
|
||||
2. C++ conversions from ``Derived`` to its bases are added to the
|
||||
Boost.Python registry. Thus wrapped C++ methods expecting (a
|
||||
pointer or reference to) an object of either base type can be
|
||||
called with an object wrapping a ``Derived`` instance. Wrapped
|
||||
member functions of class ``T`` are treated as though they have an
|
||||
implicit first argument of ``T&``, so these conversions are
|
||||
necessary to allow the base class methods to be called for derived
|
||||
objects.
|
||||
|
||||
Of course it's possible to derive new Python classes from wrapped C++
|
||||
class instances. Because Boost.Python uses the new-style class
|
||||
system, that works very much as for the Python built-in types. There
|
||||
is one significant detail in which it differs: the built-in types
|
||||
generally establish their invariants in their ``__new__`` function, so
|
||||
that derived classes do not need to call ``__init__`` on the base
|
||||
class before invoking its methods :
|
||||
|
||||
>>> class L(list):
|
||||
... def __init__(self):
|
||||
... pass
|
||||
...
|
||||
>>> L().reverse()
|
||||
>>>
|
||||
|
||||
Because C++ object construction is a one-step operation, C++ instance
|
||||
data cannot be constructed until the arguments are available, in the
|
||||
``__init__`` function:
|
||||
|
||||
>>> class D(SomeBPLClass):
|
||||
... def __init__(self):
|
||||
... pass
|
||||
...
|
||||
>>> D().some_bpl_method()
|
||||
Traceback (most recent call last):
|
||||
File "<stdin>", line 1, in ?
|
||||
TypeError: bad argument type for built-in operation
|
||||
|
||||
This happened because Boost.Python couldn't find instance data of type
|
||||
``SomeBPLClass`` within the ``D`` instance; ``D``'s ``__init__``
|
||||
function masked construction of the base class. It could be corrected
|
||||
by either removing ``D``'s ``__init__`` function or having it call
|
||||
``SomeBPLClass.__init__(...)`` explicitly.
|
||||
|
||||
Virtual Functions
|
||||
=================
|
||||
|
||||
Deriving new types in Python from extension classes is not very
|
||||
interesting unless they can be used polymorphically from C++. In
|
||||
other words, Python method implementations should appear to override
|
||||
the implementation of C++ virtual functions when called *through base
|
||||
class pointers/references from C++*. Since the only way to alter the
|
||||
behavior of a virtual function is to override it in a derived class,
|
||||
the user must build a special derived class to dispatch a polymorphic
|
||||
class' virtual functions::
|
||||
|
||||
//
|
||||
// interface to wrap:
|
||||
//
|
||||
class Base
|
||||
{
|
||||
public:
|
||||
virtual int f(std::string x) { return 42; }
|
||||
virtual ~Base();
|
||||
};
|
||||
|
||||
int calls_f(Base const& b, std::string x) { return b.f(x); }
|
||||
|
||||
//
|
||||
// Wrapping Code
|
||||
//
|
||||
|
||||
// Dispatcher class
|
||||
struct BaseWrap : Base
|
||||
{
|
||||
// Store a pointer to the Python object
|
||||
BaseWrap(PyObject* self_) : self(self_) {}
|
||||
PyObject* self;
|
||||
|
||||
// Default implementation, for when f is not overridden
|
||||
int f_default(std::string x) { return this->Base::f(x); }
|
||||
// Dispatch implementation
|
||||
int f(std::string x) { return call_method<int>(self, "f", x); }
|
||||
};
|
||||
|
||||
...
|
||||
def("calls_f", calls_f);
|
||||
class_<Base, BaseWrap>("Base")
|
||||
.def("f", &Base::f, &BaseWrap::f_default)
|
||||
;
|
||||
|
||||
Now here's some Python code which demonstrates:
|
||||
|
||||
>>> class Derived(Base):
|
||||
... def f(self, s):
|
||||
... return len(s)
|
||||
...
|
||||
>>> calls_f(Base(), 'foo')
|
||||
42
|
||||
>>> calls_f(Derived(), 'forty-two')
|
||||
9
|
||||
|
||||
Things to notice about the dispatcher class:
|
||||
|
||||
* The key element which allows overriding in Python is the
|
||||
``call_method`` invocation, which uses the same global type
|
||||
conversion registry as the C++ function wrapping does to convert its
|
||||
arguments from C++ to Python and its return type from Python to C++.
|
||||
|
||||
* Any constructor signatures you wish to wrap must be replicated with
|
||||
an initial ``PyObject*`` argument
|
||||
|
||||
* The dispatcher must store this argument so that it can be used to
|
||||
invoke ``call_method``
|
||||
|
||||
* The ``f_default`` member function is needed when the function being
|
||||
exposed is not pure virtual; there's no other way ``Base::f`` can be
|
||||
called on an object of type ``BaseWrap``, since it overrides ``f``.
|
||||
|
||||
Admittedly, this formula is tedious to repeat, especially on a project
|
||||
with many polymorphic classes; that it is necessary reflects
|
||||
limitations in C++'s compile-time reflection capabilities. Several
|
||||
efforts are underway to write front-ends for Boost.Python which can
|
||||
generate these dispatchers (and other wrapping code) automatically.
|
||||
If these are successful it will mark a move away from wrapping
|
||||
everything directly in pure C++ for many of our users.
|
||||
|
||||
---------------
|
||||
Serialization
|
||||
---------------
|
||||
|
||||
*Serialization* is the process of converting objects in memory to a
|
||||
form that can be stored on disk or sent over a network connection. The
|
||||
serialized object (most often a plain string) can be retrieved and
|
||||
converted back to the original object. A good serialization system will
|
||||
automatically convert entire object hierarchies. Python's standard
|
||||
``pickle`` module is such a system. It leverages the language's strong
|
||||
runtime introspection facilities for serializing practically arbitrary
|
||||
user-defined objects. With a few simple and unintrusive provisions this
|
||||
powerful machinery can be extended to also work for wrapped C++ objects.
|
||||
Here is an example::
|
||||
|
||||
#include <string>
|
||||
|
||||
struct World
|
||||
{
|
||||
World(std::string a_msg) : msg(a_msg) {}
|
||||
std::string greet() const { return msg; }
|
||||
std::string msg;
|
||||
};
|
||||
|
||||
#include <boost/python.hpp>
|
||||
using namespace boost::python;
|
||||
|
||||
struct World_picklers : pickle_suite
|
||||
{
|
||||
static tuple
|
||||
getinitargs(World const& w) { return make_tuple(w.greet()); }
|
||||
};
|
||||
|
||||
BOOST_PYTHON_MODULE(hello)
|
||||
{
|
||||
class_<World>("World", init<std::string>())
|
||||
.def("greet", &World::greet)
|
||||
.def_pickle(World_picklers())
|
||||
;
|
||||
}
|
||||
|
||||
Now let's create a ``World`` object and put it to rest on disk::
|
||||
|
||||
>>> import hello
|
||||
>>> import pickle
|
||||
>>> a_world = hello.World("howdy")
|
||||
>>> pickle.dump(a_world, open("my_world", "w"))
|
||||
|
||||
In a potentially *different script* on a potentially *different
|
||||
computer* with a potentially *different operating system*::
|
||||
|
||||
>>> import pickle
|
||||
>>> resurrected_world = pickle.load(open("my_world", "r"))
|
||||
>>> resurrected_world.greet()
|
||||
'howdy'
|
||||
|
||||
Of course the ``cPickle`` module can also be used for faster
|
||||
processing.
|
||||
|
||||
Boost.Python's ``pickle_suite`` fully supports the ``pickle`` protocol
|
||||
defined in the standard Python documentation. There is a one-to-one
|
||||
correspondence between the standard pickling methods (``__getinitargs__``,
|
||||
``__getstate__``, ``__setstate__``) and the functions defined by the
|
||||
user in the class derived from ``pickle_suite`` (``getinitargs``,
|
||||
``getstate``, ``setstate``). The ``class_::def_pickle()`` member function
|
||||
is used to establish the Python bindings for all user-defined functions
|
||||
simultaneously. Correct signatures for these functions are enforced at
|
||||
compile time. Non-sensical combinations of the three pickle functions
|
||||
are also rejected at compile time. These measures are designed to
|
||||
help the user in avoiding obvious errors.
|
||||
|
||||
Enabling serialization of more complex C++ objects requires a little
|
||||
more work than is shown in the example above. Fortunately the
|
||||
``object`` interface (see next section) greatly helps in keeping the
|
||||
code manageable.
|
||||
|
||||
------------------
|
||||
Object interface
|
||||
------------------
|
||||
|
||||
Experienced extension module authors will be familiar with the 'C' view
|
||||
of Python objects, the ubiquitous ``PyObject*``. Most if not all Python
|
||||
'C' API functions involve ``PyObject*`` as arguments or return type. A
|
||||
major complication is the raw reference counting interface presented to
|
||||
the 'C' programmer. E.g. some API functions return *new references* and
|
||||
others return *borrowed references*. It is up to the extension module
|
||||
writer to properly increment and decrement reference counts. This
|
||||
quickly becomes cumbersome and error prone, especially if there are
|
||||
multiple execution paths.
|
||||
|
||||
Boost.Python provides a type ``object`` which is essentially a high
|
||||
level wrapper around ``PyObject*``. ``object`` automates reference
|
||||
counting as much as possible. It also provides the facilities for
|
||||
converting arbitrary C++ types to Python objects and vice versa.
|
||||
This significantly reduces the learning effort for prospective
|
||||
extension module writers.
|
||||
|
||||
Creating an ``object`` from any other type is extremely simple::
|
||||
|
||||
object o(3);
|
||||
|
||||
``object`` has templated interactions with all other types, with
|
||||
automatic to-python conversions. It happens so naturally that it's
|
||||
easily overlooked.
|
||||
|
||||
The ``extract<T>`` class template can be used to convert Python objects
|
||||
to C++ types::
|
||||
|
||||
double x = extract<double>(o);
|
||||
|
||||
All registered user-defined conversions are automatically accessible
|
||||
through the ``object`` interface. With reference to the ``World`` class
|
||||
defined in previous examples::
|
||||
|
||||
object as_python_object(World("howdy"));
|
||||
World back_as_c_plus_plus_object = extract<World>(as_python_object);
|
||||
|
||||
If a C++ type cannot be converted to a Python object an appropriate
|
||||
exception is thrown at runtime. Similarly, an appropriate exception is
|
||||
thrown if a C++ type cannot be extracted from a Python object.
|
||||
``extract<T>`` provides facilities for avoiding exceptions if this is
|
||||
desired.
|
||||
|
||||
The ``object::attr()`` member function is available for accessing
|
||||
and manipulating attributes of Python objects. For example::
|
||||
|
||||
object planet(World());
|
||||
planet.attr("set")("howdy");
|
||||
|
||||
``planet.attr("set")`` returns a callable ``object``. ``"howdy"`` is
|
||||
converted to a Python string object which is then passed as an argument
|
||||
to the ``set`` method.
|
||||
|
||||
The ``object`` type is accompanied by a set of derived types
|
||||
that mirror the Python built-in types such as ``list``, ``dict``,
|
||||
``tuple``, etc. as much as possible. This enables convenient
|
||||
manipulation of these high-level types from C++::
|
||||
|
||||
dict d;
|
||||
d["some"] = "thing";
|
||||
d["lucky_number"] = 13;
|
||||
list l = d.keys();
|
||||
|
||||
This almost looks and works like regular Python code, but it is pure C++.
|
||||
|
||||
=================
|
||||
Thinking hybrid
|
||||
=================
|
||||
|
||||
For many applications runtime performance considerations are very
|
||||
important. This is particularly true for most scientific applications.
|
||||
Often the performance considerations dictate the use of a compiled
|
||||
language for the core algorithms. Traditionally the decision to use a
|
||||
particular programming language is an exclusive one. Because of the
|
||||
practical and mental difficulties of combining different languages many
|
||||
systems are written in just one language. This is quite unfortunate
|
||||
because the price payed for runtime performance is typically a
|
||||
significant overhead due to static typing. For example, our experience
|
||||
shows that developing maintainable C++ code is typically much more
|
||||
time-consuming and requires much more hard-earned working experience
|
||||
than developing useful Python code. A related observation is that many
|
||||
compiled packages are augmented by some type of rudimentary scripting
|
||||
layer. These ad hoc solutions clearly show that many times a compiled
|
||||
language alone does not get the job done. On the other hand it is also
|
||||
clear that a pure Python implementation is too slow for numerically
|
||||
intensive production code.
|
||||
|
||||
Boost.Python enables us to *think hybrid* when developing new
|
||||
applications. Python can be used for rapidly prototyping a
|
||||
new application. Python's ease of use and the large pool of standard
|
||||
libraries give us a head start on the way to a first working system. If
|
||||
necessary, the working procedure can be used to discover the
|
||||
rate-limiting algorithms. To maximize performance these can be
|
||||
reimplemented in C++, together with the Boost.Python bindings needed to
|
||||
tie them back into the existing higher-level procedure.
|
||||
|
||||
Of course, this *top-down* approach is less attractive if it is clear
|
||||
from the start that many algorithms will eventually have to be
|
||||
implemented in a compiled language. Fortunately Boost.Python also
|
||||
enables us to pursue a *bottom-up* approach. We have used this approach
|
||||
very successfully in the development of a toolbox for scientific
|
||||
applications (scitbx) that we will describe elsewhere. The toolbox
|
||||
started out mainly as a library of C++ classes with Boost.Python
|
||||
bindings, and for a while the growth was mainly concentrated on the C++
|
||||
parts. However, as the toolbox is becoming more complete, more and more
|
||||
newly added functionality can be implemented in Python. We expect this
|
||||
trend to continue, as illustrated qualitatively in this figure:
|
||||
|
||||
.. image:: python_cpp_mix.png
|
||||
|
||||
This figure shows the ratio of newly added C++ and Python code over
|
||||
time as new algorithms are implemented. We expect this ratio to level
|
||||
out near 70% Python. The increasing ability to solve new problems
|
||||
mostly with the easy-to-use Python language rather than a necessarily
|
||||
more arcane statically typed language is the return on the investment
|
||||
of learning how to use Boost.Python. The ability to solve some problems
|
||||
entirely using only Python will enable a larger group of people to
|
||||
participate in the rapid development of new applications.
|
||||
|
||||
=============
|
||||
Conclusions
|
||||
=============
|
||||
|
||||
The examples in this paper illustrate that Boost.Python enables
|
||||
seamless interoperability between C++ and Python. Importantly, this is
|
||||
achieved without introducing a third syntax: the Python/C++ interface
|
||||
definitions are written in pure C++. This avoids any problems with
|
||||
parsing the C++ code to be interfaced to Python, yet the interface
|
||||
definitions are concise and maintainable. Freed from most of the
|
||||
development-time penalties of crossing a language boundary, software
|
||||
designers can take full advantage of two rich and complimentary
|
||||
language environments. In practice it turns out that some things are
|
||||
very difficult to do with pure Python/C (e.g. an efficient array
|
||||
library with an intuitive interface in the compiled language) and
|
||||
others are very difficult to do with pure C++ (e.g. serialization).
|
||||
If one has the luxury of being able to design a software system as a
|
||||
hybrid system from the ground up there are many new ways of avoiding
|
||||
road blocks in one language or the other.
|
||||
|
||||
.. I'm not ready to give up on all of this quite yet
|
||||
|
||||
.. Perhaps one day we'll have a language with the simplicity and
|
||||
expressive power of Python and the compile-time muscle of C++. Being
|
||||
able to take advantage of all of these facilities without paying the
|
||||
mental and development-time penalties of crossing a language barrier
|
||||
would bring enormous benefits. Until then, interoperability tools
|
||||
like Boost.Python can help lower the barrier and make the benefits of
|
||||
both languages more accessible to both communities.
|
||||
|
||||
===========
|
||||
Footnotes
|
||||
===========
|
||||
|
||||
.. [#mi] For hard-core new-style class/extension module writers it is
|
||||
worth noting that the normal requirement that all extension classes
|
||||
with data form a layout-compatible single-inheritance chain is
|
||||
lifted for Boost.Python extension classes. Clearly, either
|
||||
``Base1`` or ``Base2`` has to occupy a different offset in the
|
||||
``Derived`` class instance. This is possible because the wrapped
|
||||
part of BPL extension class instances is never assumed to have a
|
||||
fixed offset within the wrapper.
|
||||
|
||||
===========
|
||||
Citations
|
||||
===========
|
||||
|
||||
.. [VELD1995] T. Veldhuizen, "Expression Templates," C++ Report,
|
||||
Vol. 7 No. 5 June 1995, pp. 26-31.
|
||||
http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html
|
||||
190
doc/PyConDC_2003/default.css
Normal file
@@ -0,0 +1,190 @@
|
||||
/*
|
||||
:Author: David Goodger
|
||||
:Contact: goodger@users.sourceforge.net
|
||||
:date: $Date$
|
||||
:version: $Revision$
|
||||
:copyright: This stylesheet has been placed in the public domain.
|
||||
|
||||
boostinspect:nolicense
|
||||
|
||||
Default cascading style sheet for the HTML output of Docutils.
|
||||
*/
|
||||
|
||||
.first {
|
||||
margin-top: 0 }
|
||||
|
||||
.last {
|
||||
margin-bottom: 0 }
|
||||
|
||||
a.toc-backref {
|
||||
text-decoration: none ;
|
||||
color: black }
|
||||
|
||||
dd {
|
||||
margin-bottom: 0.5em }
|
||||
|
||||
div.abstract {
|
||||
margin: 2em 5em }
|
||||
|
||||
div.abstract p.topic-title {
|
||||
font-weight: bold ;
|
||||
text-align: center }
|
||||
|
||||
div.attention, div.caution, div.danger, div.error, div.hint,
|
||||
div.important, div.note, div.tip, div.warning {
|
||||
margin: 2em ;
|
||||
border: medium outset ;
|
||||
padding: 1em }
|
||||
|
||||
div.attention p.admonition-title, div.caution p.admonition-title,
|
||||
div.danger p.admonition-title, div.error p.admonition-title,
|
||||
div.warning p.admonition-title {
|
||||
color: red ;
|
||||
font-weight: bold ;
|
||||
font-family: sans-serif }
|
||||
|
||||
div.hint p.admonition-title, div.important p.admonition-title,
|
||||
div.note p.admonition-title, div.tip p.admonition-title {
|
||||
font-weight: bold ;
|
||||
font-family: sans-serif }
|
||||
|
||||
div.dedication {
|
||||
margin: 2em 5em ;
|
||||
text-align: center ;
|
||||
font-style: italic }
|
||||
|
||||
div.dedication p.topic-title {
|
||||
font-weight: bold ;
|
||||
font-style: normal }
|
||||
|
||||
div.figure {
|
||||
margin-left: 2em }
|
||||
|
||||
div.footer, div.header {
|
||||
font-size: smaller }
|
||||
|
||||
div.system-messages {
|
||||
margin: 5em }
|
||||
|
||||
div.system-messages h1 {
|
||||
color: red }
|
||||
|
||||
div.system-message {
|
||||
border: medium outset ;
|
||||
padding: 1em }
|
||||
|
||||
div.system-message p.system-message-title {
|
||||
color: red ;
|
||||
font-weight: bold }
|
||||
|
||||
div.topic {
|
||||
margin: 2em }
|
||||
|
||||
h1.title {
|
||||
text-align: center }
|
||||
|
||||
h2.subtitle {
|
||||
text-align: center }
|
||||
|
||||
hr {
|
||||
width: 75% }
|
||||
|
||||
ol.simple, ul.simple {
|
||||
margin-bottom: 1em }
|
||||
|
||||
ol.arabic {
|
||||
list-style: decimal }
|
||||
|
||||
ol.loweralpha {
|
||||
list-style: lower-alpha }
|
||||
|
||||
ol.upperalpha {
|
||||
list-style: upper-alpha }
|
||||
|
||||
ol.lowerroman {
|
||||
list-style: lower-roman }
|
||||
|
||||
ol.upperroman {
|
||||
list-style: upper-roman }
|
||||
|
||||
p.caption {
|
||||
font-style: italic }
|
||||
|
||||
p.credits {
|
||||
font-style: italic ;
|
||||
font-size: smaller }
|
||||
|
||||
p.label {
|
||||
white-space: nowrap }
|
||||
|
||||
p.topic-title {
|
||||
font-weight: bold }
|
||||
|
||||
pre.address {
|
||||
margin-bottom: 0 ;
|
||||
margin-top: 0 ;
|
||||
font-family: serif ;
|
||||
font-size: 100% }
|
||||
|
||||
pre.line-block {
|
||||
font-family: serif ;
|
||||
font-size: 100% }
|
||||
|
||||
pre.literal-block, pre.doctest-block {
|
||||
margin-left: 2em ;
|
||||
margin-right: 2em ;
|
||||
background-color: #eeeeee }
|
||||
|
||||
span.classifier {
|
||||
font-family: sans-serif ;
|
||||
font-style: oblique }
|
||||
|
||||
span.classifier-delimiter {
|
||||
font-family: sans-serif ;
|
||||
font-weight: bold }
|
||||
|
||||
span.interpreted {
|
||||
font-family: sans-serif }
|
||||
|
||||
span.option-argument {
|
||||
font-style: italic }
|
||||
|
||||
span.pre {
|
||||
white-space: pre }
|
||||
|
||||
span.problematic {
|
||||
color: red }
|
||||
|
||||
table {
|
||||
margin-top: 0.5em ;
|
||||
margin-bottom: 0.5em }
|
||||
|
||||
table.citation {
|
||||
border-left: solid thin gray ;
|
||||
padding-left: 0.5ex }
|
||||
|
||||
table.docinfo {
|
||||
margin: 2em 4em }
|
||||
|
||||
table.footnote {
|
||||
border-left: solid thin black ;
|
||||
padding-left: 0.5ex }
|
||||
|
||||
td, th {
|
||||
padding-left: 0.5em ;
|
||||
padding-right: 0.5em ;
|
||||
vertical-align: top }
|
||||
|
||||
th.docinfo-name, th.field-name {
|
||||
font-weight: bold ;
|
||||
text-align: left ;
|
||||
white-space: nowrap }
|
||||
|
||||
h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
|
||||
font-size: 100% }
|
||||
|
||||
tt {
|
||||
background-color: #eeeeee }
|
||||
|
||||
ul.auto-toc {
|
||||
list-style-type: none }
|
||||
BIN
doc/PyConDC_2003/python_cpp_mix.jpg
Executable file
|
After Width: | Height: | Size: 22 KiB |
|
Before Width: | Height: | Size: 6.1 KiB After Width: | Height: | Size: 6.1 KiB |
947
doc/article.rst
@@ -1,947 +0,0 @@
|
||||
+++++++++++++++++++++++++++++++++++++++++++
|
||||
Building Hybrid Systems with Boost.Python
|
||||
+++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
:Author: David Abrahams
|
||||
:Contact: dave@boost-consulting.com
|
||||
:organization: `Boost Consulting`_
|
||||
:date: 2003-05-14
|
||||
|
||||
:Author: Ralf W. Grosse-Kunstleve
|
||||
|
||||
:copyright: Copyright David Abrahams and Ralf W. Grosse-Kunstleve 2003. All rights reserved
|
||||
|
||||
.. contents:: Table of Contents
|
||||
|
||||
.. _`Boost Consulting`: http://www.boost-consulting.com
|
||||
|
||||
==========
|
||||
Abstract
|
||||
==========
|
||||
|
||||
Boost.Python is an open source C++ library which provides a concise
|
||||
IDL-like interface for binding C++ classes and functions to
|
||||
Python. Leveraging the full power of C++ compile-time introspection
|
||||
and of recently developed metaprogramming techniques, this is achieved
|
||||
entirely in pure C++, without introducing a new syntax.
|
||||
Boost.Python's rich set of features and high-level interface make it
|
||||
possible to engineer packages from the ground up as hybrid systems,
|
||||
giving programmers easy and coherent access to both the efficient
|
||||
compile-time polymorphism of C++ and the extremely convenient run-time
|
||||
polymorphism of Python.
|
||||
|
||||
==============
|
||||
Introduction
|
||||
==============
|
||||
|
||||
Python and C++ are in many ways as different as two languages could
|
||||
be: while C++ is usually compiled to machine-code, Python is
|
||||
interpreted. Python's dynamic type system is often cited as the
|
||||
foundation of its flexibility, while in C++ static typing is the
|
||||
cornerstone of its efficiency. C++ has an intricate and difficult
|
||||
compile-time meta-language, while in Python, practically everything
|
||||
happens at runtime.
|
||||
|
||||
Yet for many programmers, these very differences mean that Python and
|
||||
C++ complement one another perfectly. Performance bottlenecks in
|
||||
Python programs can be rewritten in C++ for maximal speed, and
|
||||
authors of powerful C++ libraries choose Python as a middleware
|
||||
language for its flexible system integration capabilities.
|
||||
Furthermore, the surface differences mask some strong similarities:
|
||||
|
||||
* 'C'-family control structures (if, while, for...)
|
||||
|
||||
* Support for object-orientation, functional programming, and generic
|
||||
programming (these are both *multi-paradigm* programming languages.)
|
||||
|
||||
* Comprehensive operator overloading facilities, recognizing the
|
||||
importance of syntactic variability for readability and
|
||||
expressivity.
|
||||
|
||||
* High-level concepts such as collections and iterators.
|
||||
|
||||
* High-level encapsulation facilities (C++: namespaces, Python: modules)
|
||||
to support the design of re-usable libraries.
|
||||
|
||||
* Exception-handling for effective management of error conditions.
|
||||
|
||||
* C++ idioms in common use, such as handle/body classes and
|
||||
reference-counted smart pointers mirror Python reference semantics.
|
||||
|
||||
Given Python's rich 'C' interoperability API, it should in principle
|
||||
be possible to expose C++ type and function interfaces to Python with
|
||||
an analogous interface to their C++ counterparts. However, the
|
||||
facilities provided by Python alone for integration with C++ are
|
||||
relatively meager. Compared to C++ and Python, 'C' has only very
|
||||
rudimentary abstraction facilities, and support for exception-handling
|
||||
is completely missing. 'C' extension module writers are required to
|
||||
manually manage Python reference counts, which is both annoyingly
|
||||
tedious and extremely error-prone. Traditional extension modules also
|
||||
tend to contain a great deal of boilerplate code repetition which
|
||||
makes them difficult to maintain, especially when wrapping an evolving
|
||||
API.
|
||||
|
||||
These limitations have lead to the development of a variety of wrapping
|
||||
systems. SWIG_ is probably the most popular package for the
|
||||
integration of C/C++ and Python. A more recent development is SIP_,
|
||||
which was specifically designed for interfacing Python with the Qt_
|
||||
graphical user interface library. Both SWIG and SIP introduce their
|
||||
own specialized languages for customizing inter-language bindings.
|
||||
This has certain advantages, but having to deal with three different
|
||||
languages (Python, C/C++ and the interface language) also introduces
|
||||
practical and mental difficulties. The CXX_ package demonstrates an
|
||||
interesting alternative. It shows that at least some parts of
|
||||
Python's 'C' API can be wrapped and presented through a much more
|
||||
user-friendly C++ interface. However, unlike SWIG and SIP, CXX does
|
||||
not include support for wrapping C++ classes as new Python types.
|
||||
|
||||
The features and goals of Boost.Python_ overlap significantly with
|
||||
many of these other systems. That said, Boost.Python attempts to
|
||||
maximize convenience and flexibility without introducing a separate
|
||||
wrapping language. Instead, it presents the user with a high-level
|
||||
C++ interface for wrapping C++ classes and functions, managing much of
|
||||
the complexity behind-the-scenes with static metaprogramming.
|
||||
Boost.Python also goes beyond the scope of earlier systems by
|
||||
providing:
|
||||
|
||||
* Support for C++ virtual functions that can be overridden in Python.
|
||||
|
||||
* Comprehensive lifetime management facilities for low-level C++
|
||||
pointers and references.
|
||||
|
||||
* Support for organizing extensions as Python packages,
|
||||
with a central registry for inter-language type conversions.
|
||||
|
||||
* A safe and convenient mechanism for tying into Python's powerful
|
||||
serialization engine (pickle).
|
||||
|
||||
* Coherence with the rules for handling C++ lvalues and rvalues that
|
||||
can only come from a deep understanding of both the Python and C++
|
||||
type systems.
|
||||
|
||||
The key insight that sparked the development of Boost.Python is that
|
||||
much of the boilerplate code in traditional extension modules could be
|
||||
eliminated using C++ compile-time introspection. Each argument of a
|
||||
wrapped C++ function must be extracted from a Python object using a
|
||||
procedure that depends on the argument type. Similarly the function's
|
||||
return type determines how the return value will be converted from C++
|
||||
to Python. Of course argument and return types are part of each
|
||||
function's type, and this is exactly the source from which
|
||||
Boost.Python deduces most of the information required.
|
||||
|
||||
This approach leads to *user guided wrapping*: as much information is
|
||||
extracted directly from the source code to be wrapped as is possible
|
||||
within the framework of pure C++, and some additional information is
|
||||
supplied explicitly by the user. Mostly the guidance is mechanical
|
||||
and little real intervention is required. Because the interface
|
||||
specification is written in the same full-featured language as the
|
||||
code being exposed, the user has unprecedented power available when
|
||||
she does need to take control.
|
||||
|
||||
.. _Python: http://www.python.org/
|
||||
.. _SWIG: http://www.swig.org/
|
||||
.. _SIP: http://www.riverbankcomputing.co.uk/sip/index.php
|
||||
.. _Qt: http://www.trolltech.com/
|
||||
.. _CXX: http://cxx.sourceforge.net/
|
||||
.. _Boost.Python: http://www.boost.org/libs/python/doc
|
||||
|
||||
===========================
|
||||
Boost.Python Design Goals
|
||||
===========================
|
||||
|
||||
The primary goal of Boost.Python is to allow users to expose C++
|
||||
classes and functions to Python using nothing more than a C++
|
||||
compiler. In broad strokes, the user experience should be one of
|
||||
directly manipulating C++ objects from Python.
|
||||
|
||||
However, it's also important not to translate all interfaces *too*
|
||||
literally: the idioms of each language must be respected. For
|
||||
example, though C++ and Python both have an iterator concept, they are
|
||||
expressed very differently. Boost.Python has to be able to bridge the
|
||||
interface gap.
|
||||
|
||||
It must be possible to insulate Python users from crashes resulting
|
||||
from trivial misuses of C++ interfaces, such as accessing
|
||||
already-deleted objects. By the same token the library should
|
||||
insulate C++ users from low-level Python 'C' API, replacing
|
||||
error-prone 'C' interfaces like manual reference-count management and
|
||||
raw ``PyObject`` pointers with more-robust alternatives.
|
||||
|
||||
Support for component-based development is crucial, so that C++ types
|
||||
exposed in one extension module can be passed to functions exposed in
|
||||
another without loss of crucial information like C++ inheritance
|
||||
relationships.
|
||||
|
||||
Finally, all wrapping must be *non-intrusive*, without modifying or
|
||||
even seeing the original C++ source code. Existing C++ libraries have
|
||||
to be wrappable by third parties who only have access to header files
|
||||
and binaries.
|
||||
|
||||
==========================
|
||||
Hello Boost.Python World
|
||||
==========================
|
||||
|
||||
And now for a preview of Boost.Python, and how it improves on the raw
|
||||
facilities offered by Python. Here's a function we might want to
|
||||
expose::
|
||||
|
||||
char const* greet(unsigned x)
|
||||
{
|
||||
static char const* const msgs[] = { "hello", "Boost.Python", "world!" };
|
||||
|
||||
if (x > 2)
|
||||
throw std::range_error("greet: index out of range");
|
||||
|
||||
return msgs[x];
|
||||
}
|
||||
|
||||
To wrap this function in standard C++ using the Python 'C' API, we'd
|
||||
need something like this::
|
||||
|
||||
extern "C" // all Python interactions use 'C' linkage and calling convention
|
||||
{
|
||||
// Wrapper to handle argument/result conversion and checking
|
||||
PyObject* greet_wrap(PyObject* args, PyObject * keywords)
|
||||
{
|
||||
int x;
|
||||
if (PyArg_ParseTuple(args, "i", &x)) // extract/check arguments
|
||||
{
|
||||
char const* result = greet(x); // invoke wrapped function
|
||||
return PyString_FromString(result); // convert result to Python
|
||||
}
|
||||
return 0; // error occurred
|
||||
}
|
||||
|
||||
// Table of wrapped functions to be exposed by the module
|
||||
static PyMethodDef methods[] = {
|
||||
{ "greet", greet_wrap, METH_VARARGS, "return one of 3 parts of a greeting" }
|
||||
, { NULL, NULL, 0, NULL } // sentinel
|
||||
};
|
||||
|
||||
// module initialization function
|
||||
DL_EXPORT init_hello()
|
||||
{
|
||||
(void) Py_InitModule("hello", methods); // add the methods to the module
|
||||
}
|
||||
}
|
||||
|
||||
Now here's the wrapping code we'd use to expose it with Boost.Python::
|
||||
|
||||
#include <boost/python.hpp>
|
||||
using namespace boost::python;
|
||||
BOOST_PYTHON_MODULE(hello)
|
||||
{
|
||||
def("greet", greet, "return one of 3 parts of a greeting");
|
||||
}
|
||||
|
||||
and here it is in action::
|
||||
|
||||
>>> import hello
|
||||
>>> for x in range(3):
|
||||
... print hello.greet(x)
|
||||
...
|
||||
hello
|
||||
Boost.Python
|
||||
world!
|
||||
|
||||
Aside from the fact that the 'C' API version is much more verbose,
|
||||
it's worth noting a few things that it doesn't handle correctly:
|
||||
|
||||
* The original function accepts an unsigned integer, and the Python
|
||||
'C' API only gives us a way of extracting signed integers. The
|
||||
Boost.Python version will raise a Python exception if we try to pass
|
||||
a negative number to ``hello.greet``, but the other one will proceed
|
||||
to do whatever the C++ implementation does when converting an
|
||||
negative integer to unsigned (usually wrapping to some very large
|
||||
number), and pass the incorrect translation on to the wrapped
|
||||
function.
|
||||
|
||||
* That brings us to the second problem: if the C++ ``greet()``
|
||||
function is called with a number greater than 2, it will throw an
|
||||
exception. Typically, if a C++ exception propagates across the
|
||||
boundary with code generated by a 'C' compiler, it will cause a
|
||||
crash. As you can see in the first version, there's no C++
|
||||
scaffolding there to prevent this from happening. Functions wrapped
|
||||
by Boost.Python automatically include an exception-handling layer
|
||||
which protects Python users by translating unhandled C++ exceptions
|
||||
into a corresponding Python exception.
|
||||
|
||||
* A slightly more-subtle limitation is that the argument conversion
|
||||
used in the Python 'C' API case can only get that integer ``x`` in
|
||||
*one way*. PyArg_ParseTuple can't convert Python ``long`` objects
|
||||
(arbitrary-precision integers) which happen to fit in an ``unsigned
|
||||
int`` but not in a ``signed long``, nor will it ever handle a
|
||||
wrapped C++ class with a user-defined implicit ``operator unsigned
|
||||
int()`` conversion. Boost.Python's dynamic type conversion
|
||||
registry allows users to add arbitrary conversion methods.
|
||||
|
||||
==================
|
||||
Library Overview
|
||||
==================
|
||||
|
||||
This section outlines some of the library's major features. Except as
|
||||
neccessary to avoid confusion, details of library implementation are
|
||||
omitted.
|
||||
|
||||
------------------
|
||||
Exposing Classes
|
||||
------------------
|
||||
|
||||
C++ classes and structs are exposed with a similarly-terse interface.
|
||||
Given::
|
||||
|
||||
struct World
|
||||
{
|
||||
void set(std::string msg) { this->msg = msg; }
|
||||
std::string greet() { return msg; }
|
||||
std::string msg;
|
||||
};
|
||||
|
||||
The following code will expose it in our extension module::
|
||||
|
||||
#include <boost/python.hpp>
|
||||
BOOST_PYTHON_MODULE(hello)
|
||||
{
|
||||
class_<World>("World")
|
||||
.def("greet", &World::greet)
|
||||
.def("set", &World::set)
|
||||
;
|
||||
}
|
||||
|
||||
Although this code has a certain pythonic familiarity, people
|
||||
sometimes find the syntax bit confusing because it doesn't look like
|
||||
most of the C++ code they're used to. All the same, this is just
|
||||
standard C++. Because of their flexible syntax and operator
|
||||
overloading, C++ and Python are great for defining domain-specific
|
||||
(sub)languages
|
||||
(DSLs), and that's what we've done in Boost.Python. To break it down::
|
||||
|
||||
class_<World>("World")
|
||||
|
||||
constructs an unnamed object of type ``class_<World>`` and passes
|
||||
``"World"`` to its constructor. This creates a new-style Python class
|
||||
called ``World`` in the extension module, and associates it with the
|
||||
C++ type ``World`` in the Boost.Python type conversion registry. We
|
||||
might have also written::
|
||||
|
||||
class_<World> w("World");
|
||||
|
||||
but that would've been more verbose, since we'd have to name ``w``
|
||||
again to invoke its ``def()`` member function::
|
||||
|
||||
w.def("greet", &World::greet)
|
||||
|
||||
There's nothing special about the location of the dot for member
|
||||
access in the original example: C++ allows any amount of whitespace on
|
||||
either side of a token, and placing the dot at the beginning of each
|
||||
line allows us to chain as many successive calls to member functions
|
||||
as we like with a uniform syntax. The other key fact that allows
|
||||
chaining is that ``class_<>`` member functions all return a reference
|
||||
to ``*this``.
|
||||
|
||||
So the example is equivalent to::
|
||||
|
||||
class_<World> w("World");
|
||||
w.def("greet", &World::greet);
|
||||
w.def("set", &World::set);
|
||||
|
||||
It's occasionally useful to be able to break down the components of a
|
||||
Boost.Python class wrapper in this way, but the rest of this article
|
||||
will stick to the terse syntax.
|
||||
|
||||
For completeness, here's the wrapped class in use: ::
|
||||
|
||||
>>> import hello
|
||||
>>> planet = hello.World()
|
||||
>>> planet.set('howdy')
|
||||
>>> planet.greet()
|
||||
'howdy'
|
||||
|
||||
Constructors
|
||||
============
|
||||
|
||||
Since our ``World`` class is just a plain ``struct``, it has an
|
||||
implicit no-argument (nullary) constructor. Boost.Python exposes the
|
||||
nullary constructor by default, which is why we were able to write: ::
|
||||
|
||||
>>> planet = hello.World()
|
||||
|
||||
However, well-designed classes in any language may require constructor
|
||||
arguments in order to establish their invariants. Unlike Python,
|
||||
where ``__init__`` is just a specially-named method, In C++
|
||||
constructors cannot be handled like ordinary member functions. In
|
||||
particular, we can't take their address: ``&World::World`` is an
|
||||
error. The library provides a different interface for specifying
|
||||
constructors. Given::
|
||||
|
||||
struct World
|
||||
{
|
||||
World(std::string msg); // added constructor
|
||||
...
|
||||
|
||||
we can modify our wrapping code as follows::
|
||||
|
||||
class_<World>("World", init<std::string>())
|
||||
...
|
||||
|
||||
of course, a C++ class may have additional constructors, and we can
|
||||
expose those as well by passing more instances of ``init<...>`` to
|
||||
``def()``::
|
||||
|
||||
class_<World>("World", init<std::string>())
|
||||
.def(init<double, double>())
|
||||
...
|
||||
|
||||
Boost.Python allows wrapped functions, member functions, and
|
||||
constructors to be overloaded to mirror C++ overloading.
|
||||
|
||||
Data Members and Properties
|
||||
===========================
|
||||
|
||||
Any publicly-accessible data members in a C++ class can be easily
|
||||
exposed as either ``readonly`` or ``readwrite`` attributes::
|
||||
|
||||
class_<World>("World", init<std::string>())
|
||||
.def_readonly("msg", &World::msg)
|
||||
...
|
||||
|
||||
and can be used directly in Python: ::
|
||||
|
||||
>>> planet = hello.World('howdy')
|
||||
>>> planet.msg
|
||||
'howdy'
|
||||
|
||||
This does *not* result in adding attributes to the ``World`` instance
|
||||
``__dict__``, which can result in substantial memory savings when
|
||||
wrapping large data structures. In fact, no instance ``__dict__``
|
||||
will be created at all unless attributes are explicitly added from
|
||||
Python. Boost.Python owes this capability to the new Python 2.2 type
|
||||
system, in particular the descriptor interface and ``property`` type.
|
||||
|
||||
In C++, publicly-accessible data members are considered a sign of poor
|
||||
design because they break encapsulation, and style guides usually
|
||||
dictate the use of "getter" and "setter" functions instead. In
|
||||
Python, however, ``__getattr__``, ``__setattr__``, and since 2.2,
|
||||
``property`` mean that attribute access is just one more
|
||||
well-encapsulated syntactic tool at the programmer's disposal.
|
||||
Boost.Python bridges this idiomatic gap by making Python ``property``
|
||||
creation directly available to users. If ``msg`` were private, we
|
||||
could still expose it as attribute in Python as follows::
|
||||
|
||||
class_<World>("World", init<std::string>())
|
||||
.add_property("msg", &World::greet, &World::set)
|
||||
...
|
||||
|
||||
The example above mirrors the familiar usage of properties in Python
|
||||
2.2+: ::
|
||||
|
||||
>>> class World(object):
|
||||
... __init__(self, msg):
|
||||
... self.__msg = msg
|
||||
... def greet(self):
|
||||
... return self.__msg
|
||||
... def set(self, msg):
|
||||
... self.__msg = msg
|
||||
... msg = property(greet, set)
|
||||
|
||||
Operator Overloading
|
||||
====================
|
||||
|
||||
The ability to write arithmetic operators for user-defined types has
|
||||
been a major factor in the success of both languages for numerical
|
||||
computation, and the success of packages like NumPy_ attests to the
|
||||
power of exposing operators in extension modules. Boost.Python
|
||||
provides a concise mechanism for wrapping operator overloads. The
|
||||
example below shows a fragment from a wrapper for the Boost rational
|
||||
number library::
|
||||
|
||||
class_<rational<int> >("rational_int")
|
||||
.def(init<int, int>()) // constructor, e.g. rational_int(3,4)
|
||||
.def("numerator", &rational<int>::numerator)
|
||||
.def("denominator", &rational<int>::denominator)
|
||||
.def(-self) // __neg__ (unary minus)
|
||||
.def(self + self) // __add__ (homogeneous)
|
||||
.def(self * self) // __mul__
|
||||
.def(self + int()) // __add__ (heterogenous)
|
||||
.def(int() + self) // __radd__
|
||||
...
|
||||
|
||||
The magic is performed using a simplified application of "expression
|
||||
templates" [VELD1995]_, a technique originally developed for
|
||||
optimization of high-performance matrix algebra expressions. The
|
||||
essence is that instead of performing the computation immediately,
|
||||
operators are overloaded to construct a type *representing* the
|
||||
computation. In matrix algebra, dramatic optimizations are often
|
||||
available when the structure of an entire expression can be taken into
|
||||
account, rather than evaluating each operation "greedily".
|
||||
Boost.Python uses the same technique to build an appropriate Python
|
||||
method object based on expressions involving ``self``.
|
||||
|
||||
.. _NumPy: http://www.pfdubois.com/numpy/
|
||||
|
||||
Inheritance
|
||||
===========
|
||||
|
||||
C++ inheritance relationships can be represented to Boost.Python by adding
|
||||
an optional ``bases<...>`` argument to the ``class_<...>`` template
|
||||
parameter list as follows::
|
||||
|
||||
class_<Derived, bases<Base1,Base2> >("Derived")
|
||||
...
|
||||
|
||||
This has two effects:
|
||||
|
||||
1. When the ``class_<...>`` is created, Python type objects
|
||||
corresponding to ``Base1`` and ``Base2`` are looked up in
|
||||
Boost.Python's registry, and are used as bases for the new Python
|
||||
``Derived`` type object, so methods exposed for the Python ``Base1``
|
||||
and ``Base2`` types are automatically members of the ``Derived``
|
||||
type. Because the registry is global, this works correctly even if
|
||||
``Derived`` is exposed in a different module from either of its
|
||||
bases.
|
||||
|
||||
2. C++ conversions from ``Derived`` to its bases are added to the
|
||||
Boost.Python registry. Thus wrapped C++ methods expecting (a
|
||||
pointer or reference to) an object of either base type can be
|
||||
called with an object wrapping a ``Derived`` instance. Wrapped
|
||||
member functions of class ``T`` are treated as though they have an
|
||||
implicit first argument of ``T&``, so these conversions are
|
||||
neccessary to allow the base class methods to be called for derived
|
||||
objects.
|
||||
|
||||
Of course it's possible to derive new Python classes from wrapped C++
|
||||
class instances. Because Boost.Python uses the new-style class
|
||||
system, that works very much as for the Python built-in types. There
|
||||
is one significant detail in which it differs: the built-in types
|
||||
generally establish their invariants in their ``__new__`` function, so
|
||||
that derived classes do not need to call ``__init__`` on the base
|
||||
class before invoking its methods : ::
|
||||
|
||||
>>> class L(list):
|
||||
... def __init__(self):
|
||||
... pass
|
||||
...
|
||||
>>> L().reverse()
|
||||
>>>
|
||||
|
||||
Because C++ object construction is a one-step operation, C++ instance
|
||||
data cannot be constructed until the arguments are available, in the
|
||||
``__init__`` function: ::
|
||||
|
||||
>>> class D(SomeBoostPythonClass):
|
||||
... def __init__(self):
|
||||
... pass
|
||||
...
|
||||
>>> D().some_boost_python_method()
|
||||
Traceback (most recent call last):
|
||||
File "<stdin>", line 1, in ?
|
||||
TypeError: bad argument type for built-in operation
|
||||
|
||||
This happened because Boost.Python couldn't find instance data of type
|
||||
``SomeBoostPythonClass`` within the ``D`` instance; ``D``'s ``__init__``
|
||||
function masked construction of the base class. It could be corrected
|
||||
by either removing ``D``'s ``__init__`` function or having it call
|
||||
``SomeBoostPythonClass.__init__(...)`` explicitly.
|
||||
|
||||
Virtual Functions
|
||||
=================
|
||||
|
||||
Deriving new types in Python from extension classes is not very
|
||||
interesting unless they can be used polymorphically from C++. In
|
||||
other words, Python method implementations should appear to override
|
||||
the implementation of C++ virtual functions when called *through base
|
||||
class pointers/references from C++*. Since the only way to alter the
|
||||
behavior of a virtual function is to override it in a derived class,
|
||||
the user must build a special derived class to dispatch a polymorphic
|
||||
class' virtual functions::
|
||||
|
||||
//
|
||||
// interface to wrap:
|
||||
//
|
||||
class Base
|
||||
{
|
||||
public:
|
||||
virtual int f(std::string x) { return 42; }
|
||||
virtual ~Base();
|
||||
};
|
||||
|
||||
int calls_f(Base const& b, std::string x) { return b.f(x); }
|
||||
|
||||
//
|
||||
// Wrapping Code
|
||||
//
|
||||
|
||||
// Dispatcher class
|
||||
struct BaseWrap : Base
|
||||
{
|
||||
// Store a pointer to the Python object
|
||||
BaseWrap(PyObject* self_) : self(self_) {}
|
||||
PyObject* self;
|
||||
|
||||
// Default implementation, for when f is not overridden
|
||||
int f_default(std::string x) { return this->Base::f(x); }
|
||||
// Dispatch implementation
|
||||
int f(std::string x) { return call_method<int>(self, "f", x); }
|
||||
};
|
||||
|
||||
...
|
||||
def("calls_f", calls_f);
|
||||
class_<Base, BaseWrap>("Base")
|
||||
.def("f", &Base::f, &BaseWrap::f_default)
|
||||
;
|
||||
|
||||
Now here's some Python code which demonstrates: ::
|
||||
|
||||
>>> class Derived(Base):
|
||||
... def f(self, s):
|
||||
... return len(s)
|
||||
...
|
||||
>>> calls_f(Base(), 'foo')
|
||||
42
|
||||
>>> calls_f(Derived(), 'forty-two')
|
||||
9
|
||||
|
||||
Things to notice about the dispatcher class:
|
||||
|
||||
* The key element which allows overriding in Python is the
|
||||
``call_method`` invocation, which uses the same global type
|
||||
conversion registry as the C++ function wrapping does to convert its
|
||||
arguments from C++ to Python and its return type from Python to C++.
|
||||
|
||||
* Any constructor signatures you wish to wrap must be replicated with
|
||||
an initial ``PyObject*`` argument
|
||||
|
||||
* The dispatcher must store this argument so that it can be used to
|
||||
invoke ``call_method``
|
||||
|
||||
* The ``f_default`` member function is needed when the function being
|
||||
exposed is not pure virtual; there's no other way ``Base::f`` can be
|
||||
called on an object of type ``BaseWrap``, since it overrides ``f``.
|
||||
|
||||
Deeper Reflection on the Horizon?
|
||||
=================================
|
||||
|
||||
Admittedly, this formula is tedious to repeat, especially on a project
|
||||
with many polymorphic classes. That it is neccessary reflects some
|
||||
limitations in C++'s compile-time introspection capabilities: there's
|
||||
no way to enumerate the members of a class and find out which are
|
||||
virtual functions. At least one very promising project has been
|
||||
started to write a front-end which can generate these dispatchers (and
|
||||
other wrapping code) automatically from C++ headers.
|
||||
|
||||
Pyste_ is being developed by Bruno da Silva de Oliveira. It builds on
|
||||
GCC_XML_, which generates an XML version of GCC's internal program
|
||||
representation. Since GCC is a highly-conformant C++ compiler, this
|
||||
ensures correct handling of the most-sophisticated template code and
|
||||
full access to the underlying type system. In keeping with the
|
||||
Boost.Python philosophy, a Pyste interface description is neither
|
||||
intrusive on the code being wrapped, nor expressed in some unfamiliar
|
||||
language: instead it is a 100% pure Python script. If Pyste is
|
||||
successful it will mark a move away from wrapping everything directly
|
||||
in C++ for many of our users. It will also allow us the choice to
|
||||
shift some of the metaprogram code from C++ to Python. We expect that
|
||||
soon, not only our users but the Boost.Python developers themselves
|
||||
will be "thinking hybrid" about their own code.
|
||||
|
||||
.. _`GCC_XML`: http://www.gccxml.org/HTML/Index.html
|
||||
.. _`Pyste`: http://www.boost.org/libs/python/pyste
|
||||
|
||||
---------------
|
||||
Serialization
|
||||
---------------
|
||||
|
||||
*Serialization* is the process of converting objects in memory to a
|
||||
form that can be stored on disk or sent over a network connection. The
|
||||
serialized object (most often a plain string) can be retrieved and
|
||||
converted back to the original object. A good serialization system will
|
||||
automatically convert entire object hierarchies. Python's standard
|
||||
``pickle`` module is just such a system. It leverages the language's strong
|
||||
runtime introspection facilities for serializing practically arbitrary
|
||||
user-defined objects. With a few simple and unintrusive provisions this
|
||||
powerful machinery can be extended to also work for wrapped C++ objects.
|
||||
Here is an example::
|
||||
|
||||
#include <string>
|
||||
|
||||
struct World
|
||||
{
|
||||
World(std::string a_msg) : msg(a_msg) {}
|
||||
std::string greet() const { return msg; }
|
||||
std::string msg;
|
||||
};
|
||||
|
||||
#include <boost/python.hpp>
|
||||
using namespace boost::python;
|
||||
|
||||
struct World_picklers : pickle_suite
|
||||
{
|
||||
static tuple
|
||||
getinitargs(World const& w) { return make_tuple(w.greet()); }
|
||||
};
|
||||
|
||||
BOOST_PYTHON_MODULE(hello)
|
||||
{
|
||||
class_<World>("World", init<std::string>())
|
||||
.def("greet", &World::greet)
|
||||
.def_pickle(World_picklers())
|
||||
;
|
||||
}
|
||||
|
||||
Now let's create a ``World`` object and put it to rest on disk::
|
||||
|
||||
>>> import hello
|
||||
>>> import pickle
|
||||
>>> a_world = hello.World("howdy")
|
||||
>>> pickle.dump(a_world, open("my_world", "w"))
|
||||
|
||||
In a potentially *different script* on a potentially *different
|
||||
computer* with a potentially *different operating system*::
|
||||
|
||||
>>> import pickle
|
||||
>>> resurrected_world = pickle.load(open("my_world", "r"))
|
||||
>>> resurrected_world.greet()
|
||||
'howdy'
|
||||
|
||||
Of course the ``cPickle`` module can also be used for faster
|
||||
processing.
|
||||
|
||||
Boost.Python's ``pickle_suite`` fully supports the ``pickle`` protocol
|
||||
defined in the standard Python documentation. Like a __getinitargs__
|
||||
function in Python, the pickle_suite's getinitargs() is responsible for
|
||||
creating the argument tuple that will be use to reconstruct the pickled
|
||||
object. The other elements of the Python pickling protocol,
|
||||
__getstate__ and __setstate__ can be optionally provided via C++
|
||||
getstate and setstate functions. C++'s static type system allows the
|
||||
library to ensure at compile-time that nonsensical combinations of
|
||||
functions (e.g. getstate without setstate) are not used.
|
||||
|
||||
Enabling serialization of more complex C++ objects requires a little
|
||||
more work than is shown in the example above. Fortunately the
|
||||
``object`` interface (see next section) greatly helps in keeping the
|
||||
code manageable.
|
||||
|
||||
------------------
|
||||
Object interface
|
||||
------------------
|
||||
|
||||
Experienced 'C' language extension module authors will be familiar
|
||||
with the ubiquitous ``PyObject*``, manual reference-counting, and the
|
||||
need to remember which API calls return "new" (owned) references or
|
||||
"borrowed" (raw) references. These constraints are not just
|
||||
cumbersome but also a major source of errors, especially in the
|
||||
presence of exceptions.
|
||||
|
||||
Boost.Python provides a class ``object`` which automates reference
|
||||
counting and provides conversion to Python from C++ objects of
|
||||
arbitrary type. This significantly reduces the learning effort for
|
||||
prospective extension module writers.
|
||||
|
||||
Creating an ``object`` from any other type is extremely simple::
|
||||
|
||||
object s("hello, world"); // s manages a Python string
|
||||
|
||||
``object`` has templated interactions with all other types, with
|
||||
automatic to-python conversions. It happens so naturally that it's
|
||||
easily overlooked::
|
||||
|
||||
object ten_Os = 10 * s[4]; // -> "oooooooooo"
|
||||
|
||||
In the example above, ``4`` and ``10`` are converted to Python objects
|
||||
before the indexing and multiplication operations are invoked.
|
||||
|
||||
The ``extract<T>`` class template can be used to convert Python objects
|
||||
to C++ types::
|
||||
|
||||
double x = extract<double>(o);
|
||||
|
||||
If a conversion in either direction cannot be performed, an
|
||||
appropriate exception is thrown at runtime.
|
||||
|
||||
The ``object`` type is accompanied by a set of derived types
|
||||
that mirror the Python built-in types such as ``list``, ``dict``,
|
||||
``tuple``, etc. as much as possible. This enables convenient
|
||||
manipulation of these high-level types from C++::
|
||||
|
||||
dict d;
|
||||
d["some"] = "thing";
|
||||
d["lucky_number"] = 13;
|
||||
list l = d.keys();
|
||||
|
||||
This almost looks and works like regular Python code, but it is pure
|
||||
C++. Of course we can wrap C++ functions which accept or return
|
||||
``object`` instances.
|
||||
|
||||
=================
|
||||
Thinking hybrid
|
||||
=================
|
||||
|
||||
Because of the practical and mental difficulties of combining
|
||||
programming languages, it is common to settle a single language at the
|
||||
outset of any development effort. For many applications, performance
|
||||
considerations dictate the use of a compiled language for the core
|
||||
algorithms. Unfortunately, due to the complexity of the static type
|
||||
system, the price we pay for runtime performance is often a
|
||||
significant increase in development time. Experience shows that
|
||||
writing maintainable C++ code usually takes longer and requires *far*
|
||||
more hard-earned working experience than developing comparable Python
|
||||
code. Even when developers are comfortable working exclusively in
|
||||
compiled languages, they often augment their systems by some type of
|
||||
ad hoc scripting layer for the benefit of their users without ever
|
||||
availing themselves of the same advantages.
|
||||
|
||||
Boost.Python enables us to *think hybrid*. Python can be used for
|
||||
rapidly prototyping a new application; its ease of use and the large
|
||||
pool of standard libraries give us a head start on the way to a
|
||||
working system. If necessary, the working code can be used to
|
||||
discover rate-limiting hotspots. To maximize performance these can
|
||||
be reimplemented in C++, together with the Boost.Python bindings
|
||||
needed to tie them back into the existing higher-level procedure.
|
||||
|
||||
Of course, this *top-down* approach is less attractive if it is clear
|
||||
from the start that many algorithms will eventually have to be
|
||||
implemented in C++. Fortunately Boost.Python also enables us to
|
||||
pursue a *bottom-up* approach. We have used this approach very
|
||||
successfully in the development of a toolbox for scientific
|
||||
applications. The toolbox started out mainly as a library of C++
|
||||
classes with Boost.Python bindings, and for a while the growth was
|
||||
mainly concentrated on the C++ parts. However, as the toolbox is
|
||||
becoming more complete, more and more newly added functionality can be
|
||||
implemented in Python.
|
||||
|
||||
.. image:: images/python_cpp_mix.png
|
||||
|
||||
This figure shows the estimated ratio of newly added C++ and Python
|
||||
code over time as new algorithms are implemented. We expect this
|
||||
ratio to level out near 70% Python. Being able to solve new problems
|
||||
mostly in Python rather than a more difficult statically typed
|
||||
language is the return on our investment in Boost.Python. The ability
|
||||
to access all of our code from Python allows a broader group of
|
||||
developers to use it in the rapid development of new applications.
|
||||
|
||||
=====================
|
||||
Development history
|
||||
=====================
|
||||
|
||||
The first version of Boost.Python was developed in 2000 by Dave
|
||||
Abrahams at Dragon Systems, where he was privileged to have Tim Peters
|
||||
as a guide to "The Zen of Python". One of Dave's jobs was to develop
|
||||
a Python-based natural language processing system. Since it was
|
||||
eventually going to be targeting embedded hardware, it was always
|
||||
assumed that the compute-intensive core would be rewritten in C++ to
|
||||
optimize speed and memory footprint [#proto]_. The project also wanted to
|
||||
test all of its C++ code using Python test scripts [#test]_. The only
|
||||
tool we knew of for binding C++ and Python was SWIG_, and at the time
|
||||
its handling of C++ was weak. It would be false to claim any deep
|
||||
insight into the possible advantages of Boost.Python's approach at
|
||||
this point. Dave's interest and expertise in fancy C++ template
|
||||
tricks had just reached the point where he could do some real damage,
|
||||
and Boost.Python emerged as it did because it filled a need and
|
||||
because it seemed like a cool thing to try.
|
||||
|
||||
This early version was aimed at many of the same basic goals we've
|
||||
described in this paper, differing most-noticeably by having a
|
||||
slightly more cumbersome syntax and by lack of special support for
|
||||
operator overloading, pickling, and component-based development.
|
||||
These last three features were quickly added by Ullrich Koethe and
|
||||
Ralf Grosse-Kunstleve [#feature]_, and other enthusiastic contributors arrived
|
||||
on the scene to contribute enhancements like support for nested
|
||||
modules and static member functions.
|
||||
|
||||
By early 2001 development had stabilized and few new features were
|
||||
being added, however a disturbing new fact came to light: Ralf had
|
||||
begun testing Boost.Python on pre-release versions of a compiler using
|
||||
the EDG_ front-end, and the mechanism at the core of Boost.Python
|
||||
responsible for handling conversions between Python and C++ types was
|
||||
failing to compile. As it turned out, we had been exploiting a very
|
||||
common bug in the implementation of all the C++ compilers we had
|
||||
tested. We knew that as C++ compilers rapidly became more
|
||||
standards-compliant, the library would begin failing on more
|
||||
platforms. Unfortunately, because the mechanism was so central to the
|
||||
functioning of the library, fixing the problem looked very difficult.
|
||||
|
||||
Fortunately, later that year Lawrence Berkeley and later Lawrence
|
||||
Livermore National labs contracted with `Boost Consulting`_ for support
|
||||
and development of Boost.Python, and there was a new opportunity to
|
||||
address fundamental issues and ensure a future for the library. A
|
||||
redesign effort began with the low level type conversion architecture,
|
||||
building in standards-compliance and support for component-based
|
||||
development (in contrast to version 1 where conversions had to be
|
||||
explicitly imported and exported across module boundaries). A new
|
||||
analysis of the relationship between the Python and C++ objects was
|
||||
done, resulting in more intuitive handling for C++ lvalues and
|
||||
rvalues.
|
||||
|
||||
The emergence of a powerful new type system in Python 2.2 made the
|
||||
choice of whether to maintain compatibility with Python 1.5.2 easy:
|
||||
the opportunity to throw away a great deal of elaborate code for
|
||||
emulating classic Python classes alone was too good to pass up. In
|
||||
addition, Python iterators and descriptors provided crucial and
|
||||
elegant tools for representing similar C++ constructs. The
|
||||
development of the generalized ``object`` interface allowed us to
|
||||
further shield C++ programmers from the dangers and syntactic burdens
|
||||
of the Python 'C' API. A great number of other features including C++
|
||||
exception translation, improved support for overloaded functions, and
|
||||
most significantly, CallPolicies for handling pointers and
|
||||
references, were added during this period.
|
||||
|
||||
In October 2002, version 2 of Boost.Python was released. Development
|
||||
since then has concentrated on improved support for C++ runtime
|
||||
polymorphism and smart pointers. Peter Dimov's ingenious
|
||||
``boost::shared_ptr`` design in particular has allowed us to give the
|
||||
hybrid developer a consistent interface for moving objects back and
|
||||
forth across the language barrier without loss of information. At
|
||||
first, we were concerned that the sophistication and complexity of the
|
||||
Boost.Python v2 implementation might discourage contributors, but the
|
||||
emergence of Pyste_ and several other significant feature
|
||||
contributions have laid those fears to rest. Daily questions on the
|
||||
Python C++-sig and a backlog of desired improvements show that the
|
||||
library is getting used. To us, the future looks bright.
|
||||
|
||||
.. _`EDG`: http://www.edg.com
|
||||
|
||||
=============
|
||||
Conclusions
|
||||
=============
|
||||
|
||||
Boost.Python achieves seamless interoperability between two rich and
|
||||
complimentary language environments. Because it leverages template
|
||||
metaprogramming to introspect about types and functions, the user
|
||||
never has to learn a third syntax: the interface definitions are
|
||||
written in concise and maintainable C++. Also, the wrapping system
|
||||
doesn't have to parse C++ headers or represent the type system: the
|
||||
compiler does that work for us.
|
||||
|
||||
Computationally intensive tasks play to the strengths of C++ and are
|
||||
often impossible to implement efficiently in pure Python, while jobs
|
||||
like serialization that are trivial in Python can be very difficult in
|
||||
pure C++. Given the luxury of building a hybrid software system from
|
||||
the ground up, we can approach design with new confidence and power.
|
||||
|
||||
===========
|
||||
Citations
|
||||
===========
|
||||
|
||||
.. [VELD1995] T. Veldhuizen, "Expression Templates," C++ Report,
|
||||
Vol. 7 No. 5 June 1995, pp. 26-31.
|
||||
http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html
|
||||
|
||||
===========
|
||||
Footnotes
|
||||
===========
|
||||
|
||||
.. [#proto] In retrospect, it seems that "thinking hybrid" from the
|
||||
ground up might have been better for the NLP system: the
|
||||
natural component boundaries defined by the pure python
|
||||
prototype turned out to be inappropriate for getting the
|
||||
desired performance and memory footprint out of the C++ core,
|
||||
which eventually caused some redesign overhead on the Python
|
||||
side when the core was moved to C++.
|
||||
|
||||
.. [#test] We also have some reservations about driving all C++
|
||||
testing through a Python interface, unless that's the only way
|
||||
it will be ultimately used. Any transition across language
|
||||
boundaries with such different object models can inevitably
|
||||
mask bugs.
|
||||
|
||||
.. [#feature] These features were expressed very differently in v1 of
|
||||
Boost.Python
|
||||
63
doc/boost.css
Normal file
@@ -0,0 +1,63 @@
|
||||
/* Copyright David Abrahams 2006. Distributed under the Boost
|
||||
Software License, Version 1.0. (See accompanying
|
||||
file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
|
||||
*/
|
||||
H1
|
||||
{
|
||||
FONT-SIZE: 200%
|
||||
COLOR: #00007f
|
||||
}
|
||||
H2
|
||||
{
|
||||
FONT-SIZE: 150%;
|
||||
}
|
||||
H3
|
||||
{
|
||||
FONT-SIZE: 125%;
|
||||
}
|
||||
H4
|
||||
{
|
||||
FONT-SIZE: 108%;
|
||||
}
|
||||
BODY
|
||||
{
|
||||
FONT-SIZE: 100%;
|
||||
BACKGROUND-COLOR: #ffffff
|
||||
}
|
||||
PRE
|
||||
{
|
||||
MARGIN-LEFT: 2pc;
|
||||
FONT-SIZE: 80%;
|
||||
BACKGROUND-COLOR: #dfffff
|
||||
}
|
||||
CODE
|
||||
{
|
||||
FONT-SIZE: 95%;
|
||||
white-space: pre
|
||||
}
|
||||
.index
|
||||
{
|
||||
TEXT-ALIGN: left
|
||||
}
|
||||
.page-index
|
||||
{
|
||||
TEXT-ALIGN: left
|
||||
}
|
||||
.definition
|
||||
{
|
||||
TEXT-ALIGN: left
|
||||
}
|
||||
.footnote
|
||||
{
|
||||
FONT-SIZE: 66%;
|
||||
VERTICAL-ALIGN: super;
|
||||
TEXT-DECORATION: none
|
||||
}
|
||||
.function-semantics
|
||||
{
|
||||
CLEAR: left
|
||||
}
|
||||
.metafunction-semantics
|
||||
{
|
||||
CLEAR: left
|
||||
}
|
||||
636
doc/building.html
Normal file
@@ -0,0 +1,636 @@
|
||||
<?xml version="1.0" encoding="utf-8" ?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
<meta name="generator" content="Docutils 0.5: http://docutils.sourceforge.net/" />
|
||||
<title>Boost C++ Libraries: Boost.Python Build and Test HOWTO</title>
|
||||
<link rel="stylesheet" href="../../../rst.css" type="text/css" />
|
||||
</head>
|
||||
<body>
|
||||
<div class="document" id="logo-boost-python-build-and-test-howto">
|
||||
<h1 class="title"><a class="reference external" href="../index.htm"><img alt="Boost C++ Libraries:" class="boost-logo" src="../../../boost.png" /></a> Boost.Python Build and Test HOWTO</h1>
|
||||
|
||||
<!-- Copyright David Abrahams 2006. Distributed under the Boost -->
|
||||
<!-- Software License, Version 1.0. (See accompanying -->
|
||||
<!-- file LICENSE_1_0.txt or copy at -->
|
||||
<!-- http://www.boost.org/LICENSE_1_0.txt) -->
|
||||
<div class="contents sidebar small topic" id="contents">
|
||||
<p class="topic-title first">Contents</p>
|
||||
<ul class="auto-toc simple">
|
||||
<li><a class="reference internal" href="#requirements" id="id25">1 Requirements</a></li>
|
||||
<li><a class="reference internal" href="#background" id="id26">2 Background</a></li>
|
||||
<li><a class="reference internal" href="#no-install-quickstart" id="id27">3 No-Install Quickstart</a><ul class="auto-toc">
|
||||
<li><a class="reference internal" href="#basic-procedure" id="id28">3.1 Basic Procedure</a></li>
|
||||
<li><a class="reference internal" href="#in-case-of-trouble" id="id29">3.2 In Case of Trouble</a></li>
|
||||
<li><a class="reference internal" href="#in-case-everything-seemed-to-work" id="id30">3.3 In Case Everything Seemed to Work</a></li>
|
||||
<li><a class="reference internal" href="#modifying-the-example-project" id="id31">3.4 Modifying the Example Project</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#installing-boost-python-on-your-system" id="id32">4 Installing Boost.Python on your System</a></li>
|
||||
<li><a class="reference internal" href="#configuring-boost-build" id="id33">5 Configuring Boost.Build</a><ul class="auto-toc">
|
||||
<li><a class="reference internal" href="#python-configuration-parameters" id="id34">5.1 Python Configuration Parameters</a></li>
|
||||
<li><a class="reference internal" href="#examples" id="id35">5.2 Examples</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#choosing-a-boost-python-library-binary" id="id36">6 Choosing a Boost.Python Library Binary</a><ul class="auto-toc">
|
||||
<li><a class="reference internal" href="#the-dynamic-binary" id="id37">6.1 The Dynamic Binary</a></li>
|
||||
<li><a class="reference internal" href="#the-static-binary" id="id38">6.2 The Static Binary</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#include-issues" id="id39">7 <tt class="docutils literal"><span class="pre">#include</span></tt> Issues</a></li>
|
||||
<li><a class="reference internal" href="#python-debugging-builds" id="id40">8 Python Debugging Builds</a></li>
|
||||
<li><a class="reference internal" href="#testing-boost-python" id="id41">9 Testing Boost.Python</a></li>
|
||||
<li><a class="reference internal" href="#notes-for-mingw-and-cygwin-with-mno-cygwin-gcc-users" id="id42">10 Notes for MinGW (and Cygwin with -mno-cygwin) GCC Users</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="requirements">
|
||||
<h1><a class="toc-backref" href="#id25">1 Requirements</a></h1>
|
||||
<p>Boost.Python requires <a class="reference external" href="http://www.python.org/2.2">Python 2.2</a><a class="footnote-reference" href="#id22" id="id2"><sup>1</sup></a> <em>or</em> <a class="reference external" href="http://www.python.org"><em>newer</em></a>.</p>
|
||||
</div>
|
||||
<div class="section" id="background">
|
||||
<h1><a class="toc-backref" href="#id26">2 Background</a></h1>
|
||||
<p>There are two basic models for combining C++ and Python:</p>
|
||||
<ul class="simple">
|
||||
<li><a class="reference external" href="http://www.python.org/doc/current/ext/intro.html">extending</a>, in which the end-user launches the Python interpreter
|
||||
executable and imports Python “extension modules” written in C++.
|
||||
Think of taking a library written in C++ and giving it a Python
|
||||
interface so Python programmers can use it. From Python, these
|
||||
modules look just like regular Python modules.</li>
|
||||
<li><a class="reference external" href="http://www.python.org/doc/current/ext/embedding.html">embedding</a>, in which the end-user launches a program written
|
||||
in C++ that in turn invokes the Python interpreter as a library
|
||||
subroutine. Think of adding scriptability to an existing
|
||||
application.</li>
|
||||
</ul>
|
||||
<p>The key distinction between extending and embedding is the location
|
||||
of the C++ <tt class="docutils literal"><span class="pre">main()</span></tt> function: in the Python interpreter executable,
|
||||
or in some other program, respectively. Note that even when
|
||||
embedding Python in another program, <a class="reference external" href="http://www.python.org/doc/current/ext/extending-with-embedding.html">extension modules are often
|
||||
the best way to make C/C++ functionality accessible to Python
|
||||
code</a>, so the use of extension modules is really at the heart of
|
||||
both models.</p>
|
||||
<p>Except in rare cases, extension modules are built as
|
||||
dynamically-loaded libraries with a single entry point, which means
|
||||
you can change them without rebuilding either the other extension
|
||||
modules or the executable containing <tt class="docutils literal"><span class="pre">main()</span></tt>.</p>
|
||||
</div>
|
||||
<div class="section" id="no-install-quickstart">
|
||||
<span id="quickstart"></span><h1><a class="toc-backref" href="#id27">3 No-Install Quickstart</a></h1>
|
||||
<p>There is no need to “install Boost” in order to get started using
|
||||
Boost.Python. These instructions use <a class="reference external" href="../../../tools/build/index.html">Boost.Build</a> projects,
|
||||
which will build those binaries as soon as they're needed. Your
|
||||
first tests may take a little longer while you wait for
|
||||
Boost.Python to build, but doing things this way will save you from
|
||||
worrying about build intricacies like which library binaries to use
|
||||
for a specific compiler configuration and figuring out the right
|
||||
compiler options to use yourself.</p>
|
||||
<!-- .. raw:: html
|
||||
|
||||
<div style="width:50%"> -->
|
||||
<div class="note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p>Of course it's possible to use other build systems to
|
||||
build Boost.Python and its extensions, but they are not
|
||||
officially supported by Boost. Moreover <strong>99% of all “I can't
|
||||
build Boost.Python” problems come from trying to use another
|
||||
build system</strong> without first following these instructions.</p>
|
||||
<p>If you want to use another system anyway, we suggest that you
|
||||
follow these instructions, and then invoke <tt class="docutils literal"><span class="pre">bjam</span></tt> with the</p>
|
||||
<pre class="literal-block">
|
||||
<tt class="docutils literal"><span class="pre">-a</span> <span class="pre">-o</span></tt><em>filename</em>
|
||||
</pre>
|
||||
<p class="last">options to dump the build commands it executes to a file, so
|
||||
you can see what your alternate build system needs to do.</p>
|
||||
</div>
|
||||
<!-- .. raw:: html
|
||||
|
||||
</div> -->
|
||||
<div class="section" id="basic-procedure">
|
||||
<h2><a class="toc-backref" href="#id28">3.1 Basic Procedure</a></h2>
|
||||
<ol class="arabic">
|
||||
<li><p class="first">Get Boost; see sections 1 and 2 [<a class="reference external" href="../../../more/getting_started/unix-variants.html#get-boost">Unix/Linux</a>, <a class="reference external" href="../../../more/getting_started/windows.html#get-boost">Windows</a>] of the
|
||||
Boost <a class="reference external" href="../../../more/getting_started/index.html">Getting Started Guide</a>.</p>
|
||||
</li>
|
||||
<li><p class="first">Get the <tt class="docutils literal"><span class="pre">bjam</span></tt> build driver. See section 5 [<a class="reference external" href="../../../more/getting_started/unix-variants.html#prepare-to-use-a-boost-library-binary">Unix/Linux</a>,
|
||||
<a class="reference external" href="../../../more/getting_started/windows.html#prepare-to-use-a-boost-library-binary">Windows</a>] of the Boost <a class="reference external" href="../../../more/getting_started/index.html">Getting Started Guide</a>.</p>
|
||||
</li>
|
||||
<li><p class="first">cd into the <tt class="docutils literal"><span class="pre">libs/python/example/quickstart/</span></tt> directory of your
|
||||
Boost installation, which contains a small example project.</p>
|
||||
</li>
|
||||
<li><p class="first">Invoke <tt class="docutils literal"><span class="pre">bjam</span></tt>. Replace the “<tt class="docutils literal"><span class="pre">stage</span></tt>“ argument from the
|
||||
example invocation from section 5 of the <a class="reference external" href="../../../more/getting_started/index.html">Getting Started
|
||||
Guide</a> with “<tt class="docutils literal"><span class="pre">test</span></tt>,“ to build all the test targets. Also add
|
||||
the argument “<tt class="docutils literal"><span class="pre">--verbose-test</span></tt>” to see the output generated by
|
||||
the tests when they are run.</p>
|
||||
<p>On Windows, your <tt class="docutils literal"><span class="pre">bjam</span></tt> invocation might look something like:</p>
|
||||
<pre class="literal-block">
|
||||
C:\boost_1_34_0\…\quickstart> <strong>bjam toolset=msvc --verbose-test test</strong>
|
||||
</pre>
|
||||
<p>and on Unix variants, perhaps,</p>
|
||||
<pre class="literal-block">
|
||||
~/boost_1_34_0/…/quickstart$ <strong>bjam toolset=gcc --verbose-test test</strong>
|
||||
</pre>
|
||||
</li>
|
||||
</ol>
|
||||
<div class="admonition-note-to-windows-users admonition">
|
||||
<p class="first admonition-title">Note to Windows Users</p>
|
||||
<p class="last">For the sake of concision, the rest of this guide will use
|
||||
unix-style forward slashes in pathnames instead of the
|
||||
backslashes with which you may be more familiar. The forward
|
||||
slashes should work everywhere except in <a class="reference external" href="../../../more/getting_started/windows.html#command-prompt">Command Prompt</a>
|
||||
windows, where you should use backslashes.</p>
|
||||
</div>
|
||||
<p>If you followed this procedure successfully, you will have built an
|
||||
extension module called <tt class="docutils literal"><span class="pre">extending</span></tt> and tested it by running a
|
||||
Python script called <tt class="docutils literal"><span class="pre">test_extending.py</span></tt>. You will also have
|
||||
built and run a simple application called <tt class="docutils literal"><span class="pre">embedding</span></tt> that embeds
|
||||
python.</p>
|
||||
</div>
|
||||
<div class="section" id="in-case-of-trouble">
|
||||
<h2><a class="toc-backref" href="#id29">3.2 In Case of Trouble</a></h2>
|
||||
<p>If you're seeing lots of compiler and/or linker error messages,
|
||||
it's probably because Boost.Build is having trouble finding your
|
||||
Python installation. You might want to pass the
|
||||
<tt class="docutils literal"><span class="pre">--debug-configuration</span></tt> option to <tt class="docutils literal"><span class="pre">bjam</span></tt> the first few times
|
||||
you invoke it, to make sure that Boost.Build is correctly locating
|
||||
all the parts of your Python installation. If it isn't, consider
|
||||
<a class="reference internal" href="#configuring-boost-build">Configuring Boost.Build</a> as detailed below.</p>
|
||||
<p>If you're still having trouble, Someone on one of the following
|
||||
mailing lists may be able to help:</p>
|
||||
<ul class="simple">
|
||||
<li>The <a class="reference external" href="../../../more/mailing_lists.htm#jamboost">Boost.Build mailing list</a> for issues related to Boost.Build</li>
|
||||
<li>The Python <a class="reference external" href="../../../more/mailing_lists.htm#cplussig">C++ Sig</a> for issues specifically related to Boost.Python</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="in-case-everything-seemed-to-work">
|
||||
<h2><a class="toc-backref" href="#id30">3.3 In Case Everything Seemed to Work</a></h2>
|
||||
<p>Rejoice! If you're new to Boost.Python, at this point it might be
|
||||
a good idea to ignore build issues for a while and concentrate on
|
||||
learning the library by going through the <a class="reference external" href="tutorial/index.html">tutorial</a> and perhaps
|
||||
some of the <a class="reference external" href="v2/reference.html">reference documentation</a>, trying out what you've
|
||||
learned about the API by modifying the quickstart project.</p>
|
||||
</div>
|
||||
<div class="section" id="modifying-the-example-project">
|
||||
<h2><a class="toc-backref" href="#id31">3.4 Modifying the Example Project</a></h2>
|
||||
<p>If you're content to keep your extension module forever in one
|
||||
source file called <a class="reference external" href="../example/quickstart/extending.cpp"><tt class="docutils literal"><span class="pre">extending.cpp</span></tt></a>, inside your Boost
|
||||
distribution, and import it forever as <tt class="docutils literal"><span class="pre">extending</span></tt>, then you can
|
||||
stop here. However, it's likely that you will want to make a few
|
||||
changes. There are a few things you can do without having to learn
|
||||
<a class="reference external" href="../../../tools/build/index.html">Boost.Build</a> in depth.</p>
|
||||
<p>The project you just built is specified in two files in the current
|
||||
directory: <a class="reference external" href="../example/quickstart/boost-build.jam"><tt class="docutils literal"><span class="pre">boost-build.jam</span></tt></a>, which tells <tt class="docutils literal"><span class="pre">bjam</span></tt> where it can
|
||||
find the interpreted code of the Boost build system, and
|
||||
<a class="reference external" href="../example/quickstart/Jamroot"><tt class="docutils literal"><span class="pre">Jamroot</span></tt></a>, which describes the targets you just built. These
|
||||
files are heavily commented, so they should be easy to modify.
|
||||
Take care, however, to preserve whitespace. Punctuation such as
|
||||
<tt class="docutils literal"><span class="pre">;</span></tt> will not be recognized as intended by <tt class="docutils literal"><span class="pre">bjam</span></tt> if it is not
|
||||
surrounded by whitespace.</p>
|
||||
<div class="section" id="relocate-the-project">
|
||||
<h3>Relocate the Project</h3>
|
||||
<p>You'll probably want to copy this project elsewhere so you can
|
||||
change it without modifying your Boost distribution. To do that,
|
||||
simply</p>
|
||||
<ol class="loweralpha simple">
|
||||
<li>copy the entire <tt class="docutils literal"><span class="pre">libs/python/example/quickstart/</span></tt> directory
|
||||
into a new directory.</li>
|
||||
<li>In the new copies of <a class="reference external" href="../example/quickstart/boost-build.jam"><tt class="docutils literal"><span class="pre">boost-build.jam</span></tt></a> and <a class="reference external" href="../example/quickstart/Jamroot"><tt class="docutils literal"><span class="pre">Jamroot</span></tt></a>, locate
|
||||
the relative path near the top of the file that is clearly
|
||||
marked by a comment, and edit that path so that it refers to the
|
||||
same directory your Boost distribution as it referred to when
|
||||
the file was in its original location in the
|
||||
<tt class="docutils literal"><span class="pre">libs/python/example/quickstart/</span></tt> directory.</li>
|
||||
</ol>
|
||||
<p>For example, if you moved the project from
|
||||
<tt class="docutils literal"><span class="pre">/home/dave/boost_1_34_0/libs/python/example/quickstart</span></tt> to
|
||||
<tt class="docutils literal"><span class="pre">/home/dave/my-project</span></tt>, you could change the first path in
|
||||
<a class="reference external" href="../example/quickstart/boost-build.jam"><tt class="docutils literal"><span class="pre">boost-build.jam</span></tt></a> from</p>
|
||||
<pre class="literal-block">
|
||||
<strong>../../../..</strong>/tools/build/v2
|
||||
</pre>
|
||||
<p>to</p>
|
||||
<pre class="literal-block">
|
||||
<strong>/home/dave/boost_1_34_0</strong>/tools/build/v2
|
||||
</pre>
|
||||
<p>and change the first path in <a class="reference external" href="../example/quickstart/Jamroot"><tt class="docutils literal"><span class="pre">Jamroot</span></tt></a> from</p>
|
||||
<pre class="literal-block">
|
||||
<strong>../../../..</strong>
|
||||
</pre>
|
||||
<p>to</p>
|
||||
<pre class="literal-block">
|
||||
<strong>/home/dave/boost_1_34_0</strong>
|
||||
</pre>
|
||||
</div>
|
||||
<div class="section" id="add-new-or-change-names-of-existing-source-files">
|
||||
<h3>Add New or Change Names of Existing Source Files</h3>
|
||||
<p>The names of additional source files involved in building your
|
||||
extension module or embedding application can be listed in
|
||||
<a class="reference external" href="../example/quickstart/Jamroot"><tt class="docutils literal"><span class="pre">Jamroot</span></tt></a> right alongside <tt class="docutils literal"><span class="pre">extending.cpp</span></tt> or <tt class="docutils literal"><span class="pre">embedding.cpp</span></tt>
|
||||
respectively. Just be sure to leave whitespace around each
|
||||
filename:</p>
|
||||
<pre class="literal-block">
|
||||
… file1.cpp file2.cpp file3.cpp …
|
||||
</pre>
|
||||
<p>Naturally, if you want to change the name of a source file you can
|
||||
tell Boost.Build about it by editing the name in <a class="reference external" href="../example/quickstart/Jamroot"><tt class="docutils literal"><span class="pre">Jamroot</span></tt></a>.</p>
|
||||
</div>
|
||||
<div class="section" id="change-the-name-of-your-extension-module">
|
||||
<h3>Change the Name of your Extension Module</h3>
|
||||
<p>The name of the extension module is determined by two things:</p>
|
||||
<ol class="arabic simple">
|
||||
<li>the name in <a class="reference external" href="../example/quickstart/Jamroot"><tt class="docutils literal"><span class="pre">Jamroot</span></tt></a> immediately following <tt class="docutils literal"><span class="pre">python-extension</span></tt>, and</li>
|
||||
<li>the name passed to <tt class="docutils literal"><span class="pre">BOOST_PYTHON_MODULE</span></tt> in <a class="reference external" href="../example/quickstart/extending.cpp"><tt class="docutils literal"><span class="pre">extending.cpp</span></tt></a>.</li>
|
||||
</ol>
|
||||
<p>To change the name of the extension module from <tt class="docutils literal"><span class="pre">extending</span></tt> to
|
||||
<tt class="docutils literal"><span class="pre">hello</span></tt>, you'd edit <a class="reference external" href="../example/quickstart/Jamroot"><tt class="docutils literal"><span class="pre">Jamroot</span></tt></a>, changing</p>
|
||||
<pre class="literal-block">
|
||||
python-extension <strong>extending</strong> : extending.cpp ;
|
||||
</pre>
|
||||
<p>to</p>
|
||||
<pre class="literal-block">
|
||||
python-extension <strong>hello</strong> : extending.cpp ;
|
||||
</pre>
|
||||
<p>and you'd edit extending.cpp, changing</p>
|
||||
<pre class="literal-block">
|
||||
BOOST_PYTHON_MODULE(<strong>extending</strong>)
|
||||
</pre>
|
||||
<p>to</p>
|
||||
<pre class="literal-block">
|
||||
BOOST_PYTHON_MODULE(<strong>hello</strong>)
|
||||
</pre>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="installing-boost-python-on-your-system">
|
||||
<h1><a class="toc-backref" href="#id32">4 Installing Boost.Python on your System</a></h1>
|
||||
<p>Since Boost.Python is a separately-compiled (as opposed to
|
||||
<a class="reference external" href="../../../more/getting_started/windows.html#header-only-libraries">header-only</a>) library, its user relies on the services of a
|
||||
Boost.Python library binary.</p>
|
||||
<p>If you need a regular installation of the Boost.Python library
|
||||
binaries on your system, the Boost <a class="reference external" href="../../../more/getting_started/index.html">Getting Started Guide</a> will
|
||||
walk you through the steps of creating one. If building binaries
|
||||
from source, you might want to supply the <tt class="docutils literal"><span class="pre">--with-python</span></tt>
|
||||
argument to <tt class="docutils literal"><span class="pre">bjam</span></tt> (or the <tt class="docutils literal"><span class="pre">--with-libraries=python</span></tt> argument
|
||||
to <tt class="docutils literal"><span class="pre">configure</span></tt>), so only the Boost.Python binary will be built,
|
||||
rather than all the Boost binaries.</p>
|
||||
</div>
|
||||
<div class="section" id="configuring-boost-build">
|
||||
<h1><a class="toc-backref" href="#id33">5 Configuring Boost.Build</a></h1>
|
||||
<p>As described in the <a class="reference external" href="http://www.boost.orgdoc/html/bbv2/advanced.html#bbv2.advanced.configuration">Boost.Build reference manual</a>, a file called
|
||||
<tt class="docutils literal"><span class="pre">user-config.jam</span></tt> in your home directory<a class="footnote-reference" href="#home-dir" id="id11"><sup>6</sup></a> is used to
|
||||
specify the tools and libraries available to the build system. You
|
||||
may need to create or edit <tt class="docutils literal"><span class="pre">user-config.jam</span></tt> to tell Boost.Build
|
||||
how to invoke Python, <tt class="docutils literal"><span class="pre">#include</span></tt> its headers, and link with its
|
||||
libraries.</p>
|
||||
<div class="admonition-users-of-unix-variant-oses admonition">
|
||||
<p class="first admonition-title">Users of Unix-Variant OSes</p>
|
||||
<p class="last">If you are using a unix-variant OS and you ran Boost's
|
||||
<tt class="docutils literal"><span class="pre">configure</span></tt> script, it may have generated a
|
||||
<tt class="docutils literal"><span class="pre">user-config.jam</span></tt> for you.<a class="footnote-reference" href="#overwrite" id="id13"><sup>4</sup></a> If your <tt class="docutils literal"><span class="pre">configure</span></tt>/<tt class="docutils literal"><span class="pre">make</span></tt> sequence was successful and Boost.Python binaries
|
||||
were built, your <tt class="docutils literal"><span class="pre">user-config.jam</span></tt> file is probably already
|
||||
correct.</p>
|
||||
</div>
|
||||
<p>If you have one fairly “standard” python installation for your
|
||||
platform, you might not need to do anything special to describe it. If
|
||||
you haven't configured python in <tt class="docutils literal"><span class="pre">user-config.jam</span></tt> (and you don't
|
||||
specify <tt class="docutils literal"><span class="pre">--without-python</span></tt> on the Boost.Build command line),
|
||||
Boost.Build will automatically execute the equivalent of</p>
|
||||
<pre class="literal-block">
|
||||
import toolset : using ;
|
||||
using python ;
|
||||
</pre>
|
||||
<p>which automatically looks for Python in the most likely places.
|
||||
However, that only happens when using the Boost.Python project file
|
||||
(e.g. when referred to by another project as in the <a class="reference internal" href="#quickstart">quickstart</a>
|
||||
method). If instead you are linking against separately-compiled
|
||||
Boost.Python binaries, you should set up a <tt class="docutils literal"><span class="pre">user-config.jam</span></tt> file
|
||||
with at least the minimal incantation above.</p>
|
||||
<div class="section" id="python-configuration-parameters">
|
||||
<h2><a class="toc-backref" href="#id34">5.1 Python Configuration Parameters</a></h2>
|
||||
<p>If you have several versions of Python installed, or Python is
|
||||
installed in an unusual way, you may want to supply any or all of
|
||||
the following optional parameters to <tt class="docutils literal"><span class="pre">using</span> <span class="pre">python</span></tt>.</p>
|
||||
<dl class="docutils">
|
||||
<dt>version</dt>
|
||||
<dd>the version of Python to use. Should be in Major.Minor
|
||||
format, for example, <tt class="docutils literal"><span class="pre">2.3</span></tt>. Do not include the subminor
|
||||
version (i.e. <em>not</em> <tt class="docutils literal"><span class="pre">2.5.1</span></tt>). If you have multiple Python
|
||||
versions installed, the version will usually be the only
|
||||
configuration argument required.</dd>
|
||||
<dt>cmd-or-prefix</dt>
|
||||
<dd>preferably, a command that invokes a Python interpreter.
|
||||
Alternatively, the installation prefix for Python libraries and
|
||||
header files. Only use the alternative formulation if there is
|
||||
no appropriate Python executable available.</dd>
|
||||
<dt>includes</dt>
|
||||
<dd>the <tt class="docutils literal"><span class="pre">#include</span></tt> paths for Python headers. Normally the correct
|
||||
path(s) will be automatically deduced from <tt class="docutils literal"><span class="pre">version</span></tt> and/or
|
||||
<tt class="docutils literal"><span class="pre">cmd-or-prefix</span></tt>.</dd>
|
||||
<dt>libraries</dt>
|
||||
<dd>the path to Python library binaries. On MacOS/Darwin,
|
||||
you can also pass the path of the Python framework. Normally the
|
||||
correct path(s) will be automatically deduced from <tt class="docutils literal"><span class="pre">version</span></tt>
|
||||
and/or <tt class="docutils literal"><span class="pre">cmd-or-prefix</span></tt>.</dd>
|
||||
<dt>condition</dt>
|
||||
<dd>if specified, should be a set of Boost.Build
|
||||
properties that are matched against the build configuration when
|
||||
Boost.Build selects a Python configuration to use. See examples
|
||||
below for details.</dd>
|
||||
<dt>extension-suffix</dt>
|
||||
<dd>A string to append to the name of extension
|
||||
modules before the true filename extension. You almost certainly
|
||||
don't need to use this. Usually this suffix is only used when
|
||||
targeting a Windows debug build of Python, and will be set
|
||||
automatically for you based on the value of the
|
||||
<a class="reference internal" href="#python-debugging"><tt class="docutils literal"><span class="pre"><python-debugging></span></tt></a> feature. However, at least one Linux
|
||||
distribution (Ubuntu Feisty Fawn) has a specially configured
|
||||
<a class="reference external" href="https://wiki.ubuntu.com/PyDbgBuilds">python-dbg</a> package that claims to use such a suffix.</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2><a class="toc-backref" href="#id35">5.2 Examples</a></h2>
|
||||
<p>Note that in the examples below, case and <em>especially whitespace</em> are
|
||||
significant.</p>
|
||||
<ul>
|
||||
<li><p class="first">If you have both python 2.5 and python 2.4 installed,
|
||||
<tt class="docutils literal"><span class="pre">user-config.jam</span></tt> might contain:</p>
|
||||
<pre class="literal-block">
|
||||
using python : 2.5 ; # Make both versions of Python available
|
||||
|
||||
using python : 2.4 ; # To build with python 2.4, add python=2.4
|
||||
# to your command line.
|
||||
</pre>
|
||||
<p>The first version configured (2.5) becomes the default. To build
|
||||
against python 2.4, add <tt class="docutils literal"><span class="pre">python=2.4</span></tt> to the <tt class="docutils literal"><span class="pre">bjam</span></tt> command line.</p>
|
||||
</li>
|
||||
<li><p class="first">If you have python installed in an unusual location, you might
|
||||
supply the path to the interpreter in the <tt class="docutils literal"><span class="pre">cmd-or-prefix</span></tt>
|
||||
parameter:</p>
|
||||
<pre class="literal-block">
|
||||
using python : : /usr/local/python-2.6-beta/bin/python ;
|
||||
</pre>
|
||||
</li>
|
||||
<li><p class="first">If you have a separate build of Python for use with a particular
|
||||
toolset, you might supply that toolset in the <tt class="docutils literal"><span class="pre">condition</span></tt>
|
||||
parameter:</p>
|
||||
<pre class="literal-block">
|
||||
using python ; # use for most toolsets
|
||||
|
||||
# Use with Intel C++ toolset
|
||||
using python
|
||||
: # version
|
||||
: c:\\Devel\\Python-2.5-IntelBuild\\PCBuild\\python # cmd-or-prefix
|
||||
: # includes
|
||||
: # libraries
|
||||
: <toolset>intel # condition
|
||||
;
|
||||
</pre>
|
||||
</li>
|
||||
<li><p class="first">If you have downloaded the Python sources and built both the
|
||||
normal and the “<a class="reference internal" href="#id19">python debugging</a>” builds from source on
|
||||
Windows, you might see:</p>
|
||||
<pre class="literal-block">
|
||||
using python : 2.5 : C:\\src\\Python-2.5\\PCBuild\\python ;
|
||||
using python : 2.5 : C:\\src\\Python-2.5\\PCBuild\\python_d
|
||||
: # includes
|
||||
: # libs
|
||||
: <python-debugging>on ;
|
||||
</pre>
|
||||
</li>
|
||||
<li><p class="first">You can set up your user-config.jam so a bjam built under Windows
|
||||
can build/test both Windows and <a class="reference external" href="http://cygwin.com">Cygwin</a> python extensions. Just pass
|
||||
<tt class="docutils literal"><span class="pre"><target-os>cygwin</span></tt> in the <tt class="docutils literal"><span class="pre">condition</span></tt> parameter
|
||||
for the cygwin python installation:</p>
|
||||
<pre class="literal-block">
|
||||
# windows installation
|
||||
using python ;
|
||||
|
||||
# cygwin installation
|
||||
using python : : c:\\cygwin\\bin\\python2.5 : : : <target-os>cygwin ;
|
||||
</pre>
|
||||
<p>when you put target-os=cygwin in your build request, it should build
|
||||
with the cygwin version of python:<a class="footnote-reference" href="#flavor" id="id15"><sup>5</sup></a></p>
|
||||
<blockquote>
|
||||
<p>bjam target-os=cygwin toolset=gcc</p>
|
||||
</blockquote>
|
||||
<p>This is supposed to work the other way, too (targeting windows
|
||||
python with a <a class="reference external" href="http://cygwin.com">Cygwin</a> bjam) but it seems as though the support in
|
||||
Boost.Build's toolsets for building that way is broken at the
|
||||
time of this writing.</p>
|
||||
</li>
|
||||
<li><p class="first">Note that because of <a class="reference external" href="http://zigzag.cs.msu.su/boost.build/wiki/AlternativeSelection">the way Boost.Build currently selects target
|
||||
alternatives</a>, you might have be very explicit in your build
|
||||
requests. For example, given:</p>
|
||||
<pre class="literal-block">
|
||||
using python : 2.5 ; # a regular windows build
|
||||
using python : 2.4 : : : : <target-os>cygwin ;
|
||||
</pre>
|
||||
<p>building with</p>
|
||||
<pre class="literal-block">
|
||||
bjam target-os=cygwin
|
||||
</pre>
|
||||
<p>will yield an error. Instead, you'll need to write:</p>
|
||||
<pre class="literal-block">
|
||||
bjam target-os=cygwin/python=2.4
|
||||
</pre>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="choosing-a-boost-python-library-binary">
|
||||
<h1><a class="toc-backref" href="#id36">6 Choosing a Boost.Python Library Binary</a></h1>
|
||||
<p>If—instead of letting Boost.Build construct and link with the right
|
||||
libraries automatically—you choose to use a pre-built Boost.Python
|
||||
library, you'll need to think about which one to link with. The
|
||||
Boost.Python binary comes in both static and dynamic flavors. Take
|
||||
care to choose the right flavor for your application.<a class="footnote-reference" href="#naming" id="id17"><sup>2</sup></a></p>
|
||||
<div class="section" id="the-dynamic-binary">
|
||||
<h2><a class="toc-backref" href="#id37">6.1 The Dynamic Binary</a></h2>
|
||||
<p>The dynamic library is the safest and most-versatile choice:</p>
|
||||
<ul class="simple">
|
||||
<li>A single copy of the library code is used by all extension
|
||||
modules built with a given toolset.<a class="footnote-reference" href="#toolset-specific" id="id18"><sup>3</sup></a></li>
|
||||
<li>The library contains a type conversion registry. Because one
|
||||
registry is shared among all extension modules, instances of a
|
||||
class exposed to Python in one dynamically-loaded extension
|
||||
module can be passed to functions exposed in another such module.</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="the-static-binary">
|
||||
<h2><a class="toc-backref" href="#id38">6.2 The Static Binary</a></h2>
|
||||
<p>It might be appropriate to use the static Boost.Python library in
|
||||
any of the following cases:</p>
|
||||
<ul class="simple">
|
||||
<li>You are <a class="reference external" href="http://www.python.org/doc/current/ext/intro.html">extending</a> python and the types exposed in your
|
||||
dynamically-loaded extension module don't need to be used by any
|
||||
other Boost.Python extension modules, and you don't care if the
|
||||
core library code is duplicated among them.</li>
|
||||
<li>You are <a class="reference external" href="http://www.python.org/doc/current/ext/embedding.html">embedding</a> python in your application and either:<ul>
|
||||
<li>You are targeting a Unix variant OS other than MacOS or AIX,
|
||||
where the dynamically-loaded extension modules can “see” the
|
||||
Boost.Python library symbols that are part of the executable.</li>
|
||||
<li>Or, you have statically linked some Boost.Python extension
|
||||
modules into your application and you don't care if any
|
||||
dynamically-loaded Boost.Python extension modules are able to
|
||||
use the types exposed by your statically-linked extension
|
||||
modules (and vice-versa).</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="include-issues">
|
||||
<h1><a class="toc-backref" href="#id39">7 <tt class="docutils literal"><span class="pre">#include</span></tt> Issues</a></h1>
|
||||
<ol class="arabic simple">
|
||||
<li>If you should ever have occasion to <tt class="docutils literal"><span class="pre">#include</span> <span class="pre">"python.h"</span></tt>
|
||||
directly in a translation unit of a program using Boost.Python,
|
||||
use <tt class="docutils literal"><span class="pre">#include</span> <span class="pre">"boost/python/detail/wrap_python.hpp"</span></tt> instead.
|
||||
It handles several issues necessary for use with Boost.Python,
|
||||
one of which is mentioned in the next section.</li>
|
||||
<li>Be sure not to <tt class="docutils literal"><span class="pre">#include</span></tt> any system headers before
|
||||
<tt class="docutils literal"><span class="pre">wrap_python.hpp</span></tt>. This restriction is actually imposed by
|
||||
Python, or more properly, by Python's interaction with your
|
||||
operating system. See
|
||||
<a class="reference external" href="http://docs.python.org/ext/simpleExample.html">http://docs.python.org/ext/simpleExample.html</a> for details.</li>
|
||||
</ol>
|
||||
</div>
|
||||
<div class="section" id="python-debugging-builds">
|
||||
<span id="id19"></span><span id="python-debugging"></span><h1><a class="toc-backref" href="#id40">8 Python Debugging Builds</a></h1>
|
||||
<p>Python can be built in a special “python debugging” configuration
|
||||
that adds extra checks and instrumentation that can be very useful
|
||||
for developers of extension modules. The data structures used by
|
||||
the debugging configuration contain additional members, so <strong>a
|
||||
Python executable built with python debugging enabled cannot be
|
||||
used with an extension module or library compiled without it, and
|
||||
vice-versa.</strong></p>
|
||||
<p>Since pre-built “python debugging” versions of the Python
|
||||
executable and libraries are not supplied with most distributions
|
||||
of Python,<a class="footnote-reference" href="#get-debug-build" id="id20"><sup>7</sup></a> and we didn't want to force our users
|
||||
to build them, Boost.Build does not automatically enable python
|
||||
debugging in its <tt class="docutils literal"><span class="pre">debug</span></tt> build variant (which is the default).
|
||||
Instead there is a special build property called
|
||||
<tt class="docutils literal"><span class="pre">python-debugging</span></tt> that, when used as a build property, will
|
||||
define the right preprocessor symbols and select the right
|
||||
libraries to link with.</p>
|
||||
<p>On unix-variant platforms, the debugging versions of Python's data
|
||||
structures will only be used if the symbol <tt class="docutils literal"><span class="pre">Py_DEBUG</span></tt> is defined.
|
||||
On many windows compilers, when extension modules are built with
|
||||
the preprocessor symbol <tt class="docutils literal"><span class="pre">_DEBUG</span></tt>, Python defaults to force
|
||||
linking with a special debugging version of the Python DLL. Since
|
||||
that symbol is very commonly used even when Python is not present,
|
||||
Boost.Python temporarily undefines _DEBUG when Python.h
|
||||
is #included from <tt class="docutils literal"><span class="pre">boost/python/detail/wrap_python.hpp</span></tt> - unless
|
||||
<tt class="docutils literal"><span class="pre">BOOST_DEBUG_PYTHON</span></tt> is defined. The upshot is that if you want
|
||||
“python debugging”and you aren't using Boost.Build, you should make
|
||||
sure <tt class="docutils literal"><span class="pre">BOOST_DEBUG_PYTHON</span></tt> is defined, or python debugging will be
|
||||
suppressed.</p>
|
||||
</div>
|
||||
<div class="section" id="testing-boost-python">
|
||||
<h1><a class="toc-backref" href="#id41">9 Testing Boost.Python</a></h1>
|
||||
<p>To run the full test suite for Boost.Python, invoke <tt class="docutils literal"><span class="pre">bjam</span></tt> in the
|
||||
<tt class="docutils literal"><span class="pre">libs/python/test</span></tt> subdirectory of your Boost distribution.</p>
|
||||
</div>
|
||||
<div class="section" id="notes-for-mingw-and-cygwin-with-mno-cygwin-gcc-users">
|
||||
<h1><a class="toc-backref" href="#id42">10 Notes for MinGW (and Cygwin with -mno-cygwin) GCC Users</a></h1>
|
||||
<p>If you are using a version of Python prior to 2.4.1 with a MinGW
|
||||
prior to 3.0.0 (with binutils-2.13.90-20030111-1), you will need to
|
||||
create a MinGW-compatible version of the Python library; the one
|
||||
shipped with Python will only work with a Microsoft-compatible
|
||||
linker. Follow the instructions in the “Non-Microsoft” section of
|
||||
the “Building Extensions: Tips And Tricks” chapter in <a class="reference external" href="http://www.python.org/doc/current/inst/index.html">Installing
|
||||
Python Modules</a> to create <tt class="docutils literal"><span class="pre">libpythonXX.a</span></tt>, where <tt class="docutils literal"><span class="pre">XX</span></tt>
|
||||
corresponds to the major and minor version numbers of your Python
|
||||
installation.</p>
|
||||
<hr class="docutils" />
|
||||
<table class="docutils footnote" frame="void" id="id22" rules="none">
|
||||
<colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id2">[1]</a></td><td>Note that although we tested earlier versions of
|
||||
Boost.Python with Python 2.2, and we don't <em>think</em> we've done
|
||||
anything to break compatibility, this release of Boost.Python
|
||||
may not have been tested with versions of Python earlier than
|
||||
2.4, so we're not 100% sure that python 2.2 and 2.3 are
|
||||
supported.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table class="docutils footnote" frame="void" id="naming" rules="none">
|
||||
<colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id17">[2]</a></td><td><p class="first">Information about how to identify the
|
||||
static and dynamic builds of Boost.Python:</p>
|
||||
<ul class="simple">
|
||||
<li><a class="reference external" href="../../../more/getting_started/windows.html#library-naming">on Windows</a></li>
|
||||
<li><a class="reference external" href="../../../more/getting_started/unix-variants.html#library-naming">on Unix variants</a></li>
|
||||
</ul>
|
||||
</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table class="docutils footnote" frame="void" id="toolset-specific" rules="none">
|
||||
<colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id18">[3]</a></td><td>Because of the way most *nix platforms
|
||||
share symbols among dynamically-loaded objects, I'm not certain
|
||||
that extension modules built with different compiler toolsets
|
||||
will always use different copies of the Boost.Python library
|
||||
when loaded into the same Python instance. Not using different
|
||||
libraries could be a good thing if the compilers have compatible
|
||||
ABIs, because extension modules built with the two libraries
|
||||
would be interoperable. Otherwise, it could spell disaster,
|
||||
since an extension module and the Boost.Python library would
|
||||
have different ideas of such things as class layout. I would
|
||||
appreciate someone doing the experiment to find out what
|
||||
happens.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table class="docutils footnote" frame="void" id="overwrite" rules="none">
|
||||
<colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id13">[4]</a></td><td><tt class="docutils literal"><span class="pre">configure</span></tt> overwrites the existing
|
||||
<tt class="docutils literal"><span class="pre">user-config.jam</span></tt> in your home directory
|
||||
(if any) after making a backup of the old version.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table class="docutils footnote" frame="void" id="flavor" rules="none">
|
||||
<colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id15">[5]</a></td><td>Note that the <tt class="docutils literal"><span class="pre"><target-os>cygwin</span></tt> feature is
|
||||
different from the <tt class="docutils literal"><span class="pre"><flavor>cygwin</span></tt> subfeature of the <tt class="docutils literal"><span class="pre">gcc</span></tt>
|
||||
toolset, and you might need handle both explicitly if you also
|
||||
have a MinGW GCC installed.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table class="docutils footnote" frame="void" id="home-dir" rules="none">
|
||||
<colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id11">[6]</a></td><td><p class="first">Windows users, your home directory can be
|
||||
found by typing:</p>
|
||||
<pre class="literal-block">
|
||||
ECHO %HOMEDRIVE%%HOMEPATH%
|
||||
</pre>
|
||||
<p class="last">into a <a class="reference external" href="../../../more/getting_started/windows.html#command-prompt">command prompt</a> window.</p>
|
||||
</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table class="docutils footnote" frame="void" id="get-debug-build" rules="none">
|
||||
<colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id20">[7]</a></td><td>On Unix and similar platforms, a debugging
|
||||
python and associated libraries are built by adding
|
||||
<tt class="docutils literal"><span class="pre">--with-pydebug</span></tt> when configuring the Python build. On
|
||||
Windows, the debugging version of Python is generated by
|
||||
the "Win32 Debug" target of the Visual Studio project in the
|
||||
PCBuild subdirectory of a full Python source code distribution.
|
||||
You may also find</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</div>
|
||||
<div class="footer">
|
||||
<hr class="footer" />
|
||||
<a class="reference external" href="./building.rst">View document source</a>.
|
||||
Generated on: 2007-07-02 13:46 UTC.
|
||||
Generated by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
|
||||
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
566
doc/building.qbk
@@ -1,566 +0,0 @@
|
||||
[chapter Building and Testing
|
||||
[quickbook 1.7]
|
||||
[authors [Abrahams, David]]
|
||||
[copyright 2002 - 2015 David Abrahams, Stefan Seefeld]
|
||||
[id building]
|
||||
]
|
||||
[/ Copyright David Abrahams 2006. Distributed under the Boost
|
||||
/ Software License, Version 1.0. (See accompanying
|
||||
/ file LICENSE_1_0.txt or copy at
|
||||
/ http://www.boost.org/LICENSE_1_0.txt)
|
||||
/]
|
||||
|
||||
[section Requirements]
|
||||
|
||||
Boost.Python requires [@http://www.python.org/2.2 Python 2.2]
|
||||
[footnote Note that although we tested earlier versions of Boost.Python
|
||||
with Python 2.2, and we don't *think* we've done anything to break
|
||||
compatibility, this release of Boost.Python may not have been tested
|
||||
with versions of Python earlier than 2.4, so we're not 100% sure that
|
||||
python 2.2 and 2.3 are supported.] *or* [@http://www.python.org newer].
|
||||
|
||||
[endsect]
|
||||
[section Background]
|
||||
|
||||
There are two basic models for combining C++ and Python:
|
||||
|
||||
* [@http://www.python.org/doc/current/ext/intro.html extending],
|
||||
in which the end-user launches the Python interpreter
|
||||
executable and imports Python “extension modules” written in C++.
|
||||
Think of taking a library written in C++ and giving it a Python
|
||||
interface so Python programmers can use it. From Python, these
|
||||
modules look just like regular Python modules.
|
||||
|
||||
* [@http://www.python.org/doc/current/ext/embedding.html embedding],
|
||||
in which the end-user launches a program written
|
||||
in C++ that in turn invokes the Python interpreter as a library
|
||||
subroutine. Think of adding scriptability to an existing
|
||||
application.
|
||||
|
||||
The key distinction between extending and embedding is the location
|
||||
of the C++ `main()` function: in the Python interpreter executable,
|
||||
or in some other program, respectively. Note that even when
|
||||
embedding Python in another program, [@http://www.python.org/doc/current/ext/extending-with-embedding.html extension modules are often
|
||||
the best way to make C/C++ functionality accessible to Python
|
||||
code], so the use of extension modules is really at the heart of
|
||||
both models.
|
||||
|
||||
Except in rare cases, extension modules are built as
|
||||
dynamically-loaded libraries with a single entry point, which means
|
||||
you can change them without rebuilding either the other extension
|
||||
modules or the executable containing `main()`.
|
||||
|
||||
[endsect]
|
||||
[section No-Install Quickstart]
|
||||
|
||||
There is no need to “install Boost” in order to get started using
|
||||
Boost.Python. These instructions use _bb_ projects,
|
||||
which will build those binaries as soon as they're needed. Your
|
||||
first tests may take a little longer while you wait for
|
||||
Boost.Python to build, but doing things this way will save you from
|
||||
worrying about build intricacies like which library binaries to use
|
||||
for a specific compiler configuration and figuring out the right
|
||||
compiler options to use yourself.
|
||||
|
||||
[note Of course it's possible to use other build systems to
|
||||
build Boost.Python and its extensions, but they are not
|
||||
officially supported by Boost. Moreover *99% of all “I can't
|
||||
build Boost.Python” problems come from trying to use another
|
||||
build system* without first following these instructions.
|
||||
|
||||
If you want to use another system anyway, we suggest that you
|
||||
follow these instructions, and then invoke `bjam` with the
|
||||
|
||||
`-a -o`\ /filename/
|
||||
|
||||
options to dump the build commands it executes to a file, so
|
||||
you can see what your alternate build system needs to do.]
|
||||
|
||||
[section Basic Procedure]
|
||||
|
||||
1. Get Boost; see sections 1 and 2 of the _gsg_.
|
||||
|
||||
2. Get the `bjam` build driver. See section 5 of the _gsg_.
|
||||
|
||||
3. cd into the `example/quickstart/` directory of your
|
||||
Boost.Python installation, which contains a small example project.
|
||||
|
||||
4. Invoke `bjam`. Replace the “\ `stage`\ “ argument from the
|
||||
example invocation from section 5 of the _gsg_ with “\ `test`\ ,“ to
|
||||
build all the test targets. Also add the argument “\ `--verbose-test`\ ”
|
||||
to see the output generated by the tests when they are run.
|
||||
On Windows, your `bjam` invocation might look something like:
|
||||
``
|
||||
C:\\...\\quickstart> bjam toolset=msvc --verbose-test test
|
||||
``
|
||||
and on Unix variants, perhaps,
|
||||
``
|
||||
.../quickstart$ bjam toolset=gcc --verbose-test test
|
||||
``
|
||||
|
||||
[note For the sake of concision, the rest of this guide will use
|
||||
unix-style forward slashes in pathnames instead of the
|
||||
backslashes with which Windows users may be more familiar. The forward
|
||||
slashes should work everywhere except in
|
||||
[@http://www.boost.org/more/getting_started/windows.html#command-prompt
|
||||
Command Prompt] windows, where you should use backslashes.]
|
||||
|
||||
If you followed this procedure successfully, you will have built an
|
||||
extension module called `extending` and tested it by running a
|
||||
Python script called `test_extending.py`. You will also have
|
||||
built and run a simple application called `embedding` that embeds
|
||||
python.
|
||||
|
||||
[endsect]
|
||||
[section In Case of Trouble]
|
||||
|
||||
If you're seeing lots of compiler and/or linker error messages,
|
||||
it's probably because Boost.Build is having trouble finding your
|
||||
Python installation. You might want to pass the
|
||||
`--debug-configuration` option to `bjam` the first few times
|
||||
you invoke it, to make sure that Boost.Build is correctly locating
|
||||
all the parts of your Python installation. If it isn't, consider
|
||||
[link building.configuring_boost_build Configuring Boost.Build]
|
||||
as detailed below.
|
||||
|
||||
If you're still having trouble, Someone on one of the following
|
||||
mailing lists may be able to help:
|
||||
|
||||
* The _bb_list_ for issues related to Boost.Build
|
||||
* The _bp_list_ for issues specifically related to Boost.Python
|
||||
|
||||
[endsect]
|
||||
[section In Case Everything Seemed to Work]
|
||||
|
||||
Rejoice! If you're new to Boost.Python, at this point it might be
|
||||
a good idea to ignore build issues for a while and concentrate on
|
||||
learning the library by going through the _tutorial_ and perhaps
|
||||
some of the _reference_, trying out what you've
|
||||
learned about the API by modifying the quickstart project.
|
||||
|
||||
[endsect]
|
||||
[section Modifying the Example Project]
|
||||
|
||||
If you're content to keep your extension module forever in one
|
||||
source file called `extending.cpp`, inside your Boost.Python
|
||||
distribution, and import it forever as `extending`, then you can
|
||||
stop here. However, it's likely that you will want to make a few
|
||||
changes. There are a few things you can do without having to learn
|
||||
_bb_ in depth.
|
||||
|
||||
The project you just built is specified in two files in the current
|
||||
directory: `boost-build.jam`, which tells `bjam` where it can
|
||||
find the interpreted code of the Boost build system, and
|
||||
`Jamroot`, which describes the targets you just built. These
|
||||
files are heavily commented, so they should be easy to modify.
|
||||
Take care, however, to preserve whitespace. Punctuation such as
|
||||
`;` will not be recognized as intended by `bjam` if it is not
|
||||
surrounded by whitespace.
|
||||
|
||||
[section Relocate the Project]
|
||||
|
||||
You'll probably want to copy this project elsewhere so you can
|
||||
change it without modifying your Boost distribution. To do that,
|
||||
simply
|
||||
|
||||
a. copy the entire `example/quickstart/` directory
|
||||
into a new directory.
|
||||
|
||||
b. In the new copies of `boost-build.jam` and `Jamroot`, locate
|
||||
the relative path near the top of the file that is clearly
|
||||
marked by a comment, and edit that path so that it refers to the
|
||||
same directory your Boost distribution as it referred to when
|
||||
the file was in its original location in the
|
||||
`example/quickstart/` directory.
|
||||
|
||||
For example, if you moved the project from
|
||||
`/home/dave/boost_1_34_0/libs/python/example/quickstart` to
|
||||
`/home/dave/my-project`, you could change the first path in
|
||||
`boost-build.jam` from
|
||||
``
|
||||
../../../../tools/build/src
|
||||
``
|
||||
to
|
||||
``
|
||||
/home/dave/boost_1_34_0/tools/build/src
|
||||
``
|
||||
and change the first path in `Jamroot` from
|
||||
``
|
||||
../../../..
|
||||
``
|
||||
to
|
||||
``
|
||||
/home/dave/boost_1_34_0
|
||||
``
|
||||
|
||||
[endsect]
|
||||
[section Add New or Change Names of Existing Source Files]
|
||||
|
||||
The names of additional source files involved in building your
|
||||
extension module or embedding application can be listed in
|
||||
`Jamroot` right alongside `extending.cpp` or `embedding.cpp`
|
||||
respectively. Just be sure to leave whitespace around each
|
||||
filename:
|
||||
``
|
||||
… file1.cpp file2.cpp file3.cpp …
|
||||
``
|
||||
Naturally, if you want to change the name of a source file you can
|
||||
tell Boost.Build about it by editing the name in `Jamroot`.
|
||||
|
||||
[endsect]
|
||||
[section Change the Name of your Extension Module]
|
||||
|
||||
The name of the extension module is determined by two things:
|
||||
|
||||
# the name in `Jamroot` immediately following `python-extension`, and
|
||||
# the name passed to `BOOST_PYTHON_MODULE` in `extending.cpp`.
|
||||
|
||||
To change the name of the extension module from `extending` to
|
||||
`hello`, you'd edit `Jamroot`, changing
|
||||
``
|
||||
python-extension extending : extending.cpp ;
|
||||
``
|
||||
to
|
||||
``
|
||||
python-extension hello : extending.cpp ;
|
||||
``
|
||||
and you'd edit extending.cpp, changing
|
||||
|
||||
``
|
||||
BOOST_PYTHON_MODULE(extending)
|
||||
``
|
||||
to
|
||||
``
|
||||
BOOST_PYTHON_MODULE(hello)
|
||||
``
|
||||
[endsect]
|
||||
[endsect]
|
||||
[endsect]
|
||||
[section Installing Boost.Python on your System]
|
||||
|
||||
Since Boost.Python is a separately-compiled (as opposed to
|
||||
`header-only`) library, its user relies on the services of a
|
||||
Boost.Python library binary.
|
||||
|
||||
If you need a regular installation of the Boost.Python library
|
||||
binaries on your system, the _gsg_ will
|
||||
walk you through the steps of creating one. If building binaries
|
||||
from source, you might want to supply the `--with-python`
|
||||
argument to `bjam` (or the `--with-libraries=python` argument
|
||||
to `configure`), so only the Boost.Python binary will be built,
|
||||
rather than all the Boost binaries.
|
||||
|
||||
[endsect]
|
||||
[section Configuring Boost.Build]
|
||||
|
||||
As described in the [@http://www.boost.org/build/doc/html/bbv2/overview/configuration.html Boost.Build Reference Manual], a file called
|
||||
`user-config.jam` in your home directory is used to
|
||||
specify the tools and libraries available to the build system. You
|
||||
may need to create or edit `user-config.jam` to tell Boost.Build
|
||||
how to invoke Python, `#include` its headers, and link with its
|
||||
libraries.
|
||||
|
||||
[note If you are using a unix-variant OS and you ran Boost's
|
||||
`configure` script, it may have generated a
|
||||
`user-config.jam` for you. [footnote `configure` overwrites the existing
|
||||
`user-config.jam` in your home directory (if any) after making a backup of
|
||||
the old version.] If your `configure`\ /\ `make` sequence was successful and
|
||||
Boost.Python binaries were built, your `user-config.jam` file is probably already
|
||||
correct.]
|
||||
|
||||
If you have one fairly “standard” python installation for your
|
||||
platform, you might not need to do anything special to describe it. If
|
||||
you haven't configured python in `user-config.jam` (and you don't
|
||||
specify `--without-python` on the Boost.Build command line),
|
||||
Boost.Build will automatically execute the equivalent of
|
||||
|
||||
``
|
||||
import toolset : using ;
|
||||
using python ;
|
||||
``
|
||||
which automatically looks for Python in the most likely places.
|
||||
However, that only happens when using the Boost.Python project file
|
||||
(e.g. when referred to by another project as in the quickstart
|
||||
method). If instead you are linking against separately-compiled
|
||||
Boost.Python binaries, you should set up a `user-config.jam` file
|
||||
with at least the minimal incantation above.
|
||||
|
||||
[section Python Configuration Parameters]
|
||||
|
||||
If you have several versions of Python installed, or Python is
|
||||
installed in an unusual way, you may want to supply any or all of
|
||||
the following optional parameters to `using python`.
|
||||
|
||||
[variablelist
|
||||
[[version]
|
||||
|
||||
[the version of Python to use. Should be in Major.Minor
|
||||
format, for example, `2.3`. Do not include the subminor
|
||||
version (i.e. *not* `2.5.1`). If you have multiple Python
|
||||
versions installed, the version will usually be the only
|
||||
configuration argument required.]]
|
||||
|
||||
[[cmd-or-prefix]
|
||||
|
||||
[preferably, a command that invokes a Python interpreter.
|
||||
Alternatively, the installation prefix for Python libraries and
|
||||
header files. Only use the alternative formulation if there is
|
||||
no appropriate Python executable available.]]
|
||||
|
||||
[[*includes*]
|
||||
|
||||
[the `#include` paths for Python headers. Normally the correct
|
||||
path(s) will be automatically deduced from `version` and/or
|
||||
`cmd-or-prefix`.]]
|
||||
|
||||
[[*libraries*]
|
||||
|
||||
[the path to Python library binaries. On MacOS/Darwin,
|
||||
you can also pass the path of the Python framework. Normally the
|
||||
correct path(s) will be automatically deduced from `version`
|
||||
and/or `cmd-or-prefix`.]]
|
||||
|
||||
[[*condition*]
|
||||
|
||||
[if specified, should be a set of Boost.Build
|
||||
properties that are matched against the build configuration when
|
||||
Boost.Build selects a Python configuration to use. See examples
|
||||
below for details.]]
|
||||
|
||||
[[*extension-suffix*]
|
||||
|
||||
[A string to append to the name of extension
|
||||
modules before the true filename extension. You almost certainly
|
||||
don't need to use this. Usually this suffix is only used when
|
||||
targeting a Windows debug build of Python, and will be set
|
||||
automatically for you based on the value of the
|
||||
[link building.python_debugging_builds <python-debugging>] feature.
|
||||
However, at least one Linux distribution (Ubuntu Feisty Fawn) has
|
||||
a specially configured [@https://wiki.ubuntu.com/PyDbgBuilds <python-dbg>]
|
||||
package that claims to use such a suffix.]]
|
||||
]
|
||||
|
||||
[endsect]
|
||||
[section Examples]
|
||||
|
||||
Note that in the examples below, case and *especially whitespace* are
|
||||
significant.
|
||||
|
||||
* If you have both python 2.5 and python 2.4 installed,
|
||||
`user-config.jam` might contain
|
||||
|
||||
``
|
||||
using python : 2.5 ; # Make both versions of Python available
|
||||
using python : 2.4 ; # To build with python 2.4, add python=2.4
|
||||
# to your command line.
|
||||
``
|
||||
The first version configured (2.5) becomes the default. To build
|
||||
against python 2.4, add `python=2.4` to the `bjam` command line.
|
||||
|
||||
* If you have python installed in an unusual location, you might
|
||||
supply the path to the interpreter in the `cmd-or-prefix`
|
||||
parameter:
|
||||
|
||||
``
|
||||
using python : : /usr/local/python-2.6-beta/bin/python ;
|
||||
``
|
||||
|
||||
* If you have a separate build of Python for use with a particular
|
||||
toolset, you might supply that toolset in the `condition`
|
||||
parameter:
|
||||
|
||||
``
|
||||
using python ; # use for most toolsets
|
||||
|
||||
# Use with Intel C++ toolset
|
||||
using python
|
||||
: # version
|
||||
: c:\\Devel\\Python-2.5-IntelBuild\\PCBuild\\python # cmd-or-prefix
|
||||
: # includes
|
||||
: # libraries
|
||||
: <toolset>intel # condition
|
||||
;
|
||||
``
|
||||
|
||||
* If you have downloaded the Python sources and built both the
|
||||
normal and the [link building.python_debugging_builds "python debugging"]
|
||||
builds from source on Windows, you might see:
|
||||
|
||||
``
|
||||
using python : 2.5 : C:\\src\\Python-2.5\\PCBuild\\python ;
|
||||
using python : 2.5 : C:\\src\\Python-2.5\\PCBuild\\python_d
|
||||
: # includes
|
||||
: # libs
|
||||
: <python-debugging>on ;
|
||||
``
|
||||
* You can set up your user-config.jam so a bjam built under Windows
|
||||
can build/test both Windows and Cygwin_ python extensions. Just pass
|
||||
`<target-os>cygwin` in the `condition` parameter
|
||||
for the cygwin python installation:
|
||||
|
||||
``
|
||||
# windows installation
|
||||
using python ;
|
||||
|
||||
# cygwin installation
|
||||
using python : : c:\\cygwin\\bin\\python2.5 : : : <target-os>cygwin ;
|
||||
``
|
||||
when you put target-os=cygwin in your build request, it should build
|
||||
with the cygwin version of python: [#flavor]_
|
||||
|
||||
``
|
||||
bjam target-os=cygwin toolset=gcc
|
||||
``
|
||||
This is supposed to work the other way, too (targeting windows
|
||||
python with a [@http://cygwin.com Cygwin] bjam) but it seems as though the support in
|
||||
Boost.Build's toolsets for building that way is broken at the
|
||||
time of this writing.
|
||||
|
||||
* Note that because of [@http://zigzag.cs.msu.su/boost.build/wiki/AlternativeSelection
|
||||
the way Boost.Build currently selects target alternatives], you might have be very
|
||||
explicit in your build requests. For example, given:
|
||||
|
||||
``
|
||||
using python : 2.5 ; # a regular windows build
|
||||
using python : 2.4 : : : : <target-os>cygwin ;
|
||||
``
|
||||
building with
|
||||
``
|
||||
bjam target-os=cygwin
|
||||
``
|
||||
|
||||
will yield an error. Instead, you'll need to write
|
||||
|
||||
``
|
||||
bjam target-os=cygwin/python=2.4
|
||||
``
|
||||
|
||||
[endsect]
|
||||
[endsect]
|
||||
[section Choosing a Boost.Python Library Binary]
|
||||
|
||||
If—instead of letting Boost.Build construct and link with the right
|
||||
libraries automatically—you choose to use a pre-built Boost.Python
|
||||
library, you'll need to think about which one to link with. The
|
||||
Boost.Python binary comes in both static and dynamic flavors. Take
|
||||
care to choose the right flavor for your application. [footnote
|
||||
Information about how to identify the static and dynamic builds of Boost.Python on
|
||||
[@http://boost.org/more/getting_started/windows.html#library-naming Windows] /
|
||||
[@http://boost.org/more/getting_started/unix-variants.html#library-naming Unix variants]]
|
||||
|
||||
[section The Dynamic Binary]
|
||||
|
||||
The dynamic library is the safest and most-versatile choice:
|
||||
|
||||
* A single copy of the library code is used by all extension
|
||||
modules built with a given toolset. [footnote Because of the way most \*nix platforms
|
||||
share symbols among dynamically-loaded objects, I'm not certain
|
||||
that extension modules built with different compiler toolsets
|
||||
will always use different copies of the Boost.Python library
|
||||
when loaded into the same Python instance. Not using different
|
||||
libraries could be a good thing if the compilers have compatible
|
||||
ABIs, because extension modules built with the two libraries
|
||||
would be interoperable. Otherwise, it could spell disaster,
|
||||
since an extension module and the Boost.Python library would
|
||||
have different ideas of such things as class layout. I would
|
||||
appreciate someone doing the experiment to find out what
|
||||
happens.]
|
||||
|
||||
* The library contains a type conversion registry. Because one
|
||||
registry is shared among all extension modules, instances of a
|
||||
class exposed to Python in one dynamically-loaded extension
|
||||
module can be passed to functions exposed in another such module.
|
||||
|
||||
[endsect]
|
||||
[section The Static Binary]
|
||||
|
||||
It might be appropriate to use the static Boost.Python library in
|
||||
any of the following cases:
|
||||
|
||||
* You are _extending_ python and the types exposed in your
|
||||
dynamically-loaded extension module don't need to be used by any
|
||||
other Boost.Python extension modules, and you don't care if the
|
||||
core library code is duplicated among them.
|
||||
|
||||
* You are _embedding_ python in your application and either:
|
||||
|
||||
* You are targeting a Unix variant OS other than MacOS or AIX,
|
||||
where the dynamically-loaded extension modules can “see” the
|
||||
Boost.Python library symbols that are part of the executable.
|
||||
|
||||
* Or, you have statically linked some Boost.Python extension
|
||||
modules into your application and you don't care if any
|
||||
dynamically-loaded Boost.Python extension modules are able to
|
||||
use the types exposed by your statically-linked extension
|
||||
modules (and vice-versa).
|
||||
|
||||
[endsect]
|
||||
[endsect]
|
||||
[section `#include` Issues]
|
||||
|
||||
1. If you should ever have occasion to `#include "python.h"`
|
||||
directly in a translation unit of a program using Boost.Python,
|
||||
use `#include "boost/python/detail/wrap_python.hpp"` instead.
|
||||
It handles several issues necessary for use with Boost.Python,
|
||||
one of which is mentioned in the next section.
|
||||
|
||||
2. Be sure not to `#include` any system headers before
|
||||
`wrap_python.hpp`. This restriction is actually imposed by
|
||||
Python, or more properly, by Python's interaction with your
|
||||
operating system. See
|
||||
[@http://docs.python.org/ext/simpleExample.html] for details.
|
||||
|
||||
[endsect]
|
||||
[section Python Debugging Builds]
|
||||
|
||||
Python can be built in a special “python debugging” configuration
|
||||
that adds extra checks and instrumentation that can be very useful
|
||||
for developers of extension modules. The data structures used by
|
||||
the debugging configuration contain additional members, so *a
|
||||
Python executable built with python debugging enabled cannot be
|
||||
used with an extension module or library compiled without it, and
|
||||
vice-versa.*
|
||||
|
||||
Since pre-built “python debugging” versions of the Python
|
||||
executable and libraries are not supplied with most distributions
|
||||
of Python, [footnote On Unix and similar platforms, a debugging python and associated libraries are built by adding --with-pydebug when configuring the Python build. On Windows, the debugging version of Python is generated by the "Win32 Debug" target of the Visual Studio project in the PCBuild subdirectory of a full Python source code distribution.] and we didn't want to force our users
|
||||
to build them, Boost.Build does not automatically enable python
|
||||
debugging in its `debug` build variant (which is the default).
|
||||
Instead there is a special build property called
|
||||
`python-debugging` that, when used as a build property, will
|
||||
define the right preprocessor symbols and select the right
|
||||
libraries to link with.
|
||||
|
||||
On unix-variant platforms, the debugging versions of Python's data
|
||||
structures will only be used if the symbol `Py_DEBUG` is defined.
|
||||
On many windows compilers, when extension modules are built with
|
||||
the preprocessor symbol `_DEBUG`, Python defaults to force
|
||||
linking with a special debugging version of the Python DLL. Since
|
||||
that symbol is very commonly used even when Python is not present,
|
||||
Boost.Python temporarily undefines `_DEBUG` when `Python.h`
|
||||
is #included from `boost/python/detail/wrap_python.hpp` - unless
|
||||
`BOOST_DEBUG_PYTHON` is defined. The upshot is that if you want
|
||||
“python debugging”and you aren't using Boost.Build, you should make
|
||||
sure `BOOST_DEBUG_PYTHON` is defined, or python debugging will be
|
||||
suppressed.
|
||||
|
||||
[endsect]
|
||||
[section Testing Boost.Python]
|
||||
|
||||
To run the full test suite for Boost.Python, invoke `bjam` in the
|
||||
`test` subdirectory of your Boost.Python distribution.
|
||||
|
||||
[endsect]
|
||||
[section Notes for MinGW (and Cygwin with -mno-cygwin) GCC Users]
|
||||
|
||||
If you are using a version of Python prior to 2.4.1 with a MinGW
|
||||
prior to 3.0.0 (with binutils-2.13.90-20030111-1), you will need to
|
||||
create a MinGW-compatible version of the Python library; the one
|
||||
shipped with Python will only work with a Microsoft-compatible
|
||||
linker. Follow the instructions in the “Non-Microsoft” section of
|
||||
the “Building Extensions: Tips And Tricks” chapter in
|
||||
[@https://docs.python.org/2/install/index.html Installing Python Modules]
|
||||
to create `libpythonXX.a`, where `XX` corresponds to the major and minor
|
||||
version numbers of your Python installation.
|
||||
|
||||
[endsect]
|
||||
681
doc/building.rst
Normal file
@@ -0,0 +1,681 @@
|
||||
.. Copyright David Abrahams 2006. Distributed under the Boost
|
||||
.. Software License, Version 1.0. (See accompanying
|
||||
.. file LICENSE_1_0.txt or copy at
|
||||
.. http://www.boost.org/LICENSE_1_0.txt)
|
||||
|
||||
==============================================
|
||||
|(logo)|__ Boost.Python Build and Test HOWTO
|
||||
==============================================
|
||||
|
||||
.. |(logo)| image:: ../../../boost.png
|
||||
:alt: Boost C++ Libraries:
|
||||
:class: boost-logo
|
||||
|
||||
__ ../index.htm
|
||||
|
||||
|
||||
.. section-numbering::
|
||||
:depth: 2
|
||||
|
||||
.. contents:: Contents
|
||||
:depth: 2
|
||||
:class: sidebar small
|
||||
|
||||
.. |newer| replace:: *newer*
|
||||
|
||||
Requirements
|
||||
============
|
||||
|
||||
Boost.Python requires `Python 2.2`_ [#2.2]_ *or* |newer|__.
|
||||
|
||||
.. _Python 2.2: http://www.python.org/2.2
|
||||
__ http://www.python.org
|
||||
|
||||
Background
|
||||
==========
|
||||
|
||||
There are two basic models for combining C++ and Python:
|
||||
|
||||
- extending_, in which the end-user launches the Python interpreter
|
||||
executable and imports Python “extension modules” written in C++.
|
||||
Think of taking a library written in C++ and giving it a Python
|
||||
interface so Python programmers can use it. From Python, these
|
||||
modules look just like regular Python modules.
|
||||
|
||||
- embedding_, in which the end-user launches a program written
|
||||
in C++ that in turn invokes the Python interpreter as a library
|
||||
subroutine. Think of adding scriptability to an existing
|
||||
application.
|
||||
|
||||
.. _extending: http://www.python.org/doc/current/ext/intro.html
|
||||
.. _embedding: http://www.python.org/doc/current/ext/embedding.html
|
||||
|
||||
The key distinction between extending and embedding is the location
|
||||
of the C++ ``main()`` function: in the Python interpreter executable,
|
||||
or in some other program, respectively. Note that even when
|
||||
embedding Python in another program, `extension modules are often
|
||||
the best way to make C/C++ functionality accessible to Python
|
||||
code`__, so the use of extension modules is really at the heart of
|
||||
both models.
|
||||
|
||||
__ http://www.python.org/doc/current/ext/extending-with-embedding.html
|
||||
|
||||
Except in rare cases, extension modules are built as
|
||||
dynamically-loaded libraries with a single entry point, which means
|
||||
you can change them without rebuilding either the other extension
|
||||
modules or the executable containing ``main()``.
|
||||
|
||||
.. _quickstart:
|
||||
|
||||
No-Install Quickstart
|
||||
=====================
|
||||
|
||||
There is no need to “install Boost” in order to get started using
|
||||
Boost.Python. These instructions use Boost.Build_ projects,
|
||||
which will build those binaries as soon as they're needed. Your
|
||||
first tests may take a little longer while you wait for
|
||||
Boost.Python to build, but doing things this way will save you from
|
||||
worrying about build intricacies like which library binaries to use
|
||||
for a specific compiler configuration and figuring out the right
|
||||
compiler options to use yourself.
|
||||
|
||||
.. .. raw:: html
|
||||
|
||||
<div style="width:50%">
|
||||
|
||||
.. Note:: Of course it's possible to use other build systems to
|
||||
build Boost.Python and its extensions, but they are not
|
||||
officially supported by Boost. Moreover **99% of all “I can't
|
||||
build Boost.Python” problems come from trying to use another
|
||||
build system** without first following these instructions.
|
||||
|
||||
If you want to use another system anyway, we suggest that you
|
||||
follow these instructions, and then invoke ``bjam`` with the
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
``-a -o``\ *filename*
|
||||
|
||||
options to dump the build commands it executes to a file, so
|
||||
you can see what your alternate build system needs to do.
|
||||
|
||||
.. .. raw:: html
|
||||
|
||||
</div>
|
||||
|
||||
.. _Boost.Build: ../../../tools/build/index.html
|
||||
|
||||
Basic Procedure
|
||||
---------------
|
||||
|
||||
1. Get Boost; see sections 1 and 2 [`Unix/Linux`__, `Windows`__\ ] of the
|
||||
Boost `Getting Started Guide`_.
|
||||
|
||||
__ ../../../more/getting_started/unix-variants.html#get-boost
|
||||
__ ../../../more/getting_started/windows.html#get-boost
|
||||
|
||||
2. Get the ``bjam`` build driver. See section 5 [`Unix/Linux`__,
|
||||
`Windows`__\ ] of the Boost `Getting Started Guide`_.
|
||||
|
||||
__ ../../../more/getting_started/unix-variants.html#prepare-to-use-a-boost-library-binary
|
||||
__ ../../../more/getting_started/windows.html#prepare-to-use-a-boost-library-binary
|
||||
|
||||
|
||||
3. cd into the ``libs/python/example/quickstart/`` directory of your
|
||||
Boost installation, which contains a small example project.
|
||||
|
||||
4. Invoke ``bjam``. Replace the “\ ``stage``\ “ argument from the
|
||||
example invocation from section 5 of the `Getting Started
|
||||
Guide`_ with “\ ``test``\ ,“ to build all the test targets. Also add
|
||||
the argument “\ ``--verbose-test``\ ” to see the output generated by
|
||||
the tests when they are run.
|
||||
|
||||
On Windows, your ``bjam`` invocation might look something like:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
C:\\boost_1_34_0\\…\\quickstart> **bjam toolset=msvc --verbose-test test**
|
||||
|
||||
and on Unix variants, perhaps,
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
~/boost_1_34_0/…/quickstart$ **bjam toolset=gcc --verbose-test test**
|
||||
|
||||
.. Admonition:: Note to Windows Users
|
||||
|
||||
For the sake of concision, the rest of this guide will use
|
||||
unix-style forward slashes in pathnames instead of the
|
||||
backslashes with which you may be more familiar. The forward
|
||||
slashes should work everywhere except in `Command Prompt`_
|
||||
windows, where you should use backslashes.
|
||||
|
||||
.. _Command Prompt: ../../../more/getting_started/windows.html#command-prompt
|
||||
|
||||
If you followed this procedure successfully, you will have built an
|
||||
extension module called ``extending`` and tested it by running a
|
||||
Python script called ``test_extending.py``. You will also have
|
||||
built and run a simple application called ``embedding`` that embeds
|
||||
python.
|
||||
|
||||
.. _Getting Started Guide: ../../../more/getting_started/index.html
|
||||
|
||||
In Case of Trouble
|
||||
------------------
|
||||
|
||||
If you're seeing lots of compiler and/or linker error messages,
|
||||
it's probably because Boost.Build is having trouble finding your
|
||||
Python installation. You might want to pass the
|
||||
``--debug-configuration`` option to ``bjam`` the first few times
|
||||
you invoke it, to make sure that Boost.Build is correctly locating
|
||||
all the parts of your Python installation. If it isn't, consider
|
||||
`Configuring Boost.Build`_ as detailed below.
|
||||
|
||||
If you're still having trouble, Someone on one of the following
|
||||
mailing lists may be able to help:
|
||||
|
||||
* The `Boost.Build mailing list`__ for issues related to Boost.Build
|
||||
* The Python `C++ Sig`__ for issues specifically related to Boost.Python
|
||||
|
||||
__ ../../../more/mailing_lists.htm#jamboost
|
||||
__ ../../../more/mailing_lists.htm#cplussig
|
||||
|
||||
In Case Everything Seemed to Work
|
||||
---------------------------------
|
||||
|
||||
Rejoice! If you're new to Boost.Python, at this point it might be
|
||||
a good idea to ignore build issues for a while and concentrate on
|
||||
learning the library by going through the tutorial_ and perhaps
|
||||
some of the `reference documentation`_, trying out what you've
|
||||
learned about the API by modifying the quickstart project.
|
||||
|
||||
.. _reference documentation: v2/reference.html
|
||||
.. _tutorial: tutorial/index.html
|
||||
|
||||
Modifying the Example Project
|
||||
-----------------------------
|
||||
|
||||
If you're content to keep your extension module forever in one
|
||||
source file called |extending.cpp|_, inside your Boost
|
||||
distribution, and import it forever as ``extending``, then you can
|
||||
stop here. However, it's likely that you will want to make a few
|
||||
changes. There are a few things you can do without having to learn
|
||||
Boost.Build_ in depth.
|
||||
|
||||
The project you just built is specified in two files in the current
|
||||
directory: |boost-build.jam|_, which tells ``bjam`` where it can
|
||||
find the interpreted code of the Boost build system, and
|
||||
|Jamroot|_, which describes the targets you just built. These
|
||||
files are heavily commented, so they should be easy to modify.
|
||||
Take care, however, to preserve whitespace. Punctuation such as
|
||||
``;`` will not be recognized as intended by ``bjam`` if it is not
|
||||
surrounded by whitespace.
|
||||
|
||||
.. |boost-build.jam| replace:: ``boost-build.jam``
|
||||
.. _boost-build.jam: ../example/quickstart/boost-build.jam
|
||||
|
||||
.. |Jamroot| replace:: ``Jamroot``
|
||||
.. _Jamroot: ../example/quickstart/Jamroot
|
||||
|
||||
.. |extending.cpp| replace:: ``extending.cpp``
|
||||
.. _extending.cpp: ../example/quickstart/extending.cpp
|
||||
|
||||
Relocate the Project
|
||||
....................
|
||||
|
||||
You'll probably want to copy this project elsewhere so you can
|
||||
change it without modifying your Boost distribution. To do that,
|
||||
simply
|
||||
|
||||
a. copy the entire ``libs/python/example/quickstart/`` directory
|
||||
into a new directory.
|
||||
|
||||
b. In the new copies of |boost-build.jam|_ and |Jamroot|_, locate
|
||||
the relative path near the top of the file that is clearly
|
||||
marked by a comment, and edit that path so that it refers to the
|
||||
same directory your Boost distribution as it referred to when
|
||||
the file was in its original location in the
|
||||
``libs/python/example/quickstart/`` directory.
|
||||
|
||||
For example, if you moved the project from
|
||||
``/home/dave/boost_1_34_0/libs/python/example/quickstart`` to
|
||||
``/home/dave/my-project``, you could change the first path in
|
||||
|boost-build.jam|_ from
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
**../../../..**\ /tools/build/v2
|
||||
|
||||
to
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
**/home/dave/boost_1_34_0**\ /tools/build/v2
|
||||
|
||||
and change the first path in |Jamroot|_ from
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
**../../../..**
|
||||
|
||||
to
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
**/home/dave/boost_1_34_0**
|
||||
|
||||
Add New or Change Names of Existing Source Files
|
||||
................................................
|
||||
|
||||
The names of additional source files involved in building your
|
||||
extension module or embedding application can be listed in
|
||||
|Jamroot|_ right alongside ``extending.cpp`` or ``embedding.cpp``
|
||||
respectively. Just be sure to leave whitespace around each
|
||||
filename::
|
||||
|
||||
… file1.cpp file2.cpp file3.cpp …
|
||||
|
||||
Naturally, if you want to change the name of a source file you can
|
||||
tell Boost.Build about it by editing the name in |Jamroot|_.
|
||||
|
||||
Change the Name of your Extension Module
|
||||
........................................
|
||||
|
||||
The name of the extension module is determined by two things:
|
||||
|
||||
1. the name in |Jamroot|_ immediately following ``python-extension``, and
|
||||
2. the name passed to ``BOOST_PYTHON_MODULE`` in |extending.cpp|_.
|
||||
|
||||
To change the name of the extension module from ``extending`` to
|
||||
``hello``, you'd edit |Jamroot|_, changing
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
python-extension **extending** : extending.cpp ;
|
||||
|
||||
to
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
python-extension **hello** : extending.cpp ;
|
||||
|
||||
and you'd edit extending.cpp, changing
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
BOOST_PYTHON_MODULE(\ **extending**\ )
|
||||
|
||||
to
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
BOOST_PYTHON_MODULE(\ **hello**\ )
|
||||
|
||||
Installing Boost.Python on your System
|
||||
======================================
|
||||
|
||||
Since Boost.Python is a separately-compiled (as opposed to
|
||||
`header-only`_) library, its user relies on the services of a
|
||||
Boost.Python library binary.
|
||||
|
||||
.. _header-only: ../../../more/getting_started/windows.html#header-only-libraries
|
||||
|
||||
If you need a regular installation of the Boost.Python library
|
||||
binaries on your system, the Boost `Getting Started Guide`_ will
|
||||
walk you through the steps of creating one. If building binaries
|
||||
from source, you might want to supply the ``--with-python``
|
||||
argument to ``bjam`` (or the ``--with-libraries=python`` argument
|
||||
to ``configure``), so only the Boost.Python binary will be built,
|
||||
rather than all the Boost binaries.
|
||||
|
||||
|
||||
Configuring Boost.Build
|
||||
=======================
|
||||
|
||||
As described in the `Boost.Build reference manual`__, a file called
|
||||
``user-config.jam`` in your home directory [#home-dir]_ is used to
|
||||
specify the tools and libraries available to the build system. You
|
||||
may need to create or edit ``user-config.jam`` to tell Boost.Build
|
||||
how to invoke Python, ``#include`` its headers, and link with its
|
||||
libraries.
|
||||
|
||||
__ http://www.boost.orgdoc/html/bbv2/advanced.html#bbv2.advanced.configuration
|
||||
|
||||
.. Admonition:: Users of Unix-Variant OSes
|
||||
|
||||
If you are using a unix-variant OS and you ran Boost's
|
||||
``configure`` script, it may have generated a
|
||||
``user-config.jam`` for you. [#overwrite]_ If your ``configure``\
|
||||
/\ ``make`` sequence was successful and Boost.Python binaries
|
||||
were built, your ``user-config.jam`` file is probably already
|
||||
correct.
|
||||
|
||||
If you have one fairly “standard” python installation for your
|
||||
platform, you might not need to do anything special to describe it. If
|
||||
you haven't configured python in ``user-config.jam`` (and you don't
|
||||
specify ``--without-python`` on the Boost.Build command line),
|
||||
Boost.Build will automatically execute the equivalent of ::
|
||||
|
||||
import toolset : using ;
|
||||
using python ;
|
||||
|
||||
which automatically looks for Python in the most likely places.
|
||||
However, that only happens when using the Boost.Python project file
|
||||
(e.g. when referred to by another project as in the quickstart_
|
||||
method). If instead you are linking against separately-compiled
|
||||
Boost.Python binaries, you should set up a ``user-config.jam`` file
|
||||
with at least the minimal incantation above.
|
||||
|
||||
Python Configuration Parameters
|
||||
-------------------------------
|
||||
|
||||
If you have several versions of Python installed, or Python is
|
||||
installed in an unusual way, you may want to supply any or all of
|
||||
the following optional parameters to ``using python``.
|
||||
|
||||
version
|
||||
the version of Python to use. Should be in Major.Minor
|
||||
format, for example, ``2.3``. Do not include the subminor
|
||||
version (i.e. *not* ``2.5.1``). If you have multiple Python
|
||||
versions installed, the version will usually be the only
|
||||
configuration argument required.
|
||||
|
||||
cmd-or-prefix
|
||||
preferably, a command that invokes a Python interpreter.
|
||||
Alternatively, the installation prefix for Python libraries and
|
||||
header files. Only use the alternative formulation if there is
|
||||
no appropriate Python executable available.
|
||||
|
||||
includes
|
||||
the ``#include`` paths for Python headers. Normally the correct
|
||||
path(s) will be automatically deduced from ``version`` and/or
|
||||
``cmd-or-prefix``.
|
||||
|
||||
libraries
|
||||
the path to Python library binaries. On MacOS/Darwin,
|
||||
you can also pass the path of the Python framework. Normally the
|
||||
correct path(s) will be automatically deduced from ``version``
|
||||
and/or ``cmd-or-prefix``.
|
||||
|
||||
condition
|
||||
if specified, should be a set of Boost.Build
|
||||
properties that are matched against the build configuration when
|
||||
Boost.Build selects a Python configuration to use. See examples
|
||||
below for details.
|
||||
|
||||
extension-suffix
|
||||
A string to append to the name of extension
|
||||
modules before the true filename extension. You almost certainly
|
||||
don't need to use this. Usually this suffix is only used when
|
||||
targeting a Windows debug build of Python, and will be set
|
||||
automatically for you based on the value of the
|
||||
|python-debugging|_ feature. However, at least one Linux
|
||||
distribution (Ubuntu Feisty Fawn) has a specially configured
|
||||
`python-dbg`__ package that claims to use such a suffix.
|
||||
|
||||
.. |python-debugging| replace:: ``<python-debugging>``
|
||||
|
||||
__ https://wiki.ubuntu.com/PyDbgBuilds
|
||||
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
Note that in the examples below, case and *especially whitespace* are
|
||||
significant.
|
||||
|
||||
- If you have both python 2.5 and python 2.4 installed,
|
||||
``user-config.jam`` might contain::
|
||||
|
||||
using python : 2.5 ; # Make both versions of Python available
|
||||
|
||||
using python : 2.4 ; # To build with python 2.4, add python=2.4
|
||||
# to your command line.
|
||||
|
||||
The first version configured (2.5) becomes the default. To build
|
||||
against python 2.4, add ``python=2.4`` to the ``bjam`` command line.
|
||||
|
||||
- If you have python installed in an unusual location, you might
|
||||
supply the path to the interpreter in the ``cmd-or-prefix``
|
||||
parameter::
|
||||
|
||||
using python : : /usr/local/python-2.6-beta/bin/python ;
|
||||
|
||||
- If you have a separate build of Python for use with a particular
|
||||
toolset, you might supply that toolset in the ``condition``
|
||||
parameter::
|
||||
|
||||
using python ; # use for most toolsets
|
||||
|
||||
# Use with Intel C++ toolset
|
||||
using python
|
||||
: # version
|
||||
: c:\\Devel\\Python-2.5-IntelBuild\\PCBuild\\python # cmd-or-prefix
|
||||
: # includes
|
||||
: # libraries
|
||||
: <toolset>intel # condition
|
||||
;
|
||||
|
||||
|
||||
- If you have downloaded the Python sources and built both the
|
||||
normal and the “\ `python debugging`_\ ” builds from source on
|
||||
Windows, you might see::
|
||||
|
||||
using python : 2.5 : C:\\src\\Python-2.5\\PCBuild\\python ;
|
||||
using python : 2.5 : C:\\src\\Python-2.5\\PCBuild\\python_d
|
||||
: # includes
|
||||
: # libs
|
||||
: <python-debugging>on ;
|
||||
|
||||
- You can set up your user-config.jam so a bjam built under Windows
|
||||
can build/test both Windows and Cygwin_ python extensions. Just pass
|
||||
``<target-os>cygwin`` in the ``condition`` parameter
|
||||
for the cygwin python installation::
|
||||
|
||||
# windows installation
|
||||
using python ;
|
||||
|
||||
# cygwin installation
|
||||
using python : : c:\\cygwin\\bin\\python2.5 : : : <target-os>cygwin ;
|
||||
|
||||
when you put target-os=cygwin in your build request, it should build
|
||||
with the cygwin version of python: [#flavor]_
|
||||
|
||||
bjam target-os=cygwin toolset=gcc
|
||||
|
||||
This is supposed to work the other way, too (targeting windows
|
||||
python with a Cygwin_ bjam) but it seems as though the support in
|
||||
Boost.Build's toolsets for building that way is broken at the
|
||||
time of this writing.
|
||||
|
||||
- Note that because of `the way Boost.Build currently selects target
|
||||
alternatives`__, you might have be very explicit in your build
|
||||
requests. For example, given::
|
||||
|
||||
using python : 2.5 ; # a regular windows build
|
||||
using python : 2.4 : : : : <target-os>cygwin ;
|
||||
|
||||
building with ::
|
||||
|
||||
bjam target-os=cygwin
|
||||
|
||||
will yield an error. Instead, you'll need to write::
|
||||
|
||||
bjam target-os=cygwin/python=2.4
|
||||
|
||||
.. _Cygwin: http://cygwin.com
|
||||
|
||||
__ http://zigzag.cs.msu.su/boost.build/wiki/AlternativeSelection
|
||||
|
||||
Choosing a Boost.Python Library Binary
|
||||
======================================
|
||||
|
||||
If—instead of letting Boost.Build construct and link with the right
|
||||
libraries automatically—you choose to use a pre-built Boost.Python
|
||||
library, you'll need to think about which one to link with. The
|
||||
Boost.Python binary comes in both static and dynamic flavors. Take
|
||||
care to choose the right flavor for your application. [#naming]_
|
||||
|
||||
The Dynamic Binary
|
||||
------------------
|
||||
|
||||
The dynamic library is the safest and most-versatile choice:
|
||||
|
||||
- A single copy of the library code is used by all extension
|
||||
modules built with a given toolset. [#toolset-specific]_
|
||||
|
||||
- The library contains a type conversion registry. Because one
|
||||
registry is shared among all extension modules, instances of a
|
||||
class exposed to Python in one dynamically-loaded extension
|
||||
module can be passed to functions exposed in another such module.
|
||||
|
||||
The Static Binary
|
||||
-----------------
|
||||
|
||||
It might be appropriate to use the static Boost.Python library in
|
||||
any of the following cases:
|
||||
|
||||
- You are extending_ python and the types exposed in your
|
||||
dynamically-loaded extension module don't need to be used by any
|
||||
other Boost.Python extension modules, and you don't care if the
|
||||
core library code is duplicated among them.
|
||||
|
||||
- You are embedding_ python in your application and either:
|
||||
|
||||
- You are targeting a Unix variant OS other than MacOS or AIX,
|
||||
where the dynamically-loaded extension modules can “see” the
|
||||
Boost.Python library symbols that are part of the executable.
|
||||
|
||||
- Or, you have statically linked some Boost.Python extension
|
||||
modules into your application and you don't care if any
|
||||
dynamically-loaded Boost.Python extension modules are able to
|
||||
use the types exposed by your statically-linked extension
|
||||
modules (and vice-versa).
|
||||
|
||||
``#include`` Issues
|
||||
===================
|
||||
|
||||
1. If you should ever have occasion to ``#include "python.h"``
|
||||
directly in a translation unit of a program using Boost.Python,
|
||||
use ``#include "boost/python/detail/wrap_python.hpp"`` instead.
|
||||
It handles several issues necessary for use with Boost.Python,
|
||||
one of which is mentioned in the next section.
|
||||
|
||||
2. Be sure not to ``#include`` any system headers before
|
||||
``wrap_python.hpp``. This restriction is actually imposed by
|
||||
Python, or more properly, by Python's interaction with your
|
||||
operating system. See
|
||||
http://docs.python.org/ext/simpleExample.html for details.
|
||||
|
||||
.. _python-debugging:
|
||||
.. _python debugging:
|
||||
|
||||
Python Debugging Builds
|
||||
=======================
|
||||
|
||||
Python can be built in a special “python debugging” configuration
|
||||
that adds extra checks and instrumentation that can be very useful
|
||||
for developers of extension modules. The data structures used by
|
||||
the debugging configuration contain additional members, so **a
|
||||
Python executable built with python debugging enabled cannot be
|
||||
used with an extension module or library compiled without it, and
|
||||
vice-versa.**
|
||||
|
||||
Since pre-built “python debugging” versions of the Python
|
||||
executable and libraries are not supplied with most distributions
|
||||
of Python, [#get-debug-build]_ and we didn't want to force our users
|
||||
to build them, Boost.Build does not automatically enable python
|
||||
debugging in its ``debug`` build variant (which is the default).
|
||||
Instead there is a special build property called
|
||||
``python-debugging`` that, when used as a build property, will
|
||||
define the right preprocessor symbols and select the right
|
||||
libraries to link with.
|
||||
|
||||
On unix-variant platforms, the debugging versions of Python's data
|
||||
structures will only be used if the symbol ``Py_DEBUG`` is defined.
|
||||
On many windows compilers, when extension modules are built with
|
||||
the preprocessor symbol ``_DEBUG``, Python defaults to force
|
||||
linking with a special debugging version of the Python DLL. Since
|
||||
that symbol is very commonly used even when Python is not present,
|
||||
Boost.Python temporarily undefines _DEBUG when Python.h
|
||||
is #included from ``boost/python/detail/wrap_python.hpp`` - unless
|
||||
``BOOST_DEBUG_PYTHON`` is defined. The upshot is that if you want
|
||||
“python debugging”and you aren't using Boost.Build, you should make
|
||||
sure ``BOOST_DEBUG_PYTHON`` is defined, or python debugging will be
|
||||
suppressed.
|
||||
|
||||
Testing Boost.Python
|
||||
====================
|
||||
|
||||
To run the full test suite for Boost.Python, invoke ``bjam`` in the
|
||||
``libs/python/test`` subdirectory of your Boost distribution.
|
||||
|
||||
Notes for MinGW (and Cygwin with -mno-cygwin) GCC Users
|
||||
=======================================================
|
||||
|
||||
If you are using a version of Python prior to 2.4.1 with a MinGW
|
||||
prior to 3.0.0 (with binutils-2.13.90-20030111-1), you will need to
|
||||
create a MinGW-compatible version of the Python library; the one
|
||||
shipped with Python will only work with a Microsoft-compatible
|
||||
linker. Follow the instructions in the “Non-Microsoft” section of
|
||||
the “Building Extensions: Tips And Tricks” chapter in `Installing
|
||||
Python Modules`__ to create ``libpythonXX.a``, where ``XX``
|
||||
corresponds to the major and minor version numbers of your Python
|
||||
installation.
|
||||
|
||||
__ http://www.python.org/doc/current/inst/index.html
|
||||
|
||||
-----------------------------
|
||||
|
||||
.. [#2.2] Note that although we tested earlier versions of
|
||||
Boost.Python with Python 2.2, and we don't *think* we've done
|
||||
anything to break compatibility, this release of Boost.Python
|
||||
may not have been tested with versions of Python earlier than
|
||||
2.4, so we're not 100% sure that python 2.2 and 2.3 are
|
||||
supported.
|
||||
|
||||
.. [#naming] Information about how to identify the
|
||||
static and dynamic builds of Boost.Python:
|
||||
|
||||
* `on Windows`__
|
||||
* `on Unix variants`__
|
||||
|
||||
__ ../../../more/getting_started/windows.html#library-naming
|
||||
__ ../../../more/getting_started/unix-variants.html#library-naming
|
||||
|
||||
.. [#toolset-specific] Because of the way most \*nix platforms
|
||||
share symbols among dynamically-loaded objects, I'm not certain
|
||||
that extension modules built with different compiler toolsets
|
||||
will always use different copies of the Boost.Python library
|
||||
when loaded into the same Python instance. Not using different
|
||||
libraries could be a good thing if the compilers have compatible
|
||||
ABIs, because extension modules built with the two libraries
|
||||
would be interoperable. Otherwise, it could spell disaster,
|
||||
since an extension module and the Boost.Python library would
|
||||
have different ideas of such things as class layout. I would
|
||||
appreciate someone doing the experiment to find out what
|
||||
happens.
|
||||
|
||||
.. [#overwrite] ``configure`` overwrites the existing
|
||||
``user-config.jam`` in your home directory
|
||||
(if any) after making a backup of the old version.
|
||||
|
||||
.. [#flavor] Note that the ``<target-os>cygwin`` feature is
|
||||
different from the ``<flavor>cygwin`` subfeature of the ``gcc``
|
||||
toolset, and you might need handle both explicitly if you also
|
||||
have a MinGW GCC installed.
|
||||
|
||||
.. [#home-dir] Windows users, your home directory can be
|
||||
found by typing::
|
||||
|
||||
ECHO %HOMEDRIVE%%HOMEPATH%
|
||||
|
||||
into a `command prompt`_ window.
|
||||
|
||||
.. [#get-debug-build] On Unix and similar platforms, a debugging
|
||||
python and associated libraries are built by adding
|
||||
``--with-pydebug`` when configuring the Python build. On
|
||||
Windows, the debugging version of Python is generated by
|
||||
the "Win32 Debug" target of the Visual Studio project in the
|
||||
PCBuild subdirectory of a full Python source code distribution.
|
||||
You may also find
|
||||
@@ -1,83 +0,0 @@
|
||||
[chapter Configuration
|
||||
[quickbook 1.7]
|
||||
[authors [Abrahams, David]]
|
||||
[copyright 2002 - 2015 David Abrahams, Stefan Seefeld]
|
||||
[id configuration]
|
||||
]
|
||||
|
||||
|
||||
[section Configuration]
|
||||
|
||||
[section Introduction]
|
||||
[*Boost.Python] uses several configuration macros in `<boost/config.hpp>`, as well as configuration macros meant to be supplied by the application. These macros are documented here.
|
||||
|
||||
[endsect]
|
||||
[section Application Defined Macros]
|
||||
|
||||
These are the macros that may be defined by an application using Boost.Python. Note that if you extend a strict interpretation of the C++ standard to cover dynamic libraries, using different values of these macros when compiling different libraries (including extension modules and the Boost.Python library itself) is a violation of the [link odr ODR]. However, we know of no C++ implementations on which this particular violation is detectable or causes any problems.
|
||||
|
||||
[table
|
||||
[[Macro][Default][Meaning]]
|
||||
[[BOOST_PYTHON_MAX_ARITY]
|
||||
[15]
|
||||
[The maximum arity of any function, member function,
|
||||
or constructor to be wrapped, invocation of a
|
||||
Boost.Python function wich is specified as taking
|
||||
arguments x1, x2,...Xn. This includes, in particular,
|
||||
callback mechanisms such as object::operator()(...) or call_method<R>(... ).]]
|
||||
[[BOOST_PYTHON_MAX_BASES][10]
|
||||
[The maximum number of template arguments to the
|
||||
`bases<...>` class template, which is used to specify
|
||||
the bases of a wrapped C++ class..]]
|
||||
[[BOOST_PYTHON_STATIC_MODULE]
|
||||
[ /not defined/ ]
|
||||
[If defined, prevents your module initialization
|
||||
function from being treated as an exported symbol
|
||||
on platforms which support that distinction in-code]]
|
||||
[[BOOST_PYTHON_ENABLE_CDECL]
|
||||
[ /not defined/ ]
|
||||
[If defined, allows functions using the `__cdecl`
|
||||
calling convention to be wrapped.]]
|
||||
[[BOOST_PYTHON_ENABLE_STDCALL]
|
||||
[ /not defined/ ]
|
||||
[If defined, allows functions using the `__stdcall`
|
||||
calling convention to be wrapped.]]
|
||||
[[BOOST_PYTHON_ENABLE_FASTCALL]
|
||||
[ /not defined/ ]
|
||||
[If defined, allows functions using the `__fastcall`
|
||||
calling convention to be wrapped.]]
|
||||
]
|
||||
[endsect]
|
||||
[section Library Defined Defined Macros]
|
||||
These macros are defined by *Boost.Python* and are implementation details of interest only to implementors and those porting to new platforms.
|
||||
[table
|
||||
[[Macro][Default][Meaning]]
|
||||
[[BOOST_PYTHON_TYPE_ID_NAME][ /not defined/ ]
|
||||
[If defined, this indicates that the type_info comparison across
|
||||
shared library boundaries does not work on this platform.
|
||||
In other words, if shared-lib-1 passes `typeid(T)` to a function
|
||||
in shared-lib-2 which compares it to `typeid(T)`, that comparison
|
||||
may return `false`. If this macro is #defined, Boost.Python uses
|
||||
and compares `typeid(T).name()` instead of using and comparing
|
||||
the `std::type_info` objects directly.]]
|
||||
[[BOOST_PYTHON_NO_PY_SIGNATURES][ /not defined/ ]
|
||||
[If defined for a module no pythonic signatures are generated for
|
||||
the docstrings of the module functions, and no python type is
|
||||
associated with any of the converters registered by the module.
|
||||
This also reduces the binary size of the module by about 14%
|
||||
(gcc compiled).
|
||||
If defined for the boost_python runtime library, the default for
|
||||
the `docstring_options.enable_py_signatures()` is set to `false`.]]
|
||||
[[BOOST_PYTHON_SUPPORTS_PY_SIGNATURES]
|
||||
[ /defined/ if `BOOST_PYTHON_NO_PY_SIGNATURES` is /undefined/ ]
|
||||
[This macro is defined to enable a smooth transition from older
|
||||
Boost.Python versions which do not support pythonic signatures.
|
||||
For example usage see here.]]
|
||||
[[BOOST_PYTHON_PY_SIGNATURES_PROPER_INIT_SELF_TYPE][ /not defined/ ]
|
||||
[If defined the python type of `__init__` method "self" parameters
|
||||
is properly generated, otherwise object is used. It is undefined by
|
||||
default because it increases the binary size of the module by about
|
||||
14% (gcc compiled).]]
|
||||
]
|
||||
[endsect]
|
||||
[endsect]
|
||||
736
doc/faq.qbk
@@ -1,736 +0,0 @@
|
||||
[chapter Frequently Asked Questions (FAQs)
|
||||
[quickbook 1.7]
|
||||
[id faq]
|
||||
]
|
||||
|
||||
[section How can I wrap a function which takes a function pointer as an argument?]
|
||||
|
||||
If what you're trying to do is something like this:
|
||||
``
|
||||
typedef boost::function<void (string s) > funcptr;
|
||||
|
||||
void foo(funcptr fp)
|
||||
{
|
||||
fp("hello,world!");
|
||||
}
|
||||
|
||||
BOOST_PYTHON_MODULE(test)
|
||||
{
|
||||
def("foo",foo);
|
||||
}
|
||||
``
|
||||
|
||||
And then:
|
||||
|
||||
``
|
||||
>>> def hello(s):
|
||||
... print s
|
||||
...
|
||||
>>> foo(hello)
|
||||
hello, world!
|
||||
``
|
||||
The short answer is: "you can't". This is not a
|
||||
Boost.Python limitation so much as a limitation of C++. The
|
||||
problem is that a Python function is actually data, and the only
|
||||
way of associating data with a C++ function pointer is to store it
|
||||
in a static variable of the function. The problem with that is
|
||||
that you can only associate one piece of data with every C++
|
||||
function, and we have no way of compiling a new C++ function
|
||||
on-the-fly for every Python function you decide to pass
|
||||
to `foo`. In other words, this could work if the C++
|
||||
function is always going to invoke the /same/ Python
|
||||
function, but you probably don't want that.
|
||||
|
||||
If you have the luxury of changing the C++ code you're
|
||||
wrapping, pass it an `object` instead and call that;
|
||||
the overloaded function call operator will invoke the Python
|
||||
function you pass it behind the `object`.
|
||||
|
||||
[endsect]
|
||||
[section I'm getting the "attempt to return dangling reference" error.
|
||||
What am I doing wrong?]
|
||||
|
||||
That exception is protecting you from causing a nasty crash. It usually
|
||||
happens in response to some code like this:
|
||||
``
|
||||
period const &get_floating_frequency() const
|
||||
{
|
||||
return boost::python::call_method<period const &>(
|
||||
m_self,"get_floating_frequency");
|
||||
}
|
||||
``
|
||||
And you get:
|
||||
``
|
||||
ReferenceError: Attempt to return dangling reference to object of type:
|
||||
class period
|
||||
``
|
||||
|
||||
In this case, the Python method invoked by `call_method`
|
||||
constructs a new Python object. You're trying to return a reference to a
|
||||
C++ object (an instance of `class period`) contained within
|
||||
and owned by that Python object. Because the called method handed back a
|
||||
brand new object, the only reference to it is held for the duration of
|
||||
`get_floating_frequency()` above. When the function returns,
|
||||
the Python object will be destroyed, destroying the instance of
|
||||
`class period`, and leaving the returned reference dangling.
|
||||
That's already undefined behavior, and if you try to do anything with
|
||||
that reference you're likely to cause a crash. Boost.Python detects this
|
||||
situation at runtime and helpfully throws an exception instead of letting
|
||||
you do that.
|
||||
|
||||
[endsect]
|
||||
[section Is `return_internal_reference` efficient?]
|
||||
|
||||
[*Q:] /I have an object composed of 12 doubles. A `const&` to
|
||||
this object is returned by a member function of another class. From the
|
||||
viewpoint of using the returned object in Python I do not care if I get
|
||||
a copy or a reference to the returned object. In Boost.Python I have the
|
||||
choice of using `copy_const_reference` or `return_internal_reference`.
|
||||
Are there considerations that would lead me to prefer one over the other,
|
||||
such as size of generated code or memory overhead?/
|
||||
|
||||
[*A:] `copy_const_reference` will make an instance with storage
|
||||
for one of your objects, `size = base_size + 12 * sizeof(double)`.
|
||||
`return_internal_reference` will make an instance with storage for a
|
||||
pointer to one of your objects, `size = base_size + sizeof(void*)`.
|
||||
However, it will also create a weak reference object which goes in the
|
||||
source object's weakreflist and a special callback object to manage the
|
||||
lifetime of the internally-referenced object. My guess?
|
||||
`copy_const_reference` is your friend here, resulting in less overall
|
||||
memory use and less fragmentation, also probably fewer total
|
||||
cycles.
|
||||
|
||||
[endsect]
|
||||
[section How can I wrap functions which take C++ containers as arguments?]
|
||||
|
||||
Ralf W. Grosse-Kunstleve provides these notes:
|
||||
|
||||
# Using the regular `class_<>` wrapper:
|
||||
``
|
||||
class_<std::vector<double> >("std_vector_double")
|
||||
.def(...)
|
||||
...
|
||||
;
|
||||
``
|
||||
This can be moved to a template so that several types (`double`, `int`,
|
||||
`long`, etc.) can be wrapped with the same code. This technique is used
|
||||
in the file `scitbx/include/scitbx/array_family/boost_python/flex_wrapper.h`
|
||||
in the "scitbx" package. The file could easily be modified for
|
||||
wrapping `std::vector<>` instantiations.
|
||||
This type of C++/Python binding is most suitable for containers
|
||||
that may contain a large number of elements (>10000).
|
||||
|
||||
# Using custom rvalue converters. Boost.Python "rvalue converters"
|
||||
match function signatures such as:
|
||||
``
|
||||
void foo(std::vector<double> const &array); // pass by const-reference
|
||||
void foo(std::vector<double> array); // pass by value
|
||||
``
|
||||
Some custom rvalue converters are implemented in the file
|
||||
`scitbx/include/scitbx/boost_python/container_conversions.h`
|
||||
This code can be used to convert from C++ container types such as
|
||||
`std::vector<>` or `std::list<>` to Python tuples and vice
|
||||
versa. A few simple examples can be found in the file
|
||||
`scitbx/array_family/boost_python/regression_test_module.cpp`
|
||||
Automatic C++ container <-> Python tuple conversions are most
|
||||
suitable for containers of moderate size. These converters generate
|
||||
significantly less object code compared to alternative 1 above.
|
||||
|
||||
A disadvantage of using alternative 2 is that operators such as
|
||||
arithmetic +,-,*,/,% are not available. It would be useful to have custom
|
||||
rvalue converters that convert to a "math_array" type instead of tuples.
|
||||
This is currently not implemented but is possible within the framework of
|
||||
Boost.Python V2 as it will be released in the next couple of weeks. [ed.:
|
||||
this was posted on 2002/03/10]
|
||||
|
||||
It would also be useful to also have "custom lvalue converters" such
|
||||
as `std::vector<>` <-> Python list. These converters would
|
||||
support the modification of the Python list from C++. For example:
|
||||
|
||||
C++:
|
||||
``
|
||||
void foo(std::vector<double> &array)
|
||||
{
|
||||
for(std::size_t i=0;i<array.size();i++) {
|
||||
array[i] *= 2;
|
||||
}
|
||||
}
|
||||
``
|
||||
Python: [python]
|
||||
``
|
||||
>>> l = [1, 2, 3]
|
||||
>>> foo(l)
|
||||
>>> print l
|
||||
[2, 4, 6]
|
||||
``
|
||||
Custom lvalue converters require changes to the Boost.Python core library
|
||||
and are currently not available.
|
||||
|
||||
P.S.:
|
||||
|
||||
The "scitbx" files referenced above are available via anonymous
|
||||
CVS:
|
||||
``
|
||||
cvs -d:pserver:anonymous@cvs.cctbx.sourceforge.net:/cvsroot/cctbx login
|
||||
cvs -d:pserver:anonymous@cvs.cctbx.sourceforge.net:/cvsroot/cctbx co scitbx
|
||||
``
|
||||
|
||||
[endsect]
|
||||
[section fatal error C1204:Compiler limit:internal structure overflow]
|
||||
|
||||
[*Q:] /I get this error message when compiling a large source file. What can I do?/
|
||||
|
||||
[*A:] You have two choices:
|
||||
|
||||
# Upgrade your compiler (preferred)
|
||||
|
||||
# Break your source file up into multiple translation units.
|
||||
|
||||
`my_module.cpp`: [c++]
|
||||
|
||||
``
|
||||
...
|
||||
void more_of_my_module();
|
||||
BOOST_PYTHON_MODULE(my_module)
|
||||
{
|
||||
def("foo", foo);
|
||||
def("bar", bar);
|
||||
...
|
||||
more_of_my_module();
|
||||
}
|
||||
``
|
||||
`more_of_my_module.cpp`:
|
||||
``
|
||||
void more_of_my_module()
|
||||
{
|
||||
def("baz", baz);
|
||||
...
|
||||
}
|
||||
``
|
||||
If you find that a `class_<...>` declaration
|
||||
can't fit in a single source file without triggering the error, you
|
||||
can always pass a reference to the `class_` object to a
|
||||
function in another source file, and call some of its member
|
||||
functions (e.g. `.def(...)`) in the auxilliary source
|
||||
file:
|
||||
|
||||
`more_of_my_class.cpp`:
|
||||
``
|
||||
void more_of_my_class(class<my_class>& x)
|
||||
{
|
||||
x
|
||||
.def("baz", baz)
|
||||
.add_property("xx", &my_class::get_xx, &my_class::set_xx)
|
||||
;
|
||||
...
|
||||
}
|
||||
``
|
||||
|
||||
[endsect]
|
||||
[section How do I debug my Python extensions?]
|
||||
|
||||
Greg Burley gives the following answer for Unix GCC users:
|
||||
|
||||
[:Once you have created a boost python extension for your c++ library or
|
||||
class, you may need to debug the code. Afterall this is one of the
|
||||
reasons for wrapping the library in python. An expected side-effect or
|
||||
benefit of using BPL is that debugging should be isolated to the c++
|
||||
library that is under test, given that python code is minimal and
|
||||
boost::python either works or it doesn't. (ie. While errors can occur
|
||||
when the wrapping method is invalid, most errors are caught by the
|
||||
compiler ;-).
|
||||
|
||||
The basic steps required to initiate a gdb session to debug a c++
|
||||
library via python are shown here. Note, however that you should start
|
||||
the gdb session in the directory that contains your BPL my_ext.so
|
||||
module.
|
||||
|
||||
``
|
||||
(gdb) target exec python
|
||||
(gdb) run
|
||||
>>> from my_ext import *
|
||||
>>> [C-c]
|
||||
(gdb) break MyClass::MyBuggyFunction
|
||||
(gdb) cont
|
||||
>>> pyobj = MyClass()
|
||||
>>> pyobj.MyBuggyFunction()
|
||||
Breakpoint 1, MyClass::MyBuggyFunction ...
|
||||
Current language: auto; currently c++
|
||||
(gdb) do debugging stuff
|
||||
``
|
||||
]
|
||||
|
||||
Greg's approach works even better using Emacs' "gdb"
|
||||
command, since it will show you each line of source as you step through it.
|
||||
|
||||
On *Windows*, my favorite debugging solution is the debugger that
|
||||
comes with Microsoft Visual C++ 7. This debugger seems to work with code
|
||||
generated by all versions of Microsoft and Metrowerks toolsets; it's rock
|
||||
solid and "just works" without requiring any special tricks from the
|
||||
user.
|
||||
|
||||
Raoul Gough has provided the following for gdb on Windows:
|
||||
|
||||
[:gdb support for Windows DLLs has improved lately, so it is
|
||||
now possible to debug Python extensions using a few
|
||||
tricks. Firstly, you will need an up-to-date gdb with support
|
||||
for minimal symbol extraction from a DLL. Any gdb from version 6
|
||||
onwards, or Cygwin gdb-20030214-1 and onwards should do. A
|
||||
suitable release will have a section in the gdb.info file under
|
||||
Configuration - Native - Cygwin Native -
|
||||
Non-debug DLL symbols. Refer to that info section for more
|
||||
details of the procedures outlined here.
|
||||
|
||||
Secondly, it seems necessary to set a breakpoint in the
|
||||
Python interpreter, rather than using ^C to break execution. A
|
||||
good place to set this breakpoint is PyOS_Readline, which will
|
||||
stop execution immediately before reading each interactive
|
||||
Python command. You have to let Python start once under the
|
||||
debugger, so that it loads its own DLL, before you can set the
|
||||
breakpoint:
|
||||
|
||||
``
|
||||
$ gdb python
|
||||
GNU gdb 2003-09-02-cvs (cygwin-special)
|
||||
[...]
|
||||
|
||||
(gdb) run
|
||||
Starting program: /cygdrive/c/Python22/python.exe
|
||||
Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
|
||||
Type "help", "copyright", "credits" or "license" for more information.
|
||||
>>> ^Z
|
||||
|
||||
|
||||
Program exited normally.
|
||||
(gdb) break *&PyOS_Readline
|
||||
Breakpoint 1 at 0x1e04eff0
|
||||
(gdb) run
|
||||
Starting program: /cygdrive/c/Python22/python.exe
|
||||
Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
|
||||
Type "help", "copyright", "credits" or "license" for more information.
|
||||
|
||||
Breakpoint 1, 0x1e04eff0 in python22!PyOS_Readline ()
|
||||
from /cygdrive/c/WINNT/system32/python22.dll
|
||||
(gdb) cont
|
||||
Continuing.
|
||||
>>> from my_ext import *
|
||||
|
||||
Breakpoint 1, 0x1e04eff0 in python22!PyOS_Readline ()
|
||||
from /cygdrive/c/WINNT/system32/python22.dll
|
||||
(gdb) # my_ext now loaded (with any debugging symbols it contains)
|
||||
``
|
||||
]
|
||||
|
||||
[h2 Debugging extensions through Boost.Build]
|
||||
|
||||
If you are launching your extension module tests with _bb_ using the
|
||||
`boost-python-runtest` rule, you can ask it to launch your
|
||||
debugger for you by adding "--debugger=/debugger/" to your bjam
|
||||
command-line:
|
||||
``
|
||||
bjam -sTOOLS=vc7.1 "--debugger=devenv /debugexe" test
|
||||
bjam -sTOOLS=gcc -sPYTHON_LAUNCH=gdb test
|
||||
``
|
||||
It can also be extremely useful to add the `-d+2` option when
|
||||
you run your test, because Boost.Build will then show you the exact
|
||||
commands it uses to invoke it. This will invariably involve setting up
|
||||
PYTHONPATH and other important environment variables such as
|
||||
LD_LIBRARY_PATH which may be needed by your debugger in order to get
|
||||
things to work right.
|
||||
|
||||
[endsect]
|
||||
[section Why doesn't my `*=` operator work?]
|
||||
|
||||
[*Q:] ['I have exported my class to python, with many overloaded
|
||||
operators. it works fine for me except the `*=`
|
||||
operator. It always tells me "can't multiply sequence with non int
|
||||
type". If I use `p1.__imul__(p2)` instead of
|
||||
`p1 *= p2`, it successfully executes my code. What's
|
||||
wrong with me?]
|
||||
|
||||
[*A:] There's nothing wrong with you. This is a bug in Python
|
||||
2.2. You can see the same effect in Pure Python (you can learn a lot
|
||||
about what's happening in Boost.Python by playing with new-style
|
||||
classes in Pure Python).
|
||||
``
|
||||
>>> class X(object):
|
||||
... def __imul__(self, x):
|
||||
... print 'imul'
|
||||
...
|
||||
>>> x = X()
|
||||
>>> x *= 1
|
||||
``
|
||||
To cure this problem, all you need to do is upgrade your Python to
|
||||
version 2.2.1 or later.
|
||||
|
||||
[endsect]
|
||||
[section Does Boost.Python work with Mac OS X?]
|
||||
|
||||
It is known to work under 10.2.8 and 10.3 using
|
||||
Apple's gcc 3.3 compiler:
|
||||
``gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1493)``
|
||||
Under 10.2.8 get the August 2003 gcc update (free at [@http://connect.apple.com]).
|
||||
Under 10.3 get the Xcode Tools v1.0 (also free).
|
||||
|
||||
Python 2.3 is required. The Python that ships with 10.3 is
|
||||
fine. Under 10.2.8 use these commands to install Python
|
||||
as a framework:
|
||||
``./configure --enable-framework
|
||||
make
|
||||
make frameworkinstall``
|
||||
|
||||
The last command requires root privileges because the target
|
||||
directory is `/Library/Frameworks/Python.framework/Versions/2.3`.
|
||||
However, the installation does not interfere with the Python
|
||||
version that ships with 10.2.8.
|
||||
|
||||
It is also crucial to increase the `stacksize` before
|
||||
starting compilations, e.g.:
|
||||
``limit stacksize 8192k``
|
||||
If the `stacksize` is too small the build might crash with
|
||||
internal compiler errors.
|
||||
|
||||
Sometimes Apple's compiler exhibits a bug by printing an error
|
||||
like the following while compiling a
|
||||
`boost::python::class_<your_type>`
|
||||
template instantiation:
|
||||
``
|
||||
.../inheritance.hpp:44: error: cannot
|
||||
dynamic_cast `p' (of type `struct cctbx::boost_python::<unnamed>::add_pair*
|
||||
') to type `void*' (source type is not polymorphic)
|
||||
``
|
||||
|
||||
We do not know a general workaround, but if the definition of
|
||||
`your_type` can be modified the following was found
|
||||
to work in all cases encountered so far:
|
||||
``
|
||||
struct your_type
|
||||
{
|
||||
// before defining any member data
|
||||
#if defined(__MACH__) && defined(__APPLE_CC__) && __APPLE_CC__ == 1493
|
||||
bool dummy_;
|
||||
#endif
|
||||
// now your member data, e.g.
|
||||
double x;
|
||||
int j;
|
||||
// etc.
|
||||
};
|
||||
``
|
||||
[endsect]
|
||||
[section How can I find the existing PyObject that holds a C++ object?]
|
||||
|
||||
[: "I am wrapping a function that always returns a pointer to an
|
||||
already-held C++ object."]
|
||||
|
||||
One way to do that is to hijack the mechanisms used for wrapping a class
|
||||
with virtual functions. If you make a wrapper class with an initial
|
||||
PyObject* constructor argument and store that PyObject* as "self", you
|
||||
can get back to it by casting down to that wrapper type in a thin wrapper
|
||||
function. For example:
|
||||
``
|
||||
class X { X(int); virtual ~X(); ... };
|
||||
X* f(); // known to return Xs that are managed by Python objects
|
||||
|
||||
|
||||
// wrapping code
|
||||
|
||||
struct X_wrap : X
|
||||
{
|
||||
X_wrap(PyObject* self, int v) : self(self), X(v) {}
|
||||
PyObject* self;
|
||||
};
|
||||
|
||||
handle<> f_wrap()
|
||||
{
|
||||
X_wrap* xw = dynamic_cast<X_wrap*>(f());
|
||||
assert(xw != 0);
|
||||
return handle<>(borrowed(xw->self));
|
||||
}
|
||||
|
||||
...
|
||||
|
||||
def("f", f_wrap());
|
||||
class_<X,X_wrap,boost::noncopyable>("X", init<int>())
|
||||
...
|
||||
;
|
||||
``
|
||||
|
||||
Of course, if X has no virtual functions you'll have to use
|
||||
`static_cast` instead of `dynamic_cast` with no
|
||||
runtime check that it's valid. This approach also only works if the
|
||||
`X` object was constructed from Python, because
|
||||
`X`\ s constructed from C++ are of course never
|
||||
`X_wrap` objects.
|
||||
|
||||
Another approach to this requires you to change your C++ code a bit;
|
||||
if that's an option for you it might be a better way to go. work we've
|
||||
been meaning to get to anyway. When a `shared_ptr<X>` is
|
||||
converted from Python, the shared_ptr actually manages a reference to the
|
||||
containing Python object. When a shared_ptr<X> is converted back to
|
||||
Python, the library checks to see if it's one of those "Python object
|
||||
managers" and if so just returns the original Python object. So you could
|
||||
just write `object(p)` to get the Python object back. To
|
||||
exploit this you'd have to be able to change the C++ code you're wrapping
|
||||
so that it deals with shared_ptr instead of raw pointers.
|
||||
|
||||
There are other approaches too. The functions that receive the Python
|
||||
object that you eventually want to return could be wrapped with a thin
|
||||
wrapper that records the correspondence between the object address and
|
||||
its containing Python object, and you could have your f_wrap function
|
||||
look in that mapping to get the Python object out.
|
||||
|
||||
[endsect]
|
||||
[section How can I wrap a function which needs to take ownership of a raw pointer?]
|
||||
|
||||
[*Q:] Part of an API that I'm wrapping goes something like this:
|
||||
|
||||
``
|
||||
struct A {}; struct B { void add( A* ); }
|
||||
where B::add() takes ownership of the pointer passed to it.
|
||||
``
|
||||
|
||||
However:
|
||||
|
||||
``
|
||||
a = mod.A()
|
||||
b = mod.B()
|
||||
b.add( a )
|
||||
del a
|
||||
del b
|
||||
# python interpreter crashes
|
||||
# later due to memory corruption.
|
||||
``
|
||||
|
||||
Even binding the lifetime of a to b via `with_custodian_and_ward` doesn't prevent
|
||||
the python object a from ultimately trying to delete the object it's pointing to.
|
||||
Is there a way to accomplish a 'transfer-of-ownership' of a wrapped C++ object?
|
||||
|
||||
--Bruce Lowery
|
||||
|
||||
Yes: Make sure the C++ object is held by auto_ptr:
|
||||
``
|
||||
class_<A, std::auto_ptr<A> >("A")
|
||||
...
|
||||
;
|
||||
``
|
||||
Then make a thin wrapper function which takes an auto_ptr parameter:
|
||||
``
|
||||
void b_insert(B &b, std::auto_ptr<A> a)
|
||||
{
|
||||
b.insert(a.get());
|
||||
a.release();
|
||||
}
|
||||
``
|
||||
Wrap that as B.add. Note that pointers returned via `manage_new_object`
|
||||
will also be held by `auto_ptr`, so this transfer-of-ownership
|
||||
will also work correctly.
|
||||
|
||||
[endsect]
|
||||
[section Compilation takes too much time and eats too much memory!
|
||||
What can I do to make it faster?]
|
||||
|
||||
Please refer to the `Reducing Compiling Time` section in the _tutorial_.
|
||||
|
||||
[endsect]
|
||||
[section How do I create sub-packages using Boost.Python?]
|
||||
|
||||
Please refer to the `Creating Packages` section in the _tutorial_.
|
||||
|
||||
[endsect]
|
||||
[section error C2064: term does not evaluate to a function taking 2 arguments]
|
||||
|
||||
/Niall Douglas provides these notes:/
|
||||
|
||||
If you see Microsoft Visual C++ 7.1 (MS Visual Studio .NET 2003) issue
|
||||
an error message like the following it is most likely due to a bug
|
||||
in the compiler:
|
||||
``
|
||||
boost\boost\python\detail\invoke.hpp(76):
|
||||
error C2064: term does not evaluate to a function taking 2 arguments"
|
||||
``
|
||||
This message is triggered by code like the following:
|
||||
``
|
||||
#include <boost/python.hpp>
|
||||
|
||||
using namespace boost::python;
|
||||
|
||||
class FXThread
|
||||
{
|
||||
public:
|
||||
bool setAutoDelete(bool doso) throw();
|
||||
};
|
||||
|
||||
void Export_FXThread()
|
||||
{
|
||||
class_< FXThread >("FXThread")
|
||||
.def("setAutoDelete", &FXThread::setAutoDelete)
|
||||
;
|
||||
}
|
||||
``
|
||||
The bug is related to the `throw()` modifier.
|
||||
As a workaround cast off the modifier. E.g.:
|
||||
``
|
||||
.def("setAutoDelete", (bool (FXThread::*)(bool)) &FXThread::setAutoDelete)
|
||||
``
|
||||
(The bug has been reported to Microsoft.)
|
||||
|
||||
[endsect]
|
||||
[section How can I automatically convert my custom string type to and from a Python string?]
|
||||
|
||||
/Ralf W. Grosse-Kunstleve provides these notes:/
|
||||
|
||||
Below is a small, self-contained demo extension module that shows
|
||||
how to do this. Here is the corresponding trivial test:
|
||||
``
|
||||
import custom_string
|
||||
assert custom_string.hello() == "Hello world."
|
||||
assert custom_string.size("california") == 10
|
||||
``
|
||||
If you look at the code you will find:
|
||||
|
||||
* A custom `to_python` converter (easy):
|
||||
`custom_string_to_python_str`
|
||||
|
||||
*A custom lvalue converter (needs more code):
|
||||
`custom_string_from_python_str`
|
||||
|
||||
The custom converters are registered in the global Boost.Python
|
||||
registry near the top of the module initialization function. Once
|
||||
flow control has passed through the registration code the automatic
|
||||
conversions from and to Python strings will work in any module
|
||||
imported in the same process.
|
||||
|
||||
``
|
||||
#include <boost/python/module.hpp>
|
||||
#include <boost/python/def.hpp>
|
||||
#include <boost/python/to_python_converter.hpp>
|
||||
|
||||
namespace sandbox { namespace {
|
||||
|
||||
class custom_string
|
||||
{
|
||||
public:
|
||||
custom_string() {}
|
||||
custom_string(std::string const &value) : value_(value) {}
|
||||
std::string const &value() const { return value_; }
|
||||
private:
|
||||
std::string value_;
|
||||
};
|
||||
|
||||
struct custom_string_to_python_str
|
||||
{
|
||||
static PyObject* convert(custom_string const &s)
|
||||
{
|
||||
return boost::python::incref(boost::python::object(s.value()).ptr());
|
||||
}
|
||||
};
|
||||
|
||||
struct custom_string_from_python_str
|
||||
{
|
||||
custom_string_from_python_str()
|
||||
{
|
||||
boost::python::converter::registry::push_back(
|
||||
&convertible,
|
||||
&construct,
|
||||
boost::python::type_id<custom_string>());
|
||||
}
|
||||
|
||||
static void* convertible(PyObject* obj_ptr)
|
||||
{
|
||||
if (!PyString_Check(obj_ptr)) return 0;
|
||||
return obj_ptr;
|
||||
}
|
||||
|
||||
static void construct(
|
||||
PyObject* obj_ptr,
|
||||
boost::python::converter::rvalue_from_python_stage1_data* data)
|
||||
{
|
||||
const char* value = PyString_AsString(obj_ptr);
|
||||
if (value == 0) boost::python::throw_error_already_set();
|
||||
void* storage = (
|
||||
(boost::python::converter::rvalue_from_python_storage<custom_string>*)
|
||||
data)->storage.bytes;
|
||||
new (storage) custom_string(value);
|
||||
data->convertible = storage;
|
||||
}
|
||||
};
|
||||
|
||||
custom_string hello() { return custom_string("Hello world."); }
|
||||
|
||||
std::size_t size(custom_string const &s) { return s.value().size(); }
|
||||
|
||||
void init_module()
|
||||
{
|
||||
using namespace boost::python;
|
||||
|
||||
boost::python::to_python_converter<
|
||||
custom_string,
|
||||
custom_string_to_python_str>();
|
||||
|
||||
custom_string_from_python_str();
|
||||
|
||||
def("hello", hello);
|
||||
def("size", size);
|
||||
}
|
||||
|
||||
}} // namespace sandbox::<anonymous>
|
||||
|
||||
BOOST_PYTHON_MODULE(custom_string)
|
||||
{
|
||||
sandbox::init_module();
|
||||
}
|
||||
``
|
||||
[endsect]
|
||||
[section Why is my automatic to-python conversion not being found?]
|
||||
|
||||
/Niall Douglas provides these notes:/
|
||||
|
||||
If you define custom converters similar to the ones
|
||||
shown above the `def_readonly()` and `def_readwrite()`
|
||||
member functions provided by `boost::python::class_` for
|
||||
direct access to your member data will not work as expected.
|
||||
This is because `def_readonly("bar",&foo::bar)` is
|
||||
equivalent to:
|
||||
|
||||
``
|
||||
.add_property("bar", make_getter(&foo::bar, return_internal_reference()))
|
||||
``
|
||||
Similarly, `def_readwrite("bar",&foo::bar)` is
|
||||
equivalent to:
|
||||
|
||||
``
|
||||
.add_property("bar", make_getter(&foo::bar, return_internal_reference()),
|
||||
make_setter(&foo::bar, return_internal_reference())
|
||||
``
|
||||
In order to define return value policies compatible with the
|
||||
custom conversions replace `def_readonly()` and
|
||||
`def_readwrite()` by `add_property()`. E.g.:
|
||||
|
||||
``
|
||||
.add_property("bar", make_getter(&foo::bar, return_value_policy<return_by_value>()),
|
||||
make_setter(&foo::bar, return_value_policy<return_by_value>()))
|
||||
``
|
||||
|
||||
[endsect]
|
||||
[section Is Boost.Python thread-aware/compatible with multiple interpreters?]
|
||||
|
||||
/Niall Douglas provides these notes:/
|
||||
|
||||
The quick answer to this is: no.
|
||||
|
||||
The longer answer is that it can be patched to be so, but it's
|
||||
complex. You will need to add custom lock/unlock wrapping of every
|
||||
time your code enters Boost.Python (particularly every virtual
|
||||
function override) plus heavily modify
|
||||
`boost/python/detail/invoke.hpp` with custom unlock/lock
|
||||
wrapping of every time Boost.Python enters your code. You must
|
||||
furthermore take care to /not/ unlock/lock when Boost.Python
|
||||
is invoking iterator changes via `invoke.hpp`.
|
||||
|
||||
There is a patched `invoke.hpp` posted on the C++-SIG
|
||||
mailing list archives and you can find a real implementation of all
|
||||
the machinery necessary to fully implement this in the TnFOX
|
||||
project at [@http://sourceforge.net/projects/tnfox/ this]
|
||||
SourceForge project location.
|
||||
|
||||
[endsect]
|
||||
@@ -1,38 +0,0 @@
|
||||
[chapter Glossary
|
||||
[quickbook 1.7]
|
||||
[id glossary]
|
||||
]
|
||||
|
||||
[variablelist
|
||||
[[arity [#arity]]
|
||||
[The number of argumnts accepted by a function or member function.
|
||||
Unless otherwise specified, the hidden `this` argument to member
|
||||
functions is not counted when specifying arity.]]
|
||||
[[ntbs [#ntbs]]
|
||||
[Null-Terminated Byte String, or 'C'-string. C++ string literals are *ntbs*\ es.
|
||||
An *ntbs* must never be null.]]
|
||||
[[raise [#raise]]
|
||||
[Exceptions in Python are "raised", not "thrown", as they are in C++.
|
||||
When this documentation says that some Python exception is "raised" in
|
||||
the context of C++ code, it means that the corresponding Python exception
|
||||
is set via the [@http://www.python.org/doc/current/api/exceptionHandling.html Python/'C' API],
|
||||
and `throw_error_already_set()` is called.]]
|
||||
[[POD [#pod]]
|
||||
[A technical term from the C++ standard. Short for "Plain Ol'Data":
|
||||
A POD-struct is an aggregate class that has no non-static data members
|
||||
of type pointer to member, non-POD-struct, non-POD-union (or array of such
|
||||
types) or reference, and has no user-defined copy assign- ment operator and
|
||||
no user-defined destructor. Similarly, a POD-union is an aggregate union that
|
||||
has no non-static data members of type pointer to member, non-POD-struct,
|
||||
non-POD-union (or array of such types) or reference, and has no
|
||||
user-defined copy assignment operator and no user-defined destructor. A
|
||||
POD class is a class that is either a POD-struct or a POD-union. An
|
||||
aggregate is an array or a class (clause 9) with no user-declared
|
||||
constructors (12.1), no private or protected non-static data members
|
||||
(clause 11), no base classes (clause 10), and no virtual functions
|
||||
(10.3).]]
|
||||
[[ODR [#odr]]
|
||||
[The "One Definition Rule", which says that any entity in a C++ program must have
|
||||
the same definition in all translation units (object files) which make up a program.]]
|
||||
]
|
||||
|
||||
@@ -1,66 +0,0 @@
|
||||
/*=============================================================================
|
||||
Copyright 2002 William E. Kempf
|
||||
Distributed under the Boost Software License, Version 1.0. (See accompany-
|
||||
ing file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
|
||||
=============================================================================*/
|
||||
|
||||
H1
|
||||
{
|
||||
FONT-SIZE: 200%;
|
||||
COLOR: #00008B;
|
||||
}
|
||||
H2
|
||||
{
|
||||
FONT-SIZE: 150%;
|
||||
}
|
||||
H3
|
||||
{
|
||||
FONT-SIZE: 125%;
|
||||
}
|
||||
H4
|
||||
{
|
||||
FONT-SIZE: 108%;
|
||||
}
|
||||
BODY
|
||||
{
|
||||
FONT-SIZE: 100%;
|
||||
BACKGROUND-COLOR: #ffffff;
|
||||
COLOR: #000000;
|
||||
}
|
||||
PRE
|
||||
{
|
||||
MARGIN-LEFT: 2em;
|
||||
FONT-FAMILY: Courier,
|
||||
monospace;
|
||||
}
|
||||
CODE
|
||||
{
|
||||
FONT-FAMILY: Courier,
|
||||
monospace;
|
||||
}
|
||||
CODE.as_pre
|
||||
{
|
||||
white-space: pre;
|
||||
}
|
||||
.index
|
||||
{
|
||||
TEXT-ALIGN: left;
|
||||
}
|
||||
.page-index
|
||||
{
|
||||
TEXT-ALIGN: left;
|
||||
}
|
||||
.definition
|
||||
{
|
||||
TEXT-ALIGN: left;
|
||||
}
|
||||
.footnote
|
||||
{
|
||||
FONT-SIZE: 66%;
|
||||
VERTICAL-ALIGN: super;
|
||||
TEXT-DECORATION: none;
|
||||
}
|
||||
.function-semantics
|
||||
{
|
||||
CLEAR: left;
|
||||
}
|
||||
@@ -1,275 +0,0 @@
|
||||
/*
|
||||
:Author: David Goodger
|
||||
:Contact: goodger@python.org
|
||||
:Date: $Date$
|
||||
:Revision: $Revision$
|
||||
:Copyright: This stylesheet has been placed in the public domain.
|
||||
|
||||
Default cascading style sheet for the HTML output of Docutils.
|
||||
|
||||
See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to
|
||||
customize this style sheet.
|
||||
*/
|
||||
|
||||
/* used to remove borders from tables and images */
|
||||
.borderless, table.borderless td, table.borderless th {
|
||||
border: 0 }
|
||||
|
||||
table.borderless td, table.borderless th {
|
||||
/* Override padding for "table.docutils td" with "! important".
|
||||
The right padding separates the table cells. */
|
||||
padding: 0 0.5em 0 0 ! important }
|
||||
|
||||
.first {
|
||||
/* Override more specific margin styles with "! important". */
|
||||
margin-top: 0 ! important }
|
||||
|
||||
.last, .with-subtitle {
|
||||
margin-bottom: 0 ! important }
|
||||
|
||||
.hidden {
|
||||
display: none }
|
||||
|
||||
a.toc-backref {
|
||||
text-decoration: none ;
|
||||
color: black }
|
||||
|
||||
blockquote.epigraph {
|
||||
margin: 2em 5em ; }
|
||||
|
||||
dl.docutils dd {
|
||||
margin-bottom: 0.5em }
|
||||
|
||||
/* Uncomment (and remove this text!) to get bold-faced definition list terms
|
||||
dl.docutils dt {
|
||||
font-weight: bold }
|
||||
*/
|
||||
|
||||
div.abstract {
|
||||
margin: 2em 5em }
|
||||
|
||||
div.abstract p.topic-title {
|
||||
font-weight: bold ;
|
||||
text-align: center }
|
||||
|
||||
div.admonition, div.attention, div.caution, div.danger, div.error,
|
||||
div.hint, div.important, div.note, div.tip, div.warning {
|
||||
margin: 2em ;
|
||||
border: medium outset ;
|
||||
padding: 1em }
|
||||
|
||||
div.admonition p.admonition-title, div.hint p.admonition-title,
|
||||
div.important p.admonition-title, div.note p.admonition-title,
|
||||
div.tip p.admonition-title {
|
||||
font-weight: bold ;
|
||||
font-family: sans-serif }
|
||||
|
||||
div.attention p.admonition-title, div.caution p.admonition-title,
|
||||
div.danger p.admonition-title, div.error p.admonition-title,
|
||||
div.warning p.admonition-title {
|
||||
color: red ;
|
||||
font-weight: bold ;
|
||||
font-family: sans-serif }
|
||||
|
||||
/* Uncomment (and remove this text!) to get reduced vertical space in
|
||||
compound paragraphs.
|
||||
div.compound .compound-first, div.compound .compound-middle {
|
||||
margin-bottom: 0.5em }
|
||||
|
||||
div.compound .compound-last, div.compound .compound-middle {
|
||||
margin-top: 0.5em }
|
||||
*/
|
||||
|
||||
div.dedication {
|
||||
margin: 2em 5em ;
|
||||
text-align: center ;
|
||||
font-style: italic }
|
||||
|
||||
div.dedication p.topic-title {
|
||||
font-weight: bold ;
|
||||
font-style: normal }
|
||||
|
||||
div.figure {
|
||||
margin-left: 2em ;
|
||||
margin-right: 2em }
|
||||
|
||||
div.footer, div.header {
|
||||
clear: both;
|
||||
font-size: smaller }
|
||||
|
||||
div.line-block {
|
||||
display: block ;
|
||||
margin-top: 1em ;
|
||||
margin-bottom: 1em }
|
||||
|
||||
div.line-block div.line-block {
|
||||
margin-top: 0 ;
|
||||
margin-bottom: 0 ;
|
||||
margin-left: 1.5em }
|
||||
|
||||
div.sidebar {
|
||||
margin-left: 1em ;
|
||||
border: medium outset ;
|
||||
padding: 1em ;
|
||||
background-color: #ffffee ;
|
||||
width: 40% ;
|
||||
float: right ;
|
||||
clear: right }
|
||||
|
||||
div.sidebar p.rubric {
|
||||
font-family: sans-serif ;
|
||||
font-size: medium }
|
||||
|
||||
div.system-messages {
|
||||
margin: 5em }
|
||||
|
||||
div.system-messages h1 {
|
||||
color: red }
|
||||
|
||||
div.system-message {
|
||||
border: medium outset ;
|
||||
padding: 1em }
|
||||
|
||||
div.system-message p.system-message-title {
|
||||
color: red ;
|
||||
font-weight: bold }
|
||||
|
||||
div.topic {
|
||||
margin: 2em }
|
||||
|
||||
h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
|
||||
h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
|
||||
margin-top: 0.4em }
|
||||
|
||||
h1.title {
|
||||
text-align: center }
|
||||
|
||||
h2.subtitle {
|
||||
text-align: center }
|
||||
|
||||
hr.docutils {
|
||||
width: 75% }
|
||||
|
||||
img.align-left {
|
||||
clear: left }
|
||||
|
||||
img.align-right {
|
||||
clear: right }
|
||||
|
||||
ol.simple, ul.simple {
|
||||
margin-bottom: 1em }
|
||||
|
||||
ol.arabic {
|
||||
list-style: decimal }
|
||||
|
||||
ol.loweralpha {
|
||||
list-style: lower-alpha }
|
||||
|
||||
ol.upperalpha {
|
||||
list-style: upper-alpha }
|
||||
|
||||
ol.lowerroman {
|
||||
list-style: lower-roman }
|
||||
|
||||
ol.upperroman {
|
||||
list-style: upper-roman }
|
||||
|
||||
p.attribution {
|
||||
text-align: right ;
|
||||
margin-left: 50% }
|
||||
|
||||
p.caption {
|
||||
font-style: italic }
|
||||
|
||||
p.credits {
|
||||
font-style: italic ;
|
||||
font-size: smaller }
|
||||
|
||||
p.label {
|
||||
white-space: nowrap }
|
||||
|
||||
p.rubric {
|
||||
font-weight: bold ;
|
||||
font-size: larger ;
|
||||
color: maroon ;
|
||||
text-align: center }
|
||||
|
||||
p.sidebar-title {
|
||||
font-family: sans-serif ;
|
||||
font-weight: bold ;
|
||||
font-size: larger }
|
||||
|
||||
p.sidebar-subtitle {
|
||||
font-family: sans-serif ;
|
||||
font-weight: bold }
|
||||
|
||||
p.topic-title {
|
||||
font-weight: bold }
|
||||
|
||||
pre.address {
|
||||
margin-bottom: 0 ;
|
||||
margin-top: 0 ;
|
||||
font-family: serif ;
|
||||
font-size: 100% }
|
||||
|
||||
pre.literal-block, pre.doctest-block {
|
||||
margin-left: 2em ;
|
||||
margin-right: 2em }
|
||||
|
||||
span.classifier {
|
||||
font-family: sans-serif ;
|
||||
font-style: oblique }
|
||||
|
||||
span.classifier-delimiter {
|
||||
font-family: sans-serif ;
|
||||
font-weight: bold }
|
||||
|
||||
span.interpreted {
|
||||
font-family: sans-serif }
|
||||
|
||||
span.option {
|
||||
white-space: nowrap }
|
||||
|
||||
span.pre {
|
||||
white-space: pre }
|
||||
|
||||
span.problematic {
|
||||
color: red }
|
||||
|
||||
span.section-subtitle {
|
||||
/* font-size relative to parent (h1..h6 element) */
|
||||
font-size: 80% }
|
||||
|
||||
table.citation {
|
||||
border-left: solid 1px gray;
|
||||
margin-left: 1px }
|
||||
|
||||
table.docinfo {
|
||||
margin: 2em 4em }
|
||||
|
||||
table.docutils {
|
||||
margin-top: 0.5em ;
|
||||
margin-bottom: 0.5em }
|
||||
|
||||
table.footnote {
|
||||
border-left: solid 1px black;
|
||||
margin-left: 1px }
|
||||
|
||||
table.docutils td, table.docutils th,
|
||||
table.docinfo td, table.docinfo th {
|
||||
padding-left: 0.5em ;
|
||||
padding-right: 0.5em ;
|
||||
vertical-align: top }
|
||||
|
||||
table.docutils th.field-name, table.docinfo th.docinfo-name {
|
||||
font-weight: bold ;
|
||||
text-align: left ;
|
||||
white-space: nowrap ;
|
||||
padding-left: 0 }
|
||||
|
||||
h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
|
||||
h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
|
||||
font-size: 100% }
|
||||
|
||||
ul.auto-toc {
|
||||
list-style-type: none }
|
||||
|
Before Width: | Height: | Size: 374 B |
|
Before Width: | Height: | Size: 6.2 KiB |
|
Before Width: | Height: | Size: 391 B |
@@ -1,15 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M10.428,10.411h0.56c3.78,0,4.788-1.96,4.872-3.444h3.22v19.88h-3.92V13.154h-4.732V10.411z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 703 B |
|
Before Width: | Height: | Size: 485 B |
@@ -1,18 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M3.815,10.758h0.48c3.24,0,4.104-1.681,4.176-2.952h2.76v17.04h-3.36V13.11H3.815V10.758z"/>
|
||||
<path style="fill:#FFFFFF;" d="M22.175,7.806c4.009,0,5.904,2.76,5.904,8.736c0,5.975-1.896,8.76-5.904,8.76
|
||||
c-4.008,0-5.904-2.785-5.904-8.76C16.271,10.566,18.167,7.806,22.175,7.806z M22.175,22.613c1.921,0,2.448-1.68,2.448-6.071
|
||||
c0-4.393-0.527-6.049-2.448-6.049c-1.92,0-2.448,1.656-2.448,6.049C19.727,20.934,20.255,22.613,22.175,22.613z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.0 KiB |
|
Before Width: | Height: | Size: 410 B |
@@ -1,16 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M5.209,10.412h0.48c3.24,0,4.104-1.681,4.176-2.952h2.76V24.5h-3.36V12.764H5.209V10.412z"/>
|
||||
<path style="fill:#FFFFFF;" d="M18.553,10.412h0.48c3.24,0,4.104-1.681,4.176-2.952h2.76V24.5h-3.359V12.764h-4.056V10.412z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 827 B |
|
Before Width: | Height: | Size: 488 B |
@@ -1,18 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M4.813,10.412h0.48c3.24,0,4.104-1.681,4.176-2.952h2.76V24.5h-3.36V12.764H4.813V10.412z"/>
|
||||
<path style="fill:#FFFFFF;" d="M17.316,13.484c0-5.545,4.056-6.024,5.568-6.024c3.265,0,5.856,1.92,5.856,5.376
|
||||
c0,2.928-1.896,4.416-3.553,5.544c-2.256,1.584-3.432,2.353-3.815,3.145h7.392V24.5h-11.64c0.12-1.992,0.264-4.08,3.96-6.768
|
||||
c3.072-2.232,4.296-3.097,4.296-5.017c0-1.128-0.72-2.424-2.353-2.424c-2.352,0-2.423,1.944-2.447,3.192H17.316z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.0 KiB |
|
Before Width: | Height: | Size: 509 B |
@@ -1,20 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M3.813,10.412h0.48c3.24,0,4.104-1.681,4.176-2.952h2.76V24.5h-3.36V12.764H3.813V10.412z"/>
|
||||
<path style="fill:#FFFFFF;" d="M20.611,14.636h0.529c1.008,0,2.855-0.096,2.855-2.304c0-0.624-0.288-2.185-2.137-2.185
|
||||
c-2.303,0-2.303,2.185-2.303,2.784h-3.12c0-3.191,1.8-5.472,5.64-5.472c2.279,0,5.279,1.152,5.279,4.752
|
||||
c0,1.728-1.08,2.808-2.039,3.24V15.5c0.6,0.168,2.568,1.056,2.568,3.96c0,3.216-2.377,5.496-5.809,5.496
|
||||
c-1.607,0-5.928-0.36-5.928-5.688h3.288l-0.024,0.024c0,0.912,0.24,2.976,2.496,2.976c1.344,0,2.52-0.911,2.52-2.808
|
||||
c0-2.328-2.256-2.424-3.816-2.424V14.636z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.2 KiB |
|
Before Width: | Height: | Size: 499 B |
@@ -1,17 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M4.146,10.412h0.48c3.24,0,4.104-1.681,4.176-2.952h2.76V24.5h-3.36V12.764H4.146V10.412z"/>
|
||||
<path style="fill:#FFFFFF;" d="M28.457,20.732h-1.896V24.5h-3.36v-3.768h-6.72v-2.904L22.746,7.46h3.815v10.656h1.896V20.732z
|
||||
M23.201,18.116c0-4.128,0.072-6.792,0.072-7.32h-0.048l-4.272,7.32H23.201z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 906 B |
|
Before Width: | Height: | Size: 507 B |
@@ -1,19 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M3.479,11.079h0.48c3.24,0,4.104-1.681,4.176-2.952h2.76v17.04h-3.36V13.43H3.479V11.079z"/>
|
||||
<path style="fill:#FFFFFF;" d="M19.342,14.943c0.625-0.433,1.392-0.937,3.048-0.937c2.279,0,5.16,1.584,5.16,5.496
|
||||
c0,2.328-1.176,6.121-6.192,6.121c-2.664,0-5.376-1.584-5.544-5.016h3.36c0.144,1.391,0.888,2.326,2.376,2.326
|
||||
c1.607,0,2.544-1.367,2.544-3.191c0-1.512-0.72-3.047-2.496-3.047c-0.456,0-1.608,0.023-2.256,1.223l-3-0.143l1.176-9.361h9.36
|
||||
v2.832h-6.937L19.342,14.943z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.1 KiB |
@@ -1,20 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M3.813,10.412h0.48c3.24,0,4.104-1.681,4.176-2.952h2.76V24.5h-3.36V12.764H3.813V10.412z"/>
|
||||
<path style="fill:#FFFFFF;" d="M24.309,11.78c-0.097-0.96-0.721-1.633-1.969-1.633c-2.184,0-2.688,2.496-2.808,4.704L19.58,14.9
|
||||
c0.456-0.624,1.296-1.416,3.191-1.416c3.529,0,5.209,2.712,5.209,5.256c0,3.72-2.28,6.216-5.568,6.216
|
||||
c-5.16,0-6.168-4.32-6.168-8.568c0-3.24,0.432-8.928,6.336-8.928c0.695,0,2.641,0.264,3.48,1.104
|
||||
c0.936,0.912,1.271,1.416,1.584,3.217H24.309z M22.172,16.172c-1.271,0-2.568,0.792-2.568,2.928c0,1.849,1.056,3.168,2.664,3.168
|
||||
c1.225,0,2.353-0.936,2.353-3.239C24.62,16.868,23.229,16.172,22.172,16.172z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.2 KiB |
@@ -1,17 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M3.479,11.079h0.48c3.24,0,4.104-1.681,4.176-2.952h2.76v17.04h-3.36V13.43H3.479V11.079z"/>
|
||||
<path style="fill:#FFFFFF;" d="M27.838,11.006c-1.631,1.776-5.807,6.816-6.215,14.16h-3.457c0.36-6.816,4.632-12.24,6.072-13.776
|
||||
h-8.472l0.072-2.976h12V11.006z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 866 B |
@@ -1,21 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M4.813,10.412h0.48c3.24,0,4.104-1.681,4.176-2.952h2.76V24.5h-3.36V12.764H4.813V10.412z"/>
|
||||
<path style="fill:#FFFFFF;" d="M23.172,24.956c-4.392,0-5.904-2.856-5.904-5.185c0-0.863,0-3.119,2.592-4.319
|
||||
c-1.344-0.672-2.064-1.752-2.064-3.336c0-2.904,2.328-4.656,5.304-4.656c3.528,0,5.4,2.088,5.4,4.44
|
||||
c0,1.464-0.6,2.712-1.968,3.432c1.632,0.815,2.544,1.896,2.544,4.104C29.076,21.596,27.684,24.956,23.172,24.956z M23.124,16.916
|
||||
c-1.224,0-2.4,0.792-2.4,2.64c0,1.632,0.936,2.712,2.472,2.712c1.752,0,2.424-1.512,2.424-2.688
|
||||
C25.62,18.38,24.996,16.916,23.124,16.916z M25.284,12.26c0-1.296-0.888-2.112-1.968-2.112c-1.512,0-2.305,0.864-2.305,2.112
|
||||
c0,1.008,0.744,2.112,2.185,2.112C24.516,14.372,25.284,13.484,25.284,12.26z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.3 KiB |
@@ -1,20 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M4.146,10.746h0.48c3.24,0,4.104-1.681,4.176-2.952h2.76v17.041h-3.36V13.097H4.146V10.746z"/>
|
||||
<path style="fill:#FFFFFF;" d="M20.225,20.898v0.023c0.192,1.176,0.936,1.68,1.968,1.68c1.392,0,2.783-1.176,2.808-4.752
|
||||
l-0.048-0.049c-0.768,1.152-2.088,1.441-3.24,1.441c-3.264,0-5.16-2.473-5.16-5.329c0-4.176,2.472-6.12,5.808-6.12
|
||||
c5.904,0,6,6.36,6,8.76c0,6.601-3.12,8.736-6.192,8.736c-2.904,0-4.992-1.68-5.28-4.391H20.225z M22.434,16.553
|
||||
c1.176,0,2.472-0.84,2.472-2.855c0-1.944-0.841-3.145-2.568-3.145c-0.864,0-2.424,0.433-2.424,2.88
|
||||
C19.913,16.001,21.161,16.553,22.434,16.553z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.2 KiB |
|
Before Width: | Height: | Size: 446 B |
@@ -1,17 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M9.668,12.328c0-6.469,4.732-7.028,6.496-7.028c3.808,0,6.833,2.24,6.833,6.271
|
||||
c0,3.416-2.213,5.152-4.145,6.469c-2.632,1.848-4.004,2.744-4.452,3.668h8.624v3.472H9.444c0.14-2.324,0.308-4.76,4.62-7.896
|
||||
c3.584-2.604,5.012-3.612,5.012-5.853c0-1.315-0.84-2.828-2.744-2.828c-2.744,0-2.828,2.269-2.856,3.725H9.668z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 926 B |
@@ -1,20 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M3.972,13.484c0-5.545,4.056-6.024,5.568-6.024c3.264,0,5.856,1.92,5.856,5.376
|
||||
c0,2.928-1.896,4.416-3.552,5.544c-2.256,1.584-3.432,2.353-3.816,3.145h7.392V24.5H3.78c0.12-1.992,0.264-4.08,3.96-6.768
|
||||
c3.072-2.232,4.296-3.097,4.296-5.017c0-1.128-0.72-2.424-2.352-2.424c-2.352,0-2.424,1.944-2.448,3.192H3.972z"/>
|
||||
<path style="fill:#FFFFFF;" d="M23.172,7.46c4.008,0,5.904,2.76,5.904,8.736c0,5.976-1.896,8.76-5.904,8.76
|
||||
s-5.904-2.784-5.904-8.76C17.268,10.22,19.164,7.46,23.172,7.46z M23.172,22.268c1.92,0,2.448-1.68,2.448-6.071
|
||||
c0-4.393-0.528-6.049-2.448-6.049s-2.448,1.656-2.448,6.049C20.724,20.588,21.252,22.268,23.172,22.268z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.2 KiB |
@@ -1,18 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M5.306,13.151c0-5.545,4.056-6.024,5.568-6.024c3.264,0,5.856,1.92,5.856,5.376
|
||||
c0,2.928-1.896,4.416-3.552,5.544c-2.256,1.584-3.432,2.353-3.816,3.145h7.392v2.976H5.114c0.12-1.992,0.264-4.08,3.96-6.768
|
||||
c3.072-2.232,4.296-3.097,4.296-5.017c0-1.128-0.72-2.424-2.352-2.424c-2.352,0-2.424,1.944-2.448,3.192H5.306z"/>
|
||||
<path style="fill:#FFFFFF;" d="M19.49,10.079h0.48c3.239,0,4.104-1.681,4.176-2.952h2.761v17.04h-3.361V12.431H19.49V10.079z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.0 KiB |
@@ -1,20 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M3.972,13.484c0-5.545,4.056-6.024,5.568-6.024c3.264,0,5.856,1.92,5.856,5.376
|
||||
c0,2.928-1.896,4.416-3.552,5.544c-2.256,1.584-3.432,2.353-3.816,3.145h7.392V24.5H3.78c0.12-1.992,0.264-4.08,3.96-6.768
|
||||
c3.072-2.232,4.296-3.097,4.296-5.017c0-1.128-0.72-2.424-2.352-2.424c-2.352,0-2.424,1.944-2.448,3.192H3.972z"/>
|
||||
<path style="fill:#FFFFFF;" d="M17.316,13.484c0-5.545,4.056-6.024,5.568-6.024c3.265,0,5.856,1.92,5.856,5.376
|
||||
c0,2.928-1.896,4.416-3.553,5.544c-2.256,1.584-3.432,2.353-3.815,3.145h7.392V24.5h-11.64c0.12-1.992,0.264-4.08,3.96-6.768
|
||||
c3.072-2.232,4.296-3.097,4.296-5.017c0-1.128-0.72-2.424-2.353-2.424c-2.352,0-2.423,1.944-2.447,3.192H17.316z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.2 KiB |
@@ -1,22 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M3.972,13.484c0-5.545,4.056-6.024,5.568-6.024c3.264,0,5.856,1.92,5.856,5.376
|
||||
c0,2.928-1.896,4.416-3.552,5.544c-2.256,1.584-3.432,2.353-3.816,3.145h7.392V24.5H3.78c0.12-1.992,0.264-4.08,3.96-6.768
|
||||
c3.072-2.232,4.296-3.097,4.296-5.017c0-1.128-0.72-2.424-2.352-2.424c-2.352,0-2.424,1.944-2.448,3.192H3.972z"/>
|
||||
<path style="fill:#FFFFFF;" d="M21.612,14.636h0.528c1.008,0,2.855-0.096,2.855-2.304c0-0.624-0.287-2.185-2.136-2.185
|
||||
c-2.304,0-2.304,2.185-2.304,2.784h-3.12c0-3.191,1.8-5.472,5.64-5.472c2.28,0,5.28,1.152,5.28,4.752
|
||||
c0,1.728-1.08,2.808-2.04,3.24V15.5c0.6,0.168,2.568,1.056,2.568,3.96c0,3.216-2.377,5.496-5.809,5.496
|
||||
c-1.607,0-5.928-0.36-5.928-5.688h3.288l-0.024,0.024c0,0.912,0.24,2.976,2.496,2.976c1.344,0,2.521-0.911,2.521-2.808
|
||||
c0-2.328-2.257-2.424-3.816-2.424V14.636z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.4 KiB |
@@ -1,19 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M4.972,13.484c0-5.545,4.056-6.024,5.568-6.024c3.264,0,5.856,1.92,5.856,5.376
|
||||
c0,2.928-1.896,4.416-3.552,5.544c-2.256,1.584-3.432,2.353-3.816,3.145h7.392V24.5H4.78c0.12-1.992,0.264-4.08,3.96-6.768
|
||||
c3.072-2.232,4.296-3.097,4.296-5.017c0-1.128-0.72-2.424-2.352-2.424c-2.352,0-2.424,1.944-2.448,3.192H4.972z"/>
|
||||
<path style="fill:#FFFFFF;" d="M30.124,20.732h-1.896V24.5h-3.36v-3.768h-6.72v-2.904L24.412,7.46h3.816v10.656h1.896V20.732z
|
||||
M24.868,18.116c0-4.128,0.071-6.792,0.071-7.32h-0.047l-4.272,7.32H24.868z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.1 KiB |
@@ -1,21 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M3.972,13.484c0-5.545,4.056-6.024,5.568-6.024c3.264,0,5.856,1.92,5.856,5.376
|
||||
c0,2.928-1.896,4.416-3.552,5.544c-2.256,1.584-3.432,2.353-3.816,3.145h7.392V24.5H3.78c0.12-1.992,0.264-4.08,3.96-6.768
|
||||
c3.072-2.232,4.296-3.097,4.296-5.017c0-1.128-0.72-2.424-2.352-2.424c-2.352,0-2.424,1.944-2.448,3.192H3.972z"/>
|
||||
<path style="fill:#FFFFFF;" d="M20.676,14.276c0.624-0.433,1.393-0.937,3.049-0.937c2.279,0,5.16,1.584,5.16,5.496
|
||||
c0,2.328-1.177,6.12-6.193,6.12c-2.664,0-5.375-1.584-5.543-5.016h3.36c0.144,1.392,0.889,2.327,2.376,2.327
|
||||
c1.608,0,2.544-1.367,2.544-3.191c0-1.513-0.72-3.048-2.496-3.048c-0.455,0-1.607,0.023-2.256,1.224l-3-0.144l1.176-9.36h9.36
|
||||
v2.832h-6.937L20.676,14.276z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.3 KiB |
@@ -1,22 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M3.972,13.484c0-5.545,4.056-6.024,5.568-6.024c3.264,0,5.856,1.92,5.856,5.376
|
||||
c0,2.928-1.896,4.416-3.552,5.544c-2.256,1.584-3.432,2.353-3.816,3.145h7.392V24.5H3.78c0.12-1.992,0.264-4.08,3.96-6.768
|
||||
c3.072-2.232,4.296-3.097,4.296-5.017c0-1.128-0.72-2.424-2.352-2.424c-2.352,0-2.424,1.944-2.448,3.192H3.972z"/>
|
||||
<path style="fill:#FFFFFF;" d="M25.309,11.78c-0.097-0.96-0.721-1.633-1.969-1.633c-2.184,0-2.688,2.496-2.808,4.704L20.58,14.9
|
||||
c0.456-0.624,1.296-1.416,3.191-1.416c3.529,0,5.209,2.712,5.209,5.256c0,3.72-2.28,6.216-5.568,6.216
|
||||
c-5.16,0-6.168-4.32-6.168-8.568c0-3.24,0.432-8.928,6.336-8.928c0.695,0,2.641,0.264,3.48,1.104
|
||||
c0.936,0.912,1.271,1.416,1.584,3.217H25.309z M23.172,16.172c-1.271,0-2.568,0.792-2.568,2.928c0,1.849,1.056,3.168,2.664,3.168
|
||||
c1.225,0,2.353-0.936,2.353-3.239C25.62,16.868,24.229,16.172,23.172,16.172z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.4 KiB |
@@ -1,19 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M3.972,13.484c0-5.545,4.056-6.024,5.568-6.024c3.264,0,5.856,1.92,5.856,5.376
|
||||
c0,2.928-1.896,4.416-3.552,5.544c-2.256,1.584-3.432,2.353-3.816,3.145h7.392V24.5H3.78c0.12-1.992,0.264-4.08,3.96-6.768
|
||||
c3.072-2.232,4.296-3.097,4.296-5.017c0-1.128-0.72-2.424-2.352-2.424c-2.352,0-2.424,1.944-2.448,3.192H3.972z"/>
|
||||
<path style="fill:#FFFFFF;" d="M29.172,10.34c-1.632,1.776-5.808,6.816-6.216,14.16H19.5c0.36-6.816,4.632-12.24,6.072-13.776
|
||||
H17.1l0.072-2.976h12V10.34z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.1 KiB |
@@ -1,23 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M3.972,13.484c0-5.545,4.056-6.024,5.568-6.024c3.264,0,5.856,1.92,5.856,5.376
|
||||
c0,2.928-1.896,4.416-3.552,5.544c-2.256,1.584-3.432,2.353-3.816,3.145h7.392V24.5H3.78c0.12-1.992,0.264-4.08,3.96-6.768
|
||||
c3.072-2.232,4.296-3.097,4.296-5.017c0-1.128-0.72-2.424-2.352-2.424c-2.352,0-2.424,1.944-2.448,3.192H3.972z"/>
|
||||
<path style="fill:#FFFFFF;" d="M23.172,24.956c-4.392,0-5.904-2.856-5.904-5.185c0-0.863,0-3.119,2.592-4.319
|
||||
c-1.344-0.672-2.064-1.752-2.064-3.336c0-2.904,2.328-4.656,5.304-4.656c3.528,0,5.4,2.088,5.4,4.44
|
||||
c0,1.464-0.6,2.712-1.968,3.432c1.632,0.815,2.544,1.896,2.544,4.104C29.076,21.596,27.684,24.956,23.172,24.956z M23.124,16.916
|
||||
c-1.224,0-2.4,0.792-2.4,2.64c0,1.632,0.936,2.712,2.472,2.712c1.752,0,2.424-1.512,2.424-2.688
|
||||
C25.62,18.38,24.996,16.916,23.124,16.916z M25.284,12.26c0-1.296-0.888-2.112-1.968-2.112c-1.512,0-2.305,0.864-2.305,2.112
|
||||
c0,1.008,0.744,2.112,2.185,2.112C24.516,14.372,25.284,13.484,25.284,12.26z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.5 KiB |
@@ -1,22 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M3.972,13.484c0-5.545,4.056-6.024,5.568-6.024c3.264,0,5.856,1.92,5.856,5.376
|
||||
c0,2.928-1.896,4.416-3.552,5.544c-2.256,1.584-3.432,2.353-3.816,3.145h7.392V24.5H3.78c0.12-1.992,0.264-4.08,3.96-6.768
|
||||
c3.072-2.232,4.296-3.097,4.296-5.017c0-1.128-0.72-2.424-2.352-2.424c-2.352,0-2.424,1.944-2.448,3.192H3.972z"/>
|
||||
<path style="fill:#FFFFFF;" d="M20.893,20.564v0.023c0.191,1.176,0.936,1.68,1.967,1.68c1.393,0,2.785-1.176,2.809-4.752
|
||||
l-0.048-0.048c-0.769,1.152-2.088,1.44-3.24,1.44c-3.264,0-5.16-2.473-5.16-5.328c0-4.176,2.472-6.12,5.807-6.12
|
||||
c5.904,0,6.001,6.36,6.001,8.76c0,6.601-3.12,8.736-6.192,8.736c-2.904,0-4.992-1.68-5.28-4.392H20.893z M23.1,16.22
|
||||
c1.176,0,2.473-0.84,2.473-2.855c0-1.944-0.84-3.145-2.568-3.145c-0.863,0-2.424,0.433-2.424,2.88
|
||||
C20.58,15.668,21.828,16.22,23.1,16.22z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.4 KiB |
|
Before Width: | Height: | Size: 431 B |
@@ -1,19 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M15.127,14.005h0.616c1.176,0,3.332-0.112,3.332-2.688c0-0.728-0.336-2.548-2.492-2.548
|
||||
c-2.688,0-2.688,2.548-2.688,3.248h-3.64c0-3.724,2.1-6.384,6.58-6.384c2.66,0,6.16,1.344,6.16,5.544
|
||||
c0,2.016-1.261,3.276-2.38,3.78v0.056c0.699,0.196,2.996,1.232,2.996,4.62c0,3.752-2.772,6.412-6.776,6.412
|
||||
c-1.876,0-6.916-0.42-6.916-6.636h3.836l-0.028,0.027c0,1.064,0.28,3.473,2.912,3.473c1.568,0,2.94-1.064,2.94-3.276
|
||||
c0-2.716-2.632-2.828-4.452-2.828V14.005z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.0 KiB |
@@ -1,22 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M8.268,14.636h0.528c1.008,0,2.856-0.096,2.856-2.304c0-0.624-0.288-2.185-2.136-2.185
|
||||
c-2.304,0-2.304,2.185-2.304,2.784h-3.12c0-3.191,1.8-5.472,5.64-5.472c2.28,0,5.28,1.152,5.28,4.752
|
||||
c0,1.728-1.08,2.808-2.04,3.24V15.5c0.6,0.168,2.568,1.056,2.568,3.96c0,3.216-2.376,5.496-5.808,5.496
|
||||
c-1.608,0-5.928-0.36-5.928-5.688h3.288l-0.024,0.024c0,0.912,0.24,2.976,2.496,2.976c1.344,0,2.52-0.911,2.52-2.808
|
||||
c0-2.328-2.256-2.424-3.816-2.424V14.636z"/>
|
||||
<path style="fill:#FFFFFF;" d="M23.172,7.46c4.008,0,5.904,2.76,5.904,8.736c0,5.976-1.896,8.76-5.904,8.76
|
||||
s-5.904-2.784-5.904-8.76C17.268,10.22,19.164,7.46,23.172,7.46z M23.172,22.268c1.92,0,2.448-1.68,2.448-6.071
|
||||
c0-4.393-0.528-6.049-2.448-6.049s-2.448,1.656-2.448,6.049C20.724,20.588,21.252,22.268,23.172,22.268z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.4 KiB |
|
Before Width: | Height: | Size: 441 B |
@@ -1,16 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M21.891,20.784h-2.212v4.396h-3.92v-4.396h-7.84v-3.389L15.227,5.3h4.452v12.432h2.212V20.784z
|
||||
M15.759,17.731c0-4.815,0.084-7.924,0.084-8.54h-0.056l-4.984,8.54H15.759z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 783 B |
|
Before Width: | Height: | Size: 423 B |
@@ -1,18 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M14.035,14.252c0.728-0.504,1.624-1.092,3.556-1.092c2.66,0,6.02,1.848,6.02,6.411
|
||||
c0,2.717-1.372,7.141-7.224,7.141c-3.108,0-6.272-1.849-6.468-5.853h3.92c0.168,1.624,1.036,2.717,2.772,2.717
|
||||
c1.876,0,2.968-1.597,2.968-3.725c0-1.764-0.839-3.556-2.912-3.556c-0.532,0-1.876,0.028-2.632,1.428l-3.5-0.168l1.372-10.92
|
||||
h10.919v3.304h-8.092L14.035,14.252z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 967 B |
|
Before Width: | Height: | Size: 431 B |
@@ -1,19 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M19.106,10.673c-0.112-1.12-0.84-1.904-2.296-1.904c-2.548,0-3.136,2.912-3.276,5.488l0.056,0.056
|
||||
c0.532-0.728,1.512-1.651,3.724-1.651c4.116,0,6.077,3.164,6.077,6.131c0,4.34-2.66,7.252-6.497,7.252
|
||||
c-6.02,0-7.196-5.039-7.196-9.996c0-3.78,0.504-10.416,7.392-10.416c0.812,0,3.08,0.308,4.061,1.288
|
||||
c1.092,1.063,1.483,1.652,1.848,3.752H19.106z M16.614,15.797c-1.484,0-2.996,0.924-2.996,3.416c0,2.156,1.232,3.697,3.108,3.697
|
||||
c1.428,0,2.745-1.094,2.745-3.781C19.471,16.609,17.846,15.797,16.614,15.797z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.1 KiB |
|
Before Width: | Height: | Size: 397 B |
@@ -1,16 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M24.28,9.66c-1.904,2.071-6.776,7.951-7.252,16.52h-4.032c0.42-7.952,5.404-14.28,7.084-16.072
|
||||
h-9.884l0.084-3.472h14V9.66z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 738 B |
|
Before Width: | Height: | Size: 434 B |
@@ -1,20 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M16.28,26.712c-5.124,0-6.888-3.332-6.888-6.048c0-1.009,0-3.641,3.024-5.04
|
||||
c-1.568-0.784-2.408-2.044-2.408-3.893c0-3.388,2.716-5.432,6.188-5.432c4.116,0,6.3,2.436,6.3,5.18
|
||||
c0,1.708-0.7,3.164-2.296,4.004c1.903,0.952,2.968,2.212,2.968,4.788C23.168,22.792,21.544,26.712,16.28,26.712z M16.224,17.332
|
||||
c-1.428,0-2.8,0.924-2.8,3.08c0,1.903,1.092,3.164,2.884,3.164c2.043,0,2.829-1.765,2.829-3.137
|
||||
C19.137,19.04,18.408,17.332,16.224,17.332z M18.744,11.899c0-1.512-1.036-2.464-2.296-2.464c-1.764,0-2.688,1.008-2.688,2.464
|
||||
c0,1.177,0.868,2.464,2.548,2.464C17.848,14.363,18.744,13.328,18.744,11.899z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.2 KiB |
|
Before Width: | Height: | Size: 420 B |
@@ -1,19 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448) -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY ns_svg "http://www.w3.org/2000/svg">
|
||||
<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
|
||||
]>
|
||||
<svg version="1.0" id="Layer_1" xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" width="33" height="33" viewBox="0 0 33 33"
|
||||
style="overflow:visible;enable-background:new 0 0 33 33;" xml:space="preserve">
|
||||
<circle style="stroke:#000000;" cx="16.5" cy="16.5" r="16"/>
|
||||
<g>
|
||||
<g style="enable-background:new ;">
|
||||
<path style="fill:#FFFFFF;" d="M13.953,21.921v0.027c0.224,1.372,1.092,1.961,2.296,1.961c1.624,0,3.248-1.372,3.276-5.545
|
||||
l-0.057-0.056c-0.896,1.344-2.436,1.68-3.78,1.68c-3.808,0-6.02-2.884-6.02-6.216c0-4.872,2.884-7.14,6.776-7.14
|
||||
c6.888,0,7,7.42,7,10.22c0,7.7-3.641,10.192-7.224,10.192c-3.388,0-5.824-1.96-6.16-5.124H13.953z M16.529,16.853
|
||||
c1.372,0,2.884-0.979,2.884-3.332c0-2.268-0.98-3.668-2.996-3.668c-1.008,0-2.828,0.504-2.828,3.36
|
||||
C13.589,16.209,15.045,16.853,16.529,16.853z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.0 KiB |
|
Before Width: | Height: | Size: 1.2 KiB |
@@ -1,68 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Generator: Adobe Illustrator 12.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 51448) --><svg height="120.648" id="Layer_1" inkscape:version="0.42" sodipodi:docbase="F:\openclip\svg da inviare" sodipodi:docname="Attenzione.svg" sodipodi:version="0.32" space="preserve" style="overflow:visible;enable-background:new 0 0 133.878 120.648;" version="1.1" viewBox="0 0 133.878 120.648" width="133.878" xmlns="http://www.w3.org/2000/svg" xmlns:cc="http://web.resource.org/cc/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:sodipodi="http://inkscape.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:svg="http://www.w3.org/2000/svg">
|
||||
<metadata>
|
||||
<rdf:RDF xmlns:cc="http://web.resource.org/cc/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
|
||||
<cc:Work rdf:about="">
|
||||
<dc:title>Attenzione</dc:title>
|
||||
<dc:description></dc:description>
|
||||
<dc:subject>
|
||||
<rdf:Bag>
|
||||
<rdf:li>pulsante</rdf:li>
|
||||
</rdf:Bag>
|
||||
</dc:subject>
|
||||
<dc:publisher>
|
||||
<cc:Agent rdf:about="http://www.openclipart.org/">
|
||||
<dc:title>Open Clip Art Library</dc:title>
|
||||
</cc:Agent>
|
||||
</dc:publisher>
|
||||
<dc:creator>
|
||||
<cc:Agent>
|
||||
<dc:title>Architetto Francesco Rollandin</dc:title>
|
||||
</cc:Agent>
|
||||
</dc:creator>
|
||||
<dc:rights>
|
||||
<cc:Agent>
|
||||
<dc:title>Architetto Francesco Rollandin</dc:title>
|
||||
</cc:Agent>
|
||||
</dc:rights>
|
||||
<dc:date></dc:date>
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/>
|
||||
<cc:license rdf:resource="http://web.resource.org/cc/PublicDomain"/>
|
||||
<dc:language>en</dc:language>
|
||||
</cc:Work>
|
||||
<cc:License rdf:about="http://web.resource.org/cc/PublicDomain">
|
||||
<cc:permits rdf:resource="http://web.resource.org/cc/Reproduction"/>
|
||||
<cc:permits rdf:resource="http://web.resource.org/cc/Distribution"/>
|
||||
<cc:permits rdf:resource="http://web.resource.org/cc/DerivativeWorks"/>
|
||||
</cc:License>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<defs id="defs43"/>
|
||||
<sodipodi:namedview bordercolor="#666666" borderopacity="1.0" id="base" inkscape:current-layer="Layer_1" inkscape:cx="66.939003" inkscape:cy="60.324001" inkscape:pageopacity="0.0" inkscape:pageshadow="2" inkscape:window-height="510" inkscape:window-width="787" inkscape:window-x="44" inkscape:window-y="58" inkscape:zoom="2.9838869" pagecolor="#ffffff"/>
|
||||
<g id="g3">
|
||||
<linearGradient gradientTransform="matrix(56.9977 90.4964 90.4964 -56.9977 -27343.9609 47971.0547)" gradientUnits="userSpaceOnUse" id="XMLID_4_" x1="-244.5732" x2="-242.8169" y1="455.4199" y2="455.4199">
|
||||
<stop id="stop6" offset="0" style="stop-color:#FFFA5F"/>
|
||||
<stop id="stop8" offset="1" style="stop-color:#9F3300"/>
|
||||
</linearGradient>
|
||||
<path d="M51.333,8.834C34.985,37.343,18.638,65.854,2.289,94.363 c-7.081,12.352,3.352,26.285,16.453,26.285c6.708,0,13.418,0,20.128,0c22.109,0,44.217,0,66.327,0c3.644,0,7.286,0,10.931,0 c13.293,0,20.963-14.273,16.452-26.031c-4.114-10.729-11.861-20.99-17.542-30.922c-8.81-15.403-17.618-30.809-26.429-46.212 c-1.813-3.167-3.622-6.333-5.434-9.5C76.601-3.516,57.616-2.03,51.333,8.834 M53.973,9.064" id="path10" style="fill:url(#XMLID_4_);"/>
|
||||
<path d="M55.474,12.388c-8.247,14.279-16.492,28.559-24.739,42.839 c-5.526,9.567-11.05,19.137-16.577,28.707c-2.732,4.73-7.323,10.456-8.284,16c-3.799,21.9,34.927,15.743,46.734,15.743 c20.073,0,40.144,0,60.215,0c13.716,0,18.636-11.963,12.229-23.063c-6.462-11.195-12.927-22.388-19.389-33.582 c-7.249-12.557-14.499-25.113-21.75-37.671c-1.682-2.916-3.364-5.829-5.049-8.745C73.767,3.785,60.676,3.364,55.474,12.388" id="path12" style="fill-rule:evenodd;clip-rule:evenodd;fill:#FFF200;"/>
|
||||
<path d="M55.474,12.388c-8.247,14.279-16.492,28.559-24.739,42.839c-5.526,9.567-11.05,19.137-16.577,28.707 c-2.732,4.73-7.323,10.456-8.284,16c-3.799,21.9,34.927,15.743,46.734,15.743c20.073,0,40.144,0,60.215,0 c13.716,0,18.636-11.963,12.229-23.063c-6.462-11.195-12.927-22.388-19.389-33.582c-7.249-12.557-14.499-25.113-21.75-37.671 c-1.682-2.916-3.364-5.829-5.049-8.745C73.767,3.785,60.676,3.364,55.474,12.388" id="path14" style="fill:#FFCE00;"/>
|
||||
<path d="M126.731,95.522c-8.733-15.127-17.468-30.253-26.201-45.379 c-5.537-9.595-11.078-19.188-16.616-28.781c-3.938-6.821-7.459-15.689-16.813-15.689c1.013,0,5.901,10.225,6.469,11.196 c5.451,9.314,10.902,18.63,16.352,27.947c9.217,15.749,18.433,31.498,27.646,47.249c2.302,3.933,5.356,10.555,1.308,14.397 c-3.148,2.987-7.99,3.196-12.099,3.196c-7.225,0-14.448,0-21.674,0c-22.125,0-44.251,0-66.377,0c-3.598,0-7.197,0-10.794,0 c5.285,7.909,16.341,6.02,24.546,6.02c13.009,0,26.017,0,39.023,0c11.979,0,23.958,0,35.937,0c2.516,0,5.032,0,7.547,0 C125.136,115.678,131.878,104.435,126.731,95.522" id="path16" style="fill:#FFB600;"/>
|
||||
<path d="M14.615,112.457c-4.483-7.751,1.908-16.103,5.793-22.834 c4.698-8.138,9.398-16.276,14.097-24.414C44.54,47.83,54.574,30.448,64.61,13.069c0.789-1.367,3.725-4.568,2.594-5.539 c-3.913-3.353-10.287,1.936-12.107,5.087c-3.129,5.417-6.258,10.835-9.386,16.252c-11.105,19.226-22.209,38.453-33.313,57.68 c-1.649,2.854-3.299,5.713-4.95,8.569c-4.771,8.265-0.075,19.162,9.658,20.446C16.124,114.65,15.294,113.615,14.615,112.457" id="path18" style="fill-rule:evenodd;clip-rule:evenodd;fill:#FFE600;"/>
|
||||
<path d="M77.076,34.654c0,10.183-1.788,20.758-3.439,30.772 c-0.369,2.239-4.03,23.609-7.796,14.179c-4.247-10.632-4.832-23.419-5.958-34.696c-0.363-3.638-1.538-8.425-0.563-12.06 C61.667,24.099,77.076,25.199,77.076,34.654" id="path20" style="fill-rule:evenodd;clip-rule:evenodd;fill:#FFFFE1;"/>
|
||||
<path d="M77.076,34.654c-2.018,0.995-1.521,8.717-1.797,11.395c-0.685,6.643-1.505,13.282-2.614,19.869 c-0.79,4.701-1.301,10.862-3.954,14.981c-1.642,2.567-3.405-5.958-3.634-6.932c-2.948-12.443-4.464-25.664-5.09-38.43 c-0.272-5.52,5.164-8.854,10.277-7.622c3.87,0.933,5.217,7.36,7.688,6.738c0.009-11.451-19.755-11.453-19.746,0 c0.017,11.956,2.087,24.599,4.423,36.294c0.501,2.507,1.642,12.376,5.449,12.376c4.059-0.021,5.285-11.432,5.79-14.137 c1.261-6.765,2.139-13.605,2.887-20.444C77.084,45.722,79.281,35.942,77.076,34.654" id="path22" style="fill:#FFFFFF;"/>
|
||||
<linearGradient gradientTransform="matrix(68.2284 33.0019 33.0019 -68.2284 1613.9791 39385.6641)" gradientUnits="userSpaceOnUse" id="XMLID_5_" x1="-246.981" x2="-245.2275" y1="458.29" y2="458.29">
|
||||
<stop id="stop25" offset="0" style="stop-color:#FFFA5F"/>
|
||||
<stop id="stop27" offset="1" style="stop-color:#9F3300"/>
|
||||
</linearGradient>
|
||||
<path d="M57.957,34.654c0,10.053,1.632,20.54,3.242,30.431 c0.479,2.936,4.912,26.502,9.99,15.164c4.987-11.134,5.351-25.201,6.386-37.184c0.273-3.169,1.153-7.045,0.421-10.221 C75.628,22.587,57.957,23.788,57.957,34.654 M60.207,34.654c0-8.061,13.138-9.015,15.459-1.792c1.156,3.597-0.13,8.748-0.508,12.38 c-1.135,10.904-2.052,22.602-5.501,33.069c-2.816,8.545-5.546-10.187-5.934-12.522C62.039,55.63,60.207,44.985,60.207,34.654" id="path29" style="fill-rule:evenodd;clip-rule:evenodd;fill:url(#XMLID_5_);"/>
|
||||
<path d="M77.076,96.788c0,11.964-18.555,11.964-18.555,0 C58.521,84.822,77.076,84.822,77.076,96.788" id="path31" style="fill-rule:evenodd;clip-rule:evenodd;fill:#FFFFE1;"/>
|
||||
<path d="M77.076,96.788c-2.605,1.661-2.157,6.757-7.044,8.101c-6.178,1.7-12.033-4.159-10.336-10.335 c1.439-5.23,7.657-7.767,12.341-5.021c2.91,1.704,3.164,7.913,5.915,7.256c0-14.267-22.698-12.238-20.143,1.826 c0.987,5.444,6.375,9.15,11.814,8.162C72.417,106.271,81.44,98.19,77.076,96.788" id="path33" style="fill:#FFFFFF;"/>
|
||||
<linearGradient gradientTransform="matrix(68.2241 32.9998 32.9998 -68.2241 1604.682 39402.625)" gradientUnits="userSpaceOnUse" id="XMLID_6_" x1="-246.998" x2="-245.2348" y1="458.0625" y2="458.0625">
|
||||
<stop id="stop36" offset="0" style="stop-color:#FFFA5F"/>
|
||||
<stop id="stop38" offset="1" style="stop-color:#9F3300"/>
|
||||
</linearGradient>
|
||||
<path d="M57.395,96.788c0,13.41,20.805,13.41,20.805,0 C78.2,83.376,57.395,83.375,57.395,96.788 M59.647,96.788c0-10.514,16.301-10.514,16.301,0 C75.948,107.3,59.647,107.3,59.647,96.788" id="path40" style="fill-rule:evenodd;clip-rule:evenodd;fill:url(#XMLID_6_);"/>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 8.3 KiB |
|
Before Width: | Height: | Size: 17 KiB |
@@ -1,26 +0,0 @@
|
||||
<?xml version="1.0" encoding="iso-8859-1"?>
|
||||
<!-- Generator: Adobe Illustrator 9.0, SVG Export Plug-In -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY st0 "fill-rule:nonzero;clip-rule:nonzero;fill:#FFFFFF;stroke:#000000;stroke-miterlimit:4;">
|
||||
<!ENTITY st1 "fill:none;stroke:none;">
|
||||
<!ENTITY st2 "fill:#000000;">
|
||||
<!ENTITY st3 "fill:none;stroke:#FFFFFF;stroke-width:6.3469;stroke-linejoin:round;">
|
||||
<!ENTITY st4 "fill-rule:evenodd;clip-rule:evenodd;stroke:none;">
|
||||
<!ENTITY st5 "fill-rule:nonzero;clip-rule:nonzero;stroke:#000000;stroke-miterlimit:4;">
|
||||
]>
|
||||
<svg width="48pt" height="48pt" viewBox="0 0 48 48" xml:space="preserve" xmlns="http://www.w3.org/2000/svg">
|
||||
<g id="Layer_x0020_3" style="&st0;">
|
||||
<g style="&st4;">
|
||||
<path style="&st3;" d="M22.9,7.1L5.1,21.8l0,0c-0.3,0.3-0.5,0.8-0.5,1.2c0,0.2,0,0.4,0.1,0.6c0.3,0.6,0.9,1,1.6,1c0,0,1.1,0,2.2,0c0,2.4,0,14.2,0,14.2c0,1.1,0.8,1.9,1.8,1.9h27.4c1.1,0,1.9-0.9,1.9-2c0,0,0-11.8,0-14.2c1,0,2,0,2,0c0.8,0,1.4-0.5,1.7-1.2
|
||||
c0.1-0.2,0.1-0.4,0.1-0.6c0-0.5-0.2-1-0.7-1.4c0,0-3.6-3-4.5-3.7c0-1.2,0-6.9,0-6.9c0-1.2-0.8-2-2-2h-4.8c-1,0-1.7,0.6-1.9,1.5c-1.9-1.6-4.1-3.5-4.1-3.5l0.1,0.1c-0.7-0.7-1.8-0.8-2.7-0.1z"/>
|
||||
<path style="&st2;" d="M22.9,7.1L5.1,21.8l0,0c-0.3,0.3-0.5,0.8-0.5,1.2c0,0.2,0,0.4,0.1,0.6c0.3,0.6,0.9,1,1.6,1c0,0,1.1,0,2.2,0c0,2.4,0,14.2,0,14.2c0,1.1,0.8,1.9,1.8,1.9h27.4c1.1,0,1.9-0.9,1.9-2c0,0,0-11.8,0-14.2c1,0,2,0,2,0c0.8,0,1.4-0.5,1.7-1.2
|
||||
c0.1-0.2,0.1-0.4,0.1-0.6c0-0.5-0.2-1-0.7-1.4c0,0-3.6-3-4.5-3.7c0-1.2,0-6.9,0-6.9c0-1.2-0.8-2-2-2h-4.8c-1,0-1.7,0.6-1.9,1.5c-1.9-1.6-4.1-3.5-4.1-3.5l0.1,0.1c-0.7-0.7-1.8-0.8-2.7-0.1z"/>
|
||||
<path style="&st2;" d="M41.8,22.8l-5.1-4.2v-0.1L31,13.7v0l-6.5-5.5C24.2,8,24,8,23.8,8.2L6.2,22.9c-0.1,0.1-0.1,0.3,0.1,0.3h1.6H10h28.1h1.2h2.3c0.2,0,0.4-0.2,0.2-0.4z"/>
|
||||
<path d="M35.8,16.8l0-5.1c0-0.2-0.1-0.4-0.3-0.4h-3.2c-0.2,0-0.3,0.1-0.3,0.3v2.2l3.9,2.9z"/>
|
||||
<path d="M11.9,24.7V37c0,0.3,0.1,0.4,0.3,0.4h23.6c0.3,0,0.4-0.2,0.4-0.4V24.7H11.9z"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="crop_x0020_marks" style="&st5;">
|
||||
<path style="&st1;" d="M48,48H0V0h48v48z"/>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 2.0 KiB |
|
Before Width: | Height: | Size: 722 B |
@@ -1,25 +0,0 @@
|
||||
<?xml version="1.0" encoding="iso-8859-1"?>
|
||||
<!-- Generator: Adobe Illustrator 9.0, SVG Export Plug-In -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY st0 "fill:#FFFFFF;stroke:none;">
|
||||
<!ENTITY st1 "fill:#FFFFFF;stroke-width:6.6112;stroke-linecap:round;stroke-linejoin:round;">
|
||||
<!ENTITY st2 "stroke:#FFFFFF;stroke-width:6.6112;">
|
||||
<!ENTITY st3 "fill:none;stroke:none;">
|
||||
<!ENTITY st4 "fill-rule:nonzero;clip-rule:nonzero;stroke:#000000;stroke-miterlimit:4;">
|
||||
<!ENTITY st5 "stroke:none;">
|
||||
]>
|
||||
<svg width="48pt" height="48pt" viewBox="0 0 48 48" xml:space="preserve" xmlns="http://www.w3.org/2000/svg">
|
||||
<g id="Layer_x0020_3" style="&st4;">
|
||||
<g>
|
||||
<path style="&st2;" d="M41.7,35.3L26.6,9.4c-0.6-1-1.7-1.7-2.9-1.6c-1.2,0-2.3,0.7-2.9,1.7L6.3,35.4c-0.6,1-0.6,2.3,0,3.3c0.6,1,1.7,1.6,2.9,1.6h29.6c1.2,0,2.3-0.6,2.9-1.7c0.6-1,0.6-2.3,0-3.3z"/>
|
||||
<path style="&st1;" d="M23.7,11L9.2,37h29.6L23.7,11z"/>
|
||||
<path style="&st0;" d="M23.7,11.9L10.3,36.1h27.5l-14-24.1z"/>
|
||||
<g>
|
||||
<path style="&st5;" d="M24.1,34c-1.1,0-1.8-0.8-1.8-1.8c0-1.1,0.7-1.8,1.8-1.8c1.1,0,1.8,0.7,1.8,1.8c0,1-0.7,1.8-1.8,1.8h0z M22.9,29.3l-0.4-9.1h3.2l-0.4,9.1h-2.3z"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="crop_x0020_marks" style="&st4;">
|
||||
<path style="&st3;" d="M48,48H0V0h48v48z"/>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.2 KiB |
@@ -1,19 +0,0 @@
|
||||
<?xml version="1.0" encoding="iso-8859-1"?>
|
||||
<!-- Generator: Adobe Illustrator 9.0, SVG Export Plug-In -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY st0 "fill:none;stroke:none;">
|
||||
<!ENTITY st1 "fill:#FFFFFF;stroke:#FFFFFF;stroke-width:7.5901;stroke-linejoin:round;">
|
||||
<!ENTITY st2 "fill-rule:nonzero;clip-rule:nonzero;stroke:#000000;stroke-miterlimit:4;">
|
||||
<!ENTITY st3 "stroke:none;">
|
||||
]>
|
||||
<svg width="48pt" height="48pt" viewBox="0 0 48 48" xml:space="preserve" xmlns="http://www.w3.org/2000/svg">
|
||||
<g id="Layer_x0020_3" style="&st2;">
|
||||
<g>
|
||||
<path style="&st1;" d="M22.4,41.1c0,0.3,0.3,0.3,0.5,0.2l16.6-16.9c0.5-0.5,0.4-0.7,0-1L22.9,6.7c-0.1-0.1-0.4-0.1-0.4,0.1v10H8.9c-0.3,0-0.5,0.2-0.5,0.4l0,13.3C8.4,30.9,8.6,31,9,31h13.5l-0.1,10.1z"/>
|
||||
<path style="&st3;" d="M22.4,41.1c0,0.3,0.3,0.3,0.5,0.2l16.6-16.9c0.5-0.5,0.4-0.7,0-1L22.9,6.7c-0.1-0.1-0.4-0.1-0.4,0.1v10H8.9c-0.3,0-0.5,0.2-0.5,0.4l0,13.3C8.4,30.9,8.6,31,9,31h13.5l-0.1,10.1z"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="crop_x0020_marks" style="&st2;">
|
||||
<path style="&st0;" d="M48,48H0V0h48v48z"/>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.0 KiB |
|
Before Width: | Height: | Size: 1.1 KiB |
|
Before Width: | Height: | Size: 490 B |
@@ -1,33 +0,0 @@
|
||||
<?xml version="1.0" encoding="iso-8859-1"?>
|
||||
<!-- Generator: Adobe Illustrator 9.0, SVG Export Plug-In -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY st0 "fill:none;stroke:#FFFFFF;stroke-width:12.1438;stroke-linejoin:round;">
|
||||
<!ENTITY st1 "fill:none;stroke-width:1.2429;">
|
||||
<!ENTITY st2 "fill:#FFFFFF;stroke:none;">
|
||||
<!ENTITY st3 "fill:none;stroke:#FFFFFF;stroke-width:12.7649;stroke-linejoin:round;">
|
||||
<!ENTITY st4 "fill:#FFFFFF;stroke-width:6.3824;stroke-linejoin:round;">
|
||||
<!ENTITY st5 "fill:none;stroke:none;">
|
||||
<!ENTITY st6 "fill-rule:nonzero;clip-rule:nonzero;stroke:#000000;stroke-miterlimit:4;">
|
||||
<!ENTITY st7 "fill:#FFFFFF;stroke:#FFFFFF;stroke-width:12.7649;stroke-linejoin:round;">
|
||||
<!ENTITY st8 "stroke:none;">
|
||||
<!ENTITY st9 "fill:none;stroke-width:4.9715;stroke-linejoin:round;">
|
||||
]>
|
||||
<svg xmlns="http://www.w3.org/2000/svg" width="48pt" height="48pt" viewBox="0 0 48 48" xml:space="preserve">
|
||||
<g id="Layer_x0020_1" style="&st6;">
|
||||
<path style="&st0;" d="M35.7,19.8v18.9H11V8.8h13.9l10.8,11z"/>
|
||||
<path style="&st3;" d="M38.7,30.4L25,16.7l-7.7-3l2.7,8.7l13.3,13.4l5.4-5.4z"/>
|
||||
<path style="&st7;" d="M35.7,8.8H11v29.9h24.7V8.8z"/>
|
||||
<path style="&st4;" d="M35.7,8.8H11v29.9h24.7V8.8z"/>
|
||||
<path style="&st2;" d="M35.7,8.8H11v29.9h24.7V8.8z"/>
|
||||
</g>
|
||||
<g id="Layer_x0020_4" style="&st6;">
|
||||
<path style="&st9;" d="M38.7,30.4L25,16.7l-7.7-3l2.7,8.7l13.3,13.4l5.4-5.4z"/>
|
||||
<path style="&st8;" d="M38.7,30.4L25,16.7l-7.7-3l2.7,8.7l13.3,13.4l5.4-5.4z"/>
|
||||
<path style="&st8;" d="M20.6,14.7l-2.5,2.5L17,13.4l3.6,1.3z"/>
|
||||
<path style="&st1;" d="M19.6,22.2l3-0.3l2.4-2.4l0.4-2.8"/>
|
||||
<path style="&st2;" d="M20.4,14.9L18.3,17l1.6,5.2l2.7-0.3l2.4-2.4l0.3-2.4l-5-2.2z"/>
|
||||
</g>
|
||||
<g id="crop" style="&st6;">
|
||||
<path style="&st5;" d="M48,48H0V0h48v48z"/>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.7 KiB |
@@ -1,19 +0,0 @@
|
||||
<?xml version="1.0" encoding="iso-8859-1"?>
|
||||
<!-- Generator: Adobe Illustrator 9.0, SVG Export Plug-In -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY st0 "fill:none;stroke:none;">
|
||||
<!ENTITY st1 "fill:#FFFFFF;stroke:#FFFFFF;stroke-width:7.5901;stroke-linejoin:round;">
|
||||
<!ENTITY st2 "fill-rule:nonzero;clip-rule:nonzero;stroke:#000000;stroke-miterlimit:4;">
|
||||
<!ENTITY st3 "stroke:none;">
|
||||
]>
|
||||
<svg width="48pt" height="48pt" viewBox="0 0 48 48" xml:space="preserve" xmlns="http://www.w3.org/2000/svg">
|
||||
<g id="Layer_x0020_3" style="&st2;">
|
||||
<g>
|
||||
<path style="&st1;" d="M25.6,6.9c0-0.3-0.3-0.3-0.5-0.2L8.4,23.6c-0.5,0.5-0.4,0.7,0,1l16.6,16.6c0.1,0.1,0.4,0.1,0.4-0.1v-10h13.6c0.3,0,0.5-0.2,0.5-0.4l0-13.3c0-0.3-0.2-0.5-0.5-0.5H25.5l0.1-10.1z"/>
|
||||
<path style="&st3;" d="M25.6,6.9c0-0.3-0.3-0.3-0.5-0.2L8.4,23.6c-0.5,0.5-0.4,0.7,0,1l16.6,16.6c0.1,0.1,0.4,0.1,0.4-0.1v-10h13.6c0.3,0,0.5-0.2,0.5-0.4l0-13.3c0-0.3-0.2-0.5-0.5-0.5H25.5l0.1-10.1z"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="crop_x0020_marks" style="&st2;">
|
||||
<path style="&st0;" d="M48,48H0V0h48v48z"/>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.0 KiB |
|
Before Width: | Height: | Size: 1.1 KiB |
|
Before Width: | Height: | Size: 449 B |
@@ -1,84 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) --><svg height="1052.3622047" id="svg2" inkscape:version="0.42.2" sodipodi:docbase="/home/sergio/tmp/downloads" sodipodi:docname="lamp.svg" sodipodi:version="0.32" width="744.09448819" xmlns="http://www.w3.org/2000/svg" xmlns:cc="http://web.resource.org/cc/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:sodipodi="http://inkscape.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:svg="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<metadata>
|
||||
<rdf:RDF xmlns:cc="http://web.resource.org/cc/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
|
||||
<cc:Work rdf:about="">
|
||||
<dc:title>lamp</dc:title>
|
||||
<dc:description></dc:description>
|
||||
<dc:subject>
|
||||
<rdf:Bag>
|
||||
<rdf:li>office</rdf:li>
|
||||
<rdf:li></rdf:li>
|
||||
<rdf:li>lamp</rdf:li>
|
||||
</rdf:Bag>
|
||||
</dc:subject>
|
||||
<dc:publisher>
|
||||
<cc:Agent rdf:about="http://www.openclipart.org/">
|
||||
<dc:title>Open Clip Art Library</dc:title>
|
||||
</cc:Agent>
|
||||
</dc:publisher>
|
||||
<dc:creator>
|
||||
<cc:Agent>
|
||||
<dc:title>Sergio Luiz Araujo Silva</dc:title>
|
||||
</cc:Agent>
|
||||
</dc:creator>
|
||||
<dc:rights>
|
||||
<cc:Agent>
|
||||
<dc:title>Public Domain</dc:title>
|
||||
</cc:Agent>
|
||||
</dc:rights>
|
||||
<dc:date>set 2005</dc:date>
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/>
|
||||
<cc:license rdf:resource="http://web.resource.org/cc/PublicDomain"/>
|
||||
<dc:language>en</dc:language>
|
||||
</cc:Work>
|
||||
<cc:License rdf:about="http://web.resource.org/cc/PublicDomain">
|
||||
<cc:permits rdf:resource="http://web.resource.org/cc/Reproduction"/>
|
||||
<cc:permits rdf:resource="http://web.resource.org/cc/Distribution"/>
|
||||
<cc:permits rdf:resource="http://web.resource.org/cc/DerivativeWorks"/>
|
||||
</cc:License>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<defs id="defs4">
|
||||
<linearGradient id="linearGradient13125">
|
||||
<stop id="stop13127" offset="0.0000000" style="stop-color:#ffffff;stop-opacity:1.0000000;"/>
|
||||
<stop id="stop13129" offset="1" style="stop-color:#fffeff;stop-opacity:0;"/>
|
||||
</linearGradient>
|
||||
<linearGradient id="linearGradient12389">
|
||||
<stop id="stop12391" offset="0.0000000" style="stop-color:#fefefe;stop-opacity:1.0000000;"/>
|
||||
<stop id="stop12393" offset="1.0000000" style="stop-color:#fffefe;stop-opacity:1.0000000;"/>
|
||||
</linearGradient>
|
||||
<radialGradient cx="358.25909" cy="186.06468" fx="358.25909" fy="186.06468" gradientTransform="matrix(1.000001,-8.244061e-7,3.143917e-7,0.381356,-4.028738e-4,115.1081)" gradientUnits="userSpaceOnUse" id="radialGradient13131" inkscape:collect="always" r="27.486719" xlink:href="#linearGradient13125"/>
|
||||
<radialGradient cx="358.25909" cy="186.06468" fx="358.25909" fy="186.06468" gradientTransform="matrix(1.000001,-8.244061e-7,3.143917e-7,0.381356,-4.028738e-4,115.1081)" gradientUnits="userSpaceOnUse" id="radialGradient14587" inkscape:collect="always" r="27.486719" xlink:href="#linearGradient13125"/>
|
||||
<radialGradient cx="358.25909" cy="186.06468" fx="358.25909" fy="186.06468" gradientTransform="matrix(1.000001,-8.244061e-7,3.143917e-7,0.381356,-4.028738e-4,115.1081)" gradientUnits="userSpaceOnUse" id="radialGradient15390" inkscape:collect="always" r="27.486719" xlink:href="#linearGradient13125"/>
|
||||
<radialGradient cx="358.25909" cy="186.06468" fx="358.25909" fy="186.06468" gradientTransform="matrix(1.000001,-8.244061e-7,3.143917e-7,0.381356,-4.028738e-4,115.1081)" gradientUnits="userSpaceOnUse" id="radialGradient16141" inkscape:collect="always" r="27.486719" xlink:href="#linearGradient13125"/>
|
||||
</defs>
|
||||
<sodipodi:namedview bordercolor="#666666" borderopacity="1.0" id="base" inkscape:current-layer="layer1" inkscape:cx="344.34505" inkscape:cy="795.78292" inkscape:document-units="px" inkscape:guide-bbox="true" inkscape:pageopacity="0.0" inkscape:pageshadow="2" inkscape:window-height="693" inkscape:window-width="1024" inkscape:window-x="0" inkscape:window-y="25" inkscape:zoom="0.72123084" pagecolor="#ffffff" showguides="true"/>
|
||||
<g id="layer1" inkscape:groupmode="layer" inkscape:label="Layer 1">
|
||||
<path d="M 369.44028,121.86683 C 302.64703,119.68096 242.59223,184.30679 250.47188,250.87980 C 252.47522,280.21980 267.84094,306.49880 285.94332,328.82253 C 303.71281,358.65039 312.13900,393.24133 313.51068,427.73030 C 317.00419,446.97288 338.01608,454.57063 355.35334,455.26572 C 375.18456,456.91501 395.94281,455.09265 414.43470,447.69729 C 430.92724,435.70557 427.37713,413.20597 430.74488,395.55648 C 434.70351,361.57615 449.78002,329.76555 471.07843,303.26619 C 504.41026,252.31528 488.56419,176.76397 437.75400,143.26422 C 417.82956,129.49394 393.70573,121.69096 369.44028,121.86683 z " id="path1384" style="opacity:1.0000000;fill:#f3f2f3;fill-opacity:0.83333331;stroke:#000000;stroke-width:0.58960420;stroke-miterlimit:4.0000000;stroke-dasharray:none;stroke-dashoffset:0.0000000;stroke-opacity:1.0000000"/>
|
||||
<path d="M 425.72698,154.07768 C 437.68158,164.87540 453.68534,182.03604 451.17873,203.82428 C 455.99913,200.54641 460.81954,197.26853 465.63995,193.99066 C 459.85546,170.27425 448.28648,162.75442 425.72698,154.07768 z " id="path2153" sodipodi:nodetypes="cccc" style="fill:#fefefe;fill-opacity:1.0000000;fill-rule:evenodd;stroke:none;stroke-width:1.0000000px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<path d="M 506.99897 296.94009 A 37.120701 18.718985 0 1 1 432.75756,296.94009 A 37.120701 18.718985 0 1 1 506.99897 296.94009 z" id="path2881" sodipodi:cx="469.87827" sodipodi:cy="296.94009" sodipodi:rx="37.120701" sodipodi:ry="18.718985" sodipodi:type="arc" style="opacity:1.0000000;color:#000000;fill:#fefefe;fill-opacity:1.0000000;fill-rule:nonzero;stroke:none;stroke-width:0.64700001;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4.0000000;stroke-dasharray:none;stroke-dashoffset:0.0000000;stroke-opacity:1.0000000;visibility:visible;display:inline;overflow:visible" transform="matrix(0.818103,0.000000,0.000000,0.896150,-13.89510,-26.68653)"/>
|
||||
<path d="M 359.20536,314.30802 L 336.64585,244.31570 C 362.29042,230.62575 382.72895,234.28926 403.16748,243.15881 L 379.45107,315.46491 L 379.45107,315.46491" id="path3617" sodipodi:nodetypes="ccccc" style="fill:none;fill-opacity:0.75000000;fill-rule:evenodd;stroke:#8f9595;stroke-width:0.91160071px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<path d="M 513.73605 514.32300 A 52.508934 11.885468 0 1 1 408.71818,514.32300 A 52.508934 11.885468 0 1 1 513.73605 514.32300 z" id="path4361" sodipodi:cx="461.22711" sodipodi:cy="514.32300" sodipodi:rx="52.508934" sodipodi:ry="11.885468" sodipodi:type="arc" style="opacity:1.0000000;color:#000000;fill:#a0a0a0;fill-opacity:1.0000000;fill-rule:nonzero;stroke:none;stroke-width:0.64700001;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4.0000000;stroke-dasharray:none;stroke-dashoffset:0.0000000;stroke-opacity:1.0000000;visibility:visible;display:inline;overflow:visible" transform="matrix(0.982435,0.000000,0.000000,1.387810,-83.52495,-281.2705)"/>
|
||||
<path d="M 315.87677,433.07959 C 319.14672,442.90428 329.03398,448.82383 338.76816,450.68840 C 362.00206,456.37952 386.74882,455.38004 409.63484,448.57985 C 414.28840,447.19363 419.18392,445.42184 422.06530,441.25295 C 423.42527,439.84003 425.68582,434.46169 424.07088,434.30126 C 411.81432,444.17256 395.75685,447.78808 380.34111,448.56322 C 362.85475,449.05661 344.64886,448.26521 328.51659,440.79114 C 324.02706,438.71576 319.76022,436.14612 315.87677,433.07959 z " id="path4363" style="fill:#d6dee6;fill-opacity:1.0000000;fill-rule:evenodd;stroke:none;stroke-width:1.0000000px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<path d="M 400.47436,522.16227 C 396.48542,528.09177 392.49650,534.02126 388.50756,539.95076 C 383.93367,541.47295 366.98819,546.44954 353.57745,538.01018 C 350.34318,532.29631 347.10892,526.58244 343.87465,520.86856 C 364.35835,531.64946 396.48542,523.99502 400.47436,522.16227 z " id="path5094" sodipodi:nodetypes="ccccc" style="fill:#090a0c;fill-opacity:1.0000000;fill-rule:evenodd;stroke:#000000;stroke-width:0.91160071px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<path d="M 419.65600,444.27781 C 419.97026,446.39906 420.28452,448.52031 420.59878,450.64156 C 421.46299,450.95582 422.32720,451.27008 423.19142,451.58434 C 423.19142,452.91994 423.19142,454.25554 423.19142,455.59114 C 422.32720,455.98397 421.46299,456.37678 420.59878,456.76961 C 420.36308,459.20512 420.12739,461.64063 419.89170,464.07614 C 420.52021,464.23327 421.14873,464.39039 421.77725,464.54753 C 421.69869,466.59021 421.62012,468.63289 421.54156,470.67558 C 420.83447,471.46123 420.12739,472.24688 419.42030,473.03253 C 419.57744,474.05387 419.73456,475.07522 419.89170,476.09656 C 420.91303,477.11790 421.93438,478.13925 422.95572,479.16058 C 422.87716,480.18193 422.79859,481.20328 422.72003,482.22461 C 422.01294,483.01026 421.30586,483.79591 420.59878,484.58156 C 420.36308,485.05294 420.12739,485.52433 419.89170,485.99572 C 419.57744,486.70280 419.26317,487.40989 418.94892,488.11697 C 419.10605,489.05975 419.26317,490.00253 419.42030,490.94531 C 419.89170,491.65239 420.36308,492.35947 420.83447,493.06655 C 420.67734,494.71641 420.52021,496.36627 420.36308,498.01614 C 415.02067,505.24410 409.67827,512.47206 404.33587,519.70003 C 403.15740,520.24998 401.97892,520.79994 400.80045,521.34989 C 397.81498,522.29266 394.82952,523.23544 391.84406,524.17822 C 386.34452,524.80674 380.84498,525.43525 375.34545,526.06378 C 371.96717,525.90664 368.58887,525.74952 365.21059,525.59238 C 362.46082,525.51382 359.71105,525.43525 356.96128,525.35669 C 353.42587,524.49247 349.89045,523.62827 346.35503,522.76405 C 345.17656,521.82128 343.99809,520.87850 342.81962,519.93572 C 339.75559,517.81447 336.69157,515.69322 333.62754,513.57197 C 328.75652,508.30813 323.88551,503.04429 319.01448,497.78044 C 319.01448,496.52341 319.01448,495.26636 319.01448,494.00933 C 319.87870,494.00933 320.74291,494.00933 321.60712,494.00933 C 321.13574,492.83086 320.66435,491.65239 320.19296,490.47392 C 319.09305,488.19554 317.99314,485.91716 316.89323,483.63878 C 316.89323,482.93170 316.89323,482.22461 316.89323,481.51753 C 318.38597,480.26049 319.87869,479.00345 321.37143,477.74642 C 320.03583,475.54660 318.70022,473.34679 317.36462,471.14697 C 317.28606,470.83271 317.20748,470.51845 317.12892,470.20419 C 318.46453,468.39720 319.80013,466.59021 321.13574,464.78322 C 320.74291,463.68331 320.35009,462.58341 319.95726,461.48350 C 319.09305,460.38359 318.22883,459.28369 317.36462,458.18378 C 317.12892,457.31956 316.89323,456.45536 316.65753,455.59114 C 317.75744,454.17697 318.85735,452.76281 319.95726,451.34864 C 319.87870,450.01304 319.80013,448.67744 319.72157,447.34184 C 319.32874,446.71332 318.93592,446.08480 318.54310,445.45628 C 318.62166,444.74920 318.70023,444.04212 318.77879,443.33503 C 319.48588,443.25647 320.19296,443.17790 320.90004,443.09934 C 324.04263,445.22059 327.18523,447.34184 330.32782,449.46309 C 348.08347,456.92674 391.76550,461.09068 419.65600,444.27781 z " id="path7284" sodipodi:nodetypes="ccccccccccccccccccccccccccccccccccccccccccccccc" style="fill:#fba246;fill-opacity:1.0000000;fill-rule:evenodd;stroke:#000000;stroke-width:0.91160071px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<path d="M 389.86281,523.00744 C 389.46998,521.82897 391.23336,522.26765 390.84054,521.08918 C 383.37688,521.01061 375.91323,520.93205 368.44957,520.85348 C 368.44957,520.53923 368.44957,520.22496 368.44957,519.91070 C 374.10624,519.75357 379.76290,519.59645 385.41957,519.43932 C 388.24790,518.88937 391.07623,518.33941 393.90457,517.78946 C 395.39730,517.55377 396.89003,517.31807 398.38277,517.08237 C 401.44679,515.03969 404.51082,512.99701 407.57485,510.95432 C 407.49629,510.64006 407.41771,510.32580 407.33915,510.01153 C 401.36822,510.48292 395.39730,510.95432 389.42637,511.42571 C 387.30512,511.81853 385.18387,512.21135 383.06263,512.60418 C 379.13438,512.36849 375.20615,512.13279 371.27790,511.89710 C 369.78518,511.73997 368.29244,511.58284 366.79971,511.42571 C 364.44277,510.32580 362.08582,509.22589 359.72888,508.12598 C 376.54175,507.18320 396.89003,507.18320 415.11707,493.98432 C 391.31192,502.15506 371.27790,500.19093 355.01499,497.99112 C 375.91322,494.06288 396.57577,493.19867 417.00262,478.42849 C 387.38368,489.42756 366.24975,485.57788 349.35832,483.84946 C 371.51360,479.29269 403.56804,478.27136 414.40998,466.64376 C 383.06263,474.89306 355.95776,473.47890 338.75207,469.47210 C 352.81517,467.58654 366.87827,465.70098 380.94137,463.81543 C 374.10624,463.18691 367.27110,462.55840 360.43596,461.92988 C 373.32059,459.73006 386.20522,457.53024 399.08985,455.33043 C 381.88416,456.19465 346.53000,460.82997 319.89653,444.48849 C 323.66763,447.63108 328.61721,449.83090 331.20985,453.91627 C 327.28161,453.44487 323.35338,452.97349 319.42513,452.50210 C 319.66083,453.83770 319.89653,455.17330 320.13222,456.50890 C 324.13902,459.02298 328.14582,461.53704 332.15263,464.05112 C 327.43875,466.25093 322.72485,468.45075 318.01096,470.65057 C 323.90332,472.53612 329.79568,474.42169 335.68805,476.30724 C 330.03138,478.66418 322.48915,476.30724 318.71804,483.37807 C 325.55318,486.59923 335.21666,487.22774 339.22346,493.04154 C 333.33110,493.51293 326.73166,489.27043 321.54639,494.45571 C 327.67444,498.06968 333.80249,501.68367 339.93055,505.29765 C 336.55226,504.82626 333.17397,504.35487 329.79568,503.88348 C 334.58814,509.30445 341.26727,513.37780 346.05972,518.79877 C 362.00838,520.29150 373.91416,521.51471 389.86281,523.00744 z " id="path6556" sodipodi:nodetypes="ccccccccccccccccccccccccccccccccccccc" style="fill:#ffc080;fill-opacity:1.0000000;fill-rule:evenodd;stroke:none;stroke-width:1.0000000px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<path d="M 410.63580,448.38806 C 375.91016,459.46570 347.07688,453.33765 330.49970,448.38806 C 332.54238,449.09515 334.58507,449.80223 336.62775,450.50931 C 365.30391,460.56561 396.80839,453.41621 407.80747,450.27362 C 408.75025,449.64510 409.69303,449.01658 410.63580,448.38806 z " id="path7286" sodipodi:nodetypes="ccccc" style="fill:#ffffff;fill-opacity:1.0000000;fill-rule:evenodd;stroke:none;stroke-width:1.0000000px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<path d="M 431.22109,368.33927 C 427.74256,388.71364 424.26401,409.08801 420.78546,429.46237 C 416.60557,437.06563 407.94091,440.30372 400.07083,442.61238 C 391.48668,445.18530 382.40444,445.05799 373.54205,444.61656 C 371.08048,446.38986 364.99205,442.92177 370.06503,441.81235 C 377.17154,440.98795 384.60188,442.10538 391.38552,439.26558 C 401.04319,435.47671 410.26670,429.97354 417.05844,422.00834 C 421.19961,403.95301 425.34070,385.89766 429.48184,367.84233 C 430.06159,368.00798 430.64135,368.17360 431.22109,368.33927 z " id="path3629" style="fill:#ffffff;fill-opacity:0.64285713;fill-rule:evenodd;stroke:none;stroke-width:1.0000000px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<path d="M 353.42087,428.84088 L 351.10708,419.00725 L 351.68553,378.22661 L 353.13164,373.45440 L 353.05576,339.28565 L 349.95018,336.28751 L 349.37173,316.04336 C 363.86558,304.49563 376.56238,306.21837 388.70625,316.23514 L 388.12780,336.28907 L 385.23556,339.18131 L 384.65711,373.58108 L 386.39245,378.21491 L 385.81401,427.68398 L 382.34331,429.99778 L 374.24503,428.84088 L 371.35278,425.37019 L 366.14675,425.37019 L 360.94071,429.41933 L 353.42087,428.84088 z " id="path3619" sodipodi:nodetypes="ccccccccccccccccccc" style="fill:#c1c1c1;fill-opacity:1.0000000;fill-rule:evenodd;stroke:#9b989f;stroke-width:0.91160071px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<path d="M 358.25832,325.31572 L 358.25832,416.41507" id="path5096" style="fill:none;fill-opacity:0.75000000;fill-rule:evenodd;stroke:#ffffff;stroke-width:0.91160071px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<path d="M 380.15345,325.31572 L 380.15345,416.41507" id="path5824" style="fill:none;fill-opacity:0.75000000;fill-rule:evenodd;stroke:#ffffff;stroke-width:0.91160071px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<path d="M 361.91098,325.31572 L 361.91098,416.41507" id="path5826" style="fill:none;fill-opacity:0.75000000;fill-rule:evenodd;stroke:#8f8f92;stroke-width:0.91160071px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<path d="M 376.52161,325.31572 L 376.52161,416.41507" id="path6554" style="fill:none;fill-opacity:0.75000000;fill-rule:evenodd;stroke:#8f8f92;stroke-width:0.91160071px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<g id="g9475" transform="matrix(0.911601,0.000000,0.000000,0.911601,328.5961,-156.2531)">
|
||||
<path d="M 86.864034,673.56687 L 79.199560,676.97330 L 77.155700,678.67652 L 75.793127,679.69845 L 65.573829,679.35780 L 65.403508,678.33587 L 70.683478,676.97330 C 70.683478,676.97330 74.430554,676.63266 75.111841,676.46234 C 75.793127,676.29201 78.688595,674.92944 78.688595,674.92944 L 84.649852,671.52301 L 87.034355,671.52301 L 86.864034,673.56687 z " id="path8741" style="fill:#ffffff;fill-opacity:1.0000000;fill-rule:evenodd;stroke:none;stroke-width:1.0000000px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<path d="M 91.973683,686.34099 L 88.056285,686.17067 L 85.331139,687.53324 L 81.073098,689.23646 L 77.836987,691.45064 L 75.111841,692.30225 L 70.853800,692.64289 L 69.320905,693.15386 L 71.024122,693.83514 L 75.963449,693.83514 L 80.221490,694.51643 L 83.627923,693.83514 L 87.545320,690.42871 C 87.545320,690.42871 90.270466,689.23646 90.951753,688.89581 C 91.633039,688.55517 93.165934,687.87388 93.165934,687.87388 L 91.973683,686.34099 z " id="path8743" style="fill:#ffffff;fill-opacity:1.0000000;fill-rule:evenodd;stroke:none;stroke-width:1.0000000px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<path d="M 94.017542,700.30736 L 89.078215,703.03251 L 85.842104,705.07637 L 83.457601,706.94991 L 77.836987,708.14216 L 75.622806,708.14216 L 81.584063,710.01570 L 86.353069,707.97184 L 91.292396,705.58733 L 92.825291,704.05444 L 94.017542,700.30736 z " id="path8745" style="fill:#ffffff;fill-opacity:1.0000000;fill-rule:evenodd;stroke:none;stroke-width:1.0000000px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<path d="M 91.462718,717.85049 C 91.462718,717.85049 81.924706,721.59757 81.584063,722.27885 C 81.243420,722.96014 78.688595,723.98207 78.688595,723.98207 L 72.897660,724.66336 L 71.024122,725.68529 L 76.644736,726.36657 L 82.435671,724.49304 L 86.693712,724.32271 L 89.929823,722.10853 L 91.462718,720.40532 L 91.462718,717.85049 z " id="path8747" style="fill:#ffffff;fill-opacity:1.0000000;fill-rule:evenodd;stroke:none;stroke-width:1.0000000px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
</g>
|
||||
<path d="M 378.14273,525.28637 C 377.57434,530.51553 378.00099,537.83204 377.43261,543.06120 C 372.27918,543.00443 367.82875,543.82657 360.97078,541.72320 C 359.43614,536.89190 356.80919,529.30796 355.27454,524.47667 C 356.26507,524.72572 356.68741,524.86790 357.82038,524.93742 C 358.95335,525.00694 360.79692,524.96593 361.90337,525.03791 C 363.00981,525.10990 364.25012,525.06768 365.31257,525.13480 C 366.37503,525.20191 367.41113,525.22689 368.41214,525.28180 C 369.41314,525.33669 370.37905,525.38365 371.30113,525.41898 C 372.22321,525.45432 374.35115,525.55378 375.17683,525.56221 C 376.00251,525.57065 375.56381,525.48806 376.27564,525.46225 C 376.98745,525.43643 377.56225,525.35378 378.14273,525.28637 z " id="path10207" sodipodi:nodetypes="ccccsssssssc" style="fill:#ffffff;fill-opacity:0.31547615;fill-rule:evenodd;stroke:none;stroke-width:1.0000000px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000"/>
|
||||
<path d="M 467.06377,199.37552 L 453.69293,208.53364 L 451.86130,221.53816 L 468.71223,214.21167 L 467.06377,199.37552 z " id="path16869" style="fill:#fefefe;fill-opacity:1.0000000;fill-rule:evenodd;stroke:none;stroke-width:1.0000000px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000;opacity:1.0000000;color:#000000;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4.0000000;stroke-dasharray:none;stroke-dashoffset:0;visibility:visible;display:inline;overflow:visible"/>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 318 B |
|
Before Width: | Height: | Size: 259 B |
|
Before Width: | Height: | Size: 264 B |
@@ -1,19 +0,0 @@
|
||||
<?xml version="1.0" encoding="iso-8859-1"?>
|
||||
<!-- Generator: Adobe Illustrator 9.0, SVG Export Plug-In -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY st0 "fill:none;stroke:none;">
|
||||
<!ENTITY st1 "fill:#FFFFFF;stroke:#FFFFFF;stroke-width:7.5901;stroke-linejoin:round;">
|
||||
<!ENTITY st2 "fill-rule:nonzero;clip-rule:nonzero;stroke:#000000;stroke-miterlimit:4;">
|
||||
<!ENTITY st3 "stroke:none;">
|
||||
]>
|
||||
<svg width="48pt" height="48pt" viewBox="0 0 48 48" xml:space="preserve" xmlns="http://www.w3.org/2000/svg">
|
||||
<g id="Layer_x0020_3" style="&st2;">
|
||||
<g>
|
||||
<path style="&st1;" d="M41.1,25.6c0.3,0,0.3-0.3,0.2-0.5L24.4,8.4c-0.5-0.5-0.7-0.4-1,0L6.7,25.1c-0.1,0.1-0.1,0.4,0.1,0.4h10v13.6c0,0.3,0.2,0.5,0.4,0.5l13.3,0c0.3,0,0.5-0.2,0.5-0.5V25.5l10.1,0.1z"/>
|
||||
<path style="&st3;" d="M41.1,25.6c0.3,0,0.3-0.3,0.2-0.5L24.4,8.4c-0.5-0.5-0.7-0.4-1,0L6.7,25.1c-0.1,0.1-0.1,0.4,0.1,0.4h10v13.6c0,0.3,0.2,0.5,0.4,0.5l13.3,0c0.3,0,0.5-0.2,0.5-0.5V25.5l10.1,0.1z"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="crop_x0020_marks" style="&st2;">
|
||||
<path style="&st0;" d="M48,48H0V0h48v48z"/>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.0 KiB |
|
Before Width: | Height: | Size: 1.1 KiB |
|
Before Width: | Height: | Size: 1.2 KiB |
@@ -1,23 +0,0 @@
|
||||
<?xml version="1.0" encoding="iso-8859-1"?>
|
||||
<!-- Generator: Adobe Illustrator 9.0, SVG Export Plug-In -->
|
||||
<!DOCTYPE svg [
|
||||
<!ENTITY st0 "fill:#000000;stroke:#FFFFFF;stroke-width:7.9139;stroke-linejoin:round;">
|
||||
<!ENTITY st1 "fill-rule:nonzero;clip-rule:nonzero;fill:#FFFFFF;stroke:#000000;stroke-miterlimit:4;">
|
||||
<!ENTITY st2 "fill:none;stroke:none;">
|
||||
<!ENTITY st3 "fill:#000000;">
|
||||
<!ENTITY st4 "fill-rule:evenodd;clip-rule:evenodd;stroke:none;">
|
||||
<!ENTITY st5 "fill-rule:nonzero;clip-rule:nonzero;stroke:#000000;stroke-miterlimit:4;">
|
||||
]>
|
||||
<svg width="48pt" height="48pt" viewBox="0 0 48 48" xml:space="preserve" xmlns="http://www.w3.org/2000/svg">
|
||||
<g id="Layer_x0020_4" style="&st1;">
|
||||
<g style="&st4;">
|
||||
<path style="&st0;" d="M16.4,42.3L5.7,31.6V16.4L16.4,5.7h15.2l10.7,10.7v15.2L31.6,42.3H16.4z"/>
|
||||
<path style="&st3;" d="M16.4,42.3L5.7,31.6V16.4L16.4,5.7h15.2l10.7,10.7v15.2L31.6,42.3H16.4z"/>
|
||||
<path d="M11.7,17.7l18.7,18.7l5.9-5.9L17.6,11.7l-5.9,5.9z"/>
|
||||
<path d="M11.7,30.5l5.9,5.9l18.7-18.7l-5.9-5.9L11.7,30.5z"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="crop_x0020_marks" style="&st5;">
|
||||
<path style="&st2;" d="M48,48H0V0h48v48z"/>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.1 KiB |
149
doc/html/rst.css
@@ -1,149 +0,0 @@
|
||||
@import url("boostbook.css");
|
||||
@import url("docutils.css");
|
||||
/* Copyright David Abrahams 2006. Distributed under the Boost
|
||||
Software License, Version 1.0. (See accompanying
|
||||
file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
|
||||
*/
|
||||
|
||||
dl.docutils dt {
|
||||
font-weight: bold }
|
||||
|
||||
img.boost-logo {
|
||||
border: none;
|
||||
vertical-align: middle
|
||||
}
|
||||
|
||||
pre.literal-block span.concept {
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
.nav {
|
||||
display: inline;
|
||||
list-style-type: none;
|
||||
}
|
||||
|
||||
.prevpage {
|
||||
padding-top: -5px;
|
||||
text-align: left;
|
||||
float: left;
|
||||
}
|
||||
|
||||
.nextpage {
|
||||
padding-top: -20px;
|
||||
text-align: right;
|
||||
float: right;
|
||||
}
|
||||
|
||||
div.small {
|
||||
font-size: smaller }
|
||||
|
||||
h2 a {
|
||||
font-size: 90%;
|
||||
}
|
||||
h3 a {
|
||||
font-size: 80%;
|
||||
}
|
||||
h4 a {
|
||||
font-size: 70%;
|
||||
}
|
||||
h5 a {
|
||||
font-size: 60%;
|
||||
}
|
||||
|
||||
dl,table
|
||||
{
|
||||
text-align: left;
|
||||
font-size: 10pt;
|
||||
line-height: 1.15;
|
||||
}
|
||||
|
||||
|
||||
/*=============================================================================
|
||||
Tables
|
||||
=============================================================================*/
|
||||
|
||||
/* The only clue docutils gives us that tables are logically tables,
|
||||
and not, e.g., footnotes, is that they have border="1". Therefore
|
||||
we're keying off of that. We used to manually patch docutils to
|
||||
add a "table" class to all logical tables, but that proved much too
|
||||
fragile.
|
||||
*/
|
||||
|
||||
table[border="1"]
|
||||
{
|
||||
width: 92%;
|
||||
margin-left: 4%;
|
||||
margin-right: 4%;
|
||||
}
|
||||
|
||||
table[border="1"]
|
||||
{
|
||||
padding: 4px;
|
||||
}
|
||||
|
||||
/* Table Cells */
|
||||
table[border="1"] tr td
|
||||
{
|
||||
padding: 0.5em;
|
||||
text-align: left;
|
||||
font-size: 9pt;
|
||||
}
|
||||
|
||||
table[border="1"] tr th
|
||||
{
|
||||
padding: 0.5em 0.5em 0.5em 0.5em;
|
||||
border: 1pt solid white;
|
||||
font-size: 80%;
|
||||
}
|
||||
|
||||
@media screen
|
||||
{
|
||||
|
||||
/* Tables */
|
||||
table[border="1"] tr td
|
||||
{
|
||||
border: 1px solid #DCDCDC;
|
||||
}
|
||||
|
||||
table[border="1"] tr th
|
||||
{
|
||||
background-color: #F0F0F0;
|
||||
border: 1px solid #DCDCDC;
|
||||
}
|
||||
|
||||
pre,
|
||||
.screen
|
||||
{
|
||||
border: 1px solid #DCDCDC;
|
||||
}
|
||||
|
||||
td pre
|
||||
td .screen
|
||||
{
|
||||
border: 0px
|
||||
}
|
||||
|
||||
.sidebar pre
|
||||
{
|
||||
border: 0px
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
pre,
|
||||
.screen
|
||||
{
|
||||
font-size: 9pt;
|
||||
display: block;
|
||||
margin: 1pc 4% 0pc 4%;
|
||||
padding: 0.5pc 0.5pc 0.5pc 0.5pc;
|
||||
}
|
||||
|
||||
/* Program listings in tables don't get borders */
|
||||
td pre,
|
||||
td .screen
|
||||
{
|
||||
margin: 0pc 0pc 0pc 0pc;
|
||||
padding: 0pc 0pc 0pc 0pc;
|
||||
}
|
||||
|
||||
187
doc/index.html
@@ -1,13 +1,184 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
|
||||
<!-- Copyright David Abrahams 2006. Distributed under the Boost -->
|
||||
<!-- Software License, Version 1.0. (See accompanying -->
|
||||
<!-- file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -->
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="refresh" content="0; URL=html/index.html">
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Windows (vers 1st August 2002), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
||||
<link rel="stylesheet" type="text/css" href="../../../boost.css">
|
||||
|
||||
<title>Boost.Python</title>
|
||||
</head>
|
||||
<body>
|
||||
Automatic redirection failed, click this
|
||||
<a href="html/index.html">link</a> <hr>
|
||||
<p>© Copyright Stefan Seefeld, 2015</p>
|
||||
<p>Distributed under the Boost Software License, Version 1.0. (See accompanying
|
||||
file <a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">http://www.boost.org/LICENSE_1_0.txt</a>)</p>
|
||||
|
||||
<body link="#0000ff" vlink="#800080">
|
||||
<table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
|
||||
"header">
|
||||
<tr>
|
||||
<td valign="top" width="300">
|
||||
<h3><a href="../../../index.htm"><img height="86" width="277" alt=
|
||||
"C++ Boost" src="../../../boost.png" border="0"></a></h3>
|
||||
</td>
|
||||
|
||||
<td valign="top">
|
||||
<h1 align="center">Boost.Python</h1>
|
||||
|
||||
<h2 align="center">Index</h2>
|
||||
</td>
|
||||
|
||||
|
||||
<td align="right">
|
||||
|
||||
<form method="get" action="http://www.google.com/custom">
|
||||
<p>
|
||||
<span id= "search-choice">
|
||||
Search
|
||||
<select name="hq" id="hq">
|
||||
<option label="All Documentation" value=
|
||||
"site:www.boost.org inurl:www.boost.org/libs/python/doc">
|
||||
All Documentation
|
||||
</option>
|
||||
<option label="Tutorial" value=
|
||||
"site:www.boost.org inurl:www.boost.org/libs/python/doc/tutorial">
|
||||
Tutorial
|
||||
</option>
|
||||
<option label="Reference" value=
|
||||
"site:www.boost.org inurl:www.boost.org/libs/python/doc/v2">
|
||||
Reference
|
||||
</option>
|
||||
</select>
|
||||
<br>
|
||||
</span>
|
||||
|
||||
<span id="search-text">
|
||||
<input type="text" name="q" id="q" size="31" maxlength="255" alt="Search Text" />
|
||||
</span>
|
||||
|
||||
<br>
|
||||
<span id= "google">
|
||||
<a href= "http://www.google.com/search">
|
||||
<img src="../../../more/google_logo_25wht.gif" alt="Google" border="0" /></a>Powered
|
||||
</span>
|
||||
|
||||
<span id="go">
|
||||
<input type="image" name="search" src="../../../more/space.gif" alt="Search" id="search-button" />
|
||||
</span>
|
||||
|
||||
<br>
|
||||
<input type="hidden" name="cof" value= "LW:277;L:http://www.boost.org/boost.png;LH:86;AH:center;GL:0;S:http://www.boost.org;AWFID:9b83d16ce652ed5a;" />
|
||||
<input type="hidden" name="sa" value= "Google Search" />
|
||||
<input type="hidden" name= "domains" value= "www.boost.org;mail.python.org" /></p>
|
||||
</form>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
|
||||
|
||||
<h2>Synopsis</h2>
|
||||
Welcome to version 2 of <b>Boost.Python</b>, a C++ library which enables
|
||||
seamless interoperability between C++ and the <a href=
|
||||
"http://www.python.org">Python</a> programming language. The new version
|
||||
has been rewritten from the ground up, with a more convenient and
|
||||
flexible interface, and many new capabilities, including support for:
|
||||
|
||||
<ul>
|
||||
<li>References and Pointers</li>
|
||||
|
||||
<li>Globally Registered Type Coercions</li>
|
||||
|
||||
<li>Automatic Cross-Module Type Conversions</li>
|
||||
|
||||
<li>Efficient Function Overloading</li>
|
||||
|
||||
<li>C++ to Python Exception Translation</li>
|
||||
|
||||
<li>Default Arguments</li>
|
||||
|
||||
<li>Keyword Arguments</li>
|
||||
|
||||
<li>Manipulating Python objects in C++</li>
|
||||
|
||||
<li>Exporting C++ Iterators as Python Iterators</li>
|
||||
|
||||
<li>Documentation Strings</li>
|
||||
</ul>
|
||||
The development of these features was funded in part by grants to <a
|
||||
href="http://www.boost-consulting.com">Boost Consulting</a> from the <a
|
||||
href="http://www.llnl.gov/">Lawrence Livermore National Laboratories</a>
|
||||
and by the <a href="http://cci.lbl.gov/">Computational Crystallography
|
||||
Initiative</a> at Lawrence Berkeley National Laboratories.
|
||||
|
||||
<hr>
|
||||
|
||||
<h2>Contents</h2>
|
||||
|
||||
<dl class="index">
|
||||
<dt><a href="tutorial/index.html">Tutorial Introduction</a></dt>
|
||||
|
||||
<dt><a href="building.html">Building and Testing</a></dt>
|
||||
|
||||
<dt><a href="v2/reference.html">Reference Manual</a></dt>
|
||||
|
||||
<dt>Suites:</dt>
|
||||
<dd>
|
||||
<ul>
|
||||
<li><a href="v2/pickle.html">Pickle</a></li>
|
||||
<li><a href="v2/indexing.html">Indexing</a></li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt><a href="v2/configuration.html">Configuration Information</a></dt>
|
||||
|
||||
<dt><a href="v2/platforms.html">Known Working Platforms and
|
||||
Compilers</a></dt>
|
||||
|
||||
<dt><a href="v2/definitions.html">Definitions</a></dt>
|
||||
|
||||
<dt><a href="projects.html">Projects using Boost.Python</a></dt>
|
||||
|
||||
<dt><a href="support.html">Support Resources</a></dt>
|
||||
|
||||
<dt><a href="v2/faq.html">Frequently Asked Questions (FAQs)</a></dt>
|
||||
|
||||
<dt><a href="http://www.language-binding.net/pyplusplus/pyplusplus.html">Py++ Boost.Python code generator</a></dt>
|
||||
|
||||
<dt><a href="../pyste/index.html">Pyste Boost.Python code generator (no longer maintained)</a></dt>
|
||||
|
||||
<dt><a href="internals.html">Internals Documentation</a></dt>
|
||||
|
||||
<dt><a href="news.html">News/Change Log</a></dt>
|
||||
|
||||
<dt><a href="../todo.html">TODO list</a></dt>
|
||||
|
||||
<dt><a href="v2/progress_reports.html">LLNL Progress Reports</a></dt>
|
||||
|
||||
<dt><a href="v2/acknowledgments.html">Acknowledgments</a></dt>
|
||||
</dl>
|
||||
<hr>
|
||||
|
||||
<h2>Articles</h2>
|
||||
|
||||
"<a href="PyConDC_2003/bpl.html">Building Hybrid
|
||||
Systems With Boost Python</a>", by Dave Abrahams and Ralf
|
||||
W. Grosse-Kunstleve (<a href="PyConDC_2003/bpl.pdf">PDF</a>)
|
||||
|
||||
<hr>
|
||||
|
||||
<p>Revised
|
||||
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
|
||||
26 August, 2003
|
||||
<!--webbot bot="Timestamp" endspan i-checksum="39359" -->
|
||||
</p>
|
||||
|
||||
<p><i>© Copyright <a href="../../../people/dave_abrahams.htm">Dave
|
||||
Abrahams</a> 2002-2003.</i></p>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
|
||||
@@ -1,19 +0,0 @@
|
||||
[library Boost.Python
|
||||
[quickbook 1.3]
|
||||
[authors [Abrahams, David], [Seefeld, Stefan]]
|
||||
[copyright 2002 2003 2004 2005 2015 David Abrahams, Stefan Seefeld]
|
||||
[category inter-language support]
|
||||
[id python]
|
||||
[purpose
|
||||
Reflects C++ classes and functions into Python
|
||||
]
|
||||
[license
|
||||
Distributed under the Boost Software License, Version 1.0.
|
||||
(See accompanying file LICENSE_1_0.txt or copy at
|
||||
[@http://www.boost.org/LICENSE_1_0.txt])
|
||||
]
|
||||
]
|
||||
|
||||
[/ QuickBook Document version 1.3 ]
|
||||
|
||||
[include preface.qbk]
|
||||
299
doc/news.html
Normal file
@@ -0,0 +1,299 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
|
||||
<!-- Copyright David Abrahams 2006. Distributed under the Boost -->
|
||||
<!-- Software License, Version 1.0. (See accompanying -->
|
||||
<!-- file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -->
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Cygwin (vers 1st September 2004), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
|
||||
<link rel="stylesheet" type="text/css" href="boost.css">
|
||||
|
||||
<title>Boost.Python - News/Change Log</title>
|
||||
</head>
|
||||
|
||||
<body link="#0000FF" vlink="#800080">
|
||||
<table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
|
||||
"header">
|
||||
<tr>
|
||||
<td valign="top" width="300">
|
||||
<h3><a href="../../../index.htm"><img height="86" width="277" alt=
|
||||
"C++ Boost" src="../../../boost.png" border="0"></a></h3>
|
||||
</td>
|
||||
|
||||
<td valign="top">
|
||||
<h1 align="center"><a href="index.html">Boost.Python</a></h1>
|
||||
|
||||
<h2 align="center">News/Change Log</h2>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
|
||||
<dl class="page-index">
|
||||
<dt>Current CVS</dt>
|
||||
|
||||
<dd>
|
||||
<ul>
|
||||
<li>C++ signatures are now automatically appended to the
|
||||
docstrings.
|
||||
|
||||
<li>New <a href="v2/docstring_options.html"
|
||||
><code>docstring_options.hpp</code></a> header to
|
||||
control the content of docstrings.
|
||||
|
||||
<li>Support for converting <code>void*</code> to/from python,
|
||||
with <code><a
|
||||
href="v2/opaque.html">opaque_pointer_converter</a></code>
|
||||
as the return value policy. Thanks to Niall Douglas for the
|
||||
initial patch.
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>19 October 2005 - 1.33.1 release</dt>
|
||||
|
||||
<dd>
|
||||
<ul>
|
||||
<li><code>wrapper<T></code> can now be used as expected with a
|
||||
held type of <i>some-smart-pointer</i><code><T></code></li>
|
||||
|
||||
<li>The build now assumes Python 2.4 by default, rather than 2.2</li>
|
||||
|
||||
<li>Support Python that's built without Unicode support</li>
|
||||
|
||||
<li>Support for wrapping classes with overloaded address-of
|
||||
(<code>&</code>) operators</li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>14 August 2005 - 1.33 release</dt>
|
||||
|
||||
<dd>
|
||||
<ul>
|
||||
<li>Support for docstrings on nonstatic properties.</li>
|
||||
|
||||
<li>We now export the client-provided docstrings for
|
||||
<code>init<optional<> ></code> and
|
||||
<i>XXX</i><code>_FUNCTION_OVERLOADS()</code> for only the last
|
||||
overload.</li>
|
||||
|
||||
<li>Fixed some support for Embedded VC++ 4</li>
|
||||
|
||||
<li>Better support for rvalue from-python conversions of shared_ptr:
|
||||
always return a pointer that holds the owning python object *unless*
|
||||
the python object contains a NULL shared_ptr holder of the right
|
||||
type.</li>
|
||||
|
||||
<li>Support for exposing <code>vector<T*></code> with the
|
||||
indexing suite.</li>
|
||||
|
||||
<li>Support for GCC-3.3 on MacOS.</li>
|
||||
|
||||
<li>updated visual studio project build file to include two new files
|
||||
(slice.cpp and wrapper.cpp)</li>
|
||||
|
||||
<li>Added search feature to the index page.</li>
|
||||
|
||||
<li>Numerous fixes to the tutorial</li>
|
||||
|
||||
<li>Numerous workarounds for MSVC 6 and 7, GCC 2.96, and EDG
|
||||
2.45</li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>11 March 2005</dt>
|
||||
|
||||
<dd>
|
||||
<ul>
|
||||
<li>Added a hack that will fool PyDoc into working with Boost.Python,
|
||||
thanks to Nick Rasmussen</li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>19 November 2004 - 1.32 release</dt>
|
||||
|
||||
<dd>
|
||||
<ul>
|
||||
<li>Updated to use the Boost Software License.</li>
|
||||
|
||||
<li>A new, <a href=
|
||||
"tutorial/doc/html/python/exposing.html#python.class_virtual_functions">
|
||||
better method of wrapping classes with virtual functions</a> has been
|
||||
implemented.</li>
|
||||
|
||||
<li>Support for upcoming GCC symbol export control features have been
|
||||
folded in, thanks to Niall Douglas.</li>
|
||||
|
||||
<li>Improved support for <code>std::auto_ptr</code>-like types.</li>
|
||||
|
||||
<li>The Visual C++ bug that makes top-level <i>cv-qualification</i>
|
||||
of function parameter types part of the function type has been worked
|
||||
around.</li>
|
||||
|
||||
<li>Components used by other libraries have been moved out of
|
||||
<code>python/detail</code> and into <code>boost/detail</code> to
|
||||
improve dependency relationships.</li>
|
||||
|
||||
<li>Miscellaneous bug fixes and compiler workarounds.</li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>8 Sept 2004</dt>
|
||||
|
||||
<dd>Support for Python's Bool type, thanks to <a href=
|
||||
"mailto:dholth-at-fastmail.fm">Daniel Holth</a>.</dd>
|
||||
|
||||
<dt>11 Sept 2003</dt>
|
||||
|
||||
<dd>
|
||||
<ul>
|
||||
<li>Changed the response to multiple to-python converters being
|
||||
registered for the same type from a hard error into warning;
|
||||
Boost.Python now reports the offending type in the message.</li>
|
||||
|
||||
<li>Added builtin <code>std::wstring</code> conversions</li>
|
||||
|
||||
<li>Added <code>std::out_of_range</code> => Python
|
||||
<code>IndexError</code> exception conversion, thanks to <a href=
|
||||
"mailto:RaoulGough-at-yahoo.co.uk">Raoul Gough</a></li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>9 Sept 2003</dt>
|
||||
|
||||
<dd>Added new <code><a href="v2/str.html#str-spec">str</a></code></dd>
|
||||
|
||||
<dt>constructors which take a range of characters, allowing strings
|
||||
containing nul (<code>'\0'</code>) characters.</dt>
|
||||
|
||||
<dt>8 Sept 2003</dt>
|
||||
|
||||
<dd>Added the ability to create methods from function objects (with an
|
||||
<code>operator()</code>); see the <a href=
|
||||
"v2/make_function.html#make_function-spec">make_function</a> docs for
|
||||
more info.</dd>
|
||||
|
||||
<dt>10 August 2003</dt>
|
||||
|
||||
<dd>Added the new <code>properties</code> unit tests contributed by
|
||||
<a href="mailto:romany-at-actimize.com">Roman Yakovenko</a> and
|
||||
documented <code>add_static_property</code> at his urging.</dd>
|
||||
|
||||
<dt>1 August 2003</dt>
|
||||
|
||||
<dd>
|
||||
Added the new <code>arg</code> class contributed by <a href=
|
||||
"mailto:nickm-at-sitius.com">Nikolay Mladenov</a> which supplies the
|
||||
ability to wrap functions that can be called with ommitted arguments in
|
||||
the middle:
|
||||
<pre>
|
||||
void f(int x = 0, double y = 3.14, std::string z = std::string("foo"));
|
||||
|
||||
BOOST_PYTHON_MODULE(test)
|
||||
{
|
||||
def("f", f
|
||||
, (arg("x", 0), arg("y", 3.14), arg("z", "foo")));
|
||||
}
|
||||
|
||||
</pre>And in Python:
|
||||
<pre>
|
||||
>>> import test
|
||||
>>> f(0, z = "bar")
|
||||
>>> f(z = "bar", y = 0.0)
|
||||
</pre>Thanks, Nikolay!
|
||||
</dd>
|
||||
|
||||
<dt>22 July 2003</dt>
|
||||
|
||||
<dd>Killed the dreaded "bad argument type for builtin operation" error.
|
||||
Argument errors now show the actual and expected argument types!</dd>
|
||||
|
||||
<dt>19 July 2003</dt>
|
||||
|
||||
<dd>Added the new <code><a href=
|
||||
"v2/return_arg.html">return_arg</a></code> policy from <a href=
|
||||
"mailto:nickm-at-sitius.com">Nikolay Mladenov</a>. Thanks, Nikolay!</dd>
|
||||
|
||||
<dt>18 March, 2003</dt>
|
||||
|
||||
<dd><a href="mailto:Gottfried.Ganssauge-at-haufe.de">Gottfried
|
||||
Ganßauge</a> has contributed <a href=
|
||||
"v2/opaque.html">opaque pointer support</a>.<br>
|
||||
<a href="mailto:nicodemus-at-globalite.com.br">Bruno da Silva de
|
||||
Oliveira</a> has contributed the exciting <a href=
|
||||
"../pyste/index.html">Pyste</a> ("Pie-steh") package.</dd>
|
||||
|
||||
<dt>24 February 2003</dt>
|
||||
|
||||
<dd>Finished improved support for <code>boost::shared_ptr</code>. Now any
|
||||
wrapped object of C++ class <code>X</code> can be converted automatically
|
||||
to <code>shared_ptr<X></code>, regardless of how it was wrapped.
|
||||
The <code>shared_ptr</code> will manage the lifetime of the Python object
|
||||
which supplied the <code>X</code>, rather than just the <code>X</code>
|
||||
object itself, and when such a <code>shared_ptr</code> is converted back
|
||||
to Python, the original Python object will be returned.</dd>
|
||||
|
||||
<dt>19 January 2003</dt>
|
||||
|
||||
<dd>Integrated <code>staticmethod</code> support from <a href=
|
||||
"mailto:nickm-at-sitius.com">Nikolay Mladenov</a>. Thanks, Nikolay!</dd>
|
||||
|
||||
<dt>29 December 2002</dt>
|
||||
|
||||
<dd>Added Visual Studio project file and instructions from Brett Calcott.
|
||||
Thanks, Brett!</dd>
|
||||
|
||||
<dt>20 December 2002</dt>
|
||||
|
||||
<dd>Added automatic downcasting for pointers, references, and smart
|
||||
pointers to polymorphic class types upon conversion to python</dd>
|
||||
|
||||
<dt>18 December 2002</dt>
|
||||
|
||||
<dd>Optimized from_python conversions for wrapped classes by putting the
|
||||
conversion logic in the shared library instead of registering separate
|
||||
converters for each class in each extension module</dd>
|
||||
|
||||
<dt>19 November 2002</dt>
|
||||
|
||||
<dd>Removed the need for users to cast base class member function
|
||||
pointers when used as arguments to <a href=
|
||||
"v2/class.html#class_-spec-modifiers">add_property</a></dd>
|
||||
|
||||
<dt>13 December 2002</dt>
|
||||
|
||||
<dd>Allow exporting of <a href=
|
||||
"v2/enum.html#enum_-spec"><code>enum_</code></a> values into enclosing
|
||||
<a href="v2/scope.html#scope-spec"><code>scope</code></a>.<br>
|
||||
Fixed unsigned integer conversions to deal correctly with numbers that
|
||||
are out-of-range of <code>signed long</code>.</dd>
|
||||
|
||||
<dt>14 November 2002</dt>
|
||||
|
||||
<dd>Auto-detection of class data members wrapped with <a href=
|
||||
"v2/data_members.html#make_getter-spec"><code>make_getter</code></a></dd>
|
||||
|
||||
<dt>13 November 2002</dt>
|
||||
|
||||
<dd>Full Support for <code>std::auto_ptr<></code> added.</dd>
|
||||
|
||||
<dt>October 2002</dt>
|
||||
|
||||
<dd>Ongoing updates and improvements to tutorial documentation</dd>
|
||||
|
||||
<dt>10 October 2002</dt>
|
||||
|
||||
<dd>Boost.Python V2 is released!</dd>
|
||||
</dl>
|
||||
<hr>
|
||||
|
||||
<p>Revised
|
||||
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
|
||||
19 November 2004
|
||||
<!--webbot bot="Timestamp" endspan i-checksum="39359" --></p>
|
||||
|
||||
<p><i>© Copyright <a href="../../../people/dave_abrahams.htm">Dave
|
||||
Abrahams</a> 2002-2003.</i></p>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,26 +0,0 @@
|
||||
[preface Introduction
|
||||
[quickbook 1.6]
|
||||
]
|
||||
|
||||
[section Synopsis]
|
||||
|
||||
Welcome to version 2 of Boost.Python, a C++ library which enables seamless interoperability between C++ and the Python programming language. The new version has been rewritten from the ground up, with a more convenient and flexible interface, and many new capabilities, including support for:
|
||||
|
||||
* References and Pointers
|
||||
* Globally Registered Type Coercions
|
||||
* Automatic Cross-Module Type Conversions
|
||||
* Efficient Function Overloading
|
||||
* C++ to Python Exception Translation
|
||||
* Default Arguments
|
||||
* Keyword Arguments
|
||||
* Manipulating Python objects in C++
|
||||
* Exporting C++ Iterators as Python Iterators
|
||||
* Documentation Strings
|
||||
|
||||
The development of these features was funded in part by grants to Boost Consulting from the Lawrence Livermore National Laboratories and by the Computational Crystallography Initiative at Lawrence Berkeley National Laboratories.
|
||||
|
||||
[endsect]
|
||||
[section Articles]
|
||||
|
||||
"Building Hybrid Systems With Boost Python", by Dave Abrahams and Ralf W. Grosse-Kunstleve (PDF)
|
||||
[endsect]
|
||||
445
doc/projects.html
Normal file
@@ -0,0 +1,445 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
|
||||
<!-- Copyright David Abrahams 2006. Distributed under the Boost -->
|
||||
<!-- Software License, Version 1.0. (See accompanying -->
|
||||
<!-- file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -->
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Cygwin (vers 1st September 2004), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<link rel="stylesheet" type="text/css" href="boost.css">
|
||||
|
||||
<title>Boost.Python - Projects using Boost.Python</title>
|
||||
</head>
|
||||
|
||||
<body link="#0000FF" vlink="#800080">
|
||||
<table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
|
||||
"header">
|
||||
<tr>
|
||||
<td valign="top" width="300">
|
||||
<h3><a href="../../../index.htm"><img height="86" width="277" alt=
|
||||
"C++ Boost" src="../../../boost.png" border="0"></a></h3>
|
||||
</td>
|
||||
|
||||
<td valign="top">
|
||||
<h1 align="center"><a href="index.html">Boost.Python</a></h1>
|
||||
|
||||
<h2 align="center">Projects using Boost.Python</h2>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
|
||||
<h2>Introduction</h2>
|
||||
|
||||
<p>This is a partial list of projects using Boost.Python. If you are using
|
||||
Boost.Python as your Python/C++ binding solution, we'd be proud to list
|
||||
your project on this page. Just <a href=
|
||||
"mailto:c++-sig@python.org">post</a> a short description of your project
|
||||
and how Boost.Python helps you get the job done, and we'll add it to this
|
||||
page .</p>
|
||||
<hr>
|
||||
|
||||
<h3>Data Analysis</h3>
|
||||
|
||||
<dl class="page-index">
|
||||
<dt><b><a href="http://www.neuralynx.com">NeuraLab</a></b></dt>
|
||||
|
||||
<dd>Neuralab is a data analysis environment specifically tailored for
|
||||
neural data from <a href="http://www.neuralynx.com">Neuralynx</a>
|
||||
acquisition systems. Neuralab combines presentation quality graphics, a
|
||||
numerical analysis library, and the <a href=
|
||||
"http://www.python.org">Python</a> scripting engine in a single
|
||||
application. With Neuralab, Neuralynx users can perform common analysis
|
||||
tasks with just a few mouse clicks. More advanced users can create custom
|
||||
Python scripts, which can optionally be assigned to menus and mouse
|
||||
clicks.</dd>
|
||||
</dl>
|
||||
|
||||
<dl class="page-index">
|
||||
<dt><b>TSLib</b> - <a href="http://www.fortressinv.com">Fortress
|
||||
Investment Group LLC</a></dt>
|
||||
|
||||
<dd>
|
||||
Fortress Investment Group has contracted <a href=
|
||||
"http://www.boost-consulting.com">Boost Consulting</a> to develop core
|
||||
internal financial analysis tools in C++ and to prepare Python bindings
|
||||
for them using Boost.Python.
|
||||
|
||||
<p>Tom Barket of Fortress writes:</p>
|
||||
|
||||
<blockquote>
|
||||
We have a large C++ analytical library specialized for research in
|
||||
finance and economics, built for speed and mission critical
|
||||
stability. Yet Python offers us the flexibility to test out new ideas
|
||||
quickly and increase the productivity of our time versus working in
|
||||
C++. There are several key features which make Python stand out. Its
|
||||
elegance, stability, and breadth of resources on the web are all
|
||||
valuable, but the most important is its extensibility, due to its
|
||||
open source transparency. Boost.Python makes Python extensibility
|
||||
extremely simple and straightforward, yet preserves a great deal of
|
||||
power and control.
|
||||
</blockquote>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3>Educational</h3>
|
||||
|
||||
<dl class="page-index">
|
||||
<dt><a href="http://edu.kde.org/kig"><b>Kig</b></a></dt>
|
||||
|
||||
<dd>
|
||||
<p>KDE Interactive Geometry is a high-school level educational tool,
|
||||
built for the KDE desktop. It is a nice tool to let students work with
|
||||
geometrical constructions. It is meant to be the most intuitive, yet
|
||||
featureful application of its kind.</p>
|
||||
|
||||
<p>Versions after 0.6.x (will) support objects built by the user
|
||||
himself in the Python language. The exporting of the relevant internal
|
||||
API's were done using Boost.Python, which made the process very
|
||||
easy.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3>Enterprise Software</h3>
|
||||
|
||||
<dl class="page-index">
|
||||
<dt><b><a href="http://openwbem.sourceforge.net">OpenWBEM</a></b></dt>
|
||||
|
||||
<dd>
|
||||
The OpenWBEM project is an effort to develop an open-source
|
||||
implementation of Web Based Enterprise Management suitable for
|
||||
commercial and non-commercial application
|
||||
|
||||
<p><a href="mailto:dnuffer@sco.com">Dan Nuffer</a> writes:</p>
|
||||
|
||||
<blockquote>
|
||||
I'm using Boost.Python to wrap the client API of OpenWBEM.This will
|
||||
make it easier to do rapid prototyping, testing, and scripting when
|
||||
developing management solutions that use WBEM.
|
||||
</blockquote>
|
||||
</dd>
|
||||
|
||||
<dt><b><a href="http://www.transversal.com">Metafaq</a></b></dt>
|
||||
|
||||
<dd>
|
||||
Metafaq, from <a href="http://www.transversal.com">Transversal,
|
||||
Inc.</a>, is an enterprise level online knowledge base management
|
||||
system.
|
||||
|
||||
<p><a href="mailto:ben.young-at-transversal.com">Ben Young</a>
|
||||
writes:</p>
|
||||
|
||||
<blockquote>
|
||||
Boost.Python is used in an automated process to generate python
|
||||
bindings to our api which is exposed though multiple backends and
|
||||
frontends. This allows us to write quick tests and bespoke scripts to
|
||||
perform one off tasks without having to go through the full
|
||||
compilation cycle.
|
||||
</blockquote>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3>Games</h3>
|
||||
|
||||
<dl>
|
||||
<dt><b><a href="http://www.firaxis.com">Civilization IV</a></b></dt>
|
||||
</dl>
|
||||
|
||||
<blockquote>
|
||||
“The fourth game in the PC strategy series that has sold over five
|
||||
million copies, Sid Meier's Civilization IV is a bold step forward for
|
||||
the franchise, with spectacular new 3D graphics and all-new single and
|
||||
multiplayer content. Civilization IV will also set a new standard for
|
||||
user-modification, allowing gamers to create their own add-ons using
|
||||
Python and XML.
|
||||
|
||||
<p>Sid Meier's Civilization IV will be released for PC in late 2005. For
|
||||
more information please visit <a href=
|
||||
"http://www.firaxis.com">http://www.firaxis.com</a> or write <a href=
|
||||
"mailto:kgilmore@firaxis.com">kgilmore@firaxis.com</a>”</p>
|
||||
</blockquote>
|
||||
|
||||
<p>Boost.Python is used as the interface layer between the C++ game code
|
||||
and Python. Python is used for many purposes in the game, including map
|
||||
generation, interface screens, game events, tools, tutorials, etc. Most
|
||||
high-level game operations have been exposed to Python in order to give
|
||||
modders the power they need to customize the game.</p>
|
||||
|
||||
<blockquote>
|
||||
-Mustafa Thamer, Civ4 Lead Programmer
|
||||
</blockquote>
|
||||
|
||||
<dl class="page-index">
|
||||
<dt><b><a href="http://vegastrike.sourceforge.net">Vega
|
||||
Strike</a></b></dt>
|
||||
|
||||
<dd>
|
||||
<a href="http://vegastrike.sourceforge.net">Vega Strike</a> is the 3D
|
||||
Space Simulator that allows you to trade and bounty hunt in a vast
|
||||
universe. Players face dangers, decisions, piracy, and aliens.
|
||||
|
||||
<p><a href="http://vegastrike.sourceforge.net">Vega Strike</a> has
|
||||
decided to base its scripting on python, using boost as the layer
|
||||
between the class hierarchy in python and the class hierarchy in C++.
|
||||
The result is a very flexible scripting system that treats units as
|
||||
native python classes when designing missions or writing AI's.</p>
|
||||
|
||||
<p>A large economic and planetary simulation is currently being run in
|
||||
the background in python and the results are returned back into C++ in
|
||||
the form of various factions' spaceships appearing near worlds that
|
||||
they are simulated to be near in python if the player is in the general
|
||||
neighborhood.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3>Graphics</h3>
|
||||
|
||||
<dl class="page-index">
|
||||
<dt><b><a href="http://sourceforge.net/projects/pyosg">OpenSceneGraph
|
||||
Bindings</a></b></dt>
|
||||
|
||||
<dd><a href="mailto:gideon@computer.org">Gideon May</a> has created a set
|
||||
of bindings for <a href=
|
||||
"http://www.openscenegraph.org">OpenSceneGraph</a>, a cross-platform
|
||||
C++/OpenGL library for the real-time visualization.<br>
|
||||
</dd>
|
||||
|
||||
<dt><b><a href=
|
||||
"http://www.slac.stanford.edu/grp/ek/hippodraw/index.html">HippoDraw</a></b></dt>
|
||||
|
||||
<dd>
|
||||
HippoDraw is a data analysis environment consisting of a canvas upon
|
||||
which graphs such as histograms, scattter plots, etc, are prsented. It
|
||||
has a highly interactive GUI interface, but some things you need to do
|
||||
with scripts. HippoDraw can be run as Python extension module so that
|
||||
all the manipulation can be done from either Python or the GUI.
|
||||
|
||||
<p>Before the web page came online, <a href=
|
||||
"mailto:Paul_Kunz@SLAC.Stanford.EDU">Paul F. Kunz</a> wrote:</p>
|
||||
|
||||
<blockquote>
|
||||
Don't have a web page for the project, but the organization's is
|
||||
<a href=
|
||||
"http://www.slac.stanford.edu">http://www.slac.stanford.edu</a> (the
|
||||
first web server site in America, I installed it).
|
||||
</blockquote>Which was just too cool a piece of trivia to omit.<br>
|
||||
|
||||
</dd>
|
||||
|
||||
<dt><a href="http://www.iplt.org"><b>IPLT</b></a></dt>
|
||||
|
||||
<dd>
|
||||
<a href="mailto:ansgar.philippsen-at-unibas.ch">Ansgar Philippsen</a>
|
||||
writes:
|
||||
|
||||
<blockquote>
|
||||
IPLT is an image processing library and toolbox for the structural
|
||||
biology electron microscopy community. I would call it a
|
||||
budding/evolving project, since it is currently not in production
|
||||
stage, but rather under heavy development. Python is used as the main
|
||||
scripting/interaction level, but also for rapid prototyping, since
|
||||
the underlying C++ class library is pretty much fully exposed via
|
||||
boost.python (at least the high-level interface). The combined power
|
||||
of C++ and Python for this project turned out to be just awesome.
|
||||
</blockquote><br>
|
||||
|
||||
</dd>
|
||||
|
||||
<dt><a href=
|
||||
"http://www.procoders.net/pythonmagick"><b>PythonMagick</b></a></dt>
|
||||
|
||||
<dd>PythonMagick binds the <a href=
|
||||
"http://www.graphicsmagick.org">GraphicsMagick</a> image manipulation
|
||||
library to Python.<br>
|
||||
</dd>
|
||||
|
||||
<dt><a href="http://www.vpython.org"><b>VPython</b></a></dt>
|
||||
|
||||
<dd>
|
||||
<a href="mailto:Bruce_Sherwood-at-ncsu.edu">Bruce Sherwood</a> writes:
|
||||
|
||||
<blockquote>
|
||||
VPython is an extension for Python that makes it easy to create
|
||||
navigable 3D animations, which are generated as a side effect of
|
||||
computational code. VPython is used in education for various
|
||||
purposes, including teaching physics and programming, but it has also
|
||||
been used by research scientists to visualize systems or data in 3D.
|
||||
</blockquote><br>
|
||||
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3>Scientific Computing</h3>
|
||||
|
||||
<dl class="page index">
|
||||
<dt><a href="http://camfr.sourceforge.net"><b>CAMFR</b></a></dt>
|
||||
|
||||
<dd>
|
||||
CAMFR is a photonics and electromagnetics modelling tool. Python is
|
||||
used for computational steering.
|
||||
|
||||
<p><a href="mailto:Peter.Bienstman@rug.ac.be">Peter Bienstman</a>
|
||||
writes:</p>
|
||||
|
||||
<blockquote>
|
||||
Thanks for providing such a great tool!
|
||||
</blockquote>
|
||||
</dd>
|
||||
|
||||
<dt><a href="http://cctbx.sourceforge.net"><b>cctbx - Computational
|
||||
Crystallography Toolbox</b></a></dt>
|
||||
|
||||
<dd>
|
||||
Computational Crystallography is concerned with the derivation of
|
||||
atomic models of crystal structures, given experimental X-ray
|
||||
diffraction data. The cctbx is an open-source library of fundamental
|
||||
algorithms for crystallographic computations. The core algorithms are
|
||||
implemented in C++ and accessed through higher-level Python interfaces.
|
||||
|
||||
<p>The cctbx grew together with Boost.Python and is designed from the
|
||||
ground up as a hybrid Python/C++ system. With one minor exception,
|
||||
run-time polymorphism is completely handled by Python. C++ compile-time
|
||||
polymorphism is used to implement performance critical algorithms. The
|
||||
Python and C++ layers are seamlessly integrated using Boost.Python.</p>
|
||||
|
||||
<p>The SourceForge cctbx project is organized in modules to facilitate
|
||||
use in non-crystallographic applications. The scitbx module implements
|
||||
a general purpose array family for scientific applications and pure C++
|
||||
ports of FFTPACK and the L-BFGS quasi-Newton minimizer.</p>
|
||||
</dd>
|
||||
|
||||
<dt><a href="http://www.llnl.gov/CASC/emsolve"><b>EMSolve</b></a></dt>
|
||||
|
||||
<dd>EMSolve is a provably stable, charge conserving, and energy
|
||||
conserving solver for Maxwell's equations.<br>
|
||||
</dd>
|
||||
|
||||
<dt><b><a href="http://cern.ch/gaudi">Gaudi</a></b> and <b><a href=
|
||||
"http://cern.ch/Gaudi/RootPython/">RootPython</a></b></dt>
|
||||
|
||||
<dd>
|
||||
Gaudi is a framework for particle physics collision data processing
|
||||
applications developed in the context of the LHCb and ATLAS experiments
|
||||
at CERN.
|
||||
|
||||
<p><a href="mailto:Pere.Mato@cern.ch">Pere Mato Vila</a> writes:</p>
|
||||
|
||||
<blockquote>
|
||||
We are using Boost.Python to provide scripting/interactive capability
|
||||
to our framework. We have a module called "GaudiPython" implemented
|
||||
using Boost.Python that allows the interaction with any framework
|
||||
service or algorithm from python. RootPython also uses Boost.Python
|
||||
to provide a generic "gateway" between the <a href=
|
||||
"http://root.cern.ch">ROOT</a> framework and python
|
||||
|
||||
<p>Boost.Python is great. We managed very quickly to interface our
|
||||
framework to python, which is great language. We are trying to
|
||||
facilitate to our physicists (end-users) a rapid analysis application
|
||||
development environment based on python. For that, Boost.Python plays
|
||||
and essential role.</p>
|
||||
</blockquote>
|
||||
</dd>
|
||||
|
||||
<dt><b><a href="http://www.esss.com.br">ESSS</a></b></dt>
|
||||
|
||||
<dd>
|
||||
ESSS (Engineering Simulation and Scientific Software) is a company that
|
||||
provides engineering solutions and acts in the brazilian and
|
||||
south-american market providing products and services related to
|
||||
Computational Fluid Dynamics and Image Analysis.
|
||||
|
||||
<p><a href="mailto:bruno@esss.com.br">Bruno da Silva de Oliveira</a>
|
||||
writes:</p>
|
||||
|
||||
<blockquote>
|
||||
Recently we moved our work from working exclusively with C++ to an
|
||||
hybrid-language approach, using Python and C++, with Boost.Python
|
||||
providing the layer between the two. The results are great so far!
|
||||
</blockquote>
|
||||
|
||||
<p>Two projects have been developed so far with this technology:</p>
|
||||
|
||||
<p><b><a href=
|
||||
"http://www.esss.com.br/index.php?pg=dev_projetos">Simba</a></b>
|
||||
provides 3D visualization of geological formations gattered from the
|
||||
simulation of the evolution of oil systems, allowing the user to
|
||||
analyse various aspects of the simulation, like deformation, pressure
|
||||
and fluids, along the time of the simulation.</p>
|
||||
|
||||
<p><b><a href=
|
||||
"http://www.esss.com.br/index.php?pg=dev_projetos">Aero</a></b> aims to
|
||||
construct a CFD with brazilian technology, which involves various
|
||||
companies and universities. ESSS is responsible for various of the
|
||||
application modules, including GUI and post-processing of results.</p>
|
||||
</dd>
|
||||
|
||||
<dt><b><a href="http://www.rationaldiscovery.com">Rational Discovery
|
||||
LLC</a></b></dt>
|
||||
|
||||
<dd>
|
||||
Rational Discovery provides computational modeling, combinatorial
|
||||
library design and custom software development services to the
|
||||
pharmaceutical, biotech and chemical industries. We do a substantial
|
||||
amount of internal research to develop new approaches for applying
|
||||
machine-learning techniques to solve chemical problems. Because we're a
|
||||
small organization and chemistry is a large and complex field, it is
|
||||
essential that we be able to quickly and easily prototype and test new
|
||||
algorithms.
|
||||
|
||||
<p>For our internal software, we implement core data structures in C
|
||||
and expose them to Python using Boost.Python. Algorithm development is
|
||||
done in Python and then translated to C if required (often it's not).
|
||||
This hybrid development approach not only greatly increases our
|
||||
productivity, but it also allows "non-developers" (people without C
|
||||
experience) to take part in method development. Learning C is a
|
||||
daunting task, but "Python fits your brain." (Thanks to Bruce Eckel for
|
||||
the quote.)</p>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3>Systems Libraries</h3>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://itamarst.org/software"><b>Fusion</b></a></dt>
|
||||
|
||||
<dd>
|
||||
<p>Fusion is a library that supports implementing protocols in C++ for
|
||||
use with Twisted, allowing control over memory allocation strategies,
|
||||
fast method calls internally, etc.. Fusion supports TCP, UDP and
|
||||
multicast, and is implemented using the Boost.Python python
|
||||
bindings.</p>
|
||||
|
||||
<p>Fusion is licensed under the MIT license, and available for download
|
||||
from <a href=
|
||||
"http://itamarst.org/software">http://itamarst.org/software</a>.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3>Tools</h3>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://www.jayacard.org"><b>Jayacard</b></a></dt>
|
||||
|
||||
<dd>
|
||||
Jayacard aims at developing a secure portable open source operating
|
||||
system for contactless smart cards and a complete suite of high quality
|
||||
development tools to ease smart card OS and application development.
|
||||
|
||||
<p>The core of the smart card reader management is written in C++ but
|
||||
all the development tools are written in the friendly Python language.
|
||||
Boost plays the fundamental role of binding the tools to our core smart
|
||||
card reader library.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
<hr>
|
||||
|
||||
<p>Revised
|
||||
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
|
||||
15 July, 2003</p>
|
||||
|
||||
<p><i>© Copyright <a href="../../../people/dave_abrahams.htm">Dave
|
||||
Abrahams</a> 2002-2003.</i></p>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,64 +0,0 @@
|
||||
[book Boost.Python
|
||||
[quickbook 1.7]
|
||||
[authors [Abrahams, David], [Seefeld, Stefan]]
|
||||
[copyright 2002 - 2015 David Abrahams, Stefan Seefeld]
|
||||
[category inter-language support]
|
||||
[id python]
|
||||
[purpose
|
||||
Reflects C++ classes and functions into Python
|
||||
]
|
||||
[license
|
||||
Distributed under the Boost Software License, Version 1.0.
|
||||
(See accompanying file LICENSE_1_0.txt or copy at
|
||||
[@http://www.boost.org/LICENSE_1_0.txt])
|
||||
]
|
||||
]
|
||||
|
||||
[def _boost_ [@http://www.boost.org Boost]]
|
||||
[def _bb_ [@http://www.boost.org/build Boost.Build]]
|
||||
[def _bb_list_ [@http://www.boost.org/more/mailing_lists.htm#jamboost Boost.Build mailing list]]
|
||||
[def _bp_list_ [@http://www.boost.org/more/mailing_lists.htm#cplussig Boost.Python mailing list]]
|
||||
[def _tutorial_ [@tutorial/index.html Tutorial]]
|
||||
[def _reference_ [@reference/index.html Reference Manual]]
|
||||
[def _gsg_ Boost [@http://www.boost.org/more/getting_started/ Getting Started Guide]]
|
||||
[def _extending_ [@https://docs.python.org/2/extending/extending.html extending]]
|
||||
[def _embedding_ [@https://docs.python.org/2/extending/embedding.html embedding]]
|
||||
|
||||
[h2 Synopsis]
|
||||
|
||||
Welcome to Boost.Python, a C++ library which enables seamless interoperability between C++ and the Python programming language. The library includes support for:
|
||||
|
||||
* References and Pointers
|
||||
* Globally Registered Type Coercions
|
||||
* Automatic Cross-Module Type Conversions
|
||||
* Efficient Function Overloading
|
||||
* C++ to Python Exception Translation
|
||||
* Default Arguments
|
||||
* Keyword Arguments
|
||||
* Manipulating Python objects in C++
|
||||
* Exporting C++ Iterators as Python Iterators
|
||||
* Documentation Strings
|
||||
|
||||
The development of these features was funded in part by grants to `Boost Consulting` from the [@http://www.llnl.gov Lawrence Livermore National Laboratories] and by the [@http://cci.lbl.gov Computational Crystallography Initiative] at Lawrence Berkeley National Laboratories.
|
||||
|
||||
[section Contents]
|
||||
|
||||
* _tutorial_
|
||||
* [link building Building and Testing]
|
||||
* _reference_
|
||||
* [link configuration Configuration Information]
|
||||
* [link glossary Glossary]
|
||||
* [link support Support Resources]
|
||||
* [link faq Frequently Asked Questions (FAQs)]
|
||||
|
||||
[endsect]
|
||||
|
||||
[h2 Articles]
|
||||
|
||||
[@article.html Building Hybrid Systems With Boost Python], by Dave Abrahams and Ralf W. Grosse-Kunstleve
|
||||
|
||||
[include building.qbk]
|
||||
[include configuration.qbk]
|
||||
[include support.qbk]
|
||||
[include faq.qbk]
|
||||
[include glossary.qbk]
|
||||
@@ -1,21 +0,0 @@
|
||||
[book Boost.Python Reference Manual
|
||||
[quickbook 1.7]
|
||||
[authors [Abrahams, David], [Seefeld, Stefan]]
|
||||
[copyright 2002 2003 2004 2005 2015 David Abrahams, Stefan Seefeld]
|
||||
[id reference]
|
||||
[license
|
||||
Distributed under the Boost Software License, Version 1.0.
|
||||
(See accompanying file LICENSE_1_0.txt or copy at
|
||||
[@http://www.boost.org/LICENSE_1_0.txt]
|
||||
]
|
||||
]
|
||||
|
||||
[include reference/concepts.qbk]
|
||||
[include reference/components.qbk]
|
||||
[include reference/objects.qbk]
|
||||
[include reference/functions.qbk]
|
||||
[include reference/conversion.qbk]
|
||||
[include reference/embedding.qbk]
|
||||
[include reference/utility.qbk]
|
||||
[include reference/topics.qbk]
|
||||
[include glossary.qbk]
|
||||
@@ -1,62 +0,0 @@
|
||||
[section boost/python/args.hpp]
|
||||
[section Introduction]
|
||||
Supplies a family of overloaded functions for specifying argument keywords for wrapped C++ functions.
|
||||
[section keyword-expressions]
|
||||
A keyword-expression results in an object which holds a sequence of [link ntbs]\ es, and whose type encodes the number of keywords specified. The keyword-expression may contain default values for some or all of the keywords it holds
|
||||
[endsect]
|
||||
[endsect]
|
||||
[section Class `arg`]
|
||||
The objects of class arg are keyword-expressions holding one keyword ( size one )
|
||||
``
|
||||
namespace boost { namespace python
|
||||
{
|
||||
struct arg
|
||||
{
|
||||
template <class T>
|
||||
arg &operator = (T const &value);
|
||||
explicit arg (char const *name){elements[0].name = name;}
|
||||
};
|
||||
|
||||
}}
|
||||
``
|
||||
[endsect]
|
||||
[section Class `arg` constructor]
|
||||
``arg(char const* name);``
|
||||
[variablelist
|
||||
[[Requires][The argument must be a [link ntbs].]]
|
||||
[[Effects][Constructs an arg object holding a keyword with name name.]]
|
||||
]
|
||||
[endsect]
|
||||
[section Class `arg` operator=]
|
||||
``template <class T> arg &operator = (T const &value);``
|
||||
[variablelist
|
||||
[[Requires][The argument must convertible to python.]]
|
||||
[[Effects][Assigns default value for the keyword.]]
|
||||
[[Returns][Reference to `this`.]]
|
||||
]
|
||||
[endsect]
|
||||
[section Keyword-expression operator,]
|
||||
``
|
||||
keyword-expression operator , (keyword-expression, const arg &kw) const
|
||||
keyword-expression operator , (keyword-expression, const char *name) const;
|
||||
``
|
||||
[variablelist
|
||||
[[Requires][The argument name must be a [link ntbs].]]
|
||||
[[Effects][Extends the keyword-expression argument with one more keyword.]]
|
||||
[[Returns][The extended keyword-expression.]]
|
||||
]
|
||||
[endsect]
|
||||
[section Example]
|
||||
``
|
||||
#include <boost/python/def.hpp>
|
||||
using namespace boost::python;
|
||||
|
||||
int f(double x, double y, double z=0.0, double w=1.0);
|
||||
|
||||
BOOST_PYTHON_MODULE(xxx)
|
||||
{
|
||||
def("f", f, (arg("x"), "y", arg("z")=0.0, arg("w")=1.0));
|
||||
}
|
||||
``
|
||||
[endsect]
|
||||
[endsect]
|
||||