On Monday, 14 July 2014 at 06:13:38 UTC, Manu via Digitalmars-d
wrote:
On 14 July 2014 14:47, uri via Digitalmars-d
<digitalmars-d@puremagic.com>
wrote:
On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:
- I was *very* disappointed that using base library locks you
into GC vs
ref. counting.
Separate, I like how Objective C has NSObject for GC
purpose(I'd love a
framework that is just ref counting), but there should be
dual libs and
base should not be GC.
This topic was bashed to death. There were compelling arguments
from both sides, but in the end no one pushing for ARC could
produce evidence that it was better than GC.
Andrei himself pushed such evidence in an interesting case
study that
explored a high-end ARC implementation. It compared
impressively with 'the
fastest GC's' (or some description very close to that). D's GC
is certainly
not among those in comparison, which suggested the paper's tech
would
probably be a win for D no matter how you look at it.
And the counter evidence is overwhelming. As many times as I've
asked the
experts for comment, I've still *NEVER* heard anybody disagree
that D's GC
will probably remain really bad for the indefinite future. Even
the ones
that are strongly in favour of GC; nobody seems to know how to
do it, and
many have said it's probably impossible.
Even if it was theoretically possible, that only solves one of
numerous
problems... Nobody has ever addressed the low-available-memory
argument
I've put forward a number of times, which is the standard
operating
environment of most embedded computers.
So, I don't feel like there was any such conclusion as you
suggest.
Personally, I just became horribly apathetic and gave up. My
general
participation and motivation in this community has declined
significantly
as a result.
I'm among the minority that REALLY care about this, and it's
clear (and
it's been made clear) that if I'm not prepared to work on it
myself, then
it won't move forward.
That's fine, and it's perfectly reasonable. But I'm not in the
least bit
interested in working on GC technology myself - I'm not an
expert, and it's
not a field that interests me, thus I decided to desist
participating in
discussions.
Currently there's a big push to remove hidden GC allocs from
Phobos, starting with @nogc.
std.allocators is just around the corner as well, which will
provide a solid framework to build better allocation
strategies.
We're yet to see how to use the allocators API to specify a
replacement
default allocator used by the languages intrinsic allocations,
which makes
it rather less exciting.
Anyone can invent an allocator interface, but designing it such
that it can
be used to configure the languages implicit allocations is much
more
complex. I'm concerned that Andrei's allocator interface
doesn't actually
address this... At least, I haven't seen any discussion about
how it will.
That said, I'm not trying to down-play the importance of a
standard
allocator API, and Andrei's development is very important and
appreciated,
but I am yet to find out how it actually addresses any of my
real concerns
relating to allocation.
As I see it, I have zero concern about allocations I control. I
am entirely
concerned with intrinsic/implicit allocations that I don't, and
may
potentially (likely) originate from within 3rd party libraries.
All good points. Thanks and my bad for the misinformation, sorry.
uri