Darren New <dne### [at] sanrrcom> wrote:
> Sure. But people are discussing .h files, where there's no such option in 
> C++. In C, you could make the function static, but that's not the same thing 
> for a C++ method.

  How would you suggest having support for implementing private functions for
a class without having to declare them in the class declaration *and* without
opening the private parts of the class to any external code that wishes to
access it?

  Assume you could do this in C++:

//-----------------------------------------------
// HeaderFile.hh
class MyClass
{
 public:
    void some_public_function();

 private:
    some_private_data;
};
//-----------------------------------------------

//-----------------------------------------------
// HeaderFile.cc
#include "HeaderFile.hh"

void MyClass::some_public_function() { ... }

// Add a new private function to MyClass:
void MyClass::a_private_function()
{
    // Access some_private_data here
}
//-----------------------------------------------

  Hey, that's great. I can add new private functions to MyClass without
having to modify the declaration of the class nor the header file. Cool.

  Except for one problem:

//-----------------------------------------------
// SomeOtherFile.cc
#include "HeaderFile.hh"

void MyClass::bypass_privacy()
{
    // Access some_private_data here
}
//-----------------------------------------------

  Now you have opened your entire class for anyone to access from anywhere
without restriction, making your public/private distinction completely
meaningless.

  (You might find that ok, but most OO programmers don't, including most of
the people who know about these things.)

  The solution to this is to specify the private functions in the class
declaration.

  If you don't care about privacy, then put everything in the public section
of the class and write all the formerly private functions in a nameless
namespace inside the source file. That way you don't have to add anything
to the header file if you want to add a new private function.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   That's your argument for dismissing all the private types, functions and
> data that can be specified in a source file (and which don't belong to the
> header file)?

Maybe that's just the crap I've run into myself. :-)

>> However, since C# makes the "makefile" structure part of the language, it's 
>> possible to write tools that extract equivalent documentation from C# that 
>> you can't as easily write in a portable way for C++.  I.e., even if you have 
>> a complete C++ parser, now you need a whole lot of extra stuff to understand 
>> *which* header files go with *which* source files when you're trying to 
>> parse C++.
> 
>   I'm not completely following what you are saying.

I'm saying that the argument seems to be "C++ header files are better, 
because it's not mixed in with the implementation stuff."  When I point out 
that you can get documentation out of C# that's just like C++ header files, 
people point out you need a tool to do that.

That's an incorrect assertion. You don't need a tool to make that 
documentation any more than you need a tool to make C++ header files. C++ 
header files aren't better because they're C++, but because they're manually 
constructed and maintained. If they aren't manually constructed and 
maintained, then you need a tool to do that just like you do for C++.

And the tool for C++ will have a harder time of it, *because* there's no 
indication of any compilation units bigger than a .cpp file, and so on. 
I.e. you can't just give a pile of C++ source files to a tool and have it 
understand the code without having it figure out and understand all the 
compiler command lines as well. (This goes for C as well, of course.)

I can give you all the source code I'm working on, and there's no way you 
could ever figure out how to compile it without trying to compile and run it 
against each set of header files to see what works, for example. That's not 
the case with C#, because there's a file in a standard format that serves 
the purpose of a makefile and which the libraries already have tools to deal 
with.



-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Sure. But people are discussing .h files, where there's no such option in 
>> C++. In C, you could make the function static, but that's not the same thing 
>> for a C++ method.
> 
>   How would you suggest having support for implementing private functions for
> a class without having to declare them in the class declaration *and* without
> opening the private parts of the class to any external code that wishes to
> access it?

I don't know. C# does it by not having header files.  I'm not saying C++'s 
solution is a bad one per se.  (*I* don't like it as much, but that doesn't 
mean it's *bad* universally.)

I'm merely pointing out that it's hypocritical to claim that it's better to 
*have* to maintain something manually because then you're not dependent on a 
tool to maintain it.

>   The solution to this is to specify the private functions in the class
> declaration.

Or not have class declarations at all.  If you define it private, then it's 
private. You don't need to declare it at all, public or private.

>   If you don't care about privacy, then put everything in the public section
> of the class and write all the formerly private functions in a nameless
> namespace inside the source file.

That doesn't work for instance methods, does it?  An instance method 
actually has to be a member of the class in the class declaration, yes? (I'm 
just double-checking I understand that part.)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I don't know. C# does it by not having header files.

  Well, nothing stops you from implementing everything *in* the class
declaration in C++. (Well, except if you want to keep some degree of
modularity.)

> I'm merely pointing out that it's hypocritical to claim that it's better to 
> *have* to maintain something manually because then you're not dependent on a 
> tool to maintain it.

  I don't see separate declarations and implementations as such a big problem
as you seem to.

> >   The solution to this is to specify the private functions in the class
> > declaration.

> Or not have class declarations at all.  If you define it private, then it's 
> private. You don't need to declare it at all, public or private.

  How do you stop someone from adding a new private function to your class
from the outside, then?

> >   If you don't care about privacy, then put everything in the public section
> > of the class and write all the formerly private functions in a nameless
> > namespace inside the source file.

> That doesn't work for instance methods, does it?  An instance method 
> actually has to be a member of the class in the class declaration, yes? (I'm 
> just double-checking I understand that part.)

  Well, if everything is public, what do you need private methods for?
Private methods are only for access, but if access is already completely
open, then there's no need for private methods. You can replace them with
local functions (ie. local to the compilation unit, ie. in a nameless
namespace).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I don't know. C# does it by not having header files.
> 
>   Well, nothing stops you from implementing everything *in* the class
> declaration in C++. (Well, except if you want to keep some degree of
> modularity.)

Right.

>> I'm merely pointing out that it's hypocritical to claim that it's better to 
>> *have* to maintain something manually because then you're not dependent on a 
>> tool to maintain it.
> 
>   I don't see separate declarations and implementations as such a big problem
> as you seem to.

I don't either. I'm just pointing out that it's silly to say not *having* to 
do that is a *problem.*  I'm not bashing C++. I'm saying it's silly to say 
that C++ is superior in the aspect that it *makes* you manually maintain a 
separate file with the information in it that C# programs can generate 
automatically. At least because you can *also* maintain that information 
manually in C#.

>   How do you stop someone from adding a new private function to your class
> from the outside, then?

Because you have to compile all the parts of the class at the same time in 
C#. If you're *really* worried about it, you sign the result. :-)

>> That doesn't work for instance methods, does it?  An instance method 
>> actually has to be a member of the class in the class declaration, yes? (I'm 
>> just double-checking I understand that part.)
> 
>   Well, if everything is public, what do you need private methods for?

Where did I say everything is public?  I just said that the private methods 
wind up being visible in the public "interface" file in C++.  Again, I was 
just commenting in terms of people complaining there was too much "visible" 
in the C# way of doing things.

> You can replace them with
> local functions (ie. local to the compilation unit, ie. in a nameless
> namespace).

Hmm. But you don't get a "this" pointer, right? You need to start being 
explicit about everything that OO is supposed to make implicit, like 
accessing member variables from inside the function and all?

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Where did I say everything is public?  I just said that the private methods 
> wind up being visible in the public "interface" file in C++.  Again, I was 
> just commenting in terms of people complaining there was too much "visible" 
> in the C# way of doing things.

  A header file is not really a "public interface". It's just a source code
file like any other. The "public interface" of a class is what you put
inside the "public" section of the class. Whatever there might be in the
"private" section is there purely for technical reasons, and you shouldn't
concern yourself about it and consider it effectively hidden (at least if
you want to maintain good OOD).

  Yes, a class declaration cannot be split into two or more parts in C++
(for technical reasons), but that doesn't make the private part any more
"public".

  There are other programming languages (such as Objective-C) where you
can split the class declaration into two, putting one part in a header
file and the other in the source file, but that's because the way objects
are implemented allows that (at the cost of speed and memory efficiency).

> > You can replace them with
> > local functions (ie. local to the compilation unit, ie. in a nameless
> > namespace).

> Hmm. But you don't get a "this" pointer, right? You need to start being 
> explicit about everything that OO is supposed to make implicit, like 
> accessing member variables from inside the function and all?

  The 'this' pointer is passed implicitly to member functions by the
compiler. If you decide to make it a local function instead, you'll have
to pass the object pointer explicitly as a function parameter. Otherwise
there isn't too much of a difference, just a small difference in syntax.

  (The real difference between private member functions and local
functions is access scope.)

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> Warp wrote:
>>   What do you mean? Ever heard of the nameless namespace? Everything in
>> a nameless namespace is local to that source file and definitely not part
>> of the public interface of that module. (In fact, there's no way of
>> accessing anything inside a nameless namespace from another source file.)
> 
> You can't make a private method on a class without exposing that in the
> header, can you?  (If so, I've been doing it wrong. :-)

Actually, you can. COM does it. But you end up making all public methods
virtual, and a feature of C++ over C# is that you have the choice not to
make everything virtual :)

Post a reply to this message

Warp wrote:
>   A header file is not really a "public interface". It's just a source code
> file like any other. The "public interface" of a class is what you put
> inside the "public" section of the class. Whatever there might be in the
> "private" section is there purely for technical reasons, and you shouldn't
> concern yourself about it and consider it effectively hidden (at least if
> you want to maintain good OOD).

Right. If you're talking about C# being too "cluttered" in its declarations 
(because they're technically in the class body, all one file sort of thing), 
then the fact that you have to visually skip the private sections of the 
class header I think would have to be accounted for in the "ease of use of 
using a .h file for documentation" arguments.

> but that doesn't make the private part any more "public".

Only if you're looking at the ergonomics of using a .h file as documentation.

>   The 'this' pointer is passed implicitly to member functions by the
> compiler. If you decide to make it a local function instead, you'll have
> to pass the object pointer explicitly as a function parameter. Otherwise
> there isn't too much of a difference, just a small difference in syntax.

Good!  I understood that right. :-)

>   (The real difference between private member functions and local
> functions is access scope.)

Yeah, I guess that's true too. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Nicolas Alvarez wrote:
> Actually, you can. COM does it. But you end up making all public methods
> virtual, and a feature of C++ over C# is that you have the choice not to
> make everything virtual :)

Not everything in C# is virtual either, if you don't declare it virtual.

You're thinking of Eiffel or something.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New wrote:
> Nicolas Alvarez wrote:
>> Actually, you can. COM does it. But you end up making all public methods
>> virtual, and a feature of C++ over C# is that you have the choice not to
>> make everything virtual :)
> 
> Not everything in C# is virtual either, if you don't declare it virtual.
> 
> You're thinking of Eiffel or something.

Maybe Java.

Post a reply to this message