On Fri, Jul 1, 2011 at 2:09 AM, Paul Mensonides <pmenso57@comcast.net> wrote:
On Thu, 30 Jun 2011 21:31:22 -0400, Lorenzo Caminiti wrote:
On Wed, Jun 29, 2011 at 10:54 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
Nonetheless macros using variadics to identify pp-lib data types on the fly might still be useful and I have already come up with a pretty good IS_TUPLE. Whether an IS_ARRAY, IS_LIST, or IS_SEQ is posible I shall see.
Useful indeed. I have implemented some sort of IS_TUPLE within Boost.Local. BOOST_LOCAL_PARAMS() uses it to accept both the follow syntaxes when variadics are present:
BOOST_LOCAL_PARAMS(int x, int& y) // (1) BOOST_LOCAL_PARAMS( (int x) (int& y) ) // (2)
One of the things that Edward and I are discussing is introducing an IS_VARIADIC macro along the lines of the other detection macros that already exist (i.e. IS_NULLARY, IS_UNARY, IS_BINARY). In essence, IS_VARIADIC detects whether its argument *begins* with a parenthesized expression (of any arity). However, it doesn't suffer the problems associated with try to detect emptiness. For example:
IS_VARIADIC( int x, int& y ) // 0 IS_VARIADIC( (int x)(int& y) ) // 1 IS_VARIADIC( (...) xyz ) // 1
For your particular case, wouldn't that be sufficient?
Yes, in fact IS_VARIADIC is the macro Boost.Local currently uses. See my rudimentary implementation at: http://svn.boost.org/svn/boost/sandbox/local/boost/local/aux_/preprocessor/v... This implementation is fine for Boost.Local but I have not tested in general and it might impose unacceptable limitation (like the empty issue we discussed also while discussing VMD).
Regardless, I actually believe that the (1) case above is actually a large step *backwards*. It's worse, not better, because it's trying (and failing) to be the underlying language and introducing a bunch of gotchas in the attempt.
I can only say that (i) I agree with you BUT (ii) my library users (my customers) wanted (1) very badly so I really have no choice.
I'd prefer to see IS_TUPLE (and possibly all IS_XXX) as part of these Boost.Preprocess variadics changes.
Not possible unless they are laden with (unreasonable) input constraints.
Yes, I agree that a Boost.Preprocessor version of IS_TUPLE (and also IS_VARIADIC) should work in general and not requiring input constraints. I did not play with Boost.Local IS_TUPLE/IS_VARIADIC enough to assess if it is possible or not but if you guys say that a generic IS_TUPLE is not possible that is of course a good reason not to add it to Boost.Preprocessor. --Lorenzo