(no subject)

[haberg]

 <address@hidden> <address@hidden>
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: Wed, 8 Feb 2006 20:16:29 +0100
To: Paul Eggert <address@hidden>
X-Mailer: Apple Mail (2.746.2)

On 8 Feb 2006, at 01:20, Paul Eggert wrote:

>> I thought official support just meant that a feature is documented,
>
> In that case, the support is not official.  The manual does not
> document that Bison-generated code can be used with any random C++
> compiler.  I'm not inclined to document it, either.

I guess that if there is, as Akim says, a dedicated effort for the C- 
parser to compile under C++ in current and upcoming Bison versions,  
there suffices there to be a note of it somewhere that this is the  
case. It does not need to elaborate, but only so that one can say in  
Help-Bison and other places, yes, you may go ahead compile the parser  
using a C++ compiler.

>> 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.
>
> Not if the compiler #defines __cplusplus.  So it's not a problem for
> C++ compilers.

I do not see what you have in your mind here.

I said that I recall you use(d), under C, memcpy to reallocate the  
parser stack. Now, when one is using C++, the definition of POD types  
is such that this also works. Thus, one can use POD types safely as  
parser semantic type. If one uses a non-POD type this will not work,  
because for example the user defined assignment operator will not be  
properly invoked by memcpy alone. If one wants to extend the C++  
stacks working with non-POD types as well, say by invoking the  
assignment operators explicitly, then this can be tried using  
#defines __cplusplus, but this is not needed using POD types alone.

   Hans Aberg