Hi, (I can't beleive this wouldn't have been discussed already, but I haven't been able to find an answer in my searches [Google's search results into boost's web maillist seem to be incoherent.].) I recently converted a portion of a medium-sized project from loki::Smart_Ptr to boost::shared_ptr (primarily for weak_ptr support), and almost everything worked out of the box, except: boost: template<class Y> explicit shared_ptr <#constructors>(Y * p); loki: SmartPtr(const StoredType& p) In other words, code like this stopped working: some_smart_ptr<int> my_function() { return new int; // error: conversion from `int*' to non-scalar type `boost::shared_ptr<int>' // requested } Even when I adopt the convention to convert the return value to the smart pointer type such as with "return some_smart_ptr<int>(new int)", returning a null pointer as 'zero' doesn't work: some_smart_ptr<int> my_function() { return some_smart_ptr<int>(0); // error: no matching function for call to // `boost::shared_ptr<int>::shared_ptr(int)' } I've worked around this by simply using "return some_smart_ptr<int>();". However, I feel somewhat strongly that this sort of usage is unnecessarily ugly, and confuses the meaning of the code unnecessarily. More importantly, it causes smart pointers to behave differently from ordinary pointers, which is undesirable, as it requires the user (who may not know or care anything about the smart pointer, or even know that it is one, depending on a module's implementation and documentation) to have to learn and use and debug additional semantics. So my question follows. I understand that there are very good reasons for disallowing automatic conversion from a smart pointer, but why disallow automatic conversion to the smart pointer type also? If there are strong reasons for this, would it be reasonable to document this somewhere in the shared_ptr documentation? If not, is this particular aspect of shared_ptr possibly subject to discussion or change in the future? Thank you for your time, Aaron W. LaFramboise