On 01/31/05 20:08:39, Chuck Hinman wrote:
> My question is whether there is a good reason for private scope in
> QuantLib classes.
Yes. Subclasses are not allowed to modify the private members of the base
class, as doing that might cause the object to be in an inconsistent state.
Protected access would give derived classes the right to modify such
members besides inspecting them.
> In my specific example my financial analyst trusts nothing and always
> wants to see the intimate details of all calculations to validate correct
> operation of the classes we use from QuantLib and those classes that we
> write. We recently wrote a class to calculate the forward volatilities
> for caps using the CapFloor and BlackCapFloorEngine classes. Since these
> classes hide important parts in private scope I couldnt inherit from them
> and display their guts, so I copied the CapFloor and BlackCapFloorEngine
> classes, changed private to protected, inherited from the copies, and
> wrote subclasses with methods to save and display the caplet/floorlet
> values at each iteration and some other intimate details. Copying
> QuantLib classes and inheriting from them makes me feel like I am doing
> something foolish and shortsighted.
Depending on your compiler, adding
#define private protected
before including the relevant headers might work. But since what you
actually need is read-only access, there might be other ways to obtain the
same result. If the information is not too intimate--i.e., an
implementation detail--you might add an inspector method to the base class
returning the appropriate information; but this might not be viable for all
the figures you need. In the next QuantLib version, you'll be able to add
to the base class statements such as:
QL_TRACE("caplet value = " << capletValue_);
Such statements would display the information in test compilations and do
nothing in production code. If you find them useful, we'd be happy to
insert them in the code base if you provide us a patch.
Later,
Luigi
Locked
