Re: [boost] Pimpl Again?

Subject: Re: [boost] Pimpl Again?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-05-31 21:09:36

On Tue, May 31, 2016 at 6:02 PM, Vladimir Batov <
Vladimir.Batov_at_[hidden]> wrote:

> 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" :-)

What I mean by non-friend member is something that is currently not
supported in C++, which is defined/declared/called using the member
function syntax, but has no access to the private or protected members of
the class. So:

struct foo; //incomplete
void foo::do_something();

would be semantically the same as:

struct foo; //incomplete
void do_something( foo * );

the only difference being in syntax: the former would be callable using the
dot syntax.

Emil