|
|
|
|
|
|
by petke
3867 days ago
|
|
|
I dont think I agree. Abstraction in my view is (mostly) about removing implementation details that dont change from one implementation to another. Its about removing boilerplate until just the fundamental features of the implementations remain. It would be a bad abstraction if details (low level or otherwise) that do change, are removed. Im not sure I get your example. Are you implying that this C++ code is inefficient because the allocation for result is not done in advance? If you know the size of result in advance, there is no reason to use a stream for result. You can simply use std::string and reserve. |
|
|
Oh yes there is a reason. The reason is that streams are a convenient abstraction because there is very likely an operator<< for whatever transform(c) returns. And why is there an operator<<? Because streams abstract from the type of sink (string, file, network).
You are absolutely right, that this can be implemented a lot more efficiently. That's exactly my point. Abstractions lure us into using inefficient solutions without thinking.
You say "If you know the size of result in advance [...]". Well, exactly. Do you? That's something C programmers think about long and hard but you don't have to think about it if you use streams or even string abstractions naively.
This isn't just a case of "you can write bad code in any language". It's what abstractions do. Allow us to ignore stuff that is unnecessary if the goal is simply to arrive at a correct but less efficient solution.