Topic: Compile-time Type ID of Integral Type?
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sat, 29 Mar 2014 06:24:53 -0700 (PDT)
Raw View
------=_Part_1503_765868.1396099493845
Content-Type: text/plain; charset=UTF-8
One of the things we want to do in SG7 Reflection is offer primitives that
enable at compile-time the equivalent functionality of typeid,
std::type_info and std::type_index (only observing static types of course).
This entails providing a name for the type as a string literal
(compile-time string), and providing a hashable and comparable constant
expression value for a type.
So for hashablility you should be able to use the primitives to define a
variable template like:
template<typename T>
constexpr size_t hash_type = /* a hash code for type T */;
And for comparability you should be able to define a variable template like:
template<typename A, typename B>
constexpr bool is_less_type = /* is A less than B in some ordering */;
I'm trying to think how to specify the primitives and specifically I want
to know if it is feasible to require implementations to provide an integral
ID for a type?
For example imagine a standard type trait like:
template<typename T>
struct type_id_number : integral_constant<size_t, __type_id_number(T)>
{}
A unique integer for type T. type_id_number<A> == type_id_number<B> if
and only if is_same<A,B>
If this is feasible it seems like the ideal way to cover the hash and
comparison use cases. It would also mean that the value could be used as a
non-type template parameter, and also as the condition in a switch.
My questions are:
- Is it feasible for implementations to provide type_id_number<A> and the
supporting intrinsic?
- If so, what is the effort?
(I'm imagining a counter that increments each time a static type is
introduced in a program, but the interaction across TUs and linking isn't
clear)
The alternative would be to "raise" the primitives to only standardize
hash_type<T> and is_less_type<A,B>, but this offers less flexibility.
--
---
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_1503_765868.1396099493845
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">One of the things we want to do in SG7 Reflection is offer=
primitives that enable at compile-time the equivalent functionality of typ=
eid, std::type_info and std::type_index (only observing static types of cou=
rse).<div><br></div><div>This entails providing a name for the type as a st=
ring literal (compile-time string), and providing a hashable and comparable=
constant expression value for a type.</div><div><br></div><div>So for hash=
ablility you should be able to use the primitives to define a variable temp=
late like:<br></div><div><br></div><div><font face=3D"courier new, monospac=
e"> template<typename T></font></div><div><font face=3D"=
courier new, monospace"> constexpr size_t hash_type =3D /* a h=
ash code for type T */;</font></div><div><br></div><div>And for comparabili=
ty you should be able to define a variable template like:</div><div><br></d=
iv><div><font face=3D"courier new, monospace"> template<typ=
ename A, typename B></font></div><div><font face=3D"courier new, monospa=
ce"> constexpr bool is_less_type =3D /* is A less than B in so=
me ordering */;</font></div><div><br></div><div>I'm trying to think how to =
specify the primitives and specifically I want to know if it is feasible to=
require implementations to provide an integral ID for a type?</div><div><b=
r></div><div>For example imagine a standard type trait like:</div><div><br>=
</div><div><font face=3D"courier new, monospace"> template<=
typename T></font></div><div><font face=3D"courier new, monospace"> =
; struct type_id_number : integral_constant<size_t, __type_id_num=
ber(T)> {}</font></div><div><font face=3D"courier new, monospace"><br></=
font></div><div><font face=3D"courier new, monospace"> A uniqu=
e integer for type T. type_id_number<A> =3D=3D type_id_number&l=
t;B> if and only if is_same<A,B></font></div><div><br></div><div>I=
f this is feasible it seems like the ideal way to cover the hash and compar=
ison use cases. It would also mean that the value could be used as a =
non-type template parameter, and also as the condition in a switch.</div><d=
iv><br></div><div>My questions are:</div><div> - Is it feasible for im=
plementations to provide type_id_number<A> and the supporting intrins=
ic?</div><div> - If so, what is the effort?</div><div><br></div><div>(=
I'm imagining a counter that increments each time a static type is introduc=
ed in a program, but the interaction across TUs and linking isn't clear)</d=
iv><div><br></div><div>The alternative would be to "raise" the primitives t=
o only standardize hash_type<T> and is_less_type<A,B>, but this=
offers less flexibility.<br></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_1503_765868.1396099493845--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 29 Mar 2014 22:21:31 +0800
Raw View
--Apple-Mail=_71687F86-434D-45B1-B6FA-02D6658A82D4
Content-Type: text/plain; charset=ISO-8859-1
On 2014-03-29, at 9:24 PM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> I'm trying to think how to specify the primitives and specifically I want to know if it is feasible to require implementations to provide an integral ID for a type?
You are of course aware of std::type_info::hash_code?
I see no reason it shouldn't be constexpr. Since C++11 typeid expressions can appear in constant expressions, but there's nothing you can do with the type_info. So this smells like a defect.
--
---
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/.
--Apple-Mail=_71687F86-434D-45B1-B6FA-02D6658A82D4
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;03–29, at 9:24 PM, Andrew Tomazos <<a href=3D"mailto:andrewt=
omazos@gmail.com">andrewtomazos@gmail.com</a>> wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div>=
I'm trying to think how to specify the primitives and specifically I want t=
o know if it is feasible to require implementations to provide an integral =
ID for a type?</div></div></blockquote><div><br></div><div>You are of cours=
e aware of <font face=3D"Courier">std::type_info::hash_code</font>?</div><d=
iv><br></div><div>I see no reason it shouldn’t be constexpr. Since C+=
+11 typeid expressions can appear in constant expressions, but there’=
s nothing you can do with the <font face=3D"Courier">type_info</font>.=
So this smells like a defect.</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=_71687F86-434D-45B1-B6FA-02D6658A82D4--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Sat, 29 Mar 2014 09:05:33 -0700 (PDT)
Raw View
------=_Part_634_31664176.1396109134115
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I think it would be very advantageous if this could be arranged, especially=
=20
if the numbers could be guaranteed to be "small positive" ints so that a=20
vector or similar can be indexed by the type id number without risk that=20
the vector is suddenly gigabytes in size due to large holes in the number=
=20
series. This would allow very fast lookup of per-type information that may=
=20
be needed for instance for serialization etc. and no the least for a RTTI=
=20
system built on top of the CTTI system.
Den l=C3=B6rdagen den 29:e mars 2014 kl. 14:24:53 UTC+1 skrev Andrew Tomazo=
s:
>
> One of the things we want to do in SG7 Reflection is offer primitives tha=
t=20
> enable at compile-time the equivalent functionality of typeid,=20
> std::type_info and std::type_index (only observing static types of course=
).
>
> This entails providing a name for the type as a string literal=20
> (compile-time string), and providing a hashable and comparable constant=
=20
> expression value for a type.
>
> So for hashablility you should be able to use the primitives to define a=
=20
> variable template like:
>
> template<typename T>
> constexpr size_t hash_type =3D /* a hash code for type T */;
>
> And for comparability you should be able to define a variable template=20
> like:
>
> template<typename A, typename B>
> constexpr bool is_less_type =3D /* is A less than B in some ordering =
*/;
>
> I'm trying to think how to specify the primitives and specifically I want=
=20
> to know if it is feasible to require implementations to provide an integr=
al=20
> ID for a type?
>
> For example imagine a standard type trait like:
>
> template<typename T>
> struct type_id_number : integral_constant<size_t, __type_id_number(T)=
>=20
> {}
>
> A unique integer for type T. type_id_number<A> =3D=3D type_id_number=
<B>=20
> if and only if is_same<A,B>
>
> If this is feasible it seems like the ideal way to cover the hash and=20
> comparison use cases. It would also mean that the value could be used as=
a=20
> non-type template parameter, and also as the condition in a switch.
>
> My questions are:
> - Is it feasible for implementations to provide type_id_number<A> and th=
e=20
> supporting intrinsic?
> - If so, what is the effort?
>
> (I'm imagining a counter that increments each time a static type is=20
> introduced in a program, but the interaction across TUs and linking isn't=
=20
> clear)
>
> The alternative would be to "raise" the primitives to only standardize=20
> hash_type<T> and is_less_type<A,B>, but this offers less flexibility.
>
>
--=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_634_31664176.1396109134115
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think it would be very advantageous if this could be arr=
anged, especially if the numbers could be guaranteed to be "small positive"=
ints so that a vector or similar can be indexed by the type id number with=
out risk that the vector is suddenly gigabytes in size due to large holes i=
n the number series. This would allow very fast lookup of per-type informat=
ion that may be needed for instance for serialization etc. and no the least=
for a RTTI system built on top of the CTTI system.<br><br>Den l=C3=B6rdage=
n den 29:e mars 2014 kl. 14:24:53 UTC+1 skrev Andrew Tomazos:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr">One of the things we want t=
o do in SG7 Reflection is offer primitives that enable at compile-time the =
equivalent functionality of typeid, std::type_info and std::type_index (onl=
y observing static types of course).<div><br></div><div>This entails provid=
ing a name for the type as a string literal (compile-time string), and prov=
iding a hashable and comparable constant expression value for a type.</div>=
<div><br></div><div>So for hashablility you should be able to use the primi=
tives to define a variable template like:<br></div><div><br></div><div><fon=
t face=3D"courier new, monospace"> template<typename T><=
/font></div><div><font face=3D"courier new, monospace"> conste=
xpr size_t hash_type =3D /* a hash code for type T */;</font></div><div><br=
></div><div>And for comparability you should be able to define a variable t=
emplate like:</div><div><br></div><div><font face=3D"courier new, monospace=
"> template<typename A, typename B></font></div><div><fo=
nt face=3D"courier new, monospace"> constexpr bool is_less_typ=
e =3D /* is A less than B in some ordering */;</font></div><div><br></div><=
div>I'm trying to think how to specify the primitives and specifically I wa=
nt to know if it is feasible to require implementations to provide an integ=
ral ID for a type?</div><div><br></div><div>For example imagine a standard =
type trait like:</div><div><br></div><div><font face=3D"courier new, monosp=
ace"> template<typename T></font></div><div><font face=
=3D"courier new, monospace"> struct type_id_number : integral_=
constant<size_t, __type_id_number(T)> {}</font></div><div><font face=
=3D"courier new, monospace"><br></font></div><div><font face=3D"courier new=
, monospace"> A unique integer for type T. type_id_numbe=
r<A> =3D=3D type_id_number<B> if and only if is_same<A,B>=
</font></div><div><br></div><div>If this is feasible it seems like the idea=
l way to cover the hash and comparison use cases. It would also mean =
that the value could be used as a non-type template parameter, and also as =
the condition in a switch.</div><div><br></div><div>My questions are:</div>=
<div> - Is it feasible for implementations to provide type_id_number&l=
t;A> and the supporting intrinsic?</div><div> - If so, what is the =
effort?</div><div><br></div><div>(I'm imagining a counter that increments e=
ach time a static type is introduced in a program, but the interaction acro=
ss TUs and linking isn't clear)</div><div><br></div><div>The alternative wo=
uld be to "raise" the primitives to only standardize hash_type<T> and=
is_less_type<A,B>, but this offers less flexibility.<br></div><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_634_31664176.1396109134115--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 30 Mar 2014 00:51:22 +0800
Raw View
--Apple-Mail=_B561B2C9-9CDE-4E06-A24C-69BE90C7CEDE
Content-Type: text/plain; charset=ISO-8859-1
On 2014-03-30, at 12:05 AM, Bengt Gustafsson <bengt.gustafsson@beamways.com> wrote:
> I think it would be very advantageous if this could be arranged, especially if the numbers could be guaranteed to be "small positive" ints
These could only be determined at program load time, which doesn't really qualify as "compile time" any more.
> so that a vector or similar can be indexed by the type id number without risk that the vector is suddenly gigabytes in size due to large holes in the number series.
You can assign serial numbers to types using overload set counting. Be sure that the same numbers are assigned in each TU.
> This would allow very fast lookup of per-type information that may be needed for instance for serialization etc. and no the least for a RTTI system built on top of the CTTI system.
Yes, but be careful what you wish for :P .
--
---
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/.
--Apple-Mail=_B561B2C9-9CDE-4E06-A24C-69BE90C7CEDE
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;03–30, at 12:05 AM, Bengt Gustafsson <<a href=3D"mailto:beng=
t.gustafsson@beamways.com">bengt.gustafsson@beamways.com</a>> wrote:</di=
v><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div di=
r=3D"ltr">I think it would be very advantageous if this could be arranged, =
especially if the numbers could be guaranteed to be "small positive” =
ints</div></blockquote><div><br></div><div>These could only be determined a=
t program load time, which doesn’t really qualify as “compile t=
ime” any more.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"> s=
o that a vector or similar can be indexed by the type id number without ris=
k that the vector is suddenly gigabytes in size due to large holes in the n=
umber series. </div></blockquote><div><br></div><div>You can assign serial =
numbers to types using <a href=3D"http://stackoverflow.com/a/6174263/1=
53285">overload set counting</a>. Be sure that the same numbers are assigne=
d in each TU.</div><br><blockquote type=3D"cite"><div dir=3D"ltr">This woul=
d allow very fast lookup of per-type information that may be needed for ins=
tance for serialization etc. and no the least for a RTTI system built on to=
p of the CTTI system.<br></div></blockquote><div><br></div><div>Yes, but be=
careful what you wish for :P .</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=_B561B2C9-9CDE-4E06-A24C-69BE90C7CEDE--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sat, 29 Mar 2014 12:26:37 -0700 (PDT)
Raw View
------=_Part_151_19220289.1396121197408
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, March 29, 2014 3:21:31 PM UTC+1, David Krauss wrote:
>
> On 2014=E2=80=9303=E2=80=9329, at 9:24 PM, Andrew Tomazos <andrew...@gmai=
l.com<javascript:>>=20
> wrote:
>
> I'm trying to think how to specify the primitives and specifically I want=
=20
> to know if it is feasible to require implementations to provide an integr=
al=20
> ID for a type?
>
>
> You are of course aware of std::type_info::hash_code?
>
> I see no reason it shouldn=E2=80=99t be constexpr. Since C++11 typeid exp=
ressions=20
> can appear in constant expressions, but there=E2=80=99s nothing you can d=
o with the=20
> type_info. So this smells like a defect.
>
The current run-time equivalent use cases of the minimum functionality=20
(name, hashable, comparable) are roughly:
struct foo {};
template<typename T>
std::string type_name =3D typeid(T).name();
template<typename T>
size_t hash_type =3D typeid(T).hash_code();
template<typename A, typename B>
bool is_less_type =3D typeid(A).before(typeid(B));
int main()
{
assert(type_name<foo> =3D=3D "foo");
assert(hash_type<foo> =3D=3D hash_type<foo>);
assert((!is_less_type<foo, foo>));
}
The compile-time use cases are therefore something like:
template<typename T>
*constexpr std::string_literal* type_name =3D ...;
template<typename T>
*constexpr* size_t hash_type =3D ...;
template<typename A, typename B>
*constexpr* bool is_less_type =3D ...;
static_assert(type_name<foo> =3D=3D "foo");
static_assert(hash_type<foo> =3D=3D hash_type<foo>);
static_assert((!is_less_type<foo, foo>));
If type_id_number<T> is feasible the later two could be implemented pure=20
library as:
template<typename T>
constexpr size_t hash_type =3D *std::type_id_number<T>*;
template<typename A, typename B>
constexpr bool is_less_type =3D *std::type_id_number<A> <=20
std::type_id_number<B>*;
If it is not feasible, then the later two would have to be provided as the=
=20
primitives in some form. In this case we would consider extending=20
std::type_info somehow, by making name, before and hash_code constexpr for=
=20
example, but there are a couple of wrinkles with this approach that need=20
further study. typeid strips the cv-qualifiers and reference from the=20
type, we would like to leave them to the user to decide whether to apply=20
the appropriate remove traits. typeid also returns a reference, so=20
requiring that this be a reference constant expression could interact badly=
=20
with the dynamic version of typeid. Also specifying std::type_info as a=20
literal type when it is polymorphic is non-trivial. My current feeling=20
about this is that there might be a separate interface equivalent=20
std::static_type_info<T> class template that provides these functions as=20
static functions or variables - or, more likely, that all three would be=20
three separate type traits in the usual form.
--=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_151_19220289.1396121197408
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, March 29, 2014 3:21:31 PM UTC+1, David Krauss=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap=
:break-word"><div><div>On 2014=E2=80=9303=E2=80=9329, at 9:24 PM, Andrew To=
mazos <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"FR92yJL9674J" onmousedown=3D"this.href=3D'javascript:';return true;" on=
click=3D"this.href=3D'javascript:';return true;">andrew...@gmail.com</a>>=
; wrote:</div><blockquote type=3D"cite"><div dir=3D"ltr"><div>I'm trying to=
think how to specify the primitives and specifically I want to know if it =
is feasible to require implementations to provide an integral ID for a type=
?</div></div></blockquote><div><br></div><div>You are of course aware of <f=
ont face=3D"Courier">std::type_info::hash_code</font>?</div><div><br></div>=
<div>I see no reason it shouldn=E2=80=99t be constexpr. Since C++11 typeid =
expressions can appear in constant expressions, but there=E2=80=99s nothing=
you can do with the <font face=3D"Courier">type_info</font>. So this =
smells like a defect.</div></div></div></blockquote><div><br></div><div>The=
current run-time equivalent use cases of the minimum functionality (name, =
hashable, comparable) are roughly:</div><div><br></div><div><div><div><span=
style=3D"font-family: 'courier new', monospace;"> struct foo =
{};</span><br></div><div><font face=3D"courier new, monospace"><br></font><=
/div><div><font face=3D"courier new, monospace"> template<t=
ypename T></font></div><div><font face=3D"courier new, monospace"> =
std::string type_name =3D typeid(T).name();</font></div><div><font =
face=3D"courier new, monospace"><br></font></div><div><font face=3D"courier=
new, monospace"> template<typename T></font></div><div>=
<font face=3D"courier new, monospace"> size_t hash_type =3D ty=
peid(T).hash_code();</font></div><div><font face=3D"courier new, monospace"=
><br></font></div><div><font face=3D"courier new, monospace"> =
template<typename A, typename B></font></div><div><font face=3D"couri=
er new, monospace"> bool is_less_type =3D typeid(A).before(typ=
eid(B));</font></div><div><font face=3D"courier new, monospace"><br></font>=
</div><div><font face=3D"courier new, monospace"> int main()</=
font></div><div><font face=3D"courier new, monospace"> {</font=
></div><div><font face=3D"courier new, monospace"> &nbs=
p; assert(type_name<foo> =3D=3D "foo");</font></div><div><font face=
=3D"courier new, monospace"> assert(hash_type<=
;foo> =3D=3D hash_type<foo>);</font></div><div><font face=3D"couri=
er new, monospace"> assert((!is_less_type<foo=
, foo>));</font></div><div><font face=3D"courier new, monospace"> =
}</font></div><div><br></div></div><div>The compile-time use cases a=
re therefore something like:</div><div><br></div><div><div><font face=3D"co=
urier new, monospace"> template<typename T></font></div>=
<div><font face=3D"courier new, monospace"> <b>constexpr std::=
string_literal</b> type_name =3D ...;</font></div><div><br></div><div><font=
face=3D"courier new, monospace"> template<typename T></=
font></div><div><font face=3D"courier new, monospace"> <b>cons=
texpr</b> size_t hash_type =3D ...;</font></div><div><font face=3D"courier =
new, monospace"><br></font></div><div><font face=3D"courier new, monospace"=
> template<typename A, typename B></font></div><div><fon=
t face=3D"courier new, monospace"> <b>constexpr</b> bool is_le=
ss_type =3D ...;</font></div></div></div><div><font face=3D"courier new, mo=
nospace"><br></font></div><div><div><font face=3D"courier new, monospace">&=
nbsp; static_assert(type_name<foo> =3D=3D "foo");</font></div>=
<div><font face=3D"courier new, monospace"> </font><span =
style=3D"font-family: 'courier new', monospace;">static_</span><span style=
=3D"font-family: 'courier new', monospace;">assert(hash_type<foo> =3D=
=3D hash_type<foo>);</span></div><div><font face=3D"courier new, mono=
space"> </font><span style=3D"font-family: 'courier new',=
monospace;">static_</span><span style=3D"font-family: 'courier new', monos=
pace;">assert((!is_less_type<foo, foo>));</span></div></div><div><fon=
t face=3D"courier new, monospace"><br></font></div><div>If <font face=3D"co=
urier new, monospace">type_id_number<T></font> is feasible the later =
two could be implemented pure library as:</div><div><br></div><div><div><di=
v><font face=3D"courier new, monospace"> template<typename =
T></font></div><div><font face=3D"courier new, monospace"> &=
nbsp;constexpr size_t hash_type =3D <b>std::type_id_number<T></b=
>;</font></div><div><font face=3D"courier new, monospace"><br></font></div>=
<div><font face=3D"courier new, monospace"> template<typena=
me A, typename B></font></div><div><font face=3D"courier new, monospace"=
> constexpr bool is_less_type =3D <b>std::type_id_nu=
mber<A> < std::type_id_number<B></b>;</font></div></div></di=
v><div><font face=3D"courier new, monospace"><br></font></div><div><font fa=
ce=3D"arial, sans-serif">If it is not feasible, then the later two would ha=
ve to be provided as the primitives in some form. In this case we wou=
ld consider extending std::type_info somehow, by making name, before and ha=
sh_code constexpr for example, but there are a couple of wrinkles with this=
approach that need further study. typeid strips the cv-qualifiers an=
d reference from the type, we would like to leave them to the user to decid=
e whether to apply the appropriate remove traits. typeid also returns=
a reference, so requiring that this be a reference constant expression cou=
ld interact badly with the dynamic version of typeid. Also specifying=
std::type_info as a literal type when it is polymorphic is non-trivial. &n=
bsp;My current feeling about this is that there might be a separate interfa=
ce equivalent std::static_type_info<T> class template that provides t=
hese functions as static functions or variables - or, more likely, that all=
three would be three separate type traits in the usual form.</font></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_151_19220289.1396121197408--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 29 Mar 2014 19:50:15 -0700 (PDT)
Raw View
------=_Part_1550_24763508.1396147815293
Content-Type: text/plain; charset=UTF-8
On Sunday, March 30, 2014 3:26:37 AM UTC+8, Andrew Tomazos wrote:
>
>
> The current run-time equivalent use cases of the minimum functionality
> (name, hashable, comparable) are roughly:
>
I see that you changed some consts to constexprs between these two
illustrations, but I don't get what you're trying to illustrate.
> If type_id_number<T> is feasible the later two could be implemented pure
> library as:
>
Obviously we can't have a perfect hash of types to integers because
integers are bounded and types aren't.
> typeid strips the cv-qualifiers and reference from the type, we would like
> to leave them to the user to decide whether to apply the appropriate remove
> traits.
>
They won't be stripped if inside a template argument, so I'd recommend
taking the id of identity< T > in the corner cases where you want to
preserve top-level reference and const. Also note that expressions don't
have reference type and scalar expressions don't have top-level const;
those things are only re-added by decltype.
> typeid also returns a reference, so requiring that this be a reference
> constant expression could interact badly with the dynamic version of
> typeid.
>
It returns an lvalue; expressions don't have reference type. Presumably
it's already a reference constant expressions since it's allowed in a
constant expression, but this point should be clarified.
> Also specifying std::type_info as a literal type when it is polymorphic is
> non-trivial.
>
type_info does not behave differently for polymorphic types. They have more
internal RTTI properties but I don't see the relevance or the problem.
> My current feeling about this is that there might be a separate interface
> equivalent std::static_type_info<T> class template that provides these
> functions as static functions or variables - or, more likely, that all
> three would be three separate type traits in the usual form.
>
Why not let std::static_type_info<T> be a variable template of invariant
type? It seems like the application for which variable templates were
invented.
The type_info objects from various TUs would need to be merged. This
problem is why typeid has slightly weird semantics. But it seems it already
must be solved for a platform to support variable templates, so maybe typeidshould be tidied up as well.
--
---
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_1550_24763508.1396147815293
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, March 30, 2014 3:26:37 AM UTC+8, Andrew=
Tomazos 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=
"><br><div>The current run-time equivalent use cases of the minimum functio=
nality (name, hashable, comparable) are roughly:</div></div></blockquote><d=
iv><br>I see that you changed some <span style=3D"font-family: courier new,=
monospace;">const</span>s to <span style=3D"font-family: courier new,monosp=
ace;">constexpr</span>s between these two illustrations, but I don't get wh=
at you're trying to illustrate.<br> </div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr">If <font face=3D"courier new, monospace">=
type_id_number<T></font> is feasible the later two could be implement=
ed pure library as:</div></blockquote><div><br>Obviously we can't have a pe=
rfect hash of types to integers because integers are bounded and types aren=
't.<br> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><font face=3D"arial, sans-serif">typeid strips the cv-qualifiers and =
reference from the type, we would like to leave them to the user to decide =
whether to apply the appropriate remove traits. </font></div></blockq=
uote><div><br>They won't be stripped if inside a template argument, so I'd =
recommend taking the id of <span style=3D"font-family: courier new,monospac=
e;">identity< T ></span> in the corner cases where you want to preser=
ve top-level reference and const. Also note that expressions don't have ref=
erence type and scalar expressions don't have top-level const; those things=
are only re-added by <span style=3D"font-family: courier new,monospace;">d=
ecltype</span>.<br> </div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><font face=3D"arial, sans-serif">typeid also returns a re=
ference, so requiring that this be a reference constant expression could in=
teract badly with the dynamic version of typeid. </font></div></block=
quote><div><br>It returns an lvalue; expressions don't have reference type.=
Presumably it's already a reference constant expressions since it's allowe=
d in a constant expression, but this point should be clarified.<br> </=
div><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"><font fac=
e=3D"arial, sans-serif">Also specifying std::type_info as a literal type wh=
en it is polymorphic is non-trivial. </font></div></blockquote><div><=
br><span style=3D"font-family: courier new,monospace;">type_info</span> doe=
s not behave differently for polymorphic types. They have more internal RTT=
I properties but I don't see the relevance or the problem. <br> <br></=
div><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"><font fac=
e=3D"arial, sans-serif">My current feeling about this is that there might b=
e a separate interface equivalent std::static_type_info<T> class temp=
late that provides these functions as static functions or variables - or, m=
ore likely, that all three would be three separate type traits in the usual=
form.</font></div></blockquote><div><br>Why not let <span style=3D"font-fa=
mily: courier new,monospace;">std::static_type_info<T></span> be a va=
riable template of invariant type? It seems like the application for which =
variable templates were invented.<br><br>The <span style=3D"font-family: co=
urier new,monospace;">type_info</span> objects from various TUs would need =
to be merged. This problem is why <span style=3D"font-family: courier new,m=
onospace;">typeid</span> has slightly weird semantics. But it seems it alre=
ady must be solved for a platform to support variable templates, so maybe <=
span style=3D"font-family: courier new,monospace;">typeid</span> should be =
tidied up as well.<br><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_1550_24763508.1396147815293--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 29 Mar 2014 19:57:03 -0700 (PDT)
Raw View
------=_Part_637_18163554.1396148223814
Content-Type: text/plain; charset=UTF-8
On Sunday, March 30, 2014 10:50:15 AM UTC+8, David Krauss wrote:
>
>
> The type_info objects from various TUs would need to be merged. This
> problem is why typeid has slightly weird semantics. But it seems it
> already must be solved for a platform to support variable templates, so
> maybe typeid should be tidied up as well.
>
To be clear: variable templates solve the compile-time identifier-value
issue, because you can use the address of the variable template
instantiation.
You just can't use relative comparisons on the addresses, or cast to
intptr_t in a constant expression.
My impression is that hash_value already just gives you a suitably casted
address of a typeinfo object. The easiest way out of all this is probably
just to verify that's a suitable spec, and specify it just as such.
--
---
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_637_18163554.1396148223814
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, March 30, 2014 10:50:15 AM UTC+8, David=
Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><br>The <span style=3D"font-family:courier new,monospace">type_info</span>=
objects from various TUs would need to be merged. This problem is why <spa=
n style=3D"font-family:courier new,monospace">typeid</span> has slightly we=
ird semantics. But it seems it already must be solved for a platform to sup=
port variable templates, so maybe <span style=3D"font-family:courier new,mo=
nospace">typeid</span> should be tidied up as well.<br></div></blockquote><=
div><br>To be clear: variable templates solve the compile-time identifier-v=
alue issue, because you can use the address of the variable template instan=
tiation.<br><br>You just can't use relative comparisons on the addresses, o=
r cast to <span style=3D"font-family: courier new,monospace;">intptr_t</spa=
n> in a constant expression.<br><br>My impression is that <span style=3D"fo=
nt-family: courier new,monospace;">hash_value</span> already just gives you=
a suitably casted address of a <span style=3D"font-family: courier new,mon=
ospace;">typeinfo</span> object. The easiest way out of all this is probabl=
y just to verify that's a suitable spec, and specify it just as such.<br><b=
r></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_637_18163554.1396148223814--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 30 Mar 2014 13:19:15 +0800
Raw View
--Apple-Mail=_A4F772F4-44B1-406C-8EB4-C25ED9F89E31
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-03-30, at 10:57 AM, David Krauss <potswa@gmail.com> wrote:
> My impression is that hash_value already just gives you a suitably casted=
address of a typeinfo object. The easiest way out of all this is probably =
just to verify that's a suitable spec, and specify it just as such.
Oh. I have been dancing around the problem that hash_value may computed by =
the linker or loader.
For what it's worth, I don't see what a global "small" serial number for al=
l types solves anyway, because it will get big when someone else uses the f=
acility more heavily.
A well-behaved introspective type-map enumerates its contents, and then you=
can use my overload-set counting. Asking template instantiations in two TU=
s to form a relative ordering is a tall order though. It could probably be =
done with an export template model but otherwise it seems contrary to the f=
undamentals.
As for solving the problem at hand, rather than mucking about with compile =
time strings, it might be better to make constexpr typeinfo::operator=3D=3D=
and before. The latter forces the collation order not to depend on address=
es though, but rather something like strcmp. To avoid disturbing ABIs, it m=
ight be better to introduce operator< instead with a potentially different =
ordering. (While we're at it, make it a non-member!)
To be clear:
before may be faster at runtime because addresses are available, but cannot=
be constexpr.
operator< may be slow at runtime yet may be constexpr.
An implementation of operator=3D=3D would want to use operator< at compile =
time and before at runtime.
Anyone have a better idea?
--=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=_A4F772F4-44B1-406C-8EB4-C25ED9F89E31
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;03–30, at 10:57 AM, David Krauss <<a href=3D"mailto:potswa@g=
mail.com">potswa@gmail.com</a>> wrote:</div><br class=3D"Apple-interchan=
ge-newline"><blockquote type=3D"cite"><div dir=3D"ltr">My impression is tha=
t <span style=3D"font-family: 'courier new', monospace;">hash_value</span> =
already just gives you a suitably casted address of a <span style=3D"font-f=
amily: 'courier new', monospace;">typeinfo</span> object. The easiest way o=
ut of all this is probably just to verify that's a suitable spec, and speci=
fy it just as such.</div></blockquote><br></div><div>Oh. I have been dancin=
g around the problem that <font face=3D"Courier">hash_value</font> may comp=
uted by the linker or loader.</div><br><div>For what it’s worth, I do=
n’t see what a global “small” serial number for all types=
solves anyway, because it will get big when someone else uses the facility=
more heavily.</div><div><br></div><div>A well-behaved introspective type-m=
ap enumerates its contents, and then you can use my overload-set counting. =
Asking template instantiations in two TUs to form a relative ordering is a =
tall order though. It could probably be done with an <font face=3D"Cou=
rier">export</font> template model but otherwise it seems contrary to the f=
undamentals.</div><div><br></div><div>As for solving the problem at hand, r=
ather than mucking about with compile time strings, it might be better to m=
ake <font face=3D"Courier">constexpr typeinfo::operator=3D=3D</font> a=
nd <font face=3D"Courier">before</font>. The latter forces the collation or=
der not to depend on addresses though, but rather something like <font face=
=3D"Courier">strcmp</font>. To avoid disturbing ABIs, it might be better to=
introduce <font face=3D"Courier">operator<</font> instead with a p=
otentially different ordering. (While we’re at it, make it a non-memb=
er!)</div><div><br></div><div>To be clear:</div><div><br></div><div><ul cla=
ss=3D"MailOutline"><li><font face=3D"Courier">before</font> may be faster a=
t runtime because addresses are available, but cannot be <font face=3D"Cour=
ier">constexpr</font>.</li><li><font face=3D"Courier">operator<</font> m=
ay be slow at runtime yet may be <font face=3D"Courier">constexpr</font>.</=
li><li>An implementation of <font face=3D"Courier">operator=3D=3D</fon=
t> would want to use <font face=3D"Courier">operator<</font> at com=
pile time and <font face=3D"Courier">before</font> at runtime.</li></ul><di=
v><br></div></div><div>Anyone have a better idea?</div><div><br></div></bod=
y></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=_A4F772F4-44B1-406C-8EB4-C25ED9F89E31--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sun, 30 Mar 2014 04:18:07 -0700 (PDT)
Raw View
------=_Part_41_11368506.1396178287066
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, March 30, 2014 4:50:15 AM UTC+2, David Krauss wrote:
>
> On Sunday, March 30, 2014 3:26:37 AM UTC+8, Andrew Tomazos wrote:
>>
>> If type_id_number<T> is feasible the later two could be implemented pure=
=20
>> library as:
>>
>
> Obviously we can't have a perfect hash of types to integers because=20
> integers are bounded and types aren't.
>
Within a single program there are going to be less than 2^32 types, but I=
=20
think might be right that type_id_number<T> can't be calculated until=20
link/load time, so can't be an integer constant expression.
=20
> typeid strips the cv-qualifiers and reference from the type, we would lik=
e=20
>> to leave them to the user to decide whether to apply the appropriate rem=
ove=20
>> traits. =20
>>
>
> They won't be stripped if inside a template argument, so I'd recommend=20
> taking the id of identity< T > in the corner cases where you want to=20
> preserve top-level reference and const. Also note that expressions don't=
=20
> have reference type and scalar expressions don't have top-level const;=20
> those things are only re-added by decltype.
>
That would be a reasonable workaround, but I'll still need to consider how=
=20
it appears within the reflection use cases and next to type traits. My=20
sense is that reflecting const and reference will be common enough to=20
warrant being the default.
=20
> typeid also returns a reference, so requiring that this be a reference=20
>> constant expression could interact badly with the dynamic version of=20
>> typeid. =20
>>
>
> It returns an lvalue; expressions don't have reference type. Presumably=
=20
> it's already a reference constant expressions since it's allowed in a=20
> constant expression, but this point should be clarified.
>
=20
Yes fine, that is what I meant, it is an lvalue in a constant expression.=
=20
This can cause problems.
Also specifying std::type_info as a literal type when it is polymorphic is=
=20
>> non-trivial. =20
>>
>
> type_info does not behave differently for polymorphic types. They have=20
> more internal RTTI properties but I don't see the relevance or the proble=
m.=20
>
I meant std::type_info can be itself a polymorphic type, but actually this=
=20
may be wrong. It can be a base class of some derived type.
=20
> My current feeling about this is that there might be a separate interface=
=20
>> equivalent std::static_type_info<T> class template that provides these=
=20
>> functions as static functions or variables - or, more likely, that all=
=20
>> three would be three separate type traits in the usual form.
>>
>
> Why not let std::static_type_info<T> be a variable template of invariant=
=20
> type? It seems like the application for which variable templates were=20
> invented.
>
=20
For presentation, given the integral ID isn't feasible, the current=20
front-runner is three separate type traits (one for type name, one for type=
=20
hash and the other for type less). You can then compose them however you=
=20
want.
To be clear: variable templates solve the compile-time identifier-value=20
> issue, because you can use the address of the variable template=20
> instantiation.
>
Well you can already get a per-type address constant expression with:
template<class T> int x;
template<class T> constexpr int* p =3D &x<T>;
But you can't hash it or compare it in a constant expression, so it doesn't=
=20
solve the problem.
As for solving the problem at hand, rather than mucking about with compile=
=20
> time strings, it might be better to make constexpr typeinfo::operator=3D=
=3D
> and before. The latter forces the collation order not to depend on=20
> addresses though, but rather something like strcmp. To avoid disturbing=
=20
> ABIs, it might be better to introduce operator< instead with a=20
> potentially different ordering. (While we=E2=80=99re at it, make it a non=
-member!)
I guess my current design would have `std::is_less<A,B>` next to=20
`std::is_same<A,B>` where is_less is implementation-defined, but in=20
practice may be based on mangling the type to a string and using a lexical=
=20
comparison. The same string could be hashed to provide `std::hash_type<T>`=
..
I think keeping it separate from std::type_info is the better approach=20
given the clearly different environments of compile-time and run-time. You=
=20
can always compose the primitives and build out a system that can be shared=
=20
with run-time if you so desire.=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_41_11368506.1396178287066
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, March 30, 2014 4:50:15 AM UTC+2, David Krauss w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Sunda=
y, March 30, 2014 3:26:37 AM UTC+8, Andrew Tomazos wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">If <font face=3D"courier new, monos=
pace">type_id_number<T></font> is feasible the later two could be imp=
lemented pure library as:<br></div></blockquote><div><br>Obviously we can't=
have a perfect hash of types to integers because integers are bounded and =
types aren't.<br></div></div></blockquote><div><br></div><div>Within a sing=
le program there are going to be less than 2^32 types, but I think might be=
right that type_id_number<T> can't be calculated until link/load tim=
e, so can't be an integer constant expression.</div><div> </div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><font face=3D"arial, sans-serif=
">typeid strips the cv-qualifiers and reference from the type, we would lik=
e to leave them to the user to decide whether to apply the appropriate remo=
ve traits. </font></div></blockquote><div><br>They won't be stripped =
if inside a template argument, so I'd recommend taking the id of <span styl=
e=3D"font-family:courier new,monospace">identity< T ></span> in the c=
orner cases where you want to preserve top-level reference and const. Also =
note that expressions don't have reference type and scalar expressions don'=
t have top-level const; those things are only re-added by <span style=3D"fo=
nt-family:courier new,monospace">decltype</span>.<br></div></div></blockquo=
te><div><br></div><div>That would be a reasonable workaround, but I'll stil=
l need to consider how it appears within the reflection use cases and next =
to type traits. My sense is that reflecting const and reference will =
be common enough to warrant being the default.</div><div> </div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><font face=3D"arial, sans-serif">ty=
peid also returns a reference, so requiring that this be a reference consta=
nt expression could interact badly with the dynamic version of typeid. &nbs=
p;</font></div></blockquote><div><br>It returns an lvalue; expressions don'=
t have reference type. Presumably it's already a reference constant express=
ions since it's allowed in a constant expression, but this point should be =
clarified.<br></div></div></blockquote><div> </div><div>Yes fine, that=
is what I meant, it is an lvalue in a constant expression. This can =
cause problems.</div><div><br></div><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"><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"><font face=3D"arial, sans-serif">Also specifying std::type_info as a l=
iteral type when it is polymorphic is non-trivial. </font></div></blo=
ckquote><div><br><span style=3D"font-family:courier new,monospace">type_inf=
o</span> does not behave differently for polymorphic types. They have more =
internal RTTI properties but I don't see the relevance or the problem. <br>=
</div></div></blockquote><div><br></div><div>I meant std::type_info can be =
itself a polymorphic type, but actually this may be wrong. It can be =
a base class of some derived type.</div><div> <br></div><blockquote cl=
ass=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><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><font face=3D"arial, sans-serif">M=
y current feeling about this is that there might be a separate interface eq=
uivalent std::static_type_info<T> class template that provides these =
functions as static functions or variables - or, more likely, that all thre=
e would be three separate type traits in the usual form.</font></div></bloc=
kquote><div><br>Why not let <span style=3D"font-family:courier new,monospac=
e">std::static_type_info<T></span> be a variable template of invarian=
t type? It seems like the application for which variable templates were inv=
ented.<br></div></div></blockquote><div> </div><div>For presentation, =
given the integral ID isn't feasible, the current front-runner is three sep=
arate type traits (one for type name, one for type hash and the other for t=
ype less). You can then compose them however you want.</div><div><br>=
</div><div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border=
-left-style: solid; padding-left: 1ex;">To be clear: variable templates sol=
ve the compile-time identifier-value issue, because you can use the address=
of the variable template instantiation.<br></blockquote><div><br></div><di=
v>Well you can already get a per-type address constant expression with:</di=
v><div><br></div><div> template<class T> int x;</div></d=
iv><div> template<class T> constexpr int* p =3D &x&l=
t;T>;</div><div><br></div><div>But you can't hash it or compare it in a =
constant expression, so it doesn't solve the problem.</div><div><br></div><=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; b=
order-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-s=
tyle: solid; padding-left: 1ex;">As for solving the problem at hand, rather=
than mucking about with compile time strings, it might be better to make&n=
bsp;<font face=3D"Courier">constexpr typeinfo::operator=3D=3D</font> a=
nd <font face=3D"Courier">before</font>. The latter forces the collati=
on order not to depend on addresses though, but rather something like =
<font face=3D"Courier">strcmp</font>. To avoid disturbing ABIs, it might be=
better to introduce <font face=3D"Courier">operator<</font> i=
nstead with a potentially different ordering. (While we=E2=80=99re at it, m=
ake it a non-member!)</blockquote></div><div><br></div><div>I guess my curr=
ent design would have `std::is_less<A,B>` next to `std::is_same<A,=
B>` where is_less is implementation-defined, but in practice may be base=
d on mangling the type to a string and using a lexical comparison. Th=
e same string could be hashed to provide `std::hash_type<T>`.</div><d=
iv><br></div><div>I think keeping it separate from std::type_info is the be=
tter approach given the clearly different environments of compile-time and =
run-time. You can always compose the primitives and build out a syste=
m that can be shared with run-time if you so desire. </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_41_11368506.1396178287066--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 30 Mar 2014 11:47:40 -0700
Raw View
Em dom 30 mar 2014, =E0s 04:18:07, Andrew Tomazos escreveu:
> I meant std::type_info can be itself a polymorphic type, but actually thi=
s=20
> may be wrong. It can be a base class of some derived type.
And it is in the portable C++ ABI.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=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/.
.