I believe there are two shortcomings in the description of insert
iterators in section 24.4.2 of the standard:

(1) There is no description of any requirements on the container type
into which the insertion is being done. One would naturally expect the
insert iterators to be definable over container types that support the
appropriate insertion member function, but this is not spelled out.

(2) Paragraph 3 reads in part: "The assignment operator=(const T& x) is
defined on insert iterators to allow writing into them, it inserts x
right before where the insert iterator is pointing." I think this is
overly restrictive; the requirement that the insertion happens at a
specific place, if taken literally, would appear to restrict insert
iterators to sequential containers and ban their use with associative
containers (where the iterator argument to insert() is only a hint),
which I suspect was not the intention.

Proposed solution:

(1) Add to 24.4.2, immediately after para 3:

    "-4- The container type of an insert iterator shall meet the
    requirements of a Container (23.1). The container type of a
    back_insert_iterator or front_insert_iterator shall also meet the
    requirements of a Sequence (23.1.1), and shall support the
    optional push_back() (for back_insert_iterator) or push_front()
    (for front_insert_iterator) operation. The container type of an
    insert_iterator shall support the member function insert(p,t),
    where p is a valid iterator into the container and t is a value of
    the container's value_type."

(2) In 24.4.2 para 3, replace the sentence:

    "The assignment operator=(const T& x) is defined on insert iterators
    to allow writing into them, it inserts x right before where the
    insert iterator is pointing."

with:

    "The assignment operator=(const T& x) is defined on insert iterators
    to allow writing into them; it inserts x at the location implied by
    where the iterator is pointing, according to the container's normal
    insertion semantics."

Rationale:

It isn't instantly obvious what the requirements on the container types
should be. For back/front inserters, restriction to sequences seems
reasonable. The requirement for insert_iterator could have simply said
that the container must be either a sequence or an associative
container, but that would have left it unusable with user-defined
containers that don't meet the requirements of either concept but
nevertheless define insert(p,t).

The semantics of insert(p,t) are deliberately left unspecified, because
it would be too difficult to put any reasonable restrictions on it while
still allowing the various behaviours of the standard containers.

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
        "Hungarian notation is the tactical nuclear weapon of
         source code obfuscation techniques." -- Roedy Green

---
[ 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.research.att.com/~austern/csc/faq.html                ]