This is the mail archive of the
mailing list for the GDB project.
Re: [RFA 14/22] Replace two xmallocs with vector
- From: Pedro Alves <palves at redhat dot com>
- To: Tom Tromey <tom at tromey dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 13 Oct 2016 02:17:21 +0100
- Subject: Re: [RFA 14/22] Replace two xmallocs with vector
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On 10/12/2016 11:39 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <email@example.com> 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<char> 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.
Hmm, the code you're touching isn't using XNEWVEC, so I'm not sure
I know exactly what you're referring to, but I assume you're thinking
of the xmallocs you're replacing.
Both vector and unique_ptr<T> (or unique_malloc_ptr<T> with the
to go with the existing mallocs) have the advantage of not requiring a
cleanup, of course. Writing either I think is almost the same code.
I think unique_ptr communicates intent a little better for these
cases, with the added bonus of a little extra efficiency, but it's not
a huge issue.