On Thu, May 14, 2009 at 4:08 PM, Dag Sverre Seljebotn <[email protected]> wrote: > Robert Bradshaw wrote: >> >> Does this have a performance impact compared to the other way? It >> does bloat the code some. (Maybe it's not critical anyways.) >
Give me a bit more of time to give a definitive comment on this, but ... > Well, it is only used for external typedefs, and considering that the > bug is quite critical (basically it's very easy to do *(long > long*)&some_short)... > > Haven't benchmarked it, we could consider switching to my original > proposal later.. > ... as long as the "property" is defined with a C protocol (instead of the Python-side "property" builtin), I do not expect a impact on performance. > >Lisandro, would you like to argue why you were -1? > For the same rationale that othes gave on this thread (basically, the impact on C semantics), and because I believe a better and backward compatible solution can be found. Simplifying the whole type system seems a mistake to me, in the temptation to guess, I would just guess ONLY in the case of external ctypedef's. Moreover, we could extend this to make "ctypedef signed value" as an unknown-size integral, but if the code does "ctypedef int value", assume that the ctypedef is actually a "int" and treat it like that. Of course, we have a problem with floating poing. Then perhaps, you should enable a special declarations for integrals and floatings like this: ctypedef signed integral i ctypedef unsigned integral j ctypedef floating x # or "floatingpoint", or "inexact" and ONLY in such case we treat such declarations as unknown-size types. Does this make sense? -- 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
