From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Elizabeth Chastain <chastain@cygnus.com>
To: dberlin@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Handle comments in the C expression parser
Date: Tue, 13 Feb 2001 21:01:00 -0000
Message-id: <200102140501.VAA27824@bosch.cygnus.com>
X-SW-Source: 2001-02/msg00195.html

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"