(no subject)

[haberg]

cs.ucla.edu>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <address@hidden>
Cc: address@hidden
Content-Transfer-Encoding: 7bit
From: Hans Aberg <address@hidden>
Subject: Re: too many warnings from Bison CVS for Pike
Date: Mon, 6 Feb 2006 20:36:37 +0100
To: Paul Eggert <address@hidden>
X-Mailer: Apple Mail (2.746.2)

On 6 Feb 2006, at 19:43, Paul Eggert wrote:

>>> This is wrong.  Care is taken, and always has, to make yacc.c
>>> compilable with a C++ compiler.
>>
>> Sorry, then I have misunderstood the issue. Is it "a C++ compiler",
>> or "C++ compilers". And is it official support?
>
> If there's a bug, please report it, or remind us about it.  But let's
> not waste time talking about "official support".  We're talking about
> volunteers here!  There is no office.  There is no officer.  There is
> nothing "official".

I thought official support just meant that a feature is documented,  
and that there is a dedication to make it work in subsequent  
versions. Akim's response suggested that the latter is now the case,  
even though my apparently failing memory says that that was not the  
case in the past. But in the past, it has not been a documented  
feature; so the question remains whether it is now.

>> But does the parser stack work with non-POD's?
>
> Sorry, I haven't a clue what you're talking about.

A POD (Plain Old Data) is (according to the C++ standard) essentially  
the C data structures embedded as a part of the C++ language, i.e.,  
essentially they have no user-defined copy assignment operator and no  
user-defined destructor.

The restrictions in POD's means that one can use a memcpy and  
preserve values. So that is what you do in your C parser stacks. One  
can then use POD's but using non'POD's results in undefined behavior.

> That being said, the yacc.c parser is not supposed to be a nice C++
> environment.  Being compatible with C++ does not mean supporting
> namespaces, etc.; all it means is that the parser builds and you can
> run the resulting code, so long as you know its limitations.

So I am just pinning down the limitations, possibly figuring out if  
they can be stretched somewhat, though it not may be worth the effort  
for an actual implementation.

I would think that the non-POD copy assignment operator are not  
called when the parser stack re-allocates: in this case one might  
decide to call them explicitly, or use a deque, which does not need  
copy-over. But then, in addition, I would think that the non-POD  
destructors are not called: again, this might be possible using stack  
de-allocation plus embedding some C++ code in the %destructor part.

But there is the complication what to do if an exception is thrown:  
then I think that the non-POD destructors are not called properly.  
This one, I do not know how to fix.

So, I think the C++ requirement, as of now, must be that the parser  
semantic type must be a POD.

   Hans Aberg