4 ms·

STL has a lot of weird pitfalls. There was std::vector<bool>. Here you can see some pitfalls of std::unordered_map: <https://youtu.be/ncHmEUmJZf4?t=2220 https:/

STL has a lot of weird pitfalls. There was std::vector<bool>. Here you can see some pitfalls of std::unordered_map: <https://youtu.be/ncHmEUmJZf4?t=2220 https://youtu.be/ncHmEUmJZf4?t=2220>. The whole talk is interesting to watch. In the beginning you can also see the puzzling design of std::unordered_map (puzzling because of the number of indirections). I'd reach for abseil first: <https://abseil.io/ https://abseil.io/>.

fnord77 5y ago
after watching that video, I never want to touch C++ again
- db48x 5y ago
  Several CPPCON talks in recent years have reinforced that for me as well. https://www.youtube.com/watch?v=7DTlWPgX6zs https://www.youtube.com/watch?v=7DTlWPgX6zs, for example. Edit: I originally linked to the wrong video (https://www.youtube.com/watch?v=TFMKjL38xAI https://www.youtube.com/watch?v=TFMKjL38xAI), which was a different talk by the same person.
- pjmlp 5y ago
  Then someone has to do it for you, because for the foresable future there will be plenty of critical libraries, and compiler infrastructure, that won't be available in anything else as implementation language. Hence why I keep my C and C++ skills sharp, even though they aren't my main languages any longer.
  - fnord77 5y ago
    or it is time to replace these critical libraries with something that has the same features and is far less convoluted and far harder to make serious mistakes with. In addition to having experts accidentally make mistakes with `ref ref` like in that first video that resulted in performance degradation due to unwanted copies, C/C++ is a major security risk. Countless vulns are from simple mistakes and complex misunderstanding.
    - tekknik 5y ago
      This is a pipe dream. There are systems still running COBOL. It’s a real hard sell to convince those with the money to let someone rewrite something that’s working and has been for some time.
    - pjmlp 5y ago
      That is a noble goal, first LLVM and GCC need to be rewritten in one of those languages, then CUDA, Metal Shaders, DirectX, Tensorflow, Qt, WinUI, .... So even though managed languages and better systems programming languages are making their replacements, somewhere down the stack there will be C++. And then to top it, as long as people insist in using UNIX clones, C will be there as well.
deleted 5y ago
[deleted]
josefx 5y ago
> https://youtu.be/ncHmEUmJZf4?t=2220 https://youtu.be/ncHmEUmJZf4?t=2220 Some good points, but also "calling find with C strings is slow", you are using C strings, don't expect speed from code worshiping strlen of all things. Also the issue with integer hash being its identity? That is the case for every language I checked (Python, Java, C#).
- jcelerier 5y ago
  I mean, if Python, Java or C# were good enough for me as a C++ user, I'd use them. The mindset behind C++ is not a relative "thing must be good enough", but an absolute "there must not be something better possible". Of course, this is often not realized in practice, but it's the goal.
  - josefx 5y ago
    > "there must not be something better possible" It maps all integer values to distinct hashes which seems rather ideal, what it doesn't give you is perfect performance in an artificial benchmark written to exploit this implementation.
    - jcelerier 5y ago
      Tangent, but I remember reading not too long ago that there were some cases where perfect hashes weren't optimal, but can't remember where..
qalmakka 5y ago
> STL has a lot of weird pitfalls everything that's old and has legacy is doomed to have several. It's just a fact of life. The C++ committee doesn't and can't just throw away stuff like `std::vector<bool>`, despite it being a whole fractal of bad ideas, because people have already used that piece of dung in uncountable projects. It would be nice to have a way to get a _normal_ vector of booleans (even though vector<char> just suffices most of the time), but that's life I guess.
- yakubin 5y ago
  People bring this point up every time C++ is criticized, but no, not all C++ shortcomings come from its age. In fact, most of the shortcomings it is criticized for today are new. The committee just keeps on adding new ones: initialization (mentioned by another reply to my comment), std::optional & std::variant (UB), concepts[1], std::thread (good luck debugging where the std::thread which crashes your program in a destructor came from), std::random_device()() being allowed to return 0 every time (which e.g. won't show up when you compile for your own machine, but will when you cross-compile) and probably many others which I don't remember off the top of my head. [1]: <https://news.ycombinator.com/item?id=28098153 https://news.ycombinator.com/item?id=28098153> But back to the point, my original comment wasn't about C++ being a bad choice. It was about STL. You can use C++ without STL. I pointed to one alternative: abseil.
  - qalmakka 5y ago
    It does indirectly come from age, because legacy and backward compatibility mean that you can't simply change some core parts of the language at all. For instance, std::optional uses UB because _all_ of C++ does the same, and making std::optional<T>::operator* different from std::unique_ptr<T>::operator* would have caused similar concepts to have a different behaviour - something that would have definitely translated into weird bugs. Also, C++ hasn't features like built-in move semantics and borrow checking, so it's very hard to enforce certain things that just come natural in Rust. That's simply stating a fact. The real point here is that std::optional<T> is much less likely to cause UB than a plain, old C pointer, so it's a net improvement - even though it could still lead to UB in some circumstances.
cjfd 5y ago
These pitfalls really aren't that bad. An extra copy here and there only matters in the tight loops. Some of the examples in the talk are really contrived. Am I going to insert the empty string many times as a string in a hash map? No, in most cases I am going to make sure that almost all of the keys that I generate are different. Sure, google can save on its electricity bill by doing micro-optimizations. For me trying that would be a bad trade. Every language has its pitfalls and I tend to prefer C++ pitfalls to some other pitfalls. Lately I having been doing some python. Turns out a python -m venv is different from a virtualenv. Turns out pytest some/specific/test/file.py is different from python -m pytest some/specific/test/file.py. I am wishing quite hard this code base consisted of all C++. And of course mypying this is still on the TODO list so the type annotations that are there might well lie.

fnord77 5y ago

after watching that video, I never want to touch C++ again

db48x 5y ago
Several CPPCON talks in recent years have reinforced that for me as well. https://www.youtube.com/watch?v=7DTlWPgX6zs https://www.youtube.com/watch?v=7DTlWPgX6zs, for example. Edit: I originally linked to the wrong video (https://www.youtube.com/watch?v=TFMKjL38xAI https://www.youtube.com/watch?v=TFMKjL38xAI), which was a different talk by the same person.
pjmlp 5y ago
Then someone has to do it for you, because for the foresable future there will be plenty of critical libraries, and compiler infrastructure, that won't be available in anything else as implementation language. Hence why I keep my C and C++ skills sharp, even though they aren't my main languages any longer.
- fnord77 5y ago
  or it is time to replace these critical libraries with something that has the same features and is far less convoluted and far harder to make serious mistakes with. In addition to having experts accidentally make mistakes with `ref ref` like in that first video that resulted in performance degradation due to unwanted copies, C/C++ is a major security risk. Countless vulns are from simple mistakes and complex misunderstanding.
  - tekknik 5y ago
    This is a pipe dream. There are systems still running COBOL. It’s a real hard sell to convince those with the money to let someone rewrite something that’s working and has been for some time.
  - pjmlp 5y ago
    That is a noble goal, first LLVM and GCC need to be rewritten in one of those languages, then CUDA, Metal Shaders, DirectX, Tensorflow, Qt, WinUI, .... So even though managed languages and better systems programming languages are making their replacements, somewhere down the stack there will be C++. And then to top it, as long as people insist in using UNIX clones, C will be there as well.

deleted 5y ago

[deleted]

josefx 5y ago

> https://youtu.be/ncHmEUmJZf4?t=2220 https://youtu.be/ncHmEUmJZf4?t=2220 Some good points, but also "calling find with C strings is slow", you are using C strings, don't expect speed from code worshiping strlen of all things. Also the issue with integer hash being its identity? That is the case for every language I checked (Python, Java, C#).

jcelerier 5y ago
I mean, if Python, Java or C# were good enough for me as a C++ user, I'd use them. The mindset behind C++ is not a relative "thing must be good enough", but an absolute "there must not be something better possible". Of course, this is often not realized in practice, but it's the goal.
- josefx 5y ago
  > "there must not be something better possible" It maps all integer values to distinct hashes which seems rather ideal, what it doesn't give you is perfect performance in an artificial benchmark written to exploit this implementation.
  - jcelerier 5y ago
    Tangent, but I remember reading not too long ago that there were some cases where perfect hashes weren't optimal, but can't remember where..

qalmakka 5y ago

> STL has a lot of weird pitfalls everything that's old and has legacy is doomed to have several. It's just a fact of life. The C++ committee doesn't and can't just throw away stuff like `std::vector<bool>`, despite it being a whole fractal of bad ideas, because people have already used that piece of dung in uncountable projects. It would be nice to have a way to get a _normal_ vector of booleans (even though vector<char> just suffices most of the time), but that's life I guess.

yakubin 5y ago
People bring this point up every time C++ is criticized, but no, not all C++ shortcomings come from its age. In fact, most of the shortcomings it is criticized for today are new. The committee just keeps on adding new ones: initialization (mentioned by another reply to my comment), std::optional & std::variant (UB), concepts[1], std::thread (good luck debugging where the std::thread which crashes your program in a destructor came from), std::random_device()() being allowed to return 0 every time (which e.g. won't show up when you compile for your own machine, but will when you cross-compile) and probably many others which I don't remember off the top of my head. [1]: <https://news.ycombinator.com/item?id=28098153 https://news.ycombinator.com/item?id=28098153> But back to the point, my original comment wasn't about C++ being a bad choice. It was about STL. You can use C++ without STL. I pointed to one alternative: abseil.
- qalmakka 5y ago
  It does indirectly come from age, because legacy and backward compatibility mean that you can't simply change some core parts of the language at all. For instance, std::optional uses UB because _all_ of C++ does the same, and making std::optional<T>::operator* different from std::unique_ptr<T>::operator* would have caused similar concepts to have a different behaviour - something that would have definitely translated into weird bugs. Also, C++ hasn't features like built-in move semantics and borrow checking, so it's very hard to enforce certain things that just come natural in Rust. That's simply stating a fact. The real point here is that std::optional<T> is much less likely to cause UB than a plain, old C pointer, so it's a net improvement - even though it could still lead to UB in some circumstances.

cjfd 5y ago

These pitfalls really aren't that bad. An extra copy here and there only matters in the tight loops. Some of the examples in the talk are really contrived. Am I going to insert the empty string many times as a string in a hash map? No, in most cases I am going to make sure that almost all of the keys that I generate are different. Sure, google can save on its electricity bill by doing micro-optimizations. For me trying that would be a bad trade. Every language has its pitfalls and I tend to prefer C++ pitfalls to some other pitfalls. Lately I having been doing some python. Turns out a python -m venv is different from a virtualenv. Turns out pytest some/specific/test/file.py is different from python -m pytest some/specific/test/file.py. I am wishing quite hard this code base consisted of all C++. And of course mypying this is still on the TODO list so the type annotations that are there might well lie.