On Tue, Nov 3, 2009 at 2:12 PM, Dag Sverre Seljebotn <[email protected]> wrote: > Lisandro Dalcin wrote: >> On Tue, Nov 3, 2009 at 1:06 PM, Dag Sverre Seljebotn >> <[email protected]> wrote: >> >>> Lisandro Dalcin wrote: >>> >>>> On Tue, Nov 3, 2009 at 7:20 AM, Robert Bradshaw >>>> <[email protected]> wrote: >>>> >>>> >>>>> On Nov 3, 2009, at 12:45 AM, Dag Sverre Seljebotn wrote: >>>>> >>>>> >>>>> >>>>>> Robert Bradshaw wrote: >>>>>> >>>>>> >>>>>> >>>>>>> There's >>>>>>> another regression, "cdef int complex" doesn't work anymore (our >>>>>>> structs used to support this, as does gcc, even if it's non-c99). >>>>>>> >>>>>>> >>>>>> Turns out this broke nearly all my own code :-( I'll give a proper >>>>>> solution a go. >>>>>> >>>>>> >>>>> Thanks! It think it should be pretty easy (probably can use the type >>>>> name, rather than the math postfix marker to name the methods...) >>>>> >>>>> http://trac.cython.org/cython_trac/ticket/446 >>>>> >>>>> >>>>> >>>> Or use other approach for handling "int complex" types. Honestly, I >>>> did not take into account this use case. >>>> >>>> Mmm... I'm thinking that trying to support (floating) complex in C89 >>>> is not a good idea, some things are really hard to do (if ever >>>> possible)... >>>> >>>> >>> Huh? Do you mean what's there already? >>> >>> >> >> No, just the "Seamless" support... I mean, if the 'ccomplex' directive >> is not on, then make Cython generate an error when external ctypedefs >> are used, and any other situation where there is ambiguity... >> > Hmm. I don't think C89 complex is really the problem. There's plenty of > similar problems like the functions for integer division and (in future) > overloaded functions. > > Dag Sverre > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev >
Do you remember that I advocated for "ctypedef some int MyInt" or something similar? If right now we had that, Cython could reject some things, like binops on different "ctypedef some .." types, requiring users to introduce casts to resolve the ambiguity... A said it before, and I say it again: second-guessing is a bad thing (or, in Python's Zen words: "In the face of ambiguity, refuse the temptation to guess.") -- 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
