inheriting from disable_action and discard_input together

[Shaheen47]

Hello,
I want to have many types of parsers in my application(File, String, Stream).
In order to implement the Stream parser correctly, I created an action that inherits from discard_input. but I don't need this action to be enabled when I am using another parser than the stream parser. Therefore, I also made that action inherit from disable_action so it will be disabled by default.

    template<>
    struct action<TurtlePegtlGrammer::statement>: tao::pegtl::disable_action,tao::pegtl::discard_input {
        template<typename Input,typename Queue>
        static void apply(const Input &in, TurtlePegtlStates::State<Queue> &state) {
            std::cout << "test";
        }
    };

and when I am using the Stream parser I enable it in the parse function.

parse<seq<Grammer,enable<TurtlePegtlGrammer::statement>>, TurtlePegtlActions::action>(istream_input(stream, maximum_buffer_size, filename), state);

What happens is that even when I am using the File parser which has the following parse function :

parse<Grammer,TurtlePegtlActions::action>(file, state);

The action is not disabled.
it looks the disable_action has no effect when it is used with discard_input.
What should I do in this case?

Thanks very much in advance.

[ColinH]

The short answer I can give now is that you can safely call discard() on an input that doesn't need it. It's designed as an empty function call that will be discarded (no pun intended) by the compiler.

[ColinH]

@d-frey We should check whether the interaction between the two base classes is what we expect it to be, possibly change the behaviour, and probably extend the documentation somehow...

[d-frey]

I think there are multiple points of confusion here:

1. You don't need to avoid calling in.discard() for non-stream inputs (as Colin mentioned). It is an empty method that gets optimized away completely, there is no overhead, so don't be afraid to make our life easy.
2. If you derive from disable_action and you provide your own apply(), the latter overwrites the former's apply()-method, hence disable_action::apply() is not used and the actions do not get disabled.
3. Using discard_input as a base class is based on match, not based on apply - hence it will not be affected by disabling actions.
4. If you plan on writing your own grammar, you can use the discard rule instead of using action class specializations with discard_input. This is mostly a question of style, so pick what you like best.

Let us know if you have further questions.

@ColinH Not sure which of these information you'd like to see in the documentation...

[ColinH]

@d-frey Now that you've put it so clearly I'd say 2 and 4 should be self-understood, 1 and 3 should be mentioned somehow and somewhere (in case they aren't yet). Agree?

[Shaheen47]

@ColinH @d-frey Thanks very much for your help.