220 7604 <9ce77e08-d9eb-48d0-969b-3aae833a3708@isocpp.org> article Path: news.gmane.org!not-for-mail From: fmatthew5876@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Fixing the private method issue Date: Wed, 6 Nov 2013 04:21:52 -0800 (PST) Lines: 703 Approved: news@gmane.org Message-ID: <9ce77e08-d9eb-48d0-969b-3aae833a3708@isocpp.org> References: <5eeafd6f-32f3-4281-9374-617af852fe21@isocpp.org> <2bc74340-d319-4725-92dd-5b95b59db7c8@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_112_33179426.1383740512646" X-Trace: ger.gmane.org 1383740513 16941 80.91.229.3 (6 Nov 2013 12:21:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Nov 2013 12:21:53 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBYPI5CJQKGQE2UAR6VY@isocpp.org Wed Nov 06 13:21:58 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f199.google.com ([209.85.214.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ve27Q-000287-Pl for gclcip-std-proposals@m.gmane.org; Wed, 06 Nov 2013 13:21:57 +0100 Original-Received: by mail-ob0-f199.google.com with SMTP id gq1sf32007705obb.10 for ; Wed, 06 Nov 2013 04:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=sX1bXk+oxmK2RUAJHJnJ9ehvrZWows3ye/3xcfmhpTQ=; b=t50kxDPbnIrI6SEXfuRPngOWxumjbZucnZi9L4wW3oVF8nXFB9vYOYNFSs8bLtmuGv KMrqeaSyo+EzX8l5qZlCv6PZKwmbMi4CX3gVCs8RiQS6BvMBrQKUoBHy6jsWHNNveuFM fRiq4Kc3sRV6udNzh6MD+tUTXJoq9mD0aqdc77BZJuFLnaJSHscIeL5vct+A46meEAOQ NGsamHxTyYiGAVS+OzoqrafSLGdcI+4fkumc3sIo3oVwHe/r5gWUsGiic3Lqubb0ukoO QqsbJ4An6toldjytR1WGGS2pDPkCcWyxhaNVwFlf07krnfZaeQYigv1MkjJFFmp8aZiF bnHw== 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:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=sX1bXk+oxmK2RUAJHJnJ9ehvrZWows3ye/3xcfmhpTQ=; b=gHkRgtUIx2yL9bOymh6t2s8hgEKeIuUSSQ7cuqMVviuY3gfg5TM45JsL4iuIZe16OP 3vhXkQpec1TTLepK2P9GVDNVGTYEV2dLaERz42CqYFnoyWoqSHVWWmR1n6HaS6d8m/Hw lgLO6PgbUUV/sGgLrhnUfmA4Z7QS0A+I8h6ThLNrc7IhWi5YzF7L2zSOPRqhbW5QNwF7 I2ZBvkrb5CAQGdG3byIMTB1pqj4yLbrtotmiI0TPzoRU07fRDZRYf2VTk1BhTDcZDClI BmlE6rs2eY8ePdgHaAnMuZgKIxFxAs5ZBVkTU0oD1k8JFdP4uFM4K5EX/FXZsEdCBVPK cJiw== X-Gm-Message-State: ALoCoQleBZchibXZpTRzaumXhwrsuaqhDx7N2qqY6lsIxtZ6BXWDeQ3fYt8bHT1iMB9wY924L5VH X-Received: by 10.182.213.5 with SMTP id no5mr900593obc.15.1383740515162; Wed, 06 Nov 2013 04:21:55 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.5.99 with SMTP id r3ls618827qer.88.gmail; Wed, 06 Nov 2013 04:21:53 -0800 (PST) X-Received: by 10.49.41.70 with SMTP id d6mr53498qel.10.1383740513112; Wed, 06 Nov 2013 04:21:53 -0800 (PST) In-Reply-To: <2bc74340-d319-4725-92dd-5b95b59db7c8@isocpp.org> X-Original-Sender: fmatthew5876@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:7604 Archived-At: ------=_Part_112_33179426.1383740512646 Content-Type: text/plain; charset=ISO-8859-1 On Wednesday, October 30, 2013 12:12:10 AM UTC-4, Billy O'Neal wrote: > > Unit tests that test non-public data are bad (brittle) unit tests. Break up those classes! :) 99% of the time I agree, however there are some cases where it is unavoidable. One example is optimizations. For example, perhaps your class is a template that is optimized for POD types. The effect may not actually be visible from the public interface, in which case you may need to dig into the private interface to ensure the optimization triggers for all of the right cases and works as expected. Right now this is impossible to do without doing horrible things like adding extra public methods, friend declarations, or making everything protected and inheriting. All of these are horrible. On Wednesday, October 30, 2013 11:02:01 AM UTC-4, Ville Voutilainen wrote: > > > 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. This works but I'm not sure I like it as it exposes another public symbol. The other trick is the private nested class with static methods. No symbols are exposed to the user but this is still a coupling of the class definition with the private member implementations. Whoever implements the private methods, regardless of how many C files are used is restricted to using this one nested class. On Sunday, November 3, 2013 8:44:45 PM UTC-5, 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.) Actually all virtual functions with the exception of the destructor should almost always be private. This is the non-virtual idiom. http://www.gotw.ca/publications/mill18.htm On Sunday, November 3, 2013 12:10:17 PM UTC-5, mitc...@gmail.com wrote: > > I've been thinking about a new proposal for a "class implementation namespace", This is pretty interesting. One potential abuse is that if anyone wants to just avoid your public interface they can open the namespace and hack in something. I could see horrible last minute bug fixes being implemented this way. Still, access control is just a tool for allowing us to write better interfaces, if people want to do stupid things we don't need to be responsible for them. The friend idea I proposed limits the access control to the implementation of member functions. Only someone writing the actual member functions can extend the access control out to another function. On Sunday, November 3, 2013 9:06:39 PM UTC-5, Philipp Stephani wrote: > > 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. As suggested by others, virtual functions must be in the class definition. Every part of the interface which is exposed to users must be in the class definition, it should not be spread out and makes little sense to do so. More on that later. On Monday, November 4, 2013 12:56:11 AM UTC-5, Thiago Macieira wrote: > > Well, the one thing I'd want is to have a real static (as in file-local) > method, to control my exports. > > I know all the techniques. But I am forced to use compiler extensions in order > to control the list of exports from my TUs and libraries, to degrading the > linkers' performances due to way too many symbols. I was under the impression that static and anonymous namespace functions don't export symbols even in single object files. In fact the function may be removed entirely or even sliced up into callable pieces if the compiler decides to inline it everywehre. With regards to the general problem of symbol visibility, that's probably something that would probably involve [attributes] and is outside of this discussion entirely. On Monday, November 4, 2013 8:18:22 AM UTC-5, Olaf van der Spek wrote: > > Not entirely true. In general, callers don't need to know the layout. The layout is (only?) required when accessing data members, the size is only required when creating an object on the stack. > Not requiring private data members in the header would be nice too IMO. But how would you compute the size without knowing the layout? You need to know the layout for padding. Also, what real use is knowing the size without knowing the layout. As soon as you change a data member your callers will need to recompile anyway as the size will change. On Monday, November 4, 2013 2:41:35 PM UTC-5, Thiago Macieira wrote: > > Maybe the solution will come with modules, when we can finally have a > standardised syntax for "this method is called by other modules" versus "this > method is never called externally" Maybe, maybe not. What are modules? When will they become available? We have no idea. I'd like a workable solution to this problem now. I'd like to focus the discussion a bit. Lets agree on some invariants. The following must remain in the class definition. * data members with any access control. * virtual methods with any access control. * public and protected non-virtual methods, they are part of the interface. * private non-virtual methods called by inline functions, for obvious reasons. Maybe someone can come up with a good reason to break one of these but I don't want to discuss it here. If you're passionate about that then please start a new thread. Not only are there hard implementation reasons for these, restricting the external interface to a single point, namely the class interface is an extremely powerful constraint in terms of usability and readability. I don't need to chase down multiple header files, source files, and documentation, I just need to see one class definition and it has everything I need to know as a possible user of the class (using directly or inheriting). The only thing I don't need to know about is how many functions are used to implement its behavior, and those are the non-virtual private methods we are discussing. So far we have 2 suggestions, declaring friends in function bodies and having a class namespace. Here's another, simply define allow a syntax to define new private methods outside of the class definition. These methods should *always* be private and therefore only callable by other class methods. What we don't want is to allow people to start writing public or protected extension methods, making interfaces impossibly complicated. This allows easy extensibility and also keeps the interface constrained to whats in the definition. class Foo { public: Foo(int i); }; //explicitly define a new private method which is not in the class body explicit void Foo::_foo() { } //explicitly define a new private constructor, callable by other constructors explicit Foo::Foo() { } //Define the public constructor which calls the explicit private one using delegation explicit Foo::Foo(int i) : Foo() { } I like this better than the namespace proposal, because with the namespace, you have this problem: class Foo namespace { //Hundreds of lines of code //Wait, is this an extension method or a normal function? I have to look for the namespace tags. void foo(); }; Also if the only thing that's going in your namespace is function definitions, do you really need to create a scope for that? I always prefer to use static for file local functions instead of anonymous namespaces. I use anonymous namespaces for file local global variables and class definitions. The namespace idea however would allow you to define other things such as private nested types and typedefs. I also like it better than the friend proposal, because adding friend to already cluttered function bodies is hard to read and rather intelligent. Its also not obvious looking at a function knowing whether or not something else has declared it as a friend. -- --- 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/. ------=_Part_112_33179426.1383740512646 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wednesday, October 30, 2013 12:12:10 AM UTC-4, Bi= lly O'Neal wrote:
>
> Unit tests that= test non-public data are bad (brittle) unit tests. Break up those classes!= :)


99% of the time I agree, however there are some= cases where it is
unavoidable. One example is optimization= s. For example, perhaps your
class is a template that is op= timized for POD types. The effect may
not actually be visib= le from the public interface, in which case you
may need to= dig into the private interface to ensure the optimization
triggers for all of the right cases and works as expected.

<= span style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684= px;">Right now this is impossible to do without doing horrible things like<= /span>
adding extra public methods, friend declarations, or making= everything
protected and inheriting. All of these are horr= ible.

On Wednesday, October 30, 2013 11:02:01 AM UTC-4,= Ville Voutilainen wrote:
>
><= br style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px= ;">> I have also used a solution where I define a public struct fo= r the members of the class
> and have the members in a p= rivate 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= ..


This works but I'm not sure I like it as it expos= es another public symbol.

The other trick is the privat= e nested class with static methods. No
symbols are exposed = to the user but this is still a coupling of the
class defin= ition with the private member implementations.
Whoever impl= ements the private methods, regardless of how many C files
are used is restricted to using this one nested class.

On Sunday, November 3, 2013 8:44:45 PM UTC-5, 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 occ= ur in practice though.)


Actually all virtual functi= ons with the exception of the destructor
should almost alwa= ys be private. This is the non-virtual idiom.
http://www.gotw.ca/publications/mill18.htm

On Sunday, November 3, 2013 12:10:17 PM UTC-5,=  mitc...@gmail.com wrote:
>
>    I've been= thinking about a new proposal for a "class implementation namespace",
<= br>
This is pretty interesting. One potential abuse is that = if anyone
wants to just avoid your public interface they ca= n open the namespace
and hack in something. I could see hor= rible last minute bug fixes
being implemented this way. Sti= ll, access control is just a tool for
allowing us to write = better interfaces, if people want to do stupid
things we do= n't need to be responsible for them.

The friend idea I = proposed limits the access control to the
implementation of= member functions. Only someone writing the actual
member f= unctions can extend the access control out to another
funct= ion.

On Sunday, November 3, 2013 9:06:39 PM UTC-5, Phil= ipp Stephani wrote:
>
> I'm not sure = whether a restriction should be made to only allow private nonvirtual funct= ions outside the class definition -- a rule could be added that the class l= ayout 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.
=

As suggested by others, virtual functions must be in the clas= s
definition. Every part of the interface which is exposed = to users must
be in the class definition, it should not be = spread out and makes
little sense to do so. More on that la= ter.


On Monday, November 4, 2013 12:56:11 AM UTC-5,= Thiago Macieira wrote:
>
> Well, the= one thing I'd want is to have a real static (as in file-local)
<= span style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684= px;">> method, to control my exports.
>
> I know all the techniques. But I am forced to use compiler extensio= ns in order
> to control the list of exports from my TUs= and libraries, to degrading the
> linkers' performances= due to way too many symbols.


I was under the impre= ssion that static and anonymous namespace
functions don't e= xport symbols even in single object files. In fact
the func= tion may be removed entirely or even sliced up into callable

<= span style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684= px;">With regards to the general problem of symbol visibility, that's
probably something that would probably involve [attributes] and = is
outside of this discussion entirely.

On Monday, November 4, 2013 8:18:22 AM UTC-5, Olaf van der Spek wrote:
>
> Not entirely true. In general, calle= rs don't need to know the layout. The layout is (only?) required when acces= sing data members, the size is only required when creating an object on the= stack.
> Not requiring private data members in the head= er would be nice too IMO.


But how would you compute= the size without knowing the layout? You
need to know the = layout for padding. Also, what real use is knowing
the size= without knowing the layout. As soon as you change a data
member your callers will need to recompile anyway as the size will<= br style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px= ;">change.

 On Monday, November 4, 2013 2:41= :35 PM UTC-5, Thiago Macieira wrote:
>
> Maybe the solution will come with modules, when we can finally have a=
> standardised syntax for "this method is called by oth= er modules" versus "this
> method is never called extern= ally"


Maybe, maybe not. What are modules? When will= they become available?
We have no idea. I'd like a workabl= e solution to this problem now.


I'd like to focus t= he discussion a bit. Lets agree on some invariants.
The f= ollowing must remain in the class definition.
* data member= s with any access control.
* virtual methods with any acces= s control.
* public and protected non-virtual methods, they= are part of the interface.
* private non-virtual methods c= alled by inline functions, for obvious reasons.

Maybe= someone can come up with a good reason to break one of these butI don't want to discuss it here. If you're passionate about that the= n
please start a new thread.

Not only a= re there hard implementation reasons for these, restricting
the external interface to a single point, namely the class interface
is an extremely powerful constraint in terms of usability and
readability. I don't need to chase down multiple header files= , source
files, and documentation, I just need to see one c= lass definition and
it has everything I need to know as a p= ossible user of the class
(using directly or inheriting). T= he only thing I don't need to know
about is how many functi= ons are used to implement its behavior, and
those are the n= on-virtual private methods we are discussing.

So far we= have 2 suggestions, declaring friends in function bodies and
having a class namespace.

Here's another, simply def= ine allow a syntax to define new private
methods outside of= the class definition. These methods should *always*
be pr= ivate and therefore only callable by other class methods. What wedon't want is to allow people to start writing public or protected
extension methods, making interfaces impossibly complicated.= This
allows easy extensibility and also keeps the interfac= e constrained to
whats in the definition.

<= span style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684= px;">class Foo {
  public:
  Foo(= int i);
};

//explicitly define a new pr= ivate method which is not in the class body
explicit void F= oo::_foo() {
}

//explicitly define a ne= w private constructor, callable by other constructors
expli= cit Foo::Foo() {
}

//Define the public = constructor which calls the explicit private one
using dele= gation
explicit Foo::Foo(int i) : Foo() {
}

I like this better than the namespace proposal, beca= use with the
namespace, you have this problem:
class Foo namespace {

//Hundreds of lines of code

//Wait, is this an extension method or a normal function= ? I have to look for the namespace tags.
void foo();

};
Also if the only thing = that's going in your namespace is function
definitions, do = you really need to create a scope for that? I always
prefe= r to use static for file local functions instead of anonymous
namespaces. I use anonymous namespaces for file local global variables
and class definitions.

The namespace idea howe= ver would allow you to define other things such as private nested types and= typedefs.

I also like it better than the friend proposal, bec= ause adding friend
to already cluttered function bodies is = hard to read and rather
intelligent. Its also not obvious l= ooking at a function knowing
whether or not something else = has declared it as a friend.

--
 
---
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>.
------=_Part_112_33179426.1383740512646-- .