没有合适的资源?快使用搜索试试~ 我知道了~
首页"SWIG工具:C/C到Python、Tcl的接口详解"
"SWIG工具:C/C到Python、Tcl的接口详解"
需积分: 0 5 下载量 96 浏览量
更新于2023-12-17
收藏 4.6MB PDF 举报
SWIG工具是一种用于将C/C++代码转化为Python和Tcl接口的工具。它提供了一种快速、灵活和自动化的方法,使得开发人员可以轻松地将现有的C/C++代码集成到Python和Tcl等脚本语言环境中。
SWIG工具的核心文档是SWIG Core Documentation,它详细介绍了SWIG工具的使用方法和原理,以及如何进行接口定义和代码生成等操作。通过阅读这些文档,开发人员可以了解SWIG工具的基本用法,并学会如何将C/C++代码转化为Python和Tcl接口。
除了SWIG Core Documentation外,SWIG工具还提供了Supported Language Modules Documentation和Experimental Language Modules Documentation。Supported Language Modules Documentation提供了针对不同编程语言的SWIG模块的详细说明,包括Python和Tcl等常用脚本语言。Experimental Language Modules Documentation则介绍了实验性的SWIG模块,开发人员可以根据自己的需求选择合适的模块进行开发。
另外,SWIG工具还提供了Developer Documentation,这些文档主要面向SWIG工具的开发者,介绍了SWIG工具的内部结构和实现原理,以及如何进行SWIG工具的自定义扩展等操作。通过阅读这些文档,开发人员可以深入了解SWIG工具背后的技术细节,从而更好地使用和扩展SWIG工具。
SWIG工具的使用需要一些前置条件,比如安装相应的编译器和脚本语言解释器等。安装过程可以参考SWIG工具提供的安装文档,其中包括Windows和Unix系统下的安装方法。安装完成后,开发人员即可开始使用SWIG工具进行C/C++代码到Python和Tcl接口的转化。
SWIG工具具有良好的向后兼容性,不同版本之间的差异较小,因此开发人员可以放心升级和更新SWIG工具。每个版本的SWIG工具都有相应的发布说明和积分列表,开发人员可以在其中找到相关信息。
对于SWIG工具的使用过程中遇到的问题或者发现的bug,开发人员可以向SWIG工具的官方网站提交bug报告,以便工具的开发者及时解决问题。
通过以上内容的总结,我们可以了解到SWIG工具是一种用于将C/C++代码转化为Python和Tcl接口的快速、灵活且自动化的工具。它提供了详细的文档和资源,开发人员可以通过阅读这些文档了解SWIG工具的使用方法和原理,并按照文档中的指导进行操作。通过SWIG工具,开发人员可以高效地将现有的C/C++代码集成到Python和Tcl等脚本语言环境中,提高代码的可重用性和扩展性。同时,SWIG工具还提供了开发者文档,开发人员可以深入了解SWIG工具的内部结构和实现原理,从而更好地使用和扩展SWIG工具。总之,SWIG工具是一个强大而且方便的工具,对于C/C++代码与Python和Tcl等脚本语言的集成有着重要的作用。
executable, swig.exe, included in the top level directory. Otherwise it is exactly the same as the main SWIG distribution. There is no need to download anything else.
1.12.2 Unix installation
These installation instructions are for using the distributed tarball, for example, swig-3.0.8.tar.gz. If you wish to build and install from source on Github, extra steps are required. Please
see the Bleeding Edge page on the SWIG website.
You must use GNU make to build and install SWIG.
PCRE needs to be installed on your system to build SWIG, in particular pcre-config must be available. If you have PCRE headers and libraries but not pcre-config itself or, alternatively, wish to
override the compiler or linker flags returned by pcre-config, you may set PCRE_LIBS and PCRE_CFLAGS variables to be used instead. And if you don't have PCRE at all, the configure script
will provide instructions for obtaining it.
To build and install SWIG, simply type the following:
$ ./configure
$ make
$ make install
By default SWIG installs itself in /usr/local. If you need to install SWIG in a different location or in your home directory, use the --prefix option to ./configure. For example:
$ ./configure --prefix=/home/yourname/projects
$ make
$ make install
Note: the directory given to --prefix must be an absolute pathname. Do not use the ~ shell-escape to refer to your home directory. SWIG won't work properly if you do this.
The INSTALL file shipped in the top level directory details more about using configure. Also try
$ ./configure --help.
The configure script will attempt to locate various packages on your machine including Tcl, Perl5, Python and all the other target languages that SWIG supports. Don't panic if you get 'not
found' messages -- SWIG does not need these packages to compile or run. The configure script is actually looking for these packages so that you can try out the SWIG examples contained in
the 'Examples' directory without having to hack Makefiles. Note that the --without-xxx options, where xxx is a target language, have minimal effect. All they do is reduce the amount of
testing done with 'make check'. The SWIG executable and library files installed cannot currently be configured with a subset of target languages.
SWIG used to include a set of runtime libraries for some languages for working with multiple modules. These are no longer built during the installation stage. However, users can build them
just like any wrapper module as described in the Modules chapter. The CHANGES file shipped with SWIG in the top level directory also lists some examples which build the runtime library.
Note:
If you checked the code out via Git, you will have to run ./autogen.sh before ./configure. In addition, a full build of SWIG requires a number of packages to be installed. Full
instructions at SWIG bleeding edge.
1.12.3 Macintosh OS X installation
SWIG is known to work on various flavors of OS X. Follow the Unix installation instructions above. However, as of this writing, there is still great deal of inconsistency with how shared libraries
are handled by various scripting languages on OS X.
Users of OS X should be aware that Darwin handles shared libraries and linking in a radically different way than most Unix systems. In order to test SWIG and run the examples, SWIG
configures itself to use flat namespaces and to allow undefined symbols (-flat_namespace -undefined suppress). This mostly closely follows the Unix model and makes it more likely
that the SWIG examples will work with whatever installation of software you might have. However, this is generally not the recommended technique for building larger extension modules.
Instead, you should utilize Darwin's two-level namespaces. Some details about this can be found here Understanding Two-Level Namespaces.
Needless to say, you might have to experiment a bit to get things working at first.
1.12.4 Testing
If you want to test SWIG after building it, a check can be performed on Unix operating systems. Type the following:
$ make -k check
This step can be performed either before or after installation. The check requires at least one of the target languages to be installed. If it fails, it may mean that you have an uninstalled
language module or that the file 'Examples/Makefile' has been incorrectly configured. It may also fail due to compiler issues such as a broken C++ compiler. Even if the check fails, there is a
pretty good chance SWIG still works correctly --- you will just have to mess around with one of the examples and some makefiles to get it to work. Some tests may also fail due to missing
dependency packages, eg PCRE or Boost, but this will require careful analysis of the configure output done during configuration.
The test suite executed by the check is designed to stress-test many parts of the implementation including obscure corner cases. If some of these tests fail or generate warning messages,
there is no reason for alarm --- the test may be related to some new SWIG feature or a difficult bug that we're trying to resolve. Chances are that SWIG will work just fine for you. Note that if
you have more than one CPU/core, then you can use parallel make to speed up the check as it does take quite some time to run, for example:
$ make -j2 -k check
Also, SWIG's support for C++ is sufficiently advanced that certain tests may fail on older C++ compilers (for instance if your compiler does not support member templates). These errors are
harmless if you don't intend to use these features in your own programs.
Note: The test-suite currently contains over 600 tests. If you have many different target languages installed and a slow machine, it might take more than an hour to run the test-suite.
1.12.5 Examples
The Examples directory contains a variety of examples of using SWIG and it has some browsable documentation. Simply point your browser to the file "Example/index.html".
The Examples directory also includes Visual C++ project 6 (.dsp) files for building some of the examples on Windows. Later versions of Visual Studio will convert these old style project files
into a current solution file.
2 Introduction
What is SWIG?
Why use SWIG?
Target languages
Supported status
SWIG-4.0 Documentation
1.3 SWIG License 16
Experimental status
A SWIG example
SWIG interface file
The swig command
Building a Perl5 module
Building a Python module
Shortcuts
Supported C/C++ language features
Non-intrusive interface building
Incorporating SWIG into a build system
Hands off code generation
SWIG and freedom
2.1 What is SWIG?
SWIG is a software development tool that simplifies the task of interfacing different languages to C and C++ programs. In a nutshell, SWIG is a compiler that takes C/C++ declarations and
creates the wrappers needed to access those declarations from other languages including Perl, Python, Tcl, Ruby, Guile, and Java. SWIG normally requires no modifications to existing code
and can often be used to build a usable interface in only a few minutes. Possible applications of SWIG include:
Building interpreted interfaces to existing C programs.
Rapid prototyping and application development.
Interactive debugging.
Reengineering or refactoring of legacy software into scripting language components.
Making a graphical user interface (using Tk for example).
Testing of C libraries and programs (using scripts).
Building high performance C modules for scripting languages.
Making C programming more enjoyable (or tolerable depending on your point of view).
Impressing your friends.
Obtaining vast sums of research funding (although obviously not applicable to the author).
SWIG was originally designed to make it extremely easy for scientists and engineers to build extensible scientific software without having to get a degree in software engineering. Because of
this, the use of SWIG tends to be somewhat informal and ad-hoc (e.g., SWIG does not require users to provide formal interface specifications as you would find in a dedicated IDL compiler).
Although this style of development isn't appropriate for every project, it is particularly well suited to software development in the small; especially the research and development work that is
commonly found in scientific and engineering projects. However, nowadays SWIG is known to be used in many large open source and commercial projects.
2.2 Why use SWIG?
As stated in the previous section, the primary purpose of SWIG is to simplify the task of integrating C/C++ with other programming languages. However, why would anyone want to do that? To
answer that question, it is useful to list a few strengths of C/C++ programming:
Excellent support for writing programming libraries.
High performance (number crunching, data processing, graphics, etc.).
Systems programming and systems integration.
Large user community and software base.
Next, let's list a few problems with C/C++ programming
Writing a user interface is rather painful (i.e., consider programming with MFC, X11, GTK, or any number of other libraries).
Testing is time consuming (the compile/debug cycle).
Not easy to reconfigure or customize without recompilation.
Modularization can be tricky.
Security concerns (buffer overflows for instance).
To address these limitations, many programmers have arrived at the conclusion that it is much easier to use different programming languages for different tasks. For instance, writing a
graphical user interface may be significantly easier in a scripting language like Python or Tcl (consider the reasons why millions of programmers have used languages like Visual Basic if you
need more proof). An interactive interpreter might also serve as a useful debugging and testing tool. Other languages like Java might greatly simplify the task of writing distributed computing
software. The key point is that different programming languages offer different strengths and weaknesses. Moreover, it is extremely unlikely that any programming is ever going to be perfect.
Therefore, by combining languages together, you can utilize the best features of each language and greatly simplify certain aspects of software development.
From the standpoint of C/C++, a lot of people use SWIG because they want to break out of the traditional monolithic C programming model which usually results in programs that resemble
this:
A collection of functions and variables that do something useful.
A main() program that starts everything.
A horrible collection of hacks that form some kind of user interface (but which no-one really wants to touch).
Instead of going down that route, incorporating C/C++ into a higher level language often results in a more modular design, less code, better flexibility, and increased programmer productivity.
SWIG tries to make the problem of C/C++ integration as painless as possible. This allows you to focus on the underlying C program and using the high-level language interface, but not the
tedious and complex chore of making the two languages talk to each other. At the same time, SWIG recognizes that all applications are different. Therefore, it provides a wide variety of
customization features that let you change almost every aspect of the language bindings. This is the main reason why SWIG has such a large user manual ;-).
2.3 Target languages
SWIG in essence is a tool to generate code for making C/C++ code available to various other programming languages. These higher level programming languages are the target languages for
the SWIG code generator and C or C++ are the input languages. A single target language must be specified when SWIG is run. This results in generating code for C/C++ and the specified
target language to interface with each other. SWIG can be invoked multiple times, but with a different target language specified on each invocation. This ability to interface C/C++ to many
different target languages is one of SWIG's core strengths and features.
SWIG is very broadly composed of two components. A core component creates a parse tree from the input ISO C/C++ and SWIG directives (extensions to the C/C++ standards). The parse
tree is then passed to a second component, one of the target language modules for generating code specific to a higher level language. SWIG supports many different target languages.
These target languages are given a status of either Supported or Experimental. This status is provided to indicate the level of maturity to expect when using a particular target language as not
all target languages are fully developed.
The second part of the SWIG documentation contains a chapter for each target level language. Each chapter will state the status (Supported or Experimental) for that language.
2.3.1 Supported status
A target language is given the 'Supported' status when
It is in a mature, well functioning state.
It has its own comprehensive chapter in the documentation.
It passes all of the main SWIG test-suite and has a range of working examples.
It supports the vast majority of SWIG features.
It provides strong backwards compatibility between releases.
The above is a short summary and further details are outlined in the Supported status section in the Extending chapter. The good news is that all the well-known and most popular languages
have this status.
2.3.2 Experimental status
SWIG-4.0 Documentation
2.1 What is SWIG? 17
A target language is given the 'Experimental' status when
It is of sub-standard quality, failing to meet the above 'Supported' status.
It is somewhere between the mid to mature stage of development.
It does not guarantee any backwards compatibility between releases.
It is in need of help to finish development.
Anyone using an experimental target language is strongly urged to assist with development of the target language module if they wish to use it.
SWIG displays a warning when an experimental target language is used in order to set expectations and emphasize the experimental status of the target language. The usual warning
suppression techniques can be used if required.
The above is a short summary and further details are outlined in the Experimental status section in the Extending chapter.
2.4 A SWIG example
The best way to illustrate SWIG is with a simple example. Consider the following C code:
/* File : example.c */
double My_variable = 3.0;
/* Compute factorial of n */
int fact(int n) {
if (n <= 1)
return 1;
else
return n*fact(n-1);
}
/* Compute n mod m */
int my_mod(int n, int m) {
return(n % m);
}
Suppose that you wanted to access these functions and the global variable My_variable from Tcl. You start by making a SWIG interface file as shown below (by convention, these files carry
a .i suffix) :
2.4.1 SWIG interface file
/* File : example.i */
%module example
%{
/* Put headers and other declarations here */
extern double My_variable;
extern int fact(int);
extern int my_mod(int n, int m);
%}
extern double My_variable;
extern int fact(int);
extern int my_mod(int n, int m);
The interface file contains ISO C function prototypes and variable declarations. The %module directive defines the name of the module that will be created by SWIG. The %{ %} block provides
a location for inserting additional code, such as C header files or additional C declarations, into the generated C wrapper code.
2.4.2 The swig command
SWIG is invoked using the swig command. We can use this to build a Tcl module (under Linux) as follows :
unix > swig -tcl example.i
unix > gcc -c -fpic example.c example_wrap.c -I/usr/local/include
unix > gcc -shared example.o example_wrap.o -o example.so
unix > tclsh
% load ./example.so
% fact 4
24
% my_mod 23 7
2
% expr $My_variable + 4.5
7.5
%
The swig command produced a new file called example_wrap.c that should be compiled along with the example.c file. Most operating systems and scripting languages now support
dynamic loading of modules. In our example, our Tcl module has been compiled into a shared library that can be loaded into Tcl. When loaded, Tcl can now access the functions and variables
declared in the SWIG interface. A look at the file example_wrap.c reveals a hideous mess. However, you almost never need to worry about it.
2.4.3 Building a Perl5 module
Now, let's turn these functions into a Perl5 module. Without making any changes type the following (shown for Solaris):
unix > swig -perl5 example.i
unix > gcc -c example.c example_wrap.c \
-I/usr/local/lib/perl5/sun4-solaris/5.003/CORE
unix > ld -G example.o example_wrap.o -o example.so # This is for Solaris
unix > perl5.003
use example;
print example::fact(4), "\n";
print example::my_mod(23, 7), "\n";
print $example::My_variable + 4.5, "\n";
<ctrl-d>
24
2
7.5
unix >
SWIG-4.0 Documentation
2.4 A SWIG example 18
2.4.4 Building a Python module
Finally, let's build a module for Python (shown for Irix).
unix > swig -python example.i
unix > gcc -c -fpic example.c example_wrap.c -I/usr/local/include/python2.0
unix > gcc -shared example.o example_wrap.o -o _example.so
unix > python
Python 2.0 (#6, Feb 21 2001, 13:29:45)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import example
>>> example.fact(4)
24
>>> example.my_mod(23, 7)
2
>>> example.cvar.My_variable + 4.5
7.5
2.4.5 Shortcuts
To the truly lazy programmer, one may wonder why we needed the extra interface file at all. As it turns out, you can often do without it. For example, you could also build a Perl5 module by just
running SWIG on the C header file and specifying a module name as follows
unix > swig -perl5 -module example example.h
unix > gcc -c example.c example_wrap.c \
-I/usr/local/lib/perl5/sun4-solaris/5.003/CORE
unix > ld -G example.o example_wrap.o -o example.so
unix > perl5.003
use example;
print example::fact(4), "\n";
print example::my_mod(23, 7), "\n";
print $example::My_variable + 4.5, "\n";
<ctrl-d>
24
2
7.5
2.5 Supported C/C++ language features
A primary goal of the SWIG project is to make the language binding process extremely easy. Although a few simple examples have been shown, SWIG is quite capable in supporting most of
C++. Some of the major features include:
Full C99 preprocessing.
All ISO C and C++ datatypes.
Functions, variables, and constants.
Classes.
Single and multiple inheritance.
Overloaded functions and methods.
Overloaded operators.
C++ templates (including member templates, specialization, and partial specialization).
Namespaces.
Variable length arguments.
C++ smart pointers.
Most of C++11 is also supported. Details are in the C++11 chapter. C++14 support is covered in the C++14 chapter. C++17 support is covered in the C++17 chapter.
It is important to stress that SWIG is not a simplistic C++ lexing tool like several apparently similar wrapper generation tools. SWIG not only parses C++, it implements the full C++ type system
and it is able to understand C++ semantics. SWIG generates its wrappers with full knowledge of this information. As a result, you will find SWIG to be just as capable of dealing with nasty
corner cases as it is in wrapping simple C++ code. In fact, SWIG is able to handle C++ code that stresses the very limits of many C++ compilers.
2.6 Non-intrusive interface building
When used as intended, SWIG requires minimal (if any) modification to existing C or C++ code. This makes SWIG extremely easy to use with existing packages and promotes software reuse
and modularity. By making the C/C++ code independent of the high level interface, you can change the interface and reuse the code in other applications. It is also possible to support different
types of interfaces depending on the application.
2.7 Incorporating SWIG into a build system
SWIG is a command line tool and as such can be incorporated into any build system that supports invoking external tools/compilers. SWIG is most commonly invoked from within a Makefile,
but is also known to be invoked from popular IDEs such as Microsoft Visual Studio.
If you are using the GNU Autotools ( Autoconf/ Automake / Libtool) to configure SWIG use in your project, the SWIG Autoconf macros can be used. The primary macro is ax_pkg_swig, see
http://www.gnu.org/software/autoconf-archive/ax_pkg_swig.html#ax_pkg_swig . The ax_python_devel macro is also helpful for generating Python extensions. See the Autoconf Archive for
further information on this and other Autoconf macros.
There is growing support for SWIG in some build tools, for example CMake is a cross-platform, open-source build manager with built in support for SWIG. CMake can detect the SWIG
executable and many of the target language libraries for linking against. CMake knows how to build shared libraries and loadable modules on many different operating systems. This allows
easy cross platform SWIG development. It can also generate the custom commands necessary for driving SWIG from IDEs and makefiles. All of this can be done from a single cross platform
input file. The following example is a CMake input file for creating a Python wrapper for the SWIG interface file, example.i:
# This is a CMake example for Python
FIND_PACKAGE(SWIG REQUIRED)
INCLUDE(${SWIG_USE_FILE})
FIND_PACKAGE(PythonLibs)
INCLUDE_DIRECTORIES(${PYTHON_INCLUDE_PATH})
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR})
SET(CMAKE_SWIG_FLAGS "")
SWIG-4.0 Documentation
2.5 Supported C/C++ language features 19
SET_SOURCE_FILES_PROPERTIES(example.i PROPERTIES CPLUSPLUS ON)
SET_SOURCE_FILES_PROPERTIES(example.i PROPERTIES SWIG_FLAGS "-includeall")
SWIG_ADD_MODULE(example python example.i example.cxx)
SWIG_LINK_LIBRARIES(example ${PYTHON_LIBRARIES})
The above example will generate native build files such as makefiles, nmake files and Visual Studio projects which will invoke SWIG and compile the generated C++ files into _example.so
(UNIX) or _example.pyd (Windows). For other target languages on Windows a dll, instead of a .pyd file, is usually generated.
2.8 Hands off code generation
SWIG is designed to produce working code that needs no hand-modification (in fact, if you look at the output, you probably won't want to modify it). You should think of your target language
interface being defined entirely by the input to SWIG, not the resulting output file. While this approach may limit flexibility for hard-core hackers, it allows others to forget about the low-level
implementation details.
2.9 SWIG and freedom
No, this isn't a special section on the sorry state of world politics. However, it may be useful to know that SWIG was written with a certain "philosophy" about programming---namely that
programmers are smart and that tools should just stay out of their way. Because of that, you will find that SWIG is extremely permissive in what it lets you get away with. In fact, you can use
SWIG to go well beyond "shooting yourself in the foot" if dangerous programming is your goal. On the other hand, this kind of freedom may be exactly what is needed to work with complicated
and unusual C/C++ applications.
Ironically, the freedom that SWIG provides is countered by an extremely conservative approach to code generation. At its core, SWIG tries to distill even the most advanced C++ code down to
a small well-defined set of interface building techniques based on ISO C programming. Because of this, you will find that SWIG interfaces can be easily compiled by virtually every C/C++
compiler and that they can be used on any platform. Again, this is an important part of staying out of the programmer's way----the last thing any developer wants to do is to spend their time
debugging the output of a tool that relies on non-portable or unreliable programming features. Dependencies are often a source of incompatibilities and problems and so additional third party
libraries are not used in the generated code. SWIG will also generally avoid generating code that introduces a dependency on the C++ Standard Template Library (STL). SWIG will generate
code that depends on the C libraries though.
3 Getting started on Windows
Installation on Windows
Windows Executable
SWIG Windows Examples
Instructions for using the Examples with Visual Studio
C#
Java
Perl
Python
TCL
R
Ruby
Instructions for using the Examples with other compilers
SWIG on Cygwin and MinGW
Building swig.exe on Windows
Building swig.exe using MinGW and MSYS
Building swig.exe using Cygwin
Building swig.exe alternatives
Running the examples on Windows using Cygwin
Microsoft extensions and other Windows quirks
This chapter describes SWIG usage on Microsoft Windows. Installing SWIG and running the examples is covered as well as building the SWIG executable. Usage within the Unix like
environments MinGW and Cygwin is also detailed.
3.1 Installation on Windows
SWIG does not come with the usual Windows type installation program, however it is quite easy to get started. The main steps are:
Download the swigwin zip package from the SWIG website and unzip into a directory. This is all that needs downloading for the Windows platform.
Set environment variables as described in the SWIG Windows Examples section in order to run examples using Visual C++.
3.1.1 Windows Executable
The swigwin distribution contains the SWIG Windows 32-bit executable, swig.exe, which will run on both 32-bit and 64-bit versions of Windows. If you want to build your own swig.exe have a
look at Building swig.exe on Windows.
3.2 SWIG Windows Examples
Using Microsoft Visual C++ is the most common approach to compiling and linking SWIG's output. The Examples directory has a few Visual C++ project files (.dsp files). These were produced
by Visual C++ 6. Newer versions of Visual Studio should be able to open and convert these project files. Each C# example comes with a Visual Studio 2005 solution and associated project
files instead of Visual C++ 6 project files. The project files have been set up to execute SWIG in a custom build rule for the SWIG interface (.i) file. Alternatively run the examples using Cygwin.
More information on each of the examples is available with the examples distributed with SWIG (Examples/index.html).
3.2.1 Instructions for using the Examples with Visual Studio
Ensure the SWIG executable is as supplied in the SWIG root directory in order for the examples to work. Most languages require some environment variables to be set before running Visual
C++. Note that Visual C++ must be re-started to pick up any changes in environment variables. Open up an example .dsp file, Visual C++ will create a workspace for you (.dsw file). Ensure the
Release build is selected then do a Rebuild All from the Build menu. The required environment variables are displayed with their current values.
The list of required environment variables for each module language is also listed below. They are usually set from the Control Panel and System properties, but this depends on which flavour
of Windows you are running. If you don't want to use environment variables then change all occurrences of the environment variables in the .dsp files with hard coded values. If you are
interested in how the project files are set up there is explanatory information in some of the language module's documentation.
3.2.1.1 C#
The C# examples do not require any environment variables to be set as a C# project file is included. Just open up the .sln solution file in Visual Studio .NET 2003 or later, select Release Build,
and do a Rebuild All from the Build menu. The accompanying C# and C++ project files are automatically used by the solution file.
3.2.1.2 Java
JAVA_INCLUDE : Set this to the directory containing jni.h
SWIG-4.0 Documentation
2.8 Hands off code generation 20
剩余504页未读,继续阅读
2014-04-01 上传
2020-09-26 上传
点击了解资源详情
2019-12-27 上传
2011-09-29 上传
点击了解资源详情
乐乐bravo
- 粉丝: 0
- 资源: 1
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- 人工智能基础实验.zip
- chkcfg-开源
- Amaterasu Tool-开源
- twitter-application-only-auth:Twitter仅限应用程序身份验证的简单Python实现。
- 第一个项目:shoppingmall
- webpage-test
- JTextComponent.rar_Applet_Java_
- 人工智能原理课程实验1,numpy实现Lenet5,im2col方法实现的.zip
- PyPI 官网下载 | vittles-0.17-py3-none-any.whl
- Real-World-JavaScript-Pro-Level-Techniques-for-Entry-Level-Developers-V-:实际JavaScript的代码存储库
- Sitecore.Support.96670:修补程序解决了以下问题:选中“相关项目”复选框时,并非所有子项目都会发布,
- BioGRID-PPI:生物二进制PPI数据集和BioGRID的处理
- ownership-status:所有权状态页
- DMXOPL:用于末日和源端口的YMF262增强的FM补丁集
- VideoCapture.rar_视频捕捉/采集_Visual_C++_
- trd_mc:一个简单的蒙特卡洛TPX响应仿真引擎。专为ROOT互动模式
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功