<alert comment="newbie">

The dmd compiler has several flags for controlling whether optimizing or
debugging features are activated. I think I understand -g -O -debug
and -version, but I'm unclear what the -release flag does and how/if it is
used with code.

</alert>

Lynn Allan wrote:

> The dmd compiler has several flags for controlling whether optimizing or
> debugging features are activated. I think I understand -g -O -debug
> and -version, but I'm unclear what the -release flag does and how/if it is
> used with code.

-release eliminates assertion tests explicit:

   assert (x);

and implicit:

   // if -release is not given, this checks that y is in bounds for x.
   x [y] = z;

-release essentially turns all runtime safety controls off.  I don't recommend it - if your program goes bad, it'll be very difficult to find out where and why.  Array-using code is impacted by the checks, but you can get around that safely in inner loops by using pointers.

Looks like a nice FAQ entry.

   <http://www.wikiservice.at/wiki4d/wiki.cgi?FaqRoadmap#-releaseflag>

Burton Radons wrote:
> 
> Lynn Allan wrote:
> 
> > The dmd compiler has several flags for controlling whether optimizing or
> > debugging features are activated. I think I understand -g -O -debug
> > and -version, but I'm unclear what the -release flag does and how/if it is
> > used with code.
> 
> -release eliminates assertion tests explicit:
> 
>     assert (x);
> 
> and implicit:
> 
>     // if -release is not given, this checks that y is in bounds for x.
>     x [y] = z;
> 
> -release essentially turns all runtime safety controls off.  I don't recommend it - if your program goes bad, it'll be very difficult to find out where and why.  Array-using code is impacted by the checks, but you can get around that safely in inner loops by using pointers.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

Helmut Leitner wrote:
> Looks like a nice FAQ entry.
> 
>    <http://www.wikiservice.at/wiki4d/wiki.cgi?FaqRoadmap#-releaseflag>
> 
> Burton Radons wrote:
> 
>>Lynn Allan wrote:
>>
>>
>>>The dmd compiler has several flags for controlling whether optimizing or
>>>debugging features are activated. I think I understand -g -O -debug
>>>and -version, but I'm unclear what the -release flag does and how/if it is
>>>used with code.
>>
>>-release eliminates assertion tests explicit:
>>
>>    assert (x);
>>
>>and implicit:
>>
>>    // if -release is not given, this checks that y is in bounds for x.
>>    x [y] = z;
>>

-release also turns off unittests and class invariants.  It basically boils down to disabling the Design-By-Contract constructs (asserts, invariants, unittests and the like) to create code that runs faster.


>>-release essentially turns all runtime safety controls off.  I don't
>>recommend it - if your program goes bad, it'll be very difficult to find
>>out where and why.  Array-using code is impacted by the checks, but you
>>can get around that safely in inner loops by using pointers.

<rant>
The DbC constructs are meant purely for debugging purposes and should not be relied upon to catch things such as erronious input.  Good code should compile and run the exact same way from the user's point of view whether compiled using release or debug modes.

To say that it's not recommended is the entirely wrong attitude.  It is meant for exactly what it says, builds to be released.  DbC is a useful tool while developing a program, but it has no place in a final release build.
</rant>

-Deja

In article <cjf2km$1doe$1@digitaldaemon.com>, Deja Augustine says...
>
>To say that it's not recommended is the entirely wrong attitude.  It is meant for exactly what it says, builds to be released.  DbC is a useful tool while developing a program, but it has no place in a final release build.

Not strictly true.  I've heard of critical programs that ship with their DBC code still in place.  Rare perhaps, but not unheard of.


Sean

On Wed, 29 Sep 2004 14:32:38 -0500, Deja Augustine wrote:

> Helmut Leitner wrote:
>> Looks like a nice FAQ entry.
>> 
>>    <http://www.wikiservice.at/wiki4d/wiki.cgi?FaqRoadmap#-releaseflag>
>> 
>> Burton Radons wrote:
>> 
>>>Lynn Allan wrote:
>>>
>>>
>>>>The dmd compiler has several flags for controlling whether optimizing or
>>>>debugging features are activated. I think I understand -g -O -debug
>>>>and -version, but I'm unclear what the -release flag does and how/if it is
>>>>used with code.
>>>
>>>-release eliminates assertion tests explicit:
>>>
>>>    assert (x);
>>>
>>>and implicit:
>>>
>>>    // if -release is not given, this checks that y is in bounds for x.
>>>    x [y] = z;
>>>
> 
> -release also turns off unittests and class invariants.  It basically boils down to disabling the Design-By-Contract constructs (asserts, invariants, unittests and the like) to create code that runs faster.
> 
> 
>>>-release essentially turns all runtime safety controls off.  I don't recommend it - if your program goes bad, it'll be very difficult to find out where and why.  Array-using code is impacted by the checks, but you can get around that safely in inner loops by using pointers.
> 
> <rant>
> The DbC constructs are meant purely for debugging purposes and should
> not be relied upon to catch things such as erronious input.  Good code
> should compile and run the exact same way from the user's point of view
> whether compiled using release or debug modes.
> 
> To say that it's not recommended is the entirely wrong attitude.  It is
> meant for exactly what it says, builds to be released.  DbC is a useful
> tool while developing a program, but it has no place in a final release
> build.
> </rant>
> 
> -Deja

It'd be nice if there was some way to run dmd with -release, but keep some of the implicit assertions in, most notably the array bounds checking.

Deja Augustine wrote:

> Helmut Leitner wrote:
> 
>> Looks like a nice FAQ entry.
>>
>>    <http://www.wikiservice.at/wiki4d/wiki.cgi?FaqRoadmap#-releaseflag>
>>
>> Burton Radons wrote:
>>
>>> Lynn Allan wrote:
>>>
>>>
>>>> The dmd compiler has several flags for controlling whether optimizing or
>>>> debugging features are activated. I think I understand -g -O -debug
>>>> and -version, but I'm unclear what the -release flag does and how/if it is
>>>> used with code.
>>>
>>>
>>> -release eliminates assertion tests explicit:
>>>
>>>    assert (x);
>>>
>>> and implicit:
>>>
>>>    // if -release is not given, this checks that y is in bounds for x.
>>>    x [y] = z;
>>>
> 
> -release also turns off unittests and class invariants.  It basically boils down to disabling the Design-By-Contract constructs (asserts, invariants, unittests and the like) to create code that runs faster.

Please test hypotheses before stating fact.  Unittests are not normally compiled and require -unittest; -release doesn't negate this option. -release does prevent calling of class invariants (they're still defined; it only affects method calls).  -release does not prevent calling of in/out contracts themselves; however, any asserts within the contracts will not be evaluated.

>>> -release essentially turns all runtime safety controls off.  I don't
>>> recommend it - if your program goes bad, it'll be very difficult to find
>>> out where and why.  Array-using code is impacted by the checks, but you
>>> can get around that safely in inner loops by using pointers.
> 
> 
> <rant>
> The DbC constructs are meant purely for debugging purposes and should not be relied upon to catch things such as erronious input.  Good code should compile and run the exact same way from the user's point of view whether compiled using release or debug modes.
> 
> To say that it's not recommended is the entirely wrong attitude.  It is meant for exactly what it says, builds to be released.  DbC is a useful tool while developing a program, but it has no place in a final release build.
> </rant>

Using -release with release code is like taking the safety guards off when you give your drill to a bunch of raucous children.  Programs in the wild are under far greater and diverse strain than you can ever manage in a test environment; to deny yourself that tool because of - I don't know, is that an ideal? blind confidence? - is bad engineering.

All I care about is how useful the program is to the user.  A program which fails three hours after it's corrupted itself, and cannot be debugged without an intense code audit that might consume man-years, has greatly compromised utility and is inferior.  A program whose bugs can be identified quickly and fixed within a few hours because of early detection, abortion, and creation of a record of the correct state is of much less compromised utility.  Assertion failures are blunt and confusing to a user, but far better than the ticking-time-bomb alternative.

Burton Radons wrote:

> Deja Augustine wrote:
> 
>> Helmut Leitner wrote:
>>
>>> Looks like a nice FAQ entry.
>>>
>>>    <http://www.wikiservice.at/wiki4d/wiki.cgi?FaqRoadmap#-releaseflag>
>>>
>>> Burton Radons wrote:
>>>
>>>> Lynn Allan wrote:
>>>>
>>>>
>>>>> The dmd compiler has several flags for controlling whether optimizing or
>>>>> debugging features are activated. I think I understand -g -O -debug
>>>>> and -version, but I'm unclear what the -release flag does and how/if it is
>>>>> used with code.
>>>>
>>>>
>>>>
>>>> -release eliminates assertion tests explicit:
>>>>
>>>>    assert (x);
>>>>
>>>> and implicit:
>>>>
>>>>    // if -release is not given, this checks that y is in bounds for x.
>>>>    x [y] = z;
>>>>
>>
>> -release also turns off unittests and class invariants.  It basically boils down to disabling the Design-By-Contract constructs (asserts, invariants, unittests and the like) to create code that runs faster.
> 
> 
> Please test hypotheses before stating fact.  Unittests are not normally compiled and require -unittest; -release doesn't negate this option. -release does prevent calling of class invariants (they're still defined; it only affects method calls).  -release does not prevent calling of in/out contracts themselves; however, any asserts within the contracts will not be evaluated.

I stand corrected about unittests.

However, in/out contracts should not really do anything except for make assertions about the parameters and return value.  Everything else belongs in the body.

> 
>>>> -release essentially turns all runtime safety controls off.  I don't
>>>> recommend it - if your program goes bad, it'll be very difficult to find
>>>> out where and why.  Array-using code is impacted by the checks, but you
>>>> can get around that safely in inner loops by using pointers.
>>
>>
>>
>> <rant>
>> The DbC constructs are meant purely for debugging purposes and should not be relied upon to catch things such as erronious input.  Good code should compile and run the exact same way from the user's point of view whether compiled using release or debug modes.
>>
>> To say that it's not recommended is the entirely wrong attitude.  It is meant for exactly what it says, builds to be released.  DbC is a useful tool while developing a program, but it has no place in a final release build.
>> </rant>
> 
> 
> Using -release with release code is like taking the safety guards off when you give your drill to a bunch of raucous children.  Programs in the wild are under far greater and diverse strain than you can ever manage in a test environment; to deny yourself that tool because of - I don't know, is that an ideal? blind confidence? - is bad engineering.
> 
> All I care about is how useful the program is to the user.  A program which fails three hours after it's corrupted itself, and cannot be debugged without an intense code audit that might consume man-years, has greatly compromised utility and is inferior.  A program whose bugs can be identified quickly and fixed within a few hours because of early detection, abortion, and creation of a record of the correct state is of much less compromised utility.  Assertion failures are blunt and confusing to a user, but far better than the ticking-time-bomb alternative.


Then again, there's always writing good error handling code.  If you use exceptions, you can do a much more efficient job of catching errors in your program and give much more useful errors than the assertion failures.

I strongly agree that contracts are excellent tools, but I feel that to discourage people from even considering it as a possibility to do without merely encourages lazy programming.  Regardless of your personal opinions on the usefulness of -release mode, my issue is that those sorts of comments don't belong in a FAQ.

Deja Augustine wrote: (to Burton Radons)
> 
(Helmut Leitner posted:)
>>>    <http://www.wikiservice.at/wiki4d/wiki.cgi?FaqRoadmap#-releaseflag>
> ....
> without merely encourages lazy programming.  Regardless of your personal
> opinions on the usefulness of -release mode, my issue is that those
> sorts of comments don't belong in a FAQ.

Ok, but that was my decision. Blame me.

The point is, that the question belongs into the FAQ and Burtons answer is a good start. You and everybody can refine the answer.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

In article <cjg4vv$1v6s$1@digitaldaemon.com>, Deja Augustine says...

>my issue is that those sorts of comments don't belong in a FAQ.

By definition, any frequently asked question belongs in a FAQ. That's what "FAQ" stands for. So the only criterion for inclusion should be: is this question /actually/ frequently asked?

Jill