Gour wrote:
> Hello!
>
> We plan to do a project in D for which there is upcoming support in
> Swig.
>
> The C-lib which we want to access has a typical (if such thing exist)
> C API where error handling is done by checking return code and output
> of the function is handled by pointers.
>
> Here is one example:
>
> int swe_calc_ut ( double tjd_ut, int ipl, int iflag, double* xx, char*
> serr)
>
> (API is documented at
> http://www.astro.com/swisseph/swephprg.htm#_Toc226863726)
>
> If return value is < 0, it indicates error case and the *serr
> parameter will contain string of the error message.
>
> Moreover, result of the calculation is stored in the array of 6
> doubles (for longitude, latitude, distance, speed in long., speed in
> lat., and speed in dist.) named 'xx'.
>
> Considering that D is higher-level language (which we begin to learn)
> we would like to provide higher-level API for the D users of this C
> lib, iow. we would like to handle errors by throwing & catching
> exceptions and have result stored in a more structured data container,
> like C's struct, class object, hash table etc.
>
> While working with the problem of providing FFI and higher-level API
> in Haskell (e.g. using c2hs), one was able to freely design required
> higher-level API wrapper over lower-level C-like Haskell API. Iow, it
> is suggested to provide bindings in two layers.
>
> Now, just starting with the Swig, I'm curious how to do the same.
>
> Skimming over the docs, I'm aware that one can very easily bind C-lib
> by providing similar API for a target extension language which is
> similar to the original API provided by the C lib itself.
>
> The question is whether Swig enables one to provide higher-level API
> as we described in the beginning of this post, or it is recommended to
> 'just' bind functions from the lib à la C API and then write separate
> higher-level wrapper over it in the target language, which will be D
> in our case?
>
A higher level API can be obtained using just SWIG directives (typemaps
and features), but is quite fiddly and requires customising it for every
function being wrapped, unless you have some common patterns in your
API, eg all the error message are called char *serr. The other
alternative is to provide a high level C/C++ API and then use SWIG to
wrap that. For example:
struct Result {
double longitude;
double latitude;
double distance;
.. etc..
}
%include "std_string.i"
Result calc_ut(double tjd_ut, int ipl, int iflag) throw (std:string)
{
double xx[6];
char serr[256];
Result r;
... initialise r to 0 ...
if (swe_calc_ut ( tjd_ut, ipl, iflag, &xx, &serr) == 0)
r.longitute = xx[0];
r.latitude = xx[1];
r.distance = xx[2]; // etc
}
else {
throw std::string(serr);
}
return r;
}
Once you have this C++ API that is more SWIG friendly SWIG will generate
a great API in all the target languages it supports without doing
anything else specific for each of the target languages. By using the
exception specification SWIG will automatically handle the C++
exceptions too and translate them into something that the target
language handles.
William

Robert J. Brown wrote:
> NOTE: I reverted to latest 1.x version of swig and it worked fine.
> The 2.x version had problems described below.
>
> -------- Original Message --------
> Return-Path: <rj@...>
> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eli.elilabs.com
> X-Spam-Level:
> X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00
> autolearn=ham version=3.3.1
> Received: from eli.elilabs.com (localhost.localdomain [127.0.0.1]) by
> eli.elilabs.com (8.14.4/8.14.0) with ESMTP id oAIHO027028624; Thu, 18
> Nov 2010 12:24:00 -0500
> Received: (from apache@...) by eli.elilabs.com
> (8.14.4/8.13.4/Submit) id oAIHNxfk028620; Thu, 18 Nov 2010 12:23:59 -0500
> X-Authentication-Warning: eli.elilabs.com: apache set sender to
> rj@... using -f
> Received: from ofwgwc03.rockwellcollins.com ([205.175.225.12])
> (SquirrelMail authenticated user rj) by http://www.elilabs.com with HTTP; Thu,
> 18 Nov 2010 12:23:58 -0500
> Message-ID: <51bf648b9b03c696bfa8ce93518159e9.squirrel@...>
> Date: Thu, 18 Nov 2010 12:23:58 -0500
> Subject: python short and long are pointers?
> From: rj@...
> To: swig-user@...
> Cc: rj@...
> User-Agent: SquirrelMail/1.4.20
> MIME-Version: 1.0
> Content-Type: text/plain;charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
> X-Priority: 3 (Normal)
> Importance: Normal
>
>
>
> I am a new SWIG user trying to port a vendor supplied C library to python.
> The target OS is Windows XP. Things are generally trying to work, but I
> am having a problem with unsigned short and unsigned long types. They are
> typedefed as follows:
>
> typedef unsigned short u_int16;
> typedef unsigned
Is there something missing here?
> typedef unsigned long u_int64;
>
> When they are used as members of a struct as follows:
>
> typedef struct _blah {
> u_int32 foo;
> u_int16 bar;
> u_int64 baz;
> } blah;
>
> and instantiated as follows:
>
> blah zot;
>
> then I can access foo, from ptyhon as zot.foo, and it works as expected,
> but when I try access bar or baz, python says they are pointers:
>
You are not passing SWIG the definitions of these types, that is the
typedefs shown above.
> print zot.foo.__doc__
> int(x[, base]) -> integer
>
> Convert a string or number to an integer, if possible. A floating point
> argument will be truncated towards zero (this does not include a string
> representation of a floating point number!) When converting a string, use
> the optional base. It is an error to supply a base when converting a
> non-string. If the argument is outside the integer range a long object
> will be returned instead.
>
> print zot.bar.__doc__
> Swig object carries a C/C++ instance pointer
>
> print zot.baz.__doc__
> Swig object carries a C/C++ instance pointer
>
> I actually need to be able to treat these fields as numbers, not as
> pointers. The SWIGdocumentation.pdf file p 25 says:
>
> """
> Most scripting languages provide a single integer type that is implemented
> using the int or long datatype in C. The following list shows all of the C
> datatypes that SWIG will convert to and from integers in the target
> language:
>
> int
> short
> long
> unsigned
> signed
> unsigned short
> unsigned long
> unsigned char
> signed char
> bool
>
> When an integral value is converted from C, a cast is used to convert it
> to the representation in the target language. Thus, a 16 bit short in C
> may be promoted to a 32 bit integer. When integers are converted in the
> other direction, the value is cast back into the original C type. If the
> value is too large to fit, it is silently truncated.
> """
>
> This is exactly the behavior I am looking for, but it is now what I am
> seeing. Was there a recent change to how 16 and 64 bit integers are
> handled that did not make it into the manual?
>
64 bit numbers work, long long does by default. Also look at using
%include of stdint.i which contains the definitions for many C99
integral types. You have to explicitly include this file in the same way
that you have to explicitly #include <stdint.h> in C.
William

Stephen Pietrowicz wrote:
> Hi,
>
> I have a singleton object that I retrieve references from like this:
>
> Log& Log::getDefaultLog() {
> if (defaultLog == 0)
> defaultLog = new Log();
> return *Log;
> }
>
> Log::~Log() { std::cout << "destructor called" << std::endl; }
>
> in C++ I can run a program like this:
>
> Log log = Log::getDefaultLog();
> log.emit("message 1");
> log.emit("message 2");
> log.emit("message 3");
>
> and see output like this:
>
> message 1
> message 2
> message 3
> destructor called
>
>
> This code has been Swig-ed for python. If i do the following:
>
> dlog = log.getDefaultLog()
> dlog.emit("message 1")
> dlog.emit("message 2")
> dlog.emit("message 3")
>
> I get the following:
>
> destructor called
> destructor called
> message 1
> message 2
> message 3
> destructor called
>
> How do I prevent the destructor from being called multiple times, and how do I still make sure it's called at the end?
I don't think you have shown the code you are actually running, for
example the getDefaultLog function above won't compile. Is this method
static or non-static? It should be static, but given the way you are
calling it from Python it can't be. The fact you have destructors being
called indicates that Log is being marshalled by value rather than
pointer somewhere, but you don't give any indication of this in what you
have posted. Please post an example of exactly what you are doing.
William

On Fri, Dec 03, 2010 at 10:21:53PM -0500, Bob Rossi wrote:
> Hi,
>
> I'm enjoying playing around with swig, it mostly just works for me.
>
> One area i've been having trouble with is teaching swig to understand
> when pointers can cast to each other. This is mainly because i'm
> using a sort of smart pointer. For instance,
> class A {};
> class B : public A {}
> template <class T>
> class SmartPtr {
> template <class Y>
> SmartPtr(const SmartPtr<Y> &other) {}
>
> ...operator &()..
> ...operator *()..
> ...
>
> Swig doesn't seem to recognize that SmartPtr<B> can be copied to
> SmartPtr<A> with no problem.
>
> Is there a way to teach it this? Up until now, I find myself using
> typemaps...
Hopefully you understand that i'm asking how to add to this member in
the swig data structures manually,
struct swig_cast_info *cast; /* linked list of types that can cast into this type */
Is this possible?
Thanks,
Bob

Hi,
I'm enjoying playing around with swig, it mostly just works for me.
One area i've been having trouble with is teaching swig to understand
when pointers can cast to each other. This is mainly because i'm
using a sort of smart pointer. For instance,
class A {};
class B : public A {}
template <class T>
class SmartPtr {
template <class Y>
SmartPtr(const SmartPtr<Y> &other) {}
...operator &()..
...operator *()..
...
Swig doesn't seem to recognize that SmartPtr<B> can be copied to
SmartPtr<A> with no problem.
Is there a way to teach it this? Up until now, I find myself using
typemaps...
Thanks,
Bob

Bob Rossi wrote:
> Does anyone have a simple example using boost shared pointers?
> The examples directory has a smartptr test, but that's not
> exactly the same.
See the test case Examples/test-suite/li_boost_shared_ptr.i and
Examples/test-suite/python/li_boost_shared_ptr_runme.py and the
documentation at
http://www.swig.org/Doc2.0/Library.html#Library_std_shared_ptr
William

Juanjo Vega wrote:
> Hello everybody!
>
> I'm trying to fix a problem with swig since a lot of time ago.
>
> I'm wrapping a C++ library to use it from java. This library is pretty
> complex, so we don't want to reimplement algorithms in java. But, the
> problem is that objects are destroyed while execution and I don't now
> why.
>
> I can create them from java, but if I call any of the C++ functions it
> crashes because of NULL pointers. I tried to do some research and I
> discovered that objects destructor is invoked somewhere ¡¡but there is
> no explicit call to it!! =S. And it doesn't happen in all computers,
> which is really weird.
>
> I found some stuff on the internet:
> http://stackoverflow.com/questions/2778332/hot-to-get-rid-of-memory-allocations-deallocations-in-swig-wrappers
>
> But it shows some complex stuff that I don't understand.
>
This is a complex area that requires understanding of how the garbage
collector works and comprehending C++ memory management.
> I also think this problem might have something to do with what they call
> "premature garbage collection":
> http://www.swig.org/Doc1.3/Java.html#java_pgcpp
>
> But, ¿how do I set "swigCMemOwn" in the swig interface, to not allow
> auto garbage collection?
>
You can use %newobject but this may or may not lead to a memory leak
depending on how the C++ API should be used.
Also read http://www.swig.org/Doc2.0/Java.html#Java_memory_management
and the sections it refers to.
William

Am 03.12.2010 19:17, schrieb William S Fulton:
> Oliver Buchtala wrote:
>> Can not get SWIG (target: Java) to use an (existing) proxy of a class
>> when it is behind a typedef'd pointer.
>>
>> Example:
>>
>> class A {...};
>> A* goodFunction();
>>
>> In this case, all is fine: proxy for A exists; the proxied function
>> makes use of A's proxy.
>>
>> typedef A* APtr;
>> APtr badFunction();
>> (typedef replicated in .i-file)
>>
>> Here, badFunction is proxied as
>> SWIGTYPE_p_A badFunction();
>> i.e., typedef resolved, but no proxy anymore...
>>
>> Is this known as a problem or some fault on my side?
>> Is there a workaround other than using the preproc define to branch
>> source code?
> SWIG must parse the declaration of A at some point otherwise it treats
> it as an opaque type, for which there is no proxy and hence a type
> wrapper class.
>
> William
Hi William,
thanks for your response. (I sent this again, as I forgot to set the
user list on cc)
Obviously, I have not described my problem clearly enough.
If I use the pointers in the signatures (without typedef), everythings fine.
But, when I use a typdef for this pointer type and also show SWIG this
definition, these proxies are not resolved.
I can see that SWIG knows about the typedef as it produces a proxy to a
pointer to the class (i.e., SWIGTYPE_p_A).
It seems that SWIG does not map the typedef-type (APtr) to the existing
proxy class (A).
Thanks,
Oliver

Oliver Buchtala wrote:
> Can not get SWIG (target: Java) to use an (existing) proxy of a class
> when it is behind a typedef'd pointer.
>
> Example:
>
> class A {...};
> A* goodFunction();
>
> In this case, all is fine: proxy for A exists; the proxied function
> makes use of A's proxy.
>
> typedef A* APtr;
> APtr badFunction();
> (typedef replicated in .i-file)
>
> Here, badFunction is proxied as
> SWIGTYPE_p_A badFunction();
> i.e., typedef resolved, but no proxy anymore...
>
> Is this known as a problem or some fault on my side?
> Is there a workaround other than using the preproc define to branch
> source code?
SWIG must parse the declaration of A at some point otherwise it treats
it as an opaque type, for which there is no proxy and hence a type
wrapper class.
William

Hi again,
in case I didn't describe my problem clear enough, here is a very clear post
from 2000 about the same problem related to python instead of java:
http://public.kitware.com/pipermail/vtkusers/2000-October/004660.html
There a solution was announced that would allow to generate vtk-wrapped classed
from swig-mangled vtk pointers like:
newObject = vtkObject(<SWIG-mangled-ptr>) I looked around in the vtkjava
wrapper to find such typecast, but couldn't find any.
Is it available for java? If yes, where can I find it?
If no, does a work-around exist?
Thanks
Steffen
----- Original Message ----
From: Steffen Brinkmann <steffenbrinkmann@...>
To: swig-user@...
Sent: Thu, December 2, 2010 11:25:10 PM
Subject: [Swig-user] vtk java SWIG interface, compatible with existing java
bindings
Hi all,
I would like to write a SWIG wrapper for a C++ software package. The package
produces several VTK objects (see http://www.vtk.org) that I would like to
display using the default VTK java bindings
(http://www.vtk.org/Wiki/VTK/Java_Wrapping).
The problem is that the default VTK java bindings are not written in SWIG but in
a custom interface generator. How can I write another wrapper in SWIG that
outputs VTK classes, which are still compatible with the existing bindings?
Thanks
Steffen
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

Hi all,
I would like to write a SWIG wrapper for a C++ software package. The package
produces several VTK objects (see http://www.vtk.org) that I would like to
display using the default VTK java bindings
(http://www.vtk.org/Wiki/VTK/Java_Wrapping).
The problem is that the default VTK java bindings are not written in SWIG but in
a custom interface generator. How can I write another wrapper in SWIG that
outputs VTK classes, which are still compatible with the existing bindings?
Thanks
Steffen

C# frontend generates a lot of file (one for each classes, it seems).
I guess the reason is that it shares code with java frontend. Is there
a way to force generation of a single file? It would keep my visual
studio project clean :)

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details