Re: Public member variables acceptable?
On Jul 4, 9:29 pm, Tony Delroy <tony_in_da...@yahoo.co.uk> wrote:
On Jul 3, 6:28 pm, Alan McKenney <alan_mckenn...@yahoo.com> wrote:
....
I've seen this example
[a "Point" class which hides whether it
uses rectangular or polar coordinates]
get trotted out a lot.
But does anybody in the Real World (TM) actually
do this?
....
Before we get to crazy over this, I'd like
to emphasize that I don't disagree that there
are cases where one does not want to expose
the details of how data is represented.
I'm simply saying that _this_ example -- a point class
which hides its representation so that the implementer
can switch between coordinate systems -- doesn't
seem realistic to me.
But I'm willing to change
my mind if someone has actually done it and
found this all that useful in a real-world application.
Sometimes on large projects you're providing some libraries and can't
predict what the client will end up wanting to do to them.
My experience with mathematical libraries is that
if there are several ways to do something, and
which is best depends upon the application, you
supply all of them and leave the choice to the user.
In the case of a "point" class, this would mean having
a "rectangular_point" and a "polar_point" class, with
appropriate operations and with functions to
transform between the two.
... at the library level there's no way for to know what kind of
operations the app might perform, and how frequently or with how much
performance sensitivity. Clearly there are operations that are
trivial for polar coordinates but slow for x,y - .... so a good interface
should prevent the client getting locked in to one implementation. As
Francis points out, there can be cases where you start more or less
blind, and it may be only after application profiling that you can
pick the best implementation.
If your problem is complex enough that you can't eyeball
which coordinate system is better, and the cost of processing
your "point" class is significant, profiling isn't going
to be much help. You're going to need to pick a few
approaches that your analysis of the problem suggests
are profitable and benchmark them. (That is, run the
same problem on each version and compare overall times.)
+ + +
My point is that some aspects of the implementation are
too important to the user to be left unspecified. That's
why the STL includes several types of containers, and it
does _not_ include a one-size-fits-all container.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]