Re: [boost] Re: rationals initialization bug

From: Ed Brey (brey_at_[hidden])
Date: 2000-11-29 19:45:54

From: "Gary Powell" <Gary.Powell_at_[hidden]>
> I would prefer that "float" and "double" occur nowhere in the code for
> rational.hpp
>
> Reasoning: is that not too long ago I had to write code for a CPU that did
> not have a floating point processor. Linking in the floating point
> simulation library was expensive, slow, increased my executable size and
not
> allowed in the released product.

A feature should be included or excluded based on its value to the community
in general.  If a small group has trouble with a standard language feature,
the burden of working around the problem should be on that group and should
be invisible to the general community.

In this particular case, an embedded world workaround might be something
like this, in which float is defined away to a do nothing class that exists
only to appease the rational header.

class nobloat {/*implicit conversions as needed (e.g. to int)*/};
#define float nobloat
#define double nobloat
#include <rational.hpp>

Of course, even better could be a macro that tells rational to preprocess
out its floating point dependent code (especially if the code has long
doubles).  In any case, as real as the constraints of embedded systems are
(I've been there, too), they should not affect the mainstream design of
rational, but rather be dealt with as afterthoughts.

> As C++ is still used in embedded systems, some of which may still use this
> processor, I suggest that if there is an alternative which allows
> independent linking choose it. i.e. Ship the conversion algorithm in a
> separate file. Users who don't require the conversion won't get it. Should
a
> future algorithm for conversion prove better for a particular application,
> the programmer would be able to change it with greater ease. It would also
> emphasize what algorithm was chosen, and that in fact it is replaceable.

This is what should be the deciding factor.  It comes down to encapsulation.
If we find a clear way that floating point should be part of rational, be
that by constructor, static member, or whatever, we should do it.  If
floating point interfaces turn out to be orthogonal to rational and
implementations varied, then there may be grounds for a separate header
file; however, appeasing a language subset provides no such grounds.

Staying-away-from-ec++-ingly yours,
(http://www.research.att.com/~bs/bs_faq.html#EC++)
Ed