3 ms·
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 reu
by wadkar 7y ago
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.
- kragen 7y agoIt'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).
- jschwartzi 7y agoTo 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.
- kragen 7y agoThat'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.
- qes 7y agoIt's at least inversion of control.