On 9/19/12, Gabriel Dos Reis <g...@integrable-solutions.net> wrote:
> On Wed, Sep 19, 2012 at 1:39 PM, Lawrence Crowl <cr...@googlers.com> wrote:
>> On 9/19/12, Gabriel Dos Reis <g...@integrable-solutions.net> wrote:
>>> On Sep 19, 2012 Richard Guenther <richard.guent...@gmail.com> wrote:
>>> > Indeed. Btw, can we not provide a specialization for
>>> > dynamic_cast <>? This ->try_... looks awkward to me compared
>>> > to the more familiar
>>> >
>>> > vnode = dynamic_cast <varpool_node> (node)
>>> >
>>> > but yeah - dynamic_cast is not a template ... (but maybe there
>>> > is some standard library piece that mimics it?).
>>>
>>> No, it is a language primitive.
>>>
>>> but we can define out own operation with similar syntax that allows
>>> for specialization, whose generic implementation uses dynamic_cast.
>>>
>>> template<typename T, typename U>
>>> T* is(U* u) {
>>> return dynamic_cast<T*>(u);
>>> }
>>
>> At this point, dynamic_cast is not available because we do not
>> yet have polymorphic types. There has been some resistance to
>> that notion.
>
> Hmm, when did we rule that out?
We have not ruled it out, but folks are, rightly, concerned about any
size increase in critical data structures. We are also currently
lacking a gengtype that will handle inheritance. So, for now at
least, we need a scheme that will work across both inheritance and
our current tag/union approach.
> We currently implement dynamic_cast using the poor man's simulation
> based on tree_code checking. We can just as well give such
> simulation the is<> notation.
>
>> Absent dynamic cast, we need to specialize for various type
>> combinations. Function template specialization would be handy,
>> but C++ does not directly support that. We could work around
>> that.
>
> We can always use the standard workaround: call a static member
> function of a class template that can be specialized at will.
>
>> However, in the end, the fact that try_whatever is a member
>> function means that we can use a notation that depends on context
>> and so can be shorter. That is, we can write 'function' instead of
>> 'cgraph_node *'.
--
Lawrence Crowl
