4 ms·

Absolutely should you wrap malloc in any moderately sized project! But clearly that's not OOP. We need to differentiate between abstract data types (method disp

Absolutely should you wrap malloc in any moderately sized project! But clearly that's not OOP. We need to differentiate between abstract data types (method dispatch, which I would normally count as OOP) and just making functions to "reuse" code. In the latter case, there is only one possible implementation, and the implementation can expose as much or as little implementation details as is appropriate -- and in general, there won't be any abstraction leaks.

Const-me 8y ago
> and in general, there won't be any abstraction leaks. For malloc, address space fragmentation is a common issue for 32-bit processes. Multithreading issues are common, when 2 threads access same cache line, it’s even slower than accessing main RAM. Randomized nature of the allocator causes performance problems. Every time people bother writing custom allocators, they do that because malloc/free abstraction was not good enough for them, i.e. has leaked. All abstractions leak, OOP or not.
- jstimpfle 8y ago
  If I make a function called allocate_new_foo() that is not an abstraction (in the sense I mentioned - i.e. method dispatching). It's plain old boring programming - specifying in only one place how foo's should be allocated. And each caller is expected to have a good understanding what kind of allocation to expect - i.e. pool allocation or whatever. I wouldn't consider this an abstraction at all, and it doesn't leak nearly as much as a "streams" abstraction - if at all.