Re: std::function and const correctness
Am 28.05.2014 16:57, schrieb Roman Perepelitsa:
If I understand the relevant bits of the C++11 standard correctly, the
following program is well formed and passes all assertions.
Yes, your understanding is correct.
#include <cassert>
#include <functional>
struct Foo {
int operator()() { // Note: not const.
return n++;
}
int n = 0;
};
int main() {
const std::function<int()> f = Foo();
assert(f() == 0);
assert(f() == 1);
}
Since std::function has value semantics and its operator() is const, I
would expect a requirement *const* target object to be callable. I would
expect the first line of main() fail to compile because const Foo isn't
callable.
Is this behavior intended or is it an oversight? Any changes coming in
the future?
My understanding is that the behaviour is intended, but I can only
provide some indirect evidence for this:
1) std::function is described ([func.wrap.func] p1): "can store, copy,
and call arbitrary callable objects (20.9.1)", it doesn't impose
requirements onto the cv-qualifications of a function object call
operator. std::function had always been suggested as substitute for
dynamic polymorphic event handlers, irrespective whether these are
mutable or const.
2) std::function performs type-erasure, so either there would be the
choice to provide *only* a non-const operator() overload *or* a const
operator() overload (I ignore volatile here, because volatile
essentially is a second-class citizen in basically all parts of the
standard library with minor exceptions, e.g. involving std::atomic
types). Such a class design would not allow to enforce the
compiler-diagnostics that would depend on both the cv-state of
std::function and the cv-qualifications of its target.
3) std::function is required to copy it's target during copy-operations,
which means that any changes potentially performed by operator() will be
restricted to the corresponding copy, so each copy is (potentially)
statefull. In addition, direct access to it's underlying target is
possible via it's target() member functions, so this individual object
state is readable and writable.
I agree that the current specification can be read to be conflicting
when looking at the specification of the operator() overload:
"Effects: INVOKE (f, std::forward<ArgTypes>(args)..., R) (20.9.2), where
f is the target object (20.9.1) of *this."
but nowhere is said that the so-called "target" is considered a data
member or base class that would imply "const-forwarding".
It would have been possible to provide two overloads of the call
operator, but in that case it would mean that any const-violation would
impose a *runtime-diagnostics*, not a compie-time diagnostics.
It would have been easier, if the original proposals, such as
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1402.html
would have explicitly provided examples such as yours (III. Design
mentions a stateful compare_and_record function object, but here it is
wrapped by std::reference_wrapper before the construction, so this is
not a good example).
Nonetheless I think the current wording of Clause 17, in particular
[res.on.data.races] p3
"A C++ standard library function shall not directly or indirectly modify
objects (1.10) accessible by threads other than the current thread
unless the objects are accessed directly or indirectly via the
function?s non-const arguments, including this."
combined with the fact that std::function's call operator *is* a const
member imposes synchronistation requirements on implementations that
presumably have not been considered or are undesirable.
This last aspect indeed looks like a potential library issue to me.
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! ]