|
Boost : |
From: Brian McNamara (lorgon_at_[hidden])
Date: 2004-02-16 14:15:17
On Mon, Feb 16, 2004 at 06:46:26PM +0100, Gabriel Dos Reis wrote:
> David Abrahams <dave_at_[hidden]> writes:
> | Gabriel Dos Reis <gdr_at_[hidden]> writes:
> | > I understand the reasoning of letting the user says what the name
> | > should refer to. Which makes me inclined to make the construct
> | > ill-formed: That is not different from the rule that says you cannot
> | > reclare a template-parameter in its scope.
> |
> | That would be horrible for generic code.
>
> Care to explain why?
>
> | What are the requirements
> | on the T parameter of this class template?
> |
> | template <class T>
> | struct Der : T
> | {
> | template <class U>
> | void f(U x)
> | {}
> | };
>
> Should those requirements be different from those for
>
> template<class S>
> struct Der : S
> {
> template<class U>
> void f(U x)
> { }
> };
Apologies ahead of time if I am putting words in anyone's mouth.
I think Dave wants to imply that the class T in his example is not
allowed to have a member named U according to Gaby's proposed rule.
But this isn't how the rule would work; the way I see it, _these_:
struct Base { typedef int U; };
template <class U>
struct Derived : Base { }; // illegal
struct Derived2 : Base {
template <class U>
void f(U u) {} // illegal
};
would be illegal ("the name U already has another meaning; choose
another name for your template parameter"), whereas _these_:
struct Base { typedef int U; };
template <class B, class U>
struct Derived : B { };
/* ... Derived<Base> ... */
template <class B>
struct Derived2 : B {
template <class U>
void f(U u) {}
};
/* ... Derived2<Base> ... */
are both fine, since Base's "U" is hidden by virtue of being a dependent
name. There is still an issue of what happens if one of these last two
classes issues a "using B::U" in its body; presumably then "U" ought to
become outlawed as a valid template parameter name.
Just my two cents here...
-- -Brian McNamara (lorgon_at_[hidden])
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk