From: Alan Griffiths (alan_at_[hidden])
Date: 1999-12-15 19:25:17
In message <flyaaxt4kw.fsf_at_[hidden]>, Gabriel Dos Reis
<Gabriel.Dos-Reis_at_[hidden]> writes
>Alan Griffiths <alan_at_[hidden]> writes:
>
>|
>| If I am trying to produce a version (carefully avoiding "specialisation"
>| or "overloading" - those are implementation details) of a standard
>| entity (e.g. std::swap, or std::abs) for a class of mine the logical
>| namespace in which to place it is std.
>
>This is exactky where we disagree.
At least we agree on that! :)
>Since ::std is reserved for
>implementation details, and you don't care about implementation
>details, why would you insist on putting themin ::std?
Because I want to ensure that the version relevant to my UDT is called
in preference to the version in std.
>Since boost::rational<T> abs(const boost::rational<T>&) belongs to
>boost::rational<T> interface, I still don't the point to put it in
>another namespace.
Because client code (especially when templated) may have no idea of the
namespace in which rational<T> exists. Because of the name lookup rules
there is no guarantee that the either the version in boost or that in
std will be found without being explicitly named. (As when there is a
class member called abs or swap.)
>| My view is that this is where it _should_ go - 'legal' or not. (The
>| fact that it appears to be illegal suggests that a defect report is the
>| appropriate action.)
>
>From an engineering point of view, i don't think that is that is the
>place it should go.
I presume that you believe that it belongs in boost. The difficulty is
that, in some circumstances, this then requires the boost namespace to
be named in client code that tries to swap/abs the corresponding type
defined in boost.
[...]
>|
>| A little contrived, but not unreasonable...
>|
>| template<typename number_type>
>| struct example
>| {
>| static number_type abs(number_type x)
>| {
>| return std::abs(x);
>| }
>| };
>
>Writing generic code is not a trivial issue. the snippet above does
>make the assumption that number_type is coming from ::std.
No, that abs is coming from std. (int isn't from std.)
>If the intent were to make it works with every number_type then
>surelly, the code needs to be fixed. Not the rules.
Three cases:
/1/ Change name lookup rules so that boost::abs is found - without or
with "std::". (I think we agree this is wrong.)
/2/ Require any client code that references an abs function in a class
where an abs member function exists to use a proxy function like:
template<typename number_type>
number_type proxy_abs(number_type x)
{ using std::abs; return abs(x); )
(I guess this is what you intend. However, I think this would be a
maintenance disaster.)
/3/ Allow std::abs to be overloaded on UDTs. (Maybe I've not seen the
problem with this approach - AFAICS the only issue is with the letter of
the standard.)
--