Timon Gehr:
> If absolutely necessary, you can always use the volatile keyword to disable
> all
> optimizations on a given variable, or call the function explicitly using
> inline ASM.
"volatile" is present only in D1...
Bye,
bearophile
> Should the compiler optimise by computing n only once? (even possibly at
compile-time)
> Then, what if I'm doing that in purpose? (be it stupid or not)
>
> Denis
What is the difference? The only thing that is affected by this optimization is
execution speed. Optimizing is about implementing the
On 04/14/2011 08:33 PM, Steven Schveighoffer wrote:
If it does optimise, then it is definitely a compiler bug. Since you
*explicitely* ask for a double reverse, it *must* just do it. Suppressing
them is here just breaking the language's semantics!
I feel like people aren't looking at my post :)
On 4/14/11 8:24 PM, spir wrote:
If it does optimise, then it is definitely a compiler bug. Since you
*explicitely* ask for a double reverse, it *must* just do it.
Suppressing them is here just breaking the language's semantics!
[…]
Sigh… First, as Steve already pointed out, retro() specifically
On Thu, 14 Apr 2011 14:24:41 -0400, spir wrote:
On 04/14/2011 06:57 PM, Andrej Mitrovic wrote:
This leads me to another question I've always wanted to ask. A call
such as:
auto b=map!foo(map!bar1(map!bar2(a));
This constructs a lazy range. What I'm wondering is if there are any
performance
On 04/14/2011 06:57 PM, Andrej Mitrovic wrote:
This leads me to another question I've always wanted to ask. A call such as:
auto b=map!foo(map!bar1(map!bar2(a));
This constructs a lazy range. What I'm wondering is if there are any
performance issues when constructing long chains of ranges like
