On Fri, Sep 4, 2009 at 1:13 PM, Robert
Bradshaw<[email protected]> wrote:
> On Sep 4, 2009, at 7:36 AM, Lisandro Dalcin wrote:
>
>> On Thu, Sep 3, 2009 at 8:51 AM, Dag Sverre
>> Seljebotn<[email protected]> wrote:
>>> I'm wondering whether we can change this for 0.11.3:
>>>
>>> Currently (if I understand correctly) Cython decides whether you want
>>> C99 complex or Cython complex structs based on whether complex.h is
>>> included or not.
>>>
>>
>> But how the inclusion of "complex.h" is detected ?
>
> It defines a specific macro.
>
OK... Now I remember... This relies in _Complex_I definition, that
AFAIK is in the C99 standard, right? .
>>
>>> I think this is a bit too magic. Even if it works, it seems a bit
>>> confusing, and the thing is it won't work if you're interfacing with
>>> functions in C libraries taking complex numbers (which, of course, in
>>> turn include complex.h, but Cython doesn't see that).
>>>
>>
>> I agree...
>
> If you're working with C libraries that take complex numbers, you've
> included complex.h somewhere (perhaps indirectly) to use them, right?
>
Of course....
>>
>>> I'm wondering if we can move to a directive-only approach,
>>
>> No, please... Use the C preprocessor for "activating" the C99 complex
>> stuff... This way you have chance that the same generated C source
>> could be used with compilers missing C99 complex support...
>>
>> Of course, you can still use a directive, where the options where {
>> yes | no | C-compile-time}, the last based on a preprocessor
>> definition...
>
> I think there is already such a directive (though it's not nicely
> exposed). The whole thing should be better documented as well.
>
Yes, I now see that all this is there...
>>> and make C99
>>> complex the default?
>>>
>>
>> I bet you use GCC as much as me... However, you always forget that we
>> have to live with the nightmare of MSVC compilers being used out
>> there... So I think no, C99 complex cannot be the default
>
> Yep, lets not rely on C99, even though all of us developers have it
> at our fingertips. Otherwise I would have implemented it this way
> from the start...
>
Indeed...
> However, are you bringing this up because something isn't working for
> you like it should?
>
Are you asking this to Dag or to me? Though I had no chance to try
this with petsc4py, I reviewed the implementation in the past and it
looked OK for me... So I do not have any objection... My mail was
actually a reply to Dag's one ...
--
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
