Re: [boost] [function] "paranoia" vs efficiency

Subject: Re: [boost] [function] "paranoia" vs efficiency
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2009-11-01 17:28:11

"Stewart, Robert" <Robert.Stewart_at_[hidden]> wrote in message
news:DF2E67F3D097004694C8428C70A3FD69046F261514_at_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