2

I have a boost xpressive sregex and semantic action that is equivalent to the following:

Rule = ('[' >> (s1=!(set=')',']','>')))[some_op(as<std::string>(s1))];

Previously I was using this on boost 1.43 without any problems. I have had to upgrade to a newer boost recently and now I run into the following issue. On boost 1.48 when the submatch does not match anything (as it is optional) a bad_lexical_cast exception is thrown by the semantic action when as executes on the empty s1 object.

How can I fix this problem, is it just a coincidence that it worked before and there is some better safer way I should be using to do this? Or is this just e.g. some change in the lexical_cast code that now breaks xpressive?

Additional information

I have managed to temporarily solve the actual problem by changing the following in regex_actions.hpp:

template<typename T>
struct as
{
    BOOST_PROTO_CALLABLE()
    typedef T result_type;

    template<typename Value>
    T operator()(Value const &val) const
    {
        return lexical_cast<T>(val);
    }
};

Into:

template<typename T>
struct as
{
    BOOST_PROTO_CALLABLE()
    typedef T result_type;

    template<typename Value>
    T operator()(Value const &val) const
    {
        if(val.first==val.second)
        {
            return T();
        }
        else
        {
            return lexical_cast<T>(val);
        }
    }
};

This leads me to believe that perhaps this is something that needs to be fixed in xpressive itself. However I am not 100% convinced yet that it's not something I am doing wrong on my side, anyone with a bit more knowledge on xpressive have some insight into this?

Malcolm MacLeod
  • 624
  • 7
  • 15
  • Not sure it's supported, but have you tried `some_op(as >(s1))`? – ildjarn Jan 25 '12 at 20:30
  • @ildjam Unfortunately I don't think this will help as (even if `optional` were usable here) the `lexical_cast` would still take place and still throw an error. The only way I can see `optional` being of assistance here is if `s1` itself were declared using it however that would require changes inside `xpressive` itself. I did try your suggestion out anyway just in case but couldn't seem to get it to work in a useful way. – Malcolm MacLeod Jan 25 '12 at 21:19
  • Yeah, I wasn't sure whether or not Xpressive supported integration with Boost.Optional (Boost.Spirit does, which is why I thought Xpressive might). I think your best bet is to have `some_op` take a proper `sub_match` and do the appropriate success check before converting to a string. – ildjarn Jan 25 '12 at 21:21

1 Answers1

1

After investigating a bit more and speaking with the Author of Xpressive I have come to the conclusion that this is either a regression in the behaviour of lexical_cast or a bug in the way xpressive expected lexical_cast to behave.

Malcolm MacLeod
  • 624
  • 7
  • 15
  • This is indeed a regression in `lexical_cast`. I've filed a [bug](https://svn.boost.org/trac/boost/ticket/6452). Thanks for the report! – Eric Niebler Jan 26 '12 at 17:24