Le 21 févr. 06 à 19:34, Joel E. Denny a écrit :

On Tue, 21 Feb 2006, Akim Demaille wrote:

People, like me
years ago, know that you can have C code manipulate C++ structures
properly as long as they are PODs.  Trying to use non PODs in
yacc.c is not supported, that's the role of lalr1.cc.  I'll
write a piece of documentation about this.

Section `10.1.2 C++ Semantic Values' explains that only *pointers* to
non-POD types can be used in %union for "lalr1.cc" and that % destructor is
needed to prevent memory leaks.

That's because we are using a union underneath.  So we inherit
the same limitations.

I've been doing the same for "yacc.c".
I've talked to others who do this as well, but I've not searched for
online references to this usage.  If this usage is somehow an abuse of
"yacc.c", a note about it might be helpful in the documentation.

If this usage is fine, then I wonder how "lalr1.cc" supports non- POD types
more than "yacc.c".  A footnote in the same section says that
`pseudo-unions' may alleviate this need for pointers in the future. So,
are you referring to future plans rather than current support?

Yes.  Supporting non-PODs is really tough to do properly.  We need
something like Boost's variants.

http://www.boost.org/doc/html/variant.html

The portability issues are a bit frightening :(  If you care to read the
excellent material from A. Alexandrescu, you'll see what I mean.
Fortunately we need something less advanced than this, so it should be
really doable, but does require some time.

http://www.cuj.com/documents/s=7984/cujcexp2004alexandr/
http://www.cuj.com/documents/s=7982/cujcexp2006alexandr/
http://www.cuj.com/documents/s=7980/cujcexp2008alexandr/

Reply via email to