Robert Vazan <[EMAIL PROTECTED]> writes: > 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.
I was basically saying "I don't understand why you're mentioning inlining. What about it?" >> 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. Yes, but speed and size of smart pointers isn't everything. What you get in exchange for the speed and size lost to shared_ptr is extremely valuable in many applications. >> Maybe you mean something by "optimized" that I'm not familiar with? > > Have you seen the benchmarks? Yes. The ones at http://www.boost.org/libs/smart_ptr/smarttests.htm only apply to "obsolete" compilers which are more than 3 years old, for what that's worth to you. >> 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. Maybe in your world. If you don't require an intrusive count, that's no longer true. > 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. The interoperability issues handled by shared_ptr inlude: 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. A function recieving a shared_ptr can be ignorant of its deallocation and refcounting strategies (avoids a template!!) The ability to manage objects held as direct data members of other objects. The ability to correctly handle polymorphic classes without virtual destructors 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) The list goes on... > I don't think it matters here. It may be that none of the above matter to you. Does your development time matter? Is it worth your time to reimplement this stuff? >> 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. Maybe in your world. There's lots of software in which the best implementation still concentrates most of the processing time in one or two algorithms. > 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. I'd be highly surprised if you got as much as 1% performance improvement from your choice of smart pointer. But let's be honest, this is all speculation. I'd use an off-the-shelf solution first and replace it later, if neccessary. >> > 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. It depends on the compiler and its settings. It really has nothing to do with templates but with inlining. Whether a function is inlined generally has no relationship to whether it's a template or not. >> > 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. Yes. That's a pretty minimal restriction. There's nothing preventing you from adding copyringhts. I think there's nothing preventing you from adding additional licensing. > This looks like strictier Gpl. Generally the big problem with GPL is that it prohibits people from selling the software. In fact, it makes all the software effectively free. Boost's does not. In fact, it is designed to let people do just about anything they want with it. In principle we are moving all of Boost to a single license: http://www.boost-consulting.com/boost/LICENSE_1_0.txt which was designed specifically to fulfill those license requirements. > I am not sure what's the difference between modified and derived > work. Me neither. Nor am I sure why it's relevant. 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 ;-> -- Dave Abrahams Boost Consulting www.boost-consulting.com ------------------------------------------------------- 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
