CppCon 2016: Chandler Carruth “High Performance Code 201: Hybrid Data Structures"

I suggest watching this talk: ▶ this video Or pretty much any other by Chandler to understand why the STL sucks and why you should write better datastructures for your own use cases.

in CppCon 2016: Chandler Carruth “High Performance Code 201: Hybrid Data Structures"[1] he says: "but the standard deque data type is really quite bad. I wouldn't recommend anyone use it for anything. if you look at the implementation constraints, the constraints placed upon its iterators, and its invalidation constraints, it's painted into a very unpleasant corner and it has very few opportunities to be an efficient data structure." [1] ▶ this video

The parent was asking the goldilocks question -- was there ever a point where C++ was not too complex like modern C++, e.g. this {} issue, but had enough features (contrast with C, which doesn't have enough features for many applications). I don't think there was such a moment. Apparently move constructors were a de-optimization in the case of std::vector. As far as I remember, it's related to iterator invalidation and move semantics making small-size optimization impossible (e.g. inlining small vectors into the object itself rather than having another pointer and heap allocation). I'm pretty sure it's in this video: ▶ this video Although it's debatable how big a deal this is, it's a good example of the point. People like "C with classes" because they can read the source and kind of figure out what code is generated. They can reason about locality. Although I don't consider myself an expert C++ programmer, if I can't reason about the consequences of move constructors on std::vector, which is a fundamental and relatively simple data structure, then the language is already getting into "surprising" territory. I would have never figured out that de-optimization unless I heard it in a video. On a related note, I wish that return value optimization had better syntax -- that would make move semantics unnecessary in a lot of cases. On the other hand, reasoning about the generated code is already a lost cause because assembly code is so complicated now. We now have to live in a world wher