<p>C++ and Objective-C both require forward declaration of the methods and fields on a class. Objective-C lets you hide the existence of internal/private methods &amp; fields altogether:</p>
<pre class="lang-objectivec prettyprint-override"><code>// MyObject.h
#ifndef _MyObject_h_
#define _MyObject_h_

#import &lt;Foundation/Foundation.h&gt;

@interface MyObject : NSObject {
  NSInteger publicIvar;
}

- (void)publicMethod;

@end

#endif

// MyObject+Internal.h
#ifndef _MyObject_Internal_h_
#define _MyObject_Internal_h_

#import &quot;MyObject.h&quot;

@interface MyObject () {
  NSInteger internalIvar;
}

- (void)internalMethod;

@end

#endif

// MyObject.m
#import &quot;MyObject+Internal.h&quot;

@implementation MyObject {
  NSInteger privateIvar;
}

/* method implementations */

@end
</code></pre>
<p>If the project is configured such that dependents can’t import <code>MyObject+Internal.h</code>, they can’t use the symbols from that extension. However, C++ doesn’t allow this; all fields and methods must be declared in one place. Dependents are able to see things that they can’t use.</p>
<p>In a language like these that requires forward declarations, what are the advantages of requiring private functionality to be declared in a public header?</p>

<object-oriented><c++><history>
Why does C++ require private methods to be declared with public ones?
<p>The private attributes may effect the position of public attributes. If you have a class like this:</p>
<pre class="lang-cpp prettyprint-override"><code>class A {
   public:
       int a;
}
</code></pre>
<p>Here, <code>a</code> is placed at the first position, thus <code>x.a</code> translates to <code>*(a+0)</code>. But on the other hand if you have this:</p>
<pre><code>class A {
    private:
        int b;
    public:
        int a;
}
</code></pre>
<p>Here, <code>a</code> is will be stored at <code>*(x+1)</code>, a different place. The private variable, while not directly accessible, effects accesses to public variables.</p>
<p>I can speak from experience that absolutely everything breaks when your variables are not where you expect them to be, from when I tried to <code>#ifdef</code> out private methods when a header was included.</p>
<p>I'm guessing it works the same way for methods for consistency.</p>

CC BY-SA 4.0
2023-05-25T17:40:55.113Z
2023-05-25T17:54:33.217Z
2023-05-25T17:54:33.217Z
mousetail 'he-him'
CC BY-SA 4.0
2023-05-25T17:52:11.740Z
Doesn't directly answer the whole question, but it could probably bear extending with "and if that's how it is for fields, then it's extra effort for less utility to make it work with methods anyways".
Unrelated String
<p>As also explained by the other answer, all member variables need to be declared in the header, because by themself all types in C++ are value types. This implies that the compiler needs to know their size and alignment to allocate them on the stack, and that is computed from the member variables.</p>
<p>Private methods however wouldn't necessarily need to be declared in the header. This is a somewhat unfortunate state of affairs, especially if your private methods take argument types that you don't want to expose in the header.</p>
<p>If you <em>really</em> wanted, you could in your .cpp file <code>#define private public</code> and just define private member functions as static free functions that take the object by reference or pointer. Note that this suggestion is not really serious, because it violates the <a href="https://en.cppreference.com/w/cpp/language/definition" rel="nofollow noreferrer">one definition rule</a>. Also the compiler is allowed to reorder private member variables, which would totally break your builds, but no compiler does this in practice.</p>
<p>In practice you need to work around these issues, and if all else fails there is always the ultimate code insulation tool that is the <a href="https://en.cppreference.com/w/cpp/language/pimpl" rel="nofollow noreferrer">pimpl-idiom</a>.</p>
<p>And there certainly are situations where the declarations are necessary. E.g. if you have a really big class where you have multiple .cpp files for the implementation, you need them if it is used in another files that where it is defined.
Or public <code>inline</code> functions that reference the private functions. Or <code>friend</code> functions and classes that may need access to them.</p>
<p>So I assume that in the end there so many situations where you need the declarations, that the gained insulation is just not worth the effort and the added fragmantation and complexity that would come with retroactively fitting a solution into the language at this point.</p>

CC BY-SA 4.0
2023-05-25T17:57:51.290Z
2023-05-26T06:10:53.150Z
2023-05-26T06:10:53.150Z
chrysante
CC BY-SA 4.0
2023-05-25T18:16:35.143Z
That’s a good point about stack allocation — all objects in Objective-C are pointers to heap memory.
Bbrk24
# Why does C++ require private methods to be declared with public ones?
Posted by: username_0 on 2023-05-25
C++ and Objective-C both require forward declaration of the methods and fields on a class. Objective-C lets you hide the existence of internal/private methods & fields altogether:
// MyObject.h
#ifndef _MyObject_h_
#define _MyObject_h_

#import 

@interface MyObject : NSObject {
  NSInteger publicIvar;
}

- (void)publicMethod;

@end

#endif

// MyObject+Internal.h
#ifndef _MyObject_Internal_h_
#define _MyObject_Internal_h_

#import "MyObject.h"

@interface MyObject () {
  NSInteger internalIvar;
}

- (void)internalMethod;

@end

#endif

// MyObject.m
#import "MyObject+Internal.h"

@implementation MyObject {
  NSInteger privateIvar;
}

/* method implementations */

@end

If the project is configured such that dependents can’t import MyObject+Internal.h, they can’t use the symbols from that extension. However, C++ doesn’t allow this; all fields and methods must be declared in one place. Dependents are able to see things that they can’t use.
In a language like these that requires forward declarations, what are the advantages of requiring private functionality to be declared in a public header?
**Tags:** object-oriented c++ history
---
## 2 answers
### Answer by username_3 on 2023-05-25. Score: 9 | Accepted answer
As also explained by the other answer, all member variables need to be declared in the header, because by themself all types in C++ are value types. This implies that the compiler needs to know their size and alignment to allocate them on the stack, and that is computed from the member variables.

Private methods however wouldn't necessarily need to be declared in the header. This is a somewhat unfortunate state of affairs, especially if your private methods take argument types that you don't want to expose in the header.

If you *really* wanted, you could in your .cpp file `#define private public` and just define private member functions as static free functions that take the object by reference or pointer. Note that this suggestion is not really serious, because it violates the [one definition rule](https://en.cppreference.com/w/cpp/language/definition). Also the compiler is allowed to reorder private member variables, which would totally break your builds, but no compiler does this in practice.

In practice you need to work around these issues, and if all else fails there is always the ultimate code insulation tool that is the [pimpl-idiom](https://en.cppreference.com/w/cpp/language/pimpl).

And there certainly are situations where the declarations are necessary. E.g. if you have a really big class where you have multiple .cpp files for the implementation, you need them if it is used in another files that where it is defined.
Or public `inline` functions that reference the private functions. Or `friend` functions and classes that may need access to them.

So I assume that in the end there so many situations where you need the declarations, that the gained insulation is just not worth the effort and the added fragmantation and complexity that would come with retroactively fitting a solution into the language at this point.
> **Comments:**
> **username_0** (2023-05-25): That’s a good point about stack allocation — all objects in Objective-C are pointers to heap memory.  
---
### Answer by username_1 on 2023-05-25. Score: 5
The private attributes may effect the position of public attributes. If you have a class like this:
class A {
   public:
       int a;
}

Here, a is placed at the first position, thus x.a translates to *(a+0). But on the other hand if you have this:
class A {
    private:
        int b;
    public:
        int a;
}

Here, a is will be stored at *(x+1), a different place. The private variable, while not directly accessible, effects accesses to public variables.
I can speak from experience that absolutely everything breaks when your variables are not where you expect them to be, from when I tried to #ifdef out private methods when a header was included.
I'm guessing it works the same way for methods for consistency.
> **Comments:**
> **username_2** (2023-05-25): Doesn't directly answer the whole question, but it could probably bear extending with "and if that's how it is for fields, then it's extra effort for less utility to make it work with methods anyways".  
---
