Just Internally Allocate?

General
1

The basic manual memory principle of passing buffers to procedures to keep memory management as exterior in the call-stack as possible obviously makes a lot of sense on the face.

But considering the ease at which I can pass any allocator to any procedure, should I just embrace internal allocation? It would make a lot of design much simpler as I can just allow deeply nested procedure calls allocate whatever they need and clean it all up on the outside as soon as those returned allocations aren’t needed.

I’ve been trying to plan upfront what buffers will be needed for procedures and allocating and giving it to them rather than letting the procedures allocate - I guess there is still value in doing this just to make it explicit when memory is being allocated rather than hidden internal allocations, but who hecking cares when I can easily test for leaks anyways?

Is anyone going to stop me? (Jokes aside, I’m open to arguments against this style).

2

Do whatever works for you, for me these “rules” tend to be convenient:

  1. Pass an allocator when the caller cannot know the required buffer size ahead of time, whether you do this with explicit arg or default arg it’s up to you, the former isn’t much different then passing a buffer explicitly.
  2. Pass a buffer when the caller dictates how much data you give back.
  3. Return a type with an Arena inside when every field must be dropped at once (e.g. graph, string heavy struct).
  4. Forget scratch buffers, take a temp allocator.
  5. Sometimes you just want a custom iterator and not allocate at all.
1 Like