220 7535 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Fixing the private method issue Date: Wed, 30 Oct 2013 17:02:01 +0200 Lines: 158 Approved: news@gmane.org Message-ID: References: <4dbd20c2-d10d-4e49-985f-dc22281b961b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11367c1c94be9504e9f69ddc X-Trace: ger.gmane.org 1383145322 24203 80.91.229.3 (30 Oct 2013 15:02:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Oct 2013 15:02:02 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRB2V6YSJQKGQERLXPHEQ@isocpp.org Wed Oct 30 16:02:07 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ve0-f198.google.com ([209.85.128.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VbXHX-0007vI-FM for gclcip-std-proposals@m.gmane.org; Wed, 30 Oct 2013 16:02:03 +0100 Original-Received: by mail-ve0-f198.google.com with SMTP id c14sf3375661vea.1 for ; Wed, 30 Oct 2013 08:02:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from: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; bh=CI4VGq9YW4Z7qOy2UcgXbMMkyCI3c6DtysMtgdOzuZQ=; b=JUrTkpNZFTxCK+LvoBOk/T8kOeoXFGUnbbd4RdiXizxdaWtB5ZyTWW3r+xb6dHTxke Zh0E/x/kdsYkPx79oJr2H2/4FVE0KeG+OBndjd2ij0vDloVXtW7F84jg/DjvOcVbg25Q nQUyaIe8Gjd2p1bOPPnpcUwyroGJ+VTiKWwxRFeb5zt8DZr9tp5iV97VCEB4yRdvAULy jI+rmsa+mHaRpmGQSwk0g/gzc5JtWIGoGz91vpd6k3RWz1/+BqVWe460tlAsmAsnqhvj ejqc48y/r84p60DeRImuBJY9p4OQb6yqMlqRAufHJqryVcU0X0lqQ3KimYpK2CfUrQD4 bvtg== X-Gm-Message-State: ALoCoQm3KXBG1+iegnQ7ZZRj+X9Qq6kFVgY7pa9ueue6viEmw+z+FI40e5/lAJvpQ5crGZ90uJUj X-Received: by 10.236.51.170 with SMTP id b30mr4921452yhc.45.1383145322659; Wed, 30 Oct 2013 08:02:02 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.133.201 with SMTP id pe9ls499735qeb.23.gmail; Wed, 30 Oct 2013 08:02:02 -0700 (PDT) X-Received: by 10.224.7.7 with SMTP id b7mr8687530qab.12.1383145322155; Wed, 30 Oct 2013 08:02:02 -0700 (PDT) Original-Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [2607:f8b0:400d:c01::22d]) by mx.google.com with ESMTPS id n2si14870779qac.87.2013.10.30.08.02.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Oct 2013 08:02:02 -0700 (PDT) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c01::22d as permitted sender) client-ip=2607:f8b0:400d:c01::22d; Original-Received: by mail-qc0-f173.google.com with SMTP id l13so851843qcy.18 for ; Wed, 30 Oct 2013 08:02:02 -0700 (PDT) X-Received: by 10.229.106.131 with SMTP id x3mr7410535qco.1.1383145321838; Wed, 30 Oct 2013 08:02:01 -0700 (PDT) Original-Received: by 10.224.11.197 with HTTP; Wed, 30 Oct 2013 08:02:01 -0700 (PDT) In-Reply-To: <4dbd20c2-d10d-4e49-985f-dc22281b961b@isocpp.org> X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c01::22d as permitted sender) smtp.mail=ville.voutilainen@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:7535 Archived-At: --001a11367c1c94be9504e9f69ddc Content-Type: text/plain; charset=ISO-8859-1 On 30 October 2013 16:53, Cassio Neri wrote: > Some suggestions similarly to Billy O'Neal's are given here: > > > https://groups.google.com/forum/?fromgroups#!searchin/comp.lang.c$2B$2B.moderated/Moving$20private$20functions$20to$20opaque$20inner/comp.lang.c++.moderated/GJyXgeEtAOA/PwXSG_ZGeGgJ > > Cheers, > Cassio. > > > > I have also used a solution where I define a public struct for the members of the class and have the members in a private instance of that struct, and then pass a reference to that struct to implementation-file-scope 'private' functions. This way the only private member functions that need to be in the class definition are the ones that are virtual. So, 1) Changing the private method's signature or adding/removing private methods requires everyone including the header to recompile. This is a huge problem for large projects with long recompilation times. - not a problem anymore 2) file static / anonymous namespace definitions in the .cc file cannot be used in the private method's signature. Anything used in the signature must be at least forward declared in the header, adding more symbol pollution. - ditto 3) For shared library interfaces, the private methods are extra unnecessary symbols that have to be managed. - I can use implementation-specific visibility settings for this, so not a problem 4) Private method signatures or even the existence of private methods can depend on the underlying implementation. If the class has multiple implementations (e.g. different platforms), #defines and other conditional compilation mechanisms are required in the header file. - as for 1&2, not a problem 5) Its just bad encapsulation. Callers don't need to know anything about the functions which implement the class behavior. - ditto The tediousness of such a solution is seemingly not big enough to really want a language change, according to my experience. I haven't used an opaque array blob from which the implementation-functions allocate space to the real members. I have considered it a couple of times, but never bothered using it. And it doesn't help much for cases where the size of the blob must increase. The Lakosbook ( http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620) provides further insight for physical design and insulation. -- --- 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 http://groups.google.com/a/isocpp.org/group/std-proposals/. --001a11367c1c94be9504e9f69ddc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 30 October 2013 16:53, Cassio Neri <cassio.neri@gmail.com> wrote:




I have also used a sol= ution where I define a public struct for the members of the class
=
and have the members in a private instance of that struct, and then pa= ss a reference
to that struct to implementation-file-scope 'private' functions. Th= is way the only
private member functions that need to be in t= he class definition are the ones that
are virtual.

So,

1) Changing the private method's signature or adding/re= moving=20 private methods requires everyone including the header to recompile.=20 This is a huge problem for large projects with long recompilation times.
- not a problem anymore

2) file static / anonymous namespace definitions in the .cc file cannot be used in the private method's signature. Anything used in the signature= =20 must be at least forward declared in the header, adding more symbol=20 pollution.

- ditto

3) For shared librar= y interfaces, the private methods are extra unnecessary symbols that have t= o be managed.

- I can use implementation-specific visibil= ity settings for this, so not a problem

4) Private method signatures or even the existence of private methods can=20 depend on the underlying implementation. If the class has multiple=20 implementations (e.g. different platforms), #defines and other=20 conditional compilation mechanisms are required in the header file.

=
- as for 1&2, not a problem

5) Its just ba= d encapsulation. Callers don't need to know anything about the function= s which implement the class behavior.

- ditto

The tediousness of such= a solution is seemingly not big enough to really want a language
change= , according to my experience.

I haven't used an opaqu= e array blob from which the implementation-functions allocate space
to the real members. I have considered it a couple of times, but never both= ered using it. And it
doesn't help much for cases where t= he size of the blob must increase.

provides further insight for physical design and insulation.
=

--
 
---
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-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-proposals/<= /a>.
--001a11367c1c94be9504e9f69ddc-- .