Topic: [EXTERNAL] T.size_bytes() and std::size_bytes()
Author: "Hollman, David S" <dshollm@sandia.gov>
Date: Fri, 16 Dec 2016 18:40:41 +0000
Raw View
--_000_D4796AEFA4B5dshollmsandiagov_
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Well, you're right in the sense that `container_traits` introduces an third=
, far more verbose option into the mix:
```
std::container_traits<T>::size_bytes(T const&);
```
....or something like that.
But the point I'm driving at is that it could put less strain on the member=
-vs-nonmember discussion, since for objects it can (by default) look for th=
e member function, then the non-member function (or vice versa, whatever pe=
ople want), whereas for, e.g., C-style arrays the default can be to look fo=
r the nonmember function. Then the overall default behavior could be overr=
idden by fully or partially specializing `container_traits` for a given (po=
tentially user-defined) type.
I realize that this doesn't fully resolve anything, but it provides several=
clear advantages:
* It provides an analogous and uniform place to get other things: for =
instance, `value_type`. You could now have `std::container_traits<T>::valu=
e_type` do something sensible in a generic context where T could be a C-sty=
le array. (There's a lot more that could go here, too.)
* Sort of a sub point of this: I personally think it's better to pro=
vide a uniform expansion point than to start throwing around free functions=
for everything that could cause ADL issues in the future. It doesn't feel=
like providing free functions for every new feature in the standard librar=
y is very scalable (evidence: error spew from something like `cout << unsup=
ported_type();`). Also, providing "free" specialized type traits directly =
in the namespace `std` (e.g., something like `std::value_type<T>::type` and=
the accompanying alias `std::value_type_t<T>`) doesn't very scalable or su=
stainable.
* Uniformity with other parts of the standard library: The standard li=
brary interface to allocators, for instance, could have specified the inter=
face to the generic `allocate(...)`, `deallocate(...)`, etc. as free functi=
ons, but went with a traits class instead. I do realize that other proposa=
ls (e.g., executors) and some current features (e.g., `begin()` and `end()`=
) go in the opposite direction and that the uniformity argument doesn't hol=
d sway with everyone, but I think it's worth considering.
Does this clear up some of what I was thinking? I don't know if this helps=
at all, and I realize it's mostly just more bikeshedding, but maybe it wil=
l help bring more people on board (and if not, forget it).
From: "khatharr@gmail.com<mailto:khatharr@gmail.com>" <khatharr@gmail.com<m=
ailto:khatharr@gmail.com>>
Reply-To: "std-proposals@isocpp.org<mailto:std-proposals@isocpp.org>" <std-=
proposals@isocpp.org<mailto:std-proposals@isocpp.org>>
Date: Wednesday, December 14, 2016 at 11:43 AM
To: ISO C++ Standard - Future Proposals <std-proposals@isocpp.org<mailto:st=
d-proposals@isocpp.org>>
Cc: "khatharr@gmail.com<mailto:khatharr@gmail.com>" <khatharr@gmail.com<mai=
lto:khatharr@gmail.com>>
Subject: [EXTERNAL] [std-proposals] Re: T.size_bytes() and std::size_bytes(=
)
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 tha=
t I don't actually give half a damn about the non-member function. I unders=
tand it, I don't object to it, I think it would be helpful to a lot of peop=
le, and it certainly wouldn't cause me any trouble, but what I actually wan=
t for myself is the std::vector member function. The problem is that the fe=
edback I've been getting is overwhelmingly biased in the other direction, w=
ith people saying that they're okay with a non-member size_bytes but not a =
member one. I strongly suspect that if I split the proposal the result woul=
d be the non-member getting support and the member (which is my only motiva=
tion here) getting shot down.
Unified call syntax wouldn't really solve this problem because the function=
that got created would already be non-member. It would also disadvantage t=
he non-member crowd since they'd still have to write a size_bytes for C arr=
ays 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 general =
way to approach this and related problems would be to introduce a std::cont=
ainer_traits<> class template, right?
Either way, I would personally avoid adding both the instance method and th=
e free function versions to the same proposal - I agree that it's better wi=
th both, but people have really strong opinions on unified call syntax, and=
I think you'll get people bikeshedding the proposal on just that point. (=
If and when we do get unified call syntax, you'll get this sort of thing fo=
r free anyway).
--
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<mailto:std-proposals+unsubscri=
be@isocpp.org>.
To post to this group, send email to std-proposals@isocpp.org<mailto:std-pr=
oposals@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<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7500b776-f42=
e-4418-9be8-d13a286bbbe0%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoote=
r>.
--=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/D4796AEF.A4B5%25dshollm%40sandia.gov.
--_000_D4796AEFA4B5dshollmsandiagov_
Content-Type: text/html; charset=UTF-8
Content-ID: <1E7913E53ECB9841A9B4D45F69651FA7@sandia.gov>
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif;">
<div>
<div>Well, you're right in the sense that `container_traits` introduces an =
third, far more verbose option into the mix:</div>
<div>```</div>
<div>std::container_traits<T>::size_bytes(T const&);</div>
<div>```</div>
<div>...or something like that.</div>
<div><br>
</div>
<div>But the point I'm driving at is that it could put less strain on the m=
ember-vs-nonmember discussion, since for objects it can (by default) look f=
or the member function, then the non-member function (or vice versa, whatev=
er people want), whereas for, e.g.,
C-style arrays the default can be to look for the nonmember function. &nbs=
p;Then the overall default behavior could be overridden by fully or partial=
ly specializing `container_traits` for a given (potentially user-defined) t=
ype. </div>
<div><br>
</div>
<div>I realize that this doesn't fully resolve anything, but it provides se=
veral clear advantages: </div>
<ul>
<li>It provides an analogous and uniform place to get other things: f=
or instance, `value_type`. You could now have `std::container_traits&=
lt;T>::value_type` do something sensible in a generic context where T co=
uld be a C-style array. (There's a lot more that
could go here, too.)
<ul>
<li>Sort of a sub point of this: I personally think it's better to provide =
a uniform expansion point than to start throwing around free functions for =
everything that could cause ADL issues in the future. It doesn't feel=
like providing free functions for every
new feature in the standard library is very scalable (evidence: error spew=
from something like `cout << unsupported_type();`). Also, prov=
iding "free" specialized type traits directly in the namespace `s=
td` (e.g., something like `std::value_type<T>::type`
and the accompanying alias `std::value_type_t<T>`) doesn't very scal=
able or sustainable.</li></ul>
</li><li>Uniformity with other parts of the standard library: The sta=
ndard library interface to allocators, for instance, could have specified t=
he interface to the generic `allocate(...)`, `deallocate(...)`, etc. as fre=
e functions, but went with a traits class
instead. I do realize that other proposals (e.g., executors) and som=
e current features (e.g., `begin()` and `end()`) go in the opposite directi=
on and that the uniformity argument doesn't hold sway with everyone, but I =
think it's worth considering.</li></ul>
<div>Does this clear up some of what I was thinking? I don't know if =
this helps at all, and I realize it's mostly just more bikeshedding, but ma=
ybe it will help bring more people on board (and if not, forget it). <=
/div>
<div><br>
</div>
</div>
<div><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b=
lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:=
0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;=
BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style=3D"font-weight:bold">From: </span>"<a href=3D"mailto:khath=
arr@gmail.com">khatharr@gmail.com</a>" <<a href=3D"mailto:khatharr@=
gmail.com">khatharr@gmail.com</a>><br>
<span style=3D"font-weight:bold">Reply-To: </span>"<a href=3D"mailto:s=
td-proposals@isocpp.org">std-proposals@isocpp.org</a>" <<a href=3D"=
mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>><br>
<span style=3D"font-weight:bold">Date: </span>Wednesday, December 14, 2016 =
at 11:43 AM<br>
<span style=3D"font-weight:bold">To: </span>ISO C++ Standard - Futu=
re Proposals <<a href=3D"mailto:std-proposals@isocpp.org">std-proposals@=
isocpp.org</a>><br>
<span style=3D"font-weight:bold">Cc: </span>"<a href=3D"mailto:khathar=
r@gmail.com">khatharr@gmail.com</a>" <<a href=3D"mailto:khatharr@gm=
ail.com">khatharr@gmail.com</a>><br>
<span style=3D"font-weight:bold">Subject: </span>[EXTERNAL] [std-proposals]=
Re: T.size_bytes() and std::size_bytes()<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir=3D"ltr">I'm not sure how container_traits would improve the existi=
ng situation?<br>
<br>
With regard to call syntax, I'll be perfectly straight with you and say tha=
t I don't actually give half a damn about the non-member function. I unders=
tand it, I don't object to it, I think it would be helpful to a lot of peop=
le, and it certainly wouldn't cause
me any trouble, but what I actually want for myself is the std::vector mem=
ber function. The problem is that the feedback I've been getting is overwhe=
lmingly biased in the other direction, with people saying that they're okay=
with a non-member size_bytes but
not a member one. I strongly suspect that if I split the proposal the resu=
lt would be the non-member getting support and the member (which is my only=
motivation here) getting shot down.<br>
<br>
Unified call syntax wouldn't really solve this problem because the function=
that got created would already be non-member. It would also disadvantage t=
he non-member crowd since they'd still have to write a size_bytes for C arr=
ays 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" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">
<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 — 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 proposal on just that point. (If and when we do get=
unified call syntax, you'll get this sort of thing for free anyway).  =
;<br>
<br>
<br>
</div>
</div>
</blockquote>
</div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to
<a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals&#=
43;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>
</div>
</div>
</span>
</body>
</html>
<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/D4796AEF.A4B5%25dshollm%40sandia.gov?=
utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/a/isocpp.=
org/d/msgid/std-proposals/D4796AEF.A4B5%25dshollm%40sandia.gov</a>.<br />
--_000_D4796AEFA4B5dshollmsandiagov_--
.