branches/work/kdevelop4-parser

[Steven T. Hatton]

On Tuesday 23 August 2005 04:27, Roberto Raggi wrote:
> SVN commit 452392 by raggi:
>
> Initial version of the KDevelop C/C++ preprocessor.
> It can handle blocks and macro definitions. Macro substitution
> is not yet implemented. I hope to finish it the next creative friday. So
> we can integrate `rpp' in KDevelop.
>
> CCMAIL: kdevelop-devel at kdevelop.org
>
>
>
>  A             rpp (directory)
>  A             rpp/main.cpp   [License: LGPL (v2+) (wrong address)]
>  A             rpp/preprocessor.cpp   [License: LGPL (v2+) (wrong address)]
>  A             rpp/preprocessor.h   [License: LGPL (v2+) (wrong address)]
>  A             rpp/rpp.pro
>  A             rpp/symbol.h   [License: LGPL (v2+) (wrong address)]

I'm always happy to see this kind of stuff.  Thank you.

I feel rather embarrassed to make any suggestion at improving something like 
this since I am not capable of producing it in the first place.  Nonetheless, 
I would like to suggest that the code might benefit by being put in (a) 
namespace(s).  Others may disagree with this.  I can't provide extremely 
strong arguments for doing so.  I just believe that it improves the 
organization of a program to use namespaces carfully. (and organize code in 
directories reflecting that organization.)

I also have a more philosophical observation.  In D&E, Stroustrup talks about 
replacing CPP with in-language techniques, and a smarter macro processor - by 
that he means one that is context-aware, if I understand correctly.  One of 
the (few) valid uses I have seen for the CPP has been to provide a 
rudimentary form of "introspection".  Basically, it's a way of capturing text 
from the source code, and including it in the compiled program.  For the most 
part, I have found this kind of mechanism valuable for debugging.[*]  I'm 
thinking in terms of what Java provides, since I avoid the use of macros in 
C++.  With Java, introspection is part of the language.  Basically, I've used 
it to print out the fully qualified name of a class that throws an exception.  
The advantage to doing that programmatically rather than by hand, is that it 
makes it easier to rename things, or move them from one namespace (package) 
to another without having to modify a lot of code.

There are other potential uses for introspection.  With Java, the information 
is in every class at runtime regardless of whether it's used.  That is a 
violation of the C++ zero-overhead principle.  What I'm thinking is that we 
could leverage the ast to provide optional introspective behavior in a more 
comprehensive and natural way than what is done with the CPP. 

Imagine that, at any point in a program's source code you could write a 
statement that accesses a context dependent meta-object composite that 
described the current scope.  You could do things such as dump all the 
currently declared identifers, as well as any corresponding definition 
information and values.  For example, within a function, you might be able to 
provide the name of the namespace::class::function, as well as all the names 
of all parameters passed to the function.  You may even be able to extract 
information about the caller under some circumstances.

This seems closely related to how the code completion mechanism works.  (or 
should work).  What I'm thinking is that the same mechanism could be used 
both during editing, and at compile time.

[*]Of course, there is also the cookie cutter code such as that used in 
treedump-hack.cpp.
--
Regards,
Steven