As the title says, cpp_binder is a tool that generates C++ bindings.  It reads C++ headers and produces a D file filled with "extern(C++)" declarations.  It can translate a bunch of cool, small examples, but is not close to being ready for prime-time.  It crashes a lot, especially in the STL; since the STL is pretty pervasive, I have not successfully used cpp_binder on an actual C++ library.

I've written more about cpp_binder and my experiences at http://www.todayman.net/cpp_binder-pre-announcement-and-status.html.

The code is available at https://github.com/todayman/cpp_binder . cpp_binder still dumps lots of debugging info to stdout and stderr, so you'll probably want to redirect those somewhere beesides your console.

I hope that this post will spur discussion / decisions / action binding C++ libraries into D.  I think the language capabilities (e.g. extern(C++, namespace)) get really far and that the next big push needs to be on binding real libraries and tools to help.

-- 
Paul O'Neil
Github / IRC: todayman

On Monday, 21 September 2015 at 04:22:30 UTC, Paul O'Neil wrote:
> As the title says, cpp_binder is a tool that generates C++ bindings.  It reads C++ headers and produces a D file filled with "extern(C++)" declarations.  It can translate a bunch of cool, small examples, but is not close to being ready for prime-time.  It crashes a lot, especially in the STL; since the STL is pretty pervasive, I have not successfully used cpp_binder on an actual C++ library.
>
> I've written more about cpp_binder and my experiences at http://www.todayman.net/cpp_binder-pre-announcement-and-status.html.
>
> The code is available at https://github.com/todayman/cpp_binder . cpp_binder still dumps lots of debugging info to stdout and stderr, so you'll probably want to redirect those somewhere beesides your console.
>
> I hope that this post will spur discussion / decisions / action binding C++ libraries into D.  I think the language capabilities (e.g. extern(C++, namespace)) get really far and that the next big push needs to be on binding real libraries and tools to help.

This strikes as a most needed project. How come it crashes a lot ? Glancing quickly at the source, it looks like it is using clang as a source of C++ truth.

If you can make it work on the STL, that would be a significant step forward for D. I'm very serious.

On 2015-09-21 06:22, Paul O'Neil wrote:
> As the title says, cpp_binder is a tool that generates C++ bindings.  It
> reads C++ headers and produces a D file filled with "extern(C++)"
> declarations.  It can translate a bunch of cool, small examples, but is
> not close to being ready for prime-time.  It crashes a lot, especially
> in the STL; since the STL is pretty pervasive, I have not successfully
> used cpp_binder on an actual C++ library.
>
> I've written more about cpp_binder and my experiences at
> http://www.todayman.net/cpp_binder-pre-announcement-and-status.html.

I read your reasons why you're not using DStep. But I still think it's a shame that you chose to create a new tool instead of contributing to DStep.

That's the unfortunate issue with the D community. Everyone is creating their on projects instead of working together. That's why the progress is so slow.

-- 
/Jacob Carlborg

On Monday, 21 September 2015 at 04:22:30 UTC, Paul O'Neil wrote:
> I hope that this post will spur discussion / decisions / action binding C++ libraries into D.  I think the language capabilities (e.g. extern(C++, namespace)) get really far and that the next big push needs to be on binding real libraries and tools to help.

How do you deal with overloading of *, &, &&, const *, const& etc?

On 2015-09-21 06:22, Paul O'Neil wrote:

> I've written more about cpp_binder and my experiences at
> http://www.todayman.net/cpp_binder-pre-announcement-and-status.html.

About the plugin architecture. I tried modifying DMD to run DStep to automatically generate bindings and use them directly. I announced it as a proof of concept [1], but the community seemed to prefer having it as a separate tool if I recall correctly.

[1] http://forum.dlang.org/thread/ks3kir$1ubq$1@digitalmars.com

-- 
/Jacob Carlborg

On Monday, 21 September 2015 at 07:45:48 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 21 September 2015 at 04:22:30 UTC, Paul O'Neil wrote:
>> I hope that this post will spur discussion / decisions / action binding C++ libraries into D.  I think the language capabilities (e.g. extern(C++, namespace)) get really far and that the next big push needs to be on binding real libraries and tools to help.
>
> How do you deal with overloading of *, &, &&, const *, const& etc?

I guess that the only thing that doesn't map directly to D is &&. The others look on the D side like this:
C++      -> D
T*       -> T*
T&       -> ref T
const T* -> const T*
const T& -> const ref T

I think that T&& actually looks like the T& calling convention ABI-wise. The difference being that T&& functions are mangled differently so that you can overload them. The challenge is to be able to select them from the overload set. Perhaps the path of least resistance (for now) is to generate a .cpp (not a header-only library) containing a wrapper for every function that takes T&&. For example:

// C++ wrapper:

// Wrapper for `vector<T>::push_back( T&& value )`

void push_back_from_rvalue(vector<T>& this_, T& to_be_moved)
{
    this_.push_back(std::move(to_be_moved));
}

// D side:

// Let's say we want to use some move-only type
// like std::thread and push it into a std::vector:
auto my_vec = stdcpp.vector.vector!(stdcpp.Thread);

// The case with rvalue temporary:
// my_vec.push_back_from_rvalue(Thread(&theadFunc));
// ^ creates a temporary Thread object
// and moves it into the vector::push_back call stack.
// Implemented like this:
// (invisible to the user:)
Thread __rvalue_tmp = Thread(&theadFunc);
my_vec.push_back_from_rvalue(__tmp);

The case with lvalue whose ownership is transferred:
auto lvalue_thread_obj = Thread(&theadFunc);

// lvalue_thread_obj is passed by mutable reference
my_vec.push_back_from_rvalue(lvalue_thread_obj);
// (invisible to the user:)
lvalue_thread_obj.__cpp_dtor();
// Unsafe to use lvalue_thread_obj from now on...

On Monday, 21 September 2015 at 09:45:01 UTC, ZombineDev wrote:
> [...]

Another option is to introduce a special built-in function like std::move that just selects the rvalue overload. This would require a language change, but would save us from adding && type qualifiers (which is a far more invasive change with little benefit) and would not be complicated to implement in the compiler. For example:

auto my_vec = stdcpp.vector.vector!(stdcpp.thread.thread);
my_vec.push_back(__cpp_move(stdcpp.thread.thread(&threadFunc)));
//                 ^--- selects the correct && overload

On Monday, 21 September 2015 at 09:59:44 UTC, ZombineDev wrote:
> On Monday, 21 September 2015 at 09:45:01 UTC, ZombineDev wrote:
>> [...]
>
> Another option is to introduce a special built-in function like std::move that just selects the rvalue overload. This would require a language change, but would save us from adding && type qualifiers (which is a far more invasive change with little benefit) and would not be complicated to implement in the compiler. For example:
>
> auto my_vec = stdcpp.vector.vector!(stdcpp.thread.thread);
> my_vec.push_back(__cpp_move(stdcpp.thread.thread(&threadFunc)));
> //                 ^--- selects the correct && overload

However we would also need a way to mark a declaration as an rvalue overload. Perhaps it can be as simple as:

// D:
extern(C++, namespace, rvalue_params(1, 2))
void fun(const ref T, ref T, ref T, T);

// C++
void fun(const T&, T&&, T&&, T);

On Monday, 21 September 2015 at 09:45:01 UTC, ZombineDev wrote:
> I guess that the only thing that doesn't map directly to D is &&. The others look on the D side like this:
> C++      -> D
> T*       -> T*
> T&       -> ref T
> const T* -> const T*
> const T& -> const ref T

I don't think D const and C++ const share semantics. In C++ you can write to things pointed to by T even if T is const. You also have no guarantee that a "const T" isn't mutated by another thread, I believe.

A C++ pointer is what D would call a shared pointer, whereas C++ does not have the concept of thread local pointers.

etc.

How come it crashes a lot ?
> Glancing quickly at the source, it looks like it is using clang as a source of C++ truth.

It's crashing a lot because I make some incorrect assumptions about what's in the AST and not everything is handled.  Getting templates right is hard, and cpp_binder doesn't do it right.  Usually this manifests as an assertion failure or dereferencing a null pointer.

-- 
Paul O'Neil
Github / IRC: todayman