Smart pointers instead of GC?

[Frustrated]

On Tuesday, 4 February 2014 at 12:18:22 UTC, ed wrote:
> On Tuesday, 4 February 2014 at 12:03:31 UTC, Frustrated wrote:
> [snip]
>> It would be nice if one could simply write some allocator, drop
>> it into D, and everything work out dandy. e.g., I want to try 
>> out
>> a new super fast AGC like metronome GC, I write the code for 
>> it,
>> tell D to use it, and then reap the benefits.
>
> You can write your own GC now and drop it in, we did as an 
> experiment.
>
> If you're talking about a dropping in an allocator that is 
> another matter, an allocator is not a GC.
>
>
> Cheers,
> ed

Yes, you can do a lot with D, even rewrite D runtime to remove GC
dependent stuff, or write your own Phobos library. It is not easy
and D is not *designed* to do that.

AGC is about automatic deallocation so you don't have to *free*
the memory you allocate. To do this you have to allocate through
the GC so it knows when you allocate. So a GC is an allocator.

Regardless, I would simply like to have, as I'm sure many would,
the ability to set how D handles memory.

1. No memory management at all - Fast as possible. No memory is
ever free'ed. Similar to how DMD works.

2. Manual memory management - Pretty fast but old school.
Predictable but error prone. Different allocating schemes for
dealing with efficiency. Some apps require this to be performant.

3. Automatic memory management - Easy to use = Lazy mentality.
Safer. Most apps would not need anything more than this.

4. Combination of the above - The hard part. How to make all this
stuff plug and play, work well together, easy to use, etc...




Right now, D basically only has #3. Some have worked D to use 2.
std.allocators goes a long way in the right direction as does
std.allocators.gc. All I'm wanting is a unified way to use it all
and to get D and phobos off the hard dependence of the GC.