From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by sourceware.org (Postfix) with ESMTPS id B460F3858D1E for ; Mon, 18 Apr 2022 21:07:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B460F3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f54.google.com with SMTP id v64-20020a1cac43000000b0038cfd1b3a6dso243588wme.5 for ; Mon, 18 Apr 2022 14:07:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=nm3kiEIzNUB9Q42Ty8K5gu/Q3mlbFj5nQfCy+KiLxi8=; b=BZ8y1c80T654UAog1gZuHxtKIEwJAuRBZjtM1EiLYLtXe3WDPB/HL2qyCxTI7mbOMR 0qcMNxveU/FGTbI1yubBVW16cHCP7udmJRU0ZnNaZp6/juCnDYbjE0rsDPvCGwxj/Eyl kTP405eTT5SKXwTzQzHFfeMcbINc8JdDmAzlHQ2/D0DYA/GskRU5Zn6jNat7igfP+O1p Sosm8sgVfxwzYSpXZjvjUDSH30iKPItwVfC4Jou11hdfYV4gFwJ7xxenB0URIxSfHAZT KXlmP24CeYItN5hIsbeSFo1RMo3vKKRrRooonaxN+0h3TxR/jHuvEC/gDvu+5O9aaNwy HBKQ== X-Gm-Message-State: AOAM53243lL5jIqjxblqQ9FAuITcc7CV2SZftCK9OURrZvOV1Fsfyc/m wZqReYyi7tRDF50M0YXFkinKTRUrwaE= X-Google-Smtp-Source: ABdhPJztM3CJ3iOYu7iop9h5I9wzQNmN0Fz39NAzyl2eikv3cBTtNtGIj9eBcvq+7I31yPnN+78Uug== X-Received: by 2002:a05:600c:1987:b0:392:90f9:98df with SMTP id t7-20020a05600c198700b0039290f998dfmr9241405wmq.72.1650316074788; Mon, 18 Apr 2022 14:07:54 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id q14-20020a1cf30e000000b0038986a18ec8sm14001569wmq.46.2022.04.18.14.07.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Apr 2022 14:07:53 -0700 (PDT) Message-ID: <61f1d11c-d7c5-3b60-3e29-cd70a94a824f@palves.net> Date: Mon, 18 Apr 2022 22:07:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH 5/5] gdbsupport: add path_join function Content-Language: en-US To: Simon Marchi , Lancelot SIX Cc: Simon Marchi , gdb-patches@sourceware.org References: <20220414200137.3479373-1-simon.marchi@polymtl.ca> <20220414200137.3479373-5-simon.marchi@polymtl.ca> <20220415143827.t2nlcfhmh2pondev@ubuntu.lan> <1343c861-94b4-d0e6-67af-dd6eb1f870c3@palves.net> <3f6204cc-514b-9bf7-6b9a-c89151075ede@polymtl.ca> From: Pedro Alves In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2022 21:07:58 -0000 On 2022-04-18 21:55, Simon Marchi wrote: >> On 2022-04-18 15:09, Pedro Alves wrote: >>> On 2022-04-18 19:43, Simon Marchi via Gdb-patches wrote: >>>>> One implementation could be: >>>>> >>>>> /* The real worker can be compiled in a .cc file if you wish. */ >>>>> extern std::string path_join_1 (std::string a, std::string b); >>>>> >>>>> template >>>> std::string >>>>> path_join (std::string a, std::string b, Args... comps) >>>>> { >>>>> return path_join (path_join (a, b), comps...); >>>>> } >>>>> >>>>> template <> >>>>> std::string >>>>> path_join (std::string a, std::string b) >>>>> { >>>>> return path_join_1 (a, b); >>>>> } >>>>> >>>>> I do not pretend this is optimal (it is not). In this POC I pass all >>>>> arguments as std::string and by value, this is probably not what you >>>>> want to do in a production grade implementation, but this just gives the >>>>> overall idea. >>>>> >>>>> What do you think? >>>> If you can make it work using gdb::string_view or const char *, I think >>>> it would be ok. I'll give it a try. But otherwise, I am personally >>>> fine with the sentinel nullptr, given that the compiler gives you a >>>> warning if you forget it. >>> >>> I think it would just work as is you replace std::string with const char * >>> in Lancelot's snippet above. FWIW, I had the same thought as Lancelot >>> about using variable templates instead of varargs. >>> >>> OOC, is there any place in GDB that wants to pass more than two components >>> to path_join? I skimmed the patch and didn't notice one. >> >> I am not aware of one, I'd be happy to make path_join just have two >> parameters and be done with it. > > Actually, I have one use for it in my upcoming DWARF reader changes, > where I join the CU's compilation directory, the directory (from the > line header directory table) and the file name. > > I like Tom's proposal, here: > > https://sourceware.org/pipermail/gdb-patches/2022-April/188016.html > > It seems efficient (no extraneous string copies) and type-safe. I > successfully changed my patch to use it. Lancelot's approach seems more straightforward (trivially changed to use string_view) and would also work, and it avoids creating the temporary array, at the expense of being recursive when you have more than two components to join. Either approach seems good to me. In Tom's approach, I think you could use gdb::array_view in concat.