why allocators are not discussed here

Adam D. Ruppe destructionator at gmail.com
Wed Jun 26 11:40:13 PDT 2013


On Wednesday, 26 June 2013 at 17:25:24 UTC, H. S. Teoh wrote:
> malloc to allocate a pool, then use a custom gc_alloc/gc_free to
> allocate from this pool in order to support language built-ins 
> like ~ and ~= without needing to rewrite every function that 
> uses strings.

Blargh, I forgot about operator ~ on built ins. For custom types 
it is easy enough to manage, just overload it. You can even do ~= 
on types that aren't allowed to allocate, if they have a certain 
capacity set up ahead of time (like a stack buffer)

But for built ins, blargh, I don't even think we can hint on them 
to the gc. Maybe we should just go ahead and make the gc 
generational. (If you aren't using gc, I say leave binary ~ 
unimplemented in all cases. Use ~= on a temporary instead 
whenever you would do that. It is easier to follow the lifetime 
if you explicitly declare your temporary.)


More information about the Digitalmars-d mailing list