Re: Specializing std::less without an operator <
On 2011-12-06 00:52, Kevin McCarty wrote:
Hello,
Suppose one has a class to represent objects for which a total
ordering can be defined, but where the exact nature of the ordering is
not always meaningful, and in general cannot be made non-arbitrary.
(In my case the class represents a physical measurement unit, e.g.
"meters" or "seconds"... this must be modifiable at runtime so (as
well as for historical reasons) we couldn't easily use Boost.Units.)
Suppose further that defining some (albeit arbitrary) total ordering
IS highly desirable: there is no reason one wouldn't want to have
these objects usable in an std::set, as the key of an std::map, or in
a container where one would want to std::sort() them by the
(arbitrary, but default) total ordering in order to be able to find
one via binary search.
I've read in _Effective STL_, item 42, "Make sure less<T> means
operator<". The arguments presented there are of course very
reasonable ... but I think I can make a reasonable case that in this
situation the advice of _Effective STL_ does not apply. Comments are
welcomed.
I think that your approach is the right one. If a types does not have a
"natural" reason to provide operator<, don't provide it. std::less seems
to be the right thing to specialize to ensure that you provide an access
point to some "canonical" ordering. In fact, "Elements of Programming"
gives a similar recommendation.
Personally I would also like to see a partial specialization of
std::less for the std::complex template for similar reasons.
1) Providing an operator< () would be misleading, for the following
reasons. (For explicative purposes please presume the existence of a
constructor Unit::Unit(const char *) that does the right thing when
used as in the code fragments below.)
I agree.
a) The philosophical perspective: The result of
operator< (Unit("feet"), Unit("meters"))
could perhaps meaningfully return true or false, as the length of 1
foot is less than 1 meter, but what would
operator< (Unit("seconds"), Unit("degrees Kelvin"))
return?? The only two possibilities that are reasonable are
i) It should throw (which means operator< is unusable in a container
or sort function, so back to square one), or
ii) It should return a well-defined but arbitrary result (misleading).
Both these choices look wrong to me.
b) The pragmatic perspective: The representation of a Unit is a single
unsigned value, which is treated as a bitmask, but for historical
reasons the values in the bits have no relation to the magnitude of
the physical quantity they represent. So even to support the specific
desideratum that operator< () returns true when the LHS and RHS are
of the same physical dimension and LHS is "smaller" than RHS would
require an inefficient series of switch / case or if ... else if
statements.
Well, "capability" alone should not dictate which operations our types
should provide.
2) However, given the function unsigned Unit::get() const, which
simply returns the wrapped unsigned value, writing an override of
std::less<Unit> to provide a well-defined (but in general arbitrary)
total ordering is trivial, as below.
Technically you mean a specialization here, I guess. And I surely agree
in regard to the triviality to do that.
And since no one writes
"std::less<T>()(a, b)" when what they really mean is to write "a< b"
-- that is, std::less is seldom used explicitly aside from in the
context of needing a total ordering -- I feel it is not misleading.
It isn't misleading - trust me ;-)
Should I nevertheless feel morally bound by the advice of _Effective
STL_, and require that all users of this class use their own functor
(even if a default one is provided), despite the excess verbiage?
I don't think so.
// assume struct UnitCmp defined just as std::less<Unit> was above
std::set<Unit, UnitCmp> s_units;
std::vector<Unit> v_units;
// ...
std::sort(v_units.begin(), v_units.end(), UnitCmp());
auto it = std::lower_bound(v_units.begin(), v_units.end(),
Unit("meters"), UnitCmp());
Or, as boost::shared_ptr does, is it regarded as preferable to instead
go ahead and define an operator<() that returns lhs.get()< rhs.get()
even though the result of the operator< is in general meaningless?
I don't think that boost_shared pointer (or std::shared_ptr) is a *bad*
example for providing operator<. The underlying pointer does provide it
and since a smart pointer mimics the built-in pointer to some degree,
this addition looks ok.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]