Re: Is this a legal C++ code?
Thomas Maeder wrote:
"James Kanze" <james.kanze@gmail.com> writes:
Functors for for_each can have state, in fact the 'final copy' of the
functor is returned by for_each. There are no constraints other than
it must be copiable, since it passed to for_each by value and returned
by value.
Where in the standard does it say this? Where does it say that
the functional object must be copiable? Where does it say that
the same instance is appied in each iteration, and that a copy
of this object is returned?
Well, even if the Standard doesn't say it explicitly, it's the only
interpretation.
Cf. http://shrunklink.com?soa (refers to an old post of yourself) :-)
That only concerns the copy constructor. I agree that because
the functional object is passed by value, it seems reasonable
that the object must be copiable (although I think it would be
far better if the standard said so explicitly). I also think
that we can reasonably assume that the functional object is not
allowed to do anything which invalidates the iterators for_each
is using---IMHO, that too should be explicitly stated somewhere.
The standard refers to these as function objects; the only thing
I can find concerning function objects is in ?2.3 (C++98) resp.
?20.5 (latest draft), where is says:
Function objects are objects with an operator() defined. In
the places where one would expect to pass a pointer to a
function to an algorithmic template (clause 25), the
interface is specified to accept an object with an
operator() defined. This not only makes algorithmic
templates work with pointers to functions, but also enables
them to work with arbitrary function objects.
That suggests to me that function objects should act like
pointers to functions, and pointers to functions are not only
CopyConstructable, but also Assignable and DefaultConstructable;
with a pointer to a function, something like the following would
be legal:
template< ..., typename Function >
void
algorithm( ..., Function userFnc )
{
Function fnc ;
fnc = userFnc ;
// ...
}
Now, I don't know what an implementation would do something that
stupid, but I also cannot say off hand if it was actually the
intent to forbid it; perhaps there are other, more exotic cases
where it would make sense.
FWIW, there is some additional text in the latest draft, in
?20.5.2, which says: "Every call wrapper [20.5.1] shall be
CopyConstructible. A simple call wrapper is a call wrapper that
is Assignable and whose copy constructor and assignment operator
do not throw exceptions." I'm not sure what relationship call
wrappers have with function objects, however; I've not studied
this part of the new text in detail. My own gut feeling is that
there's no point in detailing it to finely---nobody will remember
all the details anyway---, and that the best solution is
probably to define a concept Copiable, which implies both
CopyConstructible and Assignable, and require it for all value
oriented objects (and function objects are value oriented, in
the sense that the algorithms make no effort to maintain
identity).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]