const ovector x; //ovector_const_base &cb=x;
doesn't complile, which is a bit weird (you have to use a const ovector_const_base reference instead).
Also, ovector_base has a function like
double &operator[](size_t i)
which in principle could be actually const, i.e.
double &operator[](size_t i) const
but isn't. Also annoying is that "const ovector_base &x" is not a perfectly generic base, since it's not a base for "ovector_const_base &y" or "const ovector_const_base &y2" (last one I'm not sure about). I had thought about making ovector_const_base a child of ovector_base instead, but that means that the interpolation routines which have ovector_const_base as a default template parameter will have to be changed. (Is this a problem?) Even worse, ovector_const_base classes could be upcasted easily to ovector_base removing const correctness.
Finally, the meaning of "const ovector_view" vs. "ovector_view" is kind of confusing, though maybe we just have to explain to the user that "const" means const where-ever it appears.
Happily, this new branch removes the need for "ovector_view_assign", in the trunk which was kind of frustrating.
Probably the best new solution is to rework the hierarchy altogether and admit that ovector and ovector_view aren't really related objects. There is no such thing as a generic base for both ovector and ovector_view. This of course might require a redesign of the solver classes, for example, as they treat these two classes as necessarily related (alloc_vec_t is supposed to be related to vec_t). Maybe not though, I need to think about this more.
Documentation generated with Doxygen and provided under the GNU Free Documentation License. See License Information for details.
Project hosting provided by
,
O2scl Sourceforge Project Page