Topic: T.size_bytes() and std::size_bytes()
Author: khatharr@gmail.com
Date: Mon, 12 Dec 2016 13:14:52 -0800 (PST)
Raw View
------=_Part_1142_1233761722.1481577292279
Content-Type: multipart/alternative;
boundary="----=_Part_1143_418491913.1481577292279"
------=_Part_1143_418491913.1481577292279
Content-Type: text/plain; charset=UTF-8
Carrying here from
https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/Md3D_7vMpgs
Many ABIs include functions using pointer/length arguments, to which end we
see the upcoming gsl::span and friends.
Examples are things like functions for loading constant buffers for
graphics shaders or sending data through a socket connection.
This data is often not be a simple stream of bytes in its practical
representation, but there is not presently a convenient and idiomatic means
of getting the byte length of the data from contiguous standard containers.
For example, a std::vector<CUSTOMVERTEX> v with sizeof(CUSTOMVERTEX) != 1
may necessitate:
abiFunc(v.data(), v.size() * sizeof(decltype(v)::value_type);
or
abiFunc(std::data(v), std::size(v) * sizeof(decltype(v)::value_type);
For the sake of convenience and for establishing a uniform idiom for
dealing with this common pattern, this proposal hopes to establish
functions:
T.size_bytes() const
and
std::size_bytes(const T&)
such that:
- Member functions shall be implemented for contiguous containers which
have a .data() member function:
- std::vector
- std::array
- std::basic_string
- (This list could be added to if new containers are added to the
standard or if we've overlooked one that makes sense.)
- These member functions shall have the following properties:
- Value returned is the number of data bytes (not reserve bytes)
stored in the container as could be calculated by container<T>.size() *
sizeof(T), or by subtracting the begin pointer from the one-past-end
pointer after casting to uintptr_t.
- Return type is the size_type of the container. (Maybe it should
just be size_t?)
- O(1) for dynamic containers such as std::vector and
std::basic_string.
- const functions.
- constexpr for static-length containers such as std::array.
- noexcept
- Non-member functions size_bytes(const T& container) and size_bytes(
const T(&c_array)[SZ]) shall be implemented such that:
- Compatible with std::span, std::view, etc. (as that all works
itself out)
- The default version returns the type/value of
container.size_bytes().
- The C array version is constexpr and returns the type/value of
sizeof(c_array).
- noexcept
The result of which would be that ABI functions such as the example above
could be neatly addressed with:
abiFunc(v.data(), v.size_bytes());
or
abiFunc(std::data(v), std::size_bytes(v));
With the added benefit of working seamlessly with the proposed gsl::span
which presently calls for a size_bytes() member.
Additionally, the non-member function will work correctly with C-style
arrays, allowing them to be swapped with std container types painlessly.
Example implementations could be:
size_type std::container::size_bytes() const {
return size() * sizeof(T);
}
namespace std {
template<class T>
constexpr auto size_bytes(const T& container) noexcept -> decltype(
container.size_bytes()) {
return container.size_bytes();
}
template<class T, size_t SZ>
constexpr size_t size_bytes(const T(&c_array)[SZ]) noexcept {
return sizeof(c_array);
}
}
Please comment with any concerns, improvements, or noticed oversights as
you deem fit.
Thank you.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1c2f6b3b-58a6-4947-96b4-775dcdccaa9e%40isocpp.org.
------=_Part_1143_418491913.1481577292279
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Carrying here from <a href=3D"https://groups.google.com/a/=
isocpp.org/forum/#!topic/sg14/Md3D_7vMpgs">https://groups.google.com/a/isoc=
pp.org/forum/#!topic/sg14/Md3D_7vMpgs</a><br><br>Many ABIs include function=
s using pointer/length arguments, to which end we see the upcoming gsl::spa=
n and friends.<br><br>Examples are things like functions for loading consta=
nt buffers for graphics shaders or sending data through a socket connection=
..<br>This
data is often not be a simple stream of bytes in its practical representat=
ion,
but there is not presently a convenient and idiomatic means of getting=20
the byte length of the data from contiguous standard containers.<br><br>For=
example, a std::vector<CUSTOMVERTEX> v with sizeof(CUSTOMVERTEX) !=
=3D 1 may necessitate:<br><br><div style=3D"background-color:rgb(250,250,25=
0);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code=
><div><span style=3D"color:#000">abiFunc</span><span style=3D"color:#660">(=
</span><span style=3D"color:#000">v</span><span style=3D"color:#660">.</spa=
n><span style=3D"color:#000">data</span><span style=3D"color:#660">(),</spa=
n><span style=3D"color:#000"> v</span><span style=3D"color:#660">.</span><s=
pan style=3D"color:#000">size</span><span style=3D"color:#660">()</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">*</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">sizeof</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#008">decltype</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">v</span><span style=
=3D"color:#660">)::</span><span style=3D"color:#000">value_type</span><span=
style=3D"color:#660"><wbr>);</span></div></code></div>=C2=A0 or<br><div st=
yle=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bord=
er-style:solid;border-width:1px"><code><div><span style=3D"color:#000">abiF=
unc</span><span style=3D"color:#660">(</span><span style=3D"color:#000">std=
</span><span style=3D"color:#660">::</span><span style=3D"color:#000">data<=
/span><span style=3D"color:#660">(</span><span style=3D"color:#000">v</span=
><span style=3D"color:#660">),</span><span style=3D"color:#000"> std</span>=
<span style=3D"color:#660">::</span><span style=3D"color:#000">size</span><=
span style=3D"color:#660">(</span><span style=3D"color:#000">v</span><span =
style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">*</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">sizeof</span><span style=3D"color:#660">(</span><span style=3D"c=
olor:#008">decltype</span><span style=3D"color:#660">(</span><span style=3D=
"color:#000">v</span><span style=3D"color:#660">)::</span><span style=3D"co=
lor:#000">value_type</span><span style=3D"color:#660"><wbr>);</span></div><=
/code></div><br>For
the sake of convenience and for establishing a uniform idiom for=20
dealing with this common pattern, this proposal hopes to establish=20
functions:<br><br>T.size_bytes() const<br>=C2=A0 and<br>std::size_bytes(con=
st T&)<br><br>such that:<br><ul><li>Member functions shall be implement=
ed for contiguous containers which have a .data() member function:</li><ul>=
<li>std::vector</li><li>std::array</li><li>std::basic_string</li><li>(This =
list could be added to if new containers are added to the standard or if we=
've overlooked one that makes sense.)</li></ul><li>These member functio=
ns shall have the following properties:</li><ul><li>Value
returned is the number of data bytes (not reserve bytes) stored in the=20
container as could be calculated by container<T>.size() *=20
sizeof(T), or by subtracting the begin pointer from the one-past-end pointe=
r after casting to uintptr_t.</li><li>Return type is the size_type of the c=
ontainer. (Maybe it should just be size_t?)</li><div class=3D"IVILX2C-Db-b"=
><li>O(1) for dynamic containers such as std::vector and std::basic_string.=
</li><li>const functions.<br></li><li>constexpr for static-length container=
s such as std::array.</li></div><li>noexcept</li></ul><li>Non-member functi=
ons <code><span style=3D"color:#000">size_bytes</span><span style=3D"color:=
#660">(</span><span style=3D"color:#008">const</span><span style=3D"color:#=
000"> T</span><span style=3D"color:#660">&</span><span style=3D"color:#=
000"> container</span><span style=3D"color:#660">)</span></code> and <code>=
<span style=3D"color:#000"><code><span style=3D"color:#000">size_bytes</spa=
n><span style=3D"color:#660">(</span><span style=3D"color:#008">const</span=
><span style=3D"color:#000"> T</span><span style=3D"color:#660">(&</spa=
n><span style=3D"color:#000">c_array</span><span style=3D"color:#660">)[</s=
pan><span style=3D"color:#000">SZ</span><span style=3D"color:#660">])</span=
></code></span><span style=3D"color:#660"></span><span style=3D"color:#000"=
> </span></code>shall be implemented such that:</li><ul><li>Compatible with=
std::span, std::view, etc. (as that all works itself out)</li><li>The defa=
ult version returns the type/value of container.size_bytes().</li><li>The C=
array version is constexpr and returns the type/value of sizeof(c_array).<=
/li><li>noexcept</li></ul></ul>The result of which would be that ABI functi=
ons such as the example above could be neatly addressed with:<br><br><div s=
tyle=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bor=
der-style:solid;border-width:1px"><code><div><span style=3D"color:#000">abi=
Func</span><span style=3D"color:#660">(</span><span style=3D"color:#000">v<=
/span><span style=3D"color:#660">.</span><span style=3D"color:#000">data</s=
pan><span style=3D"color:#660">(),</span><span style=3D"color:#000"> v</spa=
n><span style=3D"color:#660">.</span><span style=3D"color:#000">size_bytes<=
/span><span style=3D"color:#660">());</span></div></code></div>=C2=A0 or<br=
><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,1=
87);border-style:solid;border-width:1px"><code><div><span style=3D"color:#0=
00">abiFunc</span><span style=3D"color:#660">(</span><span style=3D"color:#=
000">std</span><span style=3D"color:#660">::</span><span style=3D"color:#00=
0">data</span><span style=3D"color:#660">(</span><span style=3D"color:#000"=
>v</span><span style=3D"color:#660">),</span><span style=3D"color:#000"> st=
d</span><span style=3D"color:#660">::</span><span style=3D"color:#000">size=
_bytes</span><span style=3D"color:#660">(</span><span style=3D"color:#000">=
v</span><span style=3D"color:#660">));</span></div></code></div><br>With th=
e added benefit of working seamlessly with the proposed gsl::span which pre=
sently calls for a size_bytes() member.<br>Additionally, the non-member fun=
ction will work correctly with C-style arrays, allowing them to be swapped =
with std container types painlessly.<br><br>Example implementations could b=
e:<br><br><code><div><div style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; ove=
rflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br>size_type std</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">container</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">size_bytes</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> size</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">siz=
eof</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">namespace</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">template</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">></span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> size_bytes</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> container</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> noexcept </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">-></span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">dec=
ltype</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">container</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">size_bytes</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">())</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> container</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">size_bytes</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">template</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> size_t SZ</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> size_t size_bytes</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(&</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">c_array</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">)[</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">SZ</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">])</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> noexcept </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">sizeo=
f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">c_array</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">}</span></div></code></div><span style=3D"=
color:#660"><br></span></div></code><br>Please comment with any concerns, i=
mprovements, or noticed oversights as you deem fit.<br><br>Thank you.<br></=
div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1c2f6b3b-58a6-4947-96b4-775dcdccaa9e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1c2f6b3b-58a6-4947-96b4-775dcdccaa9e=
%40isocpp.org</a>.<br />
------=_Part_1143_418491913.1481577292279--
------=_Part_1142_1233761722.1481577292279--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 12 Dec 2016 19:25:32 -0800 (PST)
Raw View
------=_Part_1693_1620618039.1481599532242
Content-Type: multipart/alternative;
boundary="----=_Part_1694_1193588483.1481599532243"
------=_Part_1694_1193588483.1481599532243
Content-Type: text/plain; charset=UTF-8
On Monday, December 12, 2016 at 4:14:52 PM UTC-5, khat...@gmail.com wrote:
>
> Carrying here from
> https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/Md3D_7vMpgs
>
> Many ABIs include functions using pointer/length arguments, to which end
> we see the upcoming gsl::span and friends.
>
> Examples are things like functions for loading constant buffers for
> graphics shaders or sending data through a socket connection.
> This data is often not be a simple stream of bytes in its practical
> representation, but there is not presently a convenient and idiomatic means
> of getting the byte length of the data from contiguous standard containers.
>
> For example, a std::vector<CUSTOMVERTEX> v with sizeof(CUSTOMVERTEX) != 1
> may necessitate:
>
> abiFunc(v.data(), v.size() * sizeof(decltype(v)::value_type);
> or
> abiFunc(std::data(v), std::size(v) * sizeof(decltype(v)::value_type);
>
> For the sake of convenience and for establishing a uniform idiom for
> dealing with this common pattern, this proposal hopes to establish
> functions:
>
> T.size_bytes() const
> and
> std::size_bytes(const T&)
>
> such that:
>
> - Member functions shall be implemented for contiguous containers
> which have a .data() member function:
> - std::vector
> - std::array
> - std::basic_string
> - (This list could be added to if new containers are added to the
> standard or if we've overlooked one that makes sense.)
> - These member functions shall have the following properties:
> - Value returned is the number of data bytes (not reserve bytes)
> stored in the container as could be calculated by container<T>.size() *
> sizeof(T), or by subtracting the begin pointer from the one-past-end
> pointer after casting to uintptr_t.
> - Return type is the size_type of the container. (Maybe it should
> just be size_t?)
> - O(1) for dynamic containers such as std::vector and
> std::basic_string.
> - const functions.
> - constexpr for static-length containers such as std::array.
> - noexcept
> - Non-member functions size_bytes(const T& container) and size_bytes(
> const T(&c_array)[SZ]) shall be implemented such that:
> - Compatible with std::span, std::view, etc. (as that all works
> itself out)
> - The default version returns the type/value of
> container.size_bytes().
> - The C array version is constexpr and returns the type/value of
> sizeof(c_array).
> - noexcept
>
> The result of which would be that ABI functions such as the example above
> could be neatly addressed with:
>
> abiFunc(v.data(), v.size_bytes());
> or
> abiFunc(std::data(v), std::size_bytes(v));
>
> With the added benefit of working seamlessly with the proposed gsl::span
> which presently calls for a size_bytes() member.
> Additionally, the non-member function will work correctly with C-style
> arrays, allowing them to be swapped with std container types painlessly.
>
> Example implementations could be:
>
>
> size_type std::container::size_bytes() const {
> return size() * sizeof(T);
> }
>
> namespace std {
> template<class T>
> constexpr auto size_bytes(const T& container) noexcept -> decltype(
> container.size_bytes()) {
> return container.size_bytes();
>
> }
>
> template<class T, size_t SZ>
> constexpr size_t size_bytes(const T(&c_array)[SZ]) noexcept {
> return sizeof(c_array);
> }
> }
>
>
> Please comment with any concerns, improvements, or noticed oversights as
> you deem fit.
>
> Thank you.
>
Any contiguous range type ought to be able to have `size_bytes` work on it.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ef0958bc-8747-455e-9be4-3a36773c05b7%40isocpp.org.
------=_Part_1694_1193588483.1481599532243
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, December 12, 2016 at 4:14:52 PM UTC-5, khat...@=
gmail.com 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"lt=
r">Carrying here from <a href=3D"https://groups.google.com/a/isocpp.org/for=
um/#!topic/sg14/Md3D_7vMpgs" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/#!topic/s=
g14/Md3D_7vMpgs';return true;" onclick=3D"this.href=3D'https://grou=
ps.google.com/a/isocpp.org/forum/#!topic/sg14/Md3D_7vMpgs';return true;=
">https://groups.google.com/a/<wbr>isocpp.org/forum/#!topic/sg14/<wbr>Md3D_=
7vMpgs</a><br><br>Many ABIs include functions using pointer/length argument=
s, to which end we see the upcoming gsl::span and friends.<br><br>Examples =
are things like functions for loading constant buffers for graphics shaders=
or sending data through a socket connection.<br>This
data is often not be a simple stream of bytes in its practical representat=
ion,
but there is not presently a convenient and idiomatic means of getting=20
the byte length of the data from contiguous standard containers.<br><br>For=
example, a std::vector<CUSTOMVERTEX> v with sizeof(CUSTOMVERTEX) !=
=3D 1 may necessitate:<br><br><div style=3D"background-color:rgb(250,250,25=
0);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code=
><div><span style=3D"color:#000">abiFunc</span><span style=3D"color:#660">(=
</span><span style=3D"color:#000">v</span><span style=3D"color:#660">.</spa=
n><span style=3D"color:#000">data</span><span style=3D"color:#660">(),</spa=
n><span style=3D"color:#000"> v</span><span style=3D"color:#660">.</span><s=
pan style=3D"color:#000">size</span><span style=3D"color:#660">()</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">*</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">sizeof</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#008">decltype</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">v</span><span style=
=3D"color:#660">)::</span><span style=3D"color:#000">value_type</span><span=
style=3D"color:#660"><wbr>);</span></div></code></div>=C2=A0 or<br><div st=
yle=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bord=
er-style:solid;border-width:1px"><code><div><span style=3D"color:#000">abiF=
unc</span><span style=3D"color:#660">(</span><span style=3D"color:#000">std=
</span><span style=3D"color:#660">::</span><span style=3D"color:#000">data<=
/span><span style=3D"color:#660">(</span><span style=3D"color:#000">v</span=
><span style=3D"color:#660">),</span><span style=3D"color:#000"> std</span>=
<span style=3D"color:#660">::</span><span style=3D"color:#000">size</span><=
span style=3D"color:#660">(</span><span style=3D"color:#000">v</span><span =
style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">*</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">sizeof</span><span style=3D"color:#660">(</span><span style=3D"c=
olor:#008">decltype</span><span style=3D"color:#660">(</span><span style=3D=
"color:#000">v</span><span style=3D"color:#660">)::</span><span style=3D"co=
lor:#000">value_type</span><span style=3D"color:#660"><wbr>);</span></div><=
/code></div><br>For
the sake of convenience and for establishing a uniform idiom for=20
dealing with this common pattern, this proposal hopes to establish=20
functions:<br><br>T.size_bytes() const<br>=C2=A0 and<br>std::size_bytes(con=
st T&)<br><br>such that:<br><ul><li>Member functions shall be implement=
ed for contiguous containers which have a .data() member function:</li><ul>=
<li>std::vector</li><li>std::array</li><li>std::basic_string</li><li>(This =
list could be added to if new containers are added to the standard or if we=
've overlooked one that makes sense.)</li></ul><li>These member functio=
ns shall have the following properties:</li><ul><li>Value
returned is the number of data bytes (not reserve bytes) stored in the=20
container as could be calculated by container<T>.size() *=20
sizeof(T), or by subtracting the begin pointer from the one-past-end pointe=
r after casting to uintptr_t.</li><li>Return type is the size_type of the c=
ontainer. (Maybe it should just be size_t?)</li><div><li>O(1) for dynamic c=
ontainers such as std::vector and std::basic_string.</li><li>const function=
s.<br></li><li>constexpr for static-length containers such as std::array.</=
li></div><li>noexcept</li></ul><li>Non-member functions <code><span style=
=3D"color:#000">size_bytes</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#008">const</span><span style=3D"color:#000"> T</span><span s=
tyle=3D"color:#660">&</span><span style=3D"color:#000"> container</span=
><span style=3D"color:#660">)</span></code> and <code><span style=3D"color:=
#000"><code><span style=3D"color:#000">size_bytes</span><span style=3D"colo=
r:#660">(</span><span style=3D"color:#008">const</span><span style=3D"color=
:#000"> T</span><span style=3D"color:#660">(&</span><span style=3D"colo=
r:#000">c_array</span><span style=3D"color:#660">)[</span><span style=3D"co=
lor:#000">SZ</span><span style=3D"color:#660">])</span></code></span><span =
style=3D"color:#660"></span><span style=3D"color:#000"> </span></code>shall=
be implemented such that:</li><ul><li>Compatible with std::span, std::view=
, etc. (as that all works itself out)</li><li>The default version returns t=
he type/value of container.size_bytes().</li><li>The C array version is con=
stexpr and returns the type/value of sizeof(c_array).</li><li>noexcept</li>=
</ul></ul>The result of which would be that ABI functions such as the examp=
le above could be neatly addressed with:<br><br><div style=3D"background-co=
lor:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;borde=
r-width:1px"><code><div><span style=3D"color:#000">abiFunc</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#000">v</span><span style=3D"=
color:#660">.</span><span style=3D"color:#000">data</span><span style=3D"co=
lor:#660">(),</span><span style=3D"color:#000"> v</span><span style=3D"colo=
r:#660">.</span><span style=3D"color:#000">size_bytes</span><span style=3D"=
color:#660">());</span></div></code></div>=C2=A0 or<br><div style=3D"backgr=
ound-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:soli=
d;border-width:1px"><code><div><span style=3D"color:#000">abiFunc</span><sp=
an style=3D"color:#660">(</span><span style=3D"color:#000">std</span><span =
style=3D"color:#660">::</span><span style=3D"color:#000">data</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#000">v</span><span style=
=3D"color:#660">),</span><span style=3D"color:#000"> std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">size_bytes</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">v</span><span style=
=3D"color:#660">));</span></div></code></div><br>With the added benefit of =
working seamlessly with the proposed gsl::span which presently calls for a =
size_bytes() member.<br>Additionally, the non-member function will work cor=
rectly with C-style arrays, allowing them to be swapped with std container =
types painlessly.<br><br>Example implementations could be:<br><br><code><di=
v><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,=
187);border-style:solid;border-width:1px"><code><div><span style=3D"color:#=
000"><br>size_type std</span><span style=3D"color:#660">::</span><span styl=
e=3D"color:#000">container</span><span style=3D"color:#660">::</span><span =
style=3D"color:#000">size_bytes</span><span style=3D"color:#660">()</span><=
span style=3D"color:#000"> </span><span style=3D"color:#008">const</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span s=
tyle=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">return</sp=
an><span style=3D"color:#000"> size</span><span style=3D"color:#660">()</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#660">*</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#008">sizeof</span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#000">T</span><span s=
tyle=3D"color:#660">);</span><span style=3D"color:#000"><br></span><span st=
yle=3D"color:#660">}</span><span style=3D"color:#000"><br><br></span><span =
style=3D"color:#008">namespace</span><span style=3D"color:#000"> std </span=
><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 <=
/span><span style=3D"color:#008">template</span><span style=3D"color:#660">=
<</span><span style=3D"color:#008">class</span><span style=3D"color:#000=
"> T</span><span style=3D"color:#660">></span><span style=3D"color:#000"=
><br>=C2=A0 </span><span style=3D"color:#008">constexpr</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">auto</span><span style=
=3D"color:#000"> size_bytes</span><span style=3D"color:#660">(</span><span =
style=3D"color:#008">const</span><span style=3D"color:#000"> T</span><span =
style=3D"color:#660">&</span><span style=3D"color:#000"> container</spa=
n><span style=3D"color:#660">)</span><span style=3D"color:#000"> noexcept <=
/span><span style=3D"color:#660">-></span><span style=3D"color:#000"> </=
span><span style=3D"color:#008">decltype</span><span style=3D"color:#660">(=
</span><span style=3D"color:#000">container</span><span style=3D"color:#660=
">.</span><span style=3D"color:#000">size_bytes</span><span style=3D"color:=
#660">(<wbr>))</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span s=
tyle=3D"color:#008">return</span><span style=3D"color:#000"> container</spa=
n><span style=3D"color:#660">.</span><span style=3D"color:#000">size_bytes<=
/span><span style=3D"color:#660">();</span><span style=3D"color:#000"><br><=
br>=C2=A0 </span><span style=3D"color:#660">}</span><span style=3D"color:#0=
00"><br><br>=C2=A0 </span><span style=3D"color:#008">template</span><span s=
tyle=3D"color:#660"><</span><span style=3D"color:#008">class</span><span=
style=3D"color:#000"> T</span><span style=3D"color:#660">,</span><span sty=
le=3D"color:#000"> size_t SZ</span><span style=3D"color:#660">></span><s=
pan style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">const=
expr</span><span style=3D"color:#000"> size_t size_bytes</span><span style=
=3D"color:#660">(</span><span style=3D"color:#008">const</span><span style=
=3D"color:#000"> T</span><span style=3D"color:#660">(&</span><span styl=
e=3D"color:#000">c_array</span><span style=3D"color:#660">)[</span><span st=
yle=3D"color:#000">SZ</span><span style=3D"color:#660">])</span><span style=
=3D"color:#000"> noexcept </span><span style=3D"color:#660">{</span><span s=
tyle=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">ret=
urn</span><span style=3D"color:#000"> </span><span style=3D"color:#008">siz=
eof</span><span style=3D"color:#660">(</span><span style=3D"color:#000">c_a=
rray</span><span style=3D"color:#660">);</span><span style=3D"color:#000"><=
br>=C2=A0 </span><span style=3D"color:#660">}</span><span style=3D"color:#0=
00"><br></span><span style=3D"color:#660">}</span></div></code></div><span =
style=3D"color:#660"><br></span></div></code><br>Please comment with any co=
ncerns, improvements, or noticed oversights as you deem fit.<br><br>Thank y=
ou.<br></div></blockquote><div><br>Any contiguous range type ought to be ab=
le to have `size_bytes` work on it.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ef0958bc-8747-455e-9be4-3a36773c05b7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ef0958bc-8747-455e-9be4-3a36773c05b7=
%40isocpp.org</a>.<br />
------=_Part_1694_1193588483.1481599532243--
------=_Part_1693_1620618039.1481599532242--
.
Author: khatharr@gmail.com
Date: Mon, 12 Dec 2016 21:22:57 -0800 (PST)
Raw View
------=_Part_2758_1124715330.1481606577417
Content-Type: multipart/alternative;
boundary="----=_Part_2759_1448642633.1481606577418"
------=_Part_2759_1448642633.1481606577418
Content-Type: text/plain; charset=UTF-8
Do you mean that I should reword it (possibly to be more clear about gsl),
or that I missed one?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6b0c27be-5daf-442e-8c34-c45a15b1a918%40isocpp.org.
------=_Part_2759_1448642633.1481606577418
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Do you mean that I should reword it (possibly to be more c=
lear about gsl), or that I missed one?<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6b0c27be-5daf-442e-8c34-c45a15b1a918%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6b0c27be-5daf-442e-8c34-c45a15b1a918=
%40isocpp.org</a>.<br />
------=_Part_2759_1448642633.1481606577418--
------=_Part_2758_1124715330.1481606577417--
.
Author: Bo Persson <bop@gmb.dk>
Date: Tue, 13 Dec 2016 17:35:44 +0100
Raw View
On 2016-12-12 22:14, khatharr@gmail.com wrote:
> Carrying here from
> https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/Md3D_7vMpgs
>
> Many ABIs include functions using pointer/length arguments, to which end
> we see the upcoming gsl::span and friends.
>
> Examples are things like functions for loading constant buffers for
> graphics shaders or sending data through a socket connection.
> This data is often not be a simple stream of bytes in its practical
> representation, but there is not presently a convenient and idiomatic
> means of getting the byte length of the data from contiguous standard
> containers.
>
> For example, a std::vector<CUSTOMVERTEX> v with sizeof(CUSTOMVERTEX) !=
> 1 may necessitate:
>
> |
> abiFunc(v.data(),v.size()*sizeof(decltype(v)::value_type);
> |
> or
> |
> abiFunc(std::data(v),std::size(v)*sizeof(decltype(v)::value_type);
> |
>
> For the sake of convenience and for establishing a uniform idiom for
> dealing with this common pattern, this proposal hopes to establish
> functions:
>
> T.size_bytes() const
> and
> std::size_bytes(const T&)
>
> such that:
>
> * Member functions shall be implemented for contiguous containers
> which have a .data() member function:
> o std::vector
> o std::array
> o std::basic_string
> o (This list could be added to if new containers are added to the
> standard or if we've overlooked one that makes sense.)
> * These member functions shall have the following properties:
> o Value returned is the number of data bytes (not reserve bytes)
> stored in the container as could be calculated by
> container<T>.size() * sizeof(T), or by subtracting the begin
> pointer from the one-past-end pointer after casting to uintptr_t.
> o Return type is the size_type of the container. (Maybe it should
> just be size_t?)
> o O(1) for dynamic containers such as std::vector and
> std::basic_string.
> o const functions.
> o constexpr for static-length containers such as std::array.
> o noexcept
> * Non-member functions |size_bytes(constT&container)| and
> ||size_bytes(constT(&c_array)[SZ])||shall be implemented such that:
> o Compatible with std::span, std::view, etc. (as that all works
> itself out)
> o The default version returns the type/value of
> container.size_bytes().
> o The C array version is constexpr and returns the type/value of
> sizeof(c_array).
> o noexcept
>
> The result of which would be that ABI functions such as the example
> above could be neatly addressed with:
>
> |
> abiFunc(v.data(),v.size_bytes());
> |
> or
> |
> abiFunc(std::data(v),std::size_bytes(v));
> |
>
> With the added benefit of working seamlessly with the proposed gsl::span
> which presently calls for a size_bytes() member.
> Additionally, the non-member function will work correctly with C-style
> arrays, allowing them to be swapped with std container types painlessly.
>
> Example implementations could be:
>
> |
> |
>
> size_type std::container::size_bytes()const{
> returnsize()*sizeof(T);
> }
>
> namespacestd {
> template<classT>
> constexprautosize_bytes(constT&container)noexcept
> ->decltype(container.size_bytes()){
> returncontainer.size_bytes();
>
> }
>
> template<classT,size_t SZ>
> constexprsize_t size_bytes(constT(&c_array)[SZ])noexcept {
> returnsizeof(c_array);
> }
> }
> |
>
> |
> Please comment with any concerns, improvements, or noticed oversights as
> you deem fit.
>
> Thank you.
>
Someone is soon :-) going to ask for a size_octets for systems where a
byte is not 8 bits.
Bo Persson
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/o2p80q%249vt%241%40blaine.gmane.org.
.
Author: David Hollman <david.s.hollman@gmail.com>
Date: Wed, 14 Dec 2016 10:57:02 -0800 (PST)
Raw View
------=_Part_932_1412925033.1481741822462
Content-Type: multipart/alternative;
boundary="----=_Part_933_764981411.1481741822463"
------=_Part_933_764981411.1481741822463
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Chiming in a bit late here, but it seems to me the more modern and general=
=20
way to approach this and related problems would be to introduce a=20
std::container_traits<> class template, right?
Either way, I would personally avoid adding both the instance method and=20
the free function versions to the same proposal =E2=80=94 I agree that it's=
better=20
with both, but people have really strong opinions on unified call syntax,=
=20
and I think you'll get people bikeshedding the proposal on just that point.=
=20
(If and when we do get unified call syntax, you'll get this sort of thing=
=20
for free anyway). =20
On Monday, December 12, 2016 at 1:14:52 PM UTC-8, khat...@gmail.com wrote:
>
> Carrying here from=20
> https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/Md3D_7vMpgs
>
> Many ABIs include functions using pointer/length arguments, to which end=
=20
> we see the upcoming gsl::span and friends.
>
> Examples are things like functions for loading constant buffers for=20
> graphics shaders or sending data through a socket connection.
> This data is often not be a simple stream of bytes in its practical=20
> representation, but there is not presently a convenient and idiomatic mea=
ns=20
> of getting the byte length of the data from contiguous standard container=
s.
>
> For example, a std::vector<CUSTOMVERTEX> v with sizeof(CUSTOMVERTEX) !=3D=
1=20
> may necessitate:
>
> abiFunc(v.data(), v.size() * sizeof(decltype(v)::value_type);
> or
> abiFunc(std::data(v), std::size(v) * sizeof(decltype(v)::value_type);
>
> For the sake of convenience and for establishing a uniform idiom for=20
> dealing with this common pattern, this proposal hopes to establish=20
> functions:
>
> T.size_bytes() const
> and
> std::size_bytes(const T&)
>
> such that:
>
> - Member functions shall be implemented for contiguous containers=20
> which have a .data() member function:
> - std::vector
> - std::array
> - std::basic_string
> - (This list could be added to if new containers are added to the=
=20
> standard or if we've overlooked one that makes sense.)
> - These member functions shall have the following properties:
> - Value returned is the number of data bytes (not reserve bytes)=20
> stored in the container as could be calculated by container<T>.size=
() *=20
> sizeof(T), or by subtracting the begin pointer from the one-past-en=
d=20
> pointer after casting to uintptr_t.
> - Return type is the size_type of the container. (Maybe it should=
=20
> just be size_t?)
> - O(1) for dynamic containers such as std::vector and=20
> std::basic_string.
> - const functions.
> - constexpr for static-length containers such as std::array.
> - noexcept
> - Non-member functions size_bytes(const T& container) and size_bytes(
> const T(&c_array)[SZ]) shall be implemented such that:
> - Compatible with std::span, std::view, etc. (as that all works=20
> itself out)
> - The default version returns the type/value of=20
> container.size_bytes().
> - The C array version is constexpr and returns the type/value of=20
> sizeof(c_array).
> - noexcept
> =20
> The result of which would be that ABI functions such as the example above=
=20
> could be neatly addressed with:
>
> abiFunc(v.data(), v.size_bytes());
> or
> abiFunc(std::data(v), std::size_bytes(v));
>
> With the added benefit of working seamlessly with the proposed gsl::span=
=20
> which presently calls for a size_bytes() member.
> Additionally, the non-member function will work correctly with C-style=20
> arrays, allowing them to be swapped with std container types painlessly.
>
> Example implementations could be:
>
>
> size_type std::container::size_bytes() const {
> return size() * sizeof(T);
> }
>
> namespace std {
> template<class T>
> constexpr auto size_bytes(const T& container) noexcept -> decltype(
> container.size_bytes()) {
> return container.size_bytes();
>
> }
>
> template<class T, size_t SZ>
> constexpr size_t size_bytes(const T(&c_array)[SZ]) noexcept {
> return sizeof(c_array);
> }
> }
>
>
> Please comment with any concerns, improvements, or noticed oversights as=
=20
> you deem fit.
>
> Thank you.
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/69cec4c6-fdf6-47ae-a178-16bd75a7120e%40isocpp.or=
g.
------=_Part_933_764981411.1481741822463
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Chiming in a bit late here, but it seems to me the more mo=
dern and general way to approach this and related problems would be to intr=
oduce a std::container_traits<> class template, right?<div><br></div>=
<div>Either way, I would personally avoid adding both the instance method a=
nd the free function versions to the same proposal =E2=80=94 I agree that i=
t's better with both, but people have really strong opinions on unified=
call syntax, and I think you'll get people bikeshedding the proposal o=
n just that point. =C2=A0(If and when we do get unified call syntax, you=
9;ll get this sort of thing for free anyway). =C2=A0<br><br>On Monday, Dece=
mber 12, 2016 at 1:14:52 PM UTC-8, khat...@gmail.com wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr">Carrying here from <a href=3D=
"https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/Md3D_7vMpgs" tar=
get=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://gro=
ups.google.com/a/isocpp.org/forum/#!topic/sg14/Md3D_7vMpgs';return true=
;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum=
/#!topic/sg14/Md3D_7vMpgs';return true;">https://groups.google.com/a/<w=
br>isocpp.org/forum/#!topic/sg14/<wbr>Md3D_7vMpgs</a><br><br>Many ABIs incl=
ude functions using pointer/length arguments, to which end we see the upcom=
ing gsl::span and friends.<br><br>Examples are things like functions for lo=
ading constant buffers for graphics shaders or sending data through a socke=
t connection.<br>This
data is often not be a simple stream of bytes in its practical representat=
ion,
but there is not presently a convenient and idiomatic means of getting=20
the byte length of the data from contiguous standard containers.<br><br>For=
example, a std::vector<CUSTOMVERTEX> v with sizeof(CUSTOMVERTEX) !=
=3D 1 may necessitate:<br><br><div style=3D"background-color:rgb(250,250,25=
0);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code=
><div><span style=3D"color:#000">abiFunc</span><span style=3D"color:#660">(=
</span><span style=3D"color:#000">v</span><span style=3D"color:#660">.</spa=
n><span style=3D"color:#000">data</span><span style=3D"color:#660">(),</spa=
n><span style=3D"color:#000"> v</span><span style=3D"color:#660">.</span><s=
pan style=3D"color:#000">size</span><span style=3D"color:#660">()</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">*</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">sizeof</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#008">decltype</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">v</span><span style=
=3D"color:#660">)::</span><span style=3D"color:#000">value_type</span><span=
style=3D"color:#660"><wbr>);</span></div></code></div>=C2=A0 or<br><div st=
yle=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bord=
er-style:solid;border-width:1px"><code><div><span style=3D"color:#000">abiF=
unc</span><span style=3D"color:#660">(</span><span style=3D"color:#000">std=
</span><span style=3D"color:#660">::</span><span style=3D"color:#000">data<=
/span><span style=3D"color:#660">(</span><span style=3D"color:#000">v</span=
><span style=3D"color:#660">),</span><span style=3D"color:#000"> std</span>=
<span style=3D"color:#660">::</span><span style=3D"color:#000">size</span><=
span style=3D"color:#660">(</span><span style=3D"color:#000">v</span><span =
style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">*</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">sizeof</span><span style=3D"color:#660">(</span><span style=3D"c=
olor:#008">decltype</span><span style=3D"color:#660">(</span><span style=3D=
"color:#000">v</span><span style=3D"color:#660">)::</span><span style=3D"co=
lor:#000">value_type</span><span style=3D"color:#660"><wbr>);</span></div><=
/code></div><br>For
the sake of convenience and for establishing a uniform idiom for=20
dealing with this common pattern, this proposal hopes to establish=20
functions:<br><br>T.size_bytes() const<br>=C2=A0 and<br>std::size_bytes(con=
st T&)<br><br>such that:<br><ul><li>Member functions shall be implement=
ed for contiguous containers which have a .data() member function:</li><ul>=
<li>std::vector</li><li>std::array</li><li>std::basic_string</li><li>(This =
list could be added to if new containers are added to the standard or if we=
've overlooked one that makes sense.)</li></ul><li>These member functio=
ns shall have the following properties:</li><ul><li>Value
returned is the number of data bytes (not reserve bytes) stored in the=20
container as could be calculated by container<T>.size() *=20
sizeof(T), or by subtracting the begin pointer from the one-past-end pointe=
r after casting to uintptr_t.</li><li>Return type is the size_type of the c=
ontainer. (Maybe it should just be size_t?)</li><div><li>O(1) for dynamic c=
ontainers such as std::vector and std::basic_string.</li><li>const function=
s.<br></li><li>constexpr for static-length containers such as std::array.</=
li></div><li>noexcept</li></ul><li>Non-member functions <code><span style=
=3D"color:#000">size_bytes</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#008">const</span><span style=3D"color:#000"> T</span><span s=
tyle=3D"color:#660">&</span><span style=3D"color:#000"> container</span=
><span style=3D"color:#660">)</span></code> and <code><span style=3D"color:=
#000"><code><span style=3D"color:#000">size_bytes</span><span style=3D"colo=
r:#660">(</span><span style=3D"color:#008">const</span><span style=3D"color=
:#000"> T</span><span style=3D"color:#660">(&</span><span style=3D"colo=
r:#000">c_array</span><span style=3D"color:#660">)[</span><span style=3D"co=
lor:#000">SZ</span><span style=3D"color:#660">])</span></code></span><span =
style=3D"color:#660"></span><span style=3D"color:#000"> </span></code>shall=
be implemented such that:</li><ul><li>Compatible with std::span, std::view=
, etc. (as that all works itself out)</li><li>The default version returns t=
he type/value of container.size_bytes().</li><li>The C array version is con=
stexpr and returns the type/value of sizeof(c_array).</li><li>noexcept</li>=
</ul></ul>The result of which would be that ABI functions such as the examp=
le above could be neatly addressed with:<br><br><div style=3D"background-co=
lor:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;borde=
r-width:1px"><code><div><span style=3D"color:#000">abiFunc</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#000">v</span><span style=3D"=
color:#660">.</span><span style=3D"color:#000">data</span><span style=3D"co=
lor:#660">(),</span><span style=3D"color:#000"> v</span><span style=3D"colo=
r:#660">.</span><span style=3D"color:#000">size_bytes</span><span style=3D"=
color:#660">());</span></div></code></div>=C2=A0 or<br><div style=3D"backgr=
ound-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:soli=
d;border-width:1px"><code><div><span style=3D"color:#000">abiFunc</span><sp=
an style=3D"color:#660">(</span><span style=3D"color:#000">std</span><span =
style=3D"color:#660">::</span><span style=3D"color:#000">data</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#000">v</span><span style=
=3D"color:#660">),</span><span style=3D"color:#000"> std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">size_bytes</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">v</span><span style=
=3D"color:#660">));</span></div></code></div><br>With the added benefit of =
working seamlessly with the proposed gsl::span which presently calls for a =
size_bytes() member.<br>Additionally, the non-member function will work cor=
rectly with C-style arrays, allowing them to be swapped with std container =
types painlessly.<br><br>Example implementations could be:<br><br><code><di=
v><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,=
187);border-style:solid;border-width:1px"><code><div><span style=3D"color:#=
000"><br>size_type std</span><span style=3D"color:#660">::</span><span styl=
e=3D"color:#000">container</span><span style=3D"color:#660">::</span><span =
style=3D"color:#000">size_bytes</span><span style=3D"color:#660">()</span><=
span style=3D"color:#000"> </span><span style=3D"color:#008">const</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span s=
tyle=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">return</sp=
an><span style=3D"color:#000"> size</span><span style=3D"color:#660">()</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#660">*</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#008">sizeof</span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#000">T</span><span s=
tyle=3D"color:#660">);</span><span style=3D"color:#000"><br></span><span st=
yle=3D"color:#660">}</span><span style=3D"color:#000"><br><br></span><span =
style=3D"color:#008">namespace</span><span style=3D"color:#000"> std </span=
><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 <=
/span><span style=3D"color:#008">template</span><span style=3D"color:#660">=
<</span><span style=3D"color:#008">class</span><span style=3D"color:#000=
"> T</span><span style=3D"color:#660">></span><span style=3D"color:#000"=
><br>=C2=A0 </span><span style=3D"color:#008">constexpr</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">auto</span><span style=
=3D"color:#000"> size_bytes</span><span style=3D"color:#660">(</span><span =
style=3D"color:#008">const</span><span style=3D"color:#000"> T</span><span =
style=3D"color:#660">&</span><span style=3D"color:#000"> container</spa=
n><span style=3D"color:#660">)</span><span style=3D"color:#000"> noexcept <=
/span><span style=3D"color:#660">-></span><span style=3D"color:#000"> </=
span><span style=3D"color:#008">decltype</span><span style=3D"color:#660">(=
</span><span style=3D"color:#000">container</span><span style=3D"color:#660=
">.</span><span style=3D"color:#000">size_bytes</span><span style=3D"color:=
#660">(<wbr>))</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span s=
tyle=3D"color:#008">return</span><span style=3D"color:#000"> container</spa=
n><span style=3D"color:#660">.</span><span style=3D"color:#000">size_bytes<=
/span><span style=3D"color:#660">();</span><span style=3D"color:#000"><br><=
br>=C2=A0 </span><span style=3D"color:#660">}</span><span style=3D"color:#0=
00"><br><br>=C2=A0 </span><span style=3D"color:#008">template</span><span s=
tyle=3D"color:#660"><</span><span style=3D"color:#008">class</span><span=
style=3D"color:#000"> T</span><span style=3D"color:#660">,</span><span sty=
le=3D"color:#000"> size_t SZ</span><span style=3D"color:#660">></span><s=
pan style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">const=
expr</span><span style=3D"color:#000"> size_t size_bytes</span><span style=
=3D"color:#660">(</span><span style=3D"color:#008">const</span><span style=
=3D"color:#000"> T</span><span style=3D"color:#660">(&</span><span styl=
e=3D"color:#000">c_array</span><span style=3D"color:#660">)[</span><span st=
yle=3D"color:#000">SZ</span><span style=3D"color:#660">])</span><span style=
=3D"color:#000"> noexcept </span><span style=3D"color:#660">{</span><span s=
tyle=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">ret=
urn</span><span style=3D"color:#000"> </span><span style=3D"color:#008">siz=
eof</span><span style=3D"color:#660">(</span><span style=3D"color:#000">c_a=
rray</span><span style=3D"color:#660">);</span><span style=3D"color:#000"><=
br>=C2=A0 </span><span style=3D"color:#660">}</span><span style=3D"color:#0=
00"><br></span><span style=3D"color:#660">}</span></div></code></div><span =
style=3D"color:#660"><br></span></div></code><br>Please comment with any co=
ncerns, improvements, or noticed oversights as you deem fit.<br><br>Thank y=
ou.<br></div></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/69cec4c6-fdf6-47ae-a178-16bd75a7120e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/69cec4c6-fdf6-47ae-a178-16bd75a7120e=
%40isocpp.org</a>.<br />
------=_Part_933_764981411.1481741822463--
------=_Part_932_1412925033.1481741822462--
.
Author: khatharr@gmail.com
Date: Wed, 14 Dec 2016 11:43:10 -0800 (PST)
Raw View
------=_Part_6625_798869478.1481744590276
Content-Type: multipart/alternative;
boundary="----=_Part_6626_138596179.1481744590277"
------=_Part_6626_138596179.1481744590277
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I'm not sure how container_traits would improve the existing situation?
With regard to call syntax, I'll be perfectly straight with you and say=20
that I don't actually give half a damn about the non-member function. I=20
understand it, I don't object to it, I think it would be helpful to a lot=
=20
of people, and it certainly wouldn't cause me any trouble, but what I=20
actually want for myself is the std::vector member function. The problem is=
=20
that the feedback I've been getting is overwhelmingly biased in the other=
=20
direction, with people saying that they're okay with a non-member=20
size_bytes but not a member one. I strongly suspect that if I split the=20
proposal the result would be the non-member getting support and the member=
=20
(which is my only motivation here) getting shot down.
Unified call syntax wouldn't really solve this problem because the function=
=20
that got created would already be non-member. It would also disadvantage=20
the non-member crowd since they'd still have to write a size_bytes for C=20
arrays if they wanted the full benefit.
Unless I'm misunderstanding something?
On Wednesday, December 14, 2016 at 10:57:02 AM UTC-8, David Hollman wrote:
>
> Chiming in a bit late here, but it seems to me the more modern and genera=
l=20
> way to approach this and related problems would be to introduce a=20
> std::container_traits<> class template, right?
>
> Either way, I would personally avoid adding both the instance method and=
=20
> the free function versions to the same proposal =E2=80=94 I agree that it=
's better=20
> with both, but people have really strong opinions on unified call syntax,=
=20
> and I think you'll get people bikeshedding the proposal on just that poin=
t.=20
> (If and when we do get unified call syntax, you'll get this sort of thin=
g=20
> for free anyway). =20
>
>
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7500b776-f42e-4418-9be8-d13a286bbbe0%40isocpp.or=
g.
------=_Part_6626_138596179.1481744590277
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm not sure how container_traits would improve the ex=
isting situation?<br><br>With regard to call syntax, I'll be perfectly =
straight with you and say that I don't actually give half a damn about =
the non-member function. I understand it, I don't object to it, I think=
it would be helpful to a lot of people, and it certainly wouldn't caus=
e me any trouble, but what I actually want for myself is the std::vector me=
mber function. The problem is that the feedback I've been getting is ov=
erwhelmingly biased in the other direction, with people saying that they=
9;re okay with a non-member size_bytes but not a member one. I strongly sus=
pect that if I split the proposal the result would be the non-member gettin=
g support and the member (which is my only motivation here) getting shot do=
wn.<br><br>Unified call syntax wouldn't really solve this problem becau=
se the function that got created would already be non-member. It would also=
disadvantage the non-member crowd since they'd still have to write a s=
ize_bytes for C arrays if they wanted the full benefit.<br><br>Unless I'=
;m misunderstanding something?<br><br>On Wednesday, December 14, 2016 at 10=
:57:02 AM UTC-8, David Hollman wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div dir=3D"ltr">Chiming in a bit late here, but it seems to me the =
more modern and general way to approach this and related problems would be =
to introduce a std::container_traits<> class template, right?<div><br=
></div><div>Either way, I would personally avoid adding both the instance m=
ethod and the free function versions to the same proposal =E2=80=94 I agree=
that it's better with both, but people have really strong opinions on =
unified call syntax, and I think you'll get people bikeshedding the pro=
posal on just that point. =C2=A0(If and when we do get unified call syntax,=
you'll get this sort of thing for free anyway). =C2=A0<br><br><br></di=
v></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7500b776-f42e-4418-9be8-d13a286bbbe0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7500b776-f42e-4418-9be8-d13a286bbbe0=
%40isocpp.org</a>.<br />
------=_Part_6626_138596179.1481744590277--
------=_Part_6625_798869478.1481744590276--
.
Author: khatharr@gmail.com
Date: Fri, 16 Dec 2016 10:49:09 -0800 (PST)
Raw View
------=_Part_1113_821681970.1481914149565
Content-Type: multipart/alternative;
boundary="----=_Part_1114_1164292790.1481914149566"
------=_Part_1114_1164292790.1481914149566
Content-Type: text/plain; charset=UTF-8
How would it actually be used in code, though?
I mean what would it look like to pass the contents of std::vector<BIGPOD>
to abiFunc(void* buffer, size_t bytes)?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/19d3621b-81f0-49a5-8c9a-d5800a2fbd1f%40isocpp.org.
------=_Part_1114_1164292790.1481914149566
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">How would it actually be used in code, though?<br><br>I me=
an what would it look like to pass the contents of std::vector<BIGPOD>=
; to abiFunc(void* buffer, size_t bytes)?<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/19d3621b-81f0-49a5-8c9a-d5800a2fbd1f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/19d3621b-81f0-49a5-8c9a-d5800a2fbd1f=
%40isocpp.org</a>.<br />
------=_Part_1114_1164292790.1481914149566--
------=_Part_1113_821681970.1481914149565--
.
Author: David Hollman <david.s.hollman@gmail.com>
Date: Fri, 16 Dec 2016 15:26:57 -0500
Raw View
--f403045f7494772e5f0543cc6505
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
// usually my_vect would come from a template parameter in generic
contextusing my_vect =3D std::vector<BIGPOD>;using my_vect_traits =3D
std::container_traits<my_vect>;/*...*/
my_vect v;/*...*/
abiFunc(v.data(), my_vect_traits::size_bytes(v));
=E2=80=8B
Like I said, not claiming it's less verbose, just that it's more general,
follows an existing pattern, and (thus) might increase consensus.
On Fri, Dec 16, 2016 at 1:49 PM, <khatharr@gmail.com> wrote:
> How would it actually be used in code, though?
>
> I mean what would it look like to pass the contents of std::vector<BIGPOD=
>
> to abiFunc(void* buffer, size_t bytes)?
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/19d3621b-81f0-49a5-
> 8c9a-d5800a2fbd1f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/19d3621b-81=
f0-49a5-8c9a-d5800a2fbd1f%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CA%2BpHZ4UHneVoz-Y%3D-Z5zjdYZvPWqBEziHcopikNd0Tu=
1r2hCLQ%40mail.gmail.com.
--f403045f7494772e5f0543cc6505
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div></div><div class=3D"markdown-here-wrapper" style=3D""=
><pre style=3D"font-size:0.85em;font-family:Consolas,Inconsolata,Courier,mo=
nospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code class=3D"hl=
js language-c++" style=3D"font-size:0.85em;font-family:Consolas,Inconsolata=
,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap=
;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border=
-radius:3px;display:inline;white-space:pre;overflow:auto;border-radius:3px;=
border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!importa=
nt;display:block;overflow-x:auto;padding:0.5em;color:rgb(51,51,51);backgrou=
nd:rgb(248,248,248)"><span class=3D"hljs-comment" style=3D"color:rgb(153,15=
3,136);font-style:italic">// usually my_vect would come from a template par=
ameter in generic context</span>
<span class=3D"hljs-keyword" style=3D"color:rgb(51,51,51);font-weight:bold"=
>using</span> my_vect =3D std::<span class=3D"hljs-stl_container"><span cla=
ss=3D"hljs-built_in" style=3D"color:rgb(0,134,179)">vector</span><BIGPOD=
></span>;
<span class=3D"hljs-keyword" style=3D"color:rgb(51,51,51);font-weight:bold"=
>using</span> my_vect_traits =3D std::container_traits<my_vect>;
<span class=3D"hljs-comment" style=3D"color:rgb(153,153,136);font-style:ita=
lic">/*...*/</span>
my_vect v;
<span class=3D"hljs-comment" style=3D"color:rgb(153,153,136);font-style:ita=
lic">/*...*/</span>
abiFunc(v.data(), my_vect_traits::size_bytes(v));
</code></pre>
<div title=3D"MDH:PGRpdj5gYGBjKys8L2Rpdj48ZGl2Pi8vIHVzdWFsbHkgbXlfdmVjdCB3b=
3VsZCBjb21lIGZyb20g
YSB0ZW1wbGF0ZSBwYXJhbWV0ZXIgaW4gZ2VuZXJpYyBjb250ZXh0PC9kaXY+dXNpbmcgbXlfdmV=
j
dCA9IHN0ZDo6dmVjdG9yJmx0O0JJR1BPRCZndDs7PGRpdj51c2luZyBteV92ZWN0X3RyYWl0cyA=
9
IHN0ZDo6Y29udGFpbmVyX3RyYWl0cyZsdDtteV92ZWN0Jmd0Ozs8L2Rpdj48ZGl2Pi8qLi4uKi8=
8
L2Rpdj48ZGl2Pm15X3ZlY3Qgdjs8L2Rpdj48ZGl2Pi8qLi4uKi88L2Rpdj48ZGl2PmFiaUZ1bmM=
o
di5kYXRhKCksIG15X3ZlY3RfdHJhaXRzOjpzaXplX2J5dGVzKHYpKTs8L2Rpdj48ZGl2PmBgYDw=
v
ZGl2PjxkaXY+PC9kaXY+" style=3D"height:0;width:0;max-height:0;max-width:0;ov=
erflow:hidden;font-size:0em;padding:0;margin:0">=E2=80=8B</div></div><div><=
br></div><div>Like I said, not claiming it's less verbose, just that it=
's more general, follows an existing pattern, and (thus) might increase=
consensus.</div><div><br></div></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Fri, Dec 16, 2016 at 1:49 PM, <span dir=3D"ltr">&l=
t;<a href=3D"mailto:khatharr@gmail.com" target=3D"_blank">khatharr@gmail.co=
m</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
How would it actually be used in code, though?<br><br>I mean what would it =
look like to pass the contents of std::vector<BIGPOD> to abiFunc(void=
* buffer, size_t bytes)?<br></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/19d3621b-81f0-49a5-8c9a-d5800a2fbd1f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/19d3=
621b-81f0-49a5-<wbr>8c9a-d5800a2fbd1f%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BpHZ4UHneVoz-Y%3D-Z5zjdYZvPWqBEzi=
HcopikNd0Tu1r2hCLQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BpHZ4UHne=
Voz-Y%3D-Z5zjdYZvPWqBEziHcopikNd0Tu1r2hCLQ%40mail.gmail.com</a>.<br />
--f403045f7494772e5f0543cc6505--
.
Author: Khatharr Malkavian <khatharr@gmail.com>
Date: Fri, 16 Dec 2016 12:32:40 -0800
Raw View
--001a11406076bad19a0543cc78a4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Ah. Yeah, that's sort of the opposite of what I'm after.
Thank you for explaining it though.
On Fri, Dec 16, 2016 at 12:26 PM, David Hollman <david.s.hollman@gmail.com>
wrote:
> // usually my_vect would come from a template parameter in generic contex=
tusing my_vect =3D std::vector<BIGPOD>;using my_vect_traits =3D std::contai=
ner_traits<my_vect>;/*...*/
> my_vect v;/*...*/
> abiFunc(v.data(), my_vect_traits::size_bytes(v));
>
> =E2=80=8B
>
> Like I said, not claiming it's less verbose, just that it's more general,
> follows an existing pattern, and (thus) might increase consensus.
>
>
> On Fri, Dec 16, 2016 at 1:49 PM, <khatharr@gmail.com> wrote:
>
>> How would it actually be used in code, though?
>>
>> I mean what would it look like to pass the contents of
>> std::vector<BIGPOD> to abiFunc(void* buffer, size_t bytes)?
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/19d3621b-81f0-49a5-8c9a-
>> d5800a2fbd1f%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/19d3621b-8=
1f0-49a5-8c9a-d5800a2fbd1f%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/ocenjHqb8KI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CA%2BpHZ4UHneVoz-Y%3D-
> Z5zjdYZvPWqBEziHcopikNd0Tu1r2hCLQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BpHZ4UH=
neVoz-Y%3D-Z5zjdYZvPWqBEziHcopikNd0Tu1r2hCLQ%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAJ87Lq1c6q15_9Fuoh%3DZfH4ugM5nQg5EU5u_3bG6Py2s4=
Yzf6Q%40mail.gmail.com.
--001a11406076bad19a0543cc78a4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Ah. Yeah, that's sort of the opposite of what I&#=
39;m after.<br><br></div>Thank you for explaining it though.<br></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Dec 16, 2016 a=
t 12:26 PM, David Hollman <span dir=3D"ltr"><<a href=3D"mailto:david.s.h=
ollman@gmail.com" target=3D"_blank">david.s.hollman@gmail.com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div=
class=3D"m_-3315205157545318549markdown-here-wrapper"><pre style=3D"font-s=
ize:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em=
;line-height:1.2em;margin:1.2em 0px"><code class=3D"m_-3315205157545318549h=
ljs m_-3315205157545318549language-c++" style=3D"font-size:0.85em;font-fami=
ly:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3=
em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:=
rgb(248,248,248);border-radius:3px;display:inline;white-space:pre-wrap;over=
flow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em=
0.7em;display:block!important;display:block;overflow-x:auto;padding:0.5em;=
color:rgb(51,51,51);background:rgb(248,248,248)"><span class=3D"m_-33152051=
57545318549hljs-comment" style=3D"color:rgb(153,153,136);font-style:italic"=
>// usually my_vect would come from a template parameter in generic context=
</span>
<span class=3D"m_-3315205157545318549hljs-keyword" style=3D"color:rgb(51,51=
,51);font-weight:bold">using</span> my_vect =3D std::<span class=3D"m_-3315=
205157545318549hljs-stl_container"><span class=3D"m_-3315205157545318549hlj=
s-built_in" style=3D"color:rgb(0,134,179)">vector</span><BIGPOD></spa=
n>;
<span class=3D"m_-3315205157545318549hljs-keyword" style=3D"color:rgb(51,51=
,51);font-weight:bold">using</span> my_vect_traits =3D std::container_trait=
s<my_vect><wbr>;
<span class=3D"m_-3315205157545318549hljs-comment" style=3D"color:rgb(153,1=
53,136);font-style:italic">/*...*/</span>
my_vect v;
<span class=3D"m_-3315205157545318549hljs-comment" style=3D"color:rgb(153,1=
53,136);font-style:italic">/*...*/</span>
abiFunc(v.data(), my_vect_traits::size_bytes(v))<wbr>;
</code></pre>
<div title=3D"MDH:PGRpdj5gYGBjKys8L2Rpdj48ZGl2Pi8vIHVzdWFsbHkgbXlfdmVjdCB3b=
3VsZCBjb21lIGZyb20g
YSB0ZW1wbGF0ZSBwYXJhbWV0ZXIgaW4gZ2VuZXJpYyBjb250ZXh0PC9kaXY+dXNpbmcgbXlfdmV=
j
dCA9IHN0ZDo6dmVjdG9yJmx0O0JJR1BPRCZndDs7PGRpdj51c2luZyBteV92ZWN0X3RyYWl0cyA=
9
IHN0ZDo6Y29udGFpbmVyX3RyYWl0cyZsdDtteV92ZWN0Jmd0Ozs8L2Rpdj48ZGl2Pi8qLi4uKi8=
8
L2Rpdj48ZGl2Pm15X3ZlY3Qgdjs8L2Rpdj48ZGl2Pi8qLi4uKi88L2Rpdj48ZGl2PmFiaUZ1bmM=
o
di5kYXRhKCksIG15X3ZlY3RfdHJhaXRzOjpzaXplX2J5dGVzKHYpKTs8L2Rpdj48ZGl2PmBgYDw=
v
ZGl2PjxkaXY+PC9kaXY+" style=3D"height:0;width:0;max-height:0;max-width:0;ov=
erflow:hidden;font-size:0em;padding:0;margin:0">=E2=80=8B</div></div><div><=
br></div><div>Like I said, not claiming it's less verbose, just that it=
's more general, follows an existing pattern, and (thus) might increase=
consensus.</div><div><br></div></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Fri, Dec 16, 2016 at 1:49 PM, <span dir=3D"ltr">&l=
t;<a href=3D"mailto:khatharr@gmail.com" target=3D"_blank">khatharr@gmail.co=
m</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
How would it actually be used in code, though?<br><br>I mean what would it =
look like to pass the contents of std::vector<BIGPOD> to abiFunc(void=
* buffer, size_t bytes)?<span class=3D"HOEnZb"><font color=3D"#888888"><br>=
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888"><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/19d3621b-81f0-49a5-8c9a-d5800a2fbd1f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/19d3=
621b-81f0-49a5-8c9a-<wbr>d5800a2fbd1f%40isocpp.org</a>.<br>
</font></span></blockquote></div><span class=3D"HOEnZb"><font color=3D"#888=
888"><br></font></span></div><span class=3D"HOEnZb"><font color=3D"#888888"=
>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/ocenjHqb8KI/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/o=
cenjHqb8KI/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BpHZ4UHneVoz-Y%3D-Z5zjdYZvPWqBEzi=
HcopikNd0Tu1r2hCLQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CA%2BpHZ4UHneVoz-Y%<wbr>3D-<wbr>Z5zjdYZvPWqBEziHcopikNd0=
Tu1r2h<wbr>CLQ%40mail.gmail.com</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJ87Lq1c6q15_9Fuoh%3DZfH4ugM5nQg5EU5=
u_3bG6Py2s4Yzf6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJ87Lq1c6q15_9=
Fuoh%3DZfH4ugM5nQg5EU5u_3bG6Py2s4Yzf6Q%40mail.gmail.com</a>.<br />
--001a11406076bad19a0543cc78a4--
.
Author: David Hollman <david.s.hollman@gmail.com>
Date: Fri, 16 Dec 2016 15:44:34 -0500
Raw View
--001a11403414725cf90543cca4e5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Can you elaborate? I must have gotten confused somewhere along the way.
You=E2=80=99re looking for a uniform, standards-consistent way to get the s=
ize of
the data underlying a container (i.e., the equivalent of v.size() *
sizeof(decltype(v)::value_type), but more general). Something like
container_traits is the most standards-consistent way of doing so IMHO, for
the reasons I outlined previously. If you=E2=80=99re looking to do somethin=
g in
fewer characters or keystrokes, that=E2=80=99s not really how standards ope=
rate
AFAIK.
=E2=80=8B
What am I missing? What's "opposite" here?
On Fri, Dec 16, 2016 at 3:32 PM, Khatharr Malkavian <khatharr@gmail.com>
wrote:
> Ah. Yeah, that's sort of the opposite of what I'm after.
>
> Thank you for explaining it though.
>
> On Fri, Dec 16, 2016 at 12:26 PM, David Hollman <david.s.hollman@gmail.co=
m
> > wrote:
>
>> // usually my_vect would come from a template parameter in generic conte=
xtusing my_vect =3D std::vector<BIGPOD>;using my_vect_traits =3D std::conta=
iner_traits<my_vect>;/*...*/
>> my_vect v;/*...*/
>> abiFunc(v.data(), my_vect_traits::size_bytes(v));
>>
>> =E2=80=8B
>>
>> Like I said, not claiming it's less verbose, just that it's more general=
,
>> follows an existing pattern, and (thus) might increase consensus.
>>
>>
>> On Fri, Dec 16, 2016 at 1:49 PM, <khatharr@gmail.com> wrote:
>>
>>> How would it actually be used in code, though?
>>>
>>> I mean what would it look like to pass the contents of
>>> std::vector<BIGPOD> to abiFunc(void* buffer, size_t bytes)?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/19d3621b-81f0-49a5-8c9a-d5800
>>> a2fbd1f%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/19d3621b-=
81f0-49a5-8c9a-d5800a2fbd1f%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit https://groups.google.com/a/is
>> ocpp.org/d/topic/std-proposals/ocenjHqb8KI/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/CA%2BpHZ4UHneVoz-Y%3D-Z5zjdYZ
>> vPWqBEziHcopikNd0Tu1r2hCLQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BpHZ4U=
HneVoz-Y%3D-Z5zjdYZvPWqBEziHcopikNd0Tu1r2hCLQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>> .
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAJ87Lq1c6q15_9Fuoh%3DZfH4ugM5nQg5EU5u_
> 3bG6Py2s4Yzf6Q%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJ87Lq1c6q=
15_9Fuoh%3DZfH4ugM5nQg5EU5u_3bG6Py2s4Yzf6Q%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CA%2BpHZ4VL9qdOG%3D88xLajmkNH%3DMLnExX87yz3KJgOE=
0V5qFNhbQ%40mail.gmail.com.
--001a11403414725cf90543cca4e5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"markdown-here-wrapper" style=3D""><p style=
=3D"margin:0px 0px 1.2em!important">Can you elaborate? I must have gotten =
confused somewhere along the way. You=E2=80=99re looking for a uniform, st=
andards-consistent way to get the size of the data underlying a container (=
i.e., the equivalent of <code style=3D"font-size:0.85em;font-family:Consola=
s,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-s=
pace:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,24=
8,248);border-radius:3px;display:inline">v.size() * sizeof(decltype(v)::val=
ue_type)</code>, but more general). Something like <code style=3D"font-siz=
e:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15=
em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234)=
;background-color:rgb(248,248,248);border-radius:3px;display:inline">contai=
ner_traits</code> is the most standards-consistent way of doing so IMHO, fo=
r the reasons I outlined previously. If you=E2=80=99re looking to do som=
ething in fewer characters or keystrokes, that=E2=80=99s not really how sta=
ndards operate AFAIK.</p>
<div title=3D"MDH:Q2FuIHlvdSBlbGFib3JhdGU/IMKgSSBtdXN0IGhhdmUgZ290dGVuIGNvb=
mZ1c2VkIHNvbWV3aGVy
ZSBhbG9uZyB0aGUgd2F5LiDCoFlvdSdyZSBsb29raW5nIGZvciBhIHVuaWZvcm0sIHN0YW5kYXJ=
k
cy1jb25zaXN0ZW50IHdheSB0byBnZXQgdGhlIHNpemUgb2YgdGhlIGRhdGEgdW5kZXJseWluZyB=
h
IGNvbnRhaW5lciAoaS5lLiwgdGhlIGVxdWl2YWxlbnQgb2YgYHYuc2l6ZSgpICogc2l6ZW9mKGR=
l
Y2x0eXBlKHYpOjp2YWx1ZV90eXBlKWAsIGJ1dCBtb3JlIGdlbmVyYWwpLiDCoFNvbWV0aGluZyB=
s
aWtlIGBjb250YWluZXJfdHJhaXRzYCBpcyB0aGUgbW9zdCBzdGFuZGFyZHMtY29uc2lzdGVudCB=
3
YXkgb2YgZG9pbmcgc28gSU1ITy4gwqDCoMKgSWYgeW91J3JlIGxvb2tpbmcgdG8gZG8gc29tZXR=
o
aW5nIGluIGZld2VyIGNoYXJhY3RlcnMgb3Iga2V5c3Ryb2tlcywgdGhhdCdzIG5vdCByZWFsbHk=
g
aG93IHN0YW5kYXJkcyBvcGVyYXRlIEFGQUlLLg=3D=3D" style=3D"height:0;width:0;max=
-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0">=E2=
=80=8B</div></div><div><div><div>What am I missing?=C2=A0 What's "=
opposite" here?</div></div></div></div><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">On Fri, Dec 16, 2016 at 3:32 PM, Khatharr Malkav=
ian <span dir=3D"ltr"><<a href=3D"mailto:khatharr@gmail.com" target=3D"_=
blank">khatharr@gmail.com</a>></span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div>Ah. Yeah, that's sort of the opposite of w=
hat I'm after.<br><br></div>Thank you for explaining it though.<br></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div class=
=3D"h5">On Fri, Dec 16, 2016 at 12:26 PM, David Hollman <span dir=3D"ltr">&=
lt;<a href=3D"mailto:david.s.hollman@gmail.com" target=3D"_blank">david.s.h=
ollman@gmail.com</a>></span> wrote:<br></div></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div><div class=3D"h5"><div dir=3D"ltr"><div></div><div class=3D"=
m_3064546350434320416m_-3315205157545318549markdown-here-wrapper"><pre styl=
e=3D"font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;fo=
nt-size:1em;line-height:1.2em;margin:1.2em 0px"><code class=3D"m_3064546350=
434320416m_-3315205157545318549hljs m_3064546350434320416m_-331520515754531=
8549language-c++" style=3D"font-size:0.85em;font-family:Consolas,Inconsolat=
a,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wra=
p;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);borde=
r-radius:3px;display:inline;white-space:pre-wrap;overflow:auto;border-radiu=
s:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!i=
mportant;display:block;overflow-x:auto;padding:0.5em;color:rgb(51,51,51);ba=
ckground:rgb(248,248,248)"><span class=3D"m_3064546350434320416m_-331520515=
7545318549hljs-comment" style=3D"color:rgb(153,153,136);font-style:italic">=
// usually my_vect would come from a template parameter in generic context<=
/span>
<span class=3D"m_3064546350434320416m_-3315205157545318549hljs-keyword" sty=
le=3D"color:rgb(51,51,51);font-weight:bold">using</span> my_vect =3D std::<=
span class=3D"m_3064546350434320416m_-3315205157545318549hljs-stl_container=
"><span class=3D"m_3064546350434320416m_-3315205157545318549hljs-built_in" =
style=3D"color:rgb(0,134,179)">vector</span><BIGPOD></span>;
<span class=3D"m_3064546350434320416m_-3315205157545318549hljs-keyword" sty=
le=3D"color:rgb(51,51,51);font-weight:bold">using</span> my_vect_traits =3D=
std::container_traits<my_vect><wbr>;
<span class=3D"m_3064546350434320416m_-3315205157545318549hljs-comment" sty=
le=3D"color:rgb(153,153,136);font-style:italic">/*...*/</span>
my_vect v;
<span class=3D"m_3064546350434320416m_-3315205157545318549hljs-comment" sty=
le=3D"color:rgb(153,153,136);font-style:italic">/*...*/</span>
abiFunc(v.data(), my_vect_traits::size_bytes(v))<wbr>;
</code></pre>
<div title=3D"MDH:PGRpdj5gYGBjKys8L2Rpdj48ZGl2Pi8vIHVzdWFsbHkgbXlfdmVjdCB3b=
3VsZCBjb21lIGZyb20g
YSB0ZW1wbGF0ZSBwYXJhbWV0ZXIgaW4gZ2VuZXJpYyBjb250ZXh0PC9kaXY+dXNpbmcgbXlfdmV=
j
dCA9IHN0ZDo6dmVjdG9yJmx0O0JJR1BPRCZndDs7PGRpdj51c2luZyBteV92ZWN0X3RyYWl0cyA=
9
IHN0ZDo6Y29udGFpbmVyX3RyYWl0cyZsdDtteV92ZWN0Jmd0Ozs8L2Rpdj48ZGl2Pi8qLi4uKi8=
8
L2Rpdj48ZGl2Pm15X3ZlY3Qgdjs8L2Rpdj48ZGl2Pi8qLi4uKi88L2Rpdj48ZGl2PmFiaUZ1bmM=
o
di5kYXRhKCksIG15X3ZlY3RfdHJhaXRzOjpzaXplX2J5dGVzKHYpKTs8L2Rpdj48ZGl2PmBgYDw=
v
ZGl2PjxkaXY+PC9kaXY+" style=3D"height:0;width:0;max-height:0;max-width:0;ov=
erflow:hidden;font-size:0em;padding:0;margin:0">=E2=80=8B</div></div><div><=
br></div><div>Like I said, not claiming it's less verbose, just that it=
's more general, follows an existing pattern, and (thus) might increase=
consensus.</div><div><br></div></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Fri, Dec 16, 2016 at 1:49 PM, <span dir=3D"ltr">&l=
t;<a href=3D"mailto:khatharr@gmail.com" target=3D"_blank">khatharr@gmail.co=
m</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
How would it actually be used in code, though?<br><br>I mean what would it =
look like to pass the contents of std::vector<BIGPOD> to abiFunc(void=
* buffer, size_t bytes)?<span class=3D"m_3064546350434320416HOEnZb"><font c=
olor=3D"#888888"><br></font></span></div><span class=3D"m_30645463504343204=
16HOEnZb"><font color=3D"#888888"><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/19d3621b-81f0-49a5-8c9a-d5800a2fbd1f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/19d3=
621b-81f0-49a5-8c9a-d5800<wbr>a2fbd1f%40isocpp.org</a>.<br>
</font></span></blockquote></div><span class=3D"m_3064546350434320416HOEnZb=
"><font color=3D"#888888"><br></font></span></div></div></div><span class=
=3D"m_3064546350434320416HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/ocenjHqb8KI/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/o=
cenjHqb8KI/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.<span class=3D""><br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BpHZ4UHneVoz-Y%3D-Z5zjdYZvPWqBEzi=
HcopikNd0Tu1r2hCLQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/=
std-proposals<wbr>/CA%2BpHZ4UHneVoz-Y%3D-Z5zjdYZ<wbr>vPWqBEziHcopikNd0Tu1r2=
hCLQ%<wbr>40mail.gmail.com</a>.<br>
</font></span></blockquote></div><br></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJ87Lq1c6q15_9Fuoh%3DZfH4ugM5nQg5EU5=
u_3bG6Py2s4Yzf6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CAJ87Lq1c6q15_9Fuoh%<wbr>3DZfH4ugM5nQg5EU5u_<wbr>3bG6Py2s4=
Yzf6Q%40mail.gmail.<wbr>com</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BpHZ4VL9qdOG%3D88xLajmkNH%3DMLnEx=
X87yz3KJgOE0V5qFNhbQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BpHZ4VL=
9qdOG%3D88xLajmkNH%3DMLnExX87yz3KJgOE0V5qFNhbQ%40mail.gmail.com</a>.<br />
--001a11403414725cf90543cca4e5--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Fri, 16 Dec 2016 16:27:17 -0500
Raw View
--f403045deb6407e6060543cd3c4e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
A traits-based approach seems nicer to existing ABIs and more extensible
too. It seems much more in line with C++ practice that adding member
functions to some types. I'm also curious to know why there's resistance to
this.
2016-12-16 15:44 GMT-05:00 David Hollman <david.s.hollman@gmail.com>:
> Can you elaborate? I must have gotten confused somewhere along the way.
> You=E2=80=99re looking for a uniform, standards-consistent way to get the=
size of
> the data underlying a container (i.e., the equivalent of v.size() *
> sizeof(decltype(v)::value_type), but more general). Something like
> container_traits is the most standards-consistent way of doing so IMHO,
> for the reasons I outlined previously. If you=E2=80=99re looking to do so=
mething in
> fewer characters or keystrokes, that=E2=80=99s not really how standards o=
perate
> AFAIK.
> =E2=80=8B
> What am I missing? What's "opposite" here?
>
> On Fri, Dec 16, 2016 at 3:32 PM, Khatharr Malkavian <khatharr@gmail.com>
> wrote:
>
>> Ah. Yeah, that's sort of the opposite of what I'm after.
>>
>> Thank you for explaining it though.
>>
>> On Fri, Dec 16, 2016 at 12:26 PM, David Hollman <
>> david.s.hollman@gmail.com> wrote:
>>
>>> // usually my_vect would come from a template parameter in generic cont=
extusing my_vect =3D std::vector<BIGPOD>;using my_vect_traits =3D std::cont=
ainer_traits<my_vect>;/*...*/
>>> my_vect v;/*...*/
>>> abiFunc(v.data(), my_vect_traits::size_bytes(v));
>>>
>>> =E2=80=8B
>>>
>>> Like I said, not claiming it's less verbose, just that it's more
>>> general, follows an existing pattern, and (thus) might increase consens=
us.
>>>
>>>
>>> On Fri, Dec 16, 2016 at 1:49 PM, <khatharr@gmail.com> wrote:
>>>
>>>> How would it actually be used in code, though?
>>>>
>>>> I mean what would it look like to pass the contents of
>>>> std::vector<BIGPOD> to abiFunc(void* buffer, size_t bytes)?
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to std-proposals+unsubscribe@isocpp.org.
>>>> To post to this group, send email to std-proposals@isocpp.org.
>>>> To view this discussion on the web visit https://groups.google.com/a/i=
s
>>>> ocpp.org/d/msgid/std-proposals/19d3621b-81f0-49a5-8c9a-d5800
>>>> a2fbd1f%40isocpp.org
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/19d3621b=
-81f0-49a5-8c9a-d5800a2fbd1f%40isocpp.org?utm_medium=3Demail&utm_source=3Df=
ooter>
>>>> .
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/a/is
>>> ocpp.org/d/topic/std-proposals/ocenjHqb8KI/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/CA%2BpHZ4UHneVoz-Y%3D-Z5zjdYZ
>>> vPWqBEziHcopikNd0Tu1r2hCLQ%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BpHZ4=
UHneVoz-Y%3D-Z5zjdYZvPWqBEziHcopikNd0Tu1r2hCLQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>>> .
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/CAJ87Lq1c6q15_9Fuoh%3DZfH4ugM
>> 5nQg5EU5u_3bG6Py2s4Yzf6Q%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJ87Lq1c6=
q15_9Fuoh%3DZfH4ugM5nQg5EU5u_3bG6Py2s4Yzf6Q%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>> .
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CA%2BpHZ4VL9qdOG%3D88xLajmkNH%
> 3DMLnExX87yz3KJgOE0V5qFNhbQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BpHZ4VL=
9qdOG%3D88xLajmkNH%3DMLnExX87yz3KJgOE0V5qFNhbQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKiZDp2y8RikdfbQHm%2BNCZ5h%3DV-mzvBtcEOCxNwUkWe=
gJ%3DEfGA%40mail.gmail.com.
--f403045deb6407e6060543cd3c4e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A traits-based approach seems nicer to existing ABIs and m=
ore extensible too. It seems much more in line with C++ practice that addin=
g member functions to some types. I'm also curious to know why there=
9;s resistance to this.<br></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">2016-12-16 15:44 GMT-05:00 David Hollman <span dir=3D"ltr"=
><<a href=3D"mailto:david.s.hollman@gmail.com" target=3D"_blank">david.s=
..hollman@gmail.com</a>></span>:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"m_5038008279786130385markdown-here-wrapper"><p sty=
le=3D"margin:0px 0px 1.2em!important">Can you elaborate? I must have gotte=
n confused somewhere along the way. You=E2=80=99re looking for a uniform, =
standards-consistent way to get the size of the data underlying a container=
(i.e., the equivalent of <code style=3D"font-size:0.85em;font-family:Conso=
las,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white=
-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,=
248,248);border-radius:3px;display:inline">v.size() * sizeof(decltype(v)::v=
alue_<wbr>type)</code>, but more general). Something like <code style=3D"f=
ont-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0=
px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,2=
34,234);background-color:rgb(248,248,248);border-radius:3px;display:inline"=
>container_traits</code> is the most standards-consistent way of doing so I=
MHO, for the reasons I outlined previously. If you=E2=80=99re looking to=
do something in fewer characters or keystrokes, that=E2=80=99s not really =
how standards operate AFAIK.</p>
<div title=3D"MDH:Q2FuIHlvdSBlbGFib3JhdGU/IMKgSSBtdXN0IGhhdmUgZ290dGVuIGNvb=
mZ1c2VkIHNvbWV3aGVy
ZSBhbG9uZyB0aGUgd2F5LiDCoFlvdSdyZSBsb29raW5nIGZvciBhIHVuaWZvcm0sIHN0YW5kYXJ=
k
cy1jb25zaXN0ZW50IHdheSB0byBnZXQgdGhlIHNpemUgb2YgdGhlIGRhdGEgdW5kZXJseWluZyB=
h
IGNvbnRhaW5lciAoaS5lLiwgdGhlIGVxdWl2YWxlbnQgb2YgYHYuc2l6ZSgpICogc2l6ZW9mKGR=
l
Y2x0eXBlKHYpOjp2YWx1ZV90eXBlKWAsIGJ1dCBtb3JlIGdlbmVyYWwpLiDCoFNvbWV0aGluZyB=
s
aWtlIGBjb250YWluZXJfdHJhaXRzYCBpcyB0aGUgbW9zdCBzdGFuZGFyZHMtY29uc2lzdGVudCB=
3
YXkgb2YgZG9pbmcgc28gSU1ITy4gwqDCoMKgSWYgeW91J3JlIGxvb2tpbmcgdG8gZG8gc29tZXR=
o
aW5nIGluIGZld2VyIGNoYXJhY3RlcnMgb3Iga2V5c3Ryb2tlcywgdGhhdCdzIG5vdCByZWFsbHk=
g
aG93IHN0YW5kYXJkcyBvcGVyYXRlIEFGQUlLLg=3D=3D" style=3D"height:0;width:0;max=
-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0">=E2=
=80=8B</div></div><div><div><div>What am I missing?=C2=A0 What's "=
opposite" here?</div></div></div></div><div><div class=3D"h5"><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Dec 16, 2016 at 3=
:32 PM, Khatharr Malkavian <span dir=3D"ltr"><<a href=3D"mailto:khatharr=
@gmail.com" target=3D"_blank">khatharr@gmail.com</a>></span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Ah. Yeah, that's so=
rt of the opposite of what I'm after.<br><br></div>Thank you for explai=
ning it though.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote"><div><div class=3D"m_5038008279786130385h5">On Fri, Dec 16, 2016 at=
12:26 PM, David Hollman <span dir=3D"ltr"><<a href=3D"mailto:david.s.ho=
llman@gmail.com" target=3D"_blank">david.s.hollman@gmail.com</a>></span>=
wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"m_=
5038008279786130385h5"><div dir=3D"ltr"><div></div><div class=3D"m_50380082=
79786130385m_3064546350434320416m_-3315205157545318549markdown-here-wrapper=
"><pre style=3D"font-size:0.85em;font-family:Consolas,Inconsolata,Courier,m=
onospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code class=3D"m=
_5038008279786130385m_3064546350434320416m_-3315205157545318549hljs m_50380=
08279786130385m_3064546350434320416m_-3315205157545318549language-c++" styl=
e=3D"font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;ma=
rgin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb=
(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:i=
nline;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid=
rgb(204,204,204);padding:0.5em 0.7em;display:block!important;display:block=
;overflow-x:auto;padding:0.5em;color:rgb(51,51,51);background:rgb(248,248,2=
48)"><span class=3D"m_5038008279786130385m_3064546350434320416m_-3315205157=
545318549hljs-comment" style=3D"color:rgb(153,153,136);font-style:italic">/=
/ usually my_vect would come from a template parameter in generic context</=
span>
<span class=3D"m_5038008279786130385m_3064546350434320416m_-331520515754531=
8549hljs-keyword" style=3D"color:rgb(51,51,51);font-weight:bold">using</spa=
n> my_vect =3D std::<span class=3D"m_5038008279786130385m_30645463504343204=
16m_-3315205157545318549hljs-stl_container"><span class=3D"m_50380082797861=
30385m_3064546350434320416m_-3315205157545318549hljs-built_in" style=3D"col=
or:rgb(0,134,179)">vector</span><BIGPOD></span>;
<span class=3D"m_5038008279786130385m_3064546350434320416m_-331520515754531=
8549hljs-keyword" style=3D"color:rgb(51,51,51);font-weight:bold">using</spa=
n> my_vect_traits =3D std::container_traits<my_vect><wbr>;
<span class=3D"m_5038008279786130385m_3064546350434320416m_-331520515754531=
8549hljs-comment" style=3D"color:rgb(153,153,136);font-style:italic">/*...*=
/</span>
my_vect v;
<span class=3D"m_5038008279786130385m_3064546350434320416m_-331520515754531=
8549hljs-comment" style=3D"color:rgb(153,153,136);font-style:italic">/*...*=
/</span>
abiFunc(v.data(), my_vect_traits::size_bytes(v))<wbr>;
</code></pre>
<div title=3D"MDH:PGRpdj5gYGBjKys8L2Rpdj48ZGl2Pi8vIHVzdWFsbHkgbXlfdmVjdCB3b=
3VsZCBjb21lIGZyb20g
YSB0ZW1wbGF0ZSBwYXJhbWV0ZXIgaW4gZ2VuZXJpYyBjb250ZXh0PC9kaXY+dXNpbmcgbXlfdmV=
j
dCA9IHN0ZDo6dmVjdG9yJmx0O0JJR1BPRCZndDs7PGRpdj51c2luZyBteV92ZWN0X3RyYWl0cyA=
9
IHN0ZDo6Y29udGFpbmVyX3RyYWl0cyZsdDtteV92ZWN0Jmd0Ozs8L2Rpdj48ZGl2Pi8qLi4uKi8=
8
L2Rpdj48ZGl2Pm15X3ZlY3Qgdjs8L2Rpdj48ZGl2Pi8qLi4uKi88L2Rpdj48ZGl2PmFiaUZ1bmM=
o
di5kYXRhKCksIG15X3ZlY3RfdHJhaXRzOjpzaXplX2J5dGVzKHYpKTs8L2Rpdj48ZGl2PmBgYDw=
v
ZGl2PjxkaXY+PC9kaXY+" style=3D"height:0;width:0;max-height:0;max-width:0;ov=
erflow:hidden;font-size:0em;padding:0;margin:0">=E2=80=8B</div></div><div><=
br></div><div>Like I said, not claiming it's less verbose, just that it=
's more general, follows an existing pattern, and (thus) might increase=
consensus.</div><div><br></div></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Fri, Dec 16, 2016 at 1:49 PM, <span dir=3D"ltr">&l=
t;<a href=3D"mailto:khatharr@gmail.com" target=3D"_blank">khatharr@gmail.co=
m</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
How would it actually be used in code, though?<br><br>I mean what would it =
look like to pass the contents of std::vector<BIGPOD> to abiFunc(void=
* buffer, size_t bytes)?<span class=3D"m_5038008279786130385m_3064546350434=
320416HOEnZb"><font color=3D"#888888"><br></font></span></div><span class=
=3D"m_5038008279786130385m_3064546350434320416HOEnZb"><font color=3D"#88888=
8"><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/19d3621b-81f0-49a5-8c9a-d5800a2fbd1f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/19d3=
621b-81f0-49a5-8c9a-d5800<wbr>a2fbd1f%40isocpp.org</a>.<br>
</font></span></blockquote></div><span class=3D"m_5038008279786130385m_3064=
546350434320416HOEnZb"><font color=3D"#888888"><br></font></span></div></di=
v></div><span class=3D"m_5038008279786130385m_3064546350434320416HOEnZb"><f=
ont color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/ocenjHqb8KI/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/o=
cenjHqb8KI/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.<span><br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BpHZ4UHneVoz-Y%3D-Z5zjdYZvPWqBEzi=
HcopikNd0Tu1r2hCLQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/=
std-proposals<wbr>/CA%2BpHZ4UHneVoz-Y%3D-Z5zjdYZ<wbr>vPWqBEziHcopikNd0Tu1r2=
hCLQ%40m<wbr>ail.gmail.com</a>.<br>
</font></span></blockquote></div><br></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJ87Lq1c6q15_9Fuoh%3DZfH4ugM5nQg5EU5=
u_3bG6Py2s4Yzf6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CAJ87Lq1c6q15_9Fuoh%3DZfH4ugM<wbr>5nQg5EU5u_3bG6Py2s4Yzf6Q=
%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BpHZ4VL9qdOG%3D88xLajmkNH%3DMLnEx=
X87yz3KJgOE0V5qFNhbQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgi=
d/std-<wbr>proposals/CA%2BpHZ4VL9qdOG%<wbr>3D88xLajmkNH%<wbr>3DMLnExX87yz3K=
JgOE0V5qFNhbQ%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2y8RikdfbQHm%2BNCZ5h%3DV-mzvBt=
cEOCxNwUkWegJ%3DEfGA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2y8R=
ikdfbQHm%2BNCZ5h%3DV-mzvBtcEOCxNwUkWegJ%3DEfGA%40mail.gmail.com</a>.<br />
--f403045deb6407e6060543cd3c4e--
.
Author: khatharr@gmail.com
Date: Fri, 16 Dec 2016 13:34:02 -0800 (PST)
Raw View
------=_Part_2204_717914948.1481924042546
Content-Type: multipart/alternative;
boundary="----=_Part_2205_874431770.1481924042546"
------=_Part_2205_874431770.1481924042546
Content-Type: text/plain; charset=UTF-8
I'm after an explicit lack of auxiliary objects or interpretive gymnastics
in order to do something that simply makes sense and is overwhelmingly the
responsibility of the specific containers in question.
Keystrokes is a small part of it, and I don't find that to be insignificant
because C++ is having an *increasingly severe* problem in that regard:
v.size_bytes()
std::container_traits<std::vector<BIGPOD>>::size_bytes(v)
The much larger part, however, is that it's patently ridiculous that vector
and array don't already have this function and it shouldn't require any
external action to achieve it. I don't want to think about a span, a
decltype, a traits object, or anything else. I just want the container to
stop being a pain in my ass.
This isn't breaking any existing pattern, it's following the pattern
established by the existing member functions. All of the containers
discussed have .data() members and .size() members that are fantastic to
work with. The existence of the .data() function screams for a
..size_bytes(), and I'm really puzzled as to why it didn't happen back in
C++11. This is clearly the container's own responsibility.
gsl::span (which has .data()) has a .size_bytes() member (it's so popular
it even has an alias). If it makes sense for span then would it not make
sense for the existing contiguous containers?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/91151065-21d2-476f-878f-e0ea8b3bac60%40isocpp.org.
------=_Part_2205_874431770.1481924042546
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm after an explicit lack of auxiliary objects or int=
erpretive gymnastics in order to do something that simply makes sense and i=
s overwhelmingly the responsibility of the specific containers in question.=
<br><br>Keystrokes is a small part of it, and I don't find that to be i=
nsignificant because C++ is having an <i>increasingly severe</i> problem in=
that regard:<br><div style=3D"background-color: rgb(250, 250, 250); border=
-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflo=
w-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div=
class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
..</span><span style=3D"color: #000;" class=3D"styled-by-prettify">size_byte=
s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>std</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">container_traits</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">vector</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">BIGPOD</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">>>::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">size_bytes</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">v</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan></div></code></div><br>The much larger part, however, is that it's =
patently ridiculous that vector and array don't already have this funct=
ion and it shouldn't require any external action to achieve it. I don&#=
39;t want to think about a span, a decltype, a traits object, or anything e=
lse. I just want the container to stop being a pain in my ass.<br><br>This =
isn't breaking any existing pattern, it's following the pattern est=
ablished by the existing member functions. All of the containers discussed =
have .data() members and .size() members that are fantastic to work with. T=
he existence of the .data() function screams for a .size_bytes(), and I'=
;m really puzzled as to why it didn't happen back in C++11. This is cle=
arly the container's own responsibility.<br><br>gsl::span (which has .d=
ata()) has a .size_bytes() member (it's so popular it even has an alias=
). If it makes sense for span then would it not make sense for the existing=
contiguous containers?<br><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/91151065-21d2-476f-878f-e0ea8b3bac60%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/91151065-21d2-476f-878f-e0ea8b3bac60=
%40isocpp.org</a>.<br />
------=_Part_2205_874431770.1481924042546--
------=_Part_2204_717914948.1481924042546--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 16 Dec 2016 14:24:38 -0800 (PST)
Raw View
------=_Part_843_1450429328.1481927078630
Content-Type: multipart/alternative;
boundary="----=_Part_844_2008037264.1481927078630"
------=_Part_844_2008037264.1481927078630
Content-Type: text/plain; charset=UTF-8
On Friday, December 16, 2016 at 4:27:20 PM UTC-5, Patrice Roy wrote:
>
> A traits-based approach seems nicer to existing ABIs and more extensible
> too. It seems much more in line with C++ practice that adding member
> functions to some types. I'm also curious to know why there's resistance to
> this.
>
But it's not in-line with C++ practice. Or rather, C++ practice is
schizophrenic on this point.
There are many container-like operations that aren't done based on traits:
`begin/end` from C++11, `cbegin/cend` from C++14, `size` from C++17, and so
on.
`traits` types seem to have gone out of fashion for extensibility; modern
preferences seem to be using non-member functions functions that
potentially forward to appropriate member functions.
And it's not like there's a lot of C++ code out there using traits classes.
Really, when was the last time you used `pointer_traits`? `iterator_traits`
and `allocator_traits` are probably the most frequently used ones. And
generally we are more likely to need to write specializations of them for a
new iterator or allocator, rather than writing code that directly uses them.
Traits-based interfaces are uncommon for C++ programmers, cumbersome to
use, and are generally not things that non-experts (or at least,
non-experienced) C++ programmers use.
I really don't see what's wrong with following the `begin/end/size`
pattern: member functions with generic non-member forwarding versions. This
is a common C++ idiom; it may have its faults, but it's there and it's
something you can't use any of the container classes without having at
least some knowledge of them.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/49ac442f-1def-4766-9ca3-75c2fe8bdf8b%40isocpp.org.
------=_Part_844_2008037264.1481927078630
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 16, 2016 at 4:27:20 PM UTC-5, Patrice =
Roy 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">A t=
raits-based approach seems nicer to existing ABIs and more extensible too. =
It seems much more in line with C++ practice that adding member functions t=
o some types. I'm also curious to know why there's resistance to th=
is.</div></blockquote><div><br>But it's not in-line with C++ practice. =
Or rather, C++ practice is schizophrenic on this point.<br><br>There are ma=
ny container-like operations that aren't done based on traits: `begin/e=
nd` from C++11, `cbegin/cend` from C++14, `size` from C++17, and so on.<br>=
<br>`traits` types seem to have gone out of fashion for extensibility; mode=
rn preferences seem to be using non-member functions functions that potenti=
ally forward to appropriate member functions.<br><br>And it's not like =
there's a lot of C++ code out there using traits classes. Really, when =
was the last time you used `pointer_traits`? `iterator_traits` and `allocat=
or_traits` are probably the most frequently used ones. And generally we are=
more likely to need to write specializations of them for a new iterator or=
allocator, rather than writing code that directly uses them.<br><br>Traits=
-based interfaces are uncommon for C++ programmers, cumbersome to use, and =
are generally not things that non-experts (or at least, non-experienced) C+=
+ programmers use.<br><br>I really don't see what's wrong with foll=
owing the `begin/end/size` pattern: member functions with generic non-membe=
r forwarding versions. This is a common C++ idiom; it may have its faults, =
but it's there and it's something you can't use any of the cont=
ainer classes without having at least some knowledge of them.<br></div></di=
v>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/49ac442f-1def-4766-9ca3-75c2fe8bdf8b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/49ac442f-1def-4766-9ca3-75c2fe8bdf8b=
%40isocpp.org</a>.<br />
------=_Part_844_2008037264.1481927078630--
------=_Part_843_1450429328.1481927078630--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Sun, 18 Dec 2016 11:25:11 -0500
Raw View
--f403045e31584d73b80543f13f4f
Content-Type: text/plain; charset=UTF-8
Agreed; I think the reason there seems to be a hiatus of sorts on the
nonmember function approach is the unified function call syntax proposals
that might make them redundant fast. That being said, since there's no
size_bytes member function in the first place, why not. size_bytes(v) is
(ever-so-slightly) shorter than v.size_bytes() anyway.
2016-12-16 17:24 GMT-05:00 Nicol Bolas <jmckesson@gmail.com>:
> On Friday, December 16, 2016 at 4:27:20 PM UTC-5, Patrice Roy wrote:
>>
>> A traits-based approach seems nicer to existing ABIs and more extensible
>> too. It seems much more in line with C++ practice that adding member
>> functions to some types. I'm also curious to know why there's resistance to
>> this.
>>
>
> But it's not in-line with C++ practice. Or rather, C++ practice is
> schizophrenic on this point.
>
> There are many container-like operations that aren't done based on traits:
> `begin/end` from C++11, `cbegin/cend` from C++14, `size` from C++17, and so
> on.
>
> `traits` types seem to have gone out of fashion for extensibility; modern
> preferences seem to be using non-member functions functions that
> potentially forward to appropriate member functions.
>
> And it's not like there's a lot of C++ code out there using traits
> classes. Really, when was the last time you used `pointer_traits`?
> `iterator_traits` and `allocator_traits` are probably the most frequently
> used ones. And generally we are more likely to need to write
> specializations of them for a new iterator or allocator, rather than
> writing code that directly uses them.
>
> Traits-based interfaces are uncommon for C++ programmers, cumbersome to
> use, and are generally not things that non-experts (or at least,
> non-experienced) C++ programmers use.
>
> I really don't see what's wrong with following the `begin/end/size`
> pattern: member functions with generic non-member forwarding versions. This
> is a common C++ idiom; it may have its faults, but it's there and it's
> something you can't use any of the container classes without having at
> least some knowledge of them.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/49ac442f-1def-4766-
> 9ca3-75c2fe8bdf8b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/49ac442f-1def-4766-9ca3-75c2fe8bdf8b%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0bL5c%3DX%2BF8JNi66URhXd6hbdA2cCvfmjc7eGcnhs3uhQ%40mail.gmail.com.
--f403045e31584d73b80543f13f4f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Agreed; I think the reason there seems to be a hiatus of s=
orts on the nonmember function approach is the unified function call syntax=
proposals that might make them redundant fast. That being said, since ther=
e's no size_bytes member function in the first place, why not. size_byt=
es(v) is (ever-so-slightly) shorter than v.size_bytes() anyway.<br></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-12-16 17:24 GM=
T-05:00 Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail=
..com" target=3D"_blank">jmckesson@gmail.com</a>></span>:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Friday, December 16=
, 2016 at 4:27:20 PM UTC-5, Patrice Roy wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr">A traits-based approach seems nicer to existing=
ABIs and more extensible too. It seems much more in line with C++ practice=
that adding member functions to some types. I'm also curious to know w=
hy there's resistance to this.</div></blockquote></span><div><br>But it=
's not in-line with C++ practice. Or rather, C++ practice is schizophre=
nic on this point.<br><br>There are many container-like operations that are=
n't done based on traits: `begin/end` from C++11, `cbegin/cend` from C+=
+14, `size` from C++17, and so on.<br><br>`traits` types seem to have gone =
out of fashion for extensibility; modern preferences seem to be using non-m=
ember functions functions that potentially forward to appropriate member fu=
nctions.<br><br>And it's not like there's a lot of C++ code out the=
re using traits classes. Really, when was the last time you used `pointer_t=
raits`? `iterator_traits` and `allocator_traits` are probably the most freq=
uently used ones. And generally we are more likely to need to write special=
izations of them for a new iterator or allocator, rather than writing code =
that directly uses them.<br><br>Traits-based interfaces are uncommon for C+=
+ programmers, cumbersome to use, and are generally not things that non-exp=
erts (or at least, non-experienced) C++ programmers use.<br><br>I really do=
n't see what's wrong with following the `begin/end/size` pattern: m=
ember functions with generic non-member forwarding versions. This is a comm=
on C++ idiom; it may have its faults, but it's there and it's somet=
hing you can't use any of the container classes without having at least=
some knowledge of them.<br></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/49ac442f-1def-4766-9ca3-75c2fe8bdf8b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/49ac=
442f-1def-4766-<wbr>9ca3-75c2fe8bdf8b%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0bL5c%3DX%2BF8JNi66URhXd6hbdA2=
cCvfmjc7eGcnhs3uhQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0bL5c%=
3DX%2BF8JNi66URhXd6hbdA2cCvfmjc7eGcnhs3uhQ%40mail.gmail.com</a>.<br />
--f403045e31584d73b80543f13f4f--
.