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.
