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

From: Daniel Spangenberg (dsp_at_[hidden])
Date: 2003-07-23 05:31:42

Daniel Frey schrieb:
> I think the OP asked about explicit instantiated
> X<myclass>. Daniel
> (Spangenberg), please correct me if I'm wrong, but you question boils
> down to something like this:
Correct. But even a simpler example, where everything is inside **one**
namespace,
either the global one or anything specific, should lead to the same
conclusion. Lets
assume the following example:

template <typename T>
struct X
{
  friend bool operator>=(const T& lhs, const T& rhs)
  {
    return !(lhs < rhs);
  }
};

struct Y{
  bool operator<(const Y& x) const;
};

template struct X<Y>;

int main()
{
  Y a, b;
  a >= b; // Should NOT be found!!!
}
 
> The above code compiles fine with the GCC 2.95.2.
> The GCC 3.3 doesn't
> find the operator (it injects it into A, not into B), the Comeau rejects
> the explicit instantiation. Initially I thought that the above example
> should be legal, as the standard reads in 14.6.5/1:
>
> "When a template is instantiated, the names of its friends are treated
> as if the specialization had been explicitly declared at its point
> of
> instantia-tion."
>
> The point of instantiation is in namespace B, but after thinking about
> it a bit longer and reading some more stuff from the standard, I wonder
> if this can be true. The instantiation could happen in a different
> translation unit, so it seems strange that the operator is found in
> the
> same translation unit but not in different ones. Also, the Comeau
> rejects the explicit instantiation as it happens inside the namespace.
> 14.7.2 is also pretty clear on the subject, so I think that the GCC
> 3.3
> is correct, the Comeau should probably turn the error into a warning
> as
> the instantiation is not illegal (AFAICS, but correct me if I'm wrong),
> but probably has surprising behaviour. The GCC 2.95.2 and the operators
> library is wrong, the OP's observation is correct that it uses
> non-standard code. Also, I need to understand why my reading of 14.6.5/1
> is wrong, or is this a DR? Should I take it to csc++?
>
> Regards, Daniel
>
> --
> Daniel Frey
>  


I don't think, that this is a namespace issue (or I do not understand
my own
argumentation, which could be true, of course) and not a problem of
the
explicit instantiation (I assume, an implicit instantiation would have
the same problem).
The problem into which namespace the explicit instantiation injects
the function
from X is maybe another one, but is not of concern to me (in the moment).

I just found, that Vandevoorde/Josuttis mentions this problem in their
book (C++ Templates).
If you have access to this book, please have look on page 176, where
an example
is given, which is relatively near to our problem.

I did not find a related DR, but please have a view at the current information
stream
in a somewhat related thread

http://groups.google.de/groups?dq=&hl=de&lr=&ie=UTF-8&selm=spaqhvkci1ap9f7m5it4jvrf7d5k0qkhgh%404ax.com

(Can someone tell me, how to compress such link???)

I think the reasoning concerning this rule is, that the instantiation
of template classes should
not suddenly/unexpectedly introduce function visibilty concerning arguments
which are not directly
related to the instantiated class.

See you,

Daniel