Lisandro Dalcin wrote: > On Tue, Oct 6, 2009 at 9:11 PM, Robert Bradshaw > <rober...@math.washington.edu> wrote: > >> On Oct 6, 2009, at 3:32 PM, Lisandro Dalcin wrote: >> >> >>> On Tue, Oct 6, 2009 at 4:03 PM, Robert Bradshaw >>> <rober...@math.washington.edu> wrote: >>> >>>> c99_complex is an internal directive (and I (intentionally) didn't >>>> add it to the list of directives because I wasn't sure if that's the >>>> final interface we wanted), so I think we're safe to change it. I'm >>>> starting to wonder if we even need it at all. >>>> >>> I think we need it... you know how much I hate second guessing... I've >>> never liked that of c99 complex being on depending of "complex.h" >>> being included... Moreover, going C++, I do not know how to detect if >>> <complex> was #include's ... >>> >> #ifdef __STD_COMPLEX ? >> >> > > That is not portable at all. GCC (4.4.1) does #define > _GLIBCXX_COMPLEX_H, but not __STD_COMPLEX ... This macro is available > from IBM's XL C++ compiler and MS VC++, though. > Is there any targeted version of C++ which does not bundle <complex>? Otherwise I'd say we *always* enable C++ complex when C++ is the target, and include <complex> ourself if we need to.
There's nothing about struct complex which would should make you choose them if compiler support complex, they're there for backwards compatability. (If it's about the possibility of doing our own arithmetic implementation, we can always have a seperate directive "slow_and_safe_complex_arithmetic" which just gets and sets real and imag parts -- this isn't linked to storage type). >> I like ccomplex which forces C99 _Complex or std::complex depending >> on __cplusplus, but perhaps I have not adequately justified why the >> auto-setting of PYX_USE_CCOMPLEX is desirable. If complex values are >> only used internally, then our native implementation works fine and >> there is no need for c99 or c++ compiler support. If, however, one >> wants to call some of the math functions in complex.h, or interact >> with some other library that uses C99/std::complex complex numbers, >> then our native implementation will create values of the wrong type. >> >> > > Well, what worries my is that "complex.h" could end-up being included > indirectly... It could certainly happens that some project with many > .pyx files end-up using different complex, just because some of then > #include some third-party header that in turn #include complex.h ... > If complex.h is somehow included indirectly, then it follows that the compiler supports C99 complex types. If the compiler supports C99 complex, there should never be a version to use the backwards-compatability structs. To make it all more predictable, perhaps we should just include "complex.h" explicitly if we know we are in C99 mode? So basically: - structs for pre-C99 - C complex for C99 - C++ complex for C++ Seems much simpler to explain. (I don't mind overriding the chosen implementation with a CYTHON_COMPLEX_IMPL or similar to the C compiler, but I don't see a need for a directive.) >> Since the compiler can figure it out, much better to >> not bother the user with it at all, and have Cython complex numbers >> just work in every scenario. >> > > That's the problem... can the compiler figure out it? For the C++ > case, I still do not know a (standard, portable) way to do that. For > C99, it is supposed that _Complex_I is a macro, but are you 100% sure > that such macro is guaranteed to be defined, or it is just a > consequence of the implementation? > I remember reading that such a macro is part of the C99 standard, at least. > >> To get this, ccomplex=True would set PYX_USE_CCOMPLEX to 1, >> ccomplex=False would set PYX_USE_CCOMPLEX to something like (defined >> (_Complex_I) || defined(__STD_COMPLEX)) rather than 0. >> >> > > I could live with that, provided that this can be changed at C compile > time pasing -DPYX_USE_CCOMPLEX=0/1 ... > > And provided that up-to now (unless you can point a reference) there > is no (portable) way to figure out on C++ that <complex> was > #include'd , perhaps we should default to use std::complex<> in C++ > (what would be the point of using structs in that case) ? > Yep, let's just include <complex> ourself. Dag SVerre _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
