> 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.
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.
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.