Notes on const vectors

The code

    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 SourceForge.net Logo, O2scl Sourceforge Project Page