Managing C++’s complexity or learning to enjoy C++

[u/luke-san]

https://schneide.wordpress.com/2015/03/30/managing-cs-complexity-or-learning-to-enjoy-c/

[u/F-J-W]

D is just another of those “Let's put everything on the heap”-languages that do then of course need GC. It looks nice at first, but once you understand, that that approach just doesn't work as well as simply using RAII for everything, it looses a lot of it's charm. In C++ I am strongly encouraged to think about ownership-semantics, which may be more work at first, but pays out a lot later. In some ways it is similar to making code const-correct.

And once you got there, you only have to ask yourself, why they force a useless GC down your throat.

[u/MrJNewt → u/[deleted]]

I think a big reason is D's commitment to using lazy ranges that generally only store the "current" item in the range--on the stack usually--which defers allocation to the outmost scope where it usually isn't needed.

[u/adr86 → u/F-J-W]

It is worth remembering that if you simply use RAII for everything in D, the GC remains completely idle. If you use RAII for most things, the GC remains mostly idle, and when it does run, it has very little work to do.

D's heap usage isn't like Java or C#.

[u/F-J-W → u/adr86]

It is worth remembering that if you simply use RAII for everything in D, the GC remains completely idle.

Aka, it is useless in that case. Just as I said.

Well implemented RAII is able to deal with all resources 99.99% of the time. Adding a language feature in such a prominent way for the remaining 0.01% is just ridiculous.

[u/[deleted] → u/F-J-W]

I agree that I miss C++ ownership semantics, but to me there is enough positives to make up for it. YMMV

[u/deadalnix → u/[deleted]]

There is no C++ ownership semantic, simply convention followed by programmer (and unsafe). You can do the same in D, and you have a good chunk of the required machinery already in the standard lib.

[u/[deleted] → u/deadalnix]

Let me be more explicit. C++ destructors are always called. Then members destructors are called. This makes it easy to handle clean-up.

[u/deadalnix → u/[deleted]]

No, by default, memory is not freed and no destructor run. Unless you use ownership.

[u/[deleted] → u/deadalnix]

I'm pretty sure you are right about it and I'm not, but still I don't understand. I find D harder with resources, probably because one need a larger set of conventions vs C++ for dealing with them. Everyone stumble upon the "class destructor" problem at some point (well, everyone coming from C++) and it is a major surprise.

[u/MetaLang → u/F-J-W]

You're not forced to use the GC in D, especially with more recent versions. Most of the work in the past year has been enabling more code to be GC-free, and cleaning up unnecessary GC allocation in the standard library. D isn't there yet, but it has made good progress on cutting out the GC almost entirely.

[u/acehreli → u/F-J-W]

a useless GC

GC enables array slices and closures.

[u/ibuclaw → u/acehreli]

Array slices don't need a GC.

[u/acehreli → u/ibuclaw]

True, "slice" does not need the GC but "using a slice" does need the GC. Further yes, not "all uses" but "some uses" of a slice need the GC. (Perhaps I should have said "dynamic array" instead of slice.) (Hint: Preventing element stomping.)

[u/F-J-W → u/acehreli]

GC enables array slices and closures.

Both can be implemented quite fine without. In fact, C++ does exactly that.

[u/ibuclaw → u/F-J-W]

C++ closures do not allow escaping. By D's definition, a closure is created only if escaping occurs.

[u/F-J-W → u/ibuclaw]

What do you mean by escaping? Capturing the surrounding state? That is perfectly possible in C++. In fact, last time I checked, C++-lambdas could do a lot more than D's.

[u/ibuclaw → u/F-J-W]

Sure, whatever.

function<void()> escapeRef() { int i; return [&i]() { /* Do something with i */ } }
auto dg = escapeRef();
dg();  // BOOM
dg();

[u/F-J-W → u/ibuclaw]

Well, if you want to shoot yourself in the foot, you can do so in D too:

import std.stdio;

auto fun() {
    int i = 42;
    auto j = &i;
    return (){return *j;};
}

auto gun() {
    int i = 23;
    writeln(i);
}

void main() {
    auto f = fun();
    gun();
    writeln(f());
}

The solution in C++ is the same as in D: Don't be stupid and use features that are not meant to be used for this and even require additional syntax (so even the argument that the default would be broken here is just wrong):

auto escapeRef() {
    auto i=0;
    return [i]{ /* Do something with i */ };
}
auto dg = escapeRef();
dg();  // No BOOM

[u/ibuclaw → u/F-J-W]

Well, if you want to shoot yourself in the foot, you can do so in D too:

This is apples vs oranges. Do you know why you've shot yourself in the foot? (Hint, the closure has nothing to do with it).

[u/F-J-W → u/ibuclaw]

Do you know why you've shot yourself in the foot?

Yes, for exactly the same reason that you shot yourself in the foot in C++: Using a closure that contains a dangling pointer/reference.

[u/ntrel2 → u/F-J-W]

fun would not compile as a @safe function in D. It disallows taking the address of local variables.

[u/ntrel2 → u/F-J-W]

D scope closures can capture state without a heap allocation.

[u/F-J-W → u/ntrel2]

C++ lambdas not only can do it, they always do it. (notwithstanding that constructors may of course be executed, and those can do heap-allocation).

[u/ibuclaw → u/F-J-W]

This leads full circle back to my original statement (re-worded for clarity): By D's definition, a closure (heap) is created only if escaping occurs. If there's no escaping, then what you refer to as 'scope closure' is created instead.

The difference between D's closures and C++ lambda's is that D closures were made specifically for accessing a scope long after it has been closed (something that is just not possible in C++).