diff options
Diffstat (limited to 'Doc')
| -rw-r--r-- | Doc/Manual/Go.html | 407 | ||||
| -rw-r--r-- | Doc/Manual/Python.html | 37 | ||||
| -rw-r--r-- | Doc/Manual/Ruby.html | 2 |
3 files changed, 232 insertions, 214 deletions
diff --git a/Doc/Manual/Go.html b/Doc/Manual/Go.html index c008ef22c..a62efec43 100644 --- a/Doc/Manual/Go.html +++ b/Doc/Manual/Go.html @@ -13,8 +13,8 @@ <li><a href="#Go_examples">Examples</a> <li><a href="#Go_running_swig">Running SWIG with Go</a> <ul> -<li><a href="#Go_commandline">Additional Commandline Options</a> -<li><a href="#Go_outputs">Go Output Files</a> +<li><a href="#Go_commandline">Go-specific Commandline Options</a> +<li><a href="#Go_outputs">Generated Wrapper Files</a> </ul> <li><a href="#Go_basic_tour">A tour of basic C/C++ wrapping</a> <ul> @@ -60,38 +60,43 @@ see <a href="http://golang.org/">golang.org</a>. <p> -Go is a compiled language, not a scripting language. However, it does -not support direct calling of functions written in C/C++. The cgo -program may be used to generate wrappers to call C code from Go, but -there is no convenient way to call C++ code. SWIG fills this gap. +Go does not support direct calling of functions written in C/C++. The +<a href="https://golang.org/cmd/cgo/">cgo program</a> may be used to generate +wrappers to call C code from Go, but there is no convenient way to call C++ +code. SWIG fills this gap. </p> <p> -There are (at least) two different Go compilers. One is the gc -compiler, normally invoked via the go tool. The other -is the gccgo compiler, which is a frontend to the gcc compiler suite. -The interface to C/C++ code is completely different for the two Go -compilers. SWIG supports both, selected by a command line option. +There are (at least) two different Go compilers. The first is the gc compiler +of the <a href="https://golang.org/doc/install">Go distribution</a>, normally +invoked via the <a href="https://golang.org/cmd/go/">go tool</a>. +The second Go compiler is the <a href="https://golang.org/doc/install/gccgo"> +gccgo compiler</a>, which is a frontend to the GCC compiler suite. +The interface to C/C++ code is completely different for the two Go compilers. +SWIG supports both Go compilers, selected by the <tt>-gccgo</tt> command line +option. </p> <p> -Because Go is a type-safe compiled language, SWIG's runtime type -checking and runtime library are not used with Go. This should be -borne in mind when reading the rest of the SWIG documentation. +Go is a type-safe compiled language and the wrapper code generated by SWIG is +type-safe as well. In case of type issues the build will fail and hence SWIG's +<a href="Modules.html#Modules_nn2">runtime library</a> and +<a href="Typemaps.html#Typemaps_runtime_type_checker">runtime type checking</a> +are not used. </p> <H2><a name="Go_examples"></a>23.2 Examples</H2> <p> -Working examples can be found here: +Working examples can be found in the +<a href="https://github.com/swig/swig/tree/master/Examples/go">SWIG source tree +</a>. </p> -<ul> -<li><a href="https://golang.org/misc/swig">Examples from the Go source tree</a> -<li><a href="https://github.com/swig/swig/tree/master/Examples/go">Examples from the SWIG source tree</a> -</ul> + <p> -The examples in the 2nd link are shipped with the SWIG distribution under the Examples/go directory. +Please note that the examples in the SWIG source tree use makefiles with the .i +SWIG interface file extension for backwards compatibility with Go 1. </p> @@ -99,12 +104,83 @@ The examples in the 2nd link are shipped with the SWIG distribution under the Ex <p> -To generate Go code, use the <tt>-go</tt> option with SWIG. By -default SWIG will generate code for the gc compilers. To generate -code for gccgo, you should also use the <tt>-gccgo</tt> option. +Most Go programs are built using the <a href="https://golang.org/cmd/go/">go +tool</a>. Since Go 1.1 the go tool has support for SWIG. To use it, give your +SWIG interface file the extension .swig (for C code) or .swigcxx (for C++ code). +Put that file in a GOPATH/src directory as usual for Go sources. Put other +C/C++ code in the same directory with extensions of .c and .cxx. The +<tt>go build</tt> and <tt>go install</tt> commands will automatically run SWIG +for you and compile the generated wrapper code. To check the SWIG command line +options the go tool uses run <tt>go build -x</tt>. To access the automatically +generated files run <tt>go build -work</tt>. You'll find the files under the +temporary WORK directory. +</p> + +<p> +To manually generate and compile C/C++ wrapper code for Go, use the <tt>-go</tt> +option with SWIG. By default SWIG will generate code for the Go compiler of the +Go distribution. To generate code for gccgo, you should also use the +<tt>-gccgo</tt> option. </p> -<H3><a name="Go_commandline"></a>23.3.1 Additional Commandline Options</H3> +<p> +When using the <tt>-cgo</tt> option, SWIG will generate files that can be used +directly by <tt>go build</tt>. Starting with the Go 1.5 distribution the +<tt>-cgo</tt> option has to be given. Put your SWIG interface file in a +directory under GOPATH/src, and give it a name that does <b>not</b> end in the +.swig or .swigcxx extension. Typically the SWIG interface file extension is .i +in this case. +</p> + +<div class="code"><pre> +% swig -go -cgo example.i +% go install +</pre></div> + +<p> +You will now have a Go package that you can import from other Go packages as +usual. +</p> + +<p> +To use SWIG without the <tt>-cgo</tt> option, more steps are required. Recall +that this only works with Go versions before 1.5. When using Go version 1.2 or +later, or when using gccgo, the code generated by SWIG can be linked directly +into the Go program. A typical command sequence when using the Go compiler of +the Go distribution would look like this: +</p> + +<div class="code"><pre> +% swig -go example.i +% gcc -c code.c # The C library being wrapped. +% gcc -c example_wrap.c +% go tool 6g example.go +% go tool 6c example_gc.c +% go tool pack grc example.a example.6 example_gc.6 code.o example_wrap.o +% go tool 6g main.go +% go tool 6l main.6 +</pre></div> + +<p> +You can also put the wrapped code into a shared library, and when using the Go +versions before 1.2 this is the only supported option. A typical command +sequence for this approach would look like this: +</p> + +<div class="code"><pre> +% swig -go -use-shlib example.i +% gcc -c -fpic example.c +% gcc -c -fpic example_wrap.c +% gcc -shared example.o example_wrap.o -o example.so +% go tool 6g example.go +% go tool 6c example_gc.c +% go tool pack grc example.a example.6 example_gc.6 +% go tool 6g main.go # your code, not generated by SWIG +% go tool 6l main.6 +</pre></div> + + +<H3><a name="Go_commandline"></a>23.3.1 Go-specific Commandline Options</H3> <p> @@ -116,9 +192,9 @@ also be seen by using: swig -go -help </pre></div> -<table summary="Go specific options"> +<table summary="Go-specific options"> <tr> -<th>Go specific options</th> +<th>Go-specific options</th> </tr> <tr> @@ -144,7 +220,7 @@ swig -go -help <tr> <td>-gccgo</td> <td>Generate code for gccgo. The default is to generate code for - the gc compiler.</td> + the Go compiler of the Go distribution.</td> </tr> <tr> @@ -156,8 +232,8 @@ swig -go -help <tr> <td>-use-shlib</td> <td>Tell SWIG to emit code that uses a shared library. This is only - meaningful for the gc compiler, which needs to know at compile time - whether a shared library will be used.</td> + meaningful for the Go compiler of the Go distribution, which needs to know at + compile time whether a shared library will be used.</td> </tr> <tr> @@ -165,9 +241,9 @@ swig -go -help <td>Set the runtime name of the shared library that the dynamic linker should include at runtime. The default is the package name with ".so" appended. This is only used when generating code for - the gc compiler; when using gccgo, the equivalent name will be taken from - the <code>-soname</code> option passed to the linker. Using this - option implies the -use-shlib option.</td> + the Go compiler of the Go distribution; when using gccgo, the equivalent name + will be taken from the <code>-soname</code> option passed to the linker. + Using this option implies the -use-shlib option.</td> </tr> <tr> @@ -186,16 +262,17 @@ swig -go -help </table> -<H3><a name="Go_outputs"></a>23.3.2 Go Output Files</H3> + +<H3><a name="Go_outputs"></a>23.3.2 Generated Wrapper Files</H3> -<p>There are two different approaches to generating output files, +<p>There are two different approaches to generating wrapper files, controlled by SWIG's <tt>-cgo</tt> option. The <tt>-cgo</tt> option works with Go version 1.2 or later. It is required when using Go version 1.5 or later.</p> <p>With or without the <tt>-cgo</tt> option, SWIG will generate the - following files when generating Go code:</p> + following files when generating wrapper code:</p> <ul> <li> @@ -229,70 +306,6 @@ combined with the compiled MODULE.go using go tool pack. </li> </ul> -<p> -Most Go programs are built using the go tool. The go tool has limited -support for SWIG. To use it, put your SWIG interface into a file with -the extension .swig, or, if you are wrapping C++ code, .swigcxx. Put -that file in a GOPATH/src directory as usual for Go sources. Put -other interface code in the same directory with extensions of .c and -.cxx. The <tt>go build</tt> and <tt>go install</tt> commands will -automatically run SWIG for you and will build the interface code. -</p> - -<p> -You can also use SWIG directly yourself. When using -the <tt>-cgo</tt> option, SWIG will generate files that can be used -directly by <tt>go build</tt>. Put your SWIG input file in a -directory under GOPATH/src, and give it a name that does not end in -.swig or .swigcxx. -</p> - -<div class="code"><pre> -% swig -go -cgo example.i -% go install -</pre></div> - -<p> -You will now have a Go package that you can import from other Go -packages as usual. -</p> - -<p> -To use SWIG without the <tt>-cgo</tt> option, more steps are required. -Recall that this only works with Go versions before 1.5. When using -Go version 1.2 or later, or when using gccgo, the code generated by -SWIG can be linked directly into the Go program. A typical command -sequence when using the gc compiler would look like this: -</p> - -<div class="code"><pre> -% swig -go example.i -% gcc -c code.c # The C library being wrapped. -% gcc -c example_wrap.c -% go tool 6g example.go -% go tool 6c example_gc.c -% go tool pack grc example.a example.6 example_gc.6 code.o example_wrap.o -% go tool 6g main.go -% go tool 6l main.6 -</pre></div> - -<p> -You can also put the wrapped code into a shared library, and when -using the Go versions before 1.2 this is the only supported option. A -typical command sequence for this approach would look like this: -</p> - -<div class="code"><pre> -% swig -go -use-shlib example.i -% gcc -c -fpic example.c -% gcc -c -fpic example_wrap.c -% gcc -shared example.o example_wrap.o -o example.so -% go tool 6g example.go -% go tool 6c example_gc.c -% go tool pack grc example.a example.6 example_gc.6 -% go tool 6g main.go # your code, not generated by SWIG -% go tool 6l main.6 -</pre></div> <H2><a name="Go_basic_tour"></a>23.4 A tour of basic C/C++ wrapping</H2> @@ -606,22 +619,22 @@ completely to avoid common pitfalls with directors in Go. <H4><a name="Go_director_example_cpp_code"></a>23.4.7.1 Example C++ code</H4> <p> -The step by step guide is based on two example C++ classes. FooBarAbs is an -abstract C++ class and the FooBarCpp class inherits from it. This guide +The step by step guide is based on two example C++ classes. FooBarAbstract is +an abstract C++ class and the FooBarCpp class inherits from it. This guide explains how to implement a FooBarGo class similar to the FooBarCpp class. </p> <p> -<tt>FooBarAbs</tt> abstract C++ class: +<tt>FooBarAbstract</tt> abstract C++ class: </p> <div class="code"> <pre> -class FooBarAbs +class FooBarAbstract { public: - FooBarAbs() {}; - virtual ~FooBarAbs() {}; + FooBarAbstract() {}; + virtual ~FooBarAbstract() {}; std::string FooBar() { return this->Foo() + ", " + this->Bar(); @@ -643,11 +656,11 @@ protected: <div class="code"> <pre> -class FooBarCpp : public FooBarAbs +class FooBarCpp : public FooBarAbstract { protected: virtual std::string Foo() { - return "C++ " + FooBarAbs::Foo(); + return "C++ " + FooBarAbstract::Foo(); } virtual std::string Bar() { @@ -691,14 +704,14 @@ directive, like this: <p> Second, you must use the %feature("director") directive to tell SWIG which -classes should get directors. In the example the FooBarAbs class needs the +classes should get directors. In the example the FooBarAbstract class needs the director feature enabled so that the FooBarGo class can inherit from it, like this: </p> <div class="code"> <pre> -%feature("director") FooBarAbs; +%feature("director") FooBarAbstract; </pre> </div> @@ -782,21 +795,21 @@ As an example see part of the <tt>FooBarGo</tt> class: <div class="code"> <pre> -type overwrittenMethodsOnFooBarAbs struct { - fb FooBarAbs +type overwrittenMethodsOnFooBarAbstract struct { + fb FooBarAbstract } -func (om *overwrittenMethodsOnFooBarAbs) Foo() string { +func (om *overwrittenMethodsOnFooBarAbstract) Foo() string { ... } -func (om *overwrittenMethodsOnFooBarAbs) Bar() string { +func (om *overwrittenMethodsOnFooBarAbstract) Bar() string { ... } func NewFooBarGo() FooBarGo { - om := &overwrittenMethodsOnFooBarAbs{} - fb := NewDirectorFooBarAbs(om) + om := &overwrittenMethodsOnFooBarAbstract{} + fb := NewDirectorFooBarAbstract(om) om.fb = fb ... } @@ -806,25 +819,25 @@ func NewFooBarGo() FooBarGo { <p> The complete example, including the <tt>FooBarGoo</tt> class implementation, can be found in <a href="#Go_director_foobargo_class">the end of the guide</a>. In -this part of the example the virtual methods <tt>FooBarAbs::Foo</tt> and -<tt>FooBarAbs::Bar</tt> have been overwritten with Go methods similarly to how -the <tt>FooBarAbs</tt> virtual methods are overwritten by the <tt>FooBarCpp</tt> -class. +this part of the example the virtual methods <tt>FooBarAbstract::Foo</tt> and +<tt>FooBarAbstract::Bar</tt> have been overwritten with Go methods similarly to +how the <tt>FooBarAbstract</tt> virtual methods are overwritten by the +<tt>FooBarCpp</tt> class. </p> <p> The <tt>DirectorInterface</tt> in the example is implemented by the -<tt>overwrittenMethodsOnFooBarAbs</tt> Go struct type. A pointer to a -<tt>overwrittenMethodsOnFooBarAbs</tt> struct instance will be given to the -<tt>NewDirectorFooBarAbs</tt> constructor function. The constructor return -value implements the <tt>FooBarAbs</tt> interface. -<tt>overwrittenMethodsOnFooBarAbs</tt> could in theory be any Go type but in -practice a struct is used as it typically contains at least a value of the +<tt>overwrittenMethodsOnFooBarAbstract</tt> Go struct type. A pointer to a +<tt>overwrittenMethodsOnFooBarAbstract</tt> struct instance will be given to the +<tt>NewDirectorFooBarAbstract</tt> constructor function. The constructor return +value implements the <tt>FooBarAbstract</tt> interface. +<tt>overwrittenMethodsOnFooBarAbstract</tt> could in theory be any Go type but +in practice a struct is used as it typically contains at least a value of the C++ class interface so that the overwritten methods can use the rest of the C++ class. If the <tt>FooBarGo</tt> class would receive additional constructor arguments then these would also typically be stored in the -<tt>overwrittenMethodsOnFooBarAbs</tt> struct so that they can be used by the -Go methods. +<tt>overwrittenMethodsOnFooBarAbstract</tt> struct so that they can be used by +the Go methods. </p> @@ -840,7 +853,7 @@ the method in the base class. This is also the case for the <div class="code"> <pre> virtual std::string Foo() { - return "C++ " + FooBarAbs::Foo(); + return "C++ " + FooBarAbstract::Foo(); } </pre> </div> @@ -853,8 +866,8 @@ The <tt>FooBarGo.Foo</tt> implementation in the example looks like this: <div class="code"> <pre> -func (om *overwrittenMethodsOnFooBarAbs) Foo() string { - return "Go " + DirectorFooBarAbsFoo(om.fb) +func (om *overwrittenMethodsOnFooBarAbstract) Foo() string { + return "Go " + DirectorFooBarAbstractFoo(om.fb) } </pre> </div> @@ -887,31 +900,31 @@ this: <div class="code"> <pre> type FooBarGo interface { - FooBarAbs - deleteFooBarAbs() + FooBarAbstract + deleteFooBarAbstract() IsFooBarGo() } type fooBarGo struct { - FooBarAbs + FooBarAbstract } -func (fbgs *fooBarGo) deleteFooBarAbs() { - DeleteDirectorFooBarAbs(fbgs.FooBarAbs) +func (fbgs *fooBarGo) deleteFooBarAbstract() { + DeleteDirectorFooBarAbstract(fbgs.FooBarAbstract) } func (fbgs *fooBarGo) IsFooBarGo() {} func NewFooBarGo() FooBarGo { - om := &overwrittenMethodsOnFooBarAbs{} - fb := NewDirectorFooBarAbs(om) + om := &overwrittenMethodsOnFooBarAbstract{} + fb := NewDirectorFooBarAbstract(om) om.fb = fb - return &fooBarGo{FooBarAbs: fb} + return &fooBarGo{FooBarAbstract: fb} } func DeleteFooBarGo(fbg FooBarGo) { - fbg.deleteFooBarAbs() + fbg.deleteFooBarAbstract() } </pre> </div> @@ -921,12 +934,12 @@ func DeleteFooBarGo(fbg FooBarGo) { The complete example, including the <tt>FooBarGoo</tt> class implementation, can be found in <a href="#Go_director_foobargo_class">the end of the guide</a>. In this part of the example the private <tt>fooBarGo</tt> struct embeds <tt> -FooBarAbs</tt> which lets the <tt>fooBarGo</tt> Go type "inherit" all the -methods of the <tt>FooBarAbs</tt> C++ class by means of embedding. The public -<tt>FooBarGo</tt> interface type includes the <tt>FooBarAbs</tt> interface and -hence <tt>FooBarGo</tt> can be used as a drop in replacement for -<tt>FooBarAbs</tt> while the reverse isn't possible and would raise a compile -time error. Furthemore the constructor and destructor functions <tt> +FooBarAbstract</tt> which lets the <tt>fooBarGo</tt> Go type "inherit" all the +methods of the <tt>FooBarAbstract</tt> C++ class by means of embedding. The +public <tt>FooBarGo</tt> interface type includes the <tt>FooBarAbstract</tt> +interface and hence <tt>FooBarGo</tt> can be used as a drop in replacement for +<tt>FooBarAbstract</tt> while the reverse isn't possible and would raise a +compile time error. Furthemore the constructor and destructor functions <tt> NewFooBarGo</tt> and <tt>DeleteFooBarGo</tt> take care of all the director specifics and to the user the class appears as any other SWIG wrapped C++ class. @@ -946,13 +959,13 @@ in the <tt>FooBarGo</tt> class is here: <div class="code"> <pre> -type overwrittenMethodsOnFooBarAbs struct { - fb FooBarAbs +type overwrittenMethodsOnFooBarAbstract struct { + fb FooBarAbstract } func NewFooBarGo() FooBarGo { - om := &overwrittenMethodsOnFooBarAbs{} - fb := NewDirectorFooBarAbs(om) // fb.v = om + om := &overwrittenMethodsOnFooBarAbstract{} + fb := NewDirectorFooBarAbstract(om) // fb.v = om om.fb = fb // Backlink causes cycle as fb.v = om! ... } @@ -963,27 +976,27 @@ func NewFooBarGo() FooBarGo { In order to be able to use <tt>runtime.SetFinalizer</tt> nevertheless the finalizer needs to be set on something that isn't in a cycle and that references the director object instance. In the <tt>FooBarGo</tt> class example the <tt> -FooBarAbs</tt> director instance can be automatically deleted by setting the -finalizer on <tt>fooBarGo</tt>: +FooBarAbstract</tt> director instance can be automatically deleted by setting +the finalizer on <tt>fooBarGo</tt>: </p> <div class="code"> <pre> type fooBarGo struct { - FooBarAbs + FooBarAbstract } -type overwrittenMethodsOnFooBarAbs struct { - fb FooBarAbs +type overwrittenMethodsOnFooBarAbstract struct { + fb FooBarAbstract } func NewFooBarGo() FooBarGo { - om := &overwrittenMethodsOnFooBarAbs{} - fb := NewDirectorFooBarAbs(om) + om := &overwrittenMethodsOnFooBarAbstract{} + fb := NewDirectorFooBarAbstract(om) om.fb = fb // Backlink causes cycle as fb.v = om! - fbgs := &fooBarGo{FooBarAbs: fb} - runtime.SetFinalizer(fbgs, FooBarGo.deleteFooBarAbs) + fbgs := &fooBarGo{FooBarAbstract: fb} + runtime.SetFinalizer(fbgs, FooBarGo.deleteFooBarAbstract) return fbgs } </pre> @@ -1007,73 +1020,75 @@ The complete and annotated <tt>FooBarGo</tt> class looks like this: <div class="code"> <pre> -// FooBarGo is a superset of FooBarAbs and hence FooBarGo can be used as a drop -// in replacement for FooBarAbs but the reverse causes a compile time error. +// FooBarGo is a superset of FooBarAbstract and hence FooBarGo can be used as a +// drop in replacement for FooBarAbstract but the reverse causes a compile time +// error. type FooBarGo interface { - FooBarAbs - deleteFooBarAbs() + FooBarAbstract + deleteFooBarAbstract() IsFooBarGo() } -// Via embedding fooBarGo "inherits" all methods of FooBarAbs. +// Via embedding fooBarGo "inherits" all methods of FooBarAbstract. type fooBarGo struct { - FooBarAbs + FooBarAbstract } -func (fbgs *fooBarGo) deleteFooBarAbs() { - DeleteDirectorFooBarAbs(fbgs.FooBarAbs) +func (fbgs *fooBarGo) deleteFooBarAbstract() { + DeleteDirectorFooBarAbstract(fbgs.FooBarAbstract) } -// The IsFooBarGo method ensures that FooBarGo is a superset of FooBarAbs. +// The IsFooBarGo method ensures that FooBarGo is a superset of FooBarAbstract. // This is also how the class hierarchy gets represented by the SWIG generated -// wrapper code. For an instance FooBarCpp has the IsFooBarAbs and IsFooBarCpp -// methods. +// wrapper code. For an instance FooBarCpp has the IsFooBarAbstract and +// IsFooBarCpp methods. func (fbgs *fooBarGo) IsFooBarGo() {} // Go type that defines the DirectorInterface. It contains the Foo and Bar -// methods that overwrite the respective virtual C++ methods on FooBarAbs. -type overwrittenMethodsOnFooBarAbs struct { - // Backlink to FooBarAbs so that the rest of the class can be used by the - // overridden methods. - fb FooBarAbs +// methods that overwrite the respective virtual C++ methods on FooBarAbstract. +type overwrittenMethodsOnFooBarAbstract struct { + // Backlink to FooBarAbstract so that the rest of the class can be used by + // the overridden methods. + fb FooBarAbstract // If additional constructor arguments have been given they are typically // stored here so that the overriden methods can use them. } -func (om *overwrittenMethodsOnFooBarAbs) Foo() string { - // DirectorFooBarAbsFoo calls the base method FooBarAbs::Foo. - return "Go " + DirectorFooBarAbsFoo(om.fb) +func (om *overwrittenMethodsOnFooBarAbstract) Foo() string { + // DirectorFooBarAbstractFoo calls the base method FooBarAbstract::Foo. + return "Go " + DirectorFooBarAbstractFoo(om.fb) } -func (om *overwrittenMethodsOnFooBarAbs) Bar() string { +func (om *overwrittenMethodsOnFooBarAbstract) Bar() string { return "Go Bar" } func NewFooBarGo() FooBarGo { - // Instantiate FooBarAbs with selected methods overridden. The methods that - // will be overwritten are defined on overwrittenMethodsOnFooBarAbs and have - // a compatible signature to the respective virtual C++ methods. - // Furthermore additional constructor arguments will be typically stored in - // the overwrittenMethodsOnFooBarAbs struct. - om := &overwrittenMethodsOnFooBarAbs{} - fb := NewDirectorFooBarAbs(om) + // Instantiate FooBarAbstract with selected methods overridden. The methods + // that will be overwritten are defined on + // overwrittenMethodsOnFooBarAbstract and have a compatible signature to the + // respective virtual C++ methods. Furthermore additional constructor + // arguments will be typically stored in the + // overwrittenMethodsOnFooBarAbstract struct. + om := &overwrittenMethodsOnFooBarAbstract{} + fb := NewDirectorFooBarAbstract(om) om.fb = fb // Backlink causes cycle as fb.v = om! - fbgs := &fooBarGo{FooBarAbs: fb} - // The memory of the FooBarAbs director object instance can be automatically - // freed once the FooBarGo instance is garbage collected by uncommenting the - // following line. Please make sure to understand the runtime.SetFinalizer - // specific gotchas before doing this. Furthemore DeleteFooBarGo should be - // deleted if a finalizer is in use or the fooBarGo struct needs additional - // data to prevent double deletion. - // runtime.SetFinalizer(fbgs, FooBarGo.deleteFooBarAbs) + fbgs := &fooBarGo{FooBarAbstract: fb} + // The memory of the FooBarAbstract director object instance can be + // automatically freed once the FooBarGo instance is garbage collected by + // uncommenting the following line. Please make sure to understand the + // runtime.SetFinalizer specific gotchas before doing this. Furthemore + // DeleteFooBarGo should be deleted if a finalizer is in use or the fooBarGo + // struct needs additional data to prevent double deletion. + // runtime.SetFinalizer(fbgs, FooBarGo.deleteFooBarAbstract) return fbgs } // Recommended to be removed if runtime.SetFinalizer is in use. func DeleteFooBarGo(fbg FooBarGo) { - fbg.deleteFooBarAbs() + fbg.deleteFooBarAbstract() } </pre> </div> @@ -1094,11 +1109,11 @@ For comparison the <tt>FooBarCpp</tt> class looks like this: <div class="code"> <pre> -class FooBarCpp : public FooBarAbs +class FooBarCpp : public FooBarAbstract { protected: virtual std::string Foo() { - return "C++ " + FooBarAbs::Foo(); + return "C++ " + FooBarAbstract::Foo(); } virtual std::string Bar() { diff --git a/Doc/Manual/Python.html b/Doc/Manual/Python.html index 57a2cd3ef..3af79e8d6 100644 --- a/Doc/Manual/Python.html +++ b/Doc/Manual/Python.html @@ -5273,8 +5273,8 @@ def function_name(*args, **kwargs): <p> Level "2" results in the function prototype as per level "0". In addition, a line of -documentation is generated for each parameter. Using the previous example, the generated -code will be: +documentation is generated for each parameter using <a href="https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt">numpydoc</a> style. +Using the previous example, the generated code will be: </p> <div class="targetlang"> @@ -5283,11 +5283,12 @@ def function_name(*args, **kwargs): """ function_name(x, y, foo=None, bar=None) -> bool - Parameters: - x: int - y: int - foo: Foo * - bar: Bar * + Parameters + ---------- + x: int + y: int + foo: Foo * + bar: Bar * """ ... @@ -5318,11 +5319,12 @@ def function_name(*args, **kwargs): """ function_name(x, y, foo=None, bar=None) -> bool - Parameters: - x (C++ type: int) -- Input x dimension - y: int - foo: Foo * - bar: Bar * + Parameters + ---------- + x (C++ type: int) -- Input x dimension + y: int + foo: Foo * + bar: Bar * """ </pre> @@ -5341,11 +5343,12 @@ def function_name(*args, **kwargs): """ function_name(int x, int y, Foo foo=None, Bar bar=None) -> bool - Parameters: - x: int - y: int - foo: Foo * - bar: Bar * + Parameters + ---------- + x: int + y: int + foo: Foo * + bar: Bar * """ ... diff --git a/Doc/Manual/Ruby.html b/Doc/Manual/Ruby.html index e78447b92..6590a133b 100644 --- a/Doc/Manual/Ruby.html +++ b/Doc/Manual/Ruby.html @@ -4818,7 +4818,7 @@ public: class Zoo { protected: - std::vector<animal *=""> animals; + std::vector<Animal *> animals; public: // Construct an empty zoo |