From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98737 invoked by alias); 18 Nov 2015 12:34:31 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 98716 invoked by uid 89); 18 Nov 2015 12:34:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 18 Nov 2015 12:34:29 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id BEB1CC10045A; Wed, 18 Nov 2015 12:34:28 +0000 (UTC) Received: from localhost (ovpn-116-19.ams2.redhat.com [10.36.116.19]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAICYRhC015856; Wed, 18 Nov 2015 07:34:28 -0500 Date: Wed, 18 Nov 2015 12:34:00 -0000 From: Jonathan Wakely To: =?iso-8859-1?Q?Fran=E7ois?= Dumont Cc: Jonathan Wakely , "libstdc++@gcc.gnu.org" , gcc-patches Subject: Re: vector lightweight debug mode Message-ID: <20151118123427.GD25025@redhat.com> References: <55FD0F35.4010106@gmail.com> <561574BE.1060005@gmail.com> <20151007200917.GU12094@redhat.com> <561C0D3A.7010504@gmail.com> <5648F551.5030404@gmail.com> <20151116102923.GI2937@redhat.com> <564B84C3.3090900@gmail.com> <20151118122744.GC25025@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20151118122744.GC25025@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2015-11/txt/msg02202.txt.bz2 On 18/11/15 12:27 +0000, Jonathan Wakely wrote: >But my unproven assumption is that it's more common to use operator[] >incorrectly, rather than pass invalid iterators to range insert, which >is a relatively "advanced" operation. It's worth noting that the google/integration branch doesn't have any checks on range insert/erase, and they have entire teams who work on analysing their code base to find common programming errors, and identify ways to avoid problems. That doesn't mean we shouldn't include any checks that aren't in the google branch, and we also shouldn't use all their checks, but it's useful to look at what they considered important to check.