here's a puzzle:

In order to use this method with the same operator for vector3d, I have to
remove the const qualifier on the vector3d & argument because of the way my
spherical components are computed.

The class gives the user options for how the vector is displayed when passed to
ostream.

There are two formats, COMPONENT and EXPRESSION and two styles, CARTESIAN and
SPHERICAL, so the ways a vector can be displayed are:

1) <X,Y,Z>
2) mag * <sin(phi) * cos(theta), sin(phi) * sin(theta), cos(phi)>
3) X * x + Y * y + Z * z
4) mag * ( sin(phi) * cos(theta) * x + sin(phi) * sin(theta) * y + cos(phi) * z
)

here's the problem:

the public interface for vector3d provides 3 functions for getting mag, phi and
theta but, rather than having those functions calculate the values every time,
which could get expensive, I store the values the first time one is requested.
As if that weren't enough, there are two methods by which the components can
change: 1) by using the [] operator and 2) by using the getIntercept() function
of vector3d, which returns a reference.

To account for changes in the intercept, vector3d keeps a reference copy for
comparison.  each time one of the spherical components is requested, the
reference is compared to the intercept, and if the two are different, the
function calls a private helper recompute_spherical().

all of this, combined, means that the getters for the spherical components
cannot take a const reference, so they can't be used from any function that has
a const qualifier, or used on a const reference.

because the other operators for vector3d work -exclusively- with the intercept
value, this isn't a problem.  The only place where it's a problem is in the
stream operators << and >>.

I could, of course, make a copy of the variable being displayed and work with
that, but it would negate the benefits of lazy computation.

I suppose that I could create a private lookup table common to all vectors by
using a map contained inside an anonymous namespace.  It should only be
accessible from within the file it's contained in, but it would require the
vector3d ctors to handle insertion and deletion of their component values...

and it would risk adding complexity from the map lookup.

thoughts?

Regards,
A.D.B.

Post a reply to this message