Re: [boost] [Algorithm] contains(v, 1)

I do not know how relevant this is, but as a competitive programmer, it is our usual practice to use #defines to make our lives easier. For such a case, we use #define all(v) v.begin(),v.end() And now any function call can just be as the following example - sort(all(v)) Or contains(all(v),Val) I'm sorry if this is irrelevant. Regards, Devika Krishnadas On Sat 2 Jun, 2018, 2:34 PM mike via Boost, wrote:

Hi

If the argument "can't you write it yourself" is a valid reason not to put something in a library then that explains, why c++ is so complicated to use and teach.

Seriously though: Even for simple things like this, the usual advantages of using a library apply (although maybe to a lesser degree): - They are (usually) being tested by more people and in case of boost are also most likely of better quality than my own (corner cases, performance ... ) - They reduce the amount of code in my own project (fewer things to test, fewer things to refactor, fewer things to code review ...) - They are easier to reuse in different projects

Best Mike

...

-----Original Message----- From: Boost On Behalf Of Robert Ramey via Boost Sent: Thursday, May 31, 2018 4:48 PM To: boost@lists.boost.org Cc: Robert Ramey Subject: Re: [boost] [Algorithm] contains(v, 1)

On 5/31/18 5:58 AM, Olaf van der Spek via Boost wrote:

...

On Thu, May 31, 2018 at 2:50 PM, Robert Ramey via Boost wrote:

...

On 5/31/18 3:14 AM, Olaf van der Spek via Boost wrote:

...

Hi,

vector<int> v; contains(v, 1);

This doesn't work as contains expects two ranges (AFAIK). Is there some other function that's usable for this purpose? Should contains support a value for argument 2?

Gr,

Hmmm- can't you just make your own? Something like ...

#include <algorithm>

template<typename V> bool contains(const V & v, const typename V::value_type & t){ return v.end != find(v.begin(), v.end(), t); }

I'm pretty sure it would work on strings as well.

Of course I could, but I'd rather not..

Why not? This is a sincere question. If libraries contain lots of stuff like this, it makes the libraries harder to understand. I prefer a set of simple, transparent tools which are easily composed. I see we disagree on this, I'm curious what your argument is.

Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost