www.digitalmars.com         C & C++   DMDScript  

D - Debug blocks and scope

reply "Scott Pigman" <scottpig some.where.com> writes:
from the web pages:

================================================

If Statement is a block statement, it does not introduce a new scope. For
example:


int k;
debug
{   int i;
    int k;// error, k already defined

    i = 3;
}
x = i;// uses the i declared above

==================================================

i can see preventing overriding the previous definition of k, but to allow
a variable to be declared inside of a debug block & then used outside of
it sounds dangerous to me.  that could lead to my personal favorite coding
problem - code that works with the debugging statements in, but which
crashes when you take them out.  i'd like to see that debug code has the
fewest possible side effects which could effect non-debug code.

-scott
Jan 21 2003
parent reply "Walter" <walter digitalmars.com> writes:
The reason for debug blocks not introducing a new scope is so that variables
can be defined in one debug block and used in another.

debug
{
    int a,b,c;
}

...[lots 'o code] ...
{{{
     ...[deeply nested code] ...
    debug
    {
        a = 3;
    }
}}}

Not allowing this would severely curtail the usefulness of debug statements.

"Scott Pigman" <scottpig some.where.com> wrote in message
news:b0k77d$31dt$1 digitaldaemon.com...
 from the web pages:

 ================================================

 If Statement is a block statement, it does not introduce a new scope. For
 example:


 int k;
 debug
 {   int i;
     int k;// error, k already defined

     i = 3;
 }
 x = i;// uses the i declared above

 ==================================================

 i can see preventing overriding the previous definition of k, but to allow
 a variable to be declared inside of a debug block & then used outside of
 it sounds dangerous to me.  that could lead to my personal favorite coding
 problem - code that works with the debugging statements in, but which
 crashes when you take them out.  i'd like to see that debug code has the
 fewest possible side effects which could effect non-debug code.

 -scott
Jan 23 2003
next sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Walter" <walter digitalmars.com> escribiσ en el mensaje
news:b0pm6b$3o8$2 digitaldaemon.com...
| The reason for debug blocks not introducing a new scope is so that
variables
| can be defined in one debug block and used in another.
|
| debug
| {
|     int a,b,c;
| }
|
| ...[lots 'o code] ...
| {{{
|      ...[deeply nested code] ...
|     debug
|     {
|         a = 3;
|     }
| }}}
|
| Not allowing this would severely curtail the usefulness of debug
statements.


Any chance that declarations inside debug blocks are only for debug blocks?
Like this:
debug {
int a;
}
debug {
a=3; //valid, like now
}
a=4; //not valid
debug {
a=2; //valid
}


—————————————————————————
Carlos Santander
http://carlos3.netfirms.com/


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.445 / Virus Database: 250 - Release Date: 2003-01-21
Jan 23 2003
next sibling parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
That's a good idea, limiting scope of debug variables only to debug blocks,
but variables in version stmt scope should be accessible by anything.

Sean

"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:b0pmmb$41m$1 digitaldaemon.com...
 Any chance that declarations inside debug blocks are only for debug
blocks?
 Like this:
 debug {
 int a;
 }
 debug {
 a=3; //valid, like now
 }
 a=4; //not valid
 debug {
 a=2; //valid
 }
Jan 23 2003
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
Let me expound upon the reason why non-debug blocks should not have access
to variables defined in debug blocks.  It would make it impossible to verify
that a program is going to be correct with the debug blocks removed, thus
inhibit automatic removal of debug blocks for optimized builds.

Yeah, you could just "see if it compiles in release", but if the below were
implemented, once you've compiled in Debug build, you would *know* the
program *will* compile in non-debug mode.

Sean

"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b0qmqf$m4f$1 digitaldaemon.com...
 That's a good idea, limiting scope of debug variables only to debug
blocks,
 but variables in version stmt scope should be accessible by anything.

 Sean

 "Carlos Santander B." <carlos8294 msn.com> wrote in message
 news:b0pmmb$41m$1 digitaldaemon.com...
 Any chance that declarations inside debug blocks are only for debug
blocks?
 Like this:
 debug {
 int a;
 }
 debug {
 a=3; //valid, like now
 }
 a=4; //not valid
 debug {
 a=2; //valid
 }
Jan 24 2003
parent Ant <duitoolkit yahoo.ca> writes:
On Fri, 24 Jan 2003 11:14:51 -0800, Sean L. Palmer wrote:

 Let me expound upon the reason why non-debug blocks should not have access
 to variables defined in debug blocks.  It would make it impossible to verify
 that a program is going to be correct with the debug blocks removed, thus
 inhibit automatic removal of debug blocks for optimized builds.
 
 Yeah, you could just "see if it compiles in release",
:) I'm going through the debuging posts. This one is priceless! Ant
Apr 22 2004
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:b0pmmb$41m$1 digitaldaemon.com...
 Any chance that declarations inside debug blocks are only for debug
blocks? I never thought of that. It might be a good idea. -Walter
Jan 28 2003
prev sibling parent reply "Scott Pigman" <scottpig some.where.com> writes:
On Thu, 23 Jan 2003 13:19:08 +0000, Walter wrote:

 The reason for debug blocks not introducing a new scope is so that
 variables can be defined in one debug block and used in another.
 
<snip>
 Not allowing this would severely curtail the usefulness of debug
 statements.
i understand your reasoning. but are introducing a new (normal) scope and not introducing a new scope the only two options? is what carlos is asking possible -- that debug blocks share thier own separate namespace? my own pie-in-the-sky wish would be that not only would debug blocks share a separate namespace, but that they wouldn't be permitted to modify variables declared outside of the debug block -- either they would have to copy values to debug-scope variables & change them, or any reference to a non-debug variable would implicitly actually refer to a copy of that value, or each debug block would implicitly include a post-condition that all variables are unchanged. is any of this possible? is it possible to implement this with less than 10 years of coding? is it painfully obvious that i'm still green at programming? scott
Jan 23 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Scott Pigman" <scottpig some.where.com> wrote in message
news:b0pp7e$5ig$1 digitaldaemon.com...
 my own pie-in-the-sky wish would be that not only would debug blocks share
 a separate namespace, but that they wouldn't be permitted to modify
 variables declared outside of the debug block -- either they would have to
 copy values to debug-scope variables & change them, or any reference to a
 non-debug variable would implicitly actually refer to a copy of that
 value, or each debug block would implicitly include a post-condition that
 all variables are unchanged.

 is any of this possible?  is it possible to implement this with less than
 10 years of coding?  is it painfully obvious that i'm still green at
 programming?
I think it's possible. It's also possible that there's some use for debug blocks that this would break. Debug blocks are a new idea, let's see for a while how they work in the real world, and then revisit this.
Jan 28 2003
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:
 "Scott Pigman" <scottpig some.where.com> wrote in message
 news:b0pp7e$5ig$1 digitaldaemon.com...
 
my own pie-in-the-sky wish would be that not only would debug blocks share
a separate namespace, but that they wouldn't be permitted to modify
variables declared outside of the debug block -- either they would have to
copy values to debug-scope variables & change them, or any reference to a
non-debug variable would implicitly actually refer to a copy of that
value, or each debug block would implicitly include a post-condition that
all variables are unchanged.

is any of this possible?  is it possible to implement this with less than
10 years of coding?  is it painfully obvious that i'm still green at
programming?
I think it's possible. It's also possible that there's some use for debug blocks that this would break. Debug blocks are a new idea, let's see for a while how they work in the real world, and then revisit this.
I think that it is a good idea, in theory, but we need some sort of better definition of "not modify." If we take the trivial implementation, then we couldn't do: debug printf("foo\n"); because printf modifies buffers. This sounds like a worthwhile idea to me, but somebody needs to figure out exactly the Right Way to do this. I agree with Walter...we'll understand this better once we see it in the wild.
May 03 2004