www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - assert and -release

reply "Ilya Zaitseff" <sark7 mail333.com> writes:
int foo() { printf("foo\n"); return 0; }

void main()
{
   assert(foo());
}

Even compiled with -release option, foo() function is called.
I think, it is a bad behaviour, because I often place heavy functions in  
asserts, and don't worry about any slowdown in release mode.
Nov 23 2004
parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Ilya Zaitseff schrieb am Wed, 24 Nov 2004 14:39:14 +1000:
 int foo() { printf("foo\n"); return 0; }

 void main()
 {
    assert(foo());
 }

 Even compiled with -release option, foo() function is called.
 I think, it is a bad behaviour, because I often place heavy functions in  
 asserts, and don't worry about any slowdown in release mode.

The current behaviour to include asserts in release builds is documented and in my opinion reasonable. 2 ways to solve your problem. Use of the debug keyword: # void main() # { # debug assert(foo()); # } Use contracts: # void main() # in{ # assert(foo()); # }body{ # ... # } Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.9.9 (GNU/Linux) iD8DBQFBpKj+3w+/yD4P9tIRArNQAKCMpAHBj8Cd7T8N0NnTMVxhmlnJbQCeM1yf v6M0ZsNvo1ZIAZ0O0MjvLXY= =CDGX -----END PGP SIGNATURE-----
Nov 24 2004
next sibling parent "Ilya Zaitseff" <sark7 mail333.com> writes:
On Wed, 24 Nov 2004 16:25:34 +0100, Thomas Kuehne  
<thomas-dloop kuehne.thisisspam.cn> wrote:

 Ilya Zaitseff schrieb am Wed, 24 Nov 2004 14:39:14 +1000:
 int foo() { printf("foo\n"); return 0; }

 void main()
 {
    assert(foo());
 }

 Even compiled with -release option, foo() function is called.
 I think, it is a bad behaviour, because I often place heavy functions in
 asserts, and don't worry about any slowdown in release mode.

The current behaviour to include asserts in release builds is documented and in my opinion reasonable. 2 ways to solve your problem. Use of the debug keyword: # void main() # { # debug assert(foo()); # } Use contracts: # void main() # in{ # assert(foo()); # }body{ # ... # } Thomas

Ok, i got it. Thanks.
Nov 24 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Thomas Kuehne wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 
 
 Ilya Zaitseff schrieb am Wed, 24 Nov 2004 14:39:14 +1000:
 
int foo() { printf("foo\n"); return 0; }

void main()
{
   assert(foo());
}

Even compiled with -release option, foo() function is called.
I think, it is a bad behaviour, because I often place heavy functions in  
asserts, and don't worry about any slowdown in release mode.

The current behaviour to include asserts in release builds is documented

Where?
 and in my opinion reasonable.

LTIK, half the point of assert was to insert checks for development purposes, which won't slow down the release build. Stewart.
Nov 24 2004
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Stewart Gordon schrieb am Wed, 24 Nov 2004 16:09:17 +0000:
int foo() { printf("foo\n"); return 0; }

void main()
{
   assert(foo());
}

Even compiled with -release option, foo() function is called.
I think, it is a bad behaviour, because I often place heavy functions in  
asserts, and don't worry about any slowdown in release mode.

The current behaviour to include asserts in release builds is documented

Where?

 and in my opinion reasonable.


 LTIK, half the point of assert was to insert checks for development
 purposes, which won't slow down the release build.

The documentation contains the statements: http://digitalmars.com/d/class.html # When compiling for release, the invariant code is not generated, and # the compiled program runs at maximum speed. http://digitalmars.com/d/version.html # Debug statements are for adding debug code that is removed for the # release version. http://digitalmars.com/d/dcompiler.html # -release # compile release version As you can clearly see general assert statements - those not in invariant code or having the debug attribute - are nowhere mentioned in connection with the release build. Thus it would be a bug if they were to be removed. For sure, assert usage is a style issue. Provide them with a "debug" attribute and they will work in your way. Personally I use asserts in the release version to resolve "impossible" situations without having to write extensive error handling code. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.9.9 (GNU/Linux) iD8DBQFBpMPE3w+/yD4P9tIRApIHAJ9XA6n5AI6goBQVfHNaYus+930IwQCfbXaY tI9SQBx3kCZA1ID/2NNoa5c= =1Owo -----END PGP SIGNATURE-----
Nov 24 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Thomas Kuehne wrote:
<snip>
 The documentation contains the statements:
 
 http://digitalmars.com/d/class.html
 # When compiling for release, the invariant code is not generated, and
 # the compiled program runs at maximum speed.
 
 http://digitalmars.com/d/version.html
 # Debug statements are for adding debug code that is removed for the
 # release version.

Removed for the release version? That looks wrong to me. They're put in only if you compile explicitly with a matching debug option. The only way both statements can be true is if dmd -release -debug causes the -debug flag to be ignored.
 http://digitalmars.com/d/dcompiler.html
 # -release
 #  compile release version
 
 As you can clearly see general assert statements - those not in
 invariant code or having the debug attribute - are nowhere mentioned in
 connection with the release build. Thus it would be a bug if they were
 to be removed.

But... expression.html "The compiler may optionally not evaluate assert expressions at all." See also digitalmars.D/6869 Anwyay, I don't think the bits you quoted were intended to be an exhaustive list of release mode differences. Indeed, the "runs at maximum speed" bit should imply that asserts are removed as well, not to mention in/out blocks and whatever else. Stewart.
Nov 25 2004
parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Stewart Gordon schrieb am Thu, 25 Nov 2004 15:26:02 +0000:
 Thomas Kuehne wrote:
<snip>
 The documentation contains the statements:
 
 http://digitalmars.com/d/class.html
 # When compiling for release, the invariant code is not generated, and
 # the compiled program runs at maximum speed.
 
 http://digitalmars.com/d/version.html
 # Debug statements are for adding debug code that is removed for the
 # release version.

Removed for the release version? That looks wrong to me. They're put in only if you compile explicitly with a matching debug option. The only way both statements can be true is if dmd -release -debug causes the -debug flag to be ignored.

debug_release.d # int main() # in{ # printf("in\n"); # }body{ # printf("body\n"); # debug printf("debug\n"); # debug assert(0); // *A* # assert(0); // *B* # return 0; # } The results are interresting: without flags: in body *B* - -release: body - -debug in body debug *A* - -debug -release / -release -debug body debug 1) Invariants are included in flagless and in debug builds. 2) The release flag doesn't cancel the debug flag. 3) Assertions (w/ and w/o debug) are removed from the relase builds. However - as pointed out by your link - any assert that has side effects remains in place(message 6872).
 expression.html

 "The compiler may optionally not evaluate assert expressions at all."

Yuk, I love the word MAY in every standard.
 Anwyay, I don't think the bits you quoted were intended to be an
 exhaustive list of release mode differences.

Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.9.9 (GNU/Linux) iD8DBQFBpg0F3w+/yD4P9tIRAuFgAKC0Vec737eKYnExLL65HbnPeisUXACdFbAi FyOHxFYmGFenpAgeRjBHcCY= =WwLy -----END PGP SIGNATURE-----
Nov 25 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Thomas Kuehne wrote:
<snip>
 The results are interresting:
 
 without flags:
      in
      body
      *B*
 
 - -release:
      body
 
 - -debug
      in
      body
      debug
      *A*
 
 - -debug -release / -release -debug
     body
     debug

As I would've expected. <snip>
 3) Assertions (w/ and w/o debug) are removed from the relase builds.
    However - as pointed out by your link - any assert that has side effects
    remains in place(message 6872).

Oh. I thought the current behaviour was that it evaluated the body of the AssertExpression, but didn't throw an AssertError. Stewart.
Nov 25 2004
parent Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Stewart Gordon schrieb am Thu, 25 Nov 2004 17:01:09 +0000:
 3) Assertions (w/ and w/o debug) are removed from the relase builds.
    However - as pointed out by your link - any assert that has side effects
    remains in place(message 6872).

Oh. I thought the current behaviour was that it evaluated the body of the AssertExpression, but didn't throw an AssertError.

You are right, currently no compiler actually generates the throwing code. # int i; # assert(i++); # writef(i,"\n"); dmd: 1 gdc: 0 I love MAY! Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.9.9 (GNU/Linux) iD8DBQFBpid83w+/yD4P9tIRAkAxAJ9jON/JbY9ifuiIazl+B0tPCYklRQCgiD8o NtkVsCOodG4KN8BI8EP/3rA= =fmn4 -----END PGP SIGNATURE-----
Nov 25 2004
prev sibling parent Sean Kelly <sean f4.ca> writes:
In article <co2bnd$21t8$1 digitaldaemon.com>, Stewart Gordon says...
LTIK, half the point of assert was to insert checks for development 
purposes, which won't slow down the release build.

IMO the purpose of asserts is to provide a checking mechanism that halts execution on failure, and its primary use is for finding programming errors. I sometimes use asserts to check the return value of functions I always want called, and while I suppose contracts could be used for this in D, contracts don't work if they weren't provided by whoever wrote the function. In C/C++ implementing this assert behavior was as easy as writing my own macro/function that only compiled away the halt signal for release builds, but as assert is built in for D this isn't as feasible. However, D provides debug statements for this sort of behavior. I personally like the flexibility of the current design and would prefer it stay the way it is. Sean
Nov 24 2004