assume, assert, enforce, @safe

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Thu Jul 31 13:33:34 PDT 2014


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


More information about the Digitalmars-d mailing list