|
Boost : |
From: Joerg Walter (jhr.walter_at_[hidden])
Date: 2002-04-07 15:24:42
Hi Kresimir,
you wrote:
> > The functions in math.h define a generic interface for scalar functions
like
> > real()/imag()/conj() over the types float, double and std::complex<>.
> >
> > The implementation currently uses non template functions for the basic
types
> > and template functions for std::complex<>. If the non template functions
are
> > not inlined, declaration and definition need to be separated AFAIK.
>
> Yes, AFAIK you are right. But all functions in math.h are simple
one-liners,
> so why they are not always inlined?
That's more a matter of principle. As you may have noticed, all inline-able
functions are prefixed with the preprocessor macro NUMERICS_INLINE, which
expands to something like _force_inline for a certain compiler (MSVC ;-).
This is really important for the performance. OTOH, one day we'll talk about
bloated code therefore, and I think we'll then distinguish between
NUMERICS_INLINE and NUMERICS_INLINE_ALWAYS ;-) So currently I wouldn't like
to support a third kind of inlining.
> > I think, it should be possible to extend numerics::type_traits<>, so
that
> > real() could be written for example
> >
> > template<class T>
> > typename type_traits<T>::real_type real (const T &t) {
> > return type_traits<T>::real (t);
> > }
> >
> > and hope, that most compilers will accept this ;-) If this works, it
should
> > be possible to eliminate instant.cpp.
>
> It seems to work at least with g++ 2.95.4, 2.96 & 3.04. I attached
> ziped diffs for `config.h', `traits.h' and `math.h' (with respect to
> the latest CVS files - dated Mar, 26th) which implement your
> suggestion. I introduced `NUMERICS_USE_EXTENDED_TRAITS'
> macro. Simple test program is also there, and Peter's example
> from the original post can be compiled, too ;o)
We were working on the same problem ;-( and you solved it faster :-). I
adopted your changes (slightly modified), tested with MSVC and ICC also and
checked them in. Thanks.
> Can this solve Toon's problems (message `ublas linking
> on gcc')?
As far as I understood from an offline conversation with Toon, yes.
Best regards
Joerg
> PS. I added `#include <algorithm>' and `#include <iterator>' to
> `traits.h' because g++ complains that `std::max()' and iterator
> tags are unknown.
>
> PPS. g++ 2.96 complains about (re)definition of `iterator<>' in
> `iterator.h'. Therefore, line 26 should be
>
> #if __GNUC__ <= 2 && __GNUC_MINOR__ <= 95
>
> (Yes, I know that 2.96 is not official version, but ... )
;-) I changed that accordingly.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk