This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2] Implement the ability to set/unset environment variables to GDBserver when starting the inferior
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Simon Marchi <simon dot marchi at polymtl dot ca>
- Cc: GDB Patches <gdb-patches at sourceware dot org>, Pedro Alves <palves at redhat dot com>, Eli Zaretskii <eliz at gnu dot org>
- Date: Fri, 04 Aug 2017 19:03:22 -0400
- Subject: Re: [PATCH v2] Implement the ability to set/unset environment variables to GDBserver when starting the inferior
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=sergiodj at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0F03C68680
- References: <20170629194106.23070-1-sergiodj@redhat.com> <20170727033531.23066-1-sergiodj@redhat.com> <d9dae60ba5a7e1aca29f15fe865f4110@polymtl.ca> <87shhc9ffa.fsf@redhat.com> <291aec4022448984a38891ddbccf08e1@polymtl.ca>
On Tuesday, August 01 2017, Simon Marchi wrote:
> On 2017-08-01 04:42, Sergio Durigan Junior wrote:
>>> I have the feeling that we can reduce the amount of boilerplate code
>>> in the set and unset methods by using std::set instead of std::vector.
>>> Performance-wise this may not be very good, since for any reasonable
>>> amount of variables, the vector would probably be more efficient. But
>>> its interface makes the code clearer and lighter, in my opinion. I
>>> suppose we could always make something with a set-like interface and
>>> behavior implemented on top of a vector.
>>
>> I thought about using std::set, but given that I was recently called
>> out
>> for doing "premature pessimization", I chose to stick with std::vector.
>> I agree that for some cases std::set would make things easier to
>> implement/understand.
>
> Yeah, the thing with std::set that simplifies the code is its
> interface, not its implementation. And it would indeed not be a good
> idea performance-wise (both CPU cycles and memory) to use std::set for
> something that would typically contain a handful of elements at the
> most. So that's why I think using something that has (part of) the
> interface of an std::set but implemented on top of an std::vector
> would be good. I'll try to prototype something soon.
So, I've been thinking about this implementation over the last few days,
but it's still a bit confuse to me. My C++-foo is not so good as yours,
so maybe you can give me a hand.
>From what I understood initially, your intention was to make a new class
that inherited from std::vector but overloaded/implemented methods to
mimic what a std::set would do. However, after reading a bit, it
doesn't seem like a good idea to inherit from std::vector (or any std
containers). Which made me realize that maybe you are talking about
creating a class that encapsulates a std::vector, without inheriting
from it, and that provided the regular .push_back, .insert, .empty,
etc., methods, but in an enhanced way in order to e.g. prevent the
insert of duplicated elements, which is one of the things we miss from
std::set.
Am I in the right direction here? Also, I started to think... I don't
envision the user setting thousands of user-set environment variables,
so *maybe* using std::set would be OK-ish for our use case scenario. I
don't know. While I understand the concern about premature
pessimization, I'm also not a fan of complicating the implementation
just for a little bit of optimization either.
WDYT?
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/