Menu
▾
▴
cpptool-develop — CppRefactory Developer Mailing List
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(33) |
Nov
(51) |
Dec
(134) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(18) |
Feb
(11) |
Mar
(1) |
Apr
(55) |
May
(29) |
Jun
(1) |
Jul
(2) |
Aug
(5) |
Sep
(4) |
Oct
|
Nov
|
Dec
(6) |
| 2004 |
Jan
(1) |
Feb
(11) |
Mar
(4) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
(27) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andre B. <and...@gm...> - 2003-01-04 20:19:32
|
Sven Reichard wrote: >The split temp refactoring is just a prototype, handling the easiest case. >IMO, the correct result would be not to split at all. However, I think it >is not completely trivial to decide if the variable is still used >afterwards (need to check for returns or breaks/continues in the >subscope). >The case above should be added to the test base, and marked as failure. > >Sven. > Well, I just started to read the Refactoring book of M. Fowler and saw that this example is shown there exactly as the SplitTemp-Routines handle it. However I have the feeling and you might agree that the new declaration needs to be placed in the right place to garantuee correct code (btw. Fowler suggest to declare the first variable as constant value). -- Andre |
|
From: Sven R. <rei...@ma...> - 2003-01-04 02:33:21
|
Guys, a happy and successful year 2003 to all of you. I'm back aboard, and trying to catch up. I'll check the Wiki for any open tasks. Catch you later, Sven. Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2003-01-04 02:31:39
|
On Mon, 30 Dec 2002, Andre Baresel wrote:
> I just played arround with SplitTemp and found that bug:
> Performing the action on the following code will result in wrong code
> ---------------
> {
> int a = 0;
> if (b==0) a=2;
> b = a;
> }
>
>
> -------
> Result:
>
> {
> int NEWNAME = 0;
> if (b==0) int a=2;
> b = a;
> }
>
> <snip>
> Correct Result:
>
> {
> int NEWNAME = 0;
> int a=2
> if (b==0) ;
> b = a;
> }
>
>
> -- Andre
>
The split temp refactoring is just a prototype, handling the easiest case.
IMO, the correct result would be not to split at all. However, I think it
is not completely trivial to decide if the variable is still used
afterwards (need to check for returns or breaks/continues in the
subscope).
The case above should be added to the test base, and marked as failure.
Sven.
Sven Reichard
Dept. of Math. Sci.
University of Delaware
rei...@ma...
|
|
From: Andre B. <and...@gm...> - 2002-12-31 11:42:46
|
I was just playing arround with this bug report / feature request thing. I have the feeling that it would be nice to write down the open bugs & features there since it gives a good overview for open tasks. I have good experiences for doing such things in my developer team... so what about using it ? I think this also counts for the project activity counter of SourceForge isn't it ? -- Andre |
|
From: Andre B. <and...@gm...> - 2002-12-30 10:57:55
|
I just played arround with SplitTemp and found that bug:
Performing the action on the following code will result in wrong code
---------------
{
int a = 0;
if (b==0) a=2;
b = a;
}
-------
Result:
{
int NEWNAME = 0;
if (b==0) int a=2;
b = a;
}
This is not compilable and wrong.
This always appears when the assignment is inside some deeper scope.
The declaration that is added, needs to be placed in front of the
statement where the
assignment is placed "inside". Correct Result:
{
int NEWNAME = 0;
int a=2
if (b==0) ;
b = a;
}
-- Andre
|
|
From: Andre B. <and...@gm...> - 2002-12-30 10:51:17
|
VC6 Addin has been extended, now it supports also InlineTemp and SplitTemp. I also redesigned the Icons for the three supported actions, If you don't like the Icons you will find the old versions in the Resourcefile. Since Icons are not always nice to use I would suggest that we also add a command that opens a Popup-Window with a Menu of all supported AddinCommands in textual form. With this the user could set up a key that calls the popup-command and than select the action he wants to perform. -- Andre |
|
From: Andre B. <and...@gm...> - 2002-12-28 11:05:27
|
I just checked in the sources for InlineTempRefactoring and its tests.
Also the extended expression parser ExpressionOperationMutator has been
added since it is needed for detecting assignments to local variables.
Please note that operators "++" and "--" are not recognized as assignment at
the moment (see InlineTemp - deactivated tests).
There are some things left for me to do:
- change the automatic check 'isAtomic' to be a hint for the user
- vc6-addin-integration of 'inline-temp'
- document ast-extensions for expression-operation-mutator
maybe:
- splitTempRefactoring use extended expression-parsing
- extend expression parsing for detecting nested assignments (in braces
or function-calls)
plus detection of the ++ and -- operators as assignments
- think about a seperate tokenizer instead of reuse of the
expressionmutator
(e.g. add feature TokenSet, checking for token sets)
-- Andre
|
|
From: Andre B. <and...@gm...> - 2002-12-27 20:15:14
|
Baptiste Lepilleur wrote:
>>I implemented an expression parser that checks for <expresssion-list>
>>which is the highest
>>level expression and creates nodes for the list members.
>>Additionally I implemented the next level <assignment-expression>
>>partly. Which means
>>only realy assignments will be recognized at the moment (conditionals
>>and throws will be ignored).
>>
>>
>
>What do you means by 'conditionals and throws' assignment ?
>
Well I was stepping down the EBNF of the C++ syntax which can be found
e.g. in the MSDN.
Expressions start with expression-list.
expression-list-elements are assignment-expressions. (Can be easily
detected by comma and balanced braces)
assignment-expression can be:
conditional-expression "a ? 1 : 0 "
throw-expression "throw <whatever>"
[term] assignment-operator [term] ...Can
be detected by searching for assignment-operators (a list!) and balanced
braces
>>Well, implementing all levels will lead to some big implementation isn't
>>it.
>>But I have no idea how to handle expressions in a different way, since
>>we need to detect the
>>hierarchy of operators to understand the expression in the right way:
>>
>>Just some examples to explain the reason for detailed expression parsing:
>>
>> a = 10; this is a simple assigment to 'a' .
>> * ( a + 1 ) = 10; whereas this is not an assignment to 'a'
>>. // we cannot simply search for assignment operator
>> fctcall( a = 10 , b = 3 ) is an assignment to 'a' and to 'b'
>> // we need to parse until the low levels of calling fcts ?
>>
>>What is you feeling about this Baptiste ?
>>
>>
>
>I would limit the expression parser to assignement to temporary variable for
>now. This should cover 99% of the cases. Writing a good expression parser is
>very complex (you need to deal with type, function call resolution, operator
>overload...). We don't have all the datas to do that now, and the it does
>not bring much functionnalities. My guess is that it will not be needed for
>a while.
>
Yep, I agree with this. I'm quite comfortable with the current solution.
However I'm not sure about the
AST-Representation.
>I would limit the current extension of the expression parser to detecting
>assignement to unqualified identifier:
>
>Supported: a = b = c = d in expression.
>Not supported: *a = *(b+1) = c = 3;
>
>This should be fairly simple to implement.
>
>I propose introducing a new node type:
>
>[locale-variable-assignement-expression]
> assigned-variable => [#unqualified-identifier]
> value => [expression]
>
Well the introduction of a new node type will probably introduce some
problems with the
testing of nodetype "expression" ... Is there any possibility to change
the direct checks of the
Expression-Node-Type to check some group of nodes ? This is just
something for the future
since every new expression-sub-type we are introducing will lead to
global changes whereever
we check for expression nodes. Am I wrong with this ?
I don't want to make it to complex, but I was thinking about variants of
the expression-node-type
just using an attribute (my prototype uses newly defined properties).
What about this ?
>The expression mutator would be extended to detect if a given expression is
>a 'simple expression' or a 'assignement expression'. The recursion created
>by the 'value' property would deal with multiple assignement.
>
>Hopefully, this should provide us with all the datas we need for now.
>
Yes, my intension was not to implement that all :-)
It was just a though for the future.
>>Is it better to implement some heuristic -- like:
>> search for '=' and look backwards for identifier and braces ...
>>*no-idea-if-this-works*
>>
>>
>
>I would extend the ExpressionMutator to detect the token '=' and check that
>the expression starts with the tokens 'identifier, assign-op', and in that
>case mutate to a locale-variable-assignement-expression and do the required
>processing for that kind of node.
>
As I did - but I added also the detection of surrounding expression list
since with this we can also handle
the following example and all expression that use the expression list
operator ',' :
a = 0, b = 10;
-- Andre
|
|
From: Baptiste L. <gai...@fr...> - 2002-12-27 20:15:08
|
----- Original Message ----- From: "Andre Baresel" <and...@gm...> To: "Baptiste Lepilleur" <gai...@fr...> Sent: Friday, December 27, 2002 8:57 PM Subject: Re: [Cpptool-develop] Progress on InlineTemp > Baptiste Lepilleur wrote: > > >----- Original Message ----- > >From: "Andre Baresel" <and...@gm...> > >To: "CppTool Mailing List" <Cpp...@li...> > >Sent: Friday, December 27, 2002 11:38 AM > >Subject: [Cpptool-develop] Progress on InlineTemp > > > > > > > > > >>There're just two things that are left to be done for the InlineTemp > >>refactoring. > >>Both of them need an improvement in expression parsing I'm currently > >>thinking > >>about. The two things are: > >>- detect assignments to a temporary variable > >> > >> > > > >Yes, we need that. Sven started something like that for the SplitTemp > >refactoring. I'm not sure what the status of the code is though. Give a look > >to SplitTempRefactoring class. > > > Yep, I did this afternoon and found that it does only check the > character the follows the occurence of a > temporary variable. This is for the first ok, but it does not really > work for the future. > imagine the code : "if (temp == 0)" .. in this case we have no > assignment ... > > > > > > > > >>- find out if the initializer expression consists of one or more > >>elements (in case > >> of more elements I need to add braces when inlining the expression) > >> > >> > > > >I don't get what you mean. Do you mean if the variable is initialized by a > >constructor ? > > > nope this will be detected as not allowed at the moment since it > contains an identifier. > However just two examples: > > int tmpTobeInlined = 3; > expr = tmpTobeInlined * 5; > ==> Here we have no problem just replacing the tmpToBeInlined by its > initializer resulting in: > expr = 3 * 5; > > But what about: > int tmpTobeInlined = 3 + 3; > expr = tmpTobeInlined * 5; > ==> Here we have to add braces for the expression "3 + 3" resulting in: > expr = (3 + 3) * 5; > > For that reason I'm currently adding allways braces which doesn't look > very nice for most usecases I believe: > expr = ( 3 ) * 5; > With some Code-Rewriter that knowns about minimal placement of braces > that would be no problem. > > I was just thinking about an heuristic for the decision of placing > braces: > Just check if any c++ operator occures in the blanked text of the > initializer. If it does, I will place braces, if not > I leave it as it is. Ok, I understand the issue better know. What would be need is: 1) Is the initializer expression 'atomic' (it is not a composite of expression) ? 2) Does the expression need to be surrounded by braces when inlined in a given expression? ( x = tmpTobeInlined; does not need braces, but x = tmpTobeInlined * 2 need braces). For now, I suggest letting the user decide if braces should be added. This would be a parameter passed to the apply() method. May be add a simple heuristic for a default value (should add braces if '-' or '+' is found in the expression). Baptiste. > > -- Andre |
|
From: Andre B. <and...@gm...> - 2002-12-27 20:00:58
|
|
From: Baptiste L. <gai...@fr...> - 2002-12-27 19:49:19
|
----- Original Message -----
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Friday, December 27, 2002 2:47 PM
Subject: [Cpptool-develop] Expression parsing
> I started to play arround with parsing of expressions and extended the
> tokenizer.
> However I expect the expression parser gets complex, for that reason I
> want to make
> sure that all are with me so that the implementation is not useless
> afterwards.
>
> I implemented an expression parser that checks for <expresssion-list>
> which is the highest
> level expression and creates nodes for the list members.
> Additionally I implemented the next level <assignment-expression>
> partly. Which means
> only realy assignments will be recognized at the moment (conditionals
> and throws will be ignored).
What do you means by 'conditionals and throws' assignment ?
>
> Well, implementing all levels will lead to some big implementation isn't
> it.
> But I have no idea how to handle expressions in a different way, since
> we need to detect the
> hierarchy of operators to understand the expression in the right way:
>
> Just some examples to explain the reason for detailed expression parsing:
>
> a = 10; this is a simple assigment to 'a' .
> * ( a + 1 ) = 10; whereas this is not an assignment to 'a'
> . // we cannot simply search for assignment operator
> fctcall( a = 10 , b = 3 ) is an assignment to 'a' and to 'b'
> // we need to parse until the low levels of calling fcts ?
>
> What is you feeling about this Baptiste ?
I would limit the expression parser to assignement to temporary variable for
now. This should cover 99% of the cases. Writing a good expression parser is
very complex (you need to deal with type, function call resolution, operator
overload...). We don't have all the datas to do that now, and the it does
not bring much functionnalities. My guess is that it will not be needed for
a while.
I would limit the current extension of the expression parser to detecting
assignement to unqualified identifier:
Supported: a = b = c = d in expression.
Not supported: *a = *(b+1) = c = 3;
This should be fairly simple to implement.
I propose introducing a new node type:
[locale-variable-assignement-expression]
assigned-variable => [#unqualified-identifier]
value => [expression]
The expression mutator would be extended to detect if a given expression is
a 'simple expression' or a 'assignement expression'. The recursion created
by the 'value' property would deal with multiple assignement.
Hopefully, this should provide us with all the datas we need for now.
> Is it better to implement some heuristic -- like:
> search for '=' and look backwards for identifier and braces ...
> *no-idea-if-this-works*
I would extend the ExpressionMutator to detect the token '=' and check that
the expression starts with the tokens 'identifier, assign-op', and in that
case mutate to a locale-variable-assignement-expression and do the required
processing for that kind of node.
Baptiste.
>
> -- Andre
|
|
From: Baptiste L. <gai...@fr...> - 2002-12-27 19:24:59
|
----- Original Message ----- From: "Andre Baresel" <and...@gm...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Friday, December 27, 2002 11:38 AM Subject: [Cpptool-develop] Progress on InlineTemp > There're just two things that are left to be done for the InlineTemp > refactoring. > Both of them need an improvement in expression parsing I'm currently > thinking > about. The two things are: > - detect assignments to a temporary variable Yes, we need that. Sven started something like that for the SplitTemp refactoring. I'm not sure what the status of the code is though. Give a look to SplitTempRefactoring class. > - find out if the initializer expression consists of one or more > elements (in case > of more elements I need to add braces when inlining the expression) I don't get what you mean. Do you mean if the variable is initialized by a constructor ? > For both things I need some more details on the operations in the > expression. See reply to the other mail. Baptiste. [...] > > -- Andre |
|
From: Andre B. <and...@gm...> - 2002-12-27 13:49:29
|
I started to play arround with parsing of expressions and extended the
tokenizer.
However I expect the expression parser gets complex, for that reason I
want to make
sure that all are with me so that the implementation is not useless
afterwards.
I implemented an expression parser that checks for <expresssion-list>
which is the highest
level expression and creates nodes for the list members.
Additionally I implemented the next level <assignment-expression>
partly. Which means
only realy assignments will be recognized at the moment (conditionals
and throws will be ignored).
Well, implementing all levels will lead to some big implementation isn't
it.
But I have no idea how to handle expressions in a different way, since
we need to detect the
hierarchy of operators to understand the expression in the right way:
Just some examples to explain the reason for detailed expression parsing:
a = 10; this is a simple assigment to 'a' .
* ( a + 1 ) = 10; whereas this is not an assignment to 'a'
. // we cannot simply search for assignment operator
fctcall( a = 10 , b = 3 ) is an assignment to 'a' and to 'b'
// we need to parse until the low levels of calling fcts ?
What is you feeling about this Baptiste ?
Is it better to implement some heuristic -- like:
search for '=' and look backwards for identifier and braces ...
*no-idea-if-this-works*
-- Andre
|
|
From: Andre B. <and...@gm...> - 2002-12-27 10:40:33
|
There're just two things that are left to be done for the InlineTemp refactoring. Both of them need an improvement in expression parsing I'm currently thinking about. The two things are: - detect assignments to a temporary variable - find out if the initializer expression consists of one or more elements (in case of more elements I need to add braces when inlining the expression) For both things I need some more details on the operations in the expression. I'm currently thinking of some ExpressionOperationMutator which splits an expression into it's highest level operation. Unfortunatly this splitting isn't so easy since it needs to know about all kinds of operators and their level. we all known: "*a = 10;" splits into "*a" and "10". The ExpressionOperationMutator can build upon the ExpressionMutator which has the tokenizer implemented. Another question is, how to present this in the AST. My suggestion would be to keep that "expression"-ASTNode and add different Operation-Properties. I'm open for discussion, since this seems to be a thing that will influence many other refactoring and codegen functionality. -- Andre |
|
From: Baptiste L. <gai...@fr...> - 2002-12-25 12:40:22
|
----- Original Message ----- From: "Baptiste Lepilleur" <gai...@fr...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Wednesday, December 25, 2002 1:30 PM Subject: Re: [Cpptool-develop] First Test of Addin ... and some bug report > ----- Original Message ----- > From: "Andre Baresel" <and...@gm...> > To: <gai...@fr...>; "CppTool Mailing List" > <Cpp...@li...> > Sent: Wednesday, December 25, 2002 1:04 PM > Subject: Re: [Cpptool-develop] First Test of Addin ... and some bug report > > > > Andre Baresel wrote: > > > > > Hello Baptiste, > > > > > > it was not a problem of the service pack. I'm using now also SP5. > > > However the Bug on wrong replacement occures in the posted example if > > > you run RenameTemp with the cursor on the declaration "int a = test;". > > > Only in this case the replacement is done as reported in my first mail > > > about this bug. > > > > > > Happy bug finding, I'm starting with InlineTemp ! > > > > > > -- Andre > > > > > > > > Sorry this bug description was wrong, I retested it ! > > The problem are the tabulator's and not the refactoring algorithm. > > if tabulators are in a program the textdocument seems to replace the > > text in wrong positions ! > > So we have to think about how Tabs can be converted to correct > > positions. Maybe it is possible to > > access the settings of the visual studio to find the length of a tab > > that is currently used. > > That would explain why I failed to reproduce it. A simple work around for > now is to use the option 'insert space instead of space'. Will need to check > if it is even possible to access this configuration setting. > > This will impact the class rfta/LineBasedTextDocument which handle > conversion from 'index of the character from the beginning of the file' to > 'line,column of the character'. Well, I found how to get the tab size setting. It was a TextDocument property. I added the code to the wrapper. LineBasedTextDocument will need to be updated to handle this. Baptiste. > Baptiste. |
|
From: Baptiste L. <gai...@fr...> - 2002-12-25 12:24:38
|
----- Original Message ----- From: "Andre Baresel" <and...@gm...> To: <gai...@fr...>; "CppTool Mailing List" <Cpp...@li...> Sent: Wednesday, December 25, 2002 1:04 PM Subject: Re: [Cpptool-develop] First Test of Addin ... and some bug report > Andre Baresel wrote: > > > Hello Baptiste, > > > > it was not a problem of the service pack. I'm using now also SP5. > > However the Bug on wrong replacement occures in the posted example if > > you run RenameTemp with the cursor on the declaration "int a = test;". > > Only in this case the replacement is done as reported in my first mail > > about this bug. > > > > Happy bug finding, I'm starting with InlineTemp ! > > > > -- Andre > > > > > Sorry this bug description was wrong, I retested it ! > The problem are the tabulator's and not the refactoring algorithm. > if tabulators are in a program the textdocument seems to replace the > text in wrong positions ! > So we have to think about how Tabs can be converted to correct > positions. Maybe it is possible to > access the settings of the visual studio to find the length of a tab > that is currently used. That would explain why I failed to reproduce it. A simple work around for now is to use the option 'insert space instead of space'. Will need to check if it is even possible to access this configuration setting. This will impact the class rfta/LineBasedTextDocument which handle conversion from 'index of the character from the beginning of the file' to 'line,column of the character'. Baptiste. |
|
From: Baptiste L. <gai...@fr...> - 2002-12-25 12:20:15
|
The mailing was finally created. You can now subscribe if you which to
recieve CVS repository update notification.
Notifications also contains the diff on the modified failes.
Baptiste.
|
|
From: Andre B. <and...@gm...> - 2002-12-25 12:06:35
|
Andre Baresel wrote: > Hello Baptiste, > > it was not a problem of the service pack. I'm using now also SP5. > However the Bug on wrong replacement occures in the posted example if > you run RenameTemp with the cursor on the declaration "int a = test;". > Only in this case the replacement is done as reported in my first mail > about this bug. > > Happy bug finding, I'm starting with InlineTemp ! > > -- Andre > > Sorry this bug description was wrong, I retested it ! The problem are the tabulator's and not the refactoring algorithm. if tabulators are in a program the textdocument seems to replace the text in wrong positions ! So we have to think about how Tabs can be converted to correct positions. Maybe it is possible to access the settings of the visual studio to find the length of a tab that is currently used. -- Andre |
|
From: Baptiste L. <gai...@fr...> - 2002-12-24 17:39:59
|
----- Original Message ----- From: "Baptiste Lepilleur" <gai...@fr...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Monday, December 23, 2002 10:50 PM Subject: Re: [Cpptool-develop] First Test of Addin ... and some bug report > ----- Original Message ----- > From: "Andre Baresel" <and...@gm...> > To: "Baptiste Lepilleur" <gai...@fr...> > Sent: Monday, December 23, 2002 10:12 PM > Subject: Re: [Cpptool-develop] First Test of Addin ... and some bug report > > > > Baptiste Lepilleur wrote: > > > > >I just recompiled everything after cleaning each project and it works > fine > > >for me. This sound a lot like the bug that was present in the first > version. > > >Though, looking at the CVS repository, only the correct version is > archived. > > > > > >Please, makes sure that you update your CVS workspace. Also, the add-in > > >should be compiled in release configuration. > > > > > It's the same with your version. > > Since it works for me, it means that the TextDocument COM object provided by > VC++ is probably bugged (or behave differently than in SP5). I'll try it at > work tomorrow, just to be sure. I installed it on two differents computers at work and it works just fine. Both were VC6 SP5. Baptiste. |
|
From: Baptiste L. <gai...@fr...> - 2002-12-23 21:45:39
|
----- Original Message ----- From: "Andre Baresel" <and...@gm...> To: "Baptiste Lepilleur" <gai...@fr...> Sent: Monday, December 23, 2002 10:12 PM Subject: Re: [Cpptool-develop] First Test of Addin ... and some bug report > Baptiste Lepilleur wrote: > > >I just recompiled everything after cleaning each project and it works fine > >for me. This sound a lot like the bug that was present in the first version. > >Though, looking at the CVS repository, only the correct version is archived. > > > >Please, makes sure that you update your CVS workspace. Also, the add-in > >should be compiled in release configuration. > > > It's the same with your version. Since it works for me, it means that the TextDocument COM object provided by VC++ is probably bugged (or behave differently than in SP5). I'll try it at work tomorrow, just to be sure. > >In any case, I just made a binary snapshot: > >http://cpptool.sourceforge.net/snapshot/ > > > >Are you using VC6 SP5 ? > > > It's just the plain VC6 Professional (english). > Btw) english version also checks for local settings and replaces for > this reason all english comments > in a DSP File with german text on my PC :-(. Hope I will always check > for this problem, Maybe I'll just > write a simple batch which always replaces these automaticly. Weird, I've got the same version running on Windows 2000 Professional SP 3 (French), and the SP5 did not cause any weird stuff (comments are in english in the DSP files). You should try to download the 'english' version (http://msdn.microsoft.com/vstudio/downloads/updates/sp/vs6/sp5/dnldoverview .asp). > SP5 is required ?? I would dare say so. VC6 contains a lot of bugs, in particular in std::string. You also often run into compiler internal error when using template... The TextDocument issue might just be another one. > -- André |
|
From: Baptiste L. <gai...@fr...> - 2002-12-23 20:31:00
|
----- Original Message -----
From: "Andre Baresel" <and...@gm...>
To: "Baptiste Lepilleur" <gai...@fr...>
Sent: Sunday, December 22, 2002 3:35 PM
Subject: Re: [Cpptool-develop] Next things ..
> Baptiste Lepilleur wrote:
> [...]
> >I skimmed a bit of the C++ standard concerning declaration (by the way,
the
> >outtermost level of a source file is only about declaration), and I can
say
> >that it's not going to be simple.
> >
> Yep, but I was looking through the ebnf-syntax today. The result of this
> is this addition to your FullParser
> wiki page. After having some "lazy parsing" declaration parser for the
> source level, we could add the
> features step by step. For that reason I started to think about how to
> find out the different types of declaration
> which are in fact not too many and than findout their end symbol ";" or
"}".
> At highest level that are only 6 different kinds of declaration
> - block decl (this is the interessting stuff, classes/struct/typedef,
etc.)
> - function decl
> - different template declarations
> - extern declaration (extern "identifier" { ... } )
> - namespace declaration
>
> the identification and getting the length of extern, namespace is not to
> difficult.
> the identification of template-declaration is easy but getting the
> length is worse because the declaration can recurse
> the length of block-declaration is easy since all of the sub types end
> with ";" and I think none of them has a ";" inside (need to check this)
> identification between block and function declaration is described in
> the wiki and follows the idea, that only a function implementation
> has a brace ")" just before the compound statement whereas for block
> declaration that use "{}" no such thing can happen.
I went over the wiki and the basic ideas is there. If you look at the
StatementsParser you see it's a lot like the declarations parsing. Though
finding the end of declarations is a bit trickier. Take the following case
for instance:
static int values[] = { 1,2, 3 };
The declaration does not stop at the brace, but at the semicolon. But
detecting the brace and semi-colon and backtracking is the way to go for
complex declarations, but should not be necessary for basic constructs
(using, namespace...)
Thinking about it, fault tolerance could probably be introduced when nothing
else is matched for a declaration (that's how I would do it for the
StatementsParser). Then, it would skip text (while balance curly brace)
until a semi-colon is found.
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2002-12-23 20:21:55
|
----- Original Message ----- From: "Andre Baresel" <and...@gm...> To: "Baptiste Lepilleur" <gai...@fr...> Sent: Sunday, December 22, 2002 3:35 PM Subject: Re: [Cpptool-develop] Next things .. > Baptiste Lepilleur wrote: > [...] > >I was blocked on this topic for a long time, but I had an idea yesterday > >(still ill defined) which I'm trying to implement. Basically, when you will > >do: > > > >CompoundStatementPtr compound= ...; > >compound->appendStatement( new WhileStatement( ... ) > > > >CompoundStatement will memorize that a new statement was added and rewrite > >the code as required. > > > So you think about implementing the code writer within extra classes for > the statement types ? > I was thinking about using some visitation of the parsed AST and to do > the rewriting on basis of the > parsed AST. This kind of rewriter would use the original source code > parts that cannot be parsed yet > (maybe remove new lines or extra whitespaces) and introduces the > formatting for all known code parts. > Also the idea of configurable formatting has to be included. I was > thinking about having some formatter > context that knows about the settings how to format and for instance > the level for indention etc. > The visitor can than collect the formatted code. You need more than just the new AST to rewrite the code. You also need to know which node were deleted, and which were replaced to know which part of the original source need to be modified. The CodeModel provided a somewhat higher level of abstraction of the code. For instance, in the AST, the type of an declaration node is the same weither it is a statement or an expression. The CodeModel clearly distinguish both case. If things work out correctly, the current refactoring will be modified to use the code model instead of doing direct text manipulation. The new classes living in CodeModel will not rewrite the code directly. They will remember the change made and their original SourceRange is they where generated from parsing. When the rewriting occurs, those change are collected during visitation and the rewriting will be done based on those change. This rewritting will also need to be combined with a formatter. Making formatting configurable will be trivial once we manage to do it. My current confusion is more around of what we should reformat and when: - For an ExpressionStatement, should it be completly reformatted if a part of the expression changed ? (a variable was renamed for instance) - For conditional statements, should the condition be reformatted if the condition expression changed ? At the current, I'm going for 'no' as an answer to both questions since we don't know how to reformat expression at the current time. Reformatting will only occur for modification of a CompoundStatement (call to add/remove/set). Also, notes that it is better to just replace what need to be as it is easier on the undo buffer of the IDE (this is just the matter of doing a 'skip over' instead of copying). Baptiste. |
|
From: Baptiste L. <gai...@fr...> - 2002-12-23 19:49:53
|
I just recompiled everything after cleaning each project and it works fine for me. This sound a lot like the bug that was present in the first version. Though, looking at the CVS repository, only the correct version is archived. Please, makes sure that you update your CVS workspace. Also, the add-in should be compiled in release configuration. In any case, I just made a binary snapshot: http://cpptool.sourceforge.net/snapshot/ Are you using VC6 SP5 ? Baptiste. ----- Original Message ----- From: "Andre Baresel" <and...@gm...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Monday, December 23, 2002 8:12 PM Subject: [Cpptool-develop] First Test of Addin ... and some bug report > Hi Baptiste, > > I was just trying out the "RenameTempVar" addin - nice job ! > nothing is as good as trying the code at the user level ;-) > > However it fails with this example: > > { > > int test; > { > int a = test; > if (test == 10) test = 10; > > } > } > > Rename "test" into "ot" will result in: > > { > > int ot; > { > int a otst; > ifotst == 10otst = 10; > > } > } > > Is this code not yet supported ? > > -- Andre |
|
From: Andre B. <and...@gm...> - 2002-12-23 19:14:39
|
Hi Baptiste,
I was just trying out the "RenameTempVar" addin - nice job !
nothing is as good as trying the code at the user level ;-)
However it fails with this example:
{
int test;
{
int a = test;
if (test == 10) test = 10;
}
}
Rename "test" into "ot" will result in:
{
int ot;
{
int a otst;
ifotst == 10otst = 10;
}
}
Is this code not yet supported ?
-- Andre
|
|
From: Baptiste L. <gai...@fr...> - 2002-12-22 13:29:32
|
----- Original Message ----- From: "Andre Baresel" <and...@gm...> To: "Baptiste Lepilleur" <gai...@fr...> Sent: Sunday, December 22, 2002 1:42 PM Subject: Re: [Cpptool-develop] Next things .. > >The current implementation of IntroduceExplainingVariable would > >simply do the following things: > >- ask the user for the type and name of the extracted expression > >- add a variable declaration before the statement in which the expression > >appears (may need to add a compound statement) > >- replace the extracted expression with a reference to the new locale > >variable. > > > So I will try to figure out more about the refactoring code ... getting > into this. You may want to try for the InlineTemp refactoring instead of IntroduceExplainingVariable. It's fairly close to RenameTemp and is mainly a search and replace. Deciding where the declaration should be added for IntroduceExplainingVariable is not a simple matter. The code model I'm creating will hopefully help with that. [...] > I was starting to think about a "code rewriter" solution but well, it > seams to me quite complex and > stoped thinking about this for the moment. I could write down some of my > ideas (which will be > incomplete since I need to get more into the code of the whole thing). I was blocked on this topic for a long time, but I had an idea yesterday (still ill defined) which I'm trying to implement. Basically, when you will do: CompoundStatementPtr compound= ...; compound->appendStatement( new WhileStatement( ... ) CompoundStatement will memorize that a new statement was added and rewrite the code as required. [...] > >Parsing for method or function declarations should probably be done while > >dealing with variable and attribute declaration. > > > okido, I'm with you. I skimmed a bit of the C++ standard concerning declaration (by the way, the outtermost level of a source file is only about declaration), and I can say that it's not going to be simple. Beyond parsing, one important thing that we will need to achieve is defining a code model for type representation, so that we will know if a local variable is an instance of a given class, a pointer... Baptiste. |
