On Monday, 9 December 2013 at 09:13:20 UTC, John Colvin wrote:

> P.S. does anyone know how the GC interacts with core.stdc.free? I.e. if you free a pointer, but don't null the pointer, presumably the GC will still scan the memory despite it being freed. Isn't this undefined behaviour?

From what I understand, if you malloc a buffer it lies outside GC's managed heap, so a pointer to this place will not be followed during GC scan. Unless you explicitly told it to, by calling GC.addRange().

On Sunday, 8 December 2013 at 18:55:26 UTC, Namespace wrote:
> On Sunday, 8 December 2013 at 18:33:39 UTC, Joseph Rushton Wakeling wrote:
>> On 08/12/13 19:18, thedeemon wrote:
>>> I just use
>>>    scope(exit) delete buf;
>>
>> Deprecated or at least disapproved of, no?
>
> Sadly yes.

Unless I'm mistaken, the only thing that was deprecated was scoped as an attribute to variables.

The scope *statement* is till valid, and one of D's more powerful arguments in "simple and exception safe programming".

On Monday, 9 December 2013 at 12:29:44 UTC, monarch_dodra wrote:
> On Sunday, 8 December 2013 at 18:55:26 UTC, Namespace wrote:
>> On Sunday, 8 December 2013 at 18:33:39 UTC, Joseph Rushton Wakeling wrote:
>>> On 08/12/13 19:18, thedeemon wrote:
>>>> I just use
>>>>   scope(exit) delete buf;
>>>
>>> Deprecated or at least disapproved of, no?
>>
>> Sadly yes.
>
> Unless I'm mistaken, the only thing that was deprecated was scoped as an attribute to variables.
>
> The scope *statement* is till valid, and one of D's more powerful arguments in "simple and exception safe programming".

'delete' was meant. ;)

On Monday, 9 December 2013 at 12:32:36 UTC, Namespace wrote:
> On Monday, 9 December 2013 at 12:29:44 UTC, monarch_dodra wrote:
>> On Sunday, 8 December 2013 at 18:55:26 UTC, Namespace wrote:
>>> On Sunday, 8 December 2013 at 18:33:39 UTC, Joseph Rushton Wakeling wrote:
>>>> On 08/12/13 19:18, thedeemon wrote:
>>>>> I just use
>>>>>  scope(exit) delete buf;
>>>>
>>>> Deprecated or at least disapproved of, no?
>>>
>>> Sadly yes.
>>
>> Unless I'm mistaken, the only thing that was deprecated was scoped as an attribute to variables.
>>
>> The scope *statement* is till valid, and one of D's more powerful arguments in "simple and exception safe programming".
>
> 'delete' was meant. ;)

*slaps face*

08.12.2013 2:32, Namespace пишет:
> Since my last thread doesn't get much attention I like to ask here: How
> did you deal with temporary memory?

The algorithm is always this:

1. Use function stack frame for small allocations.
2. Use thread local stack allocator if temporary allocations corresponds LIFO principle and use thread local heap otherwise.

As for usability it must be a single function call and D type system have to rest.

> And what do you use?

As I answered in previous thread:
http://forum.dlang.org/thread/nxrxojbzbrfkkkkwvkqj@forum.dlang.org#post-l77th1:24icc:241:40digitalmars.com

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

On 09.12.2013 10:13, John Colvin wrote:
> On Sunday, 8 December 2013 at 19:00:29 UTC, Namespace wrote:
>>  > Just using new and GC.free would be fine, but there is really no
>>  > need to burden the GC with this at all; it's a textbook case for
>>  > C's malloc/free.
>> The GC relies also on malloc / free.
>
> Yes, it does. However, obviously it does a lot more than just call
> malloc/free.
>
> If you statically know the lifetime of a chunk of memory, then there
> really is no point invoking all that extra heavyweight code* when you
> can just DIY at no extra cost.**
>
>
> *and adding to the collection burden (if triggered while the memory is
> in scope)
>
> **However, take care with unique pointers from inside the allocated
> block to resources outside the block, as the GC might not be able to
> find them later (see P.S.).


I'm not sold on preferring C's malloc/free instead of the GC.

- The operations GC.malloc and GC.free are very similar to the operations of the C functions (if no collection is triggered). The current implementation uses OS calls to get more memory from the system, only few extra data is allocated via malloc. GC.malloc/free might be missing a few optimizations (like lock-free allocations for small memory chunks), but they were a lot faster than what dmc's C runtime used to be - before the latter was switched to simply call the OS heap functions very recently.

- if the GC.malloced memory does not contain pointers (e.g. allocated with new int[N]), it isn't scanned by the GC. Determining whether a pointer actually refers to GC managed memory or not might be faster for unmanaged memory, but this depends on the memory addresses.

- if the GC.malloced memory might contain pointers to GC managed memory (like object references), you need to add and remove the memory range so that the GC scans the memory, but especially removing the range gets pretty expensive if a lot of ranges are added.

>
>
> P.S. does anyone know how the GC interacts with core.stdc.free? I.e. if
> you free a pointer, but don't null the pointer, presumably the GC will
> still scan the memory despite it being freed. Isn't this undefined
> behaviour?

Like thedeemon said, a pointer not pointing to GC managed memory is ignored, so this should do no harm.