220 38114 <968e6011-f73e-4cc0-9b5e-7b39fbfcf929@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: wargo.john25@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Multiple-Get Method for Containers Date: Wed, 16 May 2018 17:44:58 -0700 (PDT) Lines: 159 Approved: news@gmane.org Message-ID: <968e6011-f73e-4cc0-9b5e-7b39fbfcf929@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1926_772052566.1526517898731" X-Trace: blaine.gmane.org 1526517775 23756 195.159.176.226 (17 May 2018 00:42:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 17 May 2018 00:42:55 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD47H3VV3MNRBDFB6PLQKGQEMXB3MUA@isocpp.org Thu May 17 02:42:51 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fJ70M-00062g-Hf for gclcip-std-proposals@m.gmane.org; Thu, 17 May 2018 02:42:50 +0200 Original-Received: by mail-vk0-f69.google.com with SMTP id h62-v6sf2411109vke.1 for ; Wed, 16 May 2018 17:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=OIHn7hwLvrPsCx3dF33ZnLNM3jzeMTDJyqnu53Po5sk=; b=Nr76IWkm+wIVn/7NIryLJyFh9AIEvAJpjoSzewxnb+si1OJv0Y7vaolont3uqQIsiQ rlcytqO2KrxXicythxcB3t1MCtA6eolCqfet4qC4To7iJokdryaBoX6Uw6zbVUplfkuq hiXrJB45ORuQHKiQHZJ0Jj8xx85dZ8Jx9QgyLsB2NgOmlTePsKtCdloOeelqpdhApfZ2 XPi51tkr02rpgdRvEgZjE7500urXjk3ahhrCFgiTvTa162ebJlUCpkvVUAaR5OzUFW5j 0HgtliogSUteBd8x9v/3+VbZ1qSxjgtRKRUTUJQwOCT7fusM8yNWMh81qhjV/5e/JSQ4 2oOg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=OIHn7hwLvrPsCx3dF33ZnLNM3jzeMTDJyqnu53Po5sk=; b=P7dO6cnPZc9ZBs63o9oNGQa5RUdk996W8cyXu0ZH1RsYuv0T2x4st8u4SeH9p3eBBE tiNqXhhuktpmGSOMHxDqROZyeyWhCElYmFd3HXBoEv7MfJwUrOmvN23LZsBJMdqaDlFm SROidX5bWVld3wP2GGIcoNJEi1rhRMqb94PxTm++dkNERZK+At1p54WRT1/3ZXPRUC1A yKEHrv7j7gC9e/DBpicJMqzR7nSn+PzB1URAnY/MG1LEkB4f3OSHTBITvUv5HTk43CDv 2YUnYw65R6q+DVDkdLrI2HFF7JEgLAKeD3qouS4eTOl1ljPRNGJowFz7SwGHFkDYAb3G 6+kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=OIHn7hwLvrPsCx3dF33ZnLNM3jzeMTDJyqnu53Po5sk=; b=DKnbbl5c9k7m1qSEjPM3cgP/OVv0pg2A2yCuz9/BaoyFlmVDLw8LpJzmATNrtpjA0y duuN7aT+YugobLWz2SoyHVV4Ywc1+ZnPzFTiSz499zzZz6qpp6zgl2U7s+W+iYkcdnAR ZAH460+snS10xoojzl3HJDCLyLlL1fe5zyRVcOOenDYOksgJ01uvXoTMCQylPqO+qTHA L21eK9L7atG07c7v+4ezXwTzih+inpzB0L3ONDFaEhddvmX17Dlk6h/MVnthNC4hANp1 86ZSanCnIxFc7Vnx1qVtMMMxPyEooy+IGAbOcYSHFFEvmkydqCkB6HW7+jf5uj7XJl2G aHpQ== X-Gm-Message-State: ALKqPwc1dPiF7S1+MVxn4TIFe9iE9Y/R7Or95/2ggrg7WRA2kP17x8Qn ST5ShLng5Rs70MZuOnR7/faTYg== X-Google-Smtp-Source: AB8JxZqlZy1wcok7uE7F1isqAT0L58L4vxsK4tTsrJpOoodl2pl/TDgNRi36BwCHD/eAj6fo+Fj6Mg== X-Received: by 2002:ab0:1b6d:: with SMTP id n45-v6mr2592445uai.12.1526517901082; Wed, 16 May 2018 17:45:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a1f:9745:: with SMTP id z66-v6ls2517328vkd.4.gmail; Wed, 16 May 2018 17:45:00 -0700 (PDT) X-Received: by 2002:a1f:3095:: with SMTP id w143-v6mr415855vkw.9.1526517899513; Wed, 16 May 2018 17:44:59 -0700 (PDT) X-Original-Sender: wargo.john25@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:38114 Archived-At: ------=_Part_1926_772052566.1526517898731 Content-Type: multipart/alternative; boundary="----=_Part_1927_734465151.1526517898732" ------=_Part_1927_734465151.1526517898732 Content-Type: text/plain; charset="UTF-8" I've been sharpening my template machinery lately, and with the recent advent of structured binding declarations, it occurred to me that an access method for containers that was capable of returning multiple values as a tuple could be really useful. Given that I'm not certain on my phraseology, I think source code would be ideal, so attached is an example of a string splitting function where the individual results can be saved off as a structured binding without the use of any temporary variables. A few points of discussion (in addition to anything else you guys come up with) - I did it this time by returning a tuple of values instead of a tuple of references, so that they would not be dangling at the end of the split function. For more complex types in certain circumstances, there could be reason to have a reference version that returns the tuple of references (or maybe even a move version that moves it's accessed members out with) - I used 'get' as the method name, because it almost lends itself to an overload of the tuple version of get, where you could get multiple values out of a tuple with the same syntax. - Vectors don't have a tuple-like get method (for good reason), and they could definitely benefit from this, so maybe leaving it as a member function is the best idea - I'm sure with a little playing there's a way to get the bracket operators to take a tuple/init_list of indices, at which point `auto const& [first, last] = split(...)[{0,1}]` would work, *might* be more natural - The existing `.at()` function could *easily* be adopted to do this too, but it has performance drawbacks, so I almost never use it in production code... All in all, I think this fits nicely with the recent addition of structured binding declarations, so I wanted to throw it out here as a possible addition to the STL. I don't see it possibly conflicting with anything that's already implemented, and it's really easy to implement itself, but then again maybe it's not as cool as I thought, or maybe I missed something. Thoughts? -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/968e6011-f73e-4cc0-9b5e-7b39fbfcf929%40isocpp.org. ------=_Part_1927_734465151.1526517898732 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've been sharpening my template machinery lately, and= with the recent advent of structured binding declarations, it occurred to = me that an access method for containers that was capable of returning multi= ple values as a tuple could be really useful.

Given that= I'm not certain on my phraseology, I think source code would be ideal,= so attached is an example of a string splitting function where the individ= ual results can be saved off as a structured binding without the use of any= temporary variables.

A few points of discussion (= in addition to anything else you guys come up with)
  • = I did it this time by returning a tuple of values instead of a tuple of ref= erences, so that they would not be dangling at the end of the split functio= n. For more complex types in certain circumstances, there could be reason t= o have a reference version that returns the tuple of references (or maybe e= ven a move version that moves it's accessed members out with)
  • I used 'get' as the method name, because it almost lends itsel= f to an overload of the tuple version of get, where you could get multiple = values out of a tuple with the same syntax.
    • Vectors don't h= ave a tuple-like get method (for good reason), and they could definitely be= nefit from this, so maybe leaving it as a member function is the best idea<= /li>
  • I'm sure with a little playing there's a way to get th= e bracket operators to take a tuple/init_list of indices, at which point `a= uto const& [first, last] =3D split(...)[{0,1}]` would work, might=C2=A0be more natural
    • The existing `.at()` function could e= asily=C2=A0be adopted to do this too, but it has performance drawbacks,= so I almost never use it in production code...
All in a= ll, I think this fits nicely with the recent addition of structured binding= declarations, so I wanted to throw it out here as a possible addition to t= he STL.
I don't see it possibly conflicting with anythi= ng that's already implemented, and it's really easy to implement it= self, but then again maybe it's not as cool as I thought, or maybe I mi= ssed something.

Thoughts?

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/968e6011-f73e-4cc0-9b5e-7b39fbfcf929= %40isocpp.org.
------=_Part_1927_734465151.1526517898732-- ------=_Part_1926_772052566.1526517898731 Content-Type: text/x-c++src; charset=UTF-16LE; name=MultiGetVector.cpp Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=MultiGetVector.cpp X-Attachment-Id: 99335f28-dea6-4886-b315-8a3058d3925e Content-ID: <99335f28-dea6-4886-b315-8a3058d3925e> //4jAGkAbgBjAGwAdQBkAGUAIAA8AHMAdAByAGkAbgBnAD4ADQAKACMAaQBuAGMAbAB1AGQAZQAg ADwAdAB1AHAAbABlAD4ADQAKACMAaQBuAGMAbAB1AGQAZQAgADwAaQBvAHMAdAByAGUAYQBtAD4A DQAKACMAaQBuAGMAbAB1AGQAZQAgADwAdgBlAGMAdABvAHIAPgANAAoADQAKAHQAZQBtAHAAbABh AHQAZQA8AHQAeQBwAGUAbgBhAG0AZQAgAFQAPgANAAoAYwBsAGEAcwBzACAATQB1AGwAdABpAEcA ZQB0AFYAZQBjAHQAbwByACAAOgAgAHAAdQBiAGwAaQBjACAAcwB0AGQAOgA6AHYAZQBjAHQAbwBy ADwAVAA+AA0ACgB7AA0ACgBwAHUAYgBsAGkAYwA6AA0ACgAgACAALwAqACoAIABJAG4AaABlAHIA aQB0ACAAQwBvAG4AcwB0AHIAdQBjAHQAbwByACAAKgAvAA0ACgAgACAAdQBzAGkAbgBnACAAcwB0 AGQAOgA6AHYAZQBjAHQAbwByADwAVAA+ADoAOgB2AGUAYwB0AG8AcgA7AA0ACgANAAoAIAAgAC8A KgAqACAAUwB0AGEAbgBkAGEAcgBkACAARwBlAHQAIAAqAC8ADQAKACAAIABzAHQAZAA6ADoAdAB1 AHAAbABlADwAVAA+ACAAZwBlAHQAKABzAHQAZAA6ADoAcwBpAHoAZQBfAHQAIABpACkADQAKACAA IAB7AA0ACgAgACAAIAAgAHIAZQB0AHUAcgBuACAAewAoACoAdABoAGkAcwApAFsAaQBdAH0AOwAN AAoAIAAgAH0ADQAKAA0ACgAgACAALwAqACoAIABNAGEAZwBpAGMAYQBsACAARwBlAHQAIAAqAC8A DQAKACAAIAB0AGUAbQBwAGwAYQB0AGUAPAB0AHkAcABlAG4AYQBtAGUALgAuAC4AIABJAG4AZABp AGMAZQBzAD4ADQAKACAAIABhAHUAdABvACAAZwBlAHQAKABzAHQAZAA6ADoAcwBpAHoAZQBfAHQA IABpACwAIABJAG4AZABpAGMAZQBzAC4ALgAuACAAaQBuAGQAaQBjAGUAcwApAA0ACgAgACAAewAN AAoAIAAgACAAIAByAGUAdAB1AHIAbgAgAHMAdABkADoAOgB0AHUAcABsAGUAXwBjAGEAdAAoAGcA ZQB0ACgAaQApACwAIABnAGUAdAAoAGkAbgBkAGkAYwBlAHMALgAuAC4AKQApADsADQAKACAAIAB9 AA0ACgB9ADsADQAKAA0ACgAvACoAKgANAAoAIAAqACAAQABwAGEAcgBhAG0AIABzAHQAcgAgACAA IAAgACAAIAAgAFMAdAByAGkAbgBnACAAdABvACAAcwBwAGwAaQB0AA0ACgAgACoAIABAAHAAYQBy AGEAbQAgAGQAZQBsAGkAbQBpAHQAIAAgACAAUwB0AHIAaQBuAGcAIAB0AG8AIABzAHAAbABpAHQA IABvAG4ADQAKACAAKgAvAA0ACgBNAHUAbAB0AGkARwBlAHQAVgBlAGMAdABvAHIAPABzAHQAZAA6 ADoAcwB0AHIAaQBuAGcAPgAgAHMAcABsAGkAdAAoAHMAdABkADoAOgBzAHQAcgBpAG4AZwAgAGMA bwBuAHMAdAAmACAAcwB0AHIALAAgAHMAdABkADoAOgBzAHQAcgBpAG4AZwAgAGMAbwBuAHMAdAAm ACAAZABlAGwAaQBtAGkAdAApAA0ACgB7AA0ACgAgACAATQB1AGwAdABpAEcAZQB0AFYAZQBjAHQA bwByADwAcwB0AGQAOgA6AHMAdAByAGkAbgBnAD4AIAByAGUAcwB1AGwAdAB7AHMAdAByAH0AOwAN AAoADQAKACAAIABmAG8AcgAoAHMAdABkADoAOgBzAGkAegBlAF8AdAAgAHAAbwBzACAAPQAgAHIA ZQBzAHUAbAB0AC4AYgBhAGMAawAoACkALgBmAGkAbgBkACgAZABlAGwAaQBtAGkAdAApADsADQAK ACAAIAAgACAAIAAgAHAAbwBzACAAIQA9ACAAcwB0AGQAOgA6AHMAdAByAGkAbgBnADoAOgBuAHAA bwBzADsADQAKACAAIAAgACAAIAAgAHAAbwBzACAAPQAgAHIAZQBzAHUAbAB0AC4AYgBhAGMAawAo ACkALgBmAGkAbgBkACgAZABlAGwAaQBtAGkAdAApACkADQAKACAAIAB7AA0ACgAgACAAIAAgAHMA dABkADoAOgBzAHQAcgBpAG4AZwAgAHQAZQBtAHAAIAA9ACAAcgBlAHMAdQBsAHQALgBiAGEAYwBr ACgAKQAuAHMAdQBiAHMAdAByACgAcABvAHMAIAArACAAZABlAGwAaQBtAGkAdAAuAHMAaQB6AGUA KAApACkAOwANAAoAIAAgACAAIAByAGUAcwB1AGwAdAAuAGIAYQBjAGsAKAApAC4AZQByAGEAcwBl ACgAcABvAHMAKQA7AA0ACgAgACAAIAAgAHIAZQBzAHUAbAB0AC4AcAB1AHMAaABfAGIAYQBjAGsA KAB0AGUAbQBwACkAOwANAAoAIAAgAH0ADQAKAA0ACgAgACAAcgBlAHQAdQByAG4AIAByAGUAcwB1 AGwAdAA7AA0ACgB9AA0ACgANAAoAaQBuAHQAIABtAGEAaQBuACgAKQANAAoAewANAAoAIAAgAGEA dQB0AG8AIABjAG8AbgBzAHQAJgBbAGYAaQByAHMAdAAsACAAbABhAHMAdABdACAAPQAgAHMAcABs AGkAdAAoACIASgBvAGgAbgAgAFMAbQBpAHQAaAAiACwAIAAiACAAIgApAC4AZwBlAHQAKAAwACwA MQApADsADQAKACAAIABzAHQAZAA6ADoAYwBvAHUAdAAgADwAPAAgACIARgBpAHIAcwB0ACAATgBh AG0AZQAgADoAIAAiACAAPAA8ACAAZgBpAHIAcwB0ACAAPAA8ACAAIgBcAG4AIgA7AA0ACgAgACAA cwB0AGQAOgA6AGMAbwB1AHQAIAA8ADwAIAAiAEwAYQBzAHQAIABOAGEAbQBlACAAIAA6ACAAIgAg ADwAPAAgAGwAYQBzAHQAIAA8ADwAIAAiAFwAbgAiADsADQAKACAAIABzAHQAZAA6ADoAYwBvAHUA dAAgADwAPAAgAHMAdABkADoAOgBlAG4AZABsADsADQAKAH0ADQAKAA== ------=_Part_1926_772052566.1526517898731-- .