On Wed, Jun 27, 2012 at 2:35 PM, Chiheng Xu <chiheng...@gmail.com> wrote:
> 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.
RTTI requires more space than TREE_CODE, so it's not universally better.
> 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.
We already have all (or most) of this.
>>> > +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 ?
To answer, no - we should not enable RTTI (nor exceptions).
Richard.
