On 16.10.2015 12:53, Raffi Enficiaud wrote:
Le 16/10/15 11:40, Andrey Semashev a écrit :
On 16.10.2015 12:30, Raffi Enficiaud wrote:
[snip]
So I will guard the enforcement of BOOST_PP_VARIADICS=1 in case this one is already defined.
You can't guarantee the order of inclusion of Boost.Test and Boost.PP headers. So, if I understand it right, by adding that check you essentially make the interface inconsistent. If you have the non-variadic implementation anyway, why do you want this inconsistency?
PPvariadic allows to use some of the features introduced on boost.test v3 that eg. boost.log is not using. I can enforce the support of PPvariadic for the compilers I know that support variadic, so that it brings a subset of v3 for those compilers, without the user taking care of that.
I will clarify that point in the doc, but I do not see much of inconsistencies there: - variadic already defined => up to the user (either inclusion order or enforcement). - variadic not defined => up to boost.test.v3
My point is that the user can't rely on these new features if he doesn't use the compiler in C++11 mode because he may include headers in the wrong order. Relying on inclusion order in the first place is a terrible idea, to my mind. You should just use what Boost.PP allows you to use and not try to force its configuration. It's not your business to do that. If anything, it should be the user's choice, not yours. Although not related to Boost.PP, I had a similar situation with Boost.Log and Boost.ASIO - the default configs of the two libraries were conflicting and I proposed to force Boost.Log config on Boost.ASIO[1]. The result of the discussion was that a library should not impose config choices on another library.
The fix should be in develop once my runners are green (maybe half an hour).
Thanks for the quick fix. [1]: http://thread.gmane.org/gmane.comp.lib.boost.devel/258870