This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |