220 7563 article Path: news.gmane.org!not-for-mail From: "Billy O'Neal" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Fixing the private method issue Date: Sun, 3 Nov 2013 17:56:07 -0800 Lines: 365 Approved: news@gmane.org Message-ID: References: <8d5f90be-ed45-4b42-9ddd-d6e2497c8166@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e015388488dccfc04ea503a8d X-Trace: ger.gmane.org 1383530206 878 80.91.229.3 (4 Nov 2013 01:56:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Nov 2013 01:56:46 +0000 (UTC) To: std-proposals Original-X-From: std-proposals+bncBDKLBLVE6ADBBYH53OJQKGQEGF2ICIY@isocpp.org Mon Nov 04 02:56:53 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vd9PP-00045L-0G for gclcip-std-proposals@m.gmane.org; Mon, 04 Nov 2013 02:56:51 +0100 Original-Received: by mail-ob0-f198.google.com with SMTP id wp18sf21288762obc.9 for ; Sun, 03 Nov 2013 17:56:50 -0800 (PST) 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:from:date :message-id:subject: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=O3CYX3dvvdGzO0W3AyjNcJ7wze7ILEdLQqPrOXu15e4=; b=B9jmsmeRYEqebxS1G48YTtHuCW9RENcm9YoENyhY3pTN0T0Sbi+15GcvzdRCX0+X8B hDkGALarXwr8W0KkMt8A23k39gPEDtec/2WHQY9+va7vLnHdkZ/myujx19OAMKF0c90h 7Mnd7DsaTjheUQnD85AkWhIcM0GbQ5LocNLL6rofW36Ngn0e/GHpeHSFjme131QMT4yN gs4U4SYlY/cXx9GqPFy2AYGATUodeZRvEBufeCq6UoxElAtdhSRDmhONs5VtRD77nclJ SWjxNYFlVcAWSVK84Vq2I01OsXQG396nqPo+4dItJR/PX9A6bHzLNM6M+ACM7bsV1U+W zC/Q== X-Gm-Message-State: ALoCoQnF8z78KrNQ27waj2Abg4IfuEHIrkU5TvWSnI0huBpwC6AYHCZkhPDIQC2bq4+rhbQco8SR X-Received: by 10.43.93.5 with SMTP id bs5mr3681135icc.6.1383530209956; Sun, 03 Nov 2013 17:56:49 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.64.38 with SMTP id l6ls2068746qes.89.gmail; Sun, 03 Nov 2013 17:56:48 -0800 (PST) X-Received: by 10.236.210.49 with SMTP id t37mr11691343yho.46.1383530208270; Sun, 03 Nov 2013 17:56:48 -0800 (PST) Original-Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [2607:f8b0:4003:c02::231]) by mx.google.com with ESMTPS id k26si4890843yha.242.2013.11.03.17.56.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 17:56:48 -0800 (PST) Received-SPF: pass (google.com: domain of billy.oneal@gmail.com designates 2607:f8b0:4003:c02::231 as permitted sender) client-ip=2607:f8b0:4003:c02::231; Original-Received: by mail-oa0-f49.google.com with SMTP id j10so6611802oah.36 for ; Sun, 03 Nov 2013 17:56:47 -0800 (PST) X-Received: by 10.182.55.65 with SMTP id q1mr12143753obp.2.1383530207495; Sun, 03 Nov 2013 17:56:47 -0800 (PST) Original-Received: by 10.182.87.37 with HTTP; Sun, 3 Nov 2013 17:56:07 -0800 (PST) In-Reply-To: X-Original-Sender: billy.oneal@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of billy.oneal@gmail.com designates 2607:f8b0:4003:c02::231 as permitted sender) smtp.mail=billy.oneal@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:7563 Archived-At: --089e015388488dccfc04ea503a8d Content-Type: text/plain; charset=ISO-8859-1 Actually that's a good point -- most of the iostreams classes' virtual functions are all private, for example. The functions added in a single translation unit would have to be non-virtual. Billy O'Neal https://github.com/BillyONeal/ http://stackoverflow.com/users/82320/billy-oneal Malware Response Instructor - BleepingComputer.com On Sun, Nov 3, 2013 at 5:44 PM, Philipp Stephani wrote: > Adding a virtual member functions to a class without other virtual member > functions does change the class layout. (I guess classes whose virtual > member functions are all private don't occur in practice though.) > > > > 2013/11/4 Billy O'Neal > >> Private member *data* does need to be declared in the class definition so >> that callers know what size to lay out for the object. Private member >> *functions* do not. >> >> Billy O'Neal >> https://github.com/BillyONeal/ >> http://stackoverflow.com/users/82320/billy-oneal >> Malware Response Instructor - BleepingComputer.com >> >> >> On Sun, Nov 3, 2013 at 1:39 PM, wrote: >> >>> Maybe not intuitive, but this is by design. For performance reasons, the >>> compiler needs to know the layout of a struct, and it can only do that if >>> the definition is visible. Any workarounds require an indirection AFAIK, as >>> does implementing this as standard behavior. If you want hiding and abi >>> compatibility use the PIMPL idiom for private data. But realize that it >>> adds an extra indirection. >>> >>> -Tim >>> >>> >>> On Wednesday, October 30, 2013 4:39:17 AM UTC+1, fmatth...@gmail.comwrote: >>>> >>>> There is one major wart in C++ class design, and that is with private >>>> member functions required to be in the class definition. >>>> >>>> This has a number of problems: >>>> 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. >>>> 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. >>>> 3) For shared library interfaces, the private methods are extra >>>> unnecessary symbols that have to be managed. >>>> 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. >>>> 5) Its just bad encapsulation. Callers don't need to know anything >>>> about the functions which implement the class behavior. >>>> >>>> The only private declarations that should be required in the header are >>>> declarations required by the compiler. I believe all of those are: >>>> 1) Private data members (sizeof()) >>>> 2) Private virtual methods (for inheriting) >>>> 3) Private non-virtual methods called by inline functions. >>>> >>>> One way to do this would be to extend the friend feature. We could >>>> define friend functions within the body of member functions. It might look >>>> like this: >>>> >>>> //foo.hh >>>> >>>> class Foo { >>>> public: >>>> void doWork(); >>>> private: >>>> int _f; >>>> } >>>> >>>> //foo.cc >>>> static void doWorkHelper(Foo* f) { >>>> doSomethingWith(f->_f); >>>> }; >>>> >>>> void Foo::doWork() { >>>> friend void doWorkHelper(Foo*); >>>> >>>> doWorkHelper(this); >>>> } >>>> >>>> This has potential for abuse of course, but it would finally allow us >>>> to limit the list of declarations in the class definition to the bare >>>> minimum required by the compiler. When it comes to defining interfaces, >>>> less is always more. >>>> One other use of this feature could be to add a backdoor for unit tests. >>>> >>>> Thoughts? >>>> >>> -- >>> >>> --- >>> 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/. >>> >> >> -- >> >> --- >> 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/. >> > > -- > > --- > 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/. > -- --- 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/. --089e015388488dccfc04ea503a8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Actually that's a good point -- most of the iostreams = classes' virtual functions are all private, for example. The functions = added in a single translation unit would have to be non-virtual.

Billy O'Neal
Malware Response Instructor - BleepingComputer.com


On Sun, Nov 3, 2013 at 5:44 PM, Philipp = Stephani <p.stephani2@gmail.com> wrote:
Adding a virtual member functions to a class without other= virtual member functions does change the class layout. (I guess classes wh= ose virtual member functions are all private don't occur in practice th= ough.)



2013/11/4 Bil= ly O'Neal <billy.oneal@gmail.com>
Private member *data* does need to be declared in the clas= s definition so that callers know what size to lay out for the object. Priv= ate member *functions* do not.

Billy O'Neal
Malware Response Instructor - BleepingComputer.com


On Sun, Nov 3, 2013 at 1= :39 PM, <shadowdrak@gmail.com> wrote:
Maybe not intuitive, but this is by design. For performanc= e reasons, the compiler needs to know the layout of a struct, and it can on= ly do that if the definition is visible. Any workarounds require an indirec= tion AFAIK, as does implementing this as standard behavior. If you want hid= ing and abi compatibility use the PIMPL idiom for private data. But realize= that it adds an extra indirection.

-Tim


On Wednesday, October 30, 2013 4:= 39:17 AM UTC+1, fm= atth...@gmail.com wrote:
There is one major wart in C++ class design, and that is w= ith private member functions required to be in the class definition.
This has a number of problems:
1) Changing the priva= te method's signature or adding/removing private methods requires every= one including the header to recompile. This is a huge problem for large pro= jects with long recompilation times.
2) file static / anonymous namespace definitions in the .cc file canno= t be used in the private method's signature. Anything used in the signa= ture must be at least forward declared in the header, adding more symbol po= llution.
3) For shared library interfaces, the private methods are extra unnece= ssary symbols that have to be managed.
4) Private method signatur= es or even the existence of private methods can depend on the underlying im= plementation. If the class has multiple implementations (e.g. different pla= tforms), #defines and other conditional compilation mechanisms are required= in the header file.
5) Its just bad encapsulation. Callers don't need to know anything= about the functions which implement the class behavior.

The only private declarations that should be required in the header = are declarations required by the compiler. I believe all of those are:
1) Private data members (sizeof())
2) Private virtual method= s (for inheriting)
3) Private non-virtual methods called by inlin= e functions.

One way to do this would be to extend= the friend feature. We could define friend functions within the body of me= mber functions. It might look like this:

//foo.hh

class Foo {
=A0 pu= blic:
=A0 =A0 void doWork();
=A0 private:
=A0= =A0 int _f;
}

//foo.cc
static= void doWorkHelper(Foo* f) {
=A0 doSomethingWith(f->_f);
};

void Foo= ::doWork() {
=A0 friend void doWorkHelper(Foo*);

=A0 doWorkHelper(this);
}

This has pot= ential for abuse of course, but it would finally allow us to limit the list= of declarations in the class definition to the bare minimum required by th= e compiler. When it comes to defining interfaces, less is always more.
One other use of this feature could be to add a backdoor for unit test= s.

Thoughts?
<= /div>

--
=A0
---
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/gro= up/std-proposals/.

--
=A0
---
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/gro= up/std-proposals/.

--
=A0
---
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/gro= up/std-proposals/.

--
 
---
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>.
--089e015388488dccfc04ea503a8d-- .