Topic: Tuple helpers for tuple-like user defined classes ?
Author: Vincent Reverdy <vince.rev@gmail.com>
Date: Tue, 11 Feb 2014 06:52:09 -0800 (PST)
Raw View
------=_Part_528_14706413.1392130329245
Content-Type: text/plain; charset=UTF-8
I am currently implementing a library for HPC astrophysical simulations,
and I have been regularly confronted with a basic problem.
In my library, I tend to use a lot of what I call "tuple-like user defined
classes" for my fundamental generic types.
A "*tuple-like user defined class*", is a user defined class whose the main
data member is a std::tuple, a std::pair or a std::array and who gives a
direct access to it thanks to a member called data() (or any other name you
want if you think that this is inappropriate).
Then I have classes and functions that operates on these types. To provide
genericity, I generally provide two overloads: the first that operates on a
std::tuple, a std::pair or a std::array, and the second that operates on
any class who provides a data() member that decays into a std::tuple, a
std::pair or a std::array. I do not know whether it is a "standard
practice" or whether it will become a standard practice in codes based on
C++11 (which is my case), but I find this strategy very convenient for the
development of generic libraries.
But in order to provide full genericity in a more "standard" way, a very
simple thing could be added to the standard library: allowing std::get,
std::tuple_size and std::tuple_element to operate on tuple-like user
defined class.
What do you think to be the pros/cons to provide
- std::get
- std::tuple_size
- std::tuple_element
for types having a data() function on which they work?
(For example std::get<0>(x) would be the same as std::get<0>(x.data()))
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_528_14706413.1392130329245
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I am currently implementing a library for HPC astrophysica=
l simulations, and I have been regularly confronted with a basic problem.<b=
r><br>In my library, I tend to use a lot of what I call "tuple-like user de=
fined classes" for my fundamental generic types.<br>A "<i><b>tuple-like use=
r defined class</b></i>", is a user defined class whose the main data membe=
r is a <span style=3D"font-family: courier new,monospace;">std::tuple</span=
>, a <span style=3D"font-family: courier new,monospace;">std::pair</span> o=
r a <span style=3D"font-family: courier new,monospace;">std::array</span> a=
nd who gives a direct access to it thanks to a member called <span style=3D=
"font-family: courier new,monospace;">data()</span> (or any other name you =
want if you think that this is inappropriate). <br>Then I have classes and =
functions that operates on these types. To provide genericity, I generally =
provide two overloads: the first that operates on a <span style=3D"font-fam=
ily: courier new,monospace;">std::tuple</span>, a <span style=3D"font-famil=
y: courier new,monospace;">std::pair</span> or a <span style=3D"font-family=
: courier new,monospace;">std::array<span style=3D"font-family: arial,sans-=
serif;">, and the second that operates on any class who provides a </=
span>data()</span> member that decays into a <span style=3D"font-family: co=
urier new,monospace;">std::tuple</span>, a <span style=3D"font-family: cour=
ier new,monospace;">std::pair</span> or a <span style=3D"font-family: couri=
er new,monospace;">std::array<span style=3D"font-family: arial,sans-serif;"=
>. I do not know whether it is a "standard practice" or whether it will bec=
ome a standard practice in codes based on C++11 (which is my case), but I f=
ind this strategy very convenient for the development of generic libraries.=
<br>But in order to provide full genericity in a more "standard" way, a ver=
y simple thing could be added to the standard library: allowing <span style=
=3D"font-family: courier new,monospace;">std::get</span>, <span style=3D"fo=
nt-family: courier new,monospace;">std::tuple_size</span> and <span style=
=3D"font-family: courier new,monospace;">std::tuple_element </span>to opera=
te on tuple-like user defined class. <br><br>What do you think to be the pr=
os/cons to provide </span></span><br><span style=3D"font-family: courier ne=
w,monospace;"><span style=3D"font-family: arial,sans-serif;"><span style=3D=
"font-family: courier new,monospace;">- std::get<br></span></span></span><s=
pan style=3D"font-family: courier new,monospace;"><span style=3D"font-famil=
y: arial,sans-serif;"><span style=3D"font-family: courier new,monospace;">-=
std::tuple_size</span></span></span><br><span style=3D"font-family: courie=
r new,monospace;"><span style=3D"font-family: arial,sans-serif;"><span styl=
e=3D"font-family: courier new,monospace;">- std::tuple_element</span></span=
></span><br>for types having a <span style=3D"font-family: courier new,mono=
space;">data()<span style=3D"font-family: arial,sans-serif;"> function on w=
hich they work?</span></span><br><br>(For example <span style=3D"font-famil=
y: courier new,monospace;">std::get<0>(x)</span> would be the same as=
<span style=3D"font-family: courier new,monospace;">std::get<0>(x.da=
ta())</span>)<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_528_14706413.1392130329245--
.
Author: Geoffrey Romer <gromer@google.com>
Date: Tue, 11 Feb 2014 08:31:53 -0800
Raw View
--001a113ab29e70618e04f223fee7
Content-Type: text/plain; charset=UTF-8
You're already allowed to specialize ::std templates for user-defined
types, so std::tuple_size and std::tuple_element effectively already
support this. std::get is a bit more annoying: it's an ordinary function,
not a metafunction, so ideally you'd use argument-dependent lookup: instead
of calling std::get<N>(foo), just call get<N>(foo), and C++ will choose the
version of get() declared in the namespace of foo's type (or a parent
namespace, etc). The fly in the ointment is that in order to correctly
parse that function call, the compiler needs a "get<>()" function template
in the current namespace, even if it's not the one that will eventually be
chosen by ADL (otherwise there's an ambiguity about whether the angle
brackets are actually comparison operators). Something like this might be
the simplest workaround:
using std::get;
get<N>(foo);
That doesn't sit quite right with me, because it looks just like the usual
swap idiom, but it's done for completely different reasons.
I'd like tuple to be extended to support a more generic-friendly API. I
posted about this a couple weeks ago, but didn't get much uptake:
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/vNJ6VIP0PY0/discussion
..
On Tue, Feb 11, 2014 at 6:52 AM, Vincent Reverdy <vince.rev@gmail.com>wrote:
> I am currently implementing a library for HPC astrophysical simulations,
> and I have been regularly confronted with a basic problem.
>
> In my library, I tend to use a lot of what I call "tuple-like user defined
> classes" for my fundamental generic types.
> A "*tuple-like user defined class*", is a user defined class whose the
> main data member is a std::tuple, a std::pair or a std::array and who
> gives a direct access to it thanks to a member called data() (or any
> other name you want if you think that this is inappropriate).
> Then I have classes and functions that operates on these types. To provide
> genericity, I generally provide two overloads: the first that operates on a
> std::tuple, a std::pair or a std::array, and the second that operates on
> any class who provides a data() member that decays into a std::tuple, a
> std::pair or a std::array. I do not know whether it is a "standard
> practice" or whether it will become a standard practice in codes based on
> C++11 (which is my case), but I find this strategy very convenient for the
> development of generic libraries.
> But in order to provide full genericity in a more "standard" way, a very
> simple thing could be added to the standard library: allowing std::get,
> std::tuple_size and std::tuple_element to operate on tuple-like user
> defined class.
>
> What do you think to be the pros/cons to provide
> - std::get
> - std::tuple_size
> - std::tuple_element
> for types having a data() function on which they work?
>
> (For example std::get<0>(x) would be the same as std::get<0>(x.data()))
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113ab29e70618e04f223fee7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>You're already allowed to specialize ::std templa=
tes for user-defined types, so std::tuple_size and std::tuple_element effec=
tively already support this. std::get is a bit more annoying: it's an o=
rdinary function, not a metafunction, so ideally you'd use argument-dep=
endent lookup: instead of calling std::get<N>(foo), just call get<=
N>(foo), and C++ will choose the version of get() declared in the namesp=
ace of foo's type (or a parent namespace, etc). The fly in the ointment=
is that in order to correctly parse that function call, the compiler needs=
a "get<>()" function template in the current namespace, ev=
en if it's not the one that will eventually be chosen by ADL (otherwise=
there's an ambiguity about whether the angle brackets are actually com=
parison operators). Something like this might be the simplest workaround:<b=
r>
</div><div><br></div><div>using std::get;</div><div>get<N>(foo);</div=
><div><br></div><div>That doesn't sit quite right with me, because it l=
ooks just like the usual swap idiom, but it's done for completely diffe=
rent reasons.</div>
<div><br></div><div>I'd like tuple to be extended to support a more gen=
eric-friendly API. I posted about this a couple weeks ago, but didn't g=
et much uptake: <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/s=
td-proposals/vNJ6VIP0PY0/discussion">https://groups.google.com/a/isocpp.org=
/d/topic/std-proposals/vNJ6VIP0PY0/discussion</a>.=C2=A0</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue,=
Feb 11, 2014 at 6:52 AM, Vincent Reverdy <span dir=3D"ltr"><<a href=3D"=
mailto:vince.rev@gmail.com" target=3D"_blank">vince.rev@gmail.com</a>></=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I am currently implementing=
a library for HPC astrophysical simulations, and I have been regularly con=
fronted with a basic problem.<br>
<br>In my library, I tend to use a lot of what I call "tuple-like user=
defined classes" for my fundamental generic types.<br>A "<i><b>t=
uple-like user defined class</b></i>", is a user defined class whose t=
he main data member is a <span style=3D"font-family:courier new,monospace">=
std::tuple</span>, a <span style=3D"font-family:courier new,monospace">std:=
:pair</span> or a <span style=3D"font-family:courier new,monospace">std::ar=
ray</span> and who gives a direct access to it thanks to a member called <s=
pan style=3D"font-family:courier new,monospace">data()</span> (or any other=
name you want if you think that this is inappropriate). <br>
Then I have classes and functions that operates on these types. To provide =
genericity, I generally provide two overloads: the first that operates on a=
<span style=3D"font-family:courier new,monospace">std::tuple</span>, a <sp=
an style=3D"font-family:courier new,monospace">std::pair</span> or a <span =
style=3D"font-family:courier new,monospace">std::array<span style=3D"font-f=
amily:arial,sans-serif">, and the second that operates on any class who pro=
vides a=C2=A0 </span>data()</span> member that decays into a <span style=3D=
"font-family:courier new,monospace">std::tuple</span>, a <span style=3D"fon=
t-family:courier new,monospace">std::pair</span> or a <span style=3D"font-f=
amily:courier new,monospace">std::array<span style=3D"font-family:arial,san=
s-serif">. I do not know whether it is a "standard practice" or w=
hether it will become a standard practice in codes based on C++11 (which is=
my case), but I find this strategy very convenient for the development of =
generic libraries.<br>
But in order to provide full genericity in a more "standard" way,=
a very simple thing could be added to the standard library: allowing <span=
style=3D"font-family:courier new,monospace">std::get</span>, <span style=
=3D"font-family:courier new,monospace">std::tuple_size</span> and <span sty=
le=3D"font-family:courier new,monospace">std::tuple_element </span>to opera=
te on tuple-like user defined class. <br>
<br>What do you think to be the pros/cons to provide </span></span><br><spa=
n style=3D"font-family:courier new,monospace"><span style=3D"font-family:ar=
ial,sans-serif"><span style=3D"font-family:courier new,monospace">- std::ge=
t<br>
</span></span></span><span style=3D"font-family:courier new,monospace"><spa=
n style=3D"font-family:arial,sans-serif"><span style=3D"font-family:courier=
new,monospace">- std::tuple_size</span></span></span><br><span style=3D"fo=
nt-family:courier new,monospace"><span style=3D"font-family:arial,sans-seri=
f"><span style=3D"font-family:courier new,monospace">- std::tuple_element</=
span></span></span><br>
for types having a <span style=3D"font-family:courier new,monospace">data()=
<span style=3D"font-family:arial,sans-serif"> function on which they work?<=
/span></span><br><br>(For example <span style=3D"font-family:courier new,mo=
nospace">std::get<0>(x)</span> would be the same as <span style=3D"fo=
nt-family:courier new,monospace">std::get<0>(x.data())</span>)<span c=
lass=3D"HOEnZb"><font color=3D"#888888"><br>
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113ab29e70618e04f223fee7--
.
Author: Vincent Reverdy <vince.rev@gmail.com>
Date: Tue, 11 Feb 2014 08:56:46 -0800 (PST)
Raw View
------=_Part_418_27434669.1392137806302
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Thank you for the link to your post. I do not know the best solution, but I=
=20
would be happy to help on any proposal to provide a generic-friendly=20
interface to tuple-like classes. Your proposal would be to provide these=20
external functions/metafunctions as members, my proposal would be to=20
provide an overload/specialization for classes having a data() member=20
returning a tuple-like class (like std::begin() will call T::begin() if the=
=20
function exists). Do you know whether the expected concepts lite for C++17=
=20
include a unified concept for std::tuple, std::pair and std::array ?=20
Because if so, it could be worth to investigate an unified solution using=
=20
this concept.
Le mardi 11 f=C3=A9vrier 2014 17:31:53 UTC+1, Geoffrey Romer a =C3=A9crit :
>
> You're already allowed to specialize ::std templates for user-defined=20
> types, so std::tuple_size and std::tuple_element effectively already=20
> support this. std::get is a bit more annoying: it's an ordinary function,=
=20
> not a metafunction, so ideally you'd use argument-dependent lookup: inste=
ad=20
> of calling std::get<N>(foo), just call get<N>(foo), and C++ will choose t=
he=20
> version of get() declared in the namespace of foo's type (or a parent=20
> namespace, etc). The fly in the ointment is that in order to correctly=20
> parse that function call, the compiler needs a "get<>()" function templat=
e=20
> in the current namespace, even if it's not the one that will eventually b=
e=20
> chosen by ADL (otherwise there's an ambiguity about whether the angle=20
> brackets are actually comparison operators). Something like this might be=
=20
> the simplest workaround:
>
> using std::get;
> get<N>(foo);
>
> That doesn't sit quite right with me, because it looks just like the usua=
l=20
> swap idiom, but it's done for completely different reasons.
>
> I'd like tuple to be extended to support a more generic-friendly API. I=
=20
> posted about this a couple weeks ago, but didn't get much uptake:=20
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/vNJ6VIP0PY0/=
discussion
> .=20
>
>
> On Tue, Feb 11, 2014 at 6:52 AM, Vincent Reverdy <vinc...@gmail.com<javas=
cript:>
> > wrote:
>
>> I am currently implementing a library for HPC astrophysical simulations,=
=20
>> and I have been regularly confronted with a basic problem.
>>
>> In my library, I tend to use a lot of what I call "tuple-like user=20
>> defined classes" for my fundamental generic types.
>> A "*tuple-like user defined class*", is a user defined class whose the=
=20
>> main data member is a std::tuple, a std::pair or a std::array and who=20
>> gives a direct access to it thanks to a member called data() (or any=20
>> other name you want if you think that this is inappropriate).=20
>> Then I have classes and functions that operates on these types. To=20
>> provide genericity, I generally provide two overloads: the first that=20
>> operates on a std::tuple, a std::pair or a std::array, and the second=20
>> that operates on any class who provides a data() member that decays=20
>> into a std::tuple, a std::pair or a std::array. I do not know whether it=
=20
>> is a "standard practice" or whether it will become a standard practice i=
n=20
>> codes based on C++11 (which is my case), but I find this strategy very=
=20
>> convenient for the development of generic libraries.
>> But in order to provide full genericity in a more "standard" way, a very=
=20
>> simple thing could be added to the standard library: allowing std::get,=
=20
>> std::tuple_size and std::tuple_element to operate on tuple-like user=20
>> defined class.=20
>>
>> What do you think to be the pros/cons to provide=20
>> - std::get
>> - std::tuple_size
>> - std::tuple_element
>> for types having a data() function on which they work?
>>
>> (For example std::get<0>(x) would be the same as std::get<0>(x.data()))
>> =20
>> --=20
>> =20
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_418_27434669.1392137806302
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thank you for the link to your post. I do not know the bes=
t solution, but I would be happy to help on any proposal to provide a gener=
ic-friendly interface to tuple-like classes. Your proposal would be to prov=
ide these external functions/metafunctions as members, my proposal would be=
to provide an overload/specialization for classes having a data() member r=
eturning a tuple-like class (like std::begin() will call T::begin() if the =
function exists). Do you know whether the expected concepts lite for C++17 =
include a unified concept for std::tuple, std::pair and std::array ? Becaus=
e if so, it could be worth to investigate an unified solution using this co=
ncept.<br><br>Le mardi 11 f=C3=A9vrier 2014 17:31:53 UTC+1, Geoffrey Romer =
a =C3=A9crit :<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div>You're already allowed to specialize ::std templates for user-de=
fined types, so std::tuple_size and std::tuple_element effectively already =
support this. std::get is a bit more annoying: it's an ordinary function, n=
ot a metafunction, so ideally you'd use argument-dependent lookup: instead =
of calling std::get<N>(foo), just call get<N>(foo), and C++ wil=
l choose the version of get() declared in the namespace of foo's type (or a=
parent namespace, etc). The fly in the ointment is that in order to correc=
tly parse that function call, the compiler needs a "get<>()" function=
template in the current namespace, even if it's not the one that will even=
tually be chosen by ADL (otherwise there's an ambiguity about whether the a=
ngle brackets are actually comparison operators). Something like this might=
be the simplest workaround:<br>
</div><div><br></div><div>using std::get;</div><div>get<N>(foo);</div=
><div><br></div><div>That doesn't sit quite right with me, because it looks=
just like the usual swap idiom, but it's done for completely different rea=
sons.</div>
<div><br></div><div>I'd like tuple to be extended to support a more generic=
-friendly API. I posted about this a couple weeks ago, but didn't get much =
uptake: <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-propo=
sals/vNJ6VIP0PY0/discussion" target=3D"_blank" onmousedown=3D"this.href=3D'=
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/vNJ6VIP0PY0/di=
scussion';return true;" onclick=3D"this.href=3D'https://groups.google.com/a=
/isocpp.org/d/topic/std-proposals/vNJ6VIP0PY0/discussion';return true;">htt=
ps://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/vNJ6VIP=
0PY0/<wbr>discussion</a>. </div>
</div><div><br><br><div class=3D"gmail_quote">On Tue, Feb 11, 2014 at 6:52 =
AM, Vincent Reverdy <span dir=3D"ltr"><<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"y87RdAq2Ih8J" onmousedown=3D"this.href=3D=
'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return tru=
e;">vinc...@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I am currently implementing=
a library for HPC astrophysical simulations, and I have been regularly con=
fronted with a basic problem.<br>
<br>In my library, I tend to use a lot of what I call "tuple-like user defi=
ned classes" for my fundamental generic types.<br>A "<i><b>tuple-like user =
defined class</b></i>", is a user defined class whose the main data member =
is a <span style=3D"font-family:courier new,monospace">std::tuple</span>, a=
<span style=3D"font-family:courier new,monospace">std::pair</span> or a <s=
pan style=3D"font-family:courier new,monospace">std::array</span> and who g=
ives a direct access to it thanks to a member called <span style=3D"font-fa=
mily:courier new,monospace">data()</span> (or any other name you want if yo=
u think that this is inappropriate). <br>
Then I have classes and functions that operates on these types. To provide =
genericity, I generally provide two overloads: the first that operates on a=
<span style=3D"font-family:courier new,monospace">std::tuple</span>, a <sp=
an style=3D"font-family:courier new,monospace">std::pair</span> or a <span =
style=3D"font-family:courier new,monospace">std::array<span style=3D"font-f=
amily:arial,sans-serif">, and the second that operates on any class who pro=
vides a </span>data()</span> member that decays into a <span style=3D=
"font-family:courier new,monospace">std::tuple</span>, a <span style=3D"fon=
t-family:courier new,monospace">std::pair</span> or a <span style=3D"font-f=
amily:courier new,monospace">std::array<span style=3D"font-family:arial,san=
s-serif">. I do not know whether it is a "standard practice" or whether it =
will become a standard practice in codes based on C++11 (which is my case),=
but I find this strategy very convenient for the development of generic li=
braries.<br>
But in order to provide full genericity in a more "standard" way, a very si=
mple thing could be added to the standard library: allowing <span style=3D"=
font-family:courier new,monospace">std::get</span>, <span style=3D"font-fam=
ily:courier new,monospace">std::tuple_size</span> and <span style=3D"font-f=
amily:courier new,monospace">std::tuple_element </span>to operate on tuple-=
like user defined class. <br>
<br>What do you think to be the pros/cons to provide </span></span><br><spa=
n style=3D"font-family:courier new,monospace"><span style=3D"font-family:ar=
ial,sans-serif"><span style=3D"font-family:courier new,monospace">- std::ge=
t<br>
</span></span></span><span style=3D"font-family:courier new,monospace"><spa=
n style=3D"font-family:arial,sans-serif"><span style=3D"font-family:courier=
new,monospace">- std::tuple_size</span></span></span><br><span style=3D"fo=
nt-family:courier new,monospace"><span style=3D"font-family:arial,sans-seri=
f"><span style=3D"font-family:courier new,monospace">- std::tuple_element</=
span></span></span><br>
for types having a <span style=3D"font-family:courier new,monospace">data()=
<span style=3D"font-family:arial,sans-serif"> function on which they work?<=
/span></span><br><br>(For example <span style=3D"font-family:courier new,mo=
nospace">std::get<0>(x)</span> would be the same as <span style=3D"fo=
nt-family:courier new,monospace">std::get<0>(x.data())</span>)<span><=
font color=3D"#888888"><br>
</font></span></div><span><font color=3D"#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
y87RdAq2Ih8J" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"y87RdAq2Ih8J" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</font></span></blockquote></div><br></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_418_27434669.1392137806302--
.
Author: Geoffrey Romer <gromer@google.com>
Date: Tue, 11 Feb 2014 09:45:21 -0800
Raw View
--001a11c2d95a338e9704f22505fc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Feb 11, 2014 at 8:56 AM, Vincent Reverdy <vince.rev@gmail.com>wrote=
:
> Thank you for the link to your post. I do not know the best solution, but
> I would be happy to help on any proposal to provide a generic-friendly
> interface to tuple-like classes.
>
Realistically, I'm unlikely to be able to take the lead on this, but if
you're interested in drafting a proposal (
http://isocpp.org/std/submit-a-proposal), I'd be happy to provide feedback.
> Your proposal would be to provide these external functions/metafunctions
> as members, my proposal would be to provide an overload/specialization fo=
r
> classes having a data() member returning a tuple-like class (like
> std::begin() will call T::begin() if the function exists).
>
FWIW your proposed solution sounds like it's not general enough to be
standardized.
> Do you know whether the expected concepts lite for C++17 include a unifie=
d
> concept for std::tuple, std::pair and std::array ? Because if so, it coul=
d
> be worth to investigate an unified solution using this concept.
>
I don't know, but I very much doubt it, precisely because they're currently
so concept-hostile.
>
> Le mardi 11 f=C3=A9vrier 2014 17:31:53 UTC+1, Geoffrey Romer a =C3=A9crit=
:
>>
>> You're already allowed to specialize ::std templates for user-defined
>> types, so std::tuple_size and std::tuple_element effectively already
>> support this. std::get is a bit more annoying: it's an ordinary function=
,
>> not a metafunction, so ideally you'd use argument-dependent lookup: inst=
ead
>> of calling std::get<N>(foo), just call get<N>(foo), and C++ will choose =
the
>> version of get() declared in the namespace of foo's type (or a parent
>> namespace, etc). The fly in the ointment is that in order to correctly
>> parse that function call, the compiler needs a "get<>()" function templa=
te
>> in the current namespace, even if it's not the one that will eventually =
be
>> chosen by ADL (otherwise there's an ambiguity about whether the angle
>> brackets are actually comparison operators). Something like this might b=
e
>> the simplest workaround:
>>
>> using std::get;
>> get<N>(foo);
>>
>> That doesn't sit quite right with me, because it looks just like the
>> usual swap idiom, but it's done for completely different reasons.
>>
>> I'd like tuple to be extended to support a more generic-friendly API. I
>> posted about this a couple weeks ago, but didn't get much uptake:
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/vNJ6VIP0PY0=
/
>> discussion.
>>
>>
>> On Tue, Feb 11, 2014 at 6:52 AM, Vincent Reverdy <vinc...@gmail.com>wrot=
e:
>>
>>> I am currently implementing a library for HPC astrophysical simulations=
,
>>> and I have been regularly confronted with a basic problem.
>>>
>>> In my library, I tend to use a lot of what I call "tuple-like user
>>> defined classes" for my fundamental generic types.
>>> A "*tuple-like user defined class*", is a user defined class whose the
>>> main data member is a std::tuple, a std::pair or a std::array and who
>>> gives a direct access to it thanks to a member called data() (or any
>>> other name you want if you think that this is inappropriate).
>>> Then I have classes and functions that operates on these types. To
>>> provide genericity, I generally provide two overloads: the first that
>>> operates on a std::tuple, a std::pair or a std::array, and the second
>>> that operates on any class who provides a data() member that decays
>>> into a std::tuple, a std::pair or a std::array. I do not know whether
>>> it is a "standard practice" or whether it will become a standard practi=
ce
>>> in codes based on C++11 (which is my case), but I find this strategy ve=
ry
>>> convenient for the development of generic libraries.
>>> But in order to provide full genericity in a more "standard" way, a ver=
y
>>> simple thing could be added to the standard library: allowing std::get,
>>> std::tuple_size and std::tuple_element to operate on tuple-like user
>>> defined class.
>>>
>>> What do you think to be the pros/cons to provide
>>> - std::get
>>> - std::tuple_size
>>> - std::tuple_element
>>> for types having a data() function on which they work?
>>>
>>> (For example std::get<0>(x) would be the same as std::get<0>(x.data()))
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>>
>>> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
>>> proposals/.
>>>
>>
>> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c2d95a338e9704f22505fc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Feb 11, 2014 at 8:56 AM, Vincent Reverdy <span dir=3D"ltr"><<a h=
ref=3D"mailto:vince.rev@gmail.com" target=3D"_blank">vince.rev@gmail.com</a=
>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">Thank you for the link to your post. I do=
not know the best solution, but I would be happy to help on any proposal t=
o provide a generic-friendly interface to tuple-like classes.</div>
</blockquote><div><br></div><div>Realistically, I'm unlikely to be able=
to take the lead on this, but if you're interested in drafting a propo=
sal (<a href=3D"http://isocpp.org/std/submit-a-proposal">http://isocpp.org/=
std/submit-a-proposal</a>), I'd be happy to provide feedback.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"> Your proposal would be =
to provide these external functions/metafunctions as members, my proposal w=
ould be to provide an overload/specialization for classes having a data() m=
ember returning a tuple-like class (like std::begin() will call T::begin() =
if the function exists).</div>
</blockquote><div><br></div><div>FWIW your proposed solution sounds like it=
's not general enough to be standardized.</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex">
<div dir=3D"ltr"> Do you know whether the expected concepts lite for C++17 =
include a unified concept for std::tuple, std::pair and std::array ? Becaus=
e if so, it could be worth to investigate an unified solution using this co=
ncept.<br>
</div></blockquote><div><br></div><div>I don't know, but I very much do=
ubt it, precisely because they're currently so concept-hostile.</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">
<div dir=3D"ltr"><br>Le mardi 11 f=C3=A9vrier 2014 17:31:53 UTC+1, Geoffrey=
Romer a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex">
<div class=3D""><div dir=3D"ltr"><div>You're already allowed to special=
ize ::std templates for user-defined types, so std::tuple_size and std::tup=
le_element effectively already support this. std::get is a bit more annoyin=
g: it's an ordinary function, not a metafunction, so ideally you'd =
use argument-dependent lookup: instead of calling std::get<N>(foo), j=
ust call get<N>(foo), and C++ will choose the version of get() declar=
ed in the namespace of foo's type (or a parent namespace, etc). The fly=
in the ointment is that in order to correctly parse that function call, th=
e compiler needs a "get<>()" function template in the curre=
nt namespace, even if it's not the one that will eventually be chosen b=
y ADL (otherwise there's an ambiguity about whether the angle brackets =
are actually comparison operators). Something like this might be the simple=
st workaround:<br>
</div><div><br></div><div>using std::get;</div><div>get<N>(foo);</div=
><div><br></div><div>That doesn't sit quite right with me, because it l=
ooks just like the usual swap idiom, but it's done for completely diffe=
rent reasons.</div>
<div><br></div><div>I'd like tuple to be extended to support a more gen=
eric-friendly API. I posted about this a couple weeks ago, but didn't g=
et much uptake: <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/s=
td-proposals/vNJ6VIP0PY0/discussion" target=3D"_blank">https://groups.googl=
e.com/a/<u></u>isocpp.org/d/topic/std-<u></u>proposals/vNJ6VIP0PY0/<u></u>d=
iscussion</a>.=C2=A0</div>
</div></div><div><br><br><div class=3D"gmail_quote"><div class=3D"">On Tue,=
Feb 11, 2014 at 6:52 AM, Vincent Reverdy <span dir=3D"ltr"><<a>vinc...@=
gmail.com</a>></span> wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div class=3D""><div dir=3D"ltr">I am currently impl=
ementing a library for HPC astrophysical simulations, and I have been regul=
arly confronted with a basic problem.<br>
<br>In my library, I tend to use a lot of what I call "tuple-like user=
defined classes" for my fundamental generic types.<br>A "<i><b>t=
uple-like user defined class</b></i>", is a user defined class whose t=
he main data member is a <span style=3D"font-family:'courier new',m=
onospace">std::tuple</span>, a <span style=3D"font-family:'courier new&=
#39;,monospace">std::pair</span> or a <span style=3D"font-family:'couri=
er new',monospace">std::array</span> and who gives a direct access to i=
t thanks to a member called <span style=3D"font-family:'courier new'=
;,monospace">data()</span> (or any other name you want if you think that th=
is is inappropriate). <br>
Then I have classes and functions that operates on these types. To provide =
genericity, I generally provide two overloads: the first that operates on a=
<span style=3D"font-family:'courier new',monospace">std::tuple</sp=
an>, a <span style=3D"font-family:'courier new',monospace">std::pai=
r</span> or a <span style=3D"font-family:'courier new',monospace">s=
td::array<span style=3D"font-family:arial,sans-serif">, and the second that=
operates on any class who provides a=C2=A0 </span>data()</span> member tha=
t decays into a <span style=3D"font-family:'courier new',monospace"=
>std::tuple</span>, a <span style=3D"font-family:'courier new',mono=
space">std::pair</span> or a <span style=3D"font-family:'courier new=
9;,monospace">std::array<span style=3D"font-family:arial,sans-serif">. I do=
not know whether it is a "standard practice" or whether it will =
become a standard practice in codes based on C++11 (which is my case), but =
I find this strategy very convenient for the development of generic librari=
es.<br>
But in order to provide full genericity in a more "standard" way,=
a very simple thing could be added to the standard library: allowing <span=
style=3D"font-family:'courier new',monospace">std::get</span>, <sp=
an style=3D"font-family:'courier new',monospace">std::tuple_size</s=
pan> and <span style=3D"font-family:'courier new',monospace">std::t=
uple_element </span>to operate on tuple-like user defined class. <br>
<br>What do you think to be the pros/cons to provide </span></span><br><spa=
n style=3D"font-family:'courier new',monospace"><span style=3D"font=
-family:arial,sans-serif"><span style=3D"font-family:'courier new',=
monospace">- std::get<br>
</span></span></span><span style=3D"font-family:'courier new',monos=
pace"><span style=3D"font-family:arial,sans-serif"><span style=3D"font-fami=
ly:'courier new',monospace">- std::tuple_size</span></span></span><=
br>
<span style=3D"font-family:'courier new',monospace"><span style=3D"=
font-family:arial,sans-serif"><span style=3D"font-family:'courier new&#=
39;,monospace">- std::tuple_element</span></span></span><br>
for types having a <span style=3D"font-family:'courier new',monospa=
ce">data()<span style=3D"font-family:arial,sans-serif"> function on which t=
hey work?</span></span><br><br>(For example <span style=3D"font-family:'=
;courier new',monospace">std::get<0>(x)</span> would be the same =
as <span style=3D"font-family:'courier new',monospace">std::get<=
0>(x.data())</span>)<span><font color=3D"#888888"><br>
</font></span></div></div><span><font color=3D"#888888"><div class=3D"">
<p></p>
-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<div class=
=3D""><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></font></span></blockquote></div><br></div>
</blockquote></div><div class=3D""><div class=3D"h5">
<p></p>
-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2d95a338e9704f22505fc--
.
Author: Billy Donahue <billydonahue@google.com>
Date: Fri, 11 Sep 2015 11:53:01 -0700 (PDT)
Raw View
------=_Part_522_674164224.1441997581895
Content-Type: multipart/alternative;
boundary="----=_Part_523_875938997.1441997581896"
------=_Part_523_875938997.1441997581896
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
(apologies for thread necromancy)
On reading this, it occurs to me that the index for get() calls can be=20
"brought inside the parens", and specified as an ordinary integral_constant=
=20
tag parameter.
The advantage is that call sites would not have to work around the=20
grammatical ambiguity with relationals by "using std::get;" or other hacks.
i.e., an interesting solution to our problems could be:
namespace std {
template <typename Tup, typename IdxTag>
decltype(auto) get(Tup& tup, IdxTag tag) { return=20
get<IdxTag::value>(tup); }
}
void f1() {
auto t =3D std::make_tuple(42, std::string(""));
assert(get(t, std::integral_constant<size_t, 0>{}) =3D=3D 42);
assert(get(t, std::integral_constant<size_t, 1>{}) =3D=3D "");
}
void f2() {
auto t =3D yoyodyne::make_tuple(42, std::string(""));
assert(get(t, std::integral_constant<size_t, 0>{}) =3D=3D 42);
assert(get(t, std::integral_constant<size_t, 1>{}) =3D=3D "");
}
This extension could coexist with existing std:: and non-std definitions of=
=20
get.
Obviously there could be problems I'm missing.
I haven't tried this yet, but I'll work it out further if there's any=20
interest.
On Tuesday, February 11, 2014 at 12:45:21 PM UTC-5, Geoffrey Romer wrote:
>
>
> On Tue, Feb 11, 2014 at 8:56 AM, Vincent Reverdy <vinc...@gmail.com=20
> <javascript:>> wrote:
>
>> Thank you for the link to your post. I do not know the best solution, bu=
t=20
>> I would be happy to help on any proposal to provide a generic-friendly=
=20
>> interface to tuple-like classes.
>>
>
> Realistically, I'm unlikely to be able to take the lead on this, but if=
=20
> you're interested in drafting a proposal (
> http://isocpp.org/std/submit-a-proposal), I'd be happy to provide=20
> feedback.
> =20
>
>> Your proposal would be to provide these external functions/metafunctions=
=20
>> as members, my proposal would be to provide an overload/specialization f=
or=20
>> classes having a data() member returning a tuple-like class (like=20
>> std::begin() will call T::begin() if the function exists).
>>
>
> FWIW your proposed solution sounds like it's not general enough to be=20
> standardized.
> =20
>
>> Do you know whether the expected concepts lite for C++17 include a=20
>> unified concept for std::tuple, std::pair and std::array ? Because if so=
,=20
>> it could be worth to investigate an unified solution using this concept.
>>
>
> I don't know, but I very much doubt it, precisely because they're=20
> currently so concept-hostile.
> =20
>
>>
>> Le mardi 11 f=C3=A9vrier 2014 17:31:53 UTC+1, Geoffrey Romer a =C3=A9cri=
t :
>>>
>>> You're already allowed to specialize ::std templates for user-defined=
=20
>>> types, so std::tuple_size and std::tuple_element effectively already=20
>>> support this. std::get is a bit more annoying: it's an ordinary functio=
n,=20
>>> not a metafunction, so ideally you'd use argument-dependent lookup: ins=
tead=20
>>> of calling std::get<N>(foo), just call get<N>(foo), and C++ will choose=
the=20
>>> version of get() declared in the namespace of foo's type (or a parent=
=20
>>> namespace, etc). The fly in the ointment is that in order to correctly=
=20
>>> parse that function call, the compiler needs a "get<>()" function templ=
ate=20
>>> in the current namespace, even if it's not the one that will eventually=
be=20
>>> chosen by ADL (otherwise there's an ambiguity about whether the angle=
=20
>>> brackets are actually comparison operators). Something like this might =
be=20
>>> the simplest workaround:
>>>
>>> using std::get;
>>> get<N>(foo);
>>>
>>> That doesn't sit quite right with me, because it looks just like the=20
>>> usual swap idiom, but it's done for completely different reasons.
>>>
>>> I'd like tuple to be extended to support a more generic-friendly API. I=
=20
>>> posted about this a couple weeks ago, but didn't get much uptake:=20
>>> https://groups.google.com/a/isocpp.org/d/topic/std-
>>> proposals/vNJ6VIP0PY0/discussion.=20
>>>
>>>
>>> On Tue, Feb 11, 2014 at 6:52 AM, Vincent Reverdy <vinc...@gmail.com>=20
>>> wrote:
>>>
>>>> I am currently implementing a library for HPC astrophysical=20
>>>> simulations, and I have been regularly confronted with a basic problem=
..
>>>>
>>>> In my library, I tend to use a lot of what I call "tuple-like user=20
>>>> defined classes" for my fundamental generic types.
>>>> A "*tuple-like user defined class*", is a user defined class whose the=
=20
>>>> main data member is a std::tuple, a std::pair or a std::array and who=
=20
>>>> gives a direct access to it thanks to a member called data() (or any=
=20
>>>> other name you want if you think that this is inappropriate).=20
>>>> Then I have classes and functions that operates on these types. To=20
>>>> provide genericity, I generally provide two overloads: the first that=
=20
>>>> operates on a std::tuple, a std::pair or a std::array, and the second=
=20
>>>> that operates on any class who provides a data() member that decays=
=20
>>>> into a std::tuple, a std::pair or a std::array. I do not know whether=
=20
>>>> it is a "standard practice" or whether it will become a standard pract=
ice=20
>>>> in codes based on C++11 (which is my case), but I find this strategy v=
ery=20
>>>> convenient for the development of generic libraries.
>>>> But in order to provide full genericity in a more "standard" way, a=20
>>>> very simple thing could be added to the standard library: allowing=20
>>>> std::get, std::tuple_size and std::tuple_element to operate on=20
>>>> tuple-like user defined class.=20
>>>>
>>>> What do you think to be the pros/cons to provide=20
>>>> - std::get
>>>> - std::tuple_size
>>>> - std::tuple_element
>>>> for types having a data() function on which they work?
>>>>
>>>> (For example std::get<0>(x) would be the same as std::get<0>(x.data())=
)
>>>>
>>>> --=20
>>>> =20
>>>> ---=20
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>> an email to std-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>
>>>> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
>>>> proposals/.
>>>>
>>>
>>> --=20
>> =20
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_523_875938997.1441997581896
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">(apologies for thread necromancy)<div><br></div><div>On re=
ading this, it occurs to me that the index for get() calls can be "bro=
ught inside the parens", and specified as an ordinary integral_constan=
t tag parameter.</div><div>The advantage is that call sites would not have =
to work around the grammatical ambiguity with relationals by "using st=
d::get;" or other hacks.</div><div><br></div><div>i.e., an interesting=
solution to our problems could be:<br></div><div><br></div><div>namespace =
std {</div><div>=C2=A0 template <typename Tup, typename IdxTag></div>=
<div>=C2=A0 decltype(auto) get(Tup& tup, IdxTag tag) { return get<Id=
xTag::value>(tup); }</div><div>}</div><div><br></div><div><br></div><div=
>void f1() {</div><div>=C2=A0 auto t =3D std::make_tuple(42, std::string(&q=
uot;"));<br></div><div>=C2=A0 assert(get(t, std::integral_constant<=
size_t, 0>{}) =3D=3D 42);</div><div>=C2=A0 assert(get(t,=C2=A0std::integ=
ral_constant<size_t, 1>{}) =3D=3D "");</div><div>}</div><di=
v><br></div><div><div>void f2() {</div><div>=C2=A0 auto t =3D yoyodyne::mak=
e_tuple(42, std::string(""));<br></div><div>=C2=A0 assert(get(t, =
std::integral_constant<size_t, 0>{}) =3D=3D 42);<br></div><div>=C2=A0=
assert(get(t,=C2=A0std::integral_constant<size_t, 1>{}) =3D=3D "=
;");</div></div><div>}</div><div><br></div><div>This extension could c=
oexist with existing std:: and non-std definitions of get.</div><div>Obviou=
sly there could be problems I'm missing.</div><div><br></div><div>I hav=
en't tried this yet, but I'll work it out further if there's an=
y interest.</div><br>On Tuesday, February 11, 2014 at 12:45:21 PM UTC-5, Ge=
offrey Romer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><br><div class=3D"gmail_quote">On Tue, Feb 11, 2014 at 8:56 AM, =
Vincent Reverdy <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"M_z2uvwKhvQJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">vinc...@gmail.com</a>></span> wrote:<br=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">Thank you for the link to your post. I do=
not know the best solution, but I would be happy to help on any proposal t=
o provide a generic-friendly interface to tuple-like classes.</div>
</blockquote><div><br></div><div>Realistically, I'm unlikely to be able=
to take the lead on this, but if you're interested in drafting a propo=
sal (<a href=3D"http://isocpp.org/std/submit-a-proposal" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?=
q\75http%3A%2F%2Fisocpp.org%2Fstd%2Fsubmit-a-proposal\46sa\75D\46sntz\0751\=
46usg\75AFQjCNHyptWzKjic6KocEyo5ThT5aSPToA';return true;" onclick=3D"th=
is.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fisocpp.org%2Fstd%=
2Fsubmit-a-proposal\46sa\75D\46sntz\0751\46usg\75AFQjCNHyptWzKjic6KocEyo5Th=
T5aSPToA';return true;">http://isocpp.org/std/submit-<wbr>a-proposal</a=
>), I'd be happy to provide feedback.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"> Your proposal would be =
to provide these external functions/metafunctions as members, my proposal w=
ould be to provide an overload/specialization for classes having a data() m=
ember returning a tuple-like class (like std::begin() will call T::begin() =
if the function exists).</div>
</blockquote><div><br></div><div>FWIW your proposed solution sounds like it=
's not general enough to be standardized.</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex">
<div dir=3D"ltr"> Do you know whether the expected concepts lite for C++17 =
include a unified concept for std::tuple, std::pair and std::array ? Becaus=
e if so, it could be worth to investigate an unified solution using this co=
ncept.<br>
</div></blockquote><div><br></div><div>I don't know, but I very much do=
ubt it, precisely because they're currently so concept-hostile.</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">
<div dir=3D"ltr"><br>Le mardi 11 f=C3=A9vrier 2014 17:31:53 UTC+1, Geoffrey=
Romer a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex">
<div><div dir=3D"ltr"><div>You're already allowed to specialize ::std t=
emplates for user-defined types, so std::tuple_size and std::tuple_element =
effectively already support this. std::get is a bit more annoying: it's=
an ordinary function, not a metafunction, so ideally you'd use argumen=
t-dependent lookup: instead of calling std::get<N>(foo), just call ge=
t<N>(foo), and C++ will choose the version of get() declared in the n=
amespace of foo's type (or a parent namespace, etc). The fly in the oin=
tment is that in order to correctly parse that function call, the compiler =
needs a "get<>()" function template in the current namespac=
e, even if it's not the one that will eventually be chosen by ADL (othe=
rwise there's an ambiguity about whether the angle brackets are actuall=
y comparison operators). Something like this might be the simplest workarou=
nd:<br>
</div><div><br></div><div>using std::get;</div><div>get<N>(foo);</div=
><div><br></div><div>That doesn't sit quite right with me, because it l=
ooks just like the usual swap idiom, but it's done for completely diffe=
rent reasons.</div>
<div><br></div><div>I'd like tuple to be extended to support a more gen=
eric-friendly API. I posted about this a couple weeks ago, but didn't g=
et much uptake: <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/s=
td-proposals/vNJ6VIP0PY0/discussion" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/topic=
/std-proposals/vNJ6VIP0PY0/discussion';return true;" onclick=3D"this.hr=
ef=3D'https://groups.google.com/a/isocpp.org/d/topic/std-proposals/vNJ6=
VIP0PY0/discussion';return true;">https://groups.google.com/a/<u></u>is=
<wbr>ocpp.org/d/topic/std-<u></u>proposals<wbr>/vNJ6VIP0PY0/<u></u>discussi=
on</a>.=C2=A0</div>
</div></div><div><br><br><div class=3D"gmail_quote"><div>On Tue, Feb 11, 20=
14 at 6:52 AM, Vincent Reverdy <span dir=3D"ltr"><<a>vinc...@gmail.com</=
a>></span> wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div><div dir=3D"ltr">I am currently implementing a =
library for HPC astrophysical simulations, and I have been regularly confro=
nted with a basic problem.<br>
<br>In my library, I tend to use a lot of what I call "tuple-like user=
defined classes" for my fundamental generic types.<br>A "<i><b>t=
uple-like user defined class</b></i>", is a user defined class whose t=
he main data member is a <span style=3D"font-family:'courier new',m=
onospace">std::tuple</span>, a <span style=3D"font-family:'courier new&=
#39;,monospace">std::pair</span> or a <span style=3D"font-family:'couri=
er new',monospace">std::array</span> and who gives a direct access to i=
t thanks to a member called <span style=3D"font-family:'courier new'=
;,monospace">data()</span> (or any other name you want if you think that th=
is is inappropriate). <br>
Then I have classes and functions that operates on these types. To provide =
genericity, I generally provide two overloads: the first that operates on a=
<span style=3D"font-family:'courier new',monospace">std::tuple</sp=
an>, a <span style=3D"font-family:'courier new',monospace">std::pai=
r</span> or a <span style=3D"font-family:'courier new',monospace">s=
td::array<span style=3D"font-family:arial,sans-serif">, and the second that=
operates on any class who provides a=C2=A0 </span>data()</span> member tha=
t decays into a <span style=3D"font-family:'courier new',monospace"=
>std::tuple</span>, a <span style=3D"font-family:'courier new',mono=
space">std::pair</span> or a <span style=3D"font-family:'courier new=
9;,monospace">std::array<span style=3D"font-family:arial,sans-serif">. I do=
not know whether it is a "standard practice" or whether it will =
become a standard practice in codes based on C++11 (which is my case), but =
I find this strategy very convenient for the development of generic librari=
es.<br>
But in order to provide full genericity in a more "standard" way,=
a very simple thing could be added to the standard library: allowing <span=
style=3D"font-family:'courier new',monospace">std::get</span>, <sp=
an style=3D"font-family:'courier new',monospace">std::tuple_size</s=
pan> and <span style=3D"font-family:'courier new',monospace">std::t=
uple_element </span>to operate on tuple-like user defined class. <br>
<br>What do you think to be the pros/cons to provide </span></span><br><spa=
n style=3D"font-family:'courier new',monospace"><span style=3D"font=
-family:arial,sans-serif"><span style=3D"font-family:'courier new',=
monospace">- std::get<br>
</span></span></span><span style=3D"font-family:'courier new',monos=
pace"><span style=3D"font-family:arial,sans-serif"><span style=3D"font-fami=
ly:'courier new',monospace">- std::tuple_size</span></span></span><=
br>
<span style=3D"font-family:'courier new',monospace"><span style=3D"=
font-family:arial,sans-serif"><span style=3D"font-family:'courier new&#=
39;,monospace">- std::tuple_element</span></span></span><br>
for types having a <span style=3D"font-family:'courier new',monospa=
ce">data()<span style=3D"font-family:arial,sans-serif"> function on which t=
hey work?</span></span><br><br>(For example <span style=3D"font-family:'=
;courier new',monospace">std::get<0>(x)</span> would be the same =
as <span style=3D"font-family:'courier new',monospace">std::get<=
0>(x.data())</span>)<span><font color=3D"#888888"><br>
</font></span></div></div><span><font color=3D"#888888"><div>
<p></p>
-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<div><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';ret=
urn true;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.or=
g/group/std-proposals/';return true;">http://groups.google.com/a/<u></u=
>iso<wbr>cpp.org/group/std-<u></u>proposals/</a>.<br>
</div></font></span></blockquote></div><br></div>
</blockquote></div><div><div>
<p></p>
-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
M_z2uvwKhvQJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"M_z2uvwKhvQJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';ret=
urn true;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.or=
g/group/std-proposals/';return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_523_875938997.1441997581896--
------=_Part_522_674164224.1441997581895--
.