On Fri, Oct 12, 2012 at 1:22 AM, Richard Biener
<richard.guent...@gmail.com> wrote:
> On Thu, Oct 11, 2012 at 10:39 PM, Xinliang David Li <davi...@google.com>
> wrote:
>> On Thu, Oct 11, 2012 at 1:23 PM, Lawrence Crowl <cr...@googlers.com> wrote:
>>> On 10/10/12, Xinliang David Li <davi...@google.com> wrote:
>>>> In a different thread, I proposed the following alternative to 'try_xxx':
>>>>
>>>> template<typename T> T* symbol::cast_to(symbol* p) {
>>>> if (p->is<T>())
>>>> return static_cast<T*>(p);
>>>> return 0;
>>>> }
>>>>
>>>> cast:
>>>>
>>>> template<typename T> T& symbol:as(symbol* p) {
>>>> assert(p->is<T>())
>>>> return static_cast<T&>(*p);
>>>>
>>>> }
>>>
>>> My concern here was never the technical feasibility, nor the
>>> desirability of having the facility for generic code, but the amount
>>> of the amount of typing in non-generic contexts. That is
>>>
>>> if (cgraph_node *q = p->try_function ())
>>>
>>> versus
>>>
>>> if (cgraph_node *q = p->cast_to <cgraph_node *> ())
>>>
>>> I thought the latter would generate objections. Does anyone object
>>> to the extra typing?
>>>
>>> If not, I can make that change.
>>
>> Think about a more complex class hierarchy and interface consistency.
>> I believe you don't want this:
>>
>> tree::try_decl () { .. }
>> tree::try_ssa_name () { ..}
>> tree::try_type() {...}
>> tree::try_int_const () {..}
>> tree::try_exp () { ...}
>> ..
>>
>> Rather one (or two with the const_cast version).
>>
>> template <T> T *tree::cast_to ()
>> {
>> if (kind_ == kind_traits<T>::value)
>> return static_cast<T*> (this);
>>
>> return 0;
>> }
>
> I also think that instead of
>
>>> if (cgraph_node *q = p->cast_to <cgraph_node *> ())
>
> we want
>
> if ((q = cast_to <cgraph_node *> (p))
>
> I see absolutely no good reason to make cast_to a member, given
> that the language has static_cast, const_cast and stuff. cast_to
> would simply be our equivalent to dynamic_cast within our OO model.
>
> Then I'd call it *_cast instead of cast_*, so, why not gcc_cast < >?
> Or dyn_cast <> (). That way
>
> if ((q = dyn_cast <function *> (p))
>
> would be how to use it. Small enough, compared to
>
> if ((q = p->try_function ()))
>
> and a lot more familiar to folks knowing C++ (and probably doesn't make
> a difference to others).
>
> Thus, please re-use or follow existing concepts.
Agree. dyn_cast<..> for try casting, and cast<..> or gcc_cast<..>
casting with assertion sounds good.
>
> As for the example with tree we'd then have
>
> if ((q = dyn_cast <INTEGER_CST> (p)))
>
> if we can overload on the template parameter kind (can we? typename vs. enum?)
> or use tree_cast <> (no I don't want dyn_cast <tree_common> all around the
> code).
yes, that also sounds good to me.
thanks,
David
>
> Thanks,
> Richard.
>
>>
>> thanks,
>>
>> David
>>
>>
>>>
>>> --
>>> Lawrence Crowl
