Re: [boost] Pimpl Again?

Subject: Re: [boost] Pimpl Again?
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2016-05-31 21:02:18

On 2016-06-01 09:48, Emil Dotchevski wrote:
> On Tue, May 31, 2016 at 4:42 PM, Vladimir Batov <
> Vladimir.Batov_at_[hidden]> 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" :-)