shared array?

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, September 13, 2015 17:14:05 Prudence via Digitalmars-d-learn wrote:
> On Sunday, 13 September 2015 at 16:58:22 UTC, Ola Fosheim Grøstad
> wrote:
> > On Sunday, 13 September 2015 at 15:35:07 UTC, Jonathan M Davis
> > wrote:
> >> 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.
> >
> > I don't understand this argument. Even if the GC heap only
> > contains a single live object, you still have to scan ALL
> > memory that contains pointers.
> >
> > So how does programming like you do in Java affect anything
> > related to the GC?
> >
> > Or are you saying that finalization is taking up most of the
> > time?
>
> What if I happen to write a RT app that happens to use a part of
> phobo's that happens to heavily rely on the GC? Am I suppose to
> use -vgs all the time to avoid that? Do I avoid phobo's because 3
> functions in it use the GC? Am I suppose to memorize a table of
> all the places phobo's uses the GC and then roll my own to avoid
> them?

@nogc was added specifically to support folks who want to guarantee that
they aren't using the GC. If you want to guarantee that your function isn't
using the GC, then mark it with @nogc, and you try and call a function in it
that isn't @nogc (be it because it's not marked with @nogc, or it's a
templated function that wasn't inferred to be @nogc), then you'll get a
compilation error, and you'll know that you need to do something different.
Whether the function you're calling is in Phobos or a 3rd party library
doesn't really matter. If you want to be sure that it's @nogc, you'll just
have to mark your code with @nogc, and you'll catch any accidental or
otherwise unknown allocations. You can then use -vgc to figure out exactly
what is allocating in a function that you thought should be @nogc but can't
be. But you don't have to use it simply to find out whether your code is
using the GC or not. @nogc does that.

Yes, unlike C++, with D, if you don't want to use a GC at all, then you're
going to have be careful about how you write your code, because some
features use the GC (albeit not many), and some 3rd party code that you
might want to use (be it the standard library or someone else's code) is
likely going to end up using the GC, whereas in C++, that's not a concern.
But having the GC makes a lot of programs easier to write, and it does solve
some safety concern with regards to memory and allow us to have a few
features that C++ doesn't. If you're using the GC, D can guarantee memory
safety in a way that C++ can't. And that can be a big gain. And yes, that
can be a bit of a pain for those folks who can't use the GC, but that's not
the majority of programs, and the language and compiler do have tools for
supporting folks who insist on minimizing GC usage or even avoiding it
completely. So, it's not like the anti-GC folks are being left out in the
cold here. And work is being done to improve the GC and to make sure that
Phobos doesn't allocate using the GC except when it absolutely needs to. And
ranges are really helping with that.

Regardless, it's still the case that Phobos has never used the GC heavily.
It just hasn't always avoided it everywhere it could or should, and that's
being fixed. But it's always going to use the GC in some places, because
some things simply require it, and the language does have a GC. Those few
pieces of functionality will simply have to be avoided by anyone who insists
on never using the GC, and @nogc will help them ensure that they don't use
that functionality.

- Jonathan M Davis