Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c++ > #560

Proposal: Compilation-unit scoped private member functions

Show all headers | View raw

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 <string>
     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,
2. Split the functions into potentially dozens of member functions, all of which are then exposed as "private:" in the public class definition,
3. Split the functions into dozens of static functions which are not member scoped and thus need to be friended or other encapsulation breaking mechanisms,
4. Use the Pimpl solution which leads to lots of noisy, useless boilerplate code.

C#'s "partial" class concept allows you to solve this by writing non-public member functions only in the compilation unit where they are needed. The downside being that they aren't really "private" to the compilation unit, and unless you declare the class "sealed" anyone can come along and add to it - a complete burst of the encapsulation bubble.

This approach retains encapsulation integrity in that only existing members can access it; it merely allows you to break a member's implementation into named sub-routines without exposing those implementation details through the public definition of the class.

As one colleague put it: "Essentially, it is C-style static functions, with access to class members."

-Oliver


-- 
[ 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                      ]

Back to comp.std.c++ | Previous | Next — Next in thread | Find similar

Thread

Proposal: Compilation-unit scoped private member functions kfsone@googlemail.com - 2012-11-21 11:29 -0800
  Re: Proposal: Compilation-unit scoped private member functions Francis Glassborow<francis.glassborow@btinternet.com> - 2012-12-14 09:10 -0800
  Re: Proposal: Compilation-unit scoped private member functions Daniel Krügler<daniel.kruegler@googlemail.com> - 2012-12-14 09:11 -0800
  Re: Proposal: Compilation-unit scoped private member functions Ian Collins<ian-news@this.is.invalid> - 2012-12-14 09:19 -0800
    Re: Proposal: Compilation-unit scoped private member functions christopher.dearlove@googlemail.com - 2012-12-17 08:52 -0800
      Re: Proposal: Compilation-unit scoped private member functions Ian Collins<ian-news@this.is.invalid> - 2012-12-18 16:06 -0600
        Re: Proposal: Compilation-unit scoped private member functions christopher.dearlove@googlemail.com - 2013-02-22 10:48 -0600
          Re: Proposal: Compilation-unit scoped private member functions ootiib@hot.ee - 2013-02-22 16:39 -0600
            Re: Proposal: Compilation-unit scoped private member functions Jason McKesson <jmckesson@googlemail.com> - 2013-02-23 23:22 -0800
              Re: Proposal: Compilation-unit scoped private member functions Balog Pal<pasa@lib.hu> - 2013-02-25 11:01 -0600
          Re: Proposal: Compilation-unit scoped private member functions Ian Collins <ian-news@this.is.invalid> - 2013-02-23 18:21 -0800
            Re: Proposal: Compilation-unit scoped private member functions christopher.dearlove@googlemail.com - 2013-02-25 10:59 -0600
    Re: Proposal: Compilation-unit scoped private member functions Balog Pal<pasa@lib.hu> - 2013-02-25 11:01 -0600
      Re: Proposal: Compilation-unit scoped private member functions Andy Lutomirski <luto@amacapital.net> - 2013-02-28 22:16 -0800

csiph-web