On Tuesday, 20 November 2018 at 19:11:46 UTC, Steven Schveighoffer wrote:
On 11/20/18 1:04 PM, Johan Engelen wrote:

D does not make dereferencing on class objects explicit, which makes it harder to see where the dereference is happening.

Again, the terms are confusing. You just said the dereference happens at a.foo(), right? I would consider the dereference to happen when the object's data is used. i.e. when you read or write what the pointer points at.

But `a.foo()` is already using the object's data: it is accessing a function of the object and calling it. Whether it is a virtual function, or a final function, that shouldn't matter. There are different ways of implementing class function calls, but here often people seem to pin things down to one specific way. I feel I stand alone in the D community in treating the language in this abstract sense (like C and C++ do, other languages I don't know). It's similar to that people think that local variables and the function return address are put on a stack; even though that is just an implementation detail that is free to be changed (and does often change: local variables are regularly _not_ stored on the stack [*]).

Optimization isn't allowed to change behavior of a program, yet already simple dead-code-elimination would when null dereference is not treated as UB or when it is not guarded by a null check. Here is an example of code that also does what you call a "dereference" (read object data member):
```
class A {
    int i;
    final void foo() {
        int a = i; // no crash with -O
    }
}

void main() {
    A a;
    a.foo();  // dereference happens
}
```

When you don't call `a.foo()` a dereference, you basically say that `this` is allowed to be `null` inside a class member function. (and then it'd have to be normal to do `if (this) ...` inside class member functions...)

These discussions are hard to do on a mailinglist, so I'll stop here. Until next time at DConf, I suppose... ;-)

-Johan

[*] intentionally didn't say where those local variables _are_ stored, so that people can solve that little puzzle for themselves ;-)

  • Re: Why does nobody seem ... Steven Schveighoffer via Digitalmars-d-learn
    • Re: Why does nobody ... Jordi GutiĆ©rrez Hermoso via Digitalmars-d-learn
      • Re: Why does nob... Steven Schveighoffer via Digitalmars-d-learn
        • Re: Why does... Jonathan M Davis via Digitalmars-d-learn
        • Re: Why does... Johan Engelen via Digitalmars-d-learn
          • Re: Why ... Steven Schveighoffer via Digitalmars-d-learn
            • Re:... Johan Engelen via Digitalmars-d-learn
              • ... Neia Neutuladh via Digitalmars-d-learn
              • ... Johan Engelen via Digitalmars-d-learn
              • ... Patrick Schluter via Digitalmars-d-learn
              • ... Johan Engelen via Digitalmars-d-learn
              • ... Steven Schveighoffer via Digitalmars-d-learn
              • ... Timon Gehr via Digitalmars-d-learn
            • Re:... NoMoreBugs via Digitalmars-d-learn
          • Re: Why ... Jonathan M Davis via Digitalmars-d-learn
          • Re: Why ... Johan Engelen via Digitalmars-d-learn
            • Re:... Kagamin via Digitalmars-d-learn

Reply via email to