Path: csiph.com!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Ian Collins Newsgroups: comp.std.c++ Subject: Re: Proposal: Compilation-unit scoped private member functions Date: Fri, 14 Dec 2012 09:19:33 -0800 (PST) Organization: unknown Lines: 123 Sender: std-cpp-request@vandevoorde.com Approved: stephen.clamage@oracle.com Message-ID: References: NNTP-Posting-Host: Bp5MCe/vVPnza0QIJIAmNPUPus0nTENagEUhR6E+EPQ= Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Trace: news.albasani.net HE8synhDKh2qbnVrixLcESy+mFovit9RFGHjwgmIwLQwCWjCMoHWbBx+96Zk008AtnGlT3kcDx37MeIozBDx/A== X-Complaints-To: abuse@albasani.net NNTP-Posting-Date: Fri, 14 Dec 2012 17:19:09 +0000 (UTC) X-Mailer: Perl5 Mail::Internet v2.05 X-Submission-Address: std-cpp-submit@vandevoorde.com Cancel-Lock: sha1:i+7xYG6YdepedVwzeEBdvK+Uagk= X-Original-Date: Sun, 02 Dec 2012 00:08:41 +1300 Xref: csiph.com comp.std.c++:565 kfsone@googlemail.com wrote: > I'd like to propose a relatively minor language change that would help with code-hygiene in two main senses: > . Encourage compartmentalization (break large functions up into named fragments), > . Encourage privacy and encapsulation (conceal the compartmentalization from the public API), > > The intent is something closer to c-style "static" for member functions, i.e giving them compilation-unit scope. > > In addition to being treated as both a private member function and compilation-unit private (akin to a c-style static), the following would also be applied: > > . Cannot be virtual, > . Cannot be abstract, > . Cannot be exposed via "friend" status, > . Cannot be an operator, > . Cannot share a /name/ with a publicly-defined member regardless of argument fingerprint, > . Not visible to derived classes even if they are in the same compilation unit. > > ---Foo.h--- > class Foo > { > #include > public: > Foo() : m_string(""), m_int(0) {} > > void bigFunction(); > > void otherFunction(); > > private: > void privateFunction(); > > private: > std::string m_string; > unsigned int m_int; > }; > ---Foo.h--- > > ---Foo1.cpp--- > #include "Foo.h" > > // Member function with compilation-unit scope only. > private void Foo::helper1() > { > m_string = "Hello"; > m_int = 1; > } > > // Prototype flavor. > private void Foo::helper42() const; > > // Declared in the public Foo definition. > void Foo::bigFunction() > { > helper1(); // aka this->helper1(); > /* ... */ > helper42(); // aka this->helper42(); > } > > void Foo::helper42() const // I would prefer to require you to type 'private void Foo::helper42()' but this is consistent with use of static/inline etc. > { > m_string = "World"; > m_int = 42; > } > > class Bar : public Foo > { > void barFunction() > { > helper1(); // INVALID: helper1 is NOT inherited. > } > }; > ---Foo1.cpp--- > > ---Foo2.cpp--- > #include "Foo.h" > > private void Foo::helper1() > { > // OK: the helper1() in Foo1.cpp is not visible here; > // this definition has zero bearing on Foo1.cpp. > } > > // INVALID: There is a "privateFunction" definition in the class. > private void Foo::privateFunction(int, float, char, std::string&); > > void Foo::privateFunction() // Publicly-defined version from Foo.h > { > helper1(); // OK: Calls the Foo2.cpp Foo::helper1() > helper42(); // INVALID: Foo::helper42() is scoped to Foo1.cpp. > } > > private int& Foo::GetI() { return m_i; } > > void GetIFromFoo(Foo* foo) { return foo->GetI(); } // INVALID. GetI is private to Foo. > ---Foo2.cpp--- > > > How should I go about submitting a standard change request for something like this? > > > Background: > > Currently many C++ programmers revert to one of these approaches to implementing complex/lengthy member functions: > > 1. Write huge, unwieldy member functions that become incredibly difficult to validate / test / document, Your proposal would not improve testability, the locally private functions would, by virtue of their linkage, be impossible to test. It is better to split the functionality into smaller objects than to design a class with member function that end up doing too much (with results in the bloated code you describe earlier). I can see some merit in the suggestion, but it looks to much like a crutch for bad design rather than a cure... -- Ian Collins [ comp.std.c++ is moderated. To submit articles, try posting with your ] [ newsreader. If that fails, use mailto:std-cpp-submit@vandevoorde.com ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]