-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 09 July 2009, Andrey Semashev wrote:
Frank Mori Hess wrote:
And perhaps more significantly, a monitor_ptr is a completely different type than a shared_ptr. So, for example, a monitor_ptr can't be passed to a function that expects a shared_ptr as an argument.
Types shared_ptr<monitor<T*> >, shared_ptr<T*> and shared_ptr<T> are not compatible either, so you don't win here anything.
That's mostly true, however suppose you have a function like template<typename T> myfunc(shared_ptr<T> sp); You might say it could be replaced with something more generic like template<typename SharedPtr> myfunc(SharedPtr sp); but perhaps myfunc creates a weak_ptr<T> from the incoming parameter. The more generic version won't work because shared_ptr doesn't include a typedef for its corresponding weak_ptr type. Also, the more generic version of myfunc might cause conflicts if myfunc has other overloads. You'd be forced to add specialized code for each additional shared_ptr-like class you introduce, or something like type traits for them.
IMHO, one of the remarkable features of shared_ptr is its simplicity.
I agree.
All additional features that you describe, while being useful, are out of scope of this simple tool. I agree that some more elaborate policy-driven smart pointer would be useful to implement those things. It just isn't related to shared_ptr in any way.
Perhaps I should have distanced my idea from shared_ptr more in presenting it, as I know making interface changes to shared_ptr is almost unthinkable at this point. But it's obviously a related idea, in that generalized_shared<T*> would be equivalent to shared_ptr<T>. And also I imagine generalized_shared could be implemented by copying the entire shared_ptr codebase and then making only minor changes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpWT/0ACgkQ5vihyNWuA4U1RACggaAZopOtBZj2Nv2X58JdCL/D g1kAoIvAa/D9e1c6N5Z4jfbWgVk3FuZZ =5jFA -----END PGP SIGNATURE-----