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, -- Olaf
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. Robert Ramey
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.. -- Olaf
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
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
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
On 6/2/18 2:17 AM, Devika Krishnadas via Boost wrote:
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.
LOL - irrelevance is not a reason to avoid posting here. But this raises another interesting question. How about something like: template<class F, class C> auto range_adaptor(const C & c){ return F(c.begin(), c.end()); } so one could say vector<int> v = ... range_adapt(std::find, v); for any collection type. Robert Ramey
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Robert Ramey via Boost Sent: Saturday, June 2, 2018 9:36 PM
[...]
template<class F, class C> auto range_adaptor(const C & c){ return F(c.begin(), c.end()); }
so one could say
vector<int> v = ...
range_adapt(std::find, v);
for any collection type.
You know that this doesn't compile, because std::find is a function template right? (and you are also missing some parts in your function signature, but that’s just a minor detail) Most likely the standard library will finally get a std::find(range, value) but that doesn't help with the "problem" that there doesn't exist an algorithm "contains"/"includes" that searches only for a single element.
Robert Ramey
Mike
Hey, Is it not created because it's just too easy, or because of any other technical difficulties? Because if it is the former, beginners in open source like myself could grab onto some oppurtunities like this! On Sun 3 Jun, 2018, 1:24 AM mike via Boost, <boost@lists.boost.org> wrote:
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Robert Ramey via Boost Sent: Saturday, June 2, 2018 9:36 PM
[...]
template<class F, class C> auto range_adaptor(const C & c){ return F(c.begin(), c.end()); }
so one could say
vector<int> v = ...
range_adapt(std::find, v);
for any collection type.
You know that this doesn't compile, because std::find is a function template right? (and you are also missing some parts in your function signature, but that’s just a minor detail)
Most likely the standard library will finally get a
std::find(range, value)
but that doesn't help with the "problem" that there doesn't exist an algorithm "contains"/"includes" that searches only for a single element.
Robert Ramey
Mike
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I just read the thread above, I take my words back. Regards, Devika Krishnadas On Sun 3 Jun, 2018, 1:28 AM Devika Krishnadas, <devikakrishnadas97@gmail.com> wrote:
Hey, Is it not created because it's just too easy, or because of any other technical difficulties? Because if it is the former, beginners in open source like myself could grab onto some oppurtunities like this!
On Sun 3 Jun, 2018, 1:24 AM mike via Boost, <boost@lists.boost.org> wrote:
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Robert Ramey via Boost Sent: Saturday, June 2, 2018 9:36 PM
[...]
template<class F, class C> auto range_adaptor(const C & c){ return F(c.begin(), c.end()); }
so one could say
vector<int> v = ...
range_adapt(std::find, v);
for any collection type.
You know that this doesn't compile, because std::find is a function template right? (and you are also missing some parts in your function signature, but that’s just a minor detail)
Most likely the standard library will finally get a
std::find(range, value)
but that doesn't help with the "problem" that there doesn't exist an algorithm "contains"/"includes" that searches only for a single element.
Robert Ramey
Mike
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Jun 2, 2018, at 2:17 AM, Devika Krishnadas via Boost <boost@lists.boost.org> wrote:
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.
Not irrelevant at all and a very useful macro. Thanks for sharing.
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 6/2/18 2:04 AM, 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.
My point exactly !
Seriously though: Even for simple things like this, the usual advantages of using a library apply (although maybe to a lesser degree):
To me, the advantages of including something like this in the standard library out weigh the disadvantages.
- 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
I don't dispute the above. But in cases like this, these advantages don't out weigh the costs: - just looking for the component in the library is not free. - another dependency - verifying that the library component is actually the same as the one one needs. This requires study of the documentation (if there is any). - adding one more component to the standard, means that the whole standard libary is larger. So searching cost of through it, avoiding conflicts, etc. increases even for users which don't use this component. Does the invention of the "salad shooter" make the world a better place when it already has the kitchen knife? Robert Ramey
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
On Sat, Jun 2, 2018 at 9:29 PM, Robert Ramey via Boost <boost@lists.boost.org> wrote:
I don't dispute the above. But in cases like this, these advantages don't out weigh the costs:
- just looking for the component in the library is not free.
boost::algorithm::contains already exists, but it only supports two ranges, not a range and a value. I assumed it did support the latter but then my code didn't compile..
- another dependency
I was already using boost::algorithm Even if I wasn't, are we afraid of dependencies? Note you can always copy/paste the code if you really don't want the dependency.
- verifying that the library component is actually the same as the one one needs. This requires study of the documentation (if there is any). - adding one more component to the standard, means that the whole standard libary is larger. So searching cost of through it, avoiding conflicts, etc. increases even for users which don't use this component.
The request was for Boost, not for std. ;) Gr, Olaf
participants (5)
-
Devika Krishnadas -
John Dubchak -
mike.dev＠gmx.de -
Olaf van der Spek -
Robert Ramey