Re: [PATCH v2] Implement the ability to set/unset environment variables to GDBserver when starting the inferior

[Sergio Durigan Junior <sergiodj@redhat.com>]

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/