[Patch] libstdc++/25288

[Paolo Carlini]

Howard Hinnant wrote:

> Fwiw, I like to keep try/catch clauses out of "exception neutral" 
> code - code that is going to just clean up and throw the same 
> exception.  You might do this in this circumstance by changing the 
> range constructor to just do continual push_back's (almost exactly 
> like the original insert you're replacing).  And then insert can 
> simply become:
>
> list __temp(__first, __last, get_allocator());  // optimize that 
> get_allocator call?
> splice(__pos, __temp);
>
> Note that you won't need try/catch in the range ctor either.  Your 
> existing (well-designed) _List_base will clean up any mess if the 
> range ctor throws (if I'm glancing at it correctly).

I'm finishing testing the below. I think it captures your idea, besides
the internal "get_allocator" by reference optimization, which really is
unrelated and I'd like to implement after merging from v7-branch the
corresponding one for deque.

Looks ok?

> Fwiw, this particular technique is only a really good deal because 
> your temp construction is practically free when you have an empty 
> allocator and empty range - practically free because of the embedded 
> end-node design.  Fast no-throw "default" constructions are worth 
> their weight in gold! :-)

Yes! ;)

Paolo.

P.S. Seems obvious to me that there are no binary compatibility risks
with this larger patch: we are touching only inline internal
implementation functions, changing completely the names...

///////////////////
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CL_25288_2
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20051208/1568e7b8/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_25288_2
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20051208/1568e7b8/attachment-0001.ksh>