Re: Challenge policy proposal

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 
two
> > boost
> > challenges I've issued: the allocation pool and the easy I/O 
formatting
> > stuff. It occurred to me that neither of these has been accepted 
into
> > 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 
be
> 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 
issue
> 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;
      try
      {
        ptr = pool.construct(17, 17); // <== ptr is never assigned
      }
      catch (const std::logic_error &) { }
      try
      {
        // This is WRONG!  It should fail!
        pool.free(ptr);   // <== ptr is dangling!!!!********

I think you see the problem, yes?
-Dave