Boost logo

Boost :

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2003-04-12 10:22:20


On Sat, 12 Apr 2003 11:26:07 +0100, "John Maddock"
<jm_at_[hidden]> wrote:

>>Ah! Then, grepping for that, I have found a usage for the new macro in
>>tuple/detail/tuple_basic.hpp too.
>
>Add cast.hpp to the list as well, maybe others.

Yes, cast.hpp was already mentioned in the original post.

>> [...] Should we have two separate macros?
>>
>> #ifndef BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS
>> # define BOOST_DUMMY_DEFAULTED_PARAM(t)
>> # define BOOST_APPEND_DUMMY_DEFAULTED_PARAM(t)
>> #else
>> # define BOOST_DUMMY_DEFAULTED_PARAM(t) t* = 0
>> # define BOOST_APPEND_DUMMY_DEFAULTED_PARAM(t) \
>> , BOOST_DUMMY_DEFAULTED_PARAM(t)
>> #endif
>>
>> or is there a better solution?
>
>Not really, are ther really cases that require two args ?

Yes. It's not necessarily a matter of having two or more dummy
parameters, but even (for instance) a genuine parameter before the
dummy one(s). Examples:

 template <class Target, class Source>
 Target polymorphic_cast(Source* x BOOST_EXPLICIT_DEFAULT_TARGET)
 {
   ...
 }

 template<int N, class HT, class TT>
 typename access_traits<
                  typename element<N, cons<HT, TT> >::type
>::non_const_type
 get(cons<HT, TT>& c BOOST_TUPLE_DUMMY_PARM) {
   ...
 }

The above code is from cast.hpp and tuple/detail/tuple_basic.hpp.
Consider, though, that I only grabbed two examples; I didn't mean to
imply that the authors of that code would use the new function-like
macro, since specifying the type explicitly at macro invocation can be
quite verbose in their case (and defining their ad-hoc macros
BOOST_EXPLICIT_DEFAULT_TARGET and BOOST_TUPLE_DUMMY_PARM in terms of
the new one also will not likely be considered a significant
improvement)

>We need these added to the config docs as well if/when they are added (into
>the helper macros section).

Sure. And since I'm the one who has proposed the work I'm willing to
do it myself and provide a patch, of course.

Genny.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk