Classes in D with betterC

[Stanislav Blinov]

On Monday, 22 November 2021 at 12:57:27 UTC, Luís Ferreira wrote:
> On Mon, 2021-11-22 at 03:36 +0000, Stanislav Blinov via 
> Digitalmars-d- announce wrote:
>> On Sunday, 21 November 2021 at 20:30:51 UTC, Luís Ferreira 
>> wrote:
>> 
>> > I decided to have a simple approach just to show that it is
>> > easier now to do that without workarounds, and by 
>> > workarounds,
>> > I mean using scope to fetch that info and use a fake dtor, or
>> > even before scope exists, the usage of runtime-less D call 
>> > with
>> > betterC + objcopy, described
>> > [here](
>> > https://theartofmachinery.com/2018/05/27/cpp_classes_in_betterc.
>> > html).
>> 
>> I get that the news part is all about `__traits(initSymbol)`, 
>> which in this case is about instantiating a class without 
>> druntime.
>
> Yes and this is by far harder than the past/previous approach, 
> as you refered wrongly, "this has been possible for ages".

It has been, with workarounds. Which, even in that case, all the 
other problems still apply.

>> But that's just one line in the whole example. And the rest of 
>> the code? Construction may either fail altogether or cause 
>> unnecessary copies.
>
> I acknowledge that is a thing to consider, when doing generic 
> code. I'm going to be honest and say that I did't though about 
> those cases at the time of writing. The particular case is not 
> wrong however, it is just limitative to types without such 
> qualifiers. If I went that far, probably there is a number of 
> things wrong. What if I want an `immutable` version of T? I 
> simply, didn't thought about it, mostly because the point of 
> that zettelkasten was to show `__traits(initSymbol)` off.

But that is my point. You're showcasing __traits(initSymbol) but 
that is not at all what your article advertises :)

>> Calling __dtor won't call destructors of base classes or 
>> derived classes. There may not even be a __dtor yet 
>> destruction may still be required through __xdtor, which still 
>> would not destruct base or derived classes.
>
> This is an undocumented feature that I didn't know about. I'm 
> going to do a specification PR to amend it.

Awesome!

>> Deallocation can't be @trusted since you don't have a facility 
>> to prove that no other references exist.
>
> Yes, that is totally wrong and should be fixed, alhtough 
> trusting pureMalloc is fine.

Yup.

>> If anything, the code shows how NOT to use
>> classes, contrary to what your title or preface say ;)
>> Even simple, an example should at least be correct, don't you
>> think?
>
> I think you unproportionally scaled your argument -- the 
> article is not a complete how-to guide in classes -- althouh I 
> agree that a simple example like the one presented should be 
> correct.

Have I? The article is named "Classes in D with betterC", the 
preface states "Did you know that you can use classes in D as 
better C? Yes, you read correctly, you can actually use classes 
in D with -betterC." It's not at all clear that all you *really* 
mean and want to address is instantiation thanks to 
__traits(initSymbol).

Maybe it's a language or cultural issue? I'm not being bashful. 
"Use classes", at least to me, means, well, "use classes", and 
not "use a subset of classes that's really not much better than 
structs as you can't fully support inheritance anyway because 
destruction is a mess".

In other words, in order to fully appreciate the message of your 
article, one has to already be aware of all the other issues. 
Which is a dangerous presupposition for a public article, 
especially not prefaced accordingly.

> Thanks for your input! I'm going to fix the issues you 
> presented.

You're welcome :)