"Stewart, Robert" <Robert.Stewart@sig.com> wrote in message news:DF2E67F3D097004694C8428C70A3FD69046F261514@msgbal516.ds.susq.com...
Domagoj Saric wrote:
documentation states that shared_ptr uses a more joe sixpack approach with a "forced" dynamic deleter on purpose, to achieve a simpler interface and a more 'stable' abi (the point seems moot imho, the same could be achieved with default template parameters while retaining compile-time configurability)...
The same could not be achieved with defaulted template arguments. The idea is that, regardless of how something is allocated and deleted, the shared_ptr type only depends upon the type it points to. That permits interoperability among a great deal more code such as in Windows when a DLL uses a different RTL than the application.
i realize that but can't the same be achieved with a template-parameter-specified deleter that is in fact a dynamic deleter? the default provided dynamic_deleter class could still be constructible from any source that makes the expression d(p) well formed (as stated by shared_ptr documentation)...just like the current boost::detail::sp_counted_impl_pd<> class is... in other words the status quo is as if you hard-coded the deleter template parameter to be a dynamic deleter... what i'd like is (like in all things) to have the option of using the power (you mentioned in your example) of a more stable/type only dependent ABI _when i actually need it_ and also being free of virtual functions/indirect calls (and maybe/possibly even rtti) when i do not need it (which "i bet" is the vast majority of shared_ptr<> uses "out there")... but, yes, this is going off topic...
the boost::function documentation states that virtual functions are not used because they cause code bloat but comparing the actual binaries and code generated i found boost::function to actually be worse in that respect than the std::tr1::function implementation provided with msvc++ 9.0 SP1 (that does use virtual functions)...
The claim was made years ago and is for a library that doesn't have the benefit of being written by those with direct access to those writing the compiler. It may be that things have changed and that another approach is superior now, as your analysis of std::tr1::function in MSVC 9 SP1 suggests.
well the stl shipped with msvc (9) is provided by dinkumware, not ms, and can be bought separately from the msvc++ compiler...and as such does not use some particular 'msvc++ specific' tricks...not that i know of...it certainly does not use any in the implementation of std::tr1::function<>...it is standard c++... the issue is what makes virtual functions different from plain function pointers and manual vtables in this case...they both constitute a 'brick wall' for the optimizing compiler and add indirection...virtual functions/standard polymorphism only adds rtti...but the compiler is free (afaik) not to include that rtti information/record in the final binary if it is not used (or rtti is disabled alltogether)...what constitutes a bigger problem is that the type information for the contained function object is forced to be included by the target<>() member function that is part of the interface...but that is inherent to the interface (and thus present in all compliant implementations...meaning in boost and dinkumware)... ...there are however many other implementation details that can be done differently (or be made subject to configurability) while retaining standard compliancy...and this is what i tried to do...and according to performed tests the result is better than both dinkumware and the current boost implementation in both space and time efficiency with added configuration power... ;) -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley