headers
SourceForge.net | 2 Dec 2007 04:04
Picon
Favicon

[ swig-Bugs-1842527 ] [java] ctor taking long long and bool gives bad java code

Bugs item #1842527, was opened at 2007-12-02 03:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1842527&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: java
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Olly Betts (olly)
Assigned to: William Fulton (wsfulton)
Summary: [java] ctor taking long long and bool gives bad java code

Initial Comment:
SWIG adds a protected ctor to each Java class:

protected A(long cPtr, boolean cMemoryOwn) {
  // ...
}

However, if the C++ class being wrapped has a constructor taking long long and bool, then this is wrapped as a
java ctor taking long and boolean which clashes with the protected constructor and the java wrapper can't
be compiled.

The attached javabug.i demonstrates this.  Process like so:
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 2 Dec 2007 04:19
Picon
Favicon

[ swig-Bugs-1836331 ] Extra scoping on destructor

Bugs item #1836331, was opened at 2007-11-22 09:28
Message generated for change (Comment added) made by olly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1836331&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: code generation (general)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: William Fulton (wsfulton)
Assigned to: David M. Beazley (beazley)
Summary: Extra scoping on destructor

Initial Comment:

%inline %{
class MCConvergenceList
{
public:
    MCConvergenceList::~MCConvergenceList();
};
%}

example.i:8: Warning(504): Function ~MCConvergenceList must have a return type.
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 2 Dec 2007 05:54
Picon
Favicon

[ swig-Bugs-1828308 ] [python] Namespace collision with boost

Bugs item #1828308, was opened at 2007-11-08 14:18
Message generated for change (Comment added) made by olly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1828308&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: python
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Johannes Drever (jo_drever)
Assigned to: David M. Beazley (beazley)
>Summary: [python] Namespace collision with boost

Initial Comment:
The function "destructor" is not in a namespace and collides with boost::lambda::destructor. This can be
fixed by substituting destructor with ::destructor in the *_wrap.cxx file. It would be nice if swig does
this automatically.

The output of gcc:
LayerMapping_wrap.cxx: In function ‘PyTypeObject* swig_varlink_type()’:
LayerMapping_wrap.cxx:3892: error: reference to ‘destructor’ is ambiguous
/usr/include/python2.5/object.h:243: error: candidates are: typedef void (* destructor)(struct PyObject*)
/usr/include/boost/lambda/construct.hpp:116: error:                 struct boost::lambda::destructor
LayerMapping_wrap.cxx:3892: error: reference to ‘destructor’ is ambiguous
/usr/include/python2.5/object.h:243: error: candidates are: typedef void (* destructor)(struct PyObject*)
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 2 Dec 2007 13:27
Picon
Favicon

[ swig-Bugs-1734415 ] C++ parser fails on template code

Bugs item #1734415, was opened at 2007-06-10 16:16
Message generated for change (Comment added) made by gallien
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1734415&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: parsing
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Pujos (bubbleguuum)
Assigned to: Marcelo Matus (marcelomatus)
Summary: C++ parser fails on template code

Initial Comment:
The C++ fails to parse the following code:

template<typename t_item> class alloc_fast {
...
}

template<typename t_item, template<typename> class t_alloc = pfc::alloc_fast >
class list_t : public list_impl_t<t_item,pfc::array_t<t_item,t_alloc> > { };

Especially, what it don't like is "template<typename> class t_alloc = pfc::alloc_fast".
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 2 Dec 2007 18:20
Picon
Favicon

[ swig-Bugs-1842527 ] [java] ctor taking long long and bool gives bad java code

Bugs item #1842527, was opened at 2007-12-02 03:04
Message generated for change (Comment added) made by wsfulton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1842527&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: java
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Olly Betts (olly)
Assigned to: William Fulton (wsfulton)
Summary: [java] ctor taking long long and bool gives bad java code

Initial Comment:
SWIG adds a protected ctor to each Java class:

protected A(long cPtr, boolean cMemoryOwn) {
  // ...
}

However, if the C++ class being wrapped has a constructor taking long long and bool, then this is wrapped as a
java ctor taking long and boolean which clashes with the protected constructor and the java wrapper can't
be compiled.

The attached javabug.i demonstrates this.  Process like so:
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 2 Dec 2007 18:52
Picon
Favicon

[ swig-Bugs-1842527 ] [java] ctor taking long long and bool gives bad java code

Bugs item #1842527, was opened at 2007-12-02 03:04
Message generated for change (Comment added) made by olly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1842527&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: java
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Olly Betts (olly)
Assigned to: William Fulton (wsfulton)
Summary: [java] ctor taking long long and bool gives bad java code

Initial Comment:
SWIG adds a protected ctor to each Java class:

protected A(long cPtr, boolean cMemoryOwn) {
  // ...
}

However, if the C++ class being wrapped has a constructor taking long long and bool, then this is wrapped as a
java ctor taking long and boolean which clashes with the protected constructor and the java wrapper can't
be compiled.

The attached javabug.i demonstrates this.  Process like so:
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 2 Dec 2007 21:33
Picon
Favicon

[ swig-Bugs-1842527 ] [java] ctor taking long long and bool gives bad java code

Bugs item #1842527, was opened at 2007-12-02 03:04
Message generated for change (Comment added) made by wsfulton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1842527&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: java
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Olly Betts (olly)
Assigned to: William Fulton (wsfulton)
Summary: [java] ctor taking long long and bool gives bad java code

Initial Comment:
SWIG adds a protected ctor to each Java class:

protected A(long cPtr, boolean cMemoryOwn) {
  // ...
}

However, if the C++ class being wrapped has a constructor taking long long and bool, then this is wrapped as a
java ctor taking long and boolean which clashes with the protected constructor and the java wrapper can't
be compiled.

The attached javabug.i demonstrates this.  Process like so:
(Continue reading)

Permalink | Reply | 2 comments |
headers
SourceForge.net | 3 Dec 2007 23:42
Picon
Favicon

[ swig-Bugs-1836331 ] Extra scoping on destructor

Bugs item #1836331, was opened at 2007-11-22 09:28
Message generated for change (Comment added) made by wsfulton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1836331&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: code generation (general)
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: William Fulton (wsfulton)
Assigned to: David M. Beazley (beazley)
Summary: Extra scoping on destructor

Initial Comment:

%inline %{
class MCConvergenceList
{
public:
    MCConvergenceList::~MCConvergenceList();
};
%}

example.i:8: Warning(504): Function ~MCConvergenceList must have a return type.
(Continue reading)

Permalink | Reply | 3 comments |
headers
SourceForge.net | 3 Dec 2007 23:50
Picon
Favicon

[ swig-Bugs-1828308 ] [python] Namespace collision with boost

Bugs item #1828308, was opened at 2007-11-08 14:18
Message generated for change (Comment added) made by wsfulton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1828308&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: python
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Johannes Drever (jo_drever)
Assigned to: David M. Beazley (beazley)
Summary: [python] Namespace collision with boost

Initial Comment:
The function "destructor" is not in a namespace and collides with boost::lambda::destructor. This can be
fixed by substituting destructor with ::destructor in the *_wrap.cxx file. It would be nice if swig does
this automatically.

The output of gcc:
LayerMapping_wrap.cxx: In function ‘PyTypeObject* swig_varlink_type()’:
LayerMapping_wrap.cxx:3892: error: reference to ‘destructor’ is ambiguous
/usr/include/python2.5/object.h:243: error: candidates are: typedef void (* destructor)(struct PyObject*)
/usr/include/boost/lambda/construct.hpp:116: error:                 struct boost::lambda::destructor
LayerMapping_wrap.cxx:3892: error: reference to ‘destructor’ is ambiguous
/usr/include/python2.5/object.h:243: error: candidates are: typedef void (* destructor)(struct PyObject*)
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 3 Dec 2007 23:54
Picon
Favicon

[ swig-Patches-1838248 ] Use automake srcdir/builddir locations

Patches item #1838248, was opened at 2007-11-25 21:32
Message generated for change (Comment added) made by wsfulton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=1838248&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Monty Taylor (sdirector)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use automake srcdir/builddir locations

Initial Comment:
In Source/Makefile.am, there are two references to ../swig which become more robust if ../ is replaced
with ${top_builddir} (specifically this breaks the way I'm personally using swig right now, of course)
The patch should not affect anyone who is not trying to do anything crazy. 

Patch is against SVN:10172

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

>Comment By: William Fulton (wsfulton)
Date: 2007-12-03 22:54
(Continue reading)

Permalink | Reply | 0 comments |

Gmane