From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55659 invoked by alias); 12 Oct 2016 22:39:35 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 55644 invoked by uid 89); 12 Oct 2016 22:39:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:838, initializes, resize X-HELO: gproxy10-pub.mail.unifiedlayer.com Received: from gproxy10-pub.mail.unifiedlayer.com (HELO gproxy10-pub.mail.unifiedlayer.com) (69.89.20.226) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Wed, 12 Oct 2016 22:39:24 +0000 Received: (qmail 9813 invoked by uid 0); 12 Oct 2016 22:39:23 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 12 Oct 2016 22:39:23 -0000 Received: from box522.bluehost.com ([74.220.219.122]) by cmgw4 with id umfL1t0012f2jeq01mfPab; Wed, 12 Oct 2016 16:39:23 -0600 X-Authority-Analysis: v=2.1 cv=IecUBwaa c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=CH0kA5CcgfcA:10 a=20KFwNOVAAAA:8 a=YAi-3zgqY1wMf_KJ-s0A:9 a=e_O65bzb51kRm2y5VmPK:22 Received: from 75-171-239-149.hlrn.qwest.net ([75.171.239.149]:51520 helo=bapiya) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1buSBD-00025m-Q2; Wed, 12 Oct 2016 16:39:19 -0600 From: Tom Tromey To: Pedro Alves Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFA 14/22] Replace two xmallocs with vector References: <1474949330-4307-1-git-send-email-tom@tromey.com> <1474949330-4307-15-git-send-email-tom@tromey.com> <2bb436df-b6ee-cc2f-c4c1-1a79d6fcdce1@redhat.com> Date: Wed, 12 Oct 2016 22:39:00 -0000 In-Reply-To: <2bb436df-b6ee-cc2f-c4c1-1a79d6fcdce1@redhat.com> (Pedro Alves's message of "Sun, 9 Oct 2016 18:20:36 +0100") Message-ID: <87mvi9mbu1.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Exim-ID: 1buSBD-00025m-Q2 X-Source-Sender: 75-171-239-149.hlrn.qwest.net (bapiya) [75.171.239.149]:51520 X-Source-Auth: tom+tromey.com X-Email-Count: 5 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-SW-Source: 2016-10/txt/msg00334.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: >> * cli/cli-dump.c (dump_memory_to_file): Use std::vector. >> (restore_binary_file): Likewise. Pedro> As general guideline, for these cases where we only need to Pedro> construct a buffer once (never resize/reallocate) and we don't Pedro> care about the initial contents of the buffer, I think Pedro> unique_ptr buf (new char[size]); Pedro> ends up being more efficient, because std::vector Pedro> default/zero initializes its elements, which is unnecessary since Pedro> we're about to write into the buffer anyway. Pedro> WDYT? It's fine with me. Often the performance doesn't matter, and std::vector is safe to use. On the other hand XNEWVEC isn't really unsafe -- maybe just mildly less clear to gdb newbies. Tom