220 24699 article Path: news.gmane.org!not-for-mail From: Igor Baidiuk Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Partial class: a separation of a class interface from its implementation with no memory costs Date: Fri, 26 Feb 2016 06:54:48 -0800 (PST) Lines: 153 Approved: news@gmane.org Message-ID: References: <374600f5-0397-4243-91bc-d01afd145e6c@isocpp.org> <18a10a5c-ff3c-47da-ac10-f04d6898eb42@isocpp.org> <615fbe84-2733-4d78-879f-01ea15f3e267@isocpp.org> <5f31f800-1221-47a8-be6c-e1128e686450@isocpp.org> <2917bf07-c677-4b47-ad4f-a99b7a3f528b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_264_2087037061.1456498488409" X-Trace: ger.gmane.org 1456498497 23843 80.91.229.3 (26 Feb 2016 14:54:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Feb 2016 14:54:57 +0000 (UTC) Cc: daniele.bordes@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDK4F76SSIIBBOOOYG3AKGQEPQRF7HA@isocpp.org Fri Feb 26 15:54:53 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f69.google.com ([209.85.220.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aZJn9-00030j-77 for gclcip-std-proposals@m.gmane.org; Fri, 26 Feb 2016 15:54:51 +0100 Original-Received: by mail-pa0-f69.google.com with SMTP id yy13sf137324381pab.0 for ; Fri, 26 Feb 2016 06:54:50 -0800 (PST) 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:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=4ZepF7EkVOWs2DnQE0KcwjtTp9JUgoW+81C1EstmXZA=; b=O3Mts7m9OrlIb/Y+NIQgG1F0/Dto+LA+i+eIf9f3zakj/A016NoqX3CkMd8E92jnlB fTljvdD0FnvH687HPNKmvoKpkRCEiFKp53MJDrAz3Lh4LGnQEsa4CekT7G1/gW2ZrdvF uN2CyDetcF83mTsk/HgavjBOFXtLUBkLevSjPX1NiHVSjJuFNHa3ZWvTmLx6gJWM0+9Q 4eg4d42eClvkwbyvSlab6Sy6JiQT0P3aho5aoN9K7AbTPw/8POXV4DZbkyIhmiCT89LW Xg80w0nRDn6sBzjqeARkNIAYY6v2wCn8Koo7EosEmu8s6Ut7F8KVsoUaTE+ahXun02vb FQNQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=4ZepF7EkVOWs2DnQE0KcwjtTp9JUgoW+81C1EstmXZA=; b=odveipEWrAE9H9zv4jOVh3TSWIEd/urZAVJKnfJxjDqvP2QJ3ftCzZYtynPxfwpvJ3 vMB18V78qhcwrHoIkd6RwLXmcCQW1F4HSdB2wTSXG5CDwUwn//F817KVEbibstIQLzAv 5HBgvIq7S0NgxFN+IVqYKrCrI2fjps9u6dormtY49RwQuzoFRQ0MUmvYohjr05SM3+Ax xKs8rcDVu0JyY5DHj0sgYiAFmdvJ5sih+2AoncojNLNcoqnIpgmm8RQc+7ezQVfOrPpb rK1dCKilVXngvxwfCHtN1WHSbS3vbnfHsZaLer48Nx4zEd02zPmCAKwySfV/t17jzKaY hSrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=4ZepF7EkVOWs2DnQE0KcwjtTp9JUgoW+81C1EstmXZA=; b=WR3ksxVqshp8ZVMI33GnXMQyz7sOYJnEF/VXC0a/TizrW6juC9yCgQ+i4daGERm77F QTtdLHjlpoahbyANh0z5acTsI67IbluBB5ZLwcjSdcGER1Cr2e5QzojfLyV9F6J6PHy8 T353FwFvg1Nr6VqyhDFk/oU1qOyL2neU8BxI6/9CK9bxyIPSKA/rWTDAva/kbmdbihKm tcSWXcv980M0pjKED9IDMVS0p+lzGyiZ+TnanzKLRuxTNWwJINaGngrzAdkYL9BbIx8T JpIM7X4CdNcZPLOg2bJJCSHNwytNYk0bTc4p0PBsPCFvNHrmHVGoedvSBjZ4x8CsmkcR JqtA== X-Gm-Message-State: AD7BkJIAgryYHXsDTo/ofkHk3Lr3ikpXJPsgnPdHNN1pXe8hUAjfhwmw3QT9wwhwt7Hi1g== X-Received: by 10.66.102.8 with SMTP id fk8mr1386379pab.44.1456498490270; Fri, 26 Feb 2016 06:54:50 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.129.9 with SMTP id c9ls681265iod.26.gmail; Fri, 26 Feb 2016 06:54:49 -0800 (PST) X-Received: by 10.50.97.5 with SMTP id dw5mr3581igb.0.1456498489228; Fri, 26 Feb 2016 06:54:49 -0800 (PST) In-Reply-To: X-Original-Sender: target.san@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:24699 Archived-At: ------=_Part_264_2087037061.1456498488409 Content-Type: multipart/alternative; boundary="----=_Part_265_500166917.1456498488410" ------=_Part_265_500166917.1456498488410 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not comparing them as a challenge. I'm saying that your proposal is a= =20 mere tiny subset of modules proposal Modules: + Public layer isolation. No pollution of importer's namespace with what he= =20 doesn't need. + Compile time reduction, because of shrinking dependencies down to public= =20 layers. + One file per module - 'module' and 'import' syntax instead of #include - all dependents would be still recompiled on public layer change Partials: + Pointer-only dependencies recompiled faster - two headers instead of one - two includes instead of one - compile time is reduced upon amount of parsing private section of class,= =20 and only where only pointer is used - need to keep track on where you need only pointers - yet another keyword On Friday, February 26, 2016 at 2:48:17 PM UTC+2, daniele...@gmail.com=20 wrote: > > You are comparing the two proposals as a challenge, but I have nothing=20 > against the module construct, it sounds powerful. > I am only saying that is does not remove all useless compile dependencies= :=20 > if you argue the the size belongs to the public layer, all the users that= =20 > do not need the size will still suffer from this useless compile dependen= cy. > Actually the users of a class can be split in two groups: those that do= =20 > not create instances of the class and those who do. Only the second need= =20 > the size, but not the first, which therefore do not need to be recompiled= =20 > when the private part of the used class (and as consequence, the size) is= =20 > modified. > > Il giorno venerd=C3=AC 26 febbraio 2016 13:34:06 UTC+1, Igor Baidiuk ha s= critto: >> >> Very simple. First, compiler is able to generate some kind of header fro= m=20 >> module, which contains only public layer (including struct sizes, but no= t=20 >> exact layout of private parts). Having this, no one prohibits compiler f= rom=20 >> shrinking this info to "pointer-only" public layer, if needed. As a resu= lt,=20 >> no need for yet another language construct. >> >> I, on my side, can't see benefits from your proposal. Compared to=20 >> modules, you propose compile time improvement at the expense of language= =20 >> complexity and additional typing and bookkeeping. Where, this compile ti= me=20 >> improvement would happen only full static interface vs pointer-only=20 >> interface. So, would _this_ _additional_ improvement be _that_ big to=20 >> counter language complexity it introduces? Please note that=20 >> pointer-dependent interface will have high chances to change anyway=20 >> whenever any modification happens inside module - because of inlining,= =20 >> functions layout, etc. >> >> --=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/e8079d91-db89-4d84-bc22-cbcde3a06936%40isocpp.or= g. ------=_Part_265_500166917.1456498488410 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not comparing them as a challenge. I'm saying = that your proposal is a mere tiny subset of modules proposal
Modules:+ Public layer isolation. No pollution of importer's namespace with wh= at he doesn't need.
+ Compile time reduction, because of shrinking d= ependencies down to public layers.
+ One file per module
- 'modul= e' and 'import' syntax instead of #include
- all dependents = would be still recompiled on public layer change
Partials:
+ Pointer-= only dependencies recompiled faster
- two headers instead of one
- tw= o includes instead of one
- compile time is reduced upon amount of parsi= ng private section of class, and only where only pointer is used
- need = to keep track on where you need only pointers
- yet another keyword
<= br>On Friday, February 26, 2016 at 2:48:17 PM UTC+2, daniele...@gmail.com w= rote:
You are = comparing the two proposals as a challenge, but I have nothing against the = module construct, it sounds powerful.
I am only saying that is does not = remove all useless compile dependencies: if you argue the the size belongs = to the public layer, all the users that do not need the size will still suf= fer from this useless compile dependency.
Actually the users of a class = can be split in two groups: those that do not create instances of the class= and those who do. Only the second need the size, but not the first, which = therefore do not need to be recompiled when the private part of the used cl= ass (and as consequence, the size) is modified.

Il giorno venerd=C3= =AC 26 febbraio 2016 13:34:06 UTC+1, Igor Baidiuk ha scritto:
Very simple. First, compiler is = able to generate some kind of header from module, which contains only publi= c layer (including struct sizes, but not exact layout of private parts). Ha= ving this, no one prohibits compiler from shrinking this info to "poin= ter-only" public layer, if needed. As a result, no need for yet anothe= r language construct.

I, on my side, can't see benefits from you= r proposal. Compared to modules, you propose compile time improvement at th= e expense of language complexity and additional typing and bookkeeping. Whe= re, this compile time improvement would happen only full static interface v= s pointer-only interface. So, would _this_ _additional_ improvement be _tha= t_ big to counter language complexity it introduces? Please note that point= er-dependent interface will have high chances to change anyway whenever any= modification happens inside module - because of inlining, functions layout= , etc.

--
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/e8079d91-db89-4d84-bc22-cbcde3a06936= %40isocpp.org.
------=_Part_265_500166917.1456498488410-- ------=_Part_264_2087037061.1456498488409-- .