> 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.
> 

How would you address those issues?  My intermediate data structures have evolved quite a lot and I'm glad that I wasn't dragging dstep along as I tried to figure it out.

The model now is more similar to dstep than it was at some points.  For a while, I was writing to multiple files.  This tool has a long way to go, and it may make sense to move it into dstep in the future.

-- 
Paul O'Neil
Github / IRC: todayman

On 09/21/2015 12:01 PM, Ola Fosheim Grøstad wrote:
> 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.
> 

While D and C++ const don't quite share semantics, they're petty close and they mangle the same way.  I do what ZombieDev has in the table.

I completely bail on && and intentionally don't bind those things.

-- 
Paul O'Neil
Github / IRC: todayman

On 09/21/2015 05:29 AM, Jacob Carlborg wrote:
> 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
> 

I don't like it either, but it deals with uninstantiated templates...

It also means that you can handle the curiously recurring template pattern.  If you cant instantiate the template in the D compiler, then you need to generate C++ code that expresses the D structure and properly instantiates the C++ template.  The payoff here is bigger.

-- 
Paul O'Neil
Github / IRC: todayman

On Tuesday, 22 September 2015 at 00:31:45 UTC, Paul O'Neil wrote:
> While D and C++ const don't quite share semantics, they're petty close and they mangle the same way.  I do what ZombieDev has in the table.

Going from const to mutable like that breaks the type system...

On Tuesday, 22 September 2015 at 04:07:54 UTC, Ola Fosheim Grostad wrote:
> On Tuesday, 22 September 2015 at 00:31:45 UTC, Paul O'Neil wrote:
>> While D and C++ const don't quite share semantics, they're petty close and they mangle the same way.  I do what ZombieDev has in the table.
>
> Going from const to mutable like that breaks the type system...

Can pragma(mangle, ...) be used on types? Then we can define a C/C++ compatible `HeadConst` template that simulates C/C++ const semantics, while still being mangled correctly:

template HeadConst(T) {
    pragma(mangle, const(T).mangleof)
    struct HeadConst {
        // @disable opAssign();
        // and whatever else is necessary for head-const
    }
}

The constructor would of course need to make sure that it accepts only types with non-const indirection.

On 2015-09-22 02:24, Paul O'Neil wrote:

> How would you address those issues?

You mean that no one works together? Or that DStep only has one pass?

> My intermediate data structures
> have evolved quite a lot and I'm glad that I wasn't dragging dstep along
> as I tried to figure it out.
> The model now is more similar to dstep than it was at some points.  For
> a while, I was writing to multiple files.  This tool has a long way to
> go, and it may make sense to move it into dstep in the future.

DStep has only one pass because that's only what I've needed so far. Perhaps if I would start adding C++ support I would notice that I need multiple passes.

-- 
/Jacob Carlborg

On Tuesday, 22 September 2015 at 11:04:17 UTC, Marc Schütz wrote:
> Can pragma(mangle, ...) be used on types? Then we can define a C/C++ compatible `HeadConst` template that simulates C/C++ const semantics, while still being mangled correctly

I believe I've seen const declarations in C incorrectly declared as head const when transitive const was really wanted, but it wasn't done because transitive const in C is so much PITA. So the only real concern here is mangling.

On Tuesday, 22 September 2015 at 14:46:24 UTC, Kagamin wrote:
> I believe I've seen const declarations in C incorrectly declared as head const when transitive const was really wanted, but it wasn't done because transitive const in C is so much PITA. So the only real concern here is mangling.

That's a rather orthodox viewpoint... If D const is to have any value then the optimizer should be allowed to cache computations and elide memory barriers.

The consequences of a C function mutating something reachable through const is either a disaster or the D compiler will have to forget about those kind of optimizations after calling a C function. But then const has very little value...

On Tuesday, 22 September 2015 at 14:53:54 UTC, Ola Fosheim Grøstad wrote:
> The consequences of a C function mutating something reachable through const is either a disaster or the D compiler will have to forget about those kind of optimizations after calling a C function. But then const has very little value...

Another C feature you didn't know about: the standard allows to create a mutable pointer to const data and mutate it. But most of the time when you see const in C, it works as expected, so usually there shouldn't be a problem except for mangling.

On Tuesday, 22 September 2015 at 15:11:55 UTC, Kagamin wrote:
> Another C feature you didn't know about: the standard allows to create a mutable pointer to const data and mutate it.

I didn't? Of course I did. In C++ other threads can write to const objects. The function receiving a const objects is not supposed to write to const. Const cast is supposed to be used for calling legacy const interfaces without a const signature.

> But most of the time when you see const in C, it works as expected, so usually there shouldn't be a problem except for mangling.

No it doesn't. C++ even has an override for const object fields called "mutable", so that you can have things like reference counts in const objects.

Either D const is _always_ ensured or the compiler have to assume that it is _always_ violated after FFI.