Re: Splitting vector<pair<int,int> > to pair<vector<int>,vector<int>
Abhishek Padmanabh schrieb:
Thanks for the explanation, Daniel and the insight on std::set. In
fact, I actually faced the problem owing to wierd problem that came
across me sometime ago. I used 3 techniques:
http://learningcppisfun.blogspot.com/2007/02/functors-with-state-4-alternati
ve.html
I will be upfront with you: Several of the tested techniques
have severe problems in the code:
1) You should additionally add #include <ostream> in all
examples, otherwise it's not guaranteed that the needed
operator<<(basic_ostream<char,traits>&, const char*)
is available via #include <iostream>. You also need
<stddef.h> because you use size_t in PrintVector.
2) The syntax used in trial #1 to define the static member
is invalid. Most probably you want to use this one:
template<typename T>
int IsEvenIndex<T>::index = 0;
3) The second output presented in trial #2 makes no
sense compared to the first and is probably wrong,
because the contents of myintVector and myotherintVector
are not influenced by the changes (assuming the same
standard library). The expected output for this special
library is probably something like this:
Printing vector contents
10 20 30 40 50 60 70 80 90 100
Printing vector contents
30 50 70 90
Printing vector contents
10 20 40 60 80 100
Printing vector contents
50 60 70 80 90 100
4) The insertion used in trial 2 is needlessly complicated
and could be replaced by the simple assignment
myanotherintVector.assign(itend, myintVector.end());
6) Some conclusions are basically wrong, e.g. this one
from #2: "Now, how would this predicate be passed? By
reference or by value? This is unspecified by the standards."
The standard says that the predicates *are passed* by value.
7) Further on the examples would be more readable, if you
had used a simpler initialization technique, e.g. a single
loop like this:
for (int i = 1; i <= 10; ++i) {
myintVector.push_back(10 * i);
}
The individual push_back's use a lot of space and more
severe: I had to check each single push_back to check,
whether the series of elements follow a special rule or not.
This rule is directly implied in the loop above.
8) The easy fix of #2 is to use an external state, that is
replacing the index int member in IsEvenIndex by int& index
and adding a second c'tor argument. Note that this externally
stored index has a similar role as the external state of the
referenced refVec.
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.
I wonder how that can be advantageous? The problem comes when the
functor has state that has to be maintained while copy/assign -
function pointers cannot have state unless they use a global/static
variable or a reference/pointer to an external object.
I was discussing advantages in general, not for this special
example which needs state. When you need state, a functor
is often the right choice, but you could also use tr1::bind
with a function pointer (with an additional argument accepting
the state), and transferring the state via the tr1:bind argument.
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! ]