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

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

"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

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

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
> }

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
> > }
>
>

"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

"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.

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

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.