Hacker News Reader

Isn't this dependency injection though? As in, the caller must manage the buf() dependency on it's own - promoting performance and other qualities like code reuse. For example, the caller might have a library that manages creating these buffers for large bytes or maybe over network or what not. Then such dependency injection will promote code reuse of the library as well.

View on HN

It's analogous to dependency injection, and you could do it via dependency injection by passing in an allocator object (or class, in the STL), but normally I think of dependency injection as injecting polymorphic callable objects, not monomorphic memory buffers. So I think of passing in memory buffers as a lighter-weight alternative to dependency injection for cases like this, and one that can provide some additional guarantees (see my top-level comment for details).

To be honest, it's more like separating the concern of resource allocation from the concern of resource utilization. And when your resources are things like memory or devices then that promotes separating the code you can unit test from the code that you have to integration test.

That's a good point. I hadn't thought of that --- if you want to test how your code handles allocation failures, allocating in more places means you have a lot more to test.

It's at least inversion of control.

Reply on news.ycombinator.com