Hi, I see that there are some hooks for appending callbacks for certain situations in the preprocessing. I think this is great. But, I would like to know if it is possible for the user to know when the preprocessor is evaluating an preprocessor conditional, and to know what the condition is. And to fork the preprocessing to when the condition is met and when not. Thanks, -- Felipe Magno de Almeida
Felipe Magno de Almeida wrote:
I see that there are some hooks for appending callbacks for certain situations in the preprocessing. I think this is great. But, I would like to know if it is possible for the user to know when the preprocessor is evaluating an preprocessor conditional, and to know what the condition is.
There is the evaluated_conditional_expression() preprocessing hook getting called whenever a #if/#elif/#ifdef/#ifndef directive was encountered. This hook gets 2 parameters: the (non-expanded) evaluated expression and the outcome of this evaluation (true/false). Is that what you need?
And to fork the preprocessing to when the condition is met and when not.
Could you please elaborate on this? I'm not sure what you've meant here. Regards Hartmut
On 5/11/06, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
Felipe Magno de Almeida wrote:
I see that there are some hooks for appending callbacks for certain situations in the preprocessing. I think this is great. But, I would like to know if it is possible for the user to know when the preprocessor is evaluating an preprocessor conditional, and to know what the condition is.
There is the evaluated_conditional_expression() preprocessing hook getting called whenever a #if/#elif/#ifdef/#ifndef directive was encountered. This hook gets 2 parameters: the (non-expanded) evaluated expression and the outcome of this evaluation (true/false).
Yes, exactly what I need. Have I missed it from the documentation?
Is that what you need?
And to fork the preprocessing to when the condition is met and when not.
Could you please elaborate on this? I'm not sure what you've meant here.
I would like to continue preprocessing the file but with two different contexts, one with the evaluation being false and another being true.
Regards Hartmut
Thank you, -- Felipe Magno de Almeida
Felipe Magno de Almeida wrote:
On 5/11/06, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
Felipe Magno de Almeida wrote:
And to fork the preprocessing to when the condition is met and when not. Could you please elaborate on this? I'm not sure what you've meant here.
I would like to continue preprocessing the file but with two different contexts, one with the evaluation being false and another being true.
I guess that would imply to modify the preprocessor's internal state, i.e. causing it to look as if the condition that was actually false had been true. Everything else would potentially lead to inconsistent or undefined behavior. Regards, Stefan
On 5/11/06, Stefan Seefeld <seefeld@sympatico.ca> wrote: [snipped]
I guess that would imply to modify the preprocessor's internal state, i.e. causing it to look as if the condition that was actually false had been true. Everything else would potentially lead to inconsistent or undefined behavior.
I think I could keep the last context and define/undefine whatever is needed to make the evaluation true. Then preprocess the two contexts. Shouldnt that do it?
Regards, Stefan
best regards, -- Felipe Magno de Almeida
Felipe Magno de Almeida wrote:
I guess that would imply to modify the preprocessor's internal state, i.e. causing it to look as if the condition that was actually false had been true. Everything else would potentially lead to inconsistent or undefined behavior.
I think I could keep the last context and define/undefine whatever is needed to make the evaluation true. Then preprocess the two contexts. Shouldnt that do it?
We had a similar discussion already. This involves some kind of re-evaluation of some of the input sequence after changing the internal state of the preprocessor. Wave currently does not support this. Wouldn't this involve making copies of the internal state essentially after every token (or at least before every pp operation), just to ensure it can be restarted at arbitrary points? I'm sure its impossible to make sure not to run into inconsistencies when trying to implement such a scheme (even putting aside the possible performance implications of making state copies). Regards Hartmut
On 5/11/06, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote: [snipped]
We had a similar discussion already. This involves some kind of re-evaluation of some of the input sequence after changing the internal state of the preprocessor. Wave currently does not support this.
I see, this is really bad then...
Wouldn't this involve making copies of the internal state essentially after every token (or at least before every pp operation), just to ensure it can be restarted at arbitrary points?
Yes, I think it would be needed. But, it should be faster than reprocess everything from the beginning if it spans to many options.
I'm sure its impossible to make sure not to run into inconsistencies when trying to implement such a scheme (even putting aside the possible performance implications of making state copies).
Why? If I could be able to keep the symbols consistent, like not defining one that has already been used or something similar it shouldnt have any problem. I want to use wave to analyze the source, not to create a preprocessed output.
Regards Hartmut
Thanks, -- Felipe Magno de Almeida
Felipe Magno de Almeida wrote:
I'm sure its impossible to make sure not to run into inconsistencies when trying to implement such a scheme (even putting aside the possible performance implications of making state copies).
Why? If I could be able to keep the symbols consistent, like not defining one that has already been used or something similar it shouldnt have any problem. I want to use wave to analyze the source, not to create a preprocessed output.
I'll have to think about this more thoroughly. Please give me some time before I'll get back to you, ok? Regards Hartmut
On 5/11/06, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
[snipped]
We had a similar discussion already. This involves some kind of re-evaluation of some of the input sequence after changing the internal state of the preprocessor. Wave currently does not support this.
Is it hard to make wave support this? I was thinking that with some guarantees from wave, wrt side-effects in the context, it could be really useful. The guarantees that I think would be needed are rollback-semantics in face of exceptions and no side-effects *before* callbacks are called. This would allow for backup of the context only if needed. Depending on how much work would be necessary I could work on it too for my SoC proposal, since it would easy a lot my work on the features I would implement. [snipped] Thanks, -- Felipe Magno de Almeida
Felipe Magno de Almeida wrote:
We had a similar discussion already. This involves some kind of re-evaluation of some of the input sequence after changing the internal state of the preprocessor. Wave currently does not support this.
Is it hard to make wave support this? I was thinking that with some guarantees from wave, wrt side-effects in the context, it could be really useful. The guarantees that I think would be needed are rollback-semantics in face of exceptions and no side-effects *before* callbacks are called. This would allow for backup of the context only if needed. Depending on how much work would be necessary I could work on it too for my SoC proposal, since it would easy a lot my work on the features I would implement.
In fact, it was easy to implement for this particular case. The 'evaluated_conditional_expression()' preprocessing hook now has a bool return value, which forces Wave to re-evaluate the expression as long as it is 'true'. The new prototype will be: template <typename ContextT, typename ContainerT> bool evaluated_conditional_expression(ContextT const &ctx, ContainerT const& expression, bool expression_value) { return false; } // ok to continue, do not re-evaluate expression Wave guarantees to keep the own state unchanged during this, which means you can save the context state, change a macro definition and return true to force the expression to be re-evaluated. This scheme should ensure a consistent behaviour. I'll check these changes into the CVS as soon as it will be up again. It won't be part of the Boost 1.34.0 release, though. Regards Hartmut
[snipped]
Thanks, -- Felipe Magno de Almeida _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Felipe Magno de Almeida wrote:
I see that there are some hooks for appending callbacks for certain situations in the preprocessing. I think this is great. But, I would like to know if it is possible for the user to know when the preprocessor is evaluating an preprocessor conditional, and to know what the condition is.
There is the evaluated_conditional_expression() preprocessing hook getting called whenever a #if/#elif/#ifdef/#ifndef directive was encountered. This hook gets 2 parameters: the (non-expanded) evaluated expression and the outcome of this evaluation (true/false).
Yes, exactly what I need. Have I missed it from the documentation?
It has been added to Wave after the 1.33.1 release only. You can find the description here: http://tinyurl.com/pkz3o (http://boost-consulting.com/boost/libs/wave/doc/class_reference_ctxpolicy.h tml#evaluated_conditional_expression).
And to fork the preprocessing to when the condition is met and when not.
Could you please elaborate on this? I'm not sure what you've meant here.
I would like to continue preprocessing the file but with two different contexts, one with the evaluation being false and another being true.
Hmmm, I'm not sure how this may work. In this case you cannot 'fake' the result of the evaluation of the conditional expression and make Wave behave the way you like. So even if you fork a new process inside the pp hook, you won't be able to tell the new process to take the other condition branch. Even more, this may lead to unexpected behaviour, because you will have situations where you provoke contradictions wrt defined/undefined macros. Regards Hartmut
participants (3)
-
Felipe Magno de Almeida -
Hartmut Kaiser -
Stefan Seefeld