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