I tried to find some informaton on the internet about threads in c++, but unfortunatelly I couldnt. I found about threads in C#,Java etc. Please help me! I need to know ho to make a thread in c++, how to run it, how to stop it, how to run two threads simultaneously, and how to give priority to a thread. I hope you can give me some information.
Okay, thank you for the reply. But can you give me some tutorial or link with examples for Boost. And one stupid question: threading is not in the standart library of c too, right?
pthreads are not portable. Threading will be a part of the upcoming C++ standard.
Till then, use portable Boost, but be aware that the compiler does not know anything about threads and some nasty optimisation-related problems may sometimes arise in corner cases, especially on multiprocessor machines. Compilers tend to reorder instructions sometimes, breaking otherwise correct thread synchronisation.
@hakspek: I hate to say this but that's not where you post new stuff at all. You should put it in the Begginers section but not on someone else's thread. Also, please put code in "code tags" like so. One last thing, when you want an answer, ask a question. "Please do this for me" is not a question.
As for the question the OP posted, I would either use CreateThread (look it up, it's in windows.h) or SDL_CreateThread (it's the same thing but it's not operating system dependent)
Sometimes I wonder if the Standard C++ committee members are doing work or not. They approve new APIs too SLOWLY!!!!!!
I wish for below to be part of Standard C++ coming soon.
- Networking/Sockets API (includes email, ftp, scp, goher, http etc)
- 2D/3D Imaging API
- Audio/Video API
- Serialization API
- Threading API
- XML/JSON Parsing API
- Database Connectivity API
- LDAP API
- DNS API
- Security API
...
You can see I want more business-centric API. Anyone can add in to the above lis t:P
Not going to happen.
C++ is designed to run on many different kinds of systems and it would be unreasonable to have all of that as part of the language specification. There are frameworks like Qt that provide the kind of functionality that is needed for desktop GUI applications.
It might be nice to have some more general-purpose, hardware-independent, header-only aids in the standard library, but since boost is quasi-standard, there is no practical need for that either.
I believe Boost.org has threading, serialization correct ? So it just may happen cuz a lot of Boost.org API get approved to be in Standard C++ eventually. The complaint now is the Standard C++ committee is taking too long a time to get them approved!
I wonder what is so hard to stamp a chop, certify this API part of Standard C++ ? Afterall Boost.org already provide implementations already. Unless there are some non-technical issues like say political and geographical reasons behind the approval process? !
In comparison, Java-now Oracle APIs, Google APIs move at very fast pace. Maybe the Standard C++ committee members need some re-shuffling to bring in more enthusiastic members to get approval done faster :)
Adding something to the standard library is a momentous and pretty much irreversible decision.
So before you add something you'd want to make sure that it is as "perfect" as reasonably possible, integrates well with the rest of the standard library etc., because it's not really feasible to change the API later (let alone remove it) when you realize that the solution wasn't all that good after all.
Libraries like Boost.Serialization are in much better hands when they're with boost: its API may change with every new version. Which is fine, because developers can choose an API by choosing a certain boost version for their project that they stick with.
People can also choose a different serialization library that they like better - they could still do that even if the standard library had its own serialization library, but it leaves a bit of a bad aftertaste to use an external library for something that the standard library already provides.
because it's not really feasible to change the API later (let alone remove it) when you realize that the solution wasn't all that good after all.
I believe above problem has been faced by Java and even M$ on API changes. It cannot be avoided. The best solution is just to release a suffix 2 to indicate new API. Discontinue support of earlier version and persuade ppl to switch over to 2
E.g Windows used to be <winsock.h> then we have <winsock2.h>, the same applies to Google API, they have V1, V2, V3 etc...
The point I am trying to say is API will change. This problem cannot be avoided. Even if you spend a lot of time to come out with a "perfect" API, there is no guarantee it will NOT change with the passage of time.
Rather than incubate and release a "perfect" API, it should be better to faster release a stable version and increment them along as needed.
I believe my thinking deviates from Standard C++ committee members which is why I advocate re-shuffling of members :P
I wish for below to be part of Standard C++ coming soon...
As Athar said, C++ is a general purpose language and so won't have all this business related stuff, just the tools to build them. It's also vendor neutral, so no one vendor can impose it's view on the world.
However, I do think that C++ looses out to Java and C# becuase it doesn't have a defacto standard library at this level. As a result, C++ remains a fragmented community with very little reuse, with no equivalent to Java's SE or EE API in terms of scale, cost and common use, and is relegated to building parts of systems where nothing else will do, a modern day assembler.
I believe my thinking deviates from Standard C++ committee members which is why I advocate re-shuffling of members
That's a bit extreme. And who would you replace them with, a team from Oracle or Microsoft?
That's a bit extreme. And who would you replace them with, a team from Oracle or Microsoft?
I would prefer a team from Google instead. They do it fast and next year I got Chrome OS to play with. Nowadays all new "inventions" are coming out pretty fast from Google isn't it ?
Btw I am addicted to Google Maps, Google App Engine, Google Android, Google Chrome browser, Google Closure Compiler etc etc :)
Google do things fast because they only have to satisfy Google to make decisions. Microsoft can make changes to .net fast because they only have be satisfy themselves with the changes. The same goes for Java, as long as Oracle keep their eyes on the ball and don't cock it up. They do seem to be a bit distracted with chasing patents at the moment.
C++ standardisation has a lot of stakeholders and to satisfy them all takes a lot of work. I lot of work takes a lot of time.
The same goes for Java, as long as Oracle keep their eyes on the ball and don't cock it up.
Actually with Java it is more like with C++ nowadays. There are lots of companies involved in the standarization process and Oracle can't do whatever it wishes to. And Java is also moving forward too slowly. Maybe not that slowly, but major releases every 2-3 years is plain too long.
Bjarne Stroustrup said something recently, that the C++ committee works in their "spare time" and they don't get any profits for that work. So this may explain that slowness. Another reason is that it is extremely hard to add something to C++, without breaking it. It is already very hard to learn, and making it even more complex would not help its popularity (as more and more universities get away from C++ as the obligatory language, there will be less and less programmers knowing it = less new projects started in this language).