Re: setter for deleter in boost::shared_ptr (and alike)
On 25 Sep., 23:24, "Alf P. Steinbach" <al...@start.no> wrote:
I agree, but there is an independent setter, namely get_deleter, and
it's as far from const-correct as it can be.
I agree concerning the const-correctness issue (which I
have intensively discussed in *my* reply to *your*
reply to the O.P. ;-) )
I don't think that despite this issue get_deleter is a
bad design, just because it returns an object address. Yes,
this differs from the usual copy-approach that penetrates
the STL (get_allocator(), key_comp(), value_comp()), but
note that we also have:
deleter_type& unique_ptr<T, D>::get_deleter();
const deleter_type& unique_ptr<T, D>::get_deleter() const;
Returning an lvalue like this is of-course a stronger
binding to an implementation than returning an rvalue
would be, but I similarily accept the p.o.v that the
deleter is part of the object of unique_ptr and shared_ptr
as e.g. elements of a container are (which are reachable
via their references - if we ignore std::vector<bool> for
a moment ;-)). Further-on the default deleters do not
allow a modification of the deleter state itself - even,
if a mutable reference is available. And providers of
shared_ptr deleters can easily ensure proper encapsulation
of those by a proper class design (if that it is one). I
can't remember to have seen a deleter in my life, which
would allow to influence it's actual task in this
manner. Even if it would do, I don't think that C++
is a language that would prevent one of doing so in
this rather artifical situation.
One may hope the committee /makes time/ to fix this, and also to add
std::destroy and std::destroy_array (plus, while they're at it, change
the relevant wording so that we can specialize function templates in
namespace std, e.g. swap and destroy!), so that we can avoid ending up
with a standardized shared_ptr that's full of design level bugs.
Would you mind to explain your strong preference for
std::destroy? - I haven't understand this.
Actually I have a similar extension wish, but maybe for
different reasons:
The [memory] synopsis provides a bunch of helper functions
to support copy and fill for unconstructed items, but it
does *not* provide a std::destroy function of the signature:
template <class ForwardIterator>
void destroy(ForwardIterator first, ForwardIterator last);
which basically exists in every library implementation I
know of (of course with a proper name like _Destroy).
A typical implementation of the most general case is
a loop of type
for (; __first != __last; ++__first)
_Destroy(&*__first);
(where we are back at *your* proposed one-argument
std::destroy overload for pointers!)
The reason for my request is that implementors can do
very nice optimizations of this beast, i.e. they can
use type traits to discriminate types with trivial
destructors which end up in a no-op implementation of
the two-argument overload of destroy. Of-course from
C++0x on this could be done by every programmer - but
this would be a repeated reinvention of the wheel by
every thirdparty library which is involved in such
doings - which really sucks me (and for similar reasons
one could have rejected the uninitialized_* functions
as well - they are of similar complexity and always
use something like _Destroy internally).
What do you think?
Greetings from Bremen,
Daniel
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]