On Wed, Jun 27, 2012 at 2:19 AM, Lawrence Crowl <cr...@google.com> wrote:
> 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.
>
dynamic_cast use RTTI, while TREE_CODE are poor man's type info. RTTI
is better than TREE_CODE. But, If you decide to use RTTI, TREE_CODE
become redundant, that means all use of TREE_CODE should be removed,
sooner or later. Are you prepared for that ?
If every types in the type hierarchy, not just the root type and
leaves types, has a TREE_CODE, and you maintain a database of
inheritance relationship and other info of types of different
TREE_CODEs, then, for a object of a given TREE_CODE, you know its
TREE_CODE and type info, you know whether or not the object can be
cast to another type, and, you can know other info about the type,
like the size of object of the type, string name of the type.
This can be implemented as below. For every type in the type
hierarchy, static define a object of meta type( meta class, or class
class) to describe the type info of the specific type for a given
TREE_CODE. All of the meta type objects of different TREE_CODEs are
organized as an array, which is indexed by the value of TREE_CODE. And
you provide a set of C functions , that judge whether a object that
has a given TREE_CODE can be cast to a type that has another TREE_CODE
and retrieve the type info of a object that has a given TREE_CODE.
>> > +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.
>
Template function may be not necessary.
And, virtual method is not necessary.
Just normal C functions can work if you have the type info of a given TREE_CODE.
> Shall we enable RTTI?
Are you prepared to remove all use of TREE_CODE ?
--
Chiheng Xu
