[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Few bison issues

From: Frank Heckenbach
Subject: Re: Few bison issues
Date: Tue, 23 Apr 2013 21:58:53 +0200

Akim Demaille wrote:

> Le 6 févr. 2013 à 11:59, address@hidden a écrit :
> > 3. In my project I switched from std::string* to
> > boost::shared_ptr<const std::string> type for storing filename
> > in yy::position class. In order to do this I use custom
> > position.hh file. I think it may be good to modify bison code so
> > it will allow to provide type which will be used for storing
> > filenames.
> I agree, but I'm not sure how to do this properly.  I need
> to be able to initialize the filename, to "deference" it
> to display and compare it etc.

> Pointers are to be initialized with YY_NULL.  Templates can
> help on this issue.

The idiomatic way in C++ is to initialize any type with its default
constructor (e.g. "T foo = T ();"). This also works for built-in
types such as pointers (which avoids the whole mess about what the
null pointer is, as in C). Are there any cases where YY_NULL is
really needed in C++, i.e. where it's something else than the null

> But how can I write code that would appropriately dereference
> a pointer, and a shared_ptr?  This is less clear.
> It should support things like
> %define api.location.file.type {std::string}
> %define api.location.file.type {std::string*}
> %define api.location.file.type {std::shared_ptr<std::string>}
> %define api.location.file.type {boost::flyweight<std::string>}

For the other operations (initialize with filename, retrieve
filename, compare), one could use templates or overloaded functions
(which may be predefined in the skeleton for common types like these
four), or require position.hh to define special functions for the
filename type it will use.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]