Closed mwpowellhtx closed 5 years ago
The obvious answer it seems is that I should migrate to 1.69.0
to include the PR, I think. I'll stand by for a little feedback, however.
Ultimately, I'm trying to fold the Comment Skipper in with a minimum of footprint. If I could simply specify the template type in the Parent Grammar, for instance, that would be great, notwithstanding that this may not be possible, at least not without actually furnishing the skipper instance itself.
@Kojoley Please explain yourself with these comments. The illustrated code above shows you the exact opposite of that concern. In other words, specifically, the Skipper type is the SAME, furnished to my grammar, and I've tried with or without furnishing my own Skipper instance. Same "assertion" occurs.
For my part, I will check whether I am running against Boost 1.68
or 1.69
, considering the PR probably fixes the issue.
Your bug report is invalid.
There is no MCVE in it. The code snippets you have provided works for me https://wandbox.org/permlink/R3V31gHIQ6Te7lco. The PR #397 cannot be related to anything as it targeted a deprecation warning that came from a change in other Boost library (https://github.com/boostorg/predef/commit/32d4581c1689370444f2e565cfbb8421d5071807).
@Kojoley We need an example how to furnish a custom skipper type, say comment skipper, because when I replace qi::space_type
with my ProtoCommentSkipper<std::string::const_iterator>
I get this assertion/"error".
@Kojoley Is it a compiler difference? That "works" under GCC. It is breaking under MSVC.
It works for me on MSVC (VS 15.9.4).
@Kojoley Thank you for that. It's a head-scratcher to me. I spun up an academic test case locally as well. I even fleshed in the integer parser bits. That does "work", and in a variety of actual tests, with or without comments leading or trailing comments, same line, preceding line, etc. I need to investigate the other bits of my production code why that is not working. Unfortunately I do not have a "minimum" example for that; the code is the code, but I will give it some thought.
Just off the cuff, one thought is that some of the rules are using no skipper at all (default, space
?), whereas the head or start rules would use the comment skipper. Could that be the issue? Masked by the "default" to space
skipper? In which case, that is intentional; I would rather default to a true "default" or "none expected" or "unused" skipper if possible. Or does it matter? In other words, there is a reason why I do not want the skipper involved; the phrase ought not to involve anything skips. But to this end, I should use something like no_skip
or other Qi directives?
Thanks for any insights...
@Kojoley Okay, so preliminary thoughts, I should avoid parse
and instead focus on phrase_parse
, in which case I can provide the skipper instance. I will look into that further. Thanks!
There is no default skipper. The parse
function uses your grammar without a skipper (internally it passes unused_type
as a skipper to simplify implementation). The phrase_parse
function expects a skipper to be provided as a fourth argument, you cannot omit it. If you are using grammar
/rule
s with phrase_parse
, they must be instantiated without skipper type (again, internally it will be unused_type
) or with a skipper type that the passed skipper (fourth argument to phrase_parse
) must be convertible to.
If you need a skipper, but you do not want to use phrase_parse
and/or instantiate outer rule
/grammar
with a skipper type, you can use skip
directive.
But be aware that foo(first, last, r, s)
is equal to parse(first, last, r)
template <template Iterator, template Skipper>
bool foo(Iterator& first, Iterator last, rule<Iterator> const& r, Skipper const& s)
{
return parse(first, last, skip(s)[r]);
}
In other words:
skip(s)[r]; // <-- this and
r; // <-- this are equal if `r` has no skipper type because
rule<Iterator> r; // that way it explicitly states as it does not need skipping
Ah, I think I see the problem in my code. I did actually have a rule in which I was defining it in terms of qi::skip(qi::space)[...] >> qi::eoi
, which I think was some of the conflict when I specified the Skipper type. Originally there was "agreement" with the space_type
, but when I changed the Skipper, then suddenly things broken down along the asserted lines. Makes sense.
I suggest to switch to X3. It does not have those limitations.
@Kojoley Re: X3, I appreciate that, but unless the MSVC limitations have been resolved, it's a non-starter at the moment. At least the last time I checked.
I am not sure what you are talking about, X3 test suit passes on VS2015U3+.
@Kojoley I do not recall the precise set of circumstances, but I think it had something to do with available C++14 or 17 support at the time.
I am getting these kinds of errors following some of the online examples, on version
Boost v1.68.0
:Such a skipper is not a complex issue, but something is not right, I think:
And in usage:
The only difference is that I sub in the
ProtoCommentSkipper
and I get the errors. Instead of:I am trying this:
Seems like a possible duplicate of Boost library spirit failed to build, however, do you happen to have a simple example of a comment parser? Using a Spirit Qi Confix, for instance?