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.
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).
Thanks,
Richard.
>
> thanks,
>
> David
>
>
>>
>> --
>> Lawrence Crowl
