It’s used when you want all the elements to be matched exactly once, e.g.

Using: strict[char_('a') ^ 'b' ^ 'c']
Input: cab -> success
Input: ca -> fail

You can access the code at https://github.com/jamboree/boost-jamboree-spirit

Yet, I feel the usage of permutation (strict or not) is limited, it can’t deal with the case in which the elements are required to be delimited…

About the strict directive qi::strict[] that you’ve implemented:
What is the situation?

Thanks

Uba

See:
http://boost.2283326.n4.nabble.com/Strict-Permutation-Idea-amp-Impl-td3623152.html

I have come to a 2nd case where I’d like to use a “operator” for strict permutation where all the operands are required to appear exactly once.
It was mentioned there were no more c++ operators available for this?

Can a function be used instead?

Regards Hartmut

You should also be able to mix required and non required elements. For example a + b + -c would match “ab” “ba” “bac” …
a + b + *char_ would match all strings that included a and b, but you could have different semantic actions for a and b.
This would be really useful for parsing key-value pairs where a couple pairs are required, and there are optional user defined pairs.

You could write the function or operator like this:
rule operator + (rule a, rule b) {return (a << b) | (b << a);}

A strict permutation operator or function as described above would be incredible useful. It would result in cleaner looking code, and work in complicated situations that would be hard to implement using phoenix operators. Do you think you could implement one in a future release?

Thanks
–Robert Nelson

Host: 1.1.1.1:80
Connection: close
Content-Length: 1234

…via this rule:

rule = connection_header
  ^ content_length_header
  ^ host_header
  ^ omit[+print >> eol] // catch-all
  ;

…will not behave as expected. It will match the ‘Host’ header and the ‘Content-Length’ header, but the ‘Connection’ header will get eaten up by the catch-all. I don’t know if this is a bug in the spirit implementation (I’m using 2.3) or if it’s intentional, but it makes the permutation parser useless in those cases, especially if you’re trying to fuse/adapt a rule to a struct. Unfortunately, in my experience, almost all of the cases where the permutation parser would otherwise come into use are of this variety, which means I rarely end up using the ^ operator, and I have to take a messy roundabout strategy with lots of explicit semantic actions.

can you please be a little bit more precise? I got the same error, but I am not able to fix it with your hint. Can you post a source that compiles?

Thanks a lot
Patrick

Is the shown syntax correct?

Thanks,
Olaf