Re: Specializing std::less without an operator <
On Dec 6, 12:52 am, Kevin McCarty <kmcca...@gmail.com> 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.
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.)
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).
Well, actually the third and pragmatic solution is not to consider
comparing such Unit instances. Clearly, when you have two Units that
do represent same kind of measurement, you can. Otherwise, you cannot,
so don't do it. Perhaps you should classify your units better
(lengths, voltages, masses...).
b) The pragmatic perspective: The representation of a Unit is a single
unsigned value,
Loads of measurements can have negative values. I guess in your
problem domain, that's not the case.
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.
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. 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.
#include <functional>
...
namespace std {
template <> struct less<Unit> : binary_function <Unit, Unit, bool>
{
bool operator() (const Unit & x, const Unit & y) const
{ return x.get() < y.get(); }
};
}
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?
// 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?
That works if you don't care about the ordering. It allows you to
store pointers in a set or a map, but it disregards the logical
ordering, if any. Such uses are practical e.g. if you actually have
unordered data sets. But if so, use of an unordered set should be
better.
Goran.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]