------=_Part_4970_1864471658.1501055553632
Content-Type: multipart/alternative;
 boundary="----=_Part_4971_2028373932.1501055553632"

------=_Part_4971_2028373932.1501055553632
Content-Type: text/plain; charset="UTF-8"

I wanted to float an idea that came in mind. I am not entirely sure if this
has already been addressed in the latest c++ standards or proposals - to
the best of my knowledge it hasn't.

With some compile time based flags (rtti) you can typically get the
type_info to generate, so that you can use this for dynamic_cast or other
purposes. But I was never to fond of the idea that with this idea
you immediately had type-info generated for all of your classes in your
code base.  Even ones that get into your compilation unit from including
them from third party libraries. In addition for performance considerations
type info is often also disabled in most code-bases.  So I was thinking in
principle dynamic_cast or the idea of type-info can be very useful, but
these type of side-effects are less desirable.

So my thoughts on the matter are: what if you could annotate the class. The
actual syntax for this is debatable but if you had something the following
code.

typedef std::multiptr<x, y, z> resource_ptr;

@typeinfo
class x {
}

@typeinfo
class y {
}

@typeinfo
class z {
}


so @typeinfo instructs the compiler that for this class you want to
generate a type-info structure, maybe automatically does that for all it's
derivatives also (or generate a compiler error if derived classes
don't have the same annotation?). And since dynamic_cast is usually used to
up-cast from a base class, we could introduce 'type-safe' multi pointer
which you that ensures you it can only contain 'pointers of these types' -
on a compile level you can prevent assignments, ensure these types have
type info enabled.

could something like this be a nice addition to the standard?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/79dce8b4-9de5-45f4-be2e-e0fb4486c607%40isocpp.org.

------=_Part_4971_2028373932.1501055553632
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I wanted to float an idea that came in mind. I am not enti=
rely sure if this has already been addressed in the latest c++ standards or=
 proposals - to the best of my knowledge it hasn&#39;t.<br><br>With some co=
mpile time based flags (rtti) you can typically get the type_info to genera=
te, so that you can use this for dynamic_cast or other purposes. But I was =
never to fond of the idea that with this idea<br>you immediately had type-i=
nfo generated for all of your classes in your code base.=C2=A0 Even ones th=
at get into your compilation unit from including them from third party libr=
aries. In addition for performance considerations<br>type info is often als=
o disabled in most code-bases.=C2=A0 So I was thinking in principle dynamic=
_cast or the idea of type-info can be very useful, but these type of side-e=
ffects are less desirable.<br><br>So my thoughts on the matter are: what if=
 you could annotate the class. The actual syntax for this is debatable but =
if you had something the following code.<br><br>typedef std::multiptr&lt;x,=
 y, z&gt; resource_ptr;<br><br>@typeinfo<br>class x {=C2=A0 <br>}<br><br>@t=
ypeinfo<br>class y {<br>}<br><br>@typeinfo<br>class z {<br>}<br><br><br>so =
@typeinfo instructs the compiler that for this class you want to generate a=
 type-info structure, maybe automatically does that for all it&#39;s deriva=
tives also (or generate a compiler error if derived classes<br>don&#39;t ha=
ve the same annotation?). And since dynamic_cast is usually used to up-cast=
 from a base class, we could introduce &#39;type-safe&#39; multi pointer wh=
ich you that ensures you it can only contain &#39;pointers of these types&#=
39; - on a compile level you can prevent assignments, ensure these types ha=
ve type info enabled.<br><br>could something like this be a nice addition t=
o the standard?<br><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/79dce8b4-9de5-45f4-be2e-e0fb4486c607%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/79dce8b4-9de5-45f4-be2e-e0fb4486c607=
%40isocpp.org</a>.<br />

------=_Part_4971_2028373932.1501055553632--

------=_Part_4970_1864471658.1501055553632--

.

------=_Part_5215_712683299.1501076888145
Content-Type: multipart/alternative;
 boundary="----=_Part_5216_1093110119.1501076888145"

------=_Part_5216_1093110119.1501076888145
Content-Type: text/plain; charset="UTF-8"

The C++ standard does not support the idea of *not* generating type_info.
Those are extra-standard switches. And thus, their behavior is whatever
those compilers want it to be.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/11d9c4c7-c80d-431b-ba9d-3f57f4881880%40isocpp.org.

------=_Part_5216_1093110119.1501076888145
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The C++ standard does not support the idea of <i>not</i> g=
enerating type_info. Those are extra-standard switches. And thus, their beh=
avior is whatever those compilers want it to be.</div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/11d9c4c7-c80d-431b-ba9d-3f57f4881880%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/11d9c4c7-c80d-431b-ba9d-3f57f4881880=
%40isocpp.org</a>.<br />

------=_Part_5216_1093110119.1501076888145--

------=_Part_5215_712683299.1501076888145--

.

------=_Part_445_19278518.1501079607002
Content-Type: multipart/alternative;
 boundary="----=_Part_446_26521754.1501079607002"

------=_Part_446_26521754.1501079607002
Content-Type: text/plain; charset="UTF-8"

On Wednesday, 26 July 2017 17:52:33 UTC+10, phpfr...@gmail.com wrote:
>
>
> With some compile time based flags (rtti) you can typically get the
> type_info to generate, so that you can use this for dynamic_cast or other
> purposes. But I was never to fond of the idea that with this idea
> you immediately had type-info generated for all of your classes in your
> code base.  Even ones that get into your compilation unit from including
> them from third party libraries. In addition for performance considerations
> type info is often also disabled in most code-bases.  So I was thinking in
> principle dynamic_cast or the idea of type-info can be very useful, but
> these type of side-effects are less desirable.
>

I think it's the other way 'round. Some compilers offer a switch to
*disable* general RTTI generation, e.g. gcc's -fno-rtti
<https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-fno-rtti> which
itself only claims to disable RTTI generation for classes with virtual
functions.


> So my thoughts on the matter are: what if you could annotate the class.
>
[trim example]

Since it's compiler-specific, you'd have much better chances proposing a
compiler-specific attribute (for which we have a clear and portable syntax)
to mark classes that should have RTTI generated even under the aegis of
-fno-rtti. Since gcc can generate RTTI for exception handling even under
-fno-rtti, this has a chance of being feasible, but I haven't looked; those
might be unrelated RTTI generation systems after all.

From the dirty looks (^_^) SG14 gets every time we talk about habitually
disabling RTTI and exceptions, I don't fancy your chances of getting
something like this (or even the inverse, an attribute that *disables*
dynamic_cast support for specific virtual-method interfaces) into the
international standard.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4c1cbe7-f031-4a27-ab7d-1d6ff86cb7bf%40isocpp.org.

------=_Part_446_26521754.1501079607002
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, 26 July 2017 17:52:33 UTC+10, phpfr...@gmail=
..com  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
br>With some compile time based flags (rtti) you can typically get the type=
_info to generate, so that you can use this for dynamic_cast or other purpo=
ses. But I was never to fond of the idea that with this idea<br>you immedia=
tely had type-info generated for all of your classes in your code base.=C2=
=A0 Even ones that get into your compilation unit from including them from =
third party libraries. In addition for performance considerations<br>type i=
nfo is often also disabled in most code-bases.=C2=A0 So I was thinking in p=
rinciple dynamic_cast or the idea of type-info can be very useful, but thes=
e type of side-effects are less desirable.<br></div></blockquote><div><br><=
/div><div>I think it&#39;s the other way &#39;round. Some compilers offer a=
 switch to *disable* general RTTI generation, e.g. <a href=3D"https://gcc.g=
nu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-fno-rtti">gcc&=
#39;s <font face=3D"courier new, monospace">-fno-rtti</font></a>=C2=A0which=
 itself only claims to disable RTTI generation for classes with virtual fun=
ctions.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr">So my thoughts on the matter are: what if you could annota=
te the class.<br></div></blockquote><div>[trim example]=C2=A0</div><div><br=
></div><div>Since it&#39;s compiler-specific, you&#39;d have much better ch=
ances proposing a compiler-specific attribute (for which we have a clear an=
d portable syntax) to mark classes that should have RTTI generated even und=
er the aegis of <font face=3D"courier new, monospace">-fno-rtti</font>. Sin=
ce gcc can generate RTTI for exception handling even under <font face=3D"co=
urier new, monospace">-fno-rtti</font>, this has a chance of being feasible=
, but I haven&#39;t looked; those might be unrelated RTTI generation system=
s after all.</div><div><br></div><div>From the dirty looks (^_^) SG14 gets =
every time we talk about habitually disabling RTTI and exceptions, I don&#3=
9;t fancy your chances of getting something like this (or even the inverse,=
 an attribute that *disables* dynamic_cast support for specific virtual-met=
hod interfaces) into the international standard.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f4c1cbe7-f031-4a27-ab7d-1d6ff86cb7bf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f4c1cbe7-f031-4a27-ab7d-1d6ff86cb7bf=
%40isocpp.org</a>.<br />

------=_Part_446_26521754.1501079607002--

------=_Part_445_19278518.1501079607002--

.

------=_Part_2288_85035703.1501081027944
Content-Type: multipart/alternative;
 boundary="----=_Part_2289_1179108148.1501081027944"

------=_Part_2289_1179108148.1501081027944
Content-Type: text/plain; charset="UTF-8"


I think you are right that compilers offer an option to *disable* rtti
generation. However just because the situation is like that now and what
the standard intends on now, doesn't invalidate the idea or the in-justify
the reasoning around it. So maybe we should evaluate the idea on those
grounds, and identify if this actually would be make a nice contribution. I
think on the real world usage dynamic_cast is only used sparsely in very
controlled parts of code, so the inclusion model makes most sense to me.
The syntax like stated of course can be debated upon, it can actually be a
#pragma whatever people prefer.



On Wednesday, July 26, 2017 at 4:33:27 PM UTC+2, Paul Hampson wrote:
>
> On Wednesday, 26 July 2017 17:52:33 UTC+10, phpfr...@gmail.com wrote:
>>
>>
>> With some compile time based flags (rtti) you can typically get the
>> type_info to generate, so that you can use this for dynamic_cast or other
>> purposes. But I was never to fond of the idea that with this idea
>> you immediately had type-info generated for all of your classes in your
>> code base.  Even ones that get into your compilation unit from including
>> them from third party libraries. In addition for performance considerations
>> type info is often also disabled in most code-bases.  So I was thinking
>> in principle dynamic_cast or the idea of type-info can be very useful, but
>> these type of side-effects are less desirable.
>>
>
> I think it's the other way 'round. Some compilers offer a switch to
> *disable* general RTTI generation, e.g. gcc's -fno-rtti
> <https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-fno-rtti> which
> itself only claims to disable RTTI generation for classes with virtual
> functions.
>
>
>> So my thoughts on the matter are: what if you could annotate the class.
>>
> [trim example]
>
> Since it's compiler-specific, you'd have much better chances proposing a
> compiler-specific attribute (for which we have a clear and portable syntax)
> to mark classes that should have RTTI generated even under the aegis of
> -fno-rtti. Since gcc can generate RTTI for exception handling even under
> -fno-rtti, this has a chance of being feasible, but I haven't looked;
> those might be unrelated RTTI generation systems after all.
>
> From the dirty looks (^_^) SG14 gets every time we talk about habitually
> disabling RTTI and exceptions, I don't fancy your chances of getting
> something like this (or even the inverse, an attribute that *disables*
> dynamic_cast support for specific virtual-method interfaces) into the
> international standard.
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8dacd0b9-5bb6-49f9-9adf-b8a5f35ddeed%40isocpp.org.

------=_Part_2289_1179108148.1501081027944
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>I think you are right that compilers offer an option t=
o <i>disable</i> rtti generation. However just because the situation is lik=
e that now and what the standard intends on now, doesn&#39;t invalidate the=
 idea or the in-justify the reasoning around it. So maybe we should evaluat=
e the idea on those grounds, and identify if this actually would be make a =
nice contribution. I think on the real world usage dynamic_cast is only use=
d sparsely in very controlled parts of code, so the inclusion model makes m=
ost sense to me. The syntax like stated of course can be debated upon, it c=
an actually be a #pragma whatever people prefer.<br><br><br><br>On Wednesda=
y, July 26, 2017 at 4:33:27 PM UTC+2, Paul Hampson wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">On Wednesday, 26 July 2017 17:=
52:33 UTC+10, <a>phpfr...@gmail.com</a>  wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><br>With some compile time based flags (rtti) =
you can typically get the type_info to generate, so that you can use this f=
or dynamic_cast or other purposes. But I was never to fond of the idea that=
 with this idea<br>you immediately had type-info generated for all of your =
classes in your code base.=C2=A0 Even ones that get into your compilation u=
nit from including them from third party libraries. In addition for perform=
ance considerations<br>type info is often also disabled in most code-bases.=
=C2=A0 So I was thinking in principle dynamic_cast or the idea of type-info=
 can be very useful, but these type of side-effects are less desirable.<br>=
</div></blockquote><div><br></div><div>I think it&#39;s the other way &#39;=
round. Some compilers offer a switch to *disable* general RTTI generation, =
e.g. <a href=3D"https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Opti=
ons.html#index-fno-rtti" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%=
2Fonlinedocs%2Fgcc%2FC_002b_002b-Dialect-Options.html%23index-fno-rtti\x26s=
a\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF_ff8pf8nY2Y-RDMiWtxWVkhg84w&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%=
3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FC_002b_002b-Dialect-Options.html%2=
3index-fno-rtti\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF_ff8pf8nY2Y-RDMiWt=
xWVkhg84w&#39;;return true;">gcc&#39;s <font face=3D"courier new, monospace=
">-fno-rtti</font></a>=C2=A0which itself only claims to disable RTTI genera=
tion for classes with virtual functions.</div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">So my thoughts on the matter a=
re: what if you could annotate the class.<br></div></blockquote><div>[trim =
example]=C2=A0</div><div><br></div><div>Since it&#39;s compiler-specific, y=
ou&#39;d have much better chances proposing a compiler-specific attribute (=
for which we have a clear and portable syntax) to mark classes that should =
have RTTI generated even under the aegis of <font face=3D"courier new, mono=
space">-fno-rtti</font>. Since gcc can generate RTTI for exception handling=
 even under <font face=3D"courier new, monospace">-fno-rtti</font>, this ha=
s a chance of being feasible, but I haven&#39;t looked; those might be unre=
lated RTTI generation systems after all.</div><div><br></div><div>From the =
dirty looks (^_^) SG14 gets every time we talk about habitually disabling R=
TTI and exceptions, I don&#39;t fancy your chances of getting something lik=
e this (or even the inverse, an attribute that *disables* dynamic_cast supp=
ort for specific virtual-method interfaces) into the international standard=
..</div></div></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8dacd0b9-5bb6-49f9-9adf-b8a5f35ddeed%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8dacd0b9-5bb6-49f9-9adf-b8a5f35ddeed=
%40isocpp.org</a>.<br />

------=_Part_2289_1179108148.1501081027944--

------=_Part_2288_85035703.1501081027944--

.

------=_Part_5112_634109744.1501082315571
Content-Type: multipart/alternative;
 boundary="----=_Part_5113_1415569521.1501082315571"

------=_Part_5113_1415569521.1501082315571
Content-Type: text/plain; charset="UTF-8"

On Wednesday, July 26, 2017 at 10:57:08 AM UTC-4, phpfr...@gmail.com wrote:
>
>
> I think you are right that compilers offer an option to *disable* rtti
> generation. However just because the situation is like that now and what
> the standard intends on now, doesn't invalidate the idea or the in-justify
> the reasoning around it. So maybe we should evaluate the idea on those
> grounds, and identify if this actually would be make a nice contribution.
>

Um... why? The whole point of having `typeid` is that you can rely on it
working everywhere, on every type that exists. If you cannot rely on it,
then you cannot effectively use it.

I think on the real world usage dynamic_cast is only used sparsely in very
> controlled parts of code, so the inclusion model makes most sense to me.
>

You seem to have a misunderstanding between `dynamic_cast` and `typeid`.
They're not the same thing, and they're only tangentially related. Yes,
they're both RTTI mechanisms, but they're very *different* mechanisms.

`dynamic_cast` is for doing conversions from a base class to a derived one
safely. This does not require any access to `type_info` objects. It does
require that the compiler generate some per-type information, but *only*
for polymorphic classes. You can't use `dynamic_cast` with non-polymorphic
types.

`typeid` is for fetching the dynamic type of an object, as represented by a
`type_info` object. The compiler does not need to generate this for every
type; it only needs to generate it for types that you use `typeid` on
statically and for all polymorphic classes (since it needs to be able to
get at the `type_info` for the dynamic type of the object).

The only similarity is that they both rely on per-type information for
polymorphic types. Though, perhaps not the *same* information, since
they're doing different things with it.

The syntax like stated of course can be debated upon, it can actually be a
> #pragma whatever people prefer.
>

#pragmas, like attributes, have to be things that can be ignored. But your
suggestion has actual visible behavior. Your suggestion makes it impossible
to use unannotated types in `std::any`, for example. `any` relies on
`type_info` objects for verification of `any_cast`ing.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9809872a-c8c6-49ce-9bbc-d51e46711cfe%40isocpp.org.

------=_Part_5113_1415569521.1501082315571
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, July 26, 2017 at 10:57:08 AM UTC-4, phpfr...=
@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><br>I think you are right that compilers offer an option to <i>disable<=
/i> rtti generation. However just because the situation is like that now an=
d what the standard intends on now, doesn&#39;t invalidate the idea or the =
in-justify the reasoning around it. So maybe we should evaluate the idea on=
 those grounds, and identify if this actually would be make a nice contribu=
tion.</div></blockquote><div><br>Um... why? The whole point of having `type=
id` is that you can rely on it working everywhere, on every type that exist=
s. If you cannot rely on it, then you cannot effectively use it.<br><br></d=
iv><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">I think on=
 the real world usage dynamic_cast is only used sparsely in very controlled=
 parts of code, so the inclusion model makes most sense to me.</div></block=
quote><div><br>You seem to have a misunderstanding between `dynamic_cast` a=
nd `typeid`. They&#39;re not the same thing, and they&#39;re only tangentia=
lly related. Yes, they&#39;re both RTTI mechanisms, but they&#39;re very <i=
>different</i> mechanisms.<br><br>`dynamic_cast` is for doing conversions f=
rom a base class to a derived one safely. This does not require any access =
to `type_info` objects. It does require that the compiler generate some per=
-type information, but <i>only</i> for polymorphic classes. You can&#39;t u=
se `dynamic_cast` with non-polymorphic types.<br><br>`typeid` is for fetchi=
ng the dynamic type of an object, as represented by a `type_info` object. T=
he compiler does not need to generate this for every type; it only needs to=
 generate it for types that you use `typeid` on statically and for all poly=
morphic classes (since it needs to be able to get at the `type_info` for th=
e dynamic type of the object).<br><br>The only similarity is that they both=
 rely on per-type information for polymorphic types. Though, perhaps not th=
e <i>same</i> information, since they&#39;re doing different things with it=
..<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"> The syntax like stated of course can be debated upon, it can actually be=
 a #pragma whatever people prefer.<br></div></blockquote><div><br>#pragmas,=
 like attributes, have to be things that can be ignored. But your suggestio=
n has actual visible behavior. Your suggestion makes it impossible to use u=
nannotated types in `std::any`, for example. `any` relies on `type_info` ob=
jects for verification of `any_cast`ing.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9809872a-c8c6-49ce-9bbc-d51e46711cfe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9809872a-c8c6-49ce-9bbc-d51e46711cfe=
%40isocpp.org</a>.<br />

------=_Part_5113_1415569521.1501082315571--

------=_Part_5112_634109744.1501082315571--

.

------=_Part_4176_1625698881.1501083618558
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Someone correct me if I=E2=80=99m wrong, but isn=E2=80=99t it already the c=
ase that optimizing compilers generate type_info lazily? (i.e. only where n=
eeded)

-Ray

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/33a77355-1cd9-4e4f-a7ad-32ded7a5442e%40isocpp.or=
g.

------=_Part_4176_1625698881.1501083618558--

.

On quarta-feira, 26 de julho de 2017 08:40:18 PDT Ray Hamel wrote:
> Someone correct me if I=E2=80=99m wrong, but isn=E2=80=99t it already the=
 case that
> optimizing compilers generate type_info lazily? (i.e. only where needed)

You are correct. The typeinfo is generated:
 a) for polymorphic types, along with the virtual table (which needs to ref=
er=20
to the typeinfo anyway)
 b) for other types, on use (typeid, throw or catch)

The virtual table for polymorphic types is generated alongside the key virt=
ual=20
method, which is the first non-inline virtual function (override or not) in=
=20
declaration order. Well-written libraries take care to make sure that those=
=20
functions are properly defined in a .cpp and properly exported from the=20
..DLL/.so.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3346122.Q0evAOZalF%40tjmaciei-mobl1.

.