Boost logo

Boost :

Subject: Re: [boost] Review Request: Variadic Macro Data library
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2011-02-21 19:18:06

On Mon, 21 Feb 2011 18:40:17 -0500, Lorenzo Caminiti wrote:

> On Mon, Feb 21, 2011 at 2:37 PM, Paul Mensonides <pmenso57_at_[hidden]>

>> I take serious issue with anything that intentionally perpetuates this
>> mentality.  It is one thing if the syntax required is the same by
>> coincidence.  It's another thing altogether when something is done to
>> intentionally make it so.
> It might be useful to discuss this topic using the Boost.Local `PARAMS`
> macro as an example.
> IMO, the following syntax is better from a pp metaprogramming
> prospective because the arguments are a proper pp data structure (i.e.,
> a sequence) and it is very clear from the syntax that you are invoking a
> macro:
> int BOOST_LOCAL_FUNCTION_PARAMS( (int x) (const bind this) ) { // [1]
> ...
> l(-1);
> However, from the users' prospective the following syntax is preferred
> because it looks more like a C++ function parameter declaration so they
> are more familiar with it:
> int BOOST_LOCAL_FUNCTION_PARAMS(int x, const bind this) { // [2]
> ...
> l(-1);
> Therefore, as a pp metaprogrammer I'd prefer [1] but as the Boost.Local
> library developer I must keep in mind my users' preference and also
> provide [2] when variadics are available.

There is such a thing as good/bad regardless of preference. In the
second case above, you've traded compilation efficiency for a minor
syntactic difference. As a library developer, particularly in the case
of a general purpose library, that's a bad call to make. If you provide
both of the above, at least you still have the efficient version that
doesn't waste time doing a format conversion, but now you've introduced
bloat into the interface. You have two ways to do the same thing--one of
which is (apparently, given the existence of the former) non-portable as
well as brittle as far as revision is concerned. What happens when you
want to add some option--LOCAL_FUNCTION_PARAMS(option, (int x)...)? In
the latter case, because the preprocessor has no type system, that change
is radical. In the former case, you can do what I've been talking about
with BOOST_PP_TUPLE_ELEM (et al) and produce a smooth, non-breaking
revision path. Instead, you end up with yet another interface point
LOCAL_FUNCTION_PARAMS_WITH_OPTION that avoids the problem while adding
yet more interface bloat.

Perhaps this LOCAL_FUNCTION_PARAMS is a bad example for potential
revision, but the above is referring the general case. As I said
previously, the only way that I would ever provide a macro interface (in
a non-preprocessor metaprogramming library) such as the latter above, is
if I was absolutely certain that no arguments would be added or removed.

> IMO, it would be nice if Boost.Preprocessor supported variadics to make
> metaprogramming [2] easy. However, that does not necessarily mean
> providing:
> I would find having these two macros just as useful (and perhaps more
> correct):
> #define BOOST_PP_TO_TUPLE(...) (__VA_ARGS__) BOOST_PP_TUPLE((...))

What is BOOST_PP_TUPLE((...))?
> Then at some point in my pp metaprogram, I will have
> `BOOST_PP_TUPLE(BOOST_PP_TO_TUPLE(__VA_ARGS__))` which would be as
> convenient for me (a pp metaprogrammer) to use as
> `BOOST_PP_TUPLE(__VA_ARGS__)` directly. Of course, the
> `BOOST_PP_TO_TUPLE(__VA_ARGS__)` invocation will be hidden inside
> `BOOST_LOCAL_FUNCTION_PARAMS(...)` expansion to respect my library
> users' request that the `PARAMS` macro invocation should look like a
> normal C++ function parameter declaration as much as possible.

It is a DSEL. By definition it has its own syntax--as it obviously
already does.

> In summary, I would think that providing `BOOST_PP_TO_TUPLE(...)` and
> `BOOST_PP_TUPLE((...))` is a good approach.

In the case of a tuple, why would any of the above be better than simply
(__VA_ARGS__)? Again, though I don't know what you're referring to by
BOOST_PP_TUPLE((...)). What is that macro supposed to do?

Paul Mensonides

Boost list run by bdawes at, gregod at, cpdaniel at, john at