Why should I have written ZeroMQ in C, not C++ (2012)

Re:Why should I have written ZeroMQ in C, not C++ (2012) by int_19h on Thursday December 13, 2018 @06:27AM (#18671502)

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.

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (2012) by rwbt on Thursday December 13, 2018 @11:33AM (#18673592)

Yes, I'd need to check for end iterator in vector. But my point still stands - C++ does have some weird ergonomics.

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (2012) by LgWoodenBadger on Thursday December 13, 2018 @09:35AM (#18672538)

but isn't find() an O(n) operation already?

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (2012) by int_19h on Thursday December 13, 2018 @09:09PM (#18677852)

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.

[ Parent | on HN ]