On Aug 7, 2013, at 3:36 PM, Joerg Sonnenberger <[email protected]> wrote:
> On Wed, Aug 07, 2013 at 12:51:09PM -0400, Howard Hinnant wrote: >> On Aug 7, 2013, at 11:20 AM, Joerg Sonnenberger <[email protected]> >> 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... Howard _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
