Feeding new tokens to be processed from a "#pragma wave" directive

[caminant@…]

While processing a custom "#pragma wave" directive using a struct derived from context_policies::default_preprocessing_hooks like in this example :

	class EmptyPreprocessorHooks
			: public boost::wave::context_policies::default_preprocessing_hooks
	{
	public:

        template <typename ContextT, typename ContainerT>
        bool interpret_pragma(ContextT const &ctx, ContainerT &pending, 
            typename ContextT::token_type const &option, 
            ContainerT const &values, 
            typename ContextT::token_type const &pragma_token)
		{
			return true;
		}

	};

it is possible to feed tokens in the "pending" container, that are copied verbatim to the output. What I think it would be very interesting is that this tokens are not copied verbatim, but parsed and processed. For instance, you could add "#define" or "#include" directives and they would be processed normally. Right now they are just copied.

Thanks.

[Hartmut Kaiser]

Replying to caminant@gmail.com:

While processing a custom "#pragma wave" directive using a struct derived from context_policies::default_preprocessing_hooks like in this example :

[snipped example]

it is possible to feed tokens in the "pending" container, that are copied verbatim to the output. What I think it would be very interesting is that this tokens are not copied verbatim, but parsed and processed. For instance, you could add "#define" or "#include" directives and they would be processed normally. Right now they are just copied.

It's currently implemented the way it is to conform with the #define preprocessor directive for which it is undefined behaviour to generate a token sequence comprising in another preprocessor directive.

Do you have a real use case for this functionality or is it just a 'nice to have' feature?

Regards Hartmut

[caminant@…]

Thanks for answering so quickly.

What we are trying to do, is to define "macros" that allow to compile a certain piece of code in a very customisable way. These "macros" define several options which are later selected by a user and imply adding some #defines or including other files that can add more options. The piece of code is going to be big, and we don't want to have it in a monolithic file full of #ifdefs. We use a tool that reads the possible options of a piece of code (from our "macros") and allows the user to change them and recompile again, getting new options, and so on.

We cannot use preprocessor macros because of the limitation you mention. That's why we moved to wave and tried to use "#pragma wave". Right now we are doing our own parsing, combined with wave, but this implies some complicated code doing multiple passes. It would be really clean if we could use one single pass of wave.

I understand the decission of working like a preprocessor macro for the new tokens, it makes a lot of sense. But i also thought that, not being defined in the standard, it wouldn't be difficult to allow to insert tokens that would be preprocessed. Something like putting them in the "unput" container instead of the "pending", using the names in the wave source code.

j.

[Hartmut Kaiser]

Ok, I have been thinking for this for a while now and after looking at the code I realized that it isn't difficult to do the preprocessing inside the interpret_pragma hook. But while implementing this idea I stumbled over a couple of issues which had to be fixed before everything worked just fine.

To demonstrate how this can be done with only a couple lines of code I created a new example called 'preprocess_pragma_output', which does exactly what its name says: it takes the option token sequence from a #pragma directive, concatenates everything into a single string, preprocesses this string using the current context, and returns the generated token sequence to be inserted in the output.

Everything (the example and the fixes) are committed to the SVN(Head). Please give some feedback if this is really what you need. I'm going to close this ticket, please re-open it as needed.

Note to self: the Wave docs have to be updated, still.

Regards Hartmut

[caminant@…]

Thank you very much. This will work well for our case.