In article <c34kf8$d2s$1@news1nwk.SFbay.Sun.COM>, Steve Clamage
<stephen.clamage@sun.com> writes
>John Nagle wrote:
>>    It's been suggested a few times that C++ should allow
>> definition of private class member functions within
>> a compilation unit, without requiring that they appear
>> in the class declaration.  The intent is to allow the
>> addition of private class member functions without modifying
>> header files.  This reduces the impact on large projects
>> of adding private functions during implementation.
>
>A colleague on the C++ Committee is working on a more general proposal.
>It would allow partially-complete class definitions, to be completed in
>an implementation file.
>
>The proposal isn't complete yet. If we are not to invalidate current
>C++ implementations, the kind of hidden features that can be added is
>limited. But adding non-virtual member functions would be allowed.

Well considering the EWG was not overly keen on my proposal to allow a
way of adding to a class interface because it has an impact on overload
resolution I have my doubts that it will get enough support but I am
open to seeing the proposal.

Another possibility is to consider such extensions in the context of my
'explicit class' proposal. As this could be extended to incorporate a
rather different semantics for explicit classes such as making private
members invisible (i.e. do not participate in overload resolution) it
would work more comfortably with adding private function members in the
implementation file.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
>     It's been suggested a few times that C++ should allow
> definition of private class member functions within
> a compilation unit, without requiring that they appear
> in the class declaration.  The intent is to allow the
> addition of private class member functions without modifying
> header files.  This reduces the impact on large projects
> of adding private functions during implementation.
> This feature can reduce header file changes substantially,
> a major win for big C++ projects.
> snipped...
>
> Comments?

How does the compiler of a source file containing a member function which
calls a private member function such as you are describing, resolve the call
to the private member function at compile time ? Does it just assume that if
the call is not in any header files it must be a private member function ?
How does it know if the parameters and return type of the function that is
being called are correct ? I believe that these problems, which affect
compile time checking of function calls based on a function declaration,
makes your proposal a poor one.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> wrote:
>      It's been suggested a few times that C++ should allow
>  definition of private class member functions within
>  a compilation unit, without requiring that they appear
>  in the class declaration.

 In my experience, this would not help much, as the set of private
data members is much more volatile than the set of private functions.
Something I'd like to see is the local "reopening" of class declarations
to add data (and function) members so that I wouldn't have to rebuild
all when the internal representation changes. That's not a serious
suggestion, as I realize how invasive such a change would be.

>
>  The recommended workaround for the absence of this feature in C++
>  is the well-known "proxy object pattern", with a file-local
>  implemention object.
>

 Another option is separate interface (with all pure virtual functions)
from implementation (which implements all functions). Then mere users
of the class only need to depend on the interface class' header.

 Frank


--
Frank Pilhofer  ...........................................  fp@fpx.de
Today's "non-conformists" are getting harder and harder to tell
apart. - Alfred E. Neuman

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nagle@animats.com (John Nagle) wrote (abridged):
>     It's been suggested a few times that C++ should allow
> definition of private class member functions within
> a compilation unit, without requiring that they appear
> in the class declaration.
> [...]
> It allows access to the members of the class, unlike non-class
> functions.
> [...]
> There doesn't seem to be any significant downside to this proposal.

It seems to break information hiding. If I want to change a private
member variable, how can I be sure that no client code has declared
a file local private accessor for it, which will be broken by my
change?

-- Dave Harris, Nottingham, UK

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

   It would be indeed be useful to be able to add private
data members, and obtain more separation between implementation
and interface.  But that's tough to implement in compilers.
For one thing, the size of a class object wouldn't be known
until link time.  This breaks the semantics of "sizeof".

   File-local private functions, though, are straightforward to
implement.  They don't affect the class declaration.

   Yes, you can declare an implementation class as a friend
of the interface class.  But the coding is unwieldy; you have
to pass the "this" pointer as an explicit parameter to each
function of the implementation class, and use "->" for each
field reference.

   What I'm proposing reduces programmer work.  I realize that
unwieldy workarounds exist.

       John Nagle
    Animats

Balog Pal wrote:
> "John Nagle" <nagle@animats.com> wrote in message
> news:4051F6AA.7060605@animats.com...
>
>
>>    It's been suggested a few times that C++ should allow
>>definition of private class member functions within
>>a compilation unit, without requiring that they appear
>>in the class declaration. ...
>
>
>>The recommended workaround for the absence of this feature in C++
>>is the well-known "proxy object pattern", with a file-local
>>implemention object.
>
>
> That workaround is needed to allow private data members also.
> If you don't need data, only functions as you described, you can simply
> declare a class as friend, no need to have an instance of it. And then you
> gain access to any parts of the class.
>
> Paul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
>     It's been suggested a few times that C++ should allow
> definition of private class member functions within
> a compilation unit, without requiring that they appear
> in the class declaration.  The intent is to allow the
> addition of private class member functions without modifying
> header files.  This reduces the impact on large projects
> of adding private functions during implementation.
> This feature can reduce header file changes substantially,
> a major win for big C++ projects.
 IMHO this feature is not actually needed. BTW the same holds for the
well-known Pimpl idiom.

 The right solution for the interface/implementation problem is interface
itself, i.e. abstract base class:

 // interface SomeInterface
 class SomeInterface {
  public:
       // exposed methods
       virtual void f()=0;
       virtual int  g()=0;

       // required virtual destructor
       virtual ~SomeInterface() {}

  private:
       // forbidden assignment
       SomeInterface& operator=(const SomeInterface&);
 };

 // object factory namespace
 namespace Factory {

  // creates new object via operator new
  // and returns it using (shared) smart pointer
  sh_ptr<SomeInterface> newSomeInterface(/* parameters */);

 }

 void h()
 {
  // create an object that implements SomeInterface
  sh_ptr<SomeInterface> a=Factory::newSomeInterface(/* your arguments */);

  // use the object
  a->f();
  int i=a->g();

  // and destructor of sh_ptr<> will delete the object on the block exit
 }

PS If you can read Russian, you will find the details at
http://ders.angen.net/cpp3/
--
         With all respect, Sergey.               http://ders.angen.net/
         mailto : ders at skeptik.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
>
>     It's been suggested a few times that C++ should allow
> definition of private class member functions within
> a compilation unit, without requiring that they appear
> in the class declaration.  The intent is to allow the
> addition of private class member functions without modifying
> header files.  This reduces the impact on large projects
> of adding private functions during implementation.
> This feature can reduce header file changes substantially,
> a major win for big C++ projects.

If private member functions could be added without any declarations
in the class definition, *anyone* would be able to add any private
member function to access the private part of the class, resulting
in breaking the encapsulation. How would you solve this problem?

--
Seungbeom Kim

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

   You can write them, but you can't call them.  Only
a function that could already access the fields itself
can call them.  They're private.

    John Nagle
    Animats

Seungbeom Kim wrote:
> John Nagle wrote:
>
>>    It's been suggested a few times that C++ should allow
>>definition of private class member functions within
>>a compilation unit, without requiring that they appear
>>in the class declaration.  The intent is to allow the
>>addition of private class member functions without modifying
>>header files.  This reduces the impact on large projects
>>of adding private functions during implementation.
>>This feature can reduce header file changes substantially,
>>a major win for big C++ projects.
>
>
> If private member functions could be added without any declarations
> in the class definition, *anyone* would be able to add any private
> member function to access the private part of the class, resulting
> in breaking the encapsulation. How would you solve this problem?
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

   That's good.  It's hard to go very far in that direction
without deferring more work to link time and changing the
format of object files, but it's a good direction.

   John Nagle
   Animats

Steve Clamage wrote:
> John Nagle wrote:
>
>>    It's been suggested a few times that C++ should allow
>> definition of private class member functions within
>> a compilation unit, without requiring that they appear
>> in the class declaration.  The intent is to allow the
>> addition of private class member functions without modifying
>> header files.  This reduces the impact on large projects
>> of adding private functions during implementation.
>
>
> A colleague on the C++ Committee is working on a more general proposal.
> It would allow partially-complete class definitions, to be completed in
> an implementation file.
>
> The proposal isn't complete yet. If we are not to invalidate current C++
> implementations, the kind of hidden features that can be added is
> limited. But adding non-virtual member functions would be allowed.
>
> ---
> Steve Clamage, stephen.clamage@sun.com
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Seungbeom Kim wrote:
> If private member functions could be added without any declarations
> in the class definition, *anyone* would be able to add any private
> member function to access the private part of the class, resulting
> in breaking the encapsulation. How would you solve this problem?

They're private functions, so they could only be called from other
private functions. So there's no breaking of encapsulation. This
is just a convenience for the implementer, who wants some utility
routines that don't need to clutter the class definition.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

    It's been suggested a few times that C++ should allow
definition of private class member functions within
a compilation unit, without requiring that they appear
in the class declaration.  The intent is to allow the
addition of private class member functions without modifying
header files.  This reduces the impact on large projects
of adding private functions during implementation.
This feature can reduce header file changes substantially,
a major win for big C++ projects.

    I'm calling these "file-local private member functions".
Would someone suggest a better term?
(The term "static" is taken in this context.)

Example:

    class c1 {
    public:
 void f1();
    };

    ...

    // Private local function - does appear in class decl.
    //  Visible only in this file, from this point forward.
    void c1::fimpl()
    {
    }

    // Public function - appears in class decl.
    void c1::f1()
    { fimpl();
    }

This is effectively an extension of what "static" file-local
functions do now.  It allows access to the members of the
class, unlike non-class functions.

The recommended workaround for the absence of this feature in C++
is the well-known "proxy object pattern", with a file-local
implemention object.  This takes considerable extra coding.
A more typical workaround is bloated public member functions,
since it's much easier to add a few lines to an existing
function than to add a proxy object.

The following restrictions are needed to make this work.

-- Such functions must be private, since they're not visible
   outside the file.  Thus, only existing function members of the
   class can call them.  This protects the integrity of the class.

-- Such functions cannot be virtual (they presumably have no vtable
   entry), and cannot be friends.  The pointer-to-function-member
   operator cannot be applied to them.  Thus, they don't affect processing
   of the class declaration.

Such functions can be template functions, are eligible for inlining,
and can be forward-declared, much like static non-class functions.
>From a compiler perspective, they can be implemented much like
static non-class functions, without a vtable entry.

There doesn't seem to be any significant downside to this proposal.
There's no backwards compatibilty issue.  It doesn't reduce safety.
There are no new keywords. It's straightforward to explain and teach.

Many private function declarations could be removed from class
headers with this feature in place.  This would clean up class
definitions, providing more separation between interface
and implementation, without the programmer effort required to
implement and maintain a proxy object.

Comments?

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nagle@animats.com (John Nagle) wrote in message news:<4051F6AA.7060605@animats.com>...

>
>     I'm calling these "file-local private member functions".
> Would someone suggest a better term?
> (The term "static" is taken in this context.)
>
> Example:
>
>     class c1 {
>     public:
>  void f1();
>     };
>
>     ...
>
>     // Private local function - does appear in class decl.
>     //  Visible only in this file, from this point forward.
>     void c1::fimpl()
>     {
>     }
>
>     // Public function - appears in class decl.
>     void c1::f1()
>     { fimpl();
>     }

Assume that ::fimpl also exists (or a base of c1 has a fimpl, in the
class declaration):

1) I think it should be an error if some c1 member calls fimpl()
(without "::", resolving to ::fimpl) before c1::fimpl() is declared or
defined in the translation unit.  Likewise if c1::fimpl() is
overloaded, but some of the overloads aren't seen until "too late."

2) If a class derived from c1 calls fimpl, int the same translation
unit, is it an attempt to call c1::fimpl (which fails because of
private:) or is it a call to ::fimpl?

3) Can c1::fimpl be forward-declared?  Can it be static (in the
no-this-pointer sense of static)?

4) Perhaps require a keyword (namespace-scope private?) for these.  If
I intended to override a base-class virtual, but forgot the
declaration in my class, I'd like an error message at compile time,
even if I also misspelled fimpl.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:4051F6AA.7060605@animats.com...

>     It's been suggested a few times that C++ should allow
> definition of private class member functions within
> a compilation unit, without requiring that they appear
> in the class declaration. ...

> The recommended workaround for the absence of this feature in C++
> is the well-known "proxy object pattern", with a file-local
> implemention object.

That workaround is needed to allow private data members also.
If you don't need data, only functions as you described, you can simply
declare a class as friend, no need to have an instance of it. And then you
gain access to any parts of the class.

Paul


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
>    It's been suggested a few times that C++ should allow
> definition of private class member functions within
> a compilation unit, without requiring that they appear
> in the class declaration.  The intent is to allow the
> addition of private class member functions without modifying
> header files.  This reduces the impact on large projects
> of adding private functions during implementation.

A colleague on the C++ Committee is working on a more general proposal. It would
allow partially-complete class definitions, to be completed in an implementation
file.

The proposal isn't complete yet. If we are not to invalidate current C++
implementations, the kind of hidden features that can be added is limited. But
adding non-virtual member functions would be allowed.

---
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]