Re: [boost] BOOST_PP array extension proposal

On 9/10/2015 5:44 PM, Matt Calabrese wrote:

On Thu, Sep 10, 2015 at 2:11 PM, Edward Diener 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".