Subject: Re: [boost] Review Request: Variadic Macro Data library
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-02-20 11:52:20
On 2/20/2011 10:43 AM, Paul Mensonides wrote:
> On Sun, 20 Feb 2011 09:55:14 -0500, Daniel Larimer wrote:
>
>> I think that you have identified a very good use for the variadic
>> argument, but I am not sure that it completely conflicts with the ideas
>> present in the VMD library. So unless providing utilities to convert
>> from VA_ARGS -> SEQ, LIST, Array, etc somehow prevents you from
>> expanding the FOR_EACH macro like you described, I would tend to favor
>> an incremental approach. Don't hold up useful functionality because
>> there is more useful functionality you could add.
>>
>> Reworking the whole of the PP library with VA support sounds like it
>> would significantly delay the adoption of some very useful tools.
>
> I don't have a problem with the particular macros. I do have a concern
> about establishing practices which I don't consider to be terribly good
> practices.
>
> I'd really like to see a use case that is different from what I'm
> envisioning. What I'm envisioning is something like:
>
> #define ALGORITHM_B(...) \
> ALGORITHM_A(DATA_TO_SEQ(__VA_ARGS__)) \
> /**/
>
> ALGORITHM_B(a, b, c)
>
> I don't find that use case compelling, and that point of view is based on
> heavy experience utilizing variadics. When I was initially writing chaos-
> pp, I went down this path, but ultimately rejected it. It simply doesn't
> scale and results in other intrastructure that doesn't scale.
I could not agree more that it does not scale well for general use, and
I understand that it is not the way you would want to extend the pp-lib
to use variadic macros internally.
But consider just the case where an end-user is doing some pp
programming for their own use, and the use of other end-user programmers
using their library, which may have nothing to do with pp programming
itself. They want to present a macro interface which uses variadic
macros rather than, let's say, Boost PP sequences. They are doing this
just to make their interface look easier to use, ie.
SOME_MACRO(a,b,c,d,etc.) rather than SOME_MACRO((a),(b),(c),(d),etc.).
In that case creating some internal macro like ALGORITHM_B ( which is of
course a highly simplified version of using variadic macro data
internally ) above is purely a matter of their own convenience. It's not
meant to be part of some highly reusable code but just for their own
specific purposes. In that situation I see nothing wrong with it on a
technical basis. That it does not scale well in the sense that it is
integrated into a whole system of uses of variadic macros I can see. But
its only purpose is to get away from using variadic macros and to use a
pp-lib data structure instead, while still presenting an external
interface to the end user which uses variadic macros.
I myself have done this in my TTI lib. I allow an alternative macro for
some functionality which uses a variadic macro, and I take the data and
pass it on internally to inner processing which uses a pp-lib data type.
I am not trying to do internal pp programming with variadic macro data,
as the pp-lib data type is much richer in functionality. Even in cases
where I might internally use variadic macro syntax for my own library I
would not attempt to do anything with the data that is in any way
complicated, but just use it as a syntax convenience for myself. But
even in that case I find it has little to offer and pp-lib data types,
once one is comfortable using them and their syntax, is much better.
Wanting to present variadic macro syntax as a service for end-user
programmers was the main motivation for my VMD library. I believe others
have also found the using of variadic macros as an end-user macro
interface also useful.
>
> To attempt to clarify, something like
>
> ALGORITHM_A(DATA_TO_SEQ(a, b, c))
>
> is not really a problem, but the existence of the ALGORITHM_B definition
> (as a non-local construct) *is* a problem.