On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
Right now I have no idea where the development is headed and
what to expect from next few releases. I am not speaking about
wiki.dlang.org/Agenda but about bigger picture. Unexpected
focus on C++ support, thread about killing auto-decoding,
recent ref counting proposal
Just to add more salt:
http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx
Raymond Chen: " When you ask somebody what garbage collection is,
the answer you get is probably going to be something along the
lines of "Garbage collection is when the operating environment
automatically reclaims memory that is no longer being used by the
program. It does this by tracing memory starting from roots to
identify which objects are accessible."
This description confuses the mechanism with the goal. It's like
saying the job of a firefighter is "driving a red truck and
spraying water." That's a description of what a firefighter does,
but it misses the point of the job (namely, putting out fires
and, more generally, fire safety).
Garbage collection is simulating a computer with an infinite
amount of memory. The rest is mechanism. And naturally, the
mechanism is "reclaiming memory that the program wouldn't notice
went missing." It's one giant application of the as-if rule."
Interesting, in the comments, the distinction that is made
between finalizers and destructors, even if they happen to have
the same syntax, for example in C# and C++.
For example here:
http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx#10047776
I feel difficult to swallow the fact that D classes do not lend
themselves to RAII. While I could accept the memory management
could be left outside RAII, running destructors (or disposers)
deterministically is a must.
I particularily find bad that D recommends using structs to free
resources because the destructor of those is run automatically.
Just look at this example:
http://dlang.org/cpptod.html#raii
struct File
{
Handle h;
~this()
{
h.release();
}
}
void test()
{
if (...)
{
auto f = File();
...
} // f.~this() gets run at closing brace, even if
// scope was exited via a thrown exception
}
Even if C++ structs are almost the same as classes, the logical
solit between the two is: structs are DATA, classes are BEHAVIOR.
I will not get my head around the fact that I will *recommend*
putting methods in a struct.
