Greg Ewing wrote:
> Carl Witty wrote:
>> Since
>> __pyx_base has no components of type (void(*)(void)), an assignment to
>> a storage location with that type "can't possibly" interfere with an
>> assignment to __pyx_base (according to the ANSI C aliasing rules), and
>> gcc is perfectly within its rights to reorder the two.
>
> Blarg.
>
> <rant>
> I'm getting really annoyed by the way the C standards are
> going. All these tricky rules concerning casting and aliasing
> are making it very awkward to use the language as a high-level
> assembler with any confidence that it will do what you ?&^%$
> well *tell* it!
> </rant>

There's another side of the coin though, so just for the sake of it: The
aliasing rules (and especially the "restrict" keyword) means that as long
as one is following the standards, C can finally start being able to
generate as efficient code as FORTRAN. There are certain things the
compiler simply cannot do automatically for you; FORTRAN "solves" this
problem by being a very restricted language, while C has taken a different
route and tries to keep the flexibility while still going in a direction
which makes it as efficient.

Whether this could have been done in a different way though I don't know
-- I guess it could, but I don't think it would be as natural, involving
more special magic syntax when you wanted more speed.

Disclaimer: I'm just learning these things and should probably know better
than to speak up :-) but if I'm wrong I'll learn something.

Dag Sverre

_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to