|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2002-12-31 18:10:04
"Paul Mensonides" <pmenso57_at_[hidden]> writes:
> ----- Original Message -----
> From: "David Abrahams" <dave_at_[hidden]>
>
>
>> "Jaap Suter" <J.Suter_at_[hidden]> writes:
>>
>> >> Nifty! You're using one of my favorite metaprogramming tricks, the
>> >> default template parameter which allows you to avoid creating a
>> >> separate implementation template. I almost forgot about that one,
>> >> it's been so long since I've been able to use it.
>> >
>> > Funny you mention that. I've been meaning to ask for its appropriateness
> on
>> > this list. After all, we are exposing implementation details in the
>> > interface which is not something I would recommend on a daily basis.
> Glad
>> > you like it :).
>>
>> That's a good point. It's a question of overall clarity. If it's
>> clearer to dispatch to an implementation template, I would say "do
>> it".
>
> I do this type of thing all the time:
>
> namespace hidden_default_template_parameter {
>
> class hidden {
> enum type { };
> friend class access_rights;
> };
>
> struct obtuse_access_rights {
> typedef hidden::type type;
> };
>
> } // hidden_default_template_parameter
>
> #define HIDE \
> HIDE_ID( \
> hidden_default_template_parameter::obtuse_access_rights::type; \
> ) \
> /**/
>
> #define HIDE_ID(id) id = id(),
>
> template<class T, HIDE class U = T> struct sample {
> // ...
> };
>
> In other words, a user cannot specify the 'U' parameter without also
> specifying the parameter generated by 'HIDE'. This method is not
> bulletproof, because the user can still do this:
>
> sample<int, hidden_default_template_parameter::obtuse_access_rights::type(),
> double>
>
> ...but that is pretty obtuse.
Yeah. I have no problem with access protection where it prevents
unintentional misuse and improves overall code clarity. However, this
seems like it doesn't fit that bill.
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk