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.
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++
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!
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++ :)
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.
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.
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
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.
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.
@@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!
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?
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)
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.
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.
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.
@TheChernoProject I am getting the following error on code typed at @7:32 error: ‘std::literals’ has not been declared using namespace std::literals::chrono_literals; EDIT: I added "#include ", but did not work.
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.
Dude , you're video is pretty good. The audio quality is fine , you should speak a bit slower and make sure the typing noise will not interrupt too much , and also increase the font, for those of us who use notebook with small screen .
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 bet there was a bear family just behind you hiding in the bushes and learning C++:D
great tutorial thanks a lot
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++
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!
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++ :)
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.
I miss these videos in nature 😢
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
Came here because of the recommendation, stayed to see how C++ enables threading, learned that C++ offers custom literals
That is so cool!!! like this multi-threading stuff is so freaking cool
You are great at making things interesting. Loved all your videos so far. Thank you.
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!
I have been waiting for this for so long...
If tutor is going in nature, why should we study in room, I'm watching this in nature.
Cherno you are amazing brother ❤️❤️
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
Awesome video!
Can you do please videos about multithreading problems and how to avoid them? (data race, deadlock,livelock,starvation, etc.)
OMG i have been waiting
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
Thx for this series, exactly what i needed right now ! :)
Every Time I have a problem just you clarifying it gets me going!
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.
Unique ideas to appear cool in TH-cam! It sure is working.
Brilliant production Cherno! Both informative and aesthetically pleasing. I'm really looking forward to the new game engine series.
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.
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
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).
"It's a huge topic that we'll continue to explore in the future" - 6 years ago
I really like your videos. Great knowledge and charisma!
i cant thank you enough, finally found what i needed
Thank you for the clear tutorial! Very easy to follow your explanations
This series is absolutely outstanding!
11:16 His camera man says "It's done?" :D
Hey Cherno - Amazing series. I would be very interested in a couple that explore optimisation strategies in greater detail.
I work at home in a room with my pet birds, and they are going NUTS from the bird sounds in the background lol
that's something I was thinking about some time ago, great think and great video
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!
imagine hiking in woods and seeing guy speaking about threads in cpp
teaches threads in da woods. legend
Locations behind looks so peaceful
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?
Just go teach this to Notch
Love your introductions.
I LOVE YOU AND YOUR CHANNEL IS FANTASTIC IM BRAZILIAN BRO
Cherno you are a hero!
9:26 does nobody want to tell me what that sound was
thas a phantom from minecraft
I would say that’s a jay (bird)
Probably a pterodactyl
That sound was made by a "wild cherno", it's a rare animal found in the woods who codes in C++.
Nature is so beautiful!
bigfoot
Thanks Cherno
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
EXCEPTIONS Chernobyl
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)
Thanks for another awesome video!
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.
powerful for image processing
Great vid as always
The aussie forest background sounds were a vibe
This is really good explanation for this.
7:43
without using chrorno literals, would the thing look like "std::literals::chrono_literals::this_thread::sleep_for(1s);?
hey charnya its amazing series
how can you make gl stuff multi threaded? as far as i know it's sequentially executed!
A quick tip for people compiling with linux, make sure to add the compiler flag: -pthread
Underrated.
11:15
"Is it done?" LOL
That was a really nice review! Thank you
Nothing like coding in a dark forest. Priceless.
I love the fact that you are doing this in the forest!
9:28 was that a minecraft phantom sound? 🤔
yes, and u wrote timestamp after this sound. pls don't do that
9:12 Cherno.exe has stopped working
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.
Great video, love wood scenery
@9:13 "Cherno received signal SIGSEGV, Segmentation fault. Cannot access memory at address 0xff3fffe4"
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.
The “conzole”
I almost didn't recognize you until you did the hands :-)
Finally. I am waiting this.
Thank you alot for your videos!
@TheChernoProject I am getting the following error on code typed at @7:32
error: ‘std::literals’ has not been declared
using namespace std::literals::chrono_literals;
EDIT: I added "#include ", but did not work.
@Major L Hey thnx..i will check it out. Do you know why the way he said is not working?
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.
very well explained.
Thanks for the great video! Can you please do a follow up video on how Future, Promise and Coroutines work in C++?
well explained, thanks for this awesome tutorial!
This was so helpful--thank you!
why do you sometimes use "
" and other times use std::endl?
Why your int main() not returning anything? Shouldn't that cause error?
great tutorial!!! I love your videos
Hey, good man, what about you, welcome to you.
I fear no man. But that thing...
*multi-threaded programming*
it scares me.
brilliant vid, thx
A would like to know how to raise an event from another thread c++.
Could you make an example?
love the birds in the background xd
Where can I buy your logo as a sticker? I want to paste it on my laptop
9:27, did i hear a Phantom scream?
you are the best!
lmao I banged my head for 30 minutes on Linux just to realize I have to pass to the compiler the -pthread argument for it to compile.
dude that was exactly what I was doing yesterday
Need more videos in C++ series! :)
Dude , you're video is pretty good. The audio quality is fine , you should speak a bit slower and make sure the typing noise will not interrupt too much , and also increase the font, for those of us who use notebook with small screen .