Re: Containers for derived classes
David Abrahams <[email protected]>
| Newsgroups | gmane.comp.lib.boost.langbinding |
|---|---|
| Message-ID | <[email protected]> |
Daniel Wallin <[email protected]> writes: > BTW. What's the motivation for holding objects by shared_ptr<..>? A very good question. I'm not sure what *motivates* it, but you do get certain capabilities which you wouldn't get otherwise. For example, you can convert the Python object to shared_ptr<...>&, and then the shared_ptr itself can be modified. Whether or not that's actually useful is another question. If we'd like to always be able to use your adopt() policy without worrying about a runtime failure, I think we'd want to hold all C++ objects by auto_ptr instead. Hmm, I guess there's another case where its important. If some wrapped function *returns* shared_ptr<T>, there's no way to release the T object from the shared_ptr. Therefore you simply want to use the shared_ptr in the holder. So I guess I'm coming to the conclusion that the goal of holding all objects by auto_ptr is impractical. I think it's probably a bad idea anyway, since using special smart pointers in holders is extraordinarily useful. See Joel's recent indexing suite work, for example. In fact, all of the return_internal_reference stuff ought to be using a special smart pointer holder rather than the funky weakref stuff it currently does. > Doesn't the conversions to/from shared_ptr invalidate the use of > the holder? I don't understand the question, sorry. -- Dave Abrahams Boost Consulting www.boost-consulting.com ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01