On Mon, 13 Oct 2003 14:50:14 -0400 David Abrahams <[EMAIL PROTECTED]> wrote:
> Robert Vazan <[EMAIL PROTECTED]> writes: > > > Because Vadim has something against compatibility with VC6 and I have > > something against performance, compatibility with bare pointers (we have > > two-way conversion while boost insists that all pointers are converted to > > shared_ptr after operator new and then only used) > > Actually it is possible to detach the raw pointer using a custom > deleter. You just use get_deleter to detect your custom deleter and > tell it not to deallocate anything. I don't understand this, but conversion from bare pointers can be solved with weak pointer in MObjectRC as I have just read. > > and inlining (I do care about binary size) > > ...and what about inlining? I don't understand this. > Not so. In fact we have a fast allocator option for those who worry > about the cost of count allocation. I have seen benchmarks. It still isn't as fast as intrusive ref counting. There is also the cost of extra memory. > Maybe you mean something by "optimized" that I'm not familiar with? Have you seen the benchmarks? > However, shared_ptr is > specifically optimized for interoperability I don't quite understand this. Every class chooses for itself which smart pointer it wants to use. Derived classes cannot change it, of course. So what, I've chosen RefCounter for MObjectRC. How does it endanger interoperability? The only difference is class name and (rarely used) member names. I would say that it is optimized for ease of use. You don't have to adapt classes for ref counting. I don't think it matters here. > at the expense of size, > which could in theory affect performance *but nobody has ever shown it > to be a measurable bottleneck*. I am sure that this isn't going to be bottleneck. Bottlenecks don't happen unless there is a bug somewhere. Cost is always distributed all over the place. However some 20-30% improvement from intrusive ref counting (and consequent 2-3% global improvement) is important optimization target, especially when it can be achieved so easily. > > It relies on compilers that don't exist. > > That's an outlandish claim. I don't believe that templates are optimized to extent that they become invisible. > > And, after all, it has strictier license than our own code. > > Really? It's about as loose as they come, short of "public domain". Sorry, I overlooked "permission to modify" part. On the other hand, it suggests that modified work must be under that same license and (as I understand it) under that same copyright as original library. This looks like strictier Gpl. I am not sure what's the difference between modified and derived work. ------------------------------------------------------- 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
