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
> 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
> 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<>
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
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
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