From: Moore, Paul (Paul.Moore_at_[hidden])
Date: 1999-12-09 09:48:01
From: Kevlin Henney [mailto:Kevlin.Henney_at_[hidden]]
> In most examples Koenig Lookup will ensure that either
> approach is transparent as the relevant abs will be searched
> for in the namespace from which rational comes, ie boost, as
> well as anywhere else specified, ie std.
Oh, so that's what "Koenig Lookup" is. I'd wondered... (You see the phrase
used a lot, but I'd never found a definition!)
> However, one use that would fall foul of expectation would be
> full explicit qualification:
> r = std::abs(r);
Actually, it's worse. I'm developing on Visual C++ (I know, but it's what I
have and use, so I want my classes to pander to its bugs, even if I'd prefer
not to...) which is totally broken in this issue, as far as I can see.
So I think what I'll do is define abs() in boost. From what you say, this
will work on compilers where Koenig lookup is implemented. On MSVC it
doesn't work (Koenig? Who's he? :-(), but nor does putting it in std (abs is
not defined in std, but globally). So MSVC users just need to explicitly use
I don't really have much sympathy with explicit qualification with std:: if
the user is not using a standard type. This may be inconsistent, but there
Actually, thinking about it, all I really think should work is abs(r) - in
the presence of nothing more than a "using boost::rational". The presence or
absence of a using-declaration for std::abs should not be relevant.
BTW, I've just seen Ed Brey's note suggesting friend abs. It seems to me
that this doesn't add anything that Koenig Lookup hasn't already given us
(in terms of lookup issues, as opposed to access to the internal
representation). Is there any case (where KL isn't implemented) where having
abs declared as a friend, in addition to being in the same namespace as the
class, helps the compiler to find the function? MSVC can't locate the stupid
thing even in this case :-(
Right. Current decision - I'm going for
1. Put abs in the boost namespace alongside rational.
2. Rely on Koenig Lookup.
3. Add a nasty "using boost::abs" for MSVC only in my example code.
I don't really like Ed's nested namespace suggestion. 99% of the time, users
will just want rationals, and the canonical incantation for that should just
be "using boost::rational" or just explicit qualification.
Any more comments?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk