cpptool-develop

[Cpptool-develop] welcome back

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

Hi guys,

first of all a warm welcome back to blep; I hope you enjoyed your holiday. 
I also appreciate the improvements you made to the code I recently 
submitted. Let me explain the rationale behind some of the things I had 
there.

- Preprocessor condition around <map> inclusion: I figured that for VC the 
template declarations should go into stdafx; I should have actually 
included <stdafx.h> to make it compatible.

- The extraneous assert: This was due to my limited use of the debugger; 
if rfta throws an exception, I only know that some error occurs. If an 
assertion fails, I can inspect (via a core dump) the complete call stack 
and all local variables. I should have removed this once I found the bug.

- Changing shared to regular pointers: Part of it was, as I have said, 
that I didn't feel comfortable with shared pointers yet; thanks for 
pointing out the possibility of a dynamic cast for shared pointers. I 
actually had to deal with a bug where a null DeclarationPtr was 
dereferenced; I changed it to a regular pointer to see better what was 
going on. 
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.

As I said, I like the code model. However, one of the known bugs in 
SplitDeclaration is related to a problem in the Rewriter, which I still 
don't know how to circumvent.

Consider the following declaration

double* x,y[3];

This might not be good style, but it is perfectly legal, and I have 
actually seen something similar in several programs. If we remove the 
first declarator "* x," (note that I moved the '*' to the secondary type 
of the declarator, to prevent a more dangerous bug), we end up with

doubley[3];

We have to find some policy to sensibly add a space in such situations. I 
still haven't figured it out, but I'll keep thinking.

I haven't gotten Eclipse yet, but I continue working on the Emacs 
integration. In general it is clear what has to be done. BTW, is anybody 
else here using Emacs? If yes, I will upload the code as soon as it does 
something; otherwise, I will keep it here for now.

What I would need would be something like line based text document, where 
all I need is the plain text document interface, together with a 
translation from 2-d coordinates to 1-d indices. Selection won't be 
supported for a while, I think. More accurately, selection will be used  
only unidirectionally from emacs to rfta, and not vice versa.

Do we have any class that does this, or should I derive my own document 
from LineBasedTextDocument?

Enough for tonight.

Later,
Sven.

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

Re: [Cpptool-develop] welcome back

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

----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Wednesday, April 23, 2003 6:04 AM
Subject: [Cpptool-develop] welcome back


> Hi guys,
>
> first of all a warm welcome back to blep; I hope you enjoyed your holiday.
> I also appreciate the improvements you made to the code I recently
> submitted. Let me explain the rationale behind some of the things I had
> there.

You're fast, I intented to write the mail this morning with a fresher head
;-)

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.

> - Preprocessor condition around <map> inclusion: I figured that for VC the
> template declarations should go into stdafx; I should have actually
> included <stdafx.h> to make it compatible.

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.

> - The extraneous assert: This was due to my limited use of the debugger;
> if rfta throws an exception, I only know that some error occurs. If an
> assertion fails, I can inspect (via a core dump) the complete call stack
> and all local variables. I should have removed this once I found the bug.

I figured it was something like that. I usually deal with this by either
configuring the compiler to break when a C++ exception is thrown, or by
placing a break point in the exception constructor. Is it not possible to do
that for you ?

If so, we may want to introduce a asssertion facilities (throw exception in
standard mode, break in 'advanced debug mode').

> - Changing shared to regular pointers: Part of it was, as I have said,
> that I didn't feel comfortable with shared pointers yet; thanks for
> pointing out the possibility of a dynamic cast for shared pointers. I
> actually had to deal with a bug where a null DeclarationPtr was
> dereferenced; I changed it to a regular pointer to see better what was
> going on.

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.

This also makes binding to python slightly easier (Boost.Python autmatically
figure out was is the life-time of the function parameter).

> As I said, I like the code model. However, one of the known bugs in
> SplitDeclaration is related to a problem in the Rewriter, which I still
> don't know how to circumvent.
>
> Consider the following declaration
>
> double* x,y[3];
>
> This might not be good style, but it is perfectly legal, and I have
> actually seen something similar in several programs. If we remove the
> first declarator "* x," (note that I moved the '*' to the secondary type
> of the declarator, to prevent a more dangerous bug), we end up with
>
> doubley[3];
>
> We have to find some policy to sensibly add a space in such situations. I
> still haven't figured it out, but I'll keep thinking.

My thougth as do have something like insert a space if the primary type
(+secondary ?) ends with a letter, > or ] (probably slightly more complexes
because of secondary type prefix). When stumbling on weird case like this, I
tried to apply test first design (write the test and get them to work).

>
> I haven't gotten Eclipse yet, but I continue working on the Emacs
> integration. In general it is clear what has to be done. BTW, is anybody
> else here using Emacs? If yes, I will upload the code as soon as it does
> something; otherwise, I will keep it here for now.
>
> What I would need would be something like line based text document, where
> all I need is the plain text document interface, together with a
> translation from 2-d coordinates to 1-d indices. Selection won't be
> supported for a while, I think. More accurately, selection will be used
> only unidirectionally from emacs to rfta, and not vice versa.

> Do we have any class that does this, or should I derive my own document
> from LineBasedTextDocument?

Yes, that what you need to do (and what is done in by the VC++ add-in). Be
aware that there is still a known bug to deal with: tabulations are not
converted to the correct column number.

Baptiste.

>
> Enough for tonight.
>
> Later,
> Sven.
>
> --
> Sven Reichard
> Dept. of Math. Sci.
> University of Delaware
> rei...@ma...

Re: [Cpptool-develop] welcome back

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

On Wed, 23 Apr 2003, Baptiste Lepilleur wrote:
> 
> You're fast, I intented to write the mail this morning with a fresher head
> ;-)

I finally sbuscribed to the CVS mailing list :)

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

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

 > 
> I figured it was something like that. I usually deal with this by either
> configuring the compiler to break when a C++ exception is thrown, or by
> placing a break point in the exception constructor. Is it not possible to do
> that for you ?

I'll think about that. 
> 
> 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.
> 
> 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.

> > doubley[3];
> >
> > We have to find some policy to sensibly add a space in such situations. I
> > still haven't figured it out, but I'll keep thinking.
> 
> My thougth as do have something like insert a space if the primary type
> (+secondary ?) ends with a letter, > or ] (probably slightly more complexes
> because of secondary type prefix). When stumbling on weird case like this, I
> tried to apply test first design (write the test and get them to work).

I have added a test for this.

> 
> 
> > Do we have any class that does this, or should I derive my own document
> > from LineBasedTextDocument?
> 
> Yes, that what you need to do (and what is done in by the VC++ add-in). Be
> aware that there is still a known bug to deal with: tabulations are not
> converted to the correct column number.

Ok, that's what I'll do.


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

Re: [Cpptool-develop] welcome back

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

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