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