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: <[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: Mon, 6 Feb 2006 20:36:37 +0100 To: Paul Eggert <[EMAIL PROTECTED]> 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
