220 7564 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 03:06:39 +0100 Lines: 438 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=001a1132f26ad2bfea04ea505d1a X-Trace: ger.gmane.org 1383530794 5899 80.91.229.3 (4 Nov 2013 02:06:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Nov 2013 02:06:34 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD35NAXJW4GBBMEC3SJQKGQETB2ZXWA@isocpp.org Mon Nov 04 03:06:41 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f69.google.com ([209.85.215.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vd9Yv-0001Cu-02 for gclcip-std-proposals@m.gmane.org; Mon, 04 Nov 2013 03:06:41 +0100 Original-Received: by mail-la0-f69.google.com with SMTP id n7sf2372629lam.0 for ; Sun, 03 Nov 2013 18:06:40 -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=8SWmn2bHHc3FeQL+ybAfuDgDqoVZjS8RocOabhusyB4=; b=ZdNhrT6lrZjZsR8rW642ILHk0UFvNGvSFXia74/mO/zyshBKu5Z0s3iERA8z4v4ls/ jMAv4VyJUPyZYmvBGabITxAZ69pKxsYP/3fDJMr34jqQFmrwkmechXzWDAESn1WZ7NAM 7jCZtmPbKVBuxehCfRC4W3sz7+G5jmmY1mdtPJ54cAiuNPfSHrGR8jP5X9qfY70UI+P+ NBrVORRC4l62+AItvdMRBJwUa2TF9TFQBvSp6o2CjZ2wKnyiTtUC9T3XxLVwtpQ9TIoK +yxaWvQyJqO+AX+u3g/1BM1GH2g9B2e2B3bO5M5UVRK73s5UGEdYpROyXhfVvTPSAcIH khRg== X-Gm-Message-State: ALoCoQm62J16TVFwc371Ii7Hk47tFzv8fV1k/ysZj8bJqnyex/10SW4T6ME8UXi7YSCO7yEQFrON X-Received: by 10.112.150.161 with SMTP id uj1mr2412507lbb.0.1383530800561; Sun, 03 Nov 2013 18:06:40 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.185.49 with SMTP id ez17ls410644wic.22.gmail; Sun, 03 Nov 2013 18:06:39 -0800 (PST) X-Received: by 10.204.244.7 with SMTP id lo7mr7795765bkb.23.1383530799683; Sun, 03 Nov 2013 18:06:39 -0800 (PST) Original-Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [2a00:1450:4010:c04::233]) by mx.google.com with ESMTPS id b2si2477028bko.97.2013.11.03.18.06.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 18:06:39 -0800 (PST) Received-SPF: pass (google.com: domain of p.stephani2@gmail.com designates 2a00:1450:4010:c04::233 as permitted sender) client-ip=2a00:1450:4010:c04::233; Original-Received: by mail-lb0-f179.google.com with SMTP id w6so4947987lbh.38 for ; Sun, 03 Nov 2013 18:06:39 -0800 (PST) X-Received: by 10.152.10.99 with SMTP id h3mr10230086lab.13.1383530799217; Sun, 03 Nov 2013 18:06:39 -0800 (PST) Original-Received: by 10.112.9.235 with HTTP; Sun, 3 Nov 2013 18:06:39 -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::233 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:7564 Archived-At: --001a1132f26ad2bfea04ea505d1a Content-Type: text/plain; charset=ISO-8859-1 Their destructor is public. However, there can exist classes with protected nonvirtual destructors (that allow dynamic dispatch for calling but not for destruction). I'm not sure whether a restriction should be made to only allow private nonvirtual functions outside the class definition -- a rule could be added that the class layout may not be different for any nonzero number of virtual functions, and the compiler could signal an error if a virtual function is to be added to a class whose definition doesn't contain any virtual functions. In general I guess modules can solve this problem in a more generic way. 2013/11/4 Billy O'Neal > 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/. > -- --- 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/. --001a1132f26ad2bfea04ea505d1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Their destructor is public. However, there can exist class= es with protected nonvirtual destructors (that allow dynamic dispatch for c= alling but not for destruction).
I'm not sure whether a restriction= should be made to only allow private nonvirtual functions outside the clas= s definition -- a rule could be added that the class layout may not be diff= erent for any nonzero number of virtual functions, and the compiler could s= ignal an error if a virtual function is to be added to a class whose defini= tion doesn't contain any virtual functions.
In general I guess modules can solve this problem in a more generic wa= y.


2013/11/4 Billy O'Neal <billy.oneal@gmail.com>
Actually that's a good = point -- most of the iostreams classes' virtual functions are all priva= te, for example. The functions added in a single translation unit would hav= e 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/.

=

--
=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>.
--001a1132f26ad2bfea04ea505d1a-- .