Topic: Additional modifications of search methods of
Author: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Sat, 1 Nov 2014 03:20:18 -0700 (PDT)
Raw View
------=_Part_326_902916447.1414837218470
Content-Type: text/plain; charset=UTF-8
At present for example std::map has search methods that have only one
parameter of type const key_type&
In this case the searching starts from the iterator returned by member
function begin.
I would like to suggest modifications of these methods by adding second
parameter that sets the start pos in the container.
For example
iterator lower_bound(const key_type& x, const_iterator pos );
--
---
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_326_902916447.1414837218470
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>At present for example std::map has search metho=
ds that have only one parameter of type const key_type&</div><div>=
<br></div><div>In this case the searching starts from the iterator ret=
urned by member function begin.</div><div><br></div><div>I would like to su=
ggest modifications of these methods by adding second parameter that s=
ets the start pos in the container.</div><div><br></div><div>For example</d=
iv><div><br></div><div>iterator lower_bound(const key_type& x, const_it=
erator pos ); </div><div><br></div><div><br></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" 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_326_902916447.1414837218470--
.
Author: Thibaut Lutz <thibaut.lutz@googlemail.com>
Date: Sat, 1 Nov 2014 12:46:57 +0000
Raw View
--089e0118221677f41c0506cb83f5
Content-Type: text/plain; charset=UTF-8
Is there any reason why std::lower_bound is not applicable in this case?
The syntax is a bit longer but can be hoisted in a function if lower_bound
with a start offset is a recurring requirement in your code.
The problem I see with this suggestion is that I see no reason to allow for
a offset at the beginning but not at the end, so we should create a
lower_bound method with beginning and end iterators, which is very close to
std::lower_bound.
std::map<T,U> m;
auto lower = std::lower_bound(std::next(std::begin(m), offset), std::end(m),
std::make_pair<T,U>(key_value,{}),
std::less<std::pair<T,U>>());
On Sat, Nov 1, 2014 at 10:20 AM, Vlad from Moscow <vlad.moscow@mail.ru>
wrote:
> At present for example std::map has search methods that have only one
> parameter of type const key_type&
>
> In this case the searching starts from the iterator returned by member
> function begin.
>
> I would like to suggest modifications of these methods by adding second
> parameter that sets the start pos in the container.
>
> For example
>
> iterator lower_bound(const key_type& x, const_iterator pos );
>
>
> --
>
> ---
> 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/.
>
--
Thibaut LUTZ
--
---
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/.
--089e0118221677f41c0506cb83f5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Is there any reason why std::lower_bound is not applicable=
in this case? The syntax is a bit longer but can be hoisted in a function =
if lower_bound with a start offset is a recurring requirement in your code.=
<div>The problem I see with this suggestion is that I see no reason to allo=
w for a offset at the beginning but not at the end, so we should create a l=
ower_bound method with beginning and end iterators, which is very close to =
std::lower_bound.<br><div><br></div></div><div>
<pre style=3D"margin-top:0px;margin-bottom:0px"><span style=3D"color:rgb(19=
2,192,192)"> </span>std<span style=3D"color:rgb(0,0,0)">::</span>map<span =
style=3D"color:rgb(0,0,0)"><</span>T<span style=3D"color:rgb(0,0,0)">,</=
span>U<span style=3D"color:rgb(0,0,0)">></span><span style=3D"color:rgb(=
192,192,192)"> </span><span style=3D"color:rgb(0,0,0)">m</span><span style=
=3D"color:rgb(0,0,0)">;</span></pre>
<pre style=3D"margin-top:0px;margin-bottom:0px"><span style=3D"color:rgb(19=
2,192,192)"> </span><span style=3D"color:rgb(128,128,0)">auto</span><span =
style=3D"color:rgb(192,192,192)"> </span><span style=3D"color:rgb(0,0,0)">l=
ower</span><span style=3D"color:rgb(192,192,192)"> </span><span style=3D"co=
lor:rgb(0,0,0)">=3D</span><span style=3D"color:rgb(192,192,192)"> </span>st=
d<span style=3D"color:rgb(0,0,0)">::</span>lower_bound<span style=3D"color:=
rgb(0,0,0)">(</span>std<span style=3D"color:rgb(0,0,0)">::</span>next<span =
style=3D"color:rgb(0,0,0)">(</span>std<span style=3D"color:rgb(0,0,0)">::</=
span>begin<span style=3D"color:rgb(0,0,0)">(</span><span style=3D"color:rgb=
(0,0,0)">m</span><span style=3D"color:rgb(0,0,0)">),</span><span style=3D"c=
olor:rgb(192,192,192)"> </span>offset<span style=3D"color:rgb(0,0,0)">),</s=
pan><span style=3D"color:rgb(192,192,192)"> </span>std<span style=3D"color:=
rgb(0,0,0)">::</span>end<span style=3D"color:rgb(0,0,0)">(</span><span styl=
e=3D"color:rgb(0,0,0)">m</span><span style=3D"color:rgb(0,0,0)">),</span><s=
pan style=3D"color:rgb(192,192,192)"> </span></pre>
<pre style=3D"margin-top:0px;margin-bottom:0px"><span style=3D"color:rgb(19=
2,192,192)"> </span>std<span style=3D"color:=
rgb(0,0,0)">::</span>make_pair<span style=3D"color:rgb(0,0,0)"><</span>T=
<span style=3D"color:rgb(0,0,0)">,</span>U<span style=3D"color:rgb(0,0,0)">=
>(key_</span>value<span style=3D"color:rgb(0,0,0)">,{}),</span></pre>
<pre style=3D"margin-top:0px;margin-bottom:0px"><span style=3D"color:rgb(19=
2,192,192)"> </span>std<span style=3D"color:=
rgb(0,0,0)">::</span>less<span style=3D"color:rgb(0,0,0)"><</span>std<sp=
an style=3D"color:rgb(0,0,0)">::</span>pair<span style=3D"color:rgb(0,0,0)"=
><</span>T<span style=3D"color:rgb(0,0,0)">,</span>U<span style=3D"color=
:rgb(0,0,0)">>>());</span></pre></div></div><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote">On Sat, Nov 1, 2014 at 10:20 AM, Vlad from=
Moscow <span dir=3D"ltr"><<a href=3D"mailto:vlad.moscow@mail.ru" target=
=3D"_blank">vlad.moscow@mail.ru</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>At present for example std::map has=C2=
=A0search methods that have only one parameter=C2=A0of type const key_type&=
amp;</div><div><br></div><div>In this case the=C2=A0searching starts from t=
he iterator returned by member function begin.</div><div><br></div><div>I w=
ould like to suggest modifications of these=C2=A0methods by adding second p=
arameter that sets the start pos in the container.</div><div><br></div><div=
>For example</div><div><br></div><div>iterator lower_bound(const key_type&a=
mp; x, const_iterator pos );=C2=A0</div><span class=3D"HOEnZb"><font color=
=3D"#888888"><div><br></div><div><br></div></font></span></div><span class=
=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;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"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>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div class=3D"gmail_signature">Thibaut LUTZ</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" 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 />
--089e0118221677f41c0506cb83f5--
.
Author: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Sat, 1 Nov 2014 06:12:46 -0700 (PDT)
Raw View
------=_Part_132_318087367.1414847566711
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 1 =D0=BD=D0=BE=D1=8F=D0=B1=D1=
=80=D1=8F 2014 =D0=B3., 15:47:18 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=
=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thibaut Lutz =D0=BD=D0=B0=D0=BF=D0=B8=
=D1=81=D0=B0=D0=BB:
>
> Is there any reason why std::lower_bound is not applicable in this case?=
=20
> The syntax is a bit longer but can be hoisted in a function if lower_boun=
d=20
> with a start offset is a recurring requirement in your code.
>
Ask this question to members of the C++ Committee. Why did they declare=20
member functions find, lower_bound, upper_bound, equal_range for=20
associative containers?
As for me then I think it is a bad idea when at first there is used member=
=20
function lower_bound and then standard algorithm std::lower_bound.
I am sure that the member function can be realized more efficiently than=20
the standard algorithm.
The problem I see with this suggestion is that I see no reason to allow for=
=20
> a offset at the beginning but not at the end, so we should create a=20
> lower_bound method with beginning and end iterators, which is very close =
to=20
> std::lower_bound.
>
> std::map<T,U> m;
>
> auto lower =3D std::lower_bound(std::next(std::begin(m), offset), std::=
end(m),=20
>
> std::make_pair<T,U>(key_value,{}),
>
> std::less<std::pair<T,U>>());
>
>
> On Sat, Nov 1, 2014 at 10:20 AM, Vlad from Moscow <vlad....@mail.ru=20
> <javascript:>> wrote:
>
>> At present for example std::map has search methods that have only one=20
>> parameter of type const key_type&
>>
>> In this case the searching starts from the iterator returned by member=
=20
>> function begin.
>>
>> I would like to suggest modifications of these methods by adding second=
=20
>> parameter that sets the start pos in the container.
>>
>> For example
>>
>> iterator lower_bound(const key_type& x, const_iterator pos );=20
>>
>>
>> --=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
> Thibaut LUTZ
> =20
--=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_132_318087367.1414847566711
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 1 =D0=
=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3., 15:47:18 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thibaut =
Lutz =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-c=
olor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;=
"><div dir=3D"ltr">Is there any reason why std::lower_bound is not applicab=
le in this case? The syntax is a bit longer but can be hoisted in a functio=
n if lower_bound with a start offset is a recurring requirement in your cod=
e.</div></blockquote><div><br></div><div>Ask this question to members of th=
e C++ Committee. Why did they declare member functions find, lower_bound, u=
pper_bound, equal_range for associative containers?</div><div><br></div><di=
v> As for me then I think it is a bad idea when at first there is used=
member function lower_bound and then standard algorithm std::lower_bound.<=
/div><div><br></div><div>I am sure that the member function can be realized=
more efficiently than the standard algorithm.</div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left:=
1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border=
-left-style: solid;"><div dir=3D"ltr"><div>The problem I see with this sugg=
estion is that I see no reason to allow for a offset at the beginning but n=
ot at the end, so we should create a lower_bound method with beginning and =
end iterators, which is very close to std::lower_bound.<br><div><br></div><=
/div><div>
<pre style=3D"margin-top: 0px; margin-bottom: 0px;"><span style=3D"color: r=
gb(192, 192, 192);"> </span>std<span style=3D"color: rgb(0, 0, 0);">::</sp=
an>map<span style=3D"color: rgb(0, 0, 0);"><</span>T<span style=3D"color=
: rgb(0, 0, 0);">,</span>U<span style=3D"color: rgb(0, 0, 0);">></span><=
span style=3D"color: rgb(192, 192, 192);"> </span><span style=3D"color: rgb=
(0, 0, 0);">m</span><span style=3D"color: rgb(0, 0, 0);">;</span></pre>
<pre style=3D"margin-top: 0px; margin-bottom: 0px;"><span style=3D"color: r=
gb(192, 192, 192);"> </span><span style=3D"color: rgb(128, 128, 0);">auto<=
/span><span style=3D"color: rgb(192, 192, 192);"> </span><span style=3D"col=
or: rgb(0, 0, 0);">lower</span><span style=3D"color: rgb(192, 192, 192);"> =
</span><span style=3D"color: rgb(0, 0, 0);">=3D</span><span style=3D"color:=
rgb(192, 192, 192);"> </span>std<span style=3D"color: rgb(0, 0, 0);">::</s=
pan>lower_bound<span style=3D"color: rgb(0, 0, 0);">(</span>std<span style=
=3D"color: rgb(0, 0, 0);">::</span>next<span style=3D"color: rgb(0, 0, 0);"=
>(</span>std<span style=3D"color: rgb(0, 0, 0);"><wbr>::</span>begin<span s=
tyle=3D"color: rgb(0, 0, 0);">(</span><span style=3D"color: rgb(0, 0, 0);">=
m</span><span style=3D"color: rgb(0, 0, 0);">),</span><span style=3D"color:=
rgb(192, 192, 192);"> </span>offset<span style=3D"color: rgb(0, 0, 0);">),=
</span><span style=3D"color: rgb(192, 192, 192);"> </span>std<span style=3D=
"color: rgb(0, 0, 0);">::</span>end<span style=3D"color: rgb(0, 0, 0);">(</=
span><span style=3D"color: rgb(0, 0, 0);">m</span><span style=3D"color: rgb=
(0, 0, 0);">),</span><span style=3D"color: rgb(192, 192, 192);"> </span></p=
re>
<pre style=3D"margin-top: 0px; margin-bottom: 0px;"><span style=3D"color: r=
gb(192, 192, 192);"> </span>std<span style=
=3D"color: rgb(0, 0, 0);">::</span>make_pair<span style=3D"color: rgb(0, 0,=
0);"><</span>T<span style=3D"color: rgb(0, 0, 0);">,</span>U<span style=
=3D"color: rgb(0, 0, 0);">>(key_</span>value<span style=3D"color: rgb(0,=
0, 0);">,<wbr>{}),</span></pre>
<pre style=3D"margin-top: 0px; margin-bottom: 0px;"><span style=3D"color: r=
gb(192, 192, 192);"> </span>std<span style=
=3D"color: rgb(0, 0, 0);">::</span>less<span style=3D"color: rgb(0, 0, 0);"=
><</span>std<span style=3D"color: rgb(0, 0, 0);">::</span>pair<span styl=
e=3D"color: rgb(0, 0, 0);"><</span>T<span style=3D"color: rgb(0, 0, 0);"=
>,</span>U<span style=3D"color: rgb(0, 0, 0);">>>());</span></pre></d=
iv></div><div><br><div class=3D"gmail_quote">On Sat, Nov 1, 2014 at 10:20 A=
M, Vlad from Moscow <span dir=3D"ltr"><<a onmousedown=3D"this.href=3D'ja=
vascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;"=
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"m6ziBE6jWC=
wJ">vlad....@mail.ru</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-col=
or: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">=
<div dir=3D"ltr"><div>At present for example std::map has search metho=
ds that have only one parameter of type const key_type&</div><div>=
<br></div><div>In this case the searching starts from the iterator ret=
urned by member function begin.</div><div><br></div><div>I would like to su=
ggest modifications of these methods by adding second parameter that s=
ets the start pos in the container.</div><div><br></div><div>For example</d=
iv><div><br></div><div>iterator lower_bound(const key_type& x, const_it=
erator pos ); </div><span><font color=3D"#888888"><div><br></div><div>=
<br></div></font></span></div><span><font color=3D"#888888">
<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 onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"m6ziBE6jWCwJ">std-proposal...@<wbr>isocpp.=
org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return true;" href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"m6ziBE6jWCwJ">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a 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;" hr=
ef=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/" target=3D=
"_blank">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div>Thibaut LUTZ</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" 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_132_318087367.1414847566711--
.
Author: Thibaut Lutz <thibaut.lutz@googlemail.com>
Date: Sat, 1 Nov 2014 13:56:58 +0000
Raw View
--047d7b2e0efbeb3b640506cc7df3
Content-Type: text/plain; charset=UTF-8
>
> Why did they declare member functions find, lower_bound, upper_bound,
> equal_range for associative containers?
>
The non member algorithms are designed to operate on ranges, which is the
use case you require. Member algorithms typically operate over the entire
containers, and are optimized for that.
I am sure that the member function can be realized more efficiently than
> the standard algorithm.
>
In this particular case I think avoiding nodes in the tree would make it
inherently less efficient than the search used for lower_bound and others
on the full container. Although I don't know the specialized
implementations of std::lower_bound and the implementations of the member
lower_bound well enough to comment further on this.
--
---
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/.
--047d7b2e0efbeb3b640506cc7df3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><div>Why did t=
hey declare member functions find, lower_bound, upper_bound, equal_range fo=
r associative containers?<br></div></span></div></blockquote><div><br></div=
><div>The non member algorithms are designed to operate on ranges, which is=
the use case you require. Member algorithms typically operate over the ent=
ire containers, and are optimized for that.</div><div><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div>I am sure that the member functio=
n can be realized more efficiently than the standard algorithm.</div></div>=
</blockquote><div><br></div><div>In this particular case I think avoiding n=
odes in the tree would make it inherently less efficient than the search us=
ed for lower_bound and others on the full container. Although I don't k=
now the specialized implementations of std::lower_bound and the implementat=
ions of the member lower_bound well enough to comment further on this.</div=
><div><br></div><div><br></div></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" 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 />
--047d7b2e0efbeb3b640506cc7df3--
.