RE: Boost algorithm library (Was: [boost] New upload: algorithm.z ip 1)

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-07-30 08:41:20

Peter Dimov wrote:
> The problem with gcc 3.0 that you recently discovered applies 
> here, too.
> Depending on how CWG #218 is resolved, a Koenig-reachable 
> non-function named "begin" may break the lookup and the added 
> boost::tag won't help. We're back to "keyword" stage. :-(

Ouch! I hope that if some day variables and references will be allowed to
participate in overload resolution, they would have no more "rights" when
ordinary functions, e.g. 

namespace lib {

struct tag {};

template<class T>
int capacity(T const& t, lib::tag)
{
    return t.capacity();
}

template<class T>
int capacity(T const& t)
{
    return capacity(t, lib::tag());
}

} // namespace lib

namespace her {

#if !defined(YEAR_2005)
struct something
{
    int capacity() const; 
    // won't be called from lib::capacity because 
    // it has too few parameters
    friend int capacity(something const& s);
};

#else

struct something
{
    int capacity() const; 
};

// won't be "called" from lib::capacity because 
// it has too few parameters
struct {
    int operator()(something const& s);
} capacity;

#endif // YEAR_2005

} // namespace her

int main()
{
    her::something s;
    lib::capacity(s);
    return 0;
}

BTW, IMO allowing non-function entities to participate in overload
resolution process would have a limited usefulness anyway, because once you
have a variable named 'capacity', you are not allowed to declare anything
else with the same name in the same scope:

namespace her {

struct something
{
    int capacity() const; 
    friend int capacity(something const& s, lib::tag);
};

// error #147: declaration is incompatible with 
// "int her::capacity(const her::something &, lib::tag)"
struct {
    int operator()(something const& s);
} capacity;

} // namespace her

Unless this rule will be relaxed too, of course :).

Aleksey