diff options
Diffstat (limited to 'Doc/Manual/SWIG.html')
| -rw-r--r-- | Doc/Manual/SWIG.html | 40 |
1 files changed, 20 insertions, 20 deletions
diff --git a/Doc/Manual/SWIG.html b/Doc/Manual/SWIG.html index c0cde0172..bd929f7d4 100644 --- a/Doc/Manual/SWIG.html +++ b/Doc/Manual/SWIG.html @@ -224,7 +224,7 @@ $ swig -c++ -python -o example_wrap.cpp example.i <p> The C/C++ output file created by SWIG often -contains everything that is needed to construct a extension module +contains everything that is needed to construct an extension module for the target scripting language. SWIG is not a stub compiler nor is it usually necessary to edit the output file (and if you look at the output, you probably won't want to). To build the final extension module, the @@ -233,7 +233,7 @@ program to create a shared library. </p> <p> -Many target languages will also generate proxy class files in the +For many target languages SWIG will also generate proxy class files in the target language. The default output directory for these language specific files is the same directory as the generated C/C++ file. This can be modified using the <tt>-outdir</tt> option. For example: @@ -484,7 +484,7 @@ Or in Python: Whenever possible, SWIG creates an interface that closely matches the underlying C/C++ code. However, due to subtle differences between languages, run-time environments, and semantics, it is not always possible to do so. The -next few sections describes various aspects of this mapping. +next few sections describe various aspects of this mapping. </p> <H3><a name="SWIG_nn10"></a>5.2.1 Basic Type Handling</H3> @@ -728,7 +728,7 @@ However, for the same conservative reasons even a constant with a simple cast wi <div class="code"> <pre> -#define F_CONST (double) 5 // A floating pointer constant with cast +#define F_CONST (double) 5 // A floating point constant with cast </pre> </div> @@ -750,7 +750,7 @@ enum values as assigned by the C compiler. <p> The <tt>%constant</tt> directive is used to more precisely create constants corresponding to different C datatypes. Although it is not -usually not needed for simple values, it is more useful when working +usually needed for simple values, it is more useful when working with pointers and other more complex datatypes. Typically, <tt>%constant</tt> is only used when you want to add constants to the scripting language interface that are not defined in the original header file. @@ -868,7 +868,7 @@ from a scripting language to a C <tt>char *</tt>, the pointer usually points to string data stored inside the interpreter. It is almost always a really bad idea to modify this data. Furthermore, some languages may explicitly disallow it. For instance, in Python, -strings are supposed be immutable. If you violate this, you will probably +strings are supposed to be immutable. If you violate this, you will probably receive a vast amount of wrath when you unleash your module on the world. </p> @@ -1483,7 +1483,7 @@ void transpose(double (*a)[20]); <p> Like C, SWIG does not perform array bounds checking. It is up to the -user to make sure the pointer points a suitably allocated region of memory. +user to make sure the pointer points to a suitably allocated region of memory. </p> <p> @@ -2265,7 +2265,7 @@ disabled using <tt>%nocallback</tt>. When you do this, the interface now works <p> Notice that when the function is used as a callback, special names -such as <tt>add_cb</tt> is used instead. To call the function +such as <tt>add_cb</tt> are used instead. To call the function normally, just use the original function name such as <tt>add()</tt>. </p> @@ -2311,7 +2311,7 @@ handle C++ are described in the next section. If SWIG encounters the definition of a structure or union, it creates a set of accessor functions. Although SWIG does not need structure definitions to build an interface, providing definitions -make it possible to access structure members. The accessor functions +makes it possible to access structure members. The accessor functions generated by SWIG simply take a pointer to an object and allow access to an individual member. For example, the declaration :</p> @@ -2434,7 +2434,7 @@ vector_struct</tt>, SWIG knows that this is the same as Structures involving character strings require some care. SWIG assumes that all members of type <tt>char *</tt> have been dynamically allocated using <tt>malloc()</tt> and that they are NULL-terminated -ASCII strings. When such a member is modified, the previously contents +ASCII strings. When such a member is modified, the previous contents will be released, and the new contents allocated. For example :</p> <div class="code"><pre> @@ -2519,7 +2519,7 @@ typedef struct Bar { <p> When a structure member is wrapped, it is handled as a pointer, unless the <tt>%naturalvar</tt> directive is used where it is handled more like a C++ reference (see <a href="SWIGPlus.html#SWIGPlus_member_data">C++ Member data</a>). -The accessors to the member variable as a pointer is effectively wrapped as follows: +The accessors to the member variable as a pointer are effectively wrapped as follows: </p> <div class="code"> @@ -2656,8 +2656,8 @@ struct Bar { // Default constructor generated. <p> -Since ignoring the implicit or default destructors most of the times -produce memory leaks, SWIG will always try to generate them. If +Since ignoring the implicit or default destructors most of the time +produces memory leaks, SWIG will always try to generate them. If needed, however, you can selectively disable the generation of the default/implicit destructor by using <tt>%nodefaultdtor</tt> </p> @@ -2687,7 +2687,7 @@ has now been enabled as the default behavior. <b>Note:</b> There are also the <tt>-nodefault</tt> option and <tt>%nodefault</tt> directive, which disable both the default or implicit destructor generation. This could lead to memory leaks across -the target languages, and is highly recommended you don't use them. +the target languages, and it is highly recommended you don't use them. </p> @@ -3280,7 +3280,7 @@ initialization on module loading, you could write this: <p> -This section describes the general approach for building interface +This section describes the general approach for building interfaces with SWIG. The specifics related to a particular scripting language are found in later chapters.</p> @@ -3295,9 +3295,9 @@ of steps you can follow to make an interface for a C program :</p> <ul> <li>Identify the functions that you want to wrap. It's probably not -necessary to access every single function in a C program--thus, a +necessary to access every single function of a C program--thus, a little forethought can dramatically simplify the resulting scripting -language interface. C header files are particularly good source for +language interface. C header files are a particularly good source for finding things to wrap. <li>Create a new interface file to describe the scripting language @@ -3342,7 +3342,7 @@ to the <a href="http://www.swig.org/mail.html">swig-devel mailing list</a> or to <p> -The preferred method of using SWIG is to generate separate interface +The preferred method of using SWIG is to generate a separate interface file. Suppose you have the following C header file :</p> <div class="code"><pre> @@ -3436,7 +3436,7 @@ include certain header files by using a <tt>%{,%}</tt> block like this: #include <GL/glu.h> %} -// Put rest of declarations here +// Put the rest of the declarations here ... </pre></div> @@ -3478,7 +3478,7 @@ program that is more interactive. In many cases, the old or Tcl script.</p> <p> -<b>Note:</b> If some cases, you might be inclined to create a +<b>Note:</b> In some cases, you might be inclined to create a scripting language wrapper for <tt>main()</tt>. If you do this, the compilation will probably work and your module might even load correctly. The only trouble is that when you call your |