On 2016-06-01 09:48, Emil Dotchevski wrote:
On Tue, May 31, 2016 at 4:42 PM, Vladimir Batov < Vladimir.Batov@constrainttec.com> wrote:
On 2016-06-01 05:03, Emil Dotchevski wrote:
... The problem from language design point of view is that in C++ the "dot syntax" can only be used with member functions, but member functions have access to the private data, which means that they must participate in the type definitions (encapsulation), which means they can't be called without the type being complete. The C++ solution to this problem is to use only abstract types with no data members in header files, but that has virtual function call overhead compared to the C-style approach.
It would have been useful for C++ to allow the declaration of non-friend "member" functions outside of the type definition. This would require no change in syntax.
Interesting... and liberating... and dangerous... :-) Aren't you suggesting to actually officially support encapsulation violation?
No, I said non-friend. Look, there is no semantic difference between allowing non-friend member functions to be added without changes to the type definition on one hand, and allowing non-friend free functions to be added without changes to the type definition on the other hand. Neither breaks the encapsulation; the difference is entirely syntactic.
Say, by your book I can write a new free-standing "member" function to your class and cause quite a bit of mischief in there.
Not without having access to the private/protected stuff, which you wouldn't have.
That's where I think communication breaks. "Friend" to me is essentially a "member" (just declared outside) as it has access to "private". So, I interpret "non-friend member" as "non-member member" which my "computer does not compute" :-)