On 4/15/2014 12:12 PM, Steven Schveighoffer wrote:
What about syscalls?
Not sure what you mean by that, but obviously Windows API functions would be
@nogc.
Linux syscalls are not Windows API, they are extern(C) calls. Basically, we will
have to mark most as @nogc, right?
Right, just like nothrow.
or are extern(C) calls automatically considered @nogc?
No, just like for nothrow.
int isthisok(int x, int y) @nogc
{
// need scratch space
int[] buf = new int[x * y];
scope(exit) GC.free(buf.ptr);
// perform some algorithm using buf
...
//
return buf[$-1];
}
Valid?
No.
Must you use C malloc/free?
If you can GC/GCfree, then you can use malloc/free.
What if you can't use GC/GCfree? i.e. @nogc (the point of this thread)
Then use malloc/free.
What about such code that is @safe, which cannot call free?
There's no point to @nogc if you can still call the GC in it.
This is a follow-on to the previous question. Let's say you cannot use GC, but
clearly, I can use C malloc/free. Safe code that needs arbitrary buffers must
use C malloc/free to manage them, but safe cannot legally call free.
That's why @trusted exists.
I think we would need some sort of scoped allocator to make life bearable.
p = malloc(...);
scope(exit) free(p);
Let's be clear about the motivation for @nogc - there are a lot of people who
will not use D because of fear of GC. They want a guarantee that the GC isn't
being called. They don't want code that hides calls to GC.
