Posted by
Slava Mazur on
Aug 29, 2008; 6:29pm
URL: http://quantlib.414.s1.nabble.com/STL-compliant-containers-for-XLOPER-tp12234p12236.html
Hi Eric,
>The contribution would be welcome. I understand that you would need to
do
>some negotiating on your side, please keep me posted. Would you be
able to
>provide a statement authorizing the release of this code under the
QuantLib
>license? Depending on you contract and the laws in your country it may
be
>that your thoughts are the property of your employer ;) in which case
the
>statement would have to come from them.
Negotiations are still in progress. Waiting for a decision from a higher
level management. Lower level is okay.
>It would be good to get some example applications for XLL Containers,
maybe
>showing the usage of the classes with and without ObjectHandler?
I think, a good one is how QuantLibXL::operToQlArray() could be
implemented with the help of XLL array. Consider the following, more
concise and more intuitive IMHO (BTW you might want to consider passing
the second parameter by const reference):
QuantLib::Array operToQlArray(const OPER &xVector,
const std::string paramName) {
try {
xll::CellPtrConst<boost::any> pxVector(&xVector);
OH_REQUIRE(!(pxVector->isError()),
"input value '" << paramName << "' has type=error");
if (pxVector->isMissingArg() || pxVector->isNil()) {
return QuantLib::Array();
} else if (pxVector->isArray()) {
xll::VectorPtrConst<double> pv(&xVector);
QuantLib::Array a(pv->size());
std::copy (pv->begin(), pv->end(), a.begin());
return a;
} else if (pxVector->isString()) {
using namespace boost::algorithm;
xll::VectorPtrScoped<double> pv;
split(*pv,(std::string)*xll::CellPtrConst<std::string>(&xVector),
is_any_of(",;"));
QuantLib::Array a(pv->size());
std::copy(pv->begin(), pv->end(), a.begin());
return a;
} else {
xll::VectorPtrScopedExcel<double> pv(&xVector);
QuantLib::Array a(pv->size());
std::copy (pv->begin(), pv->end(), a.begin());
return a;
}
} catch (const std::bad_cast &e) {
OH_FAIL("operToVector: error converting parameter '" << paramName
<< "' : " << e.what());
}
}
There are also several general examples in html files I sent to you
previously. Another one converts input sequence of numbers in a string
format to a double array and returns it as a range to Excel:
XLOPER * sequence2doubleArray (const char *input) {
xll::VectorPtrWeakExcel<double> res;
try {
using namespace boost::algorithm;
split(*res, input, is_any_of(",;"));
} catch (const std::bad_cast &e) {
res->setError();
}
return res;
}
>As you observe, for ObjectHandler 0.9.6, boost::any is replaced
everywhere >by
>property_t, which wraps boost::variant, because the latter is supported
>natively by boost::serialization. I'm not sure how this change impacts
>your
>classes, which also use boost::any but in a different context.
I'm having a problem with such a design. Previously, when property value
type was boost::any and you handled OPER case as one of possible type a
property can have, I could use xll::CellPtrSharedExcel<boost::any> class
in my extension of ValueObject like the following and the function
ohPropertyValue worked correctly:
void MyValueObject::setProperty(const std::string& name,
const boost::any& value)
{
iterator it = properties_.find (name);
if (it == properties_.end())
throw PropertyNotFound;
if (value.type() == typeid(OPER*))
it->second = xll::CellPtrSharedExcel<boost::any>(value);
else
it->second = value;
}
boost::any MyValueObject::getProperty(const std::string& name) const
{
iterator it = properties_.find (name);
if (it == properties_.end())
throw PropertyNotFound;
boost::any w = it->second;
if (w.type() == typeid(xll::CellPtrSharedExcel<boost::any>))
return (OPER*)boost::any_cast <
xll::CellPtrSharedExcel<boost::any> > (w);
else return w;
}
My idea was to propose introduction of
xll::CellPtrSharedExcel<boost::any> as one of possible property type.
This way one could avoid unneccessary casts, transformations, and
duplication of data. However, with introduction of property_t you've
actually eliminated OPER and related types from the list of possible
types a property can have.
Now I have to convert my original data from OPER to one of acceptable
property_t type and thus to create a copy of data just to satisfy more
rigid property_t requrements. Note that by nature of my projects I'm
dealing with time series data, so creating unneccessary copies is highly
undesirable.
I'm wondering is it possible to generalize property_t concept making it
a template which depends on a variable list of types?
Thanks,
Slava Mazur
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev