Extending Temporary buffer for rvalues

[Christopher Jefferson]

Another attempt at a patch!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: temporary_buffer_patch_3
Type: application/octet-stream
Size: 3846 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20090828/9fcaa8a5/attachment.obj>
-------------- next part --------------


Some of the formatting got tricky in this patch, due to very long  
function names, sorry.

I believe adding perfect forwarding to _Construct shouldn't break  
anything else, and long
term I imagine we might want to add it to move internal functions, for  
efficiency reasons if
nothing else.

2009-08-27  Chris Jefferson <chris@bubblescope.net>
	* includes/bits/move.h : Add _GLIBCXX_FORWARD to wrap std::forward.
	* include/bits/uninitialized.h : Add __uninitialized_construct_range.
	* include/bits/tempbuf.h (_Temporary_buffer) : Make work with
	move-only types.
	* include/bits/stl_construct.h (_Construct) : Add perfect forwarding.


On 27 Aug 2009, at 14:40, Paolo Carlini wrote:

> Hi,
>> Unfortunately there are two main problems with that:
>>
>> 1) It's quite a bit slower (around 3 times slower to sort an array of
>> vector<int>s of length 1000).
>> 2) It violates the standard. The algorithm with no buffer is O(n. log
>> n. log n), we are supposed to achieve O(n log n) if there is "enough
>> extra memory available".
> I see, didn't get this from your previous message.
>> While I still don't like it much, I've substantially simplified and
>> cleaned my earlier patch and added some description to it. I'm sure
>> this is correct, as I'm careful to put *__first back when I've
>> initialised the temporary buffer.
> Ok. Then for now we can do that, but at least let's abstract out the
> ugly loop to a separate template, and dispatch either to it or one  
> just
> using the default constructor if the latter is available. In order  
> to do
> that fully effectively - and covering the large majority of real  
> cases,
> I bet - we would need a builtin trait true if a default constructor is
> available at all, not just the trivial one, but for now
> __has_trivial_constructor can do, I think.
>
> Paolo.
>
> PS: If I understand correctly the direction the standard is taking,
> std::has_default_constructor will be available soon anyway (and I see
> the corresponding builtin is trivial to implement: the C++ front-end  
> has
> TYPE_HAS_DEFAULT_CONSTRUCTOR for that)