PlutoYT: if you had just called the function, you wouldn't be able to wait for user input to terminate the loop. The best you could do is ask at each iteration of the loop whether to continue.
Cherno gave us a simple and great example of how to display a looping "Loading" text animation while waiting for our models and other materials to load. We learn c ++ with practical examples. Great things for beginners. Thanks dude!
Cheers to Cherno! Hands down the best C++ tutorials. My guy somehow manages to explain a relatively complex topic along with example in about 10 mins. Just Awesome.
Note that simple thread example is actually wrong: it accesses a global variable (s_Finished) from two different threads without using proper thread synchronisation - which according to the C++ 11 standard is "undefined behaviour". In fact, a C++ compiler is explicitly allowed to "optimise away" the read- access to the global variable s_Finsihed in your worker thread. Why? Because access to that variable is not using any thread synchronisation mechanisms (such as e.g. std::atomic), so the compiler is able to say: "Hey, s_Finished is never changed to false in this function call, so I may as well replace it with while(true)!". Of course also depending on the "optimisation level" that you set during compilation. And you would end up with a worker thread that would never stop! Also e.g. refer to the excellent TH-cam video "Back to Basics: Concurrency - Arthur O'Dwyer - CppCon 2020". At around the time mark 6:45 it says: "Every write to a single memory location must be synchronise-with all other reads or writes of that memory location, or else the program has undefined behavior". And that's why there's a bit more behind concurrency than simply spawning multiple threads ;) But otherwise nice video that shows in simple ways how to create and join threads in C++ :)
Note: in real applications one should always use e.g. std::atomic for s_Finished (or other ways to ensure thread safety) to avoid race condition, which is a kind of undefined behaviour, which is very bad.
This example is completely thread safe for 2 reasons: 1. Because he only modifies the value of the flag on the main thread so other threads could read its value without any problem. (2 thread cannot modify a variable value at the same time, that would cause a nice crash). 2. Boolean value is stored on a signle bit (0 = false, 1 = true), that means if the main thread changes its value at the same time the side thread read its value, it would be 0 or 1 anyway (so if its 0 the next time he checks it it gonna be 1 anyway). This is not true with real numbers where this technique can lead you to data corruption. In engines such as UE4 and others this technique is used heavly, because you don't waste any time on setting up mutexes and checking its locks, etc...
The code from the video "kind of works" which means it definitely works on x86 in most popular current compilers (but might break due to boolean check elimination if you enable optimization ), but is not guaranteed to work on other platforms or even future compilers because it exhibits undefined behaviour according to C++ memory model. Boolean writes (and int writes) are atomic on x86, but, say, int writes are not atomic to non-aligned addresses on ARM. I believe even bool writes might be thread-unsafe on some platforms due to memory barriers (one core sees "false", another sees "true"). Now, if you only write for x86 and did check that all current processors/compilers accept it, and have commented it heavily to avoid future bugs by non-suspecting future programmers, then maybe it's OK to write such code. But I think in that case one should know that they are breaking the rules of C++ memory model: one should assess the risks/rewards for their particular situation, whatever UE4 and others do.
That is true, my explanation is only limited to the x86 platform. Before you do any kind of threading, the first thing what you have to do is checking if the current platform the application is running on is atomic or not. I'm not saying that you should always avoid mutexes, but on boolean flags usually you can (depends how the system is designed). Note that mutexes are not for free (it costs more memory and CPU checks) and settings up mutexes on every (lets say 1000) booleans it could impact the performance.
@@robertenyedi5692 "Boolean value is stored on a signle bit (0 = false, 1 = true)" Bools aren't stored as a single bit (or even byte necessarily), and that's not relevant anyway. As ashutosh108 points out, the issue is with atomicity. Point 1 is valid though I think, probably... most of the time.
Love how you explained this. Ended up watching your video instead of my instructors' lecture because it was more content in less time more completely explained. Thanks for what you do!
Thanks for the C++ tutorials. I have seen most of your videos multiple times over the last few years. Now, your videos are my reference content whenever I need something in C++
Alex Tol, van If you want to get into neural networks, C++ doesn't have as many libraries and options compared to a highly supported language like Python.
I was teaching myself some network programming using UDP sockets and was printing off the state of the server into the console. Problem is that std::cout is really slow and it was taking up so much time my server was lagging behind the game. So what I did was stick the std::cout into a thread of it's own and put it in an infinite loop and just sleep it for 0.2 seconds after every draw. Just a toy example but something simple that shows the usefulness of threads.
A video on exception handling and a video on callbacks would be awesome if you haven't done those topics yet! Awesome videos man, you are a great teacher.
Dude I LOVE that you are in the woods. I want my office as programmer and engineer to be the summit of some mountain or in the middle of the forest. Thats badass.
My game engine uses a thread pool that I've written along with coroutines for the different components and a scheduler class. The scheduler determines how long and when each component should run based on amount of work and priority and because they're coroutines its easy to suspend them at many points, save their state, and then pick up execution from there during the next frame
@@puppergump4117 lol i just only now got that it was a joke, legit thought thread coloring was a concept in programming (which i was hearing of for the first time in my years of studying and practice).
i'm glad that modern PCs are multicore because in the old days, one could have threaded code that worked but only because all the threads were scheduled on a single CPU (i.e., software threads), getting discrete time slices and not truly running in parallel. The code would then fail on a multiprocessor system surprising the developer. But now we can rigorously test right away. Even release vs. debug builds can differ!
if you print very fast, in background thread, and you don't use std::endl but you use then it goes into new randomly. " " Outputs a newline (in the appropriate platform-specific representation, so it generates a " " on Windows), but std::endl does the same AND flushes the stream.
Suspend and resume is also used in a thread loop waiting for an event, state or condition. What it does give up control to other threads the scheduler is managing because even though you have two or more threads you may only have one CPU to run the threads. It is important for real-time multi-threaded programmers to be aware of this. A good example of this is when you come out of a critical region block, you should pause (suspend) which means another thread waiting for the critical region gets the chance to run before the region block releasing thread loops to lock the same region again. Multi-threaded programmers need to think about this aspect in their code. Also how common data is accessed. The differences between atomic operations and mutex-protected data shared between threads. I also like to use thread-local storage to store things like lastError in each thread so each thread has it's own last error. A critical region is used in a function called by many threads.
The code in this video is not thread safe, s_Finished should be atomic, it is perfectly acceptable for the compiler/machine to only do the read once for that boolean value if it can determine it is not changed anywhere throughout that function, in which case it won't see it become true.
It's worth noting that while your program can use mutli-threading, it doesn't always need to. Many beginner programmers think they have to leverage every feature in the book to create a good program but the key is simplicity. If your program doesn't do anything that would warrant a second thread then there's no need in creating one. Multi-threading vastly complicates your program especially if it grows in size and is the source for a large number of crashes, bugs, and glitches for all sorts of different reasons. Debugging can be much more complicated as well and memory management can quickly turn into a nightmare. Tracking down errors and bugs can be vastly more difficult with multiple threads. Sharing memory, and program code, etc... as well are a big source of issues. It's all worth it if it's needed, absolutely! But do know that there are incredible and amazing complicated programs written today (Even simple but entire game engines) which do not leverage anymore than 1 thread and perform very well. You don't always have to use that 2nd thread. But it's there for if you need it. I highly recommend becoming very proficient with multi-threading and really study up on it first.
@Peterolen Yes, multi-threading is wonderful but only if it's really a need for it and many times single-threaded is just fine. In all honesty I'd recommend multi-threading when, after all optimizations have been done, it's still not performing well. Then you can look into splitting a part off into separate threads but I've personally never found an actual need for mutli-threading and I've done some heavy stuff in a single thread. In all honesty the best solution 99% of the time is leveraging async features over mutli-threading. Async still uses only 1 thread but takes advantage of the downtime of the CPU in that one thread. The first time I used that was in MFC a long time ago, then Javascript super popularized it, now it's made it's way into modern C++. It can feel like multi-threading and you get many of the multi-threading speed improvements. But it's only 1 thread so you don't get any of the complexities and issues of mutli-threading. I find this works in any case where I need extra help with speed and performance. EDIT: In all honesty, even async isn't needed many times. Like I said initially. The main key is just simplicity. Wait until you need the feature and then use it. Don't over-complicate your app from the start. You can always refactor in async down the line if the need arises. I personally always try to write as fewest simplest lines of code as possible because it makes expandability and maintainability much more pleasant.
Some questions i have: - How would I make differents thread accessing and updating the same value to always have the most up to date value? - And also, how many threads can I initialize? My pc has 16 threads, so is that the maximun I can start? Or if a start more than that the OS will handle how each thread will run?
Nice intro. But note, that it's actually a hello-world example of a race condition and undefined behaviour: You write and read to the same variable from two threads. To correct this you could use std::atomic, std::atomic_flag, or guard the reads and writes with a std::mutex. Unlike for example C#, bool in C# does not have special rules that make the example valid unless you use some protection like that.
FYI open gl is single threaded .... I use threads in all my heap allocations but I try not to have more than 2 threads running at the same time. Also it's better to abandon oop and have your threads in one function with a switch loop, and each case calling a single function (then the function calls the classes etc)
Just an advice but you should prolly think about making an Udemy course on advance C++ concepts. You explain everything so well and I have never found a tutorial series on advanced C ++ concepts online that is as helpful as your videos. Thanks!
great vid! but there's so much more to talk about threads. You can't mention threads and not talk about mutexes & atomic operations (also next - semaphores, multiprocessing) :) holding on for part #2..
Hey ! I don't know if you read comments, but I'd like to understand the difference between std::thread and std::async on which you've make a video on both... Is that simple ? I don't know.
Well, gr8 vid, but....there is a very important thing you didn't say, the locking-concept and differences between mutex and semaphors. Or in other words: I would like you to make a VERY detailed video(s) on that topic alone please! Cheers!
![ลองสุ่มไอโฟน 990 โกงมั้ย? [ โกงมั้ยครับ ep.101 ] | DOM](http://i.ytimg.com/vi/bfsWe0j492k/mqdefault.jpg)
Hey guys, looks like TH-cam is still processing this video (#classic), so hopefully it will be in HD soon. Thanks for watching :)
Could you also make a video on mutexes and atomic variables. I am mainly confused about who should own the mutex in an OOP scenario...
PlutoYT: if you had just called the function, you wouldn't be able to wait for user input to terminate the loop. The best you could do is ask at each iteration of the loop whether to continue.
Thank your for all your effort. With your videos I'm starting to understand much more things in c++. Greetings from Poland!
Why your int main() not returning anything? Shouldn't that cause error?
in c++, if you dont write return 0; at the end of main function, it presums that ends with that.
Explaining thread in the woods because another cherno::thread is using the house for another video
such an underrated comment lmao
too funny
indeed
I will yeld on that
Pretty nice *Syntactic Sugar!*
Walked in the woods, found a
Cherno doing c++ multithreading.
Yee
DOLLAR
money
Yee underrated comment
He's no longer THE Cherno. He's pluralized.
Cherno gave us a simple and great example of how to display a looping "Loading" text animation while waiting for our models and other materials to load. We learn c ++ with practical examples. Great things for beginners. Thanks dude!
everyone's gonna be surprised they can exit their loading screen by pressing enter! genious game design!
There are plenty of good C++ tutorials out there, and this is by far the best C++ channel. Thank you.
Cheers to Cherno! Hands down the best C++ tutorials. My guy somehow manages to explain a relatively complex topic along with example in about 10 mins. Just Awesome.
I miss these videos in nature 😢
Note that simple thread example is actually wrong: it accesses a global variable (s_Finished) from two different threads without using proper thread synchronisation - which according to the C++ 11 standard is "undefined behaviour".
In fact, a C++ compiler is explicitly allowed to "optimise away" the read- access to the global variable s_Finsihed in your worker thread. Why? Because access to that variable is not using any thread synchronisation mechanisms (such as e.g. std::atomic), so the compiler is able to say: "Hey, s_Finished is never changed to false in this function call, so I may as well replace it with while(true)!". Of course also depending on the "optimisation level" that you set during compilation.
And you would end up with a worker thread that would never stop!
Also e.g. refer to the excellent TH-cam video "Back to Basics: Concurrency - Arthur O'Dwyer - CppCon 2020". At around the time mark 6:45 it says: "Every write to a single memory location must be synchronise-with all other reads or writes of that memory location, or else the program has undefined behavior".
And that's why there's a bit more behind concurrency than simply spawning multiple threads ;)
But otherwise nice video that shows in simple ways how to create and join threads in C++ :)
Note: in real applications one should always use e.g. std::atomic for s_Finished (or other ways to ensure thread safety) to avoid race condition, which is a kind of undefined behaviour, which is very bad.
Is this necessary when you are only writing to it from one thread?
This example is completely thread safe for 2 reasons:
1. Because he only modifies the value of the flag on the main thread so other threads could read its value without any problem. (2 thread cannot modify a variable value at the same time, that would cause a nice crash).
2. Boolean value is stored on a signle bit (0 = false, 1 = true), that means if the main thread changes its value at the same time the side thread read its value, it would be 0 or 1 anyway (so if its 0 the next time he checks it it gonna be 1 anyway). This is not true with real numbers where this technique can lead you to data corruption.
In engines such as UE4 and others this technique is used heavly, because you don't waste any time on setting up mutexes and checking its locks, etc...
The code from the video "kind of works" which means it definitely works on x86 in most popular current compilers (but might break due to boolean check elimination if you enable optimization ), but is not guaranteed to work on other platforms or even future compilers because it exhibits undefined behaviour according to C++ memory model. Boolean writes (and int writes) are atomic on x86, but, say, int writes are not atomic to non-aligned addresses on ARM. I believe even bool writes might be thread-unsafe on some platforms due to memory barriers (one core sees "false", another sees "true").
Now, if you only write for x86 and did check that all current processors/compilers accept it, and have commented it heavily to avoid future bugs by non-suspecting future programmers, then maybe it's OK to write such code. But I think in that case one should know that they are breaking the rules of C++ memory model: one should assess the risks/rewards for their particular situation, whatever UE4 and others do.
That is true, my explanation is only limited to the x86 platform. Before you do any kind of threading, the first thing what you have to do is checking if the current platform the application is running on is atomic or not. I'm not saying that you should always avoid mutexes, but on boolean flags usually you can (depends how the system is designed). Note that mutexes are not for free (it costs more memory and CPU checks) and settings up mutexes on every (lets say 1000) booleans it could impact the performance.
@@robertenyedi5692 "Boolean value is stored on a signle bit (0 = false, 1 = true)" Bools aren't stored as a single bit (or even byte necessarily), and that's not relevant anyway. As ashutosh108 points out, the issue is with atomicity. Point 1 is valid though I think, probably... most of the time.
Love how you explained this. Ended up watching your video instead of my instructors' lecture because it was more content in less time more completely explained. Thanks for what you do!
Thanks for the C++ tutorials. I have seen most of your videos multiple times over the last few years.
Now, your videos are my reference content whenever I need something in C++
My wish is that maybe one day teach us about Neural Networks in C++. I'm loving your C++ series man !
Alex Tol, van If you want to get into neural networks, C++ doesn't have as many libraries and options compared to a highly supported language like Python.
It's difficult implementing neural networks in C++ I agree, but if it is fast and efficient plus it gives you more control.
Not too difficult I can send u some code of a simple one if u want...
Neil Tsakatsa I agree C++ has major performance benefits, but in my opinion, C++ isn't the best in terms of helping beginners.
just use (py)/torch if you want fast GPU accelerated networks, else if you are CPU bound use Caffe
I was teaching myself some network programming using UDP sockets and was printing off the state of the server into the console. Problem is that std::cout is really slow and it was taking up so much time my server was lagging behind the game. So what I did was stick the std::cout into a thread of it's own and put it in an infinite loop and just sleep it for 0.2 seconds after every draw. Just a toy example but something simple that shows the usefulness of threads.
A video on exception handling and a video on callbacks would be awesome if you haven't done those topics yet! Awesome videos man, you are a great teacher.
Came here because of the recommendation, stayed to see how C++ enables threading, learned that C++ offers custom literals
Dude I LOVE that you are in the woods. I want my office as programmer and engineer to be the summit of some mountain or in the middle of the forest. Thats badass.
Immediately reminds me of Ex Machina!
That is so cool!!! like this multi-threading stuff is so freaking cool
I bet there was a bear family just behind you hiding in the bushes and learning C++:D
great tutorial thanks a lot
If tutor is going in nature, why should we study in room, I'm watching this in nature.
Cherno you are amazing brother ❤️❤️
Every Time I have a problem just you clarifying it gets me going!
My game engine uses a thread pool that I've written along with coroutines for the different components and a scheduler class. The scheduler determines how long and when each component should run based on amount of work and priority and because they're coroutines its easy to suspend them at many points, save their state, and then pick up execution from there during the next frame
Awesome video!
Can you do please videos about multithreading problems and how to avoid them? (data race, deadlock,livelock,starvation, etc.)
You are great at making things interesting. Loved all your videos so far. Thank you.
Locations behind looks so peaceful
Unique ideas to appear cool in TH-cam! It sure is working.
You should have mentioned Race Conditions which are probably the most common problem with threads. Still nice simple introduction.
Thanks for this comment. I didn't realize they are related.
@@NeoKailthas Yeah race is a big problem especially with different colored threads
@@puppergump4117 Whats thread coloring?
@@Henry14arsenal2007 A race issue lol
@@puppergump4117 lol i just only now got that it was a joke, legit thought thread coloring was a concept in programming (which i was hearing of for the first time in my years of studying and practice).
i'm glad that modern PCs are multicore because in the old days, one could have threaded code that worked but only because all the threads were scheduled on a single CPU (i.e., software threads), getting discrete time slices and not truly running in parallel. The code would then fail on a multiprocessor system surprising the developer. But now we can rigorously test right away. Even release vs. debug builds can differ!
I have been waiting for this for so long...
if you print very fast, in background thread, and you don't use std::endl but you use
then it goes into new randomly.
"
" Outputs a newline (in the appropriate platform-specific representation, so it generates a "
" on Windows), but std::endl does the same AND flushes the stream.
You're doing great job bro. You are explaining things in a really clear way and not doing it in a boring way. Lucky to find you
Suspend and resume is also used in a thread loop waiting for an event, state or condition. What it does give up control to other threads the scheduler is managing because even though you have two or more threads you may only have one CPU to run the threads. It is important for real-time multi-threaded programmers to be aware of this. A good example of this is when you come out of a critical region block, you should pause (suspend) which means another thread waiting for the critical region gets the chance to run before the region block releasing thread loops to lock the same region again. Multi-threaded programmers need to think about this aspect in their code. Also how common data is accessed. The differences between atomic operations and mutex-protected data shared between threads. I also like to use thread-local storage to store things like lastError in each thread so each thread has it's own last error. A critical region is used in a function called by many threads.
A quick tip for people compiling with linux, make sure to add the compiler flag: -pthread
Underrated.
The code in this video is not thread safe, s_Finished should be atomic, it is perfectly acceptable for the compiler/machine to only do the read once for that boolean value if it can determine it is not changed anywhere throughout that function, in which case it won't see it become true.
Love your introductions.
OMG i have been waiting
The aussie forest background sounds were a vibe
Thank you for the clear tutorial! Very easy to follow your explanations
that's something I was thinking about some time ago, great think and great video
Thx for this series, exactly what i needed right now ! :)
Brilliant production Cherno! Both informative and aesthetically pleasing. I'm really looking forward to the new game engine series.
i cant thank you enough, finally found what i needed
It's worth noting that while your program can use mutli-threading, it doesn't always need to. Many beginner programmers think they have to leverage every feature in the book to create a good program but the key is simplicity. If your program doesn't do anything that would warrant a second thread then there's no need in creating one. Multi-threading vastly complicates your program especially if it grows in size and is the source for a large number of crashes, bugs, and glitches for all sorts of different reasons. Debugging can be much more complicated as well and memory management can quickly turn into a nightmare. Tracking down errors and bugs can be vastly more difficult with multiple threads. Sharing memory, and program code, etc... as well are a big source of issues.
It's all worth it if it's needed, absolutely! But do know that there are incredible and amazing complicated programs written today (Even simple but entire game engines) which do not leverage anymore than 1 thread and perform very well. You don't always have to use that 2nd thread. But it's there for if you need it. I highly recommend becoming very proficient with multi-threading and really study up on it first.
@Peterolen Yes, multi-threading is wonderful but only if it's really a need for it and many times single-threaded is just fine. In all honesty I'd recommend multi-threading when, after all optimizations have been done, it's still not performing well. Then you can look into splitting a part off into separate threads but I've personally never found an actual need for mutli-threading and I've done some heavy stuff in a single thread.
In all honesty the best solution 99% of the time is leveraging async features over mutli-threading. Async still uses only 1 thread but takes advantage of the downtime of the CPU in that one thread. The first time I used that was in MFC a long time ago, then Javascript super popularized it, now it's made it's way into modern C++. It can feel like multi-threading and you get many of the multi-threading speed improvements. But it's only 1 thread so you don't get any of the complexities and issues of mutli-threading. I find this works in any case where I need extra help with speed and performance.
EDIT:
In all honesty, even async isn't needed many times. Like I said initially. The main key is just simplicity. Wait until you need the feature and then use it. Don't over-complicate your app from the start. You can always refactor in async down the line if the need arises. I personally always try to write as fewest simplest lines of code as possible because it makes expandability and maintainability much more pleasant.
This is really good explanation for this.
Some questions i have:
- How would I make differents thread accessing and updating the same value to always have the most up to date value?
- And also, how many threads can I initialize? My pc has 16 threads, so is that the maximun I can start? Or if a start more than that the OS will handle how each thread will run?
Thanks Cherno
Hey Cherno - Amazing series. I would be very interested in a couple that explore optimisation strategies in greater detail.
I really like your videos. Great knowledge and charisma!
powerful for image processing
This series is absolutely outstanding!
Cherno you are a hero!
11:16 His camera man says "It's done?" :D
hey charnya its amazing series
I LOVE YOU AND YOUR CHANNEL IS FANTASTIC IM BRAZILIAN BRO
Great video, love wood scenery
Nice intro. But note, that it's actually a hello-world example of a race condition and undefined behaviour: You write and read to the same variable from two threads. To correct this you could use std::atomic, std::atomic_flag, or guard the reads and writes with a std::mutex. Unlike for example C#, bool in C# does not have special rules that make the example valid unless you use some protection like that.
Thanks for the great video! Can you please do a follow up video on how Future, Promise and Coroutines work in C++?
FYI open gl is single threaded
....
I use threads in all my heap allocations but I try not to have more than 2 threads running at the same time.
Also it's better to abandon oop and have your threads in one function with a switch loop, and each case calling a single function
(then the function calls the classes etc)
"It's a huge topic that we'll continue to explore in the future" - 6 years ago
teaches threads in da woods. legend
Thanks for another awesome video!
Just go teach this to Notch
Great vid as always
EXCEPTIONS Chernobyl
Thank you alot for your videos!
That was a really nice review! Thank you
brilliant vid, thx
I work at home in a room with my pet birds, and they are going NUTS from the bird sounds in the background lol
It's easy to understand, thanks.
I love the fact that you are doing this in the forest!
very well explained.
love the birds in the background xd
This was so helpful--thank you!
No mutex or atomic :/
I would also like to see thread synchronization covered.
@@warrenbuckley3267 me too me too
No std::future or std::async :/
He just uploaded a video on it
@@warrenbuckley3267 and thread safety, race conditions etc
well explained, thanks for this awesome tutorial!
Was that a leaf you threw away? 0:04
WTF its like magic. Slow it down to 0.25x you wont see anything in his hand xD
wtf pretty scared right now
Magic Cherno..
It was Move Constructor video
Slow it down to x0.25 and he makes stroke sounds
Thanks
great tutorial!!! I love your videos
Finally. I am waiting this.
imagine hiking in woods and seeing guy speaking about threads in cpp
Need more videos in C++ series! :)
I almost didn't recognize you until you did the hands :-)
I fear no man. But that thing...
*multi-threaded programming*
it scares me.
Just an advice but you should prolly think about making an Udemy course on advance C++ concepts. You explain everything so well and I have never found a tutorial series on advanced C ++ concepts online that is as helpful as your videos. Thanks!
why do you sometimes use "
" and other times use std::endl?
you are the best!
great vid! but there's so much more to talk about threads.
You can't mention threads and not talk about mutexes & atomic operations (also next - semaphores, multiprocessing) :)
holding on for part #2..
Hey ! I don't know if you read comments, but I'd like to understand the difference between std::thread and std::async on which you've make a video on both... Is that simple ? I don't know.
11:15
"Is it done?" LOL
Nice forest!
fuck , he explained it so well
shout out to the leaf on chernos hoodie
Hi cherno , please make video on recursion in c++ & how it works internally.
Well, gr8 vid, but....there is a very important thing you didn't say,
the locking-concept and differences between mutex and semaphors.
Or in other words: I would like you to make a VERY detailed video(s) on that topic alone please!
Cheers!
thanks!
Why your int main() not returning anything? Shouldn't that cause error?
A would like to know how to raise an event from another thread c++.
Could you make an example?
awesome!
1:42 exactly what i wanted to do
Nothing like coding in a dark forest. Priceless.
I like the nature