Boost logo

Boost :

From: flameframe_at_[hidden]
Date: 2001-09-07 08:48:50


--- In boost_at_y..., williamkempf_at_h... wrote:
> Win32 does gaurantee this. From the doc for TlsGetValue (emphasis
> added by me):

Sorry, my fault.

> > But it is not a serious issue - writing a self-cleaning version
is
> > trivial.
>
> Self-cleaning?

struct thread_object
{
    thread_singleton<whatever> singl;
    void operator() { ...
};
thread thrd(thread_object);
...
Being destructed thread_singleton reclaims resources. Not an
universal solution, but does not need an additional dll.

>
> > > > - implementation of call_once will fail when called function
> > throws
> > >
> > > I didn't think about this one. I'm not sure if we should try
> > > and "fix" call_once or document that such functions must not
> throw.
> >
> > Fix is easy - instead of
> > if (!flag)
> > {
> > func();
> > flag = true;
> > }
> > should be
> > if (!flag)
> > {
> > flag = true;
> > func();
> > }
>
> Not so easy. This creates a race condition.

Could you elaborate ? This section is guarded by mutex.

>Plus claiming that
> an "init method" has been run, when that method failed, can lead to
> hard to diagnose bugs.
>I'm leaning towards the no throw
> documentation for this reason.

And what if it throws ? Undefined behaviour ?

Let pretend that someone makes an once guard for function that should
throw. To match the documentation code will be just wrapped with catch
(...){} and became much more error-prone than throwing version.

Throwing exception, especially from complex function, is a most
useful way to catch the problem. Being restricted to 'no throw'
programmers will something like static error codes ( as errno ).

Best regards,
Vitalij.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk