Nabble - SWIG

Re: C structural "inheritance"?

2009-11-25T15:50:13Z

William S Fulton wrote:

> > Add the following to your interface file:
> >
> > %types(Derived = Base);
> >
> > This will modify the runtime type system to accept a Base * where a Derived *
> is expected with a simple cast from Derived * to Base *. Hopefully that is all
> you need.
>
> Er, correction... accept a Derived * where a Base * is expected. Sorry for
> confusion.

Thanks! "%types()" seems like what I am looking for, but it only does half the
job. It does the C-level conversions, but doesn't set up the language-level
inheritance relationships. For example in the generated Python wrapper file, you
still get this:

class Derived(_object):
...

where you should have this:

class Derived(Base):
...

I'm not sure how the current (1.3.35, anyways) behavior is useful -- is it a bug?
Should this use of %types be documented somewhere?

Thanks for your help,
Sean

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: SWIG <-> Ruby 1.9.1 - std::fstream - program termination

2009-11-25T14:03:27Z

Yes, the problem was that I had have to use the /MD switch unstead of /MT

That means it was my fault (-;

But this problem is still unsolved, isn't it?

http://sourceforge.net/tracker/index.php?func=detail&aid=2859614&group_id=16
45&atid=101645

-----Ursprüngliche Nachricht-----
Von: William S Fulton [mailto:wsf@...]
Gesendet: Mittwoch, 25. November 2009 19:39
An: Sören Freudiger
Cc: swig-user@...
Betreff: Re: [Swig-user] SWIG <-> Ruby 1.9.1 - std::fstream - program
termination

I'd better look at these ruby-1.9.1 problems. The downloads from
http://www.ruby-lang.org/en/downloads/ require ancient versions of vc++.
Is there not a prebuilt visual studio 2008 version anywhere?

William
Sören Freudiger wrote:

> Arghh I dont know what to do
>
> No it doesnt work for 1.8.6 either (Win 2008 Server 64bit.. but ruby,
> my dll and swig are pure 32 bit).
>
> Do I have to include some extra interface file? Do I have to add some
> special preprocessor define (in addition to NT=1 and IMPORT)?
>
>
>
> *Von:* Sören Freudiger [mailto:freud@...]
> *Gesendet:* Donnerstag, 19. November 2009 13:37
> *An:* swig-user@...
> *Betreff:* Re: [Swig-user] SWIG <-> Ruby 1.9.1 - std::fstream - program
> termination
>
>
>
> Okay, here is some extra info I found out:
>
>
>
> It seems to be a SWIG bug.
>
> Implementing the function direct via the ruby C-API works fine (files
> attached)
>
>
>
> Any idea?
>
> (I also send an bug report to swig)
>
>
>
> *Von:* Sören Freudiger [mailto:freud@...]
> *Gesendet:* Donnerstag, 19. November 2009 10:57
> *An:* swig-user@...
> *Betreff:* [Swig-user] SWIG <-> Ruby 1.9.1 - std::fstream - program
> termination
>
>
>
> Hello
>
> Again a huge problem with ruby and C++
>
> Im not sure if this problem is related to SWIG or ruby. But maybe
> anyone has a clue how to fix that issue.
>
>
>
> Thats my source code:
>
>
>
> #include <iostream>
>
> #include <fstream>
>
>
>
> void foo()
>
> {
>
> std::ofstream file("c:/temp/text.txt", std::ios::out);
>
> file<<"hello world"<<std::endl;
>
> file.close();
>
> }
>
>
>
> As you can see, really crazy low level programming.
>
>
>
> The swig interface file:
>
> %module example
>
> %{
>
> #include "example.h"
>
> %}
>
> %include "example.h"
>
>
>
> And the problem:
>
> Platform: Windows (7)
>
> Compiler: cl from VS 2008
>
>
>
> Ruby version 1.8.6. everything works quite well
>
> Ruby version 1.9.1_p129 (installer) program termination at file.close()
>
> Ruby version 1.9.1_p243 (VS 2008 build, 32bit): program termination at
> file.close()
>
> Ruby version 1.9.2. program termination at file.close()
>
>
>
> I tried to debug the problem, but stuck in
>
>
>
> VS9/VC/Include/fstream
>
>
>
> Does anyone know about that error and has a workaround?
>
>
>
>
>
> Best,
>
> SirAnn
>
>
>
>
> ------------------------------------------------------------------------
>
>

----------------------------------------------------------------------------
--
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day
> trial. Simplify your report design, integration and deployment - and focus
on

> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Swig-user mailing list
> Swig-user@...
> https://lists.sourceforge.net/lists/listinfo/swig-user

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: SWIG <-> Ruby 1.9.1 - std::fstream - program termination

2009-11-25T10:39:15Z

I'd better look at these ruby-1.9.1 problems. The downloads from
http://www.ruby-lang.org/en/downloads/ require ancient versions of vc++.
Is there not a prebuilt visual studio 2008 version anywhere?

William
Sören Freudiger wrote:

> Arghh… I don’t know what to do…
>
> No it doesn’t work for 1.8.6 either (Win 2008 Server 64bit.. but ruby,
> my dll and swig are pure 32 bit).
>
> Do I have to include some extra interface file? Do I have to add some
> special preprocessor define (in addition to NT=1 and IMPORT)?
>
>
>
> *Von:* Sören Freudiger [mailto:freud@...]
> *Gesendet:* Donnerstag, 19. November 2009 13:37
> *An:* swig-user@...
> *Betreff:* Re: [Swig-user] SWIG <-> Ruby 1.9.1 - std::fstream - program
> termination
>
>
>
> Okay, here is some extra info I found out:
>
>
>
> It seems to be a SWIG bug.
>
> Implementing the function direct via the ruby C-API works fine (files
> attached)
>
>
>
> Any idea?
>
> (I also send an bug report to swig)
>
>
>
> *Von:* Sören Freudiger [mailto:freud@...]
> *Gesendet:* Donnerstag, 19. November 2009 10:57
> *An:* swig-user@...
> *Betreff:* [Swig-user] SWIG <-> Ruby 1.9.1 - std::fstream - program
> termination
>
>
>
> Hello
>
> Again a huge problem with ruby and C++
>
> I’m not sure if this problem is related to SWIG or ruby. But maybe
> anyone has a clue how to fix that issue.
>
>
>
> That’s’ my source code:
>
>
>
> #include <iostream>
>
> #include <fstream>
>
>
>
> void foo()
>
> {
>
> std::ofstream file("c:/temp/text.txt", std::ios::out);
>
> file<<"hello world"<<std::endl;
>
> file.close();
>
> }
>
>
>
> As you can see, really crazy low level programming.
>
>
>
> The swig interface file:
>
> %module example
>
> %{
>
> #include "example.h"
>
> %}
>
> %include "example.h"
>
>
>
> And the problem:
>
> Platform: Windows (7)
>
> Compiler: cl from VS 2008
>
>
>
> Ruby version 1.8.6. everything works quite well
>
> Ruby version 1.9.1_p129 (installer) program termination at file.close()
>
> Ruby version 1.9.1_p243 (VS 2008 build, 32bit): program termination at
> file.close()
>
> Ruby version 1.9.2. program termination at file.close()
>
>
>
> I tried to debug the problem, but stuck in
>
>
>
> VS9/VC/Include/fstream
>
>
>
> Does anyone know about that error and has a workaround?
>
>
>
>
>
> Best,
>
> SirAnn
>
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Swig-user mailing list
> Swig-user@...
> https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: pure virtual function and inheritence

2009-11-25T08:03:30Z

Also, note that the problem seems to be that SWIG does not see the base
class in which the pure virtual is declared. You might want to fix that
instead; otherwise, the wrappers for derived classes may be missing
methods.

Josh

On Wed, 25 Nov 2009, Juan Manuel Alvarez wrote:

> Try using:
> %nodefaultctor gdcm::ImageCodec;
>
> Hope this helps!
> Juan M.
>
> On Wed, Nov 25, 2009 at 10:34 AM, Mathieu Malaterre
> <mathieu.malaterre@...> wrote:
>> Hi there,
>>
>> I am trying to wrap a class that have some virtual function. It
>> seems swig is still trying to generate constructor for it:
>>
>> /home/mathieu/Perso/gdcm/debug-gcc/Wrapping/Csharp/gdcmCSHARP_wrap.cxx:
>> In function ‘void* CSharp_new_ImageCodec()’:
>> /home/mathieu/Perso/gdcm/debug-gcc/Wrapping/Csharp/gdcmCSHARP_wrap.cxx:17334:
>> error: cannot allocate an object of abstract type ‘gdcm::ImageCodec’
>> /home/mathieu/Perso/gdcm/trunk/Source/MediaStorageAndFileFormat/gdcmImageCodec.h:32:
>> note: because the following virtual functions are pure within
>> ‘gdcm::ImageCodec’:
>> /home/mathieu/Perso/gdcm/trunk/Source/MediaStorageAndFileFormat/gdcmCoder.h:35:
>> note: virtual bool gdcm::Coder::CanCode(const gdcm::TransferSyntax&)
>> const
>> make[2]: *** [Wrapping/Csharp/CMakeFiles/gdcmsharpglue.dir/gdcmCSHARP_wrap.cxx.o]
>> Error 1
>> make[1]: *** [Wrapping/Csharp/CMakeFiles/gdcmsharpglue.dir/all] Error 2
>>
>>
>> How I prevent from creating a cstor for class that inherits pure
>> virtual function ?
>>
>> Thanks,
>> --
>> Mathieu
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Swig-user mailing list
>> Swig-user@...
>> https://lists.sourceforge.net/lists/listinfo/swig-user
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Swig-user mailing list
> Swig-user@...
> https://lists.sourceforge.net/lists/listinfo/swig-user
>

From forum: swig-user

Re: pure virtual function and inheritence

2009-11-25T06:17:31Z

Try using:
%nodefaultctor gdcm::ImageCodec;

Hope this helps!
Juan M.

On Wed, Nov 25, 2009 at 10:34 AM, Mathieu Malaterre
<mathieu.malaterre@...> wrote:

> Hi there,
>
> I am trying to wrap a class that have some virtual function. It
> seems swig is still trying to generate constructor for it:
>
> /home/mathieu/Perso/gdcm/debug-gcc/Wrapping/Csharp/gdcmCSHARP_wrap.cxx:
> In function ‘void* CSharp_new_ImageCodec()’:
> /home/mathieu/Perso/gdcm/debug-gcc/Wrapping/Csharp/gdcmCSHARP_wrap.cxx:17334:
> error: cannot allocate an object of abstract type ‘gdcm::ImageCodec’
> /home/mathieu/Perso/gdcm/trunk/Source/MediaStorageAndFileFormat/gdcmImageCodec.h:32:
> note: because the following virtual functions are pure within
> ‘gdcm::ImageCodec’:
> /home/mathieu/Perso/gdcm/trunk/Source/MediaStorageAndFileFormat/gdcmCoder.h:35:
> note: virtual bool gdcm::Coder::CanCode(const gdcm::TransferSyntax&)
> const
> make[2]: *** [Wrapping/Csharp/CMakeFiles/gdcmsharpglue.dir/gdcmCSHARP_wrap.cxx.o]
> Error 1
> make[1]: *** [Wrapping/Csharp/CMakeFiles/gdcmsharpglue.dir/all] Error 2
>
>
> How I prevent from creating a cstor for class that inherits pure
> virtual function ?
>
> Thanks,
> --
> Mathieu
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Swig-user mailing list
> Swig-user@...
> https://lists.sourceforge.net/lists/listinfo/swig-user
>

From forum: swig-user

pure virtual function and inheritence

2009-11-25T05:34:38Z

Hi there,

I am trying to wrap a class that have some virtual function. It
seems swig is still trying to generate constructor for it:

/home/mathieu/Perso/gdcm/debug-gcc/Wrapping/Csharp/gdcmCSHARP_wrap.cxx:
In function ‘void* CSharp_new_ImageCodec()’:
/home/mathieu/Perso/gdcm/debug-gcc/Wrapping/Csharp/gdcmCSHARP_wrap.cxx:17334:
error: cannot allocate an object of abstract type ‘gdcm::ImageCodec’
/home/mathieu/Perso/gdcm/trunk/Source/MediaStorageAndFileFormat/gdcmImageCodec.h:32:
note: because the following virtual functions are pure within
‘gdcm::ImageCodec’:
/home/mathieu/Perso/gdcm/trunk/Source/MediaStorageAndFileFormat/gdcmCoder.h:35:
note: virtual bool gdcm::Coder::CanCode(const gdcm::TransferSyntax&)
const
make[2]: *** [Wrapping/Csharp/CMakeFiles/gdcmsharpglue.dir/gdcmCSHARP_wrap.cxx.o]
Error 1
make[1]: *** [Wrapping/Csharp/CMakeFiles/gdcmsharpglue.dir/all] Error 2

How I prevent from creating a cstor for class that inherits pure
virtual function ?

Thanks,
--
Mathieu

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: wrapping template classes which wrap stl collections

2009-11-24T17:15:18Z

Anton Lauridsen wrote:

> Hi
>
> I thought I was pretty good at c++, but I've stumpled upon something I
> don't quite understand, first a little back-ground:
>
> I'm trying to revive the Swig bindings for the Ogre3d rendering engine,
> things are progressing nicely, but, I've stumpled upon a problem:
>
> The Ogre3D library comes with the ability to track memory allocations,
> and report leaks when exiting the program, naturally I'd like to use
> that feature in order to ensure that the wrappers doesn't leak.
>
> for stl collections, this is done by wrapping the stl collections in a
> template class, I've provided a small sample here:
>
> //for stl containter
> namespace Ogre
> {
> template <typename T, typename A = STLAllocator<T, GeneralAllocPolicy>
> struct deque
> {
> #if OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR
> typedef typename std::deque<T, A> type;
> #else
> typedef typename std::deque<T> type;
> #endif
> };
>
> template <typename T, typename A = STLAllocator<T, GeneralAllocPolicy>
> struct vector
> {
> #if OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR
> typedef typename std::vector<T, A> type;
> #else
> typedef typename std::vector<T> type;
> #endif
> };
>
> template <typename T, typename A = STLAllocator<T, GeneralAllocPolicy>
> struct list
> {
> #if OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR
> typedef typename std::list<T, A> type;
> #else
> typedef typename std::list<T> type;
> #endif
> };
>
> template <typename T, typename P = std::less<T>, typename A =
> STLAllocator<T, GeneralAllocPolicy> >
> struct set
> {
> #if OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR
> typedef typename std::set<T, P, A> type;
> #else
> typedef typename std::set<T, P> type;
> #endif
> };
>
> template <typename K, typename V, typename P = std::less<K>, typename A
> = STLAllocator<std::pair<const K, V>, GeneralAllocPolicy> >
> struct map
> {
> #if OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR
> typedef typename std::map<K, V, P, A> type;
> #else
> typedef typename std::map<K, V, P> type;
> #endif
> };
>
> template <typename K, typename V, typename P = std::less<K>, typename A
> = STLAllocator<std::pair<const K, V>, GeneralAllocPolicy> >
> struct multimap
> {
> #if OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR
> typedef typename std::multimap<K, V, P, A> type;
> #else
> typedef typename std::multimap<K, V, P> type;
> #endif
> };
>
> } // Ogre
>
>
> The STLAllocator<....> has some defines, taking care of the different
> allocation scenarios, i.e. whether memory tracking is enabled or not.
>
> here comes the part which I don't really understand:
>
> typedef map<String, String>::type NameValuePairList;
>
> I didn't even know that "::type" was legal c++
>

It is just a typedef of another type. You see this a lot in the STL, for
example the containers have value_type, pointer, const_reference etc.

> I tried to wrap it using:
> %template(NameValuePairList) Ogre::map<Ogre::String,
> Ogre::String>::type;
>
> but Swig doesn't like the "::type" either, if I leave it out,
>
The syntax for %template must match that of a template, so a typedef to
a template does not work. This is a limitation, but possibly this can be
improved in the future. So for now you have to provide the exact
template instantiation:

#if OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR
%template(NameValuePairList) std::map<K, V, P, A>;
#else
%template(NameValuePairList) std::map<K, V, P>;
#endif

or you could probably do something with the preprocessor to make this
less tedious for all your templates:

#if OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR
# define OGRE_ALLOCATORS ,A
#else
# define OGRE_ALLOCATORS
#endif

%template(NameValuePairList) std::map<K, V, P OGRE_ALLOCATORS >;

> void f(const Ogre::NameValuePairList *p);
>
> gets wrapped as:
>
> public void
> f(SWIGTYPE_p_Ogre__mapT_Ogre__String_Ogre__String_std__lessT_Ogre__String_t_STLAllocatorT_std__pairT_Ogre__String_const_Ogre__String_t_Ogre__GeneralAllocPolicy_t_t__type p)
>
> I'd prefer the signature to be:
> public void f(NameValuePairList p);
>
> Is there a simple way to achieve this or do I need to manually define
> the wrappers?
>
> Any help would be greatly appreciated, especially this doing this
> manually would be quite a daunting task, given all the places that
> collections are used.

Hope that helps.

William

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: Generating C# Interfaces for Proxy Classes

2009-11-24T16:35:37Z

There was an attempt at adding a feature into SWIG to do this more
easily. If you search the mailing list for some posts by zhiyang jiang
you'll get some more info.

William

Juan Manuel Alvarez wrote:

> As far as I know, you will have to do it by hand.
>
> Here is an example:
>
> %nodefaultctor IMyInterface;
> %typemap(csbase, replace="1") IMyInterface "";
> %typemap(csclassmodifiers) IMyInterface "interface";
> %typemap(csbody) IMyInterface "";
> %typemap(csfinalize) IMyInterface "";
> %typemap(csdestruct) IMyInterface "";
> %typemap(cscode) IMyInterface
> %{
> // interface declaration here
> %}
>
> %inline %{
> class IMyInterface{};
> %}
>
> Then you just have to change the base of your wrapped class like this:
> %typemap(csinterfaces) MyClass "IMyInterface, IDisposable";
>
> Hope this helps!
> Juan M.
>
>
> On Mon, Nov 23, 2009 at 3:44 AM, Josh Rivers <josh@...> wrote:
>> Hi All,
>>
>> I've done some searching and seen mention of this previously, but I'm not
>> clear on whether a solution was ever implemented/found.
>>
>> I'd like interfaces that match my generated proxy types to be generated
>> alongside the proxy classes (so that I can use mocking tools easily to
>> generate mock objects). Can SWIG be cajoled into generating a matching
>> interface for each proxy class?
>>
>> Thanks,
>> Josh
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Swig-user mailing list
>> Swig-user@...
>> https://lists.sourceforge.net/lists/listinfo/swig-user
>>
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Swig-user mailing list
> Swig-user@...
> https://lists.sourceforge.net/lists/listinfo/swig-user
>

From forum: swig-user

Re: C#: problem with dispose method when using csbase and replace="1"

2009-11-24T16:26:14Z

Anton Lauridsen wrote:

> Hi
>
> I'm trying to redefine the base class of a wrapped class in c#, using:
>
> %typemap(csbase, replace="1") osgViewer::View "Osg.View";
>
> which works great, except I'm having issues mapping the corresponding
> "Dispose" methods, when replacing the base, the "derived" flag in
> csharp.cxx (line 1540) is assigned "false", which causes the code for
> generating the "csdestruct" method to insert a "virtual" keyword.
> Wouldn't it be better to have the "derived" flag remain true when "%
> typemap(csbase, replace="1")" is specified, which would not remove the
> issue with the inserted "derived" flag but also reduce the complexity of
> specifying a new base class, since most of the "_derived" typemaps will
> often match what is needed when overriding the base class. I.e.
> instead of:
>
> ----
> if (purebase_replace) {
> wanted_base = pure_baseclass;
> derived = false;
> Delete(baseclass);
> baseclass = NULL;
> if (purebase_notderived)
> Swig_error(input_file, line_number, "The csbase typemap for
> proxy %s must contain just one of the 'replace' or 'notderived'
> attributes.\n", typemap_lookup_type);
> } else if (Len(pure_baseclass) > 0 && Len(baseclass) > 0) {
> Swig_warning(WARN_CSHARP_MULTIPLE_INHERITANCE, input_file,
> line_number,
> "Warning for %s proxy: Base %s ignored. Multiple inheritance is not
> supported in C#. "
> "Perhaps you need one of the 'replace' or 'notderived' attributes
> in the csbase typemap?\n", typemap_lookup_type, pure_baseclass);
> }
> ----
> use:
> ----
> if (purebase_replace) {
> wanted_base = pure_baseclass;
> Delete(baseclass);
> baseclass = NULL;
> if (purebase_notderived)
> Swig_error(input_file, line_number, "The csbase typemap for
> proxy %s must contain just one of the 'replace' or 'notderived'
> attributes.\n", typemap_lookup_type);
> else
> derived = false;
> } else if (Len(pure_baseclass) > 0 && Len(baseclass) > 0) {
> Swig_warning(WARN_CSHARP_MULTIPLE_INHERITANCE, input_file,
> line_number,
> "Warning for %s proxy: Base %s ignored. Multiple inheritance is not
> supported in C#. "
> "Perhaps you need one of the 'replace' or 'notderived' attributes
> in the csbase typemap?\n", typemap_lookup_type, pure_baseclass);
> }
> ----
>

The only difference I can see above is that derived is set to false (as
before) under an error condition, so I don't get what the difference is
really unless there is an error condition... but then SWIG errors out,
so the wrappers fail. BTW, a patch generated from diff is a lot easier
to follow when submitting code suggestions.

> That way the typemap will still operate as if it the class was
> inherited, except when the "notderived" derived flag has been specified.
>

If the replace resulted in a 'override' rather than 'virtual' Dispose
method, then the base class class would have to implement the Dispose
method plus the swigCMemOwn flag. Seems more sensible to leave all this
kerfuffle to the SWIG generated classes. Also if you want you can remove
the csdestruct typemaps and put Dispose methods into the cscode typemap.

If I've missed something, I suggest you post a cut down use case of what
you want, so I can see what is c++ and what is c#.

William

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: Passing arrays of objects between C++ and C#

2009-11-24T14:54:35Z

eodabash wrote:

> We're currently dealing with a pretty tricky situation at my company trying
> to wrap a set of C++ classes for C# with SWIG. The problems we're running
> into mainly revolve around passing C++ structs or arrays of structs back and
> forth between C++ and C#.
>
> For example, suppose we have a simple type that looks like this in C++
>
> struct Point
> {
> float x,y,z;
> };
>
> We need to be able to do the following:
>
> - Pass a single Point from C# to C++
> - Pass an array of Points from C# to C++
> - Pass a pointer to a single Point from C++ to C# (to a C# override of a C++
> virtual function using the directors mechanism)
> - Pass an array of Points from C++ to C# through a virtual function override
> (as in the previous case)
>
> I'm not sure if our approach here should be to work with a SWIG proxy
> version of the Point class, since an array of these proxy objects is really
> just an array of pointers to C++ objects, not an array of sequential C++
> objects in memory, and for C++ to send an array of Points to C# we would
> need to really initialize an array of proxy objects, assign each one to an
> element in the C++ array, and then pass it on to the actual C# user code.
> Then we would also have to do something similar going the other way.
>
> The other option I thought of is to (somehow) not let SWIG define a proxy
> Point class and instead define something like:
>
> [StructLayout(LayoutKind.Sequential)]
> public struct Point
> {
> public float x;
> public float y;
> public float z;
> }
>
> And hopefully figure out a way to use this in C# so we can directly work
> with C++ input objects, and directly pass a pointer to an array of these
> structs from C# to C++ (rather than making copies).
>
> So I guess I'm wondering if there's a canonical solution to this type of
> problem, or if we're in uncharted territory here, and are we maybe asking
> too much of SWIG?
>
> Thanks in advance for any suggestions,
>
> Evan
>

With regard to marshalling structs, take a look at this old thread:
http://thread.gmane.org/gmane.comp.programming.swig/11088
http://thread.gmane.org/gmane.comp.programming.swig/12887

I'm not sure about the arrays without some thought, but SWIG really
ought to have some features and examples for marshalling C# structs as
currently there is no simple easy to use feature for this type of
marshalling.

William

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: Temporarily disable std_vector.i?

2009-11-24T14:43:56Z

Russell Owen wrote:
> Thank you very much for fixing this bug. It will be a huge help to our
> project. (I can confirm that SWIG 1.3.40 fixes the problem for me; I was
> at 1.3.36).
>
> Could you please expand a bit on your statement: "Yes, it is better to
> use %template with a class type (Bar in this case) once SWIG has
> parsed."? I'm not sure what you are recommending.
>
I'm trying to say that the order of your statements is important. SWIG
must parse Bar before you use Bar in %template. This way SWIG knows all
the type information before you use the types.

> I see that the warnings about an overlaoded method is still printed, but
> I can't see anything to warn about anymore. Should I report it as a
> minor bug?
>
The warning is there because std::vector of any type is given the same
precedence in the overloading ranking mechanism. Actually I don't know
if it is a problem or not! Try it out and see if you can get both the
overloaded constructors to work. Normally you get this warning when a
multiple C++ types have just one equivalent in the target language, eg
Foo*, Foo&, const Foo*, const Foo& etc.

> swigtest.h:24: Warning(509): Overloaded method
> test::Foo::Foo(std::vector< test::Bar,std::allocator< test::Bar > >
> const &) is shadowed by test::Foo::Foo(std::vector< int,std::allocator<
> int > > const &) at swigtest.h:18.
>

William

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: Temporarily disable std_vector.i?

2009-11-24T14:32:22Z

Thank you very much for fixing this bug. It will be a huge help to our
project. (I can confirm that SWIG 1.3.40 fixes the problem for me; I
was at 1.3.36).

Could you please expand a bit on your statement: "Yes, it is better to
use %template with a class type (Bar in this case) once SWIG has
parsed."? I'm not sure what you are recommending.

I see that the warnings about an overlaoded method is still printed,
but I can't see anything to warn about anymore. Should I report it as
a minor bug?

swigtest.h:24: Warning(509): Overloaded method
test::Foo::Foo(std::vector< test::Bar,std::allocator< test::Bar > >
const &) is shadowed by test::Foo::Foo(std::vector<
int,std::allocator< int > > const &) at swigtest.h:18.

-- Russell

On Nov 24, 2009, at 1:42 PM, William S Fulton wrote:

> Russell E. Owen wrote:
>> In article <4AEDF6C0.1070902@...>,
>> William S Fulton <wsf@...> wrote:
>> On Nov 1, 2009, at 12:59 PM, William S Fulton wrote:
>>> Russell E. Owen wrote:
>>>> I am having some issues with shadowed constructors that I think
>>>> are caused by using std_vector.i
>>>> Some of our classes have multiple constructors such as this:
>>>> Foo::Foo(std::vector<double> &values)
>>>> Foo::Foo(std::vector<boost::shared_ptr<FancyClass> > &fancyClasses)
>>>> and our SWIG file wraps the class Foo and also wraps the
>>>> arguments as so:
>>>> %template(VectorDouble) std::vector<double>;
>>>> %template
>>>> (VectorFancyClass)std::vector<boost::shared_ptr<FancyClass> >;
>>>> SWIG complains that the latter constructor is shadowed by the
>>>> former.
>>>> As far as I can tell this is because both std::vector<double> and
>>>> std::vector<boost::shared_ptr<some fancyclass> > have been
>>>> templated after including std_vector.i. Thus SWIG is trying to
>>>> support all of the following forms of Foo constructor:
>>>> 1) an explicitly constructed VectorDouble
>>>> 2) a python list of doubles (due to std_vector.i and much
>>>> appreciated)
>>>> 3) an explicitly constructed VectorFancyClass
>>>> 4) a python list of FancyClasses (due to std_vector.i and not
>>>> necessary)
>>>> and the two python list versions (2 and 4) are colliding with
>>>> each other.
>>>> I suspect that both Foo constructors are actually available, and
>>>> that only case (4) is unavailable. If so, we can live with it.
>>>> But I would rather explicitly disable std_vector.i for
>>>> VectorFancyClass if there is some easy way to do this.
>>>> I realize I could just include std_vector.i at the very end, but
>>>> that happens to be a headache due to the way we're including it
>>>> right now (in a common .i file shared by all others -- maybe that
>>>> is a mistake).
>>>> Anyone have any suggestions?
>>> I don't see why SWIG is doing this and I can't replicate this
>>> problem. I suggest you post a complete standalone example
>>> demonstrating it...
>> Here is my example (slightly longer than you requested, but short
>> enough, I trust, to serve)
>> *** swigtest.h ***
>> #include <iostream>
>> #include <vector>
>> namespace test {
>> class Bar {
>> public:
>> explicit Bar::Bar(int val=0) : intVal(val) {};
>> int intVal;
>> };
>> class Foo {
>> public:
>> explicit Foo::Foo(std::vector<int> const &intVec) {
>> std::cout << "Foo(";
>> for (size_t ind = 0; ind < intVec.size(); ++ind)
>> std::cout << intVec[ind] << ", ";
>> std::cout << ") constructor" << std::endl;
>> }
>> explicit Foo::Foo(std::vector<Bar> const &barVec) {
>> std::cout << "Foo(";
>> for (size_t ind = 0; ind < barVec.size(); ++ind)
>> std::cout << "Bar(" << barVec[ind].intVal << "), ";
>> std::cout << ") constructor" << std::endl;
>> }
>> };
>> }
>> *** swigtest.i ***
>> %module swigtest
>> %{
>> #include "swigtest.h"
>> %}
>> %include "std_vector.i"
>> %template(IntVec) std::vector<int>;
>> %template(BarVec) std::vector<test::Bar>;
>> %include "swigtest.h"
>> *** runtest.py ***
>> #!/usr/bin/env python
>> # run swigtest
>> import swigtest
>> # these should work
>> iv = swigtest.IntVec()
>> iv.append(1)
>> iv.append(2)
>> iv.append(3)
>> swigtest.Foo(iv)
>> swigtest.Foo([1, 2, 3])
>> bv = swigtest.BarVec()
>> bv.append(swigtest.Bar(1))
>> bv.append(swigtest.Bar(2))
>> bv.append(swigtest.Bar(3))
>> swigtest.Foo(bv)
>> swigtest.Foo([swigtest.Bar(1), swigtest.Bar(2), swigtest.Bar(3)])
>> # this is commented out because it aborts or send Foo garbage
>> # it may or may not be relevant to the problem being discussed
>> # I suspect the abort or garbage is a swig bug in any case
>> #swigtest.Foo([1, 2, swigtest.Bar(3)])
>> #swigtest.Foo([swigtest.Bar(1), swigtest.Bar(2), 3])
>> When I build it I get a warning about a shadowed method (see
>> appended log). But when I run the test code it works as desired.
>> I also found that if I simply move the swigtest.i line:
>> %template(BarVec) std::vector<test::Bar>;
>> after the line:
>> %include "swigtest.h"
>> then the problem goes away (though one can no longer provide a
>> plain python list of Bar). Also it solves the problem from the
>> commented-out lines of the test code: instead of aborting or
>> sending Foo garbage, swig correctly detects the mixed type list and
>> rejects it!
> Yes, it is better to use %template with a class type (Bar in this
> case) once SWIG has parsed.
>
>> I would prefer a solution that allows a plain list of Bar and
>> correctly rejects lists of mixed types. But barring such a
>> solution, simply templating the list of Bar at the end will do.
> swig-1.3.37 has a fix for this problem, as per the CHANGES entry:
>
> 2008-11-28: wsfulton
> [UTL] Fix #2080497. Some incorrect acceptance of types in the
> STL, eg a double * element
> passed into a vector<int *> constructor would be accepted, but
> the ensuing behaviour
> was undefined. Now the type conversion correctly raises an
> exception.
>
> I tried the latest version using your commented out lines above
> passing in vectors of mixed types and get:
>
> Foo(1, 2, 3, ) constructor
> Foo(1, 2, 3, ) constructor
> Foo(Bar(1), Bar(2), Bar(3), ) constructor
> Foo(Bar(1), Bar(2), Bar(3), ) constructor
> Traceback (most recent call last):
> File "./runme.py", line 26, in <module>
> example.Foo([1, 2, example.Bar(3)])
> File "/home/william/swig/trunk/Examples/william/temp9/example.py",
> line 217, in __init__
> this = _example.new_Foo(*args)
> NotImplementedError: Wrong number of arguments for overloaded
> function 'new_Foo'.
> Possible C/C++ prototypes are:
> test::Foo(std::vector< int,std::allocator< int > > const &)
> test::Foo(std::vector< test::Bar,std::allocator< test::Bar > >
> const &)
>
>
> PS I also had to correct this problem in the constructors, but I
> don't think it will affect the SWIG output:
>
> g++ -c -fpic example_wrap.cxx example.cxx -I/usr/include/
> python2.5 -I/usr/lib/python2.5/config
> In file included from example_wrap.cxx:2801:
> swigtest.h:8: error: extra qualification ‘test::Bar::’ on member ‘Bar’
> swigtest.h:14: error: extra qualification ‘test::Foo::’ on member
> ‘Foo’
> swigtest.h:20: error: extra qualification ‘test::Foo::’ on member
> ‘Foo’
>

From forum: swig-user

Re: C structural "inheritance"?

2009-11-24T14:22:09Z

William S Fulton wrote:

> Sean wrote:
>> I'm wrapping some code that mimics inheritance with C structs via
>> structural inheritance, e.g.
>>
>> struct Base {
>> int x;
>> };
>>
>> struct Derived {
>> int x;
>> int y;
>> };
>>
>> I would like to tell SWIG to treat Derived as a subclass of Base. My
>> current solution is to post-process SWIG output to (1) add appropriate
>> entries to the swig_cast_info for the base type, and (2) create
>> inheritance relationships between the scripting language wrapper
>> classes (e.g. add an entry to @ISA in Perl). This seems gross and
>> fragile, though; does anyone here know a better way?
>>
>
> Add the following to your interface file:
>
> %types(Derived = Base);
>
> This will modify the runtime type system to accept a Base * where a
> Derived * is expected with a simple cast from Derived * to Base *.
> Hopefully that is all you need.

Er, correction... accept a Derived * where a Base * is expected. Sorry
for confusion.

William

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: C structural "inheritance"?

2009-11-24T14:15:20Z

Sean wrote:

> I'm wrapping some code that mimics inheritance with C structs via structural inheritance, e.g.
>
> struct Base {
> int x;
> };
>
> struct Derived {
> int x;
> int y;
> };
>
> I would like to tell SWIG to treat Derived as a subclass of Base. My current solution is to post-process SWIG output to (1) add appropriate entries to the swig_cast_info for the base type, and (2) create inheritance relationships between the scripting language wrapper classes (e.g. add an entry to @ISA in Perl). This seems gross and fragile, though; does anyone here know a better way?
>

Add the following to your interface file:

%types(Derived = Base);

This will modify the runtime type system to accept a Base * where a
Derived * is expected with a simple cast from Derived * to Base *.
Hopefully that is all you need.

William

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: Problems with shared_ptr and Python

2009-11-24T13:43:06Z

You have three problems with your interface file. Here is the corrected
version which works:

%include "boost_shared_ptr.i"
SWIG_SHARED_PTR(Foo, Foo)

%inline %{
#include <boost/shared_ptr.hpp>
struct Foo {};
void test1(boost::shared_ptr<Foo> f) {}
void test2(boost::shared_ptr<Foo> f) {}
%}

William

andreas.held@... wrote:

> Hi William
>
> This is my interface file boost_example.i:
> %module example
>
> // For plain classes, do not use for derived classes
> %include "boost_shared_ptr.i"
> MY_SWIG_SHARED_PTR(Foo, Foo)
>
> struct Foo {};
> void test1(shared_ptr<Foo> f) {}
> void test2(boost::shared_ptr<Foo> f) {}
>
> -----------------------------------------------------------
>
> My command line:
>
> $ swig -c++ -python boost_example.i
> boost_example.i(6): Error: Syntax error in input(1).
>
> I do get the same results whether I run the command from a MSYS shell or from the Windows Power Shell, obviously, both on Windows (XP to be accurate).
>
> Finally, the version I am using:
> $ swig -version
>
> SWIG Version 1.3.40
>
> Compiled with i586-mingw32msvc-g++ [i686-pc-linux-gnu]
> Please see http://www.swig.org for reporting bugs and further information
>
>
> Best regards and thanks for your help.
>
> Andreas
> ---- William S Fulton <wsf@...> schrieb:
>> andreas.held@... wrote:
>>> Hi William
>>>
>>> Thank you for your quick reply. Sorry for my mistake in the command line. As you pointed out, the correct command line should be:
>>> swig -c++ -python example.i
>>>
>>> Still, even with that command line I do get the same error. I now stronly suspect that something is wrong with my boost installation.
>> It is impossible for SWIG to be affected by your boost installation
>> unless you tell it to via an include path (the -I option). However,
>> there might be a problem when your c++ compiler compiles the generated
>> code, as that will then use your boost installation.
>>
>>> Anyway, I have now found a way around my problem by using
>>> %template
>>>
>> I don't know what you are doing wrong, but the SWIG_SHARED_PTR macro
>> invokes the %template directive for you. I think you need to post your
>> non-working example again.
>>
>> William
>
>

From forum: swig-user

Re: Temporarily disable std_vector.i?

2009-11-24T13:42:39Z

Russell E. Owen wrote:

> In article <4AEDF6C0.1070902@...>,
> William S Fulton <wsf@...> wrote:
>
>
> On Nov 1, 2009, at 12:59 PM, William S Fulton wrote:
>
>> Russell E. Owen wrote:
>>> I am having some issues with shadowed constructors that I think are caused
>>> by
>>> using std_vector.i
>>> Some of our classes have multiple constructors such as this:
>>> Foo::Foo(std::vector<double> &values)
>>> Foo::Foo(std::vector<boost::shared_ptr<FancyClass> > &fancyClasses)
>>> and our SWIG file wraps the class Foo and also wraps the arguments as so:
>>> %template(VectorDouble) std::vector<double>;
>>> %template(VectorFancyClass)std::vector<boost::shared_ptr<FancyClass> >;
>>> SWIG complains that the latter constructor is shadowed by the former.
>>> As far as I can tell this is because both std::vector<double> and
>>> std::vector<boost::shared_ptr<some fancyclass> > have been templated after
>>> including std_vector.i. Thus SWIG is trying to support all of the following
>>> forms of Foo constructor:
>>> 1) an explicitly constructed VectorDouble
>>> 2) a python list of doubles (due to std_vector.i and much appreciated)
>>> 3) an explicitly constructed VectorFancyClass
>>> 4) a python list of FancyClasses (due to std_vector.i and not necessary)
>>> and the two python list versions (2 and 4) are colliding with each other.
>>> I suspect that both Foo constructors are actually available, and that only
>>> case (4) is unavailable. If so, we can live with it. But I would rather
>>> explicitly disable std_vector.i for VectorFancyClass if there is some easy
>>> way to do this.
>>> I realize I could just include std_vector.i at the very end, but that
>>> happens
>>> to be a headache due to the way we're including it right now (in a common
>>> .i
>>> file shared by all others -- maybe that is a mistake).
>>> Anyone have any suggestions?
>> I don't see why SWIG is doing this and I can't replicate this problem. I
>> suggest you post a complete standalone example demonstrating it...
>
> Here is my example (slightly longer than you requested, but short
> enough, I trust, to serve)
>
> *** swigtest.h ***
>
> #include <iostream>
> #include <vector>
>
> namespace test {
> class Bar {
> public:
> explicit Bar::Bar(int val=0) : intVal(val) {};
> int intVal;
> };
>
> class Foo {
> public:
> explicit Foo::Foo(std::vector<int> const &intVec) {
> std::cout << "Foo(";
> for (size_t ind = 0; ind < intVec.size(); ++ind)
> std::cout << intVec[ind] << ", ";
> std::cout << ") constructor" << std::endl;
> }
> explicit Foo::Foo(std::vector<Bar> const &barVec) {
> std::cout << "Foo(";
> for (size_t ind = 0; ind < barVec.size(); ++ind)
> std::cout << "Bar(" << barVec[ind].intVal << "), ";
> std::cout << ") constructor" << std::endl;
> }
> };
>
> }
>
> *** swigtest.i ***
>
> %module swigtest
> %{
> #include "swigtest.h"
> %}
>
> %include "std_vector.i"
> %template(IntVec) std::vector<int>;
> %template(BarVec) std::vector<test::Bar>;
> %include "swigtest.h"
>
>
> *** runtest.py ***
>
> #!/usr/bin/env python
> # run swigtest
>
> import swigtest
>
> # these should work
> iv = swigtest.IntVec()
> iv.append(1)
> iv.append(2)
> iv.append(3)
> swigtest.Foo(iv)
>
> swigtest.Foo([1, 2, 3])
>
> bv = swigtest.BarVec()
> bv.append(swigtest.Bar(1))
> bv.append(swigtest.Bar(2))
> bv.append(swigtest.Bar(3))
> swigtest.Foo(bv)
>
> swigtest.Foo([swigtest.Bar(1), swigtest.Bar(2), swigtest.Bar(3)])
>
> # this is commented out because it aborts or send Foo garbage
> # it may or may not be relevant to the problem being discussed
> # I suspect the abort or garbage is a swig bug in any case
> #swigtest.Foo([1, 2, swigtest.Bar(3)])
> #swigtest.Foo([swigtest.Bar(1), swigtest.Bar(2), 3])
>
> When I build it I get a warning about a shadowed method (see appended
> log). But when I run the test code it works as desired.
>
>
>
> I also found that if I simply move the swigtest.i line:
> %template(BarVec) std::vector<test::Bar>;
> after the line:
> %include "swigtest.h"
> then the problem goes away (though one can no longer provide a plain
> python list of Bar). Also it solves the problem from the commented-out
> lines of the test code: instead of aborting or sending Foo garbage, swig
> correctly detects the mixed type list and rejects it!
>

Yes, it is better to use %template with a class type (Bar in this case)
once SWIG has parsed.

> I would prefer a solution that allows a plain list of Bar and correctly
> rejects lists of mixed types. But barring such a solution, simply
> templating the list of Bar at the end will do.
>
swig-1.3.37 has a fix for this problem, as per the CHANGES entry:

2008-11-28: wsfulton
[UTL] Fix #2080497. Some incorrect acceptance of types in the STL,
eg a double * element
passed into a vector<int *> constructor would be accepted, but the
ensuing behaviour
was undefined. Now the type conversion correctly raises an exception.

I tried the latest version using your commented out lines above passing
in vectors of mixed types and get:

Foo(1, 2, 3, ) constructor
Foo(1, 2, 3, ) constructor
Foo(Bar(1), Bar(2), Bar(3), ) constructor
Foo(Bar(1), Bar(2), Bar(3), ) constructor
Traceback (most recent call last):
File "./runme.py", line 26, in <module>
example.Foo([1, 2, example.Bar(3)])
File "/home/william/swig/trunk/Examples/william/temp9/example.py",
line 217, in __init__
this = _example.new_Foo(*args)
NotImplementedError: Wrong number of arguments for overloaded function
'new_Foo'.
Possible C/C++ prototypes are:
test::Foo(std::vector< int,std::allocator< int > > const &)
test::Foo(std::vector< test::Bar,std::allocator< test::Bar > > const &)

PS I also had to correct this problem in the constructors, but I don't
think it will affect the SWIG output:

g++ -c -fpic example_wrap.cxx example.cxx -I/usr/include/python2.5
-I/usr/lib/python2.5/config
In file included from example_wrap.cxx:2801:
swigtest.h:8: error: extra qualification ‘test::Bar::’ on member ‘Bar’
swigtest.h:14: error: extra qualification ‘test::Foo::’ on member ‘Foo’
swigtest.h:20: error: extra qualification ‘test::Foo::’ on member ‘Foo’

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: SWIG & Tcl: %newobject ignored?

2009-11-24T13:42:33Z

Georgios Petasis wrote:
> Hi all,
>
> For some reason swig 1.3.41 seems to ignore the "%newbject foo;" feature
> (and its equivalent %feature("new", "1") foo;), which seems strange.
> This is because I looked insto Source/Modules/tcl8.cxx and the code
> seems to check the "wrap:new" feature, and act accordingly. The code in
> tcl8.cxx seems ok, why I don't see the results in the produced wrapper?
>
The appropriate typemaps need a $owner. Below is a diff which provides
what should be needed. However, the SWIG test-suite fails with this and
we have no tcl maintainer at the moment, so I'd rather leave this
leaking memory rather than crashing. If you have any tcl knowledge,
please give us a hand in debugging the two runtime test crashes then we
can add the $owner back in.

William

william@caracal:~/swig/trunk$ svn diff Lib/tcl/
Index: Lib/tcl/tcltypemaps.swg
===================================================================
--- Lib/tcl/tcltypemaps.swg (revision 11750)
+++ Lib/tcl/tcltypemaps.swg (working copy)
@@ -67,18 +67,18 @@
#if 1
// Old 1.3.25 typemaps needed to avoid premature object deletion
%typemap(out,noblock=1) SWIGTYPE *INSTANCE, SWIGTYPE &INSTANCE,
SWIGTYPE INSTANCE[] {
- Tcl_SetObjResult(interp, SWIG_NewInstanceObj( %as_voidptr($1),
$1_descriptor,0));
+ Tcl_SetObjResult(interp, SWIG_NewInstanceObj( %as_voidptr($1),
$1_descriptor, $owner));
}

%typemap(out) SWIGTYPE *DYNAMIC, SWIGTYPE &DYNAMIC {
swig_type_info *ty =
SWIG_TypeDynamicCast($1_descriptor,%as_voidptrptr(&$1));
- Tcl_SetObjResult(interp,SWIG_NewInstanceObj(%as_voidptr($1), ty,0));
+ Tcl_SetObjResult(interp,SWIG_NewInstanceObj(%as_voidptr($1), ty,
$owner));
}

#endif

%typemap(throws,noblock=1) SWIGTYPE CLASS {
- SWIG_set_result(SWIG_NewInstanceObj(%as_voidptr(SWIG_new_copy($1,
$1_ltype)), $&1_descriptor, 1));
+ SWIG_set_result(SWIG_NewInstanceObj(%as_voidptr(SWIG_new_copy($1,
$1_ltype)), $&1_descriptor, SWIG_POINTER_OWN));
SWIG_fail;
}

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: Can this be done with SWIG? - [BUG in Tcl generator?]

2009-11-24T13:42:25Z

Georgios Petasis wrote:

> O/H Georgios Petasis έγραψε:
>> Hi all,
>>
>> I have a simple class:
>>
>> %nodefaultctor nsIDOMHTMLCollection;
>> %nodefaultdtor nsIDOMHTMLCollection;
>> class nsIDOMHTMLCollection {
>> public:
>> void Release (void);
>> void Item (PRUint32 index, nsIDOMNode **OUTPUT);
>> void NamedItem (const nsAString &name, nsIDOMNode **OUTPUT);
>> }; /* nsIDOMHTMLCollection */
>>
>> %nodefaultdtor nsIDOMNode;
>> class nsIDOMNode {
>> void Release(void);
>> }
>>
>> What I want to do:
>>
>> 1) Tell SWIG that the arguments "nsIDOMNode **OUTPUT" are actually the
>> return values of the methods Item & NamedItem, and that the returned
>> value is actually a new allocated pointer. I can do this with the
>> following:
>>
>> %typemap(in, numinputs=0) nsIDOMNode **OUTPUT(nsIDOMNode *temp) {
>> $1 = &temp;
>> }
>> %typemap(argout) nsIDOMNode **OUTPUT {
>> Tcl_SetObjResult(interp, SWIG_NewInstanceObj(
>> SWIG_as_voidptr(*($1)), SWIGTYPE_p_nsIDOMNode, 1));
>> }
>> %newobject nsIDOMHTMLCollection::Item;
>> %newobject nsIDOMHTMLCollection::NamedItem;
>>
>> 2) I want to tell SWIG to delete nsIDOMNode * by calling Release().
>> How can I do this?
>>
>> If I enable the default destructor, swig always uses delete on the
>> object. How can I change that, and actually call Release() ?
>>
>> Thanks,
>>
>> George
>
> Is it possible the Tcl wrapper generator to have a bug?
> I tried the following:
>
> %nodefaultctor nsIDOMHTMLCollection;
> %feature("action") nsIDOMHTMLCollection::~nsIDOMHTMLCollection {
> arg1->MyRelease();
> }
> class nsIDOMHTMLCollection {
> public:
> nref AddRef (void);
> nref Release (void);
> void Item (PRUint32 index, nsIDOMNode **OUTPUT);
> void NamedItem (const nsAString &name, nsIDOMNode **OUTPUT);
> void GetLength (PRUint32 *OUTPUT);
> }; /* nsIDOMHTMLCollection */
>
> The wrapper was generated just fine (i.e.
> _wrap_delete_nsIDOMHTMLCollection calls MyRelease()),
> but the class destructor is still:
>
> SWIGINTERN void swig_delete_nsIDOMHTMLCollection(void *obj) {
> nsIDOMHTMLCollection *arg1 = (nsIDOMHTMLCollection *) obj;
> delete arg1;
> }
>
> Is this what I am supposed to get?

The action code appears in:

SWIGINTERN int
_wrap_delete_nsIDOMHTMLCollection(ClientData clientData SWIGUNUSED,
Tcl_Interp *interp, int objc, Tcl_Obj *CONST objv[]) {
nsIDOMHTMLCollection *arg1 = (nsIDOMHTMLCollection *) 0 ;
void *argp1 = 0 ;
int res1 = 0 ;

if (SWIG_GetArgs(interp, objc, objv,"o:delete_nsIDOMHTMLCollection
self ",(void *)0) == TCL_ERROR) SWIG_fail;
res1 = SWIG_ConvertPtr(objv[1],
&argp1,SWIGTYPE_p_nsIDOMHTMLCollection, SWIG_POINTER_DISOWN | 0 );
if (!SWIG_IsOK(res1)) {
SWIG_exception_fail(SWIG_ArgError(res1), "in method '"
"delete_nsIDOMHTMLCollection" "', argument " "1"" of type '"
"nsIDOMHTMLCollection *""'");
}
arg1 = reinterpret_cast< nsIDOMHTMLCollection * >(argp1);
{
arg1->MyRelease();
}

return TCL_OK;
fail:
return TCL_ERROR;
}

Which is where it should appear... the destructor wrapper. I'm not
familiar with the tcl module / C API, so I don't really know why there
is a swig_delete_nsIDOMHTMLCollection in addition to the
_wrap_delete_nsIDOMHTMLCollection.

William

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Swig : Objective C : C++ : Wrapper Behavior

2009-11-24T07:47:12Z

Hello All,

I'm new to the list and the SWIG software in general, but I'm considering the following scenario for a SWIG implementation and curious as to whether anyone has done something similar before. A simplified example of the architecture would consist of the following :

Objective C Layer

------------------------------

C++ Layer

ClassA ClassB

Both ClassA and ClassB will be run through SWIG in order to generate wrappers that expose their methods to the Objective-C layer. ClassA exposes a getter method that returns a pointer to ClassB. What curious about is this pointer. Will the generated SWIG code automatically wrap the pointer in the appropriate ClassB wrapper code when the Objective C layer calls the getter method ?

Any thoughts, ideas, or information regarding this proposal would be appreciated.

Thanks!

Gregory.

From forum: swig-user

Pointers to members (and python)

2009-11-24T03:32:19Z

Hello,

I made some bindings from my C++ app for python.

The problem is that I use pointers to members (It's for computing
shortest path and giving the property to minimize as parameter).

This is the C++ signature:

std::vector<Path> martins(int start, int dest, MultimodalGraph & g,
float Edge::*)

This is what I did (from what I understood in the doc):

%constant float Edge::* distance = &Edge::distance;

This is how I call my function from python:

foo.martins(0, 1000, g, foo.distance)

And this is the error I get:

NotImplementedError: Wrong number of arguments for overloaded function
'martins'.
Possible C/C++ prototypes are:
martins(int,int,MultimodalGraph &,float Edge::*)

>>> foo.distance
<Swig Packed at _00000000_m_Edge__float>

I have an overloaded method that uses a default 4th paramaters, and it
works perfectly.

So is it possible to use pointers to members with swig? If yes, what's
the trick? If no, what would be the most elegant way to work arround?

Thank you for your help!

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

wrapping template classes which wrap stl collections

2009-11-24T03:09:12Z

Hi

I thought I was pretty good at c++, but I've stumpled upon something I
don't quite understand, first a little back-ground:

I'm trying to revive the Swig bindings for the Ogre3d rendering engine,
things are progressing nicely, but, I've stumpled upon a problem:

The Ogre3D library comes with the ability to track memory allocations,
and report leaks when exiting the program, naturally I'd like to use
that feature in order to ensure that the wrappers doesn't leak.

for stl collections, this is done by wrapping the stl collections in a
template class, I've provided a small sample here:

//for stl containter
namespace Ogre
{
template <typename T, typename A = STLAllocator<T, GeneralAllocPolicy>
>
struct deque
{
#if OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR
typedef typename std::deque<T, A> type;
#else
typedef typename std::deque<T> type;
#endif
};

template <typename T, typename A = STLAllocator<T, GeneralAllocPolicy>
>
struct vector
{
#if OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR
typedef typename std::vector<T, A> type;
#else
typedef typename std::vector<T> type;
#endif
};

template <typename T, typename A = STLAllocator<T, GeneralAllocPolicy>
>
struct list
{
#if OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR
typedef typename std::list<T, A> type;
#else
typedef typename std::list<T> type;
#endif
};

template <typename T, typename P = std::less<T>, typename A =
STLAllocator<T, GeneralAllocPolicy> >
struct set
{
#if OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR
typedef typename std::set<T, P, A> type;
#else
typedef typename std::set<T, P> type;
#endif
};

template <typename K, typename V, typename P = std::less<K>, typename A
= STLAllocator<std::pair<const K, V>, GeneralAllocPolicy> >
struct map
{
#if OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR
typedef typename std::map<K, V, P, A> type;
#else
typedef typename std::map<K, V, P> type;
#endif
};

template <typename K, typename V, typename P = std::less<K>, typename A
= STLAllocator<std::pair<const K, V>, GeneralAllocPolicy> >
struct multimap
{
#if OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR
typedef typename std::multimap<K, V, P, A> type;
#else
typedef typename std::multimap<K, V, P> type;
#endif
};

} // Ogre

The STLAllocator<....> has some defines, taking care of the different
allocation scenarios, i.e. whether memory tracking is enabled or not.

here comes the part which I don't really understand:

typedef map<String, String>::type NameValuePairList;

I didn't even know that "::type" was legal c++

I tried to wrap it using:
%template(NameValuePairList) Ogre::map<Ogre::String,
Ogre::String>::type;

but Swig doesn't like the "::type" either, if I leave it out,

void f(const Ogre::NameValuePairList *p);

gets wrapped as:

public void
f(SWIGTYPE_p_Ogre__mapT_Ogre__String_Ogre__String_std__lessT_Ogre__String_t_STLAllocatorT_std__pairT_Ogre__String_const_Ogre__String_t_Ogre__GeneralAllocPolicy_t_t__type p)

I'd prefer the signature to be:
public void f(NameValuePairList p);

Is there a simple way to achieve this or do I need to manually define
the wrappers?

Any help would be greatly appreciated, especially this doing this
manually would be quite a daunting task, given all the places that
collections are used.

best regards
/anton

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

ruby 1.9.1 wrapper file compile error ID GC_VALUE::hash_id = rb_intern("hash");

2009-11-24T01:55:53Z

Hi
The wrapper module of SWIG 1.3.40 s not 100% ruby 1.9.1 compatible since
they changed

rb_intern(char *)

and
ID GC_VALUE::hash_id = rb_intern("hash");

does not compile any more...

see:
http://sourceforge.net/tracker/index.php?func=detail&aid=2859614&group_id=16
45&atid=101645

Is there any patch or workaround available yet?

Best,
SirAnn

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: Problem with SwigValueWrapper

2009-11-23T23:47:43Z

Robert Lupton the Good wrote:

> This one I do think is a bug rather than a "feature"; the non-use of
> SwigValueWrapper when it's needed, and the ignoring of a %feature
> ("valuewrapper"). This is swig 1.3.40 and -python -c++.
>
> // -*- c++ -*-
> %module hoo
>
> %inline %{
> template<typename Matrix>
> class MatrixBase {
> private:
> MatrixBase() {}
> };
>
> class Matrix { };
>
> template<typename T>
> class TMatrix { };
> %}
>
> //%template(MMatrix) MatrixBase<Matrix>; // makes no difference
> //%feature("valuewrapper") MatrixBase<Matrix>; // makes no difference
>
> %typemap(in) MatrixBase<Matrix>() { }
>
> %inline %{
> #if 1
> void size(MatrixBase<Matrix> mat); // fails
> #else
> void size(MatrixBase<TMatrix<int> > mat); // OK
> #endif
> %}
>
> With "#if 1" (i.e. void size(MatrixBase<Matrix> mat);) the generated
> code uses:
>
> SWIGINTERN PyObject *_wrap_size(PyObject *SWIGUNUSEDPARM(self),
> PyObject *args) {
> PyObject *resultobj = 0;
> MatrixBase< Matrix > arg1 ;
>
> and fails to compile due to MatrixBase's private constructor. With
> "#if 0" the code
> uses SwigValueWrapper and all is well:
>
> SWIGINTERN PyObject *_wrap_size(PyObject *SWIGUNUSEDPARM(self),
> PyObject *args) {
> PyObject *resultobj = 0;
> SwigValueWrapper< MatrixBase< TMatrix< int > > > arg1 ;
>
> I'm actually most concerned about %feature("valuewrapper")
> MatrixBase<Matrix>; being apparently ignored as I have a class that
> should have a private default constructor, but in fact has one that
> just crashes...
>

There is some strange bug here due to symbol clashes between the
template parameter 'Matrix' and the class 'Matrix'. If you change

template<typename Matrix> ...

to

template<typename M> ...

you can work around the problem. Alternatively, you need your feature
declarations before the class that you want to attach them to, so use this:

%feature("valuewrapper") MatrixBase;

before MatrixBase is defined.

William

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: Problem with recognising a typemap defined in terms of a typedef

2009-11-23T23:18:51Z

Robert Lupton the Good wrote:

> I figured out that the typemap defined for a typedef wasn't being
> applied to a declaration in terms of the underlying type but wasn't sure
> whether this was a bug or a feature.
>
> William says that it's a feature, so the docs could be clearer. For
> example,
>> Therefore, typemaps are unaffected by typedef, namespaces, and other
>> declarations that might hide the underlying type
>
> This is true, but the opposite is not true --- underlying types are
> unaware of typedefs, and I think it'd be wise to add a note to the manual.
>

Clarification added at the end of the "Typedef reduction" section, svn
version viewable online at:
http://swig.svn.sourceforge.net/viewvc/swig/trunk/Doc/Manual/Typemaps.html#Typemaps_nn18

William

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: Generating C# Interfaces for Proxy Classes

2009-11-23T05:07:30Z

As far as I know, you will have to do it by hand.

Here is an example:

%nodefaultctor IMyInterface;
%typemap(csbase, replace="1") IMyInterface "";
%typemap(csclassmodifiers) IMyInterface "interface";
%typemap(csbody) IMyInterface "";
%typemap(csfinalize) IMyInterface "";
%typemap(csdestruct) IMyInterface "";
%typemap(cscode) IMyInterface
%{
// interface declaration here
%}

%inline %{
class IMyInterface{};
%}

Then you just have to change the base of your wrapped class like this:
%typemap(csinterfaces) MyClass "IMyInterface, IDisposable";

Hope this helps!
Juan M.

On Mon, Nov 23, 2009 at 3:44 AM, Josh Rivers <josh@...> wrote:

> Hi All,
>
> I've done some searching and seen mention of this previously, but I'm not
> clear on whether a solution was ever implemented/found.
>
> I'd like interfaces that match my generated proxy types to be generated
> alongside the proxy classes (so that I can use mocking tools easily to
> generate mock objects). Can SWIG be cajoled into generating a matching
> interface for each proxy class?
>
> Thanks,
> Josh
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Swig-user mailing list
> Swig-user@...
> https://lists.sourceforge.net/lists/listinfo/swig-user
>
>

From forum: swig-user

Generating C# Interfaces for Proxy Classes

2009-11-22T22:44:28Z

Hi All,

I've done some searching and seen mention of this previously, but I'm not clear on whether a solution was ever implemented/found.

I'd like interfaces that match my generated proxy types to be generated alongside the proxy classes (so that I can use mocking tools easily to generate mock objects). Can SWIG be cajoled into generating a matching interface for each proxy class?

Thanks,
Josh

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

SWIG-TCL working with array pointer

2009-11-22T09:19:36Z

Hi,

I am new to SWIG, and tried successfully to get a working SWIG-TCL wrapping

of a few basic function API (i.e. swig.exe –tcl example.i).

Currently, I am blocked in getting the SWIG-TCL wrapper of 'API_GetMessage'

listed below in 'C' code.

I tried with helper functions, cpointer.i lib, and also typemap.i but failed

To get the final result correctly.

Q: I would like to know if there is a straight solution built-in in SWIG

Or it needs some workarounds? Any comment are welcome.

The TCL scripts

-----------------------------------------------

set pMsg [new_buffer "This is a test message"]

set pMsgData [new_MESSAGE 0 0 $pMsg]

set retCode [API_GetMessage 3 23 $pMsgData]

if {$retCode == 1} {

puts "pMsg = $pMSg" ==========è printing " This is a test message"

}

The 'C' code

----------------------------------------------

typedef struct tagRECV_DATA

{

unsigned long param;

unsigned long length;

char *pData;

} MESSAGE;

int API_GetMessage(unsigned long param_1, unsigned long param_2, DATA_MSG *pMsg)

{

/* Call target to get the Received data, and fill pMsg buffer */

pMsg->pData[0] = 'T';

pMsg->pData[1] = 'h';

pMsg->pData[2] = '\0';

}

#define DATA_MSG_LEN 100

char *pPtr = malloc(DATA_MSG_LEN);

DATA_MSG *pMessage = malloc(sizeof(MESSAGE);

pMessage->param = 0;

pMessage->length = 7;

pMessage->pData = pPtr; /* assign the data buffer */

/* call the receive API function */

int status = API_GetMessage(3, 4, pMessage);

if (status == 1)

{

printf ("Received message = %s\n", pMessage->pData);

}

Thanks,

Ronen

From forum: swig-user

std::set for Java and C#

2009-11-21T15:19:16Z

Are there any plans to implement std_set.i for Java and/or C#? I don't see it even in the trunk. Does anyone have a simple implementation for this anywhere before I attempt writing it myself?

Thanks,
Chad

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: C++ precompilation instructions to python module with SWIG

2009-11-20T07:24:53Z

You can put #define's in your interface file.

Josh

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: C++ precompilation instructions to python module with SWIG

2009-11-20T06:28:55Z

I also use CMake and SWIG.. But didnt play around with the given macros...

Just write your own macro, that's quite easy...

Why do I wrote my own macro:
1. I want to have the dependency of my swig interface file to the includes
header files (therefore I parse the xxx.i file and put them to DEPENDS later
on)
2. I need to put on every already defined preprocessor define to the swig
compiler
3. I want to source group my files in VS
...

I just attached the macro file.. maybe you can also use it or just ask the
cmake community via the cmake email list :-)

You can use it as follows:

SET_SWIG_STUFF()
SET(SWIG_FILE "interface1.i")
SET(GEN_FILES) #-> vor the generated files.. you can put these e.g. to
ADDITIONAL_CLEAN_FILES
SWIG_WAPP_CPP(SWIG_FILE "ruby" GEN_FILES)

But I would emphasize to play around with the given macros to figure out
what's the problem within your CMakeLists.txt file

Std. Macros are:
CMake2.8\share\cmake-2.8\Modules\FindSWIG.cmake
And:
CMake2.8\share\cmake-2.8\Modules\UseSWIG.cmake

Best SirAnn

-----Ursprüngliche Nachricht-----
Von: LittleBigYoan [mailto:collet@...]
Gesendet: Dienstag, 17. November 2009 11:27
An: swig-user@...
Betreff: Re: [Swig-user] C++ precompilation instructions to python module
with SWIG

Juan Manuel Alvarez wrote:
>
> Using -DNAME as a parameter on the command line, should do the trick.
>

Seems not working, but maybe it comes to the fact I am using CMake to
generate wrapper. I give you my CMake relevant part if it can help you:

/* CMakeLists.txt */
...
FIND_PACKAGE( SWIG REQUIRED )
INCLUDE( ${SWIG_USE_FILE} )

FIND_PACKAGE( PythonLibs REQUIRED )
INCLUDE_DIRECTORIES( ${PYTHON_INCLUDE_PATH} )

SET( CMAKE_SWIG_FLAGS "" )

SET_SOURCE_FILES_PROPERTIES( example.i PROPERTIES CPLUSPLUS ON )
SET_SOURCE_FILES_PROPERTIES( example.i PROPERTIES SWIG_FLAGS "-includeall" )
SET_SOURCE_FILES_PROPERTIES( example.i PROPERTIES SWIG_FLAGS "-DNAME" )

SWIG_ADD_MODULE( example python example.i )
SWIG_LINK_LIBRARIES( example ${PYTHON_LIBRARIES} )

...
/* END OF CMakeLists.txt */

Is there anything to change in my CMakeLists.txt ?
--
View this message in context:
http://old.nabble.com/C%2B%2B-precompilation-instructions-to-python-module-w
ith-SWIG-tp26369712p26387467.html
Sent from the swig-user mailing list archive at Nabble.com.

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

################################################################
### SET_SWIG_STUFF ###
################################################################
MACRO(SET_SWIG_STUFF )
IF(NOT SWIG_FOUND)
FIND_PACKAGE(SWIG REQUIRED)
ENDIF()
IF(NOT SWIG_FOUND)
MESSAGE("SET_SWIG_STUFF::could not find SWIG")
ENDIF()

IF(WIN32)
ADD_DEFINITIONS("-DNT=1")
ADD_DEFINITIONS("-DIMPORT")
ENDIF()
ENDMACRO(SET_SWIG_STUFF )

################################################################
### SET_SWIG_STUFF ###
################################################################
# swigfiles: e.g. vf.i
# language: e.g. ruby
# outfiles: list generated files AND swig files will be append on!
#
# it always uses the -c++ option (but feel free to extend this one)
MACRO(SWIG_WAPP_CPP swigfiles language outFiles)
IF(NOT SWIG_FOUND)
MESSAGE(FATAL_ERROR "SWIG_WAPP_CPP::error SWIG package was not loaded")
ENDIF()

IF(${swigfiles})
FOREACH(swigfileName ${${swigfiles}})

################################################################
# find headerfiles in interface file
################################################################
FILE(READ "${swigfileName}" swigfile)
SET(header_file_var "") #var initialisieren bzw. reseten

MESSAGE(STATUS "scanning swigfile dependencies")
WHILE(NOT header_file_var STREQUAL swigfile)
STRING(REGEX REPLACE ".*#include[ ]*[<\"]([^>\"]*)[>\"].*" "\\1" header_file_var "${swigfile}")
IF(NOT header_file_var STREQUAL swigfile) #wenn nichts zu ersetzen ist.. -> steht in className wieder komplettes file
#MESSAGE("H: ${header_file_var}")
#headerfile aus swigfile löschen!
STRING(REGEX REPLACE "(.*)#include[ ]*[<\"][ ]*${header_file_var}[ ]*[>\"].*" "\\1" swigfile "${swigfile}")
SET(i_dependencies ${i_dependencies} ${header_file_var} )
ENDIF()

ENDWHILE()
MESSAGE(STATUS "scanning swigfile dependencies: done")

################################################################
# make rule
################################################################
################################################################
# name for wrapper file
GET_FILENAME_COMPONENT(outname ${swigfileName} NAME_WE)
GET_FILENAME_COMPONENT(outdir ${swigfileName} PATH)
STRING(REGEX REPLACE "${SOURCE_ROOT}/" "" outdir ${outdir})
SET(tempSourceGroupName ${outdir})
SET(outdir ${CMAKE_CURRENT_BINARY_DIR}/swig_cpp/${outdir})
FILE(MAKE_DIRECTORY ${outdir})
SET(wrapper_file ${outdir}/${outname}_wrapp.cpp)

################################################################
# get include directories from direcotry
GET_DIRECTORY_PROPERTY(cmake_include_directories INCLUDE_DIRECTORIES)
SET(swig_include_dirs)
FOREACH(it ${cmake_include_directories})
SET(swig_include_dirs ${swig_include_dirs} "-I${it}")
ENDFOREACH(it)

################################################################
# get preprocessor defines
GET_DIRECTORY_PROPERTY(preProcessorDefs COMPILE_DEFINITIONS)
SET(swigPreProcessorDefs "")
FOREACH(define ${preProcessorDefs})
LIST(APPEND swigPreProcessorDefs "-D${define}" )
ENDFOREACH()

################################################################
# pre compile commando for the interface file
ADD_CUSTOM_COMMAND(OUTPUT ${wrapper_file}
PRE_BUILD
COMMAND echo on \n ${SWIG_EXECUTABLE}
ARGS -c++
-${language}
${swig_include_dirs}
${swigPreProcessorDefs}
-o ${wrapper_file} ${swigfileName}
MAIN_DEPENDENCY ${swigfileName}
DEPENDS ${i_dependencies}
COMMENT SWIG: generating ${wrapper_file} )
SET(GENERATED_FILES ${GENERATED_FILES} ${outname}_wrapp.cpp)

SET(${GENERATED_FILES} ${${GENERATED_FILES}} ${wrapper_file})
SET(${outFiles} ${wrapper_file} )

################################################################
# SOURCE GROUP
################################################################
#STRING(REGEX REPLACE "${CMAKE_CURRENT_BINARY_DIR}/swig_cpp/" "" tempSourceGroupName ${outdir})
#CAB_SOURCE_GROUP( ${tempSourceGroupName} ${swigfileName} ${wrapper_file} )

ENDFOREACH()
ENDIF()

ENDMACRO(SWIG_WAPP_CPP swigfiles outFiles)
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Re: C++ precompilation instructions to python module with SWIG

2009-11-20T05:03:03Z

I have never used CMake, so I can't help you on that, sorry! :(

Juan M.

On Tue, Nov 17, 2009 at 7:26 AM, LittleBigYoan <collet@...> wrote:

>
>
> Juan Manuel Alvarez wrote:
>>
>> Using -DNAME as a parameter on the command line, should do the trick.
>>
>
> Seems not working, but maybe it comes to the fact I am using CMake to
> generate wrapper. I give you my CMake relevant part if it can help you:
>
> /* CMakeLists.txt */
> ...
> FIND_PACKAGE( SWIG REQUIRED )
> INCLUDE( ${SWIG_USE_FILE} )
>
> FIND_PACKAGE( PythonLibs REQUIRED )
> INCLUDE_DIRECTORIES( ${PYTHON_INCLUDE_PATH} )
>
> SET( CMAKE_SWIG_FLAGS "" )
>
> SET_SOURCE_FILES_PROPERTIES( example.i PROPERTIES CPLUSPLUS ON )
> SET_SOURCE_FILES_PROPERTIES( example.i PROPERTIES SWIG_FLAGS "-includeall" )
> SET_SOURCE_FILES_PROPERTIES( example.i PROPERTIES SWIG_FLAGS "-DNAME" )
>
> SWIG_ADD_MODULE( example python example.i )
> SWIG_LINK_LIBRARIES( example ${PYTHON_LIBRARIES} )
>
> ...
> /* END OF CMakeLists.txt */
>
> Is there anything to change in my CMakeLists.txt ?
> --
> View this message in context: http://old.nabble.com/C%2B%2B-precompilation-instructions-to-python-module-with-SWIG-tp26369712p26387467.html
> Sent from the swig-user mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Swig-user mailing list
> Swig-user@...
> https://lists.sourceforge.net/lists/listinfo/swig-user
>

From forum: swig-user

Re: Embed perl and multi-threading (Re: segmentation fault in event-driven library wrapped with swig)

2009-11-20T01:29:06Z

Please see my post here for a resolution I found for this issue.

http://markmail.org/message/cjbhybjfikuirvud

Thx

--- On Mon, 11/2/09, Sri <w2learn@...> wrote:

> From: Sri <w2learn@...>
> Subject: Embed perl and multi-threading (Re: segmentation fault in event-driven library wrapped with swig)
> To: swig-user@...
> Date: Monday, November 2, 2009, 8:35 AM
> Hi all,
>
> In digging further into this, I feel that the
> pthread_getspecific() functions are not finding the perl
> interpreter instance corresponding to the thread in my
> library. I guess its because I havent really created
> one yet? To test if this was the cause, I modified my
> SWIG_Wrap_bsa_disc_callback method to create a new
> perl-interpreter when my_perl is NULL and the crash is now
> occuring at the call_sv. I realize its not the right
> way to do it, but not sure exactly the steps required.
> I think the solution likely involves my library thread
> creating a interpreter instance and saving relevant data
> (what is relevant?) via pthread_setspecific
> method/SET_CONTEXT().
>
> Would be great if anyone can shed some light or confirm if
> I'm on the right track.
>
> Thx
>
> void SWIG_Wrap_bsa_disc_callback(int event, tMy_MSG
> *p_data)
> {
> int new_perl = 0;
> printf("entering perl callback
> handler...\n");
> dTHX;
> printf("dTHX done...\n");
>
> if ( my_perl != NULL )
>    printf ("my_perl ==
> %ul\n", my_perl);
> else
> {
>    printf ("my_perl was
> NULL\n");
>    my_perl =
> perl_alloc();
>
>    PERL_SET_CONTEXT(my_perl);
>    new_perl = 1;
> }
> /*
> printf("Destruct level : %d...\n",
> PL_perl_destruct_level);
> */
> dSP;
> printf("DSP done...\n");
> SV * sv = bsa_perl_disc_callback;
> if (sv == (SV*)NULL)
>    croak("Internal
> error...\n");
>
> printf("Preparing to call perl
> callback...\n");
> PUSHMARK(SP);
> XPUSHs(sv_2mortal(newSViv(event)));
> printf("newSViv of %d done...\n",
> event);
>
> XPUSHs(SWIG_NewPointerObj(SWIG_as_voidptr(p_data),
> SWIGTYPE_p_tMy_MSG, SWIG_SHADOW));
> /* XPUSHs(sv_2mortal(newSVsv((SV
> *)p_data))); */
> printf("newSVsv...\n");
> PUTBACK;
>
> printf("calling the Perl sub...\n");
> /* Call the Perl sub */
> call_sv(sv, G_DISCARD);
> printf("Perl sub completed
> successfully...\n");
>
> if ( new_perl )
> perl_free(my_perl);
> }
>
>
> --- On Fri, 10/30/09, Sri <w2learn@...>
> wrote:
>
> > From: Sri <w2learn@...>
> > Subject: segmentation fault in event-driven library
> wrapped with swig
> > To: swig-user@...
> > Date: Friday, October 30, 2009, 8:35 PM
> > Hello SWIG, perl experts:
> >
> > With good help from swig-users posts & Stephen
> Chan in
> > particular, I've figured out how to wrap a C
> event-driven
> > library with SWIG. SWIG is really nice tool! I'm
> able to
> > call APIs and register perl-sub as callback into the
> C
> > library. If I invoke the perl callback as part of an
> API
> > invoked from Perl script, the callback is called (in
> perls
> > main thread). However, when the same callback
> handler
> > invokes the callback via a different thread (based on
> async
> > event), it crashes at the "dSP;" line.
> >
> > I've tried adding "dTX" before "dSP;" and also tried
> > enabling more macros to match how my perl is built.
> So far
> > no luck. The line that crashes is below
> (pre-processor
> > output). "dTHX done" is printed, but crashes before
> > "DSP done" is printed.
> >
> > printf("entering perl callback
> > handler...\n");
> > register PerlInterpreter *my_perl
> > __attribute__((unused)) = ((PerlInterpreter
> > *)pthread_getspecific((*Perl_Gthr_key_ptr(((void
> *)0)))));
> > printf("dTHX done...\n");
> > register SV **sp =
> > (*Perl_Tstack_sp_ptr(((PerlInterpreter
> > *)pthread_getspecific((*Perl_Gthr_key_ptr(((void
> > *)0))))))); <-- CRASHES!!
> > printf("DSP done...\n");
> >
> >
> > The perl-callback handler code
> > ------------------------------
> >
> > void SWIG_Wrap_bsa_disc_callback(int event, tMy_MSG
> > *p_data)
> > {
> > printf("entering perl callback
> > handler...\n");
> > dTHX;
> > printf("dTHX done...\n");
> > dSP;
> > printf("DSP done...\n");
> > SV * sv = bsa_perl_disc_callback;
> > if (sv == (SV*)NULL)
> >    croak("Internal
> > error...\n");
> >
> > printf("Preparing to call perl
> > callback...\n");
> > PUSHMARK(SP);
> > XPUSHs(sv_2mortal(newSViv(event)));
> > printf("newSViv of %d done...\n",
> > event);
> >
> > XPUSHs(SWIG_NewPointerObj(SWIG_as_voidptr(p_data),
> > SWIGTYPE_p_tMy_MSG, SWIG_SHADOW));
> > /* XPUSHs(sv_2mortal(newSVsv((SV
> > *)p_data))); */
> > printf("newSVsv...\n");
> > PUTBACK;
> >
> > printf("calling the Perl sub...\n");
> > /* Call the Perl sub */
> > call_sv(sv, G_DISCARD);
> > printf("Perl sub completed
> > successfully...\n");
> > }
> >
> > Options when running SWIG:
> > --------------------------
> >
> > swig -includeall -I. -I <lots of others proj
> specific
> > dirs> -perl5 -outdir <outdir> -module
> > <module> my_api.i
> >
> > Options when compliling _wrap.c:
> > --------------------------------
> >
> > gcc -E -Dbool=char -fpic -D_REENTRANT -D_GNU_SOURCE
> > -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing
> -pipe
> > -isystem /usr/local/include -D_LARGEFILE_SOURCE
> > -D_FILE_OFFSET_BITS=64 -DSWIG -g -DMULTIPLICITY
> > -DPERL_IMPLICIT_CONTEXT -DTHREADS_HAVE_PIDS
> > -DUSE_LARGE_FILES -DUSE_PERLIO -DUSE_REENTRANT_API
> > -DBSA_CLIENT -I/usr/lib/perl/5.8/CORE/
> >
> > Output from perl -V
> > -------------------
> >
> > Summary of my perl5 (revision 5 version 8 subversion
> 8)
> > configuration:
> > Platform:
> > osname=linux, osvers=2.6.24-19-server,
> > archname=i486-linux-gnu-thread-multi
> > uname='linux palmer 2.6.24-19-server #1 smp
> > sat jul 12 00:40:01 utc 2008 i686 gnulinux '
> > config_args='-Dusethreads -Duselargefiles
> > -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC
> > -Darchname=i486-linux-gnu -Dprefix=/usr
> > -Dprivlib=/usr/share/perl/5.8
> -Darchlib=/usr/lib/perl/5.8
> > -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5
> > -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local
> > -Dsitelib=/usr/local/share/perl/5.8.8
> > -Dsitearch=/usr/local/lib/perl/5.8.8
> > -Dman1dir=/usr/share/man/man1
> -Dman3dir=/usr/share/man/man3
> > -Dsiteman1dir=/usr/local/man/man1
> > -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1
> > -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs
> > -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -Duseshrplib
> > -Dlibperl=libperl.so.5.8.8 -Dd_dosuid -des'
> > hint=recommended, useposix=true,
> > d_sigaction=define
> > usethreads=define use5005threads=undef
> > useithreads=define usemultiplicity=define
> > useperlio=define d_sfio=undef
> > uselargefiles=define usesocks=undef
> > use64bitint=undef use64bitall=undef
> > uselongdouble=undef
> > usemymalloc=n, bincompat5005=undef
> > Compiler:
> > cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE
> > -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing
> -pipe
> > -I/usr/local/include -D_LARGEFILE_SOURCE
> > -D_FILE_OFFSET_BITS=64',
> > optimize='-O2',
> > cppflags='-D_REENTRANT -D_GNU_SOURCE
> > -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing
> -pipe
> > -I/usr/local/include'
> > ccversion='', gccversion='4.2.3 (Ubuntu
> > 4.2.3-2ubuntu7)', gccosandvers=''
> > intsize=4, longsize=4, ptrsize=4,
> > doublesize=8, byteorder=1234
> > d_longlong=define, longlongsize=8,
> > d_longdbl=define, longdblsize=12
> > ivtype='long', ivsize=4, nvtype='double',
> > nvsize=8, Off_t='off_t', lseeksize=8
> > alignbytes=4, prototype=define
> > Linker and Libraries:
> > ld='cc', ldflags =' -L/usr/local/lib'
> > libpth=/usr/local/lib /lib /usr/lib
> > libs=-lgdbm -lgdbm_compat -ldb -ldl -lm
> > -lpthread -lc -lcrypt
> > perllibs=-ldl -lm -lpthread -lc -lcrypt
> > libc=/lib/libc-2.7.so, so=so,
> > useshrplib=true, libperl=libperl.so.5.8.8
> > gnulibc_version='2.7'
> > Dynamic Linking:
> > dlsrc=dl_dlopen.xs, dlext=so,
> > d_dlsymun=undef, ccdlflags='-Wl,-E'
> > cccdlflags='-fPIC', lddlflags='-shared
> > -L/usr/local/lib'
> >
> >
> > Characteristics of this binary (from libperl):
> > Compile-time options: MULTIPLICITY
> > PERL_IMPLICIT_CONTEXT
> >
> > PERL_MALLOC_WRAP
> > THREADS_HAVE_PIDS USE_ITHREADS
> >
> > USE_LARGE_FILES USE_PERLIO
> > USE_REENTRANT_API
> > Built under linux
> > Compiled at Jan 14 2009 22:34:36
> > @INC:
> > /etc/perl
> > /usr/local/lib/perl/5.8.8
> > /usr/local/share/perl/5.8.8
> > /usr/lib/perl5
> > /usr/share/perl5
> > /usr/lib/perl/5.8
> > /usr/share/perl/5.8
> > /usr/local/lib/site_perl
> > .
> >
> > output from gcc -v
> > ------------------
> >
> > gcc -v
> > Using built-in specs.
> > Target: i486-linux-gnu
> > Configured with: ../src/configure -v
> >
> --enable-languages=c,c++,fortran,objc,obj-c++,treelang
> > --prefix=/usr --enable-shared --with-system-zlib
> > --libexecdir=/usr/lib --without-included-gettext
> > --enable-threads=posix --enable-nls
> > --with-gxx-include-dir=/usr/include/c++/4.2
> > --program-suffix=-4.2 --enable-clocale=gnu
> > --enable-libstdcxx-debug --enable-objc-gc
> --enable-mpfr
> > --enable-targets=all --enable-checking=release
> > --build=i486-linux-gnu --host=i486-linux-gnu
> > --target=i486-linux-gnu
> > Thread model: posix
> > gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
> >
> >
> >
> >
> >
>
>
>
>

From forum: swig-user

Re: Swig : Objective-C : Documentation and Next Steps

2009-11-19T12:52:14Z

On Thu, Nov 19, 2009 at 12:12 PM, Gregory Sogorka <blackberryoctopus@...> wrote:

I've checked out this branch of the Swig repo : http://swig.svn.sourceforge.net/viewvc/swig/branches/gsoc2009-ashishs99

Pertinent Information :
OS : OSX 10.5.8

swig : SWIG Version 1.3.41

gcc : i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)

After building, I used one the examples found in the perl tutorial for swig in an attempt to test the objective c support

I ran the following :

$ ls
example.c example.i

$ ~/swig-objc/bin/swig -objc ./example.i

$ ls
example.c example.i exampleProxy.h exampleProxy.m exampleWrapper.h exampleWrapper.mm

This command has now built the following files : exampleProxy.h exampleProxy.m exampleWrapper.h exampleWrapper.mm

I am curious if anyone can guide me to either 1) documentation that explains what my next steps should be in the process of incorporating my c code into my objc code. or 2) provide a brief response that might serve as guidance for next steps

There is no proper documentation as yet but you can look at examples in 'Examples/objc' to get an idea of the existing support and how you can compile objc code with C/C++ code.

Thanks in advance for any help you might provide.

Gregory

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

From forum: swig-user

Swig : Objective-C : Documentation and Next Steps

2009-11-19T10:12:35Z

I've checked out this branch of the Swig repo : http://swig.svn.sourceforge.net/viewvc/swig/branches/gsoc2009-ashishs99

Pertinent Information :

OS : OSX 10.5.8

swig : SWIG Version 1.3.41

gcc : i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)

After building, I used one the examples found in the perl tutorial for swig in an attempt to test the objective c support

I ran the following :

$ ls

example.c example.i

$ ~/swig-objc/bin/swig -objc ./example.i

$ ls

example.c example.i exampleProxy.h exampleProxy.m exampleWrapper.h exampleWrapper.mm

This command has now built the following files : exampleProxy.h exampleProxy.m exampleWrapper.h exampleWrapper.mm

I am curious if anyone can guide me to either 1) documentation that explains what my next steps should be in the process of incorporating my c code into my objc code. or 2) provide a brief response that might serve as guidance for next steps

Thanks in advance for any help you might provide.

Gregory

From forum: swig-user

Re: SWIG <-> Ruby 1.9.1 - std::fstream - program termination

2009-11-19T09:18:49Z

Arghh… I don’t know what to do…

No it doesn’t work for 1.8.6 either (Win 2008 Server 64bit.. but ruby, my dll and swig are pure 32 bit).

Do I have to include some extra interface file? Do I have to add some special preprocessor define (in addition to NT=1 and IMPORT)?

Von: Sören Freudiger [mailto:freud@...]
Gesendet: Donnerstag, 19. November 2009 13:37
An: swig-user@...
Betreff: Re: [Swig-user] SWIG <-> Ruby 1.9.1 - std::fstream - program termination

Okay, here is some extra info I found out:

It seems to be a SWIG bug.

Implementing the function direct via the ruby C-API works fine (files attached)

Any idea?

(I also send an bug report to swig)

Von: Sören Freudiger [mailto:freud@...]
Gesendet: Donnerstag, 19. November 2009 10:57
An: swig-user@...
Betreff: [Swig-user] SWIG <-> Ruby 1.9.1 - std::fstream - program termination

Hello

Again a huge problem with ruby and C++

I’m not sure if this problem is related to SWIG or ruby. But maybe anyone has a clue how to fix that issue.

That’s’ my source code:

#include <iostream>

#include <fstream>

void foo()

{

std::ofstream file("c:/temp/text.txt", std::ios::out);

file<<"hello world"<<std::endl;

file.close();

}

As you can see, really crazy low level programming.

The swig interface file:

%module example

#include "example.h"

%include "example.h"

And the problem:

Platform: Windows (7)

Compiler: cl from VS 2008

Ruby version 1.8.6. everything works quite well

Ruby version 1.9.1_p129 (installer) program termination at file.close()

Ruby version 1.9.1_p243 (VS 2008 build, 32bit): program termination at file.close()

Ruby version 1.9.2. program termination at file.close()

I tried to debug the problem, but stuck in

VS9/VC/Include/fstream

Does anyone know about that error and has a workaround?

Best,

SirAnn

From forum: swig-user