In article <2drsl5$dta@access.digex.net>, kbennett@access.digex.net (Keith R. Bennett) writes:
|> [deleted  intro...]
|>
|> One of the goals of object oriented programming, as I understand it,
|> is to separate the interface from the implementation of a logical
|> object.  Thus, the class' header is distributed to users of the
|> class, but the implementation can be hidden by distributing a library
|> (or object) file, but withholding the source code.
|>
|> This being the case, why are private data and function members
|> included in the class header?  It would seem to be more consistent
|> with the OO philosophy to put them somewhere else, in the
|> implementation (.C or .CPP) file perhaps, where the user of the class
|> could not see them.
|>
|> I know there's a good reason for this, and I'm curious to know what
|> it is.  Thanks for any help.
|>
|> - Keith
|> --
|> --------------------------------------------------------------------------
|> Keith Bennett                            Bennett Business Solutions, Inc.
|> C++/C Software Development               1605 Ingram Terrace
|> kbennett@access.digex.net                Silver Spring, MD USA 20906-5932

One good reason for having private data&methods is that it is always preferable
to use the SAME include file as the library/object developer used. This way you both use a #include-ed file from the same directory and have a single point of change whenever this is required.

--
               Amir Raveh                    | #include <std_disclaimer.h>
                                             |
My friends call me amirr@milcse.rtsg.mot.com |

maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>  2) private functions dont have to be included for
> any really good reason. I have proposed an extension to
> the namespace mechanism that would allow private functions
> to be omitted from the class interface.
What about the case of a private method called from a public inline method?
How about a private inline method called from a public inline method?

-Francis

In article <CHLzsx.AqD@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU
(John Max Skaller) writes:
>OK, so what if there is a rule that if you use the namespace
>thingy, there can only be ONE of them. Then all the definitions
>and the helper functions as well must be in the one translation
>unit, and in between the { } of the namespace at that.

Gack.  No, please, unless I misunderstand what you are saying, it would
be too confusing and probably unenforceable by a compiler.

> class X ... { /*  */ };
> namespace X {  void helper() { } }

It's exceptionally rare that a helper function needs to be visible out of
the immediate area in which it is used---all it needs to do is provide the
functionality that a file-scope static function provides to the global
functions defined in a file of a C program.  I would be happy if helper()
were in scope only to the closing } of the particular namespace fragment
in which it was defined---similar to a file-scope static function, it's
only visible until the end of the current namespace fragment.

Something like this:

 class X { /*  */ };
 namespace X {
  void helper() { }
  /* helper can _only_ be used here */
 }
 /* and is not in scope here */
 namespace X {
  /* and not in scope here, either, */
  /* even if this namespace fragment */
  /* is in the same file as the first */
 }

If it has to be visible across namespace fragments, that's grounds to
put it in the class description.

--
-- Greg Noel, Unix Guru         greg@qualcomm.com  or  greg@noel.cts.com

In article <2drsl5$dta@access.digex.net>, kbennett@access.digex.net (Keith R. Bennett) writes:
> My client, who has been a bit resistant to moving from C to C++, is
> now studying it more seriously.  He asked me a question I couldn't
> answer, and I present it to you:

> One of the goals of object oriented programming, as I understand it,
> is to separate the interface from the implementation of a logical
> object.  Thus, the class' header is distributed to users of the
> class, but the implementation can be hidden by distributing a library
> (or object) file, but withholding the source code.

Right.

> This being the case, why are private data and function members
> included in the class header?  It would seem to be more consistent
> with the OO philosophy to put them somewhere else, in the
> implementation (.C or .CPP) file perhaps, where the user of the class
> could not see them.

This is because code using the objects need to know how big the
objects will be, as well as other things derived from the layout
of the object. It is partially to maintain upward compatibility
with C and partially to improve efficiency. True, this does
introduce ways to "get around" the protection mechanisms, but
these mechanisms were mainly to help keep programmers from
grubbing around by accident where they weren't supposed to, not
as a defense from malicious attacks on an object's data. No mere
compiler could adequately defend against the latter.

> I know there's a good reason for this, and I'm curious to know what
> it is.  Thanks for any help.

Say you have a class complex, and that you have a bunch of
overloaded functions that operate on objects of type complex,
like sin(), cos(), exp(), log(), and the like. Quick, how much
space do you need to reserve on the stack to hold a variable of
type complex, or to hold the return value of a call to one of the
overloaded functions? Without knowing the structure of the
object, you don't. Keep in mind that different compilers and
machine architectures like to align things differently as well.

--
Joe Foster (joe@bftsi0.uucp)
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

In article <CHLoMM.Cnw@ucc.su.OZ.AU>, maxtal@physics.su.OZ.AU (John Max Skaller) writes

>  2) private functions dont have to be included for
> any really good reason. I have proposed an extension to
> the namespace mechanism that would allow private functions
> to be omitted from the class interface.

If the private function is the only virtual function of the class this
private function causes every object of the class to contain a pointer
to the virtual function table.

Hence clients of the class have to know about this.

Lars With
Merken & With Consulting
Winterfeldtstr. 94
Germany 10777 Berlin
Tel. (030) 211 82 20
Fax  (030) 211 82 20

lars@cs.tu-berlin.de

One of the goals of object oriented programming, as I understand it,
is to separate the interface from the implementation of a logical
object.  Thus, the class' header is distributed to users of the
class, but the implementation can be hidden by distributing a library
(or object) file, but withholding the source code.

This being the case, why are private data and function members
included in the class header?  It would seem to be more consistent
with the OO philosophy to put them somewhere else, in the
implementation (.C or .CPP) file perhaps, where the user of the class
could not see them.

I know there's a good reason for this, and I'm curious to know what
it is.  Thanks for any help.

- Keith
--
--------------------------------------------------------------------------
Keith Bennett                            Bennett Business Solutions, Inc.
C++/C Software Development               1605 Ingram Terrace
kbennett@access.digex.net                Silver Spring, MD USA 20906-5932

maxtal@physics.su.OZ.AU (John Max Skaller) writes:

[...]
>I have proposed an extension to
>the namespace mechanism that would allow private functions
>to be omitted from the class interface.
>
> The argument against that is that it destroys an
>important property: all the methods with access to the
>private parts of a class are listed in the class interface.
>
> You cant have private helpers not declared in the
>class interface and preserve this property (obviously).
>
> Which do you want?

Well, actually I want both.  I want to ensure that all the
methods with access to the private parts of a class are listed
in one place, but I don't want to put them in the class
interface.  Instead I want to put them in the class _implementation_.

Unfortunately, C++ doesn't have much of a module system.
C++ doesn't have any notion of a class implementation as a single
unit.  Instead, the implementations of different parts of a
single class interface can be spread amoung different source files or
compilation units.  So I can't get what I want in C++.

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

In article <2drsl5$dta@access.digex.net>,
Keith R. Bennett <kbennett@access.digex.net> wrote:
>This being the case, why are private data and function members
>included in the class header?

It is a compiler issue. The compiler needs to know how big the class is.

Michael


--
Michael Kaufman | I've seen things you people wouldn't believe. Attack ships on
 kaufman        | fire off the shoulder of Orion. I watched C-beams glitter in
  @eecs.nwu.edu | the dark near the Tannhauser gate. All those moments will be
                | lost in time - like tears in rain. Time to die.     Roy Batty

In article <9334021.3378@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>
>[...]
>>I have proposed an extension to
>>the namespace mechanism that would allow private functions
>>to be omitted from the class interface.
>>
>> The argument against that is that it destroys an
>>important property: all the methods with access to the
>>private parts of a class are listed in the class interface.
>>
>> You cant have private helpers not declared in the
>>class interface and preserve this property (obviously).
>>
>> Which do you want?
>
>Well, actually I want both.  I want to ensure that all the
>methods with access to the private parts of a class are listed
>in one place, but I don't want to put them in the class
>interface.  Instead I want to put them in the class _implementation_.
>
>Unfortunately, C++ doesn't have much of a module system.
>C++ doesn't have any notion of a class implementation as a single
>unit.  Instead, the implementations of different parts of a
>single class interface can be spread amoung different source files or
>compilation units.  So I can't get what I want in C++.

 Hm. Maybe you can.

 The suggestion was

 class X ... { /*  */ };
 namespace X {  void helper() { } }

so that you can only use the namespace extension if you put ... in
the header. But there was no suggestion that only one
namespace thingy could be used.

OK, so what if there is a rule that if you use the namespace
thingy, there can only be ONE of them. Then all the definitions
and the helper functions as well must be in the one translation
unit, and in between the { } of the namespace at that.

In other words in this case the class definition must occur
in a single 'module', and cant be spread around.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

maxtal@physics.su.OZ.AU (John Max Skaller) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>>I want both.  I want to ensure that all the
>>methods with access to the private parts of a class are listed
>>in one place, but I don't want to put them in the class
>>interface.  Instead I want to put them in the class _implementation_.
>>
>>C++ doesn't have any notion of a class implementation as a single
>>unit ... So I can't get what I want in C++.
>
> Hm. Maybe you can.
>
> The suggestion was
>
> class X ... { /*  */ };
> namespace X {  void helper() { } }
>
>so that you can only use the namespace extension if you put ... in
>the header. But there was no suggestion that only one
>namespace thingy could be used.
>
>OK, so what if there is a rule that if you use the namespace
>thingy, there can only be ONE of them. Then all the definitions
>and the helper functions as well must be in the one translation
>unit, and in between the { } of the namespace at that.
>
>In other words in this case the class definition must occur
>in a single 'module', and cant be spread around.

Hmm.  I think this use of `namespace' is somewhat confusing.
It means that some namespaces can be added to, but not others.
I'd rather some other syntax was used.

Oh, btw, I forgot to mention one other requirement on my list:
implementation details such as private data and bodies of inline member
functions shouldn't have to go in the interface part of a class, the
compiler should be able to work them out automatically.  This is
very easy if the language has a decent notion of modules...

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

In article <2drsl5$dta@access.digex.net> kbennett@access.digex.net (Keith R. Bennett) writes:
>My client, who has been a bit resistant to moving from C to C++, is
>now studying it more seriously.  He asked me a question I couldn't
>answer, and I present it to you:
>
>One of the goals of object oriented programming, as I understand it,
>is to separate the interface from the implementation of a logical
>object.  Thus, the class' header is distributed to users of the
>class, but the implementation can be hidden by distributing a library
>(or object) file, but withholding the source code.
>
>This being the case, why are private data and function members
>included in the class header?

 1) private data is included because C++ is design to run
on systems with DUMB environments. The compiler needs to know
how big an object is to allocate space on the stack for it,
so all the data members have to visible.

 This problem can be fixed in smart environments,
but then all the Unix people would be screwed :-)

 2) private functions dont have to be included for
any really good reason. I have proposed an extension to
the namespace mechanism that would allow private functions
to be omitted from the class interface.

 The argument against that is that it destroys an
important property: all the methods with access to the
private parts of a class are listed in the class interface.

 You cant have private helpers not declared in the
class interface and preserve this property (obviously).

 Which do you want?

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA