https://caiorss.github.io/C-Cpp-Notes/cpp-alternatives.html

Some good ol' C++ bashing. I found this interesting: if a polymorphic type gets passed by value, it loses its polymorphism. I haven't seen it spelled out like this before, but makes sense. Why mentioning it specifically though?

D is mentioned first in the General purpose section, along with some interesting choices (like ATS).
From a first couple skims, there are probably a few inaccuracies about all of them. But I liked the linked videos section and it's quite nice that somebody made it into an easily readable summary.

On 3/8/21 10:31 AM, Istvan Dobos wrote:

> https://caiorss.github.io/C-Cpp-Notes/cpp-alternatives.html
>
> Some good ol' C++ bashing. I found this interesting: if a polymorphic
> type gets passed by value, it loses its polymorphism. I haven't seen it
> spelled out like this before, but makes sense. Why mentioning it
> specifically though?

I may be responsible for that specific poing because the article lists my C++Now 2017 presentation as a reference where I mentioned reference types as a D objection at this moment in the presentation:

  https://youtu.be/vYEKEIpM2zo?t=3084

I remember Atila and others being surprised that I thought reference types were a D objection of C++ programmers. Here is the story why I thought C++ programmers may have that objection:

I co-organized and attended a presentation by Sean Parent at the Silicon Valley Chapter of the ACCU. Sean Parent lists multiple "ACCU" presentations below, so I can't be sure exactly which one that was:

  https://sean-parent.stlab.cc/papers-and-presentations/

I remember Andrei Alexandrescu and other C++ people were in the audience as well.

I may not remember this accurately but final slides of Sean Parent's presentation included his ambitions on writing a framework where he was hoping to be able to define the transitions of the code beforehand like state transitions. That made sense considering the first part of his presentation where he was advocating removing explicit language constructs like loops from the code. (This idea has been popularized by his famous "that's rotate" words, which has been referenced by other presenters as well.)

Seeing how difficult his ambitions would be achievable in C++ of that time, I approached him at the end of the presentation and said "Have you considered D? Because what you're trying to do...". I couldn't finish my sentence because he said "A language with reference types? No thanks!" while using a hand gesture that looked like "brushing away", and walked away.

Looking back after all these years, I think his objection might have been to garbage collectors. I don't know. But I never forgot that interaction and used that point in multiple presentations that C++ indeed has reference types of the worst kind: by programmer education through guidelines. D wins over C++ here as well by providing both reference types and value types. My only regret is the space cost of the monitor pointer of all D class objects. So, I hereby help populatize something I learned recently: extern(C++) class definitions don't have that monitor pointer:

// Smaller object:
extern (C++) class C {
  // ...
}

Anyway... This is the first time I told that story publicly. :)

Ali

On Monday, 8 March 2021 at 21:00:47 UTC, Ali Çehreli wrote:
> On 3/8/21 10:31 AM, Istvan Dobos wrote:
>
> > https://caiorss.github.io/C-Cpp-Notes/cpp-alternatives.html
> >
> > Some good ol' C++ bashing. I found this interesting: if a
> polymorphic
> > type gets passed by value, it loses its polymorphism. I
> haven't seen it
> > spelled out like this before, but makes sense. Why mentioning
> it
> > specifically though?
>
> I may be responsible for that specific poing because the article lists my C++Now 2017 presentation as a reference where I mentioned reference types as a D objection at this moment in the presentation:
>
>   https://youtu.be/vYEKEIpM2zo?t=3084
>
> I remember Atila and others being surprised that I thought reference types were a D objection of C++ programmers.

As someone who is trying to write a reference counting system at the moment, reference types are a massive pain.

Class instances exist, and are semantically entirely distinct entities from the references to them. Being forbidden to name or otherwise represent the type of a class instance, and therefore forbidden to introspect it properly, sucks. Having to special-case classes and interfaces everywhere, because they are accessed at a different level of indirection, sucks.

D's powerful meta-programming capabilities allow me to work around most of these issues, but I shouldn't have to. Passing class instances by reference is a best practice that applies most of the time, not a fundamental truth that should be enforced by the language.

On Monday, 8 March 2021 at 21:00:47 UTC, Ali Çehreli wrote:
> My only regret is the space cost of the monitor pointer of all D class objects. So, I hereby help populatize something I learned recently: extern(C++) class definitions don't have that monitor pointer:
>
> // Smaller object:
> extern (C++) class C {
>   // ...
> }

I think this critical bug I discovered today needs to be fixed before that's a good idea: dynamic casts seem to be completely broken for extern(C++) classes.
    https://issues.dlang.org/show_bug.cgi?id=21690
This can manifest as a logic error, memory corruption, or a security vulnerability depending on the circumstances.

More mundanely, extern(C++) mangling can't distinguish some overloads that extern(D) can. Thankfully, this problem can be worked around in an easy (albeit ugly) way:

    extern(C++) class C { extern(D):
        // ...
    }

In particular, I found the above necessary to enable overloading on `shared` with extern(C++) class methods.

On Monday, 8 March 2021 at 21:00:47 UTC, Ali Çehreli wrote:
> So, I hereby help populatize something I learned recently: extern(C++) class definitions don't have that monitor pointer:
>
> // Smaller object:
> extern (C++) class C {
>   // ...
> }

So, it turns out that I actually found TWO critical, show-stopping bugs in extern(C++) class support today (thanks @kinke):

"Unable to dynamic cast extern(C++) classes":
    https://issues.dlang.org/show_bug.cgi?id=21690
"extern(C++) class instance dtors are never called, breaking RAII":
    https://issues.dlang.org/show_bug.cgi?id=21693

I believe extern(C++) classes need more testing before they should be recommended solely as a means to save one pointer's worth of memory...

I need them to work for other reasons, though, so I hope these get fixed.

On 3/8/21 4:02 PM, tsbockman wrote:

> So, it turns out that I actually found TWO critical, show-stopping bugs
> in extern(C++) class support today (thanks @kinke):

I am happy to be involved in exposing bugs by being under-informed. :)

Once, I used the following construct during a presentation thinking that it would grab both locks:

  synchronized(a, b) {
    // ...
  }

Steven Schveighoffer corrected me during the presentation and later worked on crippling the comma operator in D. :)

Ali

On Monday, 8 March 2021 at 21:00:47 UTC, Ali Çehreli wrote:

>
> Anyway... This is the first time I told that story publicly. :)
>
> Ali

And I'm happy you did, Ali! Love reading folklore from the "Native Tribe" (or any tribe for that matter) :)

On Tuesday, 9 March 2021 at 01:43:25 UTC, Ali Çehreli wrote:
> On 3/8/21 4:02 PM, tsbockman wrote:
>
> > So, it turns out that I actually found TWO critical,
> show-stopping bugs
> > in extern(C++) class support today (thanks @kinke):
>
> I am happy to be involved in exposing bugs by being under-informed. :)

Well, it was a good idea - it *should* work - it just turns out that it doesn't, at the moment...