Re: [boost] Pimpl Again?

Subject: Re: [boost] Pimpl Again?
From: charleyb123 . (charleyb123_at_[hidden])
Date: 2016-05-31 17:12:23

>
> 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.

This is why I'm such a fan of CRTP (curiously-recurring-template-pattern),
where it should work for this PIMPL design with no virtual and no overhead.

I've been quiet on this thread, but:

  *- I like the PIMPL pattern very much
  *- I like your approach
  *- I want no overhead
  *- I vote CRTP
  *- CRTP also allows template-member-functions (requested by Chris, also
desired by me)
  *- I'm generally disappointed with namespaces

--charley

On Tue, May 31, 2016 at 1:03 PM, Emil Dotchevski <emildotchevski_at_[hidden]>
wrote:

> On Mon, May 30, 2016 at 11:22 PM, Vladimir Batov <
> Vladimir.Batov_at_[hidden]> wrote:
>
> > On 2016-05-31 13:41, Emil Dotchevski wrote:
> >
> >> On Sun, May 29, 2016 at 10:47 PM, Vladimir Batov <
> >> ...
> >> Polymorphism -- the snippets I provided are sufficient, virtual function
> >> calls work just fine. For example, in the CPP file you could define
> >> do_something (see above declaration) like so:
> >>
> >> void do_something( foo * p )
> >> {
> >>   p->do_something(); //virtual
> >> }
> >> ...
> >>
> >
> > Indeed. You right... Once we take the methods out to be free-standing
> > functions, there is nothing left of the interface/proxy class but
> > shared_ptr<foo>... I have to admit it never occurred to me... :-) Not
> sure
> > if I am ready to do things your way :-) but you are most certainly
> correct.
> > Thank you.
>
>
> Wow I must admit this surprises me, the resistance I usually get is much
> stronger. :)
>
> 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.
>
> Thanks,
> Emil
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>