Re: setter for deleter in boost::shared_ptr (and alike)
Alf P. Steinbach ha scritto:
But consider: if access to those uninteresting innards of the facility
is truly required in some situations, then that door could just as
easily be locked /by default/, a snap-lock, so that instead of extra
effort to lock it, the instantiating or other code would have to do some
extra thing in order to unlock it for other code or itself. For
example, the operation to replace or change (whatever) the deleter could
require the deleter to be of class type convertible to
"replacable_deleter", in which case the instantiating code would still
have full control, but now a by default locked door. Or, less draconian
and perhaps more practical, security-by-obscurity, the operation to
unlock could require supplying an object implementing "replace_deleter",
which could be made not-completely-trivial to implement, so that other
code wouldn't do that by accident, some spur of the moment idea.
The same effect can be achieved in a very much simple way by just having
get_deleter() return a const pointer. In that way, if the user wants to
modify the deleter he/she must either rely on mutable members or use a
const_cast. Both are ugly enough to say they won't be used by accident.
If the intent truly was to provide possible access to the innards, then
the snap-to lock, the door that's locked by default instead of wide open
by default, e.g. implemented as suggested above, would be my choice.
But my personal preference is option (3), essentially no change allowed.
You've made your point. But we should not forget that read-only access
can be useful and should be provided, IMHO. There's an example of such
need in Boost.Python. Basically, what they do there is the following:
--- UseCase.h
shared_ptr<MyType> Factory();
void SomeFunction(shared_ptr<MyType> ptr);
--- UseCase.cpp
namespace
{
struct MyDeleter { ... }; // this type can't be seen by the user
}
shared_ptr<MyType> Factory()
{
MyType* ptr = /* obtain a MyType object in some way */;
return shared_ptr<MyType>(ptr, MyDeleter());
}
void SomeFunction(shared_ptr<MyType> ptr)
{
if (get_deleter<MyDeleter>(ptr))
{
// ptr has been produced by Factory()
}
else
{
// ptr has been produced in some other way
}
}
---
In this case there is no information stored in the deleter, but it's not
hard to imagine a case where it might be useful to do so. For example,
suppose you have a naive heap-based memory management:
class heap
{
...
template <class T>
struct delete_from_heap
{
heap* m_h;
delete_from_heap(heap* h) : m_h(h)
{}
void operator()(T* ptr) const
{
ptr->~T();
m_h->deallocate_raw_memory(ptr);
}
};
public:
template <class T, class... Args>
shared_ptr<T> allocate(Args&&... args)
{
void* ptr = allocate_raw_memory(sizeof(T));
::new(ptr) T(std::forward<Args>(args)...)
return shared_ptr<T>(ptr, delete_from_heap<T>(this));
}
};
Now, suppose you already have an object allocated in such way and you
want a method to allocate a new object *on the same heap* (because you
are concerned with locality, for example). This could be achieved like this:
template <class T, class U, class... Args>
static
shared_ptr<T> allocate_same_heap(shared_ptr<U> ptr, Args&&... args)
{
// might as well be const delete_from_heap* here
if (delete_from_heap* del = get_deleter<delete_from_heap>(ptr))
{
return del->m_h->allocate<T>(std::forward<Args>(args)...)
}
else
{
// not allocated from a heap
throw /* something here */;
}
}
Do you see a problem in having this kind of access?
Ganesh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]