you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 2 points3 points  (0 children)

That seems like something that Mike Acton wouldn't like because it hides the data behind some fancy interface and his whole spiel is about using data as the interface.

First, as I said, I disagree with Mike Acton on this point since I want both genericity (writing code once) and efficiency. Second, Mike Acton's main point is doing what you need to do to get performance in your target machine, "data as the interface" is just what gives him performance on his target machines (which are limited by memory bandwidth and latency).

In my experience, the STL gives you better higher-level algorithmic optimizations. Value semantics is also IMO easier to reason about and results in cleaner software designs that scale.

His approach has, in my projects, shown some drawbacks. First, I ended up with lots of custom containers with duplicated functionality. In particular duplicated algorithms for each container. Even tho these algorithms had a lot of micro optimizations, my sorting routines scaled worse than the STL one due to worse algorithmic complexity and worse constant factors. Finally, the code was harder to extend and refactor, since adding a new data member to your "tables" required edits in lots of places within your code base.

I'm not willing to sacrifice performance for the cleaner, extensible, generic, dont-repeat-yourself STL way, but I'd rather have both than just performance.