D has the same memory model as C++

[Bastiaan Veelo]

On Wednesday, 11 August 2021 at 05:33:06 UTC, Tejas wrote:
> On Tuesday, 10 August 2021 at 21:19:39 UTC, Bastiaan Veelo 
> wrote:
>> On Tuesday, 10 August 2021 at 16:00:37 UTC, Tejas wrote:
>>> Basically, what are the subtle gotcha's in the differences 
>>> between C++ and D code that looks similar
>>
>> The only gotcha that comes to my mind is that `private` means 
>> private to the module in D, not private to the aggregate.
>>
>> — Bastiaan.
>
> A few others that I know:
>
> When importing one module(say ```m2```) into another (say 
> ```m1```), the symbols of ```m1``` aren't automatically visible 
> in ```m2```. You must import ```m1``` in ```m2``` for that.

How is that different from C++? I think you meant to say that if 
`m1` imports `m2`, the symbols of `m2` don't automatically become 
visible by importing `m1`. Indeed you also have to import `m2` 
for that, *unless* `m1` `public`ly imports `m2`.

> You can't just initialize variables willy-nilly in a module, 
> you must do them inside ```static this()```

Or declare them with an initial value. I'm not aware of a rule 
that requires module level variables to be initialized in `static 
this()`, but if you require them to be initialized at startup 
with a value not known at compile time, then that is the place to 
do it. I don't think you can go about this willy-nilly in C++ 
either...

> Method function pointers don't exist in D, equivalent 
> functionality is achieved by using a delegate that captures the 
> context of a class instantiated object.
>
> To use a function pointer explicitly, you can't just write 
> ```(func)(arguments)```, it is ```(&func)(arguments)```(thank 
> you evilrat)

To take the address of a method (in order to assign it to a 
delegate) requires `&`, yes, but not when calling the delegate.

--Bastiaan.