On 25 December 2014 at 21:02, Leo Heinsaar <leoheinsaar@gmail.com> wrote:
> Hi Olaf - same argument from me as just wrote to Andy.

See
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4273.htm
and
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4280.pdf

Having generic operations in the library is good, but it's rather likely
that having them as non-member algorithms is somewhat
preferred to adding a member to every container. Do remember that
legacy arrays do not have member functions (although personally
I don't really care). I'm not saying it wouldn't be good to add members
that do the same thing for every container and would standardize
existing-practice-boilerplate (if (foo.find(whatever)!=foo.end()) gets old
after you've written it twice). I'm just saying that it may be a hard sell. ;)

>
> Thanks,
> Leo
>
>
> On Thursday, December 25, 2014 8:44:12 PM UTC+4, Olaf van der Spek wrote:
>>
>> On Thursday, December 25, 2014 7:40:40 AM UTC+1, Leo Heinsaar wrote:
>>>
>>> Hi guys,
>>>
>>> Range-for and auto greatly simplify code dealing with iterators - thanks
>>> to all who contributed to that - but don't you think it's an omission we
>>> still don't have the very simple bool contains(const T&) family in STL
>>> containers?
>>>
>>> There's hardly a single production codebase in the world that doesn't
>>> have the contains() boilerplate (I mean, of course, comparing the result of
>>> find() to an end() to see if the value is there), often in multiple places.
>>> And I guess range-for and auto were also at least partly born out of
>>> realization that our code often deserves a higher abstraction level than
>>> iterators.
>>>
>>> Correct me if I'm wrong, but I see contains() as a not-so-big of an
>>> addition to the standard library that would be of quite significant value.
>>
>>
>> Hi Leo,
>>
>> If it's about maps etc you could use count() or a find wrapper that
>> returns a pointer (to second) for simpler syntax.
>> contains() might still be useful.
>>
>> Olaf
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_4957_451509862.1419534805642
Content-Type: multipart/alternative;
 boundary="----=_Part_4958_1466525783.1419534805642"

------=_Part_4958_1466525783.1419534805642
Content-Type: text/plain; charset=UTF-8

That's why I'm writing about it now Ville - hoping that by now everybody
will have written the boilerplate you mentioned so often that it would make
it easier to sell :-)

On Thursday, December 25, 2014 11:08:19 PM UTC+4, Ville Voutilainen wrote:
>
> On 25 December 2014 at 21:02, Leo Heinsaar <leohe...@gmail.com
> <javascript:>> wrote:
> > Hi Olaf - same argument from me as just wrote to Andy.
>
> See
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4273.htm
> and
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4280.pdf
>
> Having generic operations in the library is good, but it's rather likely
> that having them as non-member algorithms is somewhat
> preferred to adding a member to every container. Do remember that
> legacy arrays do not have member functions (although personally
> I don't really care). I'm not saying it wouldn't be good to add members
> that do the same thing for every container and would standardize
> existing-practice-boilerplate (if (foo.find(whatever)!=foo.end()) gets old
> after you've written it twice). I'm just saying that it may be a hard
> sell. ;)
>
> >
> > Thanks,
> > Leo
> >
> >
> > On Thursday, December 25, 2014 8:44:12 PM UTC+4, Olaf van der Spek
> wrote:
> >>
> >> On Thursday, December 25, 2014 7:40:40 AM UTC+1, Leo Heinsaar wrote:
> >>>
> >>> Hi guys,
> >>>
> >>> Range-for and auto greatly simplify code dealing with iterators -
> thanks
> >>> to all who contributed to that - but don't you think it's an omission
> we
> >>> still don't have the very simple bool contains(const T&) family in STL
> >>> containers?
> >>>
> >>> There's hardly a single production codebase in the world that doesn't
> >>> have the contains() boilerplate (I mean, of course, comparing the
> result of
> >>> find() to an end() to see if the value is there), often in multiple
> places.
> >>> And I guess range-for and auto were also at least partly born out of
> >>> realization that our code often deserves a higher abstraction level
> than
> >>> iterators.
> >>>
> >>> Correct me if I'm wrong, but I see contains() as a not-so-big of an
> >>> addition to the standard library that would be of quite significant
> value.
> >>
> >>
> >> Hi Leo,
> >>
> >> If it's about maps etc you could use count() or a find wrapper that
> >> returns a pointer (to second) for simpler syntax.
> >> contains() might still be useful.
> >>
> >> Olaf
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google
> Groups
> > "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an
> > email to std-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>
> > Visit this group at
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4958_1466525783.1419534805642
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">That's why I'm writing about it now Ville - hoping that by=
 now everybody will have written the boilerplate you mentioned so often tha=
t it would make it easier to sell :-)<br><br>On Thursday, December 25, 2014=
 11:08:19 PM UTC+4, Ville Voutilainen wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">On 25 December 2014 at 21:02, Leo Heinsaar &lt;<a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"HzipAv9cMnkJ" onmoused=
own=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'java=
script:';return true;">leohe...@gmail.com</a>&gt; wrote:
<br>&gt; Hi Olaf - same argument from me as just wrote to Andy.
<br>
<br>See
<br><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4273.ht=
m" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?=
q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2=
Fn4273.htm\46sa\75D\46sntz\0751\46usg\75AFQjCNG5lEWjrA5C95rgCsao7YMQcQPkug'=
;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3=
A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn4273.htm=
\46sa\75D\46sntz\0751\46usg\75AFQjCNG5lEWjrA5C95rgCsao7YMQcQPkug';return tr=
ue;">http://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2014/n4273.<wbr>ht=
m</a>
<br>and
<br><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4280.pd=
f" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?=
q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2=
Fn4280.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEhRdsDl469jeU0SzTNeX2N3tZ_mQ'=
;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3=
A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn4280.pdf=
\46sa\75D\46sntz\0751\46usg\75AFQjCNEhRdsDl469jeU0SzTNeX2N3tZ_mQ';return tr=
ue;">http://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2014/n4280.<wbr>pd=
f</a>
<br>
<br>Having generic operations in the library is good, but it's rather likel=
y
<br>that having them as non-member algorithms is somewhat
<br>preferred to adding a member to every container. Do remember that
<br>legacy arrays do not have member functions (although personally
<br>I don't really care). I'm not saying it wouldn't be good to add members
<br>that do the same thing for every container and would standardize
<br>existing-practice-boilerplate (if (foo.find(whatever)!=3Dfoo.end()<wbr>=
) gets old
<br>after you've written it twice). I'm just saying that it may be a hard s=
ell. ;)
<br>
<br>&gt;
<br>&gt; Thanks,
<br>&gt; Leo
<br>&gt;
<br>&gt;
<br>&gt; On Thursday, December 25, 2014 8:44:12 PM UTC+4, Olaf van der Spek=
 wrote:
<br>&gt;&gt;
<br>&gt;&gt; On Thursday, December 25, 2014 7:40:40 AM UTC+1, Leo Heinsaar =
wrote:
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; Hi guys,
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; Range-for and auto greatly simplify code dealing with iter=
ators - thanks
<br>&gt;&gt;&gt; to all who contributed to that - but don't you think it's =
an omission we
<br>&gt;&gt;&gt; still don't have the very simple bool contains(const T&amp=
;) family in STL
<br>&gt;&gt;&gt; containers?
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; There's hardly a single production codebase in the world t=
hat doesn't
<br>&gt;&gt;&gt; have the contains() boilerplate (I mean, of course, compar=
ing the result of
<br>&gt;&gt;&gt; find() to an end() to see if the value is there), often in=
 multiple places.
<br>&gt;&gt;&gt; And I guess range-for and auto were also at least partly b=
orn out of
<br>&gt;&gt;&gt; realization that our code often deserves a higher abstract=
ion level than
<br>&gt;&gt;&gt; iterators.
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; Correct me if I'm wrong, but I see contains() as a not-so-=
big of an
<br>&gt;&gt;&gt; addition to the standard library that would be of quite si=
gnificant value.
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; Hi Leo,
<br>&gt;&gt;
<br>&gt;&gt; If it's about maps etc you could use count() or a find wrapper=
 that
<br>&gt;&gt; returns a pointer (to second) for simpler syntax.
<br>&gt;&gt; contains() might still be useful.
<br>&gt;&gt;
<br>&gt;&gt; Olaf
<br>&gt;
<br>&gt; --
<br>&gt;
<br>&gt; ---
<br>&gt; You received this message because you are subscribed to the Google=
 Groups
<br>&gt; "ISO C++ Standard - Future Proposals" group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an
<br>&gt; email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"HzipAv9cMnkJ" onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr=
>isocpp.org</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"HzipAv9cMnkJ" onmousedown=3D"this.hre=
f=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return=
 true;">std-pr...@isocpp.org</a>.
<br>&gt; Visit this group at
<br>&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups.google.com=
/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"this.href=3D'h=
ttp://groups.google.com/a/isocpp.org/group/std-proposals/';return true;">ht=
tp://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposals/</a>.
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4958_1466525783.1419534805642--
------=_Part_4957_451509862.1419534805642--

.

On 25 December 2014 at 21:13, Leo Heinsaar <leoheinsaar@gmail.com> wrote:
> That's why I'm writing about it now Ville - hoping that by now everybody
> will have written the boilerplate you mentioned so often that it would make
> it easier to sell :-)

For what it's worth, somewhat philosophically: it took a while for people to
admit that "YES, it's FUNDAMENTAL to traverse a range from begin to
end, we should have a shortcut (range-for) for that". We are going towards
a direction where applying an algorithm for such a full range is considered
equally fundamental. One would hope that 'basic' operations like
"does this range contain element with value equivalent to 'foo'" would
be treated equally fundamental.

So, now that the *real* Ranges-work is ongoing, we need to remember
that the usual "let's do it with Ranges" is no longer just a "punt to unknown
time in the future with hand-waving", now we have a real proposal that
attempts to solve these issues in a comprehensive way instead of patching
algorithms individually.

>
> On Thursday, December 25, 2014 11:08:19 PM UTC+4, Ville Voutilainen wrote:
>>
>> On 25 December 2014 at 21:02, Leo Heinsaar <leohe...@gmail.com> wrote:
>> > Hi Olaf - same argument from me as just wrote to Andy.
>>
>> See
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4273.htm
>> and
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4280.pdf
>>
>> Having generic operations in the library is good, but it's rather likely
>> that having them as non-member algorithms is somewhat
>> preferred to adding a member to every container. Do remember that
>> legacy arrays do not have member functions (although personally
>> I don't really care). I'm not saying it wouldn't be good to add members
>> that do the same thing for every container and would standardize
>> existing-practice-boilerplate (if (foo.find(whatever)!=foo.end()) gets old
>> after you've written it twice). I'm just saying that it may be a hard
>> sell. ;)
>>
>> >
>> > Thanks,
>> > Leo
>> >
>> >
>> > On Thursday, December 25, 2014 8:44:12 PM UTC+4, Olaf van der Spek
>> > wrote:
>> >>
>> >> On Thursday, December 25, 2014 7:40:40 AM UTC+1, Leo Heinsaar wrote:
>> >>>
>> >>> Hi guys,
>> >>>
>> >>> Range-for and auto greatly simplify code dealing with iterators -
>> >>> thanks
>> >>> to all who contributed to that - but don't you think it's an omission
>> >>> we
>> >>> still don't have the very simple bool contains(const T&) family in STL
>> >>> containers?
>> >>>
>> >>> There's hardly a single production codebase in the world that doesn't
>> >>> have the contains() boilerplate (I mean, of course, comparing the
>> >>> result of
>> >>> find() to an end() to see if the value is there), often in multiple
>> >>> places.
>> >>> And I guess range-for and auto were also at least partly born out of
>> >>> realization that our code often deserves a higher abstraction level
>> >>> than
>> >>> iterators.
>> >>>
>> >>> Correct me if I'm wrong, but I see contains() as a not-so-big of an
>> >>> addition to the standard library that would be of quite significant
>> >>> value.
>> >>
>> >>
>> >> Hi Leo,
>> >>
>> >> If it's about maps etc you could use count() or a find wrapper that
>> >> returns a pointer (to second) for simpler syntax.
>> >> contains() might still be useful.
>> >>
>> >> Olaf
>> >
>> > --
>> >
>> > ---
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "ISO C++ Standard - Future Proposals" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to std-proposal...@isocpp.org.
>> > To post to this group, send email to std-pr...@isocpp.org.
>> > Visit this group at
>> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7bf18b1c177010050b1c7b95
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

One of the nice things of interfaces is that you only need to look in a
single place: if you want to know what a class can do, just look to a
bounded (close) set of methods delimited by the interface, rather than
having to look to a bunch of functions spread along random header files,
which reminds me C.
So, if we will enjoy uniform call syntax, I would vote for the member
version so the nonmember will come for free.
El 26/12/2014 06:30, "Leo Heinsaar" <leoheinsaar@gmail.com> escribi=C3=B3:

> As I wrote, if the problem is *syntactical*, then it might be solved by
>> the above-mentioned proposals. While I do understand that
>> "subject.verb(object)" reads somewhat more familiar than "verb(subject,
>> object)", I would not forget about the engineering consequences of makin=
g
>> contains() a member function, i.e. non-minimal interfaces that include m=
ore
>> functions than they need to. Scott Meyers and Alex Stepanov have written
>> extensively about this.
>
>
> Sorry Andy - I took a closer look at Bjarne's proposal; it seems like if
> it goes through, we'll indeed be able to have a global *contains()* with
> all the benefits with respect to having it for arrays and such, invokable
> via *vec.contains(x)* syntax. (It really is about nicer syntax as well as
> less - a lot less - typing.)
>
> If that's the case, then the problem is simply one step further: we simpl=
y
> need a global *contains()*. By the way, I guess that opens doors for
> other improvements as well.
>
> Thanks for pointing out.
>
> Kind regards,
> Leo
>
> On Thursday, December 25, 2014 11:46:35 PM UTC+4, Andy Prowl wrote:
>>
>> On Thursday, December 25, 2014 8:01:18 PM UTC+1, Leo Heinsaar wrote:
>>>
>>> Andy, I really don't think it's even worth going into the trouble to
>>> standardize the *contains(c, elem)* syntax. We might as well continue
>>> to write those functions ourselves - which is exactly my point: unlike =
with
>>> the *contains(c, elem)* syntax, we *can't* write *c.contains(elem)*
>>> ourselves unless we first define c's type deriving from a standard
>>> container, or including the standard container as a member and providin=
g a
>>> *contains()* method.
>>>
>>
>> As I wrote, if the problem is *syntactical*, then it might be solved by
>> the above-mentioned proposals. While I do understand that
>> "subject.verb(object)" reads somewhat more familiar than "verb(subject,
>> object)", I would not forget about the engineering consequences of makin=
g
>> contains() a member function, i.e. non-minimal interfaces that include m=
ore
>> functions than they need to. Scott Meyers and Alex Stepanov have written
>> extensively about this.
>>
>> This is a general problem, not specific to contains() and containers:
>> hence, it should be addressed generally. Many function calls are easier =
to
>> write (thanks to IDE support) using the dot notation, but that doesn't m=
ean
>> we should make all those functions members. IMO the right way of address=
ing
>> the problem of syntactic consistency for member and non-member function
>> calls (if we want to address it) is to support some sort of UFCS as
>> proposed (independently) by Herb and Bjarne. Just my two cents.
>>
>> Kind regards,
>>
>> Andy
>>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7bf18b1c177010050b1c7b95
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>One of the nice things of interfaces is that you only need to look in a =
single place: if you want to know what a class can do, just look to a bound=
ed (close) set of methods delimited by the interface, rather than having to=
 look to a bunch of functions spread along random header files, which remin=
ds me C.<br>
So, if we will enjoy uniform call syntax, I would vote for the member versi=
on so the nonmember will come for free.</p>
<div class=3D"gmail_quote">El 26/12/2014 06:30, &quot;Leo Heinsaar&quot; &l=
t;<a href=3D"mailto:leoheinsaar@gmail.com">leoheinsaar@gmail.com</a>&gt; es=
cribi=C3=B3:<br type=3D"attribution"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex"><span style=3D"font-size:13.3333330154419px">As =
I wrote, if the problem is=C2=A0</span><i style=3D"font-size:13.33333301544=
19px">syntactical</i><span style=3D"font-size:13.3333330154419px">, then it=
 might be solved by the above-mentioned proposals. While I do understand th=
at &quot;subject.verb(object)&quot; reads somewhat more familiar than &quot=
;verb(subject, object)&quot;, I would not forget about the engineering cons=
equences of making contains() a member function, i.e. non-minimal interface=
s that include more functions than they need to. Scott Meyers and Alex Step=
anov have written extensively about this.=C2=A0</span></blockquote><div><br=
></div><div>Sorry Andy - I took a closer look at Bjarne&#39;s proposal; it =
seems like if it goes through, we&#39;ll indeed be able to have a global <b=
>contains()</b>=C2=A0with all the benefits with respect to having it for ar=
rays and such, invokable via=C2=A0<b>vec.contains(x)</b> syntax. (It really=
 is=C2=A0about nicer syntax as well as less - a lot less - typing.)</div><d=
iv><br></div><div>If that&#39;s the case, then the problem is simply one st=
ep further: we simply need a global <b>contains()</b>. By the way, I guess =
that opens doors for other improvements as well.</div><div><br></div><div>T=
hanks for pointing out.</div><div><br></div><div>Kind regards,</div><div>Le=
o</div><div><br>On Thursday, December 25, 2014 11:46:35 PM UTC+4, Andy Prow=
l wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursda=
y, December 25, 2014 8:01:18 PM UTC+1, Leo Heinsaar wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">Andy, I really don&#39;t think it&#=
39;s even worth going into the trouble to standardize the <b>contains(c, el=
em)</b> syntax. We might as well continue to write those functions ourselve=
s - which is exactly my point: unlike with the=C2=A0<b>contains(c, elem)</b=
>=C2=A0syntax,=C2=A0we <i>can&#39;t</i> write <b>c.contains(elem)</b> ourse=
lves unless we first define c&#39;s type deriving from a standard container=
, or including the standard container as a member and providing a <b>contai=
ns()</b> method.</div></blockquote><div><br></div><div>As I wrote, if the p=
roblem is=C2=A0<i>syntactical</i>, then it might be solved by the above-men=
tioned proposals. While I do understand that &quot;subject.verb(object)&quo=
t; reads somewhat more familiar than &quot;verb(subject, object)&quot;, I w=
ould not forget about the engineering consequences of making contains() a m=
ember function, i.e. non-minimal interfaces that include more functions tha=
n they need to. Scott Meyers and Alex Stepanov have written extensively abo=
ut this.=C2=A0<br><br>This is a general problem, not specific to contains()=
 and containers: hence, it should be addressed generally. Many function cal=
ls are easier to write (thanks to IDE support) using the dot notation, but =
that doesn&#39;t mean we should make all those functions members. IMO the r=
ight way of addressing the problem of syntactic consistency for member and =
non-member function calls (if we want to address it) is to support some sor=
t of UFCS as proposed=C2=A0<span style=3D"font-size:13.3333330154419px">(in=
dependently)</span><span style=3D"font-size:13.3333330154419px">=C2=A0</spa=
n><span style=3D"font-size:13px">by Herb and Bjarne. Just my two cents.</sp=
an></div><div><br>Kind regards,<br><br>Andy</div></div></blockquote></div><=
/div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bf18b1c177010050b1c7b95--

.

------=_Part_5111_1158102640.1419594017112
Content-Type: multipart/alternative;
 boundary="----=_Part_5112_1586777719.1419594017112"

------=_Part_5112_1586777719.1419594017112
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


>
> One of the nice things of interfaces is that you only need to look in a=
=20
> single place: if you want to know what a class can do, just look to a=20
> bounded (close) set of methods delimited by the interface, rather than=20
> having to look to a bunch of functions spread along random header files,=
=20
> which reminds me C.
> So, if we will enjoy uniform call syntax, I would vote for the member=20
> version so the nonmember will come for free.


Good point though.

On Friday, December 26, 2014 3:05:46 PM UTC+4, dgutson wrote:
>
> One of the nice things of interfaces is that you only need to look in a=
=20
> single place: if you want to know what a class can do, just look to a=20
> bounded (close) set of methods delimited by the interface, rather than=20
> having to look to a bunch of functions spread along random header files,=
=20
> which reminds me C.
> So, if we will enjoy uniform call syntax, I would vote for the member=20
> version so the nonmember will come for free.
> El 26/12/2014 06:30, "Leo Heinsaar" <leohe...@gmail.com <javascript:>>=20
> escribi=C3=B3:
>
>> As I wrote, if the problem is *syntactical*, then it might be solved by=
=20
>>> the above-mentioned proposals. While I do understand that=20
>>> "subject.verb(object)" reads somewhat more familiar than "verb(subject,=
=20
>>> object)", I would not forget about the engineering consequences of maki=
ng=20
>>> contains() a member function, i.e. non-minimal interfaces that include =
more=20
>>> functions than they need to. Scott Meyers and Alex Stepanov have writte=
n=20
>>> extensively about this.=20
>>
>>
>> Sorry Andy - I took a closer look at Bjarne's proposal; it seems like if=
=20
>> it goes through, we'll indeed be able to have a global *contains()* with=
=20
>> all the benefits with respect to having it for arrays and such, invokabl=
e=20
>> via *vec.contains(x)* syntax. (It really is about nicer syntax as well=
=20
>> as less - a lot less - typing.)
>>
>> If that's the case, then the problem is simply one step further: we=20
>> simply need a global *contains()*. By the way, I guess that opens doors=
=20
>> for other improvements as well.
>>
>> Thanks for pointing out.
>>
>> Kind regards,
>> Leo
>>
>> On Thursday, December 25, 2014 11:46:35 PM UTC+4, Andy Prowl wrote:
>>>
>>> On Thursday, December 25, 2014 8:01:18 PM UTC+1, Leo Heinsaar wrote:
>>>>
>>>> Andy, I really don't think it's even worth going into the trouble to=
=20
>>>> standardize the *contains(c, elem)* syntax. We might as well continue=
=20
>>>> to write those functions ourselves - which is exactly my point: unlike=
 with=20
>>>> the *contains(c, elem)* syntax, we *can't* write *c.contains(elem)*=20
>>>> ourselves unless we first define c's type deriving from a standard=20
>>>> container, or including the standard container as a member and providi=
ng a=20
>>>> *contains()* method.
>>>>
>>>
>>> As I wrote, if the problem is *syntactical*, then it might be solved by=
=20
>>> the above-mentioned proposals. While I do understand that=20
>>> "subject.verb(object)" reads somewhat more familiar than "verb(subject,=
=20
>>> object)", I would not forget about the engineering consequences of maki=
ng=20
>>> contains() a member function, i.e. non-minimal interfaces that include =
more=20
>>> functions than they need to. Scott Meyers and Alex Stepanov have writte=
n=20
>>> extensively about this.=20
>>>
>>> This is a general problem, not specific to contains() and containers:=
=20
>>> hence, it should be addressed generally. Many function calls are easier=
 to=20
>>> write (thanks to IDE support) using the dot notation, but that doesn't =
mean=20
>>> we should make all those functions members. IMO the right way of addres=
sing=20
>>> the problem of syntactic consistency for member and non-member function=
=20
>>> calls (if we want to address it) is to support some sort of UFCS as=20
>>> proposed (independently) by Herb and Bjarne. Just my two cents.
>>>
>>> Kind regards,
>>>
>>> Andy
>>>
>>  --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_5112_1586777719.1419594017112
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); =
border-left-style: solid; padding-left: 1ex;"><span style=3D"font-size: 13.=
3333330154419px; line-height: 18px;">One of the nice things of interfaces i=
s that you only need to look in a single place: if you want to know what a =
class can do, just look to a bounded (close) set of methods delimited by th=
e interface, rather than having to look to a bunch of functions spread alon=
g random header files, which reminds me C.<br></span><span style=3D"font-si=
ze: 13.3333330154419px; line-height: 18px;">So, if we will enjoy uniform ca=
ll syntax, I would vote for the member version so the nonmember will come f=
or free.</span></blockquote><div><span style=3D"line-height: 18px;"><br></s=
pan></div><div><span style=3D"line-height: 18px;">Good point though.<br></s=
pan><br>On Friday, December 26, 2014 3:05:46 PM UTC+4, dgutson wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><p>One of the nice things of interfa=
ces is that you only need to look in a single place: if you want to know wh=
at a class can do, just look to a bounded (close) set of methods delimited =
by the interface, rather than having to look to a bunch of functions spread=
 along random header files, which reminds me C.<br>
So, if we will enjoy uniform call syntax, I would vote for the member versi=
on so the nonmember will come for free.</p>
<div class=3D"gmail_quote">El 26/12/2014 06:30, "Leo Heinsaar" &lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"qeUghBVFuSkJ" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">leohe...@gmail.com</a>&gt; escribi=C3=B3:<br=
 type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex"><span style=3D"font-size:13.3333330154419px">As I wrote, if the=
 problem is&nbsp;</span><i style=3D"font-size:13.3333330154419px">syntactic=
al</i><span style=3D"font-size:13.3333330154419px">, then it might be solve=
d by the above-mentioned proposals. While I do understand that "subject.ver=
b(object)" reads somewhat more familiar than "verb(subject, object)", I wou=
ld not forget about the engineering consequences of making contains() a mem=
ber function, i.e. non-minimal interfaces that include more functions than =
they need to. Scott Meyers and Alex Stepanov have written extensively about=
 this.&nbsp;</span></blockquote><div><br></div><div>Sorry Andy - I took a c=
loser look at Bjarne's proposal; it seems like if it goes through, we'll in=
deed be able to have a global <b>contains()</b>&nbsp;with all the benefits =
with respect to having it for arrays and such, invokable via&nbsp;<b>vec.co=
ntains(x)</b> syntax. (It really is&nbsp;about nicer syntax as well as less=
 - a lot less - typing.)</div><div><br></div><div>If that's the case, then =
the problem is simply one step further: we simply need a global <b>contains=
()</b>. By the way, I guess that opens doors for other improvements as well=
..</div><div><br></div><div>Thanks for pointing out.</div><div><br></div><di=
v>Kind regards,</div><div>Leo</div><div><br>On Thursday, December 25, 2014 =
11:46:35 PM UTC+4, Andy Prowl wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">On Thursday, December 25, 2014 8:01:18 PM UTC+1, Leo Hein=
saar wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Andy, I=
 really don't think it's even worth going into the trouble to standardize t=
he <b>contains(c, elem)</b> syntax. We might as well continue to write thos=
e functions ourselves - which is exactly my point: unlike with the&nbsp;<b>=
contains(c, elem)</b>&nbsp;syntax,&nbsp;we <i>can't</i> write <b>c.contains=
(elem)</b> ourselves unless we first define c's type deriving from a standa=
rd container, or including the standard container as a member and providing=
 a <b>contains()</b> method.</div></blockquote><div><br></div><div>As I wro=
te, if the problem is&nbsp;<i>syntactical</i>, then it might be solved by t=
he above-mentioned proposals. While I do understand that "subject.verb(obje=
ct)" reads somewhat more familiar than "verb(subject, object)", I would not=
 forget about the engineering consequences of making contains() a member fu=
nction, i.e. non-minimal interfaces that include more functions than they n=
eed to. Scott Meyers and Alex Stepanov have written extensively about this.=
&nbsp;<br><br>This is a general problem, not specific to contains() and con=
tainers: hence, it should be addressed generally. Many function calls are e=
asier to write (thanks to IDE support) using the dot notation, but that doe=
sn't mean we should make all those functions members. IMO the right way of =
addressing the problem of syntactic consistency for member and non-member f=
unction calls (if we want to address it) is to support some sort of UFCS as=
 proposed&nbsp;<span style=3D"font-size:13.3333330154419px">(independently)=
</span><span style=3D"font-size:13.3333330154419px">&nbsp;</span><span styl=
e=3D"font-size:13px">by Herb and Bjarne. Just my two cents.</span></div><di=
v><br>Kind regards,<br><br>Andy</div></div></blockquote></div></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
qeUghBVFuSkJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"qeUghBVFuSkJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</blockquote></div>
</blockquote></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5112_1586777719.1419594017112--
------=_Part_5111_1158102640.1419594017112--

.

On Fri, Dec 26, 2014 at 10:30 AM, Leo Heinsaar <leoheinsaar@gmail.com> wrote:
> Sorry Andy - I took a closer look at Bjarne's proposal; it seems like if it
> goes through, we'll indeed be able to have a global contains() with all the
> benefits with respect to having it for arrays and such, invokable via
> vec.contains(x) syntax. (It really is about nicer syntax as well as less - a
> lot less - typing.)

How is it less typing? Auto-complete?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_5292_1781448045.1419600702034
Content-Type: multipart/alternative;
 boundary="----=_Part_5293_580285841.1419600702035"

------=_Part_5293_580285841.1419600702035
Content-Type: text/plain; charset=UTF-8

On Friday, December 26, 2014 4:50:15 PM UTC+4, Olaf van der Spek wrote:
>
> On Fri, Dec 26, 2014 at 10:30 AM, Leo Heinsaar <leohe...@gmail.com
> <javascript:>> wrote:
> > Sorry Andy - I took a closer look at Bjarne's proposal; it seems like if
> it
> > goes through, we'll indeed be able to have a global contains() with all
> the
> > benefits with respect to having it for arrays and such, invokable via
> > vec.contains(x) syntax. (It really is about nicer syntax as well as less
> - a
> > lot less - typing.)
>
> How is it less typing? Auto-complete?
>

Since we'll be able to simply write

*phone_book.contains(number)*

instead of:

*phone_book.find(number) != phone_book.end()*

Not to mention how much more clearly the simplified version, as they like
to call it, expresses intent.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_5293_580285841.1419600702035
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, December 26, 2014 4:50:15 PM UTC+4, Olaf van de=
r Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Dec 26, 2=
014 at 10:30 AM, Leo Heinsaar &lt;<a href=3D"javascript:" target=3D"_blank"=
 gdf-obfuscated-mailto=3D"2jF1ZAHCS9cJ" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return true;">leoh=
e...@gmail.com</a>&gt; wrote:
<br>&gt; Sorry Andy - I took a closer look at Bjarne's proposal; it seems l=
ike if it
<br>&gt; goes through, we'll indeed be able to have a global contains() wit=
h all the
<br>&gt; benefits with respect to having it for arrays and such, invokable =
via
<br>&gt; vec.contains(x) syntax. (It really is about nicer syntax as well a=
s less - a
<br>&gt; lot less - typing.)
<br>
<br>How is it less typing? Auto-complete?
<br></blockquote><div><br></div><div>Since we'll be able to simply write</d=
iv><blockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><d=
iv><b>phone_book.contains(number)</b></div></blockquote><div><span style=3D=
"font-size: 13px;">instead of:</span></div><blockquote style=3D"margin: 0 0=
 0 40px; border: none; padding: 0px;"><div><span style=3D"font-size: 13px;"=
><b>phone_book.find(number) !=3D phone_book.end()</b></span></div></blockqu=
ote><div>Not to mention how much more clearly the simplified version, as th=
ey like to call it, expresses intent.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5293_580285841.1419600702035--
------=_Part_5292_1781448045.1419600702034--

.

------=_Part_684_947562529.1419606804786
Content-Type: multipart/alternative;
 boundary="----=_Part_685_2092182398.1419606804787"

------=_Part_685_2092182398.1419606804787
Content-Type: text/plain; charset=UTF-8

On Friday, December 26, 2014 12:05:46 PM UTC+1, dgutson wrote:


> One of the nice things of interfaces is that you only need to look in a
> single place: if you want to know what a class can do, just look to a
> bounded (close) set of methods delimited by the interface, rather than
> having to look to a bunch of functions spread along random header files,
> which reminds me C.
> So, if we will enjoy uniform call syntax, I would vote for the member
> version so the nonmember will come for free
>
Well, you can put the declaration of the non-fundamental functions which
are part of a class's logical interface in the header that comes with that
class, and in the same namespace as the class. This is the gist of the Interface
Principle <http://www.gotw.ca/publications/mill08.htm> (the article is old,
but still valid). This way, you'd still have one single place to look at
when you want to know what a class can do, but you won't make the class's
interface larger than necessary.

Notice, that it is generally not possible to declare all functions that
work with a class as member functions of that class, so having free
functions (or member functions of *other* classes, but that does not
eliminate the problem of functionality being "spread along random header
files") is unavoidable.

Kind regards,

Andy

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_685_2092182398.1419606804787
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, December 26, 2014 12:05:46 PM UTC+1, dgutson wr=
ote:<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p>One of=
 the nice things of interfaces is that you only need to look in a single pl=
ace: if you want to know what a class can do, just look to a bounded (close=
) set of methods delimited by the interface, rather than having to look to =
a bunch of functions spread along random header files, which reminds me C.<=
br>
So, if we will enjoy uniform call syntax, I would vote for the member versi=
on so the nonmember will come for free</p></blockquote><div>Well, you can p=
ut the declaration of the non-fundamental functions which are part of a cla=
ss's logical interface in the header that comes with that class, and in the=
 same namespace as the class. This is the gist of the <a href=3D"http://www=
..gotw.ca/publications/mill08.htm">Interface Principle</a>&nbsp;(the article=
 is old, but still valid). This way, you'd still have one single place to l=
ook at when you want to know what a class can do, but you won't make the cl=
ass's interface larger than necessary.<br><br>Notice, that it is generally =
not possible to declare all functions that work with a class as member func=
tions of that class, so having free functions (or member functions of <i>ot=
her</i> classes, but that does not eliminate the problem of functionality b=
eing "spread along random header files") is unavoidable.<br><br>Kind regard=
s,<br><br>Andy</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_685_2092182398.1419606804787--
------=_Part_684_947562529.1419606804786--

.

------=_Part_4284_597702032.1419607188992
Content-Type: multipart/alternative;
 boundary="----=_Part_4285_1797034805.1419607188992"

------=_Part_4285_1797034805.1419607188992
Content-Type: text/plain; charset=UTF-8

On Friday, December 26, 2014 2:31:42 PM UTC+1, Leo Heinsaar wrote:
>
> On Friday, December 26, 2014 4:50:15 PM UTC+4, Olaf van der Spek wrote:
>>
>> On Fri, Dec 26, 2014 at 10:30 AM, Leo Heinsaar <leohe...@gmail.com>
>> wrote:
>>
>> How is it less typing? Auto-complete?
>>
>
> Since we'll be able to simply write
>
> *phone_book.contains(number)*
>
> instead of:
>
> *phone_book.find(number) != phone_book.end()*
>
> Not to mention how much more clearly the simplified version, as they like
> to call it, expresses intent.
>

I think Olaf meant to ask what is the advantage of the v.contains(x) syntax
over the contains(v, x) syntax in terms of typing. In fact, there is not
much of an advantage apart from auto-completion (as Olaf suggests).

IMO we shouldn't focus much on minimizing the amount of *typing*: it is not
*that* important for code to be easy to write as it is to be easy to read.
We read and reason about code much more frequently than we write it, and
constantly aiming for the least number of keystrokes is not a good practice
and it does not help reasoning about the result of our typing (see the
several discussions on intent-revealing names, small extracted functions,
etc.).

This said, there are situations where the dot notation would make code easy
to read (not sure this is one of them though), e.g. when composing
algorithms that work on ranges. This is why I think it is worth considering
UFCS proposals. As a side-effect, this would bring us more flexibility (and
possibly more consistency) in choosing the best syntax for function calls.

Kind regards,

Andy

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4285_1797034805.1419607188992
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, December 26, 2014 2:31:42 PM UTC+1, Leo Heinsaa=
r wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Fr=
iday, December 26, 2014 4:50:15 PM UTC+4, Olaf van der Spek wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Fri, Dec 26, 2014 at 10:30 AM, Leo Heinsa=
ar &lt;<a>leohe...@gmail.com</a>&gt; wrote:
<br><br>How is it less typing? Auto-complete?
<br></blockquote><div><br></div><div>Since we'll be able to simply write</d=
iv><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div><b>=
phone_book.contains(number)</b></div></blockquote><div><span style=3D"font-=
size:13px">instead of:</span></div><blockquote style=3D"margin:0 0 0 40px;b=
order:none;padding:0px"><div><span style=3D"font-size:13px"><b>phone_book.f=
ind(number) !=3D phone_book.end()</b></span></div></blockquote><div>Not to =
mention how much more clearly the simplified version, as they like to call =
it, expresses intent.</div></div></blockquote><div><br>I think Olaf meant t=
o ask what is the advantage of the v.contains(x) syntax over the contains(v=
, x) syntax in terms of typing. In fact, there is not much of an advantage =
apart from auto-completion (as Olaf suggests). <br><br>IMO we shouldn't foc=
us much on minimizing the amount of <i>typing</i>: it is not <i>that</i> im=
portant for code to be easy to write as it is to be easy to read. We read a=
nd reason about code much more frequently than we write it, and constantly =
aiming for the least number of keystrokes is not a good practice and it doe=
s not help reasoning about the result of our typing (see the several discus=
sions on intent-revealing names, small extracted functions, etc.).<br><br>T=
his said, there are situations where the dot notation would make code easy =
to read (not sure this is one of them though), e.g. when composing algorith=
ms that work on ranges. This is why I think it is worth considering UFCS pr=
oposals. As a side-effect, this would bring us more flexibility (and possib=
ly more consistency) in choosing the best syntax for function calls.<br><br=
>Kind regards,<br><br>Andy</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4285_1797034805.1419607188992--
------=_Part_4284_597702032.1419607188992--

.

On Fri, Dec 26, 2014 at 2:31 PM, Leo Heinsaar <leoheinsaar@gmail.com> wrote:
> On Friday, December 26, 2014 4:50:15 PM UTC+4, Olaf van der Spek wrote:
>>
>> On Fri, Dec 26, 2014 at 10:30 AM, Leo Heinsaar <leohe...@gmail.com> wrote:
>> > Sorry Andy - I took a closer look at Bjarne's proposal; it seems like if
>> > it
>> > goes through, we'll indeed be able to have a global contains() with all
>> > the
>> > benefits with respect to having it for arrays and such, invokable via
>> > vec.contains(x) syntax. (It really is about nicer syntax as well as less
>> > - a
>> > lot less - typing.)
>>
>> How is it less typing? Auto-complete?
>
>
> Since we'll be able to simply write
>
> phone_book.contains(number)
>
> instead of:
>
> phone_book.find(number) != phone_book.end()
>
> Not to mention how much more clearly the simplified version, as they like to
> call it, expresses intent.

I thought that was an argument against a free function.
Today one can already write phone_book.count(number);

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_57_1147810814.1419613679835
Content-Type: multipart/alternative;
 boundary="----=_Part_58_410749897.1419613679835"

------=_Part_58_410749897.1419613679835
Content-Type: text/plain; charset=UTF-8


On Friday, December 26, 2014 8:29:19 PM UTC+4, Olaf van der Spek wrote:
>
> On Fri, Dec 26, 2014 at 2:31 PM, Leo Heinsaar <leohe...@gmail.com
> <javascript:>> wrote:
> > On Friday, December 26, 2014 4:50:15 PM UTC+4, Olaf van der Spek wrote:
> >>
> >> On Fri, Dec 26, 2014 at 10:30 AM, Leo Heinsaar <leohe...@gmail.com>
> wrote:
> >> > Sorry Andy - I took a closer look at Bjarne's proposal; it seems like
> if
> >> > it
> >> > goes through, we'll indeed be able to have a global contains() with
> all
> >> > the
> >> > benefits with respect to having it for arrays and such, invokable via
> >> > vec.contains(x) syntax. (It really is about nicer syntax as well as
> less
> >> > - a
> >> > lot less - typing.)
> >>
> >> How is it less typing? Auto-complete?
> >
> >
> > Since we'll be able to simply write
> >
> > phone_book.contains(number)
> >
> > instead of:
> >
> > phone_book.find(number) != phone_book.end()
> >
> > Not to mention how much more clearly the simplified version, as they
> like to
> > call it, expresses intent.
>
> I thought that was an argument against a free function.
> Today one can already write phone_book.count(number);
>

Oh sorry Olaf, I misunderstood; when I responded to Andy by saying, "It
really is about nicer syntax as well as less - a lot less - typing.", I
meant the convenience of having *contains()* versus not having it at all.

I guess *phone_book.count(number)* does more work than is necessary for
*contains()*; may not be suitable for every situation.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_58_410749897.1419613679835
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Friday, December 26, 2014 8:29:19 PM UTC+4, Olaf va=
n der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Dec 2=
6, 2014 at 2:31 PM, Leo Heinsaar &lt;<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"5ttJ357XDJwJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">l=
eohe...@gmail.com</a>&gt; wrote:
<br>&gt; On Friday, December 26, 2014 4:50:15 PM UTC+4, Olaf van der Spek w=
rote:
<br>&gt;&gt;
<br>&gt;&gt; On Fri, Dec 26, 2014 at 10:30 AM, Leo Heinsaar &lt;<a>leohe...=
@gmail.com</a>&gt; wrote:
<br>&gt;&gt; &gt; Sorry Andy - I took a closer look at Bjarne's proposal; i=
t seems like if
<br>&gt;&gt; &gt; it
<br>&gt;&gt; &gt; goes through, we'll indeed be able to have a global conta=
ins() with all
<br>&gt;&gt; &gt; the
<br>&gt;&gt; &gt; benefits with respect to having it for arrays and such, i=
nvokable via
<br>&gt;&gt; &gt; vec.contains(x) syntax. (It really is about nicer syntax =
as well as less
<br>&gt;&gt; &gt; - a
<br>&gt;&gt; &gt; lot less - typing.)
<br>&gt;&gt;
<br>&gt;&gt; How is it less typing? Auto-complete?
<br>&gt;
<br>&gt;
<br>&gt; Since we'll be able to simply write
<br>&gt;
<br>&gt; phone_book.contains(number)
<br>&gt;
<br>&gt; instead of:
<br>&gt;
<br>&gt; phone_book.find(number) !=3D phone_book.end()
<br>&gt;
<br>&gt; Not to mention how much more clearly the simplified version, as th=
ey like to
<br>&gt; call it, expresses intent.
<br>
<br>I thought that was an argument against a free function.
<br>Today one can already write phone_book.count(number);
<br></blockquote><div><br></div><div>Oh sorry Olaf, I misunderstood; when I=
 responded to Andy by saying, "It really is about nicer syntax as well as l=
ess -&nbsp;a&nbsp;lot less - typing.", I meant the convenience of having <b=
>contains()</b> versus not having it at all.</div><div><br></div><div>I gue=
ss <b>phone_book.count(number)</b> does more work than is necessary for <b>=
contains()</b>; may not be suitable for every situation.</div><div><br></di=
v></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_58_410749897.1419613679835--
------=_Part_57_1147810814.1419613679835--

.

On Fri, Dec 26, 2014 at 6:29 PM, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
>> I guess *phone_book.count(number)* does more work than is necessary for
>> *contains()*; may not be suitable for every situation.
>
> I would *hope* that non-multi-key containers optimize ::count() to be as
> efficient as ::contains() would be (and indeed, I've been known to use
> this trick before).
>
> Actually, what would probably be better is if I could write:
>
>     if (auto&& iter = container.find(key))
>
> ...since in most cases I then want to do something with the element, so
> already having the iterator is convenient. What's really inconvenient is
> having to write 'container.end()' and a separate line (one level higher
> in scope) to store the iterator because I can't both declare and assign
> the iterator, and compare it to end, in the same line.
>
> Maybe we could instead create a form of ::find() that returns an
> optional<iterator> or checked_iterator or similar, that can be
> implicitly cast to bool to test for validity.

if (auto p = find_ptr(key))

https://code.google.com/p/xbt/source/browse/trunk/xbt/misc/xbt/find_ptr.h


--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_311_1333924014.1419615229773
Content-Type: multipart/alternative;
 boundary="----=_Part_312_1679112265.1419615229773"

------=_Part_312_1679112265.1419615229773
Content-Type: text/plain; charset=UTF-8


>
> How is it less typing? Auto-complete?
>>>
>>
>> Since we'll be able to simply write
>>
>> *phone_book.contains(number)*
>>
>> instead of:
>>
>> *phone_book.find(number) != phone_book.end()*
>>
>> Not to mention how much more clearly the simplified version, as they like
>> to call it, expresses intent.
>>
>
> I think Olaf meant to ask what is the advantage of the v.contains(x)
> syntax over the contains(v, x) syntax in terms of typing. In fact, there is
> not much of an advantage apart from auto-completion (as Olaf suggests).
>

You're right Andy - I misunderstood.


>
> IMO we shouldn't focus much on minimizing the amount of *typing*: it is
> not *that* important for code to be easy to write as it is to be easy to
> read. We read and reason about code much more frequently than we write it,
> and constantly aiming for the least number of keystrokes is not a good
> practice and it does not help reasoning about the result of our typing (see
> the several discussions on intent-revealing names, small extracted
> functions, etc.).
>

Actually, the whole reason that led to the opening of this topic is
precisely because I kept seeing so many *"...!= end()"s* when trying to *read
*and understand our code. Also, it seems to me that *less typing* is
directly proportional to *easy reading*. For example, when I try to figure
out what some of our very loopy code does, I rewrite all the loops in
range-fors and get rid of all the iterators. It really does give me the
birds-eye view of the intent of the code so I read and navigate the logic
much easier. Of course, neither range-fors nor autos were introduced to *minimize
typing*, but thankfully less typing *did* come with them, and that
simplifies reading - greatly.


>
> This said, there are situations where the dot notation would make code
> easy to read (not sure this is one of them though), e.g. when composing
> algorithms that work on ranges. This is why I think it is worth considering
> UFCS proposals. As a side-effect, this would bring us more flexibility (and
> possibly more consistency) in choosing the best syntax for function calls.
>
> Kind regards,
>
> Andy
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_312_1679112265.1419615229773
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">How is it less typing? Auto-complete?
<br></blockquote><div><br></div><div>Since we'll be able to simply write</d=
iv><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div><b>=
phone_book.contains(number)</b></div></blockquote><div><span style=3D"font-=
size:13px">instead of:</span></div><blockquote style=3D"margin:0 0 0 40px;b=
order:none;padding:0px"><div><span style=3D"font-size:13px"><b>phone_book.f=
ind(number) !=3D phone_book.end()</b></span></div></blockquote><div>Not to =
mention how much more clearly the simplified version, as they like to call =
it, expresses intent.</div></div></blockquote><div><br>I think Olaf meant t=
o ask what is the advantage of the v.contains(x) syntax over the contains(v=
, x) syntax in terms of typing. In fact, there is not much of an advantage =
apart from auto-completion (as Olaf suggests). <br></div></div></blockquote=
><div><br></div><div>You're right Andy - I misunderstood.</div><div>&nbsp;<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br=
>IMO we shouldn't focus much on minimizing the amount of <i>typing</i>: it =
is not <i>that</i> important for code to be easy to write as it is to be ea=
sy to read. We read and reason about code much more frequently than we writ=
e it, and constantly aiming for the least number of keystrokes is not a goo=
d practice and it does not help reasoning about the result of our typing (s=
ee the several discussions on intent-revealing names, small extracted funct=
ions, etc.).<br></div></div></blockquote><div><br></div><div>Actually, the =
whole reason that led to the opening of this topic is precisely because I k=
ept seeing so many <i>"...!=3D end()"s</i>&nbsp;when trying to <i>read </i>=
and understand our code. Also, it seems to me that&nbsp;<i>less typing</i>&=
nbsp;is directly proportional to&nbsp;<i>easy reading</i>. For example, whe=
n I try to figure out what some of our very loopy code does, I rewrite all =
the loops in range-fors and get rid of all the iterators. It really does gi=
ve me the birds-eye view of the intent of the code so I read and navigate t=
he logic much easier. Of course, neither range-fors nor autos were introduc=
ed to <i>minimize typing</i>, but thankfully less typing <i>did</i> come wi=
th them, and that simplifies reading - greatly.&nbsp;</div><div>&nbsp;</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>Thi=
s said, there are situations where the dot notation would make code easy to=
 read (not sure this is one of them though), e.g. when composing algorithms=
 that work on ranges. This is why I think it is worth considering UFCS prop=
osals. As a side-effect, this would bring us more flexibility (and possibly=
 more consistency) in choosing the best syntax for function calls.<br><br>K=
ind regards,<br><br>Andy</div></div></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_312_1679112265.1419615229773--
------=_Part_311_1333924014.1419615229773--

.

On Fri, Dec 26, 2014 at 6:47 PM, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
> On 2014-12-26 12:33, Olaf van der Spek wrote:
>> On Fri, Dec 26, 2014 at 6:29 PM, Matthew Woehlke wrote:
>>> Maybe we could instead create a form of ::find() that returns an
>>> optional<iterator> or checked_iterator or similar, that can be
>>> implicitly cast to bool to test for validity.
>>
>> if (auto p = find_ptr(key))
>>
>> https://code.google.com/p/xbt/source/browse/trunk/xbt/misc/xbt/find_ptr.h
>
> It would be better if I can recover the iterator. Maybe I want to do
> something with the item and then remove it...

Maybe, but in most cases you don't (in code I've seen).

> (Still... something like that, *standardized*, would be an improvement.)

Yep, in the mean time...

--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_4421_2008359295.1419616927581
Content-Type: multipart/alternative;
 boundary="----=_Part_4422_990137522.1419616927586"

------=_Part_4422_990137522.1419616927586
Content-Type: text/plain; charset=UTF-8

While I agree with most of what has been written in the last few messages,
I feel we are slowly diverging from the purpose of the original post,
perhaps unnecessarily enlarging its scope.

I think an algorithm like "contains()" for "containers" is such an obvious
and elementary operation that it ought to be in the standard library: it is
simpler, easier to teach, and easier to understand than the current "!=
end()" idiom.

IMO a proposal should be written for adding this function, and keeping its
scope narrow may increase its chances to get accepted.

Kind regards,

Andy

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4422_990137522.1419616927586
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">While I agree with most of what has been written in the la=
st few messages, I feel we are slowly diverging from the purpose of the ori=
ginal post, perhaps unnecessarily enlarging its scope.<br><br>I think an al=
gorithm like "contains()" for "containers" is such an obvious and elementar=
y operation that it ought to be in the standard library: it is simpler, eas=
ier to teach, and easier to understand than the current "!=3D end()" idiom.=
<br><br>IMO a proposal should be written for adding this function, and keep=
ing its scope narrow may increase its chances to get accepted.<br><div><br>=
Kind regards,<br><br></div><div>Andy</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4422_990137522.1419616927586--
------=_Part_4421_2008359295.1419616927581--

.

------=_Part_6335_2115259800.1419617930022
Content-Type: multipart/alternative;
 boundary="----=_Part_6336_1727166162.1419617930022"

------=_Part_6336_1727166162.1419617930022
Content-Type: text/plain; charset=UTF-8


On Friday, December 26, 2014 10:02:07 PM UTC+4, Andy Prowl wrote:
>
> While I agree with most of what has been written in the last few messages,
> I feel we are slowly diverging from the purpose of the original post,
> perhaps unnecessarily enlarging its scope.
>

Yep guys, felt the same divergence.


> I think an algorithm like "contains()" for "containers" is such an obvious
> and elementary operation that it ought to be in the standard library: it is
> simpler, easier to teach, and easier to understand than the current "!=
> end()" idiom.
>
>
Exactly the point: a simple, easy-to-read, very-frequently-used,
bool-returning contains(). If we want to recover an iterator, we just use
find(), don't we? (And in cases like that the code usually isn't concerned
about the existence of an element in a container, but wants to do
something.)


> IMO a proposal should be written for adding this function, and keeping its
> scope narrow may increase its chances to get accepted.
>
>
Perhaps it would be a good idea to at this point simply raise the awareness
of the need for contains() and wait for concepts, without which, as Bjarne
has also pointed out many times, it is hard to get all container algorithms
perfect. The proposed ranges are also likely to affect.


> Kind regards,
>
> Andy
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_6336_1727166162.1419617930022
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Friday, December 26, 2014 10:02:07 PM UTC+4, Andy P=
rowl wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Wh=
ile I agree with most of what has been written in the last few messages, I =
feel we are slowly diverging from the purpose of the original post, perhaps=
 unnecessarily enlarging its scope.<br></div></blockquote><div><br></div><d=
iv>Yep guys, felt the same divergence.<br></div><div>&nbsp;</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I think an algorithm li=
ke "contains()" for "containers" is such an obvious and elementary operatio=
n that it ought to be in the standard library: it is simpler, easier to tea=
ch, and easier to understand than the current "!=3D end()" idiom.<br><br></=
div></blockquote><div>&nbsp;</div><div>Exactly the point: a simple, easy-to=
-read, very-frequently-used, bool-returning contains(). If we want to recov=
er an iterator, we just use find(), don't we? (And in cases like that the c=
ode usually isn't concerned about the existence of an element in a containe=
r, but wants to do something.)</div><div>&nbsp;</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr">IMO a proposal should be written fo=
r adding this function, and keeping its scope narrow may increase its chanc=
es to get accepted.<br><div><br></div></div></blockquote><div><br></div><di=
v>Perhaps it would be a good idea to at this point simply raise the awarene=
ss of the need for contains() and wait for concepts, without which, as Bjar=
ne has also pointed out many times, it is hard to get all container algorit=
hms perfect. The proposed ranges are also likely to affect.</div><div>&nbsp=
;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>K=
ind regards,<br><br></div><div>Andy</div></div></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6336_1727166162.1419617930022--
------=_Part_6335_2115259800.1419617930022--

.

On Fri, Dec 26, 2014 at 9:40 PM, Andy Prowl <andy.prowl@gmail.com> wrote:
> To conclude, IMO what is essential to have is a standard "contains()"; other
> algorithms may be added, but I don't find it compelling.

Sounding natural sounds nice but IMO isn't a great argument.
What's the ratio of contains()'s to find()'s in your code?
In mine find() (or a wrapper of it) is far more common than contains().

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Olaf van der Spek schreef op 27-12-2014 om 01:52:
> On Fri, Dec 26, 2014 at 9:40 PM, Andy Prowl <andy.prowl@gmail.com> wrote:
>> To conclude, IMO what is essential to have is a standard "contains()"; other
>> algorithms may be added, but I don't find it compelling.
> Sounding natural sounds nice but IMO isn't a great argument.
> What's the ratio of contains()'s to find()'s in your code?
> In mine find() (or a wrapper of it) is far more common than contains().
>
I'll chip in my 2 cents here -- a call to contains() serves a different
purpose from find() et al. When verifying the current state in for
example assertions or test code I'm usually not interested in the actual
position of an element.

Also, the meaning becomes very different when considering geometric
applications (which also translate into other domains). Testing whether
a point lies inside a box is different from figuring out where it lies
inside a box.

Kind regards,
- Gijsbert dos Santos

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Le 27/12/2014 01:49, ricky.65@hotmail.com a =C3=A9crit :
> Doesn't the "any_of" algorithm serve this purpose?
> --=20
Isn't std::any_of a predicate only algorithm in the standard ? Although=20
it would make sense to fulfill the goal of a "contains" by extending=20
std::any_of, ... maybe std::any ? Oups, seems to be already conflicting=20
with a possible boost::any...
Would have been simpler if we had have std::any_of_if :-/

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Saturday 27 December 2014 01:52:21 Olaf van der Spek wrote:
> On Fri, Dec 26, 2014 at 9:40 PM, Andy Prowl <andy.prowl@gmail.com> wrote:
> > To conclude, IMO what is essential to have is a standard "contains()";
> > other algorithms may be added, but I don't find it compelling.
>
> Sounding natural sounds nice but IMO isn't a great argument.
> What's the ratio of contains()'s to find()'s in your code?
> In mine find() (or a wrapper of it) is far more common than contains().


 $ git grep -E '\.(find|constFind)\(' -- \*.cpp \*.h | wc -l
553
 $ git grep -E '\.contains\(' -- \*.cpp \*.h | wc -l
2977

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_7010_354158899.1419663091647
Content-Type: multipart/alternative;
 boundary="----=_Part_7011_1671429656.1419663091647"

------=_Part_7011_1671429656.1419663091647
Content-Type: text/plain; charset=UTF-8

On Saturday, December 27, 2014 4:52:22 AM UTC+4, Olaf van der Spek wrote:
>
> On Fri, Dec 26, 2014 at 9:40 PM, Andy Prowl <andy....@gmail.com
> <javascript:>> wrote:
> > To conclude, IMO what is essential to have is a standard "contains()";
> other
> > algorithms may be added, but I don't find it compelling.
>
> Sounding natural sounds nice but IMO isn't a great argument.
> What's the ratio of contains()'s to find()'s in your code?
> In mine find() (or a wrapper of it) is far more common than contains().
>

Well, Olaf, it's not about sounding natural. It's about the reasons behind
sounding natural (just off the top of my head):

1) The very frequent need to check if a container contains a value,
2) The fact that even the shortest *==end()*-based code doing a contains()
logic needs such unnecessary mental parsing.

In a very similar way we have a *binary_search()* that returns a bool,
although we could have very well lived if it wasn't there at all and we
used *lower_bound()* all the time. (In fact, a bool-returning *contains()*
seems to be much more needed than a bool-returning *binary_search()*.)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_7011_1671429656.1419663091647
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, December 27, 2014 4:52:22 AM UTC+4, Olaf van =
der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Dec 26,=
 2014 at 9:40 PM, Andy Prowl &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"zltJsNO9D4AJ" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return true;">andy.=
....@gmail.com</a>&gt; wrote:
<br>&gt; To conclude, IMO what is essential to have is a standard "contains=
()"; other
<br>&gt; algorithms may be added, but I don't find it compelling.
<br>
<br>Sounding natural sounds nice but IMO isn't a great argument.
<br>What's the ratio of contains()'s to find()'s in your code?
<br>In mine find() (or a wrapper of it) is far more common than contains().
<br></blockquote><div><br></div><div>Well, Olaf, it's not about sounding na=
tural. It's about the reasons behind sounding natural (just off the top of =
my head):</div><div><br></div><div>1) The very frequent need to check if a =
container contains a value,</div><div>2) The fact that even the shortest&nb=
sp;<b>=3D=3Dend()</b>-based code doing a contains() logic needs such unnece=
ssary mental parsing.</div><div><br></div><div>In a very similar way we hav=
e a <b>binary_search()</b> that returns a bool, although we could have very=
 well lived if it wasn't there at all and we used <b>lower_bound()</b> all =
the time. (In fact, a bool-returning <b>contains()</b> seems to be much mor=
e needed than a bool-returning&nbsp;<b>binary_search()</b>.)</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_7011_1671429656.1419663091647--
------=_Part_7010_354158899.1419663091647--

.

On Sat, Dec 27, 2014 at 4:10 AM, Thiago Macieira <thiago@macieira.org> wrote:
> On Saturday 27 December 2014 01:52:21 Olaf van der Spek wrote:
>> On Fri, Dec 26, 2014 at 9:40 PM, Andy Prowl <andy.prowl@gmail.com> wrote:
>> > To conclude, IMO what is essential to have is a standard "contains()";
>> > other algorithms may be added, but I don't find it compelling.
>>
>> Sounding natural sounds nice but IMO isn't a great argument.
>> What's the ratio of contains()'s to find()'s in your code?
>> In mine find() (or a wrapper of it) is far more common than contains().
>
>
>  $ git grep -E '\.(find|constFind)\(' -- \*.cpp \*.h | wc -l
> 553
>  $ git grep -E '\.contains\(' -- \*.cpp \*.h | wc -l
> 2977

Interesting. Is this a public code base? I'd love to have a look at the usage.


--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Saturday 27 December 2014 11:39:38 Olaf van der Spek wrote:
> On Sat, Dec 27, 2014 at 4:10 AM, Thiago Macieira <thiago@macieira.org>
wrote:
> > On Saturday 27 December 2014 01:52:21 Olaf van der Spek wrote:
> >> On Fri, Dec 26, 2014 at 9:40 PM, Andy Prowl <andy.prowl@gmail.com> wrote:
> >> > To conclude, IMO what is essential to have is a standard "contains()";
> >> > other algorithms may be added, but I don't find it compelling.
> >>
> >> Sounding natural sounds nice but IMO isn't a great argument.
> >> What's the ratio of contains()'s to find()'s in your code?
> >> In mine find() (or a wrapper of it) is far more common than contains().
> >>
> >  $ git grep -E '\.(find|constFind)\(' -- \*.cpp \*.h | wc -l
> >
> > 553
> >
> >  $ git grep -E '\.contains\(' -- \*.cpp \*.h | wc -l
> >
> > 2977
>
> Interesting. Is this a public code base? I'd love to have a look at the
> usage.

Sure.

https://qt.gitorious.org/qt/qtbase/source/5.4:

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_108_1367063518.1419695643123
Content-Type: multipart/alternative;
 boundary="----=_Part_109_309007773.1419695643123"

------=_Part_109_309007773.1419695643123
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, December 27, 2014 1:55:10 AM UTC, Germinolegrand wrote:
>
> Le 27/12/2014 01:49, rick...@hotmail.com <javascript:> a =C3=A9crit :=20
> > Doesn't the "any_of" algorithm serve this purpose?=20
> > --=20
> Isn't std::any_of a predicate only algorithm in the standard ? Although=
=20
> it would make sense to fulfill the goal of a "contains" by extending=20
> std::any_of, ... maybe std::any ? Oups, seems to be already conflicting=
=20
> with a possible boost::any...=20
> Would have been simpler if we had have std::any_of_if :-/=20
>

Yes, std::any_of just takes a predicate. I agree that it would be very=20
useful if there were a version which accepts a value instead of a predicate=
=20
(the same applies for std::all_of and std::none_of).=20

As you said, it does appear that there would be an unfortunate name clash=
=20
with the proposed boost::any if a "value" version called std::any were=20
provided.

Short of inventing a time machine I don't think it would be feasible to=20
rename std::any_of to std::any_of_if!

With Concepts Lite it should be possible to have a "value" overload as we=
=20
can overload on concepts. For example, something like the following:

template<InputIterator I, Predicate<ValueType<I>> P>
bool any_of(I first, I last, P pred);

template<InputIterator I, EqualityComparable<ValueType<I>> T>
bool any_of(I first, I last, const T& value);

This would be my favoured option.

Riccardo

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_109_309007773.1419695643123
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, December 27, 2014 1:55:10 AM UTC, Germinolegr=
and wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le 27/12/2014 01:49,=
 <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"xx2HIz8=
e5cEJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"th=
is.href=3D'javascript:';return true;">rick...@hotmail.com</a> a =C3=A9crit =
:
<br>&gt; Doesn't the "any_of" algorithm serve this purpose?
<br>&gt; --=20
<br>Isn't std::any_of a predicate only algorithm in the standard ? Although=
=20
<br>it would make sense to fulfill the goal of a "contains" by extending=20
<br>std::any_of, ... maybe std::any ? Oups, seems to be already conflicting=
=20
<br>with a possible boost::any...
<br>Would have been simpler if we had have std::any_of_if :-/
<br></blockquote><div><br></div><div>Yes, std::any_of just takes a predicat=
e. I agree that it would be very useful if there were a version which accep=
ts a value instead of a predicate (the same applies for std::all_of and std=
::none_of).&nbsp;</div><div><br></div><div>As you said, it does appear that=
 there would be an unfortunate name clash with the proposed boost::any if a=
 "value" version called std::any were provided.</div><div><br></div><div>Sh=
ort of inventing a time machine I don't think it would be feasible to renam=
e std::any_of to std::any_of_if!</div><div><br></div><div>With Concepts Lit=
e it should be possible to have a "value" overload as we can overload on co=
ncepts. For example, something like the following:</div><div><br></div><div=
><div>template&lt;InputIterator I, Predicate&lt;ValueType&lt;I&gt;&gt; P&gt=
;</div><div>bool any_of(I first, I last, P pred);</div></div><div><br></div=
><div><div>template&lt;InputIterator I, EqualityComparable&lt;ValueType&lt;=
I&gt;&gt; T&gt;</div><div>bool&nbsp;any_of(I first, I last, const T&amp; va=
lue);</div></div><div><br></div><div>This would be my favoured option.</div=
><div><br></div><div>Riccardo</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_109_309007773.1419695643123--
------=_Part_108_1367063518.1419695643123--

.

------=_Part_5714_1985068290.1419698543850
Content-Type: multipart/alternative;
 boundary="----=_Part_5715_1884293885.1419698543851"

------=_Part_5715_1884293885.1419698543851
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, December 27, 2014 7:54:03 PM UTC+4, rick...@hotmail.com wrote:
>
> On Saturday, December 27, 2014 1:55:10 AM UTC, Germinolegrand wrote:
>>
>> Le 27/12/2014 01:49, rick...@hotmail.com a =C3=A9crit :=20
>> > Doesn't the "any_of" algorithm serve this purpose?=20
>> > --=20
>> Isn't std::any_of a predicate only algorithm in the standard ? Although=
=20
>> it would make sense to fulfill the goal of a "contains" by extending=20
>> std::any_of, ... maybe std::any ? Oups, seems to be already conflicting=
=20
>> with a possible boost::any...=20
>> Would have been simpler if we had have std::any_of_if :-/=20
>>
>
> Yes, std::any_of just takes a predicate. I agree that it would be very=20
> useful if there were a version which accepts a value instead of a predica=
te=20
> (the same applies for std::all_of and std::none_of).=20
>
> As you said, it does appear that there would be an unfortunate name clash=
=20
> with the proposed boost::any if a "value" version called std::any were=20
> provided.
>
> Short of inventing a time machine I don't think it would be feasible to=
=20
> rename std::any_of to std::any_of_if!
>
> With Concepts Lite it should be possible to have a "value" overload as we=
=20
> can overload on concepts. For example, something like the following:
>
> template<InputIterator I, Predicate<ValueType<I>> P>
> bool any_of(I first, I last, P pred);
>
> template<InputIterator I, EqualityComparable<ValueType<I>> T>
> bool any_of(I first, I last, const T& value);
>
> This would be my favoured option.
>

As, in a way, a generalized version of *contains()*, IMO *any_of(Iter,=20
Iter, const T&)* would certainly be another very useful addition. But I'd=
=20
really like to suggest that for containers, having *contains()* functionali=
ty=20
in any way that doesn't at the end of the day allow us to write=20
*phone_book.contains(number)* doesn't give us the syntax that, IMVHO,=20
nothing really prevents us from having.

I'm not an expert on this at all, but it seems like *contains()* could=20
perhaps even be implemented in terms of *any_of(Iter, Iter, const T&)*. The=
=20
way I see it, it'll all be inlined anyway, so it would do a lot of good to=
=20
simply have a standard name for doing one of the most used and useful=20
actions on containers.
=20

>
> Riccardo
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_5715_1884293885.1419698543851
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, December 27, 2014 7:54:03 PM UTC+4, rick...@h=
otmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Saturday, December 27, 2014 1:55:10 AM UTC, Germinolegrand wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">Le 27/12/2014 01:49, <a>rick...@hotmai=
l.com</a> a =C3=A9crit :
<br>&gt; Doesn't the "any_of" algorithm serve this purpose?
<br>&gt; --=20
<br>Isn't std::any_of a predicate only algorithm in the standard ? Although=
=20
<br>it would make sense to fulfill the goal of a "contains" by extending=20
<br>std::any_of, ... maybe std::any ? Oups, seems to be already conflicting=
=20
<br>with a possible boost::any...
<br>Would have been simpler if we had have std::any_of_if :-/
<br></blockquote><div><br></div><div>Yes, std::any_of just takes a predicat=
e. I agree that it would be very useful if there were a version which accep=
ts a value instead of a predicate (the same applies for std::all_of and std=
::none_of).&nbsp;</div><div><br></div><div>As you said, it does appear that=
 there would be an unfortunate name clash with the proposed boost::any if a=
 "value" version called std::any were provided.</div><div><br></div><div>Sh=
ort of inventing a time machine I don't think it would be feasible to renam=
e std::any_of to std::any_of_if!</div><div><br></div><div>With Concepts Lit=
e it should be possible to have a "value" overload as we can overload on co=
ncepts. For example, something like the following:</div><div><br></div><div=
><div>template&lt;InputIterator I, Predicate&lt;ValueType&lt;I&gt;&gt; P&gt=
;</div><div>bool any_of(I first, I last, P pred);</div></div><div><br></div=
><div><div>template&lt;InputIterator I, EqualityComparable&lt;ValueType&lt;=
<wbr>I&gt;&gt; T&gt;</div><div>bool&nbsp;any_of(I first, I last, const T&am=
p; value);</div></div><div><br></div><div>This would be my favoured option.=
</div></div></blockquote><div><br></div><div>As, in a way, a generalized ve=
rsion of <b>contains()</b>, IMO&nbsp;<b>any_of(Iter, Iter, const T&amp;)</b=
>&nbsp;would certainly be another very useful addition. But I'd really like=
 to suggest that for containers, having <b>contains()</b>&nbsp;functionalit=
y in any way that doesn't at the end of the day allow us to write <b>phone_=
book.contains(number)</b> doesn't give us the syntax that, IMVHO, nothing r=
eally prevents us from having.</div><div><br></div><div>I'm not an expert o=
n this at all, but it seems like <b>contains()</b> could perhaps even be im=
plemented in terms of&nbsp;<b>any_of(Iter, Iter, const T&amp;)</b>. The way=
 I see it, it'll all be inlined anyway, so it would do a lot of good to sim=
ply have a standard name for doing one of the most used and useful actions =
on containers.</div><div>&nbsp;<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div><br></div><div>Riccardo</div></div></block=
quote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5715_1884293885.1419698543851--
------=_Part_5714_1985068290.1419698543850--

.

On Monday 29 December 2014 12:12:07 Matthew Woehlke wrote:
> Yes, but in Qt (at least, with applications I've written with Qt
> containers), it's common to have code like:
>
>   if (container.contains(key))
>     ... container[key] ...
>
> ...which would be more efficiently accomplished like:
>
>   if (auto&& iter = container.find(key))
>     ... iter.value() ...
>
> IOW, use contains() to see if the value exists, and then one of value(),
> at(), operator[](), etc. to *look up the value a second time* and then
> do something with it. Whereas find() is normally used only when one
> explicitly needs the iterator (which, in fact, with Qt containers, I
> wonder why you ever really need to use find()...).

I agree that it would be better, but I can't confirm that it's common.

Random sampling of those 3k matches shows very few of those. For example, I
found:

    if (d->intHash.contains(sender))
        emit mapped(d->intHash.value(sender));
    if (d->stringHash.contains(sender))
        emit mapped(d->stringHash.value(sender));
    if (d->widgetHash.contains(sender))
        emit mapped(d->widgetHash.value(sender));
    if (d->objectHash.contains(sender))
        emit mapped(d->objectHash.value(sender));

Which is indeed bad, but those are far from the common case.

Another case I've found is the checking if an element is present in a
container before inserting it. That indicates we need a new method to "insert
if not present" and the find method would not have helped.

> It would therefore be interesting to know how many of those contains()
> instances are followed by a second look-up of on the key.

Very few.

> That said, I suspect the above numbers are skewed, since find() occurs
> in other contexts (QString::find(), QWidget::find(), etc.) that aren't
> container searches, i.e. the "true" number is actually lower. (That
> said, there are also QRect::contains(), etc. which throw off the other
> number as well.)

QString is a container, so it's a valid match. It's not easy to do a full
match due to -fvisibility-inlines-hidden.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Mon, Dec 29, 2014 at 6:37 PM, Thiago Macieira <thiago@macieira.org> wrote:
> I agree that it would be better, but I can't confirm that it's common.
>
> Random sampling of those 3k matches shows very few of those. For example, I
> found:
>
>     if (d->intHash.contains(sender))
>         emit mapped(d->intHash.value(sender));
>     if (d->stringHash.contains(sender))
>         emit mapped(d->stringHash.value(sender));
>     if (d->widgetHash.contains(sender))
>         emit mapped(d->widgetHash.value(sender));
>     if (d->objectHash.contains(sender))
>         emit mapped(d->objectHash.value(sender));
>
> Which is indeed bad, but those are far from the common case.

Are you a QT dev? If so, could you file issues to improve these?

I also found this:
                if (symbolStates.contains(transition.value())) {
                    const QString symbol = states.at(transition.value()).symbol;
                    symbolReferenceCounts[symbol]++;
                } else if (epsilonStates.contains(transition.value())) {
                    const QString symbol =
epsilonStates.value(transition.value());
                    symbolReferenceCounts[symbol]++;

Now I'm wondering whether the second line correctly uses states or
whether it should use symbolStates

It might not be the majority case, but it occurs frequently.
The code does contain an awful lof of contains() though.

> Another case I've found is the checking if an element is present in a
> container before inserting it. That indicates we need a new method to "insert
> if not present" and the find method would not have helped.

The find method can easily be used as a contains method. How would it
not have helped?

>> That said, I suspect the above numbers are skewed, since find() occurs
>> in other contexts (QString::find(), QWidget::find(), etc.) that aren't
>> container searches, i.e. the "true" number is actually lower. (That
>> said, there are also QRect::contains(), etc. which throw off the other
>> number as well.)
>
> QString is a container, so it's a valid match. It's not easy to do a full
> match due to -fvisibility-inlines-hidden.

But it's not the traditional one-element find, would it work with a
generic contains?


--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Mon, Dec 29, 2014 at 8:17 PM, Leo Heinsaar <leoheinsaar@gmail.com> wrote:
>> I can't think what behavior would be introduced that would be
>> surprising; can you please elaborate?
>
>
> On a general note: once we convert something to bool, there is no stopping
> it from interacting with other fundamental types from short to double. Just
> seems that for iterators, that might introduce unnecessary type-safety bugs.

That's why we've got explicit operator bool.




--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_632_571036662.1419881670535
Content-Type: multipart/alternative;
 boundary="----=_Part_633_308759791.1419881670535"

------=_Part_633_308759791.1419881670535
Content-Type: text/plain; charset=UTF-8



On Monday, December 29, 2014 11:26:52 PM UTC+4, Olaf van der Spek wrote:
>
> On Mon, Dec 29, 2014 at 8:17 PM, Leo Heinsaar <leohe...@gmail.com
> <javascript:>> wrote:
> >> I can't think what behavior would be introduced that would be
> >> surprising; can you please elaborate?
> >
> >
> > On a general note: once we convert something to bool, there is no
> stopping
> > it from interacting with other fundamental types from short to double.
> Just
> > seems that for iterators, that might introduce unnecessary type-safety
> bugs.
>
> That's why we've got explicit operator bool.


Well, originally, at least, Matthew wrote: "Maybe we could instead create a
form of ::find() that returns an optional<iterator> or checked_iterator or
similar, that can be *implicitly* cast to bool to test for validity."

But even if it is made explicit, seems like it becomes too verbose to write
*static_cast<bool>*.

Leo

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_633_308759791.1419881670535
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, December 29, 2014 11:26:52 PM UTC+4, Ol=
af van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Mon, =
Dec 29, 2014 at 8:17 PM, Leo Heinsaar &lt;<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"J7tktPO0joEJ" onmousedown=3D"this.href=3D=
'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return tru=
e;">leohe...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; I can't think what behavior would be introduced that would be
<br>&gt;&gt; surprising; can you please elaborate?
<br>&gt;
<br>&gt;
<br>&gt; On a general note: once we convert something to bool, there is no =
stopping
<br>&gt; it from interacting with other fundamental types from short to dou=
ble. Just
<br>&gt; seems that for iterators, that might introduce unnecessary type-sa=
fety bugs.
<br>
<br>That's why we've got explicit operator bool.
</blockquote><div>&nbsp;</div><div>Well, originally, at least, Matthew wrot=
e: "Maybe we could instead create a form of ::find() that returns=20
an optional&lt;iterator&gt; or checked_iterator or similar, that can=20
be <b>implicitly</b> cast to bool to test for validity."</div><div><br></di=
v><div>But even if it is made explicit, seems like it becomes too verbose t=
o write&nbsp;<b>static_cast&lt;bool&gt;</b>.</div><div><br></div><div>Leo</=
div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_633_308759791.1419881670535--
------=_Part_632_571036662.1419881670535--

.

On Mon, Dec 29, 2014 at 8:34 PM, Leo Heinsaar <leoheinsaar@gmail.com> wrote:
>
>
> On Monday, December 29, 2014 11:26:52 PM UTC+4, Olaf van der Spek wrote:
>>
>> On Mon, Dec 29, 2014 at 8:17 PM, Leo Heinsaar <leohe...@gmail.com> wrote:
>> >> I can't think what behavior would be introduced that would be
>> >> surprising; can you please elaborate?
>> >
>> >
>> > On a general note: once we convert something to bool, there is no
>> > stopping
>> > it from interacting with other fundamental types from short to double.
>> > Just
>> > seems that for iterators, that might introduce unnecessary type-safety
>> > bugs.
>>
>> That's why we've got explicit operator bool.
>
>
> Well, originally, at least, Matthew wrote: "Maybe we could instead create a
> form of ::find() that returns an optional<iterator> or checked_iterator or
> similar, that can be implicitly cast to bool to test for validity."
>
> But even if it is made explicit, seems like it becomes too verbose to write
> static_cast<bool>.

Not necessary as if (v) and some other constructs count as explicit
conversions already...


--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 29 December 2014 at 21:34, Leo Heinsaar <leoheinsaar@gmail.com> wrote:
>> > On a general note: once we convert something to bool, there is no
>> > stopping
>> > it from interacting with other fundamental types from short to double.
>> > Just
>> > seems that for iterators, that might introduce unnecessary type-safety
>> > bugs.
>>
>> That's why we've got explicit operator bool.
> Well, originally, at least, Matthew wrote: "Maybe we could instead create a
> form of ::find() that returns an optional<iterator> or checked_iterator or
> similar, that can be implicitly cast to bool to test for validity."
> But even if it is made explicit, seems like it becomes too verbose to write
> static_cast<bool>.


You don't need a static_cast to use an explicit operator bool in eg.
if statements.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_656_1242337957.1419882008146
Content-Type: multipart/alternative;
 boundary="----=_Part_657_2138027165.1419882008146"

------=_Part_657_2138027165.1419882008146
Content-Type: text/plain; charset=UTF-8

On Monday, December 29, 2014 11:36:13 PM UTC+4, Ville Voutilainen wrote:
>
> On 29 December 2014 at 21:34, Leo Heinsaar <leohe...@gmail.com
> <javascript:>> wrote:
> >> > On a general note: once we convert something to bool, there is no
> >> > stopping
> >> > it from interacting with other fundamental types from short to
> double.
> >> > Just
> >> > seems that for iterators, that might introduce unnecessary
> type-safety
> >> > bugs.
> >>
> >> That's why we've got explicit operator bool.
> > Well, originally, at least, Matthew wrote: "Maybe we could instead
> create a
> > form of ::find() that returns an optional<iterator> or checked_iterator
> or
> > similar, that can be implicitly cast to bool to test for validity."
> > But even if it is made explicit, seems like it becomes too verbose to
> write
> > static_cast<bool>.
>
>
> You don't need a static_cast to use an explicit operator bool in eg.
> if statements.
>
....

> Not necessary as if (v) and some other constructs count as explicit
> conversions already...


Oh ok, didn't know that. Good point then - thanks.

Leo


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_657_2138027165.1419882008146
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, December 29, 2014 11:36:13 PM UTC+4, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 29 December 2=
014 at 21:34, Leo Heinsaar &lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"sCJTpTziDPIJ" onmousedown=3D"this.href=3D'javascript=
:';return true;" onclick=3D"this.href=3D'javascript:';return true;">leohe..=
..@gmail.com</a>&gt; wrote:
<br>&gt;&gt; &gt; On a general note: once we convert something to bool, the=
re is no
<br>&gt;&gt; &gt; stopping
<br>&gt;&gt; &gt; it from interacting with other fundamental types from sho=
rt to double.
<br>&gt;&gt; &gt; Just
<br>&gt;&gt; &gt; seems that for iterators, that might introduce unnecessar=
y type-safety
<br>&gt;&gt; &gt; bugs.
<br>&gt;&gt;
<br>&gt;&gt; That's why we've got explicit operator bool.
<br>&gt; Well, originally, at least, Matthew wrote: "Maybe we could instead=
 create a
<br>&gt; form of ::find() that returns an optional&lt;iterator&gt; or check=
ed_iterator or
<br>&gt; similar, that can be implicitly cast to bool to test for validity.=
"
<br>&gt; But even if it is made explicit, seems like it becomes too verbose=
 to write
<br>&gt; static_cast&lt;bool&gt;.
<br>
<br>
<br>You don't need a static_cast to use an explicit operator bool in eg.
<br>if statements.
<br></blockquote><div>...</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(20=
4, 204, 204); border-left-style: solid; padding-left: 1ex;">Not necessary a=
s if (v) and some other constructs count as explicit&nbsp;<br>conversions a=
lready...&nbsp;</blockquote><div><br></div><div>Oh ok, didn't know that. Go=
od point then - thanks.</div><div><br></div><div>Leo</div><div>&nbsp;</div>=
</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_657_2138027165.1419882008146--
------=_Part_656_1242337957.1419882008146--

.

On Monday 29 December 2014 19:17:49 Olaf van der Spek wrote:
> Are you a QT dev? If so, could you file issues to improve these?

Yes.

> > Another case I've found is the checking if an element is present in a
> > container before inserting it. That indicates we need a new method to
> > "insert
> > if not present" and the find method would not have helped.
>
> The find method can easily be used as a contains method. How would it
> not have helped?

Because the pattern is:

 if (!container.contains(x))
  container.insert(x, value);

Using find wouldn't help since it would still require two lookups (once for
searching, once for inserting).

> > QString is a container, so it's a valid match. It's not easy to do a full
> > match due to -fvisibility-inlines-hidden.
>
> But it's not the traditional one-element find, would it work with a
> generic contains?

It has a contains(QChar), in spite of having other ones.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a113ee6f80d06d8050b665910
Content-Type: text/plain; charset=UTF-8

> Because the pattern is:
>
>         if (!container.contains(x))
>                 container.insert(x, value);

Shouldn't it be implemented like below? A little bit verbose but prevents
from second lookup.

auto it = lower_bound(container.begin(), container.end(), value);
if (it == container.end() || *it != value)
    container.insert(it, value);



On Tue, Dec 30, 2014 at 9:42 AM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Monday 29 December 2014 19:17:49 Olaf van der Spek wrote:
> > Are you a QT dev? If so, could you file issues to improve these?
>
> Yes.
>
> > > Another case I've found is the checking if an element is present in a
> > > container before inserting it. That indicates we need a new method to
> > > "insert
> > > if not present" and the find method would not have helped.
> >
> > The find method can easily be used as a contains method. How would it
> > not have helped?
>
> Because the pattern is:
>
>         if (!container.contains(x))
>                 container.insert(x, value);
>
> Using find wouldn't help since it would still require two lookups (once for
> searching, once for inserting).
>
> > > QString is a container, so it's a valid match. It's not easy to do a
> full
> > > match due to -fvisibility-inlines-hidden.
> >
> > But it's not the traditional one-element find, would it work with a
> > generic contains?
>
> It has a contains(QChar), in spite of having other ones.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113ee6f80d06d8050b665910
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"font-size:13px">&gt; Because the pattern is=
:</span><br style=3D"font-size:13px">&gt;=C2=A0<br style=3D"font-size:13px"=
><span style=3D"font-size:13px">&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!conta=
iner.contains(x))</span><br style=3D"font-size:13px"><span style=3D"font-si=
ze:13px">&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conta=
iner.insert(x, value);</span><div><br></div><div>Shouldn&#39;t it be implem=
ented like below? A little bit verbose but prevents from second lookup.</di=
v><div><br></div><div><div>auto it =3D lower_bound(<span style=3D"font-size=
:13px">container</span>.begin(),=C2=A0<span style=3D"font-size:13px">contai=
ner</span>.end(),=C2=A0<span style=3D"font-size:13px">value</span>);</div><=
div>if (it =3D=3D=C2=A0<span style=3D"font-size:13px">container</span>.end(=
) || *it !=3D=C2=A0<span style=3D"font-size:13px">value</span>)<br></div><d=
iv>=C2=A0 =C2=A0=C2=A0<span style=3D"font-size:13px">container</span>.inser=
t(it,=C2=A0<span style=3D"font-size:13px">value</span>);<br></div><div><br>=
</div><br style=3D"font-size:13px"></div></div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">On Tue, Dec 30, 2014 at 9:42 AM, Thiago Macie=
ira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"=
_blank">thiago@macieira.org</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><span class=3D"">On Monday 29 December 2014 19:17:49 Olaf van der =
Spek wrote:<br>
&gt; Are you a QT dev? If so, could you file issues to improve these?<br>
<br>
</span>Yes.<br>
<span class=3D""><br>
&gt; &gt; Another case I&#39;ve found is the checking if an element is pres=
ent in a<br>
&gt; &gt; container before inserting it. That indicates we need a new metho=
d to<br>
&gt; &gt; &quot;insert<br>
&gt; &gt; if not present&quot; and the find method would not have helped.<b=
r>
&gt;<br>
&gt; The find method can easily be used as a contains method. How would it<=
br>
&gt; not have helped?<br>
<br>
</span>Because the pattern is:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!container.contains(x))<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container.insert(x,=
 value);<br>
<br>
Using find wouldn&#39;t help since it would still require two lookups (once=
 for<br>
searching, once for inserting).<br>
<span class=3D""><br>
&gt; &gt; QString is a container, so it&#39;s a valid match. It&#39;s not e=
asy to do a full<br>
&gt; &gt; match due to -fvisibility-inlines-hidden.<br>
&gt;<br>
&gt; But it&#39;s not the traditional one-element find, would it work with =
a<br>
&gt; generic contains?<br>
<br>
</span>It has a contains(QChar), in spite of having other ones.<br>
<span class=3D"im HOEnZb"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
<br>
</span><div class=3D"HOEnZb"><div class=3D"h5">--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113ee6f80d06d8050b665910--

.

On Tuesday 30 December 2014 11:11:31 Reza Jahanbakhshi wrote:
> > Because the pattern is:
> >         if (!container.contains(x))
> >
> >                 container.insert(x, value);
>
> Shouldn't it be implemented like below? A little bit verbose but prevents
> from second lookup.
>
> auto it = lower_bound(container.begin(), container.end(), value);
> if (it == container.end() || *it != value)
>     container.insert(it, value);

You're doing this for a sequential container in sorted order. That will not
apply to a sequential container with appending at the end nor will it work for
an associative container. Think of a hashing table.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a1134af1ad3f8e1050b67d0d3
Content-Type: text/plain; charset=UTF-8

>> auto it = lower_bound(container.begin(), container.end(), value);
>> if (it == container.end() || *it != value)
>>     container.insert(it, value);
> You're doing this for a sequential container in sorted order. That will
not
> apply to a sequential container with appending at the end nor will it
work for
> an associative container. Think of a hashing table.

The only requirement is that the iterator range should be sorted. For
sorted sequential containers like vector, it works even when appending at
the end. And for unsorted sequential containers the question is whether it
is correct to use them this way or not. I mean with regarding to efficiency.
It works for associative containers (map, set) too and I think it's quite
efficient. For unordered containers I don't see any use to provide the hint
for insert operation but the insert method supports the interface. So using
the above method also works for unordered containers and at least the first
part, checking if element already exists is usable.
Please note that because std::pair doesn't have an equality check operator
the above code should be tweaked to be used for map and unrodered_map but
the general idea still applies.

On Tue, Dec 30, 2014 at 12:06 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Tuesday 30 December 2014 11:11:31 Reza Jahanbakhshi wrote:
> > > Because the pattern is:
> > >         if (!container.contains(x))
> > >
> > >                 container.insert(x, value);
> >
> > Shouldn't it be implemented like below? A little bit verbose but prevents
> > from second lookup.
> >
> > auto it = lower_bound(container.begin(), container.end(), value);
> > if (it == container.end() || *it != value)
> >     container.insert(it, value);
>
> You're doing this for a sequential container in sorted order. That will not
> apply to a sequential container with appending at the end nor will it work
> for
> an associative container. Think of a hashing table.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1134af1ad3f8e1050b67d0d3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"color:rgb(80,0,80);font-size:13px">&gt;&gt;=
 auto it =3D lower_bound(container.begin(), container.end(), value);</span>=
<br style=3D"color:rgb(80,0,80);font-size:13px"><span style=3D"color:rgb(80=
,0,80);font-size:13px">&gt;&gt; if (it =3D=3D container.end() || *it !=3D v=
alue)</span><br style=3D"color:rgb(80,0,80);font-size:13px"><span style=3D"=
color:rgb(80,0,80);font-size:13px">&gt;&gt;=C2=A0 =C2=A0 =C2=A0container.in=
sert(it, value);</span><br style=3D"color:rgb(80,0,80);font-size:13px"><div=
><span style=3D"font-size:13px">&gt; You&#39;re doing this for a sequential=
 container in sorted order. That will not</span><br style=3D"font-size:13px=
"><span style=3D"font-size:13px">&gt; apply to a sequential container with =
appending at the end nor will it work for</span><br style=3D"font-size:13px=
"><span style=3D"font-size:13px">&gt; an associative container. Think of a =
hashing table.</span><br></div><div><span style=3D"font-size:13px"><br></sp=
an></div>The only requirement is that the iterator range should be sorted. =
For sorted sequential containers like vector, it works even when appending =
at the end. And for unsorted sequential containers the question is whether =
it is correct to use them this way or not. I mean with regarding to efficie=
ncy.<div>It works for associative containers (map, set) too and I think it&=
#39;s quite efficient. For unordered containers I don&#39;t see any use to =
provide the hint for insert operation but the insert method supports the in=
terface. So using the above method also works for unordered containers and =
at least the first part, checking if element already exists is usable.</div=
><div>Please note that because std::pair doesn&#39;t have an equality check=
 operator the above code should be tweaked to be used for map and unrodered=
_map but the general idea still applies.=C2=A0</div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Tue, Dec 30, 2014 at 12:06 PM, =
Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org=
" target=3D"_blank">thiago@macieira.org</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><span class=3D"">On Tuesday 30 December 2014 11:11:31 =
Reza Jahanbakhshi wrote:<br>
&gt; &gt; Because the pattern is:<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!container.contains(x))<br>
&gt; &gt;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cont=
ainer.insert(x, value);<br>
&gt;<br>
&gt; Shouldn&#39;t it be implemented like below? A little bit verbose but p=
revents<br>
&gt; from second lookup.<br>
&gt;<br>
&gt; auto it =3D lower_bound(container.begin(), container.end(), value);<br=
>
&gt; if (it =3D=3D container.end() || *it !=3D value)<br>
&gt;=C2=A0 =C2=A0 =C2=A0container.insert(it, value);<br>
<br>
</span>You&#39;re doing this for a sequential container in sorted order. Th=
at will not<br>
apply to a sequential container with appending at the end nor will it work =
for<br>
an associative container. Think of a hashing table.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1134af1ad3f8e1050b67d0d3--

.

--089e01293ff814d877050b734196
Content-Type: text/plain; charset=UTF-8

On 30 December 2014 at 11:28, Andy Prowl <andy.prowl@gmail.com> wrote:

> On Tuesday, December 30, 2014 5:30:44 PM UTC+1, Matthew Woehlke wrote:
>>
>>
>> ...which reminds me, std::map requiring the user to use std::pair is
>> another thing I hate about STL containers :-). IMO Qt got this right;
>> the insert method takes two parameters, i.e. the key and the value.
>>
>> (Is there any reason we couldn't add this as an overload?)
>
>
> Doesn't emplace() do just that?
>

Shhhh; it is much more fun watching people argue for a feature they claim
(a) they absolutely have to have (b) which the standard already has and (c)
they obviously never use.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e01293ff814d877050b734196
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 30 December 2014 at 11:28, Andy Prowl <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:andy.prowl@gmail.com" target=3D"_blank">andy.prowl@g=
mail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D=
"">On Tuesday, December 30, 2014 5:30:44 PM UTC+1, Matthew Woehlke wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><br>...which reminds me, std::map req=
uiring the user to use std::pair is
<br>another thing I hate about STL containers :-). IMO Qt got this right;
<br>the insert method takes two parameters, i.e. the key and the value.
<br>
<br>(Is there any reason we couldn&#39;t add this as an overload?)
</blockquote><div><br></div></span><div><span style=3D"font-size:13px">Does=
n&#39;t emplace() do just that?<br></span></div></div></blockquote><div><br=
></div><div>Shhhh; it is much more fun watching people argue for a feature =
they claim (a) they absolutely have to have (b) which the standard already =
has and (c) they obviously never use.</div></div>-- <br><div class=3D"gmail=
_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01293ff814d877050b734196--

.

On 30 December 2014 at 20:34, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 30 December 2014 at 11:28, Andy Prowl <andy.prowl@gmail.com> wrote:
>>
>> On Tuesday, December 30, 2014 5:30:44 PM UTC+1, Matthew Woehlke wrote:
>>>
>>>
>>> ...which reminds me, std::map requiring the user to use std::pair is
>>> another thing I hate about STL containers :-). IMO Qt got this right;
>>> the insert method takes two parameters, i.e. the key and the value.
>>>
>>> (Is there any reason we couldn't add this as an overload?)
>>
>>
>> Doesn't emplace() do just that?
>
>
> Shhhh; it is much more fun watching people argue for a feature they claim
> (a) they absolutely have to have (b) which the standard already has and (c)
> they obviously never use.


That may be fun in a theatrical sense, but I tend to find it more
satisfactory to
disseminate information rather than disinformation, and I am a big fan of
educating programmers to use the standard library correctly. :)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 12/30/2014 02:42 AM, Thiago Macieira wrote:

> Because the pattern is:
>
>  if (!container.contains(x))
>   container.insert(x, value);

Both ordered and unordered map insert() checks if the key already
exists, so you can just use:

   container.insert(x, value);

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

If we wanted more than just a boolean, 'contains' would be confusing.
Keep it as a simple predicate, please.

On 1/1/15, Leo Heinsaar <leoheinsaar@gmail.com> wrote:
>
>
> On Thursday, January 1, 2015 10:06:23 PM UTC+4, Andy Prowl wrote:
>>
>> On Thursday, January 1, 2015 6:19:21 PM UTC+1, Matthew Woehlke wrote:
>>>
>>> On 2015-01-01 05:55, Andy Prowl wrote:
>>
>> ...
>
>>  What I do think is objective is that this code:
>>>
>>
>> if (contains(c, elem))
>> {
>>     // ...
>> }
>>
>> Is more intent-revealing than this code:
>>
>> if (find(c, elem))
>> {
>>     // ...
>> }
>>
>> There is hardly any name which is more intent-revealing than "contains"
>> when it comes to containment of containers. I think this is a fundamenta=
l
>>
>> operation that deserves being a standard algorithm. It could even be
>> written in terms of a find() algorithm returning a checked iterator, if
>> checked iterators turn out to be a really good idea: I wouldn't mind. Wh=
at
>>
>> I think is not a good idea is to throw away "contains()" because it can =
be
>>
>> generalized by a revised "find()".
>>
>
> I couldn't resist emphasizing (again) that I couldn't agree more.
>
> To try to visualize this point, I'd like to say that, to me, not being ab=
le
>
> to have the simplest form of *contains() *for containers is like not havi=
ng
>
> the "=E2=88=88" or "=E2=8A=82" symbols in math =E2=80=93 a simple and fas=
t way of expressing
> "containment" and "inclusion" =E2=80=93 IMO it's as fundamental as these =
two simple
>
> symbols because *contains()* would reveal the intent in exactly the same
> easy way as "=E2=88=88" does (*x =E2=88=88 X* for a concrete set X is lik=
e saying
> *X.contains(x)*). After all, we do have *includes() *standardized, which
> one can view as the equivalent of "=E2=8A=82".
>
> Leo
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Sat, Jan 3, 2015 at 3:55 PM, Andy Prowl <andy.prowl@gmail.com> wrote:
> Single Responsibility Principle. As I mentioned, I'm aware this is a
> subjective argument :)

It has a lot of objective aspects though.

>> Pointers can be used instead of 'checked' iterators. Pointers surely have
>> no performance or memory overhead. ;)
>> Obviously you lose the iterator but that's the same for contains().
>
>
> Yes, but contains() is explicitly mean for those cases where the iterator
> doesn't matter. I don't think the same can be said of find().

I think it can, especially with maps. See my find_ptr wrapper.

>> AFAIK the return type of binary_search was a mistake.
>
>
> OK, didn't know that. Can you provide some more background on this?

No, sorry, but a quick search turns up lots of questions why it
doesn't return an iterator.

>> IMO a variant taking a range makes sense with or without range proposal.
>
>
> Probably yes, although I'm afraid it would still be inconvenient enough (due
> to the begin()/end() noise) for users to opt for a custom wrapper, which
> would defeat the purpose.

I don't understand, a variant taking a range/container would NOT
require you to write begin() and end().

Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.