Topic: C++ named tuple - attribute_key
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 09 May 2015 18:54:04 +0200
Raw View
This is a multi-part message in MIME format.
--------------000006040803090909080405
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 13/07/14 17:34, Jean-Bernard Jansen a =C3=A9crit :
> Hello guys
>
> This post will sure be of interest to @German Diago. I drastically=20
> 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=20
> recursive class hierachy, allowing for nice and fast interactions with=20
> std::tuple.
> - The hash collision problem has been solved : if two members happen=20
> 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.
>
>
Hi,
even if this is an old post, I find this library quite interesting.
I like a lot
* the function syntax to identify the attribute holder int(age),
I like, but less
* the named parameter syntax _<name> =3D val
* the selector syntax tuple. _<name>
Just wondering if you could add in addition to attributes_holder,=20
attributes_key. An attribute_key instance could have a name.
E.g.
constexpr struct name_t : attribute_key<name_t> {} name;
This could help to replace _<name>=3Dval by *name=3Dval*.
template <class Id, class T>
auto attribute_key<Id>::operator=3D(attibute_key<Id>, T val) {return=20
attribute_helper::_<Id>=3Dval; }
The member _ could also be overloaded with attribute_key<name_t>=20
*tpl._(name).*
template <class Id>
auto named_tuple::_(attibute_key<Id>) {return attribute_helper::_<Id>(); }
or the operator() *tpl(name).*
Alternatively an overload for the operator% on tuple and=20
attribute_key<name> *tpl%name*.
template <class NamedTuple, class Id>
auto operator%(NamedTuple const& tpl, attibute_key<Id>) {return=20
tpl._<Id>(); }
Last the attribute_key could be seen as a key selector function *name(tml)*=
..
template <class NamedTuple>
auto attibute_key<Id>::operator()(NamedTuple const& tpl) {return=20
tpl._<Id>(); }
The following example
namespace {
struct name;
struct age;
struct taille;
struct liste;
}
int main() {
auto test =3D make_named_tuple(
_<name>() =3D std::string("Roger")
, _<age>() =3D 47
, _<taille>() =3D 1.92
, _<liste>() =3D std::vector<int>({1,2,3})
);
std::cout
<< test._<name>() << "\n"
<< test._<age>() << "\n"
<< test._<taille>() << "\n"
<< test._<liste>().size() << std::endl;
could be transformed using the new attribute_key as follows
namespace {
constexpr struct name_t : attribute_key<name_t> {} name;
constexpr struct age_t : attribute_key<age_t> {} age;
constexpr struct taille_t : attribute_key<taille_t> {} taille;
constexpr struct liste_t : attribute_key<liste_t> {} liste;
}
int main() {
// No need to use the artificial _<name> =3D, name =3Dis enough
auto test =3D make_named_tuple(
name =3D std::string("Roger")
, age =3D 47
, taille =3D 1.92
, liste =3D std::vector<int>({1,2,3})
);
// However, here we need the type, name_t :(
std::cout
<< test._<name_t>() << "\n"
<< test._<age_t>() << "\n"
<< test._<taille_t>() << "\n"
<< test._<liste_t>().size() << std::endl;
// making use of overloaded member _
std::cout
<< test._(name) << "\n"
<< test._(age) << "\n"
<< test._(taille) << "\n"
<< test._(liste_t).size() << std::endl;
// making use of overloaded member operator()
std::cout
<< test(name) << "\n"
<< test(age) << "\n"
<< test(taille) << "\n"
<< test(liste_t).size() << std::endl;
// Using the operator tuple % attribute_key
std::cout
<< test%name << "\n"
<< test%age << "\n"
<< test%taille << "\n"
<< (test%liste_t).size() << std::endl;
// Using the attribute_key operator ()
std::cout
<< name(test) << "\n"
<< age(test) << "\n"
<< taille(test) << "\n"
<< liste(test).size() << std::endl;
}
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/.
--------------000006040803090909080405
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 13/07/14 17:34, Jean-Bernard Jansen
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CALoNf_VL8L7R+=3DmuvdtJybh3eHfhKqMC2uQj5L+Jcxs6F__YVg@mail.gmai=
l.com"
type=3D"cite">
<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 improved my named tuple prototype
since the last time. Changes includes:<br>
</div>
</div>
- More generic API, easier to use.<br>
</div>
- New internal storage method : base on a std::stuple
instead of a recursive class hierachy, allowing for nice
and fast interactions with std::tuple.<br>
</div>
- The hash collision problem has been solved : if two
members happen to have the same id, name or hash, the
compilation will fail.<br>
</div>
- Smaller code, easier to read.<br>
<br>
</div>
Enjoy code and examples here: <a moz-do-not-send=3D"true"
href=3D"https://github.com/duckie/named_tuple">https://github.com=
/duckie/named_tuple</a>.<br>
<br>
<br>
</div>
</blockquote>
Hi,<br>
<br>
even if this is=C2=A0 an old post, I find this library quite interestin=
g.<br>
<br>
I like a lot<br>
* the function syntax to identify the attribute holder int(age),<br>
<br>
I like, but less<br>
* the named parameter syntax _<name> =3D val<br>
* the selector syntax tuple. _<name><br>
<br>
Just wondering if you could add in addition to attributes_holder,
attributes_key. An attribute_key instance could have a name.<br>
=C2=A0E.g.<br>
<br>
=C2=A0=C2=A0=C2=A0 constexpr struct name_t : attribute_key<name_t>=
; {} name;<br>
<br>
<br>
This could help to replace _<name>=3Dval by=C2=A0 <b>name=3Dval</=
b>.<br>
<br>
template <class Id, class T><br>
auto attribute_key<Id>::operator=3D(attibute_key<Id>, T
val) {return attribute_helper::_<Id>=3Dval; }<br>
<br>
The member _ could also be overloaded with
attribute_key<name_t> <b>tpl._(name).</b><br>
<br>
template <class Id><br>
auto named_tuple::_(attibute_key<Id>) {return
attribute_helper::_<Id>(); }<br>
<br>
or the operator() <b>tpl(name).</b><br>
<br>
Alternatively an overload for the operator% on tuple and
attribute_key<name> <b>tpl%name</b>.<br>
<br>
template <class NamedTuple, class Id><br>
auto operator%(NamedTuple const& tpl, attibute_key<Id>)
{return tpl._<Id>(); }<br>
<br>
Last the attribute_key could be seen as a key selector function <b>name=
(tml)</b>.<br>
<br>
template <class NamedTuple><br>
auto attibute_key<Id>::operator()(NamedTuple const& tpl)
{return tpl._<Id>(); }<br>
<br>
<br>
The following example<br>
<br>
namespace {<br>
struct name;<br>
struct age;<br>
struct taille;<br>
struct liste;<br>
}<br>
<br>
int main() {<br>
=C2=A0 auto test =3D make_named_tuple(<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _<name>() =3D std::string("Roger")=
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _<age>() =3D 47<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _<taille>() =3D 1.92<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _<liste>() =3D std::vector<in=
t>({1,2,3})<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<br>
<br>
=C2=A0 std::cout<br>
=C2=A0=C2=A0=C2=A0 << test._<name>() << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test._<age>() << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test._<taille>() << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test._<liste>().size() << std::=
endl;<br>
<br>
<br>
could be transformed using the new attribute_key as follows<br>
<br>
namespace {<br>
=C2=A0=C2=A0=C2=A0 constexpr struct name_t : attribute_key<name_t>=
; {} name;<br>
=C2=A0=C2=A0=C2=A0 constexpr struct age_t : attribute_key<age_t> =
{} age;<br>
=C2=A0=C2=A0=C2=A0 constexpr struct taille_t : attribute_key<taille_=
t> {}
taille;<br>
=C2=A0=C2=A0=C2=A0 constexpr struct liste_t : attribute_key<liste_t&=
gt; {}
liste;<br>
}<br>
<br>
int main() {<br>
<br>
// No need to use the artificial _<name> =3D, name =3Dis enough<b=
r>
<br>
=C2=A0 auto test =3D make_named_tuple(<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 name =3D std::string("Roger"=
)<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , age =3D 47<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , taille =3D 1.92<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , liste =3D std::vector<int>({1,2,=
3})<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<br>
<br>
// However, here we need the type, name_t :(<br>
<br>
=C2=A0 std::cout<br>
=C2=A0=C2=A0=C2=A0 << test._<name_t>() << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test._<age_t>() << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test._<taille_t>() << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test._<liste_t>().size() << std=
::endl;<br>
<br>
// making use of overloaded member _<br>
=C2=A0 std::cout<br>
=C2=A0=C2=A0=C2=A0 << test._(name) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test._(age) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test._(taille) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test._(liste_t).size() << std::endl;<=
br>
<br>
// making use of overloaded member operator()<br>
=C2=A0 std::cout<br>
=C2=A0=C2=A0=C2=A0 << test(name) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test(age) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test(taille) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test(liste_t).size() << std::endl;<br=
>
<br>
// Using the operator tuple % attribute_key<br>
<br>
=C2=A0 std::cout<br>
=C2=A0=C2=A0=C2=A0 << test%name << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test%age << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test%taille << "\n"<br>
=C2=A0=C2=A0=C2=A0 << (test%liste_t).size() << std::endl;<b=
r>
<br>
// Using the attribute_key operator ()<br>
<br>
=C2=A0 std::cout<br>
=C2=A0=C2=A0=C2=A0 << name(test) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << age(test) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << taille(test) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << liste(test).size() << std::endl;<br>
<br>
}<br>
<br>
Vicente<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 />
--------------000006040803090909080405--
.
Author: Jean-Bernard Jansen <jeanbernard.jansen@gmail.com>
Date: Mon, 11 May 2015 12:47:31 +0200
Raw View
--f46d044281000cb7300515cc1cf6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hello Vicente
Thank you very much for your interest about this work.
What you propose is actually doable, and is quite similar to what we can
found in this project <https://github.com/matt-42/iod>, which basically
does the same thing. I am a little bit reluctant to add this feature for a
very particular reason. Using static instances as you propose adds a
problem : you have static symbols to manage, thus leading to potential
conflicts between different compilation units. Those problems can be solved
but extra care about them is needed. For instance, you used an anonymous
namespace. It works, but duplicates every static instance in every
compilation unit using them. This adds unused data in the resulting
compiled code. When using declared (but NOT defined) types, no extra data
is added.
The main point of my particular implementation is to avoid static instances
as much as possible (cannot be avoided when you want to use runtime
introspection, obviously). This allows to use a syntax with wich you dont
even have to declare attribute names before using them.
auto test =3D make_named_tuple(
_<"nom"_h>() =3D std::string("Roger")
, _<"age"_h>() =3D 47
, _<"taille"_h>() =3D 1.92
, _<"liste"_h>() =3D std::vector<int>({1,2,3})
);
What is your opinion on this point ? My mind is always open to changes, and
I do like the proposal about using key selector function to access members.
This really is elegant, I'll think about it.
Best regards
JB
On Sat, May 9, 2015 at 6:54 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Le 13/07/14 17:34, Jean-Bernard Jansen a =C3=A9crit :
>
> 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.
>
>
> Hi,
>
> even if this is an old post, I find this library quite interesting.
>
> I like a lot
> * the function syntax to identify the attribute holder int(age),
>
> I like, but less
> * the named parameter syntax _<name> =3D val
> * the selector syntax tuple. _<name>
>
> Just wondering if you could add in addition to attributes_holder,
> attributes_key. An attribute_key instance could have a name.
> E.g.
>
> constexpr struct name_t : attribute_key<name_t> {} name;
>
>
> This could help to replace _<name>=3Dval by *name=3Dval*.
>
> template <class Id, class T>
> auto attribute_key<Id>::operator=3D(attibute_key<Id>, T val) {return
> attribute_helper::_<Id>=3Dval; }
>
> The member _ could also be overloaded with attribute_key<name_t>
> *tpl._(name).*
>
> template <class Id>
> auto named_tuple::_(attibute_key<Id>) {return attribute_helper::_<Id>(); =
}
>
> or the operator() *tpl(name).*
>
> Alternatively an overload for the operator% on tuple and
> attribute_key<name> *tpl%name*.
>
> template <class NamedTuple, class Id>
> auto operator%(NamedTuple const& tpl, attibute_key<Id>) {return
> tpl._<Id>(); }
>
> Last the attribute_key could be seen as a key selector function
> *name(tml)*.
>
> template <class NamedTuple>
> auto attibute_key<Id>::operator()(NamedTuple const& tpl) {return
> tpl._<Id>(); }
>
>
> The following example
>
> namespace {
> struct name;
> struct age;
> struct taille;
> struct liste;
> }
>
> int main() {
> auto test =3D make_named_tuple(
> _<name>() =3D std::string("Roger")
> , _<age>() =3D 47
> , _<taille>() =3D 1.92
> , _<liste>() =3D std::vector<int>({1,2,3})
> );
>
> std::cout
> << test._<name>() << "\n"
> << test._<age>() << "\n"
> << test._<taille>() << "\n"
> << test._<liste>().size() << std::endl;
>
>
> could be transformed using the new attribute_key as follows
>
> namespace {
> constexpr struct name_t : attribute_key<name_t> {} name;
> constexpr struct age_t : attribute_key<age_t> {} age;
> constexpr struct taille_t : attribute_key<taille_t> {} taille;
> constexpr struct liste_t : attribute_key<liste_t> {} liste;
> }
>
> int main() {
>
> // No need to use the artificial _<name> =3D, name =3Dis enough
>
> auto test =3D make_named_tuple(
> name =3D std::string("Roger")
> , age =3D 47
> , taille =3D 1.92
> , liste =3D std::vector<int>({1,2,3})
> );
>
> // However, here we need the type, name_t :(
>
> std::cout
> << test._<name_t>() << "\n"
> << test._<age_t>() << "\n"
> << test._<taille_t>() << "\n"
> << test._<liste_t>().size() << std::endl;
>
> // making use of overloaded member _
> std::cout
> << test._(name) << "\n"
> << test._(age) << "\n"
> << test._(taille) << "\n"
> << test._(liste_t).size() << std::endl;
>
> // making use of overloaded member operator()
> std::cout
> << test(name) << "\n"
> << test(age) << "\n"
> << test(taille) << "\n"
> << test(liste_t).size() << std::endl;
>
> // Using the operator tuple % attribute_key
>
> std::cout
> << test%name << "\n"
> << test%age << "\n"
> << test%taille << "\n"
> << (test%liste_t).size() << std::endl;
>
> // Using the attribute_key operator ()
>
> std::cout
> << name(test) << "\n"
> << age(test) << "\n"
> << taille(test) << "\n"
> << liste(test).size() << std::endl;
>
> }
>
> Vicente
>
> --
>
> ---
> 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/.
>
--=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/.
--f46d044281000cb7300515cc1cf6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div>Hello Vicente<br></div><br></div>Thank=
you very much for your interest about this work.<br><br></div>What you pro=
pose is actually doable, and is quite similar to what we can found <a href=
=3D"https://github.com/matt-42/iod">in this project</a>, which basically do=
es the same thing. I am a little bit reluctant to add this feature for a ve=
ry particular reason. Using static instances as you propose adds a problem =
: you have static symbols to manage, thus leading to potential conflicts be=
tween different compilation units. Those problems can be solved but extra c=
are about them is needed. For instance, you used an anonymous namespace. It=
works, but duplicates every static instance in every compilation unit usin=
g them. This adds unused data in the resulting compiled code. When using de=
clared (but NOT defined) types, no extra data is added.<br><br></div><div>T=
he main point of my particular implementation is to avoid static instances =
as much as possible (cannot be avoided when you want to use runtime introsp=
ection, obviously). This allows to use a syntax with wich you dont even hav=
e to declare attribute names before using them.<br><br><br>auto test =3D ma=
ke_named_tuple( <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _<"nom"_h&g=
t;() =3D std::string("Roger")<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ,=
_<"age"_h>() =3D 47<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&=
lt;"taille"_h>() =3D 1.92<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , =
_<"liste"_h>() =3D std::vector<int>({1,2,3})<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<br><br></div><div>What is your opinion on th=
is point ? My mind is always open to changes, and I do like the proposal ab=
out using key selector function to access members. This really is elegant, =
I'll think about it.<br><br></div><div>Best regards<br></div><div>JB<br=
></div><div><br></div><div><br></div><div><br></div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Sat, May 9, 2015 at 6:54 PM, Vi=
cente J. Botet Escriba <span dir=3D"ltr"><<a href=3D"mailto:vicente.bote=
t@wanadoo.fr" target=3D"_blank">vicente.botet@wanadoo.fr</a>></span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 13/07/14 17:34, Jean-Bernard Jansen
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<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 improved my named tuple prototype
since the last time. Changes includes:<br>
</div>
</div>
- More generic API, easier to use.<br>
</div>
- New internal storage method : base on a std::stuple
instead of a recursive class hierachy, allowing for nice
and fast interactions with std::tuple.<br>
</div>
- The hash collision problem has been solved : if two
members happen to have the same id, name 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">https://github.com/duckie/named_tuple</a>.<b=
r>
<br>
<br>
</div>
</blockquote>
Hi,<br>
<br>
even if this is=C2=A0 an old post, I find this library quite interestin=
g.<br>
<br>
I like a lot<br>
* the function syntax to identify the attribute holder int(age),<br>
<br>
I like, but less<br>
* the named parameter syntax _<name> =3D val<br>
* the selector syntax tuple. _<name><br>
<br>
Just wondering if you could add in addition to attributes_holder,
attributes_key. An attribute_key instance could have a name.<br>
=C2=A0E.g.<br>
<br>
=C2=A0=C2=A0=C2=A0 constexpr struct name_t : attribute_key<name_t>=
; {} name;<br>
<br>
<br>
This could help to replace _<name>=3Dval by=C2=A0 <b>name=3Dval</=
b>.<br>
<br>
template <class Id, class T><br>
auto attribute_key<Id>::operator=3D(attibute_key<Id>, T
val) {return attribute_helper::_<Id>=3Dval; }<br>
<br>
The member _ could also be overloaded with
attribute_key<name_t> <b>tpl._(name).</b><br>
<br>
template <class Id><br>
auto named_tuple::_(attibute_key<Id>) {return
attribute_helper::_<Id>(); }<br>
<br>
or the operator() <b>tpl(name).</b><br>
<br>
Alternatively an overload for the operator% on tuple and
attribute_key<name> <b>tpl%name</b>.<br>
<br>
template <class NamedTuple, class Id><br>
auto operator%(NamedTuple const& tpl, attibute_key<Id>)
{return tpl._<Id>(); }<br>
<br>
Last the attribute_key could be seen as a key selector function <b>name=
(tml)</b>.<br>
<br>
template <class NamedTuple><br>
auto attibute_key<Id>::operator()(NamedTuple const& tpl)
{return tpl._<Id>(); }<br>
<br>
<br>
The following example<br>
<br>
namespace {<br>
struct name;<br>
struct age;<br>
struct taille;<br>
struct liste;<br>
}<br>
<br>
int main() {<br>
=C2=A0 auto test =3D make_named_tuple(<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _<name>() =3D std::string("Ro=
ger")<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _<age>() =3D 47<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _<taille>() =3D 1.92<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _<liste>() =3D std::vector<in=
t>({1,2,3})<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<br>
<br>
=C2=A0 std::cout<br>
=C2=A0=C2=A0=C2=A0 << test._<name>() << "\n"=
;<br>
=C2=A0=C2=A0=C2=A0 << test._<age>() << "\n"=
<br>
=C2=A0=C2=A0=C2=A0 << test._<taille>() << "\n&qu=
ot;<br>
=C2=A0=C2=A0=C2=A0 << test._<liste>().size() << std::=
endl;<br>
<br>
<br>
could be transformed using the new attribute_key as follows<br>
<br>
namespace {<br>
=C2=A0=C2=A0=C2=A0 constexpr struct name_t : attribute_key<name_t>=
; {} name;<br>
=C2=A0=C2=A0=C2=A0 constexpr struct age_t : attribute_key<age_t> =
{} age;<br>
=C2=A0=C2=A0=C2=A0 constexpr struct taille_t : attribute_key<taille_=
t> {}
taille;<br>
=C2=A0=C2=A0=C2=A0 constexpr struct liste_t : attribute_key<liste_t&=
gt; {}
liste;<br>
}<br>
<br>
int main() {<br>
<br>
// No need to use the artificial _<name> =3D, name =3Dis enough<b=
r>
<br>
=C2=A0 auto test =3D make_named_tuple(<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 name =3D std::string("R=
oger")<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , age =3D 47<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , taille =3D 1.92<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , liste =3D std::vector<int>({1,2,=
3})<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<br>
<br>
// However, here we need the type, name_t :(<br>
<br>
=C2=A0 std::cout<br>
=C2=A0=C2=A0=C2=A0 << test._<name_t>() << "\n&qu=
ot;<br>
=C2=A0=C2=A0=C2=A0 << test._<age_t>() << "\n&quo=
t;<br>
=C2=A0=C2=A0=C2=A0 << test._<taille_t>() << "\n&=
quot;<br>
=C2=A0=C2=A0=C2=A0 << test._<liste_t>().size() << std=
::endl;<br>
<br>
// making use of overloaded member _<br>
=C2=A0 std::cout<br>
=C2=A0=C2=A0=C2=A0 << test._(name) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test._(age) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test._(taille) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test._(liste_t).size() << std::endl;<=
br>
<br>
// making use of overloaded member operator()<br>
=C2=A0 std::cout<br>
=C2=A0=C2=A0=C2=A0 << test(name) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test(age) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test(taille) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test(liste_t).size() << std::endl;<br=
>
<br>
// Using the operator tuple % attribute_key<br>
<br>
=C2=A0 std::cout<br>
=C2=A0=C2=A0=C2=A0 << test%name << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test%age << "\n"<br>
=C2=A0=C2=A0=C2=A0 << test%taille << "\n"<br>
=C2=A0=C2=A0=C2=A0 << (test%liste_t).size() << std::endl;<b=
r>
<br>
// Using the attribute_key operator ()<br>
<br>
=C2=A0 std::cout<br>
=C2=A0=C2=A0=C2=A0 << name(test) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << age(test) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << taille(test) << "\n"<br>
=C2=A0=C2=A0=C2=A0 << liste(test).size() << std::endl;<br>
<br>
}<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
Vicente<br>
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<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>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
--f46d044281000cb7300515cc1cf6--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 12 May 2015 00:11:48 +0200
Raw View
This is a multi-part message in MIME format.
--------------090603070509010504050702
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 11/05/15 12:47, Jean-Bernard Jansen a =C3=A9crit :
> Hello Vicente
>
Salut Jean-Bernard,
> Thank you very much for your interest about this work.
>
> What you propose is actually doable, and is quite similar to what we=20
> can found in this project <https://github.com/matt-42/iod>, which=20
> basically does the same thing.
A quick look let me think that there are a lot of macros there :(
> I am a little bit reluctant to add this feature for a very particular=20
> reason. Using static instances as you propose adds a problem : you=20
> have static symbols to manage, thus leading to potential conflicts=20
> between different compilation units. Those problems can be solved but=20
> extra care about them is needed. For instance, you used an anonymous=20
> namespace. It works, but duplicates every static instance in every=20
> compilation unit using them. This adds unused data in the resulting=20
> compiled code. When using declared (but NOT defined) types, no extra=20
> data is added.
The attribute_key class template has no data, so it has the same issues=20
that we have with nullopt, in_place, ..... There is a ODR issue, but we=20
can live with that, as soon as we don't use the address of these objects.
Note that I included them in an anonymous namespace as it was just an=20
example. I believe the users have other possibilities and the standard=20
doesn't need to solve this problem for them.
>
> The main point of my particular implementation is to avoid static=20
> instances as much as possible (cannot be avoided when you want to use=20
> runtime introspection, obviously). This allows to use a syntax with=20
> wich you dont even have to declare attribute names before using them.
>
>
> auto test =3D make_named_tuple(
> _<"nom"_h>() =3D std::string("Roger")
> , _<"age"_h>() =3D 47
> , _<"taille"_h>() =3D 1.92
> , _<"liste"_h>() =3D std::vector<int>({1,2,3})
> );
>
> What is your opinion on this point ?
I see the advantage but I would prefer to have less noise
_<"nom"_h>()
nom
even if this would require a declaration. Anyway the attribute key is no=20
more than syntactic sugar, and with the exception of the syntax=20
test._(name) and test(name) all the others could be added in a=20
non-intrusive way by the user on top of your proposal. If the fuction=20
call unification is adopted the function call name(test) could be used=20
also as test.name().
> My mind is always open to changes, and I do like the proposal about=20
> using key selector function to access members. This really is elegant,=20
> I'll think about it.
>
BTW, if tagged types were adopted in the standard, it would be nice to=20
use them also with std::experimental::any and=20
std::experimental::variant. What do you think of this possibility?
Vicente
P.S. What prevents to extend std::tuple with tagged types? Have you=20
found any backward compatibility issues or any lost of efficiency?
P.S..S Do you plan a have a first proposal for the next meeting?
--=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/.
--------------090603070509010504050702
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 11/05/15 12:47, Jean-Bernard Jansen
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CALoNf_UeReAes5N_b=3D7OoQjKGO55sGCd2gs69LRiO8KwgymkjA@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div>
<div>
<div>Hello Vicente<br>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
Salut Jean-Bernard,<br>
<blockquote
cite=3D"mid:CALoNf_UeReAes5N_b=3D7OoQjKGO55sGCd2gs69LRiO8KwgymkjA@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div>Thank you very much for your interest about this work.<br>
<br>
</div>
What you propose is actually doable, and is quite similar to
what we can found <a moz-do-not-send=3D"true"
href=3D"https://github.com/matt-42/iod">in this project</a>,
which basically does the same thing.</div>
</div>
</blockquote>
A quick look let me think that there are a lot of macros there :(<br>
<blockquote
cite=3D"mid:CALoNf_UeReAes5N_b=3D7OoQjKGO55sGCd2gs69LRiO8KwgymkjA@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div> I am a little bit reluctant to add this feature for a very
particular reason. Using static instances as you propose adds
a problem : you have static symbols to manage, thus leading to
potential conflicts between different compilation units. Those
problems can be solved but extra care about them is needed.
For instance, you used an anonymous namespace. It works, but
duplicates every static instance in every compilation unit
using them. This adds unused data in the resulting compiled
code. When using declared (but NOT defined) types, no extra
data is added.<br>
</div>
</div>
</blockquote>
The attribute_key class template has no data, so it has the same
issues that we have with nullopt, in_place, ..... There is a ODR
issue, but we can live with that, as soon as we don't use the
address of these objects.<br>
Note that I included them in an anonymous namespace as it was just
an example. I believe the users have other possibilities and the
standard doesn't need to solve this problem for them.<br>
<blockquote
cite=3D"mid:CALoNf_UeReAes5N_b=3D7OoQjKGO55sGCd2gs69LRiO8KwgymkjA@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div>The main point of my particular implementation is to avoid
static instances as much as possible (cannot be avoided when
you want to use runtime introspection, obviously). This allows
to use a syntax with wich you dont even have to declare
attribute names before using them.<br>
<br>
<br>
auto test =3D make_named_tuple( <br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _<"nom"_h>() =3D std::string=
("Roger")<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _<"age"_h>() =3D 47<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _<"taille"_h>() =3D 1.92<b=
r>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _<"liste"_h>() =3D std::ve=
ctor<int>({1,2,3})<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<br>
<br>
</div>
<div>What is your opinion on this point ? </div>
</div>
</blockquote>
I see the advantage but I would prefer to have less noise<br>
<br>
<tt>_<"nom"_h>()</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 nom</tt><br>
<br>
even if this would require a declaration. Anyway the attribute key
is no more than syntactic sugar, and with the exception of the
syntax test._(name) and test(name) all the others could be added in
a non-intrusive way by the user on top of your proposal. If the
fuction call unification is adopted the function call name(test)
could be used also as test.name().
<blockquote
cite=3D"mid:CALoNf_UeReAes5N_b=3D7OoQjKGO55sGCd2gs69LRiO8KwgymkjA@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div>My mind is always open to changes, and I do like the
proposal about using key selector function to access members.
This really is elegant, I'll think about it.<br>
<br>
</div>
</div>
</blockquote>
<br>
BTW, if tagged types were adopted in the standard, it would be nice
to use them also with std::experimental::any and
std::experimental::variant. What do you think of this possibility?<br>
<br>
Vicente <br>
<br>
P.S. What prevents to extend std::tuple with tagged types? Have you
found any backward compatibility issues or any lost of efficiency?<br>
<br>
P.S..S Do you plan a have a first proposal for the next meeting?<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 />
--------------090603070509010504050702--
.
Author: Jean-Bernard Jansen <jeanbernard.jansen@gmail.com>
Date: Tue, 12 May 2015 01:27:14 +0200
Raw View
--f46d043c7f0a003b1a0515d6b964
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi again :)
Yes, the IOD project uses macros, and I dont like it either.
And yes, we could add what you propose just on top of what already exists :
this convinces me to give it a try very soon.
As for tagged types into the standard, I am convinced they will make their
way through one day or antoher. *Tuple addressing via type* was the first
baby step toward it. Yes I would gladly see them well integrated with
std::exprimental::any and std::experimental::variant. And to be fully
honest, I just see them as a step toward anonymous structures : a type
described by its members' names and types, but not by its own name. It
would spare the developpers a lot of conversion code to make libraries from
different sources interoperable. Thats what I had in mind while working on
the named tuple.
I dont think anything prevents from extending std::tuple with tagged types.
I did not use inheritance because the first implementation was not based on
std::tuple.. But now that you state it, it makes sense.
I did not plan to write a proposal for the next meeting, but I can spare
time to. I am not used to the exercise though, any advice on the matter
will be appreciated.
Thank you again for your toughts.
JB
On Tue, May 12, 2015 at 12:11 AM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Le 11/05/15 12:47, Jean-Bernard Jansen a =C3=A9crit :
>
> Hello Vicente
>
> Salut Jean-Bernard,
>
> Thank you very much for your interest about this work.
>
> What you propose is actually doable, and is quite similar to what we can
> found in this project <https://github.com/matt-42/iod>, which basically
> does the same thing.
>
> A quick look let me think that there are a lot of macros there :(
>
> I am a little bit reluctant to add this feature for a very particular
> reason. Using static instances as you propose adds a problem : you have
> static symbols to manage, thus leading to potential conflicts between
> different compilation units. Those problems can be solved but extra care
> about them is needed. For instance, you used an anonymous namespace. It
> works, but duplicates every static instance in every compilation unit usi=
ng
> them. This adds unused data in the resulting compiled code. When using
> declared (but NOT defined) types, no extra data is added.
>
> The attribute_key class template has no data, so it has the same issues
> that we have with nullopt, in_place, ..... There is a ODR issue, but we c=
an
> live with that, as soon as we don't use the address of these objects.
> Note that I included them in an anonymous namespace as it was just an
> example. I believe the users have other possibilities and the standard
> doesn't need to solve this problem for them.
>
>
> The main point of my particular implementation is to avoid static
> instances as much as possible (cannot be avoided when you want to use
> runtime introspection, obviously). This allows to use a syntax with wich
> you dont even have to declare attribute names before using them.
>
>
> auto test =3D make_named_tuple(
> _<"nom"_h>() =3D std::string("Roger")
> , _<"age"_h>() =3D 47
> , _<"taille"_h>() =3D 1.92
> , _<"liste"_h>() =3D std::vector<int>({1,2,3})
> );
>
> What is your opinion on this point ?
>
> I see the advantage but I would prefer to have less noise
>
> _<"nom"_h>()
> nom
>
> even if this would require a declaration. Anyway the attribute key is no
> more than syntactic sugar, and with the exception of the syntax
> test._(name) and test(name) all the others could be added in a
> non-intrusive way by the user on top of your proposal. If the fuction cal=
l
> unification is adopted the function call name(test) could be used also as
> test.name().
>
> My mind is always open to changes, and I do like the proposal about
> using key selector function to access members. This really is elegant, I'=
ll
> think about it.
>
>
> BTW, if tagged types were adopted in the standard, it would be nice to us=
e
> them also with std::experimental::any and std::experimental::variant. Wha=
t
> do you think of this possibility?
>
> Vicente
>
> P.S. What prevents to extend std::tuple with tagged types? Have you found
> any backward compatibility issues or any lost of efficiency?
>
> P.S..S Do you plan a have a first proposal for the next meeting?
>
> --
>
> ---
> 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/.
>
--=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/.
--f46d043c7f0a003b1a0515d6b964
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div>Hi again :)<br></div><div><br></div>Ye=
s, the IOD project uses macros, and I dont like it either.<br><br></div>And=
yes, we could add what you propose just on top of what already exists : th=
is convinces me to give it a try very soon.<br><br></div>As for tagged type=
s into the standard, I am convinced they will make their way through one da=
y or antoher. <i>Tuple addressing via type</i> was the first baby step towa=
rd it. Yes I would gladly see them well integrated with std::exprimental::a=
ny and std::experimental::variant. And to be fully honest, I just see them =
as a step toward anonymous structures : a type described by its members'=
; names and types, but not by its own name. It would spare the developpers =
a lot of conversion code to make libraries from different sources interoper=
able. Thats what I had in mind while working on the named tuple.<br><br></d=
iv><div>I dont think anything prevents from extending std::tuple with tagge=
d types. I did not use inheritance because the first implementation was not=
based on std::tuple.. But now that you state it, it makes sense.<br><br></=
div><div>I did not plan to write a proposal for the next meeting, but I can=
spare time to. I am not used to the exercise though, any advice on the mat=
ter will be appreciated.<br><br></div><div>Thank you again for your toughts=
..<br><br></div><div>JB<br></div><div><br></div></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Tue, May 12, 2015 at 12:11 AM, Vicen=
te J. Botet Escriba <span dir=3D"ltr"><<a href=3D"mailto:vicente.botet@w=
anadoo.fr" target=3D"_blank">vicente.botet@wanadoo.fr</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 11/05/15 12:47, Jean-Bernard Jansen
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div>
<div>
<div>Hello Vicente<br>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
Salut Jean-Bernard,<span class=3D""><br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div>Thank you very much for your interest about this work.<br>
<br>
</div>
What you propose is actually doable, and is quite similar to
what we can found <a href=3D"https://github.com/matt-42/iod" targ=
et=3D"_blank">in this project</a>,
which basically does the same thing.</div>
</div>
</blockquote></span>
A quick look let me think that there are a lot of macros there :(<span =
class=3D""><br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div> I am a little bit reluctant to add this feature for a very
particular reason. Using static instances as you propose adds
a problem : you have static symbols to manage, thus leading to
potential conflicts between different compilation units. Those
problems can be solved but extra care about them is needed.
For instance, you used an anonymous namespace. It works, but
duplicates every static instance in every compilation unit
using them. This adds unused data in the resulting compiled
code. When using declared (but NOT defined) types, no extra
data is added.<br>
</div>
</div>
</blockquote></span>
The attribute_key class template has no data, so it has the same
issues that we have with nullopt, in_place, ..... There is a ODR
issue, but we can live with that, as soon as we don't use the
address of these objects.<br>
Note that I included them in an anonymous namespace as it was just
an example. I believe the users have other possibilities and the
standard doesn't need to solve this problem for them.<span class=3D=
""><br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div>The main point of my particular implementation is to avoid
static instances as much as possible (cannot be avoided when
you want to use runtime introspection, obviously). This allows
to use a syntax with wich you dont even have to declare
attribute names before using them.<br>
<br>
<br>
auto test =3D make_named_tuple( <br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _<"nom"_h>() =3D s=
td::string("Roger")<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _<"age"_h>() =3D=
47<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _<"taille"_h>() =
=3D 1.92<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _<"liste"_h>() =
=3D std::vector<int>({1,2,3})<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<br>
<br>
</div>
<div>What is your opinion on this point ? </div>
</div>
</blockquote></span>
I see the advantage but I would prefer to have less noise<br>
<br>
<tt>_<"nom"_h>()</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 nom</tt><br>
<br>
even if this would require a declaration. Anyway the attribute key
is no more than syntactic sugar, and with the exception of the
syntax test._(name) and test(name) all the others could be added in
a non-intrusive way by the user on top of your proposal. If the
fuction call unification is adopted the function call name(test)
could be used also as <a href=3D"http://test.name" target=3D"_blank">te=
st.name</a>().
<span class=3D""><blockquote type=3D"cite">
<div dir=3D"ltr">
<div>My mind is always open to changes, and I do like the
proposal about using key selector function to access members.
This really is elegant, I'll think about it.<br>
<br>
</div>
</div>
</blockquote>
<br></span>
BTW, if tagged types were adopted in the standard, it would be nice
to use them also with std::experimental::any and
std::experimental::variant. What do you think of this possibility?<br>
<br>
Vicente <br>
<br>
P.S. What prevents to extend std::tuple with tagged types? Have you
found any backward compatibility issues or any lost of efficiency?<br>
<br>
P.S..S Do you plan a have a first proposal for the next meeting?<br>
</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 />
--f46d043c7f0a003b1a0515d6b964--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 13 May 2015 19:04:05 +0200
Raw View
This is a multi-part message in MIME format.
--------------010207080202060705030203
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 12/05/15 01:27, Jean-Bernard Jansen a =C3=A9crit :
> Hi again :)
>
> Yes, the IOD project uses macros, and I dont like it either.
>
> And yes, we could add what you propose just on top of what already=20
> exists : this convinces me to give it a try very soon.
>
> As for tagged types into the standard, I am convinced they will make=20
> their way through one day or antoher. /Tuple addressing via type/ was=20
> the first baby step toward it. Yes I would gladly see them well=20
> integrated with std::exprimental::any and std::experimental::variant.=20
> And to be fully honest, I just see them as a step toward anonymous=20
> structures : a type described by its members' names and types, but not=20
> by its own name.
This exist already.
struct {
T1 n1;
T2 n2;
}
I believe that what your are talking off is the ability to built them at=20
compile time.
> It would spare the developpers a lot of conversion code to make=20
> libraries from different sources interoperable. Thats what I had in=20
> mind while working on the named tuple.
I agree that this will be really a good thing, but I'm not a compiler=20
guy, so I couldn't prototype anything. Recently there were some that=20
were talking about introducing discriminated unions in C++. It would be=20
great if we were also able to built these discriminated unions at=20
compile time.
Waiting for that, we can take see what can be done in C++14/17 with a=20
library solution, even if the solution couldn't be as elegant as if it=20
was integrated on the language.
>
> I dont think anything prevents from extending std::tuple with tagged=20
> types. I did not use inheritance because the first implementation was=20
> not based on std::tuple.. But now that you state it, it makes sense.
>
I was not thinking about using inheritance, but to re-define std::tuple=20
in std::experimental::tuple extending it to take in account named/tag types=
..
> I did not plan to write a proposal for the next meeting, but I can=20
> spare time to. I am not used to the exercise though, any advice on the=20
> matter will be appreciated.
>
Let see this point off line then.
Vicente
> Thank you again for your toughts.
>
> JB
>
>
> On Tue, May 12, 2015 at 12:11 AM, Vicente J. Botet Escriba=20
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
>
> Le 11/05/15 12:47, Jean-Bernard Jansen a =C3=A9crit :
>> Hello Vicente
>>
> Salut Jean-Bernard,
>> Thank you very much for your interest about this work.
>>
>> What you propose is actually doable, and is quite similar to what
>> we can found in this project <https://github.com/matt-42/iod>,
>> which basically does the same thing.
> A quick look let me think that there are a lot of macros there :(
>> I am a little bit reluctant to add this feature for a very
>> particular reason. Using static instances as you propose adds a
>> problem : you have static symbols to manage, thus leading to
>> potential conflicts between different compilation units. Those
>> problems can be solved but extra care about them is needed. For
>> instance, you used an anonymous namespace. It works, but
>> duplicates every static instance in every compilation unit using
>> them. This adds unused data in the resulting compiled code. When
>> using declared (but NOT defined) types, no extra data is added.
> The attribute_key class template has no data, so it has the same
> issues that we have with nullopt, in_place, ..... There is a ODR
> issue, but we can live with that, as soon as we don't use the
> address of these objects.
> Note that I included them in an anonymous namespace as it was just
> an example. I believe the users have other possibilities and the
> standard doesn't need to solve this problem for them.
>>
>> The main point of my particular implementation is to avoid static
>> instances as much as possible (cannot be avoided when you want to
>> use runtime introspection, obviously). This allows to use a
>> syntax with wich you dont even have to declare attribute names
>> before using them.
>>
>>
>> auto test =3D make_named_tuple(
>> _<"nom"_h>() =3D std::string("Roger")
>> , _<"age"_h>() =3D 47
>> , _<"taille"_h>() =3D 1.92
>> , _<"liste"_h>() =3D std::vector<int>({1,2,3})
>> );
>>
>> What is your opinion on this point ?
> I see the advantage but I would prefer to have less noise
>
> _<"nom"_h>()
> nom
>
> even if this would require a declaration. Anyway the attribute key
> is no more than syntactic sugar, and with the exception of the
> syntax test._(name) and test(name) all the others could be added
> in a non-intrusive way by the user on top of your proposal. If the
> fuction call unification is adopted the function call name(test)
> could be used also as test.name <http://test.name>().
>> My mind is always open to changes, and I do like the proposal
>> about using key selector function to access members. This really
>> is elegant, I'll think about it.
>>
>
> BTW, if tagged types were adopted in the standard, it would be
> nice to use them also with std::experimental::any and
> std::experimental::variant. What do you think of this possibility?
>
> Vicente
>
> P.S. What prevents to extend std::tuple with tagged types? Have
> you found any backward compatibility issues or any lost of efficiency=
?
>
> P.S..S Do you plan a have a first proposal for the next meeting?
> --=20
>
> ---
> 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-kIXNrk=
TUk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email
> to std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
> --=20
>
> ---
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------010207080202060705030203
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 12/05/15 01:27, Jean-Bernard Jansen
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CALoNf_W4WSAsNn7=3D0=3DbZbp5c+LAc_SruHxM9_vu1eE-5gLxRPA@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div>
<div>
<div>Hi again :)<br>
</div>
<div><br>
</div>
Yes, the IOD project uses macros, and I dont like it
either.<br>
<br>
</div>
And yes, we could add what you propose just on top of what
already exists : this convinces me to give it a try very
soon.<br>
<br>
</div>
As for tagged types into the standard, I am convinced they
will make their way through one day or antoher. <i>Tuple
addressing via type</i> was the first baby step toward it.
Yes I would gladly see them well integrated with
std::exprimental::any and std::experimental::variant. And to
be fully honest, I just see them as a step toward anonymous
structures : a type described by its members' names and types,
but not by its own name. </div>
</div>
</blockquote>
This exist already. <br>
struct {<br>
=C2=A0=C2=A0=C2=A0 T1 n1;<br>
=C2=A0=C2=A0=C2=A0 T2 n2;<br>
}<br>
<br>
I believe that what your are talking off is the ability to built
them at compile time. <br>
<blockquote
cite=3D"mid:CALoNf_W4WSAsNn7=3D0=3DbZbp5c+LAc_SruHxM9_vu1eE-5gLxRPA@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">
<div>It would spare the developpers a lot of conversion code to
make libraries from different sources interoperable. Thats
what I had in mind while working on the named tuple.<br>
</div>
</div>
</blockquote>
I agree that this will be really a good thing, but I'm not a
compiler guy, so I couldn't prototype anything. Recently there were
some that were talking about introducing discriminated unions in
C++. It would be great if we were also able to built these
discriminated unions at compile time. <br>
<br>
Waiting for that, we can take see what can be done in C++14/17 with
a library solution, even if the solution couldn't be as elegant as
if it was integrated on the language.<br>
<blockquote
cite=3D"mid:CALoNf_W4WSAsNn7=3D0=3DbZbp5c+LAc_SruHxM9_vu1eE-5gLxRPA@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div>I dont think anything prevents from extending std::tuple
with tagged types. I did not use inheritance because the first
implementation was not based on std::tuple.. But now that you
state it, it makes sense.<br>
<br>
</div>
</div>
</blockquote>
I was not thinking about using inheritance, but to re-define
std::tuple in std::experimental::tuple extending it to take in
account named/tag types.<br>
<blockquote
cite=3D"mid:CALoNf_W4WSAsNn7=3D0=3DbZbp5c+LAc_SruHxM9_vu1eE-5gLxRPA@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">
<div>I did not plan to write a proposal for the next meeting,
but I can spare time to. I am not used to the exercise though,
any advice on the matter will be appreciated.<br>
<br>
</div>
</div>
</blockquote>
Let see this point off line then.<br>
<br>
Vicente<br>
<blockquote
cite=3D"mid:CALoNf_W4WSAsNn7=3D0=3DbZbp5c+LAc_SruHxM9_vu1eE-5gLxRPA@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">
<div>Thank you again for your toughts.<br>
<br>
</div>
<div>JB<br>
</div>
<div><br>
</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Tue, May 12, 2015 at 12:11 AM,
Vicente J. Botet Escriba <span dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vi=
cente.botet@wanadoo.fr</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 11/05/15 12:47, Jean-Bernard Jansen a =C3=A9crit=C2=
=A0:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div>
<div>
<div>Hello Vicente<br>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
Salut Jean-Bernard,<span class=3D""><br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div>Thank you very much for your interest about
this work.<br>
<br>
</div>
What you propose is actually doable, and is quite
similar to what we can found <a
moz-do-not-send=3D"true"
href=3D"https://github.com/matt-42/iod"
target=3D"_blank">in this project</a>, which
basically does the same thing.</div>
</div>
</blockquote>
</span> A quick look let me think that there are a lot of
macros there :(<span class=3D""><br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div> I am a little bit reluctant to add this
feature for a very particular reason. Using static
instances as you propose adds a problem : you have
static symbols to manage, thus leading to
potential conflicts between different compilation
units. Those problems can be solved but extra care
about them is needed. For instance, you used an
anonymous namespace. It works, but duplicates
every static instance in every compilation unit
using them. This adds unused data in the resulting
compiled code. When using declared (but NOT
defined) types, no extra data is added.<br>
</div>
</div>
</blockquote>
</span> The attribute_key class template has no data, so
it has the same issues that we have with nullopt,
in_place, ..... There is a ODR issue, but we can live with
that, as soon as we don't use the address of these
objects.<br>
Note that I included them in an anonymous namespace as it
was just an example. I believe the users have other
possibilities and the standard doesn't need to solve this
problem for them.<span class=3D""><br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div>The main point of my particular implementation
is to avoid static instances as much as possible
(cannot be avoided when you want to use runtime
introspection, obviously). This allows to use a
syntax with wich you dont even have to declare
attribute names before using them.<br>
<br>
<br>
auto test =3D make_named_tuple( <br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _<"nom"_h>() =3D=
std::string("Roger")<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _<"age"_h>() =
=3D 47<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _<"taille"_h>(=
) =3D 1.92<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _<"liste"_h>()=
=3D
std::vector<int>({1,2,3})<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<br>
<br>
</div>
<div>What is your opinion on this point ? </div>
</div>
</blockquote>
</span> I see the advantage but I would prefer to have
less noise<br>
<br>
<tt>_<"nom"_h>()</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 nom</tt><br>
<br>
even if this would require a declaration. Anyway the
attribute key is no more than syntactic sugar, and with
the exception of the syntax test._(name) and test(name)
all the others could be added in a non-intrusive way by
the user on top of your proposal. If the fuction call
unification is adopted the function call name(test) could
be used also as <a moz-do-not-send=3D"true"
href=3D"http://test.name" target=3D"_blank">test.name</a>()=
..
<span class=3D"">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>My mind is always open to changes, and I do
like the proposal about using key selector
function to access members. This really is
elegant, I'll think about it.<br>
<br>
</div>
</div>
</blockquote>
<br>
</span> BTW, if tagged types were adopted in the standard,
it would be nice to use them also with
std::experimental::any and std::experimental::variant.
What do you think of this possibility?<br>
<br>
Vicente <br>
<br>
P.S. What prevents to extend std::tuple with tagged types?
Have you found any backward compatibility issues or any
lost of efficiency?<br>
<br>
P.S..S Do you plan a have a first proposal for the next
meeting?<br>
</div>
<div class=3D"HOEnZb">
<div class=3D"h5">
-- <br>
<br>
--- <br>
You received this message because you are subscribed to
a topic in the Google Groups "ISO C++ Standard - Future
Proposals" group.<br>
To unsubscribe from this topic, visit <a
moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/N-kIXN=
rkTUk/unsubscribe"
target=3D"_blank">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 moz-do-not-send=3D"true"
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
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank=
">std-proposals@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-p=
roposals/"
target=3D"_blank">http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
-- <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 <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<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 />
--------------010207080202060705030203--
.