[PATCH] Handle comments in the C expression parser
Michael Elizabeth Chastain
chastain@cygnus.com
Tue Feb 13 21:01:00 GMT 2001
Hi Daniel,
! while (*lexptr != '*')
! lexptr++;
What happens if the user opens a comment with '/*' and does not close it?
It looks like lexptr will go off into the weeds.
Also I do not know if lexptr has access to the whole input in contiguous
memory, or if it gets fed chunks of characters as they arrive.
I can do stuff like this in gdb:
(gdb) print 1 + \
2
$1 = 3
On the design level, I am not opposed to adding in C style comments
in a C parser. But I am skeptical about the planned use for:
break 'Foo::Foo /* base */ (int)'
... which is what I presume you are working towards.
I thought about this name scheme some more:
Foo::Foo
Foo::Foo$Base
You remark that Foo::Foo$Base is not a constructor, because
"Foo$Base" != "Foo". I think that is actually a useful property.
Foo$Base really *is not* a constructor.
If gdb wanted to construct an object in a region of memory, it would call
one of the Foo::Foo constructors. It would never call Foo::Foo$Base.
And the same with Foo::~Foo versus Foo::~Foo$Base.
If there are multiple overloaded Foo::Foo's, the Foo::Foo$Base's
should not join in overload resolution.
I admit there are some ways that Foo::Foo$Base is like a constructor.
It does contain a copy of all the code that the user wrote for a constructor.
Its object code has source line number records that point back into
the C++ source code for the constructor. But I think it's useful to
model it as *not a constructor*, because it does not have the interface
(the programming contract) of a constructor.
Michael Elizabeth Chastain
<chastain@redhat.com>
"love without fear"
More information about the Gdb-patches
mailing list