Re: [boost] Review Request: impl_ptr (pimpl)

Subject: Re: [boost] Review Request: impl_ptr (pimpl)
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2017-09-09 07:12:36

Hi Vladimir, great to see that good has come of the review process.

If you'll allow my first commit to add a CMakeLists.txt file I'll happily
just start using it and contributing where possible.

On 8 September 2017 at 22:53, Vladimir Batov via Boost <
boost_at_[hidden]> wrote:

> On 2017-09-09 01:34, Richard Hodges via Boost wrote:
>
>> How is the review process moving on? I have a clear need for this in my
>> code right now.
>>
>> Would love to see it get protection from obscurity by being accepted into
>> boost sometime soon.
>>
>
> Thank you for your interest and encouragement. Much appreciated.
>
> RE: review
>
> As for the actual review, then (unfortunately) there is no one. From my
> understanding the Boost review process has changed and now a submission is
> only scheduled for a review IFF it gets a review manager. It is not a
> position people queue for. :-) So, no one has come forward for impl_ptr to
> be a review manager... as I can see for other submissions also... Before
> such a manager-less submission would be put in the queue and stay on the
> radar... Now such a submission generates initial interest on the list, then
> drifts out of the scope and is left behind/forgotten. It's unfortunate.
>
> RE: obscurity
>
> You might consider going to https://github.com/yet-another-user/pimpl and
> adding a star to the project. It raises its visibility in a GitHub search
> with everything following.
>
> RE: accepted into boost
>
> Initially I personally had my doubts if it was not too simple, obvious and
> basic. Now Giel van Schijndel joined in and made immense
> contributions/improvements to all policies. Namely, 'unique' and 'copied'
> policies are std::unique_ptr-based and pimpl-objects are of the 'void*'
> size... no memory overhead!.. Hugely useful IMO. Then, for high performance
> two in-place (no dyn. mem. allocation) policies are really well-done with
> one such policy not having any mem. overhead at all. So, IMO the submission
> has certainly something to offer functionality-wise and deployment-wise
> beyond manual pimpl-idiom implementation and would be a useful addition to
> the existing set of smart pointers...
>
>
>
>
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman
> /listinfo.cgi/boost
>