On Thu, Jul 31, 2014 at 05:17:13PM -0300, Ary Borenszweig via Digitalmars-d wrote: > On 7/31/14, 4:54 PM, H. S. Teoh via Digitalmars-d wrote: [...] > >But doesn't that just mean that you shouldn't use -release, period? > >AFAIK, the only thing -release does it to remove various safety > >checks, like array bounds checks, asserts, contracts (which are > >generally written using asserts), etc.. I'd think that Ary wouldn't > >want any of these disabled, so he shouldn't use -release at all. > >There's already -O and -inline to enable what people generally expect > >from a release build, so -release wouldn't really be needed at all. > > > >Right? > > > > > >T > > > > That's exactly my point, thank you for summing that up :-) > > I don't see the point of having a "-release" flag. It should be > renamed to "-a-bit-faster-but-unsafe".
It's probably named -release because traditionally, turning off asserts and bounds checks is what is normally done when building a C/C++ project for release. (C/C++ don't have built-in bounds checks, but I've seen projects that use macros for manually implementing this, which are #define'd away when building for release.) > I think there are other languages that do quite well in terms of > performance without disabling bounds checks and other stuff. It depends on what you're doing. If you have assert's in CPU intensive inner loops, turning them off can make a big difference in performance. T -- Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen
