D - Debug blocks and scope
- Scott Pigman (19/19) Jan 21 2003 from the web pages:
- Walter (17/36) Jan 23 2003 The reason for debug blocks not introducing a new scope is so that varia...
-
Carlos Santander B.
(41/41)
Jan 23 2003
"Walter"
- Sean L. Palmer (6/18) Jan 23 2003 That's a good idea, limiting scope of debug variables only to debug bloc...
- Sean L. Palmer (11/29) Jan 24 2003 Let me expound upon the reason why non-debug blocks should not have acce...
- Ant (5/11) Apr 22 2004 :)
- Walter (4/5) Jan 28 2003 blocks?
- Scott Pigman (16/21) Jan 23 2003 i understand your reasoning. but are introducing a new (normal) scope a...
- Walter (5/15) Jan 28 2003 I think it's possible. It's also possible that there's some use for debu...
- Russ Lewis (9/28) May 03 2004 I think that it is a good idea, in theory, but we need some sort of
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
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
"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
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 debugblocks?Like this: debug { int a; } debug { a=3; //valid, like now } a=4; //not valid debug { a=2; //valid }
Jan 23 2003
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 debugblocks,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 debugblocks?Like this: debug { int a; } debug { a=3; //valid, like now } a=4; //not valid debug { a=2; //valid }
Jan 24 2003
Ant <duitoolkit yahoo.ca> 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
"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 debugblocks? I never thought of that. It might be a good idea. -Walter
Jan 28 2003
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
"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
Walter wrote:"Scott Pigman" <scottpig some.where.com> wrote in message news:b0pp7e$5ig$1 digitaldaemon.com...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.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.
May 03 2004