More n3644 changes - forward_list and deque

Howard Hinnant hhinnant at
Thu Aug 8 09:40:45 PDT 2013

On Aug 7, 2013, at 3:36 PM, Joerg Sonnenberger <joerg at> wrote:

> On Wed, Aug 07, 2013 at 12:51:09PM -0400, Howard Hinnant wrote:
>> On Aug 7, 2013, at 11:20 AM, Joerg Sonnenberger <joerg at> wrote:
>>> On Tue, Aug 06, 2013 at 03:18:42PM -0400, Howard Hinnant wrote:
>>>> Do you think debug mode would be more helpful, or less helpful, if the
>>>> relational operators trapped a less-than comparison between two
>>>> iterators i and j where i and j belong to two different vectors?
>>> Does it ever make sense to put iterators into a std::map? I think it
>>> does, so allowing relation operators would be sensible.
>> I'm going to slightly reword your question so that it more accurately
>> targets our discussion.  Please let me know if I've mangled your
>> intended question.  My intent is to clarify your words for us all, and
>> not to mangle what you were trying to say.
>> Does it ever make sense to put random access iterators referring to
>> more than one container into a single std::map?
> Correct, that's the intention of my question.
>> In using a std::map in this way, one would likely have to also store
>> in the map which container each iterator referred to, else the iterator
>> would be only as useful as a pointer or reference.
> The iterator could still include useful additional properties, think
> keeping a reference to the container for garbage collection.
> I'm not thinking it is generally a sign of good design and the use case
> is likely served better by an unordered_map. This leads to two
> questions:
> (1) How can it be made as obvious as possible to the programmer that
> what he is doing is wrong, why it is wrong and where it is wrong.
> (2) Similar to the complex<T> example, how can it be worked around in a
> standard compliant way, if this is really the intended behavior.
> The second is clearly a documentation issue.

I've opened a discussion on the LWG mailing list on this issue.  I'm hoping when the dust settles we will have a definitive direction...


More information about the cfe-commits mailing list