Boost logo

Boost :

From: Kevin Lynch (krlynch_at_[hidden])
Date: 2001-10-04 12:02:03


Eric Ford writes:

> Is there a reason why you use define's to deal with the std_compat
> namespace? Why not just use std_compat and make std_compat an alias
> to std, iff the cmath is compliant?

No there really wasn't a reason, it was just the snap decision I made;
in fact, in my development copy, I've changed the way I handle this (I
needed to modify the macros to handle the C99 functions, so the NS is
now a parameter of the macros). I'll look at changing this some more to
use namespace aliasing here (which I agree is probably the right way to
go.

> MAKE_STD_FUNCTION_REAL2 (and SPECIALIZE_...) need to be able to deal
> with arguments of differing types. More template arguments...

> ldexp will either need to take two template arguments (even though we
> know the second should be an int) or be done separately.

I'm not sure I understand these two comments. Could you elaborate a
bit? I understand removing the limitation on the SPECIALIZE_... macros
(I've already run into a need to make the return type a parameter
already for some of the C99 functions). But why does M_S_F_R_2 need to
change? It is a convenience macro that generates four particular
implementations of template overloads ... is it better to provide a new
macro that takes type arguments to change the current one? I'll look
into both approaches. I'm not sure I understand using multiple template
arguments for ldexp; since the second argument MUST be an int, why do we
need to provide it as a template parameter? And if we do, what should
the behavior be for other types? Perhaps you could elaborate a little
bit when you have some time.

> for pow, I think we should specialize
> to allow for integers (more likely to be intentional). I'm not sure
> whether it's appropriate to have the specializations perform
> optimzations in this layer, so maybe just convert both arguments to
> the longer type. Fernado posted some simple type promotion code a
> while ago, which seems reasonable.

Oops... you're right. I'll make sure to add those specializations. I
see these as reasonable

F pow(F,F), F pow(F,I), I pow(I,I), F pow(I,F)

where F is any of the floating point types and I is int or long

I'll also look and see if any of the other functions need this type of
behavior, although I can't think of any off the top of my head for which
this makes sense. I also just realized that I've still never
implemented the integer functions from <cstdlib>

> Making progress...

Cool. I'll try to get these changes made by tomorrow, but I'm not sure
that I'll be able to do so. I'll keep people informed.

Thanks,
E

-- 
-------------------------------------------------------------------------------
Kevin Lynch				voice:	 (617) 353-6065
Physics Department			Fax: (617) 353-6062
Boston University			office:	 PRB-565
590 Commonwealth Ave.			e-mail:	 krlynch_at_[hidden]
Boston, MA 02215 USA			http://physics.bu.edu/~krlynch
-------------------------------------------------------------------------------

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk