220 38119 <67bd9d4b-cec0-4b20-95c5-1bfe201edc92@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Multiple-Get Method for Containers Date: Thu, 17 May 2018 17:20:30 -0700 (PDT) Lines: 209 Approved: news@gmane.org Message-ID: <67bd9d4b-cec0-4b20-95c5-1bfe201edc92@isocpp.org> References: <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_7839_219147667.1526602830400" X-Trace: blaine.gmane.org 1526602708 6585 195.159.176.226 (18 May 2018 00:18:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 18 May 2018 00:18:28 +0000 (UTC) Cc: wargo.john25@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIM7OHY24CRUBDVRDQKK@isocpp.org Fri May 18 02:18:24 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f200.google.com ([209.85.217.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fJT6D-0001a8-SW for gclcip-std-proposals@m.gmane.org; Fri, 18 May 2018 02:18:22 +0200 Original-Received: by mail-ua0-f200.google.com with SMTP id x24-v6sf5330107ual.21 for ; Thu, 17 May 2018 17:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=9NTNFLpcvRpkXWUsOoR9VnsNHX+hgAMDVUDiS4ZRbAQ=; b=afq6dQqk62MHJ3rCLYHUB8wGg0bdaa/QVsnoLuv6CtBFewonW6zmHcPv62Imwv75KH 61Jg157ZjlwTP2UjSOxDb5cDdUGulQS97xtJNwReELg/GXDong0OQ33ej58ZS2/6kSpr 8jfYqZoDWX555n6fmxBhJy8ruZfb6uYML+koChN9RHteTAxxQWMHxiHiPhRyX7ffXIsa yh8cSpqb78wla3/jULxMbCm9ZqKcuLxAFX5vSK1/pCaikGy4A0OB+GKupjkghJJw4jY2 k+Db/7KJ96lwbiz54I9vYwcNYeWK8SOn1oHPu9pbSv2gwDTmvsD2E7uRnqHFjw7eVozs vdzA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=9NTNFLpcvRpkXWUsOoR9VnsNHX+hgAMDVUDiS4ZRbAQ=; b=JSAcy9TO7DT/f+jip351LR9cMXcs/ur7+OgHid0NTV22mQ99Wn3s15lt73IbV9zHDY IE5mmwzEKGrTbGVN1+7ehYJGFGCEL82w2DCzoQOhiBOWon8vnZz25O+SzUFnQCeSlHPp wyL5WsYrN4zEqqspXZv2pHW5mynNlxC8dHDi/MdOFGRvu9ihKpyuyeeJ1+4IwOsqMkl1 yrxE6qZbxc26O0+Pg+YUntl+vr4vdI/A1SIPMLqB5m+w+MetK0vqIlWXH2sw8GjTsnVf QU8hKVrRhrje/tWRxRD6mjaA7R6vGmYlqW6iuCgshAPKXG8I5qxt6CZeU5J5SJCkaFHF 7nrw== 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:cc:message-id:in-reply-to :references: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=9NTNFLpcvRpkXWUsOoR9VnsNHX+hgAMDVUDiS4ZRbAQ=; b=V4FOaExFbKPshH5oEXTqsTrOdfUvOZnwsQITKFM549nyOWCqcW5ec9jrCblYZTHegB Z5bP661cxpNbRsSM2UT6E3Uul4OZ+FdKV9api6qXVEwsYLIOihtM00VK+UBI440AnedV QdlPHsHo6m/0WjsBfxIvcVKwnlab1w6mES4byIkH23H7hnSOvzN7MALwV9C/sWvlv/F2 OJUTJrs5LVq9IHcxqNEQwXnujH3HSD9WGdOy3paVeX43flLcpEsaOJIX7hePhbm0T0Gl Kk6t39ydovI1Q0VykjOoVvf/H950HwGNSvKTgAk6iGGRkVum8N4BogGOQXAnpMwtl08g 2OBw== X-Gm-Message-State: ALKqPweHFWNzqgPPseQBam8wZBVKzXobiXR0du1G0i1oUOFunKB+kyZ8 rfkpnHC3AOGQaw1HlDR0/rCPfQ== X-Google-Smtp-Source: AB8JxZr42RYOsOcwvPzzZRP95cIBlPuT5OFicj8jePRAduKLm47YFCmDnTv681PwfJdG25NGYRf+Sw== X-Received: by 2002:a9f:3b91:: with SMTP id r17-v6mr4593419uah.118.1526602832589; Thu, 17 May 2018 17:20:32 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a1f:19d6:: with SMTP id 205-v6ls3956498vkz.12.gmail; Thu, 17 May 2018 17:20:31 -0700 (PDT) X-Received: by 2002:a1f:214b:: with SMTP id h72-v6mr991454vkh.2.1526602831187; Thu, 17 May 2018 17:20:31 -0700 (PDT) In-Reply-To: <968e6011-f73e-4cc0-9b5e-7b39fbfcf929@isocpp.org> X-Original-Sender: arthur.j.odwyer@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:38119 Archived-At: ------=_Part_7839_219147667.1526602830400 Content-Type: multipart/alternative; boundary="----=_Part_7840_710818855.1526602830401" ------=_Part_7840_710818855.1526602830401 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wednesday, May 16, 2018 at 5:44:58 PM UTC-7, wargo....@gmail.com wrote: > > I've been sharpening my template machinery lately, and with the recent=20 > advent of structured binding declarations, it occurred to me that an acce= ss=20 > method for containers that was capable of returning multiple values as a= =20 > tuple could be really useful. > > Given that I'm not certain on my phraseology, I think source code would b= e=20 > ideal, so attached is an example of a string splitting function where the= =20 > individual results can be saved off as a structured binding without the u= se=20 > of any temporary variables. > > A few points of discussion (in addition to anything else you guys come up= =20 > with) > > - I did it this time by returning a tuple of values instead of a tuple= =20 > of references, so that they would not be dangling at the end of the sp= lit=20 > function. For more complex types in certain circumstances, there could= be=20 > reason to have a reference version that returns the tuple of reference= s (or=20 > maybe even a move version that moves it's accessed members out with) > =20 > This is the biggest "point of discussion" I see with what you've made. Yo= u=20 write: auto const&[first, last] =3D split("John Smith", " ").get(0,1); What this actually does is: - Construct a vector of all the substrings in the split - Copy two of these substrings into a tuple - Bind `first` and `last` to the elements of this tuple What we'd like it to do is *at least*: - Construct a vector of all the substrings in the split - Copy two of these substrings into a tuple - Bind `first` and `last` to two of these substrings with no extra copies. But if we try returning a tuple, we= =20 run into dangling-reference problems, as you noticed. (And maybe we even want to go further and do something with lazy generators= =20 so that we don't have to allocate that vector to begin with.) I think the idea as implemented here is too inefficient to be suitable for= =20 the STL. Orthogonally, I think the idea is not *useful* enough for the STL either,= =20 but that's a less important and less objective point than the=20 efficiency/lifetime concern. Also, just a nitpick on your metaprogramming: /** Magical Get */ template auto get(std::size_t i, Indices... indices) { return std::tuple_cat(get(i), get(indices...)); } You could write simply /** Magical Get */ template auto get(Indices... indices) { return std::make_tuple(get(indices)...); } and it would have the same effect in all relevant respects, but without the= =20 recursive template instantiations. For prior art in the area of "take a container and produce a new view onto = it by shuffling and/or subsetting its indices," you might want to take a lo= ok at std::valarray's operator[] overloads. =E2=80=93Arthur --=20 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 e= mail 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/67bd9d4b-cec0-4b20-95c5-1bfe201edc92%40isocpp.or= g. ------=_Part_7840_710818855.1526602830401 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, May 16, 2018 at 5:44:58 PM UTC-7, wargo....@= gmail.com wrote:
I've been sharpening my template machinery lately, and with the rece= nt advent of structured binding declarations, it occurred to me that an acc= ess method for containers that was capable of returning multiple values as = a tuple could be really useful.

Given that I'm not c= ertain on my phraseology, I think source code would be ideal, so attached i= s an example of a string splitting function where the individual results ca= n be saved off as a structured binding without the use of any temporary var= iables.

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 th= at they would not be dangling at the end of the split function. For more co= mplex types in certain circumstances, there could be reason to have a refer= ence version that returns the tuple of references (or maybe even a move ver= sion that moves it's accessed members out with)
This is the biggest "point of discussion" I= see with what you've made. You write:

    auto const&[first, last] =3D split("=
;John Smith", " ").get(0,1);

= What this actually does is:
- Construct a vector<string> of= all the substrings in the split
- Copy two of these substrings i= nto a tuple<string, string>
- Bind `first` and `last` to th= e elements of this tuple

What we'd like it to = do is at least:
- Construct a vector<string> of= all the substrings in the split
- Copy two of these substrings i= nto a tuple<string, string>
- Bind `first` and `last` to tw= o of these substrings

with no extra copies. = But if we try returning a tuple<string&, string&>, we run int= o dangling-reference problems, as you noticed.
(And maybe we even= want to go further and do something with lazy generators so that we don= 9;t have to allocate that vector<string> to begin with.)
I = think the idea as implemented here is too inefficient to be suitable for th= e STL.

Orthogonally, I think the idea is not us= eful enough for the STL either, but that's a less important and les= s objective point than the efficiency/lifetime concern.


Also, just a nitpick on your metaprogramming:

  /** Magical Get */
  template<typename... Indices>
  auto get(std::size_t i, Indices... indices)
  {
    return std::tuple_cat(get(i), get(indices...));
  }

You could write simply

  /** Magical Get */
  template<typename... Indices>
  auto get(Indices... indices)
  {
    return std::make_tuple(get(indices)...);
  }

and it would have the same effect in all relevant respects, but = without the recursive template instantiations.

F=
or prior art in the area of "take a container and produce a new view o=
nto it by shuffling and/or subsetting its indices," you might want to =
take a look at std::valarray's operator[] overloads.

=E2=80=93Arthur

--
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/67bd9d4b-cec0-4b20-95c5-1bfe201edc92= %40isocpp.org.
------=_Part_7840_710818855.1526602830401-- ------=_Part_7839_219147667.1526602830400-- .