cpptool-develop — CppRefactory Developer Mailing List

Re: [Cpptool-develop] Our wiki was vandalized...

[Sven R. <rei...@ma...>]

Starting from last night, I'm making nightly backups of the htdocs 
directory. I'm keeping two copies around, so we should be able to recover 
from "accidents" at the wiki if we discover them within 24 hours. 

I'll devise a more intelligent, incremental backup system later this week.

Sven

-- 
Sven Reichard
Dept. of Math. Sci.
University of Delaware
rei...@ma...

Re: [Cpptool-develop] Our wiki was vandalized...

[Sven R. <rei...@ma...>]

I installed the backup, so the Wiki is running again. I'm trying to figure 
out a way to make automatic backups.

Sven.

-- 
Sven Reichard
Dept. of Math. Sci.
University of Delaware
rei...@ma...

Re: [Cpptool-develop] Our wiki was vandalized...

[Baptiste L. <gai...@fr...>]

Steven Knight provided me with a partial solution. I was able to retrieve a
15 days old backup. I've put it online for now at:
http://cpptool.sourceforge.net/backup/

I'm turning in for now. I'll see if I can restore the wiki tomorrow.

Baptiste.

----- Original Message -----
From: "Baptiste Lepilleur" <gai...@fr...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Wednesday, December 04, 2002 9:52 PM
Subject: [Cpptool-develop] Our wiki was vandalized...


> The mail below was forwarded on the boost ML, and it seems that our wiki
is
> also among the victims. All world writable files in cpptool/htdocs were
> erased. This includes the htdocs/wiki directory content.
>
> At the current time, I've been able to retrieve the
> CodeAnalysisForRefactoring page from my web browser cache. I'll try to see
> if I can find some more on my computer at work.
>
> Any help to retrieve more would be welcome (I'd really like to get the
> ParserOverview and CppRefactorings page). This can be done by searching
for
> the browser cache on the computer you used to browse the wiki. On Windows,
> this is usually in Documents and Settings\$YourUserName$\Local
> Settings\Temporary Internet Files.
>
> Keyword that can be use for the search:
> ASTNode
> SourceASTNode
> ParserOverview
> RenameTemporary
> ReduceTemporaryScope
> ExtractMethod
> RenamePrivateField
>
> If you find some of our wiki pages, please post them. I'll try to
> reconstruct the Wiki from this.
>
> To my knowledge, we can't protect the wiki data files from being world
> writable, so it would be wise to come up with a regular backup solution.
>
> Thanks in advance for any help you can provide,
> Baptiste.
>
> ----- Original Message -----
> From: "Steven Knight" <kn...@ba...>
> To: "Michael Twomey" <mic...@su...>
> Cc: <sco...@li...>
> Sent: Wednesday, December 04, 2002 1:59 PM
> Subject: Re: [scons-devel] scons wiki busted
>
>
> > > Sorry to here that, the wiki had some very useful pages on it. One
> > > possible solution if no one has an archive is to use google's cached
> > > pages feature.  For example searching for "scons aegis" gives
> > >
>
<http://www.google.ie/search?q=cache:IERqV8103rgC:www.scons.org/cgi-bin/wiki
> /NewToAegis+scons+aegis&hl=en&ie=UTF-8>.
> > >
> > > I know its a cumbersome way but it might work. Does sourceforge have
> backups?
> >
> > Chad Austin reported that somebody vandalized a whole bunch of
> > SourceForge sites in this way, not just SCons.  I forwarded Terrel the
> > information Chad supplied, so he should be able to recover things as of
> > two weeks ago.
> >
> > I'm going to look into a regular mirroring/backup strategy (for
> > everything, not just the Wiki) to guard against this in the future.
> >
> > --SK
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Microsoft Visual Studio.NET
> comprehensive development tool, built to increase your
> productivity. Try a free online hosted session at:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
> _______________________________________________
> Cpptool-develop mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpptool-develop
>

Re: [Cpptool-develop] RE: SourceBuilder::add3 (Sven Reichard)

[Sven R. <rei...@ma...>]

On Thu, 5 Dec 2002, JUDD John wrote:
> 
> I'm still here, but lurking. :-)
> 

Good :) You would also be the only one with access to the list of 
subscribers.

BTW, I got an email today from somebody from Germany who wanted to join. 
Unfortunately his email address was invalid, so I couldn't get back to 
him. 

Sven.


-- 
Sven Reichard
Dept. of Math. Sci.
University of Delaware
rei...@ma...

[Cpptool-develop] RE: SourceBuilder::add3 (Sven Reichard)

[JUDD J. <joh...@te...>]

=20
> Message: 1
> Date: Wed, 4 Dec 2002 11:32:47 -0500 (EST)
> From: Sven Reichard <rei...@ma...>
> To: CppTool Mailing List <Cpp...@li...>
> Subject: [Cpptool-develop] SourceBuilder::add3
>=20
snippity
>=20
> Sven.
>=20
> BTW, is there anybody on this list except for Baptiste and me?
>=20

I'm still here, but lurking. :-)

Cheers

John

> --=20
> Sven Reichard
> Dept. of Math. Sci.
> University of Delaware
> rei...@ma...
>=20
>=20
>=20

Re: [Cpptool-develop] SourceBuilder::add3

[Baptiste L. <gai...@fr...>]

----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Wednesday, December 04, 2002 5:32 PM
Subject: [Cpptool-develop] SourceBuilder::add3


> Recently, Baptiste wrote that he was unhappy with the name of this method.
> I agree with him insofar as it is not clear at all from the name what this
> method is supposed to do.
>
> Inspecting the source code, it becomes clear that it does the following:
> It calls add three times, where the 2nd call is a keyed one (i.e., the
> object stores the range under some name).
>
> I don't see the advantage of combining these 3 calls into one. Thus, IMO
> the best way to deal with this name is to inline the method. We would have
> 3 method calls instead of one, but it becomes clearer what the code does.
> I would also rename the keyed version of SourceBuilder::add to something
> like addKeyed or addAndRemember.

Lisibility of user code. Source code build that's way is already difficult
to read, if we were to split simple statement on multiple lines, it would
become near impossible.

For instance (renaming add3 to addKeyingMid):
builder_->addKeyingMid( "  if  ( ", "x", " > 3 )", "var1.3" );
builder_->add( "  {" );
builder_->addKeyingMid( "    int ", "x", " = ", "var2.1" );
builder_->addKeyingMid( "", "x", ",", "var2.4" );
builder_->addKeyingMid( "", "y", "=", "var3.1" );
builder_->addKeyingMid( "", "x", ";", "var2.2" );
builder_->addKeyingMid( "    ", "y", ";", "var3.2" );
builder_->addKeyingMid( "    ", "x", ";", "var2.3" );
builder_->add( "  }" );

Is just a lot more readable and compact than:

builder_->add( "  if  ( " );
builder_->addKeyed( "x", "var1.3" );
builder_->add( " > 3 )" );
builder_->add( "  {" );
builder_->add( "    int " );
builder_->addKeyed( "x", "var2.1" );
builder_->add( " = " );
builder_->addKeyed( "x", "var2.4" );
builder_->add( "," );
builder_->addKeyed( "y", "var3.1" );
builder_->add( "=" );
builder_->addKeyed( "x", "var2.2" );
builder_->add( ";" );
builder_->add( "    " );
builder_->addKeyed( "y", "var3.2" );
builder_->add( ";" );
builder_->add( "    " );
builder_->addKeyed( "x", "var2.3" );
builder_->add( ";" );
builder_->add( "  }" );

A lot of C++ structure seems to be expressible in three parts when writing
keyed text for test. This includes variable declarations,
if/for/while/switch conditions, and some expressions.

addKeyingMid() keeps the code compact and somewhat readable. I can't see
Inlining as a solution. Renaming is the best solution I see for now;
providing a similar facility in some other but practical form is another
one.

For now, I suggest to simply rename add(string, string) to addKeyed() and
add3() to addKeyingMid().

Baptiste.

>
> I would have gone ahead and done it, but I'd like to hear the reasons for
> introducing this method in the first place.
>
> Any comments?
>
> Sven.
>
> BTW, is there anybody on this list except for Baptiste and me?
>
> --
> Sven Reichard
> Dept. of Math. Sci.
> University of Delaware
> rei...@ma...

Re: [Cpptool-develop] ASTDumper

[Baptiste L. <gai...@fr...>]

What was the failure ? Are you sure you specified the range correctly ?

I've just run bin/test.bat and all are correctly processed (Main.cpp is 11th
test and works fine).  Try to adapt bin/test.bat to linux (removing the
initial del should do).

Baptiste.

----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Wednesday, December 04, 2002 5:34 PM
Subject: [Cpptool-develop] ASTDumper


> I made the ASTDumper compile under Linux. However, it failed when I tested
> it on its own main() function. Is this a known bug?
>
> Sven.
>
> --
> Sven Reichard
> Dept. of Math. Sci.
> University of Delaware
> rei...@ma...
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Microsoft Visual Studio.NET
> comprehensive development tool, built to increase your
> productivity. Try a free online hosted session at:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
> _______________________________________________
> Cpptool-develop mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpptool-develop
>

[Cpptool-develop] Our wiki was vandalized...

[Baptiste L. <gai...@fr...>]

The mail below was forwarded on the boost ML, and it seems that our wiki is
also among the victims. All world writable files in cpptool/htdocs were
erased. This includes the htdocs/wiki directory content.

At the current time, I've been able to retrieve the
CodeAnalysisForRefactoring page from my web browser cache. I'll try to see
if I can find some more on my computer at work.

Any help to retrieve more would be welcome (I'd really like to get the
ParserOverview and CppRefactorings page). This can be done by searching for
the browser cache on the computer you used to browse the wiki. On Windows,
this is usually in Documents and Settings\$YourUserName$\Local
Settings\Temporary Internet Files.

Keyword that can be use for the search:
ASTNode
SourceASTNode
ParserOverview
RenameTemporary
ReduceTemporaryScope
ExtractMethod
RenamePrivateField

If you find some of our wiki pages, please post them. I'll try to
reconstruct the Wiki from this.

To my knowledge, we can't protect the wiki data files from being world
writable, so it would be wise to come up with a regular backup solution.

Thanks in advance for any help you can provide,
Baptiste.

----- Original Message -----
From: "Steven Knight" <kn...@ba...>
To: "Michael Twomey" <mic...@su...>
Cc: <sco...@li...>
Sent: Wednesday, December 04, 2002 1:59 PM
Subject: Re: [scons-devel] scons wiki busted


> > Sorry to here that, the wiki had some very useful pages on it. One
> > possible solution if no one has an archive is to use google's cached
> > pages feature.  For example searching for "scons aegis" gives
> >
<http://www.google.ie/search?q=cache:IERqV8103rgC:www.scons.org/cgi-bin/wiki
/NewToAegis+scons+aegis&hl=en&ie=UTF-8>.
> >
> > I know its a cumbersome way but it might work. Does sourceforge have
backups?
>
> Chad Austin reported that somebody vandalized a whole bunch of
> SourceForge sites in this way, not just SCons.  I forwarded Terrel the
> information Chad supplied, so he should be able to recover things as of
> two weeks ago.
>
> I'm going to look into a regular mirroring/backup strategy (for
> everything, not just the Wiki) to guard against this in the future.
>
> --SK

[Cpptool-develop] ASTDumper

[Sven R. <rei...@ma...>]

I made the ASTDumper compile under Linux. However, it failed when I tested 
it on its own main() function. Is this a known bug?

Sven.

-- 
Sven Reichard
Dept. of Math. Sci.
University of Delaware
rei...@ma...

[Cpptool-develop] SourceBuilder::add3

[Sven R. <rei...@ma...>]

Recently, Baptiste wrote that he was unhappy with the name of this method. 
I agree with him insofar as it is not clear at all from the name what this 
method is supposed to do.

Inspecting the source code, it becomes clear that it does the following: 
It calls add three times, where the 2nd call is a keyed one (i.e., the 
object stores the range under some name). 

I don't see the advantage of combining these 3 calls into one. Thus, IMO 
the best way to deal with this name is to inline the method. We would have 
3 method calls instead of one, but it becomes clearer what the code does. 
I would also rename the keyed version of SourceBuilder::add to something 
like addKeyed or addAndRemember.

I would have gone ahead and done it, but I'd like to hear the reasons for 
introducing this method in the first place.

Any comments?

Sven.

BTW, is there anybody on this list except for Baptiste and me?

-- 
Sven Reichard
Dept. of Math. Sci.
University of Delaware
rei...@ma...

Re: [Cpptool-develop] RenameTemp now support scope

[Baptiste L. <gai...@fr...>]

It's fixed.

Baptiste.

----- Original Message -----
From: "Baptiste Lepilleur" <gai...@fr...>
To: "Sven Reichard" <rei...@ma...>; "CppTool Mailing List"
<Cpp...@li...>
Sent: Sunday, December 01, 2002 10:25 PM
Subject: Re: [Cpptool-develop] RenameTemp now support scope


> You're right. I checked with VC++ and the variable is indeed accessible in
> the initializer. This sound plain wrong for me, but that the way it is.
> Should be fairly simple to correct though.
>
> Baptiste.
>
>
> ----- Original Message -----
> From: "Sven Reichard" <rei...@ma...>
> To: "CppTool Mailing List" <Cpp...@li...>
> Sent: Saturday, November 30, 2002 4:59 PM
> Subject: Re: [Cpptool-develop] RenameTemp now support scope
>
>
> > Looks great. However, I think the code below is incorrect, if I
understand
> > the grammar correctly. Stroustrup says something like: The scope of a
> > name starts at the point of its declaration; i.e., after the complete
> > declarator and before the initializer (Stroustrup, 4.9.4, translated
back
> > from German). That means that in the line
> > >         int x = x * taxeRate;
> > the second x already refers to the new variable, i.e., its uninitialized
> > value. So, it should be left unchanged, rather than being refactored to
> > >     int x = price * taxeRate;
> > This is just my theoretical understanding; I'll check if the compiler
> > understands the standard in the same way. If this is true, it should
make
> > the refactoring even easier.
> >
> > Sven.
> >
> > --
> > Sven Reichard
> > Dept. of Math. Sci.
> > University of Delaware
> > rei...@ma...
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Cpptool-develop mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpptool-develop
>
>

Re: [Cpptool-develop] RenameTemp now support scope

[Baptiste L. <gai...@fr...>]

You're right. I checked with VC++ and the variable is indeed accessible in
the initializer. This sound plain wrong for me, but that the way it is.
Should be fairly simple to correct though.

Baptiste.


----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Saturday, November 30, 2002 4:59 PM
Subject: Re: [Cpptool-develop] RenameTemp now support scope


> Looks great. However, I think the code below is incorrect, if I understand
> the grammar correctly. Stroustrup says something like: The scope of a
> name starts at the point of its declaration; i.e., after the complete
> declarator and before the initializer (Stroustrup, 4.9.4, translated back
> from German). That means that in the line
> >         int x = x * taxeRate;
> the second x already refers to the new variable, i.e., its uninitialized
> value. So, it should be left unchanged, rather than being refactored to
> >     int x = price * taxeRate;
> This is just my theoretical understanding; I'll check if the compiler
> understands the standard in the same way. If this is true, it should make
> the refactoring even easier.
>
> Sven.
>
> --
> Sven Reichard
> Dept. of Math. Sci.
> University of Delaware
> rei...@ma...

Re: [Cpptool-develop] RenameTemp now support scope

[Sven R. <rei...@ma...>]

Looks great. However, I think the code below is incorrect, if I understand 
the grammar correctly. Stroustrup says something like: The scope of a 
name starts at the point of its declaration; i.e., after the complete 
declarator and before the initializer (Stroustrup, 4.9.4, translated back 
from German). That means that in the line
>         int x = x * taxeRate;
the second x already refers to the new variable, i.e., its uninitialized 
value. So, it should be left unchanged, rather than being refactored to
>     int x = price * taxeRate;
This is just my theoretical understanding; I'll check if the compiler 
understands the standard in the same way. If this is true, it should make 
the refactoring even easier.

Sven.

-- 
Sven Reichard
Dept. of Math. Sci.
University of Delaware
rei...@ma...

[Cpptool-develop] ASTNode and SoureASTNode...

[Baptiste L. <gai...@fr...>]

    I'm thinking of having each ASTNode store the SourceASTNode it's based
on.

    There is two advantages to this:
    - we could directly ask the node for its text.
    - it allow for multiple source to be present in an AST. This makes sense
if the child of a '#include' node is a SourceASTNode.

    What do you think ?

    Baptiste.

[Cpptool-develop] RenameTemp now support scope

[Baptiste L. <gai...@fr...>]

    I finally added scope support for RenameTemp. It's seems to work just
fine:

{
    double x = getPrice();
    x += x * rate;
    if ( needTaxes() )
    {
        int x = x * taxeRate;
        setTaxes( x );
    }
    return x * getQuantity();
}

Is correctly refactored to (rename the first occurence of x to price):

{
  double price = getPrice();
  price += price * rate;
  if ( needTaxes() )
  {
    int x = price * taxeRate;
    setTaxes( x );
  }
  return price * getQuantity();
}

Things are really looking good...

Baptiste.
---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/

[Cpptool-develop] SourceBuilder, a new class to help writing tests

[Baptiste L. <gai...@fr...>]

    I added a new class, SourceBuilder which helps writing tests. I already
refactored ScopeHolderTest and ScopeGeneratorTest to use it. I also added a
few helper methods to ScopeGeneratorTestBase,getVariableNode(), and
SourceBasedTestBase, getIdentifierNode().

    SourceBuilder is used to construct the source string, and memorise
ranges of text, keying them with a string. For example:

   source_ = "  int y = 456;"
             "  int ";
   int index1 = source_.length();
   source_ += "x=3;"
             "  ";
   int index2 = source_.length();
   source_ += "x+= 3;";

Becomes
    builder_->add( "  int y = 456;" );
    builder_->add3( " int ", "x", "=3;", "x.1" );
    builder_->add3( "", "x", "+=3;", "x.2" );

Where "x.1" and "x.2" are keys used to retreive the middle string passed to
add3():
    int index1 = builder_->getStartIndex( "x.1" );
    int index2 = bulider_->getStartIndex( "x.2" );

It is also possible to mark a range of text and extends it to the 'current'
position using mark() and extend(). See ScopeHolderTest for examples.

    I expect this class to also be of used in rftaparser tests. Should
probably rename the add3() method though, but I can not think of a good
name.

    Baptiste.

[Cpptool-develop] ScopeHolder working...

[Baptiste L. <gai...@fr...>]

    Well, finally got ScopeHolder tests passing. ScopeHolder provides the
variable declaration of any identifiers, if the identifier is a local
variable.

    RenameTemp should be fairly simple to implement now.

    Baptiste.

Re: [Cpptool-develop] files added

[Baptiste L. <gai...@fr...>]

----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Wednesday, November 27, 2002 8:59 PM
Subject: Re: [Cpptool-develop] files added


> On Wed, 27 Nov 2002, Baptiste Lepilleur wrote:
>
> > I added the files to the project.
> >
> > On the other, during the refactoring, you introduced a bug. How did you
> > manage to get past the ScopeGeneratorTest::testVariableDeclScope test ?
> >
> > I fixed the bug. In ScopeGenerator::visitNode(), canSkip() must be
called
> > after the scope generation as some node may not need to visit any
children
> > or properties, but may generate a scope (variable-decl for instance).
>
> Hmm... everything passed here. The only explanation I have is that
> ScopeGeneratorTest hasn't been added to the Makefile... I'll check that
> when I come home.

Yup, I just saw that. I added some other missing files as well.

Baptiste.

Re: [Cpptool-develop] files added

[Sven R. <rei...@ma...>]

On Wed, 27 Nov 2002, Baptiste Lepilleur wrote:

> I added the files to the project.
> 
> On the other, during the refactoring, you introduced a bug. How did you
> manage to get past the ScopeGeneratorTest::testVariableDeclScope test ?
> 
> I fixed the bug. In ScopeGenerator::visitNode(), canSkip() must be called
> after the scope generation as some node may not need to visit any children
> or properties, but may generate a scope (variable-decl for instance).

Hmm... everything passed here. The only explanation I have is that 
ScopeGeneratorTest hasn't been added to the Makefile... I'll check that 
when I come home.

> 
> Don't forget to also include astdump in your refactoring (the new visitor
> header needed to be included).

I'll do that. I have neglected that subdirectory for a while now.
 
> Well, everything is working fine now.
> Baptiste.
> 
> 

-- 
Sven Reichard
Dept. of Math. Sci.
University of Delaware
rei...@ma...

[Cpptool-develop] New refactoring on the wiki

[Baptiste L. <gai...@fr...>]

    I added a few refactoring on the wiki:
    - ReduceTemporaryScope
    - ExtractMethod
    - RenamePrivateField

    ReduceTemporaryScope will definitely be the next to be tackled. It very
useful when facing long method, and we already have all the tool to
implement it.

    Baptiste.

Re: [Cpptool-develop] Dealing with scope...

[Baptiste L. <gai...@fr...>]

----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Tuesday, November 26, 2002 5:52 PM
Subject: Re: [Cpptool-develop] Dealing with scope...


> On Sun, 24 Nov 2002, Baptiste Lepilleur wrote:
> > I think you are underestimating the complexity of matching scope to a
part
> > of the tree. For example, the AST structure of a for statement is:
> >
> > for ( int x= 1; x < 3; ++x )
> >     doStuff( x );
> >
> > [for-statement]
> >     iteration-property => [declaration-or-expression]            = ( int
x=
> > 1; x < 3; ++x )
> >     iteration-statement-property => [statement]                    =
> > doStuff( x );
> >
> > As you can see, the iterated statement is not a child of the for
iteration
> > declaration node. Also, there is no guaranty concerning the order
properties
> > are visited (at the current time they are stored in a vector, which
means
> > you get them in the order they were added, but it is an implementation
> > detail that we should not depend uppon).
>
> I see. I had the idea that you could easily access the initializer
> statement of a for statement. Still, I'll try out my idea.

You can, but the both the initializer and the iteration statement are
properties of the for statement, so you can't rely on the recursive aspect
only to resolve scope.

Baptiste.

Re: [Cpptool-develop] files added

[Baptiste L. <gai...@fr...>]

I added the files to the project.

On the other, during the refactoring, you introduced a bug. How did you
manage to get past the ScopeGeneratorTest::testVariableDeclScope test ?

I fixed the bug. In ScopeGenerator::visitNode(), canSkip() must be called
after the scope generation as some node may not need to visit any children
or properties, but may generate a scope (variable-decl for instance).

Don't forget to also include astdump in your refactoring (the new visitor
header needed to be included).

Well, everything is working fine now.
Baptiste.


----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Wednesday, November 27, 2002 6:36 PM
Subject: [Cpptool-develop] files added


> Baptiste,
>
> I continued working on the visitor classes. I extracted them to their own
> files, so you will have to edit the dsp/dsw files.
>
> Sven.
>
> --
> Sven Reichard
> Dept. of Math. Sci.
> University of Delaware
> rei...@ma...
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Cpptool-develop mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpptool-develop
>
>

[Cpptool-develop] files added

[Sven R. <rei...@ma...>]

Baptiste,

I continued working on the visitor classes. I extracted them to their own 
files, so you will have to edit the dsp/dsw files.

Sven.

-- 
Sven Reichard
Dept. of Math. Sci.
University of Delaware
rei...@ma...

Re: [Cpptool-develop] Dealing with scope...

[Sven R. <rei...@ma...>]

On Sun, 24 Nov 2002, Baptiste Lepilleur wrote:
> I think you are underestimating the complexity of matching scope to a part
> of the tree. For example, the AST structure of a for statement is:
> 
> for ( int x= 1; x < 3; ++x )
>     doStuff( x );
> 
> [for-statement]
>     iteration-property => [declaration-or-expression]            = ( int x=
> 1; x < 3; ++x )
>     iteration-statement-property => [statement]                    =
> doStuff( x );
> 
> As you can see, the iterated statement is not a child of the for iteration
> declaration node. Also, there is no guaranty concerning the order properties
> are visited (at the current time they are stored in a vector, which means
> you get them in the order they were added, but it is an implementation
> detail that we should not depend uppon).

I see. I had the idea that you could easily access the initializer 
statement of a for statement. Still, I'll try out my idea.

> On the wiki, you stated that:
> > BTW, some of the visitor code should be moved to ASTNode; I'll look into
> that.
> 
> What are you refering to ?

I removed that comment. Currently I'm trying to remove some of the code 
duplication in the visitor classes.

Sven.

Re: [Cpptool-develop] Dealing with scope...

[Baptiste L. <gai...@fr...>]

----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Saturday, November 23, 2002 5:39 PM
Subject: Re: [Cpptool-develop] Dealing with scope...


> On Sat, 23 Nov 2002, Baptiste Lepilleur wrote:
> >
> >     I'd like if you could double check the list of 'scope generator'
> > statement. I've found:
> >
> >     if ( <scopeA )  <scopeB/> else <scopeC/> </scopeA>
> >     while ( <scopeA )  <scopeB/> </scopeA>
> >     for ( <scopeA; ... ;... )  <scopeB/> </scopeA>
> >     switch ( <scopeA ) <scopeB/> </scopeA>
> >     { <scopeA/> }
> >
> >     {
> >         int x =3,<scopeX> y=2<scopeY>;
> >         ....
> >         </scopeY></scopeX>
> >     }
> >
>
> Declarations in if and while statements seem a bit suspicious to me; at
> least they are bad style. The only possible application for me would be
> something like
>
> if (int result = complicatedFunction())
> {
>    process(result);
> };

Assignation in condition statement is not recommended in most C++
guidelines, but it's valid C++ (in fact, there should probably be a
refactoring "ExtractAssignationFromCondition"  or something like that). I
checked with VC++ and you can actually do crazy things like:

if ( int x =3, y = x +2)
    ComputationObject x( x+y );    // this is a new scope

This is indeed bad style, but should be supported.

>
> However, I don't think this is legal since a declaration is not an
> expression. On the other hand, gcc compiles this without any problems or
> warnings.

I believe this to be legal C++ even if it belong to the area of C++ to
avoid.

>
> I have a different (possibly simpler) approach to dealing with scopes in
> finding references to local variables, which I'll describe on the Wiki. In
> short, we can deal with this without introducing scope objects, just
> exploiting the recursive descent behavior of the variable finder.

I think you are underestimating the complexity of matching scope to a part
of the tree. For example, the AST structure of a for statement is:

for ( int x= 1; x < 3; ++x )
    doStuff( x );

[for-statement]
    iteration-property => [declaration-or-expression]            = ( int x=
1; x < 3; ++x )
    iteration-statement-property => [statement]                    =
doStuff( x );

As you can see, the iterated statement is not a child of the for iteration
declaration node. Also, there is no guaranty concerning the order properties
are visited (at the current time they are stored in a vector, which means
you get them in the order they were added, but it is an implementation
detail that we should not depend uppon).

That being said, you're welcome to try, but at least you know what you are
getting into.

As is it, I see a few advantage to the current implementation using scope
object:
- you can 'tag' each local-scope-identifier with a Scope object, allowing
unambiguous reference to temporary variables
- you can search if a identifier already exist in a given scope (validation
of the new temporary name)
- decouple the definition of the scope of each statement from the creation
(that is, the most important stuff are in ScopeGenerator constructor).

On the other hand, it is clear to me that the current scheme will not
survive (without heavy change) dealing with class and method parsing. The
scope of a function member or an attribute declaration is that of all the
class/subclass methods. But this issue does not concern us for now.

On the wiki, you stated that:
> BTW, some of the visitor code should be moved to ASTNode; I'll look into
that.

What are you refering to ?

Baptiste.
>
> Sven.
>
>  --
> Sven Reichard
> Dept. of Math. Sci.
> University of Delaware
> rei...@ma...