From: John Maddock (jm_at_[hidden])
Date: 2003-04-16 06:03:49
> Just in case it wasn't clear, I was waiting for a response :-)
Sorry, been off line, IMO go ahead.
> Anyway, I *was*. To elaborate a bit: if
> BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS is really for the VC6
> bug I've hinted at then I think it shouldn't have been introduced in
> the first place. The reason is that it is the kind of macro that
> forces the use of conditionals _whereas_ there's a simple, unique,
> pattern to cope with the problem.
Agreed, however it's easier for the config system to have a single macro
that gets set if some test fails (by the configure script if necessary),
which then goes on to determine the state of the helper macros depending on
whether it's set or not.
> For instance we have BOOST_DEDUCED_TYPENAME but nothing like e.g.
> BOOST_NO_TYPENAME_IN_DEDUCED_CONTEXTS: the former just takes uniformly
> care of the problem, whereas the second, if it existed, would require
> repeating basically the same #if/#else at every usage. Analogously,
> the problem at hand can be generally solved with a dummy parameter. So
> there's no need, for client code, to use a BOOST_NO_xxx macro.
> In this case, what macros could have been used? A possibility is:
> /* for a single type argument */
> BOOST_EXPLICIT_TEMPLATE_TYPE_ARGUMENT(t) ...
> /* for 2nd, 3rd, etc. positions */
> BOOST_COMMA_AND_EXPLICIT_TEMPLATE_TYPE_ARGUMENT(t) \
> , BOOST_EXPLICIT_TEMPLATE_TYPE_ARGUMENT(t)
> /* ... */
> BOOST_EXPLICIT_TEMPLATE_NON_TYPE_ARGUMENT(v) ...
> /* ... */
> BOOST_COMMA_AND_EXPLICIT_TEMPLATE_NON_TYPE_ARGUMENT(t) \
> , BOOST_EXPLICIT_TEMPLATE_NON_TYPE_ARGUMENT(t)
> Unfortunately, these are 4 macros, and I already seem to hear you...
> Thus, let's just pretend I never said it! :-)
There's no doubt that it is clearer that way, so since these don't need test
cases (we already have it), just go ahead and add them if you want to
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk