220 41389 <09ae316c-664f-4508-a8a8-5beaf33c6fcf@isocpp.org> article Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: p groarke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Improving compile times for non-template dependent member functions. Date: Wed, 23 Jan 2019 08:54:10 -0800 (PST) Approved: news@gmane.org Message-ID: <09ae316c-664f-4508-a8a8-5beaf33c6fcf@isocpp.org> References: <6a72db2a-932d-4f79-ab68-7c1424e93b9d@isocpp.org> Reply-To: std-proposals@isocpp.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2849_1044282344.1548262450743" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="152326"; mail-complaints-to="usenet@blaine.gmane.org" To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCVOLFNN5ENRBM5YULRAKGQEKKPSUZY@isocpp.org Wed Jan 23 17:54:18 2019 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f71.google.com ([209.85.161.71]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1gmLn4-000dRy-5Z for gclcip-std-proposals@m.gmane.org; Wed, 23 Jan 2019 17:54:14 +0100 Original-Received: by mail-yw1-f71.google.com with SMTP id f10sf1403563ywc.21 for ; Wed, 23 Jan 2019 08:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to: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=Oql6yJuoKnnn3gHHeylmgZCkaXwrUn0+6VEidwdjSNM=; b=iSUg41hQA7E+Tu4mJ0NAzHLYhyGGvxvsYAqu5q8WFjapmipsiVMlSTRkRq+YnNa9Yw S1xynmgjPwvBcSUJpQmCnrp7L6oFbsANArdFVUoXcdFwbtIuQlmRFA4U0P5Qv8gc6Mou vHv/9axFm8FrKVfXsazNV6AMl7tE1ad+oF+eBRpDsOaUCYyLcVumF4u7ugb/g7oHR5HP ygrnVYb2w4h52NBFzIQ4KAs9zX73xjHY93KqX7BIJ+2OZLtOQJCilGvV0YfZ1x9hjs5k 8S0yt3V/A47e24TyViOdfCqbX9eGuT1fZijSJw+0FAKB7yoNUiiOk/veCXgirMXvcjCi 6svQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to: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=Oql6yJuoKnnn3gHHeylmgZCkaXwrUn0+6VEidwdjSNM=; b=dzB87aMQ4UdgiBIQeA6rnCrGZ/CnAbT4PlS8Ngq/nuVFyUkceYZbrgvdpMBESfUsRg FAvFO3ZXckA1HiHELaUPfbC/hQqjgd9mWdTLQtIJyQHl4IzWolGzdtEjODCl5l5h13ka souOyHLvALoFU3vwxY5DsI0qrxWDQhgJcCJ+QTc8E6e3C2lzmqZsb+b0P85hjrW3NkQ0 ZY16cEeCpXkZI6FCbI0psS4ITmfklvz7Xewj4LnWlg8tBRPmBrWsIM8LRpTpTz1RIT0L ybUkMsdAWvn7b/kzpOic6DZl3yTQ3Gi+9R8u40SJl+KC8LSAuWlotspWzZ6d4+/w0KQd gb3A== 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: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=Oql6yJuoKnnn3gHHeylmgZCkaXwrUn0+6VEidwdjSNM=; b=PLjEczDAoKPRIueyeM5kXSlwrfTOUBuyCLFgnK23afRZ1bJsxr85eKhXAEeRWPRBAV /+rmD7pg2CTSnay3ICr1VAGnHSYFc42oLNJF7R8w4c1T9gOc+41x6KXt3w5Ej2zeHlzI HDskP6JaySXoi9hJV4dlimjZuPgIvlBf4pvnA8L8lds0yqVeT2icztN+dTxCtG6RvAtp NCra7LtRRWf3jU2DFPm92BzeS8BD8ajXzcvJBJ4sv+NsWrFTufTAQ9Dfm7NVBb1B44ae 0NGN9nJbDbMk0SjkIqFyVHJUxLuqBZSHaGASsRCydOJsKLW1Y78ER29rY3a/bDkd/B7U GN/w== X-Gm-Message-State: AJcUukdyTjeOStQP/9Y3W+3NF4Fil0B5dJqD53LSrASuOf/HZ/FmWE31 Szt1Uipqf2PdMsHkvTG9s7IkmQ== X-Google-Smtp-Source: ALg8bN6BztwPe/0Tn0oizBt2DIoBV7pztf2jCed99/DlSyHI4Seo9aQdhqOkPrpcWGQGMZqrRRUGzw== X-Received: by 2002:a25:3a01:: with SMTP id h1mr1117241yba.5.1548262452856; Wed, 23 Jan 2019 08:54:12 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:6d41:: with SMTP id i62ls681662ybc.11.gmail; Wed, 23 Jan 2019 08:54:11 -0800 (PST) X-Received: by 2002:a25:2c92:: with SMTP id s140mr44166ybs.4.1548262451291; Wed, 23 Jan 2019 08:54:11 -0800 (PST) In-Reply-To: X-Original-Sender: philippe.groarke@gmail.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:41389 Archived-At: ------=_Part_2849_1044282344.1548262450743 Content-Type: multipart/alternative; boundary="----=_Part_2850_64177459.1548262450744" ------=_Part_2850_64177459.1548262450744 Content-Type: text/plain; charset="UTF-8" On Wednesday, January 23, 2019 at 11:34:36 AM UTC-5, Andrey Semashev wrote: > > On 1/23/19 7:11 PM, Andrey Semashev wrote: > > On 1/23/19 6:58 PM, p groarke wrote: > >> I'll take a wild guess this has already been asked, thought-of or > >> written about, but lets ask anyways. I'm curious why one cannot write > >> the implementation of non-template dependent member function in a > >> compile unit, in the hopes of improving compile times. > >> > >> For example : > >> > >> .h > >> > >> | > >> template > >> structtest { > >> intval()const; > >> > >> private: > >> intval {42}; > >> T t; > >> }; > >> | > >> > >> > >> .cpp > >> > >> | > >> // I do not depend on T, can implement in compile unit. > >> // Declaration semantics unimportant. > >> inttest::val()const{ > >> returnval; > >> } > >> | > >> > >> > >> I remember a cppcon talk from Ubisoft, where they bypass this issue by > >> inheriting a base class with non-template dependent behavior > >> implemented in their compile unit. Template dependent behavior is > >> implemented in the header of the derived class. > >> Why not offer this compilation behavior out-of-the-box? > > > > I assume, the main reason is that because the method is not instantiated > > until it is ODR-used (e.g. called). This is a useful property, which, in > > fact, may improve compile times if the method body causes a lot of other > > template instantiations or expensive code generation. > > Also, even if val's body does not depend on template parameters of its > class, it is still dependent. test::val are distinct functions for > different Ts. There are also template specializations to consider. > Is it though? Couldn't the compiler mark the function as non-dependent on T, and generate one member function for all test? -- 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/09ae316c-664f-4508-a8a8-5beaf33c6fcf%40isocpp.org. ------=_Part_2850_64177459.1548262450744 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wednesday, January 23, 2019 at 11:34:36 AM UTC-= 5, Andrey Semashev wrote:
On 1/= 23/19 7:11 PM, Andrey Semashev wrote:
> On 1/23/19 6:58 PM, p groarke wrote:
>> I'll take a wild guess this has already been asked, though= t-of or=20
>> written about, but lets ask anyways. I'm curious why one c= annot write=20
>> the implementation of non-template dependent member function i= n a=20
>> compile unit, in the hopes of improving compile times.
>>
>> For example :
>>
>> .h
>>
>> |
>> template<classT>
>> structtest {
>> intval()const;
>>
>> private:
>> intval {42};
>> =C2=A0=C2=A0 =C2=A0 T t;
>> };
>> |
>>
>>
>> .cpp
>>
>> |
>> // I do not depend on T, can implement in compile unit.
>> // Declaration semantics unimportant.
>> inttest::val()const{
>> returnval;
>> }
>> |
>>
>>
>> I remember a cppcon talk from Ubisoft, where they bypass this = issue by=20
>> inheriting a base class with non-template dependent behavior= =20
>> implemented in their compile unit. Template dependent behavior= is=20
>> implemented in the header of the derived class.
>> Why not offer this compilation behavior out-of-the-box?
>=20
> I assume, the main reason is that because the method is not instan= tiated=20
> until it is ODR-used (e.g. called). This is a useful property, whi= ch, in=20
> fact, may improve compile times if the method body causes a lot of= other=20
> template instantiations or expensive code generation.

Also, even if val's body does not depend on template parameters of = its=20
class, it is still dependent. test<T>::val are distinct functions= for=20
different Ts. There are also template specializations to consider.
=C2=A0
Is it though? Couldn't the compi= ler mark the function as non-dependent on T, and generate one member functi= on for all test<T>?

--
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/09ae316c-664f-4508-a8a8-5beaf33c6fcf= %40isocpp.org.
------=_Part_2850_64177459.1548262450744-- ------=_Part_2849_1044282344.1548262450743-- .