On 4/25/07 3:51 AM, in article
1177493160.051591.251220@n15g2000prd.googlegroups.com, "James Kanze"
<james.kanze@gmail.com> wrote:

> In response to a recent posting in comp.lang.c++, Gennaro Proto
> raised a question as to the requirements concerning the value
> type of the iterator used to instantiate the two iterator form
> of the constructor.  The actual example was:
>=20
>     unsigned char buffer[ N ] ;
>     //  Fill buffer...
>     std::string   s( buffer, buffer + N ) ;
>=20
> This works with all implementations I have tried, but his
> question was: is it guaranteed, and regretfully, I could find no
> definitive answer in the standard.  The section on this
> constructor in the definition of std::basic_string forward to
> the sequence requirements ([sequence.reqmts]), where all that is
> said is that "X(i,j)" has a post condition that "isze() =3D=3D
> distance between i and j", and that it "constructs a sequence
> equal to the range [i,j)"; previous text constrains i and j to
> satisfy input iterator requirements, and to be a valid range.
>=20
> Obviously, buffer, buffer + N, above, meets all those
> requirements.  But...
>=20
>  1. Shouldn't there be at least the requirement that the
>     iterator value type be convertible to the value type of the
>     container?  As written, things like:
>         void * a[] =3D { &x, &y, &z } ;
>         std::string s( a, a + 3 ) ;
>     or:
>         class C {
>             C( int ) ;
>         } ;
>         C a[] =3D { C(1), C(2), C(3) } ;
>=20
>         std::string s( a, a + 3 ) ;
>     would not seem to be forbidden.

Neither construction of "s" is forbidden - though both are likely to caus=
e a
compiler error. According to the requirements for a Input Iterator (as
listed in table 89 - all references are to n2134), an Input Iterator for =
a
type T - upon dereferencing - must return an object that is, at the very
least, convertible to T. Since neither a pointer-to-void nor the
user-defined "C" class in the example above is convertible to the
container's value_type (char), then in neither case has the caller provid=
ed
a suitable Input Iterator type to construct the object.

Now, an argument that fails to meet the Standard's requirements for a Inp=
ut
Iterator type - does not necessarily fail to construct the object. For on=
e
reason, a container will fall back to its other constructors in such a
situation - and check whether any of its other constructors are able to
accept the arguments as provided. And for another, more important reason,
the Standard allows an implementation to decide on its own what an accept=
al
Input Iterator type is - and therefore to accept (practically) any kind o=
f
argument type as a qualifying input iterator, if the implementation so
chooses:

"The extent to which an implementation determines that a type cannot be a=
n
input iterator is unspecified, except that as a minimum integral types sh=
all
not qualify as input iterators." [=A723.1.1/11]
=20
 =20
>  2. What is actually meant by "constructs a sequence equal to"?
>     Consider:
>         double d[] =3D { 3.14, -0.1 } ;
>         std::string s( d, d + 2 ) ;
>     Is this legal?  If not, why not?  But if so, if I read the
>     text na=EFvely, the implementation is required to ensure
>     that
>         std::equals( s.begin(), s.end(), d )
>     returns true, which is going to be more than just difficult.

Not really. This code:

    double d[] =3D { 3.14, -0.1 } ;
    std::string s( d, d + 2 ) ;

    bool result =3D equal( s.begin(), s.end(), d, std::equal_to<char>());
    std::cout << "d =3D=3D s is " << std::boolalpha << result << "\n";

produces this output:

    d =3D=3D s is true

Meaning that the initializing values and the initial values in this examp=
le
are equal - once the types have been "normalized" to match each other and
the the type of item stored in the container.
  =20
> I would propose the following modifications:
>=20
> In [sequence.reqmts]:
>=20
>  1. In paragraph 3, the text concerning i and j be amended to
>     read:
>=20
>         i and j denote iterators of the same type satisfying
>         input iterator requirements, [i, j) denotes a valid
>         range, and the value type of i and j be implicitly
>         convertible to the value type of the container

The current requirement is actually "convertible" not "implicitly
convertible" so some ground would be lost with this change.
=20
>  2. In the entry concerning X(i, j) in table 82, the third
>     column be changed to:
>=20
>         post size() =3D=3D distance between i and j
>         constructs a sequence such that each element of the
>         sequence is equal to the corresponding element of
>         the sequence [i, j), converted to the value type of
>         the container.

The reworded requirement seems to be too restrictive - it explicitly
requires that the source and container value types be convertible in at
least one direction - even though the actual requirement is that the two
types merely be equality-comparable. After all, in C++ it is possible to
test whether two objects of different types are equal - even if it is not
possible to convert between them.
 =20
>  3. In the entries concerning a.insert(p,i,j) and
>     a.assign(i,j), the text "copies of elements in [i,j)" be
>     replaced by "elements equal to the elements which would
>     be present in X(i,j)".

The subjective expression is never explicitly resolved - so it leaves the
reader in a state of suspense: "the elements which would be present in
X(I,j)...if only - if only what exactly? I eventually realized that the p=
ast
tense was the problem - the construction of X(I,J) is actually meant to b=
e
contemporaneous and hypothetical, not past and contrary-to-fact. So the
paragraph is stating that insertion is the same as construction when it
comes to Standard containers. Yet the Standard already goes on in some
length on this topic (starting at =A721.1.1/9 and following) that additio=
nal
wording seems unneeded here.
 =20
> In [associative.requmts]:
>=20
>  1. In paragraph 7, the text concerning i and j be changed to:
>=20
>         i and j denote iterators of the same type satisfying
>         input iterator requirements, [i, j) denotes a valid
>         range, and the value type of i and j be convertible
>         to the value type of the container
>=20
>     (Note that the current text requires that the iterators
>     "refer to elemens of value_type".  This is overly
>     constraining, as it is sufficient that the be implicitly
>     convertible to value_type.  It is, in fact, a frequent idiom
>     in my own code to initialize a const map with something
>     like:
>=20
>         typedef std::map< std::string, int > Map ;
>         struct MapInit
>         {
>             char const* key ;
>             int         value ;
>             operator Map::value_type() const
>             {
>                 return Map::value_type( std::string( key ), value ) ;
>             }
>         } ;
>         MapInit const init[] =3D
>         {
>             { "one", 1 },
>             { "two", 2 },
>             { "five", 5 } ,
>         } ;
>         Map           m( init, init + 3 ) ;
>=20
>     It seems reasonable to me that this be supported.)

But a std::pair<char *, int> is not convertible (implicitly or otherwise)=
 to
std::pair<std::string, int> - which is the map's value_type in the above
program. So even if you get want you wish for - and the the Standard did
adopt your proposed change - you would still not get what you want in ter=
ms
of this program.
  =20
> Interestingly enough, the text concerning the constructor in
> table 84 already seems to allow for implicit conversion, since
> an "element" can effectively be inserted into the container any
> time it is convertible to value type.

Yes, objects that are convertible to the associative container's value_ty=
pe
may be inserted on an individual basis into the container - but only obje=
cts
of value_type proper may be inserted en masse by passing a range of
iterators. Perhaps the differing requirements represents a compromise.
=20
Greg=20

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]