------=_Part_64_12237348.1391028053690
Content-Type: text/plain; charset=UTF-8

Contiguous iterators described in N3884 will fill a hole in the standard
very nicely. However, reverse_iterator probably needs to be adapted for
this proposal.

reverse_iterator<Iter> has the same iterator category as Iter. That means
that if Iter is a contiguous iterator type, reverse_iterator<iter> will be
contiguous as well... which is problematic and could break existing code.
The reverse of a contiguous iterator should be a random access iterator. I
guess this special case can be handled in the specifications of
reverse_iterator.

What is less obvious is when multiple iterator adaptors are used. For
example, if a contiguous iterator is reversed twice (that is
reverse_iterator<reverse_iterator<Iter>>), it could theoretically still be
considered contiguous. But I'm not sure how this can be done... It gets
even more tricky when mixing other adaptors, like the following, which
could be considered contiguous:
reverse_iterator<move_iterator<reverse_iterator<Iter>>>

Maybe the easiest thing to do (at least for now) is to consider the
iterator to be (at most) random access as soon as it is reversed at least
once, even if it is reversed an even number of times.

The proposal can potentially also break user-made adaptors. For example,
let's say I have a special kind of filter adaptor which always skips one
element when advancing (so advancing would in fact go 2 elements forward).
Let's call this adaptor "skip_iterator". I defined the iterator_category of
skip_iterator<Iter> to be the same as the iterator category of Iter
(similar to std::reverse_iterator). Right now (with C++11/14), the category
of skip_iterator<vector<int>::iterator> is random access. With this
proposal, it will become contiguous... which is *wrong*. Usage of this
iterator in standard algorithms will now possibly be broken (for algorithms
with new special implementation for contiguous iterators).

So as much as I like this proposal, it seems a little dangerous to me...

--

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

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

<div dir=3D"ltr"><div>Contiguous iterators described in N3884 will fill a h=
ole in the standard very nicely. However, reverse_iterator probably needs t=
o be adapted for this proposal.</div><div>&nbsp;</div><div>reverse_iterator=
&lt;Iter&gt; has the same iterator category as Iter. That means that if Ite=
r is a contiguous iterator type, reverse_iterator&lt;iter&gt; will be conti=
guous as well... which is problematic and could break existing code. The re=
verse of a contiguous iterator should be a random access iterator. I guess =
this special case can be handled in the specifications of reverse_iterator.=
</div><div>&nbsp;</div><div>What is less obvious is when multiple iterator =
adaptors are used. For example, if a contiguous iterator is reversed twice =
(that is reverse_iterator&lt;reverse_iterator&lt;Iter&gt;&gt;), it could th=
eoretically still be considered contiguous. But I'm not sure how this can b=
e done... It gets even more tricky when mixing other adaptors, like the fol=
lowing, which could be considered contiguous:</div><div>reverse_iterator&lt=
;move_iterator&lt;reverse_iterator&lt;Iter&gt;&gt;&gt;</div><div>&nbsp;</di=
v><div>Maybe the&nbsp;easiest thing to do (at least for now) is to consider=
 the iterator to be (at most) random access as soon as it is reversed at le=
ast once, even if it is reversed an even number of times.</div><div>&nbsp;<=
/div><div>The proposal&nbsp;can potentially&nbsp;also&nbsp;break user-made =
adaptors. For example, let's say I have a special kind of filter adaptor&nb=
sp;which always skips one element when advancing (so advancing would in fac=
t go 2 elements forward). Let's call this adaptor "skip_iterator". I define=
d the iterator_category of skip_iterator&lt;Iter&gt; to be the same as the =
iterator category of Iter (similar to std::reverse_iterator).&nbsp;Right no=
w (with&nbsp;C++11/14),&nbsp;the category of skip_iterator&lt;vector&lt;int=
&gt;::iterator&gt; is random access. With this proposal, it will become con=
tiguous... which is <em>wrong</em>. Usage of this iterator in standard algo=
rithms will now possibly be broken (for algorithms with new special impleme=
ntation for contiguous iterators).</div><div>&nbsp;</div><div>So as much as=
 I like this proposal, it seems a little dangerous to me...</div></div>

<p></p>

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

------=_Part_64_12237348.1391028053690--

.

--f46d0421a639a2100e04f1227867
Content-Type: text/plain; charset=ISO-8859-1

On 29 January 2014 14:40, Alex B <devalexb@gmail.com> wrote:

> Contiguous iterators described in N3884 will fill a hole in the standard
> very nicely. However, reverse_iterator probably needs to be adapted for
> this proposal.
>

You are correct.  Good catch!


> reverse_iterator<Iter> has the same iterator category as Iter. That means
> that if Iter is a contiguous iterator type, reverse_iterator<iter> will be
> contiguous as well... which is problematic and could break existing code.
> The reverse of a contiguous iterator should be a random access iterator. I
> guess this special case can be handled in the specifications of
> reverse_iterator.
>
> What is less obvious is when multiple iterator adaptors are used. For
> example, if a contiguous iterator is reversed twice (that is
> reverse_iterator<reverse_iterator<Iter>>), it could theoretically still be
> considered contiguous.
>

Assuming pointer_from was extended to reverse_iterator, it could be.

 But I'm not sure how this can be done...
>

I don't think we can solve it in general.  Once you "downgrade" an iterator
category (for whatever reason), you can't automatically upgrade it again.

The proposal can potentially also break user-made adaptors. For example,
> let's say I have a special kind of filter adaptor which always skips one
> element when advancing (so advancing would in fact go 2 elements forward).
> Let's call this adaptor "skip_iterator". I defined the iterator_category of
> skip_iterator<Iter> to be the same as the iterator category of Iter
> (similar to std::reverse_iterator).
>

I agree that anything which wraps an iterator and uses the iterator
category of the underlying type could break.  How risky this is will be up
to L(E)WG to decide (I'll forward your comments on).

Thanks for the input; it is very helpful.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

--f46d0421a639a2100e04f1227867
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 29 January 2014 14:40, Alex B <span dir=3D"ltr">&lt;<a =
href=3D"mailto:devalexb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>=
&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div>Contiguous iterators described in N3884 will fill a h=
ole in the standard very nicely. However, reverse_iterator probably needs t=
o be adapted for this proposal.</div></div></blockquote><div><br></div><div=
>

You are correct.=A0 Good catch!<br>=A0<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>reverse_iterator&lt;Iter&gt; has the same iterato=
r category as Iter. That means that if Iter is a contiguous iterator type, =
reverse_iterator&lt;iter&gt; will be contiguous as well... which is problem=
atic and could break existing code. The reverse of a contiguous iterator sh=
ould be a random access iterator. I guess this special case can be handled =
in the specifications of reverse_iterator.</div>

<div>=A0</div><div>What is less obvious is when multiple iterator adaptors =
are used. For example, if a contiguous iterator is reversed twice (that is =
reverse_iterator&lt;reverse_iterator&lt;Iter&gt;&gt;), it could theoretical=
ly still be considered contiguous.</div>

</div></blockquote><div><br></div><div>Assuming pointer_from was extended t=
o reverse_iterator, it could be.<br><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">

<div dir=3D"ltr"><div> But I&#39;m not sure how this can be done...</div></=
div></blockquote><div><br></div><div>I don&#39;t think we can solve it in g=
eneral.=A0 Once you &quot;downgrade&quot; an iterator category (for whateve=
r reason), you can&#39;t automatically upgrade it again.<br>

</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">The pr=
oposal=A0can potentially=A0also=A0break user-made adaptors. For example, le=
t&#39;s say I have a special kind of filter adaptor=A0which always skips on=
e element when advancing (so advancing would in fact go 2 elements forward)=
.. Let&#39;s call this adaptor &quot;skip_iterator&quot;. I defined the iter=
ator_category of skip_iterator&lt;Iter&gt; to be the same as the iterator c=
ategory of Iter (similar to std::reverse_iterator).=A0</div>

</blockquote><div><br></div><div>I agree that anything which wraps an itera=
tor and uses the iterator category of the underlying type could break.=A0 H=
ow risky this is will be up to L(E)WG to decide (I&#39;ll forward your comm=
ents on).<br>

<br></div><div>Thanks for the input; it is very helpful.<br clear=3D"all"><=
/div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;=A0 (847) 691-1404
</div></div>

<p></p>

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

--f46d0421a639a2100e04f1227867--

.

------=_Part_231_21237914.1391062241885
Content-Type: text/plain; charset=UTF-8

I inadvertently reply direclty to Nevin Liber so I copy/paste his answer:

On 29 January 2014 18:36, Vincent Jacquet wrote:

> Isn't reverse_iterator still contiguous? It's just that "first" is greater
> or equal than "last". So, with a reverse_iterator couldn't you optimize
> reverse_copy the same way you could optimize copy with non reverse
> iterator?
>

That would complicate all code which uses contiguous iterators, as it would
have to determine direction, and some algorithms may have ordering
guarantees.

When you write algorithms that use random access iterators, for the most
part do you assume that first <= last?  I do.  Why should contiguous
iterators be any different.

What is the use case of such a thing?


> Also, I do not quite understand the need of the pointer_from function.
> Can't you just say that countiguous_iterator guarantees that
> std::addressof(*i) is always defined (even though *i might not be) and that
> std::addressof(*(i + n))==std::addressof(*i)+n  ?
>

That would require a core language change.  Pointers are also contiguous
iterators; dereferencing is not tied to addressof and has to do the work to
return a valid reference (a checking iterator could throw, for instance),
etc.
--
 Nevin ":-)" Liber  (847) 691-1404

--

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

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

<div dir=3D"ltr">I inadvertently reply direclty to Nevin Liber so I copy/pa=
ste his answer:<br><br><div class=3D"gmail_quote">On 29 January 2014 18:36,=
 Vincent Jacquet wrote:<br><blockquote class=3D"gmail_quote"><div dir=3D"lt=
r">Isn't reverse_iterator still contiguous? It's just that "first" is great=
er or equal than "last". So, with a reverse_iterator couldn't you optimize =
reverse_copy the same way you could optimize copy with non reverse iterator=
? <br></div></blockquote><div><br></div><div>That would complicate all code=
 which uses contiguous iterators, as it would have to determine direction, =
and some algorithms may have ordering guarantees.</div><div><br></div><div>=
When you write algorithms that use random access iterators, for the most pa=
rt do you assume that first &lt;=3D last? &nbsp;I do. &nbsp;Why should cont=
iguous iterators be any different.&nbsp;</div><div><br></div><div>What is t=
he use case of such a thing?</div><div>&nbsp;<br></div><blockquote class=3D=
"gmail_quote"><div dir=3D"ltr">Also, I do not quite understand the need of =
the pointer_from function. Can't you just say that countiguous_iterator gua=
rantees that std::addressof(*i) is always defined (even though *i might not=
 be) and that std::addressof(*(i + n))=3D=3Dstd::addressof(*i)+n&nbsp; ?<br=
></div></blockquote><div><br></div><div>That would require a core language =
change. &nbsp;Pointers are also contiguous iterators; dereferencing is not =
tied to addressof and has to do the work to return a valid reference (a che=
cking iterator could throw, for instance), etc.</div></div>-- <br>&nbsp;Nev=
in ":-)" Liber&nbsp; (847) 691-1404 <br></div>

<p></p>

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

------=_Part_231_21237914.1391062241885--

.

------=_Part_6802_30084013.1391635412402
Content-Type: text/plain; charset=UTF-8

If you had 2 tags (contiguous_iterator and reverse_contiguous_iterator),
you could restore the contiguous_iterator trait if you reverse a reverse
contiguous iterator. It would not complicate code using contiguous
iterator. Apart from symmetry, I do not see any particular/interresting use
case for this.

Considering the question about the pointer_from function, and if you
forget/forgive the "even though *i might not be defined" nonsense, do you
agree that when

std::pointer_from(i) == std::addressof(*i) when i is dereferencable

then

std::pointer_from(i + n) == std::pointer_from(i) + n, when i + n is a valid
iterator

is strictly equivalent to

std::addressof(*(i + n)) == std::addressof(*i) + n, when i + n is a valid
iterator

Therefore, what is the purpose of this function in the requirements for the
contiguous iterator?

If you want to pass buffers to C function, what you need is not only the
"pointer_from" first, but also the length. So, if you want to discourage
people from using &*i, which is wrong on last, wouldn't it be more
interresting to provide a get_buffer_from function instead?

template <typename I>
std::pair<typename I::pointer,ptrdiff_t> get_buffer_from(I first, I last)

Vincent
PS: vector<bool>::iterator is not a contiguous iterator, right? So
shouldn't it be mentionned somewhere in [vector.overview] or [vector.bool]?



On Thursday, January 30, 2014 7:10:41 AM UTC+1, Vincent Jacquet wrote:
>
> I inadvertently reply direclty to Nevin Liber so I copy/paste his answer:
>
> On 29 January 2014 18:36, Vincent Jacquet wrote:
>
>> Isn't reverse_iterator still contiguous? It's just that "first" is
>> greater or equal than "last". So, with a reverse_iterator couldn't you
>> optimize reverse_copy the same way you could optimize copy with non reverse
>> iterator?
>>
>
> That would complicate all code which uses contiguous iterators, as it
> would have to determine direction, and some algorithms may have ordering
> guarantees.
>
> When you write algorithms that use random access iterators, for the most
> part do you assume that first <= last?  I do.  Why should contiguous
> iterators be any different.
>
> What is the use case of such a thing?
>
>
>> Also, I do not quite understand the need of the pointer_from function.
>> Can't you just say that countiguous_iterator guarantees that
>> std::addressof(*i) is always defined (even though *i might not be) and that
>> std::addressof(*(i + n))==std::addressof(*i)+n  ?
>>
>
> That would require a core language change.  Pointers are also contiguous
> iterators; dereferencing is not tied to addressof and has to do the work to
> return a valid reference (a checking iterator could throw, for instance),
> etc.
> --
>  Nevin ":-)" Liber  (847) 691-1404
>

--

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

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

<div dir=3D"ltr">If you had 2 tags (contiguous_iterator and reverse_contigu=
ous_iterator), you could restore the contiguous_iterator trait if you rever=
se a reverse contiguous iterator. It would not complicate code using contig=
uous iterator. Apart from symmetry, I do not see any particular/interrestin=
g use case for this.<br><br>Considering the question about the pointer_from=
 function, and if you forget/forgive the "even though *i might not be defin=
ed" nonsense,  do you agree that when<br><br>std::pointer_from(i) =3D=3D st=
d::addressof(*i) when i is dereferencable<br><br>then <br><br>std::pointer_=
from(i + n) =3D=3D std::pointer_from(i) + n, when i + n is a valid iterator=
<br><br>is strictly equivalent to<br><br>std::addressof(*(i + n)) =3D=3D st=
d::addressof(*i) + n, when i + n is a valid iterator<br><br>Therefore, what=
 is the purpose of this function in the requirements for the contiguous ite=
rator? <br><br>If you want to pass buffers to C function, what you need is =
not only the "pointer_from" first, but also the length. So, if you want to =
discourage people from using &amp;*i, which is wrong on last, wouldn't it b=
e more interresting to provide a get_buffer_from function instead?<br><br>t=
emplate &lt;typename I&gt;<br>std::pair&lt;typename I::pointer,ptrdiff_t&gt=
; get_buffer_from(I first, I last)<br><br>Vincent<br>PS: vector&lt;bool&gt;=
::iterator is not a contiguous iterator, right? So shouldn't it be mentionn=
ed somewhere in  [vector.overview] or  [vector.bool]?<br><br><br><br>On Thu=
rsday, January 30, 2014 7:10:41 AM UTC+1, Vincent Jacquet wrote:<blockquote=
 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">I inadvertently reply di=
reclty to Nevin Liber so I copy/paste his answer:<br><br><div class=3D"gmai=
l_quote">On 29 January 2014 18:36, Vincent Jacquet wrote:<br><blockquote cl=
ass=3D"gmail_quote"><div dir=3D"ltr">Isn't reverse_iterator still contiguou=
s? It's just that "first" is greater or equal than "last". So, with a rever=
se_iterator couldn't you optimize reverse_copy the same way you could optim=
ize copy with non reverse iterator? <br></div></blockquote><div><br></div><=
div>That would complicate all code which uses contiguous iterators, as it w=
ould have to determine direction, and some algorithms may have ordering gua=
rantees.</div><div><br></div><div>When you write algorithms that use random=
 access iterators, for the most part do you assume that first &lt;=3D last?=
 &nbsp;I do. &nbsp;Why should contiguous iterators be any different.&nbsp;<=
/div><div><br></div><div>What is the use case of such a thing?</div><div>&n=
bsp;<br></div><blockquote class=3D"gmail_quote"><div dir=3D"ltr">Also, I do=
 not quite understand the need of the pointer_from function. Can't you just=
 say that countiguous_iterator guarantees that std::addressof(*i) is always=
 defined (even though *i might not be) and that std::addressof(*(i + n))=3D=
=3Dstd::addressof(*i)+n&nbsp; ?<br></div></blockquote><div><br></div><div>T=
hat would require a core language change. &nbsp;Pointers are also contiguou=
s iterators; dereferencing is not tied to addressof and has to do the work =
to return a valid reference (a checking iterator could throw, for instance)=
, etc.</div></div>-- <br>&nbsp;Nevin ":-)" Liber&nbsp; (847) 691-1404 <br><=
/div></blockquote></div>

<p></p>

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

------=_Part_6802_30084013.1391635412402--

.

--047d7bd6bb0eda196a04f1b025cf
Content-Type: text/plain; charset=ISO-8859-1

On 5 February 2014 15:23, Vincent Jacquet <vjacquet@flowgroup.fr> wrote:

> If you had 2 tags (contiguous_iterator and reverse_contiguous_iterator),
> you could restore the contiguous_iterator trait if you reverse a reverse
> contiguous iterator.
>

Or someone could make a (breaking) proposal that
reverse_iterator<reverse_iterator<I>> == I, which restores all the
properties of T (and loses all the properties of reverse_iterator, such as
base(), which is why it would be a breaking change).  Note:  that someone
won't be me. :-)


> It would not complicate code using contiguous iterator.
>

It may complicate generic code using random access iterators, because now a
reverse_iterator can unexpectedly promote the category.


> Apart from symmetry, I do not see any particular/interresting use case for
> this.
>

Without a use case, I don't see a need to introduce it, nor do I see it
passing the committee (it's been discussed on internal reflectors, and only
one person is for it, but he doesn't have a use case either).


> Considering the question about the pointer_from function, and if you
> forget/forgive the "even though *i might not be defined" nonsense,
>

You cannot forget it; it's kind of the point of having the conversion
function.

That being said, I cannot think of a situation where you wouldn't have a
range (either two iterators or an iterator and a size), so the conversion
function isn't strictly needed, but it is a nicety.

Without it, you have to write less efficient code like:

auto pFirst = first == last ? nullptr : std::addressof(*first);
auto pLast = pFirst + (last - first);


> Therefore, what is the purpose of this function in the requirements for
> the contiguous iterator?
>

To be able to convert a one past the end iterator to a pointer both (a)
without requiring a range and (b) efficiently.


> If you want to pass buffers to C function, what you need is not only the
> "pointer_from" first, but also the length.
>

Some C APIs take two pointers.


> So, if you want to discourage people from using &*i, which is wrong on
> last, wouldn't it be more interresting to provide a get_buffer_from
> function instead?
>
> template <typename I>
> std::pair<typename I::pointer,ptrdiff_t> get_buffer_from(I first, I last)
>

A type for that functionality will (hopefully) exist for char*; it's called
string_view <http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3849.html>.
And I for one am glad it isn't std::pair; "first" and "second" are horrible
names in most circumstances.


> PS: vector<bool>::iterator is not a contiguous iterator, right?
>

It is not.


> So shouldn't it be mentionned somewhere in [vector.overview] or
> [vector.bool]?
>

I don't believe they meet the random access iterator requirements now, one
of which is that *i returns a true T& or T const& (see 24.2.5 Forward
Iterators for more details).  I'm not changing the status quo on
vector<bool>, so no need to change its wording.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

--047d7bd6bb0eda196a04f1b025cf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 5 February 2014 15:23, Vincent Jacquet <span dir=3D"ltr=
">&lt;<a href=3D"mailto:vjacquet@flowgroup.fr" target=3D"_blank">vjacquet@f=
lowgroup.fr</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">If you had 2 tags (contiguo=
us_iterator and reverse_contiguous_iterator), you could restore the contigu=
ous_iterator trait if you reverse a reverse contiguous iterator.</div>

</blockquote><div><br></div><div>Or someone could make a (breaking) proposa=
l that reverse_iterator&lt;reverse_iterator&lt;I&gt;&gt; =3D=3D I, which re=
stores all the properties of T (and loses all the properties of reverse_ite=
rator, such as base(), which is why it would be a breaking change).=A0 Note=
:=A0 that someone won&#39;t be me. :-)<br>

</div><div>=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"> It wou=
ld not complicate code using contiguous iterator. </div></blockquote><div><=
br>
</div>
<div>It may complicate generic code using random access iterators, because =
now a reverse_iterator can unexpectedly promote the category.<br></div><div=
>=A0</div><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">Apart from symmetry, I do not see any particular/interrest=
ing use case for this.<br></div></blockquote><div><br></div><div>Without a =
use case, I don&#39;t see a need to introduce it, nor do I see it passing t=
he committee (it&#39;s been discussed on internal reflectors, and only one =
person is for it, but he doesn&#39;t have a use case either).<br>

</div><div>=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">Conside=
ring the question about the pointer_from function, and if you forget/forgiv=
e the &quot;even though *i might not be defined&quot; nonsense,</div>

</blockquote><div><br></div><div>You cannot forget it; it&#39;s kind of the=
 point of having the conversion function.<br><br></div><div>That being said=
, I cannot think of a situation where you wouldn&#39;t have a range (either=
 two iterators or an iterator and a size), so the conversion function isn&#=
39;t strictly needed, but it is a nicety.<br>

<br></div><div>Without it, you have to write less efficient code like:<br><=
br></div><div>auto pFirst =3D first =3D=3D last ? nullptr : std::addressof(=
*first);<br></div><div>auto pLast =3D pFirst + (last - first);<br>=A0</div>=
<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">Therefore, what is the purpose of this function in the req=
uirements for the contiguous iterator? <br></div></blockquote><div><br></di=
v><div>To be able to convert a one past the end iterator to a pointer both =
(a) without requiring a range and (b) efficiently.<br>

</div><div>=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">If you =
want to pass buffers to C function, what you need is not only the &quot;poi=
nter_from&quot; first, but also the length. </div>

</blockquote><div><br></div><div>Some C APIs take two pointers.<br></div><d=
iv>=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">So, if you want=
 to discourage people from using &amp;*i, which is wrong on last, wouldn&#3=
9;t it be more interresting to provide a get_buffer_from function instead?<=
br>

<br>template &lt;typename I&gt;<br>std::pair&lt;typename I::pointer,ptrdiff=
_t&gt; get_buffer_from(I first, I last)<span class=3D"HOEnZb"><font color=
=3D"#888888"><br></font></span></div></blockquote><div><br></div>A type for=
 that functionality will (hopefully) exist for char*; it&#39;s called <a hr=
ef=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3849.html">strin=
g_view</a>.=A0 And I for one am glad it isn&#39;t std::pair; &quot;first&qu=
ot; and &quot;second&quot; are horrible names in most circumstances.<br>

<div>=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"><span class=
=3D"HOEnZb"></span>PS: vector&lt;bool&gt;::iterator is not a contiguous ite=
rator, right?</div>

</blockquote><div><br></div><div>It is not.<br></div><div>=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"> So shouldn&#39;t it be mentionned =
somewhere in  [vector.overview] or  [vector.bool]?</div>

</blockquote><div><br></div><div>I don&#39;t believe they meet the random a=
ccess iterator requirements now, one of which is that *i returns a true T&a=
mp; or T const&amp; (see 24.2.5 Forward Iterators for more details).=A0 I&#=
39;m not changing the status quo on vector&lt;bool&gt;, so no need to chang=
e its wording.<br>

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404
</div></div>

<p></p>

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

--047d7bd6bb0eda196a04f1b025cf--

.

------=_Part_7525_4650068.1391647946384
Content-Type: text/plain; charset=UTF-8



On Wednesday, February 5, 2014 11:18:38 PM UTC+1, Nevin ":-)" Liber wrote:
>
> On 5 February 2014 15:23, Vincent Jacquet <vjac...@flowgroup.fr<javascript:>
> > wrote:
>
>> If you had 2 tags (contiguous_iterator and reverse_contiguous_iterator),
>> you could restore the contiguous_iterator trait if you reverse a reverse
>> contiguous iterator.
>>
>
> Or someone could make a (breaking) proposal that
> reverse_iterator<reverse_iterator<I>> == I, which restores all the
> properties of T (and loses all the properties of reverse_iterator, such as
> base(), which is why it would be a breaking change).  Note:  that someone
> won't be me. :-)
>
>
>> It would not complicate code using contiguous iterator.
>>
>
>  It may complicate generic code using random access iterators, because
> now a reverse_iterator can unexpectedly promote the category.
>

Just for the sake of the argument, I think it cannot. reverse_iterator has
to adapted for the contiguous_iterator category. Instead of returning
random_access, it could return reverse_contiguous...


>
>> Apart from symmetry, I do not see any particular/interresting use case
>> for this.
>>
>
> Without a use case, I don't see a need to introduce it, nor do I see it
> passing the committee (it's been discussed on internal reflectors, and only
> one person is for it, but he doesn't have a use case either).
>
It's nice to know I am not the only one. I felt sometimes misunderstood in
theses forums ;)

>
>
>> Considering the question about the pointer_from function, and if you
>> forget/forgive the "even though *i might not be defined" nonsense,
>>
>
> You cannot forget it; it's kind of the point of having the conversion
> function.
>

> That being said, I cannot think of a situation where you wouldn't have a
> range (either two iterators or an iterator and a size), so the conversion
> function isn't strictly needed, but it is a nicety.
>
> Without it, you have to write less efficient code like:
>
> auto pFirst = first == last ? nullptr : std::addressof(*first);
> auto pLast = pFirst + (last - first);
>
Therefore, what is the purpose of this function in the requirements for the
>> contiguous iterator?
>>
>
> To be able to convert a one past the end iterator to a pointer both (a)
> without requiring a range and (b) efficiently.
>
OK, I get it now. It wasn't clear to me that pointer_from would be defined
for "last". I do not know if it is a good thing or not. I wonder if "never
use the 'last' iterator to retrieve a pointer" is not easier to teach that
"never use the 'last' iterator to retrieve a pointer, except if the
iterator is a contiguous iterator, in which case you should use
pointer_from"

>
>
>> If you want to pass buffers to C function, what you need is not only the
>> "pointer_from" first, but also the length.
>>
>
> Some C APIs take two pointers.
>
>
>> So, if you want to discourage people from using &*i, which is wrong on
>> last, wouldn't it be more interresting to provide a get_buffer_from
>> function instead?
>>
>> template <typename I>
>> std::pair<typename I::pointer,ptrdiff_t> get_buffer_from(I first, I last)
>>
>
> A type for that functionality will (hopefully) exist for char*; it's
> called string_view<http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3849.html>.
> And I for one am glad it isn't std::pair; "first" and "second" are horrible
> names in most circumstances.
>
Sorry, I do not share the "hopefully". I am not a big fan of string_view
but this is another story.
And I have no problem with pair, first and second. I think they serve their
purpose just fine. When I find the names first and second horrible is often
a good sign that I should be defining an abstraction instead of using a
pair.

>
>
>> PS: vector<bool>::iterator is not a contiguous iterator, right?
>>
>
> It is not.
>
>
>> So shouldn't it be mentionned somewhere in [vector.overview] or
>> [vector.bool]?
>>
>
> I don't believe they meet the random access iterator requirements now, one
> of which is that *i returns a true T& or T const& (see 24.2.5 Forward
> Iterators for more details).  I'm not changing the status quo on
> vector<bool>, so no need to change its wording.
>
I didn't knew that. Interresting ... and somehow a little sad.
That means my compiler has a bug. vector<bool>::iterator::iterator_category
returns random_access_iterator_tag under VS2013.


> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)
> 691-1404
>

--

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

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

<div dir=3D"ltr"><br><br>On Wednesday, February 5, 2014 11:18:38 PM UTC+1, =
Nevin ":-)" Liber wrote:<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">On 5 February 2014 15:23, Vincent Jacquet <span dir=3D"ltr">&lt;=
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"RAoMoBti=
EFAJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"thi=
s.href=3D'javascript:';return true;">vjac...@flowgroup.fr</a>&gt;</span> wr=
ote:<br><div><div class=3D"gmail_quote">

<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">If you had 2 tags (contiguo=
us_iterator and reverse_contiguous_iterator), you could restore the contigu=
ous_iterator trait if you reverse a reverse contiguous iterator.</div>

</blockquote><div><br></div><div>Or someone could make a (breaking) proposa=
l that reverse_iterator&lt;reverse_<wbr>iterator&lt;I&gt;&gt; =3D=3D I, whi=
ch restores all the properties of T (and loses all the properties of revers=
e_iterator, such as base(), which is why it would be a breaking change).&nb=
sp; Note:&nbsp; that someone won't be me. :-)<br>

</div><div>&nbsp;</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"> It =
would not complicate code using contiguous iterator. </div></blockquote><di=
v><br>
</div>
<div>It may complicate generic code using random access iterators, because =
now a reverse_iterator can unexpectedly promote the category.<br></div></di=
v></div></div></blockquote><div><br>Just for the sake of the argument, I th=
ink it cannot. reverse_iterator has to adapted for the contiguous_iterator =
category. Instead of returning random_access, it could return reverse_conti=
guous...<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 class=3D"gmail_quote"><div></div><div>&nbsp;</div><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">Apart from symmetry, I do not see any particular/interrest=
ing use case for this.<br></div></blockquote><div><br></div><div>Without a =
use case, I don't see a need to introduce it, nor do I see it passing the c=
ommittee (it's been discussed on internal reflectors, and only one person i=
s for it, but he doesn't have a use case either).<br></div></div></div></di=
v></blockquote><div>It's nice to know I am not the only one. I felt sometim=
es misunderstood in theses forums ;)<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>

</div><div>&nbsp;</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">Cons=
idering the question about the pointer_from function, and if you forget/for=
give the "even though *i might not be defined" nonsense,</div>

</blockquote><div><br></div><div>You cannot forget it; it's kind of the poi=
nt of having the conversion function.<br></div></div></div></div></blockquo=
te><div></div><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"=
><div><div class=3D"gmail_quote"><div><br></div><div>That being said, I can=
not think of a situation where you wouldn't have a range (either two iterat=
ors or an iterator and a size), so the conversion function isn't strictly n=
eeded, but it is a nicety.<br>

<br></div><div>Without it, you have to write less efficient code like:<br><=
br></div><div>auto pFirst =3D first =3D=3D last ? nullptr : std::addressof(=
*first);<br></div><div>auto pLast =3D pFirst + (last - first);<br></div></d=
iv></div></div></blockquote><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><div class=3D"gmail_quote"><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">Therefore, what is the purpose of this function in the req=
uirements for the contiguous iterator? <br></div></blockquote><div><br></di=
v><div>To be able to convert a one past the end iterator to a pointer both =
(a) without requiring a range and (b) efficiently.<br></div></div></div></d=
iv></blockquote><div>OK, I get it now. It wasn't clear to me that pointer_f=
rom would be defined for "last". I do not know if it is a good thing or not=
.. I wonder if "never use the 'last' iterator to retrieve a pointer" is not =
easier to teach that "never use the 'last' iterator to retrieve a pointer, =
except if the iterator is a contiguous iterator, in which case you should u=
se pointer_from"</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>&nbsp;</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">If y=
ou want to pass buffers to C function, what you need is not only the "point=
er_from" first, but also the length. </div>

</blockquote><div><br></div><div>Some C APIs take two pointers.<br></div><d=
iv>&nbsp;</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">So, if you w=
ant to discourage people from using &amp;*i, which is wrong on last, wouldn=
't it be more interresting to provide a get_buffer_from function instead?<b=
r>

<br>template &lt;typename I&gt;<br>std::pair&lt;typename I::pointer,ptrdiff=
_t&gt; get_buffer_from(I first, I last)<span><font color=3D"#888888"><br></=
font></span></div></blockquote><div><br></div>A type for that functionality=
 will (hopefully) exist for char*; it's called <a href=3D"http://open-std.o=
rg/JTC1/SC22/WG21/docs/papers/2014/n3849.html" target=3D"_blank" onmousedow=
n=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2=
FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn3849.html\46sa\75D\46sntz\075=
1\46usg\75AFQjCNFX1aIGd6D1bixtvjWxCyebXADG_g';return true;" onclick=3D"this=
..href=3D'http://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FS=
C22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn3849.html\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNFX1aIGd6D1bixtvjWxCyebXADG_g';return true;">string_view</a>.&nbsp; A=
nd I for one am glad it isn't std::pair; "first" and "second" are horrible =
names in most circumstances.<br></div></div></div></blockquote><div>Sorry, =
I do not share the "hopefully". I am not a big fan of string_view but this =
is another story.<br>And I have no problem with pair, first and second. I t=
hink they serve their purpose just fine. When I find the names first and se=
cond horrible is often a good sign that I should be defining an abstraction=
 instead of using a pair. <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 class=3D"gmail_quote">

<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span></sp=
an>PS: vector&lt;bool&gt;::iterator is not a contiguous iterator, right?</d=
iv>

</blockquote><div><br></div><div>It is not.<br></div><div>&nbsp;</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"> So shouldn't it be mentionned s=
omewhere in  [vector.overview] or  [vector.bool]?</div>

</blockquote><div><br></div><div>I don't believe they meet the random acces=
s iterator requirements now, one of which is that *i returns a true T&amp; =
or T const&amp; (see 24.2.5 Forward Iterators for more details).&nbsp; I'm =
not changing the status quo on vector&lt;bool&gt;, so no need to change its=
 wording.<br></div></div></div></div></blockquote><div>I didn't knew that. =
Interresting ... and somehow a little sad.<br>That means my compiler has a =
bug. vector&lt;bool&gt;::iterator::iterator_category returns random_access_=
iterator_tag under VS2013. <br>&nbsp;</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>

</div></div>-- <br>&nbsp;Nevin ":-)" Liber&nbsp; &lt;mailto:<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"RAoMoBtiEFAJ" onmousedo=
wn=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javas=
cript:';return true;">ne...@eviloverlord.com</a><wbr>&gt;&nbsp; (847) 691-1=
404
</div></div>
</blockquote></div>

<p></p>

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

------=_Part_7525_4650068.1391647946384--

.

--089e016347a459feb104f1c02d6e
Content-Type: text/plain; charset=ISO-8859-1

On 5 February 2014 18:52, Vincent Jacquet <vjacquet@flowgroup.fr> wrote:

>
> Just for the sake of the argument, I think it cannot. reverse_iterator has
> to adapted for the contiguous_iterator category. Instead of returning
> random_access, it could return reverse_contiguous...
>

Anything that uses iterator tags has to understand those rules.  Wrappers
in particular (reverse_iterator, move_iterator, as well as many in Boost,
etc.) tend to use tags but not via overload dispatching, so they would have
extra complexity.


> OK, I get it now. It wasn't clear to me that pointer_from would be defined
> for "last". I do not know if it is a good thing or not. I wonder if "never
> use the 'last' iterator to retrieve a pointer" is not easier to teach that
> "never use the 'last' iterator to retrieve a pointer, except if the
> iterator is a contiguous iterator, in which case you should use
> pointer_from"
>

People do it anyway via the sometimes unsafe "&*" (heck, weren't you the
one who initially argued this should become legal for one-past-the-end
iterators?); I think it is strictly better if there was a way to do it
legally.  Note:  such a mechanism could someday be extended to, say,
forward iterators and smart pointers.


> So, if you want to discourage people from using &*i, which is wrong on
>>> last, wouldn't it be more interresting to provide a get_buffer_from
>>> function instead?
>>>
>>> template <typename I>
>>> std::pair<typename I::pointer,ptrdiff_t> get_buffer_from(I first, I last)
>>>
>>
>> A type for that functionality will (hopefully) exist for char*; it's
>> called string_view<http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3849.html>.
>> And I for one am glad it isn't std::pair; "first" and "second" are horrible
>> names in most circumstances.
>>
>
>

> And I have no problem with pair, first and second. I think they serve
> their purpose just fine. When I find the names first and second horrible is
> often a good sign that I should be defining an abstraction instead of using
> a pair.
>

So, doesn't the return value from get_buffer_from() deserve its own
abstraction?

We would have far more readable code if C++03 had done something like:

std::inserted<MyMapType> ins = myMap.insert(std::make_map_entry(k, v));
std::cout << (ins.added ? "new" : "old") << ' ' << ins.position->key << ','
<< ins.position->value << std::endl;

instead of:

std::pair<MyMapType::iterator, bool> ins = myMap.insert(std::make_pair(k,
v));
std::cout << (ins.second ? "new" : "old") << ' ' ins.first->first << ',' <<
ins.first->second << std::endl;

And if functions like equal_range returned std::range_type instead of a
pair, we could have range-based for working on it right now instead of
maybe C++17.

I can't think of any use in the standard library that isn't worse off for
using pair instead of a dedicated type.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

--089e016347a459feb104f1c02d6e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 5 February 2014 18:52, Vincent Jacquet <span dir=3D"ltr=
">&lt;<a href=3D"mailto:vjacquet@flowgroup.fr" target=3D"_blank">vjacquet@f=
lowgroup.fr</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>Just for the sake =
of the argument, I think it cannot. reverse_iterator has to adapted for the=
 contiguous_iterator category. Instead of returning random_access, it could=
 return reverse_contiguous...<br>

</div></div></blockquote><div><br></div>Anything that uses iterator tags ha=
s to understand those rules.=A0 Wrappers in particular (reverse_iterator, m=
ove_iterator, as well as many in Boost, etc.) tend to use tags but not via =
overload dispatching, so they would have extra complexity.<br>

<div>=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">OK, I get it =
now. It wasn&#39;t clear to me that pointer_from would be defined for &quot=
;last&quot;. I do not know if it is a good thing or not. I wonder if &quot;=
never use the &#39;last&#39; iterator to retrieve a pointer&quot; is not ea=
sier to teach that &quot;never use the &#39;last&#39; iterator to retrieve =
a pointer, except if the iterator is a contiguous iterator, in which case y=
ou should use pointer_from&quot;</div>

</blockquote><div><br></div><div>People do it anyway via the sometimes unsa=
fe &quot;&amp;*&quot; (heck, weren&#39;t you the one who initially argued t=
his should become legal for one-past-the-end iterators?); I think it is str=
ictly better if there was a way to do it legally.=A0 Note:=A0 such a mechan=
ism could someday be extended to, say, forward iterators and smart pointers=
..<br>

</div><div>=A0 <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"><d=
iv class=3D"im"><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"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">So, if you want to discourage people from using &amp;=
*i, which is wrong on last, wouldn&#39;t it be more interresting to provide=
 a get_buffer_from function instead?<br>



<br>template &lt;typename I&gt;<br>std::pair&lt;typename I::pointer,ptrdiff=
_t&gt; get_buffer_from(I first, I last)<span><font color=3D"#888888"><br></=
font></span></div></blockquote><div><br></div>A type for that functionality=
 will (hopefully) exist for char*; it&#39;s called <a href=3D"http://open-s=
td.org/JTC1/SC22/WG21/docs/papers/2014/n3849.html" target=3D"_blank">string=
_view</a>.=A0 And I for one am glad it isn&#39;t std::pair; &quot;first&quo=
t; and &quot;second&quot; are horrible names in most circumstances.<br>

</div></div></div></blockquote></div><div><br></div></div></blockquote><div=
>=A0</div><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>And I have n=
o problem with pair, first and second. I think they serve their purpose jus=
t fine. When I find the names first and second horrible is often a good sig=
n that I should be defining an abstraction instead of using a pair. <br>

</div></div></blockquote><div><br></div><div>So, doesn&#39;t the return val=
ue from get_buffer_from() deserve its own abstraction?<br><br>We would have=
 far more readable code if C++03 had done something like:<br><br></div>

<div><font size=3D"1"><span style=3D"font-family:courier new,monospace">std=
::inserted&lt;MyMapType&gt; ins =3D myMap.insert(std::make_map_entry(k, v))=
;<br></span></font></div><div><font size=3D"1"><span style=3D"font-family:c=
ourier new,monospace">std::cout &lt;&lt; (ins.added ? &quot;new&quot; : &qu=
ot;old&quot;) &lt;&lt; &#39; &#39; &lt;&lt; ins.position-&gt;key &lt;&lt; &=
#39;,&#39; &lt;&lt; ins.position-&gt;value &lt;&lt; std::endl;</span></font=
><br>

<br></div><div>instead of:<br><br><font size=3D"1"><span style=3D"font-fami=
ly:courier new,monospace">std::pair&lt;MyMapType::iterator, bool&gt; ins =
=3D myMap.insert(std::make_pair(k, v));<br></span></font></div><div><font s=
ize=3D"1"><span style=3D"font-family:courier new,monospace">std::cout &lt;&=
lt; (ins.second ? &quot;new&quot; : &quot;old&quot;) &lt;&lt; &#39; &#39; i=
ns.first-&gt;first &lt;&lt; &#39;,&#39; &lt;&lt; ins.first-&gt;second &lt;&=
lt; std::endl;</span></font><br>

<br></div><div>And if functions like equal_range returned std::range_type i=
nstead of a pair, we could have range-based for working on it right now ins=
tead of maybe C++17.<br></div><div><br>I can&#39;t think of any use in the =
standard library that isn&#39;t worse off for using pair instead of a dedic=
ated type.<br clear=3D"all">

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404
</div></div>

<p></p>

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

--089e016347a459feb104f1c02d6e--

.

------=_Part_48_8070906.1391713328514
Content-Type: text/plain; charset=UTF-8

> pointer_from()

Why not to_pointer()? We've already got to_string()

> The initial thought was to have an explicit cast to a T* can cover both
pointers and non-pointer contiguous
iterators, but some people consider that going too far towards weakening
the boundary between pointers
and iterators.

Could you provide a concrete problem case?
I was kinda hoping for an implicit conversion to T*.

--

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

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

<div dir=3D"ltr">&gt; pointer_from()<div><br></div><div>Why not to_pointer(=
)? We've already got to_string()</div><div><br></div><div>&gt; The initial =
thought was to have an explicit cast to a T* can cover both pointers and no=
n-pointer contiguous&nbsp;</div><div>iterators, but some people consider th=
at going too far towards weakening the boundary between pointers&nbsp;</div=
><div>and iterators.&nbsp;</div><div><br></div><div>Could you provide a con=
crete problem case?</div><div>I was kinda hoping for an implicit conversion=
 to T*.</div></div>

<p></p>

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

------=_Part_48_8070906.1391713328514--

.

------=_Part_11_9981088.1391721252587
Content-Type: text/plain; charset=UTF-8


On Thursday, February 6, 2014 6:26:03 PM UTC+1, Nevin ":-)" Liber wrote:
>
> On 5 February 2014 18:52, Vincent Jacquet <vjac...@flowgroup.fr<javascript:>
> > wrote:
>
>>
>> Just for the sake of the argument, I think it cannot. reverse_iterator
>> has to adapted for the contiguous_iterator category. Instead of returning
>> random_access, it could return reverse_contiguous...
>>
>
> Anything that uses iterator tags has to understand those rules.  Wrappers
> in particular (reverse_iterator, move_iterator, as well as many in Boost,
> etc.) tend to use tags but not via overload dispatching, so they would have
> extra complexity.
>
>
>> OK, I get it now. It wasn't clear to me that pointer_from would be
>> defined for "last". I do not know if it is a good thing or not. I wonder if
>> "never use the 'last' iterator to retrieve a pointer" is not easier to
>> teach that "never use the 'last' iterator to retrieve a pointer, except if
>> the iterator is a contiguous iterator, in which case you should use
>> pointer_from"
>>
>
> People do it anyway via the sometimes unsafe "&*" (heck, weren't you the
> one who initially argued this should become legal for one-past-the-end
> iterators?); I think it is strictly better if there was a way to do it
> legally.
>
Yes, I was wrong, you were right. I was thinking of pointers while speaking
of iterators and I got confused. This is why I reworded what I meant
yesterday.


> Note:  such a mechanism could someday be extended to, say, forward
> iterators and smart pointers.
>
>
>> So, if you want to discourage people from using &*i, which is wrong on
>>>> last, wouldn't it be more interresting to provide a get_buffer_from
>>>> function instead?
>>>>
>>>> template <typename I>
>>>> std::pair<typename I::pointer,ptrdiff_t> get_buffer_from(I first, I
>>>> last)
>>>>
>>>
>>> A type for that functionality will (hopefully) exist for char*; it's
>>> called string_view<http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3849.html>.
>>> And I for one am glad it isn't std::pair; "first" and "second" are horrible
>>> names in most circumstances.
>>>
>>
>>
>
>> And I have no problem with pair, first and second. I think they serve
>> their purpose just fine. When I find the names first and second horrible is
>> often a good sign that I should be defining an abstraction instead of using
>> a pair.
>>
>
> So, doesn't the return value from get_buffer_from() deserve its own
> abstraction?
>
No, IMVHO, I do not think it does. I want to get it, use it and throw it
away. I do not want to keep it or move it around, I do not want to think
about how I should name the fields, or what methods I should or should not
provide. I just need two values.


>
> We would have far more readable code if C++03 had done something like:
>
> std::inserted<MyMapType> ins = myMap.insert(std::make_map_entry(k, v));
> std::cout << (ins.added ? "new" : "old") << ' ' << ins.position->key <<
> ',' << ins.position->value << std::endl;
>
> instead of:
>
> std::pair<MyMapType::iterator, bool> ins = myMap.insert(std::make_pair(k,
> v));
> std::cout << (ins.second ? "new" : "old") << ' ' ins.first->first << ','
> << ins.first->second << std::endl;
>
> Yes, the first version is more readable. Yet it is more things to learn,
remember, compile, implement, maintain, document and standardize. It is not
perfect but I do not think it is that bad.


> And if functions like equal_range returned std::range_type instead of a
> pair, we could have range-based for working on it right now instead of
> maybe C++17.
>
> I can't think of any use in the standard library that isn't worse off for
> using pair instead of a dedicated type.
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)
> 691-1404
>

--

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

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

<div dir=3D"ltr"><br>On Thursday, February 6, 2014 6:26:03 PM UTC+1, Nevin =
":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On 5 February 2014 18:52, Vincent Jacquet <span dir=3D"ltr">&lt;<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"IcPBnMiopNgJ" =
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">vjac...@flowgroup.fr</a>&gt;</span> wrote:<b=
r><div><div class=3D"gmail_quote">

<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"><br><div>Just for the sake =
of the argument, I think it cannot. reverse_iterator has to adapted for the=
 contiguous_iterator category. Instead of returning random_access, it could=
 return reverse_contiguous...<br>

</div></div></blockquote><div><br></div>Anything that uses iterator tags ha=
s to understand those rules.&nbsp; Wrappers in particular (reverse_iterator=
, move_iterator, as well as many in Boost, etc.) tend to use tags but not v=
ia overload dispatching, so they would have extra complexity.<br>

<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">OK, I get =
it now. It wasn't clear to me that pointer_from would be defined for "last"=
.. I do not know if it is a good thing or not. I wonder if "never use the 'l=
ast' iterator to retrieve a pointer" is not easier to teach that "never use=
 the 'last' iterator to retrieve a pointer, except if the iterator is a con=
tiguous iterator, in which case you should use pointer_from"</div>

</blockquote><div><br></div><div>People do it anyway via the sometimes unsa=
fe "&amp;*" (heck, weren't you the one who initially argued this should bec=
ome legal for one-past-the-end iterators?); I think it is strictly better i=
f there was a way to do it legally.&nbsp; </div></div></div></div></blockqu=
ote><div>Yes, I was wrong, you were right. I was thinking of pointers while=
 speaking of iterators and I got confused. This is why I <span id=3D"result=
_box" class=3D"short_text" lang=3D"en"><span class=3D"hps">reworded </span>=
</span>what I meant yesterday.<br>&nbsp;</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Note:=
&nbsp; such a mechanism could someday be extended to, say, forward iterator=
s and smart pointers.<br>

</div><div>&nbsp; <br></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><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"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">So, if you want to discourage people from using &amp;=
*i, which is wrong on last, wouldn't it be more interresting to provide a g=
et_buffer_from function instead?<br>



<br>template &lt;typename I&gt;<br>std::pair&lt;typename I::pointer,ptrdiff=
_t&gt; get_buffer_from(I first, I last)<span><font color=3D"#888888"><br></=
font></span></div></blockquote><div><br></div>A type for that functionality=
 will (hopefully) exist for char*; it's called <a href=3D"http://open-std.o=
rg/JTC1/SC22/WG21/docs/papers/2014/n3849.html" target=3D"_blank" onmousedow=
n=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2=
FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn3849.html\46sa\75D\46sntz\075=
1\46usg\75AFQjCNFX1aIGd6D1bixtvjWxCyebXADG_g';return true;" onclick=3D"this=
..href=3D'http://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FS=
C22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn3849.html\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNFX1aIGd6D1bixtvjWxCyebXADG_g';return true;">string_view</a>.&nbsp; A=
nd I for one am glad it isn't std::pair; "first" and "second" are horrible =
names in most circumstances.<br>

</div></div></div></blockquote></div><div><br></div></div></blockquote><div=
>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>And I hav=
e no problem with pair, first and second. I think they serve their purpose =
just fine. When I find the names first and second horrible is often a good =
sign that I should be defining an abstraction instead of using a pair. <br>

</div></div></blockquote><div><br></div><div>So, doesn't the return value f=
rom get_buffer_from() deserve its own abstraction?<br></div></div></div></d=
iv></blockquote><div>No, IMVHO, I do not think it does. I want to get it, u=
se it and throw it away. I do not want to keep it or move it around, I do n=
ot want to think about how I should name the fields, or what methods I shou=
ld or should not provide. I just need two values.<br>&nbsp;<br></div><block=
quote 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"><div><div class=3D"=
gmail_quote"><div><br>We would have far more readable code if C++03 had don=
e something like:<br><br></div>

<div><font size=3D"1"><span style=3D"font-family:courier new,monospace">std=
::inserted&lt;MyMapType&gt; ins =3D myMap.insert(std::make_map_<wbr>entry(k=
, v));<br></span></font></div><div><font size=3D"1"><span style=3D"font-fam=
ily:courier new,monospace">std::cout &lt;&lt; (ins.added ? "new" : "old") &=
lt;&lt; ' ' &lt;&lt; ins.position-&gt;key &lt;&lt; ',' &lt;&lt; ins.positio=
n-&gt;value &lt;&lt; std::endl;</span></font><br>

<br></div><div>instead of:<br><br><font size=3D"1"><span style=3D"font-fami=
ly:courier new,monospace">std::pair&lt;MyMapType::iterator, bool&gt; ins =
=3D myMap.insert(std::make_pair(k, v));<br></span></font></div><div><font s=
ize=3D"1"><span style=3D"font-family:courier new,monospace">std::cout &lt;&=
lt; (ins.second ? "new" : "old") &lt;&lt; ' ' ins.first-&gt;first &lt;&lt; =
',' &lt;&lt; ins.first-&gt;second &lt;&lt; std::endl;</span></font><br>

<br></div></div></div></div></blockquote><div>Yes, the first version is mor=
e readable. Yet it is more things to learn, remember, compile, implement, m=
aintain, document and standardize. It is not perfect but I do not think it =
is that bad.<br>&nbsp;</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"><div><div class=3D"gmail_quote"><div></div><div>And if funct=
ions like equal_range returned std::range_type instead of a pair, we could =
have range-based for working on it right now instead of maybe C++17.<br></d=
iv><div><br>I can't think of any use in the standard library that isn't wor=
se off for using pair instead of a dedicated type.<br clear=3D"all">

</div></div>-- <br>&nbsp;Nevin ":-)" Liber&nbsp; &lt;mailto:<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"IcPBnMiopNgJ" onmousedo=
wn=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javas=
cript:';return true;">ne...@eviloverlord.com</a><wbr>&gt;&nbsp; (847) 691-1=
404
</div></div>
</blockquote></div>

<p></p>

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

------=_Part_11_9981088.1391721252587--

.

------=_Part_53_11758645.1391723942136
Content-Type: text/plain; charset=UTF-8



On Thursday, February 6, 2014 8:02:08 PM UTC+1, Olaf van der Spek wrote:
>
> > pointer_from()
>
> Why not to_pointer()? We've already got to_string()
>
> > The initial thought was to have an explicit cast to a T* can cover both
> pointers and non-pointer contiguous
> iterators, but some people consider that going too far towards weakening
> the boundary between pointers
> and iterators.
>
> Could you provide a concrete problem case?
> I was kinda hoping for an implicit conversion to T*.
>

I believe I provided a concrete problem case: people like me could easily
get confused and forget iterators are not 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Thursday, February 6, 2014 8:02:08 PM UTC+1, Ol=
af van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">&gt; pointer_from()<div><br></div><div>Why not to_pointer()? We've=
 already got to_string()</div><div><br></div><div>&gt; The initial thought =
was to have an explicit cast to a T* can cover both pointers and non-pointe=
r contiguous&nbsp;</div><div>iterators, but some people consider that going=
 too far towards weakening the boundary between pointers&nbsp;</div><div>an=
d iterators.&nbsp;</div><div><br></div><div>Could you provide a concrete pr=
oblem case?</div><div>I was kinda hoping for an implicit conversion to T*.<=
/div></div></blockquote><div><br>I believe I provided a concrete problem ca=
se: people like me could easily get confused and forget iterators are not p=
ointers ;)<br>&nbsp;</div></div>

<p></p>

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

------=_Part_53_11758645.1391723942136--

.

------=_Part_501_10728857.1393154361112
Content-Type: text/plain; charset=UTF-8



On Thursday, February 6, 2014 8:02:08 PM UTC+1, Olaf van der Spek wrote:
>
> > pointer_from()
>
> Why not to_pointer()? We've already got to_string()
>
> > The initial thought was to have an explicit cast to a T* can cover both
> pointers and non-pointer contiguous
> iterators, but some people consider that going too far towards weakening
> the boundary between pointers
> and iterators.
>
> Could you provide a concrete problem case?
> I was kinda hoping for an implicit conversion to T*.
>

Nevin?

--

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

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

<div dir=3D"ltr"><br><br>On Thursday, February 6, 2014 8:02:08 PM UTC+1, Ol=
af van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">&gt; pointer_from()<div><br></div><div>Why not to_pointer()? We've=
 already got to_string()</div><div><br></div><div>&gt; The initial thought =
was to have an explicit cast to a T* can cover both pointers and non-pointe=
r contiguous&nbsp;</div><div>iterators, but some people consider that going=
 too far towards weakening the boundary between pointers&nbsp;</div><div>an=
d iterators.&nbsp;</div><div><br></div><div>Could you provide a concrete pr=
oblem case?</div><div>I was kinda hoping for an implicit conversion to T*.<=
/div></div></blockquote><div><br></div><div>Nevin?&nbsp;</div></div>

<p></p>

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

------=_Part_501_10728857.1393154361112--

.

--001a1134d69c9a800704f3680708
Content-Type: text/plain; charset=ISO-8859-1

On 23 February 2014 05:19, Olaf van der Spek <olafvdspek@gmail.com> wrote:

>
> I was kinda hoping for an implicit conversion to T*.
>

Below is the original reply (forwarded with permission) I got from Stephan
Lavavej when I posted my message on the internal LEWG reflector.

My own stance on this is I want a mechanism for converting a contiguous
iterator (including a one-past-the-end iterator) to a pointer w/o requiring
a range.  I'm willing to be very flexible on what that particular mechanism
is.
 Nevin :-)

---------- Forwarded message ----------
From: Stephan T. Lavavej <stl@exchange.microsoft.com>
Date: 17 January 2014 11:53
Subject: Re: Contiguous Iterators 0.1

[Nevin Liber]
> At long last, attached is my first stab at a contiguous iterator proposal.
> Comments, criticism and discussion are welcome.

> Contiguous iterators shall support explicit conversion to T*.

I am uncomfortable with weakening the boundary between iterators and
pointers here.

The Standard currently doesn't require iterators to be explicitly
convertible to T *, and indeed VC's contiguous iterators (vector, string,
array) are always class types that aren't explicitly convertible to T *.
Therefore, there can't be any existing code that depends on such explicit
conversions, so you can invent dedicated syntax.

I would *strongly* prefer to see a named, overloaded function for obtaining
raw pointers from contiguous iterators, e.g. pointer_from().

> but that is a lot of machinery to accomplish what can be spelled as
static_cast<T*>(i).

The machinery cost for implementers is irrelevant here - what matters is
safety and user syntax.

Observe that static_cast<T *>(iter), in addition to involving a cast (where
casts are notoriously potential sources of evil), is very verbose. That's
because most types are longer than T. Given a vector<pair<string,
shared_ptr<Thing>>>, saying static_cast<pair<string, shared_ptr<Thing>>
*>(iter) is obnoxious. This requires the user to specify a type that the
compiler already knows.

In contrast, pointer_from(iter) does not require the user to repeat the
type. I believe that this is overwhelmingly preferable.

Other than this, I like the proposal, and I think it's a valuable
contribution to the hierarchy of iterator powers.

Thanks,
STL
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

--001a1134d69c9a800704f3680708
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 23 February 2014 05:19, Olaf van der Spek <span dir=3D"=
ltr">&lt;<a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdsp=
ek@gmail.com</a>&gt;</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:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=
=3D"ltr"><br><div>I was kinda hoping for an implicit conversion to T*.</div=
></div>

</div></blockquote><div><br></div><div>Below is the original reply (forward=
ed with permission) I got from Stephan Lavavej when I posted my message on =
the internal LEWG reflector.<br><br>My own stance on this is I want a mecha=
nism for converting a contiguous iterator (including a one-past-the-end ite=
rator) to a pointer w/o requiring a range.=A0 I&#39;m willing to be very fl=
exible on what that particular mechanism is.<br>

</div><div>=A0Nevin :-)<br><br>---------- Forwarded message ----------<br>F=
rom: <b class=3D"gmail_sendername">Stephan T. Lavavej</b> <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:stl@exchange.microsoft.com">stl@exchange.microsoft.c=
om</a>&gt;</span><br>

Date: 17 January 2014 11:53<br>Subject: Re: Contiguous Iterators 0.1<br><br=
>[Nevin Liber]<br>
<div class=3D"">&gt; At long last, attached is my first stab at a contiguou=
s iterator proposal.<br>
&gt;=A0Comments, criticism and discussion are welcome.<br>
<br>
</div><div class=3D"">&gt; Contiguous iterators shall support explicit conv=
ersion to T*.<br>
<br>
</div>I am uncomfortable with weakening the boundary between iterators and =
pointers here.<br>
<br>
The Standard currently doesn&#39;t require iterators to be explicitly=20
convertible to T *, and indeed VC&#39;s contiguous iterators (vector,=20
string, array) are always class types that aren&#39;t explicitly convertibl=
e
 to T *. Therefore, there can&#39;t be any existing code that depends on=20
such explicit conversions, so you can invent dedicated syntax.<br>
<br>
I would *strongly* prefer to see a named, overloaded function for=20
obtaining raw pointers from contiguous iterators, e.g. pointer_from().<br>
<div class=3D""><br>
&gt; but that is a lot of machinery to accomplish what can be spelled as st=
atic_cast&lt;T*&gt;(i).<br>
<br>
</div>The machinery cost for implementers is irrelevant here - what matters=
 is safety and user syntax.<br>
<br>
Observe that static_cast&lt;T *&gt;(iter), in addition to involving a=20
cast (where casts are notoriously potential sources of evil), is very=20
verbose. That&#39;s because most types are longer than T. Given a=20
vector&lt;pair&lt;string, shared_ptr&lt;Thing&gt;&gt;&gt;, saying=20
static_cast&lt;pair&lt;string, shared_ptr&lt;Thing&gt;&gt; *&gt;(iter)=20
is obnoxious. This requires the user to specify a type that the compiler
 already knows.<br>
<br>
In contrast, pointer_from(iter) does not require the user to repeat the typ=
e. I believe that this is overwhelmingly preferable.<br>
<br>
Other than this, I like the proposal, and I think it&#39;s a valuable contr=
ibution to the hierarchy of iterator powers.<br>
<br>
Thanks,<br>
STL<br></div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a h=
ref=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.=
com</a>&gt;=A0 (847) 691-1404
</div></div>

<p></p>

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

--001a1134d69c9a800704f3680708--

.

------=_Part_2286_29177204.1393776331516
Content-Type: text/plain; charset=UTF-8

On Thursday, February 27, 2014 8:06:36 PM UTC+1, Nevin ":-)" Liber wrote:
>
> On 23 February 2014 05:19, Olaf van der Spek <olafv...@gmail.com<javascript:>
> > wrote:
>
>>
>> I was kinda hoping for an implicit conversion to T*.
>>
>
> Below is the original reply (forwarded with permission) I got from Stephan
> Lavavej when I posted my message on the internal LEWG reflector.
>
> My own stance on this is I want a mechanism for converting a contiguous
> iterator (including a one-past-the-end iterator) to a pointer w/o requiring
> a range.  I'm willing to be very flexible on what that particular mechanism
> is.
>
>
Thanks for forwarding.
My questions:

> pointer_from()

Why not to_pointer()? We've already got to_string()

Could you provide a concrete problem case?
I was kinda hoping for an implicit conversion to T*.

--

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

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

<div dir=3D"ltr">On Thursday, February 27, 2014 8:06:36 PM UTC+1, Nevin ":-=
)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">On 23 February 2014 05:19, Olaf van der Spek <span dir=3D"ltr">&lt;<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"qxCB6uFmVE0J" =
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">olafv...@gmail.com</a>&gt;</span> wrote:<br>=
<div><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=
=3D"ltr"><br><div>I was kinda hoping for an implicit conversion to T*.</div=
></div>

</div></blockquote><div><br></div><div>Below is the original reply (forward=
ed with permission) I got from Stephan Lavavej when I posted my message on =
the internal LEWG reflector.<br><br>My own stance on this is I want a mecha=
nism for converting a contiguous iterator (including a one-past-the-end ite=
rator) to a pointer w/o requiring a range.&nbsp; I'm willing to be very fle=
xible on what that particular mechanism is.<br>

</div><div><br></div></div></div></div></blockquote><div>&nbsp;</div><div>T=
hanks for forwarding.&nbsp;</div><div>My questions:</div><div><br></div>&gt=
; pointer_from()<div><br></div><div>Why not to_pointer()? We've already got=
 to_string()&nbsp;</div><div><br></div><div><div>Could you provide a concre=
te problem case?</div><div>I was kinda hoping for an implicit conversion to=
 T*.</div></div></div>

<p></p>

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

------=_Part_2286_29177204.1393776331516--

.

------=_Part_390_27269632.1405094071792
Content-Type: text/plain; charset=UTF-8

Hi,

What's the status of this proposal?

--

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

------=_Part_390_27269632.1405094071792
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Hi,<div><br></div><div>What's the status of this proposal?</div></div>

<p></p>

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

------=_Part_390_27269632.1405094071792--

.

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

On 11 July 2014 10:54, Olaf van der Spek <olafvdspek@gmail.com> wrote:

> Hi,
>
> What's the status of this proposal?
>

A friend presented it for me in Issaquah, as I wasn't there to do so
myself.  I plan on writing rev 2 of the paper for Urbana.

LEWG was split on whether or not to change iterator_category.  After giving
this more thought, I now believe it is better to have either a distinct
type inside iterator_traits or a separate trait, as grafting it onto
iterator_category will break too much stuff.

std::pointer_from(i) will use ADL to perform an unqualified call to
do_pointer_from(i) (note: names still to be bikeshedded).

LEWG was also weakly in favor of checking that std::pointer_from(i)
compiles as the low level mechanism, and a trait built on top of that.

My opinion: checking if something compiles via SFINAE tricks makes usage
expert-only; the only thing worse is having two mechanisms to do the same
thing (adding a trait which presumably can be specialized), because then no
one knows the definitive way to check for contiguous iterators.  OTOH,
hopefully I'm just misreading the wiki notes and votes.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr">On 11 July 2014 10:54, Olaf van der Spek <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@g=
mail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi,<div><br></div><div>What=
&#39;s the status of this proposal?</div></div></blockquote><div><br></div>=
<div>

A friend presented it for me in Issaquah, as I wasn&#39;t there to do so my=
self. =C2=A0I plan on writing rev 2 of the paper for Urbana.</div><div><br>=
</div><div>LEWG was split on whether or not to change iterator_category. =
=C2=A0After giving this more thought, I now believe it is better to have ei=
ther a distinct type inside iterator_traits or a separate trait, as graftin=
g it onto iterator_category will break too much stuff.</div>

<div><br></div><div>std::pointer_from(i) will use ADL to perform an unquali=
fied call to do_pointer_from(i) (note: names still to be bikeshedded).</div=
><div><br></div><div>LEWG was also weakly in favor of checking that std::po=
inter_from(i) compiles as the low level mechanism, and a trait built on top=
 of that.</div>

<div><br></div><div>My opinion: checking if something compiles via SFINAE t=
ricks makes usage expert-only; the only thing worse is having two mechanism=
s to do the same thing (adding a trait which presumably can be specialized)=
, because then no one knows the definitive way to check for contiguous iter=
ators. =C2=A0OTOH, hopefully I&#39;m just misreading the wiki notes and vot=
es.</div>

<div>--=C2=A0<br></div></div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;ma=
ilto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evil=
overlord.com</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

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

--f46d043c7f187869d804fe2cdb61--

.