Andrei Alexandrescu Wrote:

> most GC's cannot provide efficient manual reclamation. And they shouldn't anyway.
>
If one doesn't want to implement a function, he can throw NotImplementedException, or don't provide the function so that program using the delete won't link. But deallocation of allocated memory is not that unthinkable just because it can be hard.

On 07/14/2010 01:15 AM, Kagamin wrote:
> Andrei Alexandrescu Wrote:
>
>> most GC's cannot provide efficient manual reclamation. And they
>> shouldn't anyway.
>>
> If one doesn't want to implement a function, he can throw
> NotImplementedException, or don't provide the function so that
> program using the delete won't link.

And how would you use such a feature effectively? I've seen such
"optional implementation" policies in standards such as SQL (compatibility levels) and C++ (export). They _always_ fare disastrously.

> But deallocation of allocated
> memory is not that unthinkable just because it can be hard.

It's not about difficulty as much as constraining GC implementers unnecessarily. Again: use a heap tuned for manual management to manage memory manually, and a heap tuned for automatic management to manage memory automatically. I think it's a very reasonable stance.


Andrei

Andrei Alexandrescu wrote:
> On 07/14/2010 01:15 AM, Kagamin wrote:
>> Andrei Alexandrescu Wrote:
>>
>>> most GC's cannot provide efficient manual reclamation. And they
>>> shouldn't anyway.
>>>
>> If one doesn't want to implement a function, he can throw
>> NotImplementedException, or don't provide the function so that
>> program using the delete won't link.
> 
> And how would you use such a feature effectively? I've seen such
> "optional implementation" policies in standards such as SQL (compatibility levels) and C++ (export). They _always_ fare disastrously.
> 
>> But deallocation of allocated
>> memory is not that unthinkable just because it can be hard.
> 
> It's not about difficulty as much as constraining GC implementers unnecessarily. Again: use a heap tuned for manual management to manage memory manually, and a heap tuned for automatic management to manage memory automatically. I think it's a very reasonable stance.
> 
> 
> Andrei

"use a heap tuned for manual management to manage memory manually ..."

So do I call in a piano tuner having both an ear for perfect pitch
and extreme programming skills at $blackmail per hour or do
I simply (knowledgeably) call in template meta-programming idioms for free?

Justin

Justin Johansson Wrote:

> Andrei Alexandrescu wrote:
> > On 07/14/2010 01:15 AM, Kagamin wrote:
> >> Andrei Alexandrescu Wrote:
> >>
> >>> most GC's cannot provide efficient manual reclamation. And they shouldn't anyway.
> >>>
> >> If one doesn't want to implement a function, he can throw NotImplementedException, or don't provide the function so that program using the delete won't link.
> > 
> > And how would you use such a feature effectively? I've seen such
> > "optional implementation" policies in standards such as SQL
> > (compatibility levels) and C++ (export). They _always_ fare disastrously.
> > 
> >> But deallocation of allocated
> >> memory is not that unthinkable just because it can be hard.
> > 
> > It's not about difficulty as much as constraining GC implementers unnecessarily. Again: use a heap tuned for manual management to manage memory manually, and a heap tuned for automatic management to manage memory automatically. I think it's a very reasonable stance.
> > 
> > 
> > Andrei
> 
> "use a heap tuned for manual management to manage memory manually ..."
> 
> So do I call in a piano tuner having both an ear for perfect pitch
> and extreme programming skills at $blackmail per hour or do
> I simply (knowledgeably) call in template meta-programming idioms for free?
> 
> Justin

I don't comment here much because I don't really use D, and just follow this forum in my down time at work.  However, occasionally I feel the need to post because I would like to see D succeed.  (C++ is too error prone for much of the development it's used for.)  This is one of those times.

We use multiple all the time in gamedev with C++.  In fact, if a language didn't support the ability to use multiple heaps tuned for different allocation strategies, it wouldn't be suitable.

Andrei Alexandrescu Wrote:

> And how would you use such a feature effectively? I've seen such
> "optional implementation" policies in standards such as SQL
> (compatibility levels) and C++ (export). They _always_ fare disastrously.

Just like we do it now: write code for the garbage collected environment of your choise.

> It's not about difficulty as much as constraining GC implementers unnecessarily. Again: use a heap tuned for manual management to manage memory manually, and a heap tuned for automatic management to manage memory automatically. I think it's a very reasonable stance.

Yes, heap is used by language expressions new and delete. That's exactly what want to say: whether deallocation is supported or not is a feature of chosen runtime and programming style.

So what was the conclusion(if any) reached on how to allocate/deallocate objects on the C heap - equivalent of C++ new and delete keywords?

The summary i've reached so far:

1) "new" allocates on GC heap, and manually freeing memory allocated to GC's heap is not a good
idea be it either via delete or GC.free()

2) clear() is the safe "delete" for objects allocated on the GC heap

3) There is an emplace() function, what does that do again? There is a serious problem caused by
lack of easily accessible documentation.

4) Whats the correct procedure for using custom allocators? ie. i could write a D equivalent of std::memory

5) Which parts of D and Phobos rely on GC and cannot be used in classes that manage their own resources for example through RAII?

We really need an up to date page describing D's capabilities in the area of manual memory management.

Thanks,
Petr