[PREPROCESSOR] Possible improvement for BOOST_PP_VARIADIC_SIZE

Currently, BOOST_VARIADIC_SIZE() evaluates to 1. Based on http://gustedt.wordpress.com/2010/06/08/detect-empty-macro-arguments/ it can be improved to return 0 for an empty argument list.

AMDG On 09/09/2013 01:44 PM, Brent Lewis wrote:
Currently,
BOOST_VARIADIC_SIZE()
evaluates to 1. Based on http://gustedt.wordpress.com/2010/06/08/detect-empty-macro-arguments/ it can be improved to return 0 for an empty argument list.
I believe that according to Paul Mensonides, the current behavior is correct. Please see this post: http://lists.boost.org/Archives/boost/2011/11/187820.php In Christ, Steven Watanabe

On 9/9/2013 4:44 PM, Brent Lewis wrote:
Currently,
BOOST_VARIADIC_SIZE()
evaluates to 1. Based on http://gustedt.wordpress.com/2010/06/08/detect-empty-macro-arguments/ it can be improved to return 0 for an empty argument list.
The flaw in the detection of empty arguments in the above link has already been discussed. I am not putting down that implementation in saying so. It is impossible to perfectly detect an empty argument. IMO the best case for detecting an empty argument was an example by Paul Mensonides on the web which I adapted for my VMD library at https://github.com/eldiener/variadic_macro_data.git. Furthermore as Paul has pointed out even an "empty" argument is considered an argument and still counts as 1 for the variadic size. In fact the spec for a variadic macro says that you cannot pass no argument when the macro expects variadic data. In other words: #define AVAR(ARG,...) AVAR(something) is an error, but of course AVAR(something,) or #define AVARAG(...) AVARAG() is perfectly fine since you are indeed passing an argument even if it is an "empty" argument.

Currently,
BOOST_VARIADIC_SIZE()
evaluates to 1.
In the preprocessor, variadic arguments are always one or more. If you need zero or more arguments instead should use a tuple or a sequence. I'm not sure that Boost supports zero-sized tuples or sequences, yet.
Based on http://gustedt.wordpress.com/2010/06/08/detect-empty-macro-arguments/ it can be improved to return 0 for an empty argument list.
Heres an excerpt about tuples from Chaos PP documentation(I'm not sure there's a link on the web for it), that explains it well(perhaps we should adapt this to boost docs since this question comes up often): Several problems arise from this situation when using tuples as data structures. The first is that there is no general way of detecting the difference between () and (1). It is possible to get fairly close in various ways by restricting the types of elements, but a general solution is impossible. Even if such detection **was** possible, another problem surfaces. Consider again the (,,) tuple, and consider an algorithm that operates on each element of a tuple. If the algorithm was to attempt to individually process elements one- by-one, it might use CHAOS_PP_TUPLE_HEAD and CHAOS_PP_TUPLE_TAIL. Everything is fine for CHAOS_PP_TUPLE_TAIL((,,)) (which yields (,)). However, CHAOS_PP_TUPLE_TAIL((,)) yields () (i.e. the theoretical nil tuple), and an element has been silently skipped. The underlying problem is that emptiness (or "nothing") is a useful and perfectly valid form of data in its own right. As a consequence, algorithms and primitives that operate on tuples algorithmically need to use a distinct representation for nil that has no ambiguity. This representation is CHAOS_PP_TUPLE_NIL() which simply expands to nothing. This model always treats () as a unary tuple, and CHAOS_PP_TUPLE_TAIL(()) expands to nothing. Paul Fultz II
participants (4)
-
Brent Lewis
-
Edward Diener
-
paul Fultz
-
Steven Watanabe