www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - in/out with -release

reply Kai Meyer <kai unixlords.com> writes:
I have an 'enforce' function call in an 'in' block for a function. When I
compile with "-release -O -inline", the in/out blocks appear to be skipped.
It's a simple verification for a dynamic array to not have a length of 0. In
debug mode, the test condition hits the enforce in the 'in' block, but in
release mode it does not. In both release and debug mode, the same exact
enforce function works properly.

So am I to understand that -release will skip in/out blocks entirely?
Mar 04 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 04 March 2011 20:14:32 Kai Meyer wrote:

 I have an 'enforce' function call in an 'in' block for a function. When I
 compile with "-release -O -inline", the in/out blocks appear to be skipped.
 It's a simple verification for a dynamic array to not have a length of 0.
 In debug mode, the test condition hits the enforce in the 'in' block, but
 in release mode it does not. In both release and debug mode, the same
 exact enforce function works properly.
 
 So am I to understand that -release will skip in/out blocks entirely?


Of course. It uses asserts. asserts are disabled in -release. Asserts are for 
debugging, testing, and verifying code when developing, not for code which is 
released. So, you get the benefit of the test when you don't have -release and 
the benefit of speed when you do have -release. If an assertion fails, your
code 
logic is invalid. It's for validating your code, not user input or whatnot.

enforce, on the other hand, is not a language primitive. It's not intended for 
testing or debugging. It's intended to be used in production code to throw an 
exception when its condition fails. If an enforce fails, that generally means 
that you had bad input somewhere or that an operation failed or whatnot. It's 
not intended for testing the logic of your code like assert is intended to do. 
It's simply a shorthand way to throw an exception when your program runs into a 
problem.

- Jonathan M Davis
Mar 04 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 Asserts are for 
 debugging, testing, and verifying code when developing, not for code which is 
 released.


If you take a look at the dmd compiler, it's released with asserts in, and they
give all those nice error messages I put in Bugzilla :-)

Bye,
bearophile
Mar 05 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 03/05/2011 01:58 PM, bearophile wrote:

 Jonathan M Davis:


 Asserts are for
 debugging, testing, and verifying code when developing, not for code which is
 released.


 If you take a look at the dmd compiler, it's released with asserts in, and
they give all those nice error messages I put in Bugzilla :-)


lol!
I have a similar problem in designing the implementation of a toy language: the 
issue is that users of the runtime are, for instance, lib developpers, which 
own users are developpers in the source language beeing implemented, for their 
own final users...
This makes it rather abstract to think at what is, or should be, the 
realisation of an error spit by the runtime. It cannot be a normal error from 
the implementation language, and also not an error of the source language. I 
had to write my own // error system.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Mar 05 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/5/11, bearophile <bearophileHUGS lycos.com> wrote:

 Jonathan M Davis:


 Asserts are for
 debugging, testing, and verifying code when developing, not for code which
 is
 released.


 If you take a look at the dmd compiler, it's released with asserts in, and
 they give all those nice error messages I put in Bugzilla :-)

 Bye,
 bearophile


Hmm. Are those shown when compiling a file with -debug? Or do I need
to compile DMD itself in debug/nonrelease mode to activate those error
messages?
Mar 05 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 05 March 2011 05:30:23 Andrej Mitrovic wrote:

 On 3/5/11, bearophile <bearophileHUGS lycos.com> wrote:

 Jonathan M Davis:

 Asserts are for
 debugging, testing, and verifying code when developing, not for code
 which is
 released.


 
 If you take a look at the dmd compiler, it's released with asserts in,
 and they give all those nice error messages I put in Bugzilla :-)
 
 Bye,
 bearophile


 
 Hmm. Are those shown when compiling a file with -debug? Or do I need
 to compile DMD itself in debug/nonrelease mode to activate those error
 messages?


You would need to compile dmd in debug mode if you wanted it to have assertions 
enabled, the same as any other C or C++ program in existence. That's the way 
that C/C++'s assert library works.

- Jonathan M Davis
Mar 05 2011
prev sibling parent reply user domain.invalid writes:
On 03/04/2011 09:22 PM, Jonathan M Davis wrote:

 On Friday 04 March 2011 20:14:32 Kai Meyer wrote:

 I have an 'enforce' function call in an 'in' block for a function. When I
 compile with "-release -O -inline", the in/out blocks appear to be skipped.
 It's a simple verification for a dynamic array to not have a length of 0.
 In debug mode, the test condition hits the enforce in the 'in' block, but
 in release mode it does not. In both release and debug mode, the same
 exact enforce function works properly.

 So am I to understand that -release will skip in/out blocks entirely?


 Of course. It uses asserts. asserts are disabled in -release. Asserts are for
 debugging, testing, and verifying code when developing, not for code which is
 released. So, you get the benefit of the test when you don't have -release and
 the benefit of speed when you do have -release. If an assertion fails, your
code
 logic is invalid. It's for validating your code, not user input or whatnot.

 enforce, on the other hand, is not a language primitive. It's not intended for
 testing or debugging. It's intended to be used in production code to throw an
 exception when its condition fails. If an enforce fails, that generally means
 that you had bad input somewhere or that an operation failed or whatnot. It's
 not intended for testing the logic of your code like assert is intended to do.
 It's simply a shorthand way to throw an exception when your program runs into a
 problem.

 - Jonathan M Davis


I don't think I understand your response entirely. I understand that 
asserts are disabled in -release mode. I understand that enforce is a 
function that comes with std.exception, and the code isn't hard to follow.

What I'm confused about is the in block, and why it is skipped in 
-release mode. You say "It uses asserts." I didn't put an assert in my 
in block, I put an enforce. So I'm guessing that you are indicating that 
the in block is treated like an assert, and is disabled with the 
-release flag.

But I think after reading your post you've helped clarify that what I'm 
checking (that you can't pop an empty stack) based on user input is 
something I should be checking with an enforce inside the function, and 
not an assert or enforce inside the in block.

I still think I would like it if you could be a little more explicit 
about the in/out blocks. Are they always disabled entirely (skipped) 
with -release, or just certain things?

Thanks for your help!

-Kai Meyer
Mar 05 2011
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Sat, 05 Mar 2011 10:15:48 -0700, user wrote:


 On 03/04/2011 09:22 PM, Jonathan M Davis wrote:

 On Friday 04 March 2011 20:14:32 Kai Meyer wrote:

 I have an 'enforce' function call in an 'in' block for a function.
 When I compile with "-release -O -inline", the in/out blocks appear to
 be skipped. It's a simple verification for a dynamic array to not have
 a length of 0. In debug mode, the test condition hits the enforce in
 the 'in' block, but in release mode it does not. In both release and
 debug mode, the same exact enforce function works properly.

 So am I to understand that -release will skip in/out blocks entirely?


 Of course. It uses asserts. asserts are disabled in -release. Asserts
 are for debugging, testing, and verifying code when developing, not for
 code which is released. So, you get the benefit of the test when you
 don't have -release and the benefit of speed when you do have -release.
 If an assertion fails, your code logic is invalid. It's for validating
 your code, not user input or whatnot.

 enforce, on the other hand, is not a language primitive. It's not
 intended for testing or debugging. It's intended to be used in
 production code to throw an exception when its condition fails. If an
 enforce fails, that generally means that you had bad input somewhere or
 that an operation failed or whatnot. It's not intended for testing the
 logic of your code like assert is intended to do. It's simply a
 shorthand way to throw an exception when your program runs into a
 problem.

 - Jonathan M Davis


 
 I don't think I understand your response entirely. I understand that
 asserts are disabled in -release mode. I understand that enforce is a
 function that comes with std.exception, and the code isn't hard to
 follow.
 
 What I'm confused about is the in block, and why it is skipped in
 -release mode. You say "It uses asserts." I didn't put an assert in my
 in block, I put an enforce. So I'm guessing that you are indicating that
 the in block is treated like an assert, and is disabled with the
 -release flag.
 
 But I think after reading your post you've helped clarify that what I'm
 checking (that you can't pop an empty stack) based on user input is
 something I should be checking with an enforce inside the function, and
 not an assert or enforce inside the in block.
 
 I still think I would like it if you could be a little more explicit
 about the in/out blocks. Are they always disabled entirely (skipped)
 with -release, or just certain things?
 
 Thanks for your help!
 
 -Kai Meyer


That's right.  in, out and invariant blocks are not included in release 
mode.

-Lars
Mar 05 2011
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Sat, 05 Mar 2011 18:12:30 +0000, Lars T. Kyllingstad wrote:


 On Sat, 05 Mar 2011 10:15:48 -0700, user wrote:
 

 On 03/04/2011 09:22 PM, Jonathan M Davis wrote:

 On Friday 04 March 2011 20:14:32 Kai Meyer wrote:

 I have an 'enforce' function call in an 'in' block for a function.
 When I compile with "-release -O -inline", the in/out blocks appear
 to be skipped. It's a simple verification for a dynamic array to not
 have a length of 0. In debug mode, the test condition hits the
 enforce in the 'in' block, but in release mode it does not. In both
 release and debug mode, the same exact enforce function works
 properly.

 So am I to understand that -release will skip in/out blocks entirely?


 Of course. It uses asserts. asserts are disabled in -release. Asserts
 are for debugging, testing, and verifying code when developing, not
 for code which is released. So, you get the benefit of the test when
 you don't have -release and the benefit of speed when you do have
 -release. If an assertion fails, your code logic is invalid. It's for
 validating your code, not user input or whatnot.

 enforce, on the other hand, is not a language primitive. It's not
 intended for testing or debugging. It's intended to be used in
 production code to throw an exception when its condition fails. If an
 enforce fails, that generally means that you had bad input somewhere
 or that an operation failed or whatnot. It's not intended for testing
 the logic of your code like assert is intended to do. It's simply a
 shorthand way to throw an exception when your program runs into a
 problem.

 - Jonathan M Davis


 
 I don't think I understand your response entirely. I understand that
 asserts are disabled in -release mode. I understand that enforce is a
 function that comes with std.exception, and the code isn't hard to
 follow.
 
 What I'm confused about is the in block, and why it is skipped in
 -release mode. You say "It uses asserts." I didn't put an assert in my
 in block, I put an enforce. So I'm guessing that you are indicating
 that the in block is treated like an assert, and is disabled with the
 -release flag.
 
 But I think after reading your post you've helped clarify that what I'm
 checking (that you can't pop an empty stack) based on user input is
 something I should be checking with an enforce inside the function, and
 not an assert or enforce inside the in block.
 
 I still think I would like it if you could be a little more explicit
 about the in/out blocks. Are they always disabled entirely (skipped)
 with -release, or just certain things?
 
 Thanks for your help!
 
 -Kai Meyer


 
 That's right.  in, out and invariant blocks are not included in release
 mode.
 
 -Lars


It's documented here, by the way:
http://www.digitalmars.com/d/2.0/dmd-linux.html#switches

(Scroll down to -release.)

-Lars
Mar 05 2011
parent Kai Meyer <kai unixlords.com> writes:
On 03/05/2011 11:14 AM, Lars T. Kyllingstad wrote:

 On Sat, 05 Mar 2011 18:12:30 +0000, Lars T. Kyllingstad wrote:


 On Sat, 05 Mar 2011 10:15:48 -0700, user wrote:


 On 03/04/2011 09:22 PM, Jonathan M Davis wrote:

 On Friday 04 March 2011 20:14:32 Kai Meyer wrote:

 I have an 'enforce' function call in an 'in' block for a function.
 When I compile with "-release -O -inline", the in/out blocks appear
 to be skipped. It's a simple verification for a dynamic array to not
 have a length of 0. In debug mode, the test condition hits the
 enforce in the 'in' block, but in release mode it does not. In both
 release and debug mode, the same exact enforce function works
 properly.

 So am I to understand that -release will skip in/out blocks entirely?


 Of course. It uses asserts. asserts are disabled in -release. Asserts
 are for debugging, testing, and verifying code when developing, not
 for code which is released. So, you get the benefit of the test when
 you don't have -release and the benefit of speed when you do have
 -release. If an assertion fails, your code logic is invalid. It's for
 validating your code, not user input or whatnot.

 enforce, on the other hand, is not a language primitive. It's not
 intended for testing or debugging. It's intended to be used in
 production code to throw an exception when its condition fails. If an
 enforce fails, that generally means that you had bad input somewhere
 or that an operation failed or whatnot. It's not intended for testing
 the logic of your code like assert is intended to do. It's simply a
 shorthand way to throw an exception when your program runs into a
 problem.

 - Jonathan M Davis


 I don't think I understand your response entirely. I understand that
 asserts are disabled in -release mode. I understand that enforce is a
 function that comes with std.exception, and the code isn't hard to
 follow.

 What I'm confused about is the in block, and why it is skipped in
 -release mode. You say "It uses asserts." I didn't put an assert in my
 in block, I put an enforce. So I'm guessing that you are indicating
 that the in block is treated like an assert, and is disabled with the
 -release flag.

 But I think after reading your post you've helped clarify that what I'm
 checking (that you can't pop an empty stack) based on user input is
 something I should be checking with an enforce inside the function, and
 not an assert or enforce inside the in block.

 I still think I would like it if you could be a little more explicit
 about the in/out blocks. Are they always disabled entirely (skipped)
 with -release, or just certain things?

 Thanks for your help!

 -Kai Meyer


 That's right.  in, out and invariant blocks are not included in release
 mode.

 -Lars


 It's documented here, by the way:
 http://www.digitalmars.com/d/2.0/dmd-linux.html#switches

 (Scroll down to -release.)

 -Lars


All very welcome responses. Thanks for your time :) Got lots of reading 
to do.

-Kai Meyer
Mar 07 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 05 March 2011 09:15:48 user domain.invalid wrote:

 On 03/04/2011 09:22 PM, Jonathan M Davis wrote:

 On Friday 04 March 2011 20:14:32 Kai Meyer wrote:

 I have an 'enforce' function call in an 'in' block for a function. When
 I compile with "-release -O -inline", the in/out blocks appear to be
 skipped. It's a simple verification for a dynamic array to not have a
 length of 0. In debug mode, the test condition hits the enforce in the
 'in' block, but in release mode it does not. In both release and debug
 mode, the same exact enforce function works properly.
 
 So am I to understand that -release will skip in/out blocks entirely?


 
 Of course. It uses asserts. asserts are disabled in -release. Asserts are
 for debugging, testing, and verifying code when developing, not for code
 which is released. So, you get the benefit of the test when you don't
 have -release and the benefit of speed when you do have -release. If an
 assertion fails, your code logic is invalid. It's for validating your
 code, not user input or whatnot.
 
 enforce, on the other hand, is not a language primitive. It's not
 intended for testing or debugging. It's intended to be used in
 production code to throw an exception when its condition fails. If an
 enforce fails, that generally means that you had bad input somewhere or
 that an operation failed or whatnot. It's not intended for testing the
 logic of your code like assert is intended to do. It's simply a
 shorthand way to throw an exception when your program runs into a
 problem.
 
 - Jonathan M Davis


 
 I don't think I understand your response entirely. I understand that
 asserts are disabled in -release mode. I understand that enforce is a
 function that comes with std.exception, and the code isn't hard to follow.
 
 What I'm confused about is the in block, and why it is skipped in
 -release mode. You say "It uses asserts." I didn't put an assert in my
 in block, I put an enforce. So I'm guessing that you are indicating that
 the in block is treated like an assert, and is disabled with the
 -release flag.
 
 But I think after reading your post you've helped clarify that what I'm
 checking (that you can't pop an empty stack) based on user input is
 something I should be checking with an enforce inside the function, and
 not an assert or enforce inside the in block.
 
 I still think I would like it if you could be a little more explicit
 about the in/out blocks. Are they always disabled entirely (skipped)
 with -release, or just certain things?
 
 Thanks for your help!


You're not really supposed to throw exceptions from in, out, or invariant 
blocks. You're supposed to use assertions in there. That's how the whole DbC 
thing is designed in D ( http://www.digitalmars.com/d/2.0/dbc.html ). So, while 
you _can_ throw exceptions from in, out, and invariant blocks, they _will_ be 
compiled out when compiling with -release. in, out, invariant just aren't 
intended for exceptions.

- Jonathan M Davis
Mar 05 2011
prev sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
user domain.invalid Wrote:


 I still think I would like it if you could be a little more explicit 
 about the in/out blocks. Are they always disabled entirely (skipped) 
 with -release, or just certain things?
 
 Thanks for your help!
 
 -Kai Meyer


"By definition, if a pre contract fails, then the body received bad parameters.
An AssertError is thrown. If a post contract fails, then there is a bug in the
body. An AssertError is thrown. "

http://www.digitalmars.com/d/2.0/dbc.html
Mar 06 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 05 March 2011 13:54:08 Jonathan M Davis wrote:

 On Saturday 05 March 2011 05:30:23 Andrej Mitrovic wrote:

 On 3/5/11, bearophile <bearophileHUGS lycos.com> wrote:

 Jonathan M Davis:

 Asserts are for
 debugging, testing, and verifying code when developing, not for code
 which is
 released.


 
 If you take a look at the dmd compiler, it's released with asserts in,
 and they give all those nice error messages I put in Bugzilla :-)
 
 Bye,
 bearophile


 
 Hmm. Are those shown when compiling a file with -debug? Or do I need
 to compile DMD itself in debug/nonrelease mode to activate those error
 messages?


 
 You would need to compile dmd in debug mode if you wanted it to have
 assertions enabled, the same as any other C or C++ program in existence.
 That's the way that C/C++'s assert library works.


Actually, I take that back. The way that C/C++'s assert library works is that 
assertions are compiled in if NDEBUG is _not_ defined. What the "debug" build
of 
a project does is entirely up to the project. The concept of debug and release 
versions isn't really built in to the language per se. Normally, debug versions 
compile in the debug symbols and release versions do not, and release versions 
typically are set up such that they don't run unnecessary stuff which would
harm 
efficiency (such as assertions). But _exactly_ how debug and release versions
are 
set up depends on the project.

In the case of dmd, it may be that some assertions are left in on the theory 
that this it's _really_ critical code and you _still_ want it to fail 
immediately when an assertion would have failed (whereas more typically, you'd 
compile out the assertions in release mode, assuming that you'd done enough 
testing in debug mode to find and fix all the bugs that they relate to). But to 
know exactly what dmd does with assertions, you'd have to look at its makefiles 
and possibly the code itself.

- Jonathan M Davis
Mar 05 2011