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
>>> syntax" can only be used with member functions, but member functions
>>> access to the private data, which means that they must participate in
>>> type definitions (encapsulation), which means they can't be called
>>> the type being complete. The C++ solution to this problem is to use
>>> abstract types with no data members in header files, but that has
>>> function call overhead compared to the C-style approach.
>>> It would have been useful for C++ to allow the declaration of
>>> "member" functions outside of the type definition. This would require
>>> 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
> 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" :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk