top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

std::async should work with 4.7.1, but it doesn't?

0 votes

I can not compile

int parallel_sum(const RAIter beg, const RAIter end) {
 const auto len = end-beg;
 if(len < 1000) return std::accumulate(beg, end, 0);

 const RAIter mid = beg + len/2;
 auto handle = std::async(std::launch::async, parallel_sum, mid, end);
 const int sum = parallel_sum(beg, mid);
 return sum + handle.get();

int main() {
 std::vector v(10000, 1);

using "g++ -Wall -std=c++11", but running it I get terminate called after throwing an instance of 'std::system_error' what(): Unknown error -1
Aborted (core dumped)

posted Jun 2, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote
Best answer

You need to compile and link using -pthread to make use of multithreading.

answer Jun 2, 2013 by anonymous
Similar Questions
–1 vote

write a program that ask the user to enter an integer and deter mines whether it id divisible by 7 and 4 .whether it id divisible by 7 or 4 .whether it id divisible by 7 or 4 but not both

for example . if your input is 28 , the output should be :
Is 28 divisible by 7 and 4 ? False
Is 28 divisible by 7 or 4 ? True
Is 28 divisible by 7 or 4 , but not both ? False

+2 votes

I'm curious as to why libstdc++ is using a RB-tree to implement std::set (details here and here ),
when there are faster alternatives?

I'm mainly curious, because from all the people I've asked there hasn't been a single answer in favor of RB-trees, other than "they're already popular" or "easy to implement".

If you'd like more details on that, here's a link to my question on stackexchange,
where nobody has yet answered as well.

Using a variant of B-tree (or (a,b)-tree) should be faster, and everyone seems to suggest so, which makes me wonder what is the reason for picking RB-trees? This is not a question about their theoretical speed, but about real world behavior on real hardware with respect to CPU caches, etc.