Date: 2001-10-09 01:33:26
--- In boost_at_y..., Daryle Walker <darylew_at_m...> wrote:
> on 9/30/01 10:39 PM, David Abrahams at david.abrahams_at_r... wrote:
> > Ed Brey:
> > None of this code compiles with VC6sp5. As review manager, I
> > /consider/ recruiting someone to help you port it. Although this
> > has numerous conformance problems, enough people use it that your
> > will have a considerably smaller audience than it otherwise might.
> Since I don't use Windows (or an IBM-style PC), it's very hard for
> play "guess the MSVC6 fix." However, I want to support all the
> that the rational and pool libraries did, since I'm trying to
> specialty GCD/LCM routines they had. So if someone could provide a
> that's close to my style, that's OK.
I personally need only the run-time gcd.
In the (older) version I tested
the run-time gcd worked well under VC++ 6.0,
I just switched off the compile-time specific code by
I do not know whether compile-time gcd ever had worked
If my brute-force workaround is considered to be sufficient,
I can help you to identify the respective
> > --------------- dlw_gcd -------------
> > Fernando Cacciola:
> > The use of the unary '+' operator adds unneccessary dependencies;
> > removing it.
> A numeric class should have an unary operator+, and it isn't hard to
> one. It gives the result expression a pretty symmetry. :^)
In the previous version the symmetry was kept by
two return statements, which is not so nice
from the structural programming point of view.
The Euclidian Algorithm, which you used,
usually works on an Euclidian Ring, so I agree that it is
very natural to have an operator+.
OTOH, operator+ might need some CPU time
for a user defined data type such as big_int,
even when one of the operands is zero.
Since the critical part w.r.t. to performance, however,
is operator %=, this will probably make not much difference.
The more severe restriction, IMHO, is that you
require an absolute value of the same type as your ring elements,
which indeed restricts your algorithm to integer-like classes.
Anyway, it is easier to weaken restrictions in the future
than to add new ones,
and your current implementation already allows an escape,
so I see no real problem in keeping operator+.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk