Topic: C++ named tuple
Author: glmeocci@gmail.com
Date: Fri, 29 Mar 2013 06:03:24 -0700 (PDT)
Raw View
------=_Part_14_18455715.1364562204230
Content-Type: text/plain; charset=ISO-8859-1
Hi,
I propose to add a new future to C++14: "the named tuple".
In some case could be very usefull to have something like that:
std::tuple< *foo@int*, *bar@std::string *> t = std::make_tuple(5, "hello!");
than we can access to our tuple in this way:
auto n = std::get<foo>(t);
auto m = std::get<bar>(t);
What is your idea about this?
Thanks
--
---
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/?hl=en.
------=_Part_14_18455715.1364562204230
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi,<br><br>I propose to add a new future to C++14: "the named tuple".<br>In=
some case could be very usefull to have something like that:<br><br>std::t=
uple< <b>foo@int</b>, <b>bar@std::string </b>> t =3D std::make_tuple(=
5, "hello!");<br><br>than we can access to our tuple in this way:<br><br>au=
to n =3D std::get<foo>(t);<br>auto m =3D std::get<bar>(t);<br><=
br><span id=3D"result_box" class=3D"short_text" lang=3D"en"><span class=3D"=
hps">What is your</span> <span class=3D"hps">idea about this?</span></span>=
<br>Thanks <br>
<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_14_18455715.1364562204230--
.
Author: sgheeren@gmail.com
Date: Fri, 29 Mar 2013 07:05:46 -0700 (PDT)
Raw View
------=_Part_551_22795529.1364565946542
Content-Type: text/plain; charset=ISO-8859-1
Seems similar enough to what you can already achieve with 'tag structs'
These are ubiquitous in libraries such as Boost Graph Library, or Boost
MultiIndex.
Minimalist sample from Boost Fusion documentation<http://www.boost.org/doc/libs/1_53_0/libs/fusion/doc/html/fusion/sequence/intrinsic/functions/at_key.html>
:
set<int, char, bool> s(1, 'x', true);
assert(at_key<char>(s) == 'x');
Or when tag types don't correspond to the element data types: (map<http://www.boost.org/doc/libs/1_53_0/libs/fusion/doc/html/fusion/container/map.html>
)
typedef map<
pair<int, char>
, pair<double, std::string> >
map_type;
map_type m(
make_pair<int>('X')
, make_pair<double>("Men"));
std::cout << at_key<int>(m) << std::endl;
std::cout << at_key<double>(m) << std::endl;
On Friday, March 29, 2013 2:03:24 PM UTC+1, glme...@gmail.com wrote:
>
> Hi,
>
> I propose to add a new future to C++14: "the named tuple".
> In some case could be very usefull to have something like that:
>
> std::tuple< *foo@int*, *bar@std::string *> t = std::make_tuple(5,
> "hello!");
>
> than we can access to our tuple in this way:
>
> auto n = std::get<foo>(t);
> auto m = std::get<bar>(t);
>
> What is your idea about this?
> Thanks
>
--
---
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/?hl=en.
------=_Part_551_22795529.1364565946542
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Seems similar enough to what you can already achieve with 'tag structs=
' <br></div><div><br></div><div>These are ubiquitous in libraries such=
as Boost Graph Library, or Boost MultiIndex.</div><div><br></div><div>Mini=
malist sample from <a href=3D"http://www.boost.org/doc/libs/1_53_0/libs/fus=
ion/doc/html/fusion/sequence/intrinsic/functions/at_key.html">Boost Fusion =
documentation</a>:</div><div><br></div><div style=3D"margin-left: 40px !imp=
ortant;"><div style=3D"background-color: #FAFAFA; border-color: #BBB; borde=
r-style: solid; border-width: 1px; word-wrap: break-word;" class=3D"prettyp=
rint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">set</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">char</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">></span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> s</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify">'x'</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">true</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: =
#008;" class=3D"styled-by-prettify">assert</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">at_key</span><span style=3D"color: #080;" class=3D"=
styled-by-prettify"><char></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">s</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #080;" class=3D"styled-by-prettify">'x'</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">);</span></div></code></div><div=
><br>Or when tag types don't correspond to the element data types: (<a href=
=3D"http://www.boost.org/doc/libs/1_53_0/libs/fusion/doc/html/fusion/contai=
ner/map.html">map</a>)</div><div><br></div><div><div style=3D"background-co=
lor: #FAFAFA; border-color: #BBB; border-style: solid; border-width: 1px; w=
ord-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">typedef</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> map</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
pair</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
<</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</s=
pan><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: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> pair</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">double</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">string</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">></span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br>map_type</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br><br>map_type m</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br> make_pair</span><span style=3D"color:=
#080;" class=3D"styled-by-prettify"><int></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #080;" =
class=3D"styled-by-prettify">'X'</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> make_pair</span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify"><double></span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-prettify"=
>"Men"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">));<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>std=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> at_key</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify"><int></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">m</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"styled-b=
y-prettify"><<</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">endl=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>std</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify"><<</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> at_key</span><span style=3D"color:=
#080;" class=3D"styled-by-prettify"><double></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">m</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify"><<</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">endl</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span></div></=
code></div><br></div></div><br>On Friday, March 29, 2013 2:03:24 PM UTC+1, =
glme...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi,<br=
><br>I propose to add a new future to C++14: "the named tuple".<br>In some =
case could be very usefull to have something like that:<br><br>std::tuple&l=
t; <b>foo@int</b>, <b>bar@std::string </b>> t =3D std::make_tuple(5, "he=
llo!");<br><br>than we can access to our tuple in this way:<br><br>auto n =
=3D std::get<foo>(t);<br>auto m =3D std::get<bar>(t);<br><br><s=
pan lang=3D"en"><span>What is your</span> <span>idea about this?</span></sp=
an><br>Thanks <br></blockquote>
<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_551_22795529.1364565946542--
.
Author: sgheeren@gmail.com
Date: Fri, 29 Mar 2013 07:06:03 -0700 (PDT)
Raw View
------=_Part_516_27900949.1364565963300
Content-Type: text/plain; charset=ISO-8859-1
Seems similar enough to what you can already achieve with 'tag structs'
These are ubiquitous in libraries such as Boost Graph Library, or Boost
MultiIndex.
Minimalist sample from Boost Fusion documentation<http://www.boost.org/doc/libs/1_53_0/libs/fusion/doc/html/fusion/sequence/intrinsic/functions/at_key.html>
:
set<int, char, bool> s(1, 'x', true);
assert(at_key<char>(s) == 'x');
Or when tag types don't correspond to the element data types: (map<http://www.boost.org/doc/libs/1_53_0/libs/fusion/doc/html/fusion/container/map.html>
)
typedef map<
pair<int, char>
, pair<double, std::string> >
map_type;
map_type m(
make_pair<int>('X')
, make_pair<double>("Men"));
std::cout << at_key<int>(m) << std::endl;
std::cout << at_key<double>(m) << std::endl;
On Friday, March 29, 2013 2:03:24 PM UTC+1, glme...@gmail.com wrote:
>
> Hi,
>
> I propose to add a new future to C++14: "the named tuple".
> In some case could be very usefull to have something like that:
>
> std::tuple< *foo@int*, *bar@std::string *> t = std::make_tuple(5,
> "hello!");
>
> than we can access to our tuple in this way:
>
> auto n = std::get<foo>(t);
> auto m = std::get<bar>(t);
>
> What is your idea about this?
> Thanks
>
--
---
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/?hl=en.
------=_Part_516_27900949.1364565963300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Seems similar enough to what you can already achieve with 'tag structs=
' <br></div><div><br></div><div>These are ubiquitous in libraries such=
as Boost Graph Library, or Boost MultiIndex.</div><div><br></div><div>Mini=
malist sample from <a href=3D"http://www.boost.org/doc/libs/1_53_0/libs/fus=
ion/doc/html/fusion/sequence/intrinsic/functions/at_key.html">Boost Fusion =
documentation</a>:</div><div><br></div><div style=3D"margin-left: 40px !imp=
ortant;"><div style=3D"background-color: #FAFAFA; border-color: #BBB; borde=
r-style: solid; border-width: 1px; word-wrap: break-word;" class=3D"prettyp=
rint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">set</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">char</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">></span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> s</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify">'x'</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">true</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: =
#008;" class=3D"styled-by-prettify">assert</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">at_key</span><span style=3D"color: #080;" class=3D"=
styled-by-prettify"><char></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">s</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #080;" class=3D"styled-by-prettify">'x'</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">);</span></div></code></div><div=
><br>Or when tag types don't correspond to the element data types: (<a href=
=3D"http://www.boost.org/doc/libs/1_53_0/libs/fusion/doc/html/fusion/contai=
ner/map.html">map</a>)</div><div><br></div><div><div style=3D"background-co=
lor: #FAFAFA; border-color: #BBB; border-style: solid; border-width: 1px; w=
ord-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">typedef</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> map</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
pair</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
<</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</s=
pan><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: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> pair</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">double</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">string</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">></span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br>map_type</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br><br>map_type m</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br> make_pair</span><span style=3D"color:=
#080;" class=3D"styled-by-prettify"><int></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #080;" =
class=3D"styled-by-prettify">'X'</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> make_pair</span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify"><double></span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-prettify"=
>"Men"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">));<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>std=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> at_key</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify"><int></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">m</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"styled-b=
y-prettify"><<</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">endl=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>std</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify"><<</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> at_key</span><span style=3D"color:=
#080;" class=3D"styled-by-prettify"><double></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">m</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify"><<</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">endl</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span></div></=
code></div><br></div></div><br>On Friday, March 29, 2013 2:03:24 PM UTC+1, =
glme...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi,<br=
><br>I propose to add a new future to C++14: "the named tuple".<br>In some =
case could be very usefull to have something like that:<br><br>std::tuple&l=
t; <b>foo@int</b>, <b>bar@std::string </b>> t =3D std::make_tuple(5, "he=
llo!");<br><br>than we can access to our tuple in this way:<br><br>auto n =
=3D std::get<foo>(t);<br>auto m =3D std::get<bar>(t);<br><br><s=
pan lang=3D"en"><span>What is your</span> <span>idea about this?</span></sp=
an><br>Thanks <br></blockquote>
<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_516_27900949.1364565963300--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 29 Mar 2013 16:19:39 +0200
Raw View
On 29 March 2013 16:05, <sgheeren@gmail.com> wrote:
> Seems similar enough to what you can already achieve with 'tag structs'
> These are ubiquitous in libraries such as Boost Graph Library, or Boost
> MultiIndex.
> Minimalist sample from Boost Fusion documentation:
> set<int, char, bool> s(1, 'x', true);
> assert(at_key<char>(s) == 'x');
That's not the same thing. That is an example of accessing tuple elements by
type, not by name. Accessing them by type is already going forward
along the lines
proposed in http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3404.html
but there's not yet any proposal to allow accessing tuple elements by name.
--
---
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/?hl=en.
.
Author: Aleksandar Fabijanic <aleks.fabijanic@gmail.com>
Date: Fri, 29 Mar 2013 09:55:19 -0500
Raw View
On Fri, Mar 29, 2013 at 9:19 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 29 March 2013 16:05, <sgheeren@gmail.com> wrote:
>> Seems similar enough to what you can already achieve with 'tag structs'
> but there's not yet any proposal to allow accessing tuple elements by name.
If someone cares to put forth some effort it, here's an existing
implementation (not updated to C++11):
https://github.com/pocoproject/poco/blob/develop/Foundation/include/Poco/NamedTuple.h
A use example:
NamedTuple<std::string, int, bool, float, char, long>
aTuple("string", "1", "int", 1, "bool", true, "float", 1.5f, "char",
'c', "long", 999);
assert (aTuple["string"] == "1");
assert (aTuple["int"] == 1);
assert (aTuple["bool"] == true);
assert (aTuple["float"] == 1.5);
assert (aTuple["char"] == 'c');
assert (aTuple["long"] == 999);
and some shortcomings/dilemmas pointed out here:
http://pocoproject.org/blog/?p=89
--
---
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/?hl=en.
.
Author: Gian Lorenzo Meocci <glmeocci@gmail.com>
Date: Fri, 29 Mar 2013 16:19:57 +0100
Raw View
--bcaec54eebbad604af04d911cd26
Content-Type: text/plain; charset=ISO-8859-1
I think that we need put Named Tuple into the standard to avoid some
confusion and to reduce "ugly" code
On Fri, Mar 29, 2013 at 3:55 PM, Aleksandar Fabijanic <
aleks.fabijanic@gmail.com> wrote:
> On Fri, Mar 29, 2013 at 9:19 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
> > On 29 March 2013 16:05, <sgheeren@gmail.com> wrote:
> >> Seems similar enough to what you can already achieve with 'tag structs'
>
> > but there's not yet any proposal to allow accessing tuple elements by
> name.
>
> If someone cares to put forth some effort it, here's an existing
> implementation (not updated to C++11):
>
>
> https://github.com/pocoproject/poco/blob/develop/Foundation/include/Poco/NamedTuple.h
>
> A use example:
>
> NamedTuple<std::string, int, bool, float, char, long>
> aTuple("string", "1", "int", 1, "bool", true, "float", 1.5f, "char",
> 'c', "long", 999);
> assert (aTuple["string"] == "1");
> assert (aTuple["int"] == 1);
> assert (aTuple["bool"] == true);
> assert (aTuple["float"] == 1.5);
> assert (aTuple["char"] == 'c');
> assert (aTuple["long"] == 999);
>
> and some shortcomings/dilemmas pointed out here:
>
> http://pocoproject.org/blog/?p=89
>
> --
>
> ---
> 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/N-kIXNrkTUk/unsubscribe?hl=en
> .
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>
--
GL
http://www.meocci.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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--bcaec54eebbad604af04d911cd26
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think that we need put Named Tuple into the standard to =
avoid some confusion and to reduce "ugly" code<br></div><div clas=
s=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Mar 29, 2013 a=
t 3:55 PM, Aleksandar Fabijanic <span dir=3D"ltr"><<a href=3D"mailto:ale=
ks.fabijanic@gmail.com" target=3D"_blank">aleks.fabijanic@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 class=3D"im">On Fri, Mar 29, 2013 at 9:=
19 AM, Ville Voutilainen<br>
<<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.=
com</a>> wrote:<br>
> On 29 March 2013 16:05, =A0<<a href=3D"mailto:sgheeren@gmail.com">s=
gheeren@gmail.com</a>> wrote:<br>
>> Seems similar enough to what you can already achieve with 'tag=
structs'<br>
<br>
</div><div class=3D"im">> but there's not yet any proposal to allow =
accessing tuple elements by name.<br>
<br>
</div>If someone cares to put forth some effort it, here's an existing<=
br>
implementation (not updated to C++11):<br>
<br>
<a href=3D"https://github.com/pocoproject/poco/blob/develop/Foundation/incl=
ude/Poco/NamedTuple.h" target=3D"_blank">https://github.com/pocoproject/poc=
o/blob/develop/Foundation/include/Poco/NamedTuple.h</a><br>
<br>
A use example:<br>
<br>
NamedTuple<std::string, int, bool, float, char, long><br>
aTuple("string", "1", =A0"int", 1, "bool=
", true, "float", 1.5f, "char",<br>
'c', "long", 999);<br>
assert (aTuple["string"] =3D=3D "1");<br>
assert (aTuple["int"] =3D=3D 1);<br>
assert (aTuple["bool"] =3D=3D true);<br>
assert (aTuple["float"] =3D=3D 1.5);<br>
assert (aTuple["char"] =3D=3D 'c');<br>
assert (aTuple["long"] =3D=3D 999);<br>
<br>
and some shortcomings/dilemmas pointed out here:<br>
<br>
<a href=3D"http://pocoproject.org/blog/?p=3D89" target=3D"_blank">http://po=
coproject.org/blog/?p=3D89</a><br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<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/N-kIXNrkTUk/unsubscribe?hl=3Den" target=
=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/N-=
kIXNrkTUk/unsubscribe?hl=3Den</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
<br>
<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>GL<br><a hr=
ef=3D"http://www.meocci.it" target=3D"_blank">http://www.meocci.it</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--bcaec54eebbad604af04d911cd26--
.
Author: morwenn29@gmail.com
Date: Fri, 29 Mar 2013 10:36:07 -0700 (PDT)
Raw View
------=_Part_367_19651645.1364578567720
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Le vendredi 29 mars 2013 14:03:24 UTC+1, glme...@gmail.com a =E9crit :
>
> Hi,
>
> I propose to add a new future to C++14: "the named tuple".
> In some case could be very usefull to have something like that:
>
> std::tuple< *foo@int*, *bar@std::string *> t =3D std::make_tuple(5,=20
> "hello!");
>
> than we can access to our tuple in this way:
>
> auto n =3D std::get<foo>(t);
> auto m =3D std::get<bar>(t);
>
> What is your idea about this?
> Thanks=20
>
I just don't see how this would be more useful or easy to use than:
struct
{
int foo;
string bar;
} t =3D { 5, "hello" };
auto n =3D t.foo;
auto m =3D t.bar;
=20
--=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/?hl=3Den.
------=_Part_367_19651645.1364578567720
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>Le vendredi 29 mars 2013 14:03:24 UTC+1, glme...@gmail.com a =E9cri=
t :<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi,<br><br>I propose t=
o add a new future to C++14: "the named tuple".<br>In some case could be ve=
ry usefull to have something like that:<br><br>std::tuple< <b>foo@int</b=
>, <b>bar@std::string </b>> t =3D std::make_tuple(5, "hello!");<br><br>t=
han we can access to our tuple in this way:<br><br>auto n =3D std::get<f=
oo>(t);<br>auto m =3D std::get<bar>(t);<br><br><span lang=3D"en"><=
span>What is your</span> <span>idea about this?</span></span><br>Thanks <br=
></blockquote><div> I just don't see how this would be more useful or =
easy to use than:<br><br> struct<br> {<=
br> int foo;<br>  =
; string bar;<br> } t =3D { 5, "h=
ello" };<br><br> auto n =3D t.foo;<br> =
auto m =3D t.bar;<br></div><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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_367_19651645.1364578567720--
.
Author: Aleksandar Fabijanic <aleks.fabijanic@gmail.com>
Date: Fri, 29 Mar 2013 15:21:35 -0500
Raw View
> Le vendredi 29 mars 2013 14:03:24 UTC+1, glme...@gmail.com a =E9crit :
> I just don't see how this would be more useful or easy to use than:
>
> struct
> {
> int foo;
> string bar;
> } t =3D { 5, "hello" };
>
> auto n =3D t.foo;
> auto m =3D t.bar;
Such comparison would be appropriate in a context of discussion "does
C++ need std::tuple?" (or std::pair, for that matter).
Since there already exists std::tuple<int, string> and it's being
discussed here, relevant question is "which is better?":
int i =3D t.get<0>();
or
int i =3D t["foo"];
or
int i =3D t<"bar">();
Alex
--=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/?hl=3Den.
.
Author: sgheeren@gmail.com
Date: Fri, 29 Mar 2013 16:24:02 -0700 (PDT)
Raw View
------=_Part_1390_24865819.1364599442966
Content-Type: text/plain; charset=ISO-8859-1
> That's not the same thing.
I didn't say it was
> That is an example of accessing tuple elements by type, not by name.
Erm. Types /are/ ("have") names.
typedef map<
pair<struct foo, char>
, pair<struct bar, std::string> >
map_type;
auto n = at_key<foo>(m);
auto m = at_key<bar>(m);
Look familiar?
> Accessing them by type is already going forward [...]
> but there's not yet any proposal to allow accessing tuple elements by
name.
My point is, it doesn't solve any additional problem. Instead it introduces
more clumsy syntax to do basically the same but with inconsistent typology.
One might as well just ask for support of string literals as non-type
template arguments, which would frankly stand a lot better chance of
getting some sort of consistent implementation, and would also be
infinitely more generally applicable (note: I'm not proposing C++ should
have such a thing, though).
--
---
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/?hl=en.
------=_Part_1390_24865819.1364599442966
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>> That's not the same thing. </div><div><br></div><div>I didn'=
t say it was</div><div><br></div><div>> That is an example of accessing =
tuple elements by type, not by name. </div><div><br></div><div>Erm. Ty=
pes /are/ ("have") names.</div><div><br></div><div>typedef map<<br> =
; pair<struct foo, char><br> , pair<struct bar, std::st=
ring> ><br>map_type;<br><br>auto n =3D at_key<foo>(m);<br>auto =
m =3D at_key<bar>(m);<br>Look familiar?</div><div><br></div>> Acce=
ssing them by type is already going forward [...] <br><div>> but t=
here's not yet any proposal to allow accessing tuple elements by name. =
;<br></div><div><br></div><div>My point is, it doesn't solve any additional=
problem. Instead it introduces more clumsy syntax to do basically the same=
but with inconsistent typology. </div><div><br></div><div>One might as wel=
l just ask for support of string literals as non-type template arguments, w=
hich would frankly stand a lot better chance of getting some sort of consis=
tent implementation, and would also be infinitely more generally applicable=
(note: I'm not proposing C++ should have such a thing, though).</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1390_24865819.1364599442966--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 30 Mar 2013 01:53:21 +0200
Raw View
On 30 March 2013 01:24, <sgheeren@gmail.com> wrote:
>> That is an example of accessing tuple elements by type, not by name.
> Erm. Types /are/ ("have") names.
Elements of the same type have different names, in normal structs.
That's what's sought after for tuples.
> typedef map<
> pair<struct foo, char>
> , pair<struct bar, std::string> >
> map_type;
> auto n = at_key<foo>(m);
> auto m = at_key<bar>(m);
> Look familiar?
No. I don't see the point of this example.
>> Accessing them by type is already going forward [...]
>> but there's not yet any proposal to allow accessing tuple elements by
>> name.
> My point is, it doesn't solve any additional problem. Instead it introduces
> more clumsy syntax to do basically the same but with inconsistent typology.
Uh huh. The additional problem it would solve is the equivalent of
struct X { char jonesy; int bonesy};
and being able to name the components of a tuple<char, int> "jonesy"
and "bonesy". It
further solves the problem that by-type access doesn't solve, that is,
if you have
tuple<int, int, int>, you can't get<int>() from it because it's
ambiguous which int member
you mean.
> One might as well just ask for support of string literals as non-type
> template arguments, which would frankly stand a lot better chance of getting
> some sort of consistent implementation, and would also be infinitely more
> generally applicable (note: I'm not proposing C++ should have such a thing,
> though).
One certainly might, and that would be a useful tool for implementing
named access to tuple
elements.
--
---
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/?hl=en.
.
Author: sgheeren@gmail.com
Date: Fri, 29 Mar 2013 17:27:19 -0700 (PDT)
Raw View
------=_Part_902_31651989.1364603239746
Content-Type: text/plain; charset=ISO-8859-1
> No. I don't see the point of this example.
Really?
> [...] tuple<int, int, int>, you can't get<int>() from it because it's
> ambiguous which int member you mean.
Well, then, maybe this one helps:
typedef map<
pair<struct jonesy, int>
, pair<struct bonesy, int> >
map_type;
map_type m;
auto i1 = at_key<jonesy>(m);
auto i2 = at_key<bonesy>(m);
Here's a LWS demonstruction http://liveworkspace.org/code/3WmdD1$0
--
---
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/?hl=en.
------=_Part_902_31651989.1364603239746
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>> No. I don't see the point of this example.<br></div><div><br></di=
v><div>Really? </div><div><br></div><div>> [...] tuple<int, int,=
int>, you can't get<int>() from it because it's </div><div>&=
gt; ambiguous which int member you mean. </div><div><br></div><div>Wel=
l, then, maybe this one helps: <br></div><div><br></div><div><div styl=
e=3D"background-color: #FAFAFA; border-color: #BBB; border-style: solid; bo=
rder-width: 1px; word-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
class=3D"styled-by-prettify">typedef</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> map</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> pair</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> jonesy</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">></span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> pair</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> bonesy</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
gt;</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;" class=3D"styled-by-prettify"><br>map_type</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br>map_type m</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> i1 </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> at_key</span><span style=3D"color: #080;" clas=
s=3D"styled-by-prettify"><jonesy></span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">m</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">aut=
o</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i2 </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> at_key</span><span st=
yle=3D"color: #080;" class=3D"styled-by-prettify"><bonesy></span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">m</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">);</span></div></code></div><br>Here'=
s a LWS demonstruction <a href=3D"http://liveworkspace.org/code/3WmdD1$0">h=
ttp://liveworkspace.org/code/3WmdD1$0</a><br><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_902_31651989.1364603239746--
.
Author: Travis Gockel <travis@gockelhut.com>
Date: Fri, 29 Mar 2013 17:57:24 -0700 (PDT)
Raw View
------=_Part_1432_19976581.1364605044776
Content-Type: text/plain; charset=ISO-8859-1
On Friday, March 29, 2013 11:36:07 AM UTC-6, morw...@gmail.com wrote:
>
> I just don't see how this would be more useful or easy to use than:
>
> struct
> {
> int foo;
> string bar;
> } t = { 5, "hello" };
>
> auto n = t.foo;
> auto m = t.bar;
>
>
The big issue here is things like get<0>(t) don't work.
I have this funny vision where you could use your own tuple-like types
inside things like std::map.
struct MyThing
{
int id;
double score;
std::string name;
};
std::map<MyThing> m;
m.insert({ 1, 8.3, "Bob"});
m.insert({ 2, 1.2, "James"});
auto iter = m.find(2);
std::cout << iter->name << " : " << iter->score << std::endl;
Slightly better names than first and second.
--
---
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/?hl=en.
------=_Part_1432_19976581.1364605044776
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, March 29, 2013 11:36:07 AM UTC-6, morw...@gmail.com wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><br><div> I just don't see =
how this would be more useful or easy to use than:<br><br>  =
; struct<br> {<br> &nb=
sp; int foo;<br> string bar;<br>&=
nbsp; } t =3D { 5, "hello" };<br><br> auto n =
=3D t.foo;<br> auto m =3D t.bar;<br></div><div> </di=
v></blockquote><div> </div><div>The big issue here is things like get&=
lt;0>(t) don't work.</div><div><br></div><div>I have this funny vision w=
here you could use your own tuple-like types inside things like std::map.</=
div><div><br></div><div>struct MyThing</div><div>{</div><div> =
int id;</div><div> double score;</div><div> std::=
string name;</div><div>};</div><div><br></div><div>std::map<MyThing> =
m;</div><div>m.insert({ 1, 8.3, "Bob"});</div><div>m.insert({ 2, 1.2, "Jame=
s"});</div><div>auto iter =3D m.find(2);</div><div>std::cout << iter-=
>name << " : " << iter->score << std::endl;</div><d=
iv><br></div><div>Slightly better names than first and second.</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1432_19976581.1364605044776--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 29 Mar 2013 18:21:19 -0700 (PDT)
Raw View
------=_Part_1049_25725204.1364606479654
Content-Type: text/plain; charset=ISO-8859-1
On Friday, March 29, 2013 7:55:19 AM UTC-7, aleks.fabijanic wrote:
>
> On Fri, Mar 29, 2013 at 9:19 AM, Ville Voutilainen
> <ville.vo...@gmail.com <javascript:>> wrote:
> > On 29 March 2013 16:05, <sghe...@gmail.com <javascript:>> wrote:
> >> Seems similar enough to what you can already achieve with 'tag structs'
>
> > but there's not yet any proposal to allow accessing tuple elements by
> name.
>
> If someone cares to put forth some effort it, here's an existing
> implementation (not updated to C++11):
>
>
> https://github.com/pocoproject/poco/blob/develop/Foundation/include/Poco/NamedTuple.h
>
> A use example:
>
> NamedTuple<std::string, int, bool, float, char, long>
> aTuple("string", "1", "int", 1, "bool", true, "float", 1.5f, "char",
> 'c', "long", 999);
> assert (aTuple["string"] == "1");
> assert (aTuple["int"] == 1);
> assert (aTuple["bool"] == true);
> assert (aTuple["float"] == 1.5);
> assert (aTuple["char"] == 'c');
> assert (aTuple["long"] == 999);
>
> and some shortcomings/dilemmas pointed out here:
>
> http://pocoproject.org/blog/?p=89
>
Congradulations; you just implemented `std::map<std::string, any>`. Except
for potentially disallowing adding new members or changing the types of
existing members, this is functionally no different than this:
std::map<std::string, any> mp {{"string", "1"}, {"int", 1}, {"bool", true},
{"float", 1.5f}, {"char", 'c'}, {"long", 999}};
So why should we prefer a new class, when all we need to get mostly
equivalent is to add a std::any type? And that's already under discussion.
--
---
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/?hl=en.
------=_Part_1049_25725204.1364606479654
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Friday, March 29, 2013 7:55:19 AM UTC-7, aleks.fabijanic wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Mar 29, 2013 at 9:19 AM=
, Ville Voutilainen
<br><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
pLIiKlZF_8YJ">ville.vo...@gmail.com</a>> wrote:
<br>> On 29 March 2013 16:05, <<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"pLIiKlZF_8YJ">sghe...@gmail.com</a>>=
; wrote:
<br>>> Seems similar enough to what you can already achieve with 'tag=
structs'
<br>
<br>> but there's not yet any proposal to allow accessing tuple elements=
by name.
<br>
<br>If someone cares to put forth some effort it, here's an existing
<br>implementation (not updated to C++11):
<br>
<br><a href=3D"https://github.com/pocoproject/poco/blob/develop/Foundation/=
include/Poco/NamedTuple.h" target=3D"_blank">https://github.com/<wbr>pocopr=
oject/poco/blob/develop/<wbr>Foundation/include/Poco/<wbr>NamedTuple.h</a>
<br>
<br>A use example:
<br>
<br>NamedTuple<std::string, int, bool, float, char, long>
<br>aTuple("string", "1", "int", 1, "bool", true, "float", 1.5f, "cha=
r",
<br>'c', "long", 999);
<br>assert (aTuple["string"] =3D=3D "1");
<br>assert (aTuple["int"] =3D=3D 1);
<br>assert (aTuple["bool"] =3D=3D true);
<br>assert (aTuple["float"] =3D=3D 1.5);
<br>assert (aTuple["char"] =3D=3D 'c');
<br>assert (aTuple["long"] =3D=3D 999);
<br>
<br>and some shortcomings/dilemmas pointed out here:
<br>
<br><a href=3D"http://pocoproject.org/blog/?p=3D89" target=3D"_blank">http:=
//pocoproject.org/blog/?<wbr>p=3D89</a>
<br></blockquote><div><br>Congradulations; you just implemented `std::map&l=
t;std::string, any>`. Except for potentially disallowing adding new memb=
ers or changing the types of existing members, this is functionally no diff=
erent than this:<br><br><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">map=
</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"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">string</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> any</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> mp </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">{{</span><span style=3D"color: #080;" class=3D"styled-by-prett=
ify">"string"</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #080;" class=3D"styled-by-prettify">"1"</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"styled-by-prettify">{</span><span style=3D"color: #080;" =
class=3D"styled-by-prettify">"int"</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">},<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">"bool"</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">true</span><span style=3D"color: #660;" class=3D"s=
tyled-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: #080;" class=3D"styled-by-prettify">"float"=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">1.5f</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">},</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">"char"</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: #080;" class=3D"styled-by-prettify">'c'</sp=
an><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"styled-by-prettify">{</span><span style=3D"color: #=
080;" class=3D"styled-by-prettify">"long"</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: #066;" class=3D"style=
d-by-prettify">999</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">}};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span></div></code></div><br>So why should we prefer a new class, whe=
n all we need to get mostly equivalent is to add a std::any type? And that'=
s already under discussion.<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1049_25725204.1364606479654--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 29 Mar 2013 18:22:44 -0700 (PDT)
Raw View
------=_Part_1099_15025740.1364606564165
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, March 29, 2013 1:21:35 PM UTC-7, aleks.fabijanic wrote:
>
> > Le vendredi 29 mars 2013 14:03:24 UTC+1, glme...@gmail.com a =E9crit :=
=20
>
> > I just don't see how this would be more useful or easy to use than:=20
> >=20
> > struct=20
> > {=20
> > int foo;=20
> > string bar;=20
> > } t =3D { 5, "hello" };=20
> >=20
> > auto n =3D t.foo;=20
> > auto m =3D t.bar;=20
>
> Such comparison would be appropriate in a context of discussion "does=20
> C++ need std::tuple?" (or std::pair, for that matter).=20
>
> Since there already exists std::tuple<int, string> and it's being=20
> discussed here, relevant question is "which is better?":=20
>
> int i =3D t.get<0>();=20
>
> or=20
>
> int i =3D t["foo"];=20
>
> or=20
>
> int i =3D t<"bar">();=20
>
> Alex=20
>
Any such problems will be more effectively resolved once we have some=20
compile-time reflection. Though it should be noted that the middle one is a=
=20
runtime lookup, unlike the first which is compile-time.=20
--=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/?hl=3Den.
------=_Part_1099_15025740.1364606564165
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Friday, March 29, 2013 1:21:35 PM UTC-7, aleks.fabijanic wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">> Le vendredi 29 mars 2013 1=
4:03:24 UTC+1, <a>glme...@gmail.com</a> a =E9crit :
<br>
<br>> I just don't see how this would be more useful or easy to us=
e than:
<br>>
<br>> struct
<br>> {
<br>> int foo;
<br>> string bar;
<br>> } t =3D { 5, "hello" };
<br>>
<br>> auto n =3D t.foo;
<br>> auto m =3D t.bar;
<br>
<br>Such comparison would be appropriate in a context of discussion "does
<br>C++ need std::tuple?" (or std::pair, for that matter).
<br>
<br>Since there already exists std::tuple<int, string> and it's being
<br>discussed here, relevant question is "which is better?":
<br>
<br>int i =3D t.get<0>();
<br>
<br>or
<br>
<br>int i =3D t["foo"];
<br>
<br>or
<br>
<br>int i =3D t<"bar">();
<br>
<br>Alex
<br></blockquote><div><br>Any such problems will be more effectively resolv=
ed once we have some compile-time reflection. Though it should be noted tha=
t the middle one is a runtime lookup, unlike the first which is compile-tim=
e. <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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1099_15025740.1364606564165--
.
Author: Aleksandar Fabijanic <aleks.fabijanic@gmail.com>
Date: Fri, 29 Mar 2013 20:27:53 -0500
Raw View
On Fri, Mar 29, 2013 at 8:21 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> So why should we prefer a new class, when all we need to get mostly
> equivalent is to add a std::any type? And that's already under discussion.
std::any will only give you exactly the type it holds and you have to
know up front *exactly* what it is (i.e. on data extraction side,
std::any "type system" is even more rigid than C++ type system - no
implicit conversions).
But that is a topic for another discussion. Here, the topic is merits
of access of tuple members by name (as opposed to access by index).
Alex
--
---
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/?hl=en.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 29 Mar 2013 18:36:17 -0700 (PDT)
Raw View
------=_Part_1102_17338300.1364607377650
Content-Type: text/plain; charset=ISO-8859-1
On Friday, March 29, 2013 6:27:53 PM UTC-7, aleks.fabijanic wrote:
>
> On Fri, Mar 29, 2013 at 8:21 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
>
> > So why should we prefer a new class, when all we need to get mostly
> > equivalent is to add a std::any type? And that's already under
> discussion.
>
> std::any will only give you exactly the type it holds and you have to
> know up front *exactly* what it is (i.e. on data extraction side,
> std::any "type system" is even more rigid than C++ type system - no
> implicit conversions).
>
> But that is a topic for another discussion. Here, the topic is merits
> of access of tuple members by name (as opposed to access by index).
>
And that implementation of that topic is what I'm talking about. The
implementation returns a DynamicAny, which is just a variation of `any`
that is implicitly convertible to it's original type (or throws an
exception). So it's a `map<string, DynamicAny>`; why do we need a whole new
class for that?
--
---
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/?hl=en.
------=_Part_1102_17338300.1364607377650
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Friday, March 29, 2013 6:27:53 PM UTC-7, aleks.fabijanic wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Mar 29, 2013 at 8:21 PM=
, Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"L-N6iJYzyrkJ">jmck...@gmail.com</a>> wrote:
<br>
<br>> So why should we prefer a new class, when all we need to get mostl=
y
<br>> equivalent is to add a std::any type? And that's already under dis=
cussion.
<br>
<br>std::any will only give you exactly the type it holds and you have to
<br>know up front *exactly* what it is (i.e. on data extraction side,
<br>std::any "type system" is even more rigid than C++ type system - no
<br>implicit conversions).
<br>
<br>But that is a topic for another discussion. Here, the topic is merits
<br>of access of tuple members by name (as opposed to access by index).
<br></blockquote><div><br>And that implementation of that topic is what I'm=
talking about. The implementation returns a DynamicAny, which is just a va=
riation of `any` that is implicitly convertible to it's original type (or t=
hrows an exception). So it's a `map<string, DynamicAny>`; why do we n=
eed a whole new class for that?<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1102_17338300.1364607377650--
.
Author: Aleksandar Fabijanic <aleks.fabijanic@gmail.com>
Date: Fri, 29 Mar 2013 20:56:39 -0500
Raw View
On Fri, Mar 29, 2013 at 8:36 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>> But that is a topic for another discussion. Here, the topic is merits
>> of access of tuple members by name (as opposed to access by index).
>
> And that implementation of that topic is what I'm talking about. The
> implementation returns a DynamicAny, which is just a variation of `any` that
> So is implicitly convertible to it's original type (or throws an exception).
It is convertible to *any type* as long as conversion makes sense, it
prevents loss of precision or narrowing conversions, it allows user
extensions etc. But none of that is relevant here.
> it's a `map<string, DynamicAny>`; why do we need a whole new class for that?
Since someone asked about tuple members access by name, I pointed to
something related - a tuple with added vector<string> containing names
for contained values. It was not suggested that there should be
another class.
This discussion is not about any, DynamicAny or std::map. It is about
access to tuple members by name.
Alex
--
---
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/?hl=en.
.
Author: Gian Lorenzo Meocci <glmeocci@gmail.com>
Date: Sat, 30 Mar 2013 10:12:21 +0100
Raw View
--047d7b621b1401a08b04d920c97f
Content-Type: text/plain; charset=ISO-8859-1
Imagine a C++ for all, not only for nerd people.
Imagine that you are writing a library like this:
class MyLib
{
public:
std::tuple<bool, int, std::string> f()
{
// some cool computation
return std::make_tuple(true, 0, "All works fine");
}
std::tuple<bool, int, int> g() { .... }
};
All method return some kind of tuple: the first member is a bool, the
second is always an int (errorcode) the third depend by function. The user
must remember that in case of g function the errorcode is the 2th not 3th.
So If I have the possibility to "tag" a position of element in a tuple I
can do something like that
class MyLib
{
public:
std::tuple<"result"@bool, "errorcode"@int, std::string> f()
{
// some cool computation
return std::make_tuple(true, 0, "All works fine");
}
std::tuple<"result"@bool, "errorcode"@int, int> g() { .... }
};
than the user can do :
MyLib lib;
auto t = lib.g();
std::cout << std::get<"errorcode">(t) << std::endl;
In this way I create only the class that I needed without introduced any
support struct or class. The code is more clear to read and to write!
On Sat, Mar 30, 2013 at 2:56 AM, Aleksandar Fabijanic <
aleks.fabijanic@gmail.com> wrote:
> On Fri, Mar 29, 2013 at 8:36 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> >> But that is a topic for another discussion. Here, the topic is merits
> >> of access of tuple members by name (as opposed to access by index).
> >
> > And that implementation of that topic is what I'm talking about. The
> > implementation returns a DynamicAny, which is just a variation of `any`
> that
> > So is implicitly convertible to it's original type (or throws an
> exception).
>
> It is convertible to *any type* as long as conversion makes sense, it
> prevents loss of precision or narrowing conversions, it allows user
> extensions etc. But none of that is relevant here.
>
> > it's a `map<string, DynamicAny>`; why do we need a whole new class for
> that?
>
> Since someone asked about tuple members access by name, I pointed to
> something related - a tuple with added vector<string> containing names
> for contained values. It was not suggested that there should be
> another class.
>
> This discussion is not about any, DynamicAny or std::map. It is about
> access to tuple members by name.
>
> Alex
>
> --
>
> ---
> 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/N-kIXNrkTUk/unsubscribe?hl=en
> .
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>
--
GL
http://www.meocci.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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--047d7b621b1401a08b04d920c97f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>Imagine a C++ for all, not only for nerd pe=
ople.<br>Imagine that you are writing a library like this:<br><br>class MyL=
ib<br>{<br></div>public:<br></div>=A0=A0=A0 std::tuple<bool, int, std::s=
tring> f()<br>
=A0 =A0 {<br></div><div>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 // some cool computa=
tion<br></div>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return std::make_tuple(true=
, 0, "All works fine");<br><div>=A0 =A0 } <br><br>=A0=A0=A0 <br>=
=A0=A0=A0 std::tuple<bool, int, int> g() { .... }<br>
<div><div>};<br><br></div><div>All method return some kind of tuple: the fi=
rst member is=A0 a bool, the second is always an int (errorcode) the third =
depend by function. The user must remember that in case of g function the e=
rrorcode is the 2th not 3th.<br>
<br></div><div>So If I have the possibility to "tag" a position o=
f element in a tuple I can do something like that<br><br>class MyLib<br>{<b=
r>public:<br>=A0=A0=A0 std::tuple<"result"@bool, "errorco=
de"@int, std::string> f()<br>
=A0 =A0 {<br><div>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 // some cool computation<b=
r></div>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return std::make_tuple(true, 0, &=
quot;All works fine");<br>=A0 =A0 } <br><br>=A0=A0=A0 <br>=A0=A0=A0 st=
d::tuple<"result"@bool, "errorcode"@int, int> g()=
{ .... }<br>
};<br><br></div><div>than the user can do :<br><br></div><div>MyLib lib;<br=
><br></div><div>auto t =3D lib.g();<br></div><div>std::cout << std::g=
et<"errorcode">(t) << std::endl;<br><br></div><div>
In this way I create only the class that I needed without introduced any su=
pport struct or class. The code is more clear to read and to write!<br></di=
v><div><br></div></div></div></div><div class=3D"gmail_extra"><br><br><div =
class=3D"gmail_quote">
On Sat, Mar 30, 2013 at 2:56 AM, Aleksandar Fabijanic <span dir=3D"ltr"><=
;<a href=3D"mailto:aleks.fabijanic@gmail.com" target=3D"_blank">aleks.fabij=
anic@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Fri, Mar 29, 2013 at 8:36 PM, Nicol Bolas <<a href=
=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>> wrote:<br>
<br>
>> But that is a topic for another discussion. Here, the topic is mer=
its<br>
>> of access of tuple members by name (as opposed to access by index)=
..<br>
><br>
> And that implementation of that topic is what I'm talking about. T=
he<br>
> implementation returns a DynamicAny, which is just a variation of `any=
` that<br>
</div>> So is implicitly convertible to it's original type (or throw=
s an exception).<br>
<br>
It is convertible to *any type* as long as conversion makes sense, it<br>
prevents loss of precision or narrowing conversions, it allows user<br>
extensions etc. But none of that is relevant here.<br>
<div class=3D"im"><br>
> it's a `map<string, DynamicAny>`; why do we need a whole new=
class for that?<br>
<br>
</div>Since someone asked about tuple members access by name, I pointed to<=
br>
something related - a tuple with added vector<string> containing name=
s<br>
for contained values. It was not suggested that there should be<br>
another class.<br>
<br>
This discussion is not about any, DynamicAny or std::map. It is about<br>
access to tuple members by name.<br>
<br>
Alex<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<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/N-kIXNrkTUk/unsubscribe?hl=3Den" target=
=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/N-=
kIXNrkTUk/unsubscribe?hl=3Den</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
<br>
<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>GL<br><a hr=
ef=3D"http://www.meocci.it" target=3D"_blank">http://www.meocci.it</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7b621b1401a08b04d920c97f--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 30 Mar 2013 03:51:48 -0700 (PDT)
Raw View
------=_Part_1343_13932909.1364640708301
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, March 30, 2013 2:12:21 AM UTC-7, Gian Lorenzo Meocci wrote:
>
> Imagine a C++ for all, not only for nerd people.
>
So, you mean what we have right now, right?
> Imagine that you are writing a library like this:
>
> class MyLib
> {
> public:
> std::tuple<bool, int, std::string> f()
> {
> // some cool computation
> return std::make_tuple(true, 0, "All works fine");
> }
>
>
> std::tuple<bool, int, int> g() { .... }
> };
>
> All method return some kind of tuple: the first member is a bool, the
> second is always an int (errorcode) the third depend by function. The user
> must remember that in case of g function the errorcode is the 2th not 3th.
>
Why would I be returning a std::tuple? I should be returning one of these:
template<typename t>
struct ErrorRet
{
bool didError;
int errorCode;
T actualData;
};
ErrorRet<int> g();
See? Much better. It has genuine semantics with a real name on it; people
don't have to ask what the tuple means or what its elements mean. And of
course this all assumes that I'm even using an error code at all instead of
an exception.
Plus, I can put actual semantics on the type. I can throw an `explicit
operator bool` onto it, so that I can test it without having to explicitly
use the `didError` member. I could change the value representation to
minimize pointless data storage, so that it uses a union between the
template argument type and the error code.
Or we could just standardize a "value or errorcode" type as people are
talking about ;).
To my mind, the *only* reason to use a tuple instead of a struct is because
you want to compile-time iterate over the elements of the data structure.
Which you can only do with a tuple, because C++ lacks reflection. Of
course, what that means is that, once we *do* get compile-time reflection,
the main use-case for tuple disappears.
Or said another way, we need structs to behave *more like tuples*, not
vice-versa. And then we won't need tuples anymore.
> So If I have the possibility to "tag" a position of element in a tuple I
> can do something like that
>
> class MyLib
> {
> public:
> std::tuple<"result"@bool, "errorcode"@int, std::string> f()
> {
> // some cool computation
> return std::make_tuple(true, 0, "All works fine");
> }
>
>
> std::tuple<"result"@bool, "errorcode"@int, int> g() { .... }
> };
>
> than the user can do :
>
> MyLib lib;
>
> auto t = lib.g();
> std::cout << std::get<"errorcode">(t) << std::endl;
>
> In this way I create only the class that I needed without introduced any
> support struct or class. The code is more clear to read and to write!
>
Is C++ running out of typenames? Do you honestly believe that there is
something onerous being added by using a real type with a real name, rather
than a nameless, semanticless collection of values? I hope you're not
asking for a feature just because you don't want to introduce a typename.
More importantly, how is that clear to read *or* write? I have no idea what
that tuple means semantically. The typename is gigantic and bulky to write,
and the *only* thing that saves you from having to see this big thing
everywhere is using `auto` when you store it. Even so, your IDE is still
going to show you a giant, bulky typename when you want to know what type
`t` is.
Furthermore, I'd love to hear how you justify saying that
`std::get<"errorcode">(t)` is "more clear to read and to write" than
`t.errorCode`? Especially considering your "Imagine a C++ for all, not only
for nerd people," statement at the top of your post. I don't know how many
non-"nerd people" even know that much about `std::tuple` to begin with, let
alone would see your `std::get` as being more obvious as to what's going on.
People seem to have these notions nowadays that tuples should be able to
replace structs or that lambdas should be able to replace functors. That a
tuple should be a quickie way to declare a struct, or that a lambda should
be a quickie way to declare a functor. I personally despise this, for
several reasons. The most important being that it starts corrupting good,
localized functionality in order to turn it into something it's not.
Someone actually suggested a lambda syntax where you could define multiple
functions in a single expression for the same lambda type. Really, is it *
that* hard to just make an inline struct right there in the function? We
can use those as template arguments now in C++11, so there's no excuse for
not doing it.
And here you are, suggesting we take simple, clear tuple functionality and
muddy it's purpose. A tuple is not a struct. A tuple should not *behave*like a struct. A tuple is a compile-time enumerable collection of values.
The very fact that you want to access tuple elements by some name rather
than an index says that you're using the *wrong datastructure* for your
task. This is no different from wanting to random access a linked-list;
that's a good indication that you picked the wrong container for your needs.
If you want a more compact struct definition syntax, ask for one. If you
want a more compact functor definition syntax, ask for one. But at no time
should you ask for what you're asking for now.
--
---
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/?hl=en.
------=_Part_1343_13932909.1364640708301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, March 30, 2013 2:12:21 AM UTC-7, Gian Lorenzo Meocci wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div><div>I=
magine a C++ for all, not only for nerd people.<br></div></div></div></div>=
</blockquote><div><br>So, you mean what we have right now, right?<br> =
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv><div>Imagine that you are writing a library like this:<br><br>class MyLi=
b<br>{<br></div>public:<br></div> std::tuple<bool, int=
, std::string> f()<br>
{<br></div><div> &nb=
sp; // some cool computation<br></div> &=
nbsp; return std::make_tuple(true, 0, "=
All works fine");<br><div> } <br><br> <br>&n=
bsp; std::tuple<bool, int, int> g() { .... }<br>
<div><div>};<br><br></div><div>All method return some kind of tuple: the fi=
rst member is a bool, the second is always an int (errorcode) the thi=
rd depend by function. The user must remember that in case of g function th=
e errorcode is the 2th not 3th.<br></div></div></div></div></blockquote><di=
v><br>Why would I be returning a std::tuple? I should be returning one of t=
hese:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250,=
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-w=
idth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">template</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typen=
ame</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t</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></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
606;" class=3D"styled-by-prettify">ErrorRet</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br> </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> didError</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> er=
rorCode</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> T=
actualData</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">ErrorRet</span><span sty=
le=3D"color: #080;" class=3D"styled-by-prettify"><int></span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> g</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>See? M=
uch better. It has genuine semantics with a real name on it; people don't h=
ave to ask what the tuple means or what its elements mean. And of course th=
is all assumes that I'm even using an error code at all instead of an excep=
tion.<br><br>Plus, I can put actual semantics on the type. I can throw an `=
explicit operator bool` onto it, so that I can test it without having to ex=
plicitly use the `didError` member. I could change the value representation=
to minimize pointless data storage, so that it uses a union between the te=
mplate argument type and the error code.<br><br>Or we could just standardiz=
e a "value or errorcode" type as people are talking about ;).<br><br>To my =
mind, the <i>only</i> reason to use a tuple instead of a struct is because =
you want to compile-time iterate over the elements of the data structure. W=
hich you can only do with a tuple, because C++ lacks reflection. Of course,=
what that means is that, once we <i>do</i> get compile-time reflection, th=
e main use-case for tuple disappears.<br><br>Or said another way, we need s=
tructs to behave <i>more like tuples</i>, not vice-versa. And then we won't=
need tuples anymore.<br> <br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div><div><div>
</div><div>So If I have the possibility to "tag" a position of element in a=
tuple I can do something like that<br><br>class MyLib<br>{<br>public:<br>&=
nbsp; std::tuple<"result"@bool, "errorcode"@int, std::string=
> f()<br>
{<br><div> &nb=
sp; // some cool computation<br></div> &=
nbsp; return std::make_tuple(true, 0, "All wo=
rks fine");<br> } <br><br> <br> &=
nbsp; std::tuple<"result"@bool, "errorcode"@int, int> g() { .... }<br=
>
};<br><br></div><div>than the user can do :<br><br></div><div>MyLib lib;<br=
><br></div><div>auto t =3D lib.g();<br></div><div>std::cout << std::g=
et<"errorcode">(t) << std::endl;<br><br></div><div>
In this way I create only the class that I needed without introduced any su=
pport struct or class. The code is more clear to read and to write!</div></=
div></div></div></blockquote><div><br>Is C++ running out of typenames? Do y=
ou honestly believe that there is something onerous being added by using a =
real type with a real name, rather than a nameless, semanticless collection=
of values? I hope you're not asking for a feature just because you don't w=
ant to introduce a typename.<br><br>More importantly, how is that clear to =
read <i>or</i> write? I have no idea what that tuple means semantically. Th=
e typename is gigantic and bulky to write, and the <i>only</i> thing that s=
aves you from having to see this big thing everywhere is using `auto` when =
you store it. Even so, your IDE is still going to show you a giant, bulky t=
ypename when you want to know what type `t` is.<br><br>Furthermore, I'd lov=
e to hear how you justify saying that `std::get<"errorcode">(t)` is "=
more clear to read and to write" than `t.errorCode`? Especially considering=
your "Imagine a C++ for all, not only for nerd people," statement at the t=
op of your post. I don't know how many non-"nerd people" even know that muc=
h about `std::tuple` to begin with, let alone would see your `std::get` as =
being more obvious as to what's going on.<br><br>People seem to have these =
notions nowadays that tuples should be able to replace structs or that lamb=
das should be able to replace functors. That a tuple should be a quickie wa=
y to declare a struct, or that a lambda should be a quickie way to declare =
a functor. I personally despise this, for several reasons. The most importa=
nt being that it starts corrupting good, localized functionality in order t=
o turn it into something it's not.<br><br>Someone actually suggested a lamb=
da syntax where you could define multiple functions in a single expression =
for the same lambda type. Really, is it <i>that</i> hard to just make an in=
line struct right there in the function? We can use those as template argum=
ents now in C++11, so there's no excuse for not doing it.<br><br>And here y=
ou are, suggesting we take simple, clear tuple functionality and muddy it's=
purpose. A tuple is not a struct. A tuple should not <i>behave</i> like a =
struct. A tuple is a compile-time enumerable collection of values. The very=
fact that you want to access tuple elements by some name rather than an in=
dex says that you're using the <i>wrong datastructure</i> for your task. Th=
is is no different from wanting to random access a linked-list; that's a go=
od indication that you picked the wrong container for your needs.<br><br>If=
you want a more compact struct definition syntax, ask for one. If you want=
a more compact functor definition syntax, ask for one. But at no time shou=
ld you ask for what you're asking for now.</div><br>
<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1343_13932909.1364640708301--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 30 Mar 2013 03:57:16 -0700 (PDT)
Raw View
------=_Part_1256_13645640.1364641036975
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, March 30, 2013 3:51:48 AM UTC-7, Nicol Bolas wrote:
>
> To my mind, the *only* reason to use a tuple instead of a struct is
> because you want to compile-time iterate over the elements of the data
> structure. Which you can only do with a tuple, because C++ lacks
> reflection. Of course, what that means is that, once we *do* get
> compile-time reflection, the main use-case for tuple disappears.
>
Let me take that back. There is a second reason: if you're using template
metaprogramming techniques to build some value. This may well require the
ability to put together some type from raw materials in a way that a
template struct can't do.
Of course, that's another thing that is being talked about with respect to
reflection.
--
---
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/?hl=en.
------=_Part_1256_13645640.1364641036975
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, March 30, 2013 3:51:48 AM UTC-7, Nicol Bolas wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">To my mind, the <i>only</i> reason to use=
a tuple instead of a struct is because you want to compile-time iterate ov=
er the elements of the data structure. Which you can only do with a tuple, =
because C++ lacks reflection. Of course, what that means is that, once we <=
i>do</i> get compile-time reflection, the main use-case for tuple disappear=
s.<br></blockquote><div><br>Let me take that back. There is a second reason=
: if you're using template metaprogramming techniques to build some value. =
This may well require the ability to put together some type from raw materi=
als in a way that a template struct can't do.<br><br>Of course, that's anot=
her thing that is being talked about with respect to reflection.<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1256_13645640.1364641036975--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Mon, 01 Apr 2013 17:44:26 +0200
Raw View
This is a multi-part message in MIME format.
--------------090300030607000209000207
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 29/03/13 14:03, glmeocci@gmail.com a =E9crit :
> Hi,
>
> I propose to add a new future to C++14: "the named tuple".
> In some case could be very usefull to have something like that:
>
> std::tuple< *foo@int*, *bar@std::string *> t =3D std::make_tuple(5,=20
> "hello!");
>
> than we can access to our tuple in this way:
>
> auto n =3D std::get<foo>(t);
> auto m =3D std::get<bar>(t);
>
> What is your idea about this?
>
Hi,
I think the first think to do is to add tagged tuples as the ones=20
available in Boost.Fusion.
Once you have tagged tuples in the standard, the syntax you are=20
proposing is syntactical sugar.
There are however some scope issues, what is the scope of the names foo=20
and bar?
How the compiler could associate foo to the correct foo? E.g.
std::tuple< *foo@int*, *bar@std::string *> t1 =3D std::make_tuple(5,=20
"hello!");
std::tuple< *bar@std::string, ***foo@int* *> t2 =3D std::make_tuple(=20
"hello!", 5);
auto n =3D std::get<foo>(t1);
I don't know too much about compiler design, but having to look at the=20
type of t1 to understand which foo are we referring to is quite complex.=20
Maybe you need something like
auto n =3D std::get<t1::foo>(t1);
If opaque types are accepted they should allow to do something similar.
With the syntax proposed in=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf
using foo =3D public int;
using far =3D public std::string;
std::tuple< *foo*, *bar *> t =3D std::make_tuple(5, "hello!");
auto n =3D std::get<foo>(t);
auto m =3D std::get<bar>(t);
Of course this doesn't respond completely to your need and that I=20
recognize this could seem artificial when the user is not working=20
already with opaque types.
Best regards,
Vicente
--=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/?hl=3Den.
--------------090300030607000209000207
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 29/03/13 14:03, <a class="moz-txt-link-abbreviated" href="mailto:glmeocci@gmail.com">glmeocci@gmail.com</a> a
écrit :<br>
</div>
<blockquote
cite="mid:91b9e5d2-e293-4c31-b9fc-641cc546c091@isocpp.org"
type="cite">Hi,<br>
<br>
I propose to add a new future to C++14: "the named tuple".<br>
In some case could be very usefull to have something like that:<br>
<br>
std::tuple< <b>foo@int</b>, <b>bar@std::string </b>> t =
std::make_tuple(5, "hello!");<br>
<br>
than we can access to our tuple in this way:<br>
<br>
auto n = std::get<foo>(t);<br>
auto m = std::get<bar>(t);<br>
<br>
<span id="result_box" class="short_text" lang="en"><span
class="hps">What is your</span> <span class="hps">idea about
this?</span></span><br>
<br>
</blockquote>
<br>
Hi, <br>
<br>
<br>
I think the first think to do is to add tagged tuples as the ones
available in Boost.Fusion.<br>
Once you have tagged tuples in the standard, the syntax you are
proposing is syntactical sugar. <br>
There are however some scope issues, what is the scope of the names
foo and bar?<br>
How the compiler could associate foo to the correct foo? E.g.<br>
<br>
std::tuple< <b>foo@int</b>, <b>bar@std::string </b>> t1 =
std::make_tuple(5, "hello!");<br>
std::tuple< <b>bar@std::string, </b><b><b>foo@int</b> </b>>
t2 = std::make_tuple( "hello!", 5);<br>
<br>
auto n = std::get<foo>(t1);<br>
<br>
I don't know too much about compiler design, but having to look at
the type of t1 to understand which foo are we referring to is quite
complex. Maybe you need something like<br>
<br>
auto n = std::get<t1::foo>(t1);<br>
<br>
If opaque types are accepted they should allow to do something
similar. <br>
With the syntax proposed in
<a class="moz-txt-link-freetext" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf</a><br>
<br>
using foo = public int;<br>
using far = public std::string;<br>
std::tuple< <b>foo</b>, <b>bar </b>> t = std::make_tuple(5,
"hello!");<br>
<br>
auto n = std::get<foo>(t);<br>
auto m = std::get<bar>(t);<br>
<br>
Of course this doesn't respond completely to your need and that I
recognize this could seem artificial when the user is not working
already with opaque types.<br>
<br>
Best regards,<br>
Vicente<br>
</body>
</html>
<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 email 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="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------090300030607000209000207--
.
Author: glmeocci@gmail.com
Date: Sun, 7 Apr 2013 09:15:52 -0700 (PDT)
Raw View
------=_Part_1148_924273.1365351352873
Content-Type: text/plain; charset=ISO-8859-1
thanks to all for clarification and comments
On Friday, March 29, 2013 2:03:24 PM UTC+1, glme...@gmail.com wrote:
>
> Hi,
>
> I propose to add a new future to C++14: "the named tuple".
> In some case could be very usefull to have something like that:
>
> std::tuple< *foo@int*, *bar@std::string *> t = std::make_tuple(5,
> "hello!");
>
> than we can access to our tuple in this way:
>
> auto n = std::get<foo>(t);
> auto m = std::get<bar>(t);
>
> What is your idea about this?
> Thanks
>
--
---
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/?hl=en.
------=_Part_1148_924273.1365351352873
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
thanks to all for clarification and comments<br><br>On Friday, March 29, 20=
13 2:03:24 PM UTC+1, glme...@gmail.com wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">Hi,<br><br>I propose to add a new future to C++14: "the name=
d tuple".<br>In some case could be very usefull to have something like that=
:<br><br>std::tuple< <b>foo@int</b>, <b>bar@std::string </b>> t =3D s=
td::make_tuple(5, "hello!");<br><br>than we can access to our tuple in this=
way:<br><br>auto n =3D std::get<foo>(t);<br>auto m =3D std::get<b=
ar>(t);<br><br><span lang=3D"en"><span>What is your</span> <span>idea ab=
out this?</span></span><br>Thanks <br></blockquote>
<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1148_924273.1365351352873--
.
Author: masse.nicolas@gmail.com
Date: Thu, 9 May 2013 11:55:29 -0700 (PDT)
Raw View
------=_Part_145_19322912.1368125729055
Content-Type: text/plain; charset=ISO-8859-1
Hi,
for my part, what I'd like to do is to cast tuples into a struct.
Basically, the idea is to cast std::tuple into a struct whose fields will
correspond the those of the tuple.
My goal is to be able to do things like :
typedef std::tuple<int, int, std::string> user_record_type; // Note that
this definition is here for the example only. In my case, the type
user_record_type will in fact be computed as a std::tuple<int, int,
std::string> using metaprogramming.
user_record_type get_random_user_from_db();
//...
struct user { int id; int gid; std::string name; }
//...
user& u = (user)get_random_user_from_db();
std::cout << "User Id: " << u.id << " Group Id: " << u.gid << " User Name:"
<< u.name;
After some tests for that, here is what I could say:
* this could probably be achieved with compile-time refelection by copying
every field of the tuple into the struct, but I'd like to avoid copying
datas.
* using reinterpret_cast just doesn't work. The main reason is that
std::tuple<int, int, std::string> doesn't necessary have the same layout
than a struct with 3 fields. (for example, on gcc the field are stored in
reverse order).
* I've been able to do an (incomplete) implementation of std::tuple where
an std::tuple<int, int, std::string> seems to have the same layout than the
struct user as define above. Anyway, I'm unsure this is something wich is
guaranted by the standart.
* By overloading the cast operator, I was able to make the above example
work. Note that the cast operator also check that the struct is
standart-layout and have the same size in memory than the tuple. This is
done to check that they both have the same layout. Even if incomplete, this
check remains usefull in most situations. (what about adding
std::is_same_layout<T1, T2>?)
What do you think of 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_145_19322912.1368125729055
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi,<br>for my part, what I'd like to do is to cast tuples into a struct. <b=
r>Basically, the idea is to cast std::tuple into a struct whose fields will=
correspond the those of the tuple.<br><br>My goal is to be able to do thin=
gs like :<br><div style=3D"background-color: #FAFAFA; border-color: #BBB; b=
order-style: solid; border-width: 1px; word-wrap: break-word;" class=3D"pre=
ttyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">typedef</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">tuple</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
nt</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"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">string</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> user_record_type</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// Note that this definition is here for the exampl=
e only. In my case, the type user_record_type will in fact be computed as a=
std::tuple<int, int, std::string> using metaprogramming.</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br>user_record_type g=
et_random_user_from_db</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">/=
/...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> user </span><sp=
an 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=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> id</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
gid</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"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> name</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"=
styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-prett=
ify">//...</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>user</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&a=
mp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> u </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n 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">user</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">get_random_user_from_db</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><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">cout </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify"><<</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettif=
y">"User Id: "</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><&=
lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> u</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">id </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify"><<</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #08=
0;" class=3D"styled-by-prettify">" Group Id: "</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> u</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">gid </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: #080;" class=3D"styled-by-prettify">" User Na=
me:"</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify"><<</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> u</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">name</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span></div></code></div><br><br>After=
some tests for that, here is what I could say:<br>* this could probably be=
achieved with compile-time refelection by copying every field of the tuple=
into the struct, but I'd like to avoid copying datas.<br>* using reinterpr=
et_cast just doesn't work. The main reason is that std::tuple<int, int, =
std::string> doesn't necessary have the same layout than a struct with 3=
fields. (for example, on gcc the field are stored in reverse order).<br>* =
I've been able to do an (incomplete) implementation of std::tuple where an =
std::tuple<int, int, std::string> seems to have the same layout than =
the struct user as define above. Anyway, I'm unsure this is something wich =
is guaranted by the standart.<br>* By overloading the cast operator, I was =
able to make the above example work. Note that the cast operator also check=
that the struct is standart-layout and have the same size in memory than t=
he tuple. This is done to check that they both have the same layout. Even i=
f incomplete, this check remains usefull in most situations. (what about ad=
ding std::is_same_layout<T1, T2>?) <br><br><br>What do you think of i=
t? <br>
<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_145_19322912.1368125729055--
.
Author: germandiago@gmail.com
Date: Fri, 17 May 2013 01:19:51 -0700 (PDT)
Raw View
------=_Part_508_22290953.1368778791552
Content-Type: text/plain; charset=ISO-8859-1
From c++ now conference:
https://github.com/boostcon/cppnow_presentations_2013
This path seems to solve a broader problem: Sebastian Redl: Overloading the
Member Access Operator<https://github.com/boostcon/cppnow_presentations_2013/blob/master/thu/overloading_dot.pdf?raw=true>
Including named tuples also.
--
---
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/?hl=en.
------=_Part_508_22290953.1368778791552
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
From c++ now conference: <a href=3D"https://github.com/boostcon/cppnow=
_presentations_2013">https://github.com/boostcon/cppnow_presentations_2013<=
/a><div><br></div><div>This path seems to solve a broader problem: <a =
href=3D"https://github.com/boostcon/cppnow_presentations_2013/blob/master/t=
hu/overloading_dot.pdf?raw=3Dtrue" style=3D"color: rgb(65, 131, 196); font-=
family: Helvetica, arial, freesans, clean, sans-serif; font-size: 15.454545=
021057129px; line-height: 22.727272033691406px;">Sebastian Redl: Overloadin=
g the Member Access Operator</a></div><div><br></div><div>Including named t=
uples also.</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_508_22290953.1368778791552--
.
Author: snk_kid <korcan.hussein@googlemail.com>
Date: Sat, 18 May 2013 04:31:41 -0700 (PDT)
Raw View
------=_Part_1660_26353521.1368876701425
Content-Type: text/plain; charset=ISO-8859-1
The best and most general solution which not only fixes/improves the
situation but improves many other features is to make tuple types built-in
types and add support for pattern matching (and I don't mean just for
tuples but in general). There is should be no reason that built-in tuples
and pattern matching can be as efficient if not more so than any library
solution and could easily be just syntactic sugar just as much as lambda
expressions in C++11 currently are. Some imaginary examples of C++ with
built-in tuple types and pattern matching:
// a simple type-inferred tuple binding:
auto x = (0, 0.0f, "foo"); // the type of x is inferred to be the tuple
type: (int, float, const char*)
// the same as above but without local type inference:
(int, float, const char*) x = (0, 0.0f, "foo");
// some tuple pattern binding expressions (with type inference) using 'x'
from the above:
auto (a, _, _) = x; // 'a' is bound too the first element of the tuple 'x',
and a can be freely used, the other elements are ignored.
auto (_, _, c) = x; // 'c' is bound too the last element of the tuple 'x',
other elements ignored.
auto (_, y, z) = x; // 'y' and 'z' are bound to the second and last element
of 'x', others ignored.
auto (f@(_, k, _)) = (1, foo_type(), bar_type()); // 'f' binds to the whole
tuple, 'k' binds the second element.
// tuples in functions and tupple patterns in function arguments:
auto make_a_2_tuple(float x, int y) -> (float,int)
{
return (x,y);
}
template < typename FirstType, typename SecondType >
auto first(const (FirstType,SecondType)& (x, _)) -> FirstType
return x;
}
template < typename FirstType, typename SecondType >
auto second(const (FirstType,SecondType)& (_, x)) -> SecondType
{
return x;
}
// using the above definitions:
auto x = make_a_2_tuple(0.0f,0);
auto (y,z) = make_a_2_tuple(0.0f,0);
auto (_,k) = make_a_2_tuple(0.0f,0);
auto j = (1,1);
int x = second(j);
int y = first(j);
Not every language abstraction should be forced in to or even make sense as
a library abstraction. Why is the community making this so hard? I see no
reason why we couldn't have the above any more than we have say lambda
expressions and be just as efficient if not more so than a library solution
without all the ugly hacks and adding more peculiar language changes to
just make the library abstraction work.
Can we please at least try to pursue the possibility.
On Friday, March 29, 2013 1:03:24 PM UTC, glme...@gmail.com wrote:
>
> Hi,
>
> I propose to add a new future to C++14: "the named tuple".
> In some case could be very usefull to have something like that:
>
> std::tuple< *foo@int*, *bar@std::string *> t = std::make_tuple(5,
> "hello!");
>
> than we can access to our tuple in this way:
>
> auto n = std::get<foo>(t);
> auto m = std::get<bar>(t);
>
> What is your idea about this?
> Thanks
>
--
---
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/?hl=en.
------=_Part_1660_26353521.1368876701425
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
The best and most general solution which not only fixes/improves the situat=
ion but improves many other features is to make tuple types built-in types =
and add support for pattern matching (and I don't mean just for tuples but =
in general). There is should be no reason that built-in tuples and pattern =
matching can be as efficient if not more so than any library solution and c=
ould easily be just syntactic sugar just as much as lambda expressions in C=
++11 currently are. Some imaginary examples of C++ with built-in tuple type=
s and pattern matching:<br><br><div class=3D"prettyprint" style=3D"backgrou=
nd-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-styl=
e: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">// a simple type-inferred tuple binding:</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> x </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">=3D</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: #066;" class=3D"styled-by-pret=
tify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #066;" class=3D"styled-by-prettify">0.0f</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;"=
class=3D"styled-by-prettify">"foo"</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">// the type of x is inferred to be the tuple type: (int, float, con=
st char*)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =
the same as above but without local type inference:</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>float</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</s=
pan><span style=3D"color: #000;" 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"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">*)</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> x </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</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: #066;" class=3D"styled-by-prettify">0</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">0.0f</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"sty=
led-by-prettify">"foo"</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">// some tuple pattern binding expressions (with type inference) using 'x'=
from the above:</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">a</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"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;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><sp=
an 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=
: #800;" class=3D"styled-by-prettify">// 'a' is bound too the first element=
of the tuple 'x', and a can be freely used, the other elements are ignored=
..</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br><=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #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"> _</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> c</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// 'c' is bound too the last element of the tuple '=
x', other elements ignored.</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </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"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> z</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// 'y' and 'z' are bound to=
the second and last element of 'x', others ignored.</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> (f@</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">_</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> k</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> _</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: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo_type=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(),</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> bar_type</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">());</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">// 'f' binds to the whole tuple, =
'k' binds the second element.</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br><br></span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">// tuples in functions and tupple patterns in function arg=
uments:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
><br>auto make_a_2_tuple(float x, int y) -> (float,int)<br>{<br> &n=
bsp; return (x,y);<br>}<br><br></span>template < typename FirstTyp=
e, typename SecondType ><code class=3D"prettyprint"><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span></code>auto<span style=3D"=
color: #000;" class=3D"styled-by-prettify"> first</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">const </span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><code class=3D"prettyprint"><code class=3D"pretty=
print"><span style=3D"color: #000;" class=3D"styled-by-prettify">(</span></=
code></code></span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><code class=3D"prettyprint">FirstType,SecondType)</code>& (x, _)) -&g=
t; </span><code class=3D"prettyprint">FirstType<br></code><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br> return x;<br>}<br=
><br></span><br><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
code class=3D"prettyprint">template < typename FirstType, typename Secon=
dType ><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span></code>auto<span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> second</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">const </span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><code class=3D"prettyprint"><code class=3D"prettyprint"><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">(</span></code></code></s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><code class=
=3D"prettyprint">FirstType,SecondType)</code>& (_, x)) -> </span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prett=
yprint">SecondType<br></code>{<br> return x;<br>}</span></code>=
<br><br>// using the above definitions:<br><br>auto x =3D </span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prettyprint"=
><span style=3D"color: #000;" class=3D"styled-by-prettify">make_a_2_tuple</=
span></code>(0.0f,0);<br><br>auto (y,z) =3D </span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify"></span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">make_a_2_tuple</span></code=
>(0.0f,0);<br></span></code></span><br>auto (_,k) =3D <code class=3D"pretty=
print"><span style=3D"color: #000;" class=3D"styled-by-prettify"><code clas=
s=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">make_a_2_tuple</span></code>(0.0f,0);<br><br>auto j =3D (1,1);<=
br>int x =3D second(</span></code></span></code><code class=3D"prettyprint"=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"p=
rettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify"><code=
class=3D"prettyprint"><code class=3D"prettyprint"><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">j</span></code></span></code=
></code>);<br>int y =3D first(</span></code></span></code><code class=3D"pr=
ettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify"><code =
class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><code class=3D"prettyprint"><code class=3D"prettyprint"><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">j</span></code></spa=
n></code></code>);<br></span></code></span></code></div></code></div><br>No=
t every language abstraction should be forced in to or even make sense as a=
library abstraction. Why is the community making this so hard? I see no re=
ason why we couldn't have the above any more than we have say lambda expres=
sions and be just as efficient if not more so than a library solution witho=
ut all the ugly hacks and adding more peculiar language changes to just mak=
e the library abstraction work.<br><br>Can we please at least try to pursue=
the possibility.<br><br>On Friday, March 29, 2013 1:03:24 PM UTC, glme...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi,<br><br>I p=
ropose to add a new future to C++14: "the named tuple".<br>In some case cou=
ld be very usefull to have something like that:<br><br>std::tuple< <b>fo=
o@int</b>, <b>bar@std::string </b>> t =3D std::make_tuple(5, "hello!");<=
br><br>than we can access to our tuple in this way:<br><br>auto n =3D std::=
get<foo>(t);<br>auto m =3D std::get<bar>(t);<br><br><span lang=
=3D"en"><span>What is your</span> <span>idea about this?</span></span><br>T=
hanks <br></blockquote>
<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1660_26353521.1368876701425--
.
Author: Gian Lorenzo Meocci <glmeocci@gmail.com>
Date: Sat, 18 May 2013 13:47:43 +0200
Raw View
--089e0160c9f4dd472a04dcfcaa91
Content-Type: text/plain; charset=ISO-8859-1
I agree with you, this code is more cleaner and elegant!
On Sat, May 18, 2013 at 1:31 PM, snk_kid <korcan.hussein@googlemail.com>wrote:
> The best and most general solution which not only fixes/improves the
> situation but improves many other features is to make tuple types built-in
> types and add support for pattern matching (and I don't mean just for
> tuples but in general). There is should be no reason that built-in tuples
> and pattern matching can be as efficient if not more so than any library
> solution and could easily be just syntactic sugar just as much as lambda
> expressions in C++11 currently are. Some imaginary examples of C++ with
> built-in tuple types and pattern matching:
>
> // a simple type-inferred tuple binding:
> auto x = (0, 0.0f, "foo"); // the type of x is inferred to be the tuple
> type: (int, float, const char*)
>
> // the same as above but without local type inference:
> (int, float, const char*) x = (0, 0.0f, "foo");
>
> // some tuple pattern binding expressions (with type inference) using 'x'
> from the above:
>
> auto (a, _, _) = x; // 'a' is bound too the first element of the tuple
> 'x', and a can be freely used, the other elements are ignored.
>
> auto (_, _, c) = x; // 'c' is bound too the last element of the tuple
> 'x', other elements ignored.
>
> auto (_, y, z) = x; // 'y' and 'z' are bound to the second and last
> element of 'x', others ignored.
>
> auto (f@(_, k, _)) = (1, foo_type(), bar_type()); // 'f' binds to the
> whole tuple, 'k' binds the second element.
>
> // tuples in functions and tupple patterns in function arguments:
>
> auto make_a_2_tuple(float x, int y) -> (float,int)
> {
> return (x,y);
> }
>
> template < typename FirstType, typename SecondType >
> auto first(const (FirstType,SecondType)& (x, _)) -> FirstType
>
> return x;
> }
>
>
> template < typename FirstType, typename SecondType >
> auto second(const (FirstType,SecondType)& (_, x)) -> SecondType
> {
> return x;
> }
>
> // using the above definitions:
>
> auto x = make_a_2_tuple(0.0f,0);
>
> auto (y,z) = make_a_2_tuple(0.0f,0);
>
> auto (_,k) = make_a_2_tuple(0.0f,0);
>
> auto j = (1,1);
> int x = second(j);
> int y = first(j);
>
> Not every language abstraction should be forced in to or even make sense
> as a library abstraction. Why is the community making this so hard? I see
> no reason why we couldn't have the above any more than we have say lambda
> expressions and be just as efficient if not more so than a library solution
> without all the ugly hacks and adding more peculiar language changes to
> just make the library abstraction work.
>
> Can we please at least try to pursue the possibility.
>
>
> On Friday, March 29, 2013 1:03:24 PM UTC, glme...@gmail.com wrote:
>>
>> Hi,
>>
>> I propose to add a new future to C++14: "the named tuple".
>> In some case could be very usefull to have something like that:
>>
>> std::tuple< *foo@int*, *bar@std::string *> t = std::make_tuple(5,
>> "hello!");
>>
>> than we can access to our tuple in this way:
>>
>> auto n = std::get<foo>(t);
>> auto m = std::get<bar>(t);
>>
>> What is your idea about this?
>> Thanks
>>
>
--
GL
http://www.meocci.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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--089e0160c9f4dd472a04dcfcaa91
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I agree with you, this code is more cleaner and elegant!<b=
r></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sa=
t, May 18, 2013 at 1:31 PM, snk_kid <span dir=3D"ltr"><<a href=3D"mailto=
:korcan.hussein@googlemail.com" target=3D"_blank">korcan.hussein@googlemail=
..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">The best and most general solution which not=
only fixes/improves the situation but improves many other features is to m=
ake tuple types built-in types and add support for pattern matching (and I =
don't mean just for tuples but in general). There is should be no reaso=
n that built-in tuples and pattern matching can be as efficient if not more=
so than any library solution and could easily be just syntactic sugar just=
as much as lambda expressions in C++11 currently are. Some imaginary examp=
les of C++ with built-in tuple types and pattern matching:<br>
<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div=
><span style=3D"color:#800">// a simple type-inferred tuple binding:</span>=
<span style><br>
</span><span style=3D"color:#008">auto</span><span style> x </span><span st=
yle=3D"color:#660">=3D</span><span style> </span><span style=3D"color:#660"=
>(</span><span style=3D"color:#066">0</span><span style=3D"color:#660">,</s=
pan><span style> </span><span style=3D"color:#066">0.0f</span><span style=
=3D"color:#660">,</span><span style> </span><span style=3D"color:#080">&quo=
t;foo"</span><span style=3D"color:#660">);</span><span style> </span><=
span style=3D"color:#800">// the type of x is inferred to be the tuple type=
: (int, float, const char*)</span><span style><br>
<br></span><span style=3D"color:#800">// the same as above but without loca=
l type inference:</span><span style><br></span><span style=3D"color:#660">(=
</span><span style=3D"color:#008">int</span><span style=3D"color:#660">,</s=
pan><span style> </span><span style=3D"color:#008">float</span><span style=
=3D"color:#660">,</span><span style> </span><span style=3D"color:#008">cons=
t</span><span style> </span><span style=3D"color:#008">char</span><span sty=
le=3D"color:#660">*)</span><span style> x </span><span style=3D"color:#660"=
>=3D</span><span style> </span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#066">0</span><span style=3D"color:#660">,</span><span style> <=
/span><span style=3D"color:#066">0.0f</span><span style=3D"color:#660">,</s=
pan><span style> </span><span style=3D"color:#080">"foo"</span><s=
pan style=3D"color:#660">);</span><span style><br>
<br></span><span style=3D"color:#800">// some tuple pattern binding express=
ions (with type inference) using 'x' from the above:</span><span st=
yle><br><br></span><span style=3D"color:#008">auto</span><span style> </spa=
n><span style=3D"color:#660">(</span><span style>a</span><span style=3D"col=
or:#660">,</span><span style> _</span><span style=3D"color:#660">,</span><s=
pan style> _</span><span style=3D"color:#660">)</span><span style> </span><=
span style=3D"color:#660">=3D</span><span style> x</span><span style=3D"col=
or:#660">;</span><span style> </span><span style=3D"color:#800">// 'a&#=
39; is bound too the first element of the tuple 'x', and a can be f=
reely used, the other elements are ignored.</span><span style><br>
<br></span><span style=3D"color:#008">auto</span><span style> </span><span =
style=3D"color:#660">(</span><span style>_</span><span style=3D"color:#660"=
>,</span><span style> _</span><span style=3D"color:#660">,</span><span styl=
e> c</span><span style=3D"color:#660">)</span><span style> </span><span sty=
le=3D"color:#660">=3D</span><span style> x</span><span style=3D"color:#660"=
>;</span><span style> </span><span style=3D"color:#800">// 'c' is b=
ound too the last element of the tuple 'x', other elements ignored.=
</span><span style><br>
<br></span><span style=3D"color:#008">auto</span><span style> </span><span =
style=3D"color:#660">(</span><span style>_</span><span style=3D"color:#660"=
>,</span><span style> y</span><span style=3D"color:#660">,</span><span styl=
e> z</span><span style=3D"color:#660">)</span><span style> </span><span sty=
le=3D"color:#660">=3D</span><span style> x</span><span style=3D"color:#660"=
>;</span><span style> </span><span style=3D"color:#800">// 'y' and =
'z' are bound to the second and last element of 'x', others=
ignored.</span><span style><br>
<br></span><span style=3D"color:#008">auto</span><span style> (f@</span><sp=
an style=3D"color:#660">(</span><span style>_</span><span style=3D"color:#6=
60">,</span><span style> k</span><span style=3D"color:#660">,</span><span s=
tyle> _</span><span style=3D"color:#660">))</span><span style> </span><span=
style=3D"color:#660">=3D</span><span style> </span><span style=3D"color:#6=
60">(</span><span style=3D"color:#066">1</span><span style=3D"color:#660">,=
</span><span style> foo_type</span><span style=3D"color:#660">(),</span><sp=
an style> bar_type</span><span style=3D"color:#660">());</span><span style>=
</span><span style=3D"color:#800">// 'f' binds to the whole tuple,=
'k' binds the second element.</span><span style><br>
<br></span><span style=3D"color:#800">// tuples in functions and tupple pat=
terns in function arguments:</span><span style><br><br>auto make_a_2_tuple(=
float x, int y) -> (float,int)<br>{<br>=A0=A0=A0 return (x,y);<br>}<br><=
br></span>template < typename FirstType, typename SecondType ><code><=
span style><br>
</span></code>auto<span style> first</span><span style=3D"color:#660">(</sp=
an><span style>const </span><span style><code><code><span style>(</span></c=
ode></code></span><span style><code>FirstType,SecondType)</code>& (x, _=
)) -> </span><code>FirstType<br>
</code><span style><br>=A0=A0 return x;<br>}<br><br></span><br><span style>=
<code>template < typename FirstType, typename SecondType ><code><span=
style><br></span></code>auto<span style> second</span><span style=3D"color=
:#660">(</span><span style>const </span><span style><code><code><span style=
>(</span></code></code></span><span style><code>FirstType,SecondType)</code=
>& (_, x)) -> </span><span style><code>SecondType<br>
</code>{<br>=A0=A0 return x;<br>}</span></code><br><br>// using the above d=
efinitions:<br><br>auto x =3D </span><span style><code><span style>make_a_2=
_tuple</span></code>(0.0f,0);<br><br>auto (y,z) =3D </span><span style><cod=
e><span style></span><span style><code><span style>make_a_2_tuple</span></c=
ode>(0.0f,0);<br>
</span></code></span><br>auto (_,k) =3D <code><span style><code><span style=
><code><span style>make_a_2_tuple</span></code>(0.0f,0);<br><br>auto j =3D =
(1,1);<br>int x =3D second(</span></code></span></code><code><span style><c=
ode><span style><code><code><span style><code><span style>j</span></code></=
span></code></code>);<br>
int y =3D first(</span></code></span></code><code><span style><code><span s=
tyle><code><code><span style><code><span style>j</span></code></span></code=
></code>);<br></span></code></span></code></div></code></div><br>Not every =
language abstraction should be forced in to or even make sense as a library=
abstraction. Why is the community making this so hard? I see no reason why=
we couldn't have the above any more than we have say lambda expression=
s and be just as efficient if not more so than a library solution without a=
ll the ugly hacks and adding more peculiar language changes to just make th=
e library abstraction work.<br>
<br>Can we please at least try to pursue the possibility.<div class=3D"HOEn=
Zb"><div class=3D"h5"><br><br>On Friday, March 29, 2013 1:03:24 PM UTC, <a =
href=3D"mailto:glme...@gmail.com" target=3D"_blank">glme...@gmail.com</a> w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">
Hi,<br><br>I propose to add a new future to C++14: "the named tuple&qu=
ot;.<br>In some case could be very usefull to have something like that:<br>=
<br>std::tuple< <b>foo@int</b>, <b>bar@std::string </b>> t =3D std::m=
ake_tuple(5, "hello!");<br>
<br>than we can access to our tuple in this way:<br><br>auto n =3D std::get=
<foo>(t);<br>auto m =3D std::get<bar>(t);<br><br><span lang=3D"=
en"><span>What is your</span> <span>idea about this?</span></span><br>Thank=
s <br>
</blockquote></div></div></blockquote></div><br><br clear=3D"all"><br>-- <b=
r>GL<br><a href=3D"http://www.meocci.it" target=3D"_blank">http://www.meocc=
i.it</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--089e0160c9f4dd472a04dcfcaa91--
.
Author: snk_kid <korcan.hussein@googlemail.com>
Date: Sat, 18 May 2013 08:58:16 -0700 (PDT)
Raw View
------=_Part_139_24182841.1368892696451
Content-Type: text/plain; charset=ISO-8859-1
I forgot to mention that tuple patterns can work with nested tuples as well:
auto x = ((1,1),2);
auto ((_,y),_) = x;
auto (_, z) = x;
auto k = (x,"foo");
auto (((_,l),_), _) = k;
template < typename X, typename Y, typename Z >
auto swizzle(const (X,(Y,Z))& (x,(y,z))) -> ((Z,Y),X)
{
return ((z,y),x);
}
auto (_, x) = swizzle((1,(2,3));
On Saturday, May 18, 2013 12:31:41 PM UTC+1, snk_kid wrote:
>
> The best and most general solution which not only fixes/improves the
> situation but improves many other features is to make tuple types built-in
> types and add support for pattern matching (and I don't mean just for
> tuples but in general). There is should be no reason that built-in tuples
> and pattern matching can be as efficient if not more so than any library
> solution and could easily be just syntactic sugar just as much as lambda
> expressions in C++11 currently are. Some imaginary examples of C++ with
> built-in tuple types and pattern matching:
>
> // a simple type-inferred tuple binding:
> auto x = (0, 0.0f, "foo"); // the type of x is inferred to be the tuple
> type: (int, float, const char*)
>
> // the same as above but without local type inference:
> (int, float, const char*) x = (0, 0.0f, "foo");
>
> // some tuple pattern binding expressions (with type inference) using 'x'
> from the above:
>
> auto (a, _, _) = x; // 'a' is bound too the first element of the tuple
> 'x', and a can be freely used, the other elements are ignored.
>
> auto (_, _, c) = x; // 'c' is bound too the last element of the tuple
> 'x', other elements ignored.
>
> auto (_, y, z) = x; // 'y' and 'z' are bound to the second and last
> element of 'x', others ignored.
>
> auto (f@(_, k, _)) = (1, foo_type(), bar_type()); // 'f' binds to the
> whole tuple, 'k' binds the second element.
>
> // tuples in functions and tupple patterns in function arguments:
>
> auto make_a_2_tuple(float x, int y) -> (float,int)
> {
> return (x,y);
> }
>
> template < typename FirstType, typename SecondType >
> auto first(const (FirstType,SecondType)& (x, _)) -> FirstType
>
> return x;
> }
>
>
> template < typename FirstType, typename SecondType >
> auto second(const (FirstType,SecondType)& (_, x)) -> SecondType
> {
> return x;
> }
>
> // using the above definitions:
>
> auto x = make_a_2_tuple(0.0f,0);
>
> auto (y,z) = make_a_2_tuple(0.0f,0);
>
> auto (_,k) = make_a_2_tuple(0.0f,0);
>
> auto j = (1,1);
> int x = second(j);
> int y = first(j);
>
> Not every language abstraction should be forced in to or even make sense
> as a library abstraction. Why is the community making this so hard? I see
> no reason why we couldn't have the above any more than we have say lambda
> expressions and be just as efficient if not more so than a library solution
> without all the ugly hacks and adding more peculiar language changes to
> just make the library abstraction work.
>
> Can we please at least try to pursue the possibility.
>
> On Friday, March 29, 2013 1:03:24 PM UTC, glme...@gmail.com wrote:
>>
>> Hi,
>>
>> I propose to add a new future to C++14: "the named tuple".
>> In some case could be very usefull to have something like that:
>>
>> std::tuple< *foo@int*, *bar@std::string *> t = std::make_tuple(5,
>> "hello!");
>>
>> than we can access to our tuple in this way:
>>
>> auto n = std::get<foo>(t);
>> auto m = std::get<bar>(t);
>>
>> What is your idea about this?
>> Thanks
>>
>
--
---
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/?hl=en.
------=_Part_139_24182841.1368892696451
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I forgot to mention that tuple patterns can work with nested tuples as well=
:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250=
, 250); border-color: rgb(187, 187, 187); border-style: solid; border-width=
: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">aut=
o</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</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: #=
066;" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #066;" class=3D"sty=
led-by-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">),</span><span style=3D"color: #066;" class=3D"styled-by-prettify">=
2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">((</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">_</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">y</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">),</span><span style=3D"color: #000;" class=3D"styled-by-prettify">_<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</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;" class=3D"styled-by-prettify"> z</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
k </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">"foo"</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></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(((</s=
pan><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;" class=3D"styled-by-prettify">l</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">),</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">_</span><span style=3D"color: #660;" class=3D"st=
yled-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;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> k</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">template</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;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> X</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> Y</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: #008;" =
class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> Z </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">></span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> swizzle</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</sp=
an><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;" class=3D"styled-by-prettify">X</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">Y</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">Z</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
)&</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">,(</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">y</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">z</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)))</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;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">((</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">Z</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">Y</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">),</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">X</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">((</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">z</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">y</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">),</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <b=
r></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #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">_</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> swizzle</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">((</span><span style=3D"colo=
r: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">,(</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">2</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">3</span><span style=3D"color: #660;" class=3D"styled-by-prettify">));=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
></div></code></div><br>On Saturday, May 18, 2013 12:31:41 PM UTC+1, snk_ki=
d wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The best and most gene=
ral solution which not only fixes/improves the situation but improves many =
other features is to make tuple types built-in types and add support for pa=
ttern matching (and I don't mean just for tuples but in general). There is =
should be no reason that built-in tuples and pattern matching can be as eff=
icient if not more so than any library solution and could easily be just sy=
ntactic sugar just as much as lambda expressions in C++11 currently are. So=
me imaginary examples of C++ with built-in tuple types and pattern matching=
:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(1=
87,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code=
><div><span style=3D"color:#800">// a simple type-inferred tuple binding:</=
span><span style=3D"color:#000"><br></span><span style=3D"color:#008">auto<=
/span><span style=3D"color:#000"> x </span><span style=3D"color:#660">=3D</=
span><span style=3D"color:#000"> </span><span style=3D"color:#660">(</span>=
<span style=3D"color:#066">0</span><span style=3D"color:#660">,</span><span=
style=3D"color:#000"> </span><span style=3D"color:#066">0.0f</span><span s=
tyle=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=
=3D"color:#080">"foo"</span><span style=3D"color:#660">);</span><span style=
=3D"color:#000"> </span><span style=3D"color:#800">// the type of x is infe=
rred to be the tuple type: (int, float, const char*)</span><span style=3D"c=
olor:#000"><br><br></span><span style=3D"color:#800">// the same as above b=
ut without local type inference:</span><span style=3D"color:#000"><br></spa=
n><span style=3D"color:#660">(</span><span style=3D"color:#008">int</span><=
span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span =
style=3D"color:#008">float</span><span style=3D"color:#660">,</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#008">const</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">char</span><span styl=
e=3D"color:#660">*)</span><span style=3D"color:#000"> x </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">(</span><span style=3D"color:#066">0</span><span style=3D"colo=
r:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#06=
6">0.0f</span><span style=3D"color:#660">,</span><span style=3D"color:#000"=
> </span><span style=3D"color:#080">"foo"</span><span style=3D"color:#660">=
);</span><span style=3D"color:#000"><br><br></span><span style=3D"color:#80=
0">// some tuple pattern binding expressions (with type inference) using 'x=
' from the above:</span><span style=3D"color:#000"><br><br></span><span sty=
le=3D"color:#008">auto</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">(</span><span style=3D"color:#000">a</span><span style=3D"c=
olor:#660">,</span><span style=3D"color:#000"> _</span><span style=3D"color=
:#660">,</span><span style=3D"color:#000"> _</span><span style=3D"color:#66=
0">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> x</span><span style=3D"color:#660">;<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#800">// 'a' =
is bound too the first element of the tuple 'x', and a can be freely used, =
the other elements are ignored.</span><span style=3D"color:#000"><br><br></=
span><span style=3D"color:#008">auto</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#660">(</span><span style=3D"color:#000">_</span><s=
pan style=3D"color:#660">,</span><span style=3D"color:#000"> _</span><span =
style=3D"color:#660">,</span><span style=3D"color:#000"> c</span><span styl=
e=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">=3D</span><span style=3D"color:#000"> x</span><span style=3D"co=
lor:#660">;</span><span style=3D"color:#000"> </span><span style=3D"color:#=
800">// 'c' is bound too the last element of the tuple 'x', other elements =
ignored.</span><span style=3D"color:#000"><br><br></span><span style=3D"col=
or:#008">auto</span><span style=3D"color:#000"> </span><span style=3D"color=
:#660">(</span><span style=3D"color:#000">_</span><span style=3D"color:#660=
">,</span><span style=3D"color:#000"> y</span><span style=3D"color:#660">,<=
/span><span style=3D"color:#000"> z</span><span style=3D"color:#660">)</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><=
span style=3D"color:#000"> x</span><span style=3D"color:#660">;</span><span=
style=3D"color:#000"> </span><span style=3D"color:#800">// 'y' and 'z' are=
bound to the second and last element of 'x', others ignored.</span><span s=
tyle=3D"color:#000"><br><br></span><span style=3D"color:#008">auto</span><s=
pan style=3D"color:#000"> (f@</span><span style=3D"color:#660">(</span><spa=
n style=3D"color:#000">_</span><span style=3D"color:#660">,</span><span sty=
le=3D"color:#000"> k</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"color:#660">=3D</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">(</span><span style=3D"color:#=
066">1</span><span style=3D"color:#660">,</span><span style=3D"color:#000">=
foo_type</span><span style=3D"color:#660">(),</span><span style=3D"color:#=
000"> bar_type</span><span style=3D"color:#660">());</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#800">// 'f' binds to the whole tup=
le, 'k' binds the second element.</span><span style=3D"color:#000"><br><br>=
</span><span style=3D"color:#800">// tuples in functions and tupple pattern=
s in function arguments:</span><span style=3D"color:#000"><br><br>auto make=
_a_2_tuple(float x, int y) -> (float,int)<br>{<br> ret=
urn (x,y);<br>}<br><br></span>template < typename FirstType, typename Se=
condType ><code><span style=3D"color:#000"><br></span></code>auto<span s=
tyle=3D"color:#000"> first</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#000">const </span><span style=3D"color:#000"><code><code><sp=
an style=3D"color:#000">(</span></code></code></span><span style=3D"color:#=
000"><code>FirstType,SecondType)</code>& (x, _)) -> </span><code>Fir=
stType<br></code><span style=3D"color:#000"><br> return x;<br>}=
<br><br></span><br><span style=3D"color:#000"><code>template < typename =
FirstType, typename SecondType ><code><span style=3D"color:#000"><br></s=
pan></code>auto<span style=3D"color:#000"> second</span><span style=3D"colo=
r:#660">(</span><span style=3D"color:#000">const </span><span style=3D"colo=
r:#000"><code><code><span style=3D"color:#000">(</span></code></code></span=
><span style=3D"color:#000"><code>FirstType,SecondType)</code>& (_, x))=
-> </span><span style=3D"color:#000"><code>SecondType<br></code>{<br>&n=
bsp; return x;<br>}</span></code><br><br>// using the above definitio=
ns:<br><br>auto x =3D </span><span style=3D"color:#000"><code><span style=
=3D"color:#000">make_a_2_tuple</span></code>(0.0f,0);<br><br>auto (y,z) =3D=
</span><span style=3D"color:#000"><code><span style=3D"color:#000"></span>=
<span style=3D"color:#000"><code><span style=3D"color:#000">make_a_2_tuple<=
/span></code>(0.0f,0);<br></span></code></span><br>auto (_,k) =3D <code><sp=
an style=3D"color:#000"><code><span style=3D"color:#000"><code><span style=
=3D"color:#000">make_a_2_tuple</span></code>(0.0f,0);<br><br>auto j =3D (1,=
1);<br>int x =3D second(</span></code></span></code><code><span style=3D"co=
lor:#000"><code><span style=3D"color:#000"><code><code><span style=3D"color=
:#000"><code><span style=3D"color:#000">j</span></code></span></code></code=
>);<br>int y =3D first(</span></code></span></code><code><span style=3D"col=
or:#000"><code><span style=3D"color:#000"><code><code><span style=3D"color:=
#000"><code><span style=3D"color:#000">j</span></code></span></code></code>=
);<br></span></code></span></code></div></code></div><br>Not every language=
abstraction should be forced in to or even make sense as a library abstrac=
tion. Why is the community making this so hard? I see no reason why we coul=
dn't have the above any more than we have say lambda expressions and be jus=
t as efficient if not more so than a library solution without all the ugly =
hacks and adding more peculiar language changes to just make the library ab=
straction work.<br><br>Can we please at least try to pursue the possibility=
..<br><br>On Friday, March 29, 2013 1:03:24 PM UTC, <a>glme...@gmail.com</a>=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex">Hi,<br><br>I propose to add =
a new future to C++14: "the named tuple".<br>In some case could be very use=
full to have something like that:<br><br>std::tuple< <b>foo@int</b>, <b>=
bar@std::string </b>> t =3D std::make_tuple(5, "hello!");<br><br>than we=
can access to our tuple in this way:<br><br>auto n =3D std::get<foo>=
(t);<br>auto m =3D std::get<bar>(t);<br><br><span lang=3D"en"><span>W=
hat is your</span> <span>idea about this?</span></span><br>Thanks <br></blo=
ckquote></blockquote>
<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_139_24182841.1368892696451--
.
Author: Jonathan Wakely <cxx@kayari.org>
Date: Sun, 19 May 2013 03:36:14 -0700 (PDT)
Raw View
------=_Part_1849_1385651.1368959774076
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, May 18, 2013 12:31:41 PM UTC+1, snk_kid wrote:
>
> Not every language abstraction should be forced in to or even make sense
> as a library abstraction. Why is the community making this so hard? I see
> no reason why we couldn't have the above any more than we have say lambda
> expressions and be just as efficient if not more so than a library solution
> without all the ugly hacks and adding more peculiar language changes to
> just make the library abstraction work.
>
> Can we please at least try to pursue the possibility.
Sure ... the way to get such things done is to write a proposal.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_1849_1385651.1368959774076
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Saturday, May 18, 2013 12:31:41 PM UTC+1, snk_kid wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">Not every language abstraction should =
be forced in to or even make sense as a library abstraction. Why is the com=
munity making this so hard? I see no reason why we couldn't have the above =
any more than we have say lambda expressions and be just as efficient if no=
t more so than a library solution without all the ugly hacks and adding mor=
e peculiar language changes to just make the library abstraction work.<br><=
br>Can we please at least try to pursue the possibility.</blockquote><div><=
br></div><div> Sure ... the way to get such things done is to write a =
proposal. </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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1849_1385651.1368959774076--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 19 May 2013 04:31:51 -0700 (PDT)
Raw View
------=_Part_2140_19782985.1368963111618
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, May 18, 2013 4:31:41 AM UTC-7, snk_kid wrote:
>
> Not every language abstraction should be forced in to or even make sense
> as a library abstraction. Why is the community making this so hard? I see
> no reason why we couldn't have the above any more than we have say lambda
> expressions and be just as efficient if not more so than a library solution
> without all the ugly hacks and adding more peculiar language changes to
> just make the library abstraction work.
>
> Can we please at least try to pursue the possibility.
I certainly hope not.
I have very rarely been in any situation in code where I needed an
aggregate of arbitrary types that was not an *object* of some kind. That
is, where the aggregate of types was not repeated frequently enough
throughout the code that it needed a name (to identify its meaning). And
once that particular aggregation needs a name, it's really just a *struct*.
It probably should also have members in it, for specific operations on that
type.
Usually, this comes up in the places where we see std::pair used: some kind
of basic utility object who's contents are defined by user-specified
template parameters. std::tuple is really just an expanded std::pair for
these situations. But it is handy for compile-time generation of types.
In any case, if you have a function that returns multiple values, odds are
good that you are going to have multiple functions that all return those
same values with their same meaning. Therefore, you aren't returning
multiple values; you're returning *a single value*, which just so happens
to contain multiple components.
However, if you insist on having some language support for this, you can't
use parentheses. That's not going to work; it would break *lots* of code.
The standard already clearly defines what `(0, 0.0f, "foo")` means already.
However, you *could* do it with curly braces, since a curly-brace-bound
list of *types* is not defined in C++ (though Bjarne wants to define it as
a parameter/definition/thing for concepts, so you'll have to fight with him
for that). And the reason to use curly braces instead of parentheses (even
though a parenthesized list of types is equally undefined) is this:
{int, float, std::string} a = {0, 0.0f, "foo"};
Here, you're able to combine braced-type-lists (what I call the thing on
the left) with braced-init-lists (what we know is the thing on the right).
And thus, you have syntax which makes sense.
You can't backtrack uniform initialization to make `{0, 0.0f, "foo"}`
deduce to a tuple by itself. And I call dibs on addendum to uniform
initialization syntax (such as `{: ...}`), so don't do that either. But
it's not like we don't have `make_tuple` already, so if you don't want to
type the names, just use that:
auto a = make_tuple(0, 0.0f, "foo");
You won't get `std::string` out of that. But then again, you wouldn't get
it from making `{:0, 0.0f, "foo"}` deduce to a tuple either. I'd prefer
that it's spelled out directly that you're creating a tuple.
We should not *encourage* people to use tuples. They're a useful tool, but
they shouldn't be the default or go-to object for people's use. Actual *
objects*, with real definitions, should be the default object of choice.
Use `tuple` when you don't have a choice, when you have to compile-time
generate a sequence of values.
The days of tuples are numbered anyway. Once we start getting serious
reflection features (which, at a minimum, includes compile-time iteration
over types, and at a maximum includes compile-time *generation* of types
from typelists), we won't need them. I would much rather we wait until we
get some reflection features, then use *those* in language-specific
functionality.
--
---
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/?hl=en.
------=_Part_2140_19782985.1368963111618
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, May 18, 2013 4:31:41 AM UTC-7, snk_kid wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">Not every language abstraction should be forced=
in to or even make sense as a library abstraction. Why is the community ma=
king this so hard? I see no reason why we couldn't have the above any more =
than we have say lambda expressions and be just as efficient if not more so=
than a library solution without all the ugly hacks and adding more peculia=
r language changes to just make the library abstraction work.<br><br>Can we=
please at least try to pursue the possibility.</blockquote><div><br>I cert=
ainly hope not.<br><br>I have very rarely been in any situation in code whe=
re I needed an aggregate of arbitrary types that was not an <i>object</i> o=
f some kind. That is, where the aggregate of types was not repeated frequen=
tly enough throughout the code that it needed a name (to identify its meani=
ng). And once that particular aggregation needs a name, it's really just a =
<i>struct</i>. It probably should also have members in it, for specific ope=
rations on that type.<br><br>Usually, this comes up in the places where we =
see std::pair used: some kind of basic utility object who's contents are de=
fined by user-specified template parameters. std::tuple is really just an e=
xpanded std::pair for these situations. But it is handy for compile-time ge=
neration of types.<br><br>In any case, if you have a function that returns =
multiple values, odds are good that you are going to have multiple function=
s that all return those same values with their same meaning. Therefore, you=
aren't returning multiple values; you're returning <i>a single value</i>, =
which just so happens to contain multiple components.<br><br>However, if yo=
u insist on having some language support for this, you can't use parenthese=
s. That's not going to work; it would break <i>lots</i> of code. The standa=
rd already clearly defines what `(0, 0.0f, "foo")` means already.<br><br>Ho=
wever, you <i>could</i> do it with curly braces, since a curly-brace-bound =
list of <i>types</i> is not defined in C++ (though Bjarne wants to define i=
t as a parameter/definition/thing for concepts, so you'll have to fight wit=
h him for that). And the reason to use curly braces instead of parentheses =
(even though a parenthesized list of types is equally undefined) is this:<b=
r><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 2=
50); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1=
px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">int</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: #=
008;" class=3D"styled-by-prettify">float</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"color: #660;" class=3D"style=
d-by-prettify">::</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">string</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><sp=
an 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=
: #066;" class=3D"styled-by-prettify">0</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: #066;" class=3D"styled-by=
-prettify">0.0f</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #080;" class=3D"styled-by-prettify">"foo"</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></=
div><br>Here, you're able to combine braced-type-lists (what I call the thi=
ng on the left) with braced-init-lists (what we know is the thing on the ri=
ght). And thus, you have syntax which makes sense.<br><br>You can't backtra=
ck uniform initialization to make `{0, 0.0f, "foo"}` deduce to a tuple by i=
tself. And I call dibs on addendum to uniform initialization syntax (such a=
s `{: ...}`), so don't do that either. But it's not like we don't have `mak=
e_tuple` already, so if you don't want to type the names, just use that:<br=
><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 25=
0); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1p=
x; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpre=
ttyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> a </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> make_tuple</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #066;" class=3D"styled-by-prettify">0</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: #066;" class=3D"style=
d-by-prettify">0.0f</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"foo"</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span></div=
></code></div><br>You won't get `std::string` out of that. But then again, =
you wouldn't get it from making `{:0, 0.0f, "foo"}` deduce to a tuple eithe=
r. I'd prefer that it's spelled out directly that you're creating a tuple.<=
br><br>We should not <i>encourage</i> people to use tuples. They're a usefu=
l tool, but they shouldn't be the default or go-to object for people's use.=
Actual <i>objects</i>, with real definitions, should be the default object=
of choice. Use `tuple` when you don't have a choice, when you have to comp=
ile-time generate a sequence of values.<br><br>The days of tuples are numbe=
red anyway. Once we start getting serious reflection features (which, at a =
minimum, includes compile-time iteration over types, and at a maximum inclu=
des compile-time <i>generation</i> of types from typelists), we won't need =
them. I would much rather we wait until we get some reflection features, th=
en use <i>those</i> in language-specific functionality.<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2140_19782985.1368963111618--
.
Author: Gabriel Dos Reis <gdr@axiomatics.org>
Date: Sat, 18 May 2013 11:47:41 -0500
Raw View
snk_kid <korcan.hussein@googlemail.com> writes:
| I forgot to mention that tuple patterns can work with nested tuples as well:
|
| auto x = ((1,1),2);
|
| auto ((_,y),_) = x;
|
| auto (_, z) = x;
|
| auto k = (x,"foo");
in the current language, k has type 'const char*'. Are you
suggesting to break that?
It is not clear to me what the problem really is and why removing
syntactic incompatibilities between C++ and Haskell will solve it.
-- Gaby
|
| auto (((_,l),_), _) = k;
|
| template < typename X, typename Y, typename Z >
| auto swizzle(const (X,(Y,Z))& (x,(y,z))) -> ((Z,Y),X)
| {
| return ((z,y),x);
| }
|
| auto (_, x) = swizzle((1,(2,3));
|
| On Saturday, May 18, 2013 12:31:41 PM UTC+1, snk_kid wrote:
|
| The best and most general solution which not only fixes/improves the
| situation but improves many other features is to make tuple types built-in
| types and add support for pattern matching (and I don't mean just for
| tuples but in general). There is should be no reason that built-in tuples
| and pattern matching can be as efficient if not more so than any library
| solution and could easily be just syntactic sugar just as much as lambda
| expressions in C++11 currently are. Some imaginary examples of C++ with
| built-in tuple types and pattern matching:
|
| // a simple type-inferred tuple binding:
| auto x = (0, 0.0f, "foo"); // the type of x is inferred to be the tuple
| type: (int, float, const char*)
|
| // the same as above but without local type inference:
| (int, float, const char*) x = (0, 0.0f, "foo");
|
| // some tuple pattern binding expressions (with type inference) using 'x'
| from the above:
|
| auto (a, _, _) = x; // 'a' is bound too the first element of the tuple 'x',
| and a can be freely used, the other elements are ignored.
|
| auto (_, _, c) = x; // 'c' is bound too the last element of the tuple 'x',
| other elements ignored.
|
| auto (_, y, z) = x; // 'y' and 'z' are bound to the second and last element
| of 'x', others ignored.
|
| auto (f@(_, k, _)) = (1, foo_type(), bar_type()); // 'f' binds to the whole
| tuple, 'k' binds the second element.
|
| // tuples in functions and tupple patterns in function arguments:
|
| auto make_a_2_tuple(float x, int y) -> (float,int)
| {
| return (x,y);
| }
|
| template < typename FirstType, typename SecondType >
| auto first(const (FirstType,SecondType)& (x, _)) -> FirstType
|
| return x;
| }
|
|
| template < typename FirstType, typename SecondType >
| auto second(const (FirstType,SecondType)& (_, x)) -> SecondType
| {
| return x;
| }
|
| // using the above definitions:
|
| auto x = make_a_2_tuple(0.0f,0);
|
| auto (y,z) = make_a_2_tuple(0.0f,0);
|
| auto (_,k) = make_a_2_tuple(0.0f,0);
|
| auto j = (1,1);
| int x = second(j);
| int y = first(j);
|
| Not every language abstraction should be forced in to or even make sense as
| a library abstraction. Why is the community making this so hard? I see no
| reason why we couldn't have the above any more than we have say lambda
| expressions and be just as efficient if not more so than a library solution
| without all the ugly hacks and adding more peculiar language changes to
| just make the library abstraction work.
|
| Can we please at least try to pursue the possibility.
|
| On Friday, March 29, 2013 1:03:24 PM UTC, glme...@gmail.com wrote:
|
| Hi,
|
| I propose to add a new future to C++14: "the named tuple".
| In some case could be very usefull to have something like that:
|
| std::tuple< foo@int, bar@std::string > t = std::make_tuple(5, "hello!
| ");
|
| than we can access to our tuple in this way:
|
| auto n = std::get<foo>(t);
| auto m = std::get<bar>(t);
|
| What is your idea about this?
| Thanks
|
| --
|
| ---
| 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/?
| hl=en.
|
|
--
---
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/?hl=en.
.
Author: stackmachine@hotmail.com
Date: Wed, 22 May 2013 01:15:06 -0700 (PDT)
Raw View
------=_Part_254_31318603.1369210506101
Content-Type: text/plain; charset=ISO-8859-1
I like this idea particularily because it makes range based for over maps
finally readable:
for((k, v) : m)
...
The syntax using parenthesis will not work though.
--
---
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/?hl=en.
------=_Part_254_31318603.1369210506101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I like this idea particularily because it makes range based for over maps f=
inally readable:<br><div class=3D"prettyprint" style=3D"background-color: r=
gb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; b=
order-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div =
class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">for</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>((</span><span style=3D"color: #000;" class=3D"styled-by-prettify">k</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> v</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> m</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span></div></code></div>The syntax using parenthesis will not work tho=
ugh.<br>
<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_254_31318603.1369210506101--
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Wed, 22 May 2013 16:44:36 -0700 (PDT)
Raw View
------=_Part_119_15284821.1369266276386
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
2013. m=E1jus 22., szerda 10:15:06 UTC+2 id=F5pontban stackm...@hotmail.com=
a=20
k=F6vetkez=F5t =EDrta:
>
> I like this idea particularily because it makes range based for over maps=
=20
> finally readable:
> for((k, v) : m)
> ...
> The syntax using parenthesis will not work though.
>
What's not readable in
for(auto& kv : m)
?=20
--=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/?hl=3Den.
------=_Part_119_15284821.1369266276386
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>2013. m=E1jus 22., szerda 10:15:06 UTC+2 id=F5pontban stackm...@hot=
mail.com a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">I like this idea particularily because it makes range based for over map=
s finally readable:<br><div style=3D"background-color:rgb(250,250,250);bord=
er-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:bre=
ak-word"><code><div><span style=3D"color:#008">for</span><span style=3D"col=
or:#660">((</span><span style=3D"color:#000">k</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">:</s=
pan><span style=3D"color:#000"> m</span><span style=3D"color:#660">)</span>=
<span style=3D"color:#000"><br> </span><span style=3D"color:#6=
60">...</span><span style=3D"color:#000"><br></span></div></code></div>The =
syntax using parenthesis will not work though.<br></blockquote><div><br>Wha=
t's not readable in<br><div class=3D"prettyprint" style=3D"background-color=
: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid=
; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">for</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> kv </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> m</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span></div></code></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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_119_15284821.1369266276386--
.
Author: Jonathan Wakely <cxx@kayari.org>
Date: Thu, 23 May 2013 02:58:18 -0700 (PDT)
Raw View
------=_Part_163_29392745.1369303098082
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
On Thursday, May 23, 2013 12:44:36 AM UTC+1, R=F3bert D=E1vid wrote:
>
>
>
> 2013. m=E1jus 22., szerda 10:15:06 UTC+2 id=F5pontban stackm...@hotmail.c=
om a=20
> k=F6vetkez=F5t =EDrta:
>>
>> I like this idea particularily because it makes range based for over map=
s=20
>> finally readable:
>> for((k, v) : m)
>> ...
>> The syntax using parenthesis will not work though.
>>
>
> What's not readable in
> for(auto& kv : m)
> ?=20
>
You missed out the loop body where you have to refer to kv.first and=20
kv.second, not nice names like "key" and "value".
Or when traversing a range of tuples, std::get<0>(kv) and std::get<1>(kv),=
=20
which is even worse.
--=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/?hl=3Den.
------=_Part_163_29392745.1369303098082
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>On Thursday, May 23, 2013 12:44:36 AM UTC+1, R=F3bert D=E1vid wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><br><br>2013. m=E1jus 22., sz=
erda 10:15:06 UTC+2 id=F5pontban <a>stackm...@hotmail.com</a> a k=F6vetkez=
=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I like this idea partic=
ularily because it makes range based for over maps finally readable:<br><di=
v style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);=
border-style:solid;border-width:1px;word-wrap:break-word"><code><div><span =
style=3D"color:#008">for</span><span style=3D"color:#660">((</span><span st=
yle=3D"color:#000">k</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"> m</span><span style=3D"color:#660">)</span><span style=3D"color:#00=
0"><br> </span><span style=3D"color:#660">...</span><span styl=
e=3D"color:#000"><br></span></div></code></div>The syntax using parenthesis=
will not work though.<br></blockquote><div><br>What's not readable in<br><=
div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187=
);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><spa=
n style=3D"color:#008">for</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#008">auto</span><span style=3D"color:#660">&</span><span=
style=3D"color:#000"> kv </span><span style=3D"color:#660">:</span><span s=
tyle=3D"color:#000"> m</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"><br></span></div></code></div>? <br></div></blockquote><div=
><br>You missed out the loop body where you have to refer to kv.first and k=
v.second, not nice names like "key" and "value".<br><br>Or when traversing =
a range of tuples, std::get<0>(kv) and std::get<1>(kv), which i=
s even worse.<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_163_29392745.1369303098082--
.
Author: James Dennett <jdennett@google.com>
Date: Thu, 23 May 2013 05:37:52 -0700
Raw View
On Thu, May 23, 2013 at 2:58 AM, Jonathan Wakely <cxx@kayari.org> wrote:
>
>
> On Thursday, May 23, 2013 12:44:36 AM UTC+1, R=F3bert D=E1vid wrote:
>>
>>
>>
>> 2013. m=E1jus 22., szerda 10:15:06 UTC+2 id=F5pontban stackm...@hotmail.=
com a
>> k=F6vetkez=F5t =EDrta:
>>>
>>> I like this idea particularily because it makes range based for over ma=
ps
>>> finally readable:
>>> for((k, v) : m)
>>> ...
>>> The syntax using parenthesis will not work though.
>>
>>
>> What's not readable in
>> for(auto& kv : m)
>> ?
>
>
> You missed out the loop body where you have to refer to kv.first and
> kv.second, not nice names like "key" and "value".
>
> Or when traversing a range of tuples, std::get<0>(kv) and std::get<1>(kv)=
,
> which is even worse.
In many cases C++14 allows std::get<Type>(kv), and it's pretty common
for a map to have a key type that's distinct from the type it maps to.
It's still not perfect, but if I'm iterating over a map<int, string>
then std::get<int>(kv) and std::get<string>(kv) are pretty readable,
IMO.
-- James
--=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/?hl=3Den.
.
Author: Jonathan Wakely <cxx@kayari.org>
Date: Thu, 23 May 2013 05:53:23 -0700 (PDT)
Raw View
------=_Part_386_3217057.1369313603264
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, May 23, 2013 1:37:52 PM UTC+1, James Dennett wrote:
>
>
> In many cases C++14 allows std::get<Type>(kv), and it's pretty common
> for a map to have a key type that's distinct from the type it maps to.
> It's still not perfect, but if I'm iterating over a map<int, string>
> then std::get<int>(kv) and std::get<string>(kv) are pretty readable,
> IMO.
>
It's not terrible, but it's not great either.
The first one should be std::get<const int>(kv), shouldn't 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_386_3217057.1369313603264
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thursday, May 23, 2013 1:37:52 PM UTC+1, James Dennett wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><br>In many cases C++14 allows std::get&l=
t;Type>(kv), and it's pretty common
<br>for a map to have a key type that's distinct from the type it maps to.
<br> It's still not perfect, but if I'm iterating over a map<int, s=
tring>
<br>then std::get<int>(kv) and std::get<string>(kv) are pretty =
readable,
<br>IMO.
<br></blockquote><div><br>It's not terrible, but it's not great either.<br>=
<br>The first one should be std::get<const int>(kv), shouldn't it?</d=
iv><br><br>
<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_386_3217057.1369313603264--
.
Author: James Dennett <jdennett@google.com>
Date: Thu, 23 May 2013 13:48:39 -0700
Raw View
On Thu, May 23, 2013 at 5:53 AM, Jonathan Wakely <cxx@kayari.org> wrote:
> On Thursday, May 23, 2013 1:37:52 PM UTC+1, James Dennett wrote:
>>
>>
>> In many cases C++14 allows std::get<Type>(kv), and it's pretty common
>> for a map to have a key type that's distinct from the type it maps to.
>> It's still not perfect, but if I'm iterating over a map<int, string>
>> then std::get<int>(kv) and std::get<string>(kv) are pretty readable,
>> IMO.
>
>
> It's not terrible, but it's not great either.
>
> The first one should be std::get<const int>(kv), shouldn't it?
Yes, it should.
Not the first time I've made that mistake, and probably not the last.
At least it'll be caught at compile time (or at e-mail time).
-- James
--
---
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/?hl=en.
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Fri, 24 May 2013 03:34:52 -0700 (PDT)
Raw View
------=_Part_278_9744354.1369391692994
Content-Type: text/plain; charset=ISO-8859-1
> You missed out the loop body where you have to refer to kv.first and
> kv.second, not nice names like "key" and "value".
>
> Well, I'd think it is obvious what a key_value_pair.first is.. (I
generally dislike one-letter variable names anyway) Or if you use it in
gazillion places inside the loop, you can add
auto& key = key_value_pair.first;
auto& value = key_value_pair.second;
At the beginning of the loop.
The std::get<const int>(kv) won't work though if you have an int-const int
map..
I still think that it would be nice to have a "typedef" for variables, so I
could access the member values of a pair/tuple/struct with unmodifiable
code with a different name, something the original poster in this thread
asks.
For first, I thought about something like
using kv.key = kv.first;
using kv.value = kv.second;
At first it's looking like breaking encapsulation (booh!), but that's not
really that horrible: you should already have access to foo.x, you are just
making an alias foo.y, just like as a typedef (or if you like, variabledef,
memberdef).
Alternatively, Concepts would (have) come close to rescue with the concepts
map, if they support member variables, not just typenames and functions:
concept KeyValue<C> {
typename key_type;
typename value_type;
key_type key;
value_type value;
}
template<typename T1, typename T2>
concept_map KeyValue<std::pair<T1, T2>> {
typedef T1 key_type;
typedef T2 value_type;
using key = C.first;
using value = C.second;
}
void f(const std::map<int, std::string>& m) {
for(HasKeyValue& kv : m)
std::cout << "key: " << kv.key << " value: " << kv.value << std::endl;
}
Regards, Robert
--
---
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/?hl=en.
------=_Part_278_9744354.1369391692994
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div>You missed out the lo=
op body where you have to refer to kv.first and kv.second, not nice names l=
ike "key" and "value".<br><br></div></blockquote><div>Well, I'd think it is=
obvious what a key_value_pair.first is.. (I generally dislike one-letter v=
ariable names anyway) Or if you use it in gazillion places inside the loop,=
you can add<br><div class=3D"prettyprint" style=3D"background-color: rgb(2=
50, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; borde=
r-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">auto</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&a=
mp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> key &n=
bsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> key_value_p=
air</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">first</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> value </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><code class=3D"prettyprint"><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">key_value_pair</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"></span></code><span style=3D"color: #000;=
" class=3D"styled-by-prettify">second</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">;</span></div></code></div>At the beginning of t=
he loop.<br><br>The std::get<const int>(kv) won't work though if you =
have an int-const int map..<br><br>I still think that it would be nice to h=
ave a "typedef" for variables, so I could access the member values of a pai=
r/tuple/struct with unmodifiable code with a different name, something the =
original poster in this thread asks.<br><br>For first, I thought about some=
thing like<br><div class=3D"prettyprint" style=3D"background-color: rgb(250=
, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-=
width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><code class=3D"prettyprint"><span style=3D"color: #000;=
" class=3D"styled-by-prettify"></span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">using</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span></code><span style=3D"color: #000;" class=3D"styled=
-by-prettify">kv</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">key=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">kv</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">.first</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;<br>using kv.value =3D kv.second;<br=
></span></div></code></div>At first it's looking like breaking encapsulatio=
n (booh!), but that's not really that horrible: you should already have acc=
ess to foo.x, you are just making an alias foo.y, just like as a typedef (o=
r if you like, variabledef, memberdef).<br><br>Alternatively, Concepts woul=
d (have) come close to rescue with the concepts map, if they support member=
variables, not just typenames and functions:<br><div class=3D"prettyprint"=
style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187,=
187); border-style: solid; border-width: 1px; word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
#008;" class=3D"styled-by-prettify">concept</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> KeyValue</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">C</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp;typename key_type;<br> typename value_type;<br> key</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">_type key;<br> =
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><code clas=
s=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>value_</span><span style=3D"color: #000;" class=3D"styled-by-prettify">typ=
e</span></code> value;<br></span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">template</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y"><typename T1, typename T2</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;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">c=
oncept_map</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><code cla=
ss=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify=
">KeyValue</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
<</span></code>std::pair</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">T1, T2</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> typ=
edef T1 key_type;<br></span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><code class=3D"prettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> typedef T2 value_type;</span></code><br> =
;using key =3D C.first;<br> using value =3D C.second;</span><br>}<br><=
br>void f(const std::map<int, std::string>& m) {<br> for(Has=
KeyValue& kv : m)<br> std::cout << "key: " << kv.key =
<< " value: " << kv.value << std::endl;<br>}<br></div></c=
ode></div><br><div dir=3D"ltr" style=3D"font-size: 13.3333px; font-family: =
monospace; left: 96px; top: 930.667px; transform: scale(1.00017, 1); transf=
orm-origin: 0% 0% 0px;" data-font-name=3D"g_font_p0_13" data-canvas-width=
=3D"352.0586834541323">Regards, Robert<br></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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_278_9744354.1369391692994--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Tue, 28 May 2013 06:32:26 -0700 (PDT)
Raw View
------=_Part_348_1802228.1369747946160
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, May 24, 2013 11:34:52 AM UTC+1, R=F3bert D=E1vid wrote:
>
>
> You missed out the loop body where you have to refer to kv.first and=20
>> kv.second, not nice names like "key" and "value".
>>
>> Well, I'd think it is obvious what a key_value_pair.first is.. (I=20
> generally dislike one-letter variable names anyway) Or if you use it in=
=20
> gazillion places inside the loop, you can add
> auto& key =3D key_value_pair.first;
> auto& value =3D key_value_pair.second;
> At the beginning of the loop.
>
N3617 would allow this:
auto key =3D []first;
auto value =3D []second;
for(HasKeyValue& kv : m)
std::cout << "key: " << key(kv) << " value: " << value(kv) << std::endl;
=20
As proposed, I do not think N3617 would allow something like this:
auto key =3D []get<0>;
auto value =3D []get<1>;
but I guess it could be extended.
-- gpd
--=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/?hl=3Den.
------=_Part_348_1802228.1369747946160
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, May 24, 2013 11:34:52 AM UTC+1, R=F3bert D=E1vid wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;"><br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div>You missed out the loop body where you have to refer to kv.first =
and kv.second, not nice names like "key" and "value".<br><br></div></blockq=
uote><div>Well, I'd think it is obvious what a key_value_pair.first is.. (I=
generally dislike one-letter variable names anyway) Or if you use it in ga=
zillion places inside the loop, you can add<br><div style=3D"background-col=
or:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border=
-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#008">auto=
</span><span style=3D"color:#660">&</span><span style=3D"color:#000"> k=
ey </span><span style=3D"color:#660">=3D</span><span style=3D"color:=
#000"> key_value_pair</span><span style=3D"color:#660">.</span><span style=
=3D"color:#000">first</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#008">auto</span><span styl=
e=3D"color:#660">&</span><span style=3D"color:#000"> value </span><span=
style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><code><s=
pan style=3D"color:#000">key_value_pair</span><span style=3D"color:#660">.<=
/span><span style=3D"color:#000"></span></code><span style=3D"color:#000">s=
econd</span><span style=3D"color:#660">;</span></div></code></div>At the be=
ginning of the loop.<br></div></blockquote><div><br>N3617 would allow this:=
<br><br>auto key =3D []first;<br>auto value =3D []second;<br><br><code>for(=
HasKeyValue& kv : m)<br> std::cout << "key: " << key(=
kv) << " value: " << value(kv) << std::endl;</code><br>&n=
bsp; <br>As proposed, I do not think N3617 would allow something like this:=
<br><br> auto key =3D []get<0>;<br> auto valu=
e =3D []get<1>;<br><br>but I guess it could be extended.</div><br>-- =
gpd<br>
<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_348_1802228.1369747946160--
.
Author: Xeo <hivemaster@hotmail.de>
Date: Tue, 28 May 2013 10:42:02 -0700 (PDT)
Raw View
------=_Part_303_4637227.1369762922205
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, May 28, 2013 3:32:26 PM UTC+2, Giovanni Piero Deretta wrote:
> As proposed, I do not think N3617 would allow something like this:
>
> auto key = []get<0>;
> auto value = []get<1>;
>
> but I guess it could be extended.
>
>
Actually, it would (if you add `std::`), since `std::get<N>` is just
another *id-expression*. (FWIW, the paper is currently undergoing a slight
rehault that would make `[]first` invalue - `[].first` would be the new
proposed and *only* valid syntax, except when in the lexical context of a
class, i.e., a member function).
--
---
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/?hl=en.
------=_Part_303_4637227.1369762922205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, May 28, 2013 3:32:26 PM UTC+2, Giovanni Piero Deretta wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div>As proposed, I do not th=
ink N3617 would allow something like this:<br><br> auto key =3D=
[]get<0>;<br> auto value =3D []get<1>;<br><br>but =
I guess it could be extended.</div><br></blockquote><br>Actually, it would =
(if you add `std::`), since `std::get<N>` is just another *id-express=
ion*. (FWIW, the paper is currently undergoing a slight rehault that would =
make `[]first` invalue - `[].first` would be the new proposed and *only* va=
lid syntax, except when in the lexical context of a class, i.e., a member f=
unction).<br>
<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_303_4637227.1369762922205--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Wed, 29 May 2013 09:58:39 +0100
Raw View
On Tue, May 28, 2013 at 6:42 PM, Xeo <hivemaster@hotmail.de> wrote:
> On Tuesday, May 28, 2013 3:32:26 PM UTC+2, Giovanni Piero Deretta wrote:
>>
>> As proposed, I do not think N3617 would allow something like this:
>>
>> auto key = []get<0>;
>> auto value = []get<1>;
>>
>> but I guess it could be extended.
>>
>
> Actually, it would (if you add `std::`), since `std::get<N>` is just another
> *id-expression*.
That's great!!
> (FWIW, the paper is currently undergoing a slight rehault
> that would make `[]first` invalue - `[].first` would be the new proposed and
> *only* valid syntax, except when in the lexical context of a class, i.e., a
> member function).
what is the reason for the change? reserving the []<name> syntax for a
future named lambda proposal?
-- gpd
--
---
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/?hl=en.
.
Author: Xeo <hivemaster@hotmail.de>
Date: Wed, 29 May 2013 02:28:01 -0700 (PDT)
Raw View
------=_Part_4595_28163508.1369819681726
Content-Type: text/plain; charset=ISO-8859-1
>
> FWIW, the paper is currently undergoing a slight rehault that would make
> `[]first` invalue
Oh boy, so many typos in that sentence...
what is the reason for the change? reserving the []<name> syntax for a
> future named lambda proposal?
>
Ah, I meant to add that this is for member access. The rules are currently
as follows:
auto free = []foo; // always calls free function foo, unless in a member
context
auto mem = [].foo; // always INVOKE semantics for members
void X::mem_fun(){
auto mem = []foo; // only finds members, with implicit `this` capturing
}
The implicit `this`-capturing may sound particularly strange. The reason
for this is that I want to abide by a very simple rule wrt name-lookup
// the following two should be strictly equivalent in any context
foo(args...);
[]foo(args...);
I.e. a direct invocation of a lifting lambda should be the same as directly
invoking the id-expression.
--
---
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/?hl=en.
------=_Part_4595_28163508.1369819681726
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid=
rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">FWIW, the pa=
per is currently undergoing a slight rehault
that would make `[]first` invalue</blockquote> <br>Oh boy, so many typ=
os in that sentence...<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">what is the reason for the change? reserving the []<name> synta=
x for a
<br>future named lambda proposal?<br></blockquote><div><br>Ah, I meant to a=
dd that this is for member access. The rules are currently as follows:<br><=
br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250)=
; border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px;=
word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprett=
yprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> free </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">[]</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">foo</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">// always calls free function foo, unless in a member context</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> mem </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">[].</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">foo</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// alw=
ays INVOKE semantics for members</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> X</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">mem_=
fun</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(){</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> mem </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</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;" cl=
ass=3D"styled-by-prettify">foo</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: #800;" class=3D"styled-by-prettify=
">// only finds members, with implicit `this` capturing</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span></div></code></div><br>The impli=
cit `this`-capturing may sound particularly strange. The reason for this is=
that I want to abide by a very simple rule wrt name-lookup<br><br><div cla=
ss=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-co=
lor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap:=
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">// the following two=
should be strictly equivalent in any context</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>foo</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">args</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">...);</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">[]</span><span style=3D"color: #000;" class=3D"styled-by-prettify">f=
oo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">args</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">...);</span></div></cod=
e></div><br>I.e. a direct invocation of a lifting lambda should be the same=
as directly invoking the id-expression.<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_4595_28163508.1369819681726--
.
Author: thibaut.lutz@googlemail.com
Date: Thu, 10 Apr 2014 03:28:07 -0700 (PDT)
Raw View
------=_Part_92_23885566.1397125687918
Content-Type: text/plain; charset=UTF-8
Hi all,
This is an old thread, but it is worth a bump since I had exactly the same
idea, with a slightly different motivation.
To give you a concrete example of where this syntax might be really useful
is to decouple type information and data layout when using arrays of type
aggregate.
For high performance computing, a really common trick is switching between
array-of-structs and struct-of-arrays depending on your architecture.
Ideally, one would like to handle the aggregate exactly as you would for a
struct (ie by defining a collection of fields with a type and a name), but
without committing to a particular layout. This would allow to implement
abstraction layers where users give a loose description of their "objects",
but the layout can be adapted by a library. This would be really useful for
implementing databases for example.
Here is a simple example to illustrate what I would like to achieve:
// example of named template type definition
typedef Container <char R, char G, char B, char A> ImageType;
// instantiation: creates 800x600 elements, without knowing the memory
layout, could be
// struct {char R, G, B, A; } image[800*600]; or
// struct {char R, G, B, A; } image[800][600]; or
// struct {char R[800*600], G[800*600], B[800*600], A[800*600]; } image;
// etc...
ImageType image({800,600});
// Getting and setting element works regardless of the layout using the
field name
image.get<ImageType::A>({0,0}) = 0;
It is possible to achieve this using variadic template/tuples, but the
fields have to be addressed directly by index, which is simply unacceptable
for a large code base, since the readability and maintainability is awful
(think about accessing struct members by index instead of name!). Using
enums to alias the indexes is a very short term solution with more
inconvenients than benefits in then end. Using named parameters would not
only improve readability but also facilitate aggregation of tagged tuples,
ensure validity at compile time...
The solutions proposed here don't really solve this problem, either because
the scope of the name is just wrong (Boost fusion), or because they are
runtime solution (expensive, string comparisons...).
I compiled here<https://bitbucket.org/tlutz/named-variadic-template-proposal>possible implementations to achieve something close to that using the
current standard; and a very simple draft proposal about how we could make
this much simpler.
Any comment/input would be appreciated.
Thanks
TL
--
---
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_92_23885566.1397125687918
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi all,</div><div><br></div><div>This is an old threa=
d, but it is worth a bump since I had exactly the same idea, with a slightl=
y different motivation.</div><div><br></div><div>To give you a concrete exa=
mple of where this syntax might be really useful is to decouple type inform=
ation and data layout when using arrays of type aggregate. </div><div>=
<br></div><div>For high performance computing, a really common trick is swi=
tching between array-of-structs and struct-of-arrays depending on your arch=
itecture. Ideally, one would like to handle the aggregate exactly as you wo=
uld for a struct (ie by defining a collection of fields with a type and a n=
ame), but without committing to a particular layout. This would allow to im=
plement abstraction layers where users give a loose description of their "o=
bjects", but the layout can be adapted by a library. This would be really u=
seful for implementing databases for example.</div><div><br></div><div>Here=
is a simple example to illustrate what I would like to achieve:</div><div>=
<br></div><div><div class=3D"prettyprint" style=3D"background-color: rgb(25=
0, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"=
><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">// example of named template type=
definition</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">typed=
ef</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #606;" class=3D"styled-by-prettify">Container</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> R</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">char</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> G</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">char</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> B</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">char</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> A</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">ImageTyp=
e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">// instantiation: cr=
eates 800x600 elements, without knowing the memory layout, could be</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">// struct {char R, G, B,=
A; } image[800*600]; or</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">// struct {char R, G, B, A; } image[800][600]; or</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">// struct {char R[800*600], G[800*=
600], B[800*600], A[800*600]; } image; </span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// etc...</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">ImageType</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> image</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">({</span><span style=3D"color: #066;" class=3D"styled-by-prett=
ify">800</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #066;" class=3D"styled-by-prettify">600</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">});</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// Getting and setting elem=
ent works regardless of the layout using the field name</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>image</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">get</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify"><</span><span style=3D"color: #606;" clas=
s=3D"styled-by-prettify">ImageType</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">A</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">>({</span><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">0</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: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span></div></code></div><div style=3D"font-family: Arial, Helve=
tica, sans-serif; background-color: rgb(255, 255, 255);"><br></div></div><d=
iv>It is possible to achieve this using variadic template/tuples, but the f=
ields have to be addressed directly by index, which is simply unacceptable =
for a large code base, since the readability and maintainability is awful (=
think about accessing struct members by index instead of name!). Using enum=
s to alias the indexes is a very short term solution with more inconvenient=
s than benefits in then end. Using named parameters would not only improve =
readability but also facilitate aggregation of tagged tuples, ensure validi=
ty at compile time...</div><div><br></div><div>The solutions proposed here =
don't really solve this problem, either because the scope of the name is ju=
st wrong (Boost fusion), or because they are runtime solution (expensive, s=
tring comparisons...).</div><div><br></div><div>I compiled <a href=3D"https=
://bitbucket.org/tlutz/named-variadic-template-proposal">here</a> possible =
implementations to achieve something close to that using the current standa=
rd; and a very simple draft proposal about how we could make this much simp=
ler.</div><div><br></div><div>Any comment/input would be appreciated.</div>=
<div><br></div><div>Thanks</div><div><br></div><div>TL</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 <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_92_23885566.1397125687918--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 11 Apr 2014 08:37:38 +0800
Raw View
--Apple-Mail=_10CE4D05-81D6-469D-AE84-47FA6CC116DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-04-10, at 6:28 PM, thibaut.lutz@googlemail.com wrote:
> It is possible to achieve this using variadic template/tuples, but the fi=
elds have to be addressed directly by index, which is simply unacceptable f=
or a large code base, since the readability and maintainability is awful (t=
hink about accessing struct members by index instead of name!). Using enums=
to alias the indexes is a very short term solution with more inconvenients=
than benefits in then end.
Enum index types with overloading are the way I've solved this problem. The=
operator->* function has high precedence and it is intended to express mem=
ber access. image->*channel can be defined for various types of high-level =
image type (naked C array or struct containing an array, std::vector, Eigen=
::Matrix). In my implementation, index selects and operator->* returns a ch=
annel object, so you have (image->*channel)[ index ]. This works because I =
exclusively used Eigen for interleaved representation and it supports array=
slicing. Alternately you could have e.g. enum red_index : size_t select a =
different overload than enum blue_index and have syntax (image->*blue_index=
)[ x, y ]. (This would work well for a bounded range of channels, whereas i=
n my application I kept adding channels.) And don't forget the possibility =
of mapping indexes to members using an array of PTMs, which allows image->*=
pixel_index{ channel::blue, x, y }.
The nice thing about these solutions is portability to any library-defined =
image type. Your proposal seems to only apply to your own types.
However, I should note that the specific syntax you mention is already very=
close to working already. Pointer-to-members already may be template nonty=
pe parameters, so you could specialize get just the same as if R, G, B, A w=
ere enumerators. You're only missing the & in &ImageType::A. However, I don=
't see why enumerators are less convenient than PTMs.
--=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/.
--Apple-Mail=_10CE4D05-81D6-469D-AE84-47FA6CC116DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;04–10, at 6:28 PM, <a href=3D"mailto:thibaut.lutz@googlemail.co=
m">thibaut.lutz@googlemail.com</a> wrote:</div><br class=3D"Apple-interchan=
ge-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div>It is possible =
to achieve this using variadic template/tuples, but the fields have to be a=
ddressed directly by index, which is simply unacceptable for a large code b=
ase, since the readability and maintainability is awful (think about access=
ing struct members by index instead of name!). Using enums to alias the ind=
exes is a very short term solution with more inconvenients than benefits in=
then end.</div></div></blockquote><div><br></div><div>Enum index types wit=
h overloading are the way I’ve solved this problem. The <font face=3D=
"Courier">operator->*</font> function has high precedence and it is inte=
nded to express member access. <font face=3D"Courier">image->*channel</f=
ont> can be defined for various types of high-level <font face=3D"Cour=
ier">image</font> type (naked C array or struct containing an array, <=
font face=3D"Courier">std::vector</font>, <font face=3D"Courier">Eigen::Mat=
rix</font>). In my implementation, <font face=3D"Courier">index</font> sele=
cts and <font face=3D"Courier">operator->*</font> returns a channel obje=
ct, so you have <font face=3D"Courier">(image->*channel)[ index ]</font>=
.. This works because I exclusively used Eigen for interleaved representatio=
n and it supports array slicing. Alternately you could have e.g. <font=
face=3D"Courier">enum red_index : size_t</font> select a different ov=
erload than <font face=3D"Courier">enum blue_index</font> and have syn=
tax <font face=3D"Courier">(image->*blue_index)[ x, y ]</font>. (This wo=
uld work well for a bounded range of channels, whereas in my application I =
kept adding channels.) And don’t forget the possibility of mapping in=
dexes to members using an array of PTMs, which allows <font face=3D"Courier=
">image->*pixel_index{ channel::blue, x, y }</font>.</div><div><br></div=
><div>The nice thing about these solutions is portability to any library-de=
fined <font face=3D"Courier">image</font> type. Your proposal seems to only=
apply to your own types.</div><div><br></div><div>However, I should note t=
hat the specific syntax you mention is already very close to working alread=
y. Pointer-to-members already may be template nontype parameters, so you co=
uld specialize <font face=3D"Courier">get</font> just the same as if R, G, =
B, A were enumerators. You’re only missing the & in <font face=3D=
"Courier">&ImageType::A</font>. However, I don’t see why enumerat=
ors are less convenient than PTMs.</div><div><br></div></div></body></html>
<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 />
--Apple-Mail=_10CE4D05-81D6-469D-AE84-47FA6CC116DD--
.
Author: jeanbernard.jansen@gmail.com
Date: Mon, 12 May 2014 20:49:45 -0700 (PDT)
Raw View
------=_Part_1161_25476636.1399952985179
Content-Type: text/plain; charset=UTF-8
Hello guys
I think you might be interested by the way I've implemented it. It still
fresh but looks like a nice start : https://github.com/duckie/named_tuple
Feel free to ask questions, the code is pretty simple.
--
---
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_1161_25476636.1399952985179
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello guys<br><br>I think you might be interested by the w=
ay I've implemented it. It still fresh but looks like a nice start : <a hre=
f=3D"https://github.com/duckie/named_tuple">https://github.com/duckie/named=
_tuple</a><br><br>Feel free to ask questions, the code is pretty simple.<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 <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_1161_25476636.1399952985179--
.
Author: germandiago@gmail.com
Date: Fri, 16 May 2014 14:57:52 -0700 (PDT)
Raw View
VERY nice with the current features in the lang. I just wonder about collisions in hashing. How is it solved?
--
---
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/.
.
Author: germandiago@gmail.com
Date: Fri, 16 May 2014 15:06:37 -0700 (PDT)
Raw View
What about adding this to standard tuples? Can be done? I mean:
- generating a uint hash from operator "" _h
- make that available through get. Should already work?
- Overload make_tuple.
Would be great!
--
---
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/.
.
Author: gmisocpp@gmail.com
Date: Fri, 16 May 2014 19:12:54 -0700 (PDT)
Raw View
------=_Part_1257_15231221.1400292774856
Content-Type: text/plain; charset=UTF-8
Hi
On Saturday, May 17, 2014 10:06:37 AM UTC+12, germa...@gmail.com wrote:
>
> What about adding this to standard tuples? Can be done? I mean:
>
> - generating a uint hash from operator "" _h
> - make that available through get. Should already work?
> - Overload make_tuple.
>
> Would be great!
>
Can someone explain to me why I ever want a named tuple or any tuple
really? Given I never use them I find it hard to see why I'd want one
"standard" and when I have come across them in other peoples code I've
always found replacing them with a structure worked better for me and even
the original authors haven't changed them back again.
So can someone give me a real (as in useful) example of a tuple that would
help me appreciate them? I'm sure they must be useful because everyone
seems pretty fascinated with them so an example might help me here.
I've sometimes wished I could alias names for existing types, e.g. for
std::pair where first and second weren't named first and second, but
anything that takes a pair would take my aliased pair but that's something
different I guess. e.g:
std::pair<int x, int y> x;
x.x or x.first
x.y or x.second
but even that sounded like a bad idea, they just shouldn't have used pair
maybe in the original class.
Anyway, that's perhaps a tangent. Tuple help please :)
Thanks
--
---
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_1257_15231221.1400292774856
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi<br><br>On Saturday, May 17, 2014 10:06:37 AM UTC+12, ge=
rma...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204);=
border-left-width: 1px; border-left-style: solid;">What about adding this =
to standard tuples? Can be done? I mean:<p>- generating a uint hash from op=
erator "" _h<br>- make that available through get. Should already work?<br>=
- Overload make_tuple.<p>Would be great!<br></p></blockquote><div><br></div=
><div>Can someone explain to me why I ever want a named tuple or any tuple =
really? Given I never use them I find it hard to see why I'd want one "stan=
dard" and when I have come across them in other peoples code I've alwa=
ys found replacing them with a structure worked better for m=
e and even the original authors haven't changed them back again.</div><div>=
<br></div><div>So can someone give me a real (as in useful) example of=
a tuple that would help me appreciate them? I'm sure they must be useful b=
ecause everyone seems pretty fascinated with them so an example might help =
me here.</div><div><br></div><div>I've sometimes wished I could alias names=
for existing types, e.g. for std::pair where first and second weren't=
named first and second, but anything that takes a pair would take my =
aliased pair but that's something different I guess. e.g:</div><div><br></d=
iv><div>std::pair<int x, int y> x;</div><div>x.x or x.first</div><div=
>x.y or x.second</div><div><br></div><div>but even that sounded like a=
bad idea, they just shouldn't have used pair maybe in the original class.<=
/div><div><br></div><div>Anyway, that's perhaps a tangent. Tuple help pleas=
e :)</div><div><br></div><div>Thanks</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 <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_1257_15231221.1400292774856--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sat, 17 May 2014 07:33:40 +0200
Raw View
--089e0122aaee65b8b104f991dfc9
Content-Type: text/plain; charset=UTF-8
The proposal to add `std::tuple` is N1382:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1382.pdf
I guess the Motivation section is what attempts to answer your question.
On Sat, May 17, 2014 at 4:12 AM, <gmisocpp@gmail.com> wrote:
> Hi
>
>
> On Saturday, May 17, 2014 10:06:37 AM UTC+12, germa...@gmail.com wrote:
>>
>> What about adding this to standard tuples? Can be done? I mean:
>>
>> - generating a uint hash from operator "" _h
>> - make that available through get. Should already work?
>> - Overload make_tuple.
>>
>> Would be great!
>>
>>
> Can someone explain to me why I ever want a named tuple or any tuple
> really? Given I never use them I find it hard to see why I'd want one
> "standard" and when I have come across them in other peoples code I've
> always found replacing them with a structure worked better for me and even
> the original authors haven't changed them back again.
>
> So can someone give me a real (as in useful) example of a tuple that would
> help me appreciate them? I'm sure they must be useful because everyone
> seems pretty fascinated with them so an example might help me here.
>
> I've sometimes wished I could alias names for existing types, e.g. for
> std::pair where first and second weren't named first and second, but
> anything that takes a pair would take my aliased pair but that's something
> different I guess. e.g:
>
> std::pair<int x, int y> x;
> x.x or x.first
> x.y or x.second
>
> but even that sounded like a bad idea, they just shouldn't have used pair
> maybe in the original class.
>
> Anyway, that's perhaps a tangent. Tuple help please :)
>
> Thanks
>
> --
>
> ---
> 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/.
--089e0122aaee65b8b104f991dfc9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The proposal to add `std::tuple` is N1382:<div><br></div><=
div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n138=
2.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1382.pdf</a=
></div>
<div><br></div><div>I guess the Motivation section is what attempts to answ=
er your question.</div><div class=3D"gmail_extra"><br><br><div class=3D"gma=
il_quote">On Sat, May 17, 2014 at 4:12 AM, <span dir=3D"ltr"><<a href=
=3D"mailto:gmisocpp@gmail.com" target=3D"_blank">gmisocpp@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">Hi<div class=3D""><br><br>O=
n Saturday, May 17, 2014 10:06:37 AM UTC+12, <a href=3D"mailto:germa...@gma=
il.com" target=3D"_blank">germa...@gmail.com</a> wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-lef=
t-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
What about adding this to standard tuples? Can be done? I mean:<p>- generat=
ing a uint hash from operator "" _h<br>- make that available thro=
ugh get. Should already work?<br>- Overload make_tuple.</p><p>Would be grea=
t!<br>
</p><p></p></blockquote><div><br></div></div><div>Can someone explain to me=
why I ever want a named tuple or any tuple really? Given I never use them =
I find it hard to see why I'd want one "standard" and when=C2=
=A0I have come across them in other peoples code I've always=C2=A0found=
=C2=A0replacing=C2=A0them with a structure worked better for me and even th=
e original authors haven't changed them back again.</div>
<div><br></div><div>So can someone=C2=A0give me a real (as in useful) examp=
le of a tuple that would help me appreciate them? I'm sure they must be=
useful because everyone seems pretty fascinated with them so an example mi=
ght help me here.</div>
<div><br></div><div>I've sometimes wished I could alias names for exist=
ing types, e.g.=C2=A0for std::pair where first and second weren't named=
first and second,=C2=A0but anything that takes a pair would take my aliase=
d pair but that's something different I guess. e.g:</div>
<div><br></div><div>std::pair<int x, int y> x;</div><div>x.x or x.fir=
st</div><div>x.y or x.second</div><div><br></div><div>but even that sounded=
like=C2=A0a bad idea, they just shouldn't have used pair maybe in the =
original class.</div>
<div><br></div><div>Anyway, that's perhaps a tangent. Tuple help please=
:)</div><div><br></div><div>Thanks</div></div><div class=3D"HOEnZb"><div c=
lass=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></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 />
--089e0122aaee65b8b104f991dfc9--
.
Author: gmisocpp@gmail.com
Date: Sat, 17 May 2014 03:06:22 -0700 (PDT)
Raw View
------=_Part_1603_4525834.1400321182451
Content-Type: text/plain; charset=UTF-8
Hi
On Saturday, May 17, 2014 5:33:40 PM UTC+12, Andrew Tomazos wrote:
>
> The proposal to add `std::tuple` is N1382:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1382.pdf
>
> I guess the Motivation section is what attempts to answer your question.
>
I read the motivation part as suggested. I'm embarrassed to say I don't
feel any wiser.
>
>
> On Sat, May 17, 2014 at 4:12 AM, <gmis...@gmail.com <javascript:>> wrote:
>
>> Hi
>>
>>
>> On Saturday, May 17, 2014 10:06:37 AM UTC+12, germa...@gmail.com wrote:
>>>
>>> What about adding this to standard tuples? Can be done? I mean:
>>>
>>> - generating a uint hash from operator "" _h
>>> - make that available through get. Should already work?
>>> - Overload make_tuple.
>>>
>>> Would be great!
>>>
>>>
>> Can someone explain to me why I ever want a named tuple or any tuple
>> really? Given I never use them I find it hard to see why I'd want one
>> "standard" and when I have come across them in other peoples code I've
>> always found replacing them with a structure worked better for me and even
>> the original authors haven't changed them back again.
>>
>> So can someone give me a real (as in useful) example of a tuple that
>> would help me appreciate them? I'm sure they must be useful because
>> everyone seems pretty fascinated with them so an example might help me here.
>>
>> I've sometimes wished I could alias names for existing types, e.g. for
>> std::pair where first and second weren't named first and second, but
>> anything that takes a pair would take my aliased pair but that's something
>> different I guess. e.g:
>>
>> std::pair<int x, int y> x;
>> x.x or x.first
>> x.y or x.second
>>
>> but even that sounded like a bad idea, they just shouldn't have used pair
>> maybe in the original class.
>>
>> Anyway, that's perhaps a tangent. Tuple help please :)
>>
>> Thanks
>>
>> --
>>
>> ---
>> 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 <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> 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/.
------=_Part_1603_4525834.1400321182451
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi<br><br>On Saturday, May 17, 2014 5:33:40 PM UTC+12, And=
rew Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">The proposa=
l to add `std::tuple` is N1382:<div><br></div><div><a onmousedown=3D"this.h=
ref=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2=
Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2002%2Fn1382.pdf\46sa\75D\46sntz\0751\46usg\=
75AFQjCNEdu4A4Qra2mtk_5u2cYuC6HucFng';return true;" onclick=3D"this.href=3D=
'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%=
2Fwg21%2Fdocs%2Fpapers%2F2002%2Fn1382.pdf\46sa\75D\46sntz\0751\46usg\75AFQj=
CNEdu4A4Qra2mtk_5u2cYuC6HucFng';return true;" href=3D"http://www.open-std.o=
rg/jtc1/sc22/wg21/docs/papers/2002/n1382.pdf" target=3D"_blank">http://www.=
open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2002/<wbr>n1382.pdf</a></div>
<div><br></div><div>I guess the Motivation section is what attempts to answ=
er your question.</div></div></blockquote><div><br></div><div>I read the mo=
tivation part as suggested. I'm embarrassed to say I don't feel any wiser.<=
/div><div> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><b=
r><br><div class=3D"gmail_quote">On Sat, May 17, 2014 at 4:12 AM, <span di=
r=3D"ltr"><<a onmousedown=3D"this.href=3D'javascript:';return true;" onc=
lick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"7pMSkaKAIBMJ">gmis...@gmail.com</a>>=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div dir=3D"ltr">Hi<div><br><br>On Saturday, M=
ay 17, 2014 10:06:37 AM UTC+12, <a>germa...@gmail.com</a> wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1e=
x; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-le=
ft-style: solid;">
What about adding this to standard tuples? Can be done? I mean:<p>- generat=
ing a uint hash from operator "" _h<br>- make that available through get. S=
hould already work?<br>- Overload make_tuple.</p><p>Would be great!<br>
</p><p></p></blockquote><div><br></div></div><div>Can someone explain to me=
why I ever want a named tuple or any tuple really? Given I never use them =
I find it hard to see why I'd want one "standard" and when I have come=
across them in other peoples code I've always found replacing&nb=
sp;them with a structure worked better for me and even the original authors=
haven't changed them back again.</div>
<div><br></div><div>So can someone give me a real (as in useful) examp=
le of a tuple that would help me appreciate them? I'm sure they must be use=
ful because everyone seems pretty fascinated with them so an example might =
help me here.</div>
<div><br></div><div>I've sometimes wished I could alias names for existing =
types, e.g. for std::pair where first and second weren't named first a=
nd second, but anything that takes a pair would take my aliased pair b=
ut that's something different I guess. e.g:</div>
<div><br></div><div>std::pair<int x, int y> x;</div><div>x.x or x.fir=
st</div><div>x.y or x.second</div><div><br></div><div>but even that sounded=
like a bad idea, they just shouldn't have used pair maybe in the orig=
inal class.</div>
<div><br></div><div>Anyway, that's perhaps a tangent. Tuple help please :)<=
/div><div><br></div><div>Thanks</div></div><div><div>
<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 onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"7pMSkaKAIBMJ">std-proposal...@<wbr>isocpp.=
org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return true;" href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"7pMSkaKAIBMJ">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a onmousedown=3D"this.href=3D'http://groups.google.com=
/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"this.href=3D'h=
ttp://groups.google.com/a/isocpp.org/group/std-proposals/';return true;" hr=
ef=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/" target=3D=
"_blank">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</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_1603_4525834.1400321182451--
.
Author: =?UTF-8?Q?Germ=C3=A1n_Diago?= <germandiago@gmail.com>
Date: Sun, 18 May 2014 02:29:08 +0700
Raw View
--047d7b2e4a443f92b104f99d8b58
Content-Type: text/plain; charset=UTF-8
I dnt want to create a struct for.each database query or for adhoc small
data structures that I will use very few times, polluting my public
interface with those structs, yet I want to use names to keep fields
readable.
On May 17, 2014 9:12 AM, <gmisocpp@gmail.com> wrote:
> Hi
>
> On Saturday, May 17, 2014 10:06:37 AM UTC+12, germa...@gmail.com wrote:
>>
>> What about adding this to standard tuples? Can be done? I mean:
>>
>> - generating a uint hash from operator "" _h
>> - make that available through get. Should already work?
>> - Overload make_tuple.
>>
>> Would be great!
>>
>
> Can someone explain to me why I ever want a named tuple or any tuple
> really? Given I never use them I find it hard to see why I'd want one
> "standard" and when I have come across them in other peoples code I've
> always found replacing them with a structure worked better for me and even
> the original authors haven't changed them back again.
>
> So can someone give me a real (as in useful) example of a tuple that would
> help me appreciate them? I'm sure they must be useful because everyone
> seems pretty fascinated with them so an example might help me here.
>
> I've sometimes wished I could alias names for existing types, e.g. for
> std::pair where first and second weren't named first and second, but
> anything that takes a pair would take my aliased pair but that's something
> different I guess. e.g:
>
> std::pair<int x, int y> x;
> x.x or x.first
> x.y or x.second
>
> but even that sounded like a bad idea, they just shouldn't have used pair
> maybe in the original class.
>
> Anyway, that's perhaps a tangent. Tuple help please :)
>
> Thanks
>
--
---
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/.
--047d7b2e4a443f92b104f99d8b58
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">I dnt want to create a struct for.each database query or for=
adhoc small data structures that I will use very few times, polluting my p=
ublic interface with those structs, yet I want to use names to keep fields =
readable.</p>
<div class=3D"gmail_quote">On May 17, 2014 9:12 AM, <<a href=3D"mailto:=
gmisocpp@gmail.com">gmisocpp@gmail.com</a>> wrote:<br type=3D"attributio=
n"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Hi<br><br>On Saturday, May 17, 2014 10:06:37 AM UTC+12, <a=
href=3D"mailto:germa...@gmail.com" target=3D"_blank">germa...@gmail.com</a=
> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;=
border-left-style:solid">
What about adding this to standard tuples? Can be done? I mean:<p>- generat=
ing a uint hash from operator "" _h<br>- make that available thro=
ugh get. Should already work?<br>- Overload make_tuple.<p>Would be great!<b=
r>
</p></p></blockquote><div><br></div><div>Can someone explain to me why I ev=
er want a named tuple or any tuple really? Given I never use them I find it=
hard to see why I'd want one "standard" and when=C2=A0I have=
come across them in other peoples code I've always=C2=A0found=C2=A0rep=
lacing=C2=A0them with a structure worked better for me and even the origina=
l authors haven't changed them back again.</div>
<div><br></div><div>So can someone=C2=A0give me a real (as in useful) examp=
le of a tuple that would help me appreciate them? I'm sure they must be=
useful because everyone seems pretty fascinated with them so an example mi=
ght help me here.</div>
<div><br></div><div>I've sometimes wished I could alias names for exist=
ing types, e.g.=C2=A0for std::pair where first and second weren't named=
first and second,=C2=A0but anything that takes a pair would take my aliase=
d pair but that's something different I guess. e.g:</div>
<div><br></div><div>std::pair<int x, int y> x;</div><div>x.x or x.fir=
st</div><div>x.y or x.second</div><div><br></div><div>but even that sounded=
like=C2=A0a bad idea, they just shouldn't have used pair maybe in the =
original class.</div>
<div><br></div><div>Anyway, that's perhaps a tangent. Tuple help please=
:)</div><div><br></div><div>Thanks</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 />
--047d7b2e4a443f92b104f99d8b58--
.
Author: Shachar Shemesh <shachar@lingnu.com>
Date: Sat, 17 May 2014 22:37:19 +0300
Raw View
This is a multi-part message in MIME format.
--------------020609010602030704090906
Content-Type: text/plain; charset=UTF-8
On 17/05/14 13:06, gmisocpp@gmail.com wrote:
> Hi
>
> On Saturday, May 17, 2014 5:33:40 PM UTC+12, Andrew Tomazos wrote:
>
> The proposal to add `std::tuple` is N1382:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1382.pdf
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1382.pdf>
>
> I guess the Motivation section is what attempts to answer your
> question.
>
>
> I read the motivation part as suggested. I'm embarrassed to say I
> don't feel any wiser.
>
The following represents my opinion:
This is a "me too" feature. In some languages (most listed in the
motivation document mentioned above), tuples are the only way to pass,
well, anything around. Function parameter list? A tuple. Multiple
returns from a function? A tuple. Array containing more than one piece
of data? An array of tuples.
This means that some people got used to working with tuples. You might
think that this is not "the C++ way of doing things", and the only
answer I can give you is that I agree with you.
Now, some use cases do lend themselves to something that structs do not
easily provide. If you think of a function returning more than one
result, it is not easy to define such a thing as an anonymous struct and
then use it effectively. In that case, a tuple does comes in handy. I'm
not sure it is the best solution to this problem, but it's one that
exists today.
Shachar
--
---
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/.
--------------020609010602030704090906
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html style=3D"direction: ltr;">
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
<style type=3D"text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt=
; } </style>
</head>
<body style=3D"direction: ltr;"
bidimailui-detected-decoding-type=3D"UTF-8" bgcolor=3D"#FFFFFF"
text=3D"#000000">
<div class=3D"moz-cite-prefix">On 17/05/14 13:06, <a class=3D"moz-txt-l=
ink-abbreviated" href=3D"mailto:gmisocpp@gmail.com">gmisocpp@gmail.com</a>
wrote:<br>
</div>
<blockquote
cite=3D"mid:e126aee9-6de3-4b4d-847e-469972b58688@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">Hi<br>
<br>
On Saturday, May 17, 2014 5:33:40 PM UTC+12, Andrew Tomazos
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204,
204); border-left-width: 1px; border-left-style: solid;">
<div dir=3D"ltr">The proposal to add `std::tuple` is N1382:
<div><br>
</div>
<div><a moz-do-not-send=3D"true"
onmousedown=3D"this.href=3D'http://www.google.com/url?q\75h=
ttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2002%2F=
n1382.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEdu4A4Qra2mtk_5u2cYuC6HucFng';=
return
true;"
onclick=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2002%2Fn138=
2.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEdu4A4Qra2mtk_5u2cYuC6HucFng';retu=
rn
true;"
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/=
2002/n1382.pdf"
target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg=
21/docs/papers/2002/<wbr>n1382.pdf</a></div>
<div><br>
</div>
<div>I guess the Motivation section is what attempts to
answer your question.</div>
</div>
</blockquote>
<div><br>
</div>
<div>I read the motivation part as suggested. I'm embarrassed to
say I don't feel any wiser.</div>
<div>=C2=A0<br>
</div>
</div>
</blockquote>
The following represents my opinion:<br>
This is a "me too" feature. In some languages (most listed in the
motivation document mentioned above), tuples are the only way to
pass, well, anything around. Function parameter list? A tuple.
Multiple returns from a function? A tuple. Array containing more
than one piece of data? An array of tuples.<br>
<br>
This means that some people got used to working with tuples. You
might think that this is not "the C++ way of doing things", and the
only answer I can give you is that I agree with you.<br>
<br>
Now, some use cases do lend themselves to something that structs do
not easily provide. If you think of a function returning more than
one result, it is not easy to define such a thing as an anonymous
struct and then use it effectively. In that case, a tuple does comes
in handy. I'm not sure it is the best solution to this problem, but
it's one that exists today.<br>
<br>
Shachar<br>
</body>
</html>
<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 />
--------------020609010602030704090906--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Sat, 17 May 2014 14:29:21 -0700 (PDT)
Raw View
------=_Part_1342_272924.1400362161508
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Couldn't this be looked on the other way around:
instead of adding names to tuple elements to make the whole thing more=20
struct-like you could just as well add some kind of indexing possibility to=
=20
structs, to make them more tuple-like. At least as far as I have understood=
=20
it the main advantage that tuples provide over structs is that you can=20
index them with compile time constant indices, which is common in template=
=20
metaprogramming.
One way of achieving this would be to define the get<ix>(v) function to=20
work for any struct value v. As this is not implementable in library code=
=20
(at least not before CTTI) this generates a messy state where get is=20
defined in the library for tuples and in the language for structs. To avoid=
=20
this it could be a better choice to define a builtin operator[constexpr i]=
=20
for all structs. Unfortunately this clashes with any struct defining a=20
operator[] itself which can be resolved by letting such a definition hide=
=20
the built in one,
The worse problem is however to define what indexing pertains to and in=20
which order, considering things like private members and inheritance. Maybe=
=20
operator[] should only be defined for POD structs (or a similar subset=20
where indexes are obvious).
Even with these limitations and shortcomings I think that adding indexing=
=20
to structs is less strange than adding names to tuples, which would be=20
quite a big syntax change to achieve something that is almost the same as=
=20
the struct we had since C.
Den l=C3=B6rdagen den 17:e maj 2014 kl. 21:37:19 UTC+2 skrev Shachar Shemes=
h:
>
> On 17/05/14 13:06, gmis...@gmail.com <javascript:> wrote:
> =20
> Hi
>
> On Saturday, May 17, 2014 5:33:40 PM UTC+12, Andrew Tomazos wrote:=20
>>
>> The proposal to add `std::tuple` is N1382:=20
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1382.pdf
>>
>> I guess the Motivation section is what attempts to answer your question=
..
>> =20
>
> I read the motivation part as suggested. I'm embarrassed to say I don't=
=20
> feel any wiser.
> =20
> =20
> The following represents my opinion:
> This is a "me too" feature. In some languages (most listed in the=20
> motivation document mentioned above), tuples are the only way to pass,=20
> well, anything around. Function parameter list? A tuple. Multiple returns=
=20
> from a function? A tuple. Array containing more than one piece of data? A=
n=20
> array of tuples.
>
> This means that some people got used to working with tuples. You might=20
> think that this is not "the C++ way of doing things", and the only answer=
I=20
> can give you is that I agree with you.
>
> Now, some use cases do lend themselves to something that structs do not=
=20
> easily provide. If you think of a function returning more than one result=
,=20
> it is not easy to define such a thing as an anonymous struct and then use=
=20
> it effectively. In that case, a tuple does comes in handy. I'm not sure i=
t=20
> is the best solution to this problem, but it's one that exists today.
>
> Shachar
> =20
--=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_1342_272924.1400362161508
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Couldn't this be looked on the other way around:<div><br><=
/div><div>instead of adding names to tuple elements to make the whole thing=
more struct-like you could just as well add some kind of indexing possibil=
ity to structs, to make them more tuple-like. At least as far as I have und=
erstood it the main advantage that tuples provide over structs is that you =
can index them with compile time constant indices, which is common in templ=
ate metaprogramming.</div><div><br></div><div>One way of achieving this wou=
ld be to define the get<ix>(v) function to work for any struct value =
v. As this is not implementable in library code (at least not before CTTI) =
this generates a messy state where get is defined in the library for tuples=
and in the language for structs. To avoid this it could be a better choice=
to define a builtin operator[constexpr i] for all structs. Unfortunately t=
his clashes with any struct defining a operator[] itself which can be resol=
ved by letting such a definition hide the built in one,</div><div><br></div=
><div>The worse problem is however to define what indexing pertains to and =
in which order, considering things like private members and inheritance. Ma=
ybe operator[] should only be defined for POD structs (or a similar subset =
where indexes are obvious).</div><div><br></div><div>Even with these limita=
tions and shortcomings I think that adding indexing to structs is less stra=
nge than adding names to tuples, which would be quite a big syntax change t=
o achieve something that is almost the same as the struct we had since C.</=
div><div><br></div><div><br><br>Den l=C3=B6rdagen den 17:e maj 2014 kl. 21:=
37:19 UTC+2 skrev Shachar Shemesh:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
=20
=20
=20
=20
<div style=3D"direction:ltr" bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>On 17/05/14 13:06, <a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"RBZSp2NNo3wJ" onmousedown=3D"this.href=3D'javascript:';=
return true;" onclick=3D"this.href=3D'javascript:';return true;">gmis...@gm=
ail.com</a>
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">Hi<br>
<br>
On Saturday, May 17, 2014 5:33:40 PM UTC+12, Andrew Tomazos
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;=
border-left-style:solid">
<div dir=3D"ltr">The proposal to add `std::tuple` is N1382:
<div><br>
</div>
<div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2002/n1382.pdf" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fd=
ocs%2Fpapers%2F2002%2Fn1382.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEdu4A4Qr=
a2mtk_5u2cYuC6HucFng';return true;" onclick=3D"this.href=3D'http://www.goog=
le.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2F=
papers%2F2002%2Fn1382.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEdu4A4Qra2mtk_=
5u2cYuC6HucFng';return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/d=
ocs/papers/2002/<wbr>n1382.pdf</a></div>
<div><br>
</div>
<div>I guess the Motivation section is what attempts to
answer your question.</div>
</div>
</blockquote>
<div><br>
</div>
<div>I read the motivation part as suggested. I'm embarrassed to
say I don't feel any wiser.</div>
<div> <br>
</div>
</div>
</blockquote>
The following represents my opinion:<br>
This is a "me too" feature. In some languages (most listed in the
motivation document mentioned above), tuples are the only way to
pass, well, anything around. Function parameter list? A tuple.
Multiple returns from a function? A tuple. Array containing more
than one piece of data? An array of tuples.<br>
<br>
This means that some people got used to working with tuples. You
might think that this is not "the C++ way of doing things", and the
only answer I can give you is that I agree with you.<br>
<br>
Now, some use cases do lend themselves to something that structs do
not easily provide. If you think of a function returning more than
one result, it is not easy to define such a thing as an anonymous
struct and then use it effectively. In that case, a tuple does comes
in handy. I'm not sure it is the best solution to this problem, but
it's one that exists today.<br>
<br>
Shachar<br>
</div>
</blockquote></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 <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_1342_272924.1400362161508--
.
Author: gmisocpp@gmail.com
Date: Sat, 17 May 2014 14:36:37 -0700 (PDT)
Raw View
------=_Part_1923_26391842.1400362597778
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi
On Sunday, May 18, 2014 7:29:08 AM UTC+12, Germ=C3=A1n Diago wrote:
>
> I dnt want to create a struct for.each database query or for adhoc small=
=20
> data structures that I will use very few times, polluting my public=20
> interface with those structs, yet I want to use names to keep fields=20
> readable.
>
Database querying is the one place where I perhaps have thought I wanted=20
such a thing but invariably you want to use the type more / pass it on=20
further than initially intended, and then you wish you'd just have used a=
=20
struct in the first place. The same thing happens with pair really.
Wouldn't a namespace have worked here as a place to group the types? And=20
don't you get stuck with a bunch of get<0> constants that you start to hate=
=20
so want to name so end up with a namespace to put those named constants in=
=20
anyway? I see the named tuple would avoid that part but then you're back to=
=20
a struct feeling simpler again. Are you not?
--=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_1923_26391842.1400362597778
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi<br><br>On Sunday, May 18, 2014 7:29:08 AM UTC+12, Germ=
=C3=A1n Diago wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bo=
rder-left-width: 1px; border-left-style: solid;"><p dir=3D"ltr">I dnt want =
to create a struct for.each database query or for adhoc small data structur=
es that I will use very few times, polluting my public interface with those=
structs, yet I want to use names to keep fields readable.</p></blockquote>=
<div>Database querying is the one place where I perhaps have thou=
ght I wanted such a thing but invariably you want to use the=
type more / pass it on further than initially intended, and then you&=
nbsp;wish you'd just have used a struct in the first place. The same thing =
happens with pair really.</div><div><br></div><div>Wouldn't a namespac=
e have worked here as a place to group the types? And don't you g=
et stuck with a bunch of get<0> constants that you start to hate so w=
ant to name so end up with a namespace to put those nam=
ed constants in anyway? I see the named tuple would avoid that part but the=
n you're back to a struct feeling simpler again. Are you not=
?</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_1923_26391842.1400362597778--
.
Author: gmisocpp@gmail.com
Date: Sat, 17 May 2014 15:53:38 -0700 (PDT)
Raw View
------=_Part_2001_27190894.1400367218940
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi Bengt
On Sunday, May 18, 2014 9:29:21 AM UTC+12, Bengt Gustafsson wrote:
>
> Couldn't this be looked on the other way around:
>
> instead of adding names to tuple elements to make the whole thing more=20
> struct-like you could just as well add some kind of indexing possibility =
to=20
> structs, to make them more tuple-like. At least as far as I have understo=
od=20
> it the main advantage that tuples provide over structs is that you can=20
> index them with compile time constant indices, which is common in templat=
e=20
> metaprogramming.
>
Funny, I was just mentally sketching out a thought about how to "label" any=
=20
member of a struct with a number when you're post arrived. I think that=20
means I had the same thought as you here. It does indeed seem better to be=
=20
able to number any struct member than to just name any tuple item. At least=
=20
at first glance.
My concern is that just being able to query a tuple class by name isn't=20
likely to provide enough support for the problems which tuples are being=20
used to solve. But since I haven't seen any great example problems that=20
require a tuple, it's hard for me to say that.
I want to say tuples aren't needed, but I'm conscious that that might=20
just mean I'm just working in a space that doesn't need them so I shouldn't=
=20
deny that to others that are. But my worry is that I still can't see a=20
strong value for them if they just gained a name and I remain=20
sceptical that just adding a name would be enough even for people who do=20
use tuples for their problem, that it solve their problem that much better.
It seems we should have a clear understanding of real (not toy) examples=20
where tuples provide a solution and then see if it's not better to go all=
=20
out and provide full set of tools to solve those actual problems nicely and=
=20
more fully and to prove if just adding a name is enough. I suspect it=20
isn't. In which case don't add names or add more support would be the=20
conclusion; or don't add support at all if the whole problem space is too=
=20
narrow to warrant support.
But other proposals like reflection etc. might help in the tuple=20
space without good examples of the problems tuples are being employed to=20
solve we can't see where those proposals can come together for a better=20
solution either.
As soon as you make tuple "easier" by offering a name, you open up more=20
uses that demand more support. So it seems better to assume that and start=
=20
with some good examples and then really go all out to find out where people=
=20
are wanting to go with the capabilities proposed and see if the language=20
needs either no support for tuple or a lot more support than just adding=20
a name.
Having a get<n> that would work on any type seems a start in that direction=
=20
here. Other random ideas:
void f()
{
[] person; // forward declare
void print_person( person& p) -> void
// I wish an earlier proposal had got accepted to for local functions=20
that looked like them and not lamda's.
{
cout << name < " " << age << endl;
}
string name;
int age;
[s,x] as person; // lambda without da lamb. aka struct. with get<> support.=
=20
aka tuple.
print_person(p)
}
Thanks!
> One way of achieving this would be to define the get<ix>(v) function to=
=20
> work for any struct value v. As this is not implementable in library code=
=20
> (at least not before CTTI) this generates a messy state where get is=20
> defined in the library for tuples and in the language for structs. To avo=
id=20
> this it could be a better choice to define a builtin operator[constexpr i=
]=20
> for all structs. Unfortunately this clashes with any struct defining a=20
> operator[] itself which can be resolved by letting such a definition hide=
=20
> the built in one,
>
> The worse problem is however to define what indexing pertains to and in=
=20
> which order, considering things like private members and inheritance. May=
be=20
> operator[] should only be defined for POD structs (or a similar subset=20
> where indexes are obvious).
>
> Even with these limitations and shortcomings I think that adding indexing=
=20
> to structs is less strange than adding names to tuples, which would be=20
> quite a big syntax change to achieve something that is almost the same as=
=20
> the struct we had since C.
>
>
>
> Den l=C3=B6rdagen den 17:e maj 2014 kl. 21:37:19 UTC+2 skrev Shachar Shem=
esh:
>>
>> On 17/05/14 13:06, gmis...@gmail.com wrote:
>> =20
>> Hi
>>
>> On Saturday, May 17, 2014 5:33:40 PM UTC+12, Andrew Tomazos wrote:=20
>>>
>>> The proposal to add `std::tuple` is N1382:=20
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1382.pdf
>>>
>>> I guess the Motivation section is what attempts to answer your=20
>>> question.
>>> =20
>>
>> I read the motivation part as suggested. I'm embarrassed to say I don't=
=20
>> feel any wiser.
>> =20
>> =20
>> The following represents my opinion:
>> This is a "me too" feature. In some languages (most listed in the=20
>> motivation document mentioned above), tuples are the only way to pass,=
=20
>> well, anything around. Function parameter list? A tuple. Multiple return=
s=20
>> from a function? A tuple. Array containing more than one piece of data? =
An=20
>> array of tuples.
>>
>> This means that some people got used to working with tuples. You might=
=20
>> think that this is not "the C++ way of doing things", and the only answe=
r I=20
>> can give you is that I agree with you.
>>
>> Now, some use cases do lend themselves to something that structs do not=
=20
>> easily provide. If you think of a function returning more than one resul=
t,=20
>> it is not easy to define such a thing as an anonymous struct and then us=
e=20
>> it effectively. In that case, a tuple does comes in handy. I'm not sure =
it=20
>> is the best solution to this problem, but it's one that exists today.
>>
>> Shachar
>> =20
>
--=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_2001_27190894.1400367218940
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Bengt<br><br>On Sunday, May 18, 2014 9:29:21 AM UTC+12,=
Bengt Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">Could=
n't this be looked on the other way around:<div><br></div><div>instead of a=
dding names to tuple elements to make the whole thing more struct-like you =
could just as well add some kind of indexing possibility to structs, to mak=
e them more tuple-like. At least as far as I have understood it the main ad=
vantage that tuples provide over structs is that you can index them with co=
mpile time constant indices, which is common in template metaprogramming.</=
div></div></blockquote><div><br></div><div>Funny, I was just mentally =
sketching out a thought about how to "label" any member of a struct wi=
th a number when you're post arrived. I think that means I had t=
he same thought as you here. It does indeed seem better to be able to numbe=
r any struct member than to just name any tuple item. At least at firs=
t glance.</div><div><br></div><div>My concern is that just being able to&nb=
sp;query a tuple class by name isn't likely to provide enough support =
for the problems which tuples are being used to solve. But since I hav=
en't seen any great example problems that require a tuple, it's hard for me=
to say that.</div><div><br></div><div>I want to say tuples aren'=
t needed, but I'm conscious that that might just mean I'm just&nb=
sp;working in a space that doesn't need them so I shouldn't deny that to ot=
hers that are. But my worry is that I still can't see a strong value f=
or them if they just gained a name and I remain sceptical that just ad=
ding a name would be enough even for people who do use =
tuples for their problem, that it solve their problem that much better=
..</div><div><br></div><div>It seems we should have a clear understandi=
ng of real (not toy) examples where tuples provide a solution and then=
see if it's not better to go all out and provide full set of&nbs=
p;tools to solve those actual problems nicely and more fully and =
to prove if just adding a name is enough. I suspect it isn't. In which case=
don't add names or add more support would be the conclusion; or don't add =
support at all if the whole problem space is too narrow to warrant support.=
</div><div><br></div><div>But other proposals like reflection etc=
.. might help in the tuple space without good examples of the=
problems tuples are being employed to solve we can't see where t=
hose proposals can come together for a better solution either.</div><d=
iv><br></div><div>As soon as you make tuple "easier" by offering a name, yo=
u open up more uses that demand more support. So it see=
ms better to assume that and start with some good examples and th=
en really go all out to find out where people are wanting to go with t=
he capabilities proposed and see if the language needs eithe=
r no support for tuple or a lot more support than just adding a&n=
bsp;name.</div><div><br></div><div>Having a get<n> that would work on=
any type seems a start in that direction here. Other random idea=
s:</div><div><br></div><div>void f()<br>{</div><div>[] person; // forward d=
eclare</div><div><br></div><div><div><div>void print_person( person& p)=
-> void</div><div> // I wish an earlier proposal had g=
ot accepted to for local functions that looked like them and not =
lamda's.</div><div>{</div><div> cout << name < "=
" << age << endl;<br>}</div><div><br></div></div>string name;<=
/div><div>int age;</div><div><br></div><div>[s,x] as person; // lambda with=
out da lamb. aka struct. with get<> support. aka tuple.</div><div>pri=
nt_person(p)</div><div>}</div><div><br></div><div>Thanks!</div><div><br></d=
iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><br></=
div><div>One way of achieving this would be to define the get<ix>(v) =
function to work for any struct value v. As this is not implementable in li=
brary code (at least not before CTTI) this generates a messy state where ge=
t is defined in the library for tuples and in the language for structs. To =
avoid this it could be a better choice to define a builtin operator[constex=
pr i] for all structs. Unfortunately this clashes with any struct defining =
a operator[] itself which can be resolved by letting such a definition hide=
the built in one,</div><div><br></div><div>The worse problem is however to=
define what indexing pertains to and in which order, considering things li=
ke private members and inheritance. Maybe operator[] should only be defined=
for POD structs (or a similar subset where indexes are obvious).</div><div=
><br></div><div>Even with these limitations and shortcomings I think that a=
dding indexing to structs is less strange than adding names to tuples, whic=
h would be quite a big syntax change to achieve something that is almost th=
e same as the struct we had since C.</div><div><br></div><div><br><br>Den l=
=C3=B6rdagen den 17:e maj 2014 kl. 21:37:19 UTC+2 skrev Shachar Shemesh:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-=
left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; b=
order-left-style: solid;">
=20
=20
=20
=20
<div style=3D"direction: ltr;" text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 17/05/14 13:06, <a>gmis...@gmail.com</a>
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">Hi<br>
<br>
On Saturday, May 17, 2014 5:33:40 PM UTC+12, Andrew Tomazos
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8e=
x; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wi=
dth: 1px; border-left-style: solid;">
<div dir=3D"ltr">The proposal to add `std::tuple` is N1382:
<div><br>
</div>
<div><a onmousedown=3D"this.href=3D'http://www.google.com/url?q=
\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F200=
2%2Fn1382.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEdu4A4Qra2mtk_5u2cYuC6HucF=
ng';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75htt=
p%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2002%2Fn1=
382.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEdu4A4Qra2mtk_5u2cYuC6HucFng';re=
turn true;" href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002=
/n1382.pdf" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/d=
ocs/papers/2002/<wbr>n1382.pdf</a></div>
<div><br>
</div>
<div>I guess the Motivation section is what attempts to
answer your question.</div>
</div>
</blockquote>
<div><br>
</div>
<div>I read the motivation part as suggested. I'm embarrassed to
say I don't feel any wiser.</div>
<div> <br>
</div>
</div>
</blockquote>
The following represents my opinion:<br>
This is a "me too" feature. In some languages (most listed in the
motivation document mentioned above), tuples are the only way to
pass, well, anything around. Function parameter list? A tuple.
Multiple returns from a function? A tuple. Array containing more
than one piece of data? An array of tuples.<br>
<br>
This means that some people got used to working with tuples. You
might think that this is not "the C++ way of doing things", and the
only answer I can give you is that I agree with you.<br>
<br>
Now, some use cases do lend themselves to something that structs do
not easily provide. If you think of a function returning more than
one result, it is not easy to define such a thing as an anonymous
struct and then use it effectively. In that case, a tuple does comes
in handy. I'm not sure it is the best solution to this problem, but
it's one that exists today.<br>
<br>
Shachar<br>
</div>
</blockquote></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_2001_27190894.1400367218940--
.
Author: G M <gmisocpp@gmail.com>
Date: Sun, 18 May 2014 12:12:30 +1200
Raw View
--001a11c2da9cad02ec04f9a1803b
Content-Type: text/plain; charset=UTF-8
Forget the example from that last post, I hit enter way too early.
But the basic idea was to imagine get<n> worked on any type as bengt first
posted, then imagine if lambda captures could exist without their function
and see how useful that is. Does that start to create a toolbox that
compares to a tuple or solve any problems that tuple is being used for
today; or is it useful in it's own right?
Bengt's comment about accessing any type by number at compile time then
begs the opposite desire of getting at any member of any object at runtime
by name
Forgive me if I'm wrong, but It seems to me this whole tuple thing is not
really just about accessing an element by name or number at compile time,
but it will be a lead in to a very database-like feature that might benefit
from being examined in that context - of libraries like linkq etc.,
in memory databases etc, accessing an entity by name and number not just at
compile time but at runtime; dynamic vs static and querying abilities to
create shapes and types.
Language constructs that work together to allow that seem to be the
eventual evolution destination and for solving those kinds of problems.
Just adding a compile time name isn't doing much for us (at least me), I
think.
People are going to want dynamic_tuple, hybrid_tuple and "just let my
object behave like a tuple" and more creative ways of creating a tuple than
just make tuple, e.g. select.
Is there any truth to this point of view?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c2da9cad02ec04f9a1803b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>Forget the example=C2=A0from that last post, I hit enter way too early.</d=
iv><div><br></div><div>But the=C2=A0basic=C2=A0idea was to imagine get<n=
> worked on any type as bengt first posted, then imagine=C2=A0if=C2=A0la=
mbda captures=C2=A0could exist without=C2=A0their function and=C2=A0see how=
=C2=A0useful that is.=C2=A0Does=C2=A0that start to create a toolbox that co=
mpares to a tuple or solve any problems that tuple is being used for today;=
=C2=A0or is it useful in it's=C2=A0own right?</div>
<div><br></div><div><div>Bengt's=C2=A0comment about accessing any type =
by=C2=A0number at compile time then begs the opposite desire of getting at =
any=C2=A0member of any=C2=A0object at runtime by name</div><div><br></div><=
/div><div>Forgive me if I'm wrong, but It seems to me this whole tuple =
thing is not really just about accessing an element by name or number at co=
mpile time, but=C2=A0it will be a lead in to a=C2=A0very database-like=C2=
=A0feature that=C2=A0might benefit from being examined in that context -=C2=
=A0of libraries like linkq etc., in=C2=A0memory databases etc,=C2=A0accessi=
ng an entity=C2=A0by name and number=C2=A0not just at compile time=C2=A0but=
at runtime; dynamic=C2=A0vs static and querying=C2=A0abilities to create=
=C2=A0shapes and types.</div>
<div><br></div><div>Language constructs that work together to allow that se=
em to be the eventual evolution destination and for solving those kinds of =
problems. Just adding a=C2=A0compile time name isn't doing much for us =
(at least me), I think.</div>
<div><br></div><div>People are going to want dynamic_tuple, hybrid_tuple an=
d "just let my object behave like a tuple" and more creative ways=
of creating a tuple than just make tuple,=C2=A0e.g. select.</div><div><br>=
</div>
<div>Is there any=C2=A0truth to this point of view?</div></div></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 <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 />
--001a11c2da9cad02ec04f9a1803b--
.
Author: Jean-Bernard Jansen <jeanbernard.jansen@gmail.com>
Date: Sun, 18 May 2014 22:47:00 +0200
Raw View
--089e013a1180d0076d04f9b2c09b
Content-Type: text/plain; charset=UTF-8
Hello all
@GM I think your point of view is quite valuable. I am wondering about the
way to implement runtime introspection over the existing compile time
introspection. That would be nice but must be an opt-in since it has a cost
over single structs or tuples.
@German Diago Collisions are not a problem if you use the second method
with the types. Collisions are NOT solved if you used the _h trick. I
considered that attribute names in anonymous structures are often short and
common, and collisions are unlikely. I cant find a way to cope with them,
unless writing a test script that loops over a dictionary to find
collisions in it, and in which you pick your attribute names from time to
time. Its not ideal, but if you have any better idea about that, you are
welcome.
For me, adding the indexing possibility to structs is not the same than
adding the access by name on tuples. The difference resides in the fact
that a struct have itself a name. If you define a second struct with the
same attributes (name and types), they would not be copyable are movable
between each other. In the "named tuples" version, they are, because the
type is defined by its very content, and not by a name.
On Sun, May 18, 2014 at 2:12 AM, G M <gmisocpp@gmail.com> wrote:
> Forget the example from that last post, I hit enter way too early.
>
> But the basic idea was to imagine get<n> worked on any type as bengt first
> posted, then imagine if lambda captures could exist without their function
> and see how useful that is. Does that start to create a toolbox that
> compares to a tuple or solve any problems that tuple is being used for
> today; or is it useful in it's own right?
>
> Bengt's comment about accessing any type by number at compile time then
> begs the opposite desire of getting at any member of any object at runtime
> by name
>
> Forgive me if I'm wrong, but It seems to me this whole tuple thing is not
> really just about accessing an element by name or number at compile time,
> but it will be a lead in to a very database-like feature that might benefit
> from being examined in that context - of libraries like linkq etc.,
> in memory databases etc, accessing an entity by name and number not just at
> compile time but at runtime; dynamic vs static and querying abilities to
> create shapes and types.
>
> Language constructs that work together to allow that seem to be the
> eventual evolution destination and for solving those kinds of problems.
> Just adding a compile time name isn't doing much for us (at least me), I
> think.
>
> People are going to want dynamic_tuple, hybrid_tuple and "just let my
> object behave like a tuple" and more creative ways of creating a tuple than
> just make tuple, e.g. select.
>
> Is there any truth to this point of view?
>
> --
>
> ---
> 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/N-kIXNrkTUk/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.
> 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/.
--089e013a1180d0076d04f9b2c09b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>Hello all<br><br></div>@GM I think your poi=
nt of view is quite valuable. I am wondering about the way to implement run=
time introspection over the existing compile time introspection. That would=
be nice but must be an opt-in since it has a cost over single structs or t=
uples.<br>
<br></div>@German Diago=C2=A0 Collisions are not a problem if you use the s=
econd method with the types. Collisions are NOT solved if you used the _h t=
rick. I considered that attribute names in anonymous structures are often s=
hort and common, and collisions are unlikely. I cant find a way to cope wit=
h them, unless writing a test script that loops over a dictionary to find c=
ollisions in it, and in which you pick your attribute names from time to ti=
me. Its not ideal, but if you have any better idea about that, you are welc=
ome.<br>
<br></div>For me, adding the indexing possibility to structs is not the sam=
e than adding the access by name on tuples. The difference resides in the f=
act that a struct have itself a name. If you define a second struct with th=
e same attributes (name and types), they would not be copyable are movable =
between each other. In the "named tuples" version, they are, beca=
use the type is defined by its very content, and not by a name.<br>
<div><div><div><br><br></div></div></div></div><div class=3D"gmail_extra"><=
br><br><div class=3D"gmail_quote">On Sun, May 18, 2014 at 2:12 AM, G M <spa=
n dir=3D"ltr"><<a href=3D"mailto:gmisocpp@gmail.com" target=3D"_blank">g=
misocpp@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"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>Forget the example=C2=A0from that last post=
, I hit enter way too early.</div>
<div><br></div><div>But the=C2=A0basic=C2=A0idea was to imagine get<n>=
; worked on any type as bengt first posted, then imagine=C2=A0if=C2=A0lambd=
a captures=C2=A0could exist without=C2=A0their function and=C2=A0see how=C2=
=A0useful that is.=C2=A0Does=C2=A0that start to create a toolbox that compa=
res to a tuple or solve any problems that tuple is being used for today;=C2=
=A0or is it useful in it's=C2=A0own right?</div>
<div><br></div><div><div>Bengt's=C2=A0comment about accessing any type =
by=C2=A0number at compile time then begs the opposite desire of getting at =
any=C2=A0member of any=C2=A0object at runtime by name</div><div><br></div><=
/div><div>Forgive me if I'm wrong, but It seems to me this whole tuple =
thing is not really just about accessing an element by name or number at co=
mpile time, but=C2=A0it will be a lead in to a=C2=A0very database-like=C2=
=A0feature that=C2=A0might benefit from being examined in that context -=C2=
=A0of libraries like linkq etc., in=C2=A0memory databases etc,=C2=A0accessi=
ng an entity=C2=A0by name and number=C2=A0not just at compile time=C2=A0but=
at runtime; dynamic=C2=A0vs static and querying=C2=A0abilities to create=
=C2=A0shapes and types.</div>
<div><br></div><div>Language constructs that work together to allow that se=
em to be the eventual evolution destination and for solving those kinds of =
problems. Just adding a=C2=A0compile time name isn't doing much for us =
(at least me), I think.</div>
<div><br></div><div>People are going to want dynamic_tuple, hybrid_tuple an=
d "just let my object behave like a tuple" and more creative ways=
of creating a tuple than just make tuple,=C2=A0e.g. select.</div><div><br>
</div>
<div>Is there any=C2=A0truth to this point of view?</div></div></div></div>=
<div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <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/N-kIXNrkTUk/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/N-kIXNrkTUk=
/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@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--089e013a1180d0076d04f9b2c09b--
.
Author: Jean-Bernard Jansen <jeanbernard.jansen@gmail.com>
Date: Sun, 13 Jul 2014 17:34:36 +0200
Raw View
--089e013d0502ac341304fe14ea83
Content-Type: text/plain; charset=UTF-8
Hello guys
This post will sure be of interest to @German Diago. I drastically improved
my named tuple prototype since the last time. Changes includes:
- More generic API, easier to use.
- New internal storage method : base on a std::stuple instead of a
recursive class hierachy, allowing for nice and fast interactions with
std::tuple.
- The hash collision problem has been solved : if two members happen to
have the same id, name or hash, the compilation will fail.
- Smaller code, easier to read.
Enjoy code and examples here: https://github.com/duckie/named_tuple.
Regards
On Sun, May 18, 2014 at 10:47 PM, Jean-Bernard Jansen <
jeanbernard.jansen@gmail.com> wrote:
> Hello all
>
> @GM I think your point of view is quite valuable. I am wondering about the
> way to implement runtime introspection over the existing compile time
> introspection. That would be nice but must be an opt-in since it has a cost
> over single structs or tuples.
>
> @German Diago Collisions are not a problem if you use the second method
> with the types. Collisions are NOT solved if you used the _h trick. I
> considered that attribute names in anonymous structures are often short and
> common, and collisions are unlikely. I cant find a way to cope with them,
> unless writing a test script that loops over a dictionary to find
> collisions in it, and in which you pick your attribute names from time to
> time. Its not ideal, but if you have any better idea about that, you are
> welcome.
>
> For me, adding the indexing possibility to structs is not the same than
> adding the access by name on tuples. The difference resides in the fact
> that a struct have itself a name. If you define a second struct with the
> same attributes (name and types), they would not be copyable are movable
> between each other. In the "named tuples" version, they are, because the
> type is defined by its very content, and not by a name.
>
>
>
>
> On Sun, May 18, 2014 at 2:12 AM, G M <gmisocpp@gmail.com> wrote:
>
>> Forget the example from that last post, I hit enter way too early.
>>
>> But the basic idea was to imagine get<n> worked on any type as bengt
>> first posted, then imagine if lambda captures could exist without their
>> function and see how useful that is. Does that start to create a toolbox
>> that compares to a tuple or solve any problems that tuple is being used for
>> today; or is it useful in it's own right?
>>
>> Bengt's comment about accessing any type by number at compile time then
>> begs the opposite desire of getting at any member of any object at runtime
>> by name
>>
>> Forgive me if I'm wrong, but It seems to me this whole tuple thing is not
>> really just about accessing an element by name or number at compile time,
>> but it will be a lead in to a very database-like feature that might benefit
>> from being examined in that context - of libraries like linkq etc.,
>> in memory databases etc, accessing an entity by name and number not just at
>> compile time but at runtime; dynamic vs static and querying abilities to
>> create shapes and types.
>>
>> Language constructs that work together to allow that seem to be the
>> eventual evolution destination and for solving those kinds of problems.
>> Just adding a compile time name isn't doing much for us (at least me), I
>> think.
>>
>> People are going to want dynamic_tuple, hybrid_tuple and "just let my
>> object behave like a tuple" and more creative ways of creating a tuple than
>> just make tuple, e.g. select.
>>
>> Is there any truth to this point of view?
>>
>> --
>>
>> ---
>> 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/N-kIXNrkTUk/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.
>> 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/.
--089e013d0502ac341304fe14ea83
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div><div>Hello guys<br><br></div=
>This post will sure be of interest to @German Diago. I drastically improve=
d my named tuple prototype since the last time. Changes includes:<br></div>
</div>- More generic API, easier to use.<br></div>- New internal storage me=
thod : base on a std::stuple instead of a recursive class hierachy, allowin=
g for nice and fast interactions with std::tuple.<br></div>- The hash colli=
sion problem has been solved : if two members happen to have the same id, n=
ame or hash, the compilation will fail.<br>
</div>- Smaller code, easier to read.<br><br></div>Enjoy code and examples =
here: <a href=3D"https://github.com/duckie/named_tuple">https://github.com/=
duckie/named_tuple</a>.<br><br>Regards<br><div><br><br><div><br><br><br>
<br>
<div><div><div><div><div><div><div><br><br></div></div></div></div></div></=
div></div></div></div></div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">On Sun, May 18, 2014 at 10:47 PM, Jean-Bernard Jansen <spa=
n dir=3D"ltr"><<a href=3D"mailto:jeanbernard.jansen@gmail.com" target=3D=
"_blank">jeanbernard.jansen@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"><div><div><div>Hello all<br=
><br></div>@GM I think your point of view is quite valuable. I am wondering=
about the way to implement runtime introspection over the existing compile=
time introspection. That would be nice but must be an opt-in since it has =
a cost over single structs or tuples.<br>
<br></div>@German Diago=C2=A0 Collisions are not a problem if you use the s=
econd method with the types. Collisions are NOT solved if you used the _h t=
rick. I considered that attribute names in anonymous structures are often s=
hort and common, and collisions are unlikely. I cant find a way to cope wit=
h them, unless writing a test script that loops over a dictionary to find c=
ollisions in it, and in which you pick your attribute names from time to ti=
me. Its not ideal, but if you have any better idea about that, you are welc=
ome.<br>
<br></div>For me, adding the indexing possibility to structs is not the sam=
e than adding the access by name on tuples. The difference resides in the f=
act that a struct have itself a name. If you define a second struct with th=
e same attributes (name and types), they would not be copyable are movable =
between each other. In the "named tuples" version, they are, beca=
use the type is defined by its very content, and not by a name.<br>
<div><div><div><br><br></div></div></div></div><div class=3D"HOEnZb"><div c=
lass=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">O=
n Sun, May 18, 2014 at 2:12 AM, G M <span dir=3D"ltr"><<a href=3D"mailto=
:gmisocpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>></span> wr=
ote:<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"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>Forget the example=C2=A0from that last post=
, I hit enter way too early.</div>
<div><br></div><div>But the=C2=A0basic=C2=A0idea was to imagine get<n>=
; worked on any type as bengt first posted, then imagine=C2=A0if=C2=A0lambd=
a captures=C2=A0could exist without=C2=A0their function and=C2=A0see how=C2=
=A0useful that is.=C2=A0Does=C2=A0that start to create a toolbox that compa=
res to a tuple or solve any problems that tuple is being used for today;=C2=
=A0or is it useful in it's=C2=A0own right?</div>
<div><br></div><div><div>Bengt's=C2=A0comment about accessing any type =
by=C2=A0number at compile time then begs the opposite desire of getting at =
any=C2=A0member of any=C2=A0object at runtime by name</div><div><br></div><=
/div><div>Forgive me if I'm wrong, but It seems to me this whole tuple =
thing is not really just about accessing an element by name or number at co=
mpile time, but=C2=A0it will be a lead in to a=C2=A0very database-like=C2=
=A0feature that=C2=A0might benefit from being examined in that context -=C2=
=A0of libraries like linkq etc., in=C2=A0memory databases etc,=C2=A0accessi=
ng an entity=C2=A0by name and number=C2=A0not just at compile time=C2=A0but=
at runtime; dynamic=C2=A0vs static and querying=C2=A0abilities to create=
=C2=A0shapes and types.</div>
<div><br></div><div>Language constructs that work together to allow that se=
em to be the eventual evolution destination and for solving those kinds of =
problems. Just adding a=C2=A0compile time name isn't doing much for us =
(at least me), I think.</div>
<div><br></div><div>People are going to want dynamic_tuple, hybrid_tuple an=
d "just let my object behave like a tuple" and more creative ways=
of creating a tuple than just make tuple,=C2=A0e.g. select.</div><div><br>
</div>
<div>Is there any=C2=A0truth to this point of view?</div></div></div></div>=
<div><div>
<p></p>
-- <br>
<br>
--- <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/N-kIXNrkTUk/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/N-kIXNrkTUk=
/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@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></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--089e013d0502ac341304fe14ea83--
.
Author: Gian Lorenzo Meocci <glmeocci@gmail.com>
Date: Sun, 13 Jul 2014 19:37:18 +0200
Raw View
--bcaec547c9e545586204fe16a0aa
Content-Type: text/plain; charset=UTF-8
Thanks for your work!
On 13 July 2014 17:34, Jean-Bernard Jansen <jeanbernard.jansen@gmail.com>
wrote:
> Hello guys
>
> This post will sure be of interest to @German Diago. I drastically
> improved my named tuple prototype since the last time. Changes includes:
> - More generic API, easier to use.
> - New internal storage method : base on a std::stuple instead of a
> recursive class hierachy, allowing for nice and fast interactions with
> std::tuple.
> - The hash collision problem has been solved : if two members happen to
> have the same id, name or hash, the compilation will fail.
> - Smaller code, easier to read.
>
> Enjoy code and examples here: https://github.com/duckie/named_tuple.
>
> Regards
>
>
>
>
>
>
>
>
>
>
> On Sun, May 18, 2014 at 10:47 PM, Jean-Bernard Jansen <
> jeanbernard.jansen@gmail.com> wrote:
>
>> Hello all
>>
>> @GM I think your point of view is quite valuable. I am wondering about
>> the way to implement runtime introspection over the existing compile time
>> introspection. That would be nice but must be an opt-in since it has a cost
>> over single structs or tuples.
>>
>> @German Diago Collisions are not a problem if you use the second method
>> with the types. Collisions are NOT solved if you used the _h trick. I
>> considered that attribute names in anonymous structures are often short and
>> common, and collisions are unlikely. I cant find a way to cope with them,
>> unless writing a test script that loops over a dictionary to find
>> collisions in it, and in which you pick your attribute names from time to
>> time. Its not ideal, but if you have any better idea about that, you are
>> welcome.
>>
>> For me, adding the indexing possibility to structs is not the same than
>> adding the access by name on tuples. The difference resides in the fact
>> that a struct have itself a name. If you define a second struct with the
>> same attributes (name and types), they would not be copyable are movable
>> between each other. In the "named tuples" version, they are, because the
>> type is defined by its very content, and not by a name.
>>
>>
>>
>>
>> On Sun, May 18, 2014 at 2:12 AM, G M <gmisocpp@gmail.com> wrote:
>>
>>> Forget the example from that last post, I hit enter way too early.
>>>
>>> But the basic idea was to imagine get<n> worked on any type as bengt
>>> first posted, then imagine if lambda captures could exist without their
>>> function and see how useful that is. Does that start to create a toolbox
>>> that compares to a tuple or solve any problems that tuple is being used for
>>> today; or is it useful in it's own right?
>>>
>>> Bengt's comment about accessing any type by number at compile time then
>>> begs the opposite desire of getting at any member of any object at runtime
>>> by name
>>>
>>> Forgive me if I'm wrong, but It seems to me this whole tuple thing is
>>> not really just about accessing an element by name or number at compile
>>> time, but it will be a lead in to a very database-like feature that might
>>> benefit from being examined in that context - of libraries like linkq etc.,
>>> in memory databases etc, accessing an entity by name and number not just at
>>> compile time but at runtime; dynamic vs static and querying abilities to
>>> create shapes and types.
>>>
>>> Language constructs that work together to allow that seem to be the
>>> eventual evolution destination and for solving those kinds of problems.
>>> Just adding a compile time name isn't doing much for us (at least me), I
>>> think.
>>>
>>> People are going to want dynamic_tuple, hybrid_tuple and "just let my
>>> object behave like a tuple" and more creative ways of creating a tuple than
>>> just make tuple, e.g. select.
>>>
>>> Is there any truth to this point of view?
>>>
>>> --
>>>
>>> ---
>>> 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/N-kIXNrkTUk/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.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>
> --
>
> ---
> 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/N-kIXNrkTUk/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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
GL
http://www.meocci.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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--bcaec547c9e545586204fe16a0aa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks for your work!<br></div><div class=3D"gmail_extra">=
<br><br><div class=3D"gmail_quote">On 13 July 2014 17:34, Jean-Bernard Jans=
en <span dir=3D"ltr"><<a href=3D"mailto:jeanbernard.jansen@gmail.com" ta=
rget=3D"_blank">jeanbernard.jansen@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"><div><div><div><div><div><d=
iv><div>Hello guys<br><br></div>This post will sure be of interest to @Germ=
an Diago. I drastically improved my named tuple prototype since the last ti=
me. Changes includes:<br>
</div>
</div>- More generic API, easier to use.<br></div>- New internal storage me=
thod : base on a std::stuple instead of a recursive class hierachy, allowin=
g for nice and fast interactions with std::tuple.<br></div>- The hash colli=
sion problem has been solved : if two members happen to have the same id, n=
ame or hash, the compilation will fail.<br>
</div>- Smaller code, easier to read.<br><br></div>Enjoy code and examples =
here: <a href=3D"https://github.com/duckie/named_tuple" target=3D"_blank">h=
ttps://github.com/duckie/named_tuple</a>.<br><br>Regards<br><div><br><br><d=
iv>
<br><br><br>
<br>
<div><div><div><div><div><div><div><br><br></div></div></div></div></div></=
div></div></div></div></div><div class=3D"HOEnZb"><div class=3D"h5"><div cl=
ass=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, May 18, 2014=
at 10:47 PM, Jean-Bernard Jansen <span dir=3D"ltr"><<a href=3D"mailto:j=
eanbernard.jansen@gmail.com" target=3D"_blank">jeanbernard.jansen@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"><div><div><div>Hello all<br=
><br></div>@GM I think your point of view is quite valuable. I am wondering=
about the way to implement runtime introspection over the existing compile=
time introspection. That would be nice but must be an opt-in since it has =
a cost over single structs or tuples.<br>
<br></div>@German Diago=C2=A0 Collisions are not a problem if you use the s=
econd method with the types. Collisions are NOT solved if you used the _h t=
rick. I considered that attribute names in anonymous structures are often s=
hort and common, and collisions are unlikely. I cant find a way to cope wit=
h them, unless writing a test script that loops over a dictionary to find c=
ollisions in it, and in which you pick your attribute names from time to ti=
me. Its not ideal, but if you have any better idea about that, you are welc=
ome.<br>
<br></div>For me, adding the indexing possibility to structs is not the sam=
e than adding the access by name on tuples. The difference resides in the f=
act that a struct have itself a name. If you define a second struct with th=
e same attributes (name and types), they would not be copyable are movable =
between each other. In the "named tuples" version, they are, beca=
use the type is defined by its very content, and not by a name.<br>
<div><div><div><br><br></div></div></div></div><div><div><div class=3D"gmai=
l_extra"><br><br><div class=3D"gmail_quote">On Sun, May 18, 2014 at 2:12 AM=
, G M <span dir=3D"ltr"><<a href=3D"mailto:gmisocpp@gmail.com" target=3D=
"_blank">gmisocpp@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"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>Forget the example=C2=A0from that last post=
, I hit enter way too early.</div>
<div><br></div><div>But the=C2=A0basic=C2=A0idea was to imagine get<n>=
; worked on any type as bengt first posted, then imagine=C2=A0if=C2=A0lambd=
a captures=C2=A0could exist without=C2=A0their function and=C2=A0see how=C2=
=A0useful that is.=C2=A0Does=C2=A0that start to create a toolbox that compa=
res to a tuple or solve any problems that tuple is being used for today;=C2=
=A0or is it useful in it's=C2=A0own right?</div>
<div><br></div><div><div>Bengt's=C2=A0comment about accessing any type =
by=C2=A0number at compile time then begs the opposite desire of getting at =
any=C2=A0member of any=C2=A0object at runtime by name</div><div><br></div><=
/div><div>Forgive me if I'm wrong, but It seems to me this whole tuple =
thing is not really just about accessing an element by name or number at co=
mpile time, but=C2=A0it will be a lead in to a=C2=A0very database-like=C2=
=A0feature that=C2=A0might benefit from being examined in that context -=C2=
=A0of libraries like linkq etc., in=C2=A0memory databases etc,=C2=A0accessi=
ng an entity=C2=A0by name and number=C2=A0not just at compile time=C2=A0but=
at runtime; dynamic=C2=A0vs static and querying=C2=A0abilities to create=
=C2=A0shapes and types.</div>
<div><br></div><div>Language constructs that work together to allow that se=
em to be the eventual evolution destination and for solving those kinds of =
problems. Just adding a=C2=A0compile time name isn't doing much for us =
(at least me), I think.</div>
<div><br></div><div>People are going to want dynamic_tuple, hybrid_tuple an=
d "just let my object behave like a tuple" and more creative ways=
of creating a tuple than just make tuple,=C2=A0e.g. select.</div><div><br>
</div>
<div>Is there any=C2=A0truth to this point of view?</div></div></div></div>=
<div><div>
<p></p>
-- <br>
<br>
--- <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/N-kIXNrkTUk/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/N-kIXNrkTUk=
/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@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></div></blockquote></div><br></div>
<p></p>
-- <br>
<br>
--- <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/N-kIXNrkTUk/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/N-kIXNrkTUk=
/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@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>GL<br><a hr=
ef=3D"http://www.meocci.it" target=3D"_blank">http://www.meocci.it</a>
</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 />
--bcaec547c9e545586204fe16a0aa--
.
Author: german.gomez@personifyinc.com
Date: Mon, 14 Jul 2014 06:22:40 -0700 (PDT)
Raw View
------=_Part_2023_7102288.1405344161040
Content-Type: text/plain; charset=UTF-8
Great! Will take a look.
>
> This post will sure be of interest to @German Diago. I drastically
> improved my named tuple prototype since the last time. Changes includes:
> - More generic API, easier to use.
> - New internal storage method : base on a std::stuple instead of a
> recursive class hierachy, allowing for nice and fast interactions with
> std::tuple.
> - The hash collision problem has been solved : if two members happen to
> have the same id, name or hash, the compilation will fail.
> - Smaller code, easier to read.
>
>
>
>
>
>
>
> On Sun, May 18, 2014 at 10:47 PM, Jean-Bernard Jansen <
> jeanberna...@gmail.com <javascript:>> wrote:
>
>> Hello all
>>
>> @GM I think your point of view is quite valuable. I am wondering about
>> the way to implement runtime introspection over the existing compile time
>> introspection. That would be nice but must be an opt-in since it has a cost
>> over single structs or tuples.
>>
>> @German Diago Collisions are not a problem if you use the second method
>> with the types. Collisions are NOT solved if you used the _h trick. I
>> considered that attribute names in anonymous structures are often short and
>> common, and collisions are unlikely. I cant find a way to cope with them,
>> unless writing a test script that loops over a dictionary to find
>> collisions in it, and in which you pick your attribute names from time to
>> time. Its not ideal, but if you have any better idea about that, you are
>> welcome.
>>
>> For me, adding the indexing possibility to structs is not the same than
>> adding the access by name on tuples. The difference resides in the fact
>> that a struct have itself a name. If you define a second struct with the
>> same attributes (name and types), they would not be copyable are movable
>> between each other. In the "named tuples" version, they are, because the
>> type is defined by its very content, and not by a name.
>>
>>
>>
>>
>> On Sun, May 18, 2014 at 2:12 AM, G M <gmis...@gmail.com <javascript:>>
>> wrote:
>>
>>> Forget the example from that last post, I hit enter way too early.
>>>
>>> But the basic idea was to imagine get<n> worked on any type as bengt
>>> first posted, then imagine if lambda captures could exist without their
>>> function and see how useful that is. Does that start to create a toolbox
>>> that compares to a tuple or solve any problems that tuple is being used for
>>> today; or is it useful in it's own right?
>>>
>>> Bengt's comment about accessing any type by number at compile time then
>>> begs the opposite desire of getting at any member of any object at runtime
>>> by name
>>>
>>> Forgive me if I'm wrong, but It seems to me this whole tuple thing is
>>> not really just about accessing an element by name or number at compile
>>> time, but it will be a lead in to a very database-like feature that might
>>> benefit from being examined in that context - of libraries like linkq etc.,
>>> in memory databases etc, accessing an entity by name and number not just at
>>> compile time but at runtime; dynamic vs static and querying abilities to
>>> create shapes and types.
>>>
>>> Language constructs that work together to allow that seem to be the
>>> eventual evolution destination and for solving those kinds of problems.
>>> Just adding a compile time name isn't doing much for us (at least me), I
>>> think.
>>>
>>> People are going to want dynamic_tuple, hybrid_tuple and "just let my
>>> object behave like a tuple" and more creative ways of creating a tuple than
>>> just make tuple, e.g. select.
>>>
>>> Is there any truth to this point of view?
>>>
>>> --
>>>
>>> ---
>>> 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/N-kIXNrkTUk/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to
>>> std-proposal...@isocpp.org <javascript:>.
>>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>>> 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/.
------=_Part_2023_7102288.1405344161040
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Great! Will take a look.<br><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div><div><div><div><div><div><div><br></di=
v>This post will sure be of interest to @German Diago. I drastically improv=
ed my named tuple prototype since the last time. Changes includes:<br></div=
>
</div>- More generic API, easier to use.<br></div>- New internal storage me=
thod : base on a std::stuple instead of a recursive class hierachy, allowin=
g for nice and fast interactions with std::tuple.<br></div>- The hash colli=
sion problem has been solved : if two members happen to have the same id, n=
ame or hash, the compilation will fail.<br>
</div>- Smaller code, easier to read.<br><br></div><div><div><br>
<br>
<div><div><div><div><div><div><div><br><br></div></div></div></div></div></=
div></div></div></div></div><div><br><br><div class=3D"gmail_quote">On Sun,=
May 18, 2014 at 10:47 PM, Jean-Bernard Jansen <span dir=3D"ltr"><<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"NZET-diKmG0J" =
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">jeanberna...@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"><div><div><div>Hello all<br=
><br></div>@GM I think your point of view is quite valuable. I am wondering=
about the way to implement runtime introspection over the existing compile=
time introspection. That would be nice but must be an opt-in since it has =
a cost over single structs or tuples.<br>
<br></div>@German Diago Collisions are not a problem if you use the s=
econd method with the types. Collisions are NOT solved if you used the _h t=
rick. I considered that attribute names in anonymous structures are often s=
hort and common, and collisions are unlikely. I cant find a way to cope wit=
h them, unless writing a test script that loops over a dictionary to find c=
ollisions in it, and in which you pick your attribute names from time to ti=
me. Its not ideal, but if you have any better idea about that, you are welc=
ome.<br>
<br></div>For me, adding the indexing possibility to structs is not the sam=
e than adding the access by name on tuples. The difference resides in the f=
act that a struct have itself a name. If you define a second struct with th=
e same attributes (name and types), they would not be copyable are movable =
between each other. In the "named tuples" version, they are, because the ty=
pe is defined by its very content, and not by a name.<br>
<div><div><div><br><br></div></div></div></div><div><div><div><br><br><div =
class=3D"gmail_quote">On Sun, May 18, 2014 at 2:12 AM, G M <span dir=3D"ltr=
"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"NZ=
ET-diKmG0J" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">gmis...@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"><div><div class=3D"gmail_qu=
ote"><div>Forget the example from that last post, I hit enter way too =
early.</div>
<div><br></div><div>But the basic idea was to imagine get<n>=
; worked on any type as bengt first posted, then imagine if lambd=
a captures could exist without their function and see how&nb=
sp;useful that is. Does that start to create a toolbox that compa=
res to a tuple or solve any problems that tuple is being used for today;&nb=
sp;or is it useful in it's own right?</div>
<div><br></div><div><div>Bengt's comment about accessing any type by&n=
bsp;number at compile time then begs the opposite desire of getting at any&=
nbsp;member of any object at runtime by name</div><div><br></div></div=
><div>Forgive me if I'm wrong, but It seems to me this whole tuple thing is=
not really just about accessing an element by name or number at compile ti=
me, but it will be a lead in to a very database-like feature=
that might benefit from being examined in that context - of libr=
aries like linkq etc., in memory databases etc, accessing an enti=
ty by name and number not just at compile time but at runtim=
e; dynamic vs static and querying abilities to create shapes=
and types.</div>
<div><br></div><div>Language constructs that work together to allow that se=
em to be the eventual evolution destination and for solving those kinds of =
problems. Just adding a compile time name isn't doing much for us (at =
least me), I think.</div>
<div><br></div><div>People are going to want dynamic_tuple, hybrid_tuple an=
d "just let my object behave like a tuple" and more creative ways of creati=
ng a tuple than just make tuple, e.g. select.</div><div><br>
</div>
<div>Is there any truth to this point of view?</div></div></div></div>=
<div><div>
<p></p>
-- <br>
<br>
--- <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/N-kIXNrkTUk/unsubscribe" target=3D"_blan=
k" onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/top=
ic/std-proposals/N-kIXNrkTUk/unsubscribe';return true;" onclick=3D"this.hre=
f=3D'https://groups.google.com/a/isocpp.org/d/topic/std-proposals/N-kIXNrkT=
Uk/unsubscribe';return true;">https://groups.google.com/a/<wbr>isocpp.org/d=
/topic/std-<wbr>proposals/N-kIXNrkTUk/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"NZET-diKmG0J" o=
nmousedown=3D"this.href=3D'javascript:';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"NZET-diKmG0J" 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>
</div></div></blockquote></div><br></div>
</div></div></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 <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_2023_7102288.1405344161040--
.
Author: athundt@gmail.com
Date: Wed, 16 Jul 2014 13:57:24 -0700 (PDT)
Raw View
------=_Part_994_32397359.1405544244337
Content-Type: text/plain; charset=UTF-8
On Thursday, April 10, 2014 6:28:07 AM UTC-4, Thibaut Lutz wrote:
>
> Here is a simple example to illustrate what I would like to achieve:
>
> // example of named template type definition
> typedef Container <char R, char G, char B, char A> ImageType;
>
> // instantiation: creates 800x600 elements, without knowing the memory
> layout, could be
> // struct {char R, G, B, A; } image[800*600]; or
> // struct {char R, G, B, A; } image[800][600]; or
> // struct {char R[800*600], G[800*600], B[800*600], A[800*600]; } image;
> // etc...
> ImageType image({800,600});
>
> // Getting and setting element works regardless of the layout using the
> field name
> image.get<ImageType::A>({0,0}) = 0;
>
>
I've been searching for the same thing when I came across this thread and
this syntax looks pretty nice, although a sampling of others would be worth
consideration as well. Any syntax would need to fit well with the existing
constraints of C++, but the current std::tuple design specifying integers
to access tuple indices really does result in unmaintainable code. I tried
using them more extensively on my projects and from my experience it
eventually created confusion for me and other developers, particularly when
there are several fields of the same type. Some solution with better syntax
and names for tuple indices would be ideal.
Perhaps this would all become moot with compile time reflection? If
metaprogramming could be performed on simple structs then perhaps the
problem would be solved. On the other hand named tuples may still be
valuable even with compile time reflection because it would be a good
mechanism for[ inline object definition with named members.
--
---
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_994_32397359.1405544244337
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Thursday, April 10, 2014 6:28:07 AM UTC-4, Thibaut =
Lutz 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"><d=
iv>Here is a simple example to illustrate what I would like to achieve:</di=
v><div><br></div><div><div style=3D"background-color:rgb(250,250,250);borde=
r:1px solid rgb(187,187,187);word-wrap:break-word"><code><div><span style=
=3D"color:#800">// example of named template type definition</span><span st=
yle=3D"color:#000"><br></span><span style=3D"color:#008">typedef</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#606">Container</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660"><</span><sp=
an style=3D"color:#008">char</span><span style=3D"color:#000"> R</span><spa=
n style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#008">char</span><span style=3D"color:#000"> G</span><span styl=
e=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"=
color:#008">char</span><span style=3D"color:#000"> B</span><span style=3D"c=
olor:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:=
#008">char</span><span style=3D"color:#000"> A</span><span style=3D"color:#=
660">></span><span style=3D"color:#000"> </span><span style=3D"color:#60=
6">ImageType</span><span style=3D"color:#660">;</span><span style=3D"color:=
#000"><br><br></span><span style=3D"color:#800">// instantiation: creates 8=
00x600 elements, without knowing the memory layout, could be</span><span st=
yle=3D"color:#000"><br></span><span style=3D"color:#800">// struct {char R,=
G, B, A; } image[800*600]; or</span><span style=3D"color:#000"><br></span>=
<span style=3D"color:#800">// struct {char R, G, B, A; } image[800][600]; o=
r</span><span style=3D"color:#000"><br></span><span style=3D"color:#800">//=
struct {char R[800*600], G[800*600], B[800*600], A[800*600]; } image; </sp=
an><span style=3D"color:#000"><br></span><span style=3D"color:#800">// etc.=
...</span><span style=3D"color:#000"><br></span><span style=3D"color:#606">I=
mageType</span><span style=3D"color:#000"> image</span><span style=3D"color=
:#660">({</span><span style=3D"color:#066">800</span><span style=3D"color:#=
660">,</span><span style=3D"color:#066">600</span><span style=3D"color:#660=
">});</span><span style=3D"color:#000"><br><br></span><span style=3D"color:=
#800">// Getting and setting element works regardless of the layout using t=
he field name</span><span style=3D"color:#000"><br>image</span><span style=
=3D"color:#660">.</span><span style=3D"color:#008">get</span><span style=3D=
"color:#660"><</span><span style=3D"color:#606">ImageType</span><span st=
yle=3D"color:#660">::</span><span style=3D"color:#000">A</span><span style=
=3D"color:#660">>({</span><span style=3D"color:#066">0</span><span style=
=3D"color:#660">,</span><span style=3D"color:#066">0</span><span style=3D"c=
olor:#660">})</span><span style=3D"color:#000"> </span><span style=3D"color=
:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#0=
66">0</span><span style=3D"color:#660">;</span></div></code></div><div styl=
e=3D"font-family:Arial,Helvetica,sans-serif;background-color:rgb(255,255,25=
5)"><br></div></div></div></blockquote><div><br></div><div><br></div><div>I=
've been searching for the same thing when I came across this thread and th=
is syntax looks pretty nice, although a sampling of others would be worth c=
onsideration as well. Any syntax would need to fit well with the existing c=
onstraints of C++, but the current std::tuple design specifying integers to=
access tuple indices really does result in unmaintainable code. I tried us=
ing them more extensively on my projects and from my experience it eventual=
ly created confusion for me and other developers, particularly when there a=
re several fields of the same type. Some solution with better syntax and na=
mes for tuple indices would be ideal. </div><div><br></div><div>Perhap=
s this would all become moot with compile time reflection? If metaprogrammi=
ng could be performed on simple structs then perhaps the problem would be s=
olved. On the other hand named tuples may still be valuable even with compi=
le time reflection because it would be a good mechanism for[ inline object =
definition with named members.</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 <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_994_32397359.1405544244337--
.