------=_Part_39_2047791.1404962804015
Content-Type: text/plain; charset=UTF-8

I think that it would be nice if typeid(T) for type T and typeid(X) for
compile-time constant expression X would return something considered to be
a compile-time constant expression itself, such as what amounts to a const
reference to a "__declspec(selectany) extern const std::type_info" global,
to use Microsoft "selectany" terminology.  Then, have the name(), before(),
==() and !=() member functions be constexpr as well.

This would allow the compile-time acquisition of type names as strings
without using macros.

hashcode() is possible to be a constexpr as well, but there are a few
reasons to not allow this; prevention of denial-of-service attacks is one
reason that hashcode() may return different values each run of a program,
and making it a constexpr would break that.

Melissa

--

---
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_39_2047791.1404962804015
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think that it would be nice if typeid(T) for type T and =
typeid(X) for compile-time constant expression X would return something con=
sidered to be a compile-time constant expression itself, such as what amoun=
ts to a const reference to a "__declspec(selectany) extern const std::type_=
info" global, to use Microsoft "selectany" terminology.&nbsp; Then, have th=
e name(), before(), =3D=3D() and !=3D() member functions be constexpr as we=
ll.<br><br>This would allow the compile-time acquisition of type names as s=
trings without using macros.<br><br>hashcode() is possible to be a constexp=
r as well, but there are a few reasons to not allow this; prevention of den=
ial-of-service attacks is one reason that hashcode() may return different v=
alues each run of a program, and making it a constexpr would break that.<br=
><br>Melissa<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&quot; 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_39_2047791.1404962804015--

.

--001a1135e1dc82693e04fdce8e95
Content-Type: text/plain; charset=UTF-8

This is something we've been working on over at SG7:
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/reflection

We would welcome a formal proposal and reference implementation something
like a constexpr std::type_info.  I studied it and concluded that
"upgrading" std::type_info without breaking changes would be a hassle, so
the latest idea was to have a TextTrait (see N4113) called
std::type_name<T>.  To streamline N4113 I removed std::type_name<T>, so if
you want to take a run at it you would be welcome.

For the constant expression (rather than type) version you could use
std::type_name<decltype(X)>.  The idea was that the name would also be
comparable (before) and hashable (hashcode).

If you're interested write up a paper (for constexpr std::type_info or
std::type_name<T> or something else) and post it to the previously linked
SG7 reflector.

Cheers,
Andrew.




On Thu, Jul 10, 2014 at 5:26 AM, Myriachan <myriachan@gmail.com> wrote:

> I think that it would be nice if typeid(T) for type T and typeid(X) for
> compile-time constant expression X would return something considered to be
> a compile-time constant expression itself, such as what amounts to a const
> reference to a "__declspec(selectany) extern const std::type_info" global,
> to use Microsoft "selectany" terminology.  Then, have the name(), before(),
> ==() and !=() member functions be constexpr as well.
>
> This would allow the compile-time acquisition of type names as strings
> without using macros.
>
> hashcode() is possible to be a constexpr as well, but there are a few
> reasons to not allow this; prevention of denial-of-service attacks is one
> reason that hashcode() may return different values each run of a program,
> and making it a constexpr would break that.
>
> Melissa
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1135e1dc82693e04fdce8e95
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This is something we&#39;ve been working on over at SG7:=
=C2=A0<a href=3D"https://groups.google.com/a/isocpp.org/forum/?fromgroups#!=
forum/reflection">https://groups.google.com/a/isocpp.org/forum/?fromgroups#=
!forum/reflection</a><div>
<br></div><div>We would welcome a formal proposal and reference implementat=
ion something like a constexpr std::type_info. =C2=A0I studied it and concl=
uded that &quot;upgrading&quot; std::type_info without breaking changes wou=
ld be a hassle, so the latest idea was to have a TextTrait (see N4113) call=
ed std::type_name&lt;T&gt;. =C2=A0To streamline N4113 I removed std::type_n=
ame&lt;T&gt;, so if you want to take a run at it you would be welcome.</div=
>
<div><br></div><div>For the constant expression (rather than type) version =
you could use std::type_name&lt;decltype(X)&gt;. =C2=A0The idea was that th=
e name would also be comparable (before) and hashable (hashcode).</div><div=
>
<br></div><div>If you&#39;re interested write up a paper (for constexpr std=
::type_info or std::type_name&lt;T&gt; or something else) and post it to th=
e previously linked SG7 reflector.</div><div><br></div><div>Cheers,</div>
<div>Andrew.</div><div><br></div><div><br></div></div><div class=3D"gmail_e=
xtra"><br><br><div class=3D"gmail_quote">On Thu, Jul 10, 2014 at 5:26 AM, M=
yriachan <span dir=3D"ltr">&lt;<a href=3D"mailto:myriachan@gmail.com" targe=
t=3D"_blank">myriachan@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I think that it would be ni=
ce if typeid(T) for type T and typeid(X) for compile-time constant expressi=
on X would return something considered to be a compile-time constant expres=
sion itself, such as what amounts to a const reference to a &quot;__declspe=
c(selectany) extern const std::type_info&quot; global, to use Microsoft &qu=
ot;selectany&quot; terminology.=C2=A0 Then, have the name(), before(), =3D=
=3D() and !=3D() member functions be constexpr as well.<br>
<br>This would allow the compile-time acquisition of type names as strings =
without using macros.<br><br>hashcode() is possible to be a constexpr as we=
ll, but there are a few reasons to not allow this; prevention of denial-of-=
service attacks is one reason that hashcode() may return different values e=
ach run of a program, and making it a constexpr would break that.<br>
<br>Melissa<span class=3D"HOEnZb"><font color=3D"#888888"><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 the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</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&quot; 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 />

--001a1135e1dc82693e04fdce8e95--

.

--Apple-Mail=_81D65908-D872-45F4-96B2-6144A437CA2B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-10, at 11:38 AM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:

> This is something we've been working on over at SG7: https://groups.googl=
e.com/a/isocpp.org/forum/?fromgroups#!forum/reflection
>=20
> We would welcome a formal proposal and reference implementation something=
 like a constexpr std::type_info.  I studied it and concluded that "upgradi=
ng" std::type_info without breaking changes would be a hassle, so the lates=
t idea was to have a TextTrait (see N4113) called std::type_name<T>.  To st=
reamline N4113 I removed std::type_name<T>, so if you want to take a run at=
 it you would be welcome.

The problem is that type_info is (potentially) polymorphic, right? How much=
 resistance is there to fixing that problem at the source, and allowing pol=
ymorphic literal types?

--=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=_81D65908-D872-45F4-96B2-6144A437CA2B
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;07&ndash;10, at 11:38 AM, Andrew Tomazos &lt;<a href=3D"mailto:andrew=
tomazos@gmail.com">andrewtomazos@gmail.com</a>&gt; wrote:</div><br class=3D=
"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">This=
 is something we've been working on over at SG7:&nbsp;<a href=3D"https://gr=
oups.google.com/a/isocpp.org/forum/?fromgroups#!forum/reflection">https://g=
roups.google.com/a/isocpp.org/forum/?fromgroups#!forum/reflection</a><div>
<br></div><div>We would welcome a formal proposal and reference implementat=
ion something like a constexpr std::type_info. &nbsp;I studied it and concl=
uded that "upgrading" std::type_info without breaking changes would be a ha=
ssle, so the latest idea was to have a TextTrait (see N4113) called std::ty=
pe_name&lt;T&gt;. &nbsp;To streamline N4113 I removed std::type_name&lt;T&g=
t;, so if you want to take a run at it you would be welcome.</div></div></b=
lockquote><div><br></div><div>The problem is that <font face=3D"Courier">ty=
pe_info</font> is (potentially) polymorphic, right? How much resistance is =
there to fixing that problem at the source, and allowing polymorphic litera=
l types?</div></div><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&quot; 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=_81D65908-D872-45F4-96B2-6144A437CA2B--

.

--047d7b414042f7f70c04fdcfe54e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 10, 2014 at 6:17 AM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014=E2=80=9307=E2=80=9310, at 11:38 AM, Andrew Tomazos <andrewtomazos=
@gmail.com>
> wrote:
>
> This is something we've been working on over at SG7:
> https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/reflectio=
n
>
> We would welcome a formal proposal and reference implementation something
> like a constexpr std::type_info.  I studied it and concluded that
> "upgrading" std::type_info without breaking changes would be a hassle, so
> the latest idea was to have a TextTrait (see N4113) called
> std::type_name<T>.  To streamline N4113 I removed std::type_name<T>, so i=
f
> you want to take a run at it you would be welcome.
>
>
> The problem is that type_info is (potentially) polymorphic, right? How
> much resistance is there to fixing that problem at the source, and allowi=
ng
> polymorphic literal types?
>

I can't remember what the problem was now to be honest, I would need to
take another look at it.  I think it also had something to do with
comparing unrelated pointers.

As for adding polymorphic literal types, it doesn't seem that insane - but
judging by how conservative EWG is, there would have to be a pretty
thorough paper with an implementation to get any traction.

--=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/.

--047d7b414042f7f70c04fdcfe54e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jul 10, 2014 at 6:17 AM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div=
><div class=3D""><div>On 2014=E2=80=9307=E2=80=9310, at 11:38 AM, Andrew To=
mazos &lt;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andr=
ewtomazos@gmail.com</a>&gt; wrote:</div>
<br><blockquote type=3D"cite"><div dir=3D"ltr">This is something we&#39;ve =
been working on over at SG7:=C2=A0<a href=3D"https://groups.google.com/a/is=
ocpp.org/forum/?fromgroups#!forum/reflection" target=3D"_blank">https://gro=
ups.google.com/a/isocpp.org/forum/?fromgroups#!forum/reflection</a><div>

<br></div><div>We would welcome a formal proposal and reference implementat=
ion something like a constexpr std::type_info. =C2=A0I studied it and concl=
uded that &quot;upgrading&quot; std::type_info without breaking changes wou=
ld be a hassle, so the latest idea was to have a TextTrait (see N4113) call=
ed std::type_name&lt;T&gt;. =C2=A0To streamline N4113 I removed std::type_n=
ame&lt;T&gt;, so if you want to take a run at it you would be welcome.</div=
>
</div></blockquote><div><br></div></div><div>The problem is that <font face=
=3D"Courier">type_info</font> is (potentially) polymorphic, right? How much=
 resistance is there to fixing that problem at the source, and allowing pol=
ymorphic literal types?</div>
</div></div></blockquote><div><br></div><div>I can&#39;t remember what the =
problem was now to be honest, I would need to take another look at it. =C2=
=A0I think it also had something to do with comparing unrelated pointers.</=
div>
<div><br></div><div>As for adding polymorphic literal types, it doesn&#39;t=
 seem that insane - but judging by how conservative EWG is, there would hav=
e to be a pretty thorough paper with an implementation to get any traction.=
</div>
<div><br></div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />

--047d7b414042f7f70c04fdcfe54e--

.

2014-07-10 6:17 GMT+02:00 David Krauss <potswa@gmail.com>:
> The problem is that type_info is (potentially) polymorphic, right?

Right.

> How much
> resistance is there to fixing that problem at the source, and allowing
> polymorphic literal types?

The other alternative is to change type_info not to be polymorphic.
There exists a corresponding library issue for this,

http://cplusplus.github.io/LWG/lwg-active.html#2398

- Daniel

--

---
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/.

.

--001a1133812c7360da04fddd5efa
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 9, 2014 at 8:26 PM, Myriachan <myriachan@gmail.com> wrote:

> I think that it would be nice if typeid(T) for type T and typeid(X) for
> compile-time constant expression X would return something considered to be
> a compile-time constant expression itself,
>

In the interest of precision: this is already the case, unless X is a
glvalue of polymorphic class type. (The 'unless' clause here is
unnecessary, but EWG were unconvinced by my suggestion that it be removed.)

Then, have the name(), before(), ==() and !=() member functions be
> constexpr as well.
>

We can't do this for before() without breaking ABIs, because before()
orders by address of the type name in some implementations, and that's not
a compile time constant.

name(), ==(), and !=() present technical problems too, because
implementations use bit-fiddling tricks here that can't be directly modeled
in constexpr evaluation, but we can at least in principle support those
through compiler extensions.

This would allow the compile-time acquisition of type names as strings
> without using macros.
>
> hashcode() is possible to be a constexpr as well, but there are a few
> reasons to not allow this; prevention of denial-of-service attacks is one
> reason that hashcode() may return different values each run of a program,
> and making it a constexpr would break that.
>

hashcode() suffers the same problem as before(); in some implementations,
it just returns a pointer to the type name, cast to an integer type.

--

---
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/.

--001a1133812c7360da04fddd5efa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jul 9, 2014 at 8:26 PM, Myriachan <span dir=3D"ltr">&lt;<a href=3D"mail=
to:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>&gt;</span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I think that it would be ni=
ce if typeid(T) for type T and typeid(X) for compile-time constant expressi=
on X would return something considered to be a compile-time constant expres=
sion itself,</div>
</blockquote><div><br></div><div>In the interest of precision: this is alre=
ady the case, unless X is a glvalue of polymorphic class type. (The &#39;un=
less&#39; clause here is unnecessary, but EWG were unconvinced by my sugges=
tion that it be removed.)</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Then, have t=
he name(), before(), =3D=3D() and !=3D() member functions be constexpr as w=
ell.<br>
</div></blockquote><div><br></div><div>We can&#39;t do this for before() wi=
thout breaking ABIs, because before() orders by address of the type name in=
 some implementations, and that&#39;s not a compile time constant.</div>
<div><br></div><div>name(), =3D=3D(), and !=3D() present technical problems=
 too, because implementations use bit-fiddling tricks here that can&#39;t b=
e directly modeled in constexpr evaluation, but we can at least in principl=
e support those through compiler extensions.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">This would a=
llow the compile-time acquisition of type names as strings without using ma=
cros.<br>
<br>hashcode() is possible to be a constexpr as well, but there are a few r=
easons to not allow this; prevention of denial-of-service attacks is one re=
ason that hashcode() may return different values each run of a program, and=
 making it a constexpr would break that.</div>
</blockquote><div><br></div><div>hashcode() suffers the same problem as bef=
ore(); in some implementations, it just returns a pointer to the type name,=
 cast to an integer type.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />

--001a1133812c7360da04fddd5efa--

.

------=_Part_1182_24028135.1405218522925
Content-Type: text/plain; charset=UTF-8

On Thursday, July 10, 2014 2:18:42 PM UTC-7, Richard Smith wrote:
>
> On Wed, Jul 9, 2014 at 8:26 PM, Myriachan <myri...@gmail.com <javascript:>
> > wrote:
>
>> Then, have the name(), before(), ==() and !=() member functions be
>> constexpr as well.
>>
>
> We can't do this for before() without breaking ABIs, because before()
> orders by address of the type name in some implementations, and that's not
> a compile time constant.
>
> name(), ==(), and !=() present technical problems too, because
> implementations use bit-fiddling tricks here that can't be directly modeled
> in constexpr evaluation, but we can at least in principle support those
> through compiler extensions.
>
>>
name, operator == and operator != in principle all could be implemented if
it were possible to overload on whether the functions were called in a
constexpr context (__builtin_constant_p?) even if the runtime
implementation were significantly more complicated.  operator ==() and
operator !=() are just std::is_same, and name() could be implemented
several different ways.

This would allow the compile-time acquisition of type names as strings
>> without using macros.
>>
>> hashcode() is possible to be a constexpr as well, but there are a few
>> reasons to not allow this; prevention of denial-of-service attacks is one
>> reason that hashcode() may return different values each run of a program,
>> and making it a constexpr would break that.
>>
>
> hashcode() suffers the same problem as before(); in some implementations,
> it just returns a pointer to the type name, cast to an integer type.
>

I agree that hashcode() and before() are significantly harder; they're also
significantly less important to have available in constexpr-context.

Melissa

--

---
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_1182_24028135.1405218522925
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, July 10, 2014 2:18:42 PM UTC-7, Richard Smith=
 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"><div><=
div class=3D"gmail_quote">On Wed, Jul 9, 2014 at 8:26 PM, Myriachan <span d=
ir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"pZlRAatqdUUJ" onmousedown=3D"this.href=3D'javascript:';return true;"=
 onclick=3D"this.href=3D'javascript:';return true;">myri...@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Then, h=
ave the name(), before(), =3D=3D() and !=3D() member functions be constexpr=
 as well.<br>
</div></blockquote><div><br></div><div>We can't do this for before() withou=
t breaking ABIs, because before() orders by address of the type name in som=
e implementations, and that's not a compile time constant.</div>
<div><br></div><div>name(), =3D=3D(), and !=3D() present technical problems=
 too, because implementations use bit-fiddling tricks here that can't be di=
rectly modeled in constexpr evaluation, but we can at least in principle su=
pport those through compiler extensions.</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"></div></blockquote></div></=
div></div></blockquote><div><br>name, operator =3D=3D and operator !=3D in =
principle all could be implemented if it were possible to overload on wheth=
er the functions were called in a constexpr context (__builtin_constant_p?)=
 even if the runtime implementation were significantly more complicated.&nb=
sp; operator =3D=3D() and operator !=3D() are just std::is_same, and name()=
 could be implemented several different ways.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">This would allow the com=
pile-time acquisition of type names as strings without using macros.<br>
<br>hashcode() is possible to be a constexpr as well, but there are a few r=
easons to not allow this; prevention of denial-of-service attacks is one re=
ason that hashcode() may return different values each run of a program, and=
 making it a constexpr would break that.</div>
</blockquote><div><br></div><div>hashcode() suffers the same problem as bef=
ore(); in some implementations, it just returns a pointer to the type name,=
 cast to an integer type.</div></div></div></div></blockquote><div><br>I ag=
ree that hashcode() and before() are significantly harder; they're also sig=
nificantly less important to have available in constexpr-context. <br><br>M=
elissa<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&quot; 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_1182_24028135.1405218522925--

.

--20cf30434804fe8acf04fe0a38e7
Content-Type: text/plain; charset=UTF-8

On Sun, Jul 13, 2014 at 4:28 AM, Myriachan <myriachan@gmail.com> wrote:

> This would allow the compile-time acquisition of type names as strings
>>> without using macros.
>>>
>>> hashcode() is possible to be a constexpr as well, but there are a few
>>> reasons to not allow this; prevention of denial-of-service attacks is one
>>> reason that hashcode() may return different values each run of a program,
>>> and making it a constexpr would break that.
>>>
>>
>> hashcode() suffers the same problem as before(); in some implementations,
>> it just returns a pointer to the type name, cast to an integer type.
>>
>
> I agree that hashcode() and before() are significantly harder; they're
> also significantly less important to have available in constexpr-context.
>
> Ahhh, no.  The utility of before and hashcode is the same at compile-time
as at run-time.  For example if you want to have a compile-time data
structure keyed by type (sorted array, binary tree, hash table, etc).  If
you only have equality then you have to linear search for a type in a type
list.  Also consider the case where you want to prepare one of the above
data structures at compile-time for use at run-time.  You need access to
(the same) before/hash functions in order to lay it out.

--

---
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/.

--20cf30434804fe8acf04fe0a38e7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sun, Jul 13, 2014 at 4:28 AM, Myriachan <span dir=3D"lt=
r">&lt;<a href=3D"mailto:myriachan@gmail.com" target=3D"_blank">myriachan@g=
mail.com</a>&gt;</span> wrote: <br><div class=3D"gmail_extra"><div class=3D=
"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div class=3D"">=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">This would allow the compile-time acquisition of type=
 names as strings without using macros.<br>

<br>hashcode() is possible to be a constexpr as well, but there are a few r=
easons to not allow this; prevention of denial-of-service attacks is one re=
ason that hashcode() may return different values each run of a program, and=
 making it a constexpr would break that.</div>

</blockquote><div><br></div><div>hashcode() suffers the same problem as bef=
ore(); in some implementations, it just returns a pointer to the type name,=
 cast to an integer type.</div></div></div></div></blockquote></div><div>
<br>I agree that hashcode() and before() are significantly harder; they&#39=
;re also significantly less important to have available in constexpr-contex=
t. <br><br></div></div></blockquote></div>Ahhh, no.=C2=A0 The utility of be=
fore and hashcode is the same at compile-time as at run-time.=C2=A0 For exa=
mple if you want to have a compile-time data structure keyed by type (sorte=
d array, binary tree, hash table, etc).=C2=A0 If you only have equality the=
n you have to linear search for a type in a type list.=C2=A0 Also consider =
the case where you want to prepare one of the above data structures at comp=
ile-time for use at run-time.=C2=A0 You need access to (the same) before/ha=
sh functions in order to lay it out.<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&quot; 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 />

--20cf30434804fe8acf04fe0a38e7--

.

--Apple-Mail=_44D75D2E-B340-4B4C-A029-08DD37CB0A6A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-11, at 5:18 AM, Richard Smith <richard@metafoo.co.uk> wrote:

> name(), =3D=3D(), and !=3D() present technical problems too, because impl=
ementations use bit-fiddling tricks here that can't be directly modeled in =
constexpr evaluation, but we can at least in principle support those throug=
h compiler extensions.


Let those be implemented as intrinsics, discriminating runtime from compile=
 time. For implementations that guarantee uniqueness of type_info objects, =
comparing pointer identity is already constexpr safe. (I have deja vu on th=
is suggestion.)

GCC accepts this but Clang complains "not an integral constant expression."=
 Why?

static_assert ( & typeid( int ) =3D=3D & typeid( int ), "" );


On 2014-07-13, at 10:49 AM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:

> On Sun, Jul 13, 2014 at 4:28 AM, Myriachan <myriachan@gmail.com> wrote:=
=20
>=20
> I agree that hashcode() and before() are significantly harder; they're al=
so significantly less important to have available in constexpr-context.=20
>=20
> Ahhh, no.  The utility of before and hashcode is the same at compile-time=
 as at run-time.  For example if you want to have a compile-time data struc=
ture keyed by type (sorted array, binary tree, hash table, etc).  If you on=
ly have equality then you have to linear search for a type in a type list. =
 Also consider the case where you want to prepare one of the above data str=
uctures at compile-time for use at run-time.  You need access to (the same)=
 before/hash functions in order to lay it out.

It is unfortunate, but the root problem is unfixable, so we might as well w=
ork within the set limits.

Right now, hash_code is not required to be unique per type (N3936 =A718.7.1=
/8 only says "should"). Normatively we have the freedom to require an imper=
fect hash function at compile time (carried over to runtime), but this is a=
 non-starter because programs already depend on the common implementations =
providing uniqueness.

Perhaps a truly imperfect hash should be added by a new interface. ABIs and=
 individual metaprograms can sort out the gory usage details, but it's no w=
orse than things have always been, in terms of standardization. The spec of=
 hash_code might be adjusted to require a perfect hash, or maybe not, if an=
y remaining current ABIs don't use the pointer trick. Either way, uniquenes=
s should be an implementation-specified property since it's so common.

--=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=_44D75D2E-B340-4B4C-A029-08DD37CB0A6A
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;"><div><br></div><div><d=
iv>On 2014&ndash;07&ndash;11, at 5:18 AM, Richard Smith &lt;<a href=3D"mail=
to:richard@metafoo.co.uk">richard@metafoo.co.uk</a>&gt; wrote:</div><br cla=
ss=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"=
><div class=3D"gmail_extra"><div class=3D"gmail_quote">name(), =3D=3D(), an=
d !=3D() present technical problems too, because implementations use bit-fi=
ddling tricks here that can't be directly modeled in constexpr evaluation, =
but we can at least in principle support those through compiler extensions.=
</div></div></div></blockquote></div><div><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">=
Let those be implemented as intrinsics, discriminating runtime from compile=
 time. For implementations that guarantee uniqueness of <font face=3D"Couri=
er">type_info</font> objects, comparing pointer identity is already constex=
pr safe. (I have deja vu on this suggestion.)</div><div class=3D"gmail_quot=
e"><br></div><div class=3D"gmail_quote">GCC accepts this but Clang complain=
s "not an integral constant expression." Why?</div><div class=3D"gmail_quot=
e"><br></div><div class=3D"gmail_quote"><font face=3D"Courier">static_asser=
t ( &amp; typeid( int ) =3D=3D &amp; typeid( int ), "" );</font><br><br></d=
iv></div></div></div><br><div><div>On 2014&ndash;07&ndash;13, at 10:49 AM, =
Andrew Tomazos &lt;<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos=
@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><blo=
ckquote type=3D"cite"><div dir=3D"ltr">On Sun, Jul 13, 2014 at 4:28 AM, Myr=
iachan <span dir=3D"ltr">&lt;<a href=3D"mailto:myriachan@gmail.com" target=
=3D"_blank">myriachan@gmail.com</a>&gt;</span> wrote: <br><div class=3D"gma=
il_extra"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex; position: static; z-index: auto;"><div dir=3D"l=
tr"><div></div><div class=3D""></div><div>
<br>I agree that hashcode() and before() are significantly harder; they're =
also significantly less important to have available in constexpr-context. <=
br><br></div></div></blockquote></div>Ahhh, no.&nbsp; The utility of before=
 and hashcode is the same at compile-time as at run-time.&nbsp; For example=
 if you want to have a compile-time data structure keyed by type (sorted ar=
ray, binary tree, hash table, etc).&nbsp; If you only have equality then yo=
u have to linear search for a type in a type list.&nbsp; Also consider the =
case where you want to prepare one of the above data structures at compile-=
time for use at run-time.&nbsp; You need access to (the same) before/hash f=
unctions in order to lay it out.<br></div></div></blockquote><div><br></div=
></div>It is unfortunate, but the root problem is unfixable, so we might as=
 well work within the set limits.<div><br></div><div>Right now, <font face=
=3D"Courier">hash_code</font> is not required to be unique per type (N3936 =
=A718.7.1/8 only says &ldquo;should&rdquo;). Normatively we have the freedo=
m to require an imperfect hash function at compile time (carried over to ru=
ntime), but this is a non-starter because programs already depend on the co=
mmon implementations providing uniqueness.</div><div><br></div><div>Perhaps=
 a truly imperfect hash should be added by a new interface. ABIs and indivi=
dual metaprograms can sort out the gory usage details, but it&rsquo;s no wo=
rse than things have always been, in terms of standardization. The spec of =
<font face=3D"Courier">hash_code</font> might be adjusted to require a perf=
ect hash, or maybe not, if any remaining current ABIs don&rsquo;t use the p=
ointer trick. Either way, uniqueness should be an implementation-specified =
property since it&rsquo;s so common.</div><div><br></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&quot; 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=_44D75D2E-B340-4B4C-A029-08DD37CB0A6A--

.

------=_Part_744_12929982.1405228590240
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Sunday, July 13, 2014 6:39:02 AM UTC+2, David Krauss wrote:
>
>
> On 2014=E2=80=9307=E2=80=9311, at 5:18 AM, Richard Smith <ric...@metafoo.=
co.uk=20
> <javascript:>> wrote:
>
> name(), =3D=3D(), and !=3D() present technical problems too, because=20
> implementations use bit-fiddling tricks here that can't be directly model=
ed=20
> in constexpr evaluation, but we can at least in principle support those=
=20
> through compiler extensions.
>
>
> Let those be implemented as intrinsics, discriminating runtime from=20
> compile time. For implementations that guarantee uniqueness of type_info=
=20
> objects, comparing pointer identity is already constexpr safe. (I have de=
ja=20
> vu on this suggestion.)
>
> GCC accepts this but Clang complains "not an integral constant=20
> expression." Why?
>
> static_assert ( & typeid( int ) =3D=3D & typeid( int ), "" );
>
>
> On 2014=E2=80=9307=E2=80=9313, at 10:49 AM, Andrew Tomazos <andrew...@gma=
il.com=20
> <javascript:>> wrote:
>
> On Sun, Jul 13, 2014 at 4:28 AM, Myriachan <myri...@gmail.com=20
> <javascript:>> wrote:=20
>
>>
>> I agree that hashcode() and before() are significantly harder; they're=
=20
>> also significantly less important to have available in constexpr-context=
..=20
>>
>> Ahhh, no.  The utility of before and hashcode is the same at compile-tim=
e=20
> as at run-time.  For example if you want to have a compile-time data=20
> structure keyed by type (sorted array, binary tree, hash table, etc).  If=
=20
> you only have equality then you have to linear search for a type in a typ=
e=20
> list.  Also consider the case where you want to prepare one of the above=
=20
> data structures at compile-time for use at run-time.  You need access to=
=20
> (the same) before/hash functions in order to lay it out.
>
>
> It is unfortunate, but the root problem is unfixable, so we might as well=
=20
> work within the set limits.
>
=20

> Right now, hash_code is not required to be unique per type (N3936=20
> =C2=A718.7.1/8 only says =E2=80=9Cshould=E2=80=9D). Normatively we have t=
he freedom to require=20
> an imperfect hash function at compile time (carried over to runtime), but=
=20
> this is a non-starter because programs already depend on the common=20
> implementations providing uniqueness.
>
> Perhaps a truly imperfect hash should be added by a new interface. ABIs=
=20
> and individual metaprograms can sort out the gory usage details, but it=
=E2=80=99s=20
> no worse than things have always been, in terms of standardization. The=
=20
> spec of hash_code might be adjusted to require a perfect hash, or maybe=
=20
> not, if any remaining current ABIs don=E2=80=99t use the pointer trick. E=
ither way,=20
> uniqueness should be an implementation-specified property since it=E2=80=
=99s so=20
> common.
>

This sounds like it's reaching the same conclusion I came to.  Create a=20
new, completely separate system from std::type_info, for compile-time type=
=20
name, equality, comparison and hash.

Further, if we could have a std::type_name<T> compile-time string such that=
=20
std::type_name<A> =3D=3D std::type_name<B> iff std::is_same<A,B> - these=20
equality, comparison and hash functions could be simply the usual ones for=
=20
strings.  I think the sticking point here was encoding a unique ID within=
=20
the string to identify the translation unit, for types that didn't have=20
external linkage.  For example:

TU1:

    struct {} a1;

    char* s1 =3D std::type_name_v<decltype(a1);

TU2:

    struct {} a2;

    char* s2 =3D std::type_name_v<decltype(a2)>;

TU3:

    extern char *s1, *s2;

    int main()
    {
        assert(strcmp(s1, s2) !=3D 0);
    }

s1 and s2 must be different strings.  How shall they be formed?  If they=20
were from the same TU we could just use a counter.  We need a way to encode=
=20
the source TU identity at compile-time.  I thought of secure hashing the=20
TU, or similarly generating a random TU ID of sufficient size at=20
compile-time - but I haven't had much time to think about this further.


--=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_744_12929982.1405228590240
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, July 13, 2014 6:39:02 AM UTC+2, David K=
rauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word=
-wrap:break-word"><div><br></div><div><div>On 2014=E2=80=9307=E2=80=9311, a=
t 5:18 AM, Richard Smith &lt;<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"UaO27T-_sOIJ" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">ric...@me=
tafoo.co.uk</a>&gt; wrote:</div><br><blockquote type=3D"cite"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote">name(), =3D=3D(), and !=3D() present te=
chnical problems too, because implementations use bit-fiddling tricks here =
that can't be directly modeled in constexpr evaluation, but we can at least=
 in principle support those through compiler extensions.</div></div></div><=
/blockquote></div><div><div dir=3D"ltr"><div><div class=3D"gmail_quote"><br=
></div><div class=3D"gmail_quote">Let those be implemented as intrinsics, d=
iscriminating runtime from compile time. For implementations that guarantee=
 uniqueness of <font face=3D"Courier">type_info</font> objects, comparing p=
ointer identity is already constexpr safe. (I have deja vu on this suggesti=
on.)</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">G=
CC accepts this but Clang complains "not an integral constant expression." =
Why?</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><=
font face=3D"Courier">static_assert ( &amp; typeid( int ) =3D=3D &amp; type=
id( int ), "" );</font><br><br></div></div></div></div><br><div><div>On 201=
4=E2=80=9307=E2=80=9313, at 10:49 AM, Andrew Tomazos &lt;<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"UaO27T-_sOIJ" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">andrew...@gmail.com</a>&gt; wrote:</div><br><blockquote=
 type=3D"cite"><div dir=3D"ltr">On Sun, Jul 13, 2014 at 4:28 AM, Myriachan =
<span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"UaO27T-_sOIJ" onmousedown=3D"this.href=3D'javascript:';return=
 true;" onclick=3D"this.href=3D'javascript:';return true;">myri...@gmail.co=
m</a>&gt;</span> wrote: <br><div><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div></div><div></div><div>
<br>I agree that hashcode() and before() are significantly harder; they're =
also significantly less important to have available in constexpr-context. <=
br><br></div></div></blockquote></div>Ahhh, no.&nbsp; The utility of before=
 and hashcode is the same at compile-time as at run-time.&nbsp; For example=
 if you want to have a compile-time data structure keyed by type (sorted ar=
ray, binary tree, hash table, etc).&nbsp; If you only have equality then yo=
u have to linear search for a type in a type list.&nbsp; Also consider the =
case where you want to prepare one of the above data structures at compile-=
time for use at run-time.&nbsp; You need access to (the same) before/hash f=
unctions in order to lay it out.<br></div></div></blockquote><div><br></div=
></div>It is unfortunate, but the root problem is unfixable, so we might as=
 well work within the set limits.</div></blockquote><div>&nbsp;</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 style=3D"word-wrap:break-word">=
<div></div><div>Right now, <font face=3D"Courier">hash_code</font> is not r=
equired to be unique per type (N3936 =C2=A718.7.1/8 only says =E2=80=9Cshou=
ld=E2=80=9D). Normatively we have the freedom to require an imperfect hash =
function at compile time (carried over to runtime), but this is a non-start=
er because programs already depend on the common implementations providing =
uniqueness.</div><div><br></div><div>Perhaps a truly imperfect hash should =
be added by a new interface. ABIs and individual metaprograms can sort out =
the gory usage details, but it=E2=80=99s no worse than things have always b=
een, in terms of standardization. The spec of <font face=3D"Courier">hash_c=
ode</font> might be adjusted to require a perfect hash, or maybe not, if an=
y remaining current ABIs don=E2=80=99t use the pointer trick. Either way, u=
niqueness should be an implementation-specified property since it=E2=80=99s=
 so common.</div></div></blockquote><div><br>This sounds like it's reaching=
 the same conclusion I came to.&nbsp; Create a new, completely separate sys=
tem from std::type_info, for compile-time type name, equality, comparison a=
nd hash.<br><br>Further, if we could have a std::type_name&lt;T&gt; compile=
-time string such that std::type_name&lt;A&gt; =3D=3D std::type_name&lt;B&g=
t; iff std::is_same&lt;A,B&gt; - these equality, comparison and hash functi=
ons could be simply the usual ones for strings.&nbsp; I think the sticking =
point here was encoding a unique ID within the string to identify the trans=
lation unit, for types that didn't have external linkage.&nbsp; For example=
:<br><br>TU1:<br><br>&nbsp;&nbsp;&nbsp; struct {} a1;<br><br>&nbsp;&nbsp;&n=
bsp; char* s1 =3D std::type_name_v&lt;decltype(a1);<br><br>TU2:<br><br>&nbs=
p;&nbsp;&nbsp; struct {} a2;<br><br>&nbsp;&nbsp;&nbsp; char* s2 =3D std::ty=
pe_name_v&lt;decltype(a2)&gt;;<br><br>TU3:<br><br>&nbsp;&nbsp;&nbsp; extern=
 char *s1, *s2;<br><br>&nbsp;&nbsp;&nbsp; int main()<br>&nbsp;&nbsp;&nbsp; =
{<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; assert(strcmp(s1, s2) !=3D =
0);<br>&nbsp;&nbsp;&nbsp; }<br><br>s1 and s2 must be different strings.&nbs=
p; How shall they be formed?&nbsp; If they were from the same TU we could j=
ust use a counter.&nbsp; We need a way to encode the source TU identity at =
compile-time.&nbsp; I thought of secure hashing the TU, or similarly genera=
ting a random TU ID of sufficient size at compile-time - but I haven't had =
much time to think about this further.<br><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&quot; 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_744_12929982.1405228590240--

.

--Apple-Mail=_993B2010-F629-4772-8508-4525D1D51C87
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-13, at 1:16 PM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:

> This sounds like it's reaching the same conclusion I came to.  Create a n=
ew, completely separate system from std::type_info, for compile-time type n=
ame, equality, comparison and hash.

Since type_info is already polymorphic, and assuming no technical barrier t=
o literal polymorphic types,

1. Why not put new features in struct new_type_info< T > : type_info?=20
2. Why not require is_same< decltype( typeid( T ) ), new_type_info< T > >? =
This should be mostly compatible with existing polymorphic type_info extens=
ions, it just adds another layer under whatever the vendor has.
3. Since decltype( typeid( T ) ) is already suitable for nested-name-specif=
iers, there's no need for a "new_type_info" name in the library at all.

Unless there's a reason to jettison type_info, it seems perfect for extensi=
on.

Although, now that I think about it, #2 creates a rabbit-hole like

    std::type_info const * ti =3D & typeid( std::type_info );
    for (;;) ti =3D & typeid( * ti ); // Each iteration reveals a unique ob=
ject of a unique type.

Perhaps all typeid( decltype( typeid( T ) ) ) should be represented by a co=
mmon type. Doesn't seem so bad.

> Further, if we could have a std::type_name<T> compile-time string such th=
at std::type_name<A> =3D=3D std::type_name<B> iff std::is_same<A,B> - these=
 equality, comparison and hash functions could be simply the usual ones for=
 strings.  I think the sticking point here was encoding a unique ID within =
the string to identify the translation unit, for types that didn't have ext=
ernal linkage.=20

Huh, I didn't realize that typeid(T).name() wasn't unique, but it's not. Bu=
t, mangled name uniqueness sounds more like an ABI quality issue.

Where is the advantage over & typeid(T) for identity (which I think is alre=
ady constexpr-safe since C++11, I need to check the Clang bugtracker) and a=
 constexpr array-backed typeid(T).name() for debugging?

> s1 and s2 must be different strings.  How shall they be formed?  If they =
were from the same TU we could just use a counter.=20

You mean a numeric string like "542"? How is that better than serializing a=
 pointer? (They won't be stable across builds.) Can you clarify the use cas=
e?

--=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=_993B2010-F629-4772-8508-4525D1D51C87
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;07&ndash;13, at 1:16 PM, Andrew Tomazos &lt;<a href=3D"mailto:andrewt=
omazos@gmail.com">andrewtomazos@gmail.com</a>&gt; wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">This =
sounds like it's reaching the same conclusion I came to.&nbsp; Create a new=
, completely separate system from std::type_info, for compile-time type nam=
e, equality, comparison and hash.<br></div></blockquote><div><br></div><div=
>Since <font face=3D"Courier">type_info</font> is already polymorphic, and =
assuming no technical barrier to&nbsp;literal&nbsp;polymorphic types,</div>=
<div><br></div><div>1. Why not put new features in&nbsp;<font face=3D"Couri=
er">struct new_type_info&lt; T &gt; :&nbsp;</font><font face=3D"Courier">ty=
pe_info</font>?&nbsp;</div><div>2. Why not require <font face=3D"Courier">i=
s_same&lt; decltype( typeid( T ) ), new_type_info&lt; T &gt; &gt;</font>? T=
his should be mostly compatible with existing polymorphic <font face=3D"Cou=
rier">type_info</font> extensions, it just adds another layer under whateve=
r the vendor has.</div><div>3. Since&nbsp;<span style=3D"font-family: Couri=
er;">decltype( typeid( T ) )</span>&nbsp;is already suitable for nested-nam=
e-specifiers, there&rsquo;s no need for a &ldquo;<font face=3D"Courier">new=
_type_info</font>&rdquo; name in the library at all.</div><div><br></div><d=
iv>Unless there&rsquo;s a reason to jettison <font face=3D"Courier">type_in=
fo</font>, it seems perfect for extension.</div><div><br></div><div>Althoug=
h, now that I think about it, #2 creates a rabbit-hole like</div><div><br><=
/div><div><font face=3D"Courier">&nbsp; &nbsp; std::type_info const * ti =
=3D &amp; typeid( std::type_info );</font></div><div><font face=3D"Courier"=
>&nbsp; &nbsp; for (;;) ti =3D &amp; typeid( * ti ); // Each iteration reve=
als a unique object of a unique type.</font></div><div><br></div><div>Perha=
ps all&nbsp;<font face=3D"Courier">typeid( decltype( typeid( T ) ) )</font>=
 should be represented by a common type. Doesn&rsquo;t seem so bad.</div><b=
r><blockquote type=3D"cite"><div dir=3D"ltr"><div>Further, if we could have=
 a std::type_name&lt;T&gt; compile-time string such that std::type_name&lt;=
A&gt; =3D=3D std::type_name&lt;B&gt; iff std::is_same&lt;A,B&gt; - these eq=
uality, comparison and hash functions could be simply the usual ones for st=
rings.&nbsp; I think the sticking point here was encoding a unique ID withi=
n the string to identify the translation unit, for types that didn't have e=
xternal linkage.&nbsp; </div></div></blockquote><div><br></div><div>Huh, I =
didn&rsquo;t realize that <font face=3D"Courier">typeid(T).name()</font> wa=
sn&rsquo;t unique, but it&rsquo;s not. But, mangled name uniqueness sounds =
more like an ABI quality issue.</div><div><br></div><div>Where is the advan=
tage over <font face=3D"Courier">&amp; typeid(T)</font>&nbsp;for identity (=
which I think is already constexpr-safe since C++11, I need to check the Cl=
ang bugtracker) and a constexpr array-backed&nbsp;<font face=3D"Courier">ty=
peid(T).name()</font>&nbsp;for debugging?</div><br><blockquote type=3D"cite=
"><div dir=3D"ltr"><div>s1 and s2 must be different strings.&nbsp; How shal=
l they be formed?&nbsp; If they were from the same TU we could just use a c=
ounter.&nbsp; </div></div></blockquote><div><br></div><div>You mean a numer=
ic string like <font face=3D"Courier">"542"</font>? How is that better than=
 serializing a pointer? (They won&rsquo;t be stable across builds.) Can you=
 clarify the use case?</div></div><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&quot; 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=_993B2010-F629-4772-8508-4525D1D51C87--

.

--bcaec548a9bda67ac104fe2d924b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 12, 2014 at 9:38 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014=E2=80=9307=E2=80=9311, at 5:18 AM, Richard Smith <richard@metafoo=
..co.uk> wrote:
>
> name(), =3D=3D(), and !=3D() present technical problems too, because
> implementations use bit-fiddling tricks here that can't be directly model=
ed
> in constexpr evaluation, but we can at least in principle support those
> through compiler extensions.
>
>
> Let those be implemented as intrinsics, discriminating runtime from
> compile time. For implementations that guarantee uniqueness of type_info
> objects, comparing pointer identity is already constexpr safe. (I have de=
ja
> vu on this suggestion.)
>
> GCC accepts this but Clang complains "not an integral constant
> expression." Why?
>
> static_assert ( & typeid( int ) =3D=3D & typeid( int ), "" );
>

It is unspecified whether those two typeid expressions produce glvalues
referring to the same object. Therefore this is "a relational or equality
operator where the result is unspecified", so it's non-constant per 5.19/2
bullet 19.

Clang is not deliberately giving this result; I didn't think of this case
when implementing support for typeid expressions in constexpr evaluation.
Indeed, Clang gives the opposite result for this:

constexpr const std::type_info &x() { return typeid(int); }
static_assert(&x() =3D=3D &x(), "");

.... which is arguably ill-formed for the same reason. I suspect (but don't
know for sure) that GCC accepts this code because they too didn't think of
this case (and in their implementation the representation for both
address-of-typeid expressions happens to be the same, so the comparison
succeeds).

Having said all that, I'm definitely sympathetic to making your
static_assert work -- I'd suggest that within a single translation unit,
all non-dynamic typeid expressions whose arguments refer to the same type
should be defined to produce the glvalues referring to the same type_info
object.

On 2014=E2=80=9307=E2=80=9313, at 10:49 AM, Andrew Tomazos <andrewtomazos@g=
mail.com> wrote:
>
> On Sun, Jul 13, 2014 at 4:28 AM, Myriachan <myriachan@gmail.com> wrote:
>
>>
>> I agree that hashcode() and before() are significantly harder; they're
>> also significantly less important to have available in constexpr-context=
..
>>
>> Ahhh, no.  The utility of before and hashcode is the same at compile-tim=
e
> as at run-time.  For example if you want to have a compile-time data
> structure keyed by type (sorted array, binary tree, hash table, etc).  If
> you only have equality then you have to linear search for a type in a typ=
e
> list.  Also consider the case where you want to prepare one of the above
> data structures at compile-time for use at run-time.  You need access to
> (the same) before/hash functions in order to lay it out.
>
>
> It is unfortunate, but the root problem is unfixable, so we might as well
> work within the set limits.
>
> Right now, hash_code is not required to be unique per type (N3936
> =C2=A718.7.1/8 only says =E2=80=9Cshould=E2=80=9D). Normatively we have t=
he freedom to require
> an imperfect hash function at compile time (carried over to runtime), but
> this is a non-starter because programs already depend on the common
> implementations providing uniqueness.
>
> Perhaps a truly imperfect hash should be added by a new interface. ABIs
> and individual metaprograms can sort out the gory usage details, but it=
=E2=80=99s
> no worse than things have always been, in terms of standardization. The
> spec of hash_code might be adjusted to require a perfect hash, or maybe
> not, if any remaining current ABIs don=E2=80=99t use the pointer trick. E=
ither way,
> uniqueness should be an implementation-specified property since it=E2=80=
=99s so
> common.
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--bcaec548a9bda67ac104fe2d924b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Jul 12, 2014 at 9:38 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div style=3D"word-wrap:break-word"><div class=3D""><div><=
br></div>
<div><div>On 2014=E2=80=9307=E2=80=9311, at 5:18 AM, Richard Smith &lt;<a h=
ref=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.u=
k</a>&gt; wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote">
name(), =3D=3D(), and !=3D() present technical problems too, because implem=
entations use bit-fiddling tricks here that can&#39;t be directly modeled i=
n constexpr evaluation, but we can at least in principle support those thro=
ugh compiler extensions.</div>
</div></div></blockquote></div></div><div><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">=
Let those be implemented as intrinsics, discriminating runtime from compile=
 time. For implementations that guarantee uniqueness of <font face=3D"Couri=
er">type_info</font> objects, comparing pointer identity is already constex=
pr safe. (I have deja vu on this suggestion.)</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">GCC accepts=
 this but Clang complains &quot;not an integral constant expression.&quot; =
Why?</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><=
font face=3D"Courier">static_assert ( &amp; typeid( int ) =3D=3D &amp; type=
id( int ), &quot;&quot; );</font></div>
</div></div></div></div></blockquote><div><br></div><div>It is unspecified =
whether those two typeid expressions produce glvalues referring to the same=
 object. Therefore this is &quot;a relational or equality operator where th=
e result is unspecified&quot;, so it&#39;s non-constant per 5.19/2 bullet 1=
9.</div>
<div><br></div><div>Clang is not deliberately giving this result; I didn&#3=
9;t think of this case when implementing support for typeid expressions in =
constexpr evaluation. Indeed, Clang gives the opposite result for this:</di=
v>
<div><br></div><div><div><div>constexpr const std::type_info &amp;x() { ret=
urn typeid(int); }=C2=A0</div><div>static_assert(&amp;x() =3D=3D &amp;x(), =
&quot;&quot;);</div></div></div><div><br></div><div>... which is arguably i=
ll-formed for the same reason. I suspect (but don&#39;t know for sure) that=
 GCC accepts this code because they too didn&#39;t think of this case (and =
in their implementation the representation for both address-of-typeid expre=
ssions happens to be the same, so the comparison succeeds).</div>
<div><br></div><div>Having said all that, I&#39;m definitely sympathetic to=
 making your static_assert work -- I&#39;d suggest that within a single tra=
nslation unit, all non-dynamic typeid expressions whose arguments refer to =
the same type should be defined to produce the glvalues referring to the sa=
me type_info object.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div><d=
iv class=3D"">
<div>On 2014=E2=80=9307=E2=80=9313, at 10:49 AM, Andrew Tomazos &lt;<a href=
=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.c=
om</a>&gt; wrote:</div><br></div><blockquote type=3D"cite"><div dir=3D"ltr"=
><div class=3D"">On Sun, Jul 13, 2014 at 4:28 AM, Myriachan <span dir=3D"lt=
r">&lt;<a href=3D"mailto:myriachan@gmail.com" target=3D"_blank">myriachan@g=
mail.com</a>&gt;</span> wrote: <br>
</div><div class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div></div><div></div><div>
<br>I agree that hashcode() and before() are significantly harder; they&#39=
;re also significantly less important to have available in constexpr-contex=
t. <br><br></div></div></blockquote></div>Ahhh, no.=C2=A0 The utility of be=
fore and hashcode is the same at compile-time as at run-time.=C2=A0 For exa=
mple if you want to have a compile-time data structure keyed by type (sorte=
d array, binary tree, hash table, etc).=C2=A0 If you only have equality the=
n you have to linear search for a type in a type list.=C2=A0 Also consider =
the case where you want to prepare one of the above data structures at comp=
ile-time for use at run-time.=C2=A0 You need access to (the same) before/ha=
sh functions in order to lay it out.<br>
</div></div></div></blockquote><div><br></div></div>It is unfortunate, but =
the root problem is unfixable, so we might as well work within the set limi=
ts.<div><br></div><div>Right now, <font face=3D"Courier">hash_code</font> i=
s not required to be unique per type (N3936 =C2=A718.7.1/8 only says =E2=80=
=9Cshould=E2=80=9D). Normatively we have the freedom to require an imperfec=
t hash function at compile time (carried over to runtime), but this is a no=
n-starter because programs already depend on the common implementations pro=
viding uniqueness.</div>
<div><br></div><div>Perhaps a truly imperfect hash should be added by a new=
 interface. ABIs and individual metaprograms can sort out the gory usage de=
tails, but it=E2=80=99s no worse than things have always been, in terms of =
standardization. The spec of <font face=3D"Courier">hash_code</font> might =
be adjusted to require a perfect hash, or maybe not, if any remaining curre=
nt ABIs don=E2=80=99t use the pointer trick. Either way, uniqueness should =
be an implementation-specified property since it=E2=80=99s so common.</div>
<div><br></div></div><div class=3D""><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />

--bcaec548a9bda67ac104fe2d924b--

.

On 14 July 2014 23:59, Richard Smith <richard@metafoo.co.uk> wrote:
> Having said all that, I'm definitely sympathetic to making your
> static_assert work -- I'd suggest that within a single translation unit, all
> non-dynamic typeid expressions whose arguments refer to the same type should
> be defined to produce the glvalues referring to the same type_info object.


A short proposal targeting EWG and authored by Mr. Smith would be nice. ;)

--

---
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=_4E785539-10CE-4539-8D37-294048F500D4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-15, at 4:59 AM, Richard Smith <richard@metafoo.co.uk> wrote:

> Indeed, Clang gives the opposite result for this:
>=20
> constexpr const std::type_info &x() { return typeid(int); }=20
> static_assert(&x() =3D=3D &x(), "");
>=20
> ... which is arguably ill-formed for the same reason. I suspect (but don'=
t know for sure) that GCC accepts this code because they too didn't think o=
f this case (and in their implementation the representation for both addres=
s-of-typeid expressions happens to be the same, so the comparison succeeds)=
..
>=20
> Having said all that, I'm definitely sympathetic to making your static_as=
sert work -- I'd suggest that within a single translation unit, all non-dyn=
amic typeid expressions whose arguments refer to the same type should be de=
fined to produce the glvalues referring to the same type_info object.

This (and your above example) cannot be reconciled with the ODR. It require=
s ODR-compliant inline functions definitions in different TUs to produce di=
fferent behavior. (Please forward this to CWG per the Clang bug report comm=
ent.)

Apparently my mind wandered between subsequent sentences, because right bef=
ore I gave my example, I'd mentioned "implementations that guarantee unique=
ness of type_info objects." Looks like I underestimated the nasal demons, b=
y assuming that runtime identity of type_info objects (which I'm currently =
assuming, without verification, are a property of the common ABI or at leas=
t Clang) is sufficient to guarantee compile-time identity.

The real solution is what I mentioned next: split the compile-tme and runti=
me uniqueness guarantees between two separate interfaces, essentially addin=
g a new type_info::static_hash_code(). But, using &typeid() as a model, poi=
nters are better than hashes because their identity can be tested at compil=
e time, but no other observations exist like numeric conversions. They are =
also inferior in that before() is sacrificed.

Extrapolating back to my suggestions, now I suggest two new interfaces, wit=
h ABI-specified details:

-- constexpr void * type_info::unique_key() const which may be implemented =
as returning a pointer to a dummy function/object of vague linkage (an inli=
ne function or variable template instantiation, casted to void*), or just t=
his on systems that prevent duplicate type_info instances.
-- constexpr uintptr_t type_info::static_hash() const which may be implemen=
ted as a compile-time string hash, perhaps adding an appropriately stable T=
U identifier into the mix. To the user, this is constexpr-friendly but infe=
rior to hash_id.

Things that would be nice to resolve, or else definitively prove impossible=
:
-- constexpr full ordering of types must depend on a hash function which po=
tentially has collisions.
-- void * unique_key(), being not a number, cannot be used for a hash table=
 or a search algorithm faster than O(N). The user is stuck with linear sear=
ch, which is only acceptable at compile time. Perhaps this can be resolved =
by somehow hooking an intrinsic into std::type_index.

--=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=_4E785539-10CE-4539-8D37-294048F500D4
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;07&ndash;15, at 4:59 AM, Richard Smith &lt;<a href=3D"mailto:richard@=
metafoo.co.uk">richard@metafoo.co.uk</a>&gt; wrote:</div><br class=3D"Apple=
-interchange-newline"><blockquote type=3D"cite"><div style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-=
weight: normal; letter-spacing: normal; line-height: normal; orphans: auto;=
 text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><di=
v dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>In=
deed, Clang gives the opposite result for this:</div><div><br></div><div><d=
iv>constexpr const std::type_info &amp;x() { return typeid(int); }&nbsp;</d=
iv><div>static_assert(&amp;x() =3D=3D &amp;x(), "");</div></div><div><br></=
div><div>... which is arguably ill-formed for the same reason. I suspect (b=
ut don't know for sure) that GCC accepts this code because they too didn't =
think of this case (and in their implementation the representation for both=
 address-of-typeid expressions happens to be the same, so the comparison su=
cceeds).</div><div><br></div><div>Having said all that, I'm definitely symp=
athetic to making your static_assert work -- I'd suggest that within a sing=
le translation unit, all non-dynamic typeid expressions whose arguments ref=
er to the same type should be defined to produce the glvalues referring to =
the same type_info object.</div></div></div></div></div></blockquote><div><=
br></div><div>This (and your above example) cannot be reconciled with the O=
DR. It requires ODR-compliant inline functions definitions in different TUs=
 to produce different behavior. (Please forward this to CWG per the Clang b=
ug report comment.)</div><div><br></div><div>Apparently my mind wandered be=
tween subsequent sentences, because right before I gave my example, I&rsquo=
;d mentioned &ldquo;implementations that guarantee uniqueness of&nbsp;<font=
 face=3D"Courier">type_info</font>&nbsp;objects.&rdquo; Looks like I undere=
stimated the nasal demons, by assuming that runtime identity of <font face=
=3D"Courier">type_info</font> objects (which I&rsquo;m currently assuming, =
without verification, are a property of the common ABI or at least Clang) i=
s sufficient to guarantee compile-time identity.</div><div><br></div><div>T=
he real solution is what I mentioned next: split the compile-tme and runtim=
e uniqueness guarantees between two separate interfaces, essentially adding=
 a new <font face=3D"Courier">type_info::static_hash_code()</font>. But, us=
ing <font face=3D"Courier">&amp;typeid()</font> as a model, pointers are be=
tter than hashes because their identity can be tested at compile time, but =
no other observations exist like numeric conversions. They are also inferio=
r in that <font face=3D"Courier">before()</font> is sacrificed.</div><div><=
br></div><div>Extrapolating back to my suggestions, now I suggest two new i=
nterfaces, with ABI-specified details:</div><div><br></div><div>&mdash; <fo=
nt face=3D"Courier">constexpr void * type_info::unique_key() const</font> w=
hich may be implemented as returning a pointer to a dummy function/object o=
f vague linkage (an inline function or variable template instantiation, cas=
ted to <font face=3D"Courier">void*</font>), or just <font face=3D"Courier"=
>this</font>&nbsp;on systems that prevent duplicate <font face=3D"Courier">=
type_info</font> instances.</div><div>&mdash; <font face=3D"Courier">conste=
xpr uintptr_t type_info::static_hash() const</font>&nbsp;which may be imple=
mented as a compile-time string hash, perhaps adding an appropriately stabl=
e TU identifier into the mix. To the user, this is constexpr-friendly but i=
nferior to <font face=3D"Courier">hash_id</font>.</div><div><br></div><div>=
Things that would be nice to resolve, or else definitively prove impossible=
:</div><div>&mdash; <font face=3D"Courier">constexpr</font> full ordering o=
f types must depend on a hash function which potentially has collisions.</d=
iv><div>&mdash; <font face=3D"Courier">void * unique_key()</font>, being no=
t a number, cannot be used for a hash table or a search algorithm faster th=
an O(N). The user is stuck with linear search, which is only acceptable at =
compile time. Perhaps this can be resolved by somehow hooking an intrinsic =
into <font face=3D"Courier">std::type_index</font>.</div><div><br></div></d=
iv></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&quot; 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=_4E785539-10CE-4539-8D37-294048F500D4--

.

--047d7b604e12d62c3a04fe331fa5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 14, 2014 at 8:13 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014=E2=80=9307=E2=80=9315, at 4:59 AM, Richard Smith <richard@metafoo=
..co.uk> wrote:
>
> Indeed, Clang gives the opposite result for this:
>
> constexpr const std::type_info &x() { return typeid(int); }
> static_assert(&x() =3D=3D &x(), "");
>
> ... which is arguably ill-formed for the same reason. I suspect (but don'=
t
> know for sure) that GCC accepts this code because they too didn't think o=
f
> this case (and in their implementation the representation for both
> address-of-typeid expressions happens to be the same, so the comparison
> succeeds).
>
> Having said all that, I'm definitely sympathetic to making your
> static_assert work -- I'd suggest that within a single translation unit,
> all non-dynamic typeid expressions whose arguments refer to the same type
> should be defined to produce the glvalues referring to the same type_info
> object.
>
>
> This (and your above example) cannot be reconciled with the ODR. It
> requires ODR-compliant inline functions definitions in different TUs to
> produce different behavior. (Please forward this to CWG per the Clang bug
> report comment.)
>

My mail to core already had a discussion of this problem in it =3D)

Apparently my mind wandered between subsequent sentences, because right
> before I gave my example, I=E2=80=99d mentioned =E2=80=9Cimplementations =
that guarantee
> uniqueness of type_info objects.=E2=80=9D Looks like I underestimated the=
 nasal
> demons, by assuming that runtime identity of type_info objects (which I=
=E2=80=99m
> currently assuming, without verification, are a property of the common AB=
I
> or at least Clang) is sufficient to guarantee compile-time identity.
>
> The real solution is what I mentioned next: split the compile-tme and
> runtime uniqueness guarantees between two separate interfaces, essentiall=
y
> adding a new type_info::static_hash_code(). But, using &typeid() as a
> model, pointers are better than hashes because their identity can be test=
ed
> at compile time, but no other observations exist like numeric conversions=
..
> They are also inferior in that before() is sacrificed.
>
> Extrapolating back to my suggestions, now I suggest two new interfaces,
> with ABI-specified details:
>
> =E2=80=94 constexpr void * type_info::unique_key() const which may be imp=
lemented
> as returning a pointer to a dummy function/object of vague linkage (an
> inline function or variable template instantiation, casted to void*), or
> just this on systems that prevent duplicate type_info instances.
> =E2=80=94 constexpr uintptr_t type_info::static_hash() const which may be
> implemented as a compile-time string hash, perhaps adding an appropriatel=
y
> stable TU identifier into the mix. To the user, this is constexpr-friendl=
y
> but inferior to hash_id.
>
> Things that would be nice to resolve, or else definitively prove
> impossible:
> =E2=80=94 constexpr full ordering of types must depend on a hash function=
 which
> potentially has collisions.
> =E2=80=94 void * unique_key(), being not a number, cannot be used for a h=
ash
> table or a search algorithm faster than O(N). The user is stuck with line=
ar
> search, which is only acceptable at compile time. Perhaps this can be
> resolved by somehow hooking an intrinsic into std::type_index.
>

I think the utility of these will be somewhat limited since we don't have
the ability to allocate memory during constexpr evaluation (but a
fixed-size hash table is probably good enough for a lot of use cases).

--=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/.

--047d7b604e12d62c3a04fe331fa5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jul 14, 2014 at 8:13 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div=
><div class=3D""><div>On 2014=E2=80=9307=E2=80=9315, at 4:59 AM, Richard Sm=
ith &lt;<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@=
metafoo.co.uk</a>&gt; wrote:</div>
<br><blockquote type=3D"cite"><div style=3D"font-family:Helvetica;font-size=
:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spaci=
ng:normal;line-height:normal;text-align:start;text-indent:0px;text-transfor=
m:none;white-space:normal;word-spacing:0px">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>Indeed, Clang gives the opposite result for this:</div><div><br></div><div=
><div>constexpr const std::type_info &amp;x() { return typeid(int); }=C2=A0=
</div><div>
static_assert(&amp;x() =3D=3D &amp;x(), &quot;&quot;);</div></div><div><br>=
</div><div>... which is arguably ill-formed for the same reason. I suspect =
(but don&#39;t know for sure) that GCC accepts this code because they too d=
idn&#39;t think of this case (and in their implementation the representatio=
n for both address-of-typeid expressions happens to be the same, so the com=
parison succeeds).</div>
<div><br></div><div>Having said all that, I&#39;m definitely sympathetic to=
 making your static_assert work -- I&#39;d suggest that within a single tra=
nslation unit, all non-dynamic typeid expressions whose arguments refer to =
the same type should be defined to produce the glvalues referring to the sa=
me type_info object.</div>
</div></div></div></div></blockquote><div><br></div></div><div>This (and yo=
ur above example) cannot be reconciled with the ODR. It requires ODR-compli=
ant inline functions definitions in different TUs to produce different beha=
vior. (Please forward this to CWG per the Clang bug report comment.)</div>
</div></div></blockquote><div><br></div><div>My mail to core already had a =
discussion of this problem in it =3D)</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div style=3D"word-wrap:break-word"><div><div>Apparently my mind wandered b=
etween subsequent sentences, because right before I gave my example, I=E2=
=80=99d mentioned =E2=80=9Cimplementations that guarantee uniqueness of=C2=
=A0<font face=3D"Courier">type_info</font>=C2=A0objects.=E2=80=9D Looks lik=
e I underestimated the nasal demons, by assuming that runtime identity of <=
font face=3D"Courier">type_info</font> objects (which I=E2=80=99m currently=
 assuming, without verification, are a property of the common ABI or at lea=
st Clang) is sufficient to guarantee compile-time identity.</div>
<div><br></div><div>The real solution is what I mentioned next: split the c=
ompile-tme and runtime uniqueness guarantees between two separate interface=
s, essentially adding a new <font face=3D"Courier">type_info::static_hash_c=
ode()</font>. But, using <font face=3D"Courier">&amp;typeid()</font> as a m=
odel, pointers are better than hashes because their identity can be tested =
at compile time, but no other observations exist like numeric conversions. =
They are also inferior in that <font face=3D"Courier">before()</font> is sa=
crificed.</div>
<div><br></div><div>Extrapolating back to my suggestions, now I suggest two=
 new interfaces, with ABI-specified details:</div><div><br></div><div>=E2=
=80=94 <font face=3D"Courier">constexpr void * type_info::unique_key() cons=
t</font> which may be implemented as returning a pointer to a dummy functio=
n/object of vague linkage (an inline function or variable template instanti=
ation, casted to <font face=3D"Courier">void*</font>), or just <font face=
=3D"Courier">this</font>=C2=A0on systems that prevent duplicate <font face=
=3D"Courier">type_info</font> instances.</div>
<div>=E2=80=94 <font face=3D"Courier">constexpr uintptr_t type_info::static=
_hash() const</font>=C2=A0which may be implemented as a compile-time string=
 hash, perhaps adding an appropriately stable TU identifier into the mix. T=
o the user, this is constexpr-friendly but inferior to <font face=3D"Courie=
r">hash_id</font>.</div>
<div><br></div><div>Things that would be nice to resolve, or else definitiv=
ely prove impossible:</div><div>=E2=80=94 <font face=3D"Courier">constexpr<=
/font> full ordering of types must depend on a hash function which potentia=
lly has collisions.</div>
<div>=E2=80=94 <font face=3D"Courier">void * unique_key()</font>, being not=
 a number, cannot be used for a hash table or a search algorithm faster tha=
n O(N). The user is stuck with linear search, which is only acceptable at c=
ompile time. Perhaps this can be resolved by somehow hooking an intrinsic i=
nto <font face=3D"Courier">std::type_index</font>.</div>
</div></div></blockquote><div><br></div><div>I think the utility of these w=
ill be somewhat limited since we don&#39;t have the ability to allocate mem=
ory during constexpr evaluation (but a fixed-size hash table is probably go=
od enough for a lot of use cases).</div>
</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />

--047d7b604e12d62c3a04fe331fa5--

.

--Apple-Mail=_EF11C3F5-43E5-41A2-9ACF-2F452F866325
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-15, at 11:37 AM, Richard Smith <richard@metafoo.co.uk> wrote:

> On Mon, Jul 14, 2014 at 8:13 PM, David Krauss <potswa@gmail.com> wrote:
>=20
> -- constexpr void * type_info::unique_key() const which may be implemente=
d as returning a pointer to a dummy function/object of vague linkage (an in=
line function or variable template instantiation, casted to void*), or just=
 this on systems that prevent duplicate type_info instances.
> -- constexpr uintptr_t type_info::static_hash() const which may be implem=
ented as a compile-time string hash, perhaps adding an appropriately stable=
 TU identifier into the mix. To the user, this is constexpr-friendly but in=
ferior to hash_id.
>=20
>=20
> I think the utility of these will be somewhat limited since we don't have=
 the ability to allocate memory during constexpr evaluation (but a fixed-si=
ze hash table is probably good enough for a lot of use cases).

I've not played much with it, but I would expect the constexpr code to calc=
ulate the size of an array and initialize that, or just generate a braced-i=
nit-list and use that for std::initializer_list. The linear or O(log N) sea=
rch would be based on indexes.

One of the first things I tried with C++11 constexpr is a binary search, ov=
er linked global objects as opposed to a single container object. It contin=
ues to serve well in my project, although I don't know if I'd call the expe=
riment a success, the same general pattern is still viable in C++14 and hig=
her.

--=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=_EF11C3F5-43E5-41A2-9ACF-2F452F866325
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;07&ndash;15, at 11:37 AM, Richard Smith &lt;<a href=3D"mailto:richard=
@metafoo.co.uk">richard@metafoo.co.uk</a>&gt; wrote:</div><br class=3D"Appl=
e-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote">On Mon, Jul 14, 2014 at 8:13 P=
M, David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:potswa@gmail.com" t=
arget=3D"_blank">potswa@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex; position: static; z-index: auto;"><div style=3D=
"word-wrap:break-word"><br><div><div class=3D""><div>&mdash; <font face=3D"=
Courier">constexpr void * type_info::unique_key() const</font> which may be=
 implemented as returning a pointer to a dummy function/object of vague lin=
kage (an inline function or variable template instantiation, casted to <fon=
t face=3D"Courier">void*</font>), or just <font face=3D"Courier">this</font=
>&nbsp;on systems that prevent duplicate <font face=3D"Courier">type_info</=
font> instances.</div></div></div></div></blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; bor=
der-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left:=
 1ex; position: static; z-index: auto;"><div style=3D"word-wrap:break-word"=
>
<div>&mdash; <font face=3D"Courier">constexpr uintptr_t type_info::static_h=
ash() const</font>&nbsp;which may be implemented as a compile-time string h=
ash, perhaps adding an appropriately stable TU identifier into the mix. To =
the user, this is constexpr-friendly but inferior to <font face=3D"Courier"=
>hash_id</font>.</div>
<div><br></div>
</div></blockquote><div><br></div><div>I think the utility of these will be=
 somewhat limited since we don't have the ability to allocate memory during=
 constexpr evaluation (but a fixed-size hash table is probably good enough =
for a lot of use cases).</div>
</div></div></div></blockquote><br></div><div>I&rsquo;ve not played much wi=
th it, but I would expect the constexpr code to calculate the size of an ar=
ray and initialize that, or just generate a <i>braced-init-list</i> and use=
 that for <font face=3D"Courier">std::initializer_list</font>. The linear o=
r O(log N) search would be based on indexes.</div><br><div>One of the first=
 things I tried with C++11 constexpr is a binary search, over linked global=
 objects as opposed to a single container object. It continues to serve wel=
l in my&nbsp;<a href=3D"https://code.google.com/p/c-plus/source/browse/src/=
constants.h#80">project</a>, although I don&rsquo;t know if I&rsquo;d call =
the experiment a success, the same general pattern is still viable in C++14=
 and higher.</div><div><br></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&quot; 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=_EF11C3F5-43E5-41A2-9ACF-2F452F866325--

.

--047d7bdc0cc225a83704fe33b495
Content-Type: text/plain; charset=UTF-8

On Tue, Jul 15, 2014 at 5:37 AM, Richard Smith <richard@metafoo.co.uk>
wrote:

> I think the utility of these will be somewhat limited since we don't have
> the ability to allocate memory during constexpr evaluation (but a
> fixed-size hash table is probably good enough for a lot of use cases).
>

The use of the term "fixed-size" here is misleading.  You can calculate
during compile-time the required size of a compile-time data structure
based on the data it will hold (or whatever other factors), and then
"allocate" that amount of memory for the data structure by passing in the
calculated size(s) as template parameter(s).

After writing my `has_member_function` paper that happens to use this
technique, I have had a lot of interest from people in the paper because of
the technique itself (and unrelated to reflection).

I think C++14 compile-time data structures (enabled by the constexpr
function relaxations) are going to be heavily used, because it is so much
easier/better than the old Boost MPL style.  We should therefore endeavour
to enable equality, comparison and hash for all standard library literal
types, including this specific case of a literal wrapper type for types
themselves.

(Having said that, the predynamic storage duration stuff is still welcome,
but as I mention in the std::string_literal paper - I expect it will get a
similar reaction from EWG to Classes of Runtime Size.)

--

---
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/.

--047d7bdc0cc225a83704fe33b495
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Jul 15, 2014 at 5:37 AM, Richard Smith <span dir=
=3D"ltr">&lt;<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">ric=
hard@metafoo.co.uk</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>I think the utility of these will be somewh=
at limited since we don&#39;t have the ability to allocate memory during co=
nstexpr evaluation (but a fixed-size hash table is probably good enough for=
 a lot of use cases).</div>

</div></div></div></blockquote><br></div>The use of the term &quot;fixed-si=
ze&quot; here is misleading.=C2=A0 You can calculate during compile-time th=
e required size of a compile-time data structure based on the data it will =
hold (or whatever other factors), and then &quot;allocate&quot; that amount=
 of memory for the data structure by passing in the calculated size(s) as t=
emplate parameter(s).<br>
<br></div><div class=3D"gmail_extra">After writing my `has_member_function`=
 paper that happens to use this technique, I have had a lot of interest fro=
m people in the paper because of the technique itself (and unrelated to ref=
lection).<br>
<br></div><div class=3D"gmail_extra">I think C++14 compile-time data struct=
ures (enabled by the constexpr function relaxations) are going to be heavil=
y used, because it is so much easier/better than the old Boost MPL style.=
=C2=A0 We should therefore endeavour to enable equality, comparison and has=
h for all standard library literal types, including this specific case of a=
 literal wrapper type for types themselves.<br>
<br></div><div class=3D"gmail_extra">(Having said that, the predynamic stor=
age duration stuff is still welcome, but as I mention in the std::string_li=
teral paper - I expect it will get a similar reaction from EWG to Classes o=
f Runtime Size.)<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&quot; 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 />

--047d7bdc0cc225a83704fe33b495--

.