Re: Solving mt_allocator's static initialization ordering problem

[Brad Spencer <spencer at infointeractive dot com>]

On Wed, Jun 30, 2004 at 01:29:55PM +0200, Paolo Carlini wrote:
> Seems not so bad to me, frankly. In any case, it should be moved *before*
> the lines
> 
>  if (_S_options._M_force_new)
>     return;
 
You are definately correct about this.  Otherwise, GLIBCXX_FORCE_NEW
cannot be taken into account!

Plus, that raises another point, actually.  I think we once discussed
changing that to:

  if (_S_options._M_force_new) {
    _S_init = true;
    return;
  }

This is because (I think) the code presumes that _M_force_new can
never change after the first call to allocate().  So, if
GLIBCPP_FORCE_NEW is on, there's no need to get all the way to
_S_initialize() on every allocate() call.

I've attached a revised patch which I verified works with
GLIBCXX_FORCE_NEW.

-- 
------------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | A Canadian AOL Company

Attachment: gcc-3.4.1-mt_allocator-lazy-initialization.ChangeLog
Description: Text document

Attachment: gcc-3.4.1-mt_allocator-lazy-initialization.patch
Description: Text document