shared array?

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, September 12, 2015 13:42:42 Prudence via Digitalmars-d-learn wrote:
> On Saturday, 12 September 2015 at 06:23:12 UTC, Jonathan M Davis
> wrote:
> > On Friday, September 11, 2015 23:29:05 Laeeth Isharc via
> > Digitalmars-d-learn wrote:
> >> On Friday, 11 September 2015 at 21:58:28 UTC, Adam D. Ruppe
> >> wrote:
> >> > [...]
> >>
> >> Seems to be quite a lot of FUD wrt use of standard library and
> >> GC, which means also perhaps we don't communicate this point
> >> very well as a community.  Making Phobos GC-optional perhaps
> >> is an ultimate answer.  But people seem to think that you're
> >> back to C without the GC.
> >
> > Aside from the few classes in Phobos, its GC usage is almost
> > entirely restricted to when it allocates arrays or when it has
> > to allocate a closure for a delegate, which can happen in some
> > cases when passing predicates to range-based algorithms.
> > Avoiding functions that need to allocate arrays avoids that
> > source of allocation, and using functors or function pointers
> > as predicates avoids having to allocate closures. So, you _can_
> > end up with GC allocations accidentally in Phobos if you're not
> > careful, but on the whole, the assertion that Phobos uses the
> > GC heavily is FUD - or at least a misunderstanding. But as we
> > make more of the functions use lazy ranges rather than arrays
> > (particularly with regards to strings), and we make more of the
> > code @nogc, it becomes even clearer that the GC isn't involved.
> > Also, improvements to how lambdas are handled should reduce how
> > often closures have to be allocated for them.
> >
>
> I don't think it's that simple.
>
> Saying that it doesn't use it most of the time is not an
> answer/solution. Using it at all is a problem because one doesn't
> know when and where. I realize there is a switch now(-vgc), and
> maybe that is the solution, but you say "well, phobos only uses
> 0.01% on the GC", yet since you either don't, can't, or won't
> know where that is, then it might as well be 100% if you would
> like to potentially get off the GC one day.
>
> It's like playing Russian roulette. It doesn't matter if only 1/6
> times will kill you. It's totally different than 0/6.

If someone wants to avoid the GC entirely, then they need to use @nogc and
-vgc to verify that they didn't miss marking something with @nogc somewhere
whether they're using Phobos or not. But regardless, it's still FUD to claim
that Phobos uses the GC heavily. And the reality of the matter is that the
vast majority of programs will have _no_ problems with using the GC so long
as they don't use it heavily. Programming like you're in Java and allocating
everything on the heap will kill performance, but idiomatic D code doesn't
do that, and Phobos doesn't do that. Far too many programmers freak out at
the thought of D even having a GC and overreact thinking that they have to
root it out completely, when there really is no need to. Plenty of folks how
written highly performant code in D using the GC. You just have to avoid
doing a lot of allocating and make sure you track down unwanted allocations
when you have a performance problem.

@nogc will help folks avoid allocations that they don't intend to have, and
other improvements to Phobos like rangifying most of the array/string-based
stuff such that very little functionality actually needs to operate on
arrays and instead is able to operate on lazy ranges will help as well. But
the idea that your average D program is going to run into problems with the
GC while using Phobos is just plain wrong. The folks who need to care are
the rare folks who need extreme enough performance that they can't afford
for the GC to _ever_ stop the world. And anyone who cares that much is
simply going to have to avoid using new anywhere in their code, and if they
use any code that they don't write - Phobos included - they will need to
verify whether the GC is being used or not by that coding @nogc or by using
-vgc. That's not going to change no matter what we do with Phobos. And it
doesn't change the fact that it's just plain wrong to claim that Phobos
requires the GC. _Some_ of its functionality does. The vast majority of it
doesn't, and anyone who cares enough to make sure that they don't use the GC
while using Phobos can mark their code with @nogc to make sure that they
don't accidentally use something in Phobos which could allocate on the GC
heap.

- Jonathan M Davis