In article <3t22f9$8j6@peippo.cs.tut.fi> esap@cs.tut.fi (Pulkkinen Esa) writes:

   [Discussion about declaring private non-virtual member functions
   outside the class deleted].

   I can't understand this. You mean defining static objects
   inside the added private function? If so, those constructors won't
   be called until the function itself is entered first time (which can't
   happen until the access had been violated...)

Sorry, I had overlooked that.  It now seems that allowing introduction
of new private non-virtual member functions outside the class
definiton would cause no access control problems.  At least I can't
think of any.

I wonder if people think this extension would be useful enough to be
submitted to the working group, and if so, how to submit it.
--
 Timo Korvola  Timo.Korvola@hut.fi

In article <TKORVOLA.95Jun29131024@dopey.hut.fi>,
Timo Korvola <Timo.Korvola@hut.fi> wrote:
[Discussion about declaring private non-virtual member functions
outside the class deleted].
>But it just occurred to me that there would nevertheless be an access
>control problem: the violating function could arrange calls to private
>constructors by defining static objects.  This would breach access
>control by invoking any side effects the constructors might have.

I can't understand this. You mean defining static objects
inside the added private function? If so, those constructors won't
be called until the function itself is entered first time (which can't
happen until the access had been violated...)

What am I missing?
--
   Esa Pulkkinen                        | C++ programmers do it virtually
   E-Mail:  esap@cs.tut.fi              | everywhere with a class, resulting
   WWW   :  http://www.cs.tut.fi/~esap/ | in multiple inheritance.

In article <TKORVOLA.95Jun29131024@dopey.hut.fi>,
Timo Korvola <Timo.Korvola@hut.fi> wrote:
[Discussion about declaring private non-virtual member functions
outside the class deleted].
>But it just occurred to me that there would nevertheless be an access
>control problem: the violating function could arrange calls to private
>constructors by defining static objects.  This would breach access
>control by invoking any side effects the constructors might have.

I can't understand this. You mean defining static objects
inside the added private function? If so, those constructors won't
be called until the function itself is entered first time (which can't
happen until the access had been violated...)

What am I missing?
--
   Esa Pulkkinen                        | C++ programmers do it virtually
   E-Mail:  esap@cs.tut.fi              | everywhere with a class, resulting
   WWW   :  http://www.cs.tut.fi/~esap/ | in multiple inheritance.

> |> Timo Korvola <Timo.Korvola@hut.fi> wrote:
> |> >
> |> >I would like to hear whether people think the following extension to
> |> >C++ would be useful.
> |> >I think it should be made possible to declare private non-virtual member
> |> >functions outside of the class definition.

Bad idea, unfortunately: you violate encapsulation of a class. If your
proposal were adopted, I could violate the encapsulation of *any* class
simply by declaring a hitherto unknown private function in my own code.
Consider:

class VerySafe
{
public:

 // whatever ...

private:

 VeryImportantResource critical;
};


Then someone comes along and breaks open the class by just writing:

private void VerySafe::Naughty()
{
 // do something with VeryImportantResource member 'critical'
}

As someone else pointed out, there are ways to do what you want using friends
or whatever when writing the class; your proposal opens the back door for
users of the class to violate its encapsulation. It would be nice to be able
to do what you're suggesting, but unfortunately that's not enough :-(

David.

=======================================================================
David McCann                    | VOICE: +43 1 60171-5606
PSE TMN 23                      | FAX:   +43 1 60171-5712
Siemens AG Austria              | MAIL: David.McCann@siemens.co.at
Gudrunstrasse 11                | Banyan: David McCann@TMN2@PSE OE
A-1101 Wien                     | X.400: Hamma net. Wos isn denn des?
=======================================================================

david@PROBLEM_WITH_INEWS_DOMAIN_FILE (Hr.McCann) writes:
> Timo Korvola <Timo.Korvola@hut.fi> wrote:
>> I would like to hear whether people think the following extension to C++
>> would be useful.  I think it should be made possible to declare private
>> non-virtual member functions outside of the class definition.
>
> Bad idea, unfortunately: .... If your proposal were adopted, I could violate
> the encapsulation of *any* class simply by declaring a hitherto unknown
> private function in my own code.  Consider:
>
> class VerySafe {public: // whatever ...
>  private: VeryImportantResource critical;};
>
> Then someone comes along and breaks open the class by just writing:
>
> private void VerySafe::Naughty()
> {/* do something with VeryImportantResource member 'critical' */}

You could write such a function, but the compiler would not allow you to ever
call it.  This has been pointed out already.

In article <3srr9d$6lt@siemens.co.at> david@PROBLEM_WITH_INEWS_DOMAIN_FILE (Hr.McCann) writes:

   Timo Korvola <Timo.Korvola@hut.fi> wrote:
   >
   >I would like to hear whether people think the following extension to
   >C++ would be useful.
   >I think it should be made possible to declare private non-virtual member
   >functions outside of the class definition.

   Bad idea, unfortunately: you violate encapsulation of a class. If your
   proposal were adopted, I could violate the encapsulation of *any* class
   simply by declaring a hitherto unknown private function in my own code.

I mentioned this possibility in the original posting.  I didn't think
that there would be an access control problem, as this violating
function would be uncallable.

But it just occurred to me that there would nevertheless be an access
control problem: the violating function could arrange calls to private
constructors by defining static objects.  This would breach access
control by invoking any side effects the constructors might have.

I still think it is a shame that one has to use the friend kluge
someone mentioned just to get decent implementation hiding.
Unfortunately it now seems there is no trivial way to fix this.
--
 Timo Korvola  Timo.Korvola@hut.fi

In article <3rpmra$sac@metro.ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
|> In article <TKORVOLA.95Jun8155440@dopey.hut.fi>,
|> Timo Korvola <Timo.Korvola@hut.fi> wrote:
|> >
|> >I would like to hear whether people think the following extension to
|> >C++ would be useful.
|> >I think it should be made possible to declare private non-virtual member
|> >functions outside of the class definition.  E.g.
|>
|> [...text elided...]
|>
|>  The second problem is syntax. Neither your syntax nor
|> mine is really good enough. Something like
|>
|>  void foo:private:bar() { .. }
|>
|> is needed to explicitly say "I'm creating a new private member here".
|>
|> --
|>         JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
|>  Maxtal Pty Ltd,
|>         81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
|>         NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

It would seem to me the obvoious syntax would be (outside of a class declaration)

private foo::bar() { ... }

But frankly, I believe your earlier namespace proposal was good.  In some
classes, you get very tired of typing

ClassWithLongName::TypeWithLongName ClassWithLongName::memberFunctionName(
 ...
) {}
 .
 .
 .

as opposed to

namespace ClassWithLongName {
 TypeWithLongName memberFunctionName(
  ...
 ) {}
}
--
Alexis Layton    XSoft Advanced Information Technology
alex@XAIT.Xerox.COM   Xerox Corporation
+1 617 499-4443    Four Cambridge Center
     Cambridge, MA  02142-1494

In article <TKORVOLA.95Jun8155440@dopey.hut.fi>,
Timo Korvola <Timo.Korvola@hut.fi> wrote:
>
>I would like to hear whether people think the following extension to
>C++ would be useful.
>I think it should be made possible to declare private non-virtual member
>functions outside of the class definition.  E.g.

 I agree. However, let me place before you the
main technical counter-argument:  at present _all_ methods
which have access to private parts of a class are listed in
the class definition, whether or not they are actually defined
there themselves. This "indexing" property is valuable and
is threatened by allowing arbitrary addition of private
members like this:

>class foo {
>  // ... no declaration of bar() here...
>};
>
>void foo::bar( int);

 This requires a "recursive" search for methods permitted
access to private details. It also delays error checking
on "foo::XXXX()" -- was that meant to be a defintion of a member
or the addition of a new private? (You get to find out at link time)

 I have proposed the following:

 struct foo {  int mem(); private: int x; };
 namespace foo {
  int bar () { return x; } // "local" private member
  int mem() {return bar(); }
 }

-- that is, a namespace can be opened for the purpose of
defining members of foo. This also gets rid of the foo::
prefix and allows grouping of definitions, as well as
solving nasty lookup problems of return types (which are
written _before_ the foo:: prefix and may not be
in scope (say you return a nested class). There's a syntactic problem,
however, distinguishing non-static member functions
and non-member functions introduced this way.

 The consensus of the committee members on this and
related proposals was NO. This is probably the right decision:
committee's sometimes have to be conservative.

 Another mechanism which would partly alleviate this
problem would be the introduction of nested functions.
(Also rejected -- and this time I think the committee made a
major mistake)

>Private member functions are not part of the interface, as they cannot
>be called from outside of the class.

 I believe you are quite correct there is no
violation of encapsulation.

>As long as they are non-virtual,
>the compiler shouldn't need to know about them to be able to create
>objects.  Having such members listed in the class definition therefore
>seems unnecessary.

 Again, this is both correct and is also the counter
argument -- it isn't necessary, but it is useful.

 The second problem is syntax. Neither your syntax nor
mine is really good enough. Something like

 void foo:private:bar() { .. }

is needed to explicitly say "I'm creating a new private member here".

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

Barton Stanley (barton@tyrell.net) wrote:
: tkorvola@dopey.hut.fi (Timo Korvola) wrote:


: >I would like to hear whether people think the following extension to
: >C++ would be useful.

: >I think it should be made possible to declare private non-virtual member
: >functions outside of the class definition.  E.g.

: >class foo {
: >  // ... no declaration of bar() here...
: >};

: >void foo::bar( int);

: >should be valid and equivalent to

: >class foo {
: >  // ...
: >private:
: >  void bar( int);
: >};

: >As I see it, the class definition has essentially two purposes:
: >- to specify the interface to the class.
: >- to provide enough information for the compiler to create objects
: >  of the class.

: >Private member functions are not part of the interface, as they cannot
: >be called from outside of the class.  As long as they are non-virtual,
: >the compiler shouldn't need to know about them to be able to create
: >objects.  Having such members listed in the class definition therefore
: >seems unnecessary.


a better form would be :

class foo
{
public:
   foo();
...

};

namespace foo
{
   void bar(int); // additional private member declaration

   foo() { ... }  // definition of member

...
}


[...]


: Barton Stanley
: barton@tyrell.net



--------------------
LD

I would like to hear whether people think the following extension to
C++ would be useful.

I think it should be made possible to declare private non-virtual member
functions outside of the class definition.  E.g.

class foo {
  // ... no declaration of bar() here...
};

void foo::bar( int);

should be valid and equivalent to

class foo {
  // ...
private:
  void bar( int);
};

As I see it, the class definition has essentially two purposes:
- to specify the interface to the class.
- to provide enough information for the compiler to create objects
  of the class.

Private member functions are not part of the interface, as they cannot
be called from outside of the class.  As long as they are non-virtual,
the compiler shouldn't need to know about them to be able to create
objects.  Having such members listed in the class definition therefore
seems unnecessary.

The suggested extension would make it easier to create new private
member functions to facilitate the implementation of the public and
protected members, as no changes to the class definition would be
necessary.  A lot of useless recompilation could thus be avoided.

Access control would not be broken by this extension:  although it
would allow rather free creation of functions with access to the private
class members, these functions would ultimately have to be called from
public or protected members, which would have to be declared within
the class definition.
--
 Timo Korvola  Timo.Korvola@hut.fi

tkorvola@dopey.hut.fi (Timo Korvola) wrote:


>I would like to hear whether people think the following extension to
>C++ would be useful.

>I think it should be made possible to declare private non-virtual member
>functions outside of the class definition.  E.g.

>class foo {
>  // ... no declaration of bar() here...
>};

>void foo::bar( int);

>should be valid and equivalent to

>class foo {
>  // ...
>private:
>  void bar( int);
>};

>As I see it, the class definition has essentially two purposes:
>- to specify the interface to the class.
>- to provide enough information for the compiler to create objects
>  of the class.

>Private member functions are not part of the interface, as they cannot
>be called from outside of the class.  As long as they are non-virtual,
>the compiler shouldn't need to know about them to be able to create
>objects.  Having such members listed in the class definition therefore
>seems unnecessary.

>[snip]

I strongly second this motion.  I've figured out ways to get the
declaration of private data members out of the interface, which
allowing me to modify private data without affecting the interface
(and thus without requiring a recompilation of all interface clients)
but private member functions remain problematic.  Whether it is
implemented as you suggest or not, the basic idea of being able to add
and remove private member functions without affecting the interface
would be a welcome improvement to C++, IMO.

One (inadequate) solution to this problem is to write a static
"helper" function for the class, and put it in the same source file as
the member function definitions.  The deficiency of this solution is
that you don't get a *this* pointer with these routines (of course).
Regardless of how it's implemented, what I need is a private function
that does not appear in the class declaration, but which has a *this*
pointer.

Thanks for speaking up on this!  Does anyone out there know how we can
go about getting a solution to this problem added to the standard?

Barton Stanley
barton@tyrell.net