This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/15523] Can't have vectors of vector::const_iterator
- From: "llewelly at xmission dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 19 May 2004 18:22:45 -0000
- Subject: [Bug libstdc++/15523] Can't have vectors of vector::const_iterator
- References: <20040518193757.15523.bangerth@dealii.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From llewelly at xmission dot com 2004-05-19 18:22 -------
Subject: Re: Can't have vectors of vector::const_iterator
"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. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15523