SWIG == magic?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

SWIG == magic?

Jonathan Stoikovitch
Hi All,

First of all, thanks to the contributors for supporting the SWIG community. Disclosure: I'm a SWIG pre-newbie (haven't used it yet).

I'm considering using SWIG to generate the bindings to a purpose-built c++ parser for (at least) python, ruby, golang, java and javascript. The parser would be relying heavily on yaml-cpp to parse a yaml file with specific properties.

What I'm wondering is:
1) is this the right approach vs the alternative which would to write parsers in each target language?
2) why aren't more people designing parsers this way? am I missing something? is this harder than I think? 

Voilà for now.

Thanks,
Jonathan


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SWIG == magic?

Andrew Haining

A lot of parsers are built this way and from my personal perspective it is an excellent way to design such a system. Writing the same code in 2 different languages is the surest way to double the bugs in a system that I know of. It also increases maintenance time exponentially.

 

I think the main reason people don’t use swig is that they haven’t heard of it or they have unrealistic expectations of its functionality. If the C++ interface of a given library is written in a way that is conducive to interoperating with garbage collectors and foreign ABI’s the swig layer will be relatively simple, if not you will almost certainly have to write a lot of proprietary swig code and target language (c#, python, java, etc) glue code. In my experience, most people are put off by swig at this point, where they are hoping to be able to glue a C/C++ library to their own code without having to write any C++ or swig code or make any sort of accommodations for how the 2 runtimes operate, that is not a realistic expectation.

 

I personally use the Pimpl idiom and pass wrapper objects to the target language by value. This ensures that as long as the target language keeps it reference to the object the memory will be valid, it also ensures the external facing headers will be clean and free of implementation details, which allows me to keep my swig code fairly simple and cross platform.

 

Hope that helps!

Andy.

 

From: Jonathan Stoikovitch [mailto:[hidden email]]
Sent: 13 July 2016 22:48
To: [hidden email]
Subject: [Swig-user] SWIG == magic?

 

Hi All,

 

First of all, thanks to the contributors for supporting the SWIG community. Disclosure: I'm a SWIG pre-newbie (haven't used it yet).

 

I'm considering using SWIG to generate the bindings to a purpose-built c++ parser for (at least) python, ruby, golang, java and javascript. The parser would be relying heavily on yaml-cpp to parse a yaml file with specific properties.

 

What I'm wondering is:

1) is this the right approach vs the alternative which would to write parsers in each target language?

2) why aren't more people designing parsers this way? am I missing something? is this harder than I think? 

 

Voilà for now.

 

Thanks,

Jonathan

 


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________



Digital Barriers e-Mail Confidentiality and Disclaimer This message contains confidential information and is intended only for the individual named. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. Digital Barriers plc is a company registered in England and Wales. Registered number: 7149547. Registered office: Cargo Works, 1-2 Hatfields, London SE1 9PG, United Kingdom. For further information about Digital Barriers, please visit www.digitalbarriers.com.
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SWIG == magic?

jcupitt
In reply to this post by Jonathan Stoikovitch
I agree with Andrew, it's a good way to do this kind of thing, I used
swig for years to generate bindings for my image processing library.

As well as swig's great advantages, you should consider the downsides
too. For me, they'd be:

- It's very static. It relies on generating and compiling code, so if
something changes in your API, you have to regenerate everything
downstream.

- You have to know quite a lot about how the various object models
work. Ruby and Python, for example, are very different once you start
looking at their GCs, and this knowledge has to be embedded and
maintained in your swig code somehow.

- When you compile your binding, you're building for a platform and a
target language version and a target language implementation. It
depends on the language and the range of users you have to support,
but you can find yourself maintaining dozens of binary packages.

I've actually switched away from swig, I'm now using
gobject-introspection instead. With this model you write a C interface
to your library using the gobject model, then call it directly from
python / ruby / javascript using libffi plus the gobject-introspection
library.

This fixes the three problems above (the binding is fully dynamic,
object lifetime is handled for you, you can write the whole binding in
the target language with no compiling), though it does bring in a host
more, of course. The most frustrating one being the variable quality
of the gobject-introspection language libraries.

Anyway, it sounds like swig would be a good fit for your problem.

John






On 13 July 2016 at 22:47, Jonathan Stoikovitch <[hidden email]> wrote:

> Hi All,
>
> First of all, thanks to the contributors for supporting the SWIG community.
> Disclosure: I'm a SWIG pre-newbie (haven't used it yet).
>
> I'm considering using SWIG to generate the bindings to a purpose-built c++
> parser for (at least) python, ruby, golang, java and javascript. The parser
> would be relying heavily on yaml-cpp to parse a yaml file with specific
> properties.
>
> What I'm wondering is:
> 1) is this the right approach vs the alternative which would to write
> parsers in each target language?
> 2) why aren't more people designing parsers this way? am I missing
> something? is this harder than I think?
>
> Voilà for now.
>
> Thanks,
> Jonathan
> http://ramses.tech
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> Swig-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/swig-user
>

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SWIG == magic?

Marko Klopcic
In reply to this post by Jonathan Stoikovitch
1. I'm using SWIG for years. Although it is usually faster to write code in Java or Python, it
    is still much faster to write/debug code once in C++ than in Java AND Python, not to mention if more
   languages have to be supported, and maintaining the code. In your case I'd definitely use SWIG.
2. No idea.

    Marko


    
On 2016-07-13 11:47 PM, Jonathan Stoikovitch wrote:
Hi All,

First of all, thanks to the contributors for supporting the SWIG community. Disclosure: I'm a SWIG pre-newbie (haven't used it yet).

I'm considering using SWIG to generate the bindings to a purpose-built c++ parser for (at least) python, ruby, golang, java and javascript. The parser would be relying heavily on yaml-cpp to parse a yaml file with specific properties.

What I'm wondering is:
1) is this the right approach vs the alternative which would to write parsers in each target language?
2) why aren't more people designing parsers this way? am I missing something? is this harder than I think? 

Voilà for now.

Thanks,
Jonathan



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev


_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Loading...