|
Boost : |
Subject: Re: [boost] Is there interest in an alternative to the Singleton anti-pattern?
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2011-06-27 03:59:02
2011/6/27 Ben Robinson <icaretaker_at_[hidden]>:
> The purpose of auto_ptr is to clean up the instance automatically. It was a
> design goal to make destruction of the Singularity explicit, especially in
> multi-threaded contexts. However, users can create custom ThreadingModel
> policies which use any kind of smart pointer they desires. I thought to
> provide the only a primitive pointer for the included policies.
It is a good thing, to have an explicit destructor, but we must call
destructor in case, when user forgets to call destruction or when the
program suddenly exits.
Consider the following example:
DescriptorThatMustBeClosed & horizon =
DescriptorThatMustBeClosed::create(&event);
...
function_that_calls_exit();
...
DescriptorThatMustBeClosed::destroy();
Moreover, auto_ptr is primitive enough and will not make the
performance worse.
> The recommended usage of Singularity is without a globally accessible get()
> function, so the performance of create() and destroy() should not be an
> issue. If global_access is enabled, it would be advisable to minimize calls
> to get(), such as calling get() once per thread, storing the result in
> thread-local storage.
Than it is OK.
More remarks:
1) it is a common practice to put all the support structures and
variables to namespace boost::detail
2) Overload the virtual const char* what() const throw(); function for
all your exceptions (struct singularity_already_created,
already_destroyed, singularity_not_created,
singularity_destroy_on_incorrect_threading )
3) Back to the question with auto_ptr. It looks like there is no need
in specifying the ptr_type. You always return references, user can't
get access to the pointer directly. So, all you need is to hold the
pointer and take care of freeing resources, if user forget to do it.
And std::auto_ptr looks like a great thing for such cases
Best regards,
Antony Polukhin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk