220 12935 article Path: news.gmane.org!not-for-mail From: =?UTF-8?B?QWd1c3TDrW4gSy1iYWxsbyBCZXJnw6k=?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: type list indexing Date: Wed, 17 Sep 2014 13:08:56 -0300 Lines: 73 Approved: news@gmane.org Message-ID: References: <541736C0.7040407@gmail.com> <5417436D.4060209@gmail.com> <921715a7-2cf7-45e1-9764-cae5d5aeceec@isocpp.org> <5419ABF3.4010502@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1410970228 10335 80.91.229.3 (17 Sep 2014 16:10:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2014 16:10:28 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD2JZ7PP7QERB27E42QAKGQEQWNP5GY@isocpp.org Wed Sep 17 18:10:21 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XUHoD-0005Sj-6n for gclcip-std-proposals@m.gmane.org; Wed, 17 Sep 2014 18:10:21 +0200 Original-Received: by mail-ie0-f199.google.com with SMTP id y20sf8217082ier.10 for ; Wed, 17 Sep 2014 09:10:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type:content-transfer-encoding; bh=DK7cvPpA9UkIaQrApkGGk98hL27ZqW1y0yhRkktcgTo=; b=g8r3F93Qt+G8/5L4+tS2Djgg9cVnFG589yWjxPNDRufP70gSq7tE2CajR71FW7S3mP jCgRby8tRnF3gDHI8b6ZrrBJ5JapgNrytYs3/cI8a+Se9AYe6N5Jzww1A9FGYGaVueTk 8oOjmXuAYnJA5UXYeIVfEaZwvXL5pGxPTRGu55D05MHI2H/AgSHyu+bNWJ52hZQdtnX1 9xVjvrfS9qHa7z1jYyToOY8imfCiEMujoTj4Y4MSgFn9YJn5dVFHx+xIM3Hl7Bo1NDW/ xbZQ8ozm6vLgyqyubOWqnreuV6pP2HnTOrCLpRut4uPChmd1YM0E6leQL4Fgu2oUU66Z sY+ X-Gm-Message-State: ALoCoQlA58Wmid1DsV7ktSXhqv62LeLBqiZkv+8OiUcJ5BaoV4vHfhOWlDAaEBsC4UB5LnJKH2zh X-Received: by 10.50.92.104 with SMTP id cl8mr21950056igb.1.1410970220289; Wed, 17 Sep 2014 09:10:20 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.105.247 with SMTP id c110ls395866qgf.5.gmail; Wed, 17 Sep 2014 09:10:19 -0700 (PDT) X-Received: by 10.236.222.103 with SMTP id s97mr1371916yhp.106.1410970219334; Wed, 17 Sep 2014 09:10:19 -0700 (PDT) Original-Received: from BLU004-OMC1S32.hotmail.com (blu004-omc1s32.hotmail.com. [65.55.116.43]) by mx.google.com with ESMTPS id hx4si12388386qcb.38.2014.09.17.09.10.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Sep 2014 09:10:19 -0700 (PDT) Received-SPF: pass (google.com: domain of kaballo86@hotmail.com designates 65.55.116.43 as permitted sender) client-ip=65.55.116.43; Original-Received: from BLU436-SMTP238 ([65.55.116.8]) by BLU004-OMC1S32.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22724); Wed, 17 Sep 2014 09:10:19 -0700 X-TMN: [oaJaUoIlc2Is2YgG+8cIpVIO/Eto9RBy] X-Originating-Email: [kaballo86@hotmail.com] Original-Received: from [192.168.1.35] ([190.177.70.57]) by BLU436-SMTP238.smtp.hotmail.com over TLS secured channel with Microsoft SMTPSVC(8.0.9200.16384); Wed, 17 Sep 2014 09:10:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 In-Reply-To: <5419ABF3.4010502@gmail.com> X-OriginalArrivalTime: 17 Sep 2014 16:10:18.0024 (UTC) FILETIME=[DF957A80:01CFD291] X-Original-Sender: kaballo86@hotmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of kaballo86@hotmail.com designates 65.55.116.43 as permitted sender) smtp.mail=kaballo86@hotmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:12935 Archived-At: On 17/09/2014 12:42 p.m., George Makrydakis wrote: > > On 09/16/2014 04:12 AM, Louis Dionne wrote: >> That being said, a valid objection would be the compile-time >> performance of >> std::tuple, which is really bad. I think this is a problem in itself >> and it >> ought to be addressed, but not by introducing a new construct that would >> address this issue only. If you look at Hana's implementation, the dirty >> tricks are very rare [1], and it would be easy to handle some of these >> with >> compiler-dependent intrinsics. > > The compile time performance of the std::tuple class template and its > accompanying std::get function template are shameful /because of the way > they are forced to be implemented due to the lack of language features > as those required by EWG#30 resolution/. Even having individual > parameter access, would make them trivial enough to not be even a > concern during "compile-time". The more you go down the recursive > instantiation and compiler intrinsic path for these things, the less you > are going to be able to have predictable performance between different > compilers - or even uniform behavior. That's why you need this at a > standard level. That sounds like a wild claim, and I would appreciate if you would=20 expand on it a bit. After all, no single piece of `std::tuple` and=20 related facilities is /forced/ to be implemented via recursive template=20 instantiation. Furthermore, considering slow compile-times in heavily=20 templated code nowadays is a direct consequence of name mangling, there=20 would be hardly any benefit from using a language feature as opposed to=20 an efficient library implementation; the same amount of mangling would=20 be involved. >> TL;DR >> For what it's worth, I would favor a well-thought library approach with >> (possibly) a compiler-backed implementation more than a change to the >> core language. >> >> > Sean said Stroustrup himself deliberated on the computational > complexities involved even for individual parameter access in a pack > through a library over a language feature. Given the status of EWG#30, I > seriously see no reason to not have fundamental pack manipulation as a > language feature over any other solution. Especially if it would allow > us to not require a third-party, unpredictably portable library > regardless of how good it actually is. As time goes by, we know more and more ways of avoiding big recursive=20 template instantiations. I would like to say that anything that is not a=20 fold can be implemented without recursion, but that'd be a hard claim to=20 prove. We also know more and more of what actually does cause compile-time=20 performance to drop. Yet, I am not aware of any active effort to avoid=20 or diminish the effect of name mangling in execution time and memory=20 usage during compilation. Regards, --=20 Agust=C3=ADn K-ballo Berg=C3=A9.- http://talesofcpp.fusionfenix.com --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. .