5 ms·
It seems like a fouls errand for C++ to continue to try and add higher level abstractions while maintaining a zero overhead principle.
by Guthur 5y ago
It seems like a fouls errand for C++ to continue to try and add higher level abstractions while maintaining a zero overhead principle.
- bruce343434 5y agoIt is. It is a well known public secret that the STL isn't all that efficient due to issues with e.g. iterator invalidation. You can crank out a hash table that supersedes std::unordered_map in pretty much every situation in a weekend. What C++ people need to realize is that they can't keep their cake and eat it too.
- gpderetta 5y agoThe single biggest contribution of the STL are not the data structures nor the algorithms. It is the design, the shared vocabulary and protocols. This is why I can replace almost any use of unordered_map with, say the corresponding abseil implementation with very little changes to the code. Stepanov has always seen the STL as a starting point, not a finished library.
- bruce343434 5y agoAny C++ code I have ever worked with is littered with `std::`. Replacing all that with `otherlib::` would be a herculean effort at best. You might be tempted to do a simple search and replace, but let's say there's also instances of `mystd::` (probably rare). Or perhaps you don't want _all_ `std::` to be replaced. Anyway, my point is that this whole ordeal gets hairy quickly. And in practice, I only ever see `std::`. And not only does it give off horrible noise in the code, in my mind I think "this data structure is probably not optimal". "This algorithm is probably not optimal".
- steerablesafe 5y agoMost data structures in a project are not performance bottlenecks, so that's alright. While there are much better hash table implementations, std::unordered_map is still usable, although not great.
- jcelerier 5y ago> Any C++ code I have ever worked with is littered with `std::`. Replacing all that with `otherlib::` would be a herculean effort at best. You might be tempted to do a simple search and replace, but let's say there's also instances of `mystd::` (probably rare). Or perhaps you don't want _all_ `std::` to be replaced. Anyway, my point is that this whole ordeal gets hairy quickly. replacing a std::type by a semi-equivalent non-std::one has never taken more than a few minutes with my IDE's find-and-replace, on up to MLOC-codebases.
- 72deluxe 5y agoWhat about putting using std::vector or whatever in the header or implementation? Saves littering the codebase with std:: everywhere without having to do a blanket using namespace std;
- physicsguy 5y agoIf I as a C++ dev come to a new project, I'd much rather that someone was using std::vector or std::array or std::unordered_map or whatever other container because I know how it works, and I know that any other new developer will know how it works. Personally, I would expect very heavy justification (incl. profiling results showing orders of magnitude differences in total task performance) and a very strongly tested + well documented implementation for anyone sending me a PR with their own implementation of a container.
- bogwog 5y ago> This is why I can replace almost any use of unordered_map with, say the corresponding abseil implementation with very little changes to the code. How is that useful? For "easy" optimization? Because that's not how you optimize code.
- gpderetta 5y agoI haven't made any claim about performance.
- pjmlp 5y agoInterator invalidation can be easily caught with debug builds. Not every C++ application needs to win microbenchmarks when using hash tables.
- bruce343434 5y ago> Not every C++ application needs to win microbenchmarks when using hash tables. strawman and you know it.
- pjmlp 5y agoNot at all, rather the C micro benchmarks culture that sadly infects some C++ subcultures. I never had any performance issue using the STL to deliver projects under the customer acceptance criteria.
- deleted 5y ago[deleted]