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, <boost@lists.boost.org> 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 <boost-bounces@lists.boost.org> On Behalf Of Robert Ramey via Boost Sent: Thursday, May 31, 2018 4:48 PM To: boost@lists.boost.org Cc: Robert Ramey <ramey@rrsd.com> 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 <boost@lists.boost.org> 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