Am 09.10.2013 10:17, schrieb dennis luehring:
Am 09.10.2013 10:05, schrieb Andrei Alexandrescu:
On 10/9/13 12:58 AM, dennis luehring wrote:
Am 09.10.2013 09:51, schrieb Andrei Alexandrescu:
On 10/9/13 12:01 AM, Mehrdad wrote:
On Wednesday, 9 October 2013 at 03:39:38 UTC, Andrei Alexandrescu wrote:
On 10/8/13 4:45 PM, Jonathan M Davis wrote:
On Wednesday, October 09, 2013 01:04:39 Tourist wrote:
I thought about an alternative approach:
Instead of using a (yet another) annotation, how about
introducing a flag similar to -cov, which would output lines in
which the GC is used.
This information can be used by an IDE to highlight those lines.
Then you could quickly navigate through your performance-critical
loop and make sure it's clean of GC.
That sounds like a much less invasive approach no a @nogc attribute.
Problem is with functions that have no source available.
Andrei
Mangle the @nogc it into the name?
That would work. Then anything that doesn't have @nogc counts as an
allocation, and the corresponding line will be labeled as such. (I
suspect that would cause a bunch of false positives in systems that
don't add @nogc systematically.)
Andrei
but maybe combined with adam ruppes idea in thread
http://forum.dlang.org/post/[email protected]
will reduce the false postive amount faster
I'm hesitant about stuff that computes function summaries such as
__traits(getFunctionsCalled, function) without allowing those summaries
to make it into the function's signature or attributes. It makes
separate compilation difficult.
what speaks against doing it so (after thinking about it a long long
time...) i think D needs a proper way of express the function "features"
compatible with seperated compilation, and there is nothing else as the
signature - as long as D don't get its own internal object format, and
still want to be C link compatible
same goes to nothrow, pure, safe, ... and nogc (and possible noarc to
even prevent auto reference counting in hierachy if it mabye comes in
the future)
