September 22, 2015 Re: cpp_binder, a not-yet-useful tool for generating C++ bindings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | > 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 |
September 22, 2015 Re: cpp_binder, a not-yet-useful tool for generating C++ bindings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | 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 |
September 22, 2015 Re: cpp_binder, a not-yet-useful tool for generating C++ bindings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 |
September 22, 2015 Re: cpp_binder, a not-yet-useful tool for generating C++ bindings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul O'Neil | 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...
|
September 22, 2015 Re: cpp_binder, a not-yet-useful tool for generating C++ bindings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grostad | 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.
|
September 22, 2015 Re: cpp_binder, a not-yet-useful tool for generating C++ bindings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul O'Neil | 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 |
September 22, 2015 Re: cpp_binder, a not-yet-useful tool for generating C++ bindings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marc Schütz | 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.
|
September 22, 2015 Re: cpp_binder, a not-yet-useful tool for generating C++ bindings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | 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...
|
September 22, 2015 Re: cpp_binder, a not-yet-useful tool for generating C++ bindings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | 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.
|
September 22, 2015 Re: cpp_binder, a not-yet-useful tool for generating C++ bindings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | 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. |
Copyright © 1999-2021 by the D Language Foundation