Re: [boost] BOOST_PP array extension proposal

Subject: Re: [boost] BOOST_PP array extension proposal
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-09-10 19:15:16

On 9/10/2015 5:44 PM, Matt Calabrese wrote:
> On Thu, Sep 10, 2015 at 2:11 PM, Edward Diener <eldiener_at_[hidden]>
> wrote:
>>
>> Given that variadic macros are supported for just about all compilers now,
>> the Boost PP array is largely obsolete as the Boost PP tuple has all the
>> functionality which an array has except for the fact that a tuple can never
>> hold 0 elements while an array can. Therefore I am trying to phase out the
>> use of Boost PP arrays in favor of Boost PP tuples.
>
>
> This might just be just paranoia, but has there ever been profiling done
> regarding large usage of PP tuple-based code vs PP array-based code? I've
> experienced some pretty drastic differences in memory usage during
> compilation when switching between different looping constructs and
> container types, etc. and it's not always immediately obvious why. There is
> certainly at least some minimal cost to always using tuples, IIUC.
> Particularly if these operations are performed inside of repetition
> constructs, though, especially with a compiler that does sophisticated
> macro expansion tracking, seemingly minimal differences might actually
> become noticeable. I've never done the benchmark myself, but I just think
> it might be best to proceed with caution before encouraging switching over
> whole-sale to tuples.

Ouch <g> !

I admit I have never done any benchmarking of preprocessor code. This is 
not only compile time code but is preprocessor code, which occurs pretty 
earlier in the compilation phases. So I have never thought very hard and 
long about how one would measure the time spent by the compiler in macro 
expansion depending on whether you use one Boost PP construct versus 
another. Any thoughts about how anybody could accurately benchmark such 
time would be most welcome.

The main reason for preferring a PP tuple to a PP array when using 
variadic macros is that you don't have to specify the number of elements 
in the tuple as you do in the array, so the tuple syntax is easier to 
work with. Call this my own sense of syntactical elegance. It also 
eliminates the mistake where you might specify the wrong array size for 
a PP array. This mistake could more easily occur when you have nested 
parenthesis as array elements.

I have no doubt manipulating tuples are probably slower than 
manipulating arrays when variadic macros are being used, since 
calculating the tuple size is slower than having it there as a 
preprocessor number. I still vote for elegance over preprocessor speed, 
but I understand your point of view.

>
> I wonder if, instead, we might also consider the opposite approach. By that
> I mean consider using arrays and phasing out direct tuple operations,
> except for the ability to create a PP array from a PP tuple, automatically
> deducing the size. As you mentioned, arrays can properly represent an empty
> range, so that alone might be a good reason to prefer it as the go-to
> tuple-like container, even with all else being equal.

I should have specified that "phase out the use of Boost PP arrays" does 
not mean that they will ever be eliminated from Boost PP AFAICS.

VMD makes a strong case for general emptiness when variadic macros are 
being used. For the two composite constructs, tuples and seqs, which can 
not have zero elements, I should have added to Boost PP's functionality 
with tuples and seqs my own BOOST_VMD_xxx functionality which allows the 
macro programmer to work with them starting from or ending with an 
"empty" state. I can certainly do that.

> I haven't given a lot
> of thought to this, though, but I'm sure Paul would also have some pretty
> good input on the matter. Do you know his stance on this?

I am pretty sure I know Paul's stance since he was the one who mentioned 
to me that with the use of variadic macros the Boost PP array is "obsolete".