Complex number portability

[Niels Elken Sønderby]

Hi all!

While implementing a formula involving complex numbers I encountered a few
problems.

First, I need to use log, exp and pow, but the QL-macros don't work with
complex numbers. (I guess they use the global namespace versions.) So when a
is complex, instead of writing QL_POW(a, x), I have to write std::pow(a, x)
etc. (See full code below.)

What's the correct and portable way to deal with this?

Second, when compiling the below piece of code using the "Debug
Multithreaded DLL"-setting (as required for QuantLib), I get the following
warning message from Visual C++ 6.0: "non dll-interface class
'std::_Complex_base<double>' used as base for dll-interface class
'std::complex<double>'" (full warnings below)

Everything works fine, but it just looks ugly. Does anyone have a way to
avoid these warnings?

Cheers... Niels

// --- QLcomplex.cpp ---
#include <iostream>
#include <complex>
#include <ql/quantlib.hpp>

int main()
{
    std::complex<double> a(0.1,0.5), b(0.2,0.4), c(0.2,0.3);
    double x = 0.2, res;

    res = std::real(std::pow(a, x) * std::exp(b) * std::log(c));
//    res = std::real(QL_POW(a, x) * QL_EXP(b) * QL_LOG(c));

    return 0;
}

--------------------Configuration: QLcomplex - Win32
Debug--------------------
Compiling...
QLcomplex.cpp
e:\program files\microsoft visual studio\vc98\include\complex(203) : warning
C4275: non dll-interface class 'std::_Complex_base<float>' used as base for
dll-interface class 'std::complex<float>'
        e:\program files\microsoft visual studio\vc98\include\complex(203) :
see declaration of 'complex<float>'
e:\program files\microsoft visual studio\vc98\include\complex(216) : warning
C4275: non dll-interface class 'std::_Complex_base<double>' used as base for
dll-interface class 'std::complex<double>'
        e:\program files\microsoft visual studio\vc98\include\complex(216) :
see declaration of 'complex<double>'
e:\program files\microsoft visual studio\vc98\include\complex(229) : warning
C4275: non dll-interface class 'std::_Complex_base<long double>' used as
base for dll-interface class 'std::complex<long double>'
        e:\program files\microsoft visual studio\vc98\include\complex(229) :
see declaration of 'complex<long double>'
Linking...

QLcomplex.exe - 0 error(s), 3 warning(s)

[Jens Thiel]

> Everything works fine, but it just looks ugly. Does anyone have a way
> to avoid these warnings?

If you made absoluetly sure that there won't be any problems later you can
do (MSVC only)
    #pragma warning(disable: 4275)

Regards,

Jens.

> --------------------Configuration: QLcomplex - Win32
> Debug--------------------
> Compiling...
> QLcomplex.cpp
> e:\program files\microsoft visual studio\vc98\include\complex(203) :
> warning C4275: non dll-interface class 'std::_Complex_base<float>' used
> as base for dll-interface class 'std::complex<float>'
>        e:\program files\microsoft visual
>        studio\vc98\include\complex(203) :
> see declaration of 'complex<float>'

[Luigi Ballabio-2]

At 10:11 AM +0200 4/25/03, Niels Elken Sønderby wrote:
>First, I need to use log, exp and pow, but the QL-macros don't work with
>complex numbers. (I guess they use the global namespace versions.) So when a
>is complex, instead of writing QL_POW(a, x), I have to write std::pow(a, x)
>etc. (See full code below.)
>
>What's the correct and portable way to deal with this?

Niels,
        QL_POW should be defined to std::pow when possible, and to
pow in the global namespace only if there's no such function in std.
Mistakenly, I was under the impression that the latter was the case
when using Visual C++ (at least, at a certain point in the past it
refused to compile when I used std::pow.) I'll double-check that.

Thanks,
        Luigi

[Niels Elken Sønderby]

> > Everything works fine, but it just looks ugly. Does anyone have a way
> > to avoid these warnings?
>
> If you made absoluetly sure that there won't be any problems later you can
> do (MSVC only)
>     #pragma warning(disable: 4275)

Well, I guess, I can't... ;-) Some mysterious linking problem or whatever
might of course show up sometime, but I'll probably use your
pragma-statement it in my own code. Thanks!

If someone knows something about what the root of the problem is, I would be
happy to hear this.

Regards... Niels