multi threading

[BardiaH]

Hi. I'm working on c++ for a year. I wanna know if it is possible in c++ to run two (or more) function in a same time.
For example one function prints number in a infinite loop and the other one waits to catch an input. If the input was character 'b' (for example) then the loop stop printing.
Can you help me to make a program like this?

[Cubbi]

Sure, something like that could be pretty simple:

#include <thread>
#include <chrono>
#include <future>
#include <iostream>

int main()
{
    std::cout << "Enter b to quit\n";

    std::promise<void> finish_p;
    std::future<void> finish_f(finish_p.get_future());

    // launch thread
    std::thread t([&]{
        do { 
            std::cout << "number" << std::endl; // keep printing this every second
        } while(finish_f.wait_for(std::chrono::seconds(1)) != std::future_status::ready);
    });
    // end of the thread body

    // wait for input
    for(char c; std::cin.get(c) && c != 'b'; )
    {   
        // not 'b', wait for more input
    }

    // signal the thread to exit
    finish_p.set_value();

    // wait for the thread to finish
    t.join();
}

[BardiaH]

My compiler doesn't find thread, chrono and future libraries.

[DeXecipher]

You have to do multithreading for software graphics processing because rendering pixel by pixel is too slow when you have to handle game logic and such.

And you might be using an old compiler or ide suite. <thread>,... are C+11 standard.

[seven50]

C++11 offers a native support for multithreading
there are also other libs such as boost::thread or pthread that work on older versions of the standard too.

[BardiaH]

Is there any book that has explane all these new libraries?
I've read Deitel & Dietel fourth edition and it doesn't include any of them.

[seven50]

http://www.amazon.com/C-Concurrency-Action-Practical-Multithreading/dp/1933988770

[Mitch]

Yeah, he is definitly using an older compiler (even if only a little).
<thread> is one of the awesome C++11 features (too bad C++11 isn't fully supported yet)!

It's really awesome, but sadly I (like most), don't have a lot of C++11 compatible compilers...
I always wanted <thead> and that cool sleep_for functionality!!!

sleep_for is revolutionary!

[Cubbi]

sleep_for is revolutionary!

It was available from boost.thread for many years.

[BardiaH]

I use minGW 3.2.0 compiler for my windows and fedora13's default gcc compiler .

[giblit]

Go to compiler settings flags then put -std=c++11
This will enable c++11 then you should be able to use #include <thread> and all the other c++11 features like range-based for loops and initialization

*http://www.cplusplus.com/reference/thread/thread/?kw=thread

[kbw]

Go to compiler settings flags then put -std=c++11

... that's assuming the compiler supports C++11 at all, and supports GCC options.

[giblit]

He said he used mingw 3.2.0 which is GCC I thought but yeah I don't know if it supports c++11 or not I just figured most people have modern compilers besides all those people that use borland.

[kbw]

Most GCC users don't. Look at the compilers on stable versions RedHat, CentOS, Debian, OpenBSD, FreeBSD, ...

[o1vk4iN6]

You have to do multithreading for software graphics processing because rendering pixel by pixel is too slow when you have to handle game logic and such.

Actually, rendering the pixels is probably the fastest part for that pipeline.

[DeXecipher]

Actually, rendering the pixels is probably the fastest part for that pipeline.

Not if you do it with gdi. And I think for DirectX and Opengl they create thread in the background automatically for handling/accessing graphics card RAM on initialization. Otherwise it will be way too slow at least for my computer to render/swap/copy multiple images in one main thread.

[o1vk4iN6]

Not if you do it with gdi. And I think for DirectX and Opengl they create thread in the background automatically for handling/accessing graphics card RAM on initialization. Otherwise it will be way too slow at least for my computer to render/swap/copy multiple images in one main thread.

Yes even with gdi, you have a finite number of pixels. There are a lot of techniques for graphics used to improve performance by simply filling in the pixels that are required, most recent being Euclideon's technique. If you are loading textures into GPU memory every time you draw something on the screen (30-60 fps) that is a fault with your implementation and not cause "rendering pixel by pixel is too slow".