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

bitset assignment

P: n/a
I have a question concerning the use of the [] operator in bitset
asignment.

bitset<4> a("1100");
bitset<4> b("0011");

a[i] = a[j];

Is clearly supported by the standard, and works with all the C++
compilers I have worked with. But what about

a[i] = b[j]; // ?

Assume that there are no indices out of range.
This works with gcc-3.* and MSVC 6 and higher but fails on an older
Borland compiler. I contend that this is ok because both a[i] and
b[j] return type bitset<N>::reference. Others say no, but for
unspecified reasons. Does anybody
have an authoritative answer?
Jul 22 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a

"Andy Skypeck" <as******@earthlink.net> wrote in message news:42**************************@posting.google.c om...
Is clearly supported by the standard, and works with all the C++
compilers I have worked with. But what about

a[i] = b[j]; // ?

Assume that there are no indices out of range.


It's supposed to work. That's the whole point of operator[] returning bitset::reference. Otherwise
it'd just return bool. Bitset::reference has a copy assignment operator.
Jul 22 '05 #2

P: n/a
On 3 Dec 2003 08:45:34 -0800, as******@earthlink.net (Andy Skypeck)
wrote:
I have a question concerning the use of the [] operator in bitset
asignment.

bitset<4> a("1100");
bitset<4> b("0011");

a[i] = a[j];

Is clearly supported by the standard, and works with all the C++
compilers I have worked with. But what about

a[i] = b[j]; // ?

Assume that there are no indices out of range.
This works with gcc-3.* and MSVC 6 and higher but fails on an older
Borland compiler. I contend that this is ok because both a[i] and
b[j] return type bitset<N>::reference. Others say no, but for
unspecified reasons. Does anybody
have an authoritative answer?


Try casting b[1], say, to an int, and see what the different compilers
give you; assuming it's set, it should return 1. If it returns 2 it
probably means they took a shortcut that's confusing the assignment,
--i.e.: broken compiler.

Jul 22 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.