220 24451 article Path: news.gmane.org!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: [tuple] extracting tuples out of a tuple Date: Wed, 17 Feb 2016 12:43:46 -0500 Lines: 86 Approved: news@gmane.org Message-ID: References: <7e08b6c5-853c-471e-b248-a9df7e8e27be@isocpp.org> <67c3c86d-3089-4f07-878a-3f3e706744df@isocpp.org> <42a29c5b-07e4-4e36-bab4-03a7e86ff905@isocpp.org> <6e02dbfe-01f3-4840-92ab-bcc8f7824348@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1455731050 27331 80.91.229.3 (17 Feb 2016 17:44:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Feb 2016 17:44:10 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBBXHCSK3AKGQE5NKOS5Q@isocpp.org Wed Feb 17 18:43:58 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f199.google.com ([209.85.217.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aW68s-0006Mx-01 for gclcip-std-proposals@m.gmane.org; Wed, 17 Feb 2016 18:43:58 +0100 Original-Received: by mail-lb0-f199.google.com with SMTP id h8sf5262213lbh.3 for ; Wed, 17 Feb 2016 09:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=to:from:subject:date:lines:message-id:references:mime-version :content-type:user-agent:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Q8un9z71seG92I3HUZfUgaz4Knj1+Cvvqc/dzDyoFcE=; b=LSpocNRSCxkUtxLUCU2FsULljAT3qNf6quLFDzrpsi0RFfr7una2KPfQS3jzhB6jzv IgnqnoF9RXPHaTOWG5aWaIKs4KUIbzN+AbYttryB+rajCb/FX273tXodP1dMbm15qZPk 0aEIxhMzGisQYwvzC+17k/f7yaDXikGXRoosFLq8yqMBcEl/9SF5fpEhQ2BZBexSS9WN +FI44wF0WE/2YDvU8P4AFrrthPEhh1kwK76+lAJFeFzyHvFi6a2qSvCWrjHYEgUdOxFO mIczhIaCF6muflpUpjdf6pNxY4Hj0AK7esPj5gXZEdLPYLq9rZa1F88/gE7Gr9PZlnKN F23 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:date:lines:message-id:references :mime-version:content-type:user-agent:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Q8un9z71seG92I3HUZfUgaz4Knj1+Cvvqc/dzDyoFcE=; b=SrERnyDm7TiG8VHnKsWh1rgk2soehV+W5/4i0PIvW+z9oniUqr9pf5FCnZIFZxxing pCK/tlhRf4rf9KwqtQyEJMG5mo4rYcLKKZPUe+zZEP5vi1pbI40kVUAn3h9WxHtEjiV/ boep6t30EVcbUW6v+1tJjGzzuAs+IoVHXnmrFA1tr6dykOscW/xUxTBs6wiKYKe0hH1H b3MD5XQl7bOX6j0qKT5U0uBlxN8Nu7edvTQqg3v5X8d90d4HA/UH8cT7EqgB6Ko4E402 lspIazGCaVE9hUy5ol7mHMmObeA1Pun1Yron+hzTD8lzESzFQIlQgM+3elUXrvZw2Xtx X-Gm-Message-State: AG10YOT9w2Yc9Z9a//JQf3AS/iUWyWl23T8KP56J0zVGJ7X2rUopIpG2iMwlwcftgDZscQ== X-Received: by 10.194.62.69 with SMTP id w5mr467549wjr.5.1455731037255; Wed, 17 Feb 2016 09:43:57 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.165.203 with SMTP id o194ls951255lfe.39.gmail; Wed, 17 Feb 2016 09:43:55 -0800 (PST) X-Received: by 10.112.161.198 with SMTP id xu6mr1323487lbb.131.1455731035804; Wed, 17 Feb 2016 09:43:55 -0800 (PST) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id mz3si1485051lbb.158.2016.02.17.09.43.55 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 17 Feb 2016 09:43:55 -0800 (PST) Received-SPF: pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aW68m-0006J4-60 for std-proposals@isocpp.org; Wed, 17 Feb 2016 18:43:52 +0100 Original-Received: from tripoint.kitware.com ([66.194.253.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Feb 2016 18:43:52 +0100 Original-Received: from mwoehlke.floss by tripoint.kitware.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Feb 2016 18:43:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 77 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tripoint.kitware.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: X-Original-Sender: mwoehlke.floss@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) smtp.mailfrom=gclcip-std-proposals@m.gmane.org; dmarc=fail (p=NONE dis=NONE) header.from=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:24451 Archived-At: On 2016-02-16 18:57, Louis Dionne wrote: > What happens when a function is called with a large number of > arguments performance-wise? If performance is important, it might be > better to pass the actual tuple instead of its unpacked > representation, but that would call for a benchmark. I see a couple cases here: 1. For whatever reason, you have arguments to a non-template function in a tuple-like, and want to use them to invoke a function. (Might happen with RPC's. *Definitely* happens when dealing with linear algebra vectors, when the function takes N floats/doubles, but you have a vector-type of some sort.) 2. You need to pass a tuple-like to a function that could take a tuple. 3. You need to pass a bunch of values to a template function that will do something with each value. For #1, it's not really relevant; the reason you're unpacking in the first place is almost certainly because you can't change the API being called to take the struct in the first place, or because there is no reason to do so. Performance is probably not an issue, and you likely aren't dealing with "many" values anyway. For #2, passing a tuple instead of a bunch of values may require constructing a tuple from a tuple-like. That may indeed be worthwhile, but you may need unpacking to construct the tuple in the first place. For #3, you may need unpacking to make use of the tuple that was received. You almost certainly will if the function takes an arbitrary tuple-like. I definitely agree with your point here. I just don't see it as a good argument why unpacking isn't needed (although it may affect *where* unpacking is used). > On Tuesday, 16 February 2016 18:19:00 UTC-5, Nicol Bolas wrote: >> On Tuesday, February 16, 2016 at 3:21:29 PM UTC-5, Louis Dionne wrote: >>> You could write >>> >>> auto x = hana::fold_left(hana::transform(tpl, inner), std::plus<>{}); >> >> And for people who natively read right to left, this would probably be >> decent. But that's not how the rest of C++ works. > > Wtf? How is this different from writing > > auto x = ranges::accumulate(ranges::transformed(...), std::plus<>{}); You missed the point. It's different from: auto x = inner([:]tpl) + ...; ....which is MUCH more terse, and (to me, anyway) very easy to read and understand. > the point I'm trying to make is that from the point of view of a > metaprogramming library writer, this proposal, in its current form, > misses the goal just like fold expressions did. As Nicol also pointed out, improved metaprogramming was never an explicit goal. The first, most important goal is to be able to write: foo([:]tpl...); Secondary goals are being able to slice in unpacking assignments, and being able to use a tuple-like in parameter pack based fold expressions, especially `expr << ... << [:]tpl;`. If it also helps metaprogramming, that's an added bonus. That's not 90+% of C++ users, though. -- Matthew -- --- 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. Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/. .