[boost] Re: Non-standard feature proposed in help text of operators library??

From: Daniel Spangenberg (dsp_at_[hidden])
Date: 2003-07-23 04:15:19

Daniel Frey schrieb:

> They needn't be visible for myclass. They only need to be visible in the
> namespace where this happened. See 3.4.2/2:
>
> "If T is a class type, its associated classes are the class itself and
> its direct and indirect base classes. Its associated namespaces are the
> namespaces in which its associated classes are defined."
>
> The namespace is what is important here, not the class. The
> friend-operators declared by X<T> are injected to the namespace as given
> by 14.6.2/2:
>
> "As with non-template classes, the names of namespace-scope friend
> functions of a class template special-ization are not visible during an
> ordinary lookup unless explicitly declared at namespace scope (11.4).
> Such names may be found under the rules for associated classes (3.4.2)."
>
> note the "...namespace-scope friend functions...", which to me means
> that the operators are not injected to X<T>, but to the namespace where
> the explicit instantiation happened. As this should be the same
> namespace where T lives, anything should IMHO be legal C++. At least
> this is how I read the standard.
>
> Regards, Daniel
>
> PS: I don't think english is our problem, but if you feel more
> comfortable with german you can mail me directly if you like.

Thanks for that! But first I try to explain it in English...

1) Regrettably I made an error during my transformation of the example
given in 14.6.5, because I substituted myclass for the number ergument
of the gcd function. This must have caused the trouble, that we seem
to speak of different things.

2) Momentarily I still think, that myclass should not see the injected
functions (operators) of less_than_comparable<myclass>, iff this class is
explicitely istantiated (w/o inheritance connection to myclass!!!). I will
explain below the details.

3) Of course, the canonical way to instantiate these operator via the
inheritance trick (Barton-Nackman + CRTP) should work, I never
said anything else.

Explanation: Lets consider the two possible instantiations:

(a) Canonical way:
class myclass : private boost::less_than_comparable<myclass>
{
...
public:
  bool operator<(const myclass& x) const;
};

bool g()
{
  myclass a, b;
  ...
  return a >= b; // OK, >= will be found!
}

This mechanism should work, because myclass, which inherits from
boost::less_than_comparable<myclass>, is an associated with myclass,
because:

less_than_comparable<myclass>::operator>=(const& myclass, const& myclass);

has arguments (const myclass&) which are associated with the defining template,
and because myclass "is a" less_than_comparable<myclass>.

Here 3.4.2/p. 2 applies:

"— If T is a class type, its associated classes are the class itself and its direct
and indirect base classes. Its
associated namespaces are the namespaces in which its associated classes are
defined."

The validity of **this** mechanism was never called into question by me.

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Now the critized method:
(b) Alternative way:

class myclass{ // No inheritance connection with less_than_comparable!!
...
public:
  bool operator<(const myclass& x) const;
};

template struct boost::less_than_comparable<myclass>;

bool g()
{
  myclass a, b;
  ...
  return a >= b; // Should NOT be found!!!
}

The reasoning is the following: The explicit instantiation of
boost::less_than_comparable<myclass> does in fact inject
the operators into the surrounding namespace, **but** these
operators should **not** be visible during ordinary lookup,
because myclass is **no longer associated** with
boost::less_than_comparable<myclass>, because myclass
does NOT depend on boost::less_than_comparable<myclass>
(otherway around they do depend, of course), because
3.4.2/2 **does** not apply here!!!

I hope, I could make my position clearer to you...

Thanks and no hard feelings,

Daniel