|
Boost : |
From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2000-08-02 16:16:28
The global swap() function (at the bottom of array.hpp) uses
const reference parameters, which is definitely wrong. Is it ok
for me to go ahead and remove the "const"-ness in the CVS?
Nicolai Josuttis wrote:
> - Jens Maurer <Jens.Maurer_at_[hidden]>:
> Do we want the "using std::swap;" trick so that Koenig lookup finds
> more global element swap() functions?
> What's that????
This comment was induced by the previous array.hpp incarnation,
which had an explicit loop for swap(), I think. You are now
using std::swap_ranges, so the concerns in the following lines
no longer apply and you can forget about the comment.
For example, consider an array with user-defined member type
with your code.
Would swap() have worked optimally on instances of this construct?
Not necessarily, because the swap() loop in array<>::swap() would
have called std::swap() on the user-defined member type, which is
possibly a sub-optimal implementation of swap() for that type,
even though the user-defined type probably also defined a better
non-member swap() in its namespace. The C++ name lookup rules
never consider the latter if std::swap() is called with explicit
std:: qualification. So it might be better to use swap() without
the std:: qualifier and add a "using std::swap" at the top of the
function. This allows the compiler to apply Koenig lookup to find
other non-member swap()s which possibly fit better than the generic
template<class T> void swap(T&a, T&b) in namespace std.
The same problem shows more drastically for abs() in
boost/rational.hpp, and has been discussed extensively in that
context.
> DENIED:
[...]
> - PRINT_ELEMENTS() still ALL_CAPS (again for readability,
> I could turn it into a macro, though :-)
I am looking at the CVS version.
array2.cpp uses print.hpp, but the header isn't in the CVS.
I'm still in favour of doing printing similar to array3.cpp
instead of using PRINT_ELEMENTS() in only one example.
Jens Maurer
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk