------=_Part_2592_24689219.1396833801460
Content-Type: text/plain; charset=UTF-8

C++11 added vector::data to get a raw pointer to the first element in the
vector. Which is great as now you don't have to write &vec.front( ) or
similar.

So how about a pointer to the end of the data, or one past the end? Well it
looks like we're stuck with &vec.back( ) + 1, or vec.data( ) + vec.size( ),
or ....

So give vector::front, vector::back and vector::begin( ), vector::end( )
why only a vector::data. Maybe vector::begin_data( ) and vector::end_data()
would have been more consistent. Anyway whatever it's called a single
method to get either a pointer to the last element or a one past the last
element would be nice.

I am motivated here by a number of C mathematical functions I am calling
that take start and one past the end pointer to input data.

David

--

---
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_2592_24689219.1396833801460
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">C++11 added vector::data to get a raw pointer to the first=
 element in the vector. Which is great as now you don't have to write &amp;=
vec.front( ) or similar.<br><br>So how about a pointer to the end of the da=
ta, or one past the end? Well it looks like we're stuck with &amp;vec.back(=
 ) + 1, or vec.data( ) + vec.size( ), or .... <br><br>So give vector::front=
, vector::back and vector::begin( ), vector::end( ) why only a vector::data=
.. Maybe vector::begin_data( ) and vector::end_data() would have been more c=
onsistent. Anyway whatever it's called a single method to get either a poin=
ter to the last element or a one past the last element would be nice.<br><b=
r>I am motivated here by a number of C mathematical functions I am calling =
that take start and one past the end pointer to input data.<br><br>David<br=
></div>

<p></p>

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

------=_Part_2592_24689219.1396833801460--

.

Em dom 06 abr 2014, =E0s 18:23:21, David Hunter escreveu:
> C++11 added vector::data to get a raw pointer to the first element in the
> vector. Which is great as now you don't have to write &vec.front( ) or
> similar.
>=20
> So how about a pointer to the end of the data, or one past the end? Well =
it
> looks like we're stuck with &vec.back( ) + 1, or vec.data( ) + vec.size( =
),
> or ....

While it would be convenient to have such a method, vec.data() + vec.size()=
 is=20
the answer you're looking for.

There are two possible implementations of such an end_data() method, depend=
ing=20
on what the vector implementation stores internally:

- if it stores begin + size pointers, the implementation would be:
 T *end_data() const { return data() + size(); }
  which is what your code is doing

- if it stores begin and end pointers, the implementation would be:
 T *end_data() const { return m_end_data; }
 size_t size() const { return m_end_data - m_begin_data; }
  which means your code of vec.begin() + vec.size() gets optimised to=20
  m_end_data anyway

So this function would be convenience, but no optimisation.

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

--=20

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

.

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

There is no performance advantage either in providing 'data()' from doing
'vector.empty()? 0 : &vector.front()', or 'vector.empty()? 0 :
&*vector.begin()'.

The question, I understood, is more of a style than an implementation. Of
course in this case the difference in style is lesser (since the
conditional is already handled inside 'data()' and need not be replicated,
so it might not be worth it, but it should not only be considered in terms
of performance.


On Mon, Apr 7, 2014 at 12:01 AM, Thiago Macieira <thiago@macieira.org>wrote=
:

> Em dom 06 abr 2014, =E0s 18:23:21, David Hunter escreveu:
> > C++11 added vector::data to get a raw pointer to the first element in t=
he
> > vector. Which is great as now you don't have to write &vec.front( ) or
> > similar.
> >
> > So how about a pointer to the end of the data, or one past the end? Wel=
l
> it
> > looks like we're stuck with &vec.back( ) + 1, or vec.data( ) + vec.size=
(
> ),
> > or ....
>
> While it would be convenient to have such a method, vec.data() +
> vec.size() is
> the answer you're looking for.
>
> There are two possible implementations of such an end_data() method,
> depending
> on what the vector implementation stores internally:
>
> - if it stores begin + size pointers, the implementation would be:
>         T *end_data() const { return data() + size(); }
>   which is what your code is doing
>
> - if it stores begin and end pointers, the implementation would be:
>         T *end_data() const { return m_end_data; }
>         size_t size() const { return m_end_data - m_begin_data; }
>   which means your code of vec.begin() + vec.size() gets optimised to
>   m_end_data anyway
>
> So this function would be convenience, but no optimisation.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr">There is no performance advantage either in providing &#39=
;data()&#39; from doing &#39;vector.empty()? 0 : &amp;vector.front()&#39;, =
or &#39;vector.empty()? 0 : &amp;*vector.begin()&#39;.<br><br>The question,=
 I understood, is more of a style than an implementation. Of course in this=
 case the difference in style is lesser (since the conditional is already h=
andled inside &#39;data()&#39; and need not be replicated, so it might not =
be worth it, but it should not only be considered in terms of performance.<=
br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon,=
 Apr 7, 2014 at 12:01 AM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"=
mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Em dom 06 abr 2014, =E0s 18:23:21, David Hun=
ter escreveu:<br>
<div class=3D"">&gt; C++11 added vector::data to get a raw pointer to the f=
irst element in the<br>
&gt; vector. Which is great as now you don&#39;t have to write &amp;vec.fro=
nt( ) or<br>
&gt; similar.<br>
&gt;<br>
&gt; So how about a pointer to the end of the data, or one past the end? We=
ll it<br>
&gt; looks like we&#39;re stuck with &amp;vec.back( ) + 1, or vec.data( ) +=
 vec.size( ),<br>
&gt; or ....<br>
<br>
</div>While it would be convenient to have such a method, vec.data() + vec.=
size() is<br>
the answer you&#39;re looking for.<br>
<br>
There are two possible implementations of such an end_data() method, depend=
ing<br>
on what the vector implementation stores internally:<br>
<br>
- if it stores begin + size pointers, the implementation would be:<br>
=A0 =A0 =A0 =A0 T *end_data() const { return data() + size(); }<br>
=A0 which is what your code is doing<br>
<br>
- if it stores begin and end pointers, the implementation would be:<br>
=A0 =A0 =A0 =A0 T *end_data() const { return m_end_data; }<br>
=A0 =A0 =A0 =A0 size_t size() const { return m_end_data - m_begin_data; }<b=
r>
=A0 which means your code of vec.begin() + vec.size() gets optimised to<br>
=A0 m_end_data anyway<br>
<br>
So this function would be convenience, but no optimisation.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=A0 =A0Software Architect - Intel Open Source Technology Center<br>
=A0 =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=A0 =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a11c1e0fcab89c804f676053b--

.

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

On Monday, April 7, 2014 12:04:28 PM UTC-4, David Rodr=C3=ADguez Ibeas wrot=
e:
>
> There is no performance advantage either in providing 'data()' from doing=
=20
> 'vector.empty()? 0 : &vector.front()', or 'vector.empty()? 0 :=20
> &*vector.begin()'.
>

Yes there is.  It eliminates a check to see if the vector is empty.
=20

> The question, I understood, is more of a style than an implementation. Of=
=20
> course in this case the difference in style is lesser (since the=20
> conditional is already handled inside 'data()' and need not be replicated=
,=20
> so it might not be worth it, but it should not only be considered in term=
s=20
> of performance.
>

There is no conditional in std::vector::data().  It simply returns the=20
pointer to the internal array storage.

--=20

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

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

<div dir=3D"ltr">On Monday, April 7, 2014 12:04:28 PM UTC-4, David Rodr=C3=
=ADguez Ibeas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">There is no performance advantage either in providing 'data()' fro=
m doing 'vector.empty()? 0 : &amp;vector.front()', or 'vector.empty()? 0 : =
&amp;*vector.begin()'.<br></div></blockquote><div><br></div><div>Yes there =
is. &nbsp;It eliminates a check to see if the vector is empty.</div><div>&n=
bsp;</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">The=
 question, I understood, is more of a style than an implementation. Of cour=
se in this case the difference in style is lesser (since the conditional is=
 already handled inside 'data()' and need not be replicated, so it might no=
t be worth it, but it should not only be considered in terms of performance=
..<br></div></blockquote><div><br></div><div>There is no conditional in std:=
:vector::data(). &nbsp;It simply returns the pointer to the internal array =
storage.</div><div><br></div></div>

<p></p>

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

------=_Part_162_2358190.1396895399358--

.

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

Fine, but that is still missing the point. There are proposed changes and
changes that went into the standard that are just stylistic. Consider a
different case:

vector<T>::cbegin() vs. casting to 'const vector<T>&' and calling 'begin()'

No performance there. Same comment as in previous message: this is a
different level of improvement in style, 'data()+size()' is not as ugly as
the cast above.


On Mon, Apr 7, 2014 at 2:29 PM, Greg Marr <gregmmarr@gmail.com> wrote:

> On Monday, April 7, 2014 12:04:28 PM UTC-4, David Rodr=EDguez Ibeas wrote=
:
>>
>> There is no performance advantage either in providing 'data()' from doin=
g
>> 'vector.empty()? 0 : &vector.front()', or 'vector.empty()? 0 :
>> &*vector.begin()'.
>>
>
> Yes there is.  It eliminates a check to see if the vector is empty.
>
>
>> The question, I understood, is more of a style than an implementation. O=
f
>> course in this case the difference in style is lesser (since the
>> conditional is already handled inside 'data()' and need not be replicate=
d,
>> so it might not be worth it, but it should not only be considered in ter=
ms
>> of performance.
>>
>
> There is no conditional in std::vector::data().  It simply returns the
> pointer to the internal array storage.
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr">Fine, but that is still missing the point. There are propo=
sed changes and changes that went into the standard that are just stylistic=
.. Consider a different case:=A0<br><br>vector&lt;T&gt;::cbegin() vs. castin=
g to &#39;const vector&lt;T&gt;&amp;&#39; and calling &#39;begin()&#39;<br>
<br>No performance there. Same comment as in previous message: this is a di=
fferent level of improvement in style, &#39;data()+size()&#39; is not as ug=
ly as the cast above.</div><div class=3D"gmail_extra"><br><br><div class=3D=
"gmail_quote">
On Mon, Apr 7, 2014 at 2:29 PM, Greg Marr <span dir=3D"ltr">&lt;<a href=3D"=
mailto:gregmmarr@gmail.com" target=3D"_blank">gregmmarr@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"">On Monday, April 7, 2014 12:04:28 PM UTC-4=
, David Rodr=EDguez Ibeas wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">
There is no performance advantage either in providing &#39;data()&#39; from=
 doing &#39;vector.empty()? 0 : &amp;vector.front()&#39;, or &#39;vector.em=
pty()? 0 : &amp;*vector.begin()&#39;.<br></div></blockquote><div><br></div>
</div><div>Yes there is. =A0It eliminates a check to see if the vector is e=
mpty.</div><div class=3D""><div>=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex">
<div dir=3D"ltr">The question, I understood, is more of a style than an imp=
lementation. Of course in this case the difference in style is lesser (sinc=
e the conditional is already handled inside &#39;data()&#39; and need not b=
e replicated, so it might not be worth it, but it should not only be consid=
ered in terms of performance.<br>
</div></blockquote><div><br></div></div><div>There is no conditional in std=
::vector::data(). =A0It simply returns the pointer to the internal array st=
orage.</div><div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

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

<p></p>

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

--001a11c136a4b23d4004f6783262--

.

------=_Part_3452_7545789.1396899987453
Content-Type: text/plain; charset=UTF-8

Just to clarify my main issue was more obvious user code rather than
efficiency. I'm sure a good compiler would optimize vec.data( ) + vec.end(
) to be the same as vec.end_data( ). I guess it depends on the
implementation of vector, as mentioned by Tiago earlier, which as a user of
vector I don't care about. I suspect a vec::end_data would never end up
being less efficient than vec.data( ) + vec.end( ) or friends.

If we don't care about simpler user code why add vec.data()? &vec.front()
or equivalents work just as well. Given the following

c_func( &vec.front( ), &vec.end( ) + 1 );
c_func( vec.data( ), vec.data() + vec.size( ) );
c_func( vec.begin_data( ), vec.end_data( ) );

or maybe, the following if we follow the begin/end free functions to allow
any data type that can produce a raw begin and end pointer.

c_func( begin_data( stuff ), end_data( stuff ) );

I find the latter more obvious.I implement the free functions above in my
own code and they seem to work nicely.




--

---
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_3452_7545789.1396899987453
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Just to clarify my main issue was more obvious user code r=
ather than efficiency. I'm sure a good compiler would optimize vec.data( ) =
+ vec.end( ) to be the same as vec.end_data( ). I guess it depends on the i=
mplementation of vector, as mentioned by Tiago earlier, which as a user of =
vector I don't care about. I suspect a vec::end_data would never end up bei=
ng less efficient than vec.data( ) + vec.end( ) or friends.<br><br>If we do=
n't care about simpler user code why add vec.data()? &amp;vec.front() or eq=
uivalents work just as well. Given the following<br><br>c_func( &amp;vec.fr=
ont( ), &amp;vec.end( ) + 1 );<br>c_func( vec.data( ), vec.data() + vec.siz=
e( ) );<br>c_func( vec.begin_data( ), vec.end_data( ) );<br><br>or maybe, t=
he following if we follow the begin/end free functions to allow any data ty=
pe that can produce a raw begin and end pointer.<br><br>c_func( begin_data(=
 stuff ), end_data( stuff ) );<br><br>I find the latter more obvious.I impl=
ement the free functions above in my own code and they seem to work nicely.=
<br><br><br><br><br></div>

<p></p>

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

------=_Part_3452_7545789.1396899987453--

.

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

On 7 April 2014 14:46, David Hunter <davidhunter22@gmail.com> wrote:

> Just to clarify my main issue was more obvious user code rather than
> efficiency. I'm sure a good compiler would optimize vec.data( ) + vec.end(
> ) to be the same as vec.end_data( ). I guess it depends on the
> implementation of vector, as mentioned by Tiago earlier, which as a user of
> vector I don't care about. I suspect a vec::end_data would never end up
> being less efficient than vec.data( ) + vec.end( ) or friends.
>
> If we don't care about simpler user code why add vec.data()? &vec.front()
> or equivalents work just as well. Given the following
>
> c_func( &vec.front( ), &vec.end( ) + 1 );
>

You probably meant &vec.back() + 1.  Unfortunately, that expression depends
on the precondition !vec.empty().  Much prefer:


> c_func( vec.data( ), vec.data() + vec.size( ) );
>

As mentioned earlier, this is the safe way to do it which doesn't depend on
a precondition.

I don't see half-open ranges showing up all that much in C.  And it will
lead to endless confusion in something like std::string, as it will not
include the trailing '\0'.  I'd be neutral  to weakly against it.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr">On 7 April 2014 14:46, David Hunter <span dir=3D"ltr">&lt;=
<a href=3D"mailto:davidhunter22@gmail.com" target=3D"_blank">davidhunter22@=
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:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Just to clarify my main iss=
ue was more obvious user code rather than efficiency. I&#39;m sure a good c=
ompiler would optimize vec.data( ) + vec.end( ) to be the same as vec.end_d=
ata( ). I guess it depends on the implementation of vector, as mentioned by=
 Tiago earlier, which as a user of vector I don&#39;t care about. I suspect=
 a vec::end_data would never end up being less efficient than vec.data( ) +=
 vec.end( ) or friends.<br>

<br>If we don&#39;t care about simpler user code why add vec.data()? &amp;v=
ec.front() or equivalents work just as well. Given the following<br><br>c_f=
unc( &amp;vec.front( ), &amp;vec.end( ) + 1 );<br></div></blockquote><div>

<br></div><div>You probably meant &amp;vec.back() + 1. =A0Unfortunately, th=
at expression depends on the precondition !vec.empty(). =A0Much prefer:</di=
v><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">c_func( vec.data( ), vec.data() + vec.size( ) );<br></div>=
</blockquote><div><br></div><div>As mentioned earlier, this is the safe way=
 to do it which doesn&#39;t depend on a precondition.</div><div>=A0</div><d=
iv>

I don&#39;t see half-open ranges showing up all that much in C. =A0And it w=
ill lead to endless confusion in something like std::string, as it will not=
 include the trailing &#39;\0&#39;. =A0I&#39;d be neutral =A0to weakly agai=
nst it.</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 />
<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 />

--047d7b3a8d6a2b9dc004f6794ac2--

.

Em seg 07 abr 2014, =C3=A0s 11:29:59, Greg Marr escreveu:
> On Monday, April 7, 2014 12:04:28 PM UTC-4, David Rodr=C3=ADguez Ibeas wr=
ote:
> > There is no performance advantage either in providing 'data()' from doi=
ng
> > 'vector.empty()? 0 : &vector.front()', or 'vector.empty()? 0 :
> > &*vector.begin()'.
>=20
> Yes there is.  It eliminates a check to see if the vector is empty.

The check is not necessary because:

> There is no conditional in std::vector::data().  It simply returns the
> pointer to the internal array storage.

end =3D begin + size
size =3D 0
=E2=88=B4 end =3D=3D begin

and when you have a range of [begin, end) with begin =3D=3D end, the range =
is=20
empty, no matter what the value of begin is. You don't need to perform any=
=20
checks.

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

--=20

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

.

Em seg 07 abr 2014, =E0s 14:57:42, Nevin Liber escreveu:
> I don't see half-open ranges showing up all that much in C.  And it will
> lead to endless confusion in something like std::string, as it will not
> include the trailing '\0'.  I'd be neutral  to weakly against it.

True, but very often the API is derived from C++ needs and it ends up using=
=20
half-open ranges as parameters.

For example, for QString (a vector of QChar), there are just as many intern=
al=20
functions taking begin & size as there are functions taking begin & end. It=
=20
often boils down to who wrote the code, what was most optimal at the time o=
f=20
writing, and what how much refactoring the code has gone through.

And FYI, neither QString, nor QByteArray, nor QVector provide an "end_data"=
=20
pointer API. We either do data() + size(), or we "abuse" the knowledge the=
=20
iterator for those three classes is just a pointer, so begin() and end() se=
rve=20
the same purpose.

QString, QByteArray, QVector::data have been available since Qt 3. It's=20
extremely useful to tell QByteArray to allocate N bytes, pass the data poin=
ter=20
to a C function for filling in, then returning the array.

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

--=20

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

.

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

On Monday, April 7, 2014 2:40:13 PM UTC-4, David Rodr=C3=ADguez Ibeas wrote=
:
>
> Fine, but that is still missing the point.
>

No, it's not.

There are proposed changes and changes that went into the standard that are=
=20
> just stylistic.
>

The data() function is not stylistic.  It provides a capability that you=20
could not have before, which is to get a pointer to the internal array=20
without first checking to see if the vector is empty.

Consider a different case:=20
>
> vector<T>::cbegin() vs. casting to 'const vector<T>&' and calling 'begin(=
)'
>
No performance there. Same comment as in previous message: this is a=20
> different level of improvement in style, 'data()+size()' is not as ugly a=
s=20
> the cast above.
>

That is an extremely different level.  There is really no comparison=20
between adding v.cbegin() to replace (static_cast<vector<std::vector<std::w=
string>>=20
&>(v)).begin(); and adding v.end_data() to replace v.data() + v.size()

--=20

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

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

<div dir=3D"ltr">On Monday, April 7, 2014 2:40:13 PM UTC-4, David Rodr=C3=
=ADguez Ibeas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Fine, but that is still missing the point.</div></blockquote><div>=
<br></div><div>No, it's not.</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"> There are proposed changes and changes=
 that went into the standard that are just stylistic.</div></blockquote><di=
v><br></div><div>The data() function is not stylistic. &nbsp;It provides a =
capability that you could not have before, which is to get a pointer to the=
 internal array without first checking to see if the vector is empty.</div>=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"> Consider a different case:&nbsp;<br><br>vector&lt;T&gt;::cbegin() vs. ca=
sting to 'const vector&lt;T&gt;&amp;' and calling 'begin()'<br></div></bloc=
kquote><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">No per=
formance there. Same comment as in previous message: this is a different le=
vel of improvement in style, 'data()+size()' is not as ugly as the cast abo=
ve.</div></blockquote><div><br></div><div>That is an extremely different le=
vel. &nbsp;There is really no comparison between adding&nbsp;<span style=3D=
"font-size: 13px;">v.cbegin() to replace </span><span style=3D"font-size: 1=
3px;">(static_cast&lt;vector&lt;std::vector&lt;std::wstring&gt;&gt; &amp;&g=
t;(v)).begin();&nbsp;</span><span style=3D"font-size: 13px;">and adding&nbs=
p;</span><span style=3D"font-size: 13px;">v.end_data() to replace v.data() =
+ v.size()</span></div><div><span style=3D"font-size: 13px;"><br></span></d=
iv></div>

<p></p>

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

------=_Part_1560_17275254.1396905999684--

.

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

On Monday, April 7, 2014 4:33:50 PM UTC-4, Thiago Macieira wrote:
>
> Em seg 07 abr 2014, =C3=A0s 11:29:59, Greg Marr escreveu:=20
> > On Monday, April 7, 2014 12:04:28 PM UTC-4, David Rodr=C3=ADguez Ibeas =
wrote:=20
> > > There is no performance advantage either in providing 'data()' from=
=20
> doing=20
> > > 'vector.empty()? 0 : &vector.front()', or 'vector.empty()? 0 :=20
> > > &*vector.begin()'.=20
> >=20
> > Yes there is.  It eliminates a check to see if the vector is empty.=20
>
> The check is not necessary because:=20
>
> > There is no conditional in std::vector::data().  It simply returns the=
=20
> > pointer to the internal array storage.=20
>
> end =3D begin + size=20
> size =3D 0=20
> =E2=88=B4 end =3D=3D begin=20
>
> and when you have a range of [begin, end) with begin =3D=3D end, the rang=
e is=20
> empty, no matter what the value of begin is. You don't need to perform an=
y=20
> checks.=20
>

Yes, exactly, data() is a performance advantage because it eliminates an=20
unnecessary test for the vector being empty when working with either half=
=20
empty ranges or start plus size, and that's why adding it was more than=20
just stylistic.

--=20

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

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

<div dir=3D"ltr">On Monday, April 7, 2014 4:33:50 PM UTC-4, Thiago Macieira=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em seg 07 abr 2014, =C3=
=A0s 11:29:59, Greg Marr escreveu:
<br>&gt; On Monday, April 7, 2014 12:04:28 PM UTC-4, David Rodr=C3=ADguez I=
beas wrote:
<br>&gt; &gt; There is no performance advantage either in providing 'data()=
' from doing
<br>&gt; &gt; 'vector.empty()? 0 : &amp;vector.front()', or 'vector.empty()=
? 0 :
<br>&gt; &gt; &amp;*vector.begin()'.
<br>&gt;=20
<br>&gt; Yes there is. &nbsp;It eliminates a check to see if the vector is =
empty.
<br>
<br>The check is not necessary because:
<br>
<br>&gt; There is no conditional in std::vector::data(). &nbsp;It simply re=
turns the
<br>&gt; pointer to the internal array storage.
<br>
<br>end =3D begin + size
<br>size =3D 0
<br>=E2=88=B4 end =3D=3D begin
<br>
<br>and when you have a range of [begin, end) with begin =3D=3D end, the ra=
nge is=20
<br>empty, no matter what the value of begin is. You don't need to perform =
any=20
<br>checks.
<br></blockquote><div><br></div><div>Yes, exactly, data() is a performance =
advantage because it eliminates an unnecessary test for the vector being em=
pty when working with either half empty ranges or start plus size, and that=
's why adding it was more than just stylistic.</div><div><br></div></div>

<p></p>

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

------=_Part_280_30424213.1396906543766--

.

------=_Part_3745_9026460.1396906723395
Content-Type: text/plain; charset=UTF-8

On Monday, April 7, 2014 5:26:39 PM UTC-4, Greg Marr wrote:
>
> Consider a different case:
>>
>> vector<T>::cbegin() vs. casting to 'const vector<T>&' and calling
>> 'begin()'
>>
> No performance there. Same comment as in previous message: this is a
>> different level of improvement in style, 'data()+size()' is not as ugly as
>> the cast above.
>>
>
> That is an extremely different level.  There is really no comparison
> between adding v.cbegin() to replace (static_cast<vector<std::vector<std::wstring>>
> &>(v)).begin(); and adding v.end_data() to replace v.data() + v.size()
>

especially since I forgot the "const" in the cast, and so in the end,
didn't even end up getting the same thing as cbegin(), and didn't notice
until my third or fourth time reading the code.  :)

--

---
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_3745_9026460.1396906723395
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, April 7, 2014 5:26:39 PM UTC-4, Greg Marr wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><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">Consider a different case:&nbs=
p;<br><br>vector&lt;T&gt;::cbegin() vs. casting to 'const vector&lt;T&gt;&a=
mp;' and calling 'begin()'<br></div></blockquote><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">No performance there. Same comment as in pre=
vious message: this is a different level of improvement in style, 'data()+s=
ize()' is not as ugly as the cast above.</div></blockquote><div><br></div><=
div>That is an extremely different level. &nbsp;There is really no comparis=
on between adding&nbsp;<span style=3D"font-size:13px">v.cbegin() to replace=
 </span><span style=3D"font-size:13px">(static_cast&lt;vector&lt;std::<wbr>=
vector&lt;std::wstring&gt;&gt; &amp;&gt;(v)).begin();&nbsp;</span><span sty=
le=3D"font-size:13px">and adding&nbsp;</span><span style=3D"font-size:13px"=
>v.end_data() to replace v.data() + v.size()</span></div></div></blockquote=
><div><br></div><div>especially since I forgot the "const" in the cast, and=
 so in the end, didn't even end up getting the same thing as cbegin(), and =
didn't notice until my third or fourth time reading the code. &nbsp;:)</div=
><div><br></div></div>

<p></p>

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

------=_Part_3745_9026460.1396906723395--

.

Em seg 07 abr 2014, =C3=A0s 14:35:43, Greg Marr escreveu:
> > The check is not necessary because:=20
> >=20
> > > There is no conditional in std::vector::data().  It simply returns th=
e=20
> > > pointer to the internal array storage.=20
> >=20
> > end =3D begin + size=20
> > size =3D 0=20
> > =E2=88=B4 end =3D=3D begin=20
> >=20
> > and when you have a range of [begin, end) with begin =3D=3D end, the ra=
nge is=20
> > empty, no matter what the value of begin is. You don't need to perform
> > any=20
> > checks.=20
>=20
> Yes, exactly, data() is a performance advantage because it eliminates an=
=20
> unnecessary test for the vector being empty when working with either half=
=20
> empty ranges or start plus size, and that's why adding it was more than=
=20
> just stylistic.

Sorry, I think I had misunderstood you.

Yes, data() is a performance advantage, since you can't call front() or=20
*begin() on an empty container.

My point is that end_data() is not a performance advantage. It's just=20
syntactic sugar.

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

--=20

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

.

------=_Part_393_20075703.1396918439066
Content-Type: text/plain; charset=UTF-8

Actually the comment about performance with a empty vector made me look at
the standard. I can see the following








*23.3.6.4 vector data [vector.data]T* data() noexcept;const T* data() const
noexcept;1Returns: A pointer such that [data(),data() + size()) is a valid
range. For a non-empty vector,data() == &front().2Complexity: Constant
time.*

So my question is what does this mean for an empty vector.

I am wondering if there is any guarantee that the data function never
returns nullptr. My understanding of the standard is that adding 0 to a
nullptr is valid and you get a nullptr.
*S*o [data(),data() + size()) would be two nullptrs. I did a seach for
"valid range" in the standard and it doesn't seem to be defined. Maybe the
"A pointer" implies a non nullptr but I couldn't find anywhere in the
standard where it says "A pointer" must not be a nullptr.

David

--

---
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_393_20075703.1396918439066
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Actually the comment about performance with a empty vector=
 made me look at the standard. I can see the following <br><br><i>23.3.6.4 =
vector data [vector.data]<br>T* data() noexcept;<br>const T* data() const n=
oexcept;<br>1<br>Returns: A pointer such that [data(),data() + size()) is a=
 valid range. For a non-empty vector,<br>data() =3D=3D &amp;front().<br>2<b=
r>Complexity: Constant time.</i><br><br>So my question is what does this me=
an for an empty vector.<br><br>I am wondering if there is any guarantee tha=
t the data function never returns nullptr. My understanding of the standard=
 is that adding 0 to a nullptr is valid and you get a nullptr.<br><i>S</i>o=
 [data(),data() + size()) would be two nullptrs. I did a seach for "valid r=
ange" in the standard and it doesn't seem to be defined. Maybe the "A point=
er" implies a non nullptr but I couldn't find anywhere in the standard wher=
e it says "A pointer" must not be a nullptr.<br><br>David<br><i></i></div>

<p></p>

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

------=_Part_393_20075703.1396918439066--

.

Em seg 07 abr 2014, =E0s 17:53:58, David Hunter escreveu:
> Actually the comment about performance with a empty vector made me look a=
t
> the standard. I can see the following
>=20
> *23.3.6.4 vector data [vector.data]T* data() noexcept;const T* data() con=
st
> noexcept;1Returns: A pointer such that [data(),data() + size()) is a vali=
d
> range. For a non-empty vector,data() =3D=3D &front().2Complexity: Constan=
t
> time.*
>=20
> So my question is what does this mean for an empty vector.
>=20
> I am wondering if there is any guarantee that the data function never
> returns nullptr. My understanding of the standard is that adding 0 to a
> nullptr is valid and you get a nullptr.

There's no guarantee that I can see, either. It can return anything it want=
s=20
if the size is zero. The range [x, x) is empty for all x. You can't do *x i=
n=20
that case, just like you can't do *end().

I would recommend that implementations not return null there, just so=20
applications don't get in the habit of checking data() =3D=3D nullptr to te=
st if=20
the array is empty. At the same time, they should return an address that wi=
ll=20
cause a segmentation fault if dereferenced, to catch applications that try =
to=20
dereference everything.

For example: it can return (T*) alignof(T).

> *S*o [data(),data() + size()) would be two nullptrs. I did a seach for
> "valid range" in the standard and it doesn't seem to be defined. Maybe th=
e
> "A pointer" implies a non nullptr but I couldn't find anywhere in the
> standard where it says "A pointer" must not be a nullptr.

I don't see why it would have to be non-null.

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

--=20

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

.

------=_Part_463_25899.1396919862047
Content-Type: text/plain; charset=UTF-8

On Monday, April 7, 2014 7:01:27 PM UTC-4, Thiago Macieira wrote:
>
> Sorry, I think I had misunderstood you.
>
> Yes, data() is a performance advantage, since you can't call front() or
> *begin() on an empty container.
>
> My point is that end_data() is not a performance advantage. It's just
> syntactic sugar.
>

Yes, we are in agreement on both points.

--

---
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_463_25899.1396919862047
Content-Type: text/html; charset=UTF-8

<div dir="ltr">On Monday, April 7, 2014 7:01:27 PM UTC-4, Thiago Macieira wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Sorry, I think I had misunderstood you.
<br>
<br>Yes, data() is a performance advantage, since you can't call front() or
<br>*begin() on an empty container.
<br>
<br>My point is that end_data() is not a performance advantage. It's just
<br>syntactic sugar.
<br></blockquote><div><br></div><div>Yes, we are in agreement on both points.</div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&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_463_25899.1396919862047--

.

------=_Part_410_33240901.1396920160094
Content-Type: text/plain; charset=UTF-8

On Monday, April 7, 2014 8:53:58 PM UTC-4, David Hunter wrote:
>
> Actually the comment about performance with a empty vector made me look at
> the standard.
>


> So my question is what does this mean for an empty vector.
>

In general, if the vector has always been empty, it will return nullptr,
but if the vector is empty because it had data and has been resized to be
empty, it will return the pointer to the allocated array.  In neither case
are you allowed to dereference the pointer, because the size is zero.

I am wondering if there is any guarantee that the data function never
> returns nullptr.
>

It is perfectly valid to return nullptr, so there is no such guarantee.


> My understanding of the standard is that adding 0 to a nullptr is valid
> and you get a nullptr.
> *S*o [data(),data() + size()) would be two nullptrs.
>

That's correct, and this call will be perfectly valid on that range:

for_each(data(), data() + size(), [](auto x) { cout << x; });

--

---
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_410_33240901.1396920160094
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, April 7, 2014 8:53:58 PM UTC-4, David Hunter wr=
ote:<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">Actually =
the comment about performance with a empty vector made me look at the stand=
ard.</div></blockquote><div>&nbsp;</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr">So my question is what does this mean for an emp=
ty vector.<br></div></blockquote><div><br></div><div>In general, if the vec=
tor has always been empty, it will return nullptr, but if the vector is emp=
ty because it had data and has been resized to be empty, it will return the=
 pointer to the allocated array. &nbsp;In neither case are you allowed to d=
ereference the pointer, because the size is zero.</div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I am wondering if =
there is any guarantee that the data function never returns nullptr.</div><=
/blockquote><div><br></div><div>It is perfectly valid to return nullptr, so=
 there is no such guarantee.</div><div>&nbsp;</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"> My understanding of the standard is =
that adding 0 to a nullptr is valid and you get a nullptr.<br><i>S</i>o [da=
ta(),data() + size()) would be two nullptrs.</div></blockquote><div><br></d=
iv><div>That's correct, and this call will be perfectly valid on that range=
:</div><div><br></div><div>for_each(data(), data() + size(), [](auto x) { c=
out &lt;&lt; x; });</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><i></i></div></blockquote></div>

<p></p>

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

------=_Part_410_33240901.1396920160094--

.

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

Range is a general concept represented by a pair of similar-type iterators
as its bounds; Validity of  a range implies the validity of its bounds, but
not just that; a valid range must not be empty. in case of using pointers
as iterators, validity if iterators means none-null pointers, since
validity of a pointer **does mean** the validity of what it points to, and
nullptr is pointing to somewhere that is not supposed to contain anything.
So i don`t see any reason to emphasize that nullptr  is invalid.

By this observation, we can see that if 'size()' equals to 0,then
*[data(),data()
+ size()) *is an invalid range regardless of validity of 'data().So my
understanding is that, although an implementation might be allowed to
return a none-null pointer as its 'data()' when the vector is empty,
validity of the range can be checked via comparing its bounds which is
implicitly achieved in any 'for' based iterative algorithm.

regards,
FM.


On Tue, Apr 8, 2014 at 5:23 AM, David Hunter <davidhunter22@gmail.com>wrote:

> Actually the comment about performance with a empty vector made me look at
> the standard. I can see the following
>
>
>
>
>
>
>
>
> *23.3.6.4 vector data [vector.data]T* data() noexcept;const T* data()
> const noexcept;1Returns: A pointer such that [data(),data() + size()) is a
> valid range. For a non-empty vector,data() == &front(). 2Complexity:
> Constant time.*
>
> So my question is what does this mean for an empty vector.
>
> I am wondering if there is any guarantee that the data function never
> returns nullptr. My understanding of the standard is that adding 0 to a
> nullptr is valid and you get a nullptr.
> *S*o [data(),data() + size()) would be two nullptrs. I did a seach for
> "valid range" in the standard and it doesn't seem to be defined. Maybe the
> "A pointer" implies a non nullptr but I couldn't find anywhere in the
> standard where it says "A pointer" must not be a nullptr.
>
> David
>
> --
>
> ---
> 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/.
>



--
how am I supposed to end the twisted road of  your hair in the dark night,
unless the candle of your face does not turn a lamp on up my way?

--

---
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/.

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

<div dir=3D"ltr">Range is a general concept represented by a pair of simila=
r-type iterators as its bounds; Validity of =C2=A0a range implies the valid=
ity of its bounds, but not just that; a valid range must not be empty. in c=
ase of using pointers as iterators, validity if iterators means none-null p=
ointers, since validity of a pointer **does mean** the validity of what it =
points to, and nullptr is pointing to somewhere that is not supposed to con=
tain anything. So i don`t see any reason to emphasize that=C2=A0nullptr=C2=
=A0 is invalid.<div>

<br></div><div>By this observation, we can see that if &#39;size()&#39; equ=
als to 0,then=C2=A0<i style=3D"font-size:13px;font-family:arial,sans-serif"=
>[data(),data() + size()) </i><span style=3D"font-size:13px;font-family:ari=
al,sans-serif">is an invalid range regardless of validity of &#39;data().So=
 my understanding is that, although an implementation might be allowed to r=
eturn a none-null pointer as its &#39;data()&#39; when the vector is empty,=
 validity of the range can be checked via comparing its bounds which is imp=
licitly achieved in any &#39;for&#39; based iterative algorithm.</span></di=
v>

<div><span style=3D"font-size:13px;font-family:arial,sans-serif"><br></span=
></div><div><span style=3D"font-size:13px;font-family:arial,sans-serif">reg=
ards,</span></div><div><span style=3D"font-size:13px;font-family:arial,sans=
-serif">FM.</span></div>

</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue,=
 Apr 8, 2014 at 5:23 AM, David Hunter <span dir=3D"ltr">&lt;<a href=3D"mail=
to:davidhunter22@gmail.com" target=3D"_blank">davidhunter22@gmail.com</a>&g=
t;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Actually the comment about =
performance with a empty vector made me look at the standard. I can see the=
 following <br>

<br><i>23.3.6.4 vector data [vector.data]<br>T* data() noexcept;<br>const T=
* data() const noexcept;<br>1<br>Returns: A pointer such that [data(),data(=
) + size()) is a valid range. For a non-empty vector,<br>data() =3D=3D &amp=
;front().<br>

2<br>Complexity: Constant time.</i><br><br>So my question is what does this=
 mean for an empty vector.<br><br>I am wondering if there is any guarantee =
that the data function never returns nullptr. My understanding of the stand=
ard is that adding 0 to a nullptr is valid and you get a nullptr.<br>

<i>S</i>o [data(),data() + size()) would be two nullptrs. I did a seach for=
 &quot;valid range&quot; in the standard and it doesn&#39;t seem to be defi=
ned. Maybe the &quot;A pointer&quot; implies a non nullptr but I couldn&#39=
;t find anywhere in the standard where it says &quot;A pointer&quot; must n=
ot be a nullptr.<span class=3D"HOEnZb"><font color=3D"#888888"><br>

<br>David<br><i></i></font></span></div><div class=3D"HOEnZb"><div class=3D=
"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
how am I supposed to end the twisted road of=C2=A0 your hair in the dark ni=
ght,<br>unless the candle of your face does not turn a lamp on up my way?<b=
r>


</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 />

--089e01419af67eef5204f69c6bc9--

.

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

On 9 April 2014 08:52, Farid Mehrabi <farid.mehrabi@gmail.com> wrote:

>  in case of using pointers as iterators, validity if iterators means
> none-null pointers,
>

No, it doesn't.


> since validity of a pointer **does mean** the validity of what it points
> to,
>

No it doesn't.  Valid pointers are not necessarily dereferenceable.  This
is true for vector.data() + vector.size(), nullptr and a pointer just past
the end of an array.  The last two (other than the spelling of nullptr)
have been true since the C90 standard.


> By this observation, we can see that if 'size()' equals to 0,then *[data(),data()
> + size()) *is an invalid range regardless of validity of 'data().
>

It's a perfectly valid empty range.  That is the point of half-open ranges:
it gives us a way to represent empty ranges without having to specifically
check for them.
--
 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/.

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

<div dir=3D"ltr">On 9 April 2014 08:52, Farid Mehrabi <span dir=3D"ltr">&lt=
;<a href=3D"mailto:farid.mehrabi@gmail.com" target=3D"_blank">farid.mehrabi=
@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:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">=A0in case of using pointer=
s as iterators, validity if iterators means none-null pointers,</div></bloc=
kquote>

<div><br></div><div>No, it doesn&#39;t.</div><div>=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"> since validity of a pointer **does mean** =
the validity of what it points to, </div>

</blockquote><div><br></div><div>No it doesn&#39;t. =A0Valid pointers are n=
ot necessarily dereferenceable. =A0This is true for vector.data() + vector.=
size(), nullptr and a pointer just past the end of an array. =A0The last tw=
o (other than the spelling of nullptr) have been true since the C90 standar=
d.</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"><div>By this =
observation, we can see that if &#39;size()&#39; equals to 0,then=A0<i styl=
e=3D"font-size:13px;font-family:arial,sans-serif">[data(),data() + size()) =
</i><span style=3D"font-size:13px;font-family:arial,sans-serif">is an inval=
id range regardless of validity of &#39;data().</span></div>

</div></blockquote><div><br></div><div>It&#39;s a perfectly valid empty ran=
ge. =A0That is the point of half-open ranges: it gives us a way to represen=
t empty ranges without having to specifically check for them.</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 />
<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 />

--047d7b6704cf1c273004f69d0003--

.

------=_Part_1426_6719276.1397216028226
Content-Type: text/plain; charset=UTF-8

On Monday, April 7, 2014 3:23:21 AM UTC+2, David Hunter wrote:
>
> C++11 added vector::data to get a raw pointer to the first element in the
> vector. Which is great as now you don't have to write &vec.front( ) or
> similar.
>
> So how about a pointer to the end of the data, or one past the end? Well
> it looks like we're stuck with &vec.back( ) + 1, or vec.data( ) + vec.size(
> ), or ....
>
> So give vector::front, vector::back and vector::begin( ), vector::end( )
> why only a vector::data. Maybe vector::begin_data( ) and vector::end_data()
> would have been more consistent. Anyway whatever it's called a single
> method to get either a pointer to the last element or a one past the last
> element would be nice.
>
> I am motivated here by a number of C mathematical functions I am calling
> that take start and one past the end pointer to input data.
>

 What about writing C++ wrappers that take containers or something like
array_view?

--

---
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_1426_6719276.1397216028226
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, April 7, 2014 3:23:21 AM UTC+2, David Hunter wr=
ote:<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">C++11 add=
ed vector::data to get a raw pointer to the first element in the vector. Wh=
ich is great as now you don't have to write &amp;vec.front( ) or similar.<b=
r><br>So how about a pointer to the end of the data, or one past the end? W=
ell it looks like we're stuck with &amp;vec.back( ) + 1, or vec.data( ) + v=
ec.size( ), or .... <br><br>So give vector::front, vector::back and vector:=
:begin( ), vector::end( ) why only a vector::data. Maybe vector::begin_data=
( ) and vector::end_data() would have been more consistent. Anyway whatever=
 it's called a single method to get either a pointer to the last element or=
 a one past the last element would be nice.<br><br>I am motivated here by a=
 number of C mathematical functions I am calling that take start and one pa=
st the end pointer to input data.<br></div></blockquote><div><br></div><div=
>&nbsp;What about writing C++ wrappers that take containers or something li=
ke array_view?</div></div>

<p></p>

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

------=_Part_1426_6719276.1397216028226--

.