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