Thread overview
Quasi debug mode
Jan 07, 2006
Chris Miller
Jan 07, 2006
Ameer Armaly
Re: Quasi debug mode (asserts)
Jan 08, 2006
Ameer Armaly
January 07, 2006
DMD has a quasi debug mode when you don't use -debug and -release.


import std.stdio;
int main()
{
   debug
   {
      writefln("debug");
      assert("test" is null);
   }
   else
   {
      writefln("release?");
      assert("test" is null);
   }
   return 0;
}


Compiled 3 times:

"dmd test" outputs:
release?
Error: AssertError Failure test(12)

"dmd -debug test" outputs:
debug
Error: AssertError Failure test(7)

"dmd -release test" outputs:
release?


Notice the first one (quasi debug) not saying debug, yet it does asserts.


There are at least 2 problems with this quasi debug mode:

   1) If you wish to distribute lib files for debug and release, you will actually have to distribute 3 due to this quasi debug mode. If you use either a debug lib or release lib with the quasi debug mode, things sometimes don't line up when linking. (phobos:std.boxer is home proof).

   2) There's no way to know if it's a release compilation using version or debug statements.


The best move would probably be to make -debug default unless -release is specified. It might be nice to add a version(release) but won't be necessary if debug{}else{} worked.

- Chris
January 07, 2006
"Chris Miller" <chris@dprogramming.com> wrote in message news:op.s205x4rxpo9bzi@moe...
> DMD has a quasi debug mode when you don't use -debug and -release.
>
>
> import std.stdio;
> int main()
> {
>    debug
>    {
>       writefln("debug");
>       assert("test" is null);
>    }
>    else
>    {
>       writefln("release?");
>       assert("test" is null);
>    }
>    return 0;
> }
>
>
> Compiled 3 times:
>
> "dmd test" outputs:
> release?
> Error: AssertError Failure test(12)
>
> "dmd -debug test" outputs:
> debug
> Error: AssertError Failure test(7)
>
> "dmd -release test" outputs:
> release?
>
>
> Notice the first one (quasi debug) not saying debug, yet it does asserts.
>
>
> There are at least 2 problems with this quasi debug mode:
>
>    1) If you wish to distribute lib files for debug and release, you will
> actually have to distribute 3 due to this quasi debug mode. If you use
> either a debug lib or release lib with the quasi debug mode, things
> sometimes don't line up when linking. (phobos:std.boxer is home proof).
>
>    2) There's no way to know if it's a release compilation using version
> or debug statements.
>
>
> The best move would probably be to make -debug default unless -release is specified. It might be nice to add a version(release) but won't be necessary if debug{}else{} worked.
>
I don't know; I do understand the problem with not beeing able to differentiate between -debug and no switch, but I do see some uses for having the no switch option.  The way I see it, -debug is to turn on optional debugging functionality, and -release is to take out *all* of it. If you don't specify either, you're basically asking for the default package; that which does what is considered "standard" testing, without having to necessarily give you verbose reports or whatever you have it do in -debug mode.
> - Chris


January 08, 2006
Chris Miller wrote:

> DMD has a quasi debug mode when you don't use -debug and -release.

I usually call this the D "contracts" mode, myself.

It's useful to have such a Phobos version around...
(If you use my RPM, such a beast is in a subpackage)

The default Phobos doesn't show contract violations.


-release is just a short-hand for "strip asserts / contracts" :
(if you want to optimize, you need to look at -O and -inline)

    if (global.params.release)
    {	global.params.useInvariants = 0;
	global.params.useIn = 0;
	global.params.useOut = 0;
	global.params.useAssert = 0;
	global.params.useArrayBounds = 0;
	global.params.useSwitchError = 0;
    }

Kinda confusing though. Catches all newcomers to D, for sure...


Just guessing, you'd think that -debug and -release are related ?

But -debug is part of the version-system*, and it has variants :
-debug=string, -debug=zlib, or whatever that you want to debug...

And it does *not* add the debugging symbols, for that you use -g.

--anders

* see http://www.digitalmars.com/d/version.html#debug :
  "The debug statement conditionally compiles in its statement body.
   It is D's way of what in C is done with #ifdef DEBUG / #endif pairs."
January 08, 2006
Ameer Armaly wrote:

> The way I see it, -debug is to turn on optional debugging
> functionality, and -release is to take out *all* of it.

In D, -release doesn't affect debugging but it does affect contracts...

The confusion comes from:
"Two versions of programs are commonly built,
a release build and a debug build. The debug
build includes extra error checking code,
test harnesses, pretty-printing code, etc."
(http://www.digitalmars.com/d/version.html)

versus:
"-release
    compile release version, which means not
    generating code for contracts and asserts"
(http://www.digitalmars.com/d/dcompiler.html)

Some people think it would have been better named "-nocontracts" or so.


This in turn comes from an age-old debate whether asserts* should be
left in the release builds or not. C/C++/D tends to side with "not":
"If I wanted runtime assertions in my release code, I'd use Java" :-P
(as Java has no means of stripping out assertions or bounds checking)


I believe that Matthew is running an article series on the subject ?
http://www.artima.com/cppsource/deepspace.html

By naming the option "release", I think Walter's position is clear :-)
(as -release in D is the equivalent of -DNDEBUG in C, i.e. no asserts)

--anders

* assuming here that "assert" is the basic form of a code contract
January 08, 2006
"Anders F Björklund" <afb@algonet.se> wrote in message news:dppq61$2h50$1@digitaldaemon.com...
> Ameer Armaly wrote:
>
>> The way I see it, -debug is to turn on optional debugging functionality, and -release is to take out *all* of it.
>
> In D, -release doesn't affect debugging but it does affect contracts...
>
> The confusion comes from:
> "Two versions of programs are commonly built,
> a release build and a debug build. The debug
> build includes extra error checking code,
> test harnesses, pretty-printing code, etc."
> (http://www.digitalmars.com/d/version.html)
>
> versus:
> "-release
>     compile release version, which means not
>     generating code for contracts and asserts"
> (http://www.digitalmars.com/d/dcompiler.html)
>
> Some people think it would have been better named "-nocontracts" or so.
>
>
> This in turn comes from an age-old debate whether asserts* should be left in the release builds or not. C/C++/D tends to side with "not": "If I wanted runtime assertions in my release code, I'd use Java" :-P (as Java has no means of stripping out assertions or bounds checking)
>
>
> I believe that Matthew is running an article series on the subject ? http://www.artima.com/cppsource/deepspace.html
>
> By naming the option "release", I think Walter's position is clear :-)
> (as -release in D is the equivalent of -DNDEBUG in C, i.e. no asserts)
>
That's what I'm saying; -debug implies you want maximum checking done, -release says you want none of it, and nothing just means you want those checks not designated as "debug."  Personally I find it very useful.
> --anders
>
> * assuming here that "assert" is the basic form of a code contract