Passing around vectors of shared_ptrs to RateHelpers

[kw1958]

Folks,

            We have developed some classes that essentially parallel the RateHelpers hierarchy. They all derive from OurRateHelper which is essentially defined like this:

 

 class OurRateHelper : public QuantLib::RateHelper {

            // Constructor definitions here�

            inline void setRateShift(Real s) {rateShift_ = s;}

            inline Real getRateShift() const {return rateShift_;}

      protected:

             Real rateShift_;

}

 

[Luigi Ballabio]

On 11/17/2005 02:36:09 PM, [hidden email] wrote:

>             We have developed some classes that essentially parallel
> the RateHelpers hierarchy. They all derive from OurRateHelper>
>
> Here is my problem. My class that creates the collection of
> YieldTermStructures takes (by choice) as a parameter an input of
> type:
>
> std::vector<boost::share_ptr<OurRateHelper> > &v // Vector1
>
> Unfortunately when I need to create the individual  
> PiecwiseFlatForward objects they only take
>
> std::vector<boost::share_ptr<OurRateHelper> > &v // Vector2
>
> as an input. Passing in a Vector1 in place of a Vector2 causes a
> compile time error as it should.
>
> What would be the best way to massage the Vector1 so that it could be
> passed as a Vector2. A cast? Create another Vector2 object whose
> elements are pointers to the OurRateHelper objects?

Given your

std::vector<boost::shared_ptr<OurRateHelper> > v;

you can do as follows:

std::vector<boost::shared_ptr<RateHelper> > w(v.size());
for (Size i=0; i<v.size(); i++)
     w[i] = boost::dynamic_pointer_cast<RateHelper>(v[i]);

after which you can pass w to the piecewise curve. The newly  
instantiated shared pointers to RateHelper and your shared pointers to  
OutRateHelpers point to the same instances.


> In addition can you QuantLib creators tell me why all of the  
> internals of the RateHelpers are private and not protected?

When we write a class, we start by giving its member the strictest  
access level. The rationale is that things might change: while it is  
easy to start this way and relax the access later should the need  
arise, it would be more difficult to start relaxed and restrict it  
later as client code might have come to rely on the member access.

Since the need seems to have arisen, in which way should I relax the  
access to make it easier for you to write your classes? Should I make  
the data protected (but wouldn't this force you to use multiple  
inheritance, e.g. from both OurRateHelper and QuantLib::DepoRateHelper  
to OurDepoRateHelper?) or provide getters?

Another possibility is that you modify the classes yourself and send me  
a patch.

Later,
        Luigi

----------------------------------------

All generalizations are false, including this one.
-- Mark Twain