www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What does dmd compiler -release flag do?

reply "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>
Sep 28 2004
parent reply 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.
Sep 28 2004
parent reply 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
Sep 28 2004
parent reply 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
Sep 29 2004
next sibling parent 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
Sep 29 2004
prev sibling next sibling parent reply 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.
Sep 29 2004
next sibling parent 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
Sep 30 2004
prev sibling parent reply 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
Oct 01 2004
parent 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
Oct 02 2004
prev sibling parent reply 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.
Sep 29 2004
parent reply 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.
Sep 29 2004
next sibling parent 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
Sep 30 2004
prev sibling next sibling parent reply 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
Sep 30 2004
next sibling parent reply 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
Sep 30 2004
parent 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
Sep 30 2004
prev sibling parent "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.
Sep 30 2004
prev sibling parent "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.
Sep 30 2004