4 ms·

I'd love a real world example as I've been using the STL for 14 years, and only thing I've worked around was std::map, which I implemented much like boost flat_

I'd love a real world example as I've been using the STL for 14 years, and only thing I've worked around was std::map, which I implemented much like boost flat_map. Yes, you need to be aware of object lifetimes in c++, but so do you in C. C++ makes it far easier to manage, though.

rwbt 8y ago
I agree. These days I can't even imagine programming in C++ without using STL. It still has some weird ergonomics at some places though. For example - instead of a simple vector.contains(something) we have to write this std::vector<T> x_Vec; if (!(x_Vec.find(another_x) == std::vector<T>::npos) { //some code } Also the ugly std::get<N> syntax.. auto x = std::get<0>(myTuple); Why not - auto x = myTuple.0
- jcelerier 8y ago
  If you didn't write your own generic "contains" method on the third time you had this pattern I don't know what to say
- int_19h 8y ago
  The first snippet you wrote makes sense for string, but not for vector. For vector, you'd need to do: if (x_Vec.find(another_x) != x_Vec.end()) { //some code } The reason why vector doesn't have contains() is because it would be an O(N) operation for a vector. STL is generally designed in such a way that, when something needs to do an O(N) lookup, it has to deal with iterators, making the iteration happening in the background a bit more explicit. But, for example, for std::set and map, you can just do: if (a_set.count(x)) { ... } It's not a good pattern for multiset and multimap, since it won't stop at the first occurrence. C++20 finally added contains() for that reason - but, again, only to associative containers.
  - LgWoodenBadger 8y ago
    but isn't find() an O(n) operation already?
    - int_19h 8y ago
      Indeed! Which is why find() is not a member function on vector (so my snippet above is wrong - I just missed that part). It's a global function, so you need to do: if (find(x, v.begin(), v.end()) != v.end()) ... For maps and sets, find is a member function though. Same principle - if it is implemented in some optimized way, the class provides it directly, but not otherwise.
  - rwbt 8y ago
    Yes, I'd need to check for end iterator in vector. But my point still stands - C++ does have some weird ergonomics.

rwbt 8y ago

I agree. These days I can't even imagine programming in C++ without using STL. It still has some weird ergonomics at some places though. For example - instead of a simple vector.contains(something) we have to write this std::vector<T> x_Vec; if (!(x_Vec.find(another_x) == std::vector<T>::npos) { //some code } Also the ugly std::get<N> syntax.. auto x = std::get<0>(myTuple); Why not - auto x = myTuple.0

jcelerier 8y ago
If you didn't write your own generic "contains" method on the third time you had this pattern I don't know what to say
int_19h 8y ago
The first snippet you wrote makes sense for string, but not for vector. For vector, you'd need to do: if (x_Vec.find(another_x) != x_Vec.end()) { //some code } The reason why vector doesn't have contains() is because it would be an O(N) operation for a vector. STL is generally designed in such a way that, when something needs to do an O(N) lookup, it has to deal with iterators, making the iteration happening in the background a bit more explicit. But, for example, for std::set and map, you can just do: if (a_set.count(x)) { ... } It's not a good pattern for multiset and multimap, since it won't stop at the first occurrence. C++20 finally added contains() for that reason - but, again, only to associative containers.
- LgWoodenBadger 8y ago
  but isn't find() an O(n) operation already?
  - int_19h 8y ago
    Indeed! Which is why find() is not a member function on vector (so my snippet above is wrong - I just missed that part). It's a global function, so you need to do: if (find(x, v.begin(), v.end()) != v.end()) ... For maps and sets, find is a member function though. Same principle - if it is implemented in some optimized way, the class provides it directly, but not otherwise.
- rwbt 8y ago
  Yes, I'd need to check for end iterator in vector. But my point still stands - C++ does have some weird ergonomics.