View mode: basic / threaded / horizontal-split · Log in · Help
February 20, 2012
CWrap - higher abstraction level for calling C functions
D has complete (IMHO) compiler support for calling C functions (using 
extern(C)). But there is a lack of library support. Microsoft .NET 
Framework has such support, but it's poor (see previous thread about 
CWrap in digitalmars.D NG).

Once original function is properly described in IDL, CWrap gives the 
fallowing advantages:
* [memory-corruption-safe] User works with arrays, not separate pointers 
and lengths.
* [memory-leak-safe] Original function allocated memory will be freed on 
any failure (NOTE: see "Original function restrictions" in documentation).
* [fail-safe] An exception will be thrown if original function fails.
* [usability] Much easier to work with arrays/preferred string types (it 
converts UTF-8/16/32 back and forth, see docs).
* [speed] No unnecessary GC (or other) allocations/copying/reading.
* [garbage-free] Look at, e.g. std.file - it leaves lots of garbage 
because of calling native platform functions. Generated wrappers don't 
even allocate GC memory (except for output parameters when user do want 
get GC allocated buffers).

Sources: https://bitbucket.org/denis_sh/cwrap
Docs (incomplete): http://deoma-cmd.ru/d/docs/src/cwrap.html

Phobos is needed.
Besides Phobos, the only file needed for generating: cwrap.d
The only file needed for generated wrappers to work: internal/cwraprt.d

Library state: almost every internal function is unittested, generated 
wrappers pass rather complicated test-suit in internal/cwrapunittests.d

"Examples" is the most informative section of the documentation. Other 
examples:
1. Original functions, all in one file:
https://bitbucket.org/denis_sh/cwrap/src/tip/examples/c.d
https://bitbucket.org/denis_sh/cwrap/src/tip/internal/cwrapunittests.d
2. Generated wrappers:
https://bitbucket.org/denis_sh/cwrap/src/tip/out

NOTE1: You need dmd 2.058 to generate wrappers at CT.
NOTE2: You can change `enum data` to `auto data` in examples/c.d, this 
will reduce compilation time.

Previous thread about CWrap in digitalmars.D NG:
http://www.digitalmars.com/d/archives/digitalmars/D/Higher_abstraction_level_for_calling_C_functions_156633.html
February 20, 2012
Re: CWrap - higher abstraction level for calling C functions
On Mon, 20 Feb 2012 18:02:49 +0400
Denis Shelomovskij <verylonglogin.reg@gmail.com> wrote:

Hello Denis,

> D has complete (IMHO) compiler support for calling C functions (using 
> extern(C)). But there is a lack of library support. 

I'm glad you're working on (another) bindings tool being aware that it's
not reasonable that D will cover all our library needs.

Otoh, I'm also concerned that using just wrappers over C code would
erode (potential) type-safety and advantage of using D in the first
place. (In our app we envision to use wXD for GUI, need bindings for 3rd
party C lib, using one of Sqlite3 wrappers...)

> Once original function is properly described in IDL, CWrap gives the 
> fallowing advantages:

If we eliminate htod which is Windows only and considering that manual
wrapping is not very attractive option, along with your list which sound
quite goo, my question is what would be some of pro/cons of CWrap in
comparison with e.g. SWIG and it's D support as well as with dstep
(https://github.com/jacob-carlborg/dstep) if our main objective would be
to keep some of D's advantages such as having higher-level (D-ish) API,
exception handling (insted of error-checking), type-safety etc.
available in our D bindings of C lib(s)?


Sincerely,
Gour

-- 
One who restrains his senses, keeping them under full control, 
and fixes his consciousness upon Me, is known as a man of 
steady intelligence.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
February 20, 2012
Re: CWrap - higher abstraction level for calling C functions
On 2012-02-20 16:34, Gour wrote:
> On Mon, 20 Feb 2012 18:02:49 +0400
> Denis Shelomovskij<verylonglogin.reg@gmail.com>  wrote:
>
> Hello Denis,
>
>> D has complete (IMHO) compiler support for calling C functions (using
>> extern(C)). But there is a lack of library support.
>
> I'm glad you're working on (another) bindings tool being aware that it's
> not reasonable that D will cover all our library needs.
>
> Otoh, I'm also concerned that using just wrappers over C code would
> erode (potential) type-safety and advantage of using D in the first
> place. (In our app we envision to use wXD for GUI, need bindings for 3rd
> party C lib, using one of Sqlite3 wrappers...)
>
>> Once original function is properly described in IDL, CWrap gives the
>> fallowing advantages:
>
> If we eliminate htod which is Windows only and considering that manual
> wrapping is not very attractive option, along with your list which sound
> quite goo, my question is what would be some of pro/cons of CWrap in
> comparison with e.g. SWIG and it's D support as well as with dstep
> (https://github.com/jacob-carlborg/dstep) if our main objective would be
> to keep some of D's advantages such as having higher-level (D-ish) API,
> exception handling (insted of error-checking), type-safety etc.
> available in our D bindings of C lib(s)?
>
>
> Sincerely,
> Gour
>

As I understand it, CWrap provides more than just bindings for a C 
function. SWIG or dstep could output CWrap bindings.

-- 
/Jacob Carlborg
February 21, 2012
Re: CWrap - higher abstraction level for calling C functions
On Mon, 20 Feb 2012 20:52:04 +0100
Jacob Carlborg <doob@me.com> wrote:

> As I understand it, CWrap provides more than just bindings for a C 
> function. 

Right, but, afaik, SWIG can also make more than wrapper for a C function
by using typemaps, %exception etc.

Does it mean that dstep is only tool for wrapping C function for usage
in D?

> SWIG or dstep could output CWrap bindings.

The former probably won't bother to do it, but wonder about the latter?


Sincerely,
Gour


-- 
Whatever action a great man performs, common men follow. And 
whatever standards he sets by exemplary acts, all the world pursues.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
February 21, 2012
Re: CWrap - higher abstraction level for calling C functions
On 2012-02-21 13:12, Gour wrote:
> On Mon, 20 Feb 2012 20:52:04 +0100
> Jacob Carlborg<doob@me.com>  wrote:
>
>> As I understand it, CWrap provides more than just bindings for a C
>> function.
>
> Right, but, afaik, SWIG can also make more than wrapper for a C function
> by using typemaps, %exception etc.
>
> Does it mean that dstep is only tool for wrapping C function for usage
> in D?
>
>> SWIG or dstep could output CWrap bindings.
>
> The former probably won't bother to do it, but wonder about the latter?

DStep is currently used only for automatically generating bindings for C 
functions and Objective-C classes and methods.

But it depends what code I output, I could change dstep to output code 
that uses CWrap.

-- 
/Jacob Carlborg
February 22, 2012
Re: CWrap - higher abstraction level for calling C functions
On Tue, 21 Feb 2012 18:40:20 +0100
Jacob Carlborg <doob@me.com> wrote:

> DStep is currently used only for automatically generating bindings
> for C functions and Objective-C classes and methods.

OK. Thank you.

> But it depends what code I output, I could change dstep to output
> code that uses CWrap.

That would be nice and make the whole job of binding C functions and
providing customized D API easier...and let's not forget about extra
points for coordinating work. ;)


Sincerely,
Gour


-- 
One who is not connected with the Supreme can have neither 
transcendental intelligence nor a steady mind, without which 
there is no possibility of peace. And how can there be any 
happiness without peace?

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
February 22, 2012
Re: CWrap - higher abstraction level for calling C functions
20.02.2012 19:34, Gour пишет:
> On Mon, 20 Feb 2012 18:02:49 +0400
> Denis Shelomovskij<verylonglogin.reg@gmail.com>  wrote:
>
> Hello Denis,
>
>> D has complete (IMHO) compiler support for calling C functions (using
>> extern(C)). But there is a lack of library support.
>
> I'm glad you're working on (another) bindings tool being aware that it's
> not reasonable that D will cover all our library needs.
>
> Otoh, I'm also concerned that using just wrappers over C code would
> erode (potential) type-safety and advantage of using D in the first
> place. (In our app we envision to use wXD for GUI, need bindings for 3rd
> party C lib, using one of Sqlite3 wrappers...)
>
>> Once original function is properly described in IDL, CWrap gives the
>> fallowing advantages:
>
> If we eliminate htod which is Windows only and considering that manual
> wrapping is not very attractive option, along with your list which sound
> quite goo, my question is what would be some of pro/cons of CWrap in
> comparison with e.g. SWIG and it's D support as well as with dstep
> (https://github.com/jacob-carlborg/dstep) if our main objective would be
> to keep some of D's advantages such as having higher-level (D-ish) API,
> exception handling (insted of error-checking), type-safety etc.
> available in our D bindings of C lib(s)?
>
>
> Sincerely,
> Gour
>

OK, I'm here again. Jacob Carlborg is right - CWrap is a different tool 
so it's incorrect to compare it with SWIG/dstep. It's developed as a 
high performance backend for other tools or for manual wrapping a couple 
of functions, not for translating entire *.h files or creating class 
hierarchy.

Let's imagine there is no std.file, no std.windows.charset, and no 
std.windows.registry. Look at my WinAPI examples - it will be easier and 
more robust to write IDL descriptions by hands (because you should read 
specs for every WinAPI function at least once) and use generated 
wrappers than to write lots of boring code to converts strings/check 
errors. E.g. I did it already (CWrap WinAPI examples) and it wasn't too 
long compared with reading specs.

Or let's imagine one will have to finally revise Phobos to stop 
producing garbage and/or make D usable without GC. He will kill himself 
if he want to write optimal-performance garbage-less calls to WinAPI or 
will spend lot of time by writing non-optimal. Or he will just use CWrap 
generated code.
February 22, 2012
Re: CWrap - higher abstraction level for calling C functions
22.02.2012 13:41, Gour пишет:
> That would be nice and make the whole job of binding C functions and
> providing customized D API easier...and let's not forget about extra
> points for coordinating work. ;)

I'm open for emails about using/changing/fixing CWrap.
February 22, 2012
Re: CWrap - higher abstraction level for calling C functions
On 2012-02-22 19:59, Denis Shelomovskij wrote:
> 22.02.2012 13:41, Gour пишет:
>> That would be nice and make the whole job of binding C functions and
>> providing customized D API easier...and let's not forget about extra
>> points for coordinating work. ;)
>
> I'm open for emails about using/changing/fixing CWrap.

Before adding CWrap to DStep I need to finish the regular bindings 
generator.

-- 
/Jacob Carlborg
February 22, 2012
Re: CWrap - higher abstraction level for calling C functions
On Wed, 22 Feb 2012 22:54:19 +0400
Denis Shelomovskij <verylonglogin.reg@gmail.com> wrote:

> OK, I'm here again. Jacob Carlborg is right - CWrap is a different
> tool so it's incorrect to compare it with SWIG/dstep. It's developed
> as a high performance backend for other tools or for manual wrapping
> a couple of functions, not for translating entire *.h files or
> creating class hierarchy.

Thank you for clarification. The doc page just says: "Stuff for
automated wrapping functions written in C." So I thought it's meant for
binding whole libs.

However, I still believe that having dstep producing CWrap output would
be beneficial for those having task to provide D bindings for C libs
with customized D-ish API.


Sincerely,
Gour

-- 
But a person free from all attachment and aversion and able 
to control his senses through regulative principles of 
freedom can obtain the complete mercy of the Lord.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home