Re: Splitting vector<pair<int,int> > to pair<vector<int>,vector<int>
Abhishek Padmanabh schrieb:
On Apr 19, 10:13 am, Daniel Kr?gler <daniel.krueg...@googlemail.com>
There is a second part to that Note :
"[ Note: Unless otherwise specified, algorithms that take function
objects as arguments are permitted to copy those function
objects freely. Programmers for whom object identity is important
should consider using a wrapper class that points
to a noncopied implementation object, or some equivalent solution. -
end note ]"
What would that second part mean?
The second part is related to a situation described in
http://www2.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92
and can be summarized to the following: Let's assume
you invoke std::remove_if with a functor and you have
the genious idea that you could simply call the invocations
of the functor's operator() call by incrementing a counter
each time to indirectly determine the position ("index")
of the currently checked element. This is not guaranteed
to work by simply adding the count state as normal
member to the functor, because that one could be copied.
Therefore it's recommended that you use an externally
stored state to realize this, where each functor references
this state, e.g. you have to modify the example as shown
below:
class Nth { // function object that returns true for the nth
element
private:
int nth; // element to return true for
int& count; // element counter
public:
Nth (int n, int& count) : nth(n), count(count) {
}
bool operator() (int) {
return ++count == nth;
}
};
That Comeau accepts it - I think it interprets copy freely is to just
refer to copy and not assignment (or that there is no assignment
involved in this particular implementation).
I cannot follow your argumentation here. I did not say (in my first
answer) that an implementation *must* use assignment. So if
you use a functor with a reference member and this functor "works"
with some algorithm, this is does not proof that the standard did
allow assignments of functors.
Is it defined as to what
copy freely would mean? Should one really not have any assignment
members in functors?
IMO, the original (that is currently existing in 14882:2003)
wording is not precise enougth to specify that. But - as I
said in my refining answer - the new C++ concepts (and
other newcomers as rvalue references) lead to lesser
requirements (and to a clearer languag!) on such functors
and it will be sufficient now, if these are MoveConstructible.
So neither CopyConstructible nor Assignable must be
provided by the functor.
But it can be advantagous, if a functor is both CopyConstructible
and Assignable, because both requirements are given by
normal function pointers. So, if you would like to be flexible
enough to use a functor where you would use a function
pointer, both requirements should be fulfilled.
Another example is e.g. std::set. If you use a non-assignable
comparison object here, you cannot copy-assign the set,
see 23.1.2/11:
"[..] When an associative container is copied, either
through a copy constructor or an assignment operator,
the target container shall then use the comparison
object from the container being copied, as if that
comparison object had been passed to the target
container in its constructor."
Of course if you would simply *move-assign* the
containers there would be no such problem.
Also, even if there were copy involved - the compiler would shout
about it rather than it being UB. So, I would consider it safe.
Yes, in this sense it's a safe thing. But it can cause a lot
of grief for a company with a large code base that wants
to update it's standard library. In this case earlier working
code *could* loudly resist to compile now - with possibly
weeks of adaption work.
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! ]