-
Notifications
You must be signed in to change notification settings - Fork 16
/
Copy pathExer11_07.cpp
70 lines (70 loc) · 1.91 KB
/
Exer11_07.cpp
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
#include <iostream>
#include <string>
#include <vector>
#include <map>
#include <algorithm>
#include <iterator>
using std::cout;
using std::cin;
using std::endl;
using std::string;
using std::vector;
using std::map;
using std::istream_iterator;
using std::ostream_iterator;
int main()
{
map<string, vector<string>> family;
string patronymic;
string child;
ostream_iterator<string> os(cout, " ");
while(cin >> patronymic)
{
while(cin >> child)
{
family[patronymic].push_back(child);
}
cin.clear(); // clear for next input
}
for(const auto &w : family)
{
cout << w.first << ":\n";
copy(w.second.cbegin(), w.second.cend(), os);
cout << endl;
}
return 0;
}
// ******QUESTION******
// Q: Can we use istream_iterator here?
// A: No.
// Explanation: first, if an istream_iterator is defined, we ALWAYS have to use
// it for reading values from standard input, we can't write this way:
//
// istream_iterator<string> is(cin), eof;
// while(cin >> patronymic)
// {
// while(is != eof)
// family[patronymic].push_back(*is++);
// cin.clear(); // clear for next input
// }
//
// Compile the code above and input some strings, we'll find the result is not
// what we want:
//
// ******Result compiled by cl and g++******
// A
// 1 2 3
// ^Z
// ^Z
// 1:
// A 2 3
//
// This is possibly because istream_iterators are permitted to use lazy
// evaluation(see page 405), thus influencing the result.
//
// Moreover, even if we use istream_iterator at both inner loop and outer loop,
// still we cannot do what we want. Because that way we have to compare is and eof
// at both inner and outer loop, but when in inner loop is == eof, so is the one
// at outer loop. Thus once the inner loop is terminated, outer loop will, too.
// We may use the state of cin as termination condition, but this doesn't solve
// the lazy evaluation problem.