Re: SWIG?
On Friday, 29 August 2014 at 02:10:48 UTC, Timothee Cour via Digitalmars-d wrote: I've used it quite a bit for a number of bindings (opencv, sfml + many other libs). Actually I would like to try some stuff with opencv, but I've never used SWIG, so I don't know how hight is the bar. To lower it, what do you think about some sort of github repo to push some SWIG bindings into? Something like 'opencv/2.4.9/stuffinside'? Bye, dlangophile
Re: SWIG?
On Thursday, 28 August 2014 at 01:08:43 UTC, Scott Wilson wrote:
SWIG has D support. But it seems old and out of fashion.
Community here does not buzz about it much either. Whats the
word on the street about the quality of SWIG-D stuff?
Scott
PS thankyou Walter for replying
The swig bindings are good and I use them quite a bit to
interface with legacy C++ projects.
This might be fixed already, I don't know and haven't tracked it
but I had to make a minor change to the binding generator, as
shown below.
edit commoncore_im.d and change the following:
---
mixin template SwigOperatorDefinitions() {
...
static if (is(typeof(swigOpEquals(rhs {
return swigOpEquals(rhs);
} else {
...
---
to
---
mixin template SwigOperatorDefinitions() {
...
static if (is(typeof(swigOpEquals(rhs {
return cast(bool)(swigOpEquals(rhs)); // <-- cast(bool)
added
} else {
...
---
cheers, uri
Re: SWIG?
I've used it quite a bit for a number of bindings (opencv, sfml + many other libs). It's much easier than the conventional approach of manual bindings (eg deimos), especially to keep the port up to date with upstream changes. However the following should be worked on: * support for newly introduced C++ namespaces ( https://github.com/swig/swig/issues/213) * some support for multiple inheritance (I proposed using alias this in https://github.com/swig/swig/issues/98) * mapping of C++ templates to D templates in simple cases at least (the templates would have to be instantiated somewhere in source file of course to avoid linker errors). Only the function signature would be mapped, the implementation would be still on C++ side * miscellaneous compiler warnings that shouldn't be hard to deal with - Deprecation: Read-modify-write operations are not allowed for shared variables : has a pull request (https://github.com/swig/swig/issues/203 ) - missing override * it would help to have a dedicated bug tracker for D-swig. Currently github issues for swig lump all other languages together, making D-swig of limited visibility for D community. At least create a SWIG-D label in github issues. @klickverbot will tell you more as he implemented most of it IIRC On Wed, Aug 27, 2014 at 6:08 PM, Scott Wilson via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > SWIG has D support. But it seems old and out of fashion. Community here > does not buzz about it much either. Whats the word on the street about the > quality of SWIG-D stuff? > > Scott > > PS thankyou Walter for replying >
SWIG?
SWIG has D support. But it seems old and out of fashion. Community here does not buzz about it much either. Whats the word on the street about the quality of SWIG-D stuff? Scott PS thankyou Walter for replying
Re: Anyone tried wrapping DMD with Swig?
On 8/9/12, David Nadlinger wrote: > Have you > tried adding a »%module dmd« directive to the top of your .i > file? That fixes it, thanks.
Re: Anyone tried wrapping DMD with Swig?
On Thursday, 9 August 2012 at 00:28:32 UTC, Andrej Mitrovic wrote: This is my .i file: https://gist.github.com/3299941 I've ran: swig -c++ -Isrc/root -IC:\MinGW\lib\gcc\mingw32\4.6.1\include -IC:\MinGW\include -includeall -d -d2 dmd_all.i C:\MinGW\include\stdlib.h(96) : Error: Syntax error in input(1). Without using "-includeall" I get a lot of warnings but swig doesn't generate a single file. Using -includeall is almost always the wrong thing to do, precisely for the reason that it also pulls in system headers. As for the »doesn't generate a single file« problem: Have you tried adding a »%module dmd« directive to the top of your .i file? David
Anyone tried wrapping DMD with Swig?
This is my .i file: https://gist.github.com/3299941 I've ran: swig -c++ -Isrc/root -IC:\MinGW\lib\gcc\mingw32\4.6.1\include -IC:\MinGW\include -includeall -d -d2 dmd_all.i C:\MinGW\include\stdlib.h(96) : Error: Syntax error in input(1). Without using "-includeall" I get a lot of warnings but swig doesn't generate a single file. I don't really need the wrapper as I'm just doing this for testing purposes. I've used my own codegenerator to create a wrapper but I keep getting out of memory errors when trying to compile the D wrapper, and I want to know if SWIG-generated code suffers from the same problem or if I've just ran into a DMD bug.
wrapping C++ templates to D templates (via SWIG)
I was writing my own template code wrapper until I saw the
excellent SWIG for D tool; currently, given a C++ template
(class/function) "A" and a set of instantiations in interface
file (eg T=double), SWIG seems to only output non-template
classes/functions with user-defined mangled names, eg A_double.
Is there currently a way for SWIG to output instead a D template
(class/function) "A(T)" ?
or rather, the corresponding instantiations, cf A(T:double), etc.
The advantage: simple client code (eg class A_array(T){A!T [] a;}
), similar C++ / D syntax, no magic name mangling or namespace
pollution required by the user, better encapsulation and easier
to keep D in sync with C++.
I have a workaround to achieve this by modifying SWIG output (see
below) but ideally, this could be directly generated in SWIG
(more convenient/efficient). Would it be possible to add this
feature in SWIG, say with a D specific command line switch
-preserve_class_templates and -preserve_function_templates.
In addition, the user shouldn't have to specify himself the name
manglings (eg %template(A_double) A;) but could instead
write something like:
%instantiate(A); in the swig interface file.
***
input: fun.h
template class A{
T x;
A(T x):x(x){}
};
interface:fun.i
%{
#include "fun.h"
%}
%template(A_double) A;
current output: fun.d
class A_double {
private void* swigCPtr;
//..other wrapper code
public this(double x) {
this(fun_im.new_A_double(x), true);
}
}
desired output: fun_desired.d
class A(T:double) {
private void* swigCPtr;
//..other wrapper code
public this(double x) {
this(fun_im.new_A_double(x), true);
}
}
my current hack to get same behavior as desired output:
fun_hacked.d
private alias A ! double A_double;
class A(T:double) {
private alias typeof(this) A_double;
private void* swigCPtr;
//..other wrapper code
public this(double x) {
this(fun_im.new_A_double(x), true);
}
}
***
NOTE: in fun_hacked.d, which seems to work, I need to have 2
aliases: one inside (to avoid recursive definition error) and one
outside, which takes care of references to A_double that could
appear outside of the class definition.
This hack could of course be automated, with post-processing of
fun.d=>fun_hacked.d and in the interface file for eg:
%template(A_double) A;
can be generalized using something like (untested):
#define INSTANTIATE_TPL(Atpl,T) %template(Atpl ## _ ## T) Atpl;
INSTANTIATE_TPL(A,double)
wrapping C++ templates to D templates (via SWIG)
I was writing my own template code wrapper until I saw the
excellent SWIG for D tool; currently, given a C++ template
(class/function) "A" and a set of instantiations in interface
file (eg T=double), SWIG seems to only output non-template
classes/functions with user-defined mangled names, eg A_double.
Is there currently a way for SWIG to output instead a D template
(class/function) "A(T)" ?
or rather, the corresponding instantiations, cf A(T:double), etc.
The advantage: simple client code (eg class A_array(T){A!T [] a;}
), similar C++ / D syntax, no magic name mangling or namespace
pollution required by the user, better encapsulation and easier
to keep D in sync with C++.
I have a workaround to achieve this by modifying SWIG output (see
below) but ideally, this could be directly generated in SWIG
(more convenient/efficient). Would it be possible to add this
feature in SWIG, say with a D specific command line switch
-preserve_class_templates and -preserve_function_templates.
In addition, the user shouldn't have to specify himself the name
manglings (eg %template(A_double) A;) but could instead
write something like:
%instantiate(A); in the swig interface file.
***
input: fun.h
template class A{
T x;
A(T x):x(x){}
};
interface:fun.i
%{
#include "fun.h"
%}
%template(A_double) A;
current output: fun.d
class A_double {
private void* swigCPtr;
//..other wrapper code
public this(double x) {
this(fun_im.new_A_double(x), true);
}
}
desired output: fun_desired.d
class A(T:double) {
private void* swigCPtr;
//..other wrapper code
public this(double x) {
this(fun_im.new_A_double(x), true);
}
}
my current hack to get same behavior as desired output:
fun_hacked.d
private alias A ! double A_double;
class A(T:double) {
private alias typeof(this) A_double;
private void* swigCPtr;
//..other wrapper code
public this(double x) {
this(fun_im.new_A_double(x), true);
}
}
***
NOTE: in fun_hacked.d, which seems to work, I need to have 2
aliases: one inside (to avoid recursive definition error) and one
outside, which takes care of references to A_double that could
appear outside of the class definition.
This hack could of course be automated, with post-processing of
fun.d=>fun_hacked.d and in the interface file for eg:
%template(A_double) A;
can be generalized using something like (untested):
#define INSTANTIATE_TPL(Atpl,T) %template(Atpl ## _ ## T) Atpl;
INSTANTIATE_TPL(A,double)
Re: SWIG 4 D2 How To : namespace, friend, operator()
On Sun, Dec 12, 2010 at 2:13 PM, BLS wrote: > > Last question is about : operator() > > f.i.bool operator()(HWND const a, const HWND b) const > > Klickverbot suggests to use the SWIG's %rename. But how that would look > like in practice ? > > Beside, I guess this is what opImplicitCast should solve. maybe alias this > could help somehow .. dunno. > > Thanks in advance.. > Bjoern > > I think you can do this: %rename(_call) *::operator(); Currently Klickverbot is working on support for operator overloading wrappers.
SWIG 4 D2 How To : namespace, friend, operator()
Hi, this is my first attempt to use SWIG for D2, So in case that my
questions are stupid simple.. Sorry.
questions are included in swig file wincore.i
/* wincore.i */
%module(directors="1") wincore
%{
#include "wincore.h"
%}
%include "std_string.i"
%include
/* turn on director wrapping for CWnd */
%feature("director") CWnd;
namespace Win32xx // HOW TO deal with namspaces ?
{
class CWnd
{
// HOW TO handle friend ?
friend class CMDIChild; //defined in frame.h
friend class CWinApp; //define in wincore.h
//
}
}
Last question is about : operator()
f.i.bool operator()(HWND const a, const HWND b) const
Klickverbot suggests to use the SWIG's %rename. But how that would look
like in practice ?
Beside, I guess this is what opImplicitCast should solve. maybe alias
this could help somehow .. dunno.
Thanks in advance..
Bjoern
