Re: Extending Temporary buffer for rvalues

[Christopher Jefferson <caj at cs dot st-andrews dot ac dot uk>]

Another attempt at a patch!

Attachment: temporary_buffer_patch_3
Description: Binary data

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)