Topic: Definition of std::is_sorted for iterators of the
Author: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Tue, 17 Mar 2015 23:28:18 -0700 (PDT)
Raw View
------=_Part_5695_658524920.1426660098486
Content-Type: multipart/alternative;
boundary="----=_Part_5696_1845097449.1426660098486"
------=_Part_5696_1845097449.1426660098486
Content-Type: text/plain; charset=UTF-8
Currently standard algorithm std::is_sorted is defined for iterators of the
forward iterator category.
However
1. There is no reason why it could not be defined for iterators of the
input iterator category.
2. It is useful to have this algorithm for the input iterator category and
it can find its own area of application. For example let;s assume that
there is a string that filled with some sequence of integers (or some words
and so on)
std::string s( " 1 2 3 4 5 6 7 8 9" );
and we need to check whether these integers are sorted within the string.
In general case there is no sense to extratc these integers and place them
in a separate container with forward iterators that only to check whether
they are ordered.
We could use standard iterator adapter std::istream_iterator and
appropriately defined algorithm std::is_sorted that to perform the task
without using additional resources.
3. The algorithm for iterators of the input iterator category can be
written simply. For iterators of the forward iterator category it can use
the existent implementation.
Whar are your thoughts?
--
---
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_5696_1845097449.1426660098486
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Currently standard algorithm std::is_sorted is define=
d for iterators of the forward iterator category.</div><div><br></div><div>=
However</div><div><br></div><div>1. There is no reason why it could not be =
defined for iterators of the input iterator category.</div><div><br></div><=
div>2. It is useful to have this algorithm for the input iterator category =
and it can find its own area of application. For example let;s assume that =
there is a string that filled with some sequence of integers (or some words=
and so on)</div><div><br></div><div>std::string s( " 1 2 3 4 5 6 7 8 9" );=
</div><div><br></div><div>and we need to check whether these integers are s=
orted within the string. In general case there is no sense to extratc these=
integers and place them in a separate container with forward iterators tha=
t only to check whether they are ordered. </div><div><br></div><div>We coul=
d use standard iterator adapter std::istream_iterator and appropriate=
ly defined algorithm std::is_sorted that to perform the task without using =
additional resources.</div><div><br></div><div>3. The algorithm for iterato=
rs of the input iterator category can be written simply. For iterators of t=
he forward iterator category it can use the existent implementation.</div><=
div><br></div><div>Whar are your thoughts?</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_5696_1845097449.1426660098486--
------=_Part_5695_658524920.1426660098486--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 18 Mar 2015 14:37:49 +0800
Raw View
> On 2015=E2=80=9303=E2=80=9318, at 2:28 PM, Vlad from Moscow <vlad.moscow@=
mail.ru> wrote:
>=20
> Currently standard algorithm std::is_sorted is defined for iterators of t=
he forward iterator category.
>=20
> However
>=20
> 1. There is no reason why it could not be defined for iterators of the in=
put iterator category.
is_sorted compares consecutive elements, which requires looking at two elem=
ents at a time. However, an InputIterator sequence only provides access to =
one element at a time. The algorithm would have to keep its own copies, whi=
ch would require CopyConstructible elements. But the copying would only hap=
pen for InputIterators, which would be a bit odd.
--=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/.
.
Author: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Tue, 17 Mar 2015 23:44:56 -0700 (PDT)
Raw View
------=_Part_5651_1596040792.1426661096697
Content-Type: multipart/alternative;
boundary="----=_Part_5652_439356467.1426661096698"
------=_Part_5652_439356467.1426661096698
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
David, your remark can be reflected in the description of the algorithm in=
=20
the requirements.
On Wednesday, March 18, 2015 at 9:38:04 AM UTC+3, David Krauss wrote:
>
>
> > On 2015=E2=80=9303=E2=80=9318, at 2:28 PM, Vlad from Moscow <vlad....@m=
ail.ru=20
> <javascript:>> wrote:=20
> >=20
> > Currently standard algorithm std::is_sorted is defined for iterators of=
=20
> the forward iterator category.=20
> >=20
> > However=20
> >=20
> > 1. There is no reason why it could not be defined for iterators of the=
=20
> input iterator category.=20
>
> is_sorted compares consecutive elements, which requires looking at two=20
> elements at a time. However, an InputIterator sequence only provides acce=
ss=20
> to one element at a time. The algorithm would have to keep its own copies=
,=20
> which would require CopyConstructible elements. But the copying would onl=
y=20
> happen for InputIterators, which would be a bit odd.=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_5652_439356467.1426661096698
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">David, your remark can be reflected in the description of =
the algorithm in the requirements.<br><br>On Wednesday, March 18, 2015 at 9=
:38:04 AM UTC+3, David Krauss wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;">
<br>> On 2015=E2=80=9303=E2=80=9318, at 2:28 PM, Vlad from Moscow <<a=
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;" href=3D"javascript:" target=3D"_blank" rel=
=3D"nofollow" gdf-obfuscated-mailto=3D"82CGZ48IuaQJ">vlad....@mail.ru</a>&g=
t; wrote:
<br>>=20
<br>> Currently standard algorithm std::is_sorted is defined for iterato=
rs of the forward iterator category.
<br>>=20
<br>> However
<br>>=20
<br>> 1. There is no reason why it could not be defined for iterators of=
the input iterator category.
<br>
<br>is_sorted compares consecutive elements, which requires looking at two =
elements at a time. However, an InputIterator sequence only provides access=
to one element at a time. The algorithm would have to keep its own copies,=
which would require CopyConstructible elements. But the copying would only=
happen for InputIterators, which would be a bit odd.
<br>
<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" 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_5652_439356467.1426661096698--
------=_Part_5651_1596040792.1426661096697--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 18 Mar 2015 10:20:41 -0500
Raw View
--047d7bfd01eac03650051191a23c
Content-Type: text/plain; charset=UTF-8
On 18 March 2015 at 01:44, Vlad from Moscow <vlad.moscow@mail.ru> wrote:
> David, your remark can be reflected in the description of the algorithm in
> the requirements.
>
That wouldn't be a remark; copyable (and whether or not you need both
CopyConstructible and CopyAssignable) would be a requirement. This would
also mean that the algorithm could throw.
Given the above surprising behavior (plus the performance difference
between using InputIterators and ForwardIterators), such a proposal is
unlikely to go anywhere. IMNSHO this is a solution in search of a problem.
--
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/.
--047d7bfd01eac03650051191a23c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 18 March 2015 at 01:44, Vlad from Moscow <span dir=3D"l=
tr"><<a href=3D"mailto:vlad.moscow@mail.ru" target=3D"_blank">vlad.mosco=
w@mail.ru</a>></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;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">David, your r=
emark can be reflected in the description of the algorithm in the requireme=
nts.<br></div></blockquote><div><br></div><div>That wouldn't be a remar=
k; copyable (and whether or not you need both CopyConstructible and CopyAss=
ignable) would be a requirement.=C2=A0 This would also mean that the algori=
thm could throw.</div><div><br></div><div>Given the above surprising behavi=
or (plus the performance difference between using InputIterators and Forwar=
dIterators), such a proposal is unlikely to go anywhere.=C2=A0 IMNSHO this =
is a solution in search of a problem.</div></div>-- <br><div class=3D"gmail=
_signature">=C2=A0Nevin ":-)" Liber=C2=A0 <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" 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 />
--047d7bfd01eac03650051191a23c--
.
Author: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Wed, 18 Mar 2015 08:38:32 -0700 (PDT)
Raw View
------=_Part_599_2002634777.1426693112031
Content-Type: multipart/alternative;
boundary="----=_Part_600_771497608.1426693112031"
------=_Part_600_771497608.1426693112031
Content-Type: text/plain; charset=UTF-8
Suprising behaviour has algorithm std::copy_n. However it was adopted by
the C++ Standards Committee.:)
As for performance difference for input iterators and forward iterators
then there is no any performance difference because the areas of
application of the algorithm with input iterators and forward iterators
are ddifferent. It would be correct to compare the performance of the
example I showed with using the algorithm and the approach you are going to
apply without using the algorithm. Can you show your approach? We will
compare the performance for example for a string that contains 10000
integers.
I am sure it is a good proposal.
On Wednesday, March 18, 2015 at 6:21:24 PM UTC+3, Nevin ":-)" Liber wrote:
> On 18 March 2015 at 01:44, Vlad from Moscow <vlad....@mail.ru
> <javascript:>> wrote:
>
>> David, your remark can be reflected in the description of the algorithm
>> in the requirements.
>>
>
> That wouldn't be a remark; copyable (and whether or not you need both
> CopyConstructible and CopyAssignable) would be a requirement. This would
> also mean that the algorithm could throw.
>
> Given the above surprising behavior (plus the performance difference
> between using InputIterators and ForwardIterators), such a proposal is
> unlikely to go anywhere. IMNSHO this is a solution in search of a problem.
> --
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> (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/.
------=_Part_600_771497608.1426693112031
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Suprising behaviour has algorithm std::copy_n. Howeve=
r it was adopted by the C++ Standards Committee.:)</div><div><br></div><div=
>As for performance difference for input iterators and forward iterators th=
en there is no any performance difference because the areas of applica=
tion of the algorithm with input iterators and forward iterators are =
ddifferent. It would be correct to compare the performance of the example I=
showed with using the algorithm and the approach you are going to apply wi=
thout using the algorithm. Can you show your approach? We will compare the =
performance for example for a string that contains 10000 integers.</div><di=
v><br></div><div>I am sure it is a good proposal.<br><br>On Wednesday, Marc=
h 18, 2015 at 6:21:24 PM UTC+3, Nevin ":-)" Liber wrote:</div><blockquote c=
lass=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">On 18 March 2015 at 01:44, Vlad from Mosco=
w <span dir=3D"ltr"><<a onmousedown=3D"this.href=3D'javascript:';return =
true;" onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"i7nuwi67L-o=
J">vlad....@mail.ru</a>></span> wrote:<br><div><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pad=
ding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1=
px; border-left-style: solid;"><div dir=3D"ltr">David, your remark can be r=
eflected in the description of the algorithm in the requirements.<br></div>=
</blockquote><div><br></div><div>That wouldn't be a remark; copyable (and w=
hether or not you need both CopyConstructible and CopyAssignable) would be =
a requirement. This would also mean that the algorithm could throw.</=
div><div><br></div><div>Given the above surprising behavior (plus the perfo=
rmance difference between using InputIterators and ForwardIterators), such =
a proposal is unlikely to go anywhere. IMNSHO this is a solution in s=
earch of a problem.</div></div>-- <br><div> Nevin ":-)" Liber &l=
t;mailto:<a onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=3D"=
_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"i7nuwi67L-oJ">ne...@evilo=
verlord.com</a><wbr>> (847) 691-1404</div>
</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_600_771497608.1426693112031--
------=_Part_599_2002634777.1426693112031--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 18 Mar 2015 11:33:55 -0500
Raw View
--001a11349952a2e26e051192a8b0
Content-Type: text/plain; charset=UTF-8
On 18 March 2015 at 10:38, Vlad from Moscow <vlad.moscow@mail.ru> wrote:
> Suprising behaviour has algorithm std::copy_n.
>
What surprising behavior is that?
> As for performance difference for input iterators and forward iterators
> then there is no any performance difference because the areas of
> application of the algorithm with input iterators and forward iterators
> are ddifferent.
>
Sure they are, if one requires copying and the other doesn't. Yes, there
is no algorithmic complexity difference, but there most certainly can be a
practical difference, especially types that have nontrivial copy semantics.
> It would be correct to compare the performance of the example I showed
> with using the algorithm and the approach you are going to apply without
> using the algorithm. Can you show your approach? We will compare the
> performance for example for a string that contains 10000 integers.
>
I don't see it as a terribly useful addition outside of that contrived
example. After all, one calls is_sorted presumably to do something based
on what it returns, which will typically means one already has a container
of objects so that one can do multiple passes over the data, and that
container has better than just input iterators.
How, for instance, would you go and sort the string of numbers if is_sorted
returns false?
> I am sure it is a good proposal.
>
I am sure you are sure it is a good proposal. Best of luck writing it up
and coming to Lenexa to present it.
--
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/.
--001a11349952a2e26e051192a8b0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 18 March 2015 at 10:38, Vlad from Moscow <span dir=3D"l=
tr"><<a href=3D"mailto:vlad.moscow@mail.ru" target=3D"_blank">vlad.mosco=
w@mail.ru</a>></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;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Suprisin=
g behaviour has algorithm std::copy_n. </div></div></blockquote><div><br></=
div><div>What surprising behavior is that?</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div>As for performance difference fo=
r input iterators and forward iterators then there is no any performance di=
fference because the areas=C2=A0of application of the algorithm =C2=A0with =
input iterators and forward iterators are ddifferent.</div></div></blockquo=
te><div><br></div><div>Sure they are, if one requires copying and the other=
doesn't.=C2=A0 Yes, there is no algorithmic complexity difference, but=
there most certainly can be a practical difference, especially types that =
have nontrivial copy semantics.</div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div> It would be correct to compare the perform=
ance of the example I showed with using the algorithm and the approach you =
are going to apply without using the algorithm. Can you show your approach?=
We will compare the performance for example for a string that contains 100=
00 integers.<br></div></div></blockquote><div><br></div><div>I don't se=
e it as a terribly useful addition outside of that contrived example.=C2=A0=
After all, one calls is_sorted presumably to do something based on what it=
returns, which will typically means one already has a container of objects=
so that one can do multiple passes over the data, and that container has b=
etter than just input iterators.</div><div><br></div><div>How, for instance=
, would you go and sort the string of numbers if is_sorted returns false?</=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><=
/div><div>I am sure it is a good proposal.<br></div></div></blockquote><div=
><br></div><div>I am sure you are sure it is a good proposal.=C2=A0 Best of=
luck writing it up and coming to Lenexa to present it.</div></div>-- <br><=
div class=3D"gmail_signature">=C2=A0Nevin ":-)" Liber=C2=A0 <m=
ailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evi=
loverlord.com</a>>=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" 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 />
--001a11349952a2e26e051192a8b0--
.
Author: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Wed, 18 Mar 2015 10:19:19 -0700 (PDT)
Raw View
------=_Part_6892_140754711.1426699159144
Content-Type: multipart/alternative;
boundary="----=_Part_6893_1284932430.1426699159145"
------=_Part_6893_1284932430.1426699159145
Content-Type: text/plain; charset=UTF-8
The behaviour of copy_n is suprising because in general case it is simply
an invalid algorithm. You can not say beforehand whether selected n is
correct or not. Using n means that in fact you are dealing with a forward
iterator where the end of the range is calculated like std::next( begin, n
).
Opposite to copy_n algorithm is_sorted with input iterators is a valid
algorithm.
And it is indeed useful addition. Otherwise in fact each programmer will
write its own is_sorted algorithm for input iterators.
Imagine the following task. There is a file that contains records that in
turn contain sequences of numbers. And you need to copy records that
have an ordered sequence of numbers from this file in another output file .
How will you check that numbers in a record are ordered?
Will you place the numbers in some container as for example std::vector?
And what about the performance?
I do not see any other clear approach accept to use std::istream_iterator
with std::is_sorted.
Of course you can write the same using some loops. But what is the reason
to make your code less readable and to use some loops instead of simply to
apply the algorithm? Are you going to write your own function instead of
the algorithm? And how will you name it?
In my opinion it does not make sense.
On Wednesday, March 18, 2015 at 7:34:38 PM UTC+3, Nevin ":-)" Liber wrote:
> On 18 March 2015 at 10:38, Vlad from Moscow <vlad....@mail.ru
> <javascript:>> wrote:
>
>> Suprising behaviour has algorithm std::copy_n.
>>
>
> What surprising behavior is that?
>
>
>> As for performance difference for input iterators and forward iterators
>> then there is no any performance difference because the areas of
>> application of the algorithm with input iterators and forward iterators
>> are ddifferent.
>>
>
> Sure they are, if one requires copying and the other doesn't. Yes, there
> is no algorithmic complexity difference, but there most certainly can be a
> practical difference, especially types that have nontrivial copy semantics.
>
>
>> It would be correct to compare the performance of the example I showed
>> with using the algorithm and the approach you are going to apply without
>> using the algorithm. Can you show your approach? We will compare the
>> performance for example for a string that contains 10000 integers.
>>
>
> I don't see it as a terribly useful addition outside of that contrived
> example. After all, one calls is_sorted presumably to do something based
> on what it returns, which will typically means one already has a container
> of objects so that one can do multiple passes over the data, and that
> container has better than just input iterators.
>
> How, for instance, would you go and sort the string of numbers if
> is_sorted returns false?
>
>
>> I am sure it is a good proposal.
>>
>
> I am sure you are sure it is a good proposal. Best of luck writing it up
> and coming to Lenexa to present it.
> --
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> (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/.
------=_Part_6893_1284932430.1426699159145
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>The behaviour of copy_n is suprising because in gener=
al case it is simply an invalid algorithm. You can not say beforehand wheth=
er selected n is correct or not. Using n means that in fact you are de=
aling with a forward iterator where the end of the range is calcu=
lated like std::next( begin, n ).</div><div><br></div><div>Opposite to copy=
_n algorithm is_sorted with input iterators is a valid algorithm. </div><di=
v><br></div><div>And it is indeed useful addition. Otherwise in fact each p=
rogrammer will write its own is_sorted algorithm for input iterators.</div>=
<div><br></div><div>Imagine the following task. There is a file that contai=
ns records that in turn contain sequences of numbers. And you need to =
copy records that have an ordered sequence of numbers from =
this file in another output file .</div><div><br></div><div>How will y=
ou check that numbers in a record are ordered?</div><div><br></div><div>Wil=
l you place the numbers in some container as for example std::vector? And w=
hat about the performance?</div><div><br></div><div>I do not see any other =
clear approach accept to use std::istream_iterator with std::is_sorted.</di=
v><div><br></div><div>Of course you can write the same using some loop=
s. But what is the reason to make your code less readable and to use some&n=
bsp;loops instead of simply to apply the algorithm? Are you going to write =
your own function instead of the algorithm? And how will you name it?</div>=
<div><br></div><div>In my opinion it does not make sense.</div><div> <=
br><br>On Wednesday, March 18, 2015 at 7:34:38 PM UTC+3, Nevin ":-)" Liber =
wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On 18 March 2015 =
at 10:38, Vlad from Moscow <span dir=3D"ltr"><<a onmousedown=3D"this.hre=
f=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return=
true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfusca=
ted-mailto=3D"qj1BooutI2kJ">vlad....@mail.ru</a>></span> wrote:<br><div>=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 2=
04); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><d=
iv>Suprising behaviour has algorithm std::copy_n. </div></div></blockquote>=
<div><br></div><div>What surprising behavior is that?</div><div> </div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;"><div dir=3D"ltr"><div>As for performance diff=
erence for input iterators and forward iterators then there is no any perfo=
rmance difference because the areas of application of the algorithm &n=
bsp;with input iterators and forward iterators are ddifferent.</div></div><=
/blockquote><div><br></div><div>Sure they are, if one requires copying and =
the other doesn't. Yes, there is no algorithmic complexity difference=
, but there most certainly can be a practical difference, especially types =
that have nontrivial copy semantics.</div><div> </div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bo=
rder-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-st=
yle: solid;"><div dir=3D"ltr"><div> It would be correct to compare the perf=
ormance of the example I showed with using the algorithm and the approach y=
ou are going to apply without using the algorithm. Can you show your approa=
ch? We will compare the performance for example for a string that contains =
10000 integers.<br></div></div></blockquote><div><br></div><div>I don't see=
it as a terribly useful addition outside of that contrived example. =
After all, one calls is_sorted presumably to do something based on what it =
returns, which will typically means one already has a container of objects =
so that one can do multiple passes over the data, and that container has be=
tter than just input iterators.</div><div><br></div><div>How, for instance,=
would you go and sort the string of numbers if is_sorted returns false?</d=
iv><div> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bo=
rder-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div></di=
v><div>I am sure it is a good proposal.<br></div></div></blockquote><div><b=
r></div><div>I am sure you are sure it is a good proposal. Best of lu=
ck writing it up and coming to Lenexa to present it.</div></div>-- <br><div=
> Nevin ":-)" Liber <mailto:<a onmousedown=3D"this.href=3D'ja=
vascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;"=
href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mai=
lto=3D"qj1BooutI2kJ">ne...@eviloverlord.com</a><wbr>> (847) 691-14=
04</div>
</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_6893_1284932430.1426699159145--
------=_Part_6892_140754711.1426699159144--
.
Author: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Wed, 18 Mar 2015 11:22:05 -0700 (PDT)
Raw View
------=_Part_6507_1423946482.1426702925760
Content-Type: multipart/alternative;
boundary="----=_Part_6508_710760806.1426702925760"
------=_Part_6508_710760806.1426702925760
Content-Type: text/plain; charset=UTF-8
Specially for you I prepared a simple and at the same time elegant example
Here you are
#include <iostream>
#include <iterator>
#include <string>
#include <sstream>
#include <vector>
template <class InputIterator>
bool is_sorted( InputIterator first, InputIterator last )
{
if ( first != last )
{
typename std::iterator_traits<InputIterator>::value_type prev( *first );
while ( ++first != last && !( *first < prev ) ) prev = *first;
}
return first == last;
}
int main()
{
std::vector<std::string> sorted;
std::vector<std::string> non_sorted;
std::string record;
while ( std::getline( std::cin, record ) && !record.empty() )
{
std::istringstream is( record );
if ( is_sorted( std::istream_iterator<int>( is ),
std::istream_iterator<int>() ) )
{
sorted.push_back( record );
}
else
{
non_sorted.push_back( record );
}
}
std::cout << "Sorted" << std::endl;
for ( const auto &s : sorted ) std::cout << s << std::endl;
std::cout << "\nNon-sorted" << std::endl;
for ( const auto &s : non_sorted ) std::cout << s << std::endl;
return 0;
}
If to enter for example the following sequences
1 2 3 4 5
1 2 2 2 2
1 2 3 5 4
2 1 1 1 1
then the program output will be
Sorted
1 2 3 4 5
1 2 2 2 2
Non-sorted
1 2 3 5 4
2 1 1 1 1
As you see the code is very clear.
On Wednesday, March 18, 2015 at 7:34:38 PM UTC+3, Nevin ":-)" Liber wrote:
> On 18 March 2015 at 10:38, Vlad from Moscow <vlad....@mail.ru
> <javascript:>> wrote:
>
>> Suprising behaviour has algorithm std::copy_n.
>>
>
> What surprising behavior is that?
>
>
>> As for performance difference for input iterators and forward iterators
>> then there is no any performance difference because the areas of
>> application of the algorithm with input iterators and forward iterators
>> are ddifferent.
>>
>
> Sure they are, if one requires copying and the other doesn't. Yes, there
> is no algorithmic complexity difference, but there most certainly can be a
> practical difference, especially types that have nontrivial copy semantics.
>
>
>> It would be correct to compare the performance of the example I showed
>> with using the algorithm and the approach you are going to apply without
>> using the algorithm. Can you show your approach? We will compare the
>> performance for example for a string that contains 10000 integers.
>>
>
> I don't see it as a terribly useful addition outside of that contrived
> example. After all, one calls is_sorted presumably to do something based
> on what it returns, which will typically means one already has a container
> of objects so that one can do multiple passes over the data, and that
> container has better than just input iterators.
>
> How, for instance, would you go and sort the string of numbers if
> is_sorted returns false?
>
>
>> I am sure it is a good proposal.
>>
>
> I am sure you are sure it is a good proposal. Best of luck writing it up
> and coming to Lenexa to present it.
> --
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> (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/.
------=_Part_6508_710760806.1426702925760
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Specially for you I prepared a simple and at the same=
time elegant example</div><div><br></div><div>Here you are</div><div><br><=
/div><div>#include <iostream><br>#include <iterator><br>#includ=
e <string><br>#include <sstream><br>#include <vector></di=
v><div><br></div><div>template <class InputIterator><br>bool is_sorte=
d( InputIterator first, InputIterator last )<br>{<br> if ( first !=3D =
last )<br> {<br> typename std::iterator_traits<InputIter=
ator>::value_type prev( *first );<br> <br> while (=
++first !=3D last && !( *first < prev ) ) prev =3D *first;<br>&=
nbsp;}<br> <br> return first =3D=3D last;<br>}</div><div><br></di=
v><div>int main() <br>{<br> std::vector<std::string> sorted;<br>=
std::vector<std::string> non_sorted;<br> <br> std::st=
ring record;<br> while ( std::getline( std::cin, record ) && !=
record.empty() )<br> {<br> std::istringstream is( record );=
</div><div><br> if ( is_sorted( std::istream_iterator<int>=
( is ),<br> &nbs=
p; std::istream_iterator<int>() )=
)<br> {<br> sorted.push_back( record );<br>&nb=
sp; }  =
; <br> else<br> {<br>&n=
bsp; non_sorted.push_back( record );<br> }<br> }=
<br> <br> std::cout << "Sorted" << std::endl;<br>&nbs=
p;for ( const auto &s : sorted ) std::cout << s << std::end=
l;</div><div> </div><div> std::cout << "\nNon-sorted" <&=
lt; std::endl;<br> for ( const auto &s : non_sorted ) std::cout &l=
t;< s << std::endl;<br> <br> return 0;<br>}<br></div><di=
v><br></div><div>If to enter for example the following sequences</div><div>=
<br></div><div>1 2 3 4 5<br>1 2 2 2 2<br>1 2 3 5 4<br>2 1 1 1 1</div><div><=
br></div><div>then the program output will be</div><div><br></div><div>Sort=
ed</div><div>1 2 3 4 5<br>1 2 2 2 2<br><br>Non-sorted<br>1 2 3 5 4<br>2 1 1=
1 1<br></div><div><br></div><div>As you see the code is very clear.<br></d=
iv><div><br></div><div><br>On Wednesday, March 18, 2015 at 7:34:38 PM UTC+3=
, Nevin ":-)" Liber wrote:</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 2=
04, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"lt=
r">On 18 March 2015 at 10:38, Vlad from Moscow <span dir=3D"ltr"><<a onm=
ousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;" href=3D"javascript:" target=3D"_blank" rel=3D"n=
ofollow" gdf-obfuscated-mailto=3D"qj1BooutI2kJ">vlad....@mail.ru</a>></s=
pan> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-co=
lor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"=
><div dir=3D"ltr"><div>Suprising behaviour has algorithm std::copy_n. </div=
></div></blockquote><div><br></div><div>What surprising behavior is that?</=
div><div> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0px=
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>As =
for performance difference for input iterators and forward iterators then t=
here is no any performance difference because the areas of application=
of the algorithm with input iterators and forward iterators are ddif=
ferent.</div></div></blockquote><div><br></div><div>Sure they are, if one r=
equires copying and the other doesn't. Yes, there is no algorithmic c=
omplexity difference, but there most certainly can be a practical differenc=
e, especially types that have nontrivial copy semantics.</div><div> </=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; p=
adding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width:=
1px; border-left-style: solid;"><div dir=3D"ltr"><div> It would be correct=
to compare the performance of the example I showed with using the algorith=
m and the approach you are going to apply without using the algorithm. Can =
you show your approach? We will compare the performance for example for a s=
tring that contains 10000 integers.<br></div></div></blockquote><div><br></=
div><div>I don't see it as a terribly useful addition outside of that contr=
ived example. After all, one calls is_sorted presumably to do somethi=
ng based on what it returns, which will typically means one already has a c=
ontainer of objects so that one can do multiple passes over the data, and t=
hat container has better than just input iterators.</div><div><br></div><di=
v>How, for instance, would you go and sort the string of numbers if is_sort=
ed returns false?</div><div> </div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div d=
ir=3D"ltr"><div></div><div>I am sure it is a good proposal.<br></div></div>=
</blockquote><div><br></div><div>I am sure you are sure it is a good propos=
al. Best of luck writing it up and coming to Lenexa to present it.</d=
iv></div>-- <br><div> Nevin ":-)" Liber <mailto:<a onmousedow=
n=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javasc=
ript:';return true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow=
" gdf-obfuscated-mailto=3D"qj1BooutI2kJ">ne...@eviloverlord.com</a><wbr>>=
; (847) 691-1404</div>
</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_6508_710760806.1426702925760--
------=_Part_6507_1423946482.1426702925760--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Wed, 18 Mar 2015 18:46:53 +0000
Raw View
I notice you use *first twice in the while loop without an intervening
++first. That is not guaranteed to work!
On 3/18/15, Vlad from Moscow <vlad.moscow@mail.ru> wrote:
> Specially for you I prepared a simple and at the same time elegant example
>
> Here you are
>
> #include <iostream>
> #include <iterator>
> #include <string>
> #include <sstream>
> #include <vector>
>
> template <class InputIterator>
> bool is_sorted( InputIterator first, InputIterator last )
> {
> if ( first != last )
> {
> typename std::iterator_traits<InputIterator>::value_type prev( *first );
>
> while ( ++first != last && !( *first < prev ) ) prev = *first;
> }
>
> return first == last;
> }
>
> int main()
> {
> std::vector<std::string> sorted;
> std::vector<std::string> non_sorted;
>
> std::string record;
> while ( std::getline( std::cin, record ) && !record.empty() )
> {
> std::istringstream is( record );
>
> if ( is_sorted( std::istream_iterator<int>( is ),
> std::istream_iterator<int>() ) )
> {
> sorted.push_back( record );
> }
> else
> {
> non_sorted.push_back( record );
> }
> }
>
> std::cout << "Sorted" << std::endl;
> for ( const auto &s : sorted ) std::cout << s << std::endl;
>
> std::cout << "\nNon-sorted" << std::endl;
> for ( const auto &s : non_sorted ) std::cout << s << std::endl;
>
> return 0;
> }
>
> If to enter for example the following sequences
>
> 1 2 3 4 5
> 1 2 2 2 2
> 1 2 3 5 4
> 2 1 1 1 1
>
> then the program output will be
>
> Sorted
> 1 2 3 4 5
> 1 2 2 2 2
>
> Non-sorted
> 1 2 3 5 4
> 2 1 1 1 1
>
> As you see the code is very clear.
>
>
> On Wednesday, March 18, 2015 at 7:34:38 PM UTC+3, Nevin ":-)" Liber wrote:
>
>> On 18 March 2015 at 10:38, Vlad from Moscow <vlad....@mail.ru
>> <javascript:>> wrote:
>>
>>> Suprising behaviour has algorithm std::copy_n.
>>>
>>
>> What surprising behavior is that?
>>
>>
>>> As for performance difference for input iterators and forward iterators
>>> then there is no any performance difference because the areas of
>>> application of the algorithm with input iterators and forward iterators
>>>
>>> are ddifferent.
>>>
>>
>> Sure they are, if one requires copying and the other doesn't. Yes, there
>>
>> is no algorithmic complexity difference, but there most certainly can be a
>>
>> practical difference, especially types that have nontrivial copy
>> semantics.
>>
>>
>>> It would be correct to compare the performance of the example I showed
>>> with using the algorithm and the approach you are going to apply without
>>>
>>> using the algorithm. Can you show your approach? We will compare the
>>> performance for example for a string that contains 10000 integers.
>>>
>>
>> I don't see it as a terribly useful addition outside of that contrived
>> example. After all, one calls is_sorted presumably to do something based
>>
>> on what it returns, which will typically means one already has a container
>>
>> of objects so that one can do multiple passes over the data, and that
>> container has better than just input iterators.
>>
>> How, for instance, would you go and sort the string of numbers if
>> is_sorted returns false?
>>
>>
>>> I am sure it is a good proposal.
>>>
>>
>> I am sure you are sure it is a good proposal. Best of luck writing it up
>>
>> and coming to Lenexa to present it.
>> --
>> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> (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/.
>
--
---
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/.
.
Author: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Wed, 18 Mar 2015 11:51:31 -0700 (PDT)
Raw View
------=_Part_902_1063615168.1426704691300
Content-Type: multipart/alternative;
boundary="----=_Part_903_526250948.1426704691300"
------=_Part_903_526250948.1426704691300
Content-Type: text/plain; charset=UTF-8
The algorithm itself can be rewritten in appropriate way. At present it is
important to demonstrate the idea.:)
On Wednesday, March 18, 2015 at 9:46:54 PM UTC+3, Douglas Boffey wrote:
>
> I notice you use *first twice in the while loop without an intervening
> ++first. That is not guaranteed to work!
>
> On 3/18/15, Vlad from Moscow <vlad....@mail.ru <javascript:>> wrote:
> > Specially for you I prepared a simple and at the same time elegant
> example
> >
> > Here you are
> >
> > #include <iostream>
> > #include <iterator>
> > #include <string>
> > #include <sstream>
> > #include <vector>
> >
> > template <class InputIterator>
> > bool is_sorted( InputIterator first, InputIterator last )
> > {
> > if ( first != last )
> > {
> > typename std::iterator_traits<InputIterator>::value_type prev( *first
> );
> >
> > while ( ++first != last && !( *first < prev ) ) prev = *first;
> > }
> >
> > return first == last;
> > }
> >
> > int main()
> > {
> > std::vector<std::string> sorted;
> > std::vector<std::string> non_sorted;
> >
> > std::string record;
> > while ( std::getline( std::cin, record ) && !record.empty() )
> > {
> > std::istringstream is( record );
> >
> > if ( is_sorted( std::istream_iterator<int>( is ),
> > std::istream_iterator<int>() ) )
> > {
> > sorted.push_back( record );
> > }
> > else
> > {
> > non_sorted.push_back( record );
> > }
> > }
> >
> > std::cout << "Sorted" << std::endl;
> > for ( const auto &s : sorted ) std::cout << s << std::endl;
> >
> > std::cout << "\nNon-sorted" << std::endl;
> > for ( const auto &s : non_sorted ) std::cout << s << std::endl;
> >
> > return 0;
> > }
> >
> > If to enter for example the following sequences
> >
> > 1 2 3 4 5
> > 1 2 2 2 2
> > 1 2 3 5 4
> > 2 1 1 1 1
> >
> > then the program output will be
> >
> > Sorted
> > 1 2 3 4 5
> > 1 2 2 2 2
> >
> > Non-sorted
> > 1 2 3 5 4
> > 2 1 1 1 1
> >
> > As you see the code is very clear.
> >
> >
> > On Wednesday, March 18, 2015 at 7:34:38 PM UTC+3, Nevin ":-)" Liber
> wrote:
> >
> >> On 18 March 2015 at 10:38, Vlad from Moscow <vlad....@mail.ru
> >> <javascript:>> wrote:
> >>
> >>> Suprising behaviour has algorithm std::copy_n.
> >>>
> >>
> >> What surprising behavior is that?
> >>
> >>
> >>> As for performance difference for input iterators and forward
> iterators
> >>> then there is no any performance difference because the areas of
> >>> application of the algorithm with input iterators and forward
> iterators
> >>>
> >>> are ddifferent.
> >>>
> >>
> >> Sure they are, if one requires copying and the other doesn't. Yes,
> there
> >>
> >> is no algorithmic complexity difference, but there most certainly can
> be a
> >>
> >> practical difference, especially types that have nontrivial copy
> >> semantics.
> >>
> >>
> >>> It would be correct to compare the performance of the example I showed
> >>> with using the algorithm and the approach you are going to apply
> without
> >>>
> >>> using the algorithm. Can you show your approach? We will compare the
> >>> performance for example for a string that contains 10000 integers.
> >>>
> >>
> >> I don't see it as a terribly useful addition outside of that contrived
> >> example. After all, one calls is_sorted presumably to do something
> based
> >>
> >> on what it returns, which will typically means one already has a
> container
> >>
> >> of objects so that one can do multiple passes over the data, and that
> >> container has better than just input iterators.
> >>
> >> How, for instance, would you go and sort the string of numbers if
> >> is_sorted returns false?
> >>
> >>
> >>> I am sure it is a good proposal.
> >>>
> >>
> >> I am sure you are sure it is a good proposal. Best of luck writing it
> up
> >>
> >> and coming to Lenexa to present it.
> >> --
> >> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>>
> (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-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_903_526250948.1426704691300
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The algorithm itself can be rewritten in appropriate way. =
At present it is important to demonstrate the idea.:)<br><br>On Wednesday, =
March 18, 2015 at 9:46:54 PM UTC+3, Douglas Boffey wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;">I notice you use *first twice in the while loop without an inte=
rvening
<br>++first. That is not guaranteed to work!
<br>
<br>On 3/18/15, Vlad from Moscow <<a onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return true;" href=
=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=
=3D"rGSij-vfJ4UJ">vlad....@mail.ru</a>> wrote:
<br>> Specially for you I prepared a simple and at the same time elegant=
example
<br>>
<br>> Here you are
<br>>
<br>> #include <iostream>
<br>> #include <iterator>
<br>> #include <string>
<br>> #include <sstream>
<br>> #include <vector>
<br>>
<br>> template <class InputIterator>
<br>> bool is_sorted( InputIterator first, InputIterator last )
<br>> {
<br>> if ( first !=3D last )
<br>> {
<br>> typename std::iterator_traits<<wbr>InputIterator>::va=
lue_type prev( *first );
<br>>
<br>> while ( ++first !=3D last && !( *first < prev ) =
) prev =3D *first;
<br>> }
<br>>
<br>> return first =3D=3D last;
<br>> }
<br>>
<br>> int main()
<br>> {
<br>> std::vector<std::string> sorted;
<br>> std::vector<std::string> non_sorted;
<br>>
<br>> std::string record;
<br>> while ( std::getline( std::cin, record ) && !record.=
empty() )
<br>> {
<br>> std::istringstream is( record );
<br>>
<br>> if ( is_sorted( std::istream_iterator<int>( is ),
<br>> std=
::istream_iterator<int>() ) )
<br>> {
<br>> sorted.push_back( record );
<br>> }
<br>> else
<br>> {
<br>> non_sorted.push_back( record );
<br>> }
<br>> }
<br>>
<br>> std::cout << "Sorted" << std::endl;
<br>> for ( const auto &s : sorted ) std::cout << s <=
< std::endl;
<br>>
<br>> std::cout << "\nNon-sorted" << std::endl;
<br>> for ( const auto &s : non_sorted ) std::cout << s =
<< std::endl;
<br>>
<br>> return 0;
<br>> }
<br>>
<br>> If to enter for example the following sequences
<br>>
<br>> 1 2 3 4 5
<br>> 1 2 2 2 2
<br>> 1 2 3 5 4
<br>> 2 1 1 1 1
<br>>
<br>> then the program output will be
<br>>
<br>> Sorted
<br>> 1 2 3 4 5
<br>> 1 2 2 2 2
<br>>
<br>> Non-sorted
<br>> 1 2 3 5 4
<br>> 2 1 1 1 1
<br>>
<br>> As you see the code is very clear.
<br>>
<br>>
<br>> On Wednesday, March 18, 2015 at 7:34:38 PM UTC+3, Nevin ":-)" Libe=
r wrote:
<br>>
<br>>> On 18 March 2015 at 10:38, Vlad from Moscow <<a>vlad....@ma=
il.ru</a>
<br>>> <javascript:>> wrote:
<br>>>
<br>>>> Suprising behaviour has algorithm std::copy_n.
<br>>>>
<br>>>
<br>>> What surprising behavior is that?
<br>>>
<br>>>
<br>>>> As for performance difference for input iterators and forw=
ard iterators
<br>>>> then there is no any performance difference because the ar=
eas of
<br>>>> application of the algorithm with input iterators an=
d forward iterators
<br>>>>
<br>>>> are ddifferent.
<br>>>>
<br>>>
<br>>> Sure they are, if one requires copying and the other doesn't. =
Yes, there
<br>>>
<br>>> is no algorithmic complexity difference, but there most certai=
nly can be a
<br>>>
<br>>> practical difference, especially types that have nontrivial co=
py
<br>>> semantics.
<br>>>
<br>>>
<br>>>> It would be correct to compare the performance of the exam=
ple I showed
<br>>>> with using the algorithm and the approach you are going to=
apply without
<br>>>>
<br>>>> using the algorithm. Can you show your approach? We will c=
ompare the
<br>>>> performance for example for a string that contains 10000 i=
ntegers.
<br>>>>
<br>>>
<br>>> I don't see it as a terribly useful addition outside of that c=
ontrived
<br>>> example. After all, one calls is_sorted presumably to do=
something based
<br>>>
<br>>> on what it returns, which will typically means one already has=
a container
<br>>>
<br>>> of objects so that one can do multiple passes over the data, a=
nd that
<br>>> container has better than just input iterators.
<br>>>
<br>>> How, for instance, would you go and sort the string of numbers=
if
<br>>> is_sorted returns false?
<br>>>
<br>>>
<br>>>> I am sure it is a good proposal.
<br>>>>
<br>>>
<br>>> I am sure you are sure it is a good proposal. Best of lu=
ck writing it up
<br>>>
<br>>> and coming to Lenexa to present it.
<br>>> --
<br>>> Nevin ":-)" Liber <mailto:<a>ne...@eviloverlord=
..<wbr>com</a> <javascript:>> (847)
<br>>> 691-1404
<br>>>
<br>>
<br>> --
<br>>
<br>> ---
<br>> You received this message because you are subscribed to the Google=
Groups
<br>> "ISO C++ Standard - Future Proposals" group.
<br>> To unsubscribe from this group and stop receiving emails from it, =
send an
<br>> email to <a onmousedown=3D"this.href=3D'javascript:';return true;"=
onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" ta=
rget=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"rGSij-vfJ4UJ">std=
-proposal...@<wbr>isocpp.org</a>.
<br>> To post to this group, send email to <a onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscat=
ed-mailto=3D"rGSij-vfJ4UJ">std-pr...@isocpp.org</a>.
<br>> Visit this group at
<br>> <a onmousedown=3D"this.href=3D'http://groups.google.com/a/isocpp.o=
rg/group/std-proposals/';return true;" onclick=3D"this.href=3D'http://group=
s.google.com/a/isocpp.org/group/std-proposals/';return true;" href=3D"http:=
//groups.google.com/a/isocpp.org/group/std-proposals/" target=3D"_blank" re=
l=3D"nofollow">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>pr=
oposals/</a>.
<br>>
<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" 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_903_526250948.1426704691300--
------=_Part_902_1063615168.1426704691300--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Wed, 18 Mar 2015 14:56:53 -0400
Raw View
On Wed, Mar 18, 2015 at 2:46 PM, Douglas Boffey
<douglas.boffey@gmail.com> wrote:
> I notice you use *first twice in the while loop without an intervening
> ++first. That is not guaranteed to work!
>
Dereferencing twice is guaranteed to work for InputIterator.
That's why istream_iterator has a data member of T to
"remember" the seen value.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 19 Mar 2015 07:38:23 +0800
Raw View
--Apple-Mail=_852089F3-DE2C-45AA-B11D-21F20CD933DF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9303=E2=80=9319, at 1:19 AM, Vlad from Moscow <vlad.moscow@=
mail.ru> wrote:
>=20
> The behaviour of copy_n is suprising because in general case it is simply=
an invalid algorithm. You can not say beforehand whether selected n is cor=
rect or not. Using n means that in fact you are dealing with a forward iter=
ator where the end of the range is calculated like std::next( begin, n ).
copy_n adds efficiency with any sort of iterator besides random-access, bec=
ause that std::next call is avoided.
Just because you=E2=80=99re using a bidirectional iterator with n succeedin=
g elements, doesn=E2=80=99t mean you want to call std::next(it,n).
Also, in theory an InputIterator can support copy_n well by throwing on der=
eference of a singular value. (However, the standard stream iterators don=
=E2=80=99t do so.)
--=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/.
--Apple-Mail=_852089F3-DE2C-45AA-B11D-21F20CD933DF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9303=
=E2=80=9319, at 1:19 AM, Vlad from Moscow <<a href=3D"mailto:vlad.moscow=
@mail.ru" class=3D"">vlad.moscow@mail.ru</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><div class=3D""><div style=3D"font-family: Helvet=
ica; font-size: 12px; font-style: normal; font-variant: normal; font-weight=
: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-=
align: start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"=
">The behaviour of copy_n is suprising because in general case it is simply=
an invalid algorithm. You can not say beforehand whether selected n is cor=
rect or not. Using n means that in fact you are dealing with a fo=
rward iterator where the end of the range is calculated like std::next=
( begin, n ).</div></div></blockquote></div><br class=3D""><div class=3D"">=
<font face=3D"Courier" class=3D"">copy_n</font> adds efficiency with any so=
rt of iterator besides random-access, because that <font face=3D"Courier" c=
lass=3D"">std::next</font> call is avoided.</div><div class=3D""><br class=
=3D""></div><div class=3D"">Just because you=E2=80=99re using a bidirection=
al iterator with n succeeding elements, doesn=E2=80=99t mean you want to ca=
ll <font face=3D"Courier" class=3D"">std::next(it,n)</font>.</div><div clas=
s=3D""><br class=3D""></div><div class=3D"">Also, in theory an InputIterato=
r can support <font face=3D"Courier" class=3D"">copy_n</font> well by throw=
ing on dereference of a singular value. (However, the standard stream itera=
tors don=E2=80=99t do so.)</div></body></html>
<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 />
--Apple-Mail=_852089F3-DE2C-45AA-B11D-21F20CD933DF--
.
Author: "T. C." <rs2740@gmail.com>
Date: Wed, 18 Mar 2015 16:18:17 -0700 (PDT)
Raw View
------=_Part_1127_1295253403.1426720697873
Content-Type: multipart/alternative;
boundary="----=_Part_1128_282214582.1426720697874"
------=_Part_1128_282214582.1426720697874
Content-Type: text/plain; charset=UTF-8
There is precedent for having different requirements on the value type
depending on iterator category. unique_copy, for example
(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2439). Both
unique_copy and adjacent_difference support InputIterators, even though
both need to access two elements at once.
With two implementations and tag dispatching, implementing the proposed
change shouldn't affect the behavior or requirements for forward iterators
or stronger; this would be a pure extension.
On Wednesday, March 18, 2015 at 11:21:24 AM UTC-4, Nevin ":-)" Liber wrote:
>
> On 18 March 2015 at 01:44, Vlad from Moscow <vlad....@mail.ru
> <javascript:>> wrote:
>
>> David, your remark can be reflected in the description of the algorithm
>> in the requirements.
>>
>
> That wouldn't be a remark; copyable (and whether or not you need both
> CopyConstructible and CopyAssignable) would be a requirement. This would
> also mean that the algorithm could throw.
>
> Given the above surprising behavior (plus the performance difference
> between using InputIterators and ForwardIterators), such a proposal is
> unlikely to go anywhere. IMNSHO this is a solution in search of a problem.
> --
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> (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/.
------=_Part_1128_282214582.1426720697874
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">There is precedent for having different requirements on th=
e value type depending on iterator category. <font face=3D"courier new=
, monospace">unique_copy</font>, for example (http://www.open-std.org/jtc1/=
sc22/wg21/docs/lwg-active.html#2439). Both <span style=3D"font-family:=
'courier new', monospace;">unique_copy</span> and <span style=3D=
"font-family: 'courier new', monospace;">adjacent_difference </span>su=
pport InputIterators, even though both need to access two elements at once.=
<div><br></div><div>With two implementations and tag dispatching, implement=
ing the proposed change shouldn't affect the behavior or requirements for f=
orward iterators or stronger; this would be a pure extension.<div><br>On We=
dnesday, March 18, 2015 at 11:21:24 AM UTC-4, Nevin ":-)" Liber wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On 18 March 2015 a=
t 01:44, Vlad from Moscow <span dir=3D"ltr"><<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"i7nuwi67L-oJ" rel=3D"nofollow" onmo=
usedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
javascript:';return true;">vlad....@mail.ru</a>></span> wrote:<br><div><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">D=
avid, your remark can be reflected in the description of the algorithm in t=
he requirements.<br></div></blockquote><div><br></div><div>That wouldn't be=
a remark; copyable (and whether or not you need both CopyConstructible and=
CopyAssignable) would be a requirement. This would also mean that th=
e algorithm could throw.</div><div><br></div><div>Given the above surprisin=
g behavior (plus the performance difference between using InputIterators an=
d ForwardIterators), such a proposal is unlikely to go anywhere. IMNS=
HO this is a solution in search of a problem.</div></div>-- <br><div> =
Nevin ":-)" Liber <mailto:<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"i7nuwi67L-oJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';=
return true;">ne...@eviloverlord.com</a><wbr>> (847) 691-1404</div=
>
</div></div>
</blockquote></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 />
------=_Part_1128_282214582.1426720697874--
------=_Part_1127_1295253403.1426720697873--
.
Author: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Fri, 20 Mar 2015 22:14:47 -0700 (PDT)
Raw View
------=_Part_1463_2030033701.1426914887517
Content-Type: multipart/alternative;
boundary="----=_Part_1464_1703712818.1426914887517"
------=_Part_1464_1703712818.1426914887517
Content-Type: text/plain; charset=UTF-8
And I said the same.:)
It is just a polymorphism and function overloading. But it provides
more possibilities and covers more use cases. The example I showed is
enough interesting.
Of course the algorithm is less efficient for input iterators than for
forward iterators. Nevertheless it is more efficient than using some
intermediate container that only to check whether a sequence is sorted. And
it will not be suprising for a programmer. The programmer knows very well
why he prefered to use the algorithm with input iterators instead of some
container and the algorithm with forward iterators. The choice of the
programmer depends on the task and its context.
On Thursday, March 19, 2015 at 2:18:17 AM UTC+3, T. C. wrote:
> There is precedent for having different requirements on the value type
> depending on iterator category. unique_copy, for example (
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2439). Both
> unique_copy and adjacent_difference support InputIterators, even though
> both need to access two elements at once.
>
> With two implementations and tag dispatching, implementing the proposed
> change shouldn't affect the behavior or requirements for forward iterators
> or stronger; this would be a pure extension.
>
> On Wednesday, March 18, 2015 at 11:21:24 AM UTC-4, Nevin ":-)" Liber wrote:
>>
>> On 18 March 2015 at 01:44, Vlad from Moscow <vlad....@mail.ru> wrote:
>>
>>> David, your remark can be reflected in the description of the algorithm
>>> in the requirements.
>>>
>>
>> That wouldn't be a remark; copyable (and whether or not you need both
>> CopyConstructible and CopyAssignable) would be a requirement. This would
>> also mean that the algorithm could throw.
>>
>> Given the above surprising behavior (plus the performance difference
>> between using InputIterators and ForwardIterators), such a proposal is
>> unlikely to go anywhere. IMNSHO this is a solution in search of a problem.
>> --
>> Nevin ":-)" Liber <mailto:ne...@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/.
------=_Part_1464_1703712818.1426914887517
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>And I said the same.:) </div><div><br></div><div>It i=
s just a polymorphism and function overloading. But it provides more p=
ossibilities and covers more use cases. The example I showed is enough=
interesting.</div><div><br></div><div>Of course the algorithm is less effi=
cient for input iterators than for forward iterators. Nevertheless it is mo=
re efficient than using some intermediate container that only to check=
whether a sequence is sorted. And it will not be suprising for a programme=
r. The programmer knows very well why he prefered to use the algorithm with=
input iterators instead of some container and the algorithm with forward i=
terators. The choice of the programmer depends on the task and its context.=
<br><br>On Thursday, March 19, 2015 at 2:18:17 AM UTC+3, T. C. wrote:</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div dir=3D"ltr">There is precedent for having=
different requirements on the value type depending on iterator category.&n=
bsp;<font face=3D"courier new, monospace">unique_copy</font>, for example (=
<a onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fw=
ww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Flwg-active.html%232439\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNE9ROcsNMQvoj5doBk4n6QmczA44w';return true;" on=
click=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-s=
td.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Flwg-active.html%232439\46sa\75D\46sntz=
\0751\46usg\75AFQjCNE9ROcsNMQvoj5doBk4n6QmczA44w';return true;" href=3D"htt=
p://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2439" target=3D"_b=
lank" rel=3D"nofollow">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/lwg=
-active.<wbr>html#2439</a>). Both <span style=3D'font-family: "courier=
new",monospace;'>unique_copy</span> and <span style=3D'font-fami=
ly: "courier new",monospace;'>adjacent_<wbr>difference </span>support =
InputIterators, even though both need to access two elements at once.<div><=
br></div><div>With two implementations and tag dispatching, implementing th=
e proposed change shouldn't affect the behavior or requirements for forward=
iterators or stronger; this would be a pure extension.<div><br>On Wednesda=
y, March 18, 2015 at 11:21:24 AM UTC-4, Nevin ":-)" Liber wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1e=
x; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-le=
ft-style: solid;"><div dir=3D"ltr">On 18 March 2015 at 01:44, Vlad from Mos=
cow <span dir=3D"ltr"><<a rel=3D"nofollow">vlad....@mail.ru</a>></spa=
n> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-colo=
r: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><=
div dir=3D"ltr">David, your remark can be reflected in the description of t=
he algorithm in the requirements.<br></div></blockquote><div><br></div><div=
>That wouldn't be a remark; copyable (and whether or not you need both Copy=
Constructible and CopyAssignable) would be a requirement. This would =
also mean that the algorithm could throw.</div><div><br></div><div>Given th=
e above surprising behavior (plus the performance difference between using =
InputIterators and ForwardIterators), such a proposal is unlikely to go any=
where. IMNSHO this is a solution in search of a problem.</div></div>-=
- <br><div> Nevin ":-)" Liber <mailto:<a rel=3D"nofollow">ne.=
...@eviloverlord.com</a><wbr>> (847) 691-1404</div>
</div></div>
</blockquote></div></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_1464_1703712818.1426914887517--
------=_Part_1463_2030033701.1426914887517--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 24 Mar 2015 11:51:38 -0400
Raw View
--001a11c2bc881b0e7905120ac222
Content-Type: text/plain; charset=UTF-8
On Wed, Mar 18, 2015 at 7:18 PM, T. C. <rs2740@gmail.com> wrote:
> There is precedent for having different requirements on the value type
> depending on iterator category. unique_copy, for example (
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2439). Both
> unique_copy and adjacent_difference support InputIterators, even though
> both need to access two elements at once.
>
>
If those work on InputIterators, then I think you may have an argument for
is_sorted. But how many examples are there of functions that could work
with InputIterators, but don't?
Tony
--
---
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/.
--001a11c2bc881b0e7905120ac222
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Mar 18, 2015 at 7:18 PM, T. C. <span dir=3D"ltr"><<a href=3D=
"mailto:rs2740@gmail.com" target=3D"_blank">rs2740@gmail.com</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">There is precede=
nt for having different requirements on the value type depending on iterato=
r category.=C2=A0<font face=3D"courier new, monospace">unique_copy</font>, =
for example (<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-act=
ive.html#2439" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/doc=
s/lwg-active.html#2439</a>). Both=C2=A0<span style=3D"font-family:'cour=
ier new',monospace">unique_copy</span>=C2=A0and=C2=A0<span style=3D"fon=
t-family:'courier new',monospace">adjacent_difference=C2=A0</span>s=
upport InputIterators, even though both need to access two elements at once=
..<div><br></div></div></blockquote><div><br></div></div>If those work on In=
putIterators, then I think you may have an argument for is_sorted.=C2=A0 Bu=
t how many examples are there of functions that could work with InputIterat=
ors, but don't?<br><br></div><div class=3D"gmail_extra">Tony<br><br></d=
iv></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 />
--001a11c2bc881b0e7905120ac222--
.