On 6/26/12, Jason Merrill <ja...@redhat.com> wrote:
> On 06/25/2012 06:26 PM, Lawrence Crowl wrote:
> > +or<code>gcc_unreachable</code>. If the checks are expensive or the
> > +compiler can reasonably carry on after the error, they may be
> > +conditioned on<code>--enable-checking</code>.</p>
>
> by using <code>gcc_checking_assert</code>
I inserted that suggestion, but note that I did not create that text,
only moved it.
> [Rationale]
> > +FIXME: Discussion of deleting inappropraite special members.
>
> Is this FIXME still needed? The text following it seems to cover the
> issue well enough.
No longer needed.
> > +However, by default, RTTI is not permitted
> > +and the compiler must build cleanly with <code>-fno-rtti</code>.
>
> This seems like an unnecessary restriction to me.
>
> > +Disabling RTTI will save space in the compiler.
>
> This is a fine reason to disable RTTI if it isn't used, but doesn't
> seem like a strong reason to prohibit using it. The information is
> only emitted for classes with virtual functions, isn't very large,
> is typically emitted in only one object file, and since it lives
> in .rodata it can be shared between multiple compiler processes.
>
> > +Checking the type of a class at runtime usually indicates a design problem.
>
> The tree_contains_struct machinery recently added to GCC maps
> directly onto dynamic_cast;
>
> if (CODE_CONTAINS_STRUCT(TREE_CODE(t),TS_DECL_WRTL))
> /* do something with t->decl_with_rtl */
>
> translates roughly to to
>
> if (decl_with_rtl *p = dynamic_cast <decl_with_rtl *>(t))
> /* do something with p */
>
> When new interfaces are added partway down an inheritance tree,
> dynamic_cast is the right way to access them. This isn't checking
> what the type is, it's checking whether the object supports a
> particular method.
>
> The fact that we've gone to the trouble to implement this
> functionality in C suggests to me that using it isn't always
> indicative of a design problem. :)
Personally, I am fine with using dynamic_cast. I was writing up what
I thought was a consensus on the wiki. I can live without it, or I
can use it profitably. Whatever you all decide, I will write up.
> > +If you need to know the type of a class for some other reason,
> > +use an enum or a virtual member function
> > +that coverts a pointer to the more derived class.
> > +For example,
> > +</p>
> > +
> > +<blockquote><pre><code>
> > +common_type *p = ....;
> > +if (specific_type *q = p->to_specific ()) {
> > + // We have and can use a specific_type pointed to by q.
> > +}
> > +</code></pre></blockquote>
>
> This is basically equivalent to dynamic_cast except that you need
> to clutter up your root base class with one virtual function for
> each derived class you want to be able to convert to.
Note quite equivalent, as you can implement to_specific with
non-virtual classes using the TREE_CODE. Thus would could implement
a type-save dynamic pointer converter before converting to virtual
classes.
OTOH, we could probably work up a template function that looks like
dynamic_cast but uses the TREE_CODE instead, achieving the same
intermediate step.
I agree that it does clutter up the base class.
Shall we enable RTTI?
--
Lawrence Crowl
