In your below example, A would be added to the lexical pre-processor,
and be handled ok. It's only when it is in a header which is not
processed before parsing.
The current CVS version only handles string replacements. I've been
working on trying to get the lexical replacements to handle more
complex things, but I haven't checked it in yet.
If you use any other kind of tool (etags, ebrowse, doxygen, etc) you
will find they have the same problem.
I've found that most cpp macros don't occur in definitions in a way
that would prevent the definition from parsing and are, in general,
pretty obvious. (ie, all caps)
It has been on my list of things to do for a long time to create
pre-processor caches for this purpose, but the overall impact is
pretty small. Particularly in C++ where using a pre-processor to
replace actual C++ code is generally frowned upon.
A recent development is that there is a new GCC feature that dumps out
an XML representation of a C file. Presumably with pre-processor
handling. If this is true and works out, it could solve this problem
handily.
Eric
>>> "Dave Milter" <davemilter@...> seems to think that:
>On 3/17/08, Eric M. Ludlam <eric@...> wrote:
>
>> Semantic cannot do this for you because parsing all the headers can
>> be very slow.
>>
>
>Looks very bad, because of I find out that problem in "export", after some time,
>using semantic debug functions and reducing test case, if I should do
>it every time, to find out what cause a problem, and fix it bad
>hands... :(
>it is problem of elisp, it works too slow?
>
>But what about such example, in this case I also should add
>"A" into semantic-lex-c-preprocessor-symbol-map?
>-------------------------------------
>#define A /**/
>
>struct Foo {
> int i;
>};
>
>int main()
>{
> Foo foo;
>
> return 0;
>}
>-------------------------------------
>
--
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net
|