• Lynn Allan (6/6) Sep 28 2004
• Burton Radons (10/14) Sep 28 2004 -release eliminates assertion tests explicit:
• Helmut Leitner (6/27) Sep 28 2004 Looks like a nice FAQ entry.
• Deja Augustine (15/42) Sep 29 2004 -release also turns off unittests and class invariants. It basically
• Sean Kelly (4/8) Sep 29 2004 Not strictly true. I've heard of critical programs that ship with their...
• teqDruid (3/51) Sep 29 2004 It'd be nice if there was some way to run dmd with -release, but keep so...
• Arcane Jill (11/13) Sep 30 2004 Indeed - and I note this code from dmd/src/mars.d:
• Dave (27/80) Oct 01 2004 I agree, but want to add one suggestion - that '-O' itself always implie...
• Dave (8/29) Oct 02 2004 Ack - Once again I've made the mistake of thinking that -O removes bound...
• Burton Radons (20/69) Sep 29 2004 Please test hypotheses before stating fact. Unittests are not normally
• Deja Augustine (13/92) Sep 29 2004 I stand corrected about unittests.
• Helmut Leitner (8/14) Sep 30 2004 Ok, but that was my decision. Blame me.
• Arcane Jill (5/7) Sep 30 2004 By definition, any frequently asked question belongs in a FAQ. That's wh...
• Helmut Leitner (14/23) Sep 30 2004 ================
• Arcane Jill (17/34) Sep 30 2004 I frequently change my mind - that's no crime.
• Walter (9/12) Sep 30 2004 "FAQ"
• Bent Rasmussen (7/15) Sep 30 2004 "Critics of DBC, and Eiffel, have argued that to 'fail hard' in real lif...

"Lynn Allan" <l_d_allan adelphia.net> writes:

<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>

Burton Radons <burton-radons smocky.com> writes:

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 <helmut.leitner wikiservice.at> writes:

Looks like a nice FAQ entry.



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

Deja Augustine <deja scratch-ware.net> writes:

Helmut Leitner wrote:
 Looks like a nice FAQ entry.
 

 
 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

Sean Kelly <sean f4.ca> writes:

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

teqDruid <me teqdruid.com> writes:

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

 Helmut Leitner wrote:
 Looks like a nice FAQ entry.
 

 
 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.

Arcane Jill <Arcane_member pathlink.com> writes:

In article <pan.2004.09.29.23.56.34.302280 teqdruid.com>, teqDruid says...

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.

Indeed - and I note this code from dmd/src/mars.d:








Seems a shame these flags are not individually settable from the command line.

Arcane Jill

Dave <Dave_member pathlink.com> writes:

teqDruid wrote:

 On Wed, 29 Sep 2004 14:32:38 -0500, Deja Augustine wrote:
 
 Helmut Leitner wrote:
 Looks like a nice FAQ entry.
 

 
 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.

I agree, but want to add one suggestion - that '-O' itself always implies
what it currently does - maximum (pragmatic) optimizations apply.

What I'm seeing in the great majority of make files for GCC applications is
the repetition of the same flags; e.g.: '-O2 -fomit-frame-pointer'. Other
compilers basically do all this with with one switch, like -o for DMC,
-fast for Intel and /Ox or whatever for MSVC.

This is to underscore that I think -O should simply do what it implies (and
does now): Optimize code by default, including removing array bounds
checks. The bounds checking requirement is purposely /not/ a hard-and-fast
rule for D as it is for Java because it shouldn't be forced on D
executables, or D compiler developers.

As for safety of release executables, personally I have started to try and
always use D language constructs like array concatention operators along
with foreach, etc. when I write my code. This is a win-win-win in many
cases - code that is safer, easier to write and easier for the compiler/GC
to optimize.

Besides, with buffer overflow type attacks, it may be the actual intent of
the overflow to have the software abort itself immediately. For this reason
and the (currently) more common case where the overflow is directly
exploited, there is really no excuse to not write code protecting buffers
anyhow.

IMO, the 'extra' compiler switch clutter should be introduced to release
code make files only when it is desirable that a common optimization be
turned off, because that will be a smallish minority of cases from what I'm
seeing.

- Dave

Dave <Dave_member pathlink.com> writes:

Dave wrote:

 teqDruid wrote:
 

[snip]
 
 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.

 
 I agree, but want to add one suggestion - that '-O' itself always implies
 what it currently does - maximum (pragmatic) optimizations apply.
 
 What I'm seeing in the great majority of make files for GCC applications
 is the repetition of the same flags; e.g.: '-O2 -fomit-frame-pointer'.
 Other compilers basically do all this with with one switch, like -o for
 DMC, -fast for Intel and /Ox or whatever for MSVC.
 
 This is to underscore that I think -O should simply do what it implies
 (and does now): Optimize code by default, including removing array bounds
 checks. The bounds checking requirement is purposely /not/ a hard-and-fast
 rule for D as it is for Java because it shouldn't be forced on D
 executables, or D compiler developers.
 

Ack - Once again I've made the mistake of thinking that -O removes bounds
checking when of course it is '-release'.

Basically what I was getting at is that I think -release should continue to
remove bounds checking by default. An explicit -bounds-check flag added to
override the default behaviour would be fine by me <g>.

- Dave

Burton Radons <burton-radons smocky.com> writes:

Deja Augustine wrote:

 Helmut Leitner wrote:
 
 Looks like a nice FAQ entry.



 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.

Deja Augustine <deja scratch-ware.net> writes:

Burton Radons wrote:

 Deja Augustine wrote:
 
 Helmut Leitner wrote:

 Looks like a nice FAQ entry.



 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.

Helmut Leitner <helmut.leitner wikiservice.at> writes:

Deja Augustine wrote: (to Burton Radons)
 

(Helmut Leitner posted:)



 ....
 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

Arcane Jill <Arcane_member pathlink.com> writes:

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

Helmut Leitner <leitner hls.via.at> writes:

Arcane Jill wrote:
 
 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?

Now you changed your mind.

If you think, the question doesn't belong into this FAQ, you can delete it.

I don't think that you are right, because one can feel which questions
(intelligent
ones, that are obvious but have no obvious answer) belong into an FAQ.

Any forum visitor will look for the FAQ to avoid standard questions. 
The quality and size of an FAQ therefore also tells about the quality of what
we 
are doing here. If we do it in 2 years it is better than to count questions for
5 years and then start working on it. 

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

Arcane Jill <Arcane_member pathlink.com> writes:

In article <415C0295.79A533E hls.via.at>, Helmut Leitner says...
Arcane Jill wrote:
 
 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?

Now you changed your mind.

I frequently change my mind - that's no crime.

But in this particular case, I didn't. I never said that the item in question
either should or shouldn't be in the FAQ, either before or after the above
statement. I ventured, and continue to venture, no opinion whatsoever on the
subject.



If you think, the question doesn't belong into this FAQ

I didn't say that. And neither did I say the converse. Therefore I have nothing
either to justify or refute.


I don't think that you are right,

About what?

I simply made a generalization - that questions which are frequently asked are
precisely the questions which (by definition) belong in a FAQ. I said nothing
about whether or not this /particular/ question falls into that category - and
nor would I, because I don't know enough to make that assessment.


because one can feel which questions (intelligent
ones, that are obvious but have no obvious answer) belong into an FAQ.

I'd say that such questions belong in official documentation, such a manual, or
a properly indexed page on a web site.

But hey - I don't care. Honestly. This really is too trivial to argue about.
Jill

"Walter" <newshound digitalmars.com> writes:

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cjgppc$2a13$1 digitaldaemon.com...
 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?

I view it a little differently. If it's a reasonable question, and someone
is willing to provide an answer, by all means, put it in the FAQ.  I often
review FAQs and move the answers into the regular documentation. Also, with
the advent of great search tools, the FAQ won't get unwieldy no matter how
many questions and answers are in it. The more the better.

"Bent Rasmussen" <exo bent-rasmussen.info> writes:

 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.

"Critics of DBC, and Eiffel, have argued that to 'fail hard' in real life 
situations is sometimes literally dangerous. In an attempt to address this, 
Eiffel treats contract breaches as exceptions that can be caught, allowing a 
system to recover from its own defects. The degree to which this approach 
succeeds is arguable."

http://encyclopedia.thefreedictionary.com/Design%20by%20Contract

 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.

There's some interesting text in OOSC page 396 and onward about this.