Merged revisions 10487,10498-10499,10503-10504,10506,10508,10511,10515-10516,10518-10519,10527,10530-10531,10536-10537,10539-10552,10558-10568,10574-10580,10582,10584,10588-10589,10594,10607-10610,10616,10621,10624-10629,10633-10641,10643,10647,10649-10650,10662,10672,10676-10677,10682-10683,10714,10726-10727,10738,10743,10747,10749,10794,10801-10809,10827-10831,10834 via svnmerge from
https://swig.svn.sourceforge.net/svnroot/swig/trunk ................ r10487 | wsfulton | 2008-05-21 23:15:52 +0100 (Wed, 21 May 2008) | 1 line Apply patch from Petr Viktorin to fix some recent regressions in CFFI/CLOS ................ r10498 | talby | 2008-05-26 21:09:56 +0100 (Mon, 26 May 2008) | 2 lines run test cases in the Perl set by the --with-perl5 configure option. ................ r10499 | talby | 2008-05-26 22:04:06 +0100 (Mon, 26 May 2008) | 3 lines The perl5 minherit runtime test will work better if the classes are actually built under SWIGPERL. ................ r10503 | wsfulton | 2008-05-28 10:44:37 +0100 (Wed, 28 May 2008) | 1 line Fix variable wrappers when using -proxy. Patch from Jan Jezabek ................ r10504 | bhy | 2008-05-28 18:27:48 +0100 (Wed, 28 May 2008) | 2 lines Fixed SF #1971977: typo in pycontainer.swg (related to -extranative option) ................ r10506 | wsfulton | 2008-05-29 01:45:28 +0100 (Thu, 29 May 2008) | 1 line Fix variable wrappers when using -noproxy ................ r10508 | bhy | 2008-05-30 14:53:33 +0100 (Fri, 30 May 2008) | 1 line Fixed SF #1976978, apply the macros for primitive types to std::wstring ................ r10511 | olly | 2008-05-30 17:11:27 +0100 (Fri, 30 May 2008) | 4 lines Fix typo in handling of /*@SWIG[...]*/ comments in the scanner. This just meant we were only actually looking for /*@SWI at the start of the comment, so was pretty harmless in practice. ................ r10515 | wsfulton | 2008-06-02 21:10:40 +0100 (Mon, 02 Jun 2008) | 1 line Fix samename testcase for c# and java ................ r10516 | wsfulton | 2008-06-02 21:15:39 +0100 (Mon, 02 Jun 2008) | 1 line Fix enums when using -noproxy ................ r10518 | bhy | 2008-06-07 12:20:07 +0100 (Sat, 07 Jun 2008) | 4 lines Added a test case for keyword renaming. Now it works for Python in SWIG's -c++ mode, but in C mode it doesn't work! (you can try with make keyword_rename.ctest) ................ r10519 | bhy | 2008-06-07 14:40:51 +0100 (Sat, 07 Jun 2008) | 1 line fixed keyword_rename.ctest tese case, caused by a mistake in Swig/naming.c ................ r10527 | mgossage | 2008-06-17 03:57:15 +0100 (Tue, 17 Jun 2008) | 1 line [lua] bugfix 1938142 (bool& and bool* support) ................ r10530 | wsfulton | 2008-06-19 21:02:13 +0100 (Thu, 19 Jun 2008) | 1 line Add R keyword support. Rename keywords for successful compilation of Java and C# code. More consistent keyword warnings across the different languages. ................ r10531 | wsfulton | 2008-06-19 22:15:48 +0100 (Thu, 19 Jun 2008) | 1 line add complete list of R reserved words ................ r10536 | wsfulton | 2008-06-21 12:35:33 +0100 (Sat, 21 Jun 2008) | 1 line better terminology for static types ................ r10537 | wsfulton | 2008-06-21 12:42:48 +0100 (Sat, 21 Jun 2008) | 1 line remove raise as keyword test- it conflicts with _raise in LIBCMT on windows ................ r10539 | wsfulton | 2008-06-21 16:21:29 +0100 (Sat, 21 Jun 2008) | 1 line Lua example warning removal fixes for vc++ ................ r10540 | wsfulton | 2008-06-21 16:23:02 +0100 (Sat, 21 Jun 2008) | 1 line Remove some vc++ /W4 warnings ................ r10541 | wsfulton | 2008-06-21 17:04:55 +0100 (Sat, 21 Jun 2008) | 1 line minor vc++ /W4 warning fixes ................ r10542 | wsfulton | 2008-06-21 20:07:51 +0100 (Sat, 21 Jun 2008) | 1 line 'byte' is already used in Ruby on windows, so use another keyword ................ r10543 | wsfulton | 2008-06-21 21:45:32 +0100 (Sat, 21 Jun 2008) | 1 line Fix crashing in the Ruby reject method in the STL wrappers ................ r10544 | wsfulton | 2008-06-21 21:48:28 +0100 (Sat, 21 Jun 2008) | 1 line Fix crashing in the Ruby reject method in the STL wrappers ................ r10545 | wsfulton | 2008-06-21 21:49:10 +0100 (Sat, 21 Jun 2008) | 1 line remove unnecessary variable int the char **STRING_ARRAY out typemap ................ r10546 | wsfulton | 2008-06-21 22:07:49 +0100 (Sat, 21 Jun 2008) | 1 line Fix Ruby C++ example dependencies in dsp files ................ r10547 | wsfulton | 2008-06-21 23:25:36 +0100 (Sat, 21 Jun 2008) | 1 line Fix unused parameter warnings in python when using gcc's -W -Wall options ................ r10548 | wsfulton | 2008-06-21 23:26:35 +0100 (Sat, 21 Jun 2008) | 1 line Fix virtual destructor ................ r10549 | wsfulton | 2008-06-22 00:25:20 +0100 (Sun, 22 Jun 2008) | 1 line various warning fixes ................ r10550 | wsfulton | 2008-06-22 01:09:11 +0100 (Sun, 22 Jun 2008) | 1 line Another fix for the JVM hanging on exit problem when using directors ................ r10551 | wsfulton | 2008-06-22 01:09:51 +0100 (Sun, 22 Jun 2008) | 1 line documentation sections update ................ r10552 | wsfulton | 2008-06-22 01:18:10 +0100 (Sun, 22 Jun 2008) | 1 line more docs on defining macros for the thread hanging problem ................ r10558 | wsfulton | 2008-06-22 22:30:20 +0100 (Sun, 22 Jun 2008) | 1 line fix unused parms in last commit for C code ................ r10559 | wsfulton | 2008-06-22 23:12:43 +0100 (Sun, 22 Jun 2008) | 1 line Suppress unused methods warning for VC++ ................ r10560 | wsfulton | 2008-06-23 21:26:07 +0100 (Mon, 23 Jun 2008) | 1 line fix partialcheck-test-suite and parallel make for r, chicken, tcl and php ................ r10561 | wsfulton | 2008-06-23 21:39:41 +0100 (Mon, 23 Jun 2008) | 1 line correct message display when running the partialcheck-test-suite make target ................ r10562 | wsfulton | 2008-06-23 22:14:53 +0100 (Mon, 23 Jun 2008) | 1 line fix typo ................ r10563 | olly | 2008-06-23 22:23:54 +0100 (Mon, 23 Jun 2008) | 3 lines Fix bad use of Python API (untested, since I can't even compile this code on x86-64!) ................ r10564 | olly | 2008-06-23 23:58:03 +0100 (Mon, 23 Jun 2008) | 3 lines [PHP] Fix segfault when wrapping a non-class function marked with %newobject (testcase char_strings). ................ r10565 | olly | 2008-06-24 01:27:34 +0100 (Tue, 24 Jun 2008) | 3 lines [PHP] Fix assertion failure when handling %typemap(in,numinputs=0) (testcase ignore_parameter). ................ r10566 | olly | 2008-06-24 01:33:08 +0100 (Tue, 24 Jun 2008) | 2 lines [PHP] Fix typemap_namespace.i to not try to copy a non-existent typemap. ................ r10567 | olly | 2008-06-24 01:41:07 +0100 (Tue, 24 Jun 2008) | 3 lines Clean up dead and unused code in SwigToPhpType(), and rename to GetShadowReturnType(). ................ r10568 | olly | 2008-06-24 01:42:29 +0100 (Tue, 24 Jun 2008) | 2 lines Fix cosmetic typo in string constant. ................ r10574 | wsfulton | 2008-06-24 21:10:28 +0100 (Tue, 24 Jun 2008) | 1 line zap last entry ................ r10575 | wsfulton | 2008-06-24 21:11:46 +0100 (Tue, 24 Jun 2008) | 1 line variable name changes to remove php keywords ................ r10576 | wsfulton | 2008-06-24 21:12:08 +0100 (Tue, 24 Jun 2008) | 1 line variable name hiding fix ................ r10577 | wsfulton | 2008-06-24 21:12:43 +0100 (Tue, 24 Jun 2008) | 1 line More info about numobjects added ................ r10578 | wsfulton | 2008-06-24 21:13:41 +0100 (Tue, 24 Jun 2008) | 1 line update for 1.3.36 release ................ r10579 | wsfulton | 2008-06-24 22:48:46 +0100 (Tue, 24 Jun 2008) | 1 line remove deprecated -c commandline option (runtime library generation) ................ r10580 | wsfulton | 2008-06-24 22:53:12 +0100 (Tue, 24 Jun 2008) | 1 line correct comment about deprecated option ................ r10582 | wsfulton | 2008-06-25 00:00:27 +0100 (Wed, 25 Jun 2008) | 1 line use rsync and ssh to upload releases to SourceForge as ftp no longer works ................ r10584 | wsfulton | 2008-06-25 00:24:48 +0100 (Wed, 25 Jun 2008) | 1 line correction for 1.3.36 ................ r10588 | wsfulton | 2008-06-25 01:16:04 +0100 (Wed, 25 Jun 2008) | 1 line section update ................ r10589 | wsfulton | 2008-06-25 01:16:40 +0100 (Wed, 25 Jun 2008) | 1 line bump version to 1.3.37 ................ r10594 | wsfulton | 2008-06-26 19:33:06 +0100 (Thu, 26 Jun 2008) | 1 line correct typo in first entry about %fragment ................ r10607 | wsfulton | 2008-06-29 01:19:05 +0100 (Sun, 29 Jun 2008) | 1 line fix some potential null pointer usage as reported by CoveriCoverity Prevent ................ r10608 | wsfulton | 2008-06-29 01:50:27 +0100 (Sun, 29 Jun 2008) | 1 line fix potential null pointer usage as reported by Coverity Prevent ................ r10609 | wsfulton | 2008-06-29 10:57:41 +0100 (Sun, 29 Jun 2008) | 1 line make life easier for svn status updates as everyone has different autotool versions installed - use svn:ignore on config.sub and config.guess ................ r10610 | wsfulton | 2008-06-29 11:08:14 +0100 (Sun, 29 Jun 2008) | 1 line make life easier for svn status updates as everyone has different autotool versions installed - use svn:ignore on config.sub and config.guess ................ r10616 | talby | 2008-07-01 00:41:27 +0100 (Tue, 01 Jul 2008) | 2 lines Hopefully this provides more portable values for Infinity and NaN in Perl. ................ r10621 | wsfulton | 2008-07-01 23:02:14 +0100 (Tue, 01 Jul 2008) | 1 line update old commandline option ................ r10624 | olly | 2008-07-02 04:17:46 +0100 (Wed, 02 Jul 2008) | 5 lines [Python] Import the C extension differently for Python 2.6 and later so that an implicit relative import doesn't produce a deprecation warning for 2.6 and a failure for 2.7 and later. Patch from Richard Boulton in SF#2008229. ................ r10625 | bhy | 2008-07-02 05:56:11 +0100 (Wed, 02 Jul 2008) | 1 line fix the relative import patch by try both relative and absolute import ................ r10626 | olly | 2008-07-02 06:55:18 +0100 (Wed, 02 Jul 2008) | 4 lines [PHP4] Support for PHP4 has been removed. The PHP developers are no longer making new PHP4 releases, and won't even be patching critical security issues after 2008-08-08. ................ r10627 | bhy | 2008-07-02 07:06:56 +0100 (Wed, 02 Jul 2008) | 1 line fix the previous commit -- new approach using imp module ................ r10628 | bhy | 2008-07-02 07:29:15 +0100 (Wed, 02 Jul 2008) | 1 line minor fix on relative import: close fp if exception occured during imp.find_module ................ r10629 | bhy | 2008-07-02 08:08:00 +0100 (Wed, 02 Jul 2008) | 1 line reconstruct the relative import, now the generated code looks better ................ r10633 | olly | 2008-07-03 01:09:56 +0100 (Thu, 03 Jul 2008) | 9 lines WARN_* constants are user visible, so keep existing WARN_PHP4_* for backward compatibility, but add preferred forms WARN_PHP_* and use these ourselves. Rename Lib/php4 to Lib/php, Source/Modules/php4.cxx to Source/Modules/php.cxx. Add typemaps for const reference so Examples/test-suite/apply_signed_char.i works. ................ r10634 | olly | 2008-07-03 01:12:58 +0100 (Thu, 03 Jul 2008) | 2 lines Remove file added in error. ................ r10635 | olly | 2008-07-03 01:37:38 +0100 (Thu, 03 Jul 2008) | 2 lines Rename php4*.swg to php*.swg. ................ r10636 | olly | 2008-07-03 02:13:51 +0100 (Thu, 03 Jul 2008) | 2 lines Update wrt PHP4. ................ r10637 | olly | 2008-07-03 03:32:11 +0100 (Thu, 03 Jul 2008) | 4 lines [PHP] The deprecated command line option "-phpfull" has been removed. We recommend building your extension as a dynamically loadable module. ................ r10638 | olly | 2008-07-03 03:32:41 +0100 (Thu, 03 Jul 2008) | 2 lines Fix version number ................ r10639 | olly | 2008-07-03 07:04:24 +0100 (Thu, 03 Jul 2008) | 2 lines Make t_output_helper() static. ................ r10640 | olly | 2008-07-03 07:05:34 +0100 (Thu, 03 Jul 2008) | 2 lines Make testcase li_typemaps work for PHP. ................ r10641 | olly | 2008-07-03 10:12:16 +0100 (Thu, 03 Jul 2008) | 2 lines Fix check::classname() to compare case-insensitively and not try to interpolate objects into strings. ................ r10643 | olly | 2008-07-03 23:00:01 +0100 (Thu, 03 Jul 2008) | 4 lines The operator& trick in allowexcept.i doesn't work for SWIG/PHP because the generated code takes the address of the variable in the code in the "vinit" section. So comment out the private operator& for PHP. ................ r10647 | olly | 2008-07-04 00:55:33 +0100 (Fri, 04 Jul 2008) | 2 lines [PHP] The SWIG cdata.i library module is now supported. ................ r10649 | olly | 2008-07-04 02:02:22 +0100 (Fri, 04 Jul 2008) | 4 lines [PHP] The deprecated command line option "-make" has been removed. Searches on Google codesearch suggest that nobody is using it now anyway. ................ r10650 | olly | 2008-07-04 02:22:11 +0100 (Fri, 04 Jul 2008) | 4 lines [PHP] For std_vector.i and std_map.i, rename empty() to is_empty() since "empty" is a PHP reserved word. Based of patch from Mark Klein in SF#1943417. ................ r10662 | wsfulton | 2008-07-14 22:09:23 +0100 (Mon, 14 Jul 2008) | 1 line Fix director typemaps for pointers so that NULL pointers are correctly marshalled to C#/Java null in director methods ................ r10672 | olly | 2008-07-17 02:17:08 +0100 (Thu, 17 Jul 2008) | 2 lines Fix a typo; improve wording. ................ r10676 | wsfulton | 2008-07-17 22:05:49 +0100 (Thu, 17 Jul 2008) | 1 line SF #2019156 Configuring with --without-octave or --without-alllang did not disable octave. ................ r10677 | wsfulton | 2008-07-17 22:08:22 +0100 (Thu, 17 Jul 2008) | 1 line tidy output after detecting X11 headers ................ r10682 | wsfulton | 2008-07-19 19:08:06 +0100 (Sat, 19 Jul 2008) | 1 line a bit more on pgcpp ................ r10683 | wsfulton | 2008-07-19 23:45:54 +0100 (Sat, 19 Jul 2008) | 1 line Fix building of Tcl examples/test-suite on Mac OSX ................ r10714 | olly | 2008-07-27 13:51:16 +0100 (Sun, 27 Jul 2008) | 2 lines Fix "can can" typo in docs (SF#2026756) ................ r10726 | wuzzeb | 2008-08-02 09:28:02 +0100 (Sat, 02 Aug 2008) | 1 line Commit patch 2019314 ................ r10727 | wuzzeb | 2008-08-02 09:49:43 +0100 (Sat, 02 Aug 2008) | 1 line add assert.h to fix chicken build of external runtime (ext_test testsuite) ................ r10738 | talby | 2008-08-07 07:28:13 +0100 (Thu, 07 Aug 2008) | 2 lines hoist globals to local scope where trival. ................ r10743 | talby | 2008-08-08 04:10:55 +0100 (Fri, 08 Aug 2008) | 2 lines initial steps to clean up perl5 class methods (primarily constructors). ................ r10747 | talby | 2008-08-09 05:08:26 +0100 (Sat, 09 Aug 2008) | 2 lines moves perl space constructor fixups into wrapper code. ................ r10749 | talby | 2008-08-10 00:57:55 +0100 (Sun, 10 Aug 2008) | 2 lines usage_func() fix + CHANGES.current entry to explain my past few commits. ................ r10794 | talby | 2008-08-19 08:09:29 +0100 (Tue, 19 Aug 2008) | 3 lines rollback 10737:10749, this work is better left on a branch until it is in support a significant feature enhancement. ................ r10801 | drjoe | 2008-08-31 17:07:43 +0100 (Sun, 31 Aug 2008) | 2 lines change Rf_warning to warning. Looks like a typo ................ r10802 | wsfulton | 2008-09-01 20:59:23 +0100 (Mon, 01 Sep 2008) | 1 line Fix ruby detection problem breaking configure ................ r10803 | wsfulton | 2008-09-01 21:00:28 +0100 (Mon, 01 Sep 2008) | 1 line Fix another perl global namespace pollution ................ r10804 | wsfulton | 2008-09-01 21:32:53 +0100 (Mon, 01 Sep 2008) | 1 line Fix array bounds checking in C# std::vector wrappers ................ r10805 | wsfulton | 2008-09-01 21:34:49 +0100 (Mon, 01 Sep 2008) | 1 line fix runtime problem in Ruby std_vector example ................ r10806 | wsfulton | 2008-09-01 21:42:40 +0100 (Mon, 01 Sep 2008) | 1 line Fix portability problem using /dev/null ................ r10807 | wsfulton | 2008-09-01 22:46:41 +0100 (Mon, 01 Sep 2008) | 1 line patch #2079381 submitted by Boris Smilga - constant exprs put into no-eval context in DEFCENUM ................ r10808 | wsfulton | 2008-09-02 21:56:52 +0100 (Tue, 02 Sep 2008) | 1 line Add new terminator attribute for the csin typemap for C# ................ r10809 | wsfulton | 2008-09-03 00:01:37 +0100 (Wed, 03 Sep 2008) | 1 line Fix #1988296 - Multiple module director linking issue ................ r10827 | richardb | 2008-09-10 11:08:21 +0100 (Wed, 10 Sep 2008) | 6 lines [Python] Commit patch #2089149: Director exception handling mangles returned exception. Exceptions raised by Python code in directors are now passed through to the caller without change. Also, remove the ": " prefix which used to be added to other director exceptions (eg, those due to incorrect return types). ................ r10828 | bhy | 2008-09-10 11:45:33 +0100 (Wed, 10 Sep 2008) | 3 lines Initialized merge tracking via "svnmerge" with revisions "1-10827" from https://swig.svn.sourceforge.net/svnroot/swig/branches/gsoc2008-bhy ................ r10829 | bhy | 2008-09-10 12:04:09 +0100 (Wed, 10 Sep 2008) | 4 lines Removed merge tracking for "svnmerge" for https://swig.svn.sourceforge.net/svnroot/swig/branches/gsoc2008-bhy (Undo the init due to user error) ................ r10830 | bhy | 2008-09-10 12:08:16 +0100 (Wed, 10 Sep 2008) | 3 lines Initialized merge tracking via "svnmerge" with revisions "1-10403" from https://swig.svn.sourceforge.net/svnroot/swig/branches/gsoc2008-bhy ................ r10831 | bhy | 2008-09-10 12:51:12 +0100 (Wed, 10 Sep 2008) | 11 lines (Still trying to set right properity to get svnmerge work...) Recorded merge of revisions 10404 via svnmerge from https://swig.svn.sourceforge.net/svnroot/swig/branches/gsoc2008-bhy ........ r10404 | bhy | 2008-05-01 08:35:49 +0800 (Thu, 01 May 2008) | 5 lines Start of gsoc2008-bhy branch. This is a branch for Haoyu Bai's Python 3.0 backend project. Some file already modified since a little of work already done when starting the branch. ........ ................ r10834 | bhy | 2008-09-11 18:18:07 +0100 (Thu, 11 Sep 2008) | 8 lines Merged the Python 3.0 support branch. The merging progress is not so smooth, so hope this commit won't make anything broken. This is the (incomplemete) log produced by svnmerge.py: Merged revisions 10405-10409,10420-10422,10426,10438,10445,10451,10454-10465,10467,10473-10475,10485,10488-10489,10493-10495,10497,10509-10510,10513-10514,10517,10520,10525,10528-10529,10533-10535,10554-10557,10570,10573,10593,10614,10666-10669,10673,10678,10687,10690,10704-10706,10731,10744,10750-10752,10755,10759,10770,10775-10776,10813,10819 via svnmerge from https://swig.svn.sourceforge.net/svnroot/swig/branches/gsoc2008-bhy ................ git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/branches/gsoc2008-cherylfoil@10837 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
Jamie Kirkpatrick
parent
721327573b
commit
825e67b2b0
237 changed files with 3218 additions and 5059 deletions
|
|
@ -1567,6 +1567,7 @@ Let's assume the code being wrapped is as follows:
|
|||
<pre>
|
||||
class CDate {
|
||||
public:
|
||||
CDate();
|
||||
CDate(int year, int month, int day);
|
||||
int getYear();
|
||||
int getMonth();
|
||||
|
|
@ -1649,8 +1650,8 @@ The typemaps to achieve this are shown below.
|
|||
<pre>
|
||||
%typemap(cstype) const CDate& "System.DateTime"
|
||||
%typemap(csin,
|
||||
pre=" CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day);")
|
||||
const CDate &
|
||||
pre=" CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day);"
|
||||
) const CDate &
|
||||
"$csclassname.getCPtr(temp$csinput)"
|
||||
|
||||
%typemap(cstype) CDate& "out System.DateTime"
|
||||
|
|
@ -1658,7 +1659,8 @@ The typemaps to achieve this are shown below.
|
|||
pre=" CDate temp$csinput = new CDate();",
|
||||
post=" $csinput = new System.DateTime(temp$csinput.getYear(),"
|
||||
" temp$csinput.getMonth(), temp$csinput.getDay(), 0, 0, 0);",
|
||||
cshin="out $csinput") CDate &
|
||||
cshin="out $csinput"
|
||||
) CDate &
|
||||
"$csclassname.getCPtr(temp$csinput)"
|
||||
|
||||
</pre>
|
||||
|
|
@ -1763,7 +1765,8 @@ will be possible with the following <tt>CDate *</tt> typemaps
|
|||
pre=" CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day);",
|
||||
post=" $csinput = new System.DateTime(temp$csinput.getYear(),"
|
||||
" temp$csinput.getMonth(), temp$csinput.getDay(), 0, 0, 0);",
|
||||
cshin="ref $csinput") CDate *
|
||||
cshin="ref $csinput"
|
||||
) CDate *
|
||||
"$csclassname.getCPtr(temp$csinput)"
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -1788,6 +1791,50 @@ public class example {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The following typemap is the same as the previous but demonstrates how a using block can be used for the temporary variable.
|
||||
The only change to the previous typemap is the introduction of the 'terminator' attribute to terminate the <tt>using</tt> block.
|
||||
The <tt>subtractYears</tt> method is nearly identical to the above <tt>addYears</tt> method.
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%typemap(csin,
|
||||
pre=" using (CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day)) {",
|
||||
post=" $csinput = new System.DateTime(temp$csinput.getYear(),"
|
||||
" temp$csinput.getMonth(), temp$csinput.getDay(), 0, 0, 0);",
|
||||
terminator=" } // terminate temp$csinput using block",
|
||||
cshin="ref $csinput"
|
||||
) CDate *
|
||||
"$csclassname.getCPtr(temp$csinput)"
|
||||
|
||||
void subtractYears(CDate *pDate, int years) {
|
||||
*pDate = CDate(pDate->getYear() - years, pDate->getMonth(), pDate->getDay());
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The resulting generated code shows the termination of the <tt>using</tt> block:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
public class example {
|
||||
public static void subtractYears(ref System.DateTime pDate, int years) {
|
||||
using (CDate temppDate = new CDate(pDate.Year, pDate.Month, pDate.Day)) {
|
||||
try {
|
||||
examplePINVOKE.subtractYears(CDate.getCPtr(temppDate), years);
|
||||
} finally {
|
||||
pDate = new System.DateTime(temppDate.getYear(), temppDate.getMonth(), temppDate.getDay(), 0, 0, 0);
|
||||
}
|
||||
} // terminate temppDate using block
|
||||
}
|
||||
...
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="csharp_date_properties"></a>17.5.4 A date example demonstrating marshalling of C# properties</H3>
|
||||
|
||||
|
||||
|
|
@ -1827,7 +1874,8 @@ The typemap type required is thus <tt>CDate *</tt>. Given that the previous sect
|
|||
pre=" CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day);",
|
||||
post=" $csinput = new System.DateTime(temp$csinput.getYear(),"
|
||||
" temp$csinput.getMonth(), temp$csinput.getDay(), 0, 0, 0);",
|
||||
cshin="ref $csinput") CDate *
|
||||
cshin="ref $csinput"
|
||||
) CDate *
|
||||
"$csclassname.getCPtr(temp$csinput)"
|
||||
|
||||
%typemap(csvarin, excode=SWIGEXCODE2) CDate * %{
|
||||
|
|
|
|||
|
|
@ -380,7 +380,7 @@
|
|||
</ul>
|
||||
<li><a href="Typemaps.html#Typemaps_nn43">Typemaps for multiple languages</a>
|
||||
<li><a href="Typemaps.html#Typemaps_optimal">Optimal code generation when returning by value</a>
|
||||
<li><a href="Typemaps.html#Typemaps_nn42">Multi-argument typemaps</a>
|
||||
<li><a href="Typemaps.html#Typemaps_multi_argument_typemaps">Multi-argument typemaps</a>
|
||||
<li><a href="Typemaps.html#runtime_type_checker">The run-time type checker</a>
|
||||
<ul>
|
||||
<li><a href="Typemaps.html#Typemaps_nn45">Implementation</a>
|
||||
|
|
@ -768,6 +768,7 @@
|
|||
<li><a href="Java.html#java_directors_classes">Director classes</a>
|
||||
<li><a href="Java.html#java_directors_overhead">Overhead and code bloat</a>
|
||||
<li><a href="Java.html#java_directors_example">Simple directors example</a>
|
||||
<li><a href="Java.html#java_directors_threading">Director threading issues</a>
|
||||
</ul>
|
||||
<li><a href="Java.html#java_allprotected">Accessing protected members</a>
|
||||
<li><a href="Java.html#common_customization">Common customization features</a>
|
||||
|
|
|
|||
|
|
@ -448,7 +448,8 @@ of the output.
|
|||
<p>
|
||||
The contents of each parse tree node consist of a collection of attribute/value
|
||||
pairs. Internally, the nodes are simply represented by hash tables. A display of
|
||||
the entire parse-tree structure can be obtained using <tt>swig -dump_tree</tt>.
|
||||
the entire parse-tree structure can be obtained using <tt>swig -debug-top <n></tt>, where <tt>n</tt> is
|
||||
the stage being processed.
|
||||
There are a number of other parse tree display options, for example, <tt>swig -debug-module <n></tt> will
|
||||
avoid displaying system parse information and only display the parse tree pertaining to the user's module at
|
||||
stage <tt>n</tt> of processing.
|
||||
|
|
|
|||
|
|
@ -85,6 +85,7 @@
|
|||
<li><a href="#java_directors_classes">Director classes</a>
|
||||
<li><a href="#java_directors_overhead">Overhead and code bloat</a>
|
||||
<li><a href="#java_directors_example">Simple directors example</a>
|
||||
<li><a href="#java_directors_threading">Director threading issues</a>
|
||||
</ul>
|
||||
<li><a href="#java_allprotected">Accessing protected members</a>
|
||||
<li><a href="#common_customization">Common customization features</a>
|
||||
|
|
@ -2856,7 +2857,11 @@ and therefore there is no possibility of premature garbage collection. In practi
|
|||
|
||||
<p>
|
||||
The premature garbage collection prevention parameter for proxy classes is generated by default whenever proxy classes are passed by value, reference or with a pointer.
|
||||
The additional parameters do impose a slight performance overhead and the parameter generation can be suppressed globally with the <tt>-nopgcpp</tt> commandline option.
|
||||
The implementation for this extra parameter generation requires the "jtype" typemap to contain <tt>long</tt> and the "jstype" typemap to contain the name of a proxy class.
|
||||
<p>
|
||||
|
||||
<p>
|
||||
The additional parameter does impose a slight performance overhead and the parameter generation can be suppressed globally with the <tt>-nopgcpp</tt> commandline option.
|
||||
More selective suppression is possible with the 'nopgcpp' attribute in the "jtype" <a href="#java_typemaps">Java typemap</a>.
|
||||
The attribute is a flag and so should be set to "1" to enable the suppression, or it can be omitted or set to "0" to disable.
|
||||
For example:
|
||||
|
|
@ -3450,6 +3455,26 @@ DirectorDerived::upcall_method() invoked.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="java_directors_threading"></a>20.5.5 Director threading issues</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Depending on your operating system and version of Java and how you are using threads, you might find the JVM hangs on exit.
|
||||
There are a couple of solutions to try out. The preferred solution requires jdk-1.4 and later and uses <tt>AttachCurrentThreadAsDaemon</tt> instead of <tt>AttachCurrentThread</tt> whenever a call into the JVM is required. This can be enabled by defining the SWIG_JAVA_ATTACH_CURRENT_THREAD_AS_DAEMON macro when compiling the C++ wrapper code. For older JVMs define SWIG_JAVA_NO_DETACH_CURRENT_THREAD instead, to avoid the <tt>DetachCurrentThread</tt> call but this will result in a memory leak instead. For further details inspect the source code in the java/director.swg library file.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Macros can be defined on the commandline when compiling your C++ code, or alternatively added to the C++ wrapper file as shown below:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%insert("runtime") %{
|
||||
#define SWIG_JAVA_NO_DETACH_CURRENT_THREAD
|
||||
%}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="java_allprotected"></a>20.6 Accessing protected members</H2>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -43,21 +43,24 @@
|
|||
<b>Caution: This chapter (and module!) is still under construction</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
SWIG supports generating wrappers for PHP5. Support for PHP4 has been removed
|
||||
as of SWIG 1.3.37. The PHP developers are no longer making new PHP4 releases,
|
||||
and won't even be patching critical security issues after 2008-08-08, so it
|
||||
doesn't make much sense for SWIG to continue to support PHP4 at this point.
|
||||
If you need to continue to use PHP4, stick with SWIG 1.3.36.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In this chapter, we discuss SWIG's support of PHP. The PHP module
|
||||
was extensively rewritten in release 1.3.26, and although it is
|
||||
significantly more functional, it still does not implement all the
|
||||
was extensively rewritten in release 1.3.26, and support for generating
|
||||
OO wrappers for PHP5 was added in 1.3.30. The PHP module works fairly
|
||||
well, but currently does not implement all the
|
||||
features available in some of the other languages.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The examples and test cases have been developed with PHP4. Release
|
||||
1.3.30 added support for generating PHP5 class wrappers for C++
|
||||
libraries.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In order to use this module, you will need to have a copy of the PHP4 or PHP5
|
||||
In order to use this module, you will need to have a copy of the PHP5
|
||||
include files to compile the SWIG generated files. If you installed
|
||||
PHP from a binary package, you may need to install a "php-dev" or "php-devel"
|
||||
package for these to be installed. You can find out where these files are
|
||||
|
|
@ -88,7 +91,7 @@ you wish to statically link the extension into the php interpreter.
|
|||
The third file,
|
||||
<tt>example.php</tt> can be included by PHP scripts. It attempts to
|
||||
dynamically load the extension and contains extra php code specified
|
||||
in the interface file. If wrapping C++ code for PHP5, it will
|
||||
in the interface file. If wrapping C++ code with PHP classes, it will
|
||||
also contain PHP5 class wrappers.
|
||||
</p>
|
||||
|
||||
|
|
@ -100,7 +103,8 @@ more detail in <a href="#Php_nn2_6">section 27.2.6</a>.
|
|||
|
||||
<p>
|
||||
The usual (and recommended) way is to build the extension as a separate
|
||||
dynamically loaded module. You can then specify that this be loaded
|
||||
dynamically loaded module (which is supported by all modern operating
|
||||
systems). You can then specify that this be loaded
|
||||
automatically in <tt>php.ini</tt> or load it explicitly for any script which
|
||||
needs it.
|
||||
</p>
|
||||
|
|
@ -110,17 +114,15 @@ It is also possible to rebuild PHP from source so that your module is
|
|||
statically linked into the php executable/library. This is a lot more
|
||||
work, and also requires a full rebuild of PHP to update your module,
|
||||
and it doesn't play nicely with package system. We don't recommend
|
||||
this approach, but if you really want to do this, the <tt>-phpfull</tt>
|
||||
command line argument to swig may be of use - see below for details.
|
||||
this approach, or provide explicit support for it.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn1_1"></a>28.1.1 Building a loadable extension</H3>
|
||||
|
||||
|
||||
<p>
|
||||
To build your module as a dynamically loadable extension, use compilation
|
||||
commands like these (if you aren't using GCC, the commands will be different,
|
||||
and there may be so variation between platforms - these commands should at
|
||||
and there may be some variation between platforms - these commands should at
|
||||
least work for Linux though):
|
||||
</p>
|
||||
|
||||
|
|
@ -129,137 +131,8 @@ least work for Linux though):
|
|||
gcc -shared example_wrap.o -o example.so
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
There is a deprecated <tt>-make</tt> command line argument to swig which will
|
||||
generate an additional file <tt>makefile</tt> which can usually build the
|
||||
extension (at least on some UNIX platforms), but the Makefile generated isn't
|
||||
very flexible, and the commands required are trivial so it is simpler to just
|
||||
add them to your Makefile or other build system directly. We recommend that
|
||||
you don't use <tt>-make</tt> and it's likely to be removed at some point.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn1_2"></a>28.1.2 Building extensions into PHP</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Note that we don't recommend this approach - it's cleaner and simpler to
|
||||
use dynamically loadable modules, which are supported by all modern OSes.
|
||||
Support for this may be discontinued entirely in the future.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
It is possible to rebuild PHP itself with your module statically linked
|
||||
in. To do this, you can use the <tt>-phpfull</tt> command line option to
|
||||
swig. Using this option will generate three additional files. The first
|
||||
extra file, <tt>config.m4</tt> contains the m4 and shell code needed to
|
||||
enable the extension as part of the PHP build process. The second
|
||||
extra file, <tt>Makefile.in</tt> contains the information needed to
|
||||
build the final Makefile after substitutions. The third and final
|
||||
extra file, <tt>CREDITS</tt> should contain the credits for the
|
||||
extension.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To build with phpize, after you have run swig you will need to run the
|
||||
'phpize' command (installed as part of php) in the same
|
||||
directory. This re-creates the php build environment in that
|
||||
directory. It also creates a configure file which includes the shell
|
||||
code from the config.m4 that was generated by SWIG, this configure
|
||||
script will accept a command line argument to enable the extension to
|
||||
be run (by default the command line argument is --enable-modulename,
|
||||
however you can edit the config.m4 file before running phpize to
|
||||
accept --with-modulename. You can also add extra tests in config.m4 to
|
||||
check that a correct library version is installed or correct header
|
||||
files are included, etc, but you must edit this file before running
|
||||
phpize.) You can also get SWIG to generate simple extra tests for
|
||||
libraries and header files for you.
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
swig -php -phpfull
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
If you depend on source files not generated by SWIG, before generating
|
||||
the configure file, you may need to edit the <tt>Makefile.in</tt>
|
||||
file. This contains the names of the source files to compile (just the
|
||||
wrapper file by default) and any additional libraries needed to be
|
||||
linked in. If there are extra C files to compile, you will need to add
|
||||
them to the <tt>Makefile.in</tt>, or add the names of libraries if they are
|
||||
needed. In simple cases SWIG is pretty good at generating a complete
|
||||
<tt>Makefile.in</tt> and <tt>config.m4</tt> which need no further editing.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You then run the configure script with the command line argument needed
|
||||
to enable the extension. Then run make, which builds the extension.
|
||||
The extension object file will be left in the modules sub directory, you can
|
||||
move it to wherever it is convenient to call from your php script.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
When using <tt>-phpfull</tt>, swig also accepts the following
|
||||
additional optional arguments:
|
||||
</p>
|
||||
<ul>
|
||||
<li><tt>-withincs "<incs>"</tt> Adds include files to the config.m4 file.
|
||||
<li><tt>-withlibs "<libs>"</tt> Links with the specified libraries.
|
||||
<li><tt>-withc "<files>"</tt> Compiles and links the additional specified C files.
|
||||
<li><tt>-withcxx "<files>"</tt> Compiles and links the additional specified C++ files.
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
After running swig with the <tt>-phpfull</tt> switch, you will be left with a shockingly
|
||||
similar set of files to the previous build process. However you will then need
|
||||
to move these files to a subdirectory within the php source tree, this subdirectory you will need to create under the ext directory, with the name of the extension (e.g. <tt>mkdir php-4.0.6/ext/modulename</tt>).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
After moving the files into this directory, you will need to run the 'buildall'
|
||||
script in the php source directory. This rebuilds the configure script
|
||||
and includes the extra command line arguments from the module you have added.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Before running the generated configure file, you may need to edit the <tt>
|
||||
Makefile.in</tt>. This contains the names of the source files to compile (
|
||||
just the wrapper file by default) and any additional libraries needed to
|
||||
link in. If there are extra C files to compile you will need to add them
|
||||
to the Makefile, or add the names of libraries if they are needed.
|
||||
In most cases <tt>Makefile.in</tt> will be complete, especially if you
|
||||
make use of <tt>-withlibs</tt> and <tt>-withincs</tt>
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
swig -php -phpfull -withlibs "xapian omquery" --withincs "om.h"
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
Will include in the <tt>config.m4</tt> and <tt>Makefile.in</tt> search for
|
||||
<tt>libxapian.a</tt> or <tt>libxapian.so</tt> and search for
|
||||
<tt>libomquery.a</tt> or <tt>libomquery.so</tt> as well as a
|
||||
search for <tt>om.h</tt>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You then need to run the configure command and pass the necessary command
|
||||
line arguments to enable your module (by default this is --enable-modulename,
|
||||
but this can be changed by editing the config.m4 file in the modules directory
|
||||
before running the buildall script. In addition, extra tests can be added to
|
||||
the config.m4 file to ensure the correct libraries and header files are
|
||||
installed.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Once configure has completed, you can run make to build php. If this all
|
||||
compiles correctly, you should end up with a php executable/library
|
||||
which contains your new module. You can test it with a php script which
|
||||
does not have the 'dl' command as used above.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn1_3"></a>28.1.3 Using PHP Extensions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
To test the extension from a PHP script, you need to load it first. You
|
||||
can load it for every script by adding this line the <tt>[PHP]</tt> section of
|
||||
|
|
@ -717,20 +590,9 @@ variable, or assigning <tt>NULL</tt> to a variable.
|
|||
|
||||
|
||||
<p>
|
||||
SWIG defaults to wrapping C++ structs and classes with PHP classes. This
|
||||
requires SWIG to generate different code for PHP4 and PHP5, so you must
|
||||
specify which you want using <tt>-php4</tt> or <tt>-php5</tt> (currently
|
||||
<tt>-php</tt> generates PHP4 class wrappers for compatibility with
|
||||
SWIG 1.3.29 and earlier, but this may change in the future).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
PHP4 classes are implemented entirely using the Zend C API so
|
||||
no additional php code is generated. For PHP5, a PHP wrapper
|
||||
SWIG defaults to wrapping C++ structs and classes with PHP classes
|
||||
unless "-noproxy" is specified. For PHP5, a PHP wrapper
|
||||
class is generated which calls a set of flat functions wrapping the C++ class.
|
||||
In many cases the PHP4 and PHP5 wrappers will behave the same way,
|
||||
but the PHP5 ones make use of better PHP5's better OO functionality
|
||||
where appropriate.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -754,7 +616,7 @@ struct Complex {
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
Would be used in the following way from either PHP4 or PHP5:
|
||||
Would be used in the following way from PHP5:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -854,9 +716,9 @@ the programmer can either reassign the variable or call
|
|||
|
||||
|
||||
<p>
|
||||
Static member variables are not supported in PHP4, and it does not
|
||||
appear to be possible to intercept accesses to static member variables
|
||||
in PHP5. Therefore, static member variables are
|
||||
Static member variables in C++ are not wrapped as such in PHP
|
||||
as it does not appear to be possible to intercept accesses to such variables.
|
||||
Therefore, static member variables are
|
||||
wrapped using a class function with the same name, which
|
||||
returns the current value of the class variable. For example
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@
|
|||
<li><a href="#Python_nn30">Memory management</a>
|
||||
<li><a href="#Python_nn31">Python 2.2 and classic classes</a>
|
||||
</ul>
|
||||
<li><a href="#directors">Cross language polymorphism</a>
|
||||
<li><a href="#Python_directors">Cross language polymorphism</a>
|
||||
<ul>
|
||||
<li><a href="#Python_nn33">Enabling directors</a>
|
||||
<li><a href="#Python_nn34">Director classes</a>
|
||||
|
|
@ -101,6 +101,12 @@
|
|||
<li><a href="#Python_nn71">%feature("docstring")</a>
|
||||
</ul>
|
||||
<li><a href="#Python_nn72">Python Packages</a>
|
||||
<li><a href="#Python_python3support">Python 3 Support</a>
|
||||
<ul>
|
||||
<li><a href="#Python_nn74">Function annotation</a>
|
||||
<li><a href="#Python_nn75">Buffer interface</a>
|
||||
<li><a href="#Python_nn76">Abstract base classes</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
|
@ -113,9 +119,9 @@
|
|||
|
||||
<p>
|
||||
This chapter describes SWIG's support of Python. SWIG is compatible
|
||||
with most recent Python versions including Python 2.2 as well as older
|
||||
versions dating back to Python 1.5.2. For the best results, consider using Python
|
||||
2.0 or newer.
|
||||
with most recent Python versions including Python 3.0 and Python 2.6,
|
||||
as well as older versions dating back to Python 2.0. For the best results,
|
||||
consider using Python 2.3 or newer.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -2544,7 +2550,7 @@ class itself. In Python-2.1 and earlier, they have to be accessed as a global
|
|||
function or through an instance (see the earlier section).
|
||||
</p>
|
||||
|
||||
<H2><a name="directors"></a>30.5 Cross language polymorphism</H2>
|
||||
<H2><a name="Python_directors"></a>30.5 Cross language polymorphism</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4929,7 +4935,7 @@ with more than one line.
|
|||
<p>
|
||||
Using the <tt>package</tt> option of the <tt>%module</tt> directive
|
||||
allows you to specify what Python package that the module will be
|
||||
living in when installed.
|
||||
living in when installed.
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
|
|
@ -4950,6 +4956,241 @@ and also in base class declarations, etc. if the package name is
|
|||
different than its own.
|
||||
</p>
|
||||
|
||||
<H2><a name="Python_python3support"></a>30.12 Python 3 Support</H2>
|
||||
|
||||
|
||||
<p>
|
||||
SWIG is able to support Python 3.0. The wrapper code generated by
|
||||
SWIG can be compiled with both Python 2.x or 3.0. Further more, by
|
||||
passing the <tt>-py3</tt> command line option to SWIG, wrapper code
|
||||
with some Python 3 specific features can be generated (see below
|
||||
subsections for details of these features). The <tt>-py3</tt> option also
|
||||
disables some incompatible features for Python 3, such as
|
||||
<tt>-classic</tt>.
|
||||
|
||||
<p>
|
||||
There is a list of known-to-be-broken features in Python 3:
|
||||
</p>
|
||||
<ul>
|
||||
<li>No more support for FILE* typemaps, because PyFile_AsFile has been dropped
|
||||
in Python 3.</li>
|
||||
<li>The <tt>-apply</tt> command line option is removed and generating
|
||||
code using apply() is no longer supported.</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
The following are Python 3.0 new features that are currently supported by
|
||||
SWIG.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn74"></a>30.12.1 Function annotation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The <tt>-py3</tt> option will enable function annotation support. When used
|
||||
SWIG is able to generate proxy method definitions like
|
||||
this:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
def foo(self, bar : "int" = 0) -> "void" : ...
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
For details of usage of function annotation, see PEP 3107.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn75"></a>30.12.2 Buffer interface</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Buffer protocols were revised in Python 3. SWIG also gains a series of
|
||||
new typemaps to support buffer interfaces. These typemap macros are
|
||||
defined in <tt>pybuffer.i</tt>, which must be included in order to use them.
|
||||
By using these typemaps, your wrapped function will be able to
|
||||
accept any Python object that exposes a suitable buffer interface.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For example, the <tt>get_path()</tt> function puts the path string
|
||||
into the memory pointed to by its argument:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
void get_path(char *s);
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
Then you can write a typemap like this: (the following example is
|
||||
applied to both Python 3.0 and 2.6, since the <tt>bytearray</tt> type
|
||||
is backported to 2.6.
|
||||
</p>
|
||||
|
||||
|
||||
<div class="code"><pre>
|
||||
%include <pybuffer.i>
|
||||
%pybuffer_mutable_string(char *str);
|
||||
void get_path(char *s);
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
And then on the Python side the wrapped <tt>get_path</tt> could be used in this
|
||||
way:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
>>> p = bytearray(10)
|
||||
>>> get_path(p)
|
||||
>>> print(p)
|
||||
bytearray(b'/Foo/Bar/\x00')
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
The macros defined in <tt>pybuffer.i</tt> are similar to those in
|
||||
<tt>cstring.i</tt>:
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>%pybuffer_mutable_binary(parm, size_parm)</b>
|
||||
</p>
|
||||
|
||||
<div class="indent">
|
||||
|
||||
<p>
|
||||
The macro can be used to generate a typemap which maps a buffer of an
|
||||
object to a pointer provided by <tt>parm</tt> and a size argument
|
||||
provided by <tt>size_parm</tt>. For example:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
%pybuffer_mutable_binary(char *str, size_t size);
|
||||
...
|
||||
int snprintf(char *str, size_t size, const char *format, ...);
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
In Python:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
>>> buf = bytearray(6)
|
||||
>>> snprintf(buf, "Hello world!")
|
||||
>>> print(buf)
|
||||
bytearray(b'Hello\x00')
|
||||
>>>
|
||||
</pre></div>
|
||||
|
||||
</div>
|
||||
|
||||
<p>
|
||||
<b>%pybuffer_mutable_string(parm)</b>
|
||||
</p>
|
||||
|
||||
<div class="indent">
|
||||
|
||||
<p>
|
||||
This typemap macro requires the buffer to be a zero terminated string,
|
||||
and maps the pointer of the buffer to <tt>parm</tt>. For example:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
%pybuffer_mutable_string(char *str);
|
||||
...
|
||||
size_t make_upper(char *str);
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
In Python:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
>>> buf = bytearray(b'foo\x00')
|
||||
>>> make_upper(buf)
|
||||
>>> print(buf)
|
||||
bytearray(b'FOO\x00')
|
||||
>>>
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
Both <tt>%pybuffer_mutable_binary</tt> and <tt>%pybuffer_mutable_string</tt>
|
||||
require the provided buffer to be mutable, eg. they can accept a
|
||||
<tt>bytearray</tt> type but can't accept an immutable <tt>byte</tt>
|
||||
type.
|
||||
</p>
|
||||
|
||||
</div>
|
||||
|
||||
<p>
|
||||
<b>%pybuffer_binary(parm, size_parm)</b>
|
||||
</p>
|
||||
|
||||
<div class="indent">
|
||||
|
||||
<p>
|
||||
This macro maps an object's buffer to a pointer <tt>parm</tt> and a
|
||||
size <tt>size_parm</tt>. It is similar to
|
||||
<tt>%pybuffer_mutable_binary</tt>, except the
|
||||
<tt>%pybuffer_binary</tt> an accept both mutable and immutable
|
||||
buffers. As a result, the wrapped function should not modify the buffer.
|
||||
</p>
|
||||
|
||||
</div>
|
||||
|
||||
<p>
|
||||
<b>%pybuffer_string(parm)</b>
|
||||
</p>
|
||||
|
||||
<div class="indent">
|
||||
|
||||
<p>
|
||||
This macro maps an object's buffer as a string pointer <tt>parm</tt>.
|
||||
It is similar to <tt>%pybuffer_mutable_string</tt> but the buffer
|
||||
could be both mutable and immutable. And your function should not
|
||||
modify the buffer.
|
||||
</p>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<H3><a name="Python_nn76"></a>30.12.3 Abstract base classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
By including <tt>pyabc.i</tt> and using the <tt>-py3</tt> command
|
||||
line option when calling SWIG, the proxy classes of the STL containers
|
||||
will automatically gain an appropriate abstract base class. For
|
||||
example, the following SWIG interface:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
%include <pyabc.i>
|
||||
%include <std_map.i>
|
||||
%include <std_list.i>
|
||||
|
||||
namespace std {
|
||||
%template(Mapii) map<int, int>;
|
||||
%template(IntList) list<int>;
|
||||
}
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
will generate a Python proxy class <tt>Mapii</tt> inheriting from
|
||||
<tt>collections.MutableMap</tt> and a proxy class <tt>IntList</tt>
|
||||
inheriting from <tt>collections.MutableSequence</tt>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<tt>pyabc.i</tt> also provides a macro <tt>%pythonabc</tt> that could be
|
||||
used to define an abstract base class for your own C++ class:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
%pythonabc(MySet, collections.MutableSet);
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
For details of abstract base class, please see PEP 3119.
|
||||
</p>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@
|
|||
<li><a href="#SWIG_nn33">Character strings and structures</a>
|
||||
<li><a href="#SWIG_nn34">Array members</a>
|
||||
<li><a href="#SWIG_structure_data_members">Structure data members</a>
|
||||
<li><a href="#SWIG_nn36">C constructors and destructors </a>
|
||||
<li><a href="#SWIG_nn36">C constructors and destructors</a>
|
||||
<li><a href="#SWIG_adding_member_functions">Adding member functions to C structures</a>
|
||||
<li><a href="#SWIG_nested_structs">Nested structures</a>
|
||||
<li><a href="#SWIG_nn39">Other things to note about structure wrapping</a>
|
||||
|
|
@ -224,7 +224,7 @@ The C/C++ output file created by SWIG often
|
|||
contains everything that is needed to construct a 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
|
||||
you probably won't want to). To build the final extension module, the
|
||||
SWIG output file is compiled and linked with the rest of your C/C++
|
||||
program to create a shared library.
|
||||
</p>
|
||||
|
|
@ -232,7 +232,7 @@ program to create a shared library.
|
|||
<p>
|
||||
Many target languages 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
|
||||
specific files is the same directory as the generated C/C++ file. This
|
||||
can be modified using the <tt>-outdir</tt> option. For example:
|
||||
</p>
|
||||
|
||||
|
|
@ -2219,13 +2219,13 @@ void Foo_w_set(FOO *f, WORD value) {
|
|||
|
||||
|
||||
<p>
|
||||
<b>Compatibility Note: </b> SWIG-1.3.11 and earlier releases transformed all non-primitive member datatypes
|
||||
to pointers. Starting in SWIG-1.3.12, this transformation <em>only</em> occurs if a datatype is known to be a structure,
|
||||
class, or union. This is unlikely to break existing code. However, if you need to tell SWIG that an undeclared
|
||||
<b>Compatibility Note:</b> SWIG-1.3.11 and earlier releases transformed all non-primitive member datatypes
|
||||
to pointers. Starting in SWIG-1.3.12, this transformation <em>only</em> occurs if a datatype is known to be a structure,
|
||||
class, or union. This is unlikely to break existing code. However, if you need to tell SWIG that an undeclared
|
||||
datatype is really a struct, simply use a forward struct declaration such as <tt>"struct Foo;"</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="SWIG_nn36"></a>5.5.5 C constructors and destructors </H3>
|
||||
<H3><a name="SWIG_nn36"></a>5.5.5 C constructors and destructors</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2282,7 +2282,7 @@ struct Bar { // Default constructor generated.
|
|||
Since ignoring the implicit or default destructors most of the times
|
||||
produce 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>
|
||||
default/implicit destructor by using <tt>%nodefaultdtor</tt>
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
|
|
|
|||
|
|
@ -1153,8 +1153,9 @@ public:
|
|||
|
||||
|
||||
<p>
|
||||
This is great for reducing the size of the wrappers, but the caveat is it does not work for the strongly typed languages
|
||||
which don't have optional arguments in the language, such as C# and Java.
|
||||
This is great for reducing the size of the wrappers, but the caveat is it does not work for the statically typed languages,
|
||||
such as C# and Java,
|
||||
which don't have optional arguments in the language,
|
||||
Another restriction of this feature is that it cannot handle default arguments that are not public.
|
||||
The following example illustrates this:
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Sections"></a>SWIG-1.3 Development Documentation</H1>
|
||||
|
||||
Last update : SWIG-1.3.36 (in progress)
|
||||
Last update : SWIG-1.3.37 (in progress)
|
||||
|
||||
<H2>Sections</H2>
|
||||
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@
|
|||
</ul>
|
||||
<li><a href="#Typemaps_nn43">Typemaps for multiple languages</a>
|
||||
<li><a href="#Typemaps_optimal">Optimal code generation when returning by value</a>
|
||||
<li><a href="#Typemaps_nn42">Multi-argument typemaps</a>
|
||||
<li><a href="#Typemaps_multi_argument_typemaps">Multi-argument typemaps</a>
|
||||
<li><a href="#runtime_type_checker">The run-time type checker</a>
|
||||
<ul>
|
||||
<li><a href="#Typemaps_nn45">Implementation</a>
|
||||
|
|
@ -702,7 +702,7 @@ variables (parms). The purpose of these variables will be explained shortly.
|
|||
</p>
|
||||
|
||||
<p><em>code</em> specifies the code used in the typemap.
|
||||
Usually this is C/C++ code, but in the strongly typed target languages, such as Java and C#, this can contain target language code for certain typemaps.
|
||||
Usually this is C/C++ code, but in the statically typed target languages, such as Java and C#, this can contain target language code for certain typemaps.
|
||||
It can take any one of the following forms:
|
||||
</p>
|
||||
|
||||
|
|
@ -1933,7 +1933,7 @@ to implement customized conversions.
|
|||
|
||||
<p>
|
||||
In addition, the "in" typemap allows the number of converted arguments to be
|
||||
specified. For example:
|
||||
specified. The <tt>numinputs</tt> attributes facilitates this. For example:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
|
|
@ -1946,7 +1946,12 @@ specified. For example:
|
|||
</div>
|
||||
|
||||
<p>
|
||||
At this time, only zero or one arguments may be converted.
|
||||
At this time, only zero or one arguments may be converted.
|
||||
When <tt>numinputs</tt> is set to 0, the argument is effectively ignored and cannot be supplied from the target language.
|
||||
The argument is still required when making the C/C++ call and the above typemap
|
||||
shows the value used is instead obtained from a locally declared variable called <tt>temp</tt>.
|
||||
Usually <tt>numinputs</tt> is not specified, whereupon the default value is 1, that is, there is a one to one mapping of the number of arguments when used from the target language to the C/C++ call.
|
||||
<a href="#Typemaps_multi_argument_typemaps">Multi-argument typemaps</a> provide a similar concept where the number of arguments mapped from the target language to C/C++ can be changed for more tha multiple adjacent C/C++ arguments.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -2811,7 +2816,7 @@ optimal attribute usage in the out typemap at example.i:7.
|
|||
However, it doesn't always get it right, for example when <tt>$1</tt> is within some commented out code.
|
||||
</p>
|
||||
|
||||
<H2><a name="Typemaps_nn42"></a>10.9 Multi-argument typemaps</H2>
|
||||
<H2><a name="Typemaps_multi_argument_typemaps"></a>10.9 Multi-argument typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -373,7 +373,7 @@ example.i(4): Syntax error in input.
|
|||
<li>117. Deprecated <tt>%new</tt> directive.
|
||||
<li>118. Deprecated <tt>%typemap(except)</tt>.
|
||||
<li>119. Deprecated <tt>%typemap(ignore)</tt>.
|
||||
<li>120. Deprecated command line option (-c).
|
||||
<li>120. Deprecated command line option (-runtime, -noruntime).
|
||||
<li>121. Deprecated <tt>%name</tt> directive.
|
||||
</ul>
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue