www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - D has the same memory model as C++

reply Tejas <notrealemail gmail.com> writes:
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!!
Aug 10 2021
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 10 August 2021 at 11:05:53 UTC, Tejas wrote:

 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++?


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

```c++
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:

```d
int n = 123; // mutable object
const(int)* p = &n; // const pointer
cast(int*)p = 456; // not allowed to mutate via p
```
Aug 10 2021
parent reply Tejas <notrealemail gmail.com> writes:
On Tuesday, 10 August 2021 at 13:18:24 UTC, Paul Backus wrote:

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

 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++?


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

 ```c++
 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:

 ```d
 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!
Aug 10 2021
next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Tuesday, 10 August 2021 at 16:00:37 UTC, Tejas wrote:

 there's casting away const, a clearly seperate language feature 
 which has no equivalent in D;


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

— Bastiaan.
Aug 10 2021
parent reply Tejas <notrealemail gmail.com> writes:
On Tuesday, 10 August 2021 at 18:07:35 UTC, Bastiaan Veelo wrote:

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

 there's casting away const, a clearly seperate language 
 feature which has no equivalent in D;


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

 — Bastiaan.


Yes, but it is UB, not defined and supported by the 
standard/implementation.
Aug 10 2021
parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Tuesday, 10 August 2021 at 18:13:17 UTC, Tejas wrote:

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

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

 there's casting away const, a clearly seperate language 
 feature which has no equivalent in D;


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

 — Bastiaan.


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


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.
Aug 10 2021
prev sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
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.
Aug 10 2021
parent reply Tejas <notrealemail gmail.com> writes:
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.

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)
Aug 10 2021
parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
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.
Aug 11 2021
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
This is an interesting thread but "memory model" does not cover or mean 
all of the points discussed here. I can't define it precisely, so I'm 
leaving it to interested parties to search for themselves. :)

Ali
Aug 11 2021
parent reply Tejas <notrealemail gmail.com> writes:
On Wednesday, 11 August 2021 at 19:04:50 UTC, Ali Çehreli wrote:

 This is an interesting thread but "memory model" does not cover 
 or mean all of the points discussed here. I can't define it 
 precisely, so I'm leaving it to interested parties to search 
 for themselves. :)

 Ali


A little bit of spoon feeding isn't bad, right?

Atleast leave some pointers on where to start :(
Aug 11 2021
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 8/11/21 12:19 PM, Tejas wrote:


 Atleast leave some pointers on where to start :(


I DuckDuckGo'ed it for you. :)

   https://en.cppreference.com/w/cpp/language/memory_model

Then looked it up at Wikipedia too:

   https://en.wikipedia.org/wiki/Memory_model_(programming)

Ali
Aug 11 2021
parent reply Tejas <notrealemail gmail.com> writes:
On Wednesday, 11 August 2021 at 19:27:34 UTC, Ali Çehreli wrote:

 On 8/11/21 12:19 PM, Tejas wrote:


 Atleast leave some pointers on where to start :(


 I DuckDuckGo'ed it for you. :)

   https://en.cppreference.com/w/cpp/language/memory_model

 Then looked it up at Wikipedia too:

   https://en.wikipedia.org/wiki/Memory_model_(programming)

 Ali


I was hoping on material regarding. c++ vs D memory model, not 
C++ model alone. That's the problem. For pure C++, there's even 
the paper by Stroustroup et al. which feels pretty definitive.

That's why I asked here whether anyone could tell me about the 
subtle differences between C++ and D, with regards to memory 
model, or any other features that share surface resemblance, but 
are different underneath.
Aug 11 2021
parent Paul Backus <snarwin gmail.com> writes:
On Wednesday, 11 August 2021 at 19:38:38 UTC, Tejas wrote:

 On Wednesday, 11 August 2021 at 19:27:34 UTC, Ali Çehreli wrote:

 On 8/11/21 12:19 PM, Tejas wrote:


 Atleast leave some pointers on where to start :(


 I DuckDuckGo'ed it for you. :)

   https://en.cppreference.com/w/cpp/language/memory_model

 Then looked it up at Wikipedia too:

   https://en.wikipedia.org/wiki/Memory_model_(programming)

 Ali


 I was hoping on material regarding. c++ vs D memory model, not 
 C++ model alone. That's the problem. For pure C++, there's even 
 the paper by Stroustroup et al. which feels pretty definitive.

 That's why I asked here whether anyone could tell me about the 
 subtle differences between C++ and D, with regards to memory 
 model, or any other features that share surface resemblance, 
 but are different underneath.


D's memory model is described on this page of the language spec:

https://dlang.org/spec/intro.html

I'm not super familiar with C++'s memory model, but just from 
eyeballing the cppreference page, it looks like the main 
difference between the C++ and D memory models is how they handle 
access to memory from multiple threads. In particular, D makes a 
distinction between "thread-local memory locations", which may 
only be accessed from one thread, and "shared memory locations", 
which may be accessed from multiple threads. In C++, any memory 
location can be accessed from any thread.

The other big difference is that D's spec does not really define 
its terms. What exactly it means for a thread to "access" a 
memory location, or for concurrent accesses to be "synchronized", 
is never actually explained. For these details, it is *probably* 
safe to fill in the blanks with the equivalent definitions from 
C++.
Aug 11 2021