diff --git a/dynamic_bitset.html b/dynamic_bitset.html
index d01b6ea..ad36f1e 100644
--- a/dynamic_bitset.html
+++ b/dynamic_bitset.html
@@ -634,9 +634,9 @@ explicit
If this constructor is called with a type BlockInputIterator which
is actually an integral type, the library behaves as if the constructor
-from unsigned long had been called, with arguments
+from unsigned long were called, with arguments
static_cast<size_type>(first), last and alloc, in that order.
-
+
Example:
// b is constructed as if by calling the constructor
@@ -654,31 +654,44 @@ Example:
dynamic_bitset<unsigned short> b(8, 7);
Note:
-This is analogous to what the standard mandates for sequence containers (namely,
-that if the type on which the template constructor is intantiated "does not
-qualify as an input iterator" then the other constructor is called; "the extent
-to which an implementation determines that a type cannot be an input iterator is
-unspecified, except that as a minimum integral types shall not qualify as input
-iterators").
+At the time of writing (October 2008) this is aligned with the
+proposed resolution for library
+ issue 438. That is a post C++03
+change, and is currently in the working paper for
+C++0x. Informally speaking, the critical changes with
+respect to C++03 are the drop of a static_cast
+on the second argument, and more leeway as to when the
+templated constructor should have the same effect as the (size,
+value) one: only when InputIterator is an integral
+type, in C++03; when it is either an integral type or
+any other type that the implementation might detect as
+impossible to be an input iterator, with the proposed
+resolution. For the purposes of dynamic_bitset we limit
+ourselves to the first of these two changes.
-Otherwise (i.e. if the template argument is not an integral
-type), constructs—under the condition in the requires
-clause—a bitset based on a range of blocks. Let *first be block
-number 0, *++first block number 1, etc. Block number b is used
-to initialize the bits of the dynamic_bitset in the position range
-[b*bits_per_block, (b+1)*bits_per_block). For each block number
-b with value bval, the bit (bval >> i) & 1
-corresponds to the bit at position (b * bits_per_block + i) in the
-bitset (where i goes through the range [0, bits_per_block)).
+Otherwise (i.e. if the template argument is not an
+integral type), constructs—under the condition in the
+requires clause—a bitset based on a range of
+blocks. Let *first be block number 0, *++first
+block number 1, etc. Block number b is used to
+initialize the bits of the dynamic_bitset in the position range
+[b*bits_per_block, (b+1)*bits_per_block). For each
+block number b with value bval, the bit
+(bval >> i) & 1 corresponds to the bit at
+position (b * bits_per_block + i) in the bitset (where
+i goes through the range [0, bits_per_block)).
-Requires: BlockInputIterator must be either an integral type or
-a model of Input
+Requires: BlockInputIterator must be either an
+integral type or a model of Input
Iterator whose value_type is the same type as
-Block.
Throws: An allocation error if memory is exhausted
-(std::bad_alloc if Allocator=std::allocator).
+Block.
Throws: An allocation error if
+memory is exhausted (std::bad_alloc if
+Allocator=std::allocator).
@@ -1484,7 +1497,7 @@ exception guarantee.
Changes in Boost 1.37.0
-- The constructor from a block-range implements a do-the-right-thing
+
- The constructor from a block range implements a "do the right thing"
behavior, a la standard sequences.
@@ -1492,21 +1505,24 @@ behavior, a la standard sequences.
Changes from Boost 1.31.0
-
-The stream extractor has completely different semantics: as
-natural for a dynamic structure, it now expands the bitset as needed
-during extraction. The new behaviour mimics that of the basic_string
-extractor but there are some differences the user should be aware
-of; so, please, look at the documentation.
-(One of the differences concerns the case where
-
stream.width() > bitset.max_size() > 0
-In that circumstance the extractor of dynamic_bitset never attempts to
-extract more than max_size() characters, whereas the extractor of
-basic_string goes on and, on conforming implementations, eventually
-throws a length_error. Note: That's what the standard mandates -see
-especially library issue 83- but not all implementations conform)
+The stream extractor has completely different semantics: as natural
+for a dynamic structure, it now expands the bitset as needed during
+extraction. The new behaviour mimics that of the basic_string
+extractor but there are some differences the user should be aware of;
+so, please, check the documentation. (One
+difference concerns the case where stream.width() >
+ bitset.max_size() > 0. In that circumstance the
+extractor of dynamic_bitset never attempts to extract more
+than max_size() characters, whereas the extractor of
+basic_string goes on and, on conforming implementations,
+eventually throws a length_error exception. Note: That's what
+the standard mandates -see especially library
+ issue 83- but not all implementations conform)
+
+The stream extractor is now also "exception-aware" in the sense that
+it works correctly when setting exception masks on the stream.
-The stream extractor is now also 'exception-aware' in the sense that
-it works correctly when setting exception masks on the stream.
-
Several member functions (empty(), find_first()
@@ -1515,7 +1531,7 @@ Several member functions (empty(), find_first()
have been added.
-
-The constructor from basic_string has a new parameter that was totally
+The constructor from basic_string has a new parameter that was totally
forgotten before.