From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7227 invoked by alias); 19 May 2004 17:32:29 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 7216 invoked from network); 19 May 2004 17:32:28 -0000 Received: from unknown (HELO mgr2.xmission.com) (198.60.22.202) by sourceware.org with SMTP; 19 May 2004 17:32:28 -0000 Received: from [198.60.22.201] (helo=mgr1.xmission.com) by mgr2.xmission.com with esmtp (Exim 3.35 #1) id 1BQUvb-0002Dv-02; Wed, 19 May 2004 11:32:27 -0600 Received: from [166.70.238.3] (helo=xmission.xmission.com) by mgr1.xmission.com with esmtp (Exim 4.30) id 1BQUu6-0006ku-R5; Wed, 19 May 2004 11:30:54 -0600 Received: from llewelly by xmission.xmission.com with local (Exim 3.35 #1 (Debian)) id 1BQUgI-00054w-00; Wed, 19 May 2004 11:16:38 -0600 To: gcc-bugzilla@gcc.gnu.org Cc: gcc-bugs@gcc.gnu.org References: <20040518193757.15523.bangerth@dealii.org> <20040519142405.8002.qmail@sourceware.org> From: llewelly@xmission.com Date: Thu, 20 May 2004 18:43:00 -0000 In-Reply-To: <20040519142405.8002.qmail@sourceware.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Subject: Re: [Bug libstdc++/15523] Can't have vectors of vector::const_iterator Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mgr1.xmission.com X-Spam-Level: X-Spam-Status: No, hits=0.3 required=8.0 tests=NO_REAL_NAME autolearn=no version=2.63 X-SA-Exim-Mail-From: llewelly@xmission.com X-SA-Exim-Version: 3.1 (built Wed Aug 20 09:38:54 PDT 2003) X-SA-Exim-Scanned: Yes X-SW-Source: 2004-05/txt/msg02157.txt.bz2 List-Id: "bangerth at dealii dot org" writes: > ------- Additional Comments From bangerth at dealii dot org 2004-05-19 14:24 ------- > I see your point, although 24.1/5 only speaks about "most operations" and > does not specifically rule out that we do the sensible thing here. I > think my point is that I fail to see the value of this check, since it > seems to be allowed to create such an iterator, but not to copy it. On > the other hand, if we simply omitted the check we would fall over later > if we ever tried to dereference it. The only thing that one would have > to make sure is that the result of assigning a singular iterator to > another iterator is again a singular iterator, but that should be what > happens anyway if we simply copy all member variables. > > I don't feel strongly either way, since I already fixed my code to > work around this, but I do feel that there are cases where one would > like to generate a vector of singular iterators, and only after that > assign individual values to them. The obvious answer is that if one can't initialize a vector of iterators to the 'right' value, one should initialize them to the null iterator. :-) (I know, pointers are the only iterators for which such a value exists.) 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. 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.