220 7562 article Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Fixing the private method issue Date: Mon, 4 Nov 2013 02:44:45 +0100 Lines: 278 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=001a11c23c8883a5ce04ea500f02 X-Trace: ger.gmane.org 1383529481 25775 80.91.229.3 (4 Nov 2013 01:44:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Nov 2013 01:44:41 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD35NAXJW4GBBDXY3OJQKGQENIW552Q@isocpp.org Mon Nov 04 02:44:48 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f197.google.com ([209.85.212.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vd9Dj-0006J9-Ly for gclcip-std-proposals@m.gmane.org; Mon, 04 Nov 2013 02:44:47 +0100 Original-Received: by mail-wi0-f197.google.com with SMTP id f4sf4630842wiw.4 for ; Sun, 03 Nov 2013 17:44:47 -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: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=3fYKhK0El6ATOwQjXkGBiXMNmawcTIsGXVxksvl5R0w=; b=BG1CzpGZEmFWQzSzMckDXvqoDYDwpj2YKuBcH1KsIFAWo+8Cjsb3whnJFIDUnv9yu5 /94dVLU5yqe/nSnR6ssJfkq6GEm4L7TCVOWRwFKTASvneNrJ9qkfOCNE9UrvqNzOXNXo Ugwb75jDcbDULRNS1ARvz1B8BkZbg8cUxaZDCLTZ//47ZwxUtBTlqe7TnDwPzoB7hCRz NIAWBArmSGis/wguC1/8tKgy89KRxNsQMKGW3w+IoQ9nFu15ZSzr2VHbkw5wbCcc3CH5 jFfWbk/knlQx4y+iVKNFJ+FDR+3Y1K5mobwwYC2VMksUrojRofwCaMXAQkhGoeetRiHT HjyA== X-Gm-Message-State: ALoCoQkg/KIA1N/7i5iVuIIqiHtVZ69TwdPKRCyJJacrqtgIHDu9a4+skbowXPAAFVnTOr//b6wH X-Received: by 10.180.90.196 with SMTP id by4mr5388861wib.2.1383529486959; Sun, 03 Nov 2013 17:44:46 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.218.130 with SMTP id pg2ls406379wic.41.canary; Sun, 03 Nov 2013 17:44:46 -0800 (PST) X-Received: by 10.205.15.72 with SMTP id pt8mr7714564bkb.17.1383529486035; Sun, 03 Nov 2013 17:44:46 -0800 (PST) Original-Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [2a00:1450:4010:c04::236]) by mx.google.com with ESMTPS id yh8si2466728bkb.232.2013.11.03.17.44.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 17:44:46 -0800 (PST) Received-SPF: pass (google.com: domain of p.stephani2@gmail.com designates 2a00:1450:4010:c04::236 as permitted sender) client-ip=2a00:1450:4010:c04::236; Original-Received: by mail-lb0-f182.google.com with SMTP id w6so4918021lbh.41 for ; Sun, 03 Nov 2013 17:44:45 -0800 (PST) X-Received: by 10.112.168.170 with SMTP id zx10mr9494120lbb.0.1383529485410; Sun, 03 Nov 2013 17:44:45 -0800 (PST) Original-Received: by 10.112.9.235 with HTTP; Sun, 3 Nov 2013 17:44:45 -0800 (PST) In-Reply-To: X-Original-Sender: p.stephani2@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of p.stephani2@gmail.com designates 2a00:1450:4010:c04::236 as permitted sender) smtp.mail=p.stephani2@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:7562 Archived-At: --001a11c23c8883a5ce04ea500f02 Content-Type: text/plain; charset=ISO-8859-1 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/. --001a11c23c8883a5ce04ea500f02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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/.

--
 
---
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>.
--001a11c23c8883a5ce04ea500f02-- .