zwang <nehzgnaw gmail.com> writes:

<code>
void main(){
     debug int v;
     assert(!v);
}
</code>

dmd reports an "undefined identifier v" error when the -release switch is 
on.  Why does the compiler try to resolve "v" here?  Assert expressions 
are not supposed to be evaluated in release version, aren't they?

MicroWizard <MicroWizard_member pathlink.com> writes:

dmd reports an "undefined identifier v" error when the -release switch is 
on.  Why does the compiler try to resolve "v" here?  Assert expressions 
are not supposed to be evaluated in release version, aren't they?

No. Assert works where you placed it.
Of course you should place it in "unittest", "in" and "out" blocks.

Take a look into Contracts in D programming reference.
http://www.digitalmars.com/d/dbc.html

Tamas Nagy

zwang <nehzgnaw gmail.com> writes:

MicroWizard wrote:
dmd reports an "undefined identifier v" error when the -release switch is 
on.  Why does the compiler try to resolve "v" here?  Assert expressions 
are not supposed to be evaluated in release version, aren't they?

 
 
 No. Assert works where you placed it.
 Of course you should place it in "unittest", "in" and "out" blocks.
 
 Take a look into Contracts in D programming reference.
 http://www.digitalmars.com/d/dbc.html
 
 Tamas Nagy
 
 

It's not that obvious to me that asserts should always be placed in 
unittest{}, in{}, and out{} blocks.  Isn't it common to insert an 
assertion in the middle of a function?

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

zwang wrote:

 It's not that obvious to me that asserts should always be placed in 
 unittest{}, in{}, and out{} blocks.  Isn't it common to insert an 
 assertion in the middle of a function?

Me neither, assertions can (and should) be placed in the body as well.

It's supposed to throw different kinds of exceptions depending on
where it is encountered, but I don't think that's implemented yet.

--anders

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

zwang wrote:

 <code>
 void main(){
     debug int v;
     assert(!v);
 }
 </code>
 
 dmd reports an "undefined identifier v" error when the -release switch 
 is on.  Why does the compiler try to resolve "v" here?  Assert 
 expressions are not supposed to be evaluated in release version, aren't 
 they?

While both of "debug" (version) and "assert" (contract)
should eventually be removed with the -release switch,
a simple way to make the program compile is to use:

void main(){
     debug int v;
     debug assert(!v);
}

Assuming that you do use -debug, for your debug build ?

--anders

Stewart Gordon <smjg_1998 yahoo.com> writes:

Anders F Björklund wrote:
 zwang wrote:
 
 <code>
 void main(){
     debug int v;
     assert(!v);
 }
 </code>

 dmd reports an "undefined identifier v" error when the -release switch 
 is on.  Why does the compiler try to resolve "v" here?  Assert 
 expressions are not supposed to be evaluated in release version, 
 aren't they?

 
 
 While both of "debug" (version) and "assert" (contract)
 should eventually be removed with the -release switch,

<snip>

Debug - no it shouldn't.  The -debug and -release options are completely 
independent of each other.

Assert - it already doesn't evaluate it.  But the compiler still 
semantically analyses it.

The compiler is correct - there's no such variable as v if -debug isn't 
specified.  Hence the OP's code doesn't make sense.

It would appear that the current semantic analyser doesn't support 
skipping assert expressions.  But you could also argue that it's 
logical, considering that -release is meant for once you know your 
program is working.  Even if DMD is wasting its time....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Stewart Gordon wrote:

 While both of "debug" (version) and "assert" (contract)
 should eventually be removed with the -release switch,

 
 Debug - no it shouldn't.  The -debug and -release options are completely 
 independent of each other.

OK, what was meant there was: "the lack of a -debug switch",
not the presence of the -release switch (which is unrelated)

--anders

clayasaurus <clayasaurus gmail.com> writes:

zwang wrote:
 <code>
 void main(){
     debug int v;
     assert(!v);
 }
 </code>
 
 dmd reports an "undefined identifier v" error when the -release switch 
 is on.  Why does the compiler try to resolve "v" here?  Assert 
 expressions are not supposed to be evaluated in release version, aren't 
 they?

It also reports "undefined identifier v" without the release switch. 
Anyway, my suggestion is to use..

void main(){
     debug int v;
     debug assert(!v);
}

If this is your desired behavior.

Derek Parnell <derek psych.ward> writes:

On Wed, 08 Jun 2005 18:14:22 +0000, clayasaurus wrote:

 zwang wrote:
 <code>
 void main(){
     debug int v;
     assert(!v);
 }
 </code>
 
 dmd reports an "undefined identifier v" error when the -release switch 
 is on.  Why does the compiler try to resolve "v" here?  Assert 
 expressions are not supposed to be evaluated in release version, aren't 
 they?

 
 It also reports "undefined identifier v" without the release switch. 
 Anyway, my suggestion is to use..
 
 void main(){
      debug int v;
      debug assert(!v);
 }
 
 If this is your desired behavior.

I occasionally use assert() outside of contract programming blocks. 
I code it as  ...

  debug {
      int v;
      assert(!v);
  }

or sometimes ...

   version(xyzzy) {
      int v;
      assert(!v);
  }

-- 
Derek Parnell
Melbourne, Australia
9/06/2005 7:33:06 AM

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Derek Parnell wrote:

 I code it as  ...
 
   debug {
       int v;
       assert(!v);
   }
 
 or sometimes ...
 
    version(xyzzy) {
       int v;
       assert(!v);
   }

You can also use the combined:

     debug(xyzzy) {
        int v;
        assert(!v);
    }

It's invoked as -debug=xyzzy


Might make it clearer that it
is debugging code, depending ?

--anders

Derek Parnell <derek psych.ward> writes:

On Thu, 09 Jun 2005 00:40:21 +0200, Anders F Björklund wrote:

 Derek Parnell wrote:
 
 I code it as  ...
 
   debug {
       int v;
       assert(!v);
   }
 
 or sometimes ...
 
    version(xyzzy) {
       int v;
       assert(!v);
   }

 
 You can also use the combined:
 
      debug(xyzzy) {
         int v;
         assert(!v);
     }
 
 It's invoked as -debug=xyzzy
 
 Might make it clearer that it
 is debugging code, depending ?

Exactly my point, and Walter also said as much in the Docs. The version()
and the debug() statements have exactly the same effect, it just a matter
of communicating intent to the readers. Use debug() on stuff that is
intentionally not any part of any production code, and version() for
alternatives in application editions.

-- 
Derek
Melbourne, Australia
9/06/2005 9:27:50 AM

Kyle Furlong <ky220 umail.ucsb.edu> writes:

Correct me if I am wrong, but I thought that when you compile -release 
all debug blocks are *ignored* by the compiler. That means that the:

debug int v; doesnt exist as far as the assert(!v) is concerned.

zwang wrote:
 <code>
 void main(){
     debug int v;
     assert(!v);
 }
 </code>
 
 dmd reports an "undefined identifier v" error when the -release switch 
 is on.  Why does the compiler try to resolve "v" here?  Assert 
 expressions are not supposed to be evaluated in release version, aren't 
 they?

clayasaurus <clayasaurus gmail.com> writes:

Kyle Furlong wrote:
 Correct me if I am wrong, but I thought that when you compile -release 
 all debug blocks are *ignored* by the compiler. That means that the:
 
 debug int v; doesnt exist as far as the assert(!v) is concerned.
 

No. the -debug and -release flags are not mutally exclusive, otherwise 
there would only be one flag, either -debug or -release.

 zwang wrote:
 
 <code>
 void main(){
     debug int v;
     assert(!v);
 }
 </code>

 dmd reports an "undefined identifier v" error when the -release switch 
 is on.  Why does the compiler try to resolve "v" here?  Assert 
 expressions are not supposed to be evaluated in release version, 
 aren't they?

Chris Sauls <ibisbasenji gmail.com> writes:

Kyle Furlong wrote:
 Correct me if I am wrong, but I thought that when you compile -release 
 all debug blocks are *ignored* by the compiler.

You are right, but I believe the oddity here is that all 'assert' 
statements are also supposed to be ignored with the -release flag.  So 
there is no error, because neither the debug-decleration nor the assert 
actually exist when -release is given.

-- Chris Sauls

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Chris Sauls wrote:

 You are right, but I believe the oddity here is that all 'assert' 
 statements are also supposed to be ignored with the -release flag.  So 
 there is no error, because neither the debug-decleration nor the assert 
 actually exist when -release is given.

Both assert(), with the -release flag, and version(none) { }
are supposed to not actually generate any object code output.

This does not mean they are _ignored_ by the compiler, though,
It still tries to parse them, so they need to be valid code...


Derek ran into something similar while trying to version "!is".

--anders

Chris Sauls <ibisbasenji gmail.com> writes:

Anders F Björklund wrote:
 This does not mean they are _ignored_ by the compiler, though,
 It still tries to parse them, so they need to be valid code...

This makes perfectly good/obvious sense.  My mistake/brainfart.

-- Chris Sauls

Derek Parnell <derek psych.ward> writes:

On Wed, 08 Jun 2005 13:54:50 -0500, Chris Sauls wrote:

 Kyle Furlong wrote:
 Correct me if I am wrong, but I thought that when you compile -release 
 all debug blocks are *ignored* by the compiler.

 
 You are right, but I believe the oddity here is that all 'assert' 
 statements are also supposed to be ignored with the -release flag.  So 
 there is no error, because neither the debug-decleration nor the assert 
 actually exist when -release is given.

assert() is not ignored. It is parsed as normal. The difference is that
when -release is in effect, there is no generated code for assert().


-- 
Derek Parnell
Melbourne, Australia
9/06/2005 7:39:13 AM

Derek Parnell <derek psych.ward> writes:

On Wed, 08 Jun 2005 11:14:48 -0700, Kyle Furlong wrote:

 Correct me if I am wrong, but I thought that when you compile -release 
 all debug blocks are *ignored* by the compiler. That means that the:
 
 debug int v; doesnt exist as far as the assert(!v) is concerned.
 
 zwang wrote:
 <code>
 void main(){
     debug int v;
     assert(!v);
 }
 </code>
 
 dmd reports an "undefined identifier v" error when the -release switch 
 is on.  Why does the compiler try to resolve "v" here?  Assert 
 expressions are not supposed to be evaluated in release version, aren't 
 they?


debug() and -release have nothing whatsoever to do with each other. They
are completely independant.

debug() is only effected by the -debug switch. It is identical to version()
statements in effect. 

-release switch cuts out 'in' and 'out' blocks, turns asserts() into NOPs,
and doesn't generated array bounds checking and a few other 'safety'
features.


-- 
Derek Parnell
Melbourne, Australia
9/06/2005 7:34:55 AM

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Derek Parnell wrote:

 debug() and -release have nothing whatsoever to do with each other. They
 are completely independant.

This should probably be written in Big Red Ink somewhere,
since it's one of those things that trips all newcomers up.

Most are used to "Debug" and "Release" being opposites,
or two different build modes... (Release a.k.a. Final)


There is also a third build style in D, which is what you
get if you don't specify *either* of -debug nor -release.
That way, the ("heavy") debugging blocks are stripped out
but the contracts and the bounds checks are still left in.

I built a special version of Phobos like that, for checking
my own code against the contracts in the standard library...


Some people also find it confusing that the -debug / -release
doesn't affect the settings of -O (optimize) and -g (symbols).

That could probably also deserve a mentioning at the same time.
(maybe scribble it on the Wiki somewhere, to end up in the docs)

--anders