On 2017-08-21 16:29, Andrzej Krzemienski via Boost wrote:

2017-08-20 0:46 GMT+02:00 Vladimir Batov via Boost :

...

2) As I think I mentioned before impl_ptr is not part of any namespace by design... because the way proxy and implementation are connected, the specialization of impl_ptr<>::implementation. As I also mentioned it is IMO only a "problem" for "purists" but not for "practitioners" as from outside it is all kosher and accessed via boost::impl_ptr.

Could you summarize why using the global namespace is necessary?

template<> struct impl_ptr<Foo>::implementation is a template specialization. So, it has to be defined in the original namespace. So, if it is namespace boost { template<typename> struct impl_ptr; } then the developer will have to declare his specialization of "implementation" inside boost: namespace boost { template<> struct impl_ptr<Foo>::implementation { ... }; } That's ugly and wrong. So, I did template<typename> struct _internal_boost_impl_ptr; namespace boost { template<typename T> using impl_ptr = ::_internal_boost_impl_ptr<T>; } Now for all purposes impl_ptr appears as "boost::impl_ptr". Then, the developer defines his "implementation" specialization like template<> struct boost::impl_ptr<Foo>::implementation { ... }; which looks sensible IMO.

On 21-08-17 11:48, Vladimir Batov via Boost wrote:

That's ugly and wrong.

/I'm just gonna say it's neither ugly nor wrong./ On 22-08-17 09:50, Gevorg Voskanyan via Boost wrote:

so for a long time now, we have a precedent too.

One of a great many. Same for specializations of std::hash, boost::hash, boost::fusion::extension::*, boost::spirit::traits::*, etc. That said, I'm not convinced there isn't a "better" way: why not implement another layer of indirection. Make it a trait: boost::impl_ptr::traits::implementation_for::type could be made to refer to the user-defined implementation type. That way the "pain" is only in 1 line where the trait is specialized.

On 22-08-17 23:37, Vladimir Batov via Boost wrote:

template<> struct boost::impl_ptr<Foo>::implementation

not at all. I believe it is you who named that "ugly and wrong". So there you go.

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. On 24 August 2017 at 13:34, Vladimir Batov via Boost wrote:

On 2017-08-24 16:54, Seth via Boost wrote:

...

On 22-08-17 23:37, Vladimir Batov via Boost wrote:

...

template<> struct boost::impl_ptr<Foo>::implementation

not at all. I believe it is you who named that "ugly and wrong". So there you go.

Thank you for clarifications. Appreciated. All good then. :-) I was referring to something similar but different... but obviously muddled it all up. Moving on. :-)

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost

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@lists.boost.org> 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

@Vladimir - issue posted on github. On 9 September 2017 at 09:52, Vladimir Batov via Boost < boost@lists.boost.org> wrote:

On 2017-09-09 17:12, Richard Hodges via Boost wrote:

...

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

Well, to clarify -- there was no Boost review... There was some initial (and very useful) input to my submission request but Boost-wise the submission did not get anywhere... as the review mgr could not be found... so far anyway. Still, something good indeed has come of as after Giel's effort impl_ptr is a serious smart pointer for the purpose.

If you'll allow my first commit to add a CMakeLists.txt file I'll happily

...

just start using it and contributing where possible.

All contributions are most and truly welcome. For starters I'd suggest you fork the project first into your GitHub userspace. Apply your changes. Then, submit a pull request, Giel or I will be happy to merge it in. I might not be able to do that for a few more days (I am away). Looking forward to your input.

On 8 September 2017 at 22:53, Vladimir Batov 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

Thanks for pointing this out Andrzej. I'll refactor another project of mine to use it and give it a thorough workout. R On 11 September 2017 at 09:04, Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:

2017-09-08 22:53 GMT+02:00 Vladimir Batov via Boost

...

:

...

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.

Regarding visibility, maybe registering in Boost library Incubator ( http://blincubator.com/) should attract potential users and reviewers.

Richard, Since you have expressed a clear interest in the library, maybe you could consider *endorsing* it, as required by the new Boost Library Submission process: http://www.boost.org/development/submissions.html

This would be a hint for potential reviewers and review manager that the library is worth investing their time.

Regards, &rzej;

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost