What exactly does the above statement mean?

Also, I have read here a principle that

If it looks like C, it behaves like C

How true is that for C++? Does code that look like C++(minus obvious syntax differences) behave like C++?

Does having the same memory model help?

Thanks for reading!!

On Tuesday, 10 August 2021 at 11:05:53 UTC, Tejas wrote:

No. D and C++ have different semantics for many things. One example is const. In C++, the following code is totally fine:

int n = 123; // mutable object
const int *p = &n; // const pointer
const_cast<int*>(p) = 456; // ok to mutate via p

However, the equivalent code in D is undefined behavior:

int n = 123; // mutable object
const(int)* p = &n; // const pointer
cast(int*)p = 456; // not allowed to mutate via p

On Tuesday, 10 August 2021 at 13:18:24 UTC, Paul Backus wrote:

int n = 123; // mutable object
const int *p = &n; // const pointer
const_cast<int*>(p) = 456; // ok to mutate via p

int n = 123; // mutable object
const(int)* p = &n; // const pointer
cast(int*)p = 456; // not allowed to mutate via p

Yes, I should've been more precise.

I was hoping for an answer in terms of implicit conversions, default constructors that get created by the respective compilers(ignoring the move constructors), sequence points(Walter said that the sequence point rules are same for D and C, so is it safe to assume they're the same as C++ as well?), also whether there is any difference in template instantiations(IFTI, or template argument detection rules)

Also, about the const thing, since there is no const_cast in D, therefore it is not the same as D, yet doesn't violate the statement that C++ that looks like D behaves the same as D, since that would require you to write (int*) but there's casting away const, a clearly seperate language feature which has no equivalent in D; it's kind of like saying that int a[] = [1,2,3] is not the same as in D since in D that's a dynamic array, not static. Yeah it isn't but there is an equivalent representation for it available, unlike const_cast

Sorry for the ambiguous statement below

Basically, what are the subtle gotcha's in the differences between C++ and D code that looks similar (again, I fully understanding I'm ambiguous here, but I simply don't know how to express this otherwise)

Thank you for replying!

On Tuesday, 10 August 2021 at 16:00:37 UTC, Tejas wrote:

You can cast away const in D: https://run.dlang.io/is/sWa5Mf

— Bastiaan.

On Tuesday, 10 August 2021 at 18:07:35 UTC, Bastiaan Veelo wrote:

Yes, but it is UB, not defined and supported by the standard/implementation.

On Tuesday, 10 August 2021 at 16:00:37 UTC, Tejas wrote:

The only gotcha that comes to my mind is that private means private to the module in D, not private to the aggregate.

— Bastiaan.

On Tuesday, 10 August 2021 at 18:13:17 UTC, Tejas wrote:

OK, strictly speaking casting away const is in the language, but modifying after that is UB.
https://dlang.org/spec/const3.html#removing_with_cast

— Bastiaan.

On Tuesday, 10 August 2021 at 21:19:39 UTC, Bastiaan Veelo wrote:

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.

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

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)

sizeof/alignof differs in D and C++(thank you evilrat)

On Wednesday, 11 August 2021 at 05:33:06 UTC, Tejas wrote:

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 publicly imports m2.

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

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

--Bastiaan.