Re: [boost] [spirit] Support for one-pass iterators?

Subject: Re: [boost] [spirit] Support for one-pass iterators?
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2009-10-19 12:51:33

> > >> The docs say that the grammar should pass a reference to the
> > starting
> > >> rule to the base class constructor (qi::grammar specialization).
> But
> > >> at this point the rule's constructor has not yet been called.
> What's
> > >> more, the base class calls a method on the passed reference.
> > >
> > > Where did you get that info? The base class does not call a method
> on
> > > the passed reference. That is not correct. It only does so at parse
> > > time and at that time, everything has already been constructed.
> >
> > Hmm... I may be misinterpreting what I see at
> > boost/spirit/home/qi/nonterminal/grammar.hpp:54, in the release
> branch:
> >
> >      grammar(
> >          start_type const& start
> >        , std::string const& name_ = "unnamed-grammar")
> > =>  : proto::extends<terminal,
> > base_type>(terminal::make(start.alias()))
> >      , name_(name_)
> >      {}
> >
> > Here "start" is a reference to a not yet constructed object.
> 
> All the construct is doing is to use the address of start (which is
> known and well defined at this point). The address of an object doesn't
> change during construction. Just look at the code, you'll see it. The
> code does not refer to any member data items of 'start'. I see no
> problem with this.
> 
> Do you have a real problem while using Spirit or is this discussion
> merely 'academic'?

I looked into the Standard and it says there [3.8.6]:

<quote>
Similarly, before the lifetime of an object has started but after the
storage 
which the object will occupy has been allocated or, after the lifetime of an

object has ended and before the storage which the object occupied is reused 
or released, any lvalue which refers to the original object may be used but 
only in limited ways. Such an lvalue refers to allocated storage (3.7.4.2), 
and using the properties of the lvalue which do not depend on its value is 
well-defined.
</quote>

Regards Hartmut

-------------------
Meet me at BoostCon
http://boostcon.com