Re: [Bug libstdc++/15523] Can't have vectors of vector::const_iterator

[llewelly@xmission.com]

"bangerth at ices dot utexas dot edu" <gcc-bugzilla@gcc.gnu.org> writes:

> ------- Additional Comments From bangerth at ices dot utexas dot edu  2004-05-19 17:39 -------
> Subject: Re:  Can't have vectors of vector::const_iterator
> 
> 
> > I think in most cases it would be sufficient to create an empty
> >     vector, set it its vector<>::capacity(), and then push_back() new
> >     values into it.
> 
> That's exactly what I ended up doing in our code.
> 
> 
> > My naive expectation would be that -D_GLIBCXX_DEBUG_PEDANTIC would
> >     cause an abort() for all dectectable undefined behavior. I think
> >     most other users would expect this as well, *but* many probably
> >     don't realize this extends to aborting on the copy of a singular
> >     iterator, much less to aborting on the creation of the vector full
> >     of singular iterators. OTOH, some users expect implementations to
> >     report errors they don't know about.
> 
> As I said, I don't feel strongly way, I'm just confused because I don't see a 
> reaonsing behind this particular check. What harm does it do to copy an 
> object that you will not be allowed to use anyway?

I can only speculate as to the reasoning behind the check, but the
    example is undefined behavior. The check prevents an unsuspecting
    user from writing code which may misbehave on another
    implementation. 

In theory, such code may not be portable to other implementations. In
    practice, I don't know of an implementation in which copying an
    invalid iterator is a significant problem. But then, I mostly only
    use libstdc++ . :-)

I don't really know how far libstdc++ should go in emitting errors for
    non-conforming code. I did expect -D_GLIBCXX_DEBUG_PEDANTIC to
    cause that abort, and mildly prefer that it continue to do so, but
    I don't know how other users would react to it.

> Since the standard says 
> that behavior is undefined, we have some leeway in implementing sensible 
> behavior, in particular since we know that this can never hurt
> anyone.

I don't see this as being about whether gcc can implement sensible
    behavior for this case. My question is, should libstdc++ emit an
    error for this case, because some *other* implementation may not
    implement a sensible behavior for this case? The safe answer seems
    to be yes, but if nobody knows of an implementation where copying
    invalid pointers or iterators has bad behavior, maybe it's just
    paranoia. 

> 
> But I'm fine if we decide that this is NAD and that we should close this PR. 
> Please feel free to do so if you want.

I'm just an overly talkative observer. I don't close bugs. :-)