The STL Is Not An Abstraction
hacksoflife.blogspot.com/2010/02/stl-is-not-a...Posted Jul 8, 2010, 1:56 PM UTC
319
hacksoflife.blogspot.com
This guy doesn't quite understand what an abstraction is. Upvoted for trying, though.
data abstractions don't have to hide all complexity details or implementation specific characteristics as such from the user, what they do is restrict access to raw implementation to a few select operations, so that an interface exists for accessing the data that "abstracts" the raw implementation such that it cannot be directly manipulated, which the STL does do, hence it is an abstraction.
8
Does it actually matter?
The STL provides building blocks to get stuff done. I don't feel that the exact label you put on that is critical.
2
If STL is anything, it's optimization.
0
You don't have to pick a container type, you can operate on iterators. Iterators are the abstraction of the STL.
7
from wikipedia
Some containers, among them list, provide specialised version of sort as a member function. This is because linked lists don't have random access (and therefore can't use the regular sort function); and the specialised version also preserves the values list iterators point to.
I think this makes them leaky.
4
That is correct. There is a conflict between performance and generality in this case and the STL usually chooses performance. You could implement a general sort function that doesn't need random access iterators, though it wouldn't be as fast.
4
I think there could be a more general sort function that only needs bidirectional iterators like those in linked list. In which case the random access iterator sort function would just be a specialized version.
I kind of think it would already exist if it was that easy. So my guess is that a general bidirectional iterator version couldn't reasonably preserve the "values list iterators point to" without access to internal guts. Given that rationale, it seems like the new move semantics might make a general bidirectional iterator version more reasonable (less of a performance cost.) I admit I haven't looked into the details though.
2
No it does not. Sort is defined for an iterator category that list doesn't support.
3
You have to choose data structures depending upon what algorithms you want to apply. And you can only choose your algorithms when you know what data structures you have. There are trade offs if for example you want efficient lookup on a set.
The abstraction of STL is iterators and algorithms which operate on them. A slightly better abstraction though is algorithms which operate on a range. See Iterators Must Go[PDF]
2
Almost all complex abstractions are leaky.
1
Yes it is. It's not a very high-level abstraction but it's an abstraction nonetheless. The standard defines an interface and certain properties for that interface including, for specific containers, time-complexity for its operations. This does not mean the implementation is set in stone. For example, std::map can be implemented as a number of different data structures, such as a red-black tree and a skip list, while satisfying its defined interface.
Further, the standard describes higher level abstractions than any particular container, such as the various iterator categories (random access iterator, forward iterator, etc) and container categories (general container, sequence, associative). The general container interface supports a number of operations like iteration, retrieval of size, etc.
Here's a simple function which uses that abstraction:
template <typename Container>
int sum(Container const& c) {
int result = 0;
for(typename Container::const_iterator i = c.begin(), e = c.end(); i != e; ++i) {
result += *i;
}
return result;
}
7
A comment:
Dude, when you have to code in Java for your day job, you will realize just how lucky you were to be burned by STL all those years.
4
hahaha the java collections library is so much better than STL it's not even funny. most people can figure out java collections in a day if they are familiar with containers in some other language. most people will never take the time to figure out STL and its seemingly endless list of gotchas, so they will either not use it or use it wrong.
2
But let's recognize what the STL is: a way to make certain known containers and algorithms much faster to put into your code - not a way to write code without knowing what your algorithms and containers do!
Also let recognize that whoever told you you can do that with language X or library Y was a liar.
The STL is actually a good way to learn about the differences between these containers, not only about operation complexities (which are specified IIRC), but iterators immutability over insertion/deletions, etc... All these fine prints which often let you write efficient code with the STL instead of reinventing another container.
2
[deleted]
0
ObQwe1234:
no fucking shit, sherlock.
if you don't know the exact performance characteristics and space and time constraints of what you're coding, then you shouldn't be allowed to touch a computer.
c++ and the stl are for grown-ups who want to get real work done, not babymen who think only in bullshit "abstractions".
0
[deleted]
1
Google uses no STL (nor the rest of the Standard library). Wonder why?
-4
Erm, Google's C++ Style Guide says nothing explicit about the standard library. It mentions not using streams, but also presumes use of the standard library in some places, such as the section about smart pointers.
3
Well, I can switch from STLPort to DinkumWare to libstdc++ without knowing the internal implementations. I'd say that is an abstraction -- even by the author's definition.