From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9161 invoked by alias); 4 Aug 2017 23:03:29 -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 9118 invoked by uid 89); 4 Aug 2017 23:03:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=lighter 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 ESMTP; Fri, 04 Aug 2017 23:03:24 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0F03C68680; Fri, 4 Aug 2017 23:03:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0F03C68680 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@redhat.com Received: from localhost (unused-10-15-17-193.yyz.redhat.com [10.15.17.193]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D64C2707BC; Fri, 4 Aug 2017 23:03:22 +0000 (UTC) From: Sergio Durigan Junior To: Simon Marchi Cc: GDB Patches , Pedro Alves , Eli Zaretskii Subject: Re: [PATCH v2] Implement the ability to set/unset environment variables to GDBserver when starting the inferior References: <20170629194106.23070-1-sergiodj@redhat.com> <20170727033531.23066-1-sergiodj@redhat.com> <87shhc9ffa.fsf@redhat.com> <291aec4022448984a38891ddbccf08e1@polymtl.ca> Date: Fri, 04 Aug 2017 23:03:00 -0000 In-Reply-To: <291aec4022448984a38891ddbccf08e1@polymtl.ca> (Simon Marchi's message of "Tue, 01 Aug 2017 11:53:51 +0200") Message-ID: <87mv7f7x6t.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00091.txt.bz2 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/