Hi,

while looking through the DWP I noticed the class 'bitset' and
investigated the semantics of this class. When doing so, I came across
a couple of strange things which need, IMHO, clarification (or even
modification)... Here is the list of things I noticed appearing strange
or inconsistent to me:

1 The description refers to character values '0' and '1' in various
  places related to the conversion to and from 'basic_string<...>' or
  related to IO.  Although 'basic_string<charT, Traits, Allocator>' is
  used, there is nothing said about a way how to figure out what is '0'
  or '1'. Is it sufficient to assume that '0' is the character literal
  "'0'" and '1' is the character literal "'1'"? ... or is there a need
  for two 'string_char_traits' members called 'zero()' and 'one()'
  returning a corresponding representation? Or is there already such a
  thing and I just missed it...? I can imagine that it could be useful
  to convert strings like "++--+-" or "ttfftf" to 'bitset's (resulting
  in the same value as "110010" would do) or vice versa. This would be
  possible if 'zero()' and 'one()' were defined in the
  'string_char_traits'.

2 The template member 'bitset::to_string()' (note that it doesn't get
  any argument) is declared like this (in the january DWP, which I
  officially don't have...):

    template <class charT, class string_char_traits, class Allocator,
       size_t N>
    basic_string<charT, string_char_traits, Allocator>
      bitset<N>::to_string();

  Is this really possible? ... and what type is constructed, if it is
  possible, in an expression like this: "bitset<8>().to_string();"?
  The declaration in the April DWP requires a 'string'. Was there too
  much "STL-ization" done in this place?

3 'bitset' appears in the section about containers but it does not
  fullfill the normal container requirements: Why are the normal
  'typedef's missing? Are they just not listed or is the omission
  intentional? Wouldn't it be possible to define at least
  'bitset<N>::value_type' to be 'bool'. The type 'bitset<N>::reference'
  is defined (it is a 'class' in this case) but 'const_reference' is
  not. A reasonable definition could be 'typedef bool const_reference'.
  This would also enable to add a 'const' subscript operator returning
  a 'const_reference'; currently there is no 'const' subscript
  operator.

4 Why are iterators missing? The following types have to be defined to
  fullfill the requirements for containers:
  - iterator
  - const_iterator
  - difference_type
  - size_type
  None of them is defined for 'bitset<N>'. Also the functions
  - begin()
  - end()
  are missing. As the iterators are likely to be random access iterators,
  if they are added, the functions
  - rbegin()
  - rend()
  together with the necessary iterator 'typedef's would also make sense.

5 'swap()' takes O(N) time (because 'bitset' is intended to use
  built-in arrays as representation instead of memory allocated e.g. on
  the heap).  But since 'N' is part of the input, this is O(1), i.e.
  constant. Why is 'swap()' missing?

6 Why are the relational operators missing? I think that 'false < true'
  holds (I haven't seen a contradicting statement) and this would
  represent the common logic: A 'bitset<N>' can be converted to an
  'unsigned long' (as long as the 'bitset' can be represented as
  'unsigned long' that is). These can be compared with results which
  would be the same if 'bitset' could be compared lexicographically
  with the assumption that 'false < true'.

7 Why are 'max_size()' and 'empty()' missing ('empty()' always
  returning 'false')? These are the only two members missing from
  'bitset<N>' to make it a conforming container (i.e. one which
  fullfills all container requirements), if the other stuff is added.

8 The DWP claims (by the place where bitset is found) that 'bitset' is
  a sequence. This is a lie. The following sequence requirements cannot
  be implemented for 'bitset': 'insert()', 'remove()'. However, when
  stating which containers are seuqences (lib.sequence.reqmts) 'bitset'
  is not listed (this is the truth...).

I'm not sure what the state of 'bitset' is... As 'vector<bool,...>' is
a separate class required by the DWP it is well possible that 'bitset'
is the result of a compromise and my suggestions are stretching this
comprise. However, as 'bitset' will apparently become part of the
Standard C++ Library, it should conform to the semantics for other
classes found in the same library. Maybe this stuff can be fixed before
the next public review (I think most, if not all, of these points are
just editorial changes; whether they are wanted is another
question...).

Thank you very much for any clarification on the points noted above
  dk

BTW, will an overview of the results of the meeting of the
standardization committee posted to this newsgroup? (I think there was
such a meeting very recently...).
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl
I am a realistic optimist - that's why I appear to be slightly pessimistic
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]