Three Years of Abstractionless C(replicated.wiki)
replicated.wiki
Three Years of Abstractionless C
https://replicated.wiki/blog/abc
3 comments
https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar...
My point, more or less. Of course, a heap is different from append-only array, on higher level. On lower level, these are bit strings. Which is handy, if you can send it over the network with exactly the same function, for example.
My point, more or less. Of course, a heap is different from append-only array, on higher level. On lower level, these are bit strings. Which is handy, if you can send it over the network with exactly the same function, for example.
But my bitstring representation of a heap may not be your bitstring representation of the same heap. Neither C nor C++ makes enough guarantees about the representation of the heap that you can assume that, so a higher-level ‘heap’ type that abstracts over the respective representations of my heap and your heap is inevitable, and not something to be scared of. Of course you can reasonably ask for a language in which the representation of a heap is uniform across hardware, but it will come with some performance penalties.
Everything on the computer can be _represented as_ a bit string. But it's important not to confuse that fact with everything on the computer _being_ a bit string. The bit string is only a ‘name’ to represent the thing in conversation between people who share an understanding of what that representation should represent.
Everything on the computer can be _represented as_ a bit string. But it's important not to confuse that fact with everything on the computer _being_ a bit string. The bit string is only a ‘name’ to represent the thing in conversation between people who share an understanding of what that representation should represent.
Then you might want to avoid computers in general: C also sits on a tower of ‘imaginary’ abstractions (binary, gates, functions, allocation, virtual memory…). The computer itself is an abstraction, and sits on top of a teetering tower of other abstractions like electronics, physics, and (if you want to get philosophical about it) discrete objects.
> same bytes packaged differently become entirely different incompatible entities (like std::string vs std::vector<char> vs std::valarray<> etc)
The same bytes simply _are_ (in)compatible with different things depending on semantic context, and C++ is just surfacing that to you. A given slice of linear memory (which is an abstraction, of course) could be representing a heap or a string with the same bytes, and you'd better know which when using them — that information is not stored in the bytes themselves. Your choice is either to represent this in a way that the compiler can check for you, or encode that information in freeform human documentation about how to avoid the error cases that the compiler can no longer help you with.