It turns out my Review Request was somewhat premature as the submission procedures changed quite a bit. Now it says that to just have "library added to the review queue" I "need to find at least one member (but preferably several) of the Boost community who is willing to publicly endorse your library for entry into Boost". So, to enter the review queue, I need the lib already reviewed... and approved/endorsed. Hmm, feels like a chicken-n-egg situation... but who am I to judge? So, I was told I 1) should first have a review manager, 2) some candidate review dates, 3) and "seconded" support from the mailing list. So, I guess, it is the time when I humbly request if I can find anyone to step forward for No.1 and No.3 of the list? Please?.. Pretty please?.. Jeez, that surely feels awkward. On 2017-08-15 10:51, Vladimir Batov via Boost wrote:
After much procrastination I would like to request a formal review for the pimpl library... once and for all :-) (given it's been through a few almost-reviews and discussions)... to get some kind of a resolution one way or the other. :-)
On one hand it is embarrassingly simple and no match to a string of late TMP submissions. On the other hand it seems quite handy for ordinary s/w folk (like me) as it formalizes, streamlines and noticeably simplifies (IMO) pimpl-based deployments and makes code-review process quite simple and straightforward. Its benefits are more visible for pimpls with exclusive-ownership proxy-implementation relationships (value-semantics pimpls) as it uses internally an incomplete-type management smart pointer instead of std:unique_ptr.
Given that it is policy-based I am hoping others might get interested writing additional policies within that framework such as COW or stack-based.
The major oddity/peculiarity (that caused a stir before and Gavin mentioned about a year ago) is that the main class -- impl_ptr -- is declared in the global namespace. That might happen to be a deal breaker but that's the best I could come up with to get it to work. If anyone has a better working solution, I am all ears.
That "oddity" is an "implementation detail" and does not affect the user -- from the user side it appears inside boost. Like boost::impl_ptr... Internally to address that we might think of striking a compromise. For ex., instead of the traditional
namespace boost { template<> class impl_ptr }
have
template<> class _boost_impl_ptr_
Again, that is an implementation nit, wrinkle, niggle (IMO anyway). From the outside it all looks kosher -- boost::impl_ptr<...> and such.
The code and the docs are at https://github.com/yet-another-user/pimpl <https://github.com/yet-another-user/pimpl>.
Due to personal circumstances Glen -- Pimpl's original manager -- had to bail out. So, if anyone kindly steps forward to manage the review, that'd be immensely appreciated.
Thank you, Vladimir.
P.S. Ron, I am only CCing you so that you'd put it to the schedule... Tnx.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost