Boost logo

Boost :

Subject: Re: [boost] xml?
From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2010-04-09 13:58:52


On 04/09/2010 01:50 PM, Larry Evans wrote:
> On 04/09/10 11:46, Stewart, Robert wrote:
>> Stefan Seefeld wrote:
>>> On 04/09/2010 12:34 PM, Larry Evans wrote:
>>>> On 04/09/10 10:48, Mathias Gaunard wrote:
>>>>> Some could argue that the point of a base class is moot if
>>>>> you have to downcast it to make anything useful with it,
>>>> But boost.variant has to do the equivalent of downcasting based on
>>>> discriminant (the value returned by which()).
>>> No, accessing a member of a union is not really a cast, neither
>>> conceptually nor technically.
>>
>> Conceptually, they are doing the same: determining whether the
>> requested type is appropriate and returning the appropriately typed
>> value. However, dynamic_cast does so by comparing RTTI objects,
>> which may be more expensive than the discriminator comparison, and
>> then by apply fixups to the this pointer to account for MI, virtual
>> bases, etc.
>>
>> What's more, once the dynamic_cast has been done, the various
>> functions calls may still wind up being virtual, depending upon how
>> things are implemented. When using Boost.Variant, the types used
>> could have no virtual functions.
>
> However if the operation to be performed is implemented as a virtual
> function, then no dynamic_casting is needed. Just call the virtual
> function. I thought this was one of the main selling points
> of virtual functions vs. using a switch statement to cover
> all elements in a type hierarchy and then performing
> the operation at the appropriate case clause.

For avoidance of doubt: Does this discussion of virtual methods and
their virtues wrt. common interfaces have anything to do with the
original question about whether or not to capture the set of types that
may be returned by an XPath query in a common base class / type hierarchy ?

Thanks,
         Stefan

-- 
       ...ich hab' noch einen Koffer in Berlin...

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk