On Tue, 14 Oct 2003 14:27:39 -0400 David Abrahams <[EMAIL PROTECTED]> wrote:
Proper deallocation when objects are passed across DLL boundaries. This might be relevant to you if you are allowing people to implement plugins, especially Python extension modules.
No such problem with intrusive ref counting.
It has nothing to do with intrusive or external refcounts; it has to do with the dynamic deleter function which is instantiated at the point the smart pointer first takes ownership of the pointee.
A function recieving a shared_ptr can be ignorant of its deallocation and refcounting strategies (avoids a template!!)
Every class chooses its smart pointer
By Mahogany convention, you mean?
> so there is no reason to accept multiple smart pointers.
Things are different for template functions, but there are (template) adaptors for those cases.
Your relationship to templates really confuses me. How are things different for function templates?
The ability to manage objects held as direct data members of other objects.
Dangerous.
To some degree. As I said before, this may not matter to your project.
The ability to correctly handle polymorphic classes without virtual destructors
No such problem with intrusive ref counting.
This also has nothing to do with intrusive/extrusive refcounting.
The ability to handle a refcounted heap-allocated object or an unmanaged (e.g. stack or global) object with the same shared_ptr interface (using a null deleter)
Dangerous.
Not at all. The lifetime of that object never ends anyway and the holder of a shared_ptr never has the right to expect that destroying that shared_ptr will result in destruction of the pointee.
Does your development time matter? Is it worth your time to reimplement this stuff?
Implementing smart pointers is extremely cheap compared to conversion of legacy code. When we are past that point, we can convert RefCounter to shared_ptr or other type automatically. It's worth spending effort on 100 lines of code that is used 100 000 times. Integrating boost is no fun either, just to get smart pointers.
I wasn't suggesting that you integrate it just to get smart pointers. I might not think that was a great trade-off either. Anyway, it's clear you don't want to use Boost, so there's no point flogging the horse carcass, as they say.
Robert Vazan <[EMAIL PROTECTED]> writes:
I am not sure what's the difference between modified and derived work.
Me neither. Nor am I sure why it's relevant.
Mixed Gpl and non-Gpl code must be published under Gpl. I am afraid that this applies to shared_ptr too.
Oh, I didn't realize Mahogany was GPL'd. I thought you were worried that Boost's license was *more* restrictive.
Anyway, as I said: it's your nickel. If you want to roll your own smart pointers, who am I to say otherwise? I'm outta this thread now ;->
No problem. I think it was a good choice. I also think that external library can be better, but Boost isn't.
Suit yourself, my friend. In the meantime, I found Mozilla's Thunderbird project, which seems much closer to doing everything I need from a mailer (sans crashes), so I'm feeling more optimistic about the future too.
G'night!
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
