By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,389 Members | 1,881 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,389 IT Pros & Developers. It's quick & easy.

Reading from an istream to a bool vector

P: n/a
Hello,

With this code:

$ cat -n ifs.cc
1 #include <vector>
2 #include <iostream>
3
4 using std::vector;
5 using std::cin;
6
7 int
8 main()
9 {
10 vector< bool > vb(1);
11 vector< int > vi(1);
12 bool b;
13 int i;
14
15 cin >> b;
16 cin >> i;
17 cin >> (vb[0]);
18 cin >> (vi[0]);
19 return 0;
20 }

I have the following errors:

$ g++-2.95.3 -Wall ifs.cc
ifs.cc: In function `int main()':
ifs.cc:17: initialization of non-const reference type `bool &'
ifs.cc:17: from rvalue of type `bool'
/.../iostream.h:217: in passing argument 1 of `istream::operator
(bool &)'


$ g++-3.3.2 -Wall ifs.cc
ifs.cc: In function `int main()':
ifs.cc:17: error: no match for 'operator>>' in 'std::cin >>
std::vector<bool, _Alloc>::operator[](unsigned int) [with _Alloc =
std::allocator<bool>](0)'

$ g++-3.4.0 -Wall ifs.cc
ifs.cc: In function `int main()':
ifs.cc:17: error: no match for 'operator>>' in 'std::cin >>
(&vb)->std::vector<bool, _Alloc>::operator[] [with _Alloc =
std::allocator<bool>](0u)'

$ g++-3.4.1 -Wall ifs.cc
ifs.cc: In function `int main()':
ifs.cc:17: error: no match for 'operator>>' in 'std::cin >>
(&vb)->std::vector<bool, _Alloc>::operator[] [with _Alloc =
std::allocator<bool>](0u)'

So i guess this is the good behavior, but does anybody have a
rationale for that? Why can i read into an int vector but not a bool
one??

--
Nomak

Jul 22 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
On Sat, 07 Aug 2004 12:37:30 -0700, Nomak wrote:
$ cat -n ifs.cc
1 #include <vector>
2 #include <iostream>
3
4 using std::vector;
5 using std::cin;
6
7 int
8 main()
9 {
10 vector< bool > vb(1);
11 vector< int > vi(1);
12 bool b;
13 int i;
14
15 cin >> b;
b is an lvalue, we can pass it as a non-const reference to
operator>>.
16 cin >> i;
17 cin >> (vb[0]);
vb[0] is an rvalue because vector<bool>::operator[] returns 'bool'
(the value of the first object, by-value).
18 cin >> (vi[0]);
vi[0] is an lvalue because vector<int>::operator[] returns 'int&'
(the first object by-reference).
19 return 0;
20 }

I have the following errors:

$ g++-2.95.3 -Wall ifs.cc
ifs.cc: In function `int main()':
ifs.cc:17: initialization of non-const reference type `bool &'
ifs.cc:17: from rvalue of type `bool' /.../iostream.h:217: in passing
argument 1 of `istream::operator
(bool &)'

[...]
So i guess this is the good behavior, but does anybody have a rationale
for that? Why can i read into an int vector but not a bool one??


There is a specialization for vector<bool> where the return type
of operator[] differs from the return value of operator[] of the
general vector implementation.

vector<bool> is special in that it uses single bits to store the
bool objects. In a typical implementation, an unsigned int may be
used as the underlying data type. On a 32-bit machine this might
have the first 32 objects of the container share one unsigned
int.

Since it is not possible to return a reference to a single bit,
operator[] has to return by-value in the vector<bool>
specialization.

Ali
Jul 22 '05 #2

P: n/a
Ali Cehreli wrote:
[...]

So i guess this is the good behavior, but does anybody have a
rationale for that? Why can i read into an int vector but not a
bool one??


There is a specialization for vector<bool> where the return type
of operator[] differs from the return value of operator[] of the
general vector implementation.

vector<bool> is special in that it uses single bits to store the
bool objects. In a typical implementation, an unsigned int may be
used as the underlying data type. On a 32-bit machine this might
have the first 32 objects of the container share one unsigned
int.

Since it is not possible to return a reference to a single bit,
operator[] has to return by-value in the vector<bool>
specialization.


Thanks. It makes my loading code ugly...

--
Nomak
Jul 22 '05 #3

P: n/a
>> 16 cin >> i;
17 cin >> (vb[0]);
vb[0] is an rvalue because vector<bool>::operator[] returns 'bool'
(the value of the first object, by-value).


[...]
Since it is not possible to return a reference to a single bit,
operator[] has to return by-value in the vector<bool>
specialization.


That might not be that simple, otherwise it would be impossible to
change any value in that bool array : if vb[i] is rvalue, we can't
assign anything to it.

If I'm not mistaken, the vector<>::operator[] method returns an object
of type named "reference", which (in the case of bool vector) is
probably some kind of proxy object for the targetted array element.

Not too sure though, but I can't think of anything else that would do
the job...

Sylvain.
Jul 22 '05 #4

P: n/a
On Fri, 13 Aug 2004 17:47:11 -0700, Sylvain Audi wrote:
16 cin >> i;
17 cin >> (vb[0]);
vb[0] is an rvalue because vector<bool>::operator[] returns 'bool' (the
value of the first object, by-value).


[...]
Since it is not possible to return a reference to a single bit,
operator[] has to return by-value in the vector<bool> specialization.


That might not be that simple, otherwise it would be impossible to
change any value in that bool array : if vb[i] is rvalue, we can't
assign anything to it.


Thank you for the correction.
If I'm not mistaken, the vector<>::operator[] method returns an object
of type named "reference", which (in the case of bool vector) is
probably some kind of proxy object for the targetted array element.


Even when writing the above I was thinking about the posibility of such
a proxy but didn't pay much attention to it. A quick test of mine made
me believe that the operator>> for the proxy can do what the OP
needed. I am not sure why it's not implemented that way.

In any case, googling for older posts show that vector<bool> does not
satisfy some of the container requirements anyway.

Ali
Jul 22 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.