Topic: iterators of contiguous containers should
Author: =?UTF-8?Q?Jonathan_M=c3=bcller?= <jonathanmueller.dev@gmail.com>
Date: Sat, 19 Aug 2017 10:13:12 +0200
Raw View
On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip wrote:
>
> I think iterators for contiguous containers
> (std::vector<T>,std::array<T>,std::basic_string<T>) should all be T*.
>
> template<typename T>
> class vector
> {
> public:
> using pointer = T*;
> using iterator = pointer;
> };
>
>
> It could solve following issues:
> 1.passing through C APIs
`c_api(vec.data(), vec.data() + vec.size())`
> 2.contiguous Iterator/Container issue(if Container<T>::iterator is
> T*, it is a contiguous container)
There could be a `contigouos_iterator_tag` but there's probably a reason
why there isn't.
> 3.converting one container to another easily
What do you mean?
> 4.easy to learn and understand
An iterator is a class that provides pointer like semantics.
I don't think that's difficult.
> 5. Reduce Compilation Time
Implementations are free to implement iterators as pointers, I think
libstdc++ does.
> 6. Easy to implement a Contiguous Container for libraries.
Libraries are free to implement iterators as pointers.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7d39ca11-4080-c291-998e-79fb5d86aa39%40gmail.com.
.
Author: euloanty@live.com
Date: Sat, 19 Aug 2017 01:25:21 -0700 (PDT)
Raw View
------=_Part_3716_745748057.1503131121470
Content-Type: multipart/alternative;
boundary="----=_Part_3717_1473886726.1503131121470"
------=_Part_3717_1473886726.1503131121470
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jonathan M=C3=BCller wrot=
e:
>
> On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip wrote:=
=20
> >=20
> > I think iterators for contiguous containers=20
> > (std::vector<T>,std::array<T>,std::basic_string<T>) should all be=
=20
> T*.=20
> >=20
> > template<typename T>=20
> > class vector=20
> > {=20
> > public:=20
> > using pointer =3D T*;=20
> > using iterator =3D pointer;=20
> > };=20
> >=20
> >=20
> > It could solve following issues:=20
> > 1.passing through C APIs=20
>
> `c_api(vec.data(), vec.data() + vec.size())`=20
>
> This code is horrible;
Why not just make C_API(vec.begin(),vec.end()); works?
For example:
std::copy suffers this issue a lot. ( I have to=20
std::copy(vec.data(),vec.data()+vec.size()) in order to maximize its=20
performance.)
> 2.contiguous Iterator/Container issue(if Container<T>::iterator is=20
> > T*, it is a contiguous container)=20
>
> There could be a `contigouos_iterator_tag` but there's probably a reason=
=20
> why there isn't.=20
>
> It is not able to implement. contiguous_iterator is still even draft sinc=
e=20
it is annoying on the semantics with smart pointers.=20
> > 3.converting one container to another easily=20
>
> What do you mean?=20
>
splice contiguous containers. (like gsl::span<T>)
=20
> > 4.easy to learn and understand=20
>
> =20
It is easy to learn and understand for implementing a iterator.=20
(implementing vector iterators is always annoying.)
An iterator is a class that provides pointer like semantics.=20
>
> I don't think that's difficult.=20
>
> 1.it is difficult when you try to pass parameters to C APIs.
2.pointers are also iterators. input iterator->forward=20
iterator->bidirectional iterator->random access iterator->pointer
> 5. Reduce Compilation Time=20
>
> Implementations are free to implement iterators as pointers, I think=20
> libstdc++ does.=20
>
no. libstdc++ doesn't.
=20
> > 6. Easy to implement a Contiguous Container for libraries.=20
>
> Libraries are free to implement iterators as pointers.=20
>
That is the problem. Library should have less freedom when it comes to=20
different interfaces.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d04ec47e-034e-4bf0-97c1-2908de96d11b%40isocpp.or=
g.
------=_Part_3717_1473886726.1503131121470
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, =
Jonathan M=C3=BCller wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On =
Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 I think iterators for contiguous containers
<br>> =C2=A0 =C2=A0 (std::vector<T>,std::array<T>,<wbr>std::=
basic_string<T>) should all be T*.
<br>>=20
<br>> =C2=A0 =C2=A0 template<typename T>
<br>> =C2=A0 =C2=A0 class vector
<br>> =C2=A0 =C2=A0 {
<br>> =C2=A0 =C2=A0 public:
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using pointer =3D T*;
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using iterator =3D pointe=
r;
<br>> =C2=A0 =C2=A0 };
<br>>=20
<br>>=20
<br>> =C2=A0 =C2=A0 It could solve following issues:
<br>> =C2=A0 =C2=A0 1.passing through C APIs
<br>
<br>`c_api(vec.data(), vec.data() + vec.size())`
<br>
<br></blockquote><div>This code is horrible;</div><div>Why not just make C_=
API(vec.begin(),vec.end()); works?</div><div><br></div><div>For example:</d=
iv><div>std::copy suffers this issue a lot. ( I have to std::copy(vec.data(=
),vec.data()+vec.size()) in order to maximize its performance.)</div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> =C2=A0 =C2=A0 2.=
contiguous Iterator/Container issue(if Container<T>::iterator is
<br>> =C2=A0 =C2=A0 T*, it is a contiguous container)
<br>
<br>There could be a `contigouos_iterator_tag` but there's probably a r=
eason=20
<br>why there isn't.
<br>
<br></blockquote><div>It is not able to implement. contiguous_iterator is s=
till even draft since it is annoying on the semantics with smart pointers.=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> =C2=A0 =C2=A0=
3.converting one container to another easily
<br>
<br>What do you mean?=C2=A0<br></blockquote><div>splice contiguous containe=
rs. (like gsl::span<T>)</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">> =C2=A0 =C2=A0 4.easy to learn and understand
<br>
<br></blockquote><div>=C2=A0</div><div>It is easy to learn and understand f=
or implementing a iterator. (implementing vector iterators is always annoyi=
ng.)</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">An it=
erator is a class that provides pointer like semantics.
<br>
<br>I don't think that's difficult.
<br>
<br></blockquote><div>1.it is difficult when you try to pass parameters to =
C APIs.</div><div>2.pointers are also iterators. input iterator->forward=
iterator->bidirectional iterator->random access iterator->pointer=
</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">=C2=A0> 5. Reduce Compilation Time
<br>
<br>Implementations are free to implement iterators as pointers, I think=20
<br>libstdc++ does.=C2=A0<br></blockquote><div>no. libstdc++ doesn't.</=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=C2=A0>=
; 6. Easy to implement a Contiguous Container for libraries.
<br>
<br>Libraries are free to implement iterators as pointers.
<br></blockquote><div><br></div><div>That is the problem. Library should ha=
ve less freedom when it comes to different interfaces.=C2=A0</div><div>=C2=
=A0</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d04ec47e-034e-4bf0-97c1-2908de96d11b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d04ec47e-034e-4bf0-97c1-2908de96d11b=
%40isocpp.org</a>.<br />
------=_Part_3717_1473886726.1503131121470--
------=_Part_3716_745748057.1503131121470--
.
Author: euloanty@live.com
Date: Sat, 19 Aug 2017 01:29:14 -0700 (PDT)
Raw View
------=_Part_3692_1029078033.1503131354817
Content-Type: multipart/alternative;
boundary="----=_Part_3693_281527540.1503131354817"
------=_Part_3693_281527540.1503131354817
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Debug mode iterators are always not standard and should be broken.
For example, debug mode iterators of std::list are O(n) performance(which=
=20
should be O(1) from the standard.)
On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jonathan M=C3=BCller wrot=
e:
> On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip wrote:=
=20
> >=20
> > I think iterators for contiguous containers=20
> > (std::vector<T>,std::array<T>,std::basic_string<T>) should all be=
=20
> T*.=20
> >=20
> > template<typename T>=20
> > class vector=20
> > {=20
> > public:=20
> > using pointer =3D T*;=20
> > using iterator =3D pointer;=20
> > };=20
> >=20
> >=20
> > It could solve following issues:=20
> > 1.passing through C APIs=20
>
> `c_api(vec.data(), vec.data() + vec.size())`=20
>
> > 2.contiguous Iterator/Container issue(if Container<T>::iterator is=
=20
> > T*, it is a contiguous container)=20
>
> There could be a `contigouos_iterator_tag` but there's probably a reason=
=20
> why there isn't.=20
>
> > 3.converting one container to another easily=20
>
> What do you mean?=20
>
> > 4.easy to learn and understand=20
>
> An iterator is a class that provides pointer like semantics.=20
>
> I don't think that's difficult.=20
>
> > 5. Reduce Compilation Time=20
>
> Implementations are free to implement iterators as pointers, I think=20
> libstdc++ does.=20
>
> > 6. Easy to implement a Contiguous Container for libraries.=20
>
> Libraries are free to implement iterators as pointers.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2911a548-b7d3-43ef-b8e0-53245ff8f538%40isocpp.or=
g.
------=_Part_3693_281527540.1503131354817
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Debug mode iterators are always not standard and shou=
ld be broken.</div><div><br></div><div>For example, debug mode iterators of=
std::list are O(n) performance(which should be O(1) from the standard.)<br=
><br>On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jonathan M=C3=BCller=
wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Saturday, Augu=
st 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 I think iterators for contiguous containers
<br>> =C2=A0 =C2=A0 (std::vector<T>,std::array<T>,<wbr>std::=
basic_string<T>) should all be T*.
<br>>=20
<br>> =C2=A0 =C2=A0 template<typename T>
<br>> =C2=A0 =C2=A0 class vector
<br>> =C2=A0 =C2=A0 {
<br>> =C2=A0 =C2=A0 public:
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using pointer =3D T*;
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using iterator =3D pointe=
r;
<br>> =C2=A0 =C2=A0 };
<br>>=20
<br>>=20
<br>> =C2=A0 =C2=A0 It could solve following issues:
<br>> =C2=A0 =C2=A0 1.passing through C APIs
<br>
<br>`c_api(vec.data(), vec.data() + vec.size())`
<br>
<br>> =C2=A0 =C2=A0 2.contiguous Iterator/Container issue(if Container&l=
t;T>::iterator is
<br>> =C2=A0 =C2=A0 T*, it is a contiguous container)
<br>
<br>There could be a `contigouos_iterator_tag` but there's probably a r=
eason=20
<br>why there isn't.
<br>
<br>> =C2=A0 =C2=A0 3.converting one container to another easily
<br>
<br>What do you mean?
<br>
<br>> =C2=A0 =C2=A0 4.easy to learn and understand
<br>
<br>An iterator is a class that provides pointer like semantics.
<br>
<br>I don't think that's difficult.
<br>
<br>=C2=A0> 5. Reduce Compilation Time
<br>
<br>Implementations are free to implement iterators as pointers, I think=20
<br>libstdc++ does.
<br>
<br>=C2=A0> 6. Easy to implement a Contiguous Container for libraries.
<br>
<br>Libraries are free to implement iterators as pointers.
<br>
<br></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3-43ef-b8e0-53245ff8f538%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3-43ef-b8e0-53245ff8f538=
%40isocpp.org</a>.<br />
------=_Part_3693_281527540.1503131354817--
------=_Part_3692_1029078033.1503131354817--
.
Author: =?UTF-8?Q?Jonathan_M=c3=bcller?= <jonathanmueller.dev@gmail.com>
Date: Sat, 19 Aug 2017 10:30:34 +0200
Raw View
On 19.08.2017 10:25, euloanty@live.com wrote:
>
>
> This code is horrible;
> Why not just make C_API(vec.begin(),vec.end()); works?
>
> For example:
> std::copy suffers this issue a lot. ( I have to
> std::copy(vec.data(),vec.data()+vec.size()) in order to maximize its
> performance.)
What about `C_API(vec.begin_ptr(), vec.end_ptr())`?
>
> > 2.contiguous Iterator/Container issue(if
> Container<T>::iterator is
> > T*, it is a contiguous container)
>
> There could be a `contigouos_iterator_tag` but there's probably a
> reason
> why there isn't.
>
> It is not able to implement. contiguous_iterator is still even draft
> since it is annoying on the semantics with smart pointers.
It can be implemented, tag is manually specified by writer of iterator
class.
> Libraries are free to implement iterators as pointers.
>
>
> That is the problem. Library should have less freedom when it comes to
> different interfaces.
But it is not a different interface, it is the same interface.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/afc19bb5-1ef4-4a8b-8015-05be1dda48df%40gmail.com.
.
Author: euloanty@live.com
Date: Sat, 19 Aug 2017 01:40:12 -0700 (PDT)
Raw View
------=_Part_3813_930282938.1503132012795
Content-Type: multipart/alternative;
boundary="----=_Part_3814_966647359.1503132012795"
------=_Part_3814_966647359.1503132012795
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Saturday, August 19, 2017 at 4:30:38 PM UTC+8, Jonathan M=C3=BCller wrot=
e:
>
> On 19.08.2017 10:25, eulo...@live.com <javascript:> wrote:=20
> >=20
> >=20
> > This code is horrible;=20
> > Why not just make C_API(vec.begin(),vec.end()); works?=20
> >=20
> > For example:=20
> > std::copy suffers this issue a lot. ( I have to=20
> > std::copy(vec.data(),vec.data()+vec.size()) in order to maximize its=20
> > performance.)=20
>
> What about `C_API(vec.begin_ptr(), vec.end_ptr())`?=20
>
> How could you insert/erase an element from pointers which are got from=20
begin_ptr,end_ptr??? It still messed up.
auto p (vec.begin_ptr()+3);
vec.erase(p);???? compilation error.
>=20
> > > 2.contiguous Iterator/Container issue(if=20
> > Container<T>::iterator is=20
> > > T*, it is a contiguous container)=20
> >=20
> > There could be a `contigouos_iterator_tag` but there's probably a=
=20
> > reason=20
> > why there isn't.=20
> >=20
> > It is not able to implement. contiguous_iterator is still even draft=20
> > since it is annoying on the semantics with smart pointers.=20
>
> It can be implemented, tag is manually specified by writer of iterator=20
> class.=20
>
> It cant. Since its semantics are always messed up with smart pointers.=20
That is why C++ 17 does not have contiguous containers/contiguous iterators=
..
=20
> > Libraries are free to implement iterators as pointers.=20
> >=20
> >=20
> > That is the problem. Library should have less freedom when it comes to=
=20
> > different interfaces.=20
>
> But it is not a different interface, it is the same interface.=20
>
It is difference interfaces.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c946f28b-3d41-4cb8-9598-b76fda66a313%40isocpp.or=
g.
------=_Part_3814_966647359.1503132012795
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, August 19, 2017 at 4:30:38 PM UTC+8, =
Jonathan M=C3=BCller wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On =
19.08.2017 10:25, <a onmousedown=3D"this.href=3D'javascript:';retur=
n true;" onclick=3D"this.href=3D'javascript:';return true;" href=3D=
"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"M=
QiK6rGJCgAJ">eulo...@live.com</a> wrote:
<br>>
<br>>=20
<br>> This code is horrible;
<br>> Why not just make C_API(vec.begin(),vec.end()); works?
<br>>=20
<br>> For example:
<br>> std::copy suffers this issue a lot. ( I have to=20
<br>> std::copy(vec.data(),vec.data(<wbr>)+vec.size()) in order to maxim=
ize its=20
<br>> performance.)
<br>
<br>What about `C_API(vec.begin_ptr(), vec.end_ptr())`?
<br><br></blockquote><div>How could you insert/erase an element from pointe=
rs which are got from begin_ptr,end_ptr???=C2=A0 It still messed up.</div><=
div><br></div><div>auto p (vec.begin_ptr()+3);</div><div>vec.erase(p);???? =
compilation error.</div><div><br></div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">>=20
<br>> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 2.contiguous Iterator/Conta=
iner issue(if
<br>> =C2=A0 =C2=A0 Container<T>::iterator is
<br>> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 T*, it is a contiguous cont=
ainer)
<br>>=20
<br>> =C2=A0 =C2=A0 There could be a `contigouos_iterator_tag` but there=
's probably a
<br>> =C2=A0 =C2=A0 reason
<br>> =C2=A0 =C2=A0 why there isn't.
<br>>=20
<br>> It is not able to implement. contiguous_iterator is still even dra=
ft=20
<br>> since it is annoying on the semantics with smart pointers.
<br>
<br>It can be implemented, tag is manually specified by writer of iterator=
=20
<br>class.
<br>
<br></blockquote><div>It cant. Since its semantics are always messed up wit=
h smart pointers. That is why C++ 17 does not have contiguous containers/co=
ntiguous iterators.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">> =C2=A0 =C2=A0 Libraries are free to implement iterators as=
pointers.
<br>>=20
<br>>=20
<br>> That is the problem. Library should have less freedom when it come=
s to=20
<br>> different interfaces.
<br>
<br>But it is not a different interface, it is the same interface.
<br></blockquote><div>It is difference interfaces.=C2=A0</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c946f28b-3d41-4cb8-9598-b76fda66a313%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c946f28b-3d41-4cb8-9598-b76fda66a313=
%40isocpp.org</a>.<br />
------=_Part_3814_966647359.1503132012795--
------=_Part_3813_930282938.1503132012795--
.
Author: euloanty@live.com
Date: Sat, 19 Aug 2017 01:41:47 -0700 (PDT)
Raw View
------=_Part_2029_1383559119.1503132108028
Content-Type: multipart/alternative;
boundary="----=_Part_2030_719952392.1503132108029"
------=_Part_2030_719952392.1503132108029
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3884.pdf
Like this :
std::pointer_from
pointer_from smart pointers???
On Saturday, August 19, 2017 at 4:30:38 PM UTC+8, Jonathan M=C3=BCller wrot=
e:
> On 19.08.2017 10:25, eulo...@live.com <javascript:> wrote:=20
> >=20
> >=20
> > This code is horrible;=20
> > Why not just make C_API(vec.begin(),vec.end()); works?=20
> >=20
> > For example:=20
> > std::copy suffers this issue a lot. ( I have to=20
> > std::copy(vec.data(),vec.data()+vec.size()) in order to maximize its=20
> > performance.)=20
>
> What about `C_API(vec.begin_ptr(), vec.end_ptr())`?=20
>
> >=20
> > > 2.contiguous Iterator/Container issue(if=20
> > Container<T>::iterator is=20
> > > T*, it is a contiguous container)=20
> >=20
> > There could be a `contigouos_iterator_tag` but there's probably a=
=20
> > reason=20
> > why there isn't.=20
> >=20
> > It is not able to implement. contiguous_iterator is still even draft=20
> > since it is annoying on the semantics with smart pointers.=20
>
> It can be implemented, tag is manually specified by writer of iterator=20
> class.=20
>
> > Libraries are free to implement iterators as pointers.=20
> >=20
> >=20
> > That is the problem. Library should have less freedom when it comes to=
=20
> > different interfaces.=20
>
> But it is not a different interface, it is the same interface.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7f03b0b1-7af2-44f1-b427-dc8980a7f28f%40isocpp.or=
g.
------=_Part_2030_719952392.1503132108029
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n=
3884.pdf</div><div><br></div><div><br></div><div>Like this :</div><div><br>=
</div><div>std::pointer_from</div><div><br></div><div>pointer_from smart po=
inters???<br><br>On Saturday, August 19, 2017 at 4:30:38 PM UTC+8, Jonathan=
M=C3=BCller wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 19=
..08.2017 10:25, <a onmousedown=3D"this.href=3D'javascript:';return =
true;" onclick=3D"this.href=3D'javascript:';return true;" href=3D"j=
avascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"MQi=
K6rGJCgAJ">eulo...@live.com</a> wrote:
<br>>
<br>>=20
<br>> This code is horrible;
<br>> Why not just make C_API(vec.begin(),vec.end()); works?
<br>>=20
<br>> For example:
<br>> std::copy suffers this issue a lot. ( I have to=20
<br>> std::copy(vec.data(),vec.data(<wbr>)+vec.size()) in order to maxim=
ize its=20
<br>> performance.)
<br>
<br>What about `C_API(vec.begin_ptr(), vec.end_ptr())`?
<br>
<br>>=20
<br>> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 2.contiguous Iterator/Conta=
iner issue(if
<br>> =C2=A0 =C2=A0 Container<T>::iterator is
<br>> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 T*, it is a contiguous cont=
ainer)
<br>>=20
<br>> =C2=A0 =C2=A0 There could be a `contigouos_iterator_tag` but there=
's probably a
<br>> =C2=A0 =C2=A0 reason
<br>> =C2=A0 =C2=A0 why there isn't.
<br>>=20
<br>> It is not able to implement. contiguous_iterator is still even dra=
ft=20
<br>> since it is annoying on the semantics with smart pointers.
<br>
<br>It can be implemented, tag is manually specified by writer of iterator=
=20
<br>class.
<br>
<br>> =C2=A0 =C2=A0 Libraries are free to implement iterators as pointer=
s.
<br>>=20
<br>>=20
<br>> That is the problem. Library should have less freedom when it come=
s to=20
<br>> different interfaces.
<br>
<br>But it is not a different interface, it is the same interface.
<br></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7f03b0b1-7af2-44f1-b427-dc8980a7f28f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7f03b0b1-7af2-44f1-b427-dc8980a7f28f=
%40isocpp.org</a>.<br />
------=_Part_2030_719952392.1503132108029--
------=_Part_2029_1383559119.1503132108028--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Sat, 19 Aug 2017 08:48:26 +0000
Raw View
--94eb2c18f1cab3d91b0557174f77
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Failing the complexity requirements vs not compiling at all are two
*very* different
things. Your reasoning will not get past LEWG.
On Sat, Aug 19, 2017 at 10:29 AM <euloanty@live.com> wrote:
> Debug mode iterators are always not standard and should be broken.
>
> For example, debug mode iterators of std::list are O(n) performance(which
> should be O(1) from the standard.)
>
>
> On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jonathan M=C3=BCller wr=
ote:
>
>> On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip wrote:
>> >
>> > I think iterators for contiguous containers
>> > (std::vector<T>,std::array<T>,std::basic_string<T>) should all be
>> T*.
>> >
>> > template<typename T>
>> > class vector
>> > {
>> > public:
>> > using pointer =3D T*;
>> > using iterator =3D pointer;
>> > };
>> >
>> >
>> > It could solve following issues:
>> > 1.passing through C APIs
>>
>> `c_api(vec.data(), vec.data() + vec.size())`
>>
>> > 2.contiguous Iterator/Container issue(if Container<T>::iterator is
>> > T*, it is a contiguous container)
>>
>> There could be a `contigouos_iterator_tag` but there's probably a reason
>> why there isn't.
>>
>> > 3.converting one container to another easily
>>
>> What do you mean?
>>
>> > 4.easy to learn and understand
>>
>> An iterator is a class that provides pointer like semantics.
>>
>> I don't think that's difficult.
>>
>> > 5. Reduce Compilation Time
>>
>> Implementations are free to implement iterators as pointers, I think
>> libstdc++ does.
>>
>> > 6. Easy to implement a Contiguous Container for libraries.
>>
>> Libraries are free to implement iterators as pointers.
>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d=
3-43ef-b8e0-53245ff8f538%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548-b7=
d3-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAPCFJdQijsg1WXwyG%2BeVeVWbrvFOPT77y%2BTwSk9Darq=
tdMSuPA%40mail.gmail.com.
--94eb2c18f1cab3d91b0557174f77
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Failing the complexity requirements vs not compiling at al=
l are two <i>very</i>=C2=A0different things. Your reasoning will not get pa=
st LEWG.<br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 19,=
2017 at 10:29 AM <<a href=3D"mailto:euloanty@live.com">euloanty@live.co=
m</a>> wrote:<br></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>Debug mode iterators are always not standard and should be broken.</div=
><div><br></div><div>For example, debug mode iterators of std::list are O(n=
) performance(which should be O(1) from the standard.)</div></div><div dir=
=3D"ltr"><div><br><br>On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jon=
athan M=C3=BCller wrote:</div></div><div dir=3D"ltr"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq=
mabmip wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 I think iterators for contiguous containers
<br>> =C2=A0 =C2=A0 (std::vector<T>,std::array<T>,std::basic=
_string<T>) should all be T*.
<br>>=20
<br>> =C2=A0 =C2=A0 template<typename T>
<br>> =C2=A0 =C2=A0 class vector
<br>> =C2=A0 =C2=A0 {
<br>> =C2=A0 =C2=A0 public:
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using pointer =3D T*;
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using iterator =3D pointe=
r;
<br>> =C2=A0 =C2=A0 };
<br>>=20
<br>>=20
<br>> =C2=A0 =C2=A0 It could solve following issues:
<br>> =C2=A0 =C2=A0 1.passing through C APIs
<br>
<br>`c_api(vec.data(), vec.data() + vec.size())`
<br>
<br>> =C2=A0 =C2=A0 2.contiguous Iterator/Container issue(if Container&l=
t;T>::iterator is
<br>> =C2=A0 =C2=A0 T*, it is a contiguous container)
<br>
<br>There could be a `contigouos_iterator_tag` but there's probably a r=
eason=20
<br>why there isn't.
<br>
<br>> =C2=A0 =C2=A0 3.converting one container to another easily
<br>
<br>What do you mean?
<br>
<br>> =C2=A0 =C2=A0 4.easy to learn and understand
<br>
<br>An iterator is a class that provides pointer like semantics.
<br>
<br>I don't think that's difficult.
<br>
<br>=C2=A0> 5. Reduce Compilation Time
<br>
<br>Implementations are free to implement iterators as pointers, I think=20
<br>libstdc++ does.
<br>
<br>=C2=A0> 6. Easy to implement a Contiguous Container for libraries.
<br>
<br>Libraries are free to implement iterators as pointers.
<br>
<br></blockquote></div>
<p></p>
-- <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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3-43ef-b8e0-53245ff8f538%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3-=
43ef-b8e0-53245ff8f538%40isocpp.org</a>.<br>
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQijsg1WXwyG%2BeVeVWbrvFOPT77y%=
2BTwSk9DarqtdMSuPA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQijsg1=
WXwyG%2BeVeVWbrvFOPT77y%2BTwSk9DarqtdMSuPA%40mail.gmail.com</a>.<br />
--94eb2c18f1cab3d91b0557174f77--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Sat, 19 Aug 2017 08:53:31 +0000
Raw View
--f403045f9084df01380557176162
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Also as a general note: your approach is way too emotional and not rational
enough to ever get treated seriously by LEWG. If you want something like
this (which I would not expect to get through LEWG because debug iterators,
as I've said), you need to make a more sensible rationale than "it's a
different interface", "this code is horrible" (without giving a *single* re=
ason
for why it is horrible) (also your `std::copy` example needs an actual
example when you show how faster that is) or "debug iterators are
pointless" (this claim is in itself incredibly laughable).
On Sat, Aug 19, 2017 at 10:48 AM Micha=C5=82 Dominiak <griwes@griwes.info> =
wrote:
> Failing the complexity requirements vs not compiling at all are two *very=
* different
> things. Your reasoning will not get past LEWG.
>
>
> On Sat, Aug 19, 2017 at 10:29 AM <euloanty@live.com> wrote:
>
>> Debug mode iterators are always not standard and should be broken.
>>
>> For example, debug mode iterators of std::list are O(n) performance(whic=
h
>> should be O(1) from the standard.)
>>
>>
>> On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jonathan M=C3=BCller w=
rote:
>>
>>> On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip wrote:
>>> >
>>> > I think iterators for contiguous containers
>>> > (std::vector<T>,std::array<T>,std::basic_string<T>) should all be
>>> T*.
>>> >
>>> > template<typename T>
>>> > class vector
>>> > {
>>> > public:
>>> > using pointer =3D T*;
>>> > using iterator =3D pointer;
>>> > };
>>> >
>>> >
>>> > It could solve following issues:
>>> > 1.passing through C APIs
>>>
>>> `c_api(vec.data(), vec.data() + vec.size())`
>>>
>>> > 2.contiguous Iterator/Container issue(if Container<T>::iterator i=
s
>>> > T*, it is a contiguous container)
>>>
>>> There could be a `contigouos_iterator_tag` but there's probably a reaso=
n
>>> why there isn't.
>>>
>>> > 3.converting one container to another easily
>>>
>>> What do you mean?
>>>
>>> > 4.easy to learn and understand
>>>
>>> An iterator is a class that provides pointer like semantics.
>>>
>>> I don't think that's difficult.
>>>
>>> > 5. Reduce Compilation Time
>>>
>>> Implementations are free to implement iterators as pointers, I think
>>> libstdc++ does.
>>>
>>> > 6. Easy to implement a Contiguous Container for libraries.
>>>
>>> Libraries are free to implement iterators as pointers.
>>>
>>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548-b7=
d3-43ef-b8e0-53245ff8f538%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548-b=
7d3-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAPCFJdRzOQovCrc%2BFHdqWWGB-bneq4M6rvfqFG721v_MF=
BZoZQ%40mail.gmail.com.
--f403045f9084df01380557176162
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Also as a general note: your approach is way too emotional=
and not rational enough to ever get treated seriously by LEWG. If you want=
something like this (which I would not expect to get through LEWG because =
debug iterators, as I've said), you need to make a more sensible ration=
ale than "it's a different interface", "this code is hor=
rible" (without giving a <i>single</i>=C2=A0reason for why it is horri=
ble) (also your `std::copy` example needs an actual example when you show h=
ow faster that is) or "debug iterators are pointless" (this claim=
is in itself incredibly laughable).</div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr">On Sat, Aug 19, 2017 at 10:48 AM Micha=C5=82 Dominiak <<a=
href=3D"mailto:griwes@griwes.info">griwes@griwes.info</a>> wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Failing the complexity =
requirements vs not compiling at all are two <i>very</i>=C2=A0different thi=
ngs. Your reasoning will not get past LEWG.</div><div dir=3D"ltr"><br><br><=
div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 19, 2017 at 10:29 AM=
<<a href=3D"mailto:euloanty@live.com" target=3D"_blank">euloanty@live.c=
om</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div>Debug mode iterators are always not standard and should be broken.</di=
v><div><br></div><div>For example, debug mode iterators of std::list are O(=
n) performance(which should be O(1) from the standard.)</div></div><div dir=
=3D"ltr"><div><br><br>On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jon=
athan M=C3=BCller wrote:</div></div><div dir=3D"ltr"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq=
mabmip wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 I think iterators for contiguous containers
<br>> =C2=A0 =C2=A0 (std::vector<T>,std::array<T>,std::basic=
_string<T>) should all be T*.
<br>>=20
<br>> =C2=A0 =C2=A0 template<typename T>
<br>> =C2=A0 =C2=A0 class vector
<br>> =C2=A0 =C2=A0 {
<br>> =C2=A0 =C2=A0 public:
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using pointer =3D T*;
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using iterator =3D pointe=
r;
<br>> =C2=A0 =C2=A0 };
<br>>=20
<br>>=20
<br>> =C2=A0 =C2=A0 It could solve following issues:
<br>> =C2=A0 =C2=A0 1.passing through C APIs
<br>
<br>`c_api(vec.data(), vec.data() + vec.size())`
<br>
<br>> =C2=A0 =C2=A0 2.contiguous Iterator/Container issue(if Container&l=
t;T>::iterator is
<br>> =C2=A0 =C2=A0 T*, it is a contiguous container)
<br>
<br>There could be a `contigouos_iterator_tag` but there's probably a r=
eason=20
<br>why there isn't.
<br>
<br>> =C2=A0 =C2=A0 3.converting one container to another easily
<br>
<br>What do you mean?
<br>
<br>> =C2=A0 =C2=A0 4.easy to learn and understand
<br>
<br>An iterator is a class that provides pointer like semantics.
<br>
<br>I don't think that's difficult.
<br>
<br>=C2=A0> 5. Reduce Compilation Time
<br>
<br>Implementations are free to implement iterators as pointers, I think=20
<br>libstdc++ does.
<br>
<br>=C2=A0> 6. Easy to implement a Contiguous Container for libraries.
<br>
<br>Libraries are free to implement iterators as pointers.
<br>
<br></blockquote></div>
<p></p>
-- <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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3-43ef-b8e0-53245ff8f538%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3-=
43ef-b8e0-53245ff8f538%40isocpp.org</a>.<br>
</blockquote></div></div></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRzOQovCrc%2BFHdqWWGB-bneq4M6rv=
fqFG721v_MFBZoZQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRzOQovCr=
c%2BFHdqWWGB-bneq4M6rvfqFG721v_MFBZoZQ%40mail.gmail.com</a>.<br />
--f403045f9084df01380557176162--
.
Author: euloanty@live.com
Date: Sat, 19 Aug 2017 02:02:38 -0700 (PDT)
Raw View
------=_Part_3783_487569982.1503133358741
Content-Type: multipart/alternative;
boundary="----=_Part_3784_998332966.1503133358741"
------=_Part_3784_998332966.1503133358741
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Nope.
1.You can still use "debug mode" iterators when you need. (debug iterators=
=20
for iterators. pointers for none debug mode)
2.vector pointer is the same type as its allocator pointer. If you need=20
this, you can define your debug mode in allocator.
On Saturday, August 19, 2017 at 4:53:43 PM UTC+8, Micha=C5=82 Dominiak wrot=
e:
> Also as a general note: your approach is way too emotional and not=20
> rational enough to ever get treated seriously by LEWG. If you want=20
> something like this (which I would not expect to get through LEWG because=
=20
> debug iterators, as I've said), you need to make a more sensible rational=
e=20
> than "it's a different interface", "this code is horrible" (without givin=
g=20
> a *single* reason for why it is horrible) (also your `std::copy` example=
=20
> needs an actual example when you show how faster that is) or "debug=20
> iterators are pointless" (this claim is in itself incredibly laughable).
>
> On Sat, Aug 19, 2017 at 10:48 AM Micha=C5=82 Dominiak <gri...@griwes.info=
=20
> <javascript:>> wrote:
>
>> Failing the complexity requirements vs not compiling at all are two=20
>> *very* different things. Your reasoning will not get past LEWG.
>>
>>
>> On Sat, Aug 19, 2017 at 10:29 AM <eulo...@live.com <javascript:>> wrote:
>>
>>> Debug mode iterators are always not standard and should be broken.
>>>
>>> For example, debug mode iterators of std::list are O(n)=20
>>> performance(which should be O(1) from the standard.)
>>>
>>>
>>> On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jonathan M=C3=BCller =
wrote:
>>>
>>>> On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip wrote=
:=20
>>>> >=20
>>>> > I think iterators for contiguous containers=20
>>>> > (std::vector<T>,std::array<T>,std::basic_string<T>) should all b=
e=20
>>>> T*.=20
>>>> >=20
>>>> > template<typename T>=20
>>>> > class vector=20
>>>> > {=20
>>>> > public:=20
>>>> > using pointer =3D T*;=20
>>>> > using iterator =3D pointer;=20
>>>> > };=20
>>>> >=20
>>>> >=20
>>>> > It could solve following issues:=20
>>>> > 1.passing through C APIs=20
>>>>
>>>> `c_api(vec.data(), vec.data() + vec.size())`=20
>>>>
>>>> > 2.contiguous Iterator/Container issue(if Container<T>::iterator=
=20
>>>> is=20
>>>> > T*, it is a contiguous container)=20
>>>>
>>>> There could be a `contigouos_iterator_tag` but there's probably a=20
>>>> reason=20
>>>> why there isn't.=20
>>>>
>>>> > 3.converting one container to another easily=20
>>>>
>>>> What do you mean?=20
>>>>
>>>> > 4.easy to learn and understand=20
>>>>
>>>> An iterator is a class that provides pointer like semantics.=20
>>>>
>>>> I don't think that's difficult.=20
>>>>
>>>> > 5. Reduce Compilation Time=20
>>>>
>>>> Implementations are free to implement iterators as pointers, I think=
=20
>>>> libstdc++ does.=20
>>>>
>>>> > 6. Easy to implement a Contiguous Container for libraries.=20
>>>>
>>>> Libraries are free to implement iterators as pointers.=20
>>>>
>>>> --=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@isocpp.org <javascript:>.
>>> To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..
>>> To view this discussion on the web visit=20
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548-b=
7d3-43ef-b8e0-53245ff8f538%40isocpp.org=20
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548-=
b7d3-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6478b7e0-ae07-48e5-ae65-3457f8bab76f%40isocpp.or=
g.
------=_Part_3784_998332966.1503133358741
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Nope.</div><div>1.You can still use "debug mode&=
quot; iterators when you need. (debug iterators for iterators. pointers for=
none debug mode)<br></div><div>2.vector pointer is the same type as its al=
locator pointer. If you need this, you can define your debug mode in alloca=
tor.</div><div><br>On Saturday, August 19, 2017 at 4:53:43 PM UTC+8, Micha=
=C5=82 Dominiak wrote:</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">Also as a general note: your approach is way too emotional a=
nd not rational enough to ever get treated seriously by LEWG. If you want s=
omething like this (which I would not expect to get through LEWG because de=
bug iterators, as I've said), you need to make a more sensible rational=
e than "it's a different interface", "this code is horri=
ble" (without giving a <i>single</i>=C2=A0reason for why it is horribl=
e) (also your `std::copy` example needs an actual example when you show how=
faster that is) or "debug iterators are pointless" (this claim i=
s in itself incredibly laughable).</div><br><div class=3D"gmail_quote"><div=
dir=3D"ltr">On Sat, Aug 19, 2017 at 10:48 AM Micha=C5=82 Dominiak <<a o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"th=
is.href=3D'javascript:';return true;" href=3D"javascript:" target=
=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"PfQkgPSKCgAJ">gri...@=
griwes.info</a>> wrote:<br></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">Failing the complexity requirements vs not compiling at all are tw=
o <i>very</i>=C2=A0different things. Your reasoning will not get past LEWG.=
</div><div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Sat, Aug 19, 2017 at 10:29 AM <<a onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"PfQkgPSKCgAJ">eulo...@live.com</a>> wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Debug mode iterators are=
always not standard and should be broken.</div><div><br></div><div>For exa=
mple, debug mode iterators of std::list are O(n) performance(which should b=
e O(1) from the standard.)</div></div><div dir=3D"ltr"><div><br><br>On Satu=
rday, August 19, 2017 at 4:13:16 PM UTC+8, Jonathan M=C3=BCller wrote:</div=
></div><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Saturday=
, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 I think iterators for contiguous containers
<br>> =C2=A0 =C2=A0 (std::vector<T>,std::array<T>,<wbr>std::=
basic_string<T>) should all be T*.
<br>>=20
<br>> =C2=A0 =C2=A0 template<typename T>
<br>> =C2=A0 =C2=A0 class vector
<br>> =C2=A0 =C2=A0 {
<br>> =C2=A0 =C2=A0 public:
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using pointer =3D T*;
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using iterator =3D pointe=
r;
<br>> =C2=A0 =C2=A0 };
<br>>=20
<br>>=20
<br>> =C2=A0 =C2=A0 It could solve following issues:
<br>> =C2=A0 =C2=A0 1.passing through C APIs
<br>
<br>`c_api(vec.data(), vec.data() + vec.size())`
<br>
<br>> =C2=A0 =C2=A0 2.contiguous Iterator/Container issue(if Container&l=
t;T>::iterator is
<br>> =C2=A0 =C2=A0 T*, it is a contiguous container)
<br>
<br>There could be a `contigouos_iterator_tag` but there's probably a r=
eason=20
<br>why there isn't.
<br>
<br>> =C2=A0 =C2=A0 3.converting one container to another easily
<br>
<br>What do you mean?
<br>
<br>> =C2=A0 =C2=A0 4.easy to learn and understand
<br>
<br>An iterator is a class that provides pointer like semantics.
<br>
<br>I don't think that's difficult.
<br>
<br>=C2=A0> 5. Reduce Compilation Time
<br>
<br>Implementations are free to implement iterators as pointers, I think=20
<br>libstdc++ does.
<br>
<br>=C2=A0> 6. Easy to implement a Contiguous Container for libraries.
<br>
<br>Libraries are free to implement iterators as pointers.
<br>
<br></blockquote></div>
<p></p>
-- <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 onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"PfQkgPSKCgA=
J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"PfQkgPSKCgAJ">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a onmousedown=3D"this.href=3D'=
;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3=
-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium\x3demail\x26utm_source\x3df=
ooter';return true;" onclick=3D"this.href=3D'https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3-43ef-b8e0-53245ff8f538=
%40isocpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;=
" href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911=
a548-b7d3-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium=3Demail&utm_so=
urce=3Dfooter" target=3D"_blank" rel=3D"nofollow">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/2911a548-b7d3-43ef-<wbr>b8e0-=
53245ff8f538%40isocpp.org</a><wbr>.<br>
</blockquote></div></div></blockquote></div>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6478b7e0-ae07-48e5-ae65-3457f8bab76f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6478b7e0-ae07-48e5-ae65-3457f8bab76f=
%40isocpp.org</a>.<br />
------=_Part_3784_998332966.1503133358741--
------=_Part_3783_487569982.1503133358741--
.
Author: euloanty@live.com
Date: Sat, 19 Aug 2017 02:04:34 -0700 (PDT)
Raw View
------=_Part_2844_2102859112.1503133474263
Content-Type: multipart/alternative;
boundary="----=_Part_2845_1792812481.1503133474264"
------=_Part_2845_1792812481.1503133474264
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Debug iterators are none standard. I don't think it will break any code if=
=20
you don't mess up with pointers.
On Saturday, August 19, 2017 at 4:53:43 PM UTC+8, Micha=C5=82 Dominiak wrot=
e:
>
> Also as a general note: your approach is way too emotional and not=20
> rational enough to ever get treated seriously by LEWG. If you want=20
> something like this (which I would not expect to get through LEWG because=
=20
> debug iterators, as I've said), you need to make a more sensible rational=
e=20
> than "it's a different interface", "this code is horrible" (without givin=
g=20
> a *single* reason for why it is horrible) (also your `std::copy` example=
=20
> needs an actual example when you show how faster that is) or "debug=20
> iterators are pointless" (this claim is in itself incredibly laughable).
>
> On Sat, Aug 19, 2017 at 10:48 AM Micha=C5=82 Dominiak <gri...@griwes.info=
=20
> <javascript:>> wrote:
>
>> Failing the complexity requirements vs not compiling at all are two=20
>> *very* different things. Your reasoning will not get past LEWG.
>>
>>
>> On Sat, Aug 19, 2017 at 10:29 AM <eulo...@live.com <javascript:>> wrote:
>>
>>> Debug mode iterators are always not standard and should be broken.
>>>
>>> For example, debug mode iterators of std::list are O(n)=20
>>> performance(which should be O(1) from the standard.)
>>>
>>>
>>> On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jonathan M=C3=BCller =
wrote:
>>>
>>>> On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip wrote=
:=20
>>>> >=20
>>>> > I think iterators for contiguous containers=20
>>>> > (std::vector<T>,std::array<T>,std::basic_string<T>) should all b=
e=20
>>>> T*.=20
>>>> >=20
>>>> > template<typename T>=20
>>>> > class vector=20
>>>> > {=20
>>>> > public:=20
>>>> > using pointer =3D T*;=20
>>>> > using iterator =3D pointer;=20
>>>> > };=20
>>>> >=20
>>>> >=20
>>>> > It could solve following issues:=20
>>>> > 1.passing through C APIs=20
>>>>
>>>> `c_api(vec.data(), vec.data() + vec.size())`=20
>>>>
>>>> > 2.contiguous Iterator/Container issue(if Container<T>::iterator=
=20
>>>> is=20
>>>> > T*, it is a contiguous container)=20
>>>>
>>>> There could be a `contigouos_iterator_tag` but there's probably a=20
>>>> reason=20
>>>> why there isn't.=20
>>>>
>>>> > 3.converting one container to another easily=20
>>>>
>>>> What do you mean?=20
>>>>
>>>> > 4.easy to learn and understand=20
>>>>
>>>> An iterator is a class that provides pointer like semantics.=20
>>>>
>>>> I don't think that's difficult.=20
>>>>
>>>> > 5. Reduce Compilation Time=20
>>>>
>>>> Implementations are free to implement iterators as pointers, I think=
=20
>>>> libstdc++ does.=20
>>>>
>>>> > 6. Easy to implement a Contiguous Container for libraries.=20
>>>>
>>>> Libraries are free to implement iterators as pointers.=20
>>>>
>>>> --=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@isocpp.org <javascript:>.
>>> To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..
>>> To view this discussion on the web visit=20
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548-b=
7d3-43ef-b8e0-53245ff8f538%40isocpp.org=20
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548-=
b7d3-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9995813e-c166-4504-a21d-8c15b8785931%40isocpp.or=
g.
------=_Part_2845_1792812481.1503133474264
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Debug iterators are none standard. I don't think it wi=
ll break any code if you don't mess up with pointers.<br><br>On Saturda=
y, August 19, 2017 at 4:53:43 PM UTC+8, Micha=C5=82 Dominiak wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Also as a general not=
e: your approach is way too emotional and not rational enough to ever get t=
reated seriously by LEWG. If you want something like this (which I would no=
t expect to get through LEWG because debug iterators, as I've said), yo=
u need to make a more sensible rationale than "it's a different in=
terface", "this code is horrible" (without giving a <i>singl=
e</i>=C2=A0reason for why it is horrible) (also your `std::copy` example ne=
eds an actual example when you show how faster that is) or "debug iter=
ators are pointless" (this claim is in itself incredibly laughable).</=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 19, 2017 at=
10:48 AM Micha=C5=82 Dominiak <<a onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfus=
cated-mailto=3D"PfQkgPSKCgAJ">gri...@griwes.info</a>> wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">Failing the complexity requir=
ements vs not compiling at all are two <i>very</i>=C2=A0different things. Y=
our reasoning will not get past LEWG.</div><div dir=3D"ltr"><br><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 19, 2017 at 10:29 AM <<=
a onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D=
"this.href=3D'javascript:';return true;" href=3D"javascript:" targe=
t=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"PfQkgPSKCgAJ">eulo..=
..@live.com</a>> wrote:<br></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>Debug mode iterators are always not standard and should be br=
oken.</div><div><br></div><div>For example, debug mode iterators of std::li=
st are O(n) performance(which should be O(1) from the standard.)</div></div=
><div dir=3D"ltr"><div><br><br>On Saturday, August 19, 2017 at 4:13:16 PM U=
TC+8, Jonathan M=C3=BCller wrote:</div></div><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex">On Saturday, August 19, 2017 at 3:51:12 PM UTC+8=
, ejsvifq mabmip wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 I think iterators for contiguous containers
<br>> =C2=A0 =C2=A0 (std::vector<T>,std::array<T>,<wbr>std::=
basic_string<T>) should all be T*.
<br>>=20
<br>> =C2=A0 =C2=A0 template<typename T>
<br>> =C2=A0 =C2=A0 class vector
<br>> =C2=A0 =C2=A0 {
<br>> =C2=A0 =C2=A0 public:
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using pointer =3D T*;
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using iterator =3D pointe=
r;
<br>> =C2=A0 =C2=A0 };
<br>>=20
<br>>=20
<br>> =C2=A0 =C2=A0 It could solve following issues:
<br>> =C2=A0 =C2=A0 1.passing through C APIs
<br>
<br>`c_api(vec.data(), vec.data() + vec.size())`
<br>
<br>> =C2=A0 =C2=A0 2.contiguous Iterator/Container issue(if Container&l=
t;T>::iterator is
<br>> =C2=A0 =C2=A0 T*, it is a contiguous container)
<br>
<br>There could be a `contigouos_iterator_tag` but there's probably a r=
eason=20
<br>why there isn't.
<br>
<br>> =C2=A0 =C2=A0 3.converting one container to another easily
<br>
<br>What do you mean?
<br>
<br>> =C2=A0 =C2=A0 4.easy to learn and understand
<br>
<br>An iterator is a class that provides pointer like semantics.
<br>
<br>I don't think that's difficult.
<br>
<br>=C2=A0> 5. Reduce Compilation Time
<br>
<br>Implementations are free to implement iterators as pointers, I think=20
<br>libstdc++ does.
<br>
<br>=C2=A0> 6. Easy to implement a Contiguous Container for libraries.
<br>
<br>Libraries are free to implement iterators as pointers.
<br>
<br></blockquote></div>
<p></p>
-- <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 onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"PfQkgPSKCgA=
J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"PfQkgPSKCgAJ">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a onmousedown=3D"this.href=3D'=
;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3=
-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium\x3demail\x26utm_source\x3df=
ooter';return true;" onclick=3D"this.href=3D'https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3-43ef-b8e0-53245ff8f538=
%40isocpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;=
" href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911=
a548-b7d3-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium=3Demail&utm_so=
urce=3Dfooter" target=3D"_blank" rel=3D"nofollow">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/2911a548-b7d3-43ef-<wbr>b8e0-=
53245ff8f538%40isocpp.org</a><wbr>.<br>
</blockquote></div></div></blockquote></div>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9995813e-c166-4504-a21d-8c15b8785931%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9995813e-c166-4504-a21d-8c15b8785931=
%40isocpp.org</a>.<br />
------=_Part_2845_1792812481.1503133474264--
------=_Part_2844_2102859112.1503133474263--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Sat, 19 Aug 2017 09:04:47 +0000
Raw View
--f403043ec3b02a3bd80557178a34
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sat, Aug 19, 2017 at 11:02 AM <euloanty@live.com> wrote:
> Nope.
> 1.You can still use "debug mode" iterators when you need. (debug iterator=
s
> for iterators. pointers for none debug mode)
>
No, you can't, because by guaranteeing iterators are literally pointers,
people will write code that requires them to be `T *`, which means debug
iterators *will not even compile* in some pieces of code. There's no such
problem currently.
> 2.vector pointer is the same type as its allocator pointer. If you need
> this, you can define your debug mode in allocator.
>
> On Saturday, August 19, 2017 at 4:53:43 PM UTC+8, Micha=C5=82 Dominiak wr=
ote:
>
>> Also as a general note: your approach is way too emotional and not
>> rational enough to ever get treated seriously by LEWG. If you want
>> something like this (which I would not expect to get through LEWG becaus=
e
>> debug iterators, as I've said), you need to make a more sensible rationa=
le
>> than "it's a different interface", "this code is horrible" (without givi=
ng
>> a *single* reason for why it is horrible) (also your `std::copy` example
>> needs an actual example when you show how faster that is) or "debug
>> iterators are pointless" (this claim is in itself incredibly laughable).
>>
>> On Sat, Aug 19, 2017 at 10:48 AM Micha=C5=82 Dominiak <gri...@griwes.inf=
o>
>> wrote:
>>
> Failing the complexity requirements vs not compiling at all are two *very=
* different
>>> things. Your reasoning will not get past LEWG.
>>>
>> On Sat, Aug 19, 2017 at 10:29 AM <eulo...@live.com> wrote:
>>>
>> Debug mode iterators are always not standard and should be broken.
>>>>
>>>> For example, debug mode iterators of std::list are O(n)
>>>> performance(which should be O(1) from the standard.)
>>>>
>>>>
>>>> On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jonathan M=C3=BCller=
wrote:
>>>>
>>>>> On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip
>>>>> wrote:
>>>>> >
>>>>> > I think iterators for contiguous containers
>>>>> > (std::vector<T>,std::array<T>,std::basic_string<T>) should all
>>>>> be T*.
>>>>> >
>>>>> > template<typename T>
>>>>> > class vector
>>>>> > {
>>>>> > public:
>>>>> > using pointer =3D T*;
>>>>> > using iterator =3D pointer;
>>>>> > };
>>>>> >
>>>>> >
>>>>> > It could solve following issues:
>>>>> > 1.passing through C APIs
>>>>>
>>>>> `c_api(vec.data(), vec.data() + vec.size())`
>>>>>
>>>>> > 2.contiguous Iterator/Container issue(if Container<T>::iterator
>>>>> is
>>>>> > T*, it is a contiguous container)
>>>>>
>>>>> There could be a `contigouos_iterator_tag` but there's probably a
>>>>> reason
>>>>> why there isn't.
>>>>>
>>>>> > 3.converting one container to another easily
>>>>>
>>>>> What do you mean?
>>>>>
>>>>> > 4.easy to learn and understand
>>>>>
>>>>> An iterator is a class that provides pointer like semantics.
>>>>>
>>>>> I don't think that's difficult.
>>>>>
>>>>> > 5. Reduce Compilation Time
>>>>>
>>>>> Implementations are free to implement iterators as pointers, I think
>>>>> libstdc++ does.
>>>>>
>>>>> > 6. Easy to implement a Contiguous Container for libraries.
>>>>>
>>>>> Libraries are free to implement iterators as pointers.
>>>>>
>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>>
>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to std-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>
>>>
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548-=
b7d3-43ef-b8e0-53245ff8f538%40isocpp.org
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548=
-b7d3-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium=3Demail&utm_source=3Df=
ooter>
>>>> .
>>>>
>>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6478b7e0-ae0=
7-48e5-ae65-3457f8bab76f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6478b7e0-ae=
07-48e5-ae65-3457f8bab76f%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAPCFJdTEnesZqrzA0sjUdXN1Fu6HMfaYuqwN%2Bdt3h4Whx=
sCUHA%40mail.gmail.com.
--f403043ec3b02a3bd80557178a34
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 19=
, 2017 at 11:02 AM <<a href=3D"mailto:euloanty@live.com">euloanty@live.c=
om</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div>Nope.</div><div>1.You can still use "debug mode" iterators w=
hen you need. (debug iterators for iterators. pointers for none debug mode)=
<br></div></div></blockquote><div><br></div><div>No, you can't, because=
by guaranteeing iterators are literally pointers, people will write code t=
hat requires them to be `T *`, which means debug iterators <i>will not even=
compile</i>=C2=A0in some pieces of code. There's no such problem curre=
ntly.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div></div><div>2.vector pointer is the same type as its allocator pointer=
.. If you need this, you can define your debug mode in allocator.</div></div=
><div dir=3D"ltr"><div><br>On Saturday, August 19, 2017 at 4:53:43 PM UTC+8=
, Micha=C5=82 Dominiak wrote:</div></div><div dir=3D"ltr"><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">Also as a general note: your approa=
ch is way too emotional and not rational enough to ever get treated serious=
ly by LEWG. If you want something like this (which I would not expect to ge=
t through LEWG because debug iterators, as I've said), you need to make=
a more sensible rationale than "it's a different interface",=
"this code is horrible" (without giving a <i>single</i>=C2=A0rea=
son for why it is horrible) (also your `std::copy` example needs an actual =
example when you show how faster that is) or "debug iterators are poin=
tless" (this claim is in itself incredibly laughable).</div><br></bloc=
kquote></div><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 19, 2017 at 10:48 AM Mic=
ha=C5=82 Dominiak <<a rel=3D"nofollow">gri...@griwes.info</a>> wrote:=
<br></div></div></blockquote></div><div dir=3D"ltr"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr">Failing the complexity requirements vs not compiling at al=
l are two <i>very</i>=C2=A0different things. Your reasoning will not get pa=
st LEWG.</div></blockquote></div></blockquote></div><div dir=3D"ltr"><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"lt=
r">On Sat, Aug 19, 2017 at 10:29 AM <<a rel=3D"nofollow">eulo...@live.co=
m</a>> wrote:<br></div></div></div></blockquote></div></blockquote></div=
><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Debug mode i=
terators are always not standard and should be broken.</div><div><br></div>=
<div>For example, debug mode iterators of std::list are O(n) performance(wh=
ich should be O(1) from the standard.)</div></div><div dir=3D"ltr"><div><br=
><br>On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jonathan M=C3=BCller=
wrote:</div></div><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 I think iterators for contiguous containers
<br>> =C2=A0 =C2=A0 (std::vector<T>,std::array<T>,std::basic=
_string<T>) should all be T*.
<br>>=20
<br>> =C2=A0 =C2=A0 template<typename T>
<br>> =C2=A0 =C2=A0 class vector
<br>> =C2=A0 =C2=A0 {
<br>> =C2=A0 =C2=A0 public:
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using pointer =3D T*;
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using iterator =3D pointe=
r;
<br>> =C2=A0 =C2=A0 };
<br>>=20
<br>>=20
<br>> =C2=A0 =C2=A0 It could solve following issues:
<br>> =C2=A0 =C2=A0 1.passing through C APIs
<br>
<br>`c_api(vec.data(), vec.data() + vec.size())`
<br>
<br>> =C2=A0 =C2=A0 2.contiguous Iterator/Container issue(if Container&l=
t;T>::iterator is
<br>> =C2=A0 =C2=A0 T*, it is a contiguous container)
<br>
<br>There could be a `contigouos_iterator_tag` but there's probably a r=
eason=20
<br>why there isn't.
<br>
<br>> =C2=A0 =C2=A0 3.converting one container to another easily
<br>
<br>What do you mean?
<br>
<br>> =C2=A0 =C2=A0 4.easy to learn and understand
<br>
<br>An iterator is a class that provides pointer like semantics.
<br>
<br>I don't think that's difficult.
<br>
<br>=C2=A0> 5. Reduce Compilation Time
<br>
<br>Implementations are free to implement iterators as pointers, I think=20
<br>libstdc++ does.
<br>
<br>=C2=A0> 6. Easy to implement a Contiguous Container for libraries.
<br>
<br>Libraries are free to implement iterators as pointers.
<br>
<br></blockquote></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></blockquote></div=
></div></blockquote></div></blockquote></div><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><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 class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.</blockquote></div></div></blockquote></div></blockquote></div><div =
dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3-43ef-b8e0-53245ff8f538%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/2911a548-b7d3-43ef-b8e0-53245ff8f538%40isocpp.org</a>.<br>
</blockquote></div></div></blockquote></div></blockquote></div>
<p></p>
-- <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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6478b7e0-ae07-48e5-ae65-3457f8bab76f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6478b7e0-ae07-=
48e5-ae65-3457f8bab76f%40isocpp.org</a>.<br>
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTEnesZqrzA0sjUdXN1Fu6HMfaYuqwN=
%2Bdt3h4WhxsCUHA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTEnesZqr=
zA0sjUdXN1Fu6HMfaYuqwN%2Bdt3h4WhxsCUHA%40mail.gmail.com</a>.<br />
--f403043ec3b02a3bd80557178a34--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Sat, 19 Aug 2017 09:10:10 +0000
Raw View
--001a1142a1d06e393a0557179da5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
"They are not standard" is a red herring. They are not *mandated* by the
standard, but they generally adhere to the requirements - at least the
syntactic requirements, if not always to the complexity requirements. The
truth is they exist and are used, and if you tell LEWG you want to outlaw
them and make them not compile sometimes (because people *will* use the
guarantee that an iterator in `vector` is literally a pointer), the people
who are implementing standard libraries will immediately say "this breaks
code our clients use" and the proposal will just die.
Sorry to burst your bubble, but the standard doesn't exist away from
reality; practical decisions made by implementations of the standard do
influence the text of the standard.
On Sat, Aug 19, 2017 at 11:04 AM Micha=C5=82 Dominiak <griwes@griwes.info> =
wrote:
> On Sat, Aug 19, 2017 at 11:02 AM <euloanty@live.com> wrote:
>
>> Nope.
>> 1.You can still use "debug mode" iterators when you need. (debug
>> iterators for iterators. pointers for none debug mode)
>>
>
> No, you can't, because by guaranteeing iterators are literally pointers,
> people will write code that requires them to be `T *`, which means debug
> iterators *will not even compile* in some pieces of code. There's no such
> problem currently.
>
>
>> 2.vector pointer is the same type as its allocator pointer. If you need
>> this, you can define your debug mode in allocator.
>>
>> On Saturday, August 19, 2017 at 4:53:43 PM UTC+8, Micha=C5=82 Dominiak w=
rote:
>>
>>> Also as a general note: your approach is way too emotional and not
>>> rational enough to ever get treated seriously by LEWG. If you want
>>> something like this (which I would not expect to get through LEWG becau=
se
>>> debug iterators, as I've said), you need to make a more sensible ration=
ale
>>> than "it's a different interface", "this code is horrible" (without giv=
ing
>>> a *single* reason for why it is horrible) (also your `std::copy`
>>> example needs an actual example when you show how faster that is) or "d=
ebug
>>> iterators are pointless" (this claim is in itself incredibly laughable)=
..
>>>
>>> On Sat, Aug 19, 2017 at 10:48 AM Micha=C5=82 Dominiak <gri...@griwes.in=
fo>
>>> wrote:
>>>
>> Failing the complexity requirements vs not compiling at all are two
>>>> *very* different things. Your reasoning will not get past LEWG.
>>>>
>>> On Sat, Aug 19, 2017 at 10:29 AM <eulo...@live.com> wrote:
>>>>
>>> Debug mode iterators are always not standard and should be broken.
>>>>>
>>>>> For example, debug mode iterators of std::list are O(n)
>>>>> performance(which should be O(1) from the standard.)
>>>>>
>>>>>
>>>>> On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jonathan M=C3=BClle=
r
>>>>> wrote:
>>>>>
>>>>>> On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip
>>>>>> wrote:
>>>>>> >
>>>>>> > I think iterators for contiguous containers
>>>>>> > (std::vector<T>,std::array<T>,std::basic_string<T>) should all
>>>>>> be T*.
>>>>>> >
>>>>>> > template<typename T>
>>>>>> > class vector
>>>>>> > {
>>>>>> > public:
>>>>>> > using pointer =3D T*;
>>>>>> > using iterator =3D pointer;
>>>>>> > };
>>>>>> >
>>>>>> >
>>>>>> > It could solve following issues:
>>>>>> > 1.passing through C APIs
>>>>>>
>>>>>> `c_api(vec.data(), vec.data() + vec.size())`
>>>>>>
>>>>>> > 2.contiguous Iterator/Container issue(if Container<T>::iterato=
r
>>>>>> is
>>>>>> > T*, it is a contiguous container)
>>>>>>
>>>>>> There could be a `contigouos_iterator_tag` but there's probably a
>>>>>> reason
>>>>>> why there isn't.
>>>>>>
>>>>>> > 3.converting one container to another easily
>>>>>>
>>>>>> What do you mean?
>>>>>>
>>>>>> > 4.easy to learn and understand
>>>>>>
>>>>>> An iterator is a class that provides pointer like semantics.
>>>>>>
>>>>>> I don't think that's difficult.
>>>>>>
>>>>>> > 5. Reduce Compilation Time
>>>>>>
>>>>>> Implementations are free to implement iterators as pointers, I think
>>>>>> libstdc++ does.
>>>>>>
>>>>>> > 6. Easy to implement a Contiguous Container for libraries.
>>>>>>
>>>>>> Libraries are free to implement iterators as pointers.
>>>>>>
>>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>>>
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to std-proposal...@isocpp.org.
>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>
>>>>
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548=
-b7d3-43ef-b8e0-53245ff8f538%40isocpp.org
>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a54=
8-b7d3-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium=3Demail&utm_source=3D=
footer>
>>>>> .
>>>>>
>>>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6478b7e0-ae=
07-48e5-ae65-3457f8bab76f%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6478b7e0-a=
e07-48e5-ae65-3457f8bab76f%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAPCFJdRNOv0U%2B3ivrHrsKaZqhLe27s7ZxK4mmTmCrSa_P=
rm7JQ%40mail.gmail.com.
--001a1142a1d06e393a0557179da5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">"They are not standard" is a red herring. They a=
re not <i>mandated</i>=C2=A0by the standard, but they generally adhere to t=
he requirements - at least the syntactic requirements, if not always to the=
complexity requirements. The truth is they exist and are used, and if you =
tell LEWG you want to outlaw them and make them not compile sometimes (beca=
use people <i>will</i>=C2=A0use the guarantee that an iterator in `vector` =
is literally a pointer), the people who are implementing standard libraries=
will immediately say "this breaks code our clients use" and the =
proposal will just die.<div><br></div><div>Sorry to burst your bubble, but =
the standard doesn't exist away from reality; practical decisions made =
by implementations of the standard do influence the text of the standard.</=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 19, 2=
017 at 11:04 AM Micha=C5=82 Dominiak <<a href=3D"mailto:griwes@griwes.in=
fo">griwes@griwes.info</a>> wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug=
19, 2017 at 11:02 AM <<a href=3D"mailto:euloanty@live.com" target=3D"_b=
lank">euloanty@live.com</a>> wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div>Nope.</div><div>1.You can still use "debug m=
ode" iterators when you need. (debug iterators for iterators. pointers=
for none debug mode)<br></div></div></blockquote><div><br></div></div></di=
v><div dir=3D"ltr"><div class=3D"gmail_quote"><div>No, you can't, becau=
se by guaranteeing iterators are literally pointers, people will write code=
that requires them to be `T *`, which means debug iterators <i>will not ev=
en compile</i>=C2=A0in some pieces of code. There's no such problem cur=
rently.</div></div></div><div dir=3D"ltr"><div class=3D"gmail_quote"><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div=
>2.vector pointer is the same type as its allocator pointer. If you need th=
is, you can define your debug mode in allocator.</div></div><div dir=3D"ltr=
"><div><br>On Saturday, August 19, 2017 at 4:53:43 PM UTC+8, Micha=C5=82 Do=
miniak wrote:</div></div><div dir=3D"ltr"><blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">Also as a general note: your approach is way too em=
otional and not rational enough to ever get treated seriously by LEWG. If y=
ou want something like this (which I would not expect to get through LEWG b=
ecause debug iterators, as I've said), you need to make a more sensible=
rationale than "it's a different interface", "this code=
is horrible" (without giving a <i>single</i>=C2=A0reason for why it i=
s horrible) (also your `std::copy` example needs an actual example when you=
show how faster that is) or "debug iterators are pointless" (thi=
s claim is in itself incredibly laughable).</div><br></blockquote></div><di=
v dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_q=
uote"><div dir=3D"ltr">On Sat, Aug 19, 2017 at 10:48 AM Micha=C5=82 Dominia=
k <<a rel=3D"nofollow">gri...@griwes.info</a>> wrote:<br></div></div>=
</blockquote></div><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>Failing the complexity requirements vs not compiling at all are two <i>ver=
y</i>=C2=A0different things. Your reasoning will not get past LEWG.</div></=
blockquote></div></blockquote></div><div dir=3D"ltr"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 1=
9, 2017 at 10:29 AM <<a rel=3D"nofollow">eulo...@live.com</a>> wrote:=
<br></div></div></div></blockquote></div></blockquote></div><div dir=3D"ltr=
"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div>Debug mode iterators are alw=
ays not standard and should be broken.</div><div><br></div><div>For example=
, debug mode iterators of std::list are O(n) performance(which should be O(=
1) from the standard.)</div></div><div dir=3D"ltr"><div><br><br>On Saturday=
, August 19, 2017 at 4:13:16 PM UTC+8, Jonathan M=C3=BCller wrote:</div></d=
iv><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Saturday, Au=
gust 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 I think iterators for contiguous containers
<br>> =C2=A0 =C2=A0 (std::vector<T>,std::array<T>,std::basic=
_string<T>) should all be T*.
<br>>=20
<br>> =C2=A0 =C2=A0 template<typename T>
<br>> =C2=A0 =C2=A0 class vector
<br>> =C2=A0 =C2=A0 {
<br>> =C2=A0 =C2=A0 public:
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using pointer =3D T*;
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using iterator =3D pointe=
r;
<br>> =C2=A0 =C2=A0 };
<br>>=20
<br>>=20
<br>> =C2=A0 =C2=A0 It could solve following issues:
<br>> =C2=A0 =C2=A0 1.passing through C APIs
<br>
<br>`c_api(vec.data(), vec.data() + vec.size())`
<br>
<br>> =C2=A0 =C2=A0 2.contiguous Iterator/Container issue(if Container&l=
t;T>::iterator is
<br>> =C2=A0 =C2=A0 T*, it is a contiguous container)
<br>
<br>There could be a `contigouos_iterator_tag` but there's probably a r=
eason=20
<br>why there isn't.
<br>
<br>> =C2=A0 =C2=A0 3.converting one container to another easily
<br>
<br>What do you mean?
<br>
<br>> =C2=A0 =C2=A0 4.easy to learn and understand
<br>
<br>An iterator is a class that provides pointer like semantics.
<br>
<br>I don't think that's difficult.
<br>
<br>=C2=A0> 5. Reduce Compilation Time
<br>
<br>Implementations are free to implement iterators as pointers, I think=20
<br>libstdc++ does.
<br>
<br>=C2=A0> 6. Easy to implement a Contiguous Container for libraries.
<br>
<br>Libraries are free to implement iterators as pointers.
<br>
<br></blockquote></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></blockquote></div=
></div></blockquote></div></blockquote></div><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><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 class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.</blockquote></div></div></blockquote></div></blockquote></div><div =
dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3-43ef-b8e0-53245ff8f538%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/2911a548-b7d3-43ef-b8e0-53245ff8f538%40isocpp.org</a>.<br>
</blockquote></div></div></blockquote></div></blockquote></div>
<p></p>
-- <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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6478b7e0-ae07-48e5-ae65-3457f8bab76f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6478b7e0-ae07-=
48e5-ae65-3457f8bab76f%40isocpp.org</a>.<br>
</blockquote></div></div></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRNOv0U%2B3ivrHrsKaZqhLe27s7ZxK=
4mmTmCrSa_Prm7JQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRNOv0U%2=
B3ivrHrsKaZqhLe27s7ZxK4mmTmCrSa_Prm7JQ%40mail.gmail.com</a>.<br />
--001a1142a1d06e393a0557179da5--
.
Author: euloanty@live.com
Date: Sat, 19 Aug 2017 02:50:52 -0700 (PDT)
Raw View
------=_Part_740_2025724474.1503136252205
Content-Type: multipart/alternative;
boundary="----=_Part_741_528833573.1503136252206"
------=_Part_741_528833573.1503136252206
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
You can.
On Saturday, August 19, 2017 at 5:04:59 PM UTC+8, Micha=C5=82 Dominiak wrot=
e:
>
> On Sat, Aug 19, 2017 at 11:02 AM <eulo...@live.com <javascript:>> wrote:
>
>> Nope.
>> 1.You can still use "debug mode" iterators when you need. (debug=20
>> iterators for iterators. pointers for none debug mode)
>>
>
> No, you can't, because by guaranteeing iterators are literally pointers,=
=20
> people will write code that requires them to be `T *`, which means debug=
=20
> iterators *will not even compile* in some pieces of code. There's no such=
=20
> problem currently.
> =20
>
>> 2.vector pointer is the same type as its allocator pointer. If you need=
=20
>> this, you can define your debug mode in allocator.
>>
>> On Saturday, August 19, 2017 at 4:53:43 PM UTC+8, Micha=C5=82 Dominiak w=
rote:
>>
>>> Also as a general note: your approach is way too emotional and not=20
>>> rational enough to ever get treated seriously by LEWG. If you want=20
>>> something like this (which I would not expect to get through LEWG becau=
se=20
>>> debug iterators, as I've said), you need to make a more sensible ration=
ale=20
>>> than "it's a different interface", "this code is horrible" (without giv=
ing=20
>>> a *single* reason for why it is horrible) (also your `std::copy`=20
>>> example needs an actual example when you show how faster that is) or "d=
ebug=20
>>> iterators are pointless" (this claim is in itself incredibly laughable)=
..
>>>
>>> On Sat, Aug 19, 2017 at 10:48 AM Micha=C5=82 Dominiak <gri...@griwes.in=
fo>=20
>>> wrote:
>>>
>> Failing the complexity requirements vs not compiling at all are two=20
>>>> *very* different things. Your reasoning will not get past LEWG.
>>>>
>>> On Sat, Aug 19, 2017 at 10:29 AM <eulo...@live.com> wrote:
>>>>
>>> Debug mode iterators are always not standard and should be broken.
>>>>>
>>>>> For example, debug mode iterators of std::list are O(n)=20
>>>>> performance(which should be O(1) from the standard.)
>>>>>
>>>>>
>>>>> On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jonathan M=C3=BClle=
r=20
>>>>> wrote:
>>>>>
>>>>>> On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip=20
>>>>>> wrote:=20
>>>>>> >=20
>>>>>> > I think iterators for contiguous containers=20
>>>>>> > (std::vector<T>,std::array<T>,std::basic_string<T>) should all=
=20
>>>>>> be T*.=20
>>>>>> >=20
>>>>>> > template<typename T>=20
>>>>>> > class vector=20
>>>>>> > {=20
>>>>>> > public:=20
>>>>>> > using pointer =3D T*;=20
>>>>>> > using iterator =3D pointer;=20
>>>>>> > };=20
>>>>>> >=20
>>>>>> >=20
>>>>>> > It could solve following issues:=20
>>>>>> > 1.passing through C APIs=20
>>>>>>
>>>>>> `c_api(vec.data(), vec.data() + vec.size())`=20
>>>>>>
>>>>>> > 2.contiguous Iterator/Container issue(if Container<T>::iterato=
r=20
>>>>>> is=20
>>>>>> > T*, it is a contiguous container)=20
>>>>>>
>>>>>> There could be a `contigouos_iterator_tag` but there's probably a=20
>>>>>> reason=20
>>>>>> why there isn't.=20
>>>>>>
>>>>>> > 3.converting one container to another easily=20
>>>>>>
>>>>>> What do you mean?=20
>>>>>>
>>>>>> > 4.easy to learn and understand=20
>>>>>>
>>>>>> An iterator is a class that provides pointer like semantics.=20
>>>>>>
>>>>>> I don't think that's difficult.=20
>>>>>>
>>>>>> > 5. Reduce Compilation Time=20
>>>>>>
>>>>>> Implementations are free to implement iterators as pointers, I think=
=20
>>>>>> libstdc++ does.=20
>>>>>>
>>>>>> > 6. Easy to implement a Contiguous Container for libraries.=20
>>>>>>
>>>>>> Libraries are free to implement iterators as pointers.=20
>>>>>>
>>>>>> --=20
>>>>> You received this message because you are subscribed to the Google=20
>>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>>>
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>>> an email to std-proposal...@isocpp.org.
>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>
>>>>
>>>>> To view this discussion on the web visit=20
>>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548=
-b7d3-43ef-b8e0-53245ff8f538%40isocpp.org=20
>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a54=
8-b7d3-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium=3Demail&utm_source=3D=
footer>
>>>>> .
>>>>>
>>>> --=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:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6478b7e0-ae=
07-48e5-ae65-3457f8bab76f%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6478b7e0-a=
e07-48e5-ae65-3457f8bab76f%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/02e0bc5d-e9d0-4652-8cdb-505e46576437%40isocpp.or=
g.
------=_Part_741_528833573.1503136252206
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">You can.<br><br>On Saturday, August 19, 2017 at 5:04:59 PM=
UTC+8, Micha=C5=82 Dominiak wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, =
Aug 19, 2017 at 11:02 AM <<a onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return tru=
e;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-=
mailto=3D"W5bM0pGLCgAJ">eulo...@live.com</a>> wrote:<br></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>Nope.</div><div>1.You can still =
use "debug mode" iterators when you need. (debug iterators for it=
erators. pointers for none debug mode)<br></div></div></blockquote><div><br=
></div><div>No, you can't, because by guaranteeing iterators are litera=
lly pointers, people will write code that requires them to be `T *`, which =
means debug iterators <i>will not even compile</i>=C2=A0in some pieces of c=
ode. There's no such problem currently.</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>2.vector pointer is =
the same type as its allocator pointer. If you need this, you can define yo=
ur debug mode in allocator.</div></div><div dir=3D"ltr"><div><br>On Saturda=
y, August 19, 2017 at 4:53:43 PM UTC+8, Micha=C5=82 Dominiak wrote:</div></=
div><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">Also as a general note: your approach is way too emotional and not ratio=
nal enough to ever get treated seriously by LEWG. If you want something lik=
e this (which I would not expect to get through LEWG because debug iterator=
s, as I've said), you need to make a more sensible rationale than "=
;it's a different interface", "this code is horrible" (w=
ithout giving a <i>single</i>=C2=A0reason for why it is horrible) (also you=
r `std::copy` example needs an actual example when you show how faster that=
is) or "debug iterators are pointless" (this claim is in itself =
incredibly laughable).</div><br></blockquote></div><div dir=3D"ltr"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div dir=3D"ltr=
">On Sat, Aug 19, 2017 at 10:48 AM Micha=C5=82 Dominiak <<a rel=3D"nofol=
low">gri...@griwes.info</a>> wrote:<br></div></div></blockquote></div><d=
iv dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><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">Failing the complexi=
ty requirements vs not compiling at all are two <i>very</i>=C2=A0different =
things. Your reasoning will not get past LEWG.</div></blockquote></div></bl=
ockquote></div><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v 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"><di=
v class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 19, 2017 at 10:29 AM &=
lt;<a rel=3D"nofollow">eulo...@live.com</a>> wrote:<br></div></div></div=
></blockquote></div></blockquote></div><div dir=3D"ltr"><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div>Debug mode iterators are always not standard an=
d should be broken.</div><div><br></div><div>For example, debug mode iterat=
ors of std::list are O(n) performance(which should be O(1) from the standar=
d.)</div></div><div dir=3D"ltr"><div><br><br>On Saturday, August 19, 2017 a=
t 4:13:16 PM UTC+8, Jonathan M=C3=BCller wrote:</div></div><div dir=3D"ltr"=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">On Saturday, August 19, 2017 at 3:=
51:12 PM UTC+8, ejsvifq mabmip wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 I think iterators for contiguous containers
<br>> =C2=A0 =C2=A0 (std::vector<T>,std::array<T>,<wbr>std::=
basic_string<T>) should all be T*.
<br>>=20
<br>> =C2=A0 =C2=A0 template<typename T>
<br>> =C2=A0 =C2=A0 class vector
<br>> =C2=A0 =C2=A0 {
<br>> =C2=A0 =C2=A0 public:
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using pointer =3D T*;
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using iterator =3D pointe=
r;
<br>> =C2=A0 =C2=A0 };
<br>>=20
<br>>=20
<br>> =C2=A0 =C2=A0 It could solve following issues:
<br>> =C2=A0 =C2=A0 1.passing through C APIs
<br>
<br>`c_api(vec.data(), vec.data() + vec.size())`
<br>
<br>> =C2=A0 =C2=A0 2.contiguous Iterator/Container issue(if Container&l=
t;T>::iterator is
<br>> =C2=A0 =C2=A0 T*, it is a contiguous container)
<br>
<br>There could be a `contigouos_iterator_tag` but there's probably a r=
eason=20
<br>why there isn't.
<br>
<br>> =C2=A0 =C2=A0 3.converting one container to another easily
<br>
<br>What do you mean?
<br>
<br>> =C2=A0 =C2=A0 4.easy to learn and understand
<br>
<br>An iterator is a class that provides pointer like semantics.
<br>
<br>I don't think that's difficult.
<br>
<br>=C2=A0> 5. Reduce Compilation Time
<br>
<br>Implementations are free to implement iterators as pointers, I think=20
<br>libstdc++ does.
<br>
<br>=C2=A0> 6. Easy to implement a Contiguous Container for libraries.
<br>
<br>Libraries are free to implement iterators as pointers.
<br>
<br></blockquote></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></blockquote></div=
></div></blockquote></div></blockquote></div><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><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 class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.</blockquote></div></div></blockquote></div></blockquote></div><div =
dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><br>
To view this discussion on the web visit <a onmousedown=3D"this.href=3D'=
;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3=
-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium\x3demail\x26utm_source\x3df=
ooter';return true;" onclick=3D"this.href=3D'https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3-43ef-b8e0-53245ff8f538=
%40isocpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;=
" href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911=
a548-b7d3-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium=3Demail&utm_so=
urce=3Dfooter" target=3D"_blank" rel=3D"nofollow">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/2911a548-b7d3-43ef-<wbr>b8e0-=
53245ff8f538%40isocpp.org</a><wbr>.<br>
</blockquote></div></div></blockquote></div></blockquote></div>
<p></p>
-- <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 onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"W5bM0pGLCgA=
J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"W5bM0pGLCgAJ">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a onmousedown=3D"this.href=3D'=
;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6478b7e0-ae07=
-48e5-ae65-3457f8bab76f%40isocpp.org?utm_medium\x3demail\x26utm_source\x3df=
ooter';return true;" onclick=3D"this.href=3D'https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6478b7e0-ae07-48e5-ae65-3457f8bab76f=
%40isocpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;=
" href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6478=
b7e0-ae07-48e5-ae65-3457f8bab76f%40isocpp.org?utm_medium=3Demail&utm_so=
urce=3Dfooter" target=3D"_blank" rel=3D"nofollow">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/6478b7e0-ae07-48e5-<wbr>ae65-=
3457f8bab76f%40isocpp.org</a><wbr>.<br>
</blockquote></div></div>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/02e0bc5d-e9d0-4652-8cdb-505e46576437%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/02e0bc5d-e9d0-4652-8cdb-505e46576437=
%40isocpp.org</a>.<br />
------=_Part_741_528833573.1503136252206--
------=_Part_740_2025724474.1503136252205--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Sat, 19 Aug 2017 09:53:55 +0000
Raw View
--089e08204f6cea4e2d0557183964
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Are you capable of actually discussing arguments? Because it doesn't seem
you can, and until you change that - I'm not going to reply.
On Sat, Aug 19, 2017 at 11:50 AM <euloanty@live.com> wrote:
> You can.
>
> On Saturday, August 19, 2017 at 5:04:59 PM UTC+8, Micha=C5=82 Dominiak wr=
ote:
>>
>> On Sat, Aug 19, 2017 at 11:02 AM <eulo...@live.com> wrote:
>>
>>> Nope.
>>> 1.You can still use "debug mode" iterators when you need. (debug
>>> iterators for iterators. pointers for none debug mode)
>>>
>>
>> No, you can't, because by guaranteeing iterators are literally pointers,
>> people will write code that requires them to be `T *`, which means debug
>> iterators *will not even compile* in some pieces of code. There's no
>> such problem currently.
>>
>>
> 2.vector pointer is the same type as its allocator pointer. If you need
>>> this, you can define your debug mode in allocator.
>>>
>>> On Saturday, August 19, 2017 at 4:53:43 PM UTC+8, Micha=C5=82 Dominiak =
wrote:
>>>
>>>> Also as a general note: your approach is way too emotional and not
>>>> rational enough to ever get treated seriously by LEWG. If you want
>>>> something like this (which I would not expect to get through LEWG beca=
use
>>>> debug iterators, as I've said), you need to make a more sensible ratio=
nale
>>>> than "it's a different interface", "this code is horrible" (without gi=
ving
>>>> a *single* reason for why it is horrible) (also your `std::copy`
>>>> example needs an actual example when you show how faster that is) or "=
debug
>>>> iterators are pointless" (this claim is in itself incredibly laughable=
).
>>>>
>>>> On Sat, Aug 19, 2017 at 10:48 AM Micha=C5=82 Dominiak <gri...@griwes.i=
nfo>
>>>> wrote:
>>>>
>>> Failing the complexity requirements vs not compiling at all are two
>>>>> *very* different things. Your reasoning will not get past LEWG.
>>>>>
>>>> On Sat, Aug 19, 2017 at 10:29 AM <eulo...@live.com> wrote:
>>>>>
>>>> Debug mode iterators are always not standard and should be broken.
>>>>>>
>>>>>> For example, debug mode iterators of std::list are O(n)
>>>>>> performance(which should be O(1) from the standard.)
>>>>>>
>>>>>>
>>>>>> On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jonathan M=C3=BCll=
er
>>>>>> wrote:
>>>>>>
>>>>>>> On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > I think iterators for contiguous containers
>>>>>>> > (std::vector<T>,std::array<T>,std::basic_string<T>) should al=
l
>>>>>>> be T*.
>>>>>>> >
>>>>>>> > template<typename T>
>>>>>>> > class vector
>>>>>>> > {
>>>>>>> > public:
>>>>>>> > using pointer =3D T*;
>>>>>>> > using iterator =3D pointer;
>>>>>>> > };
>>>>>>> >
>>>>>>> >
>>>>>>> > It could solve following issues:
>>>>>>> > 1.passing through C APIs
>>>>>>>
>>>>>>> `c_api(vec.data(), vec.data() + vec.size())`
>>>>>>>
>>>>>>> > 2.contiguous Iterator/Container issue(if
>>>>>>> Container<T>::iterator is
>>>>>>> > T*, it is a contiguous container)
>>>>>>>
>>>>>>> There could be a `contigouos_iterator_tag` but there's probably a
>>>>>>> reason
>>>>>>> why there isn't.
>>>>>>>
>>>>>>> > 3.converting one container to another easily
>>>>>>>
>>>>>>> What do you mean?
>>>>>>>
>>>>>>> > 4.easy to learn and understand
>>>>>>>
>>>>>>> An iterator is a class that provides pointer like semantics.
>>>>>>>
>>>>>>> I don't think that's difficult.
>>>>>>>
>>>>>>> > 5. Reduce Compilation Time
>>>>>>>
>>>>>>> Implementations are free to implement iterators as pointers, I thin=
k
>>>>>>> libstdc++ does.
>>>>>>>
>>>>>>> > 6. Easy to implement a Contiguous Container for libraries.
>>>>>>>
>>>>>>> Libraries are free to implement iterators as pointers.
>>>>>>>
>>>>>>> --
>>>>>> 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, sen=
d
>>>>>> an email to std-proposal...@isocpp.org.
>>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>>
>>>>>
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a54=
8-b7d3-43ef-b8e0-53245ff8f538%40isocpp.org
>>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a5=
48-b7d3-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium=3Demail&utm_source=
=3Dfooter>
>>>>>> .
>>>>>>
>>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6478b7e0-a=
e07-48e5-ae65-3457f8bab76f%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6478b7e0-=
ae07-48e5-ae65-3457f8bab76f%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/02e0bc5d-e9d=
0-4652-8cdb-505e46576437%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/02e0bc5d-e9=
d0-4652-8cdb-505e46576437%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAPCFJdSLsvhYDFMtBY3iqcpcS8xoj-hx9BDGhq0a03x5MxR=
57w%40mail.gmail.com.
--089e08204f6cea4e2d0557183964
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Are you capable of actually discussing arguments? Because =
it doesn't seem you can, and until you change that - I'm not going =
to reply.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug =
19, 2017 at 11:50 AM <<a href=3D"mailto:euloanty@live.com">euloanty@live=
..com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">You can.<br><br>On Saturday, August 19, 2017 at 5:04:59 PM UTC+8, Micha=
=C5=82 Dominiak wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_quote"></div></div></blockquote></div><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_quote"><div dir=3D"ltr">On Sat, Aug 19, 2017 at 11:02 AM <<a rel=
=3D"nofollow">eulo...@live.com</a>> wrote:<br></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>Nope.</div><div>1.You can still use "=
debug mode" iterators when you need. (debug iterators for iterators. p=
ointers for none debug mode)<br></div></div></blockquote><div><br></div><di=
v>No, you can't, because by guaranteeing iterators are literally pointe=
rs, people will write code that requires them to be `T *`, which means debu=
g iterators <i>will not even compile</i>=C2=A0in some pieces of code. There=
's no such problem currently.</div><div>=C2=A0</div></div></div></block=
quote></div><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div></div><div>2.vector pointer is the same type as its allocat=
or pointer. If you need this, you can define your debug mode in allocator.<=
/div></div><div dir=3D"ltr"><div><br>On Saturday, August 19, 2017 at 4:53:4=
3 PM UTC+8, Micha=C5=82 Dominiak wrote:</div></div><div dir=3D"ltr"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Also as a general note: y=
our approach is way too emotional and not rational enough to ever get treat=
ed seriously by LEWG. If you want something like this (which I would not ex=
pect to get through LEWG because debug iterators, as I've said), you ne=
ed to make a more sensible rationale than "it's a different interf=
ace", "this code is horrible" (without giving a <i>single</i=
>=C2=A0reason for why it is horrible) (also your `std::copy` example needs =
an actual example when you show how faster that is) or "debug iterator=
s are pointless" (this claim is in itself incredibly laughable).</div>=
<br></blockquote></div><div dir=3D"ltr"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 19, 2017 at 10=
:48 AM Micha=C5=82 Dominiak <<a rel=3D"nofollow">gri...@griwes.info</a>&=
gt; wrote:<br></div></div></blockquote></div><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><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">Failing the complexity requirements vs not compi=
ling at all are two <i>very</i>=C2=A0different things. Your reasoning will =
not get past LEWG.</div></blockquote></div></blockquote></div><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div 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"><div class=3D"gmail_quote"><div=
dir=3D"ltr">On Sat, Aug 19, 2017 at 10:29 AM <<a rel=3D"nofollow">eulo.=
...@live.com</a>> wrote:<br></div></div></div></blockquote></div></blockq=
uote></div><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div cl=
ass=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 cl=
ass=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>De=
bug mode iterators are always not standard and should be broken.</div><div>=
<br></div><div>For example, debug mode iterators of std::list are O(n) perf=
ormance(which should be O(1) from the standard.)</div></div><div dir=3D"ltr=
"><div><br><br>On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jonathan M=
=C3=BCller wrote:</div></div><div dir=3D"ltr"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip=
wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 I think iterators for contiguous containers
<br>> =C2=A0 =C2=A0 (std::vector<T>,std::array<T>,std::basic=
_string<T>) should all be T*.
<br>>=20
<br>> =C2=A0 =C2=A0 template<typename T>
<br>> =C2=A0 =C2=A0 class vector
<br>> =C2=A0 =C2=A0 {
<br>> =C2=A0 =C2=A0 public:
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using pointer =3D T*;
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using iterator =3D pointe=
r;
<br>> =C2=A0 =C2=A0 };
<br>>=20
<br>>=20
<br>> =C2=A0 =C2=A0 It could solve following issues:
<br>> =C2=A0 =C2=A0 1.passing through C APIs
<br>
<br>`c_api(vec.data(), vec.data() + vec.size())`
<br>
<br>> =C2=A0 =C2=A0 2.contiguous Iterator/Container issue(if Container&l=
t;T>::iterator is
<br>> =C2=A0 =C2=A0 T*, it is a contiguous container)
<br>
<br>There could be a `contigouos_iterator_tag` but there's probably a r=
eason=20
<br>why there isn't.
<br>
<br>> =C2=A0 =C2=A0 3.converting one container to another easily
<br>
<br>What do you mean?
<br>
<br>> =C2=A0 =C2=A0 4.easy to learn and understand
<br>
<br>An iterator is a class that provides pointer like semantics.
<br>
<br>I don't think that's difficult.
<br>
<br>=C2=A0> 5. Reduce Compilation Time
<br>
<br>Implementations are free to implement iterators as pointers, I think=20
<br>libstdc++ does.
<br>
<br>=C2=A0> 6. Easy to implement a Contiguous Container for libraries.
<br>
<br>Libraries are free to implement iterators as pointers.
<br>
<br></blockquote></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></blockquote></div=
></div></blockquote></div></blockquote></div><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><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 class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.</blockquote></div></div></blockquote></div></blockquote></div><div =
dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3-43ef-b8e0-53245ff8f538%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/2911a548-b7d3-43ef-b8e0-53245ff8f538%40isocpp.org</a>.<br>
</blockquote></div></div></blockquote></div></blockquote></div>
<p></p>
-- <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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></blockquote></div></div></blockquote></div><div dir=3D"ltr"><bl=
ockquote 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"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6478b7e0-ae07-48e5-ae65-3457f8bab76f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/6478b7e0-ae07-48e5-ae65-3457f8bab76f%40isocpp.org</a>.<br>
</blockquote></div></div>
</blockquote></div>
<p></p>
-- <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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/02e0bc5d-e9d0-4652-8cdb-505e46576437%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/02e0bc5d-e9d0-=
4652-8cdb-505e46576437%40isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSLsvhYDFMtBY3iqcpcS8xoj-hx9BDG=
hq0a03x5MxR57w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSLsvhYDFMt=
BY3iqcpcS8xoj-hx9BDGhq0a03x5MxR57w%40mail.gmail.com</a>.<br />
--089e08204f6cea4e2d0557183964--
.
Author: euloanty@live.com
Date: Sat, 19 Aug 2017 03:17:14 -0700 (PDT)
Raw View
------=_Part_4057_131583201.1503137834779
Content-Type: multipart/alternative;
boundary="----=_Part_4058_2047542958.1503137834780"
------=_Part_4058_2047542958.1503137834780
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Arguments? interface like vec.data() already breaks most of iterator=20
implementations. It is nothing wrong to break it either.
On Saturday, August 19, 2017 at 5:54:08 PM UTC+8, Micha=C5=82 Dominiak wrot=
e:
>
> Are you capable of actually discussing arguments? Because it doesn't seem=
=20
> you can, and until you change that - I'm not going to reply.
>
> On Sat, Aug 19, 2017 at 11:50 AM <eulo...@live.com <javascript:>> wrote:
>
>> You can.
>>
>> On Saturday, August 19, 2017 at 5:04:59 PM UTC+8, Micha=C5=82 Dominiak w=
rote:
>>>
>>> On Sat, Aug 19, 2017 at 11:02 AM <eulo...@live.com> wrote:
>>>
>>>> Nope.
>>>> 1.You can still use "debug mode" iterators when you need. (debug=20
>>>> iterators for iterators. pointers for none debug mode)
>>>>
>>>
>>> No, you can't, because by guaranteeing iterators are literally pointers=
,=20
>>> people will write code that requires them to be `T *`, which means debu=
g=20
>>> iterators *will not even compile* in some pieces of code. There's no=20
>>> such problem currently.
>>> =20
>>>
>> 2.vector pointer is the same type as its allocator pointer. If you need=
=20
>>>> this, you can define your debug mode in allocator.
>>>>
>>>> On Saturday, August 19, 2017 at 4:53:43 PM UTC+8, Micha=C5=82 Dominiak=
wrote:
>>>>
>>>>> Also as a general note: your approach is way too emotional and not=20
>>>>> rational enough to ever get treated seriously by LEWG. If you want=20
>>>>> something like this (which I would not expect to get through LEWG bec=
ause=20
>>>>> debug iterators, as I've said), you need to make a more sensible rati=
onale=20
>>>>> than "it's a different interface", "this code is horrible" (without g=
iving=20
>>>>> a *single* reason for why it is horrible) (also your `std::copy`=20
>>>>> example needs an actual example when you show how faster that is) or =
"debug=20
>>>>> iterators are pointless" (this claim is in itself incredibly laughabl=
e).
>>>>>
>>>>> On Sat, Aug 19, 2017 at 10:48 AM Micha=C5=82 Dominiak <gri...@griwes.=
info>=20
>>>>> wrote:
>>>>>
>>>> Failing the complexity requirements vs not compiling at all are two=20
>>>>>> *very* different things. Your reasoning will not get past LEWG.
>>>>>>
>>>>> On Sat, Aug 19, 2017 at 10:29 AM <eulo...@live.com> wrote:
>>>>>>
>>>>> Debug mode iterators are always not standard and should be broken.
>>>>>>>
>>>>>>> For example, debug mode iterators of std::list are O(n)=20
>>>>>>> performance(which should be O(1) from the standard.)
>>>>>>>
>>>>>>>
>>>>>>> On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jonathan M=C3=BCl=
ler=20
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq mabmip=
=20
>>>>>>>> wrote:=20
>>>>>>>> >=20
>>>>>>>> > I think iterators for contiguous containers=20
>>>>>>>> > (std::vector<T>,std::array<T>,std::basic_string<T>) should=
=20
>>>>>>>> all be T*.=20
>>>>>>>> >=20
>>>>>>>> > template<typename T>=20
>>>>>>>> > class vector=20
>>>>>>>> > {=20
>>>>>>>> > public:=20
>>>>>>>> > using pointer =3D T*;=20
>>>>>>>> > using iterator =3D pointer;=20
>>>>>>>> > };=20
>>>>>>>> >=20
>>>>>>>> >=20
>>>>>>>> > It could solve following issues:=20
>>>>>>>> > 1.passing through C APIs=20
>>>>>>>>
>>>>>>>> `c_api(vec.data(), vec.data() + vec.size())`=20
>>>>>>>>
>>>>>>>> > 2.contiguous Iterator/Container issue(if=20
>>>>>>>> Container<T>::iterator is=20
>>>>>>>> > T*, it is a contiguous container)=20
>>>>>>>>
>>>>>>>> There could be a `contigouos_iterator_tag` but there's probably a=
=20
>>>>>>>> reason=20
>>>>>>>> why there isn't.=20
>>>>>>>>
>>>>>>>> > 3.converting one container to another easily=20
>>>>>>>>
>>>>>>>> What do you mean?=20
>>>>>>>>
>>>>>>>> > 4.easy to learn and understand=20
>>>>>>>>
>>>>>>>> An iterator is a class that provides pointer like semantics.=20
>>>>>>>>
>>>>>>>> I don't think that's difficult.=20
>>>>>>>>
>>>>>>>> > 5. Reduce Compilation Time=20
>>>>>>>>
>>>>>>>> Implementations are free to implement iterators as pointers, I=20
>>>>>>>> think=20
>>>>>>>> libstdc++ does.=20
>>>>>>>>
>>>>>>>> > 6. Easy to implement a Contiguous Container for libraries.=20
>>>>>>>>
>>>>>>>> Libraries are free to implement iterators as pointers.=20
>>>>>>>>
>>>>>>>> --=20
>>>>>>> You received this message because you are subscribed to the Google=
=20
>>>>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>>>>>
>>>>>> To unsubscribe from this group and stop receiving emails from it,=20
>>>>>>> send an email to std-proposal...@isocpp.org.
>>>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>>>
>>>>>>
>>>>>>> To view this discussion on the web visit=20
>>>>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a5=
48-b7d3-43ef-b8e0-53245ff8f538%40isocpp.org=20
>>>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a=
548-b7d3-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium=3Demail&utm_source=
=3Dfooter>
>>>>>>> .
>>>>>>>
>>>>>> --=20
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>> an email to std-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>
>>> To view this discussion on the web visit=20
>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6478b7e0-=
ae07-48e5-ae65-3457f8bab76f%40isocpp.org=20
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6478b7e0=
-ae07-48e5-ae65-3457f8bab76f%40isocpp.org?utm_medium=3Demail&utm_source=3Df=
ooter>
>>>> .
>>>>
>>> --=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:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/02e0bc5d-e9=
d0-4652-8cdb-505e46576437%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/02e0bc5d-e=
9d0-4652-8cdb-505e46576437%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/474b0dbf-3932-457a-b4bf-2b18ed803642%40isocpp.or=
g.
------=_Part_4058_2047542958.1503137834780
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Arguments? interface like vec.data() already breaks most o=
f iterator implementations. It is nothing wrong to break it either.<br><br>=
On Saturday, August 19, 2017 at 5:54:08 PM UTC+8, Micha=C5=82 Dominiak wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Are you cap=
able of actually discussing arguments? Because it doesn't seem you can,=
and until you change that - I'm not going to reply.</div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 19, 2017 at 11:50 AM <<a =
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"t=
his.href=3D'javascript:';return true;" href=3D"javascript:" target=
=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"BlQ7c0COCgAJ">eulo...=
@live.com</a>> wrote:<br></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">You can.<br><br>On Saturday, August 19, 2017 at 5:04:59 PM UTC+8, =
Micha=C5=82 Dominiak wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_quote"></div></div></blockquote></div><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 19, 2017 at 11:02 AM <<a =
rel=3D"nofollow">eulo...@live.com</a>> wrote:<br></div><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>Nope.</div><div>1.You can still use &qu=
ot;debug mode" iterators when you need. (debug iterators for iterators=
.. pointers for none debug mode)<br></div></div></blockquote><div><br></div>=
<div>No, you can't, because by guaranteeing iterators are literally poi=
nters, people will write code that requires them to be `T *`, which means d=
ebug iterators <i>will not even compile</i>=C2=A0in some pieces of code. Th=
ere's no such problem currently.</div><div>=C2=A0</div></div></div></bl=
ockquote></div><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><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"><di=
v dir=3D"ltr"><div></div><div>2.vector pointer is the same type as its allo=
cator pointer. If you need this, you can define your debug mode in allocato=
r.</div></div><div dir=3D"ltr"><div><br>On Saturday, August 19, 2017 at 4:5=
3:43 PM UTC+8, Micha=C5=82 Dominiak wrote:</div></div><div dir=3D"ltr"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Also as a general note=
: your approach is way too emotional and not rational enough to ever get tr=
eated seriously by LEWG. If you want something like this (which I would not=
expect to get through LEWG because debug iterators, as I've said), you=
need to make a more sensible rationale than "it's a different int=
erface", "this code is horrible" (without giving a <i>single=
</i>=C2=A0reason for why it is horrible) (also your `std::copy` example nee=
ds an actual example when you show how faster that is) or "debug itera=
tors are pointless" (this claim is in itself incredibly laughable).</d=
iv><br></blockquote></div><div dir=3D"ltr"><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 19, 2017 at=
10:48 AM Micha=C5=82 Dominiak <<a rel=3D"nofollow">gri...@griwes.info</=
a>> wrote:<br></div></div></blockquote></div><div dir=3D"ltr"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><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">Failing the complexity requirements vs not c=
ompiling at all are two <i>very</i>=C2=A0different things. Your reasoning w=
ill not get past LEWG.</div></blockquote></div></blockquote></div><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"=
><div dir=3D"ltr">On Sat, Aug 19, 2017 at 10:29 AM <<a rel=3D"nofollow">=
eulo...@live.com</a>> wrote:<br></div></div></div></blockquote></div></b=
lockquote></div><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv 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=
iv 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=
iv>Debug mode iterators are always not standard and should be broken.</div>=
<div><br></div><div>For example, debug mode iterators of std::list are O(n)=
performance(which should be O(1) from the standard.)</div></div><div dir=
=3D"ltr"><div><br><br>On Saturday, August 19, 2017 at 4:13:16 PM UTC+8, Jon=
athan M=C3=BCller wrote:</div></div><div dir=3D"ltr"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">On Saturday, August 19, 2017 at 3:51:12 PM UTC+8, ejsvifq=
mabmip wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 I think iterators for contiguous containers
<br>> =C2=A0 =C2=A0 (std::vector<T>,std::array<T>,<wbr>std::=
basic_string<T>) should all be T*.
<br>>=20
<br>> =C2=A0 =C2=A0 template<typename T>
<br>> =C2=A0 =C2=A0 class vector
<br>> =C2=A0 =C2=A0 {
<br>> =C2=A0 =C2=A0 public:
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using pointer =3D T*;
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using iterator =3D pointe=
r;
<br>> =C2=A0 =C2=A0 };
<br>>=20
<br>>=20
<br>> =C2=A0 =C2=A0 It could solve following issues:
<br>> =C2=A0 =C2=A0 1.passing through C APIs
<br>
<br>`c_api(vec.data(), vec.data() + vec.size())`
<br>
<br>> =C2=A0 =C2=A0 2.contiguous Iterator/Container issue(if Container&l=
t;T>::iterator is
<br>> =C2=A0 =C2=A0 T*, it is a contiguous container)
<br>
<br>There could be a `contigouos_iterator_tag` but there's probably a r=
eason=20
<br>why there isn't.
<br>
<br>> =C2=A0 =C2=A0 3.converting one container to another easily
<br>
<br>What do you mean?
<br>
<br>> =C2=A0 =C2=A0 4.easy to learn and understand
<br>
<br>An iterator is a class that provides pointer like semantics.
<br>
<br>I don't think that's difficult.
<br>
<br>=C2=A0> 5. Reduce Compilation Time
<br>
<br>Implementations are free to implement iterators as pointers, I think=20
<br>libstdc++ does.
<br>
<br>=C2=A0> 6. Easy to implement a Contiguous Container for libraries.
<br>
<br>Libraries are free to implement iterators as pointers.
<br>
<br></blockquote></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></blockquote></div=
></div></blockquote></div></blockquote></div><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><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 class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.</blockquote></div></div></blockquote></div></blockquote></div><div =
dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><br>
To view this discussion on the web visit <a onmousedown=3D"this.href=3D'=
;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3=
-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium\x3demail\x26utm_source\x3df=
ooter';return true;" onclick=3D"this.href=3D'https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2911a548-b7d3-43ef-b8e0-53245ff8f538=
%40isocpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;=
" href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2911=
a548-b7d3-43ef-b8e0-53245ff8f538%40isocpp.org?utm_medium=3Demail&utm_so=
urce=3Dfooter" target=3D"_blank" rel=3D"nofollow">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/2911a548-b7d3-43ef-<wbr>b8e0-=
53245ff8f538%40isocpp.org</a><wbr>.<br>
</blockquote></div></div></blockquote></div></blockquote></div>
<p></p>
-- <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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></blockquote></div></div></blockquote></div><div dir=3D"ltr"><bl=
ockquote 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"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
To view this discussion on the web visit <a onmousedown=3D"this.href=3D'=
;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6478b7e0-ae07=
-48e5-ae65-3457f8bab76f%40isocpp.org?utm_medium\x3demail\x26utm_source\x3df=
ooter';return true;" onclick=3D"this.href=3D'https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6478b7e0-ae07-48e5-ae65-3457f8bab76f=
%40isocpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;=
" href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6478=
b7e0-ae07-48e5-ae65-3457f8bab76f%40isocpp.org?utm_medium=3Demail&utm_so=
urce=3Dfooter" target=3D"_blank" rel=3D"nofollow">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/6478b7e0-ae07-48e5-<wbr>ae65-=
3457f8bab76f%40isocpp.org</a><wbr>.<br>
</blockquote></div></div>
</blockquote></div>
<p></p>
-- <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 onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"BlQ7c0COCgA=
J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"BlQ7c0COCgAJ">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a onmousedown=3D"this.href=3D'=
;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/02e0bc5d-e9d0=
-4652-8cdb-505e46576437%40isocpp.org?utm_medium\x3demail\x26utm_source\x3df=
ooter';return true;" onclick=3D"this.href=3D'https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/02e0bc5d-e9d0-4652-8cdb-505e46576437=
%40isocpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;=
" href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/02e0=
bc5d-e9d0-4652-8cdb-505e46576437%40isocpp.org?utm_medium=3Demail&utm_so=
urce=3Dfooter" target=3D"_blank" rel=3D"nofollow">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/02e0bc5d-e9d0-4652-<wbr>8cdb-=
505e46576437%40isocpp.org</a><wbr>.<br>
</blockquote></div>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/474b0dbf-3932-457a-b4bf-2b18ed803642%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/474b0dbf-3932-457a-b4bf-2b18ed803642=
%40isocpp.org</a>.<br />
------=_Part_4058_2047542958.1503137834780--
------=_Part_4057_131583201.1503137834779--
.
Author: =?UTF-8?Q?Jonathan_M=c3=bcller?= <jonathanmueller.dev@gmail.com>
Date: Sat, 19 Aug 2017 12:19:54 +0200
Raw View
On 19.08.2017 12:17, euloanty@live.com wrote:
> Arguments? interface like vec.data() already breaks most of iterator
> implementations. It is nothing wrong to break it either.
You're missing the point.
If you write code dealing with vector's iterators and they're pointers,
you will - either on purpose or by accident - write code that *only*
works with pointers.
So you can't put in a debug mode iterator anymore.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4d8d66b2-4300-e908-4ba4-3d52a5ad3688%40gmail.com.
.
Author: euloanty@live.com
Date: Sat, 19 Aug 2017 03:21:08 -0700 (PDT)
Raw View
------=_Part_3883_1401492048.1503138068976
Content-Type: multipart/alternative;
boundary="----=_Part_3884_1782535128.1503138068977"
------=_Part_3884_1782535128.1503138068977
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
You can. Just define your "debug" mode in the allocator.
On Saturday, August 19, 2017 at 6:19:59 PM UTC+8, Jonathan M=C3=BCller wrot=
e:
>
> On 19.08.2017 12:17, eulo...@live.com <javascript:> wrote:=20
> > Arguments? interface like vec.data() already breaks most of iterator=20
> > implementations. It is nothing wrong to break it either.=20
>
> You're missing the point.=20
> If you write code dealing with vector's iterators and they're pointers,=
=20
> you will - either on purpose or by accident - write code that *only*=20
> works with pointers.=20
>
> So you can't put in a debug mode iterator anymore.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4f83f17f-afb9-43a8-a6a7-7f7aa279e4ff%40isocpp.or=
g.
------=_Part_3884_1782535128.1503138068977
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">You can. Just define your "debug" mode in the al=
locator.<br><br>On Saturday, August 19, 2017 at 6:19:59 PM UTC+8, Jonathan =
M=C3=BCller wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 19.08.201=
7 12:17, <a onmousedown=3D"this.href=3D'javascript:';return true;" =
onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascri=
pt:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"T9EcfqmPCg=
AJ">eulo...@live.com</a> wrote:
<br>> Arguments? interface like vec.data() already breaks most of iterat=
or=20
<br>> implementations. It is nothing wrong to break it either.
<br>
<br>You're missing the point.
<br>If you write code dealing with vector's iterators and they're p=
ointers,=20
<br>you will - either on purpose or by accident - write code that *only*=20
<br>works with pointers.
<br>
<br>So you can't put in a debug mode iterator anymore.
<br></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4f83f17f-afb9-43a8-a6a7-7f7aa279e4ff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4f83f17f-afb9-43a8-a6a7-7f7aa279e4ff=
%40isocpp.org</a>.<br />
------=_Part_3884_1782535128.1503138068977--
------=_Part_3883_1401492048.1503138068976--
.
Author: euloanty@live.com
Date: Sat, 19 Aug 2017 03:23:04 -0700 (PDT)
Raw View
------=_Part_3830_1473332624.1503138184778
Content-Type: multipart/alternative;
boundary="----=_Part_3831_502472075.1503138184778"
------=_Part_3831_502472075.1503138184778
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
using pointer =3D *std::allocator_traits*=20
<http://en.cppreference.com/w/cpp/memory/allocator_traits><Allocator>::
pointer;
using iterator =3D pointer;
So you can still define your "debug" mode in allocator.
On Saturday, August 19, 2017 at 6:19:59 PM UTC+8, Jonathan M=C3=BCller wrot=
e:
> On 19.08.2017 12:17, eulo...@live.com <javascript:> wrote:=20
> > Arguments? interface like vec.data() already breaks most of iterator=20
> > implementations. It is nothing wrong to break it either.=20
>
> You're missing the point.=20
> If you write code dealing with vector's iterators and they're pointers,=
=20
> you will - either on purpose or by accident - write code that *only*=20
> works with pointers.=20
>
> So you can't put in a debug mode iterator anymore.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e7a45b1a-90da-4b51-8a50-ef103d29dc5a%40isocpp.or=
g.
------=_Part_3831_502472075.1503138184778
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div><br></div><div>using pointer =3D=C2=A0=
<span class=3D"t-c"><span class=3D"mw-geshi cpp source-cpp"><font face=3D"C=
onsolas"><a href=3D"http://en.cppreference.com/w/cpp/memory/allocator_trait=
s"><span class=3D"kw701"><u><font color=3D"#0066cc">std::<span class=3D"me2=
">allocator_traits</span></font></u></span></a><span class=3D"sy1"><font co=
lor=3D"#000080"><</font></span>Allocator<span class=3D"sy1"><font color=
=3D"#000080">></font></span><span class=3D"sy4"><font color=3D"#008080">=
::</font></span><span class=3D"me2">pointer;</span></font></span></span></d=
iv><div><span class=3D"t-c"><span class=3D"mw-geshi cpp source-cpp"><font f=
ace=3D"Consolas"><span class=3D"me2">using iterator =3D pointer;</span></fo=
nt></span></span></div><div><span class=3D"t-c"><span class=3D"mw-geshi cpp=
source-cpp"><font face=3D"Consolas"><span class=3D"me2"><br></span></font>=
</span></span></div><div><span class=3D"t-c"><span class=3D"mw-geshi cpp so=
urce-cpp"><font face=3D"Consolas"><span class=3D"me2">So you can still defi=
ne your "debug" mode in allocator.</span></font></span></span></d=
iv><div><br></div><div><b></b><i></i><u></u><sub></sub><sup></sup><strike><=
/strike><br><br>On Saturday, August 19, 2017 at 6:19:59 PM UTC+8, Jonathan =
M=C3=BCller wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 19.=
08.2017 12:17, <a onmousedown=3D"this.href=3D'javascript:';return t=
rue;" onclick=3D"this.href=3D'javascript:';return true;" href=3D"ja=
vascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"T9Ec=
fqmPCgAJ">eulo...@live.com</a> wrote:
<br>> Arguments? interface like vec.data() already breaks most of iterat=
or=20
<br>> implementations. It is nothing wrong to break it either.
<br>
<br>You're missing the point.
<br>If you write code dealing with vector's iterators and they're p=
ointers,=20
<br>you will - either on purpose or by accident - write code that *only*=20
<br>works with pointers.
<br>
<br>So you can't put in a debug mode iterator anymore.
<br></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e7a45b1a-90da-4b51-8a50-ef103d29dc5a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e7a45b1a-90da-4b51-8a50-ef103d29dc5a=
%40isocpp.org</a>.<br />
------=_Part_3831_502472075.1503138184778--
------=_Part_3830_1473332624.1503138184778--
.
Author: Manuel Bergler <berglerma@gmail.com>
Date: Sat, 19 Aug 2017 12:29:18 +0200
Raw View
--001a114172dee50ec1055718b79e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
So the main argument for requiring the iterators of contiguous iterators to
be pointers you presented so far is that you want to interface with C APIs.
But there also is another alternative, which the much more sensible
approach in my opinion: write C++ wrappers for the C APIs instead. Not only
are you able to use regular iterators then, but you also get the added
benefit of better type-safety that C++ APIs typically provide over C APIs.
On Sat, Aug 19, 2017 at 12:21 PM, <euloanty@live.com> wrote:
> You can. Just define your "debug" mode in the allocator.
>
> On Saturday, August 19, 2017 at 6:19:59 PM UTC+8, Jonathan M=C3=BCller wr=
ote:
>>
>> On 19.08.2017 12:17, eulo...@live.com wrote:
>> > Arguments? interface like vec.data() already breaks most of iterator
>> > implementations. It is nothing wrong to break it either.
>>
>> You're missing the point.
>> If you write code dealing with vector's iterators and they're pointers,
>> you will - either on purpose or by accident - write code that *only*
>> works with pointers.
>>
>> So you can't put in a debug mode iterator anymore.
>>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/4f83f17f-afb9-43a8-
> a6a7-7f7aa279e4ff%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f83f17f-af=
b9-43a8-a6a7-7f7aa279e4ff%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAM76qmtBkXW5T7T4cNGqwnoTuZHbcGZo5so%3Df-gDC5AhR=
v6zJw%40mail.gmail.com.
--001a114172dee50ec1055718b79e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">So the main argument for requiring the iterators of contig=
uous iterators to be pointers you presented so far is that you want to inte=
rface with C APIs. But there also is another alternative, which the much mo=
re sensible approach in my opinion: write C++ wrappers for the C APIs inste=
ad. Not only are you able to use regular iterators then, but you also get t=
he added benefit of better type-safety that C++ APIs typically provide over=
C APIs.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Sat, Aug 19, 2017 at 12:21 PM, <span dir=3D"ltr"><<a href=3D"mailto:eul=
oanty@live.com" target=3D"_blank">euloanty@live.com</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">You can. Just define your=
"debug" mode in the allocator.<br><br>On Saturday, August 19, 20=
17 at 6:19:59 PM UTC+8, Jonathan M=C3=BCller wrote:<span class=3D""><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex">On 19.08.2017 12:17, <a rel=3D"nofollow">e=
ulo...@live.com</a> wrote:
<br>> Arguments? interface like vec.data() already breaks most of iterat=
or=20
<br>> implementations. It is nothing wrong to break it either.
<br>
<br>You're missing the point.
<br>If you write code dealing with vector's iterators and they're p=
ointers,=20
<br>you will - either on purpose or by accident - write code that *only*=20
<br>works with pointers.
<br>
<br>So you can't put in a debug mode iterator anymore.
<br></blockquote></span></div><span class=3D"">
<p></p>
-- <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@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4f83f17f-afb9-43a8-a6a7-7f7aa279e4ff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4f83=
f17f-afb9-43a8-<wbr>a6a7-7f7aa279e4ff%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAM76qmtBkXW5T7T4cNGqwnoTuZHbcGZo5so%=
3Df-gDC5AhRv6zJw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM76qmtBkXW5T7=
T4cNGqwnoTuZHbcGZo5so%3Df-gDC5AhRv6zJw%40mail.gmail.com</a>.<br />
--001a114172dee50ec1055718b79e--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Sat, 19 Aug 2017 10:30:57 +0000
Raw View
--001a114f2f7460dca9055718bef4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
You are incredibly missing the point: the *users* of the iterators will be
broken, because they will assume raw pointers, hence code will be written
as if the iterators *always* are raw pointers.
Also you can't just refern to `allocator_traits<Allocator>::pointer` (it
has all the same problems we are mentioning, plus:) now, to have debug
iterators, your allocator has to know... about container types. No no no no
no. Please go look at debug iterators for, say, vector, and see how they
are implemented. Then try, as an exercise, to implement that inside
allocator, so that it works with all containers in the standard library in
the same way. And also, now people start needing to know what allocators
are and what specific allocator is used by a container in question to write
correct code (and, as I've said, will inevitably fall into the trap of
"these things are raw pointers here, so they must be raw pointers
everywhere", which again leads to them writing code that stops compiling in
debug mode).
You are yet to present any factual arguments *for* this. The argument of "I
don't like .data(), .data() + .size()" is not really a valid argument, and
the argument of "std::copy is faster on pointers" has not been proven by
you.
On Sat, Aug 19, 2017 at 12:21 PM <euloanty@live.com> wrote:
> You can. Just define your "debug" mode in the allocator.
>
> On Saturday, August 19, 2017 at 6:19:59 PM UTC+8, Jonathan M=C3=BCller wr=
ote:
>
>> On 19.08.2017 12:17, eulo...@live.com wrote:
>> > Arguments? interface like vec.data() already breaks most of iterator
>> > implementations. It is nothing wrong to break it either.
>>
>> You're missing the point.
>> If you write code dealing with vector's iterators and they're pointers,
>> you will - either on purpose or by accident - write code that *only*
>> works with pointers.
>>
>> So you can't put in a debug mode iterator anymore.
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f83f17f-afb=
9-43a8-a6a7-7f7aa279e4ff%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f83f17f-af=
b9-43a8-a6a7-7f7aa279e4ff%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAPCFJdQqTMr6_nS28Ybprm%2BO3TWNPcSQEVfkp-C5a5Bzi=
CoWQA%40mail.gmail.com.
--001a114f2f7460dca9055718bef4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">You are incredibly missing the point: the <i>users</i>=C2=
=A0of the iterators will be broken, because they will assume raw pointers, =
hence code will be written as if the iterators <i>always</i>=C2=A0are raw p=
ointers.<div><br></div><div>Also you can't just refern to `allocator_tr=
aits<Allocator>::pointer` (it has all the same problems we are mentio=
ning, plus:) now, to have debug iterators, your allocator has to know... ab=
out container types. No no no no no. Please go look at debug iterators for,=
say, vector, and see how they are implemented. Then try, as an exercise, t=
o implement that inside allocator, so that it works with all containers in =
the standard library in the same way. And also, now people start needing to=
know what allocators are and what specific allocator is used by a containe=
r in question to write correct code (and, as I've said, will inevitably=
fall into the trap of "these things are raw pointers here, so they mu=
st be raw pointers everywhere", which again leads to them writing code=
that stops compiling in debug mode).</div><div><br></div><div>You are yet =
to present any factual arguments <i>for</i>=C2=A0this. The argument of &quo=
t;I don't like .data(), .data()=C2=A0+ .size()" is not really a va=
lid argument, and the argument of "std::copy is faster on pointers&quo=
t; has not been proven by you.</div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr">On Sat, Aug 19, 2017 at 12:21 PM <<a href=3D"mailto:euloa=
nty@live.com">euloanty@live.com</a>> wrote:<br></div><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">You can. Just define your "debug" =
mode in the allocator.<br><br>On Saturday, August 19, 2017 at 6:19:59 PM UT=
C+8, Jonathan M=C3=BCller wrote:</div><div dir=3D"ltr"><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex">On 19.08.2017 12:17, <a rel=3D"nofollow">eulo...@live.c=
om</a> wrote:
<br>> Arguments? interface like vec.data() already breaks most of iterat=
or=20
<br>> implementations. It is nothing wrong to break it either.
<br>
<br>You're missing the point.
<br>If you write code dealing with vector's iterators and they're p=
ointers,=20
<br>you will - either on purpose or by accident - write code that *only*=20
<br>works with pointers.
<br>
<br>So you can't put in a debug mode iterator anymore.
<br></blockquote></div>
<p></p>
-- <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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4f83f17f-afb9-43a8-a6a7-7f7aa279e4ff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f83f17f-afb9-=
43a8-a6a7-7f7aa279e4ff%40isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQqTMr6_nS28Ybprm%2BO3TWNPcSQEV=
fkp-C5a5BziCoWQA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQqTMr6_n=
S28Ybprm%2BO3TWNPcSQEVfkp-C5a5BziCoWQA%40mail.gmail.com</a>.<br />
--001a114f2f7460dca9055718bef4--
.
Author: euloanty@live.com
Date: Sat, 19 Aug 2017 03:36:39 -0700 (PDT)
Raw View
------=_Part_3753_941863419.1503139000019
Content-Type: multipart/alternative;
boundary="----=_Part_3754_708203890.1503139000020"
------=_Part_3754_708203890.1503139000020
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
It is not possible. For example, I write a io library which could accept=20
iterator range for input/output.
in.read(vec.begin(),vec.end());//It does not work.
On Saturday, August 19, 2017 at 6:29:21 PM UTC+8, Manuel Bergler wrote:
> So the main argument for requiring the iterators of contiguous iterators=
=20
> to be pointers you presented so far is that you want to interface with C=
=20
> APIs. But there also is another alternative, which the much more sensible=
=20
> approach in my opinion: write C++ wrappers for the C APIs instead. Not on=
ly=20
> are you able to use regular iterators then, but you also get the added=20
> benefit of better type-safety that C++ APIs typically provide over C APIs=
..
>
> On Sat, Aug 19, 2017 at 12:21 PM, <eulo...@live.com <javascript:>> wrote:
>
>> You can. Just define your "debug" mode in the allocator.
>>
>> On Saturday, August 19, 2017 at 6:19:59 PM UTC+8, Jonathan M=C3=BCller w=
rote:
>>>
>>> On 19.08.2017 12:17, eulo...@live.com wrote:=20
>>> > Arguments? interface like vec.data() already breaks most of iterator=
=20
>>> > implementations. It is nothing wrong to break it either.=20
>>>
>>> You're missing the point.=20
>>> If you write code dealing with vector's iterators and they're pointers,=
=20
>>> you will - either on purpose or by accident - write code that *only*=20
>>> works with pointers.=20
>>>
>>> So you can't put in a debug mode iterator anymore.=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:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f83f17f-af=
b9-43a8-a6a7-7f7aa279e4ff%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f83f17f-a=
fb9-43a8-a6a7-7f7aa279e4ff%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/8b33fff2-eb39-45b9-b697-11533a19557e%40isocpp.or=
g.
------=_Part_3754_708203890.1503139000020
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>It is not possible. For example, I write a io library=
which could accept iterator range for input/output.</div><div><br></div><d=
iv>in.read(vec.begin(),vec.end());//It does not work.</div><div><br></div><=
div><br>On Saturday, August 19, 2017 at 6:29:21 PM UTC+8, Manuel Bergler wr=
ote:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">So =
the main argument for requiring the iterators of contiguous iterators to be=
pointers you presented so far is that you want to interface with C APIs. B=
ut there also is another alternative, which the much more sensible approach=
in my opinion: write C++ wrappers for the C APIs instead. Not only are you=
able to use regular iterators then, but you also get the added benefit of =
better type-safety that C++ APIs typically provide over C APIs.</div><div><=
br><div class=3D"gmail_quote">On Sat, Aug 19, 2017 at 12:21 PM, <span dir=
=3D"ltr"><<a onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;" href=3D"java=
script:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"XnWZgy=
yQCgAJ">eulo...@live.com</a>></span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">You can. Just define your "debug" mode in =
the allocator.<br><br>On Saturday, August 19, 2017 at 6:19:59 PM UTC+8, Jon=
athan M=C3=BCller wrote:<span><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 19=
..08.2017 12:17, <a rel=3D"nofollow">eulo...@live.com</a> wrote:
<br>> Arguments? interface like vec.data() already breaks most of iterat=
or=20
<br>> implementations. It is nothing wrong to break it either.
<br>
<br>You're missing the point.
<br>If you write code dealing with vector's iterators and they're p=
ointers,=20
<br>you will - either on purpose or by accident - write code that *only*=20
<br>works with pointers.
<br>
<br>So you can't put in a debug mode iterator anymore.
<br></blockquote></span></div><span>
<p></p>
-- <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 onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"XnWZgyyQCgA=
J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"XnWZgyyQCgAJ">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a onmousedown=3D"this.href=3D'=
;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f83f17f-afb9=
-43a8-a6a7-7f7aa279e4ff%40isocpp.org?utm_medium\x3demail\x26utm_source\x3df=
ooter';return true;" onclick=3D"this.href=3D'https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4f83f17f-afb9-43a8-a6a7-7f7aa279e4ff=
%40isocpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;=
" href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f83=
f17f-afb9-43a8-a6a7-7f7aa279e4ff%40isocpp.org?utm_medium=3Demail&utm_so=
urce=3Dfooter" target=3D"_blank" rel=3D"nofollow">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4f83f17f-afb9-43a8-<wbr>a6a7-=
7f7aa279e4ff%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8b33fff2-eb39-45b9-b697-11533a19557e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8b33fff2-eb39-45b9-b697-11533a19557e=
%40isocpp.org</a>.<br />
------=_Part_3754_708203890.1503139000020--
------=_Part_3753_941863419.1503139000019--
.
Author: euloanty@live.com
Date: Sat, 19 Aug 2017 03:46:39 -0700 (PDT)
Raw View
------=_Part_3759_1813638083.1503139599176
Content-Type: multipart/alternative;
boundary="----=_Part_3760_1825998747.1503139599176"
------=_Part_3760_1825998747.1503139599176
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Saturday, August 19, 2017 at 6:31:10 PM UTC+8, Micha=C5=82 Dominiak wrot=
e:
>
> You are incredibly missing the point: the *users* of the iterators will=
=20
> be broken, because they will assume raw pointers, hence code will be=20
> written as if the iterators *always* are raw pointers.
>
=20
It is already broken as long as users use v.data() once. Contiguous=20
iterators just do the same thing(std::pointer_from) etc. It breaks the code=
=20
for you more.
> Also you can't just refern to `allocator_traits<Allocator>::pointer` (it=
=20
> has all the same problems we are mentioning, plus:) now, to have debug=20
> iterators, your allocator has to know... about container types. No no no =
no=20
> no. Please go look at debug iterators for, say, vector, and see how they=
=20
> are implemented. Then try, as an exercise, to implement that inside=20
> allocator, so that it works with all containers in the standard library i=
n=20
> the same way. And also, now people start needing to know what allocators=
=20
> are and what specific allocator is used by a container in question to wri=
te=20
> correct code (and, as I've said, will inevitably fall into the trap of=20
> "these things are raw pointers here, so they must be raw pointers=20
> everywhere", which again leads to them writing code that stops compiling =
in=20
> debug mode).
>
> For containers like vector. You mostly debug for its range(to avoid out o=
f=20
range), so just pass [begin,end) parameters to your observer pointers. It=
=20
is just too easy. I don't know why debug mode does not work for you.
=20
> You are yet to present any factual arguments *for* this. The argument of=
=20
> "I don't like .data(), .data() + .size()" is not really a valid argument,=
=20
> and the argument of "std::copy is faster on pointers" has not been proven=
=20
> by you.
>
> It is not "I like"/"I don't like".v.data() would potentially break code=
=20
for template parameters.
=20
> On Sat, Aug 19, 2017 at 12:21 PM <eulo...@live.com <javascript:>> wrote:
>
>> You can. Just define your "debug" mode in the allocator.
>>
>> On Saturday, August 19, 2017 at 6:19:59 PM UTC+8, Jonathan M=C3=BCller w=
rote:
>>
>>> On 19.08.2017 12:17, eulo...@live.com wrote:=20
>>> > Arguments? interface like vec.data() already breaks most of iterator=
=20
>>> > implementations. It is nothing wrong to break it either.=20
>>>
>>> You're missing the point.=20
>>> If you write code dealing with vector's iterators and they're pointers,=
=20
>>> you will - either on purpose or by accident - write code that *only*=20
>>> works with pointers.=20
>>>
>>> So you can't put in a debug mode iterator anymore.=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:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f83f17f-af=
b9-43a8-a6a7-7f7aa279e4ff%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f83f17f-a=
fb9-43a8-a6a7-7f7aa279e4ff%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5aca4dcc-ea0e-4eca-8cf5-fa82cbec8a18%40isocpp.or=
g.
------=_Part_3760_1825998747.1503139599176
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, August 19, 2017 at 6:31:10 PM UTC+8, =
Micha=C5=82 Dominiak wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">You are incredibly missing the point: the <i>users</i>=C2=A0o=
f the iterators will be broken, because they will assume raw pointers, henc=
e code will be written as if the iterators <i>always</i>=C2=A0are raw point=
ers.</div></blockquote><div>=C2=A0</div><div>It is already broken as long a=
s users use v.data() once. Contiguous iterators just do the same thing(std:=
:pointer_from) etc. It breaks the code for you more.</div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div>=
<div>Also you can't just refern to `allocator_traits<Allocator>::=
<wbr>pointer` (it has all the same problems we are mentioning, plus:) now, =
to have debug iterators, your allocator has to know... about container type=
s. No no no no no. Please go look at debug iterators for, say, vector, and =
see how they are implemented. Then try, as an exercise, to implement that i=
nside allocator, so that it works with all containers in the standard libra=
ry in the same way. And also, now people start needing to know what allocat=
ors are and what specific allocator is used by a container in question to w=
rite correct code (and, as I've said, will inevitably fall into the tra=
p of "these things are raw pointers here, so they must be raw pointers=
everywhere", which again leads to them writing code that stops compil=
ing in debug mode).</div><div><br></div></div></blockquote><div>For contain=
ers like vector. You mostly debug for its range(to avoid out of range), so =
just pass [begin,end) parameters to your observer pointers. It is just too =
easy. I don't know why debug mode does not work for you.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
></div><div>You are yet to present any factual arguments <i>for</i>=C2=A0th=
is. The argument of "I don't like .data(), .data()=C2=A0+ .size()&=
quot; is not really a valid argument, and the argument of "std::copy i=
s faster on pointers" has not been proven by you.</div></div><br></blo=
ckquote><div>It is not "I like"/"I don't like".v.da=
ta() would potentially break code for template parameters.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quot=
e"><div dir=3D"ltr">On Sat, Aug 19, 2017 at 12:21 PM <<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"-tg740WQCgAJ">eulo...@live.com</a>&g=
t; wrote:<br></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">You can.=
Just define your "debug" mode in the allocator.<br><br>On Saturd=
ay, August 19, 2017 at 6:19:59 PM UTC+8, Jonathan M=C3=BCller wrote:</div><=
div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 19.08.2017 12:17=
, <a rel=3D"nofollow">eulo...@live.com</a> wrote:
<br>> Arguments? interface like vec.data() already breaks most of iterat=
or=20
<br>> implementations. It is nothing wrong to break it either.
<br>
<br>You're missing the point.
<br>If you write code dealing with vector's iterators and they're p=
ointers,=20
<br>you will - either on purpose or by accident - write code that *only*=20
<br>works with pointers.
<br>
<br>So you can't put in a debug mode iterator anymore.
<br></blockquote></div>
<p></p>
-- <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 onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"-tg740WQCgA=
J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"-tg740WQCgAJ">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a onmousedown=3D"this.href=3D'=
;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f83f17f-afb9=
-43a8-a6a7-7f7aa279e4ff%40isocpp.org?utm_medium\x3demail\x26utm_source\x3df=
ooter';return true;" onclick=3D"this.href=3D'https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4f83f17f-afb9-43a8-a6a7-7f7aa279e4ff=
%40isocpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;=
" href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f83=
f17f-afb9-43a8-a6a7-7f7aa279e4ff%40isocpp.org?utm_medium=3Demail&utm_so=
urce=3Dfooter" target=3D"_blank" rel=3D"nofollow">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4f83f17f-afb9-43a8-<wbr>a6a7-=
7f7aa279e4ff%40isocpp.org</a><wbr>.<br>
</blockquote></div>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5aca4dcc-ea0e-4eca-8cf5-fa82cbec8a18%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5aca4dcc-ea0e-4eca-8cf5-fa82cbec8a18=
%40isocpp.org</a>.<br />
------=_Part_3760_1825998747.1503139599176--
------=_Part_3759_1813638083.1503139599176--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Sat, 19 Aug 2017 12:05:45 +0000
Raw View
--001a1145343c62fcd105571a1171
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sat, Aug 19, 2017 at 12:46 PM <euloanty@live.com> wrote:
>
>
> On Saturday, August 19, 2017 at 6:31:10 PM UTC+8, Micha=C5=82 Dominiak wr=
ote:
>>
>> You are incredibly missing the point: the *users* of the iterators will
>> be broken, because they will assume raw pointers, hence code will be
>> written as if the iterators *always* are raw pointers.
>>
>
> It is already broken as long as users use v.data() once. Contiguous
> iterators just do the same thing(std::pointer_from) etc. It breaks the co=
de
> for you more.
>
....no? Because all those cases explicitly give you pointers. `.begin()` and
`.end()` explicitly give you *iterators*, so you can't assume more over
"this is a random access iterator". After your proposal - people will
assume more, and use iterators as if they were, literally, pointers, i.e.
they'll pass them, with no explicit conversions like `std::pointer_from` -
notice how explicit this is! - into functions expecting raw pointers (like
C APIs), which won't compile for debug mode iterators.
>
>
>> Also you can't just refern to `allocator_traits<Allocator>::pointer` (it
>> has all the same problems we are mentioning, plus:) now, to have debug
>> iterators, your allocator has to know... about container types. No no no=
no
>> no. Please go look at debug iterators for, say, vector, and see how they
>> are implemented. Then try, as an exercise, to implement that inside
>> allocator, so that it works with all containers in the standard library =
in
>> the same way. And also, now people start needing to know what allocators
>> are and what specific allocator is used by a container in question to wr=
ite
>> correct code (and, as I've said, will inevitably fall into the trap of
>> "these things are raw pointers here, so they must be raw pointers
>> everywhere", which again leads to them writing code that stops compiling=
in
>> debug mode).
>>
>> For containers like vector. You mostly debug for its range(to avoid out
> of range), so just pass [begin,end) parameters to your observer pointers.
> It is just too easy. I don't know why debug mode does not work for you.
>
Oh awesome. So now I have to implement a separate allocator for each
container that's not vector for debug mode, because I can't use the same
logic for checking whether something's in a map or in a deque. Brilliant
(not).
>
>
>> You are yet to present any factual arguments *for* this. The argument of
>> "I don't like .data(), .data() + .size()" is not really a valid argument=
,
>> and the argument of "std::copy is faster on pointers" has not been prove=
n
>> by you.
>>
>> It is not "I like"/"I don't like".v.data() would potentially break code
> for template parameters.
>
Blanket statements like this are not considered an argument - you'll have
to demonstrate the problem here, because I have no clue what you're on
about here.
>
>
>> On Sat, Aug 19, 2017 at 12:21 PM <eulo...@live.com> wrote:
>>
> You can. Just define your "debug" mode in the allocator.
>>>
>>> On Saturday, August 19, 2017 at 6:19:59 PM UTC+8, Jonathan M=C3=BCller =
wrote:
>>>
>>>> On 19.08.2017 12:17, eulo...@live.com wrote:
>>>> > Arguments? interface like vec.data() already breaks most of iterator
>>>> > implementations. It is nothing wrong to break it either.
>>>>
>>>> You're missing the point.
>>>> If you write code dealing with vector's iterators and they're pointers=
,
>>>> you will - either on purpose or by accident - write code that *only*
>>>> works with pointers.
>>>>
>>>> So you can't put in a debug mode iterator anymore.
>>>>
>>> --
>>> 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 a=
n
>>> email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>
>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f83f17f-a=
fb9-43a8-a6a7-7f7aa279e4ff%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f83f17f-=
afb9-43a8-a6a7-7f7aa279e4ff%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5aca4dcc-ea0=
e-4eca-8cf5-fa82cbec8a18%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5aca4dcc-ea=
0e-4eca-8cf5-fa82cbec8a18%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAPCFJdTN-%3DXgLdEmhrjeScD5gPMDf7CD%2B6JcoE22QpA=
FkOE4FA%40mail.gmail.com.
--001a1145343c62fcd105571a1171
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 19=
, 2017 at 12:46 PM <<a href=3D"mailto:euloanty@live.com">euloanty@live.c=
om</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<br><br>On Saturday, August 19, 2017 at 6:31:10 PM UTC+8, Micha=C5=82 Domin=
iak wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">You are =
incredibly missing the point: the <i>users</i>=C2=A0of the iterators will b=
e broken, because they will assume raw pointers, hence code will be written=
as if the iterators <i>always</i>=C2=A0are raw pointers.</div></blockquote=
><div>=C2=A0</div></div><div dir=3D"ltr"><div>It is already broken as long =
as users use v.data() once. Contiguous iterators just do the same thing(std=
::pointer_from) etc. It breaks the code for you more.</div></div></blockquo=
te><div><br></div><div>...no? Because all those cases explicitly give you p=
ointers. `.begin()` and `.end()` explicitly give you <i>iterators</i>, so y=
ou can't assume more over "this is a random access iterator".=
After your proposal - people will assume more, and use iterators as if the=
y were, literally, pointers, i.e. they'll pass them, with no explicit c=
onversions like `std::pointer_from` - notice how explicit this is! - into f=
unctions expecting raw pointers (like C APIs), which won't compile for =
debug mode iterators.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div><br></div><div>Also you can't just refern to `alloca=
tor_traits<Allocator>::pointer` (it has all the same problems we are =
mentioning, plus:) now, to have debug iterators, your allocator has to know=
.... about container types. No no no no no. Please go look at debug iterator=
s for, say, vector, and see how they are implemented. Then try, as an exerc=
ise, to implement that inside allocator, so that it works with all containe=
rs in the standard library in the same way. And also, now people start need=
ing to know what allocators are and what specific allocator is used by a co=
ntainer in question to write correct code (and, as I've said, will inev=
itably fall into the trap of "these things are raw pointers here, so t=
hey must be raw pointers everywhere", which again leads to them writin=
g code that stops compiling in debug mode).</div><div><br></div></div></blo=
ckquote></div><div dir=3D"ltr"><div>For containers like vector. You mostly =
debug for its range(to avoid out of range), so just pass [begin,end) parame=
ters to your observer pointers. It is just too easy. I don't know why d=
ebug mode does not work for you.</div></div></blockquote><div><br></div><di=
v>Oh awesome. So now I have to implement a separate allocator for each cont=
ainer that's not vector for debug mode, because I can't use the sam=
e logic for checking whether something's in a map or in a deque. Brilli=
ant (not).</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>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div></div><div>You are yet to present any factual arguments <i>for</i=
>=C2=A0this. The argument of "I don't like .data(), .data()=C2=A0+=
.size()" is not really a valid argument, and the argument of "st=
d::copy is faster on pointers" has not been proven by you.</div></div>=
<br></blockquote></div><div dir=3D"ltr"><div>It is not "I like"/&=
quot;I don't like".v.data() would potentially break code for templ=
ate parameters.</div></div></blockquote><div><br></div><div>Blanket stateme=
nts like this are not considered an argument - you'll have to demonstra=
te the problem here, because I have no clue what you're on about here.<=
/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>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quo=
te"></div></blockquote></div><div dir=3D"ltr"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 19, 2017=
at 12:21 PM <<a rel=3D"nofollow">eulo...@live.com</a>> wrote:<br></d=
iv></div></blockquote></div><div dir=3D"ltr"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">You can. Just define your "debug" mode in the allocator=
..<br><br>On Saturday, August 19, 2017 at 6:19:59 PM UTC+8, Jonathan M=C3=BC=
ller wrote:</div><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>On 19.08.2017 12:17, <a rel=3D"nofollow">eulo...@live.com</a> wrote:
<br>> Arguments? interface like vec.data() already breaks most of iterat=
or=20
<br>> implementations. It is nothing wrong to break it either.
<br>
<br>You're missing the point.
<br>If you write code dealing with vector's iterators and they're p=
ointers,=20
<br>you will - either on purpose or by accident - write code that *only*=20
<br>works with pointers.
<br>
<br>So you can't put in a debug mode iterator anymore.
<br></blockquote></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></blockquote></div=
></blockquote></div><div dir=3D"ltr"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.</blockquote></div></blockquote></div><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><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"><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4f83f17f-afb9-43a8-a6a7-7f7aa279e4ff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/4f83f17f-afb9-43a8-a6a7-7f7aa279e4ff%40isocpp.org</a>.<br>
</blockquote></div></blockquote></div>
<p></p>
-- <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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5aca4dcc-ea0e-4eca-8cf5-fa82cbec8a18%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5aca4dcc-ea0e-=
4eca-8cf5-fa82cbec8a18%40isocpp.org</a>.<br>
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTN-%3DXgLdEmhrjeScD5gPMDf7CD%2=
B6JcoE22QpAFkOE4FA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTN-%3D=
XgLdEmhrjeScD5gPMDf7CD%2B6JcoE22QpAFkOE4FA%40mail.gmail.com</a>.<br />
--001a1145343c62fcd105571a1171--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 19 Aug 2017 15:12:57 +0300
Raw View
On 19 August 2017 at 15:05, Micha=C5=82 Dominiak <griwes@griwes.info> wrote=
:
> ...no? Because all those cases explicitly give you pointers. `.begin()` a=
nd
> `.end()` explicitly give you iterators, so you can't assume more over "th=
is
> is a random access iterator". After your proposal - people will assume mo=
re,
> and use iterators as if they were, literally, pointers, i.e. they'll pass
> them, with no explicit conversions like `std::pointer_from` - notice how
> explicit this is! - into functions expecting raw pointers (like C APIs),
> which won't compile for debug mode iterators.
This idea also
a) breaks code that currently overloads pointers and iterators
b) is an ABI break
While (a) might not break reasonable code, (b) kinda kills the whole idea.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUZwFWPGpOSmXHBhR8nv9h%2BHPe10MpQ6uFp2Lraje=
tpyuA%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 19 Aug 2017 09:58:13 -0700 (PDT)
Raw View
------=_Part_4188_250357263.1503161893673
Content-Type: multipart/alternative;
boundary="----=_Part_4189_1440394793.1503161893673"
------=_Part_4189_1440394793.1503161893673
Content-Type: text/plain; charset="UTF-8"
On Saturday, August 19, 2017 at 6:21:09 AM UTC-4, ejsvifq mabmip wrote:
>
> You can. Just define your "debug" mode in the allocator.
>
Part of the point of debug iterators is that you don't have to modify your
code to use them. You flip a compile-time switch and you have them. A
`vector<int>` will use debug iterators just as effectively as a
`vector<int, my_allocator>`. I don't have to redefine my types just to get
debug iterator support; it's built into the implementation.
`std::allocator<T>` is defined to use `T*` as its pointer type
(`std::allocator::pointer` is deprecated in C++17, but that merely means
that the `T*` comes from `allocator_traits::pointer` instead). We *cannot*
change that without breaking compatibility.
So that's a non-starter.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8ee53f91-cb94-4fa6-8b20-dd5674b48995%40isocpp.org.
------=_Part_4189_1440394793.1503161893673
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, August 19, 2017 at 6:21:09 AM UTC-4, ejsvifq =
mabmip wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
You can. Just define your "debug" mode in the allocator.<br></div=
></blockquote><div><br>Part of the point of debug iterators is that you don=
't have to modify your code to use them. You flip a compile-time switch=
and you have them. A `vector<int>` will use debug iterators just as =
effectively as a `vector<int, my_allocator>`. I don't have to red=
efine my types just to get debug iterator support; it's built into the =
implementation.<br><br>`std::allocator<T>` is defined to use `T*` as =
its pointer type (`std::allocator::pointer` is deprecated in C++17, but tha=
t merely means that the `T*` comes from `allocator_traits::pointer` instead=
). We <i>cannot</i> change that without breaking compatibility.<br><br>So t=
hat's a non-starter.<br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8ee53f91-cb94-4fa6-8b20-dd5674b48995%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8ee53f91-cb94-4fa6-8b20-dd5674b48995=
%40isocpp.org</a>.<br />
------=_Part_4189_1440394793.1503161893673--
------=_Part_4188_250357263.1503161893673--
.
Author: Manuel Bergler <berglerma@gmail.com>
Date: Sun, 20 Aug 2017 09:53:40 +0200
Raw View
--001a113ce8a41a8e0b05572aa931
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I don't understand what exactly doesn't work. What's wrong with converting
the iterators to pointers by using std::addressof(*iterator)?
On Sat, Aug 19, 2017 at 12:36 PM, <euloanty@live.com> wrote:
> It is not possible. For example, I write a io library which could accept
> iterator range for input/output.
>
> in.read(vec.begin(),vec.end());//It does not work.
>
>
> On Saturday, August 19, 2017 at 6:29:21 PM UTC+8, Manuel Bergler wrote:
>
>> So the main argument for requiring the iterators of contiguous iterators
>> to be pointers you presented so far is that you want to interface with C
>> APIs. But there also is another alternative, which the much more sensibl=
e
>> approach in my opinion: write C++ wrappers for the C APIs instead. Not o=
nly
>> are you able to use regular iterators then, but you also get the added
>> benefit of better type-safety that C++ APIs typically provide over C API=
s.
>>
>> On Sat, Aug 19, 2017 at 12:21 PM, <eulo...@live.com> wrote:
>>
>>> You can. Just define your "debug" mode in the allocator.
>>>
>>> On Saturday, August 19, 2017 at 6:19:59 PM UTC+8, Jonathan M=C3=BCller =
wrote:
>>>>
>>>> On 19.08.2017 12:17, eulo...@live.com wrote:
>>>> > Arguments? interface like vec.data() already breaks most of iterator
>>>> > implementations. It is nothing wrong to break it either.
>>>>
>>>> You're missing the point.
>>>> If you write code dealing with vector's iterators and they're pointers=
,
>>>> you will - either on purpose or by accident - write code that *only*
>>>> works with pointers.
>>>>
>>>> So you can't put in a debug mode iterator anymore.
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/4f83f17f-afb9-43a8-a6a7-
>>> 7f7aa279e4ff%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f83f17f-=
afb9-43a8-a6a7-7f7aa279e4ff%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>
>> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/8b33fff2-eb39-45b9-
> b697-11533a19557e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8b33fff2-eb=
39-45b9-b697-11533a19557e%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAM76qmuj9C95hWCusi5Te-_8jqgucOaXT_z%2Bm7euzpWR8=
aOKTw%40mail.gmail.com.
--001a113ce8a41a8e0b05572aa931
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I don't understand what exactly doesn't work. What=
's wrong with converting the iterators to pointers by using std::addres=
sof(*iterator)?<div><br></div></div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">On Sat, Aug 19, 2017 at 12:36 PM, <span dir=3D"ltr"><=
;<a href=3D"mailto:euloanty@live.com" target=3D"_blank">euloanty@live.com</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v>It is not possible. For example, I write a io library which could accept =
iterator range for input/output.</div><div><br></div><div>in.read(vec.begin=
(),vec.end())<wbr>;//It does not work.</div><span class=3D""><div><br></div=
><div><br>On Saturday, August 19, 2017 at 6:29:21 PM UTC+8, Manuel Bergler =
wrote:</div></span><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""=
><div dir=3D"ltr">So the main argument for requiring the iterators of conti=
guous iterators to be pointers you presented so far is that you want to int=
erface with C APIs. But there also is another alternative, which the much m=
ore sensible approach in my opinion: write C++ wrappers for the C APIs inst=
ead. Not only are you able to use regular iterators then, but you also get =
the added benefit of better type-safety that C++ APIs typically provide ove=
r C APIs.</div></span><div><br><div class=3D"gmail_quote"><span class=3D"">=
On Sat, Aug 19, 2017 at 12:21 PM, <span dir=3D"ltr"><<a rel=3D"nofollow=
">eulo...@live.com</a>></span> wrote:<br></span><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><span class=3D""><div dir=3D"ltr">You can. Just define your "de=
bug" mode in the allocator.<br><br>On Saturday, August 19, 2017 at 6:1=
9:59 PM UTC+8, Jonathan M=C3=BCller wrote:<span><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex">On 19.08.2017 12:17, <a rel=3D"nofollow">eulo...@live.com</a> =
wrote:
<br>> Arguments? interface like vec.data() already breaks most of iterat=
or=20
<br>> implementations. It is nothing wrong to break it either.
<br>
<br>You're missing the point.
<br>If you write code dealing with vector's iterators and they're p=
ointers,=20
<br>you will - either on purpose or by accident - write code that *only*=20
<br>works with pointers.
<br>
<br>So you can't put in a debug mode iterator anymore.
<br></blockquote></span></div></span><span><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span><span class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4f83f17f-afb9-43a8-a6a7-7f7aa279e4ff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/4f83f17f-afb9-43a8-a6a7-<wbr>7f7aa279e4ff%40isocpp.org</a>.<br=
>
</span></blockquote></div><br></div>
</blockquote></div><span class=3D"">
<p></p>
-- <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@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8b33fff2-eb39-45b9-b697-11533a19557e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/8b33=
fff2-eb39-45b9-<wbr>b697-11533a19557e%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAM76qmuj9C95hWCusi5Te-_8jqgucOaXT_z%=
2Bm7euzpWR8aOKTw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM76qmuj9C95hW=
Cusi5Te-_8jqgucOaXT_z%2Bm7euzpWR8aOKTw%40mail.gmail.com</a>.<br />
--001a113ce8a41a8e0b05572aa931--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Sun, 20 Aug 2017 03:12:54 -0500
Raw View
--94eb2c03148e42164305572af0c8
Content-Type: text/plain; charset="UTF-8"
On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <berglerma@gmail.com> wrote:
> I don't understand what exactly doesn't work. What's wrong with converting
> the iterators to pointers by using std::addressof(*iterator)?
>
Dereferencing *end() is undefined behavior.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
<(847)%20691-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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPYbWVL-vUdi2jjduSuUk9Or3i%3DWwa_sDM5avGwhCmU_A%40mail.gmail.com.
--94eb2c03148e42164305572af0c8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <span dir=
=3D"ltr"><<a href=3D"mailto:berglerma@gmail.com" target=3D"_blank">bergl=
erma@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=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">I don=
9;t understand what exactly doesn't work. What's wrong with convert=
ing the iterators to pointers by using std::addressof(*iterator)?</div></bl=
ockquote><div><br></div><div>Dereferencing *end() is undefined behavior.</d=
iv></div>-- <br><div class=3D"m_8148805115304184508gmail_signature" data-sm=
artmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=
=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@evi=
loverlord.com" target=3D"_blank">nevin@eviloverlord.com</a><wbr>> =C2=A0=
<a href=3D"tel:(847)%20691-1404" value=3D"+18476911404" target=3D"_blank">+=
1-847-691-1404</a></div></div></div></div></div>
</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPYbWVL-vUdi2jjduSuUk9Or3i%3D=
Wwa_sDM5avGwhCmU_A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPYbW=
VL-vUdi2jjduSuUk9Or3i%3DWwa_sDM5avGwhCmU_A%40mail.gmail.com</a>.<br />
--94eb2c03148e42164305572af0c8--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 20 Aug 2017 09:55:52 -0700
Raw View
On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:
> On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <berglerma@gmail.com> wrote:
> > I don't understand what exactly doesn't work. What's wrong with converting
> > the iterators to pointers by using std::addressof(*iterator)?
>
> Dereferencing *end() is undefined behavior.
std::addressof(end()[-1]) + 1
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7772285.tCZj9Pc9gV%40tjmaciei-mobl1.
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Sun, 20 Aug 2017 17:37:07 +0000
Raw View
--001a114dd4ce4a4593055732d04a
Content-Type: text/plain; charset="UTF-8"
On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <thiago@macieira.org> wrote:
> On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:
> > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <berglerma@gmail.com>
> wrote:
> > > I don't understand what exactly doesn't work. What's wrong with
> converting
> > > the iterators to pointers by using std::addressof(*iterator)?
> >
> > Dereferencing *end() is undefined behavior.
>
> std::addressof(end()[-1]) + 1
>
That's UB when begin() == end(), no?
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7772285.tCZj9Pc9gV%40tjmaciei-mobl1
> .
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSXzofSHTfjQD%3D2xb%3DsPrU_WaHtM_KOYpQkVg-CuBA_MA%40mail.gmail.com.
--001a114dd4ce4a4593055732d04a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, Aug 20, 2017, 6:55 PM T=
hiago Macieira <<a href=3D"mailto:thiago@macieira.org">thiago@macieira.o=
rg</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sunday, 20 Aug=
ust 2017 01:12:54 PDT Nevin Liber wrote:<br>
> On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <<a href=3D"mailto:=
berglerma@gmail.com" target=3D"_blank">berglerma@gmail.com</a>> wrote:<b=
r>
> > I don't understand what exactly doesn't work. What's =
wrong with converting<br>
> > the iterators to pointers by using std::addressof(*iterator)?<br>
><br>
> Dereferencing *end() is undefined behavior.<br>
<br>
std::addressof(end()[-1]) + 1<br></blockquote></div><div><br></div><div>Tha=
t's UB when begin() =3D=3D end(), no?=C2=A0</div><div><br></div><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<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%2Bunsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7772285.tCZj9Pc9gV%40tjmaciei-mobl1" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org=
/d/msgid/std-proposals/7772285.tCZj9Pc9gV%40tjmaciei-mobl1</a>.<br>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSXzofSHTfjQD%3D2xb%3DsPrU_WaHt=
M_KOYpQkVg-CuBA_MA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSXzofS=
HTfjQD%3D2xb%3DsPrU_WaHtM_KOYpQkVg-CuBA_MA%40mail.gmail.com</a>.<br />
--001a114dd4ce4a4593055732d04a--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Sun, 20 Aug 2017 12:55:36 -0500
Raw View
--f403045c61fa2bd17d0557331441
Content-Type: text/plain; charset="UTF-8"
On Sun, Aug 20, 2017 at 11:55 AM, Thiago Macieira <thiago@macieira.org>
wrote:
> On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:
> > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <berglerma@gmail.com>
> wrote:
> > > I don't understand what exactly doesn't work. What's wrong with
> converting
> > > the iterators to pointers by using std::addressof(*iterator)?
> >
> > Dereferencing *end() is undefined behavior.
>
> std::addressof(end()[-1]) + 1
>
Doesn't work for an empty range.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMN4LXM%3DAjFNahrcrTZz5Q1n9pLmTEi2gCjq0fiMKzMqQ%40mail.gmail.com.
--f403045c61fa2bd17d0557331441
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sun, Aug 20, 2017 at 11:55 AM, Thiago Macieira <span di=
r=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thia=
go@macieira.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Sund=
ay, 20 August 2017 01:12:54 PDT Nevin Liber wrote:<br>
> On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <<a href=3D"mailto:=
berglerma@gmail.com">berglerma@gmail.com</a>> wrote:<br>
> > I don't understand what exactly doesn't work. What's =
wrong with converting<br>
> > the iterators to pointers by using std::addressof(*iterator)?<br>
><br>
> Dereferencing *end() is undefined behavior.<br>
<br>
</span>std::addressof(end()[-1]) + 1<br></blockquote><div><br></div><div>Do=
esn't work for an empty range.</div><div>--=C2=A0<br></div></div><div c=
lass=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr=
"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <ma=
ilto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evil=
overlord.com</a>> =C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMN4LXM%3DAjFNahrcrTZz5Q1n9pL=
mTEi2gCjq0fiMKzMqQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMN4L=
XM%3DAjFNahrcrTZz5Q1n9pLmTEi2gCjq0fiMKzMqQ%40mail.gmail.com</a>.<br />
--f403045c61fa2bd17d0557331441--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Sun, 20 Aug 2017 13:12:26 -0500
Raw View
--94eb2c1168e86a85b8055733500e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sun, Aug 20, 2017 at 12:37 PM, Micha=C5=82 Dominiak <griwes@griwes.info>
wrote:
>
>> std::addressof(end()[-1]) + 1
>>
>
> That's UB when begin() =3D=3D end(), no?
>
There is this longstanding open issue for pointers <
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232>, but AFAIK
library believes end() iterators are non-dereferenceable.
> --
>
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
<(847)%20691-1404>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAGg_6%2BPc%2B8hNMVvmJ3RpGAefXxHpC7caQZKEw60vcvH=
DqQ1ihQ%40mail.gmail.com.
--94eb2c1168e86a85b8055733500e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sun, Aug 20, 2017 at 12:37 PM, Micha=C5=82 Dominiak <sp=
an dir=3D"ltr"><<a href=3D"mailto:griwes@griwes.info" target=3D"_blank">=
griwes@griwes.info</a>></span> wrote:<br><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-c=
olor:rgb(204,204,204);padding-left:1ex"><span class=3D"m_-24893257790146013=
57gmail-"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><br>std::addressof(en=
d()[-1]) + 1<br></blockquote></div><div><br></div></span><div>That's UB=
when begin() =3D=3D end(), no? </div></blockquote><div><br></div><div>Ther=
e is this longstanding open issue for pointers <<a href=3D"http://www.op=
en-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232" target=3D"_blank">http:=
//www.open-std.org/jtc1/<wbr>sc22/wg21/docs/cwg_active.<wbr>html#232</a>>=
;, but AFAIK library believes end() iterators are non-dereferenceable.=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex"><div>--=C2=A0<br></div></blockquote></div><div cl=
ass=3D"m_-2489325779014601357gmail_signature"><div dir=3D"ltr"><div><div di=
r=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a><wbr>> =C2=A0<a href=3D"tel:(847)%20691-1404" value=3D"+18476911404"=
target=3D"_blank">+1-847-691-1404</a></div></div></div></div></div>
</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPc%2B8hNMVvmJ3RpGAefXxHpC7ca=
QZKEw60vcvHDqQ1ihQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPc%2=
B8hNMVvmJ3RpGAefXxHpC7caQZKEw60vcvHDqQ1ihQ%40mail.gmail.com</a>.<br />
--94eb2c1168e86a85b8055733500e--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 20 Aug 2017 11:43:21 -0700
Raw View
On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dominiak wrote:
> On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <thiago@macieira.org> wrote=
:
> > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:
> > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <berglerma@gmail.com>
> >=20
> > wrote:
> > > > I don't understand what exactly doesn't work. What's wrong with
> >=20
> > converting
> >=20
> > > > the iterators to pointers by using std::addressof(*iterator)?
> > >=20
> > > Dereferencing *end() is undefined behavior.
> >=20
> > std::addressof(end()[-1]) + 1
>=20
> That's UB when begin() =3D=3D end(), no?
Yes, but you can't dereference the begin pointer that way either when the l=
ist=20
is empty.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2339638.frLVoL28E3%40tjmaciei-mobl1.
.
Author: Manuel Bergler <berglerma@gmail.com>
Date: Mon, 21 Aug 2017 00:07:22 +0200
Raw View
--94eb2c095874382c1d05573696ac
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sun, Aug 20, 2017 at 8:43 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dominiak wrote:
> > On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <thiago@macieira.org>
> wrote:
> > > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:
> > > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <berglerma@gmail.co=
m
> >
> > >
> > > wrote:
> > > > > I don't understand what exactly doesn't work. What's wrong with
> > >
> > > converting
> > >
> > > > > the iterators to pointers by using std::addressof(*iterator)?
> > > >
> > > > Dereferencing *end() is undefined behavior.
> > >
> > > std::addressof(end()[-1]) + 1
> >
> > That's UB when begin() =3D=3D end(), no?
>
> Yes, but you can't dereference the begin pointer that way either when the
> list
> is empty.
>
>
You don't need to dereference begin() when the range is empty and you also
don't need to dereference end(). For a typical example of a C API that
takes a pointer and a size, a C++ wrapper using iterators can easily be
implemented as
void c_style_function(void* start, size_t size);
template <typename RandomAccessIterator>
void cpp_wrapper(RandomAccessIterator begin, RandomAccessIterator end)
{
auto const size =3D std::distance(begin, end);
if (size !=3D 0) {
auto begin_ptr =3D std::addressof(*begin);
c_style_function(begin_ptr, size);
}
}
If one additionally creates a trait for contiguous iterators, the template
can also be restricted accordingly. And for C APIs that expect an end
pointer instead of a size argument you can also compute the end pointer
from begin_ptr and size. As far as I can tell this doesn't cause UB and
does exactly what the OP would like to achieve, without needing the
iterators to be pointers.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAM76qmsfK16UPgvbW1HK9zv_2M%2BQ10MKLz8OE_GamgOVe=
opx9A%40mail.gmail.com.
--94eb2c095874382c1d05573696ac
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sun, Aug 20, 2017 at 8:43 PM, Thiago Macieira <span dir=3D"ltr"><<a h=
ref=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On S=
unday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dominiak wrote:<br>
> On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <<a href=3D"mailto:th=
iago@macieira.org">thiago@macieira.org</a>> wrote:<br>
> > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:<br>
> > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <<a href=
=3D"mailto:berglerma@gmail.com">berglerma@gmail.com</a>><br>
> ><br>
> > wrote:<br>
> > > > I don't understand what exactly doesn't work. W=
hat's wrong with<br>
> ><br>
> > converting<br>
> ><br>
> > > > the iterators to pointers by using std::addressof(*iter=
ator)?<br>
> > ><br>
> > > Dereferencing *end() is undefined behavior.<br>
> ><br>
> > std::addressof(end()[-1]) + 1<br>
><br>
> That's UB when begin() =3D=3D end(), no?<br>
<br>
</span>Yes, but you can't dereference the begin pointer that way either=
when the list<br>
is empty.<br>
<span class=3D""><br></span></blockquote><div><br></div><div>You don't =
need to dereference begin() when the range is empty and you also don't =
need to dereference end(). For a typical example of a C API that takes a po=
inter and a size, a C++ wrapper using iterators can easily be implemented a=
s</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0void c_style_function(void* =
start, size_t size);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0template =
<typename RandomAccessIterator></div><div>=C2=A0 =C2=A0 =C2=A0void cp=
p_wrapper(RandomAccessIterator begin, RandomAccessIterator end) {</div><div=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto const size =3D std::distance(begin=
, end);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (siz=
e !=3D 0) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto=
begin_ptr =3D std::addressof(*begin);</div><div><br></div><div>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 c_style_function(begin_ptr, size);</=
div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0 =C2=A0=
}</div><div><br></div><div>If one additionally creates a trait for contiguo=
us iterators, the template can also be restricted accordingly. And for C AP=
Is that expect an end pointer instead of a size argument you can also compu=
te the end pointer from begin_ptr and size. As far as I can tell this doesn=
't cause UB and does exactly what the OP would like to achieve, without=
needing the iterators to be pointers.</div></div></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAM76qmsfK16UPgvbW1HK9zv_2M%2BQ10MKLz=
8OE_GamgOVeopx9A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM76qmsfK16UPg=
vbW1HK9zv_2M%2BQ10MKLz8OE_GamgOVeopx9A%40mail.gmail.com</a>.<br />
--94eb2c095874382c1d05573696ac--
.
Author: euloanty@live.com
Date: Mon, 21 Aug 2017 07:10:05 -0700 (PDT)
Raw View
------=_Part_5097_2029195776.1503324605436
Content-Type: multipart/alternative;
boundary="----=_Part_5098_147088566.1503324605436"
------=_Part_5098_147088566.1503324605436
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Horrible. Random Access Iterators are not Contiguous Iterators. If somebody=
=20
passes deque iterators into it, UB. Pointers can guaranteed to be=20
contiguous iterators.
On Monday, August 21, 2017 at 6:07:25 AM UTC+8, Manuel Bergler wrote:
>
> On Sun, Aug 20, 2017 at 8:43 PM, Thiago Macieira <thi...@macieira.org=20
> <javascript:>> wrote:
>
>> On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dominiak wrote:
>> > On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <thi...@macieira.org=20
>> <javascript:>> wrote:
>> > > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:
>> > > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <berg...@gmail.com=
=20
>> <javascript:>>
>> > >
>> > > wrote:
>> > > > > I don't understand what exactly doesn't work. What's wrong with
>> > >
>> > > converting
>> > >
>> > > > > the iterators to pointers by using std::addressof(*iterator)?
>> > > >
>> > > > Dereferencing *end() is undefined behavior.
>> > >
>> > > std::addressof(end()[-1]) + 1
>> >
>> > That's UB when begin() =3D=3D end(), no?
>>
>> Yes, but you can't dereference the begin pointer that way either when th=
e=20
>> list
>> is empty.
>>
>>
> You don't need to dereference begin() when the range is empty and you als=
o=20
> don't need to dereference end(). For a typical example of a C API that=20
> takes a pointer and a size, a C++ wrapper using iterators can easily be=
=20
> implemented as
>
> void c_style_function(void* start, size_t size);
>
> template <typename RandomAccessIterator>
> void cpp_wrapper(RandomAccessIterator begin, RandomAccessIterator=20
> end) {
> auto const size =3D std::distance(begin, end);
>
> if (size !=3D 0) {
> auto begin_ptr =3D std::addressof(*begin);
>
> c_style_function(begin_ptr, size);
> }
> }
>
> If one additionally creates a trait for contiguous iterators, the templat=
e=20
> can also be restricted accordingly. And for C APIs that expect an end=20
> pointer instead of a size argument you can also compute the end pointer=
=20
> from begin_ptr and size. As far as I can tell this doesn't cause UB and=
=20
> does exactly what the OP would like to achieve, without needing the=20
> iterators to be pointers.
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621%40isocpp.or=
g.
------=_Part_5098_147088566.1503324605436
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Horrible. Random Access Iterators are not Contiguous =
Iterators. If somebody passes deque iterators into it, UB. Pointers can gua=
ranteed to be contiguous iterators.</div><div><br></div><div><br>On Monday,=
August 21, 2017 at 6:07:25 AM UTC+8, Manuel Bergler wrote:</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br><div class=3D"=
gmail_quote">On Sun, Aug 20, 2017 at 8:43 PM, Thiago Macieira <span dir=3D"=
ltr"><<a onmousedown=3D"this.href=3D'javascript:';return true;" =
onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascri=
pt:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"MOJS-9gECw=
AJ">thi...@macieira.org</a>></span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><span>On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dominiak wrot=
e:<br>
> On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <<a onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;" href=3D"javascript:" target=3D"_blank" rel=3D=
"nofollow" gdf-obfuscated-mailto=3D"MOJS-9gECwAJ">thi...@macieira.org</a>&g=
t; wrote:<br>
> > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:<br>
> > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <<a onmou=
sedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.h=
ref=3D'javascript:';return true;" href=3D"javascript:" target=3D"_b=
lank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"MOJS-9gECwAJ">berg...@gmail=
..com</a>><br>
> ><br>
> > wrote:<br>
> > > > I don't understand what exactly doesn't work. W=
hat's wrong with<br>
> ><br>
> > converting<br>
> ><br>
> > > > the iterators to pointers by using std::addressof(*iter=
ator)?<br>
> > ><br>
> > > Dereferencing *end() is undefined behavior.<br>
> ><br>
> > std::addressof(end()[-1]) + 1<br>
><br>
> That's UB when begin() =3D=3D end(), no?<br>
<br>
</span>Yes, but you can't dereference the begin pointer that way either=
when the list<br>
is empty.<br>
<span><br></span></blockquote><div><br></div><div>You don't need to der=
eference begin() when the range is empty and you also don't need to der=
eference end(). For a typical example of a C API that takes a pointer and a=
size, a C++ wrapper using iterators can easily be implemented as</div><div=
><br></div><div>=C2=A0 =C2=A0 =C2=A0void c_style_function(void* start, size=
_t size);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0template <typenam=
e RandomAccessIterator></div><div>=C2=A0 =C2=A0 =C2=A0void cpp_wrapper(<=
wbr>RandomAccessIterator begin, RandomAccessIterator end) {</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto const size =3D std::distance(begin, en=
d);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (size !=
=3D 0) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto be=
gin_ptr =3D std::addressof(*begin);</div><div><br></div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 c_style_function(begin_ptr, size);</div>=
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0 =C2=A0}</d=
iv><div><br></div><div>If one additionally creates a trait for contiguous i=
terators, the template can also be restricted accordingly. And for C APIs t=
hat expect an end pointer instead of a size argument you can also compute t=
he end pointer from begin_ptr and size. As far as I can tell this doesn'=
;t cause UB and does exactly what the OP would like to achieve, without nee=
ding the iterators to be pointers.</div></div></div></div>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621=
%40isocpp.org</a>.<br />
------=_Part_5098_147088566.1503324605436--
------=_Part_5097_2029195776.1503324605436--
.
Author: Manuel Bergler <berglerma@gmail.com>
Date: Mon, 21 Aug 2017 16:14:35 +0200
Raw View
--001a114172de4145c3055744191d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Aug 21, 2017 at 4:10 PM, <euloanty@live.com> wrote:
> Horrible. Random Access Iterators are not Contiguous Iterators. If
> somebody passes deque iterators into it, UB. Pointers can guaranteed to b=
e
> contiguous iterators.
>
>
That's why I wrote one should add a custom trait for contiguous
iterators... The point was to show that you can easily get the pointers to
the elements pointed to by the iterator, not to write a complete
implementation. Right now the template is unconstrained, so you could even
pass std::list iterators even though they don't satify the
RandomAccessIterator concept.
> On Monday, August 21, 2017 at 6:07:25 AM UTC+8, Manuel Bergler wrote:
>
>>
>> On Sun, Aug 20, 2017 at 8:43 PM, Thiago Macieira <thi...@macieira.org>
>> wrote:
>>
>>> On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dominiak wrote:
>>> > On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <thi...@macieira.org>
>>> wrote:
>>> > > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:
>>> > > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <berg...@gmail.co=
m
>>> >
>>> > >
>>> > > wrote:
>>> > > > > I don't understand what exactly doesn't work. What's wrong with
>>> > >
>>> > > converting
>>> > >
>>> > > > > the iterators to pointers by using std::addressof(*iterator)?
>>> > > >
>>> > > > Dereferencing *end() is undefined behavior.
>>> > >
>>> > > std::addressof(end()[-1]) + 1
>>> >
>>> > That's UB when begin() =3D=3D end(), no?
>>>
>>> Yes, but you can't dereference the begin pointer that way either when
>>> the list
>>> is empty.
>>>
>>>
>> You don't need to dereference begin() when the range is empty and you
>> also don't need to dereference end(). For a typical example of a C API t=
hat
>> takes a pointer and a size, a C++ wrapper using iterators can easily be
>> implemented as
>>
>> void c_style_function(void* start, size_t size);
>>
>> template <typename RandomAccessIterator>
>> void cpp_wrapper(RandomAccessIterator begin, RandomAccessIterator
>> end) {
>> auto const size =3D std::distance(begin, end);
>>
>> if (size !=3D 0) {
>> auto begin_ptr =3D std::addressof(*begin);
>>
>> c_style_function(begin_ptr, size);
>> }
>> }
>>
>> If one additionally creates a trait for contiguous iterators, the
>> template can also be restricted accordingly. And for C APIs that expect =
an
>> end pointer instead of a size argument you can also compute the end poin=
ter
>> from begin_ptr and size. As far as I can tell this doesn't cause UB and
>> does exactly what the OP would like to achieve, without needing the
>> iterators to be pointers.
>>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/5d5b4b9b-907d-4f86-
> aa20-493c99915621%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-90=
7d-4f86-aa20-493c99915621%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAM76qmtOfm8q7O1dqdWdGRWBgtDhUC1xsrLmvcUX4dJvRJa=
h0g%40mail.gmail.com.
--001a114172de4145c3055744191d
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 Mon, Aug 21, 2017 at 4:10 PM, <span dir=3D"ltr"><<a href=3D"mail=
to:euloanty@live.com" target=3D"_blank">euloanty@live.com</a>></span> wr=
ote:<br><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>Horrible. Rand=
om Access Iterators are not Contiguous Iterators. If somebody passes deque =
iterators into it, UB. Pointers can guaranteed to be contiguous iterators.<=
/div><div><br></div></div></blockquote><div><br></div><div>That's why I=
wrote one should add a custom trait for contiguous iterators...=C2=A0 The =
point was to show that you can easily get the pointers to the elements poin=
ted to by the iterator, not to write a complete implementation. Right now t=
he template is unconstrained, so you could even pass std::list iterators ev=
en though they don't satify the RandomAccessIterator concept.</div><div=
> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div=
><br>On Monday, August 21, 2017 at 6:07:25 AM UTC+8, Manuel Bergler wrote:<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br><div=
class=3D"gmail_quote"><span class=3D"">On Sun, Aug 20, 2017 at 8:43 PM, Th=
iago Macieira <span dir=3D"ltr"><<a rel=3D"nofollow">thi...@macieira.org=
</a>></span> wrote:<br></span><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><span=
class=3D"">On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dominiak wro=
te:<br></span><span class=3D"">
> On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <<a rel=3D"nofollow">=
thi...@macieira.org</a>> wrote:<br>
> > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:<br></sp=
an>
> > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <<a rel=
=3D"nofollow">berg...@gmail.com</a>><span class=3D""><br>
> ><br>
> > wrote:<br>
> > > > I don't understand what exactly doesn't work. W=
hat's wrong with<br>
> ><br>
> > converting<br>
> ><br>
> > > > the iterators to pointers by using std::addressof(*iter=
ator)?<br>
> > ><br>
> > > Dereferencing *end() is undefined behavior.<br>
> ><br>
> > std::addressof(end()[-1]) + 1<br>
><br>
> That's UB when begin() =3D=3D end(), no?<br>
<br>
</span></span><span class=3D"">Yes, but you can't dereference the begin=
pointer that way either when the list<br>
is empty.<br>
<span><br></span></span></blockquote><span class=3D""><div><br></div><div>Y=
ou don't need to dereference begin() when the range is empty and you al=
so don't need to dereference end(). For a typical example of a C API th=
at takes a pointer and a size, a C++ wrapper using iterators can easily be =
implemented as</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0void c_style_fu=
nction(void* start, size_t size);</div><div><br></div><div>=C2=A0 =C2=A0 =
=C2=A0template <typename RandomAccessIterator></div><div>=C2=A0 =C2=
=A0 =C2=A0void cpp_wrapper(RandomAccessIterat<wbr>or begin, RandomAccessIte=
rator end) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto const size =
=3D std::distance(begin, end);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 if (size !=3D 0) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 auto begin_ptr =3D std::addressof(*begin);</div><div><=
br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 c_style_func=
tion(begin_ptr, size);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><=
div>=C2=A0 =C2=A0 =C2=A0}</div><div><br></div><div>If one additionally crea=
tes a trait for contiguous iterators, the template can also be restricted a=
ccordingly. And for C APIs that expect an end pointer instead of a size arg=
ument you can also compute the end pointer from begin_ptr and size. As far =
as I can tell this doesn't cause UB and does exactly what the OP would =
like to achieve, without needing the iterators to be pointers.</div></span>=
</div></div></div>
</blockquote></div>
<p></p>
-- <br><span class=3D"">
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@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/5d5b=
4b9b-907d-4f86-<wbr>aa20-493c99915621%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAM76qmtOfm8q7O1dqdWdGRWBgtDhUC1xsrLm=
vcUX4dJvRJah0g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM76qmtOfm8q7O1d=
qdWdGRWBgtDhUC1xsrLmvcUX4dJvRJah0g%40mail.gmail.com</a>.<br />
--001a114172de4145c3055744191d--
.
Author: euloanty@live.com
Date: Mon, 21 Aug 2017 07:17:45 -0700 (PDT)
Raw View
------=_Part_6757_180225085.1503325065662
Content-Type: multipart/alternative;
boundary="----=_Part_6758_1459739942.1503325065663"
------=_Part_6758_1459739942.1503325065663
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Contiguous iterators might also be initialized by pointers. That would be=
=20
easier to convert to contiguous iterators from pointers.
On Monday, August 21, 2017 at 10:14:43 PM UTC+8, Manuel Bergler wrote:
>
>
>
> On Mon, Aug 21, 2017 at 4:10 PM, <eulo...@live.com <javascript:>> wrote:
>
>> Horrible. Random Access Iterators are not Contiguous Iterators. If=20
>> somebody passes deque iterators into it, UB. Pointers can guaranteed to =
be=20
>> contiguous iterators.
>>
>>
> That's why I wrote one should add a custom trait for contiguous=20
> iterators... The point was to show that you can easily get the pointers =
to=20
> the elements pointed to by the iterator, not to write a complete=20
> implementation. Right now the template is unconstrained, so you could eve=
n=20
> pass std::list iterators even though they don't satify the=20
> RandomAccessIterator concept.
>
>
>> On Monday, August 21, 2017 at 6:07:25 AM UTC+8, Manuel Bergler wrote:
>>
>>>
>>> On Sun, Aug 20, 2017 at 8:43 PM, Thiago Macieira <thi...@macieira.org>=
=20
>>> wrote:
>>>
>>>> On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dominiak wrote:
>>>> > On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <thi...@macieira.org>=
=20
>>>> wrote:
>>>> > > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:
>>>> > > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <
>>>> berg...@gmail.com>
>>>> > >
>>>> > > wrote:
>>>> > > > > I don't understand what exactly doesn't work. What's wrong wit=
h
>>>> > >
>>>> > > converting
>>>> > >
>>>> > > > > the iterators to pointers by using std::addressof(*iterator)?
>>>> > > >
>>>> > > > Dereferencing *end() is undefined behavior.
>>>> > >
>>>> > > std::addressof(end()[-1]) + 1
>>>> >
>>>> > That's UB when begin() =3D=3D end(), no?
>>>>
>>>> Yes, but you can't dereference the begin pointer that way either when=
=20
>>>> the list
>>>> is empty.
>>>>
>>>>
>>> You don't need to dereference begin() when the range is empty and you=
=20
>>> also don't need to dereference end(). For a typical example of a C API =
that=20
>>> takes a pointer and a size, a C++ wrapper using iterators can easily be=
=20
>>> implemented as
>>>
>>> void c_style_function(void* start, size_t size);
>>>
>>> template <typename RandomAccessIterator>
>>> void cpp_wrapper(RandomAccessIterator begin, RandomAccessIterator=
=20
>>> end) {
>>> auto const size =3D std::distance(begin, end);
>>>
>>> if (size !=3D 0) {
>>> auto begin_ptr =3D std::addressof(*begin);
>>>
>>> c_style_function(begin_ptr, size);
>>> }
>>> }
>>>
>>> If one additionally creates a trait for contiguous iterators, the=20
>>> template can also be restricted accordingly. And for C APIs that expect=
an=20
>>> end pointer instead of a size argument you can also compute the end poi=
nter=20
>>> from begin_ptr and size. As far as I can tell this doesn't cause UB and=
=20
>>> does exactly what the OP would like to achieve, without needing the=20
>>> iterators to be pointers.
>>>
>> --=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:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-90=
7d-4f86-aa20-493c99915621%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-9=
07d-4f86-aa20-493c99915621%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9be523a7-ec66-4e3f-a8f5-3c00ff49a588%40isocpp.or=
g.
------=_Part_6758_1459739942.1503325065663
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Contiguous iterators might also be initialized by pointers=
.. That would be easier to convert to contiguous iterators from pointers.<br=
><br>On Monday, August 21, 2017 at 10:14:43 PM UTC+8, Manuel Bergler wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><br>=
<div class=3D"gmail_quote">On Mon, Aug 21, 2017 at 4:10 PM, <span dir=3D"l=
tr"><<a onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"GALZCaI5CwA=
J">eulo...@live.com</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div>Horrible. Random Access Iterators are not Contiguous=
Iterators. If somebody passes deque iterators into it, UB. Pointers can gu=
aranteed to be contiguous iterators.</div><div><br></div></div></blockquote=
><div><br></div><div>That's why I wrote one should add a custom trait f=
or contiguous iterators...=C2=A0 The point was to show that you can easily =
get the pointers to the elements pointed to by the iterator, not to write a=
complete implementation. Right now the template is unconstrained, so you c=
ould even pass std::list iterators even though they don't satify the Ra=
ndomAccessIterator concept.</div><div> <br></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><br>On Monday, August 21, 2017 at 6:0=
7:25 AM UTC+8, Manuel Bergler wrote:</div><blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div><br><div class=3D"gmail_quote"><span>On Sun, A=
ug 20, 2017 at 8:43 PM, Thiago Macieira <span dir=3D"ltr"><<a rel=3D"nof=
ollow">thi...@macieira.org</a>></span> wrote:<br></span><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><span><span>On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=
=82 Dominiak wrote:<br></span><span>
> On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <<a rel=3D"nofollow">=
thi...@macieira.org</a>> wrote:<br>
> > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:<br></sp=
an>
> > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <<a rel=
=3D"nofollow">berg...@gmail.com</a>><span><br>
> ><br>
> > wrote:<br>
> > > > I don't understand what exactly doesn't work. W=
hat's wrong with<br>
> ><br>
> > converting<br>
> ><br>
> > > > the iterators to pointers by using std::addressof(*iter=
ator)?<br>
> > ><br>
> > > Dereferencing *end() is undefined behavior.<br>
> ><br>
> > std::addressof(end()[-1]) + 1<br>
><br>
> That's UB when begin() =3D=3D end(), no?<br>
<br>
</span></span><span>Yes, but you can't dereference the begin pointer th=
at way either when the list<br>
is empty.<br>
<span><br></span></span></blockquote><span><div><br></div><div>You don'=
t need to dereference begin() when the range is empty and you also don'=
t need to dereference end(). For a typical example of a C API that takes a =
pointer and a size, a C++ wrapper using iterators can easily be implemented=
as</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0void c_style_function(void=
* start, size_t size);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0templat=
e <typename RandomAccessIterator></div><div>=C2=A0 =C2=A0 =C2=A0void =
cpp_wrapper(<wbr>RandomAccessIterator begin, RandomAccessIterator end) {</d=
iv><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto const size =3D std::distanc=
e(begin, end);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
if (size !=3D 0) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 auto begin_ptr =3D std::addressof(*begin);</div><div><br></div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 c_style_function(begin_ptr, s=
ize);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0=
=C2=A0}</div><div><br></div><div>If one additionally creates a trait for c=
ontiguous iterators, the template can also be restricted accordingly. And f=
or C APIs that expect an end pointer instead of a size argument you can als=
o compute the end pointer from begin_ptr and size. As far as I can tell thi=
s doesn't cause UB and does exactly what the OP would like to achieve, =
without needing the iterators to be pointers.</div></span></div></div></div=
>
</blockquote></div>
<p></p>
-- <br><span>
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 onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"GALZCaI5CwA=
J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"GALZCaI5CwAJ">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a onmousedown=3D"this.href=3D'=
;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-907d=
-4f86-aa20-493c99915621%40isocpp.org?utm_medium\x3demail\x26utm_source\x3df=
ooter';return true;" onclick=3D"this.href=3D'https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621=
%40isocpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;=
" href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b=
4b9b-907d-4f86-aa20-493c99915621%40isocpp.org?utm_medium=3Demail&utm_so=
urce=3Dfooter" target=3D"_blank" rel=3D"nofollow">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/5d5b4b9b-907d-4f86-<wbr>aa20-=
493c99915621%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9be523a7-ec66-4e3f-a8f5-3c00ff49a588%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9be523a7-ec66-4e3f-a8f5-3c00ff49a588=
%40isocpp.org</a>.<br />
------=_Part_6758_1459739942.1503325065663--
------=_Part_6757_180225085.1503325065662--
.
Author: Manuel Bergler <berglerma@gmail.com>
Date: Mon, 21 Aug 2017 16:32:07 +0200
Raw View
--001a113df3e8f999fd0557445745
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Aug 21, 2017 at 4:17 PM, <euloanty@live.com> wrote:
> Contiguous iterators might also be initialized by pointers. That would be
> easier to convert to contiguous iterators from pointers.
>
Yes, but as was pointed out by other people already, there is no chance to
get the Standard revised to mandate iterators of contiguous containers to
be pointers.
When you instead write a custom trait for contiguous iterators, you can
also immedately specialize it for pointers in addition to the std
containers so that pointers also work with such a function template. The
only "drawback" you have is that you have to write the trait, but we can
discuss the merits of such a trait and maybe extend the iterator categories
to include it. Then at least in the future no one has to write it
themselves.
>
> On Monday, August 21, 2017 at 10:14:43 PM UTC+8, Manuel Bergler wrote:
>>
>>
>>
>> On Mon, Aug 21, 2017 at 4:10 PM, <eulo...@live.com> wrote:
>>
>>> Horrible. Random Access Iterators are not Contiguous Iterators. If
>>> somebody passes deque iterators into it, UB. Pointers can guaranteed to=
be
>>> contiguous iterators.
>>>
>>>
>> That's why I wrote one should add a custom trait for contiguous
>> iterators... The point was to show that you can easily get the pointers=
to
>> the elements pointed to by the iterator, not to write a complete
>> implementation. Right now the template is unconstrained, so you could ev=
en
>> pass std::list iterators even though they don't satify the
>> RandomAccessIterator concept.
>>
>>
>>> On Monday, August 21, 2017 at 6:07:25 AM UTC+8, Manuel Bergler wrote:
>>>
>>>>
>>>> On Sun, Aug 20, 2017 at 8:43 PM, Thiago Macieira <thi...@macieira.org>
>>>> wrote:
>>>>
>>>>> On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dominiak wrote:
>>>>> > On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <thi...@macieira.org>
>>>>> wrote:
>>>>> > > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:
>>>>> > > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <
>>>>> berg...@gmail.com>
>>>>> > >
>>>>> > > wrote:
>>>>> > > > > I don't understand what exactly doesn't work. What's wrong wi=
th
>>>>> > >
>>>>> > > converting
>>>>> > >
>>>>> > > > > the iterators to pointers by using std::addressof(*iterator)?
>>>>> > > >
>>>>> > > > Dereferencing *end() is undefined behavior.
>>>>> > >
>>>>> > > std::addressof(end()[-1]) + 1
>>>>> >
>>>>> > That's UB when begin() =3D=3D end(), no?
>>>>>
>>>>> Yes, but you can't dereference the begin pointer that way either when
>>>>> the list
>>>>> is empty.
>>>>>
>>>>>
>>>> You don't need to dereference begin() when the range is empty and you
>>>> also don't need to dereference end(). For a typical example of a C API=
that
>>>> takes a pointer and a size, a C++ wrapper using iterators can easily b=
e
>>>> implemented as
>>>>
>>>> void c_style_function(void* start, size_t size);
>>>>
>>>> template <typename RandomAccessIterator>
>>>> void cpp_wrapper(RandomAccessIterator begin, RandomAccessIterator
>>>> end) {
>>>> auto const size =3D std::distance(begin, end);
>>>>
>>>> if (size !=3D 0) {
>>>> auto begin_ptr =3D std::addressof(*begin);
>>>>
>>>> c_style_function(begin_ptr, size);
>>>> }
>>>> }
>>>>
>>>> If one additionally creates a trait for contiguous iterators, the
>>>> template can also be restricted accordingly. And for C APIs that expec=
t an
>>>> end pointer instead of a size argument you can also compute the end po=
inter
>>>> from begin_ptr and size. As far as I can tell this doesn't cause UB an=
d
>>>> does exactly what the OP would like to achieve, without needing the
>>>> iterators to be pointers.
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/5d5b4b9b-907d-4f86-aa20-
>>> 493c99915621%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-=
907d-4f86-aa20-493c99915621%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>
>> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/9be523a7-ec66-4e3f-
> a8f5-3c00ff49a588%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9be523a7-ec=
66-4e3f-a8f5-3c00ff49a588%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAM76qmuFyse%3D3NbFWJ4KVNFLMxAHRJEzGEzpTWq1gJ14Y=
ARPYA%40mail.gmail.com.
--001a113df3e8f999fd0557445745
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">On M=
on, Aug 21, 2017 at 4:17 PM, <span dir=3D"ltr"><<a href=3D"mailto:euloa=
nty@live.com" target=3D"_blank">euloanty@live.com</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Contiguous iterators might =
also be initialized by pointers. That would be easier to convert to contigu=
ous iterators from pointers.<br></div></blockquote><div><br></div><div>Yes,=
but as was pointed out by other people already, there is no chance to get =
the Standard revised to mandate iterators of contiguous containers to be po=
inters.</div><div><br></div><div>When you instead write a custom trait for =
contiguous iterators, you can also immedately specialize it for pointers in=
addition to the std containers so that pointers also work with such a func=
tion template. The only "drawback" you have is that you have to w=
rite the trait, but we can discuss the merits of such a trait and maybe ext=
end the iterator categories to include it. Then at least in the future no o=
ne has to write it themselves. <br></div><div>=C2=A0</div><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"><br>On Monday, August 21, 2017 at 10:14:43 P=
M UTC+8, Manuel Bergler wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><br><div><br><div class=3D"gmail_quote"><div><div class=3D"h5">=
On Mon, Aug 21, 2017 at 4:10 PM, <span dir=3D"ltr"><<a rel=3D"nofollow"=
>eulo...@live.com</a>></span> wrote:<br><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>Horrible. Random Access Iterators are not Contiguous I=
terators. If somebody passes deque iterators into it, UB. Pointers can guar=
anteed to be contiguous iterators.</div><div><br></div></div></blockquote><=
div><br></div><div>That's why I wrote one should add a custom trait for=
contiguous iterators...=C2=A0 The point was to show that you can easily ge=
t the pointers to the elements pointed to by the iterator, not to write a c=
omplete implementation. Right now the template is unconstrained, so you cou=
ld even pass std::list iterators even though they don't satify the Rand=
omAccessIterator concept.</div><div> <br></div></div></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr"><div></div><div><br>=
On Monday, August 21, 2017 at 6:07:25 AM UTC+8, Manuel Bergler wrote:</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br><div clas=
s=3D"gmail_quote"><span>On Sun, Aug 20, 2017 at 8:43 PM, Thiago Macieira <s=
pan dir=3D"ltr"><<a rel=3D"nofollow">thi...@macieira.org</a>></span> =
wrote:<br></span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><span><span>On Sunday, 20 A=
ugust 2017 10:37:07 PDT Micha=C5=82 Dominiak wrote:<br></span><span>
> On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <<a rel=3D"nofollow">=
thi...@macieira.org</a>> wrote:<br>
> > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:<br></sp=
an>
> > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <<a rel=
=3D"nofollow">berg...@gmail.com</a>><span><br>
> ><br>
> > wrote:<br>
> > > > I don't understand what exactly doesn't work. W=
hat's wrong with<br>
> ><br>
> > converting<br>
> ><br>
> > > > the iterators to pointers by using std::addressof(*iter=
ator)?<br>
> > ><br>
> > > Dereferencing *end() is undefined behavior.<br>
> ><br>
> > std::addressof(end()[-1]) + 1<br>
><br>
> That's UB when begin() =3D=3D end(), no?<br>
<br>
</span></span><span>Yes, but you can't dereference the begin pointer th=
at way either when the list<br>
is empty.<br>
<span><br></span></span></blockquote><span><div><br></div><div>You don'=
t need to dereference begin() when the range is empty and you also don'=
t need to dereference end(). For a typical example of a C API that takes a =
pointer and a size, a C++ wrapper using iterators can easily be implemented=
as</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0void c_style_function(void=
* start, size_t size);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0templat=
e <typename RandomAccessIterator></div><div>=C2=A0 =C2=A0 =C2=A0void =
cpp_wrapper(RandomAccessIterat<wbr>or begin, RandomAccessIterator end) {</d=
iv><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto const size =3D std::distanc=
e(begin, end);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
if (size !=3D 0) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 auto begin_ptr =3D std::addressof(*begin);</div><div><br></div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 c_style_function(begin_ptr, s=
ize);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0=
=C2=A0}</div><div><br></div><div>If one additionally creates a trait for c=
ontiguous iterators, the template can also be restricted accordingly. And f=
or C APIs that expect an end pointer instead of a size argument you can als=
o compute the end pointer from begin_ptr and size. As far as I can tell thi=
s doesn't cause UB and does exactly what the OP would like to achieve, =
without needing the iterators to be pointers.</div></span></div></div></div=
>
</blockquote></div>
<p></p>
-- <br></div></div><span><div><div class=3D"h5">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span><span class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/5d5b4b9b-907d-4f86-aa20-<wbr>493c99915621%40isocpp.org</a>.<br=
>
</span></blockquote></div><br></div></div>
</blockquote></div><span class=3D"">
<p></p>
-- <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@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9be523a7-ec66-4e3f-a8f5-3c00ff49a588%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/9be5=
23a7-ec66-4e3f-<wbr>a8f5-3c00ff49a588%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAM76qmuFyse%3D3NbFWJ4KVNFLMxAHRJEzGE=
zpTWq1gJ14YARPYA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM76qmuFyse%3D=
3NbFWJ4KVNFLMxAHRJEzGEzpTWq1gJ14YARPYA%40mail.gmail.com</a>.<br />
--001a113df3e8f999fd0557445745--
.
Author: euloanty@live.com
Date: Mon, 21 Aug 2017 08:04:32 -0700 (PDT)
Raw View
------=_Part_1866_2118012792.1503327872971
Content-Type: multipart/alternative;
boundary="----=_Part_1867_1468809472.1503327872972"
------=_Part_1867_1468809472.1503327872972
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Contiguous iterator fails to accomplish anything. It is a horrible idea=20
from the beginning. Just like .data(). Some containers uses "proxy=20
pointers" and it cant even be converted to pointers. Is it a contiguous=20
container??
If concepts like contiguous iterators are just for converting to a raw=20
pointer, I don't think it should be implemented at the first place.
On Monday, August 21, 2017 at 10:32:11 PM UTC+8, Manuel Bergler wrote:
> On Mon, Aug 21, 2017 at 4:17 PM, <eulo...@live.com <javascript:>> wrote:
>
>> Contiguous iterators might also be initialized by pointers. That would b=
e=20
>> easier to convert to contiguous iterators from pointers.
>>
>
> Yes, but as was pointed out by other people already, there is no chance t=
o=20
> get the Standard revised to mandate iterators of contiguous containers to=
=20
> be pointers.
>
> When you instead write a custom trait for contiguous iterators, you can=
=20
> also immedately specialize it for pointers in addition to the std=20
> containers so that pointers also work with such a function template. The=
=20
> only "drawback" you have is that you have to write the trait, but we can=
=20
> discuss the merits of such a trait and maybe extend the iterator categori=
es=20
> to include it. Then at least in the future no one has to write it=20
> themselves.=20
> =20
>
>>
>> On Monday, August 21, 2017 at 10:14:43 PM UTC+8, Manuel Bergler wrote:
>>>
>>>
>>>
>>> On Mon, Aug 21, 2017 at 4:10 PM, <eulo...@live.com> wrote:
>>>
>>>> Horrible. Random Access Iterators are not Contiguous Iterators. If=20
>>>> somebody passes deque iterators into it, UB. Pointers can guaranteed t=
o be=20
>>>> contiguous iterators.
>>>>
>>>>
>>> That's why I wrote one should add a custom trait for contiguous=20
>>> iterators... The point was to show that you can easily get the pointer=
s to=20
>>> the elements pointed to by the iterator, not to write a complete=20
>>> implementation. Right now the template is unconstrained, so you could e=
ven=20
>>> pass std::list iterators even though they don't satify the=20
>>> RandomAccessIterator concept.
>>>
>>>
>>>> On Monday, August 21, 2017 at 6:07:25 AM UTC+8, Manuel Bergler wrote:
>>>>
>>>>>
>>>>> On Sun, Aug 20, 2017 at 8:43 PM, Thiago Macieira <thi...@macieira.org=
>=20
>>>>> wrote:
>>>>>
>>>>>> On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dominiak wrote:
>>>>>> > On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <thi...@macieira.org=
>=20
>>>>>> wrote:
>>>>>> > > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:
>>>>>> > > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <
>>>>>> berg...@gmail.com>
>>>>>> > >
>>>>>> > > wrote:
>>>>>> > > > > I don't understand what exactly doesn't work. What's wrong=
=20
>>>>>> with
>>>>>> > >
>>>>>> > > converting
>>>>>> > >
>>>>>> > > > > the iterators to pointers by using std::addressof(*iterator)=
?
>>>>>> > > >
>>>>>> > > > Dereferencing *end() is undefined behavior.
>>>>>> > >
>>>>>> > > std::addressof(end()[-1]) + 1
>>>>>> >
>>>>>> > That's UB when begin() =3D=3D end(), no?
>>>>>>
>>>>>> Yes, but you can't dereference the begin pointer that way either whe=
n=20
>>>>>> the list
>>>>>> is empty.
>>>>>>
>>>>>>
>>>>> You don't need to dereference begin() when the range is empty and you=
=20
>>>>> also don't need to dereference end(). For a typical example of a C AP=
I that=20
>>>>> takes a pointer and a size, a C++ wrapper using iterators can easily =
be=20
>>>>> implemented as
>>>>>
>>>>> void c_style_function(void* start, size_t size);
>>>>>
>>>>> template <typename RandomAccessIterator>
>>>>> void cpp_wrapper(RandomAccessIterator begin, RandomAccessIterato=
r=20
>>>>> end) {
>>>>> auto const size =3D std::distance(begin, end);
>>>>>
>>>>> if (size !=3D 0) {
>>>>> auto begin_ptr =3D std::addressof(*begin);
>>>>>
>>>>> c_style_function(begin_ptr, size);
>>>>> }
>>>>> }
>>>>>
>>>>> If one additionally creates a trait for contiguous iterators, the=20
>>>>> template can also be restricted accordingly. And for C APIs that expe=
ct an=20
>>>>> end pointer instead of a size argument you can also compute the end p=
ointer=20
>>>>> from begin_ptr and size. As far as I can tell this doesn't cause UB a=
nd=20
>>>>> does exactly what the OP would like to achieve, without needing the=
=20
>>>>> iterators to be pointers.
>>>>>
>>>> --=20
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>> an email to std-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> To view this discussion on the web visit=20
>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-=
907d-4f86-aa20-493c99915621%40isocpp.org=20
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b=
-907d-4f86-aa20-493c99915621%40isocpp.org?utm_medium=3Demail&utm_source=3Df=
ooter>
>>>> .
>>>>
>>>
>>> --=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:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9be523a7-ec=
66-4e3f-a8f5-3c00ff49a588%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9be523a7-e=
c66-4e3f-a8f5-3c00ff49a588%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/953443c5-7dde-42b5-81c8-07a65b00b066%40isocpp.or=
g.
------=_Part_1867_1468809472.1503327872972
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Contiguous iterator fails to accomplish anything. It =
is a horrible idea from the beginning. Just like .data(). Some containers u=
ses "proxy pointers" and it cant even be converted to pointers. I=
s it a contiguous container??</div><div><br></div><div>If concepts like con=
tiguous iterators are just for converting to a raw pointer, I don't thi=
nk it should be implemented at the first place.<br><br>On Monday, August 21=
, 2017 at 10:32:11 PM UTC+8, Manuel Bergler wrote:</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
">On Mon, Aug 21, 2017 at 4:17 PM, <span dir=3D"ltr"><<a onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;" href=3D"javascript:" target=3D"_blank" rel=
=3D"nofollow" gdf-obfuscated-mailto=3D"H8TI65U6CwAJ">eulo...@live.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Contigu=
ous iterators might also be initialized by pointers. That would be easier t=
o convert to contiguous iterators from pointers.<br></div></blockquote><div=
><br></div><div>Yes, but as was pointed out by other people already, there =
is no chance to get the Standard revised to mandate iterators of contiguous=
containers to be pointers.</div><div><br></div><div>When you instead write=
a custom trait for contiguous iterators, you can also immedately specializ=
e it for pointers in addition to the std containers so that pointers also w=
ork with such a function template. The only "drawback" you have i=
s that you have to write the trait, but we can discuss the merits of such a=
trait and maybe extend the iterator categories to include it. Then at leas=
t in the future no one has to write it themselves. <br></div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>On Monday, August 21=
, 2017 at 10:14:43 PM UTC+8, Manuel Bergler wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><br><div><br><div class=3D"gmail_quote"><di=
v><div>On Mon, Aug 21, 2017 at 4:10 PM, <span dir=3D"ltr"><<a rel=3D"no=
follow">eulo...@live.com</a>></span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div>Horrible. Random Access Iterators are not Conti=
guous Iterators. If somebody passes deque iterators into it, UB. Pointers c=
an guaranteed to be contiguous iterators.</div><div><br></div></div></block=
quote><div><br></div><div>That's why I wrote one should add a custom tr=
ait for contiguous iterators...=C2=A0 The point was to show that you can ea=
sily get the pointers to the elements pointed to by the iterator, not to wr=
ite a complete implementation. Right now the template is unconstrained, so =
you could even pass std::list iterators even though they don't satify t=
he RandomAccessIterator concept.</div><div> <br></div></div></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div><div><div dir=3D"ltr"><div></div><div><br>On Mon=
day, August 21, 2017 at 6:07:25 AM UTC+8, Manuel Bergler wrote:</div><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br><div class=3D"g=
mail_quote"><span>On Sun, Aug 20, 2017 at 8:43 PM, Thiago Macieira <span di=
r=3D"ltr"><<a rel=3D"nofollow">thi...@macieira.org</a>></span> wrote:=
<br></span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span><span>On Sunday, 20 August =
2017 10:37:07 PDT Micha=C5=82 Dominiak wrote:<br></span><span>
> On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <<a rel=3D"nofollow">=
thi...@macieira.org</a>> wrote:<br>
> > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:<br></sp=
an>
> > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <<a rel=
=3D"nofollow">berg...@gmail.com</a>><span><br>
> ><br>
> > wrote:<br>
> > > > I don't understand what exactly doesn't work. W=
hat's wrong with<br>
> ><br>
> > converting<br>
> ><br>
> > > > the iterators to pointers by using std::addressof(*iter=
ator)?<br>
> > ><br>
> > > Dereferencing *end() is undefined behavior.<br>
> ><br>
> > std::addressof(end()[-1]) + 1<br>
><br>
> That's UB when begin() =3D=3D end(), no?<br>
<br>
</span></span><span>Yes, but you can't dereference the begin pointer th=
at way either when the list<br>
is empty.<br>
<span><br></span></span></blockquote><span><div><br></div><div>You don'=
t need to dereference begin() when the range is empty and you also don'=
t need to dereference end(). For a typical example of a C API that takes a =
pointer and a size, a C++ wrapper using iterators can easily be implemented=
as</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0void c_style_function(void=
* start, size_t size);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0templat=
e <typename RandomAccessIterator></div><div>=C2=A0 =C2=A0 =C2=A0void =
cpp_wrapper(<wbr>RandomAccessIterator begin, RandomAccessIterator end) {</d=
iv><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto const size =3D std::distanc=
e(begin, end);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
if (size !=3D 0) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 auto begin_ptr =3D std::addressof(*begin);</div><div><br></div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 c_style_function(begin_ptr, s=
ize);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0=
=C2=A0}</div><div><br></div><div>If one additionally creates a trait for c=
ontiguous iterators, the template can also be restricted accordingly. And f=
or C APIs that expect an end pointer instead of a size argument you can als=
o compute the end pointer from begin_ptr and size. As far as I can tell thi=
s doesn't cause UB and does exactly what the OP would like to achieve, =
without needing the iterators to be pointers.</div></span></div></div></div=
>
</blockquote></div>
<p></p>
-- <br></div></div><span><div><div>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span><span>
To view this discussion on the web visit <a onmousedown=3D"this.href=3D'=
;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-907d=
-4f86-aa20-493c99915621%40isocpp.org?utm_medium\x3demail\x26utm_source\x3df=
ooter';return true;" onclick=3D"this.href=3D'https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621=
%40isocpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;=
" href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b=
4b9b-907d-4f86-aa20-493c99915621%40isocpp.org?utm_medium=3Demail&utm_so=
urce=3Dfooter" target=3D"_blank" rel=3D"nofollow">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/5d5b4b9b-907d-4f86-<wbr>aa20-=
493c99915621%40isocpp.org</a><wbr>.<br>
</span></blockquote></div><br></div></div>
</blockquote></div><span>
<p></p>
-- <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 onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"H8TI65U6CwA=
J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"H8TI65U6CwAJ">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a onmousedown=3D"this.href=3D'=
;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9be523a7-ec66=
-4e3f-a8f5-3c00ff49a588%40isocpp.org?utm_medium\x3demail\x26utm_source\x3df=
ooter';return true;" onclick=3D"this.href=3D'https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9be523a7-ec66-4e3f-a8f5-3c00ff49a588=
%40isocpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;=
" href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9be5=
23a7-ec66-4e3f-a8f5-3c00ff49a588%40isocpp.org?utm_medium=3Demail&utm_so=
urce=3Dfooter" target=3D"_blank" rel=3D"nofollow">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/9be523a7-ec66-4e3f-<wbr>a8f5-=
3c00ff49a588%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/953443c5-7dde-42b5-81c8-07a65b00b066%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/953443c5-7dde-42b5-81c8-07a65b00b066=
%40isocpp.org</a>.<br />
------=_Part_1867_1468809472.1503327872972--
------=_Part_1866_2118012792.1503327872971--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Mon, 21 Aug 2017 15:10:01 +0000
Raw View
--001a114f2f740e6ad4055744e0fb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Aug 21, 2017 at 5:04 PM <euloanty@live.com> wrote:
> Contiguous iterator fails to accomplish anything. It is a horrible idea
> from the beginning. Just like .data(). Some containers uses "proxy
> pointers" and it cant even be converted to pointers. Is it a contiguous
> container??
>
> If concepts like contiguous iterators are just for converting to a raw
> pointer, I don't think it should be implemented at the first place.
>
I'm very glad you're not the person to decide this, then.
>
> On Monday, August 21, 2017 at 10:32:11 PM UTC+8, Manuel Bergler wrote:
>
>> On Mon, Aug 21, 2017 at 4:17 PM, <eulo...@live.com> wrote:
>>
>>> Contiguous iterators might also be initialized by pointers. That would
>>> be easier to convert to contiguous iterators from pointers.
>>>
>>
>> Yes, but as was pointed out by other people already, there is no chance
>> to get the Standard revised to mandate iterators of contiguous container=
s
>> to be pointers.
>>
>> When you instead write a custom trait for contiguous iterators, you can
>> also immedately specialize it for pointers in addition to the std
>> containers so that pointers also work with such a function template. The
>> only "drawback" you have is that you have to write the trait, but we can
>> discuss the merits of such a trait and maybe extend the iterator categor=
ies
>> to include it. Then at least in the future no one has to write it
>> themselves.
>>
>>
>
>>> On Monday, August 21, 2017 at 10:14:43 PM UTC+8, Manuel Bergler wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Aug 21, 2017 at 4:10 PM, <eulo...@live.com> wrote:
>>>>
>>>>> Horrible. Random Access Iterators are not Contiguous Iterators. If
>>>>> somebody passes deque iterators into it, UB. Pointers can guaranteed =
to be
>>>>> contiguous iterators.
>>>>>
>>>>>
>>>> That's why I wrote one should add a custom trait for contiguous
>>>> iterators... The point was to show that you can easily get the pointe=
rs to
>>>> the elements pointed to by the iterator, not to write a complete
>>>> implementation. Right now the template is unconstrained, so you could =
even
>>>> pass std::list iterators even though they don't satify the
>>>> RandomAccessIterator concept.
>>>>
>>>>
>>>>> On Monday, August 21, 2017 at 6:07:25 AM UTC+8, Manuel Bergler wrote:
>>>>>
>>>>>>
>>>>>> On Sun, Aug 20, 2017 at 8:43 PM, Thiago Macieira <thi...@macieira.or=
g
>>>>>> > wrote:
>>>>>>
>>>>>>> On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dominiak wrote:
>>>>>>> > On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <thi...@macieira.or=
g>
>>>>>>> wrote:
>>>>>>> > > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:
>>>>>>> > > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <
>>>>>>> berg...@gmail.com>
>>>>>>> > >
>>>>>>> > > wrote:
>>>>>>> > > > > I don't understand what exactly doesn't work. What's wrong
>>>>>>> with
>>>>>>> > >
>>>>>>> > > converting
>>>>>>> > >
>>>>>>> > > > > the iterators to pointers by using std::addressof(*iterator=
)?
>>>>>>> > > >
>>>>>>> > > > Dereferencing *end() is undefined behavior.
>>>>>>> > >
>>>>>>> > > std::addressof(end()[-1]) + 1
>>>>>>> >
>>>>>>> > That's UB when begin() =3D=3D end(), no?
>>>>>>>
>>>>>>> Yes, but you can't dereference the begin pointer that way either
>>>>>>> when the list
>>>>>>> is empty.
>>>>>>>
>>>>>>>
>>>>>> You don't need to dereference begin() when the range is empty and yo=
u
>>>>>> also don't need to dereference end(). For a typical example of a C A=
PI that
>>>>>> takes a pointer and a size, a C++ wrapper using iterators can easily=
be
>>>>>> implemented as
>>>>>>
>>>>>> void c_style_function(void* start, size_t size);
>>>>>>
>>>>>> template <typename RandomAccessIterator>
>>>>>> void cpp_wrapper(RandomAccessIterator begin,
>>>>>> RandomAccessIterator end) {
>>>>>> auto const size =3D std::distance(begin, end);
>>>>>>
>>>>>> if (size !=3D 0) {
>>>>>> auto begin_ptr =3D std::addressof(*begin);
>>>>>>
>>>>>> c_style_function(begin_ptr, size);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> If one additionally creates a trait for contiguous iterators, the
>>>>>> template can also be restricted accordingly. And for C APIs that exp=
ect an
>>>>>> end pointer instead of a size argument you can also compute the end =
pointer
>>>>>> from begin_ptr and size. As far as I can tell this doesn't cause UB =
and
>>>>>> does exactly what the OP would like to achieve, without needing the
>>>>>> iterators to be pointers.
>>>>>>
>>>>> --
>>>>> 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, sen=
d
>>>>> an email to std-proposal...@isocpp.org.
>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b=
-907d-4f86-aa20-493c99915621%40isocpp.org
>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9=
b-907d-4f86-aa20-493c99915621%40isocpp.org?utm_medium=3Demail&utm_source=3D=
footer>
>>>>> .
>>>>>
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9be523a7-e=
c66-4e3f-a8f5-3c00ff49a588%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9be523a7-=
ec66-4e3f-a8f5-3c00ff49a588%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/953443c5-7dd=
e-42b5-81c8-07a65b00b066%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/953443c5-7d=
de-42b5-81c8-07a65b00b066%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAPCFJdRV%3DYQfRkhWWoUnDzt4NwNFOn%3Dqyv2yJQK%2BR=
0N36TvZVQ%40mail.gmail.com.
--001a114f2f740e6ad4055744e0fb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 21=
, 2017 at 5:04 PM <<a href=3D"mailto:euloanty@live.com">euloanty@live.co=
m</a>> wrote:<br></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>Contiguous iterator fails to accomplish anything. It is a horrible idea=
from the beginning. Just like .data(). Some containers uses "proxy po=
inters" and it cant even be converted to pointers. Is it a contiguous =
container??</div><div><br></div><div>If concepts like contiguous iterators =
are just for converting to a raw pointer, I don't think it should be im=
plemented at the first place.<br></div></div></blockquote><div><br></div><d=
iv>I'm very glad you're not the person to decide this, then.</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>On=
Monday, August 21, 2017 at 10:32:11 PM UTC+8, Manuel Bergler wrote:</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote"></div></div></div></blockquote></div><div dir=3D"ltr"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_q=
uote">On Mon, Aug 21, 2017 at 4:17 PM, <span dir=3D"ltr"><<a rel=3D"nof=
ollow">eulo...@live.com</a>></span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">Contiguous iterators might also be initialized by poi=
nters. That would be easier to convert to contiguous iterators from pointer=
s.<br></div></blockquote><div><br></div><div>Yes, but as was pointed out by=
other people already, there is no chance to get the Standard revised to ma=
ndate iterators of contiguous containers to be pointers.</div><div><br></di=
v><div>When you instead write a custom trait for contiguous iterators, you =
can also immedately specialize it for pointers in addition to the std conta=
iners so that pointers also work with such a function template. The only &q=
uot;drawback" you have is that you have to write the trait, but we can=
discuss the merits of such a trait and maybe extend the iterator categorie=
s to include it. Then at least in the future no one has to write it themsel=
ves. <br></div><div>=C2=A0</div></div></div></div></blockquote></div><div d=
ir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><d=
iv 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"><b=
r>On Monday, August 21, 2017 at 10:14:43 PM UTC+8, Manuel Bergler wrote:<bl=
ockquote 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"><br><div><br><div cla=
ss=3D"gmail_quote"><div><div>On Mon, Aug 21, 2017 at 4:10 PM, <span dir=3D=
"ltr"><<a rel=3D"nofollow">eulo...@live.com</a>></span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Horrible. Random Access I=
terators are not Contiguous Iterators. If somebody passes deque iterators i=
nto it, UB. Pointers can guaranteed to be contiguous iterators.</div><div><=
br></div></div></blockquote><div><br></div><div>That's why I wrote one =
should add a custom trait for contiguous iterators...=C2=A0 The point was t=
o show that you can easily get the pointers to the elements pointed to by t=
he iterator, not to write a complete implementation. Right now the template=
is unconstrained, so you could even pass std::list iterators even though t=
hey don't satify the RandomAccessIterator concept.</div><div> <br></div=
></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr"><div=
></div><div><br>On Monday, August 21, 2017 at 6:07:25 AM UTC+8, Manuel Berg=
ler wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv><br><div class=3D"gmail_quote"><span>On Sun, Aug 20, 2017 at 8:43 PM, Th=
iago Macieira <span dir=3D"ltr"><<a rel=3D"nofollow">thi...@macieira.org=
</a>></span> wrote:<br></span><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><span=
>On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dominiak wrote:<br></sp=
an><span>
> On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <<a rel=3D"nofollow">=
thi...@macieira.org</a>> wrote:<br>
> > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:<br></sp=
an>
> > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <<a rel=
=3D"nofollow">berg...@gmail.com</a>><span><br>
> ><br>
> > wrote:<br>
> > > > I don't understand what exactly doesn't work. W=
hat's wrong with<br>
> ><br>
> > converting<br>
> ><br>
> > > > the iterators to pointers by using std::addressof(*iter=
ator)?<br>
> > ><br>
> > > Dereferencing *end() is undefined behavior.<br>
> ><br>
> > std::addressof(end()[-1]) + 1<br>
><br>
> That's UB when begin() =3D=3D end(), no?<br>
<br>
</span></span><span>Yes, but you can't dereference the begin pointer th=
at way either when the list<br>
is empty.<br>
<span><br></span></span></blockquote><span><div><br></div><div>You don'=
t need to dereference begin() when the range is empty and you also don'=
t need to dereference end(). For a typical example of a C API that takes a =
pointer and a size, a C++ wrapper using iterators can easily be implemented=
as</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0void c_style_function(void=
* start, size_t size);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0templat=
e <typename RandomAccessIterator></div><div>=C2=A0 =C2=A0 =C2=A0void =
cpp_wrapper(RandomAccessIterator begin, RandomAccessIterator end) {</div><d=
iv>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto const size =3D std::distance(beg=
in, end);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (s=
ize !=3D 0) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 au=
to begin_ptr =3D std::addressof(*begin);</div><div><br></div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 c_style_function(begin_ptr, size)=
;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0 =C2=
=A0}</div><div><br></div><div>If one additionally creates a trait for conti=
guous iterators, the template can also be restricted accordingly. And for C=
APIs that expect an end pointer instead of a size argument you can also co=
mpute the end pointer from begin_ptr and size. As far as I can tell this do=
esn't cause UB and does exactly what the OP would like to achieve, with=
out needing the iterators to be pointers.</div></span></div></div></div>
</blockquote></div>
<p></p>
-- <br></div></div><span><div><div>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span><span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/5d5b4b9b-907d-4f86-aa20-493c99915621%40isocpp.org</a>.<br>
</span></blockquote></div><br></div></div>
</blockquote></div><span>
<p></p>
-- <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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span></blockquote></div></div></div></blockquote></div><div di=
r=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9be523a7-ec66-4e3f-a8f5-3c00ff49a588%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/9be523a7-ec66-4e3f-a8f5-3c00ff49a588%40isocpp.org</a>.<br>
</blockquote></div></div></div></blockquote></div>
<p></p>
-- <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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/953443c5-7dde-42b5-81c8-07a65b00b066%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/953443c5-7dde-=
42b5-81c8-07a65b00b066%40isocpp.org</a>.<br>
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRV%3DYQfRkhWWoUnDzt4NwNFOn%3Dq=
yv2yJQK%2BR0N36TvZVQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRV%3=
DYQfRkhWWoUnDzt4NwNFOn%3Dqyv2yJQK%2BR0N36TvZVQ%40mail.gmail.com</a>.<br />
--001a114f2f740e6ad4055744e0fb--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 21 Aug 2017 08:46:09 -0700 (PDT)
Raw View
------=_Part_5794_950882682.1503330369496
Content-Type: multipart/alternative;
boundary="----=_Part_5795_610055348.1503330369496"
------=_Part_5795_610055348.1503330369496
Content-Type: text/plain; charset="UTF-8"
On Monday, August 21, 2017 at 11:04:33 AM UTC-4, ejsvifq mabmip wrote:
>
> Contiguous iterator fails to accomplish anything. It is a horrible idea
> from the beginning. Just like .data().
>
OK, we all sometimes make declarations that "<insert thing the standard
does or proposal wants> is stupid". We're all guilt of doing that at one
time or another.
But when you're asked to explain what is so bad about it, and you repeated
refuse to justify such statements, it makes it difficult to effectively
engage in useful discussion.
Some containers uses "proxy pointers" and it cant even be converted to
> pointers.
>
Name one (besides `vector<bool>` which is not a true STL container to begin
with). `vector::data` is explicitly specified to return a `T*`, not a
"proxy pointer". This is regardless of what `allocator_traits::pointer`
says.
Is it a contiguous container??
>
Is what a contiguous container?
If concepts like contiguous iterators are just for converting to a raw
> pointer, I don't think it should be implemented at the first place.
>
No. It is important to have iterators exist as an abstraction where the
implementation feels such an abstraction is warranted. The GSL `span`
implementation, for example, tracks the size of the range and will check to
see if you're exceeding that boundary. But it's still a contiguous
iterator, and thus you should be able to do the operations that contiguous
iterators can do.
So long as users have the power to get at the pointer range, denying
implementers the right to provide such features serves no useful purpose.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/db8f891a-97f0-481d-8aad-2cab75971588%40isocpp.org.
------=_Part_5795_610055348.1503330369496
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 21, 2017 at 11:04:33 AM UTC-4, ejsvifq m=
abmip wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>Contiguous iterator fails to accomplish anything. It is a horrible idea=
from the beginning. Just like .data().</div></div></blockquote><div><br>OK=
, we all sometimes make declarations that "<insert thing the standa=
rd does or proposal wants> is stupid". We're all guilt of doing=
that at one time or another.<br><br>But when you're asked to explain w=
hat is so bad about it, and you repeated refuse to justify such statements,=
it makes it difficult to effectively engage in useful discussion.<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Som=
e containers uses "proxy pointers" and it cant even be converted =
to pointers.</div></div></blockquote><div><br>Name one (besides `vector<=
bool>` which is not a true STL container to begin with). `vector::data` =
is explicitly specified to return a `T*`, not a "proxy pointer". =
This is regardless of what `allocator_traits::pointer` says.<br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Is it a c=
ontiguous container??</div></div></blockquote><div><br>Is what a contiguous=
container?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div></div><div>If concepts like contiguous iterators are just =
for converting to a raw pointer, I don't think it should be implemented=
at the first place.</div></div></blockquote><div><br>No. It is important t=
o have iterators exist as an abstraction where the implementation feels suc=
h an abstraction is warranted. The GSL `span` implementation, for example, =
tracks the size of the range and will check to see if you're exceeding =
that boundary. But it's still a contiguous iterator, and thus you shoul=
d be able to do the operations that contiguous iterators can do.<br><br>So =
long as users have the power to get at the pointer range, denying implement=
ers the right to provide such features serves no useful purpose.</div></div=
>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/db8f891a-97f0-481d-8aad-2cab75971588%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/db8f891a-97f0-481d-8aad-2cab75971588=
%40isocpp.org</a>.<br />
------=_Part_5795_610055348.1503330369496--
------=_Part_5794_950882682.1503330369496--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Mon, 21 Aug 2017 13:32:38 -0700 (PDT)
Raw View
------=_Part_5746_1846284244.1503347558430
Content-Type: multipart/alternative;
boundary="----=_Part_5747_93049265.1503347558431"
------=_Part_5747_93049265.1503347558431
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Saturday, August 19, 2017 at 3:23:04 AM UTC-7, ejsvifq mabmip wrote:
>
>
> using pointer =3D *std::allocator_traits*=20
> <http://en.cppreference.com/w/cpp/memory/allocator_traits><Allocator>::
> pointer;
> using iterator =3D pointer;
>
Semi-tangential: I'll have a paper in Albuquerque on the subject of fancy=
=20
pointers and their proper uses; and this is *not* one of them IMO.
Different vendors, and different containers within the same vendor, differ=
=20
as to their use of fancy-pointers-in-iterators. For example,=20
libc++:
- Using fancy pointers: deque (both levels), forward_list, list, map, set,=
=20
unordered_map, unordered_set, vector
- Using raw pointers: none
libstdc++:
- Using fancy pointers: deque (both levels), vector
- Using raw pointers: forward_list, list, map, set, unordered_map,=20
unordered_set
MSVC:
- Using fancy pointers: forward_list, list, map, set, unordered_map,=20
unordered_set, vector
- Using raw pointers: deque (both levels)
The test harness that got these results:=20
https://wandbox.org/permlink/URss8Zya4RnFHblR
I certainly wouldn't want to require that every iterator use its=20
container's fancy pointer type; and in fact my paper will *almost* propose=
=20
the opposite: that because vendors today in practice don't make iterators=
=20
what-I-call-"storage-aware" (essentially "safe for use with=20
boost::interprocess::offset_ptr"), the standard *might* want to consider=20
formally delineating which entities must be "storage-aware" and which not.=
=20
(My paper's working title is "Towards meaningful fancy pointers." If you're=
=20
specifically interested in this kind of thing, shoot me an email.)
As for converting iterators to pointers, I strongly believe that=20
"static_cast" is the one correct way to spell *natural* conversions, and=20
vice versa, "static_cast" is the wrong way to spell any conversion that is=
=20
*not* natural. Right now it seems plausible to me that the conversion from=
=20
"contiguous iterator" to "raw pointer" ought to be considered a natural=20
conversion; and that the reverse conversion, from raw pointer to iterator,=
=20
ought *not* to be considered natural (, because, debug iterators).
=E2=80=93Arthur
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5d8909f3-86b8-4aa2-9375-94a140788d9b%40isocpp.or=
g.
------=_Part_5747_93049265.1503347558431
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, August 19, 2017 at 3:23:04 AM UTC-7, ejsvifq =
mabmip wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><br></div><div>using pointer =3D=C2=A0<span><span><font face=3D"Consol=
as"><a href=3D"http://en.cppreference.com/w/cpp/memory/allocator_traits" ta=
rget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fmemory%2F=
allocator_traits\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEyEf12QDK6cDYWCvXX=
uS2SkZ74Ew';return true;" onclick=3D"this.href=3D'http://www.google=
..com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fmemory%2Fallocat=
or_traits\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEyEf12QDK6cDYWCvXXuS2SkZ7=
4Ew';return true;"><span><u><font color=3D"#0066cc">std::<span>allocato=
r_traits</span></font></u></span></a><span><font color=3D"#000080"><</fo=
nt></span>Alloca<wbr>tor<span><font color=3D"#000080">></font></span><sp=
an><font color=3D"#008080">::</font></span><span>pointer;</span></font></sp=
an></span></div><div><span><span><font face=3D"Consolas"><span>using iterat=
or =3D pointer;</span></font></span></span></div></div></blockquote><div><b=
r></div><div>Semi-tangential: I'll have a paper in Albuquerque on the s=
ubject of fancy pointers and their proper uses; and this is <i><b>not</b></=
i> one of them IMO.</div><div>Different vendors, and different containers w=
ithin the same vendor, differ as to their use of fancy-pointers-in-iterator=
s. For example,=C2=A0</div><div><br></div><div>libc++:</div><div>- Using fa=
ncy pointers: deque (both levels), forward_list, list, map, set, unordered_=
map, unordered_set, vector</div><div>- Using raw pointers: none</div><div><=
br></div><div>libstdc++:</div><div>- Using fancy pointers: deque (both leve=
ls), vector</div><div>- Using raw pointers: forward_list, list, map, set, u=
nordered_map, unordered_set</div><div><br></div><div>MSVC:</div><div>- Usin=
g fancy pointers: forward_list, list, map, set, unordered_map, unordered_se=
t, vector</div><div>- Using raw pointers: deque (both levels)</div><div><br=
></div><div><div>The test harness that got these results: <a href=3D"https:=
//wandbox.org/permlink/URss8Zya4RnFHblR">https://wandbox.org/permlink/URss8=
Zya4RnFHblR</a></div></div><div><br></div><div>I certainly wouldn't wan=
t to require that every iterator use its container's fancy pointer type=
; and in fact my paper will <i>almost</i> propose the opposite: that becaus=
e vendors today in practice don't make iterators what-I-call-"stor=
age-aware" (essentially "safe for use with boost::interprocess::o=
ffset_ptr"), the standard <i>might</i> want to consider formally delin=
eating which entities must be "storage-aware" and which not. (My =
paper's working title is "Towards meaningful fancy pointers."=
If you're specifically interested in this kind of thing, shoot me an e=
mail.)</div><div><br></div><div>As for converting iterators to pointers, I =
strongly believe that "static_cast" is the one correct way to spe=
ll <i>natural</i> conversions, and vice versa, "static_cast" is t=
he wrong way to spell any conversion that is <i>not</i> natural. Right now =
it seems plausible to me that the conversion from "contiguous iterator=
" to "raw pointer" ought to be considered a natural conversi=
on; and that the reverse conversion, from raw pointer to iterator, ought <i=
>not</i> to be considered natural (, because, debug iterators).</div><div><=
br></div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5d8909f3-86b8-4aa2-9375-94a140788d9b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5d8909f3-86b8-4aa2-9375-94a140788d9b=
%40isocpp.org</a>.<br />
------=_Part_5747_93049265.1503347558431--
------=_Part_5746_1846284244.1503347558430--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 21 Aug 2017 16:03:22 -0500
Raw View
--94eb2c1197ba897b12055749d109
Content-Type: text/plain; charset="UTF-8"
On Mon, Aug 21, 2017 at 3:32 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
> As for converting iterators to pointers, I strongly believe that
> "static_cast" is the one correct way to spell *natural* conversions, and
> vice versa, "static_cast" is the wrong way to spell any conversion that is
> *not* natural. Right now it seems plausible to me that the conversion
> from "contiguous iterator" to "raw pointer" ought to be considered a
> natural conversion;
>
Here is the counter argument: https://groups.google.com/a/isocpp.org/d/msg/
std-proposals/85pdJ2rZ_Ss/qxCB6uFmVE0J
While I wrote the paper, I wasn't the one presenting n3384
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3884.pdf> in
Issaquah in 2014, so I don't know if anyone asked that question to LEWG (I
believe I was mistaken when I said LEWG rejected it earlier).
At this point, I don't plan on proposing static_cast in the second revision
to that paper, but feel free to bring it up in LEWG or in a paper
addressing my still being written revision of n4183
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4183.pdf>.
Personally, I am for this working but not strongly enough to actually
propose it.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
<(847)%20691-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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOEhov2Vdzipe%2B2Md64%3DbCxnm3SwdWGCiukUS92V%2BmcYw%40mail.gmail.com.
--94eb2c1197ba897b12055749d109
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Aug 21, 2017 at 3:32 PM, Arthur O'Dwyer <span =
dir=3D"ltr"><<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_bla=
nk">arthur.j.odwyer@gmail.com</a>></span> wrote:<br><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=
As for converting iterators to pointers, I strongly believe that "stat=
ic_cast" is the one correct way to spell <i>natural</i> conversions, a=
nd vice versa, "static_cast" is the wrong way to spell any conver=
sion that is <i>not</i> natural. Right now it seems plausible to me that th=
e conversion from "contiguous iterator" to "raw pointer"=
; ought to be considered a natural conversion; </div></div></blockquote><di=
v><br></div><div>Here is the counter argument:=C2=A0<a href=3D"https://grou=
ps.google.com/a/isocpp.org/d/msg/std-proposals/85pdJ2rZ_Ss/qxCB6uFmVE0J" ta=
rget=3D"_blank">https://groups.<wbr>google.com/a/isocpp.org/d/msg/<wbr>std-=
proposals/85pdJ2rZ_Ss/<wbr>qxCB6uFmVE0J</a></div><div><br></div><div>While =
I wrote the paper, I wasn't the one presenting <a href=3D"http://www.op=
en-std.org/jtc1/sc22/wg21/docs/papers/2014/n3884.pdf" target=3D"_blank">n33=
84</a> in Issaquah in 2014, so I don't know if anyone asked that questi=
on to LEWG (I believe I was mistaken when I said LEWG rejected it earlier).=
</div><div><br></div><div>At this point, I don't plan on proposing stat=
ic_cast in the second revision to that paper, but feel free to bring it up =
in LEWG or in a paper addressing my still being written revision of <a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4183.pdf" targ=
et=3D"_blank">n4183</a>.=C2=A0 Personally, I am for this working but not st=
rongly enough to actually propose it.</div></div>-- <br><div class=3D"m_-43=
11595229096652140gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><d=
iv>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nev=
in@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a><wbr>> =
=C2=A0<a href=3D"tel:(847)%20691-1404" value=3D"+18476911404" target=3D"_bl=
ank">+1-847-691-1404</a></div></div></div></div></div>
</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOEhov2Vdzipe%2B2Md64%3DbCxnm=
3SwdWGCiukUS92V%2BmcYw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
OEhov2Vdzipe%2B2Md64%3DbCxnm3SwdWGCiukUS92V%2BmcYw%40mail.gmail.com</a>.<br=
/>
--94eb2c1197ba897b12055749d109--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Mon, 21 Aug 2017 23:17:50 -0700 (PDT)
Raw View
------=_Part_7904_656619574.1503382670889
Content-Type: multipart/alternative;
boundary="----=_Part_7905_315710192.1503382670889"
------=_Part_7905_315710192.1503382670889
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2017=E5=B9=B48=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8B=E5=8D=8811:04:33=EF=BC=8Cejsvifq mabmip=E5=86=99=E9=81=93=EF=BC=
=9A
>
> Contiguous iterator fails to accomplish anything. It is a horrible idea=
=20
> from the beginning. Just like .data(). Some containers uses "proxy=20
> pointers" and it cant even be converted to pointers. Is it a contiguous=
=20
> container??
>
> Wrong. Pointer is horrible at first, even despite of the ambiguity of the=
=20
term itself (defined by an ISA or in a high-level language). Any refinement=
=20
based on that umbrella concept seems relatively plausible, if not=20
identical, just because it avoid the ambiguity of intent to introduce the=
=20
type. It may also reduce possibilities of wrong use due to static=20
typechecking.
Say, what about oberserver_ptr<T>?
The meaning of a contiguous iterator explicitly relies on an underlying=20
sequence by the nature of an iterator, while the meaning of a pointer=20
relies on the nasty details of implementation (e.g. an address space) which=
=20
is not expressible well in the current language. The former reflects the=20
intent far better than the latter in almost any cases, as long as=20
implementable.
If concepts like contiguous iterators are just for converting to a raw=20
> pointer, I don't think it should be implemented at the first place.
>
> In aspect of a general-purposed high-level language, pointers (as in=20
C/C++) should better not be introduced to the language at first. Need of=20
interoperation between language implementations, need of handling owned=20
resources and need of referencing elements in/out of a sequence are all=20
quite different, but neither is served well by pointers. It only coupled in=
=20
specific implementations. Support of built-in pointers (whether hijacked by=
=20
ISA spec or not) is the technical debt on immature language design for=20
historical reasons, not the real needs of the users of the language.=20
Fortunately, C++ has ability to fill the leaked abstraction hole (more or=
=20
less), by using portable integer types, smart pointers, and, contiguous=20
iterators instead of raw pointers in user code. Not all of them have=20
covered the real needs (e.g. being portable enough), but the direction of=
=20
evolution should be clear.
On Monday, August 21, 2017 at 10:32:11 PM UTC+8, Manuel Bergler wrote:
>
>> On Mon, Aug 21, 2017 at 4:17 PM, <eulo...@live.com> wrote:
>>
>>> Contiguous iterators might also be initialized by pointers. That would=
=20
>>> be easier to convert to contiguous iterators from pointers.
>>>
>>
>> Yes, but as was pointed out by other people already, there is no chance=
=20
>> to get the Standard revised to mandate iterators of contiguous container=
s=20
>> to be pointers.
>>
>> When you instead write a custom trait for contiguous iterators, you can=
=20
>> also immedately specialize it for pointers in addition to the std=20
>> containers so that pointers also work with such a function template. The=
=20
>> only "drawback" you have is that you have to write the trait, but we can=
=20
>> discuss the merits of such a trait and maybe extend the iterator categor=
ies=20
>> to include it. Then at least in the future no one has to write it=20
>> themselves.=20
>> =20
>>
>>>
>>> On Monday, August 21, 2017 at 10:14:43 PM UTC+8, Manuel Bergler wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Aug 21, 2017 at 4:10 PM, <eulo...@live.com> wrote:
>>>>
>>>>> Horrible. Random Access Iterators are not Contiguous Iterators. If=20
>>>>> somebody passes deque iterators into it, UB. Pointers can guaranteed =
to be=20
>>>>> contiguous iterators.
>>>>>
>>>>>
>>>> That's why I wrote one should add a custom trait for contiguous=20
>>>> iterators... The point was to show that you can easily get the pointe=
rs to=20
>>>> the elements pointed to by the iterator, not to write a complete=20
>>>> implementation. Right now the template is unconstrained, so you could =
even=20
>>>> pass std::list iterators even though they don't satify the=20
>>>> RandomAccessIterator concept.
>>>>
>>>>
>>>>> On Monday, August 21, 2017 at 6:07:25 AM UTC+8, Manuel Bergler wrote:
>>>>>
>>>>>>
>>>>>> On Sun, Aug 20, 2017 at 8:43 PM, Thiago Macieira <thi...@macieira.or=
g
>>>>>> > wrote:
>>>>>>
>>>>>>> On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dominiak wrote:
>>>>>>> > On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <thi...@macieira.or=
g>=20
>>>>>>> wrote:
>>>>>>> > > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:
>>>>>>> > > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <
>>>>>>> berg...@gmail.com>
>>>>>>> > >
>>>>>>> > > wrote:
>>>>>>> > > > > I don't understand what exactly doesn't work. What's wrong=
=20
>>>>>>> with
>>>>>>> > >
>>>>>>> > > converting
>>>>>>> > >
>>>>>>> > > > > the iterators to pointers by using std::addressof(*iterator=
)?
>>>>>>> > > >
>>>>>>> > > > Dereferencing *end() is undefined behavior.
>>>>>>> > >
>>>>>>> > > std::addressof(end()[-1]) + 1
>>>>>>> >
>>>>>>> > That's UB when begin() =3D=3D end(), no?
>>>>>>>
>>>>>>> Yes, but you can't dereference the begin pointer that way either=20
>>>>>>> when the list
>>>>>>> is empty.
>>>>>>>
>>>>>>>
>>>>>> You don't need to dereference begin() when the range is empty and yo=
u=20
>>>>>> also don't need to dereference end(). For a typical example of a C A=
PI that=20
>>>>>> takes a pointer and a size, a C++ wrapper using iterators can easily=
be=20
>>>>>> implemented as
>>>>>>
>>>>>> void c_style_function(void* start, size_t size);
>>>>>>
>>>>>> template <typename RandomAccessIterator>
>>>>>> void cpp_wrapper(RandomAccessIterator begin,=20
>>>>>> RandomAccessIterator end) {
>>>>>> auto const size =3D std::distance(begin, end);
>>>>>>
>>>>>> if (size !=3D 0) {
>>>>>> auto begin_ptr =3D std::addressof(*begin);
>>>>>>
>>>>>> c_style_function(begin_ptr, size);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> If one additionally creates a trait for contiguous iterators, the=20
>>>>>> template can also be restricted accordingly. And for C APIs that exp=
ect an=20
>>>>>> end pointer instead of a size argument you can also compute the end =
pointer=20
>>>>>> from begin_ptr and size. As far as I can tell this doesn't cause UB =
and=20
>>>>>> does exactly what the OP would like to achieve, without needing the=
=20
>>>>>> iterators to be pointers.
>>>>>>
>>>>> --=20
>>>>> You received this message because you are subscribed to the Google=20
>>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, sen=
d=20
>>>>> an email to std-proposal...@isocpp.org.
>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>> To view this discussion on the web visit=20
>>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b=
-907d-4f86-aa20-493c99915621%40isocpp.org=20
>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9=
b-907d-4f86-aa20-493c99915621%40isocpp.org?utm_medium=3Demail&utm_source=3D=
footer>
>>>>> .
>>>>>
>>>>
>>>> --=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit=20
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9be523a7-e=
c66-4e3f-a8f5-3c00ff49a588%40isocpp.org=20
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9be523a7-=
ec66-4e3f-a8f5-3c00ff49a588%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>
>>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/577d0114-eb8a-44b6-9db7-95fba86e6e94%40isocpp.or=
g.
------=_Part_7905_315710192.1503382670889
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B48=E6=9C=8821=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=8811:04:33=EF=BC=8Cejsvifq mabmi=
p=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div>Contiguous iterator fails to accomplish anything. It is=
a horrible idea from the beginning. Just like .data(). Some containers use=
s "proxy pointers" and it cant even be converted to pointers. Is =
it a contiguous container??</div><div><br></div></div></blockquote><div>Wro=
ng. Pointer is horrible at first, even despite of the ambiguity of the term=
itself (defined by an ISA or in a high-level language). Any refinement bas=
ed on that umbrella concept seems relatively plausible, if not identical, j=
ust because it avoid the ambiguity of intent to introduce the type. It may =
also reduce possibilities of wrong use due to static typechecking.<br></div=
><div><br></div><div>Say, what about oberserver_ptr<T>?</div><div><br=
></div><div>The meaning of a contiguous iterator explicitly relies on an un=
derlying sequence by the nature of an iterator, while the meaning of a poin=
ter relies on the nasty details of implementation (e.g. an address space) w=
hich is not expressible well in the current language. The former reflects t=
he intent far better than the latter in almost any cases, as long as implem=
entable.<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div></div><div>If concepts like contiguous iterators a=
re just for converting to a raw pointer, I don't think it should be imp=
lemented at the first place.<br><br></div></div></blockquote><div>In aspect=
of a general-purposed high-level language, pointers (as in C/C++) should b=
etter not be introduced to the language at first. Need of interoperation be=
tween language implementations, need of handling owned resources and need o=
f referencing elements in/out of a sequence are all quite different, but ne=
ither is served well by pointers. It only coupled in specific implementatio=
ns. Support of built-in pointers (whether hijacked by ISA spec or not) is t=
he technical debt on immature language design for historical reasons, not t=
he real needs of the users of the language. Fortunately, C++ has ability to=
fill the leaked abstraction hole (more or less), by using portable integer=
types, smart pointers, and, contiguous iterators instead of raw pointers i=
n user code. Not all of them have covered the real needs (e.g. being portab=
le enough), but the direction of evolution should be clear.<br></div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
>On Monday, August 21, 2017 at 10:32:11 PM UTC+8, Manuel Bergler wrote:</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Mon, Aug 21, 2017 at 4:17 PM, <span dir=3D"ltr"><<a=
rel=3D"nofollow">eulo...@live.com</a>></span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">Contiguous iterators might also be initial=
ized by pointers. That would be easier to convert to contiguous iterators f=
rom pointers.<br></div></blockquote><div><br></div><div>Yes, but as was poi=
nted out by other people already, there is no chance to get the Standard re=
vised to mandate iterators of contiguous containers to be pointers.</div><d=
iv><br></div><div>When you instead write a custom trait for contiguous iter=
ators, you can also immedately specialize it for pointers in addition to th=
e std containers so that pointers also work with such a function template. =
The only "drawback" you have is that you have to write the trait,=
but we can discuss the merits of such a trait and maybe extend the iterato=
r categories to include it. Then at least in the future no one has to write=
it themselves. <br></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"><br>On Monday, August 21, 2017 at 10:14:43 PM UTC+8, Manuel=
Bergler wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br=
><div><br><div class=3D"gmail_quote"><div><div>On Mon, Aug 21, 2017 at 4:10=
PM, <span dir=3D"ltr"><<a rel=3D"nofollow">eulo...@live.com</a>></s=
pan> wrote:<br><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>Horribl=
e. Random Access Iterators are not Contiguous Iterators. If somebody passes=
deque iterators into it, UB. Pointers can guaranteed to be contiguous iter=
ators.</div><div><br></div></div></blockquote><div><br></div><div>That'=
s why I wrote one should add a custom trait for contiguous iterators...=C2=
=A0 The point was to show that you can easily get the pointers to the eleme=
nts pointed to by the iterator, not to write a complete implementation. Rig=
ht now the template is unconstrained, so you could even pass std::list iter=
ators even though they don't satify the RandomAccessIterator concept.</=
div><div> <br></div></div></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><d=
iv dir=3D"ltr"><div></div><div><br>On Monday, August 21, 2017 at 6:07:25 AM=
UTC+8, Manuel Bergler wrote:</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><br><div class=3D"gmail_quote"><span>On Sun, Aug 20,=
2017 at 8:43 PM, Thiago Macieira <span dir=3D"ltr"><<a rel=3D"nofollow"=
>thi...@macieira.org</a>></span> wrote:<br></span><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><span><span>On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dom=
iniak wrote:<br></span><span>
> On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <<a rel=3D"nofollow">=
thi...@macieira.org</a>> wrote:<br>
> > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:<br></sp=
an>
> > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <<a rel=
=3D"nofollow">berg...@gmail.com</a>><span><br>
> ><br>
> > wrote:<br>
> > > > I don't understand what exactly doesn't work. W=
hat's wrong with<br>
> ><br>
> > converting<br>
> ><br>
> > > > the iterators to pointers by using std::addressof(*iter=
ator)?<br>
> > ><br>
> > > Dereferencing *end() is undefined behavior.<br>
> ><br>
> > std::addressof(end()[-1]) + 1<br>
><br>
> That's UB when begin() =3D=3D end(), no?<br>
<br>
</span></span><span>Yes, but you can't dereference the begin pointer th=
at way either when the list<br>
is empty.<br>
<span><br></span></span></blockquote><span><div><br></div><div>You don'=
t need to dereference begin() when the range is empty and you also don'=
t need to dereference end(). For a typical example of a C API that takes a =
pointer and a size, a C++ wrapper using iterators can easily be implemented=
as</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0void c_style_function(void=
* start, size_t size);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0templat=
e <typename RandomAccessIterator></div><div>=C2=A0 =C2=A0 =C2=A0void =
cpp_wrapper(<wbr>RandomAccessIterator begin, RandomAccessIterator end) {</d=
iv><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto const size =3D std::distanc=
e(begin, end);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
if (size !=3D 0) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 auto begin_ptr =3D std::addressof(*begin);</div><div><br></div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 c_style_function(begin_ptr, s=
ize);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0=
=C2=A0}</div><div><br></div><div>If one additionally creates a trait for c=
ontiguous iterators, the template can also be restricted accordingly. And f=
or C APIs that expect an end pointer instead of a size argument you can als=
o compute the end pointer from begin_ptr and size. As far as I can tell thi=
s doesn't cause UB and does exactly what the OP would like to achieve, =
without needing the iterators to be pointers.</div></span></div></div></div=
>
</blockquote></div>
<p></p>
-- <br></div></div><span><div><div>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span><span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/5d5b4b9b-907d-4f86-<wbr>aa20-=
493c99915621%40isocpp.org</a><wbr>.<br>
</span></blockquote></div><br></div></div>
</blockquote></div><span>
<p></p>
-- <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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9be523a7-ec66-4e3f-a8f5-3c00ff49a588%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/9be523a7-ec66-4e3f-a8f5-3c00ff49a588%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/9be523a7-ec66-4e3f-a8f5-3c00ff49a588%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/9be523a7-ec66-4e3f-<wbr>a8f5-=
3c00ff49a588%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>
</blockquote></div></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/577d0114-eb8a-44b6-9db7-95fba86e6e94%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/577d0114-eb8a-44b6-9db7-95fba86e6e94=
%40isocpp.org</a>.<br />
------=_Part_7905_315710192.1503382670889--
------=_Part_7904_656619574.1503382670889--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Mon, 21 Aug 2017 23:37:45 -0700 (PDT)
Raw View
------=_Part_8066_2106181078.1503383865405
Content-Type: multipart/alternative;
boundary="----=_Part_8067_367841531.1503383865405"
------=_Part_8067_367841531.1503383865405
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2017=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8A=E5=8D=884:32:38=EF=BC=8CArthur O'Dwyer=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On Saturday, August 19, 2017 at 3:23:04 AM UTC-7, ejsvifq mabmip wrote:
>>
>>
>> using pointer =3D *std::allocator_traits*=20
>> <http://en.cppreference.com/w/cpp/memory/allocator_traits><Allocator>::
>> pointer;
>> using iterator =3D pointer;
>>
>
> Semi-tangential: I'll have a paper in Albuquerque on the subject of fancy=
=20
> pointers and their proper uses; and this is *not* one of them IMO.
> Different vendors, and different containers within the same vendor, diffe=
r=20
> as to their use of fancy-pointers-in-iterators. For example,=20
>
> libc++:
> - Using fancy pointers: deque (both levels), forward_list, list, map, set=
,=20
> unordered_map, unordered_set, vector
> - Using raw pointers: none
>
> libstdc++:
> - Using fancy pointers: deque (both levels), vector
> - Using raw pointers: forward_list, list, map, set, unordered_map,=20
> unordered_set
>
> MSVC:
> - Using fancy pointers: forward_list, list, map, set, unordered_map,=20
> unordered_set, vector
> - Using raw pointers: deque (both levels)
>
> Are they depend on version of implementations or build configurations?=20
IIRC at least MSVC does not agree with standard library ABI between major=
=20
releases and vector::iterator is pointer only in some build configurations.
The test harness that got these results:=20
> https://wandbox.org/permlink/URss8Zya4RnFHblR
>
> I certainly wouldn't want to require that every iterator use its=20
> container's fancy pointer type; and in fact my paper will *almost*=20
> propose the opposite: that because vendors today in practice don't make=
=20
> iterators what-I-call-"storage-aware" (essentially "safe for use with=20
> boost::interprocess::offset_ptr"), the standard *might* want to consider=
=20
> formally delineating which entities must be "storage-aware" and which not=
..=20
> (My paper's working title is "Towards meaningful fancy pointers." If you'=
re=20
> specifically interested in this kind of thing, shoot me an email.)
>
> As for converting iterators to pointers, I strongly believe that=20
> "static_cast" is the one correct way to spell *natural* conversions, and=
=20
> vice versa, "static_cast" is the wrong way to spell any conversion that i=
s=20
> *not* natural. Right now it seems plausible to me that the conversion=20
> from "contiguous iterator" to "raw pointer" ought to be considered a=20
> natural conversion; and that the reverse conversion, from raw pointer to=
=20
> iterator, ought *not* to be considered natural (, because, debug=20
> iterators).
>
> =E2=80=93Arthur
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e478111a-4304-443a-93b3-fa2435c0e9c5%40isocpp.or=
g.
------=_Part_8067_367841531.1503383865405
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=884:32:38=EF=BC=8CArthur O'D=
wyer=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr">On Saturday, August 19, 2017 at 3:23:04 AM UTC-7, ejsvifq=
mabmip wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
><br></div><div>using pointer =3D=C2=A0<span><span><font face=3D"Consolas">=
<a href=3D"http://en.cppreference.com/w/cpp/memory/allocator_traits" rel=3D=
"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fmemory%2Fallo=
cator_traits\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEyEf12QDK6cDYWCvXXuS2S=
kZ74Ew';return true;" onclick=3D"this.href=3D'http://www.google.com=
/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fmemory%2Fallocator_t=
raits\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEyEf12QDK6cDYWCvXXuS2SkZ74Ew&=
#39;;return true;"><span><u><font color=3D"#0066cc">std::<span>allocator_tr=
aits</span></font></u></span></a><span><font color=3D"#000080"><</font><=
/span>Alloca<wbr>tor<span><font color=3D"#000080">></font></span><span><=
font color=3D"#008080">::</font></span><span>pointer;</span></font></span><=
/span></div><div><span><span><font face=3D"Consolas"><span>using iterator =
=3D pointer;</span></font></span></span></div></div></blockquote><div><br><=
/div><div>Semi-tangential: I'll have a paper in Albuquerque on the subj=
ect of fancy pointers and their proper uses; and this is <i><b>not</b></i> =
one of them IMO.</div><div>Different vendors, and different containers with=
in the same vendor, differ as to their use of fancy-pointers-in-iterators. =
For example,=C2=A0</div><div><br></div><div>libc++:</div><div>- Using fancy=
pointers: deque (both levels), forward_list, list, map, set, unordered_map=
, unordered_set, vector</div><div>- Using raw pointers: none</div><div><br>=
</div><div>libstdc++:</div><div>- Using fancy pointers: deque (both levels)=
, vector</div><div>- Using raw pointers: forward_list, list, map, set, unor=
dered_map, unordered_set</div><div><br></div><div>MSVC:</div><div>- Using f=
ancy pointers: forward_list, list, map, set, unordered_map, unordered_set, =
vector</div><div>- Using raw pointers: deque (both levels)</div><div><br></=
div></div></blockquote><div>Are they depend on version of implementations o=
r build configurations? IIRC at least MSVC does not agree with standard lib=
rary ABI between major releases and vector::iterator is pointer only in som=
e build configurations.<br></div><div> <br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div></div><div><div>The test harness t=
hat got these results: <a href=3D"https://wandbox.org/permlink/URss8Zya4RnF=
HblR" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'ht=
tps://www.google.com/url?q\x3dhttps%3A%2F%2Fwandbox.org%2Fpermlink%2FURss8Z=
ya4RnFHblR\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFYK0mws776KgYMtbir5m4mAo=
puHg';return true;" onclick=3D"this.href=3D'https://www.google.com/=
url?q\x3dhttps%3A%2F%2Fwandbox.org%2Fpermlink%2FURss8Zya4RnFHblR\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNFYK0mws776KgYMtbir5m4mAopuHg';return true=
;">https://wandbox.org/permlink/<wbr>URss8Zya4RnFHblR</a></div></div><div><=
br></div><div>I certainly wouldn't want to require that every iterator =
use its container's fancy pointer type; and in fact my paper will <i>al=
most</i> propose the opposite: that because vendors today in practice don&#=
39;t make iterators what-I-call-"storage-aware" (essentially &quo=
t;safe for use with boost::interprocess::offset_<wbr>ptr"), the standa=
rd <i>might</i> want to consider formally delineating which entities must b=
e "storage-aware" and which not. (My paper's working title is=
"Towards meaningful fancy pointers." If you're specifically =
interested in this kind of thing, shoot me an email.)</div><div><br></div><=
div>As for converting iterators to pointers, I strongly believe that "=
static_cast" is the one correct way to spell <i>natural</i> conversion=
s, and vice versa, "static_cast" is the wrong way to spell any co=
nversion that is <i>not</i> natural. Right now it seems plausible to me tha=
t the conversion from "contiguous iterator" to "raw pointer&=
quot; ought to be considered a natural conversion; and that the reverse con=
version, from raw pointer to iterator, ought <i>not</i> to be considered na=
tural (, because, debug iterators).</div><div><br></div><div>=E2=80=93Arthu=
r</div></div></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e478111a-4304-443a-93b3-fa2435c0e9c5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e478111a-4304-443a-93b3-fa2435c0e9c5=
%40isocpp.org</a>.<br />
------=_Part_8067_367841531.1503383865405--
------=_Part_8066_2106181078.1503383865405--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 22 Aug 2017 00:03:10 -0700 (PDT)
Raw View
------=_Part_3250_231223087.1503385390951
Content-Type: multipart/alternative;
boundary="----=_Part_3251_1938153558.1503385390952"
------=_Part_3251_1938153558.1503385390952
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2017=E5=B9=B48=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8B=E5=8D=8811:04:33=EF=BC=8Cejsvifq mabmip=E5=86=99=E9=81=93=EF=BC=
=9A
>
> Contiguous iterator fails to accomplish anything. It is a horrible idea=
=20
> from the beginning. Just like .data(). Some containers uses "proxy=20
> pointers" and it cant even be converted to pointers. Is it a contiguous=
=20
> container??
>
> One more point that you have ignored: a contiguous iterator does not impl=
y=20
there is a special standalone sentinel value available of that type, while=
=20
the null pointer value (which can be value-initialized without referring=20
any sequence) is always in the well-defined range of a pointer. (Note the=
=20
rules of null pointer value is largely orthogonal with iterator=20
requirements, and they are also effective on non-object pointer types and=
=20
pointer-to-member types.) So the use of a contiguous makes users free to=20
ignore null value handling (if any).
There can be more... e.g. the ability of being aliased in a well-defined=20
manner, but this is related with other core rules, not only pointers.
If concepts like contiguous iterators are just for converting to a raw=20
> pointer, I don't think it should be implemented at the first place.
>
> On Monday, August 21, 2017 at 10:32:11 PM UTC+8, Manuel Bergler wrote:
>
>> On Mon, Aug 21, 2017 at 4:17 PM, <eulo...@live.com> wrote:
>>
>>> Contiguous iterators might also be initialized by pointers. That would=
=20
>>> be easier to convert to contiguous iterators from pointers.
>>>
>>
>> Yes, but as was pointed out by other people already, there is no chance=
=20
>> to get the Standard revised to mandate iterators of contiguous container=
s=20
>> to be pointers.
>>
>> When you instead write a custom trait for contiguous iterators, you can=
=20
>> also immedately specialize it for pointers in addition to the std=20
>> containers so that pointers also work with such a function template. The=
=20
>> only "drawback" you have is that you have to write the trait, but we can=
=20
>> discuss the merits of such a trait and maybe extend the iterator categor=
ies=20
>> to include it. Then at least in the future no one has to write it=20
>> themselves.=20
>> =20
>>
>>>
>>> On Monday, August 21, 2017 at 10:14:43 PM UTC+8, Manuel Bergler wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Aug 21, 2017 at 4:10 PM, <eulo...@live.com> wrote:
>>>>
>>>>> Horrible. Random Access Iterators are not Contiguous Iterators. If=20
>>>>> somebody passes deque iterators into it, UB. Pointers can guaranteed =
to be=20
>>>>> contiguous iterators.
>>>>>
>>>>>
>>>> That's why I wrote one should add a custom trait for contiguous=20
>>>> iterators... The point was to show that you can easily get the pointe=
rs to=20
>>>> the elements pointed to by the iterator, not to write a complete=20
>>>> implementation. Right now the template is unconstrained, so you could =
even=20
>>>> pass std::list iterators even though they don't satify the=20
>>>> RandomAccessIterator concept.
>>>>
>>>>
>>>>> On Monday, August 21, 2017 at 6:07:25 AM UTC+8, Manuel Bergler wrote:
>>>>>
>>>>>>
>>>>>> On Sun, Aug 20, 2017 at 8:43 PM, Thiago Macieira <thi...@macieira.or=
g
>>>>>> > wrote:
>>>>>>
>>>>>>> On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dominiak wrote:
>>>>>>> > On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <thi...@macieira.or=
g>=20
>>>>>>> wrote:
>>>>>>> > > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:
>>>>>>> > > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <
>>>>>>> berg...@gmail.com>
>>>>>>> > >
>>>>>>> > > wrote:
>>>>>>> > > > > I don't understand what exactly doesn't work. What's wrong=
=20
>>>>>>> with
>>>>>>> > >
>>>>>>> > > converting
>>>>>>> > >
>>>>>>> > > > > the iterators to pointers by using std::addressof(*iterator=
)?
>>>>>>> > > >
>>>>>>> > > > Dereferencing *end() is undefined behavior.
>>>>>>> > >
>>>>>>> > > std::addressof(end()[-1]) + 1
>>>>>>> >
>>>>>>> > That's UB when begin() =3D=3D end(), no?
>>>>>>>
>>>>>>> Yes, but you can't dereference the begin pointer that way either=20
>>>>>>> when the list
>>>>>>> is empty.
>>>>>>>
>>>>>>>
>>>>>> You don't need to dereference begin() when the range is empty and yo=
u=20
>>>>>> also don't need to dereference end(). For a typical example of a C A=
PI that=20
>>>>>> takes a pointer and a size, a C++ wrapper using iterators can easily=
be=20
>>>>>> implemented as
>>>>>>
>>>>>> void c_style_function(void* start, size_t size);
>>>>>>
>>>>>> template <typename RandomAccessIterator>
>>>>>> void cpp_wrapper(RandomAccessIterator begin,=20
>>>>>> RandomAccessIterator end) {
>>>>>> auto const size =3D std::distance(begin, end);
>>>>>>
>>>>>> if (size !=3D 0) {
>>>>>> auto begin_ptr =3D std::addressof(*begin);
>>>>>>
>>>>>> c_style_function(begin_ptr, size);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> If one additionally creates a trait for contiguous iterators, the=20
>>>>>> template can also be restricted accordingly. And for C APIs that exp=
ect an=20
>>>>>> end pointer instead of a size argument you can also compute the end =
pointer=20
>>>>>> from begin_ptr and size. As far as I can tell this doesn't cause UB =
and=20
>>>>>> does exactly what the OP would like to achieve, without needing the=
=20
>>>>>> iterators to be pointers.
>>>>>>
>>>>> --=20
>>>>> You received this message because you are subscribed to the Google=20
>>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, sen=
d=20
>>>>> an email to std-proposal...@isocpp.org.
>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>> To view this discussion on the web visit=20
>>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b=
-907d-4f86-aa20-493c99915621%40isocpp.org=20
>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9=
b-907d-4f86-aa20-493c99915621%40isocpp.org?utm_medium=3Demail&utm_source=3D=
footer>
>>>>> .
>>>>>
>>>>
>>>> --=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit=20
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9be523a7-e=
c66-4e3f-a8f5-3c00ff49a588%40isocpp.org=20
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9be523a7-=
ec66-4e3f-a8f5-3c00ff49a588%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>
>>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2cfc3f07-1a93-4b5f-a30d-c3c9a1b39c9a%40isocpp.or=
g.
------=_Part_3251_1938153558.1503385390952
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B48=E6=9C=8821=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=8811:04:33=EF=BC=8Cejsvifq mabmi=
p=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div>Contiguous iterator fails to accomplish anything. It is=
a horrible idea from the beginning. Just like .data(). Some containers use=
s "proxy pointers" and it cant even be converted to pointers. Is =
it a contiguous container??</div><div><br></div></div></blockquote><div>One=
more point that you have ignored: a contiguous iterator does not imply the=
re is a special standalone sentinel value available of that type, while the=
null pointer value (which can be value-initialized without referring any s=
equence) is always in the well-defined range of a pointer. (Note the rules =
of null pointer value is largely orthogonal with iterator requirements, and=
they are also effective on non-object pointer types and pointer-to-member =
types.) So the use of a contiguous makes users free to ignore null value ha=
ndling (if any).<br></div><div><br></div><div>There can be more... e.g. the=
ability of being aliased in a well-defined manner, but this is related wit=
h other core rules, not only pointers.<br></div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>If concep=
ts like contiguous iterators are just for converting to a raw pointer, I do=
n't think it should be implemented at the first place.<br><br>On Monday=
, August 21, 2017 at 10:32:11 PM UTC+8, Manuel Bergler wrote:</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_q=
uote">On Mon, Aug 21, 2017 at 4:17 PM, <span dir=3D"ltr"><<a rel=3D"nof=
ollow">eulo...@live.com</a>></span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">Contiguous iterators might also be initialized by poi=
nters. That would be easier to convert to contiguous iterators from pointer=
s.<br></div></blockquote><div><br></div><div>Yes, but as was pointed out by=
other people already, there is no chance to get the Standard revised to ma=
ndate iterators of contiguous containers to be pointers.</div><div><br></di=
v><div>When you instead write a custom trait for contiguous iterators, you =
can also immedately specialize it for pointers in addition to the std conta=
iners so that pointers also work with such a function template. The only &q=
uot;drawback" you have is that you have to write the trait, but we can=
discuss the merits of such a trait and maybe extend the iterator categorie=
s to include it. Then at least in the future no one has to write it themsel=
ves. <br></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"><br>On Monday, August 21, 2017 at 10:14:43 PM UTC+8, Manuel Bergler wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><br><=
div class=3D"gmail_quote"><div><div>On Mon, Aug 21, 2017 at 4:10 PM, <span=
dir=3D"ltr"><<a rel=3D"nofollow">eulo...@live.com</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Horrible. Random A=
ccess Iterators are not Contiguous Iterators. If somebody passes deque iter=
ators into it, UB. Pointers can guaranteed to be contiguous iterators.</div=
><div><br></div></div></blockquote><div><br></div><div>That's why I wro=
te one should add a custom trait for contiguous iterators...=C2=A0 The poin=
t was to show that you can easily get the pointers to the elements pointed =
to by the iterator, not to write a complete implementation. Right now the t=
emplate is unconstrained, so you could even pass std::list iterators even t=
hough they don't satify the RandomAccessIterator concept.</div><div> <b=
r></div></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"lt=
r"><div></div><div><br>On Monday, August 21, 2017 at 6:07:25 AM UTC+8, Manu=
el Bergler wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div><br><div class=3D"gmail_quote"><span>On Sun, Aug 20, 2017 at 8:43=
PM, Thiago Macieira <span dir=3D"ltr"><<a rel=3D"nofollow">thi...@macie=
ira.org</a>></span> wrote:<br></span><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><spa=
n><span>On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dominiak wrote:<=
br></span><span>
> On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <<a rel=3D"nofollow">=
thi...@macieira.org</a>> wrote:<br>
> > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:<br></sp=
an>
> > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <<a rel=
=3D"nofollow">berg...@gmail.com</a>><span><br>
> ><br>
> > wrote:<br>
> > > > I don't understand what exactly doesn't work. W=
hat's wrong with<br>
> ><br>
> > converting<br>
> ><br>
> > > > the iterators to pointers by using std::addressof(*iter=
ator)?<br>
> > ><br>
> > > Dereferencing *end() is undefined behavior.<br>
> ><br>
> > std::addressof(end()[-1]) + 1<br>
><br>
> That's UB when begin() =3D=3D end(), no?<br>
<br>
</span></span><span>Yes, but you can't dereference the begin pointer th=
at way either when the list<br>
is empty.<br>
<span><br></span></span></blockquote><span><div><br></div><div>You don'=
t need to dereference begin() when the range is empty and you also don'=
t need to dereference end(). For a typical example of a C API that takes a =
pointer and a size, a C++ wrapper using iterators can easily be implemented=
as</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0void c_style_function(void=
* start, size_t size);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0templat=
e <typename RandomAccessIterator></div><div>=C2=A0 =C2=A0 =C2=A0void =
cpp_wrapper(<wbr>RandomAccessIterator begin, RandomAccessIterator end) {</d=
iv><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto const size =3D std::distanc=
e(begin, end);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
if (size !=3D 0) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 auto begin_ptr =3D std::addressof(*begin);</div><div><br></div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 c_style_function(begin_ptr, s=
ize);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0=
=C2=A0}</div><div><br></div><div>If one additionally creates a trait for c=
ontiguous iterators, the template can also be restricted accordingly. And f=
or C APIs that expect an end pointer instead of a size argument you can als=
o compute the end pointer from begin_ptr and size. As far as I can tell thi=
s doesn't cause UB and does exactly what the OP would like to achieve, =
without needing the iterators to be pointers.</div></span></div></div></div=
>
</blockquote></div>
<p></p>
-- <br></div></div><span><div><div>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span><span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/5d5b4b9b-907d-4f86-<wbr>aa20-=
493c99915621%40isocpp.org</a><wbr>.<br>
</span></blockquote></div><br></div></div>
</blockquote></div><span>
<p></p>
-- <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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9be523a7-ec66-4e3f-a8f5-3c00ff49a588%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/9be523a7-ec66-4e3f-a8f5-3c00ff49a588%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/9be523a7-ec66-4e3f-a8f5-3c00ff49a588%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/9be523a7-ec66-4e3f-<wbr>a8f5-=
3c00ff49a588%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>
</blockquote></div></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2cfc3f07-1a93-4b5f-a30d-c3c9a1b39c9a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2cfc3f07-1a93-4b5f-a30d-c3c9a1b39c9a=
%40isocpp.org</a>.<br />
------=_Part_3251_1938153558.1503385390952--
------=_Part_3250_231223087.1503385390951--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sat, 26 Aug 2017 11:47:41 -0700 (PDT)
Raw View
------=_Part_4525_293562096.1503773261492
Content-Type: multipart/alternative;
boundary="----=_Part_4526_1969358757.1503773261493"
------=_Part_4526_1969358757.1503773261493
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2017=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=883:03:11=EF=BC=8CFrankHB1989=E5=86=99=E9=81=93=EF=BC=9A
>
>
>
> =E5=9C=A8 2017=E5=B9=B48=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 U=
TC+8=E4=B8=8B=E5=8D=8811:04:33=EF=BC=8Cejsvifq mabmip=E5=86=99=E9=81=93=EF=
=BC=9A
>>
>> Contiguous iterator fails to accomplish anything. It is a horrible idea=
=20
>> from the beginning. Just like .data(). Some containers uses "proxy=20
>> pointers" and it cant even be converted to pointers. Is it a contiguous=
=20
>> container??
>>
>> One more point that you have ignored: a contiguous iterator does not=20
> imply there is a special standalone sentinel value available of that type=
,=20
> while the null pointer value (which can be value-initialized without=20
> referring any sequence) is always in the well-defined range of a pointer.=
=20
> (Note the rules of null pointer value is largely orthogonal with iterator=
=20
> requirements, and they are also effective on non-object pointer types and=
=20
> pointer-to-member types.) So the use of a contiguous makes users free to=
=20
> ignore null value handling (if any).
>
> Now I really want the pointers and nonnull pointers have been different=
=20
kinds of types, to conceptually avoid such stupid bug at the very beginning=
=20
in coding even with C:
https://github.com/google/boringssl/commit/17cf2cb1d226b0ba2401304242df7ddd=
3b6f1ff2
There can be more... e.g. the ability of being aliased in a well-defined=20
> manner, but this is related with other core rules, not only pointers.
>
> If concepts like contiguous iterators are just for converting to a raw=20
>> pointer, I don't think it should be implemented at the first place.
>>
>> On Monday, August 21, 2017 at 10:32:11 PM UTC+8, Manuel Bergler wrote:
>>
>>> On Mon, Aug 21, 2017 at 4:17 PM, <eulo...@live.com> wrote:
>>>
>>>> Contiguous iterators might also be initialized by pointers. That would=
=20
>>>> be easier to convert to contiguous iterators from pointers.
>>>>
>>>
>>> Yes, but as was pointed out by other people already, there is no chance=
=20
>>> to get the Standard revised to mandate iterators of contiguous containe=
rs=20
>>> to be pointers.
>>>
>>> When you instead write a custom trait for contiguous iterators, you can=
=20
>>> also immedately specialize it for pointers in addition to the std=20
>>> containers so that pointers also work with such a function template. Th=
e=20
>>> only "drawback" you have is that you have to write the trait, but we ca=
n=20
>>> discuss the merits of such a trait and maybe extend the iterator catego=
ries=20
>>> to include it. Then at least in the future no one has to write it=20
>>> themselves.=20
>>> =20
>>>
>>>>
>>>> On Monday, August 21, 2017 at 10:14:43 PM UTC+8, Manuel Bergler wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Aug 21, 2017 at 4:10 PM, <eulo...@live.com> wrote:
>>>>>
>>>>>> Horrible. Random Access Iterators are not Contiguous Iterators. If=
=20
>>>>>> somebody passes deque iterators into it, UB. Pointers can guaranteed=
to be=20
>>>>>> contiguous iterators.
>>>>>>
>>>>>>
>>>>> That's why I wrote one should add a custom trait for contiguous=20
>>>>> iterators... The point was to show that you can easily get the point=
ers to=20
>>>>> the elements pointed to by the iterator, not to write a complete=20
>>>>> implementation. Right now the template is unconstrained, so you could=
even=20
>>>>> pass std::list iterators even though they don't satify the=20
>>>>> RandomAccessIterator concept.
>>>>>
>>>>>
>>>>>> On Monday, August 21, 2017 at 6:07:25 AM UTC+8, Manuel Bergler wrote=
:
>>>>>>
>>>>>>>
>>>>>>> On Sun, Aug 20, 2017 at 8:43 PM, Thiago Macieira <
>>>>>>> thi...@macieira.org> wrote:
>>>>>>>
>>>>>>>> On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dominiak wrote:
>>>>>>>> > On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <
>>>>>>>> thi...@macieira.org> wrote:
>>>>>>>> > > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:
>>>>>>>> > > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <
>>>>>>>> berg...@gmail.com>
>>>>>>>> > >
>>>>>>>> > > wrote:
>>>>>>>> > > > > I don't understand what exactly doesn't work. What's wrong=
=20
>>>>>>>> with
>>>>>>>> > >
>>>>>>>> > > converting
>>>>>>>> > >
>>>>>>>> > > > > the iterators to pointers by using=20
>>>>>>>> std::addressof(*iterator)?
>>>>>>>> > > >
>>>>>>>> > > > Dereferencing *end() is undefined behavior.
>>>>>>>> > >
>>>>>>>> > > std::addressof(end()[-1]) + 1
>>>>>>>> >
>>>>>>>> > That's UB when begin() =3D=3D end(), no?
>>>>>>>>
>>>>>>>> Yes, but you can't dereference the begin pointer that way either=
=20
>>>>>>>> when the list
>>>>>>>> is empty.
>>>>>>>>
>>>>>>>>
>>>>>>> You don't need to dereference begin() when the range is empty and=
=20
>>>>>>> you also don't need to dereference end(). For a typical example of =
a C API=20
>>>>>>> that takes a pointer and a size, a C++ wrapper using iterators can =
easily=20
>>>>>>> be implemented as
>>>>>>>
>>>>>>> void c_style_function(void* start, size_t size);
>>>>>>>
>>>>>>> template <typename RandomAccessIterator>
>>>>>>> void cpp_wrapper(RandomAccessIterator begin,=20
>>>>>>> RandomAccessIterator end) {
>>>>>>> auto const size =3D std::distance(begin, end);
>>>>>>>
>>>>>>> if (size !=3D 0) {
>>>>>>> auto begin_ptr =3D std::addressof(*begin);
>>>>>>>
>>>>>>> c_style_function(begin_ptr, size);
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> If one additionally creates a trait for contiguous iterators, the=
=20
>>>>>>> template can also be restricted accordingly. And for C APIs that ex=
pect an=20
>>>>>>> end pointer instead of a size argument you can also compute the end=
pointer=20
>>>>>>> from begin_ptr and size. As far as I can tell this doesn't cause UB=
and=20
>>>>>>> does exactly what the OP would like to achieve, without needing the=
=20
>>>>>>> iterators to be pointers.
>>>>>>>
>>>>>> --=20
>>>>>> You received this message because you are subscribed to the Google=
=20
>>>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,=20
>>>>>> send an email to std-proposal...@isocpp.org.
>>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>>> To view this discussion on the web visit=20
>>>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b4b9=
b-907d-4f86-aa20-493c99915621%40isocpp.org=20
>>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d5b4b=
9b-907d-4f86-aa20-493c99915621%40isocpp.org?utm_medium=3Demail&utm_source=
=3Dfooter>
>>>>>> .
>>>>>>
>>>>>
>>>>> --=20
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>> an email to std-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> To view this discussion on the web visit=20
>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9be523a7-=
ec66-4e3f-a8f5-3c00ff49a588%40isocpp.org=20
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9be523a7=
-ec66-4e3f-a8f5-3c00ff49a588%40isocpp.org?utm_medium=3Demail&utm_source=3Df=
ooter>
>>>> .
>>>>
>>>
>>>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/910e4bef-1550-446f-a403-735e061c9468%40isocpp.or=
g.
------=_Part_4526_1969358757.1503773261493
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=883:03:11=EF=BC=8CFrankHB1989=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B48=E6=9C=8821=E6=97=A5=E6=98=9F=E6=
=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=8811:04:33=EF=BC=8Cejsvifq mabmip=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div>Contiguous iterator fails to accomplish anything. It is a horrib=
le idea from the beginning. Just like .data(). Some containers uses "p=
roxy pointers" and it cant even be converted to pointers. Is it a cont=
iguous container??</div><div><br></div></div></blockquote><div>One more poi=
nt that you have ignored: a contiguous iterator does not imply there is a s=
pecial standalone sentinel value available of that type, while the null poi=
nter value (which can be value-initialized without referring any sequence) =
is always in the well-defined range of a pointer. (Note the rules of null p=
ointer value is largely orthogonal with iterator requirements, and they are=
also effective on non-object pointer types and pointer-to-member types.) S=
o the use of a contiguous makes users free to ignore null value handling (i=
f any).<br></div><div><br></div></div></blockquote><div>Now I really want t=
he pointers and nonnull pointers have been different kinds of types, to con=
ceptually avoid such stupid bug at the very beginning in coding even with C=
:</div><div><br></div><div>https://github.com/google/boringssl/commit/17cf2=
cb1d226b0ba2401304242df7ddd3b6f1ff2</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>There can be m=
ore... e.g. the ability of being aliased in a well-defined manner, but this=
is related with other core rules, not only pointers.<br></div><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div=
>If concepts like contiguous iterators are just for converting to a raw poi=
nter, I don't think it should be implemented at the first place.<br><br=
>On Monday, August 21, 2017 at 10:32:11 PM UTC+8, Manuel Bergler wrote:</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Mon, Aug 21, 2017 at 4:17 PM, <span dir=3D"ltr"><<a=
rel=3D"nofollow">eulo...@live.com</a>></span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">Contiguous iterators might also be initial=
ized by pointers. That would be easier to convert to contiguous iterators f=
rom pointers.<br></div></blockquote><div><br></div><div>Yes, but as was poi=
nted out by other people already, there is no chance to get the Standard re=
vised to mandate iterators of contiguous containers to be pointers.</div><d=
iv><br></div><div>When you instead write a custom trait for contiguous iter=
ators, you can also immedately specialize it for pointers in addition to th=
e std containers so that pointers also work with such a function template. =
The only "drawback" you have is that you have to write the trait,=
but we can discuss the merits of such a trait and maybe extend the iterato=
r categories to include it. Then at least in the future no one has to write=
it themselves. <br></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"><br>On Monday, August 21, 2017 at 10:14:43 PM UTC+8, Manuel=
Bergler wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br=
><div><br><div class=3D"gmail_quote"><div><div>On Mon, Aug 21, 2017 at 4:10=
PM, <span dir=3D"ltr"><<a rel=3D"nofollow">eulo...@live.com</a>></s=
pan> wrote:<br><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>Horribl=
e. Random Access Iterators are not Contiguous Iterators. If somebody passes=
deque iterators into it, UB. Pointers can guaranteed to be contiguous iter=
ators.</div><div><br></div></div></blockquote><div><br></div><div>That'=
s why I wrote one should add a custom trait for contiguous iterators...=C2=
=A0 The point was to show that you can easily get the pointers to the eleme=
nts pointed to by the iterator, not to write a complete implementation. Rig=
ht now the template is unconstrained, so you could even pass std::list iter=
ators even though they don't satify the RandomAccessIterator concept.</=
div><div> <br></div></div></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><d=
iv dir=3D"ltr"><div></div><div><br>On Monday, August 21, 2017 at 6:07:25 AM=
UTC+8, Manuel Bergler wrote:</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><br><div class=3D"gmail_quote"><span>On Sun, Aug 20,=
2017 at 8:43 PM, Thiago Macieira <span dir=3D"ltr"><<a rel=3D"nofollow"=
>thi...@macieira.org</a>></span> wrote:<br></span><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><span><span>On Sunday, 20 August 2017 10:37:07 PDT Micha=C5=82 Dom=
iniak wrote:<br></span><span>
> On Sun, Aug 20, 2017, 6:55 PM Thiago Macieira <<a rel=3D"nofollow">=
thi...@macieira.org</a>> wrote:<br>
> > On Sunday, 20 August 2017 01:12:54 PDT Nevin Liber wrote:<br></sp=
an>
> > > On Sun, Aug 20, 2017 at 2:53 AM, Manuel Bergler <<a rel=
=3D"nofollow">berg...@gmail.com</a>><span><br>
> ><br>
> > wrote:<br>
> > > > I don't understand what exactly doesn't work. W=
hat's wrong with<br>
> ><br>
> > converting<br>
> ><br>
> > > > the iterators to pointers by using std::addressof(*iter=
ator)?<br>
> > ><br>
> > > Dereferencing *end() is undefined behavior.<br>
> ><br>
> > std::addressof(end()[-1]) + 1<br>
><br>
> That's UB when begin() =3D=3D end(), no?<br>
<br>
</span></span><span>Yes, but you can't dereference the begin pointer th=
at way either when the list<br>
is empty.<br>
<span><br></span></span></blockquote><span><div><br></div><div>You don'=
t need to dereference begin() when the range is empty and you also don'=
t need to dereference end(). For a typical example of a C API that takes a =
pointer and a size, a C++ wrapper using iterators can easily be implemented=
as</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0void c_style_function(void=
* start, size_t size);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0templat=
e <typename RandomAccessIterator></div><div>=C2=A0 =C2=A0 =C2=A0void =
cpp_wrapper(<wbr>RandomAccessIterator begin, RandomAccessIterator end) {</d=
iv><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto const size =3D std::distanc=
e(begin, end);</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
if (size !=3D 0) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 auto begin_ptr =3D std::addressof(*begin);</div><div><br></div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 c_style_function(begin_ptr, s=
ize);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0=
=C2=A0}</div><div><br></div><div>If one additionally creates a trait for c=
ontiguous iterators, the template can also be restricted accordingly. And f=
or C APIs that expect an end pointer instead of a size argument you can als=
o compute the end pointer from begin_ptr and size. As far as I can tell thi=
s doesn't cause UB and does exactly what the OP would like to achieve, =
without needing the iterators to be pointers.</div></span></div></div></div=
>
</blockquote></div>
<p></p>
-- <br></div></div><span><div><div>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span><span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/5d5b4b9b-907d-4f86-aa20-493c99915621%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/5d5b4b9b-907d-4f86-<wbr>aa20-=
493c99915621%40isocpp.org</a><wbr>.<br>
</span></blockquote></div><br></div></div>
</blockquote></div><span>
<p></p>
-- <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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9be523a7-ec66-4e3f-a8f5-3c00ff49a588%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/9be523a7-ec66-4e3f-a8f5-3c00ff49a588%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/9be523a7-ec66-4e3f-a8f5-3c00ff49a588%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/9be523a7-ec66-4e3f-<wbr>a8f5-=
3c00ff49a588%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>
</blockquote></div></blockquote></div></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/910e4bef-1550-446f-a403-735e061c9468%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/910e4bef-1550-446f-a403-735e061c9468=
%40isocpp.org</a>.<br />
------=_Part_4526_1969358757.1503773261493--
------=_Part_4525_293562096.1503773261492--
.