This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.
Section: 22.9.2.2[bitset.cons]Status:CD1Submitter: Martin SeborOpened: 2003-01-05Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [bitset.cons].
View all issues withCD1 status.
Discussion:
23.3.5.1, p6 [lib.bitset.cons] talks about a generic characterhaving the value of 0 or 1 but there is no definition of whatthat means for charT other than char and wchar_t. And even forthose two types, the values 0 and 1 are not actually what isintended -- the values '0' and '1' are. This, along with theconverse problem in the description of to_string() in 23.3.5.2,p33, looks like a defect remotely related to DR303(i).
23.3.5.1: -6- An element of the constructed string has value zero if the corresponding character in str, beginning at position pos, is 0. Otherwise, the element has the value one.
23.3.5.2: -33- Effects: Constructs a string object of the appropriate type and initializes it to a string of length N characters. Each character is determined by the value of its corresponding bit position in *this. Character position N ?- 1 corresponds to bit position zero. Subsequent decreasing character positions correspond to increasing bit positions. Bit value zero becomes the character 0, bit value one becomes the character 1.
Also note the typo in 23.3.5.1, p6: the object under constructionis a bitset, not a string.
[Sophia Antipolis:]
We note that
bitsethas been moved from section 23 to section 20, byanother issue (842(i)) previously resolved at this meeting.Disposition: move to ready.
We request that Howard submit a separate issue regarding the three
to_stringoverloads.
[post Bellevue:]
We are happy with the resolution as proposed, and we move this to Ready.
[Howard adds:]
The proposed wording neglects the 3 newer
to_stringoverloads.
Proposed resolution:
Change the constructor's function declaration immediately before 22.9.2.2[bitset.cons] p3 to:
template <class charT, class traits, class Allocator> explicit bitset(const basic_string<charT, traits, Allocator>& str, typename basic_string<charT, traits, Allocator>::size_type pos = 0, typename basic_string<charT, traits, Allocator>::size_type n = basic_string<charT, traits, Allocator>::npos, charT zero = charT('0'), charT one = charT('1'))Change the first two sentences of 22.9.2.2[bitset.cons] p6 to: "Anelement of the constructed string has value 0 if the correspondingcharacter instr, beginning at positionpos,iszero. Otherwise, the element has the value 1.
Change the text of the second sentence in 23.3.5.1, p5 to read: "The function then throws invalid_argument if any of the rlen characters in str beginning at position pos is other thanzero orone. The function uses traits::eq() to compare the character values."
Change the declaration of theto_string member function immediately before 22.9.2.3[bitset.members] p33 to:
template <class charT, class traits, class Allocator> basic_string<charT, traits, Allocator> to_string(charT zero = charT('0'), charT one = charT('1')) const;Change the last sentence of 22.9.2.3[bitset.members] p33 to: "Bit value 0 becomes the characterzero, bit value 1 becomes the characterone.
Change 22.9.4[bitset.operators] p8 to:
Returns:
os << x.template to_string<charT,traits,allocator<charT> >( use_facet<ctype<charT> >(os.getloc()).widen('0'), use_facet<ctype<charT> >(os.getloc()).widen('1'));Rationale:
There is a real problem here: we need the character values of '0' and '1', and we have no way to get them since strings don't have imbued locales. In principle the "right" solution would be to provide an extra object, either a ctype facet or a full locale, which would be used to widen '0' and '1'. However, there was some discomfort about using such a heavyweight mechanism. The proposed resolution allows those users who care about this issue to get it right.
We fix the inserter to use the new arguments. Note that we already fixed the analogous problem with the extractor in issue303(i).