Re: Bison, C++ and shared_ptr<>

cbarron3@ix.netcom.com (Carl Barron)
3 Feb 2006 21:00:47 -0500

          From comp.compilers

Related articles
Bison, C++ and shared_ptr<> pocmatos@gmail.com (Paulo Matos) (2006-02-03)
Re: Bison, C++ and shared_ptr<> cbarron3@ix.netcom.com (2006-02-03)
Re: Bison, C++ and shared_ptr<> haberg@math.su.se (2006-02-06)
| List of all articles for this month |

From: cbarron3@ix.netcom.com (Carl Barron)
Newsgroups: comp.compilers,comp.unix.programmer
Date: 3 Feb 2006 21:00:47 -0500
Organization: EarthLink Inc. -- http://www.EarthLink.net
References: 06-02-022
Keywords: lex, C++

Paulo Matos <pocmatos@gmail.com> wrote:


> .... I've been reading about
> shared_ptr<> which would be great on the case but it seems %union won't
> let me have a shared_ptr<> as a member. shared_ptr<>* seems awkward and
> meaningless so what I would really like to know is if there is any
> trick to make bison work nicely with 'types with constructors' or
> shared_ptr<>. :)


    This is a restriction imposed by C++ as %union generates a union
declaration and only POD's [essentially types valid in c89] are valid in
unions. Since ypu ara thinking shared_ptr<...> why not use boost
variannt which is a discriminating 'union' of C++ types. A shared_ptr<
of the variant type can be used if copying the variant is to
expensive...


wxample:
    typedef boost::variant
    <
            int,
            pair<int,int>,
            some_class
    > variant_typee;
    #define YYSTYPE variant_type
or
    #define YYSTYPE boost::shared_ptr<variant_type>
insted of %union. This will require rewritting the semantic actions as
automatic selection of the proper type is gone. but the actions are
functions /function objects, they can be overloaded...


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.