Re: [boost] Possible patch to format for Borland BCB5

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-01 21:07:02

A small correction --

David Abrahams <dave_at_[hidden]> writes:

> It's pretty simple:
>
> 0. A "dependent" name is one whose meaning depends on the type or
>    value of a template parameter.
>
> 1. templates are parsed in phase 1 and all non-dependent names are
>    bound at that point. Any unqualified names which are not followed
>    by dependent arguments (e.g. some_name(x), where x is of type T)
>    are considered to be non-dependent. 
>
> 1.5 It is in phase 1 that the compiler also decides whether each name
>    is referring to a member or a non-member. I guess the theory is
>    that we don't want our templates to suddenly start using members
>    instead of non-members because we instantiated them with a base
>    class that has an unfortunate member name:
>
>        template <class T> void f(T x);
>
>        template <class B> struct D : B
>        {
>             D() { typedef typename B::some_type some_type; f(some_type()); }
>        };
>
>        struct Base
>        {   
>             f(int);
>             typedef int some_type;
>        };
>
>        D<Base> x; // uh-oh?
>
>    In this case, f is dependent, because ADL says to look it up based
>    on argument types. However, phase 1 parsing determines that it's a
>    non-member name because it's not defined in D or any of its
>    non-dependent bases (of which it has none).
>
> 2. When templates are instantiated, phase 2 lookup goes into effect
>    and dependent names are bound.
>
> 3. If a base class is dependent on (or is) a template parameter, you
>    can't know the base's exact definition until all specializations
>    have been seen, so unqualified names never refer to members of
>    dependent bases. They are always treated as non-dependent and bound
                                                 ^^^^^^^^^^^^^
This is wrong, since they may be dependent due to Koenig lookup on
dependent arguments. Actually, they are just treated as non-members
unless they can be found in the template or its non-dependent
bases. I'm juste repeating what I said in 1.5.

>    in phase 1 at the template's point-of-definition. By the time we
>    get to phase 2 and know the definition of the actual base, it's too
>    late.
>
> 4. If the template has dependent bases, and the name is not found in
>    the template itself, you can make the name dependent by adding
>    this->, since then its definition may depend on the base class.
>
> So, adding this-> or BaseClass:: doesn't actually make the names
> visible. Instead it
>
>    a. Marks the name as a member in phase 1
>
>    b. delays lookup of the names until phase 2 when they might be
>    visible.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution