chili wrote:I mostly stick to std::thread stuff, but there is an argument to be made for using platform-specific APIs. The std library is made to be lean by design, and it also has to work at the LCD in terms of features. You can get access to more sophisticated/higher performance constructs by digging down into the WinAPI.
E.g I'm doing some tests on my Xeon system with 16 hardware cores. Since I am dealing with 2 NUMA pools, the ability to set processor affinity is paramount.
The standard isn't specifically about keeping things lean or targeting the lower-common-denominator, there are many things involved in the
philosophy (Safety, Performance, etc).
Using OS API's don't always provide better performance, more then likely you will get equal performance. Performance should not always be your number one concern instead profile and then look at the problem instead of prematurely optimizing.
For doing things such as controlling processor affinity the standard provides std::thread::native_handle() for being able to call the OS functions when necessary.
LuisR14 wrote:... is taking the fun out of programming, anyways, to consider NULL as an always-related-to-ptrs kind of concept just kind of seems contradictory (which i deem wrong for those other compilers to issue a warning, but what can i do *shrugs*), considering what albpapa mentioned
I don't think it's a matter of taking the fun out of programming, understanding why to use one technique vs another technique is where alot of fun exists. Knowing the pros and cons is very useful.
The warnings are there for very good reasons, because people get things wrong and to provide better type safety. Not only that it is documentation for the code reader that (this is a pointer, this is 0)