Constraints on value type of iterators in two iterator ctors of sequences missing

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:

    unsigned char buffer[ N ] ;
    // Fill buffer...
    std::string s( buffer, buffer + N ) ;

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() ==
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.

Obviously, buffer, buffer + N, above, meets all those
requirements. But...

 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[] = { &x, &y, &z } ;
        std::string s( a, a + 3 ) ;
    or:
        class C {
            C( int ) ;
        } ;
        C a[] = { C(1), C(2), C(3) } ;

        std::string s( a, a + 3 ) ;
    would not seem to be forbidden.

 2. What is actually meant by "constructs a sequence equal to"?
    Consider:
        double d[] = { 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?vely, 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.

I would propose the following modifications:

In [sequence.reqmts]:

 1. In paragraph 3, the text concerning i and j be amended to
    read:

        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

 2. In the entry concerning X(i, j) in table 82, the third
    column be changed to:

        post size() == 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.

 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)".

In [associative.requmts]:

 1. In paragraph 7, the text concerning i and j be changed to:

        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

    (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:

        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[] =
        {
            { "one", 1 },
            { "two", 2 },
            { "five", 5 } ,
        } ;
        Map m( init, init + 3 ) ;

    It seems reasonable to me that this be supported.)

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.

In [unord.req]:

 1. In paragraph 9, the same changes as in
    [associative.requmts], paragraph 7, above.

--
James Kanze (GABI Software) mailto:james.kanze@gmail.com
Conseils en informatique orient?e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34

---
[ 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 ]