Re: dlw_int/dlw_gcd review summary

From: helmut.zeisel_at_[hidden]
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 
suggest you
> > /consider/ recruiting someone to help you port it. Although this 
compiler
> > has numerous conformance problems, enough people use it that your 
library
> > 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 
me to
> play "guess the MSVC6 fix."  However, I want to support all the 
platforms
> that the rational and pool libraries did, since I'm trying to 
replace the
> specialty GCD/LCM routines they had.  So if someone could provide a 
fix
> 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

#ifndef BOOST_MSVC

I do not know whether compile-time gcd ever had worked 
under VC++.
If my brute-force workaround is considered to be sufficient,
I can help you to identify the respective
code fragment(s).

> 
> > --------------- dlw_gcd -------------
> > 
> > Fernando Cacciola:
> > 
> > The use of the unary '+' operator adds unneccessary dependencies; 
consider
> > removing it.
> 
> A numeric class should have an unary operator+, and it isn't hard to 
add
> 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+.

Helmut