Re: [boost] Pimpl Again?

Subject: Re: [boost] Pimpl Again?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-05-31 19:07:26

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

> On 2016-06-01 07:58, Emil Dotchevski wrote:
>
>> On Tue, May 31, 2016 at 2:48 PM, Rob Stewart <rstewart_at_[hidden]> wrote:
>>
>>> The upside is not writing some calls one way and others the other way on
>>> the same object, and having to remember which is which.
>>>
>>
>> So, don't use the dot syntax. :)
>>
>
> Even I must say that from the "purist" point of view forcing free-function
> API kinda violates the very basic OO paradigm -- the association between
> data and behavior. From practical point of view it's "meh, big deal".
>

C++ provides alternative mechanisms to express that association, for
example:

namespace boost { template <class> class shared_ptr; };

namespace file
{
  struct handle;
  boost::shared_ptr<handle> open( char const * name );
  void read( handle *, void * buf, size_t size );
}

As a bonus, ADL allows unqualified calls to read (but, obviously, not to
open.)

That said, the most important feature of object-oriented design is data
encapsulation, which is actually stronger if types are left incomplete in
interfaces, compared to using private/protected.

> Please do not get me wrong. I am not criticizing your approach. In fact,
> to me it feels surprisingly potent just using the tools we've had
> "forever". I feel that it is unlikely to "fly" with "general programming
> population". :-)

Yes, I'm aware of that. It doesn't mean they have a point though. :)

I just can't support including yet another can of worms in the already
complicated name lookup/implicit instantiation/overload resolution process.
A compromise would be to allow the definition of non-friend members, like
this:

struct foo;
void foo::do_something();

This language change seems a lot safer than messing with the overload
resolution. Perhaps I'm wrong. Either way, I don't consider "but I want to
use the dot syntax" a very compelling argument.

Emil