[preprocessor] Warning: Incoming

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[preprocessor] Warning: Incoming

Paul Mensonides
I'm about to commit a relatively significant changeset to the pp-lib.  
This is the result of work by Edward Diener and I to add limited variadic
support to the pp-lib.  Edward can comment in more detail regarding the
extent of those changes, but they do not add ground-up support.

However, there are significant changes to heavily used low-level
facilities such as BOOST_PP_TUPLE_ELEM (sometimes even complete
implementation replacements).  We have put in a great deal of effort to
avoid introducing new errors or warnings in either the building of the
Boost binaries or in the regression tests.  However, we may have missed
some issues.

Regards,
Paul Mensonides

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

lcaminiti
On Sun, Jun 26, 2011 at 9:02 AM, Paul Mensonides <[hidden email]> wrote:
> I'm about to commit a relatively significant changeset to the pp-lib.

Do these changes need to be peer-reviewed?

> This is the result of work by Edward Diener and I to add limited variadic
> support to the pp-lib.  Edward can comment in more detail regarding the
> extent of those changes, but they do not add ground-up support.

If the pp-lib needs to be changed, why not change it radically to add
ground-up variadic support? (This is not a rhetoric question. I am
sincerely asking as there might be very good reasons not to add
ground-up variadic support to Boost.Preprocessor.)

> However, there are significant changes to heavily used low-level
> facilities such as BOOST_PP_TUPLE_ELEM (sometimes even complete
> implementation replacements).  We have put in a great deal of effort to
> avoid introducing new errors or warnings in either the building of the
> Boost binaries or in the regression tests.  However, we may have missed
> some issues.

I use Boost.Preprocessor (PP_TUPLE_, etc) pervasively in the
implementation of a lot of macros in my projects. I also occasionally
use Edward's VMD library. I will haply test the Boost.Preprocessor
changes against my code.

--Lorenzo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Edward Diener-3
On 6/26/2011 10:57 AM, Lorenzo Caminiti wrote:
> On Sun, Jun 26, 2011 at 9:02 AM, Paul Mensonides<[hidden email]>  wrote:
>> I'm about to commit a relatively significant changeset to the pp-lib.
>
> Do these changes need to be peer-reviewed?

I will leave Paul to comment on this if he wishes.

>
>> This is the result of work by Edward Diener and I to add limited variadic
>> support to the pp-lib.  Edward can comment in more detail regarding the
>> extent of those changes, but they do not add ground-up support.
>
> If the pp-lib needs to be changed, why not change it radically to add
> ground-up variadic support? (This is not a rhetoric question. I am
> sincerely asking as there might be very good reasons not to add
> ground-up variadic support to Boost.Preprocessor.)

I am not sure what Paul meant by "ground-up" variadic support, nor how
you take it, but the variadic support in pp-lib is very much the same as
in my VMD library with a few added enhancements based on Paul's
knowledge of preprocessor programming. The overall intent in pp-lib was
the same as VMD: to integrate the use of variadic macros with pp-lib's
richer data types ( tuple, array, list, seq ) and to enhance the use of
pp-lib tuples with variadic macro support.

>
>> However, there are significant changes to heavily used low-level
>> facilities such as BOOST_PP_TUPLE_ELEM (sometimes even complete
>> implementation replacements).  We have put in a great deal of effort to
>> avoid introducing new errors or warnings in either the building of the
>> Boost binaries or in the regression tests.  However, we may have missed
>> some issues.
>
> I use Boost.Preprocessor (PP_TUPLE_, etc) pervasively in the
> implementation of a lot of macros in my projects. I also occasionally
> use Edward's VMD library. I will haply test the Boost.Preprocessor
> changes against my code.

That would be very welcome.

I added a section in the pp-lib documentation under "Topics" called
"variadic macros" which should help you.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Paul Mensonides
In reply to this post by lcaminiti
On Sun, 26 Jun 2011 10:57:55 -0400, Lorenzo Caminiti wrote:

> On Sun, Jun 26, 2011 at 9:02 AM, Paul Mensonides <[hidden email]>
> wrote:
>> I'm about to commit a relatively significant changeset to the pp-lib.
>
> Do these changes need to be peer-reviewed?

No, but feel free to comment.

>> This is the result of work by Edward Diener and I to add limited
>> variadic support to the pp-lib.  Edward can comment in more detail
>> regarding the extent of those changes, but they do not add ground-up
>> support.
>
> If the pp-lib needs to be changed, why not change it radically to add
> ground-up variadic support? (This is not a rhetoric question. I am
> sincerely asking as there might be very good reasons not to add
> ground-up variadic support to Boost.Preprocessor.)

The biggest reason not to do so would be compatibility.  A ground-up
reimplementation would entail significant interface breaking.  A
secondary reason is that there is a limit on what can be done while
having to support broken preprocessors, and that limit has the potential
to drastically undermine the benefits of doing so.  To be clear, I'm not
referring to having some support disabled for broken preprocessors.  
Rather, it would be having entirely different interfaces--just like Chaos
has entirely different interfaces, and, more importantly, an entirely
different methodology.

That aside, if broken preprocessors are taken off the table (i.e.
abandoning VC++ as a supported compiler or using a different preprocessor
front-end to it such as Wave), there is already a library (Chaos) that
was written from the ground up to support variadics that is released
under the same license that Boost uses (and created).  As an example,
everything that Edward and I have added to Boost.Preprocessor has already
existed in Chaos (in some form) for years.

Regards,
Paul Mensonides

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Paul Mensonides
In reply to this post by Edward Diener-3
On Sun, 26 Jun 2011 11:31:55 -0400, Edward Diener wrote:

> On 6/26/2011 10:57 AM, Lorenzo Caminiti wrote:

>> If the pp-lib needs to be changed, why not change it radically to add
>> ground-up variadic support? (This is not a rhetoric question. I am
>> sincerely asking as there might be very good reasons not to add
>> ground-up variadic support to Boost.Preprocessor.)
>
> I am not sure what Paul meant by "ground-up" variadic support, nor how
> you take it, but the variadic support in pp-lib is very much the same as
> in my VMD library with a few added enhancements based on Paul's
> knowledge of preprocessor programming. The overall intent in pp-lib was
> the same as VMD: to integrate the use of variadic macros with pp-lib's
> richer data types ( tuple, array, list, seq ) and to enhance the use of
> pp-lib tuples with variadic macro support.

This is a good summary of the changes.

What I meant by "ground-up" would be effectively re-implementing
Boost.Preprocessor from scratch with variadic macros and placemarkers in
mind.  For example, with decent preprocessors (something we don't have as
a rule), this would drastically reduce the number of use cases for
BOOST_PP_TUPLE_ELEM.  The use case I'm specifically thinking of at the
moment is the encoding and decoding of auxiliary data or state data
passed through algorithms provided by the library.  E.g.

#define ADD(x, y) WHILE(PRED, OP, (x, y))

#define PRED(d, state) \
    TUPLE_ELEM(2, 1, state) \
    /**/
#define OP(d, state) \
    (INC(TUPLE_ELEM(2, 0, state)), DEC(TUPLE_ELEM(2, 1, state))) \
    /**/

This one type of scenario decreases the efficiency and drastically
decreases the readability of the code because the TUPLE_ELEM (or similar)
clutter required in the implementation of both PRED and OP is either
pervasive or results in more macro definitions.

Ground-up support would imply that WHILE (and every other higher-order
macro in the library) allow variadic state such that the example becomes:

#define ADD(x, y) WHILE(PRED, OP, x, y)

#define PRED(d, x, y) y
#define OP(d, x, y) INC(x), DEC(y)

The amount of clutter, even in this trivial example, is significantly
reduced resulting in smaller, more efficient, and more readable code.

However, even doing this requires breaking interfaces because existing
arguments are in the wrong orders in many places.  For example,
SEQ_FOLD_LEFT's interface is SEQ_FOLD_LEFT(op, state, seq) where op's
interface must be op(s, state, elem).  This would need to be SEQ_FOLD_LEFT
(op, (a1, a2, ...)(b1, b2, ...), s1, s2, ...) where op's interface must
"compatible" with op(s, e1, e2, ..., s1, s2, ...).  In this case, that's
variadic accumulation state (i.e. fold state) together with potentially n-
ary sequence data (in this case, not variadic sequence data such as (1)
(1, 2)(1, 2, 3), but sequence data that is unary (1)(1)(1), binary (1, 2)
(1, 2)(1, 2), or whatever so long as each element has the same "arity").

All of that aside, there is no way to generalize recursion on broken
compilers--particularly popular ones such as VC++.  The lack of this
leads to an implementation explosion.  Every reentrant algorithm in
Boost.Preprocessor is implemented with a huge set of macros.  Often
times, they are implemented with multiple huge sets of macros which are
different in that they contain differing workarounds for various
compilers.  Furthermore, many other higher-order algorithms are not
reentrant because they are not implemented that way (and are instead
implemented in terms of the ones which are).  This inherently leads to
implementation bubbling which is particularly costly with the
preprocessor since there is no direct recursion and because the resulting
error messages can be as bad as template-related error messages.

With decent preprocessors, on the other hand, recursion is both
generalizable and extensible.  For example, all higher-order algorithms
in Chaos are reentrant and none of them are implemented via huge sets of
algorithm-specific macros.  At the end of the day, the lack of
generalizable recursion is even more fundamental and cripples
Boost.Preprocessor even more than lack of ground-up support for variadic
macros.  I consider the entire methodology of Boost.Preprocessor to be
garbage due to widespread, aspectual workarounds.  Because of the above,
I have no incentive to put major effort into minor improvements
particularly when some vendor is too lazy to fix their preprocessor
(which is a minor implementation in comparison to the underlying compiler
and optimizer) or has too much of a "the standard is whatever we say it
is" mentality.

Regards,
Paul Mensonides

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Olaf van der Spek-3
In reply to this post by Paul Mensonides
On Mon, Jun 27, 2011 at 1:13 AM, Paul Mensonides <[hidden email]> wrote:
> That aside, if broken preprocessors are taken off the table (i.e.
> abandoning VC++ as a supported compiler or using a different

Is this true for all versions?
If so, is there a MS connect issue we could vote on for a better preprocessor?

Olaf
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Mathias Gaunard-2
On 06/27/2011 11:48 AM, Olaf van der Spek wrote:
> On Mon, Jun 27, 2011 at 1:13 AM, Paul Mensonides<[hidden email]>  wrote:
>> That aside, if broken preprocessors are taken off the table (i.e.
>> abandoning VC++ as a supported compiler or using a different
>
> Is this true for all versions?

Yes.

Its variadic macro support is completely broken, but interestingly
enough it is still possible to do a few things with it if you're willing
to put MSVC-specific hacks everywhere.



> If so, is there a MS connect issue we could vote on for a better preprocessor?

The main bug appears to be present three times in the database, twice as
won't fix, and one that appeared just last month.

http://connect.microsoft.com/VisualStudio/feedback/details/380090/variadic-macro-replacement

http://connect.microsoft.com/VisualStudio/feedback/details/521844/variadic-macro-treating-va-args-as-a-single-parameter-for-other-macros

http://connect.microsoft.com/VisualStudio/feedback/details/676585/bug-in-cl-c-compiler-in-correct-expansion-of-va-args

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Paul Mensonides
On Mon, 27 Jun 2011 12:21:28 +0200, Mathias Gaunard wrote:

> On 06/27/2011 11:48 AM, Olaf van der Spek wrote:
>> On Mon, Jun 27, 2011 at 1:13 AM, Paul Mensonides<[hidden email]>
>> wrote:
>>> That aside, if broken preprocessors are taken off the table (i.e.
>>> abandoning VC++ as a supported compiler or using a different
>>
>> Is this true for all versions?
>
> Yes.
>
> Its variadic macro support is completely broken, but interestingly
> enough it is still possible to do a few things with it if you're willing
> to put MSVC-specific hacks everywhere.

It's far deeper than that.  Their entire macro replacement mechanism is
fundamentally broken.  However, MS's consistent response has been "won't
fix."  My response to that is "won't support."

Regards,
Paul Mensonides

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

lcaminiti
In reply to this post by Paul Mensonides
Paul Mensonides wrote
On Sun, 26 Jun 2011 11:31:55 -0400, Edward Diener wrote:

> On 6/26/2011 10:57 AM, Lorenzo Caminiti wrote:

>> If the pp-lib needs to be changed, why not change it radically to add
>> ground-up variadic support? (This is not a rhetoric question. I am
>> sincerely asking as there might be very good reasons not to add
>> ground-up variadic support to Boost.Preprocessor.)
>
> I am not sure what Paul meant by "ground-up" variadic support, nor how
> you take it, but the variadic support in pp-lib is very much the same as
> in my VMD library with a few added enhancements based on Paul's
> knowledge of preprocessor programming. The overall intent in pp-lib was
> the same as VMD: to integrate the use of variadic macros with pp-lib's
> richer data types ( tuple, array, list, seq ) and to enhance the use of
> pp-lib tuples with variadic macro support.

This is a good summary of the changes.

What I meant by "ground-up" would be effectively re-implementing
Boost.Preprocessor from scratch with variadic macros and placemarkers in
mind.  For example, with decent preprocessors (something we don't have as
a rule), this would drastically reduce the number of use cases for
BOOST_PP_TUPLE_ELEM.  The use case I'm specifically thinking of at the
moment is the encoding and decoding of auxiliary data or state data
passed through algorithms provided by the library.  E.g.

#define ADD(x, y) WHILE(PRED, OP, (x, y))

#define PRED(d, state) \
    TUPLE_ELEM(2, 1, state) \
    /**/
#define OP(d, state) \
    (INC(TUPLE_ELEM(2, 0, state)), DEC(TUPLE_ELEM(2, 1, state))) \
    /**/

This one type of scenario decreases the efficiency and drastically
decreases the readability of the code because the TUPLE_ELEM (or similar)
clutter required in the implementation of both PRED and OP is either
pervasive or results in more macro definitions.

Ground-up support would imply that WHILE (and every other higher-order
macro in the library) allow variadic state such that the example becomes:

#define ADD(x, y) WHILE(PRED, OP, x, y)

#define PRED(d, x, y) y
#define OP(d, x, y) INC(x), DEC(y)

The amount of clutter, even in this trivial example, is significantly
reduced resulting in smaller, more efficient, and more readable code.

However, even doing this requires breaking interfaces because existing
arguments are in the wrong orders in many places.  For example,
SEQ_FOLD_LEFT's interface is SEQ_FOLD_LEFT(op, state, seq) where op's
interface must be op(s, state, elem).  This would need to be SEQ_FOLD_LEFT
(op, (a1, a2, ...)(b1, b2, ...), s1, s2, ...) where op's interface must
"compatible" with op(s, e1, e2, ..., s1, s2, ...).  In this case, that's
variadic accumulation state (i.e. fold state) together with potentially n-
ary sequence data (in this case, not variadic sequence data such as (1)
(1, 2)(1, 2, 3), but sequence data that is unary (1)(1)(1), binary (1, 2)
(1, 2)(1, 2), or whatever so long as each element has the same "arity").
Yes, I remember we discussed this before when we first discussed the VMD library. As a user of Boost.Preprocessor, I agree 100% that spending the variadic argument on "data", "state", etc will incredibly simplify my pp code. However, even without that, variadic support similar to the one added by VMD is very useful. Therefore, I am looking forward to the Boost.Preprocessor variadic changes you have made (even if they don't provide "ground-up" variadic support and I'll have to continue to use PP_TUPLE_ELEM in the algorithms everywhere).

All of that aside, there is no way to generalize recursion on broken
compilers--particularly popular ones such as VC++.  The lack of this
leads to an implementation explosion.  Every reentrant algorithm in
Boost.Preprocessor is implemented with a huge set of macros.  Often
times, they are implemented with multiple huge sets of macros which are
different in that they contain differing workarounds for various
compilers.  Furthermore, many other higher-order algorithms are not
reentrant because they are not implemented that way (and are instead
implemented in terms of the ones which are).  This inherently leads to
implementation bubbling which is particularly costly with the
preprocessor since there is no direct recursion and because the resulting
error messages can be as bad as template-related error messages.

With decent preprocessors, on the other hand, recursion is both
generalizable and extensible.  For example, all higher-order algorithms
in Chaos are reentrant and none of them are implemented via huge sets of
algorithm-specific macros.  At the end of the day, the lack of
generalizable recursion is even more fundamental and cripples
Boost.Preprocessor even more than lack of ground-up support for variadic
macros.  I consider the entire methodology of Boost.Preprocessor to be
garbage due to widespread, aspectual workarounds.  Because of the above,
I have no incentive to put major effort into minor improvements
particularly when some vendor is too lazy to fix their preprocessor
(which is a minor implementation in comparison to the underlying compiler
and optimizer) or has too much of a "the standard is whatever we say it
is" mentality.
I understand that MVSC pp is broken and I share the pain of writing endless workarounds for that pp (especially to ensure proper macro expansions). I have take a good look look to Boost.Preprocessor implementation and I understand well the amount of work that went in it to support broken pp... At the end of the day, I need my code to also compile on MVSC so I'm "stock" with it whether a I like it or not :(

Thanks a lot!
--Lorenzo
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Mathias Gaunard-2
In reply to this post by Paul Mensonides
On 06/26/2011 03:02 PM, Paul Mensonides wrote:
> I'm about to commit a relatively significant changeset to the pp-lib.
> This is the result of work by Edward Diener and I to add limited variadic
> support to the pp-lib.  Edward can comment in more detail regarding the
> extent of those changes, but they do not add ground-up support.

What are the new features?
Is it only new functions or are there also some fixes like allowing
(a)(b, c)(d) to be a valid sequence?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Edward Diener-3
In reply to this post by Mathias Gaunard-2
On 6/27/2011 6:21 AM, Mathias Gaunard wrote:

> On 06/27/2011 11:48 AM, Olaf van der Spek wrote:
>> On Mon, Jun 27, 2011 at 1:13 AM, Paul Mensonides<[hidden email]>
>> wrote:
>>> That aside, if broken preprocessors are taken off the table (i.e.
>>> abandoning VC++ as a supported compiler or using a different
>>
>> Is this true for all versions?
>
> Yes.
>
> Its variadic macro support is completely broken, but interestingly
> enough it is still possible to do a few things with it if you're willing
> to put MSVC-specific hacks everywhere.

Paul has gone out of his way to support the VC++ preprocessor in pp-lib,
even though it is broken in many respects, with many hacks. I also had
to find a hack to get VC++ to work with variadic macros in my VMD
library, and the work I did with Paul to get variadic macros into pp-lib
also needed various hacks for VC++. I write this because I want to
emphasize that the updated pp-lib with variadic macro support does work
with VC++, despite it being difficult to force the VC++ preprocessor to
expand both variadic and non-variadic macros in a timely and correct
manner in quite a number of cases.

So while I share Paul's frustration at working with the VC++
preprocessor, and Microsoft's unwillingness to ever fix it ( they are
probably afraid that actually fixing their preprocessor will break
end-user's code which inadvertently relies on their buggy code ), I
pushed very hard to have the functionality from my VMD library added to
pp-lib and still support VC++. At the same time I totally understand
that to write a really great preprocessor library, as Paul has done with
Chaos, one needs to abandon support for broken preprocessors such as
VC++ and work only with preprocessor which implement the C++ standard.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Edward Diener-3
In reply to this post by Mathias Gaunard-2
On 6/27/2011 9:16 AM, Mathias Gaunard wrote:
> On 06/26/2011 03:02 PM, Paul Mensonides wrote:
>> I'm about to commit a relatively significant changeset to the pp-lib.
>> This is the result of work by Edward Diener and I to add limited variadic
>> support to the pp-lib. Edward can comment in more detail regarding the
>> extent of those changes, but they do not add ground-up support.
>
> What are the new features?
> Is it only new functions or are there also some fixes like allowing
> (a)(b, c)(d) to be a valid sequence?

The new features are adding variadic macro support. No other fixes are
provided. Look at 'variadic macros' under the Topics heading for what
has been done. I believe I give a pretty good general explanation there.
Of couurse the individual variadic macro support is documented under the
Reference and Headers.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Mathias Gaunard-2
On 06/27/2011 04:01 PM, Edward Diener wrote:

> On 6/27/2011 9:16 AM, Mathias Gaunard wrote:
>> On 06/26/2011 03:02 PM, Paul Mensonides wrote:
>>> I'm about to commit a relatively significant changeset to the pp-lib.
>>> This is the result of work by Edward Diener and I to add limited
>>> variadic
>>> support to the pp-lib. Edward can comment in more detail regarding the
>>> extent of those changes, but they do not add ground-up support.
>>
>> What are the new features?
>> Is it only new functions or are there also some fixes like allowing
>> (a)(b, c)(d) to be a valid sequence?
>
> The new features are adding variadic macro support. No other fixes are
> provided. Look at 'variadic macros' under the Topics heading for what
> has been done. I believe I give a pretty good general explanation there.
> Of couurse the individual variadic macro support is documented under the
> Reference and Headers.

Ok, so there are a few new tuple "overloads" and a new "variadic" type
which is essentially a tuple without the parentheses.

May I suggest the addition of a macro that strips parentheses but only
if they are present?
I have found this to be very useful for passing arguments that contain
commas easily.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Edward Diener-3
On 6/27/2011 12:29 PM, Mathias Gaunard wrote:

> On 06/27/2011 04:01 PM, Edward Diener wrote:
>> On 6/27/2011 9:16 AM, Mathias Gaunard wrote:
>>> On 06/26/2011 03:02 PM, Paul Mensonides wrote:
>>>> I'm about to commit a relatively significant changeset to the pp-lib.
>>>> This is the result of work by Edward Diener and I to add limited
>>>> variadic
>>>> support to the pp-lib. Edward can comment in more detail regarding the
>>>> extent of those changes, but they do not add ground-up support.
>>>
>>> What are the new features?
>>> Is it only new functions or are there also some fixes like allowing
>>> (a)(b, c)(d) to be a valid sequence?
>>
>> The new features are adding variadic macro support. No other fixes are
>> provided. Look at 'variadic macros' under the Topics heading for what
>> has been done. I believe I give a pretty good general explanation there.
>> Of couurse the individual variadic macro support is documented under the
>> Reference and Headers.
>
> Ok, so there are a few new tuple "overloads" and a new "variadic" type
> which is essentially a tuple without the parentheses.
>
> May I suggest the addition of a macro that strips parentheses but only
> if they are present?

I do not think this is possible. But I am out of the loop regarding
pp-lib additions and Paul would really know if this could be done.

> I have found this to be very useful for passing arguments that contain
> commas easily.

Can you give an example of what you are trying to do ?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Mathias Gaunard-2
On 06/27/2011 10:37 PM, Edward Diener wrote:

>> May I suggest the addition of a macro that strips parentheses but only
>> if they are present?
>
> I do not think this is possible. But I am out of the loop regarding
> pp-lib additions and Paul would really know if this could be done.

Code to do this was already given on the Boost ML by Steven Watanabe:
<http://article.gmane.org/gmane.comp.lib.boost.user/61011>

I've already been using this for a year in my code, and it works fine.

There is one little caveat with the above code, it's not strictly
conforming to C99/C++0x so it doesn't work with Wave.
Replacing
(__VA_ARGS__, 2, 1)
by
(__VA_ARGS__, 2, 1, 0)

fixes the problem.



>
>> I have found this to be very useful for passing arguments that contain
>> commas easily.
>
> Can you give an example of what you are trying to do ?

Consider something like

BOOST_FOREACH(std::pair<A, B> a, mymap)

this fails because the preprocessor sees it as three arguments.

Assuming BOOST_FOREACH was using STRIP_PARENS on its arguments, you could do

BOOST_FOREACH((std::pair<A, B> a), mymap)

in the cases where it is necessary.

This is actually pretty much a requirement when you want to write macros
that take template with multiple parameters as arguments.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Stephan T. Lavavej-2
In reply to this post by Mathias Gaunard-2
[Mathias Gaunard]
> The main bug appears to be present three times in the database, twice as
> won't fix, and one that appeared just last month.
> http://connect.microsoft.com/VisualStudio/feedback/details/380090/variadic-macro-replacement
> http://connect.microsoft.com/VisualStudio/feedback/details/521844/variadic-macro-treating-va-args-as-a-single-parameter-for-other-macros
> http://connect.microsoft.com/VisualStudio/feedback/details/676585/bug-in-cl-c-compiler-in-correct-expansion-of-va-args

I've passed these comments to our compiler front-end team, and they're going to take another look at fixing these bugs. They can't promise anything, but they'll try.

Thanks,
Stephan T. Lavavej
Visual C++ Libraries Developer
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Edward Diener-3
In reply to this post by Mathias Gaunard-2
On 6/27/2011 5:25 PM, Mathias Gaunard wrote:

> On 06/27/2011 10:37 PM, Edward Diener wrote:
>
>>> May I suggest the addition of a macro that strips parentheses but only
>>> if they are present?
>>
>> I do not think this is possible. But I am out of the loop regarding
>> pp-lib additions and Paul would really know if this could be done.
>
> Code to do this was already given on the Boost ML by Steven Watanabe:
> <http://article.gmane.org/gmane.comp.lib.boost.user/61011>

You are right and Steve came up with his technique in answering my own
question.

>
> I've already been using this for a year in my code, and it works fine.
>
> There is one little caveat with the above code, it's not strictly
> conforming to C99/C++0x so it doesn't work with Wave.
> Replacing
> (__VA_ARGS__, 2, 1)
> by
> (__VA_ARGS__, 2, 1, 0)
>
> fixes the problem.
>
>
>
>>
>>> I have found this to be very useful for passing arguments that contain
>>> commas easily.
>>
>> Can you give an example of what you are trying to do ?
>
> Consider something like
>
> BOOST_FOREACH(std::pair<A, B> a, mymap)
>
> this fails because the preprocessor sees it as three arguments.
>
> Assuming BOOST_FOREACH was using STRIP_PARENS on its arguments, you
> could do
>
> BOOST_FOREACH((std::pair<A, B> a), mymap)
>
> in the cases where it is necessary.
>
> This is actually pretty much a requirement when you want to write macros
> that take template with multiple parameters as arguments.

Tt is a good example.

This has led me to work on some macros for pp-lib, which uses variadics,
which can tell whether a macro parameter is a tuple, array, seq, or list.

Then in your case you can go:

#define STRIP_PARENS(x)\
BOOST_PP_IIF(BOOSTPP_IS_TUPLE(x),BOOST_PP_TUPLE_ENUM(x),x)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Jeffrey Lee Hellrung, Jr.-2
On Mon, Jun 27, 2011 at 4:21 PM, Edward Diener <[hidden email]>wrote:
[...]

> This has led me to work on some macros for pp-lib, which uses variadics,
> which can tell whether a macro parameter is a tuple, array, seq, or list.
>
> Then in your case you can go:
>
> #define STRIP_PARENS(x)\
> BOOST_PP_IIF(BOOSTPP_IS_TUPLE(x),BOOST_PP_TUPLE_ENUM(x),x)
>

I'm not a preprocessing expert, so I would be afraid of the preprocessor
trying to expand BOOST_PP_TUPLE_ENUM(x) when x is not a tuple.  If so, I
would think something like

#define STRIP_PARENS( x ) BOOST_PP_IIF( BOOST_PP_IS_TUPLE( x ),
BOOST_PP_TUPLE_ENUM, BOOST_PP_IDENTITY ) ( x )

would be better...?

- Jeff
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Edward Diener-3
On 6/27/2011 8:31 PM, Jeffrey Lee Hellrung, Jr. wrote:

> On Mon, Jun 27, 2011 at 4:21 PM, Edward Diener<[hidden email]>wrote:
> [...]
>
>> This has led me to work on some macros for pp-lib, which uses variadics,
>> which can tell whether a macro parameter is a tuple, array, seq, or list.
>>
>> Then in your case you can go:
>>
>> #define STRIP_PARENS(x)\
>> BOOST_PP_IIF(BOOSTPP_IS_TUPLE(x),BOOST_PP_TUPLE_ENUM(x),x)
>>
>
> I'm not a preprocessing expert, so I would be afraid of the preprocessor
> trying to expand BOOST_PP_TUPLE_ENUM(x) when x is not a tuple.  If so, I
> would think something like
>
> #define STRIP_PARENS( x ) BOOST_PP_IIF( BOOST_PP_IS_TUPLE( x ),
> BOOST_PP_TUPLE_ENUM, BOOST_PP_IDENTITY ) ( x )
>
> would be better...?

You are right. Good catch !

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [preprocessor] Warning: Incoming

Paul Mensonides
In reply to this post by Mathias Gaunard-2
On Mon, 27 Jun 2011 23:25:15 +0200, Mathias Gaunard wrote:

> Consider something like
>
> BOOST_FOREACH(std::pair<A, B> a, mymap)
>
> this fails because the preprocessor sees it as three arguments.
>
> Assuming BOOST_FOREACH was using STRIP_PARENS on its arguments, you
> could do

Chaos has a macro that does this called CHAOS_PP_DECODE (and a
corresponding CHAOS_PP_ENCODE which is provided for symmetry).

However, assuming BOOST_FOREACH doesn't use it, you can still do it...

  // 1.cpp
  #include <boost/foreach.hpp>

  #include <chaos/preprocessor/facilities/type.h>
  #include <chaos/preprocessor/recursion/rail.h>

  CHAOS_PP_WALL(
      BOOST_FOREACH(
          CHAOS_PP_TYPE(std::pair<A, B> a),
          mymap
      )
  ) { /* ... */ }

g++ -E -P -std=gnu++0x -I $BOOST_ROOT -I $CHAOS_ROOT -D
CHAOS_PP_VARIADICS 1.cpp

...or, cleaned up...

  // 2.cpp
  #include <boost/foreach.hpp>

  #include <chaos/preprocessor/facilities/encode.h>
  #include <chaos/preprocessor/facilities/type.h>
  #include <chaos/preprocessor/recursion/rail.h>

  #define FOREACH(d, c) \
      CHAOS_PP_WALL(BOOST_FOREACH( \
          CHAOS_PP_TYPE(CHAOS_PP_DECODE(d)), \
          c \
      )) \
      /**/

  FOREACH((std::pair<A, B> a), mymap) { /* ... */ }

g++ -E -P -std=gnu++0x -I $BOOST_ROOT -I $CHAOS_ROOT -D
CHAOS_PP_VARIADICS 2.cpp

How's that for black magic?

Chaos calls this sort of thing a "rail" (in the railgun sense) because it
sends nearly arbitrary stuff through any amount of macro machinery and
expands it (and any number of copies of it) after it comes out the other
side regardless of where it appears in the output.

Regards,
Paul Mensonides

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123