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

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

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

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

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

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

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.

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.

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

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