On Tue, Sep 22, 2009 at 4:13 PM, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
>> Dynamic downcasts do usually indicate a weakness in the design. But an
>> even more fundamental matter of style is to not repeat yourself. You
>> don't use "x + y" if you need the sum of x and y in ten places; you do
>> "sum = x + y" and then use "sum." The same applies here. You're not
>> just working around a deficiency in the compiler, you're saving
>> yourself work later if you need to change all those values, and you're
>> giving it some kind of semantic attachment by putting it in a named
>> location.
>
> What if x and y are possibly changing in between calls to x + y?
>
> I'm thinking of a situation where o *might* be changing, but also might not,
> the compiler could do some optimization to avoid the dynamic-cast calls in
> the cases where it doesn't change. These would be hard to code manually.
> My understanding of pure function benefits (and it's not that great) is
> that you can express yourself how you want and the compiler fixes your code
> to be more optimized knowing it can avoid calls.
Realistically, how often is this going to come up? Why the hell are we
looking at what amounts to CSEE on a rarely-used construct when there
are far more important performance issues? I understand wanting to
solve this problem for pedagogical reasons, but practically, I don't
see the benefit.
>> Besides, you're probably going to be doing:
>>
>> if(auto d = cast(Derived)baseRef)
>> {
>> // ..
>> }
>>
>> so you've already bound the result of the dynamic cast to a variable.
>> *shrug*
>
> Probably. But even then, if this statement is in a loop that might not
> change baseRef, the compiler can avoid dynamic casting again.
Then you'd hoist the conditional out of the loop. Again, not specific
to dynamic downcasts.
