Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #70923 > unrolled thread
| Started by | Soviet_Mario <SovietMario@CCCP.MIR> |
|---|---|
| First post | 2020-01-01 13:17 +0100 |
| Last post | 2020-01-03 21:00 +0000 |
| Articles | 11 on this page of 51 — 12 participants |
Back to article view | Back to comp.lang.c++
C++ threshold for "stupid" sorting algorithms (O(n^2)) Soviet_Mario <SovietMario@CCCP.MIR> - 2020-01-01 13:17 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 13:25 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-01 17:33 +0000
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 03:54 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 04:04 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-05 03:59 +0000
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 05:03 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Soviet_Mario <SovietMario@CCCP.MIR> - 2020-01-05 21:13 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-06 05:50 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-06 06:55 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-05 04:20 +0000
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 05:26 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-05 13:33 +0000
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 15:01 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-05 22:26 +0000
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-06 05:39 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Öö Tiib <ootiib@hot.ee> - 2020-01-05 23:54 -0800
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-06 08:59 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Öö Tiib <ootiib@hot.ee> - 2020-01-06 01:02 -0800
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-06 09:34 +0000
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-06 10:36 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Öö Tiib <ootiib@hot.ee> - 2020-01-06 03:33 -0800
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-06 12:59 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-06 22:54 +0000
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 04:57 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-07 07:51 +0000
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-05 15:16 +0000
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 05:50 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bo Persson <bo@bo-persson.se> - 2020-01-01 13:34 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Soviet_Mario <SovietMario@CCCP.MIR> - 2020-01-01 14:09 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bo Persson <bo@bo-persson.se> - 2020-01-01 15:16 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Robert Wessel <robertwessel2@yahoo.com> - 2020-01-01 09:24 -0600
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Soviet_Mario <SovietMario@CCCP.MIR> - 2020-01-01 17:12 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Öö Tiib <ootiib@hot.ee> - 2020-01-02 15:11 -0800
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 13:53 -0800
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Robert Wessel <robertwessel2@yahoo.com> - 2020-01-10 16:45 -0600
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 03:11 -0800
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-21 15:04 +0000
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 11:52 -0800
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-30 00:32 +0000
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-15 05:30 -0800
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-15 16:39 +0000
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Christian Gollwitzer <auriocus@gmx.de> - 2020-01-02 11:28 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Soviet_Mario <SovietMario@CCCP.MIR> - 2020-01-02 19:46 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-02 20:00 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-03 07:37 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Soviet_Mario <SovietMario@CCCP.MIR> - 2020-01-03 20:06 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Öö Tiib <ootiib@hot.ee> - 2020-01-03 11:12 -0800
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Soviet_Mario <SovietMario@CCCP.MIR> - 2020-01-04 17:58 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) David Brown <david.brown@hesbynett.no> - 2020-01-03 21:25 +0100
Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-03 21:00 +0000
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-02-15 05:30 -0800 |
| Message-ID | <86eeuwgept.fsf@linuxsc.com> |
| In reply to | #71649 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > > <cut lots> > > I left this a few days in the hope that I'd have something interesting > to say about it since your post was itself interesting and clearly not > trivial to write. Unfortunately I failed, but such a thoughtful post > merits a reply, even if the reply is not thoughtful. Thanks, I appreciate the followup. (for Ben: I sent you an email earlier this week. Did you get that or did it fall through the cracks?)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-02-15 16:39 +0000 |
| Message-ID | <87blpzg5yr.fsf@bsb.me.uk> |
| In reply to | #71854 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: <cut> > (for Ben: I sent you an email earlier this week. Did you get that > or did it fall through the cracks?) I replied a 3 days ago. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2020-01-02 11:28 +0100 |
| Message-ID | <qukgll$52j$2@dont-email.me> |
| In reply to | #70923 |
Am 01.01.20 um 13:17 schrieb Soviet_Mario: > In your experience, what is (roughly) a reasonable threshold (n) in > terms of convenience of passing from stupid algorithms (bubblesort, > gnomesort) to better and more complex ones ? > > I know this depends a lot also on HW. > I did not mention that the algorithm HAS TO BE "stable" : not to move > equally ranked items (in order to allow tables to be sorted by multiple > keys) Do mergesort: it is inherently stable, rather simple and scales well for large sorts, too. Christian
[toc] | [prev] | [next] | [standalone]
| From | Soviet_Mario <SovietMario@CCCP.MIR> |
|---|---|
| Date | 2020-01-02 19:46 +0100 |
| Message-ID | <quldq1$7hb$1@dont-email.me> |
| In reply to | #70960 |
On 02/01/2020 11:28, Christian Gollwitzer wrote: > Am 01.01.20 um 13:17 schrieb Soviet_Mario: >> In your experience, what is (roughly) a reasonable >> threshold (n) in terms of convenience of passing from >> stupid algorithms (bubblesort, gnomesort) to better and >> more complex ones ? >> >> I know this depends a lot also on HW. I did not mention >> that the algorithm HAS TO BE "stable" : not to move >> equally ranked items (in order to allow tables to be >> sorted by multiple keys) > > Do mergesort: it is inherently stable, rather simple and > scales well for large sorts, too. > > Christian I'll look for it, tnx -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-02 20:00 +0100 |
| Message-ID | <quleld$sna$1@news.albasani.net> |
| In reply to | #70978 |
>> Do mergesort: it is inherently stable, rather simple and scales well >> for large sorts, too. >> Christian > I'll look for it, tnx And there's std::stable_sort which is usually implemented with megesort. With parallel_policy or parallel_unsequenced_policy it even exploits all cores.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-03 07:37 +0100 |
| Message-ID | <qumnep$35c$1@news.albasani.net> |
| In reply to | #70979 |
>>> Do mergesort: it is inherently stable, rather simple and scales well
>>> for large sorts, too.
>>> Christian
>> I'll look for it, tnx
> And there's std::stable_sort which is usually implemented with megesort.
> With parallel_policy or parallel_unsequenced_policy it even exploits all
> cores.
Here's a simple parallel mergesort in C++.
Use it as a temporary object to sort anything.
template<typename T>
struct invoke_on_destruct
{
private:
T &m_t;
bool m_enabled;
public:
invoke_on_destruct( T &t ) :
m_t( t ), m_enabled( true )
{
}
~invoke_on_destruct()
{
if( m_enabled )
m_t();
}
void invoke_and_disable()
{
m_t();
m_enabled = false;
}
};
template<typename It,
typename Cmp = std::less<typename
std::iterator_traits<It>::value_type>,
typename Allocator = std::allocator<typename
std::iterator_traits<It>::value_type>>
class merge_sort
{
private:
using ep_allocator = typename
std::allocator_traits<Allocator>::template rebind_alloc<std::exception_ptr>;
using exceptions_vector = std::vector<std::exception_ptr,
ep_allocator>;
public:
merge_sort( It start, It end, Cmp const &cmp = Cmp(), unsigned
nThreads = 0, Allocator const &alloc = Allocator() );
struct par_exception : public std::exception
{
using iterator = typename exceptions_vector::iterator;
// there's no copy-constructor because of internal vector
// so catch par_exception only via reference
iterator begin();
iterator end();
private:
friend class merge_sort;
par_exception( exceptions_vector &&exceptions );
exceptions_vector m_exceptions;
};
private:
Cmp m_cmp;
Allocator m_alloc;
// mutex that protects the exception-array
std::mutex m_excMtx;
exceptions_vector m_exceptions;
template<typename UpIt>
void parRecursion( UpIt start, UpIt end, unsigned nThreads );
template<typename UpIt, typename BufIt>
void recursion( UpIt start, UpIt end, BufIt buf );
template<typename UpIt, typename BufIt>
void merge( UpIt start, BufIt leftBuf, BufIt rightBuf, BufIt bufEnd );
};
template<typename It, typename Cmp, typename Allocator>
merge_sort<It, Cmp, Allocator>::merge_sort( It start, It end, Cmp const
&cmp, unsigned nThreads, Allocator const &alloc ) :
m_cmp( cmp ),
m_alloc( alloc ),
m_exceptions( ep_allocator( alloc ) )
{
using namespace std;
// threads == 0 -> number of threads = hardware-threads
unsigned hwThreads = thread::hardware_concurrency();
hwThreads += hwThreads == 0;
nThreads = nThreads == 0 ? hwThreads : nThreads <= hwThreads ?
nThreads : hwThreads;
// reserve number of threads elements in the exception_ptr-vector
// so that there will be no exception when we do emplace_back
m_exceptions.reserve( nThreads );
try
{
parRecursion( start, end, nThreads );
}
catch( ... )
{
if( m_exceptions.size() )
{
// additional exception catched: throw par_exception
m_exceptions.emplace_back( current_exception() );
throw par_exception( move( m_exceptions ) );
}
else
// single exception: rethrow it
throw;
}
if( m_exceptions.size() )
if( m_exceptions.size() > 1 )
// multiple exceptions from threads: throw par_exception
throw par_exception( move( m_exceptions ) );
else
// only one exception from threads: rethrow it
rethrow_exception( m_exceptions[0] );
}
template<typename It, typename Cmp, typename Allocator>
template<typename UpIt>
void merge_sort<It, Cmp, Allocator>::parRecursion( UpIt start, UpIt end,
unsigned nThreads )
{
using namespace std;
using T = typename iterator_traits<It>::value_type;
size_t n = end - start;
if( nThreads <= 1 )
{
size_t bs = 0;
// calculate buffer-/stack-size
for( size_t split = n; split > 1; bs += split, split -= split /
2 );
vector<T, Allocator> buf( bs, T(), m_alloc );;
recursion( start, end, buf.begin() );
}
else
{
if( n < 2 )
return;
// split-buffer
vector<T, Allocator> buf( start, end, m_alloc );
// array for left-recursion and right-recursion thread
array<thread, 2> threads;
// automatically join threads when an exception is thrown
auto joinThreads = [&threads]()
{
for( thread &thr : threads )
if( thr.get_id() != thread::id() )
// try to join infinitely because the thread
// will continue to access our buffer
for( ; ; )
try
{
thr.join();
break;
}
catch( ... )
{
}
};
invoke_on_destruct iodJoin( joinThreads );
// iterator-type for our split-buffer
using BufIt = typename vector<T, Allocator>::iterator;
// proxy thread-lambda for our new threads
auto prProxy = [this]( BufIt start, BufIt end, unsigned nThreads )
{
try
{
parRecursion( start, end, nThreads );
}
catch( ... )
{
// remember exception in our exception-array
unique_lock<mutex> excLock( m_excMtx );
m_exceptions.emplace_back( current_exception() );
}
};
unsigned rightThreads = nThreads / 2,
leftThreads = nThreads - rightThreads;
// if the left number of threads is uneven give the threads
more input
size_t left = (size_t)(n * ((double)leftThreads /
nThreads)),
right = n - left;
BufIt leftBuf = buf.begin(),
leftBufEnd = buf.begin() + left,
rightBuf = leftBufEnd,
bufEnd = buf.begin() + n;
// start left thread
threads[0] = move( thread( prProxy, leftBuf, leftBufEnd,
leftThreads ) );
if( rightThreads > 1 )
// start right thread
threads[1] = move( thread( prProxy, rightBuf, bufEnd,
rightThreads ) );
else
// there's only one thread right, so we do it on our own
parRecursion( rightBuf, bufEnd, 1 );
// join threads
iodJoin.invoke_and_disable();
// stop if there are any exceptions from the threads
unique_lock<mutex> excLock( m_excMtx );
if( m_exceptions.size() )
return;
excLock.unlock();
// merge split-buffer back into input-buffer
merge( start, leftBuf, rightBuf, bufEnd );
}
}
template<typename It, typename Cmp, typename Allocator>
template<typename UpIt, typename BufIt>
void merge_sort<It, Cmp, Allocator>::recursion( UpIt start, UpIt end,
BufIt buf )
{
using namespace std;
if( end - start < 2 )
return;
copy( start, end, buf );
size_t n = end - start,
right = n / 2,
left = n - right;
BufIt leftBuf = buf,
leftBufEnd = buf + left,
rightBuf = leftBufEnd,
bufEnd = buf + n;
recursion( leftBuf, leftBufEnd, bufEnd );
recursion( rightBuf, bufEnd, bufEnd );
merge( start, leftBuf, rightBuf, bufEnd );
}
template<typename It, typename Cmp, typename Allocator>
template<typename UpIt, typename BufIt>
void merge_sort<It, Cmp, Allocator>::merge( UpIt start, BufIt leftBuf,
BufIt rightBuf, BufIt bufEnd )
{
assert(leftBuf < rightBuf && rightBuf < bufEnd);
BufIt leftBufEnd = rightBuf;
for( UpIt wrtBack = start; ; )
if( m_cmp( *leftBuf, *rightBuf ) )
{
*wrtBack++ = *leftBuf;
if( ++leftBuf == leftBufEnd )
{
// faster for small number of elements than std::copy
do
*wrtBack++ = *rightBuf;
while( ++rightBuf != bufEnd );
return;
}
}
else
{
*wrtBack++ = *rightBuf;
if( ++rightBuf == bufEnd )
{
do
*wrtBack++ = *leftBuf;
while( ++leftBuf != leftBufEnd );
return;
}
}
}
[toc] | [prev] | [next] | [standalone]
| From | Soviet_Mario <SovietMario@CCCP.MIR> |
|---|---|
| Date | 2020-01-03 20:06 +0100 |
| Message-ID | <quo3b8$eb4$2@dont-email.me> |
| In reply to | #70979 |
On 02/01/20 20:00, Bonita Montero wrote: >>> Do mergesort: it is inherently stable, rather simple and >>> scales well for large sorts, too. >>> Christian > >> I'll look for it, tnx > > And there's std::stable_sort which is usually implemented > with megesort. > With parallel_policy or parallel_unsequenced_policy it even > exploits all > cores. do you happen to remember in which header is that stable_sort declared ? I can't find it under namespace std:: without some proper #include ... -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato)
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-01-03 11:12 -0800 |
| Message-ID | <f388bdc9-c435-417a-b062-d0e3b95bb94e@googlegroups.com> |
| In reply to | #71047 |
On Friday, 3 January 2020 21:06:26 UTC+2, Soviet_Mario wrote:
> On 02/01/20 20:00, Bonita Montero wrote:
> >>> Do mergesort: it is inherently stable, rather simple and
> >>> scales well for large sorts, too.
> >>> Christian
> >
> >> I'll look for it, tnx
> >
> > And there's std::stable_sort which is usually implemented
> > with megesort.
> > With parallel_policy or parallel_unsequenced_policy it even
> > exploits all
> > cores.
>
>
> do you happen to remember in which header is that
> stable_sort declared ? I can't find it under namespace std::
> without some proper #include ...
The <algorithm> also you need to compile in compiler set to C++17.
That perhaps means adding
CONFIG += c++17
To your qtcreator .pro project.
[toc] | [prev] | [next] | [standalone]
| From | Soviet_Mario <SovietMario@CCCP.MIR> |
|---|---|
| Date | 2020-01-04 17:58 +0100 |
| Message-ID | <quqg6r$kqs$1@dont-email.me> |
| In reply to | #71048 |
On 03/01/20 20:12, Öö Tiib wrote: > On Friday, 3 January 2020 21:06:26 UTC+2, Soviet_Mario wrote: >> On 02/01/20 20:00, Bonita Montero wrote: >>>>> Do mergesort: it is inherently stable, rather simple and >>>>> scales well for large sorts, too. >>>>> Christian >>> >>>> I'll look for it, tnx >>> >>> And there's std::stable_sort which is usually implemented >>> with megesort. >>> With parallel_policy or parallel_unsequenced_policy it even >>> exploits all >>> cores. >> >> >> do you happen to remember in which header is that >> stable_sort declared ? I can't find it under namespace std:: >> without some proper #include ... > > The <algorithm> also you need to compile in compiler set to C++17. > That perhaps means adding > > CONFIG += c++17 tnx to you both I'd have to verify if GCC installed supports such a recent standard. But I guess some proper version of algorithm exist also in less recent version, or at least I hope > > To your qtcreator .pro project. > -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-03 21:25 +0100 |
| Message-ID | <quo7vi$b8o$1@dont-email.me> |
| In reply to | #71047 |
On 03/01/2020 20:06, Soviet_Mario wrote: > On 02/01/20 20:00, Bonita Montero wrote: >>>> Do mergesort: it is inherently stable, rather simple and scales well >>>> for large sorts, too. >>>> Christian >> >>> I'll look for it, tnx >> >> And there's std::stable_sort which is usually implemented with megesort. >> With parallel_policy or parallel_unsequenced_policy it even exploits all >> cores. > > > do you happen to remember in which header is that stable_sort declared ? > I can't find it under namespace std:: without some proper #include ... > <https://en.cppreference.com/w/cpp/algorithm/stable_sort> That site is an excellent reference for this sort of thing.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2020-01-03 21:00 +0000 |
| Message-ID | <SXNPF.172491$X71.138486@fx02.am4> |
| In reply to | #71050 |
On 2020-01-03, David Brown <david.brown@hesbynett.no> wrote: > On 03/01/2020 20:06, Soviet_Mario wrote: >> On 02/01/20 20:00, Bonita Montero wrote: >>>>> Do mergesort: it is inherently stable, rather simple and scales well >>>>> for large sorts, too. >>>>> Christian >>> >>>> I'll look for it, tnx >>> >>> And there's std::stable_sort which is usually implemented with megesort. >>> With parallel_policy or parallel_unsequenced_policy it even exploits all >>> cores. >> >> >> do you happen to remember in which header is that stable_sort declared ? >> I can't find it under namespace std:: without some proper #include ... >> > ><https://en.cppreference.com/w/cpp/algorithm/stable_sort> > > That site is an excellent reference for this sort of thing. and pops up on every google search metionig cpp. > -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.lang.c++
csiph-web