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-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: 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: Baptiste L. <gai...@fr...> - 2003-01-07 08:37:31
|
----- 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 > > [...] > >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; OK, I understand what you mind. That the kind of stuff you don't see until you tackle the refactoring. > 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 don't believe removing the braces should be done after. It would be very tricky to distinguish between brace added by the user for clarity and those added by the tool. There should be a way to say weither or not the braces are required, though it promise to be tricky anyway. > 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. This sound good. Baptiste. > > -- Andre |