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


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

Re: Proposal: Compilation-unit scoped private member functions

From Ian Collins<ian-news@this.is.invalid>
Newsgroups comp.std.c++
Subject Re: Proposal: Compilation-unit scoped private member functions
Date 2012-12-14 09:19 -0800
Organization unknown
Message-ID <ahu6pqFijb1U1@mid.individual.net> (permalink)
References <ff2d9902-a232-40f4-9e22-97b2563099f8@googlegroups.com>

Show all headers | View raw


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<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,

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                      ]

Back to comp.std.c++ | Previous | NextPrevious in thread | 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