• Kagamin <spam here.lot> Jul 13 2010
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Jul 14 2010
• Justin Johansson <no spam.com> Jul 14 2010
• bigsandwich <bigsandwich_nospamplease gmail.com> Jul 14 2010
• Kagamin <spam here.lot> Jul 15 2010
• Petr Janda <janda.petr gmail.com> Jul 26 2010

Kagamin <spam here.lot> writes:

Andrei Alexandrescu Wrote:

 most GC's cannot provide efficient manual 
 reclamation. And they shouldn't anyway.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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.


 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

Justin Johansson <no spam.com> writes:

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.


 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

bigsandwich <bigsandwich_nospamplease gmail.com> writes:

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.


 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.

Kagamin <spam here.lot> writes:

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.

Petr Janda <janda.petr gmail.com> writes:

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