Boost logo

Boost :

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2003-01-01 15:07:47

----- Original Message -----
From: "David Abrahams" <dave_at_[hidden]>

> "Paul Mensonides" <pmenso57_at_[hidden]> writes:
> > ----- Original Message -----
> > From: "David Abrahams" <dave_at_[hidden]>
> >
> >> 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.
> >
> > Oh, it does IMHO. Once it is defined it can be reused in all such
> > contexts.
> You said "it doesn't change the usage syntax", but doesn't it? How to
> do you make a recursive invocation which needs to specify something
> where the default parameter appears?

It doesn't because the default parameter is an implementation detail. I.e.
not part of the interface. The purpose of hiding it is to make it unusable
to the client.

> BTW, I read your thing about exception-specs, but fail to see any
> relationship.

A partial specialization loses the exception specification:

template<class R, class P1, class P2> struct test<R (P1, P2)> {
    typedef R type(P1, P2);

If the original function type had an exception specification, the nested
"type" is not equivalent to the input type. The only way to prevent that
lose of information is to pass along a copy of the original template
argument to the partial specialization. Hence, a default:

template<class T, class U = T> struct test;

template<class R, class P1, class P2, class U> struct test<R (P1, P2), class
U> {
    typedef U type;

In a situation such as this, the 'U' parameter is _not_ part of the public
interface. It is an implementation detail, so it is preferable to make it
unusable to the client. You can do this like so:

template<class T> struct test : detail::test<T, T> { };

Or you can force the unusability of the parameter inline:

template<class T, HIDE class U = T> struct test;

Paul Mensonides

Boost list run by bdawes at, gregod at, cpdaniel at, john at