On 8/8/22 4:04 PM, ag0aep6g wrote:
On Monday, 8 August 2022 at 19:33:14 UTC, Steven Schveighoffer wrote:
There's nothing clever. If you want to access C globals, you should
use `__gshared`, because that's what it is. Using `shared`, isn't
going to save you at all.
Yes, using `shared` does save you.
C might not have a `shared` qualifier, but C programmers still have to
think about thread-safety. Calling a C function or accessing a C global
always comes with some (possibly implied) contract on how to do it
safely from multiple threads (the contract might be: "don't").
`shared` (with `-preview=nosharedaccess`) forces you to think about what
the contract is. `__gshared` doesn't.
shared gives you a sense that the language is helping you prevent
problems. Again, if C isn't playing ball, this is a lie.
[...]
Using `__gshared` to share data with C is as safe as using
`-boundscheck=on` and sending the array into C which has no such
restrictions.
No it's not. C always being unsafe is true but irrelevant. The point is
what you can/can't do on the D side.
`-boundscheck=on` - Can't easily mess up on the D side. C side can still
mess up.
`-boundscheck=off` - Can easily mess up on the D side.
`shared` - Can't easily mess up on the D side. C side can still mess up.
`__gshared` - Can easily mess up on the D side.
Bounds are defined the same in both C and D -- you have a pointer and a
size, and you can't exceed that size. Yes, the data is conveyed
differently, but this is trivial to understand and use.
`shared` doesn't fix anything on the D side. All sides must use the same
mechanism to synchronize data. And there is no standard for
synchronizing data.
Consider if the proper way to use such a variable is to call
`properlyUse(int *)`, it won't accept a `shared int *`. Now you are
doubly-sure to mess up using it specifically because it's marked `shared`.
-Steve
