Where should the type information be 231
On Thu, 31 Mar 2005 20:50:58 -0500, Herman Rubin
Many modern compilers will do constant propagation. If your pow function is in-lined, then the constant propagation will follow naturally, and you may end up with a similar result.
Where should the type information be 233
At one shop the standard was to overprint all heading and total lines. The more worn the ribbon was...
What would be *really* nice would be a compiler that contained an interpreter, so that constant expressions that included (user defined) functions could be evaluated to constants at compile time. Are there any compilers that can do that already? (I'd be pretty surprised if there wern't.)
I see what you're saying, now, but I don't believe that it fits the usual definitions of operator vs function, which (IMO) are strictly syntactical differences. For example, you would hardly call memcpy() an operator, but it can have many of the same sorts of optimisations performed on it, as an in-lined compiler "intrinsic".
Where should the type information be 232
I don't think it is that simple. While the "taste of the designer" is important, there are...
What I'd really like to see is an ability to blur the line between what optimizations are built into the compiler, and what can be programmed independantly, as an interaction between the optimizer and the language. I know that lisp macros go a long way in this direction, but the syntax is sufficiently alian to put a lot of people off. I'd like a way to write a function in the normal "language" of the system, but include conditions that can only be resolved at compile time. Like: if you're in-lining me, and this argument is known to be in "this" range, use this different algorithm, otherwise do it this other way...
Maybe compilers already do all of the interesting tweaks that you could usefully think of? Things like unroll loop completely, for small constant loop count...
Alt Folklore Computers Newsgroups