C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Policy Based Smart Ptr (n1681)          C++Talk.NET Forum Index -> C++ language, library and standards View previous topic :: View next topic   Author Message Vladimir Marko Guest Posted: Thu Oct 21, 2004 1:55 am    Post subject: Policy Based Smart Ptr (n1681) I've got two questions regarding the Policy Based Smart Ptr proposal (n1681). 1. Which policy covers the constness propagation? (In my opinion it is a crucial property of a smart pointer suitable for use in pimpl-idiom.) 2. Should the chained-policy approach illustration (page 4, similar on page 10) read template <typename T, template template<typename> class OwnershipPolicy, template<typename> class ConversionPolicy, template<typename> class CheckingPolicy> class smart_ptr : public CheckingPolicy< ConversionPolicy< OwnershipPolicy< StoragePolicy Quote: { ... }; instead of template <typename T, class StoragePolicy,class OwnershipPolicy, class ConversionPolicy,class CheckingPolicy> class smart_ptr : public CheckingPolicy< ... Quote: { ... }; ? Vladimir Marko --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top David B. Held Guest Posted: Mon Oct 25, 2004 6:21 pm    Post subject: Re: Policy Based Smart Ptr (n1681) Vladimir Marko wrote: Quote: I've got two questions regarding the Policy Based Smart Ptr proposal (n1681). 1. Which policy covers the constness propagation? (In my opinion it is a crucial property of a smart pointer suitable for use in pimpl-idiom.) Good question. There has been much debate on the Boost mailing list about whether smart pointers should propagate constness or not. The general consensus is that they should not, because raw pointers do not, and in most cases, that is not what is desired. I believe it would be fairly easy to write a custom storage policy (call it deep_const_storage, if you like) which does propagate constness. I will consider writing such a policy myself, if you do not volunteer one first. ;) Quote: 2. Should the chained-policy approach illustration (page 4, similar on page 10) read template <typename T, template template<typename> class OwnershipPolicy, template<typename> class ConversionPolicy, template<typename> class CheckingPolicy class smart_ptr : public CheckingPolicy ConversionPolicy OwnershipPolicy StoragePolicy<T { ... }; instead of template class StoragePolicy,class OwnershipPolicy, class ConversionPolicy,class CheckingPolicy class smart_ptr : public CheckingPolicy ... { ... }; No. The policies really are class types. More specifically, to use the terminology of Boost.MPL, they are "metafunction classes". That is, they are classes containing a metafunction named apply<> (which "returns" a type named 'type'). This makes them very convenient to use with MPL, and not much more difficult for policy writers to write. This was especially important when support for template template arguments was flaky across a large number of compilers. Even though support is decidedly better, it turns out that metafunction classes are more flexible anyway (for instance, they are polymorphic w.r.t. template arity), and the next version of MPL allegedly has built-in meta-lambda, which means that it should also be possible to pass in lambda-ized templates as well, without me having to modify the policy adaptor. What that means is that today, you can write: smart_ptr<array_storage, assert_strict>::to<foo> p; Because those are class types with nested template classes that do the real work. If you write your own policy, my_policy, you should also write a metafunction class wrapper for it, and really do it like so: template <typename P> class my_policy_ { // ...good stuff goes here }; struct my_policy { template <typename P> struct apply { typedef my_policy_<P> type; }; }; Then you will also be able to send in your policy even though smart_ptr<> does not accept template template arguments: smart_ptr<my_policy>::to<foo> q; In the future, you should also be able to do this: smart_ptr<my_policy_<_> >::to<foo> r; This uses the meta-lambda facilities of MPL to allow you to pass your raw template class through the policy adaptor without writing a wrapper class (though I still prefer the wrapper). Dave --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top David B. Held Guest Posted: Mon Oct 25, 2004 8:31 pm    Post subject: Re: Policy Based Smart Ptr (n1681) Vladimir Marko wrote: Quote: I've got two questions regarding the Policy Based Smart Ptr proposal (n1681). 1. Which policy covers the constness propagation? (In my opinion it is a crucial property of a smart pointer suitable for use in pimpl-idiom.) Good question. There has been much debate on the Boost mailing list about whether smart pointers should propagate constness or not. The general consensus is that they should not, because raw pointers do not, and in most cases, that is not what is desired. I believe it would be fairly easy to write a custom storage policy (call it deep_const_storage, if you like) which does propagate constness. I will consider writing such a policy myself, if you do not volunteer one first. ;) Quote: 2. Should the chained-policy approach illustration (page 4, similar on page 10) read template <typename T, template template<typename> class OwnershipPolicy, template<typename> class ConversionPolicy, template<typename> class CheckingPolicy class smart_ptr : public CheckingPolicy ConversionPolicy OwnershipPolicy StoragePolicy<T { ... }; instead of template class StoragePolicy,class OwnershipPolicy, class ConversionPolicy,class CheckingPolicy class smart_ptr : public CheckingPolicy ... { ... }; No. The policies really are class types. More specifically, to use the terminology of Boost.MPL, they are "metafunction classes". That is, they are classes containing a metafunction named apply<> (which "returns" a type named 'type'). This makes them very convenient to use with MPL, and not much more difficult for policy writers to write. This was especially important when support for template template arguments was flaky across a large number of compilers. Even though support is decidedly better, it turns out that metafunction classes are more flexible anyway (for instance, they are polymorphic w.r.t. template arity), and the next version of MPL allegedly has built-in meta-lambda, which means that it should also be possible to pass in lambda-ized templates as well, without me having to modify the policy adaptor. What that means is that today, you can write: smart_ptr<array_storage, assert_strict>::to<foo> p; Because those are class types with nested template classes that do the real work. If you write your own policy, my_policy, you should also write a metafunction class wrapper for it, and really do it like so: template <typename P> class my_policy_ { // ...good stuff goes here }; struct my_policy { template <typename P> struct apply { typedef my_policy_<P> type; }; }; Then you will also be able to send in your policy even though smart_ptr<> does not accept template template arguments: smart_ptr<my_policy>::to<foo> q; In the future, you should also be able to do this: smart_ptr<my_policy_<_> >::to<foo> r; This uses the meta-lambda facilities of MPL to allow you to pass your raw template class through the policy adaptor without writing a wrapper class (though I still prefer the wrapper). Dave --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language, library and standards All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.