The "no gc" crowd

dennis luehring dl.soluz at gmx.net
Wed Oct 9 01:17:32 PDT 2013


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/l322df$1n8o$1@digitalmars.com
>>
>> 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





More information about the Digitalmars-d mailing list