This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.

396. what are characters zero and one

Section: 22.9.2.2 [bitset.cons] Status: CD1 Submitter: Martin Sebor Opened: 2003-01-05 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [bitset.cons].

View all issues with CD1 status.

Discussion:

23.3.5.1, p6 [lib.bitset.cons] talks about a generic character having the value of 0 or 1 but there is no definition of what that means for charT other than char and wchar_t. And even for those two types, the values 0 and 1 are not actually what is intended -- the values '0' and '1' are. This, along with the converse problem in the description of to_string() in 23.3.5.2, p33, looks like a defect remotely related to DR 303(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 construction is a bitset, not a string.

[ Sophia Antipolis: ]

We note that bitset has been moved from section 23 to section 20, by another issue (842(i)) previously resolved at this meeting.

Disposition: move to ready.

We request that Howard submit a separate issue regarding the three to_string overloads.

[ 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_string overloads.

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: "An element of the constructed string has value 0 if the corresponding character in str, beginning at position pos, is zero. 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 than zero or one. The function uses traits::eq() to compare the character values."

Change the declaration of the to_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 character zero, bit value 1 becomes the character one.

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 issue 303(i).