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]

Re: Extending Temporary buffer for rvalues


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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]