<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <[EMAIL PROTECTED]> Cc: [email protected] Content-Transfer-Encoding: 7bit From: Hans Aberg <[EMAIL PROTECTED]> Subject: Re: too many warnings from Bison CVS for Pike Date: Wed, 8 Feb 2006 20:16:29 +0100 To: Paul Eggert <[EMAIL PROTECTED]> 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
