Boost logo

Boost :

From: Dave Abrahams (abrahams_at_[hidden])
Date: 2000-05-30 15:26:34

> > While I was out on my bike ride today I got to thinking about the
> > boost
> > challenges I've issued: the allocation pool and the easy I/O
> > stuff. It occurred to me that neither of these has been accepted
> > boost.
> > In fact, neither has been formally reviewed, AFAIK.
> pool<> is not yet ready for review :)

Phew! off the hook.

Oops, too late; I've been looking at it anyway.

> There are 3 things that I consider "critical", meaning I want to
solve them
> before review:
> 1) I'm still looking at solving the thread-safe singleton issue.
The best
> solution I have so far is to just say that pool's used by global var
> initialization cannot be thread-safe; therefore, no threads should
> created during global var initialization in a program that uses
pool --
> other threads running after global var init is complete is OK.
> 2) The allocators are useless as they currently stand (see my
previous post
> on pool). This solution should fall into place after the singleton
> above is resolved.
> 3) The allocators are not thread-safe. At all. I'm working on
this, too.
> :)

Well, I wasn't worried about any of *those* issues anyhow. The main
thing that concerned me was the exponential explosion of forwarding
constructor type arguments that it needs to support. If we could get
around some of those issues by using placement new, it might be ideal.

Oh, one other thing, from your test code:
    for (int i = 0; i < 5; ++i)
      tester * ptr;
        ptr = pool.construct(17, 17); // <== ptr is never assigned
      catch (const std::logic_error &) { }
        // This is WRONG! It should fail!; // <== ptr is dangling!!!!********

I think you see the problem, yes?

Boost list run by bdawes at, gregod at, cpdaniel at, john at