chromatic wrote:Ah, shouldn't optimization be automatic? Much preferrable to provide
> The point is not for module authors to say "no one can ever extend or
> modify this class". It's for module users to say "I'm not
> extending or modifying this class".
opt-out optimizations instead of opt-in optimizations. C++ const
qualifiers, anybody? final in Java? Compressable line noise in most
programs, those.... Even--especially--programmers who are writing code
in main:: can be naïve of the code they call; they're no more
trustworthy than the module author. It's the local user of a class which
knows what's going on, and not even then in the case of polymorphic
classes. The optimizations enabled by final/sealed are very broadly
applicable to most code; would be good to turn them on by default and
automatically turn them off when they become inapplicable. DWIM +
performance + flexibility. Thus the notifications discussion.
If method call->function call optimization were dicking with a routine
no optimized <method_calls>;
That way, I could move the pragma down as far as an unnamed block, if I
Potentially disruptive optimizations, off by default, could be
# Try hard to vectorize hyper arithmetic for SSE and AltiVec.
And it sets up a namespace for optimizations, which might help make
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.