I was just wondering out of curosity if the algorithms in the C++
standard library are allowed to add consts? I noticed this recently when
I found various random compile-time messages appearing from a class
where I had not declared operator< const.

On one hand I can't see anything which tells me I have to declare
operator< (or operator==) const, on the other hand I imagine it would
make implementing the standard library somewhat harder.

Any comments?

Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello Chris,

Chris schrieb:

> I was just wondering out of curosity if the algorithms in the C++=20
> standard library are allowed to add consts? I noticed this recently=20
> when I found various random compile-time messages appearing from a=20
> class where I had not declared operator< const.
>
> On one hand I can't see anything which tells me I have to declare=20
> operator< (or operator=3D=3D) const, on the other hand I imagine it wou=
ld=20
> make implementing the standard library somewhat harder.=20


You should definitely declare your overloaded relation operators either=20
as constant member
functions expecting constant arguments or as non-member functions=20
expecting both arguments
as immutable. The later is generally preferrable, but that is not the=20
point here.

Depending on the algorithm it is also definitly true, that an addition=20
might be performed (either on
the iterator or on its value type). This is either directly documented=20
(consider std::accumulate concerning +
or std::sort in the two-argument form, which delegates to std::less and=20
that itself usually delegates to
operator <) implicitly expectable (if the iterator must be incrementable=20
or even random-access-able)
by the requirements of the algorithm (i.e. std::sort).
Secondly it is actually a design error, if relational, logical, or=20
two-argument arithmetic operators
expect mutable arguments. This violates usual expectations on the=20
behaviour of such functions.
The only exception are **mutable** data members (which are declared as=20
such!), that do physically
change, but where the implementation guarantees that the class instance=20
itself remains **logically**
constant (Typically these members are needed for caching-like behaviour).
One example of this kind of caching can be found in most implementations=20
of std::istreambuf_iterator.
Iff your implementation of your operator< overload really needs=20
mutability, you should consider to

- rethink about its implementation and possibly refactor it (maybe=20
simply declaring your member
   function as const is sufficient?).
- recognize possible mutable members of you class which are needed for=20
the mentioned caching
   effects and declare them as such (If your compiler does **really**=20
not know the mutable
    keyword, you should use const_cast inside your class!)
- if nothing of the former points applies, you should consider to rename=20
operator< to some named
   member function, because obviously this function does **not** behave=20
like usual relational
   operations!

Greetings from Bremen,

Daniel Kr=FCgler




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Daniel Kr=FCgler (ne Spangenberg) schrieb:

> Depending on the algorithm it is also definitly true, that an addition=20
> might be performed (either on
> the iterator or on its value type).=20

To prevent any unnecessary brooding concerning the sense of this=20
sentence ;-)

Of course I meant "less comparison" instead of "addition". I was mixing=20
up here two examples I
wanted to provide: One example concerning relational comparison (i.e.=20
<), and one concerning
a two-argument arithmetic operator (i.e. +). Traces of this attempt are=20
left in my example with
std::accumulate (which belongs to <numeric>, but is also an "algorithm").

I apologize for any inconvenience,

Daniel Kr=FCgler

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]