On 12/12/2010 02:27, Joshua Maurice wrote:
On Dec 11, 6:00 pm, Leigh Johnston<le...@i42.co.uk> wrote:
On 12/12/2010 01:23, Joshua Maurice wrote:
On Dec 11, 5:19 pm, Tiib<oot...@hot.ee> wrote:
On Dec 12, 2:30 am, Joshua Maurice<joshuamaur...@gmail.com> wrote:
On Dec 11, 11:57 am, "Chris M. Thomasson"<cris...@charter.net> wrote:
"Leigh Johnston"<le...@i42.co.uk> wrote in message
news:aI-dnTRysdoEVJ7QnZ2dnUVZ7sSdnZ2d@giganews.com...
On 11/12/2010 18:47, Chris M. Thomasson wrote:
[...]
How there can be such an heated discussion about singleton anti-
pattern? If several singletons get constructed during concurrent
grabbing of instance() then destroy them until there remains one. Or
better none. No harm made since singletons are trash anyway.
I haven't been talking about singletons. I've been having a heated
discussion over incorrect, or at least non-portable bad-style,
threading code.
Bullshit. I never said it was portable. It works for me on the
implementation I use. What is bad-style is Kanze's leaky, broken
(multiple TU) singleton method. What is bad-style is designing classes
without any consideration of object destruction.
One can instantiate multiple "Meyers Singletons" before creating any
threads to avoid any singleton related threading code. No object
destruction problems.
You continue to assert that a memory leak is bad a priori. The rest of
us in this thread disagree with that claim. Instead, we program to
tangible requirements, such as cost, time to market, meets (business)
use case. We also keep in mind less tangible but still important
considerations, like maintainability and reusability.
You are not listening. If you have multiple singletons using Mr Kanze's
method that "you all" agree with it is unspecified as to the order of
construction of these singletons across multiple TUs; i.e. the method
suffers the same problem as ordinary global variables; it is no better
than using ordinary global variables modulo the lack of object
destruction (which is shite). Unspecified construction order is anathema
to maintainability as the order could change as TUs are added or removed
from a project.
"No memory leaks" in the sense you're using has never been a
(business) use case for any of my projects. However, arguably, you
have a good point with regards to maintainability and reusability
w.r.t. the use case of repeated loading and unloading of the same DLL
in the same process.
With that out of the way, let's go back to the threading issue. I
never claimed that you claimed that it was portable. I said the code
is very badly written because writing the threading code the correct
way:
1- carries no additional runtime cost,
2- has less time to code (as you don't need to whip out an x86
assembly manual),
3- let's others easily verify your code's correctness (as it doesn't
require them to whip out an x86 assembly manual),
4- better guarantees that future compiler or hardware upgrades won't
break your program,
5- gives portability,
6- and finally makes you look like not someone who writes bad code.
As Chris pointed out the only problem with my version compared to the
version given in document by Meyers and Alexandrescu that you seem so
fond of is the lack of a memory barrier after the initial fast check but
this is only a problem for a minimal number of CPUs as the load is
dependent. If I had to port my code to run on such CPUs I simply have to
add this extra barrier.
In the real world people write non-portable code all the time as doing
so is not "incorrect".
/Leigh