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: Baptiste L. <gai...@fr...> - 2003-04-28 20:09:21
|
I was reading some of the new parsing code, that is template parsing:
---
if (tryNextIs('<'))
{
// skipping all the parameters until next '>'
findNextBalanced('<','>');
---
The issue is not specific to that code, it's just the one that got me
thinking. We know an obvious way to have findNextBalanced fails is to have
some constant comparison expression in the template parameter (very unlikely
though), that is "template <const bool optimize = sizeof(A) < sizeof(B) >
... ;"
While it is not dramatic if we failed to parse this correctly, but it
would be better if we could do some error recovery. One of the way I think
this could be achieve would be by introducing a findNextBalanced, but stop
parsing if '{' or ';' is found. Then the error recovery could start here.
What do you think ?
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2003-04-28 19:50:33
|
Well, I was writing the Enumerator code and I realized that we commonly
use a macro in place of typename (when it is used for deduced typename).
Main reason for this is portability. For instance, VC6 does not support
typename for deduced type. Here is an excerpt from boost/config/suffix.hpp,
that probably explain things better:
---
// BOOST_DEDUCED_TYPENAME
workaround ------------------------------------------//
//
// Some compilers don't support the use of `typename' for dependent
// types in deduced contexts, e.g.
//
// template <class T> void f(T, typename T::type);
// ^^^^^^^^
// Replace these declarations with:
//
// template <class T> void f(T, BOOST_DEDUCED_TYPENAME T::type);
#ifndef BOOST_NO_DEDUCED_TYPENAME
# define BOOST_DEDUCED_TYPENAME typename
#else
# define BOOST_DEDUCED_TYPENAME
#endif
---
One way to handle that in parsing would be to declare the macro (some
project setting) as being a substitute for typename. Any other ideas ?
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2003-04-28 18:48:52
|
----- Original Message ----- From: Andre Baresel To: Baptiste Lepilleur Sent: Monday, April 28, 2003 5:17 AM Subject: Re: [Cpptool-develop] Declaration parsing started... Baptiste Lepilleur wrote: Counting by hand is the simple answer. >>>E.g. "const short int" has three specifiers. They start at 0, 6, and 12. Their lengths are 5, 5, and 3. I will clean this up a little bit ! >>That would explain why most 'source' where on a single line. I'll try to see if I can come up with a better version of SourceBuilder for testing (this issue is not specific to your code. I remember that variable declaration testing was quite a mess). >I have fixed this with a new test util class "KeyedString". Great job. The code is much more readable. Baptiste. -- André |
|
From: Andre B. <and...@gm...> - 2003-04-28 03:11:48
|
|
From: Andre B. <and...@gm...> - 2003-04-28 03:05:43
|
Hello together,
i have introduced a new test util class for declaration parsing called
"keyedstring"
it has the same idea as SourceBuilder but specific behaviour for
declaration parsing,
the same key can be used more than one time:
addKeyed( keyword , text )
the "text" elements registered under the same keyword are stored as vector.
Text that should not be keyed can be added by the "<<" operator.
keyedstring s;
s. addKeyed( "SPECIFIER", "short" ) << " ";
s. addKeyed( "SPECIFIER", "int" ) << " ";
s. addKeyed( "DECLARATOR", "* x" ) << ";";
will result in
"short int * x;"
keyed-string will be implicitly converted to std::string if needed.
"Keyed" words can be accessed by "getWord(key,index)".
s.getWord("SPECIFIER",1) will return "int"
The tests look much nicer now and are easier to be extended.
-- André
|
|
From: Baptiste L. <gai...@fr...> - 2003-04-27 11:42:35
|
----- Original Message ----- From: Andre Baresel To: CppTool Mailing List Sent: Sunday, April 27, 2003 12:09 PM Subject: Re: [Cpptool-develop] Declaration parsing started... Baptiste Lepilleur wrote: >>I've looked at some of the tests, and there is some 'magical' constants appearing from nowhere for ast node range test. This makes it hard to understand what is the range of a given node. How did you figure out their values anyway ? >Counting by hand is the simple answer. E.g. "const short int" has three specifiers. They start at 0, 6, and 12. Their lengths are 5, 5, and 3. I will clean this up a little bit ! That would explain why most 'source' where on a single line. I'll try to see if I can come up with a better version of SourceBuilder for testing (this issue is not specific to your code. I remember that variable declaration testing was quite a mess). >>As for the test routines, they call it test driven design, or test first design. I just made the environment to make it possible for us ;-). It was actually the reason why I renounced to use Boost.Spirit (a generic programming parser framework). Compile time were huge (just including the headers in a cpp resulted in a compile time of around a minute !). >I'm not sure yet, if the boost.spirit approach makes the parser better understandable, since even reading the simple examples at the spirit pages don't make me say "wow that's it" ... what do you think - did I miss some point which makes the "Spirit" worth for us ? I think it would be useful to write mini-parser (much akin to ours). The problem is again compilation time. Who would use a date parser that take a minute to compile ? You also get more flexibility than in parser generator since you can define hand coded rules and action. Another major issue with Spirit is support for VC 6 is low. You often stumble uppon internal compiler error, some or those, I never managed to work around. If we need a parser, I think PCCTS would be the best choice. It's widely supported, and have a lot of functionnalities (it's only drawback I remember when I looked at it a long while ago was unicode support, which is not an issue for us). One of the nice feature it has is the ability to generate AST, and then write a 'parser' to modify or visit that AST. Even if it would require code generation, it would still lead to a compile/test cycle way faster than with Boost.Spirit. Anyway, our hand parser is fairly good and allow for very simple testing. One of its most important property I think is the fact that it takes advantage of the hierarchical structure of C++. This provides strong error recovery capability (or at least, it should :-) ). Baptiste. >-- André |
|
From: Baptiste L. <gai...@fr...> - 2003-04-27 11:25:29
|
----- Original Message -----=20
From: Andre Baresel=20
To: CppTool Mailing List=20
Sent: Sunday, April 27, 2003 12:09 PM
Subject: Re: [Cpptool-develop] Declaration parsing started...
Declaration of class variables or variables of a namespace are using =
this syntax.
typedef int myint;
namespace nnnn {
extern int x;
}
myint ::nnnn::x =3D 0;
Note that the problem only appears in case of userdefined type. =
Since than the syntax
specifies, that a userdefined type can be specified using "::". For =
this reason we can not
stop reading after "myint" and have to continue with "::nnnn". The =
parser does not know
where to stop if a "::" follows.
A second example is the use of class variables:
class nnnn {
static int x;
};
myint ::nnnn::x =3D 0;
The second example is more of an issue than the first one. Though, I =
doubt we'll stumble uppon it often. In most case we can rely on the fact =
that the static will be declared within the namespace and the type won't =
be prefixed:
namespace nnnn {
myint x =3D 0;
}
Or :
myint nnnn::x =3D 0;
Have you ever seen code as you pointed out ? I don't think I did.
Baptiste.
PS: check your mailer configuration. I think that mail was in HTML. This =
makes it difficult to quote when replying.
|
|
From: Andre B. <and...@gm...> - 2003-04-27 10:03:22
|
Baptiste Lepilleur wrote:
>>I'll try to replace the variable-
>>declaration-mutator as soon as the 'variable-detection' is handled by
>>the new Parser.
>>
>>
>
>Local variable declaration is very close to class attribute declaration, so
>reuse should occur.
>
Definitly, however the declaration list within a class body has an
extended syntax (visibility keywords and
pure-declaration. But I think we can simply extend the usual
declaration-list-parser for this, since these
keywords will not appear at filescope.
>>Durring tests I also recognized a problem in parsing declaration which
>>can not be solved with parser
>>information only (I believe): (Has been added to the Wiki)
>>
>> typedef int myint;
>>
>> class x {
>> public:
>> static myint y;
>> };
>>
>> myint ::x::y; // <--- how to parse ?
>>(variant a) type "myint::x::y" + no variable
>>(variant b) type "myint::x" + variable "::y"
>>(variant c) type "myint" + variable "::x::y"
>>
>> btw: spaces are allowed between '::' and identifier ("x<space>::y"
>>equals "x::y")
>> "class x ::z::y" has three meanings !
>>
>>
>Could you provide some examples of variable declaration ? For what I've
>tried, it is not possible to prefix the name of the declared variable by ::.
>
>int ::x; // failed to compile => can not force x to be in global
>namespace
>
>The only place I could see this work is when you are referering to variable
>x in some expression.
>
Declaration of class variables or variables of a namespace are using
this syntax.
typedef int myint;
namespace nnnn {
extern int x;
}
myint ::nnnn::x = 0;
Note that the problem only appears in case of userdefined type. Since
than the syntax
specifies, that a userdefined type can be specified using "::". For this
reason we can not
stop reading after "myint" and have to continue with "::nnnn". The
parser does not know
where to stop if a "::" follows.
A second example is the use of class variables:
class nnnn {
static int x;
};
myint ::nnnn::x = 0;
>
>
>
>>>Concerning code clean-up, you might want to reuse the SourceBuilder class
>>>
>>>
>we
>
>
>>>use in the rfta library (or implement a similar class, more dedicated to
>>>
>>>
>ast
>
>
>>>node range). This would makes the tests easier to write, read and
>>>
>>>
>maintain.
>
>
>>I was thinking about that, but than decide a different solution.
>>For class body parsing I will check this test solution again.
>>I more and more understand your test routines ;-)...
>>
>>
>
>I've looked at some of the tests, and there is some 'magical' constants
>appearing from nowhere for ast node range test. This makes it hard to
>understand what is the range of a given node. How did you figure out their
>values anyway ?
>
Counting by hand is the simple answer.
E.g. "const short int" has three specifiers.
They start at 0, 6, and 12. Their lengths are 5, 5, and 3.
I will clean this up a little bit !
>As for the test routines, they call it test driven design, or test first
>design. I just made the environment to make it possible for us ;-). It was
>actually the reason why I renounced to use Boost.Spirit (a generic
>programming parser framework). Compile time were huge (just including the
>headers in a cpp resulted in a compile time of around a minute !).
>
>
I'm not sure yet, if the boost.spirit approach makes the parser better
understandable, since
even reading the simple examples at the spirit pages don't make me say
"wow that's it" ...
what do you think - did I miss some point which makes the "Spirit" worth
for us ?
>I was thinking of something along the same lines. I've added a CPPParser
>class, which should ultimately become the main interface to the rftaparser
>library (at the current time, it's just a squeleton).
>
Yep that CPPParser is a nice idea.
>I'll also try to get something out so that we can run the new parser over a
>large number of sources and study the output (much like astdumper).
>
Yep, I also allready played arround with a modified version of ASTDump,
but did not checked it in...
-- André
|
|
From: Andre B. <and...@gm...> - 2003-04-27 08:55:14
|
The ParserTools solution is a good idea since some implementation found in parser classes can be moved there (e.g. some members of variabledeclmutator and unparseddeclarationmutator). I will play arround with the CStringView and Enumerator - at the moment the code of CaseStatementParser does look a little bit complex with the Enumerator and StringView ... it's just a feeling -- André |
|
From: Andre B. <and...@gm...> - 2003-04-27 08:08:44
|
|
From: Baptiste L. <gai...@fr...> - 2003-04-26 22:30:38
|
Fine with me (doing the error detection is already part of the work). Though, we agree that it can be a useful refactoring ?. Notes that the code model make adding a compound fairly easy. The hard part is figuring out if it is needed, and what data to put in. Baptiste. ----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Friday, April 25, 2003 3:42 PM Subject: Re: [Cpptool-develop] space problem > On Fri, 25 Apr 2003, Baptiste Lepilleur wrote: > > > Good. > > > > I've added a test to SplitDeclarationRefactoringTest for declaration > > occuring inside for statement. > > > > What should we do in that case ? If we keep the current semantic of the > > refactoring, I think a error should be reported, but on the other hand, we > > could change the refactoring to ExtractDeclarationRefactoring. > > For now, I think an error should be reported. > > > > For a declaration statement, the semantic remaing identical. > > For a declaration occuring in a for statement (initializer), a if or a while > > condition, declarations are extracted before the for statement (tricky, may > > need to add a compound statement). > > > > What do you think ? > > This requires some more sophisticated code analysis, unless we decide to > always encapsulate the extracted declaration and the for statement in a > new compound. Let's keep this on the TODO list. > > Sven. > > > Baptiste. > > > > ----- Original Message ----- > > From: "Sven Reichard" <rei...@ma...> > > To: "CppTool Mailing List" <Cpp...@li...> > > Sent: Thursday, April 24, 2003 6:29 PM > > Subject: [Cpptool-develop] space problem > > > > > > > I solved the "space problem" that occured when rewriting declarator > > > expression. I'm currently checking in the changes. > > > > > > My past remarks about keeping pointers to deleted elements are obsolete. > > > Sorry about the confusion. > > > > > > Sven. > > > > > > -- > > > Sven Reichard > > > Dept. of Math. Sci. > > > University of Delaware > > > rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2003-04-26 22:26:43
|
I was looking at the implementation and it seems while a bool is
returned, no error is ever declared.
Shouldn't:
DeclarationParser parser(context_, current_ , end_ );
if ( !parser.tryParse() )
break;
do a return false; instead of a break ?
Also, at a later time, we will need to introduce error recovery support.
What could be the strategy ?
- Find next ';' and restart parsing.
- Find next '}' and restart parsing (end of function body, this would mean
that we failed to parse a function declaration)
- Find next '{' and walk backward as much as possible until a successful
parse occurs (search for a function/class body start, then search the start
of the declaration associated to the body).
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2003-04-26 22:21:09
|
I've added a new utility class: CStringView (in xtl/CStringView.h).
Tests are in rftaparser. It's basically a object that take a start and end
const char *pointer to represent a string. The string is not copied (it's to
be use for parsing). A random access and reverse random access iterator are
also provided. Notes that the iterators are also enumerators: they know the
string they are iterating over.
The classes probably still need a few adjustement, but I've already used
it successfully to refactor CaseStatementParser.
This should enable a few IntroduceParameterObject refactored. It should
also be possible to extract some of the mini-parser present in Parser and
made them more generic. This has already been done for a few (see
ParserTools.h).
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2003-04-26 22:12:02
|
----- Original Message -----
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Saturday, April 26, 2003 4:06 PM
Subject: Re: [Cpptool-develop] Declaration parsing started...
> Baptiste Lepilleur wrote:
>
> >Notes that concerning the function pointer, the most important place to
> >support them is typedef. In most of the code I have seen, function
pointers
> >were nearly always 'typedefed'.
> >
> Function pointers and even the declaration of 'operator'
> overloading/type-conversion can be detected
> now. The parser does recognize this and parses it correctly (hopefully!?
> see Tests), but no information
> is stored yet. We get Type-Specifiers and Unparsed-Declarators at the
> moment.
I skimmed over the test, and this looks very promising. Nice works !
> Well typedef itselfe is no problem, since it is just one keyword.
> Note that it can even stay in the middle of a declaration:
>
> int typedef mydef;
>
> Looks strange ? yes, but the EBNF allows this.
What it the comon equivalent expression ? (That's the kind of stuff that
will probably never be used, just like the fact you can put braces around
parameter name).
> Tests took really long (see UnparsedDeclarationMutatorTests), but after
> all I managed a very clean
> solution. I first played arround with the VariableDeclMutator which does
> nearly the same job, but was
> not able to fullfill all tests and was to complex after adding
> functionality. I'll try to replace the variable-
> declaration-mutator as soon as the 'variable-detection' is handled by
> the new Parser.
Local variable declaration is very close to class attribute declaration, so
reuse should occur.
> Durring tests I also recognized a problem in parsing declaration which
> can not be solved with parser
> information only (I believe): (Has been added to the Wiki)
>
> typedef int myint;
>
> class x {
> public:
> static myint y;
> };
>
> myint ::x::y; // <--- how to parse ?
> (variant a) type "myint::x::y" + no variable
> (variant b) type "myint::x" + variable "::y"
> (variant c) type "myint" + variable "::x::y"
>
> btw: spaces are allowed between '::' and identifier ("x<space>::y"
> equals "x::y")
> "class x ::z::y" has three meanings !
> I wrote a test on this (deactivated), but this problem is not high
priority.
Could you provide some examples of variable declaration ? For what I've
tried, it is not possible to prefix the name of the declared variable by ::.
int ::x; // failed to compile => can not force x to be in global
namespace
The only place I could see this work is when you are referering to variable
x in some expression.
> >Concerning code clean-up, you might want to reuse the SourceBuilder class
we
> >use in the rfta library (or implement a similar class, more dedicated to
ast
> >node range). This would makes the tests easier to write, read and
maintain.
> >
> I was thinking about that, but than decide a different solution.
> For class body parsing I will check this test solution again.
> I more and more understand your test routines ;-)...
I've looked at some of the tests, and there is some 'magical' constants
appearing from nowhere for ast node range test. This makes it hard to
understand what is the range of a given node. How did you figure out their
values anyway ?
As for the test routines, they call it test driven design, or test first
design. I just made the environment to make it possible for us ;-). It was
actually the reason why I renounced to use Boost.Spirit (a generic
programming parser framework). Compile time were huge (just including the
headers in a cpp resulted in a compile time of around a minute !).
> Open tasks for me, at the moment:
> - class body parsing, supporting additional declaration elements
> (e.g. public, protected keywords)
You may want to add QT extension too:
public slots: // (any access modifier is ok before slots)
signals:
slots is a macro that expands to nothing, and signals expands to protected
(I think). More info: http://doc.trolltech.com/3.1/signalsandslots.html.
They should not be expanded, but memorized as additional access modifiers.
> "UnparsedClassSpecifierMutator" will be created
> - simple declarator parsing for detecting variables
> "UnparsedDeclaratorMutator" will be created
> - function header parsing, to detect parameters
> "UnparsedFunctionHeaderMutator" will be created
> - I'm thinking about a new Mutator to replace the MaxLODMutator.
> This Mutator only accesses Mutator for more details at the
> specified Source Position.
> It would allow us for Refactoring Operations to start parsing
> allways at SourceLevel and
> than step down to the position where the user has activated
> some refactoring request.
> How to name it ? what about "PositionMaxLODMutator"
> - An additional Mutator could be written which only parses source
> positions where some
> identifier does appear. (reuse of the PositionMaxLODMutator)
I was thinking of something along the same lines. I've added a CPPParser
class, which should ultimately become the main interface to the rftaparser
library (at the current time, it's just a squeleton).
The only service we need at the current time is:
- find and parse the function body which encompass a specified location
(usualy, the user selection).
A service we will need later:
- parse all the source, but don't parse struct/class/function bodies
As for the implementation, I would go the other way: keep the MaxLODMutator
expanding everything (if given at top-level, everything get expanded). And I
would add another LOD mutator to implements second service (up to function
level). May be name it BodyLessLODMutator (we parse everything but the
bodies) or something like that.
The first service would be implemented roughly like this:
- parse at bodyless level (DeclarationListParser + BodyLessLODMutator)
- walk down the ast node tree until we find a body that includes the
specified position (error if not found)
- mutate the body with the MaxLODMutator
- return the function declaration node (will need to updated Refactoring to
start at this level, and obtains the compound statement node from that one).
We will probably need a service concerning identifiers, but will study that
when we get there (global renaming).
> For the future:
> - to access identifier:
> identifier resolver strategy for class/namespace/function header
> --> we need named scopes, and methods to resolve scoped identifier
Yes, and that promise to be tough. We'll definitively use TDD for that one.
Hopyfully, we'll have a nice code model to work with at the time.
I'll also try to get something out so that we can run the new parser over a
large number of sources and study the output (much like astdumper).
Baptiste.
>
> -- André
|
|
From: Andre B. <and...@gm...> - 2003-04-26 14:00:10
|
Baptiste Lepilleur wrote:
>Notes that concerning the function pointer, the most important place to
>support them is typedef. In most of the code I have seen, function pointers
>were nearly always 'typedefed'.
>
Function pointers and even the declaration of 'operator'
overloading/type-conversion can be detected
now. The parser does recognize this and parses it correctly (hopefully!?
see Tests), but no information
is stored yet. We get Type-Specifiers and Unparsed-Declarators at the
moment.
Well typedef itselfe is no problem, since it is just one keyword.
Note that it can even stay in the middle of a declaration:
int typedef mydef;
Looks strange ? yes, but the EBNF allows this.
Tests took really long (see UnparsedDeclarationMutatorTests), but after
all I managed a very clean
solution. I first played arround with the VariableDeclMutator which does
nearly the same job, but was
not able to fullfill all tests and was to complex after adding
functionality. I'll try to replace the variable-
declaration-mutator as soon as the 'variable-detection' is handled by
the new Parser.
Durring tests I also recognized a problem in parsing declaration which
can not be solved with parser
information only (I believe): (Has been added to the Wiki)
typedef int myint;
class x {
public:
static myint y;
};
myint ::x::y; // <--- how to parse ?
(variant a) type "myint::x::y" + no variable
(variant b) type "myint::x" + variable "::y"
(variant c) type "myint" + variable "::x::y"
btw: spaces are allowed between '::' and identifier ("x<space>::y"
equals "x::y")
"class x ::z::y" has three meanings !
I wrote a test on this (deactivated), but this problem is not high priority.
>Concerning code clean-up, you might want to reuse the SourceBuilder class we
>use in the rfta library (or implement a similar class, more dedicated to ast
>node range). This would makes the tests easier to write, read and maintain.
>
I was thinking about that, but than decide a different solution.
For class body parsing I will check this test solution again.
I more and more understand your test routines ;-)...
Open tasks for me, at the moment:
- class body parsing, supporting additional declaration elements
(e.g. public, protected keywords)
"UnparsedClassSpecifierMutator" will be created
- simple declarator parsing for detecting variables
"UnparsedDeclaratorMutator" will be created
- function header parsing, to detect parameters
"UnparsedFunctionHeaderMutator" will be created
- I'm thinking about a new Mutator to replace the MaxLODMutator.
This Mutator only accesses Mutator for more details at the
specified Source Position.
It would allow us for Refactoring Operations to start parsing
allways at SourceLevel and
than step down to the position where the user has activated
some refactoring request.
How to name it ? what about "PositionMaxLODMutator"
- An additional Mutator could be written which only parses source
positions where some
identifier does appear. (reuse of the PositionMaxLODMutator)
For the future:
- to access identifier:
identifier resolver strategy for class/namespace/function header
--> we need named scopes, and methods to resolve scoped identifier
-- André
|
|
From: Sven R. <rei...@ma...> - 2003-04-25 13:42:51
|
On Fri, 25 Apr 2003, Baptiste Lepilleur wrote: > Good. > > I've added a test to SplitDeclarationRefactoringTest for declaration > occuring inside for statement. > > What should we do in that case ? If we keep the current semantic of the > refactoring, I think a error should be reported, but on the other hand, we > could change the refactoring to ExtractDeclarationRefactoring. For now, I think an error should be reported. > > For a declaration statement, the semantic remaing identical. > For a declaration occuring in a for statement (initializer), a if or a while > condition, declarations are extracted before the for statement (tricky, may > need to add a compound statement). > > What do you think ? This requires some more sophisticated code analysis, unless we decide to always encapsulate the extracted declaration and the for statement in a new compound. Let's keep this on the TODO list. Sven. > Baptiste. > > ----- Original Message ----- > From: "Sven Reichard" <rei...@ma...> > To: "CppTool Mailing List" <Cpp...@li...> > Sent: Thursday, April 24, 2003 6:29 PM > Subject: [Cpptool-develop] space problem > > > > I solved the "space problem" that occured when rewriting declarator > > expression. I'm currently checking in the changes. > > > > My past remarks about keeping pointers to deleted elements are obsolete. > > Sorry about the confusion. > > > > 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 > -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2003-04-25 08:41:26
|
Wouah, you're fast. This sound very promising.
Notes that concerning the function pointer, the most important place to
support them is typedef. In most of the code I have seen, function pointers
were nearly always 'typedefed'.
Concerning code clean-up, you might want to reuse the SourceBuilder class we
use in the rfta library (or implement a similar class, more dedicated to ast
node range). This would makes the tests easier to write, read and maintain.
Baptiste.
----- Original Message -----
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Friday, April 25, 2003 8:50 AM
Subject: Re: [Cpptool-develop] Declaration parsing started...
> Baptiste Lepilleur wrote:
>
> >I'll give this a more thorough look later on. A few primilary remarks
> >though:
> >
> >Our 'C++' is wider than the standard (we have single pass parsing). For
> >example, we should support class declaration such as:
> >
> >class RFTA_API TextDocument { };
> >
> >Were RFTA_API is stored as the optional 'export macro name'. This is a
> >widely used idiom on Win32.
> >
> >The AST should capture all data required for the source code manipulation
> >(capture the range of all element that might be removed, inserted,
> >modified).
> >
> >A primary goal would probably be able to identify the function/method
bodies
> >(this would solve the issue you raised concerning the starting compound
> >statement for variable declaration search).
> >
> This works allready, I'm currently at the point of parsing declaration
> specifiers and declarators. The parsing of
> specifiers includes class declarations. About the declarators I'm not
> yet sure how far I should go. At the moment
> I try to merge the variabledeclmutator with my declarationmutator and
> try to get a more general solution which
> can parse any declaration type.
> There's only one problem left which are function pointers like:
> usertype (*f) ( int );
> As soon as I have cleaned the code I will check in.
>
> >Next, I would probably go for class parsing (rough, just extract the
name,
> >methods, and method/function implementation parsing. Having those two
open
> >doors for ExtractInterface refactoring (just needs the class methods),
and
> >ExtractMethod refactoring (need to add a method in the class declaration,
> >adding a new method body, and know what are the method parameters).
> >
> This is fine with the current implementation.
>
> until later,
> André
|
|
From: Baptiste L. <gai...@fr...> - 2003-04-25 08:04:03
|
Good. I've added a test to SplitDeclarationRefactoringTest for declaration occuring inside for statement. What should we do in that case ? If we keep the current semantic of the refactoring, I think a error should be reported, but on the other hand, we could change the refactoring to ExtractDeclarationRefactoring. For a declaration statement, the semantic remaing identical. For a declaration occuring in a for statement (initializer), a if or a while condition, declarations are extracted before the for statement (tricky, may need to add a compound statement). What do you think ? Baptiste. ----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Thursday, April 24, 2003 6:29 PM Subject: [Cpptool-develop] space problem > I solved the "space problem" that occured when rewriting declarator > expression. I'm currently checking in the changes. > > My past remarks about keeping pointers to deleted elements are obsolete. > Sorry about the confusion. > > Sven. > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... |
|
From: Andre B. <and...@gm...> - 2003-04-25 06:44:16
|
Baptiste Lepilleur wrote:
>I'll give this a more thorough look later on. A few primilary remarks
>though:
>
>Our 'C++' is wider than the standard (we have single pass parsing). For
>example, we should support class declaration such as:
>
>class RFTA_API TextDocument { };
>
>Were RFTA_API is stored as the optional 'export macro name'. This is a
>widely used idiom on Win32.
>
>The AST should capture all data required for the source code manipulation
>(capture the range of all element that might be removed, inserted,
>modified).
>
>A primary goal would probably be able to identify the function/method bodies
>(this would solve the issue you raised concerning the starting compound
>statement for variable declaration search).
>
This works allready, I'm currently at the point of parsing declaration
specifiers and declarators. The parsing of
specifiers includes class declarations. About the declarators I'm not
yet sure how far I should go. At the moment
I try to merge the variabledeclmutator with my declarationmutator and
try to get a more general solution which
can parse any declaration type.
There's only one problem left which are function pointers like:
usertype (*f) ( int );
As soon as I have cleaned the code I will check in.
>Next, I would probably go for class parsing (rough, just extract the name,
>methods, and method/function implementation parsing. Having those two open
>doors for ExtractInterface refactoring (just needs the class methods), and
>ExtractMethod refactoring (need to add a method in the class declaration,
>adding a new method body, and know what are the method parameters).
>
This is fine with the current implementation.
until later,
André
|
|
From: Sven R. <rei...@ma...> - 2003-04-24 16:29:42
|
I solved the "space problem" that occured when rewriting declarator expression. I'm currently checking in the changes. My past remarks about keeping pointers to deleted elements are obsolete. Sorry about the confusion. Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2003-04-23 22:49:15
|
On Wed, 23 Apr 2003, Baptiste Lepilleur wrote: > I'm not sure I understand what you want. The Change structure stored the > original source range of the element is what was parsed (set in the > setElementIsFromSource() method of CodeElement). That way the old text can > be retrieved if needed, as well as its range for deletion. What I want is to avoid reparsing the source code. > > Problem with keeping the old pointer around is that a common practice of > refactoring is to move things around (for example, remove a statement and > insert it somewhere else). So what? That's why use smart pointers, isn't it? Maybe I'm again missing something major here :) Sven. > Baptiste. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2003-04-23 19:47:39
|
Well done. I hadn't though it was possible to use the CodeModel for actual
code transformation yet
For notes, The ASTNode should disappears from the Refactoring, and the
IdentifierResolver will be rewritten using the CodeModel. That way code
analysis and transformation will only deal with a fairly clearly defined
CodeModel.
Notes that the unit test CodeModelGeneratorTest::testFunctionPointer fails
because function pointer are not recognized (yet) as variable declaration
(meaning that the produced is not of the correct type).
Baptiste.
----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Monday, April 21, 2003 5:19 AM
Subject: [Cpptool-develop] new refactoring
> In order to understand the code model component, I tried to implement a
> silly little refactoring which I would call SplitDeclaration. Basically,
> it transforms something like
> {
> double *x, y[3], &z;
> }
> to
> {
> double *x;
> double y[3];
> double &z;
> }
> This is useful if e.g., we want to modify the declaration of one of the
> variables, like make it const. It also avoids one common mistake, namely
>
> int* x, y; // these are not two pointers
>
> It is fully implemented using the code model, though the code is still a
> bit ugly, since I haven't gotten used to dealing with shared pointers yet.
> I will clean it up a bit before committing it.
>
> In order to make it run, I had to modify the way declaration expressions
> are handled in the model/rewriter. I committed the changes, as well as the
> tests that made them necessary.
>
> As I said, the main purpose was to understand the code model, and I start
> to like it :) I still have a few questions, but they can wait until
> Baptiste gets back.
>
> More later,
> Sven.
>
> --
> Sven Reichard
> Dept. of Math. Sci.
> University of Delaware
> rei...@ma...
|
|
From: Baptiste L. <gai...@fr...> - 2003-04-23 19:22:42
|
I'm not sure I understand what you want. The Change structure stored the original source range of the element is what was parsed (set in the setElementIsFromSource() method of CodeElement). That way the old text can be retrieved if needed, as well as its range for deletion. Problem with keeping the old pointer around is that a common practice of refactoring is to move things around (for example, remove a statement and insert it somewhere else). Baptiste. ----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Wednesday, April 23, 2003 6:56 PM Subject: [Cpptool-develop] space problem > I looked into the white space problem when removing the first declarator > in a declarator expression. The problem is that when rewriting, we don't > have access to the removed element anymore. Maybe we can just mark things > as removed, without replacing them by null pointers. > > Sven. > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2003-04-23 19:12:39
|
----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Wednesday, April 23, 2003 5:50 PM Subject: Re: [Cpptool-develop] welcome back > On Wed, 23 Apr 2003, Baptiste Lepilleur wrote: > > ... > > > > By the way Sven, would you mind changing your editor settings from 'insert > > tabs' to 'insert spaces' ? This would allow the code to be correctly > > indented without regards to the editor settings. > > Hmmm... usually emacs inserts spaces. The only issue that I can think of > is that when adding a statement, it uses the indentation space found in > the previous statement. Where there tabs in all the code I added? Hum, tabs length was around 8 if I remember. It may be an optimization applied when saving the file. > I still need to remember to change the indentation space; right now emacs > uses 2 spaces, where as in most of the code, 3 spaces are used, if I'm not > mistaken. Yes, the tabs were presents only on the new code (checked by enable view whitespace in VC). > > Don't ever do that. stdafx.h is an optimization only (I made some benchmark > > a while ago with an old project and it saved about 5 seconds out of 35 > > seconds for a complete build). The project should compile correctly fine if > > stdafx.h is a blank file. Only widely used STL headers should go there. If > > it does not compile on Unix, then it is a bug, and the missing STL include > > should be added. > > Ok. BTW, your timing is impressive. gcc is way slower. Just tested, it > uses 7 min for a complete rebuild (with tests, but without eclipse and VC > plugins) :( But then, I have a slow computer. Timing was refering to an old project. Rfta in debug configuration (including cppunit, the dllplugintester and all the unit tests ) takes about 1mn30s on my PC (P4 2.4Ghz). Amazingly the release configuration takes a similar time (even though unit test are not compiled, but that the time cost for optimization). For notes, pyrfta (basic python binding using Boost.Python which use the MPL) takes 1mn20s. That the cost of 'template to death' ;-( > [...] > > If so, we may want to introduce a asssertion facilities (throw exception in > > standard mode, break in 'advanced debug mode'). > > Is it correct that during normal execution of the code, no exceptions are > thrown? Then I could just switch off support for exceptions. However, I > think that at least CppUnit relies heavily on them. No, this is incorrect. A major exception may be thrown during the normal execution: There is some exception that may be thrown during normal execution: it's ParserError, thrown when parsing fail. This occurs for example when a badly formed (or unsupported) source is provided. This is part of the 'normal' path. Some others libraries also rely on exception to report error (Boost.FileSystem, converting a weak_ptr to a shared_ptr if the pointed object has been destroyed...). Also, I think the default new handler throw an exception if no memory is available. > > Check out the boost documentation in boost/libs/smart_ptr. You'll find the > > few functions to deal with smart-pointer (cast...), as well as a new page > > explaining the many use of shared_ptr. > > > > > The other point is that I understand the use of shared pointers if we have > > > several pointers to the same object, and it is not clear which one will > > > survive longer. IMO this is not the case when dealing with a visitor; the > > > host calls a method of the visitor in its accept method, and the host > > > certainly exists during the execution of the method. Thus an ordinary > > > pointer is sufficient in this case; since it is simpler to manage (and > > > more efficient) it should be preferred. > > > Please let me know if I'm missing a good reason why to use shared pointers > > > here. > > > > Yes there is. This allow you to collect code element while visiting and > > reuse them when transforming the code. Main use though would probably be to > > move statements and declarations around. > > I still need to get used to the idea of a visitor modifying the structure > (not only the content) of the object it is visiting. I was more thinking of the visitor collecting the interesting element. Change being made to the structure after it was visited. Baptiste. > > Later, > Sven. > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2003-04-23 16:56:18
|
I looked into the white space problem when removing the first declarator in a declarator expression. The problem is that when rewriting, we don't have access to the removed element anymore. Maybe we can just mark things as removed, without replacing them by null pointers. Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
