It's unfortunate that we won't be able to post the video of the talk like we do for the rest of the events that we run, because it was definitely a neat talk.
It's unfortunate that we won't be able to post the video of the talk like we do for the rest of the events that we run, because it was definitely a neat talk.
Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah
You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie
Why can't you guys post it?
Turns out that Texas A&M won't allow videos of their profs lectures to be posted online, and apparently this type of lecture is included in that rule.
Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah
You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie
Yeah smart pointers are mentioned in there (the wikipedia article i mean). Near the top actually:Smart pointers?
I did not see anything about smart pointers being a part of the new standard but I admit I did not read the all of the text so it might be in there.
I had a couple of questions. Here is a quote from the Wikipedia article:Despite this, many people insist that C++ include some mechanism for safe management of the pointer. For this reason, the new standard will provide support for smart pointers, but only through the standard library.
I understand their logic here...but if they make a high level library, the threads won't have very high priority and won't be very powerful, true?The C++ standard committee plans to introduce some tools for multiprocessing and multithreaded programming.
At this stage, full support for multiprocessing appears too dependent on the operating system used, and too complex to be resolved only through an extension of the core language. The common understanding is that multiprocessing support shall be created via a high-level library instead of a low-level library (with potentially dangerous synchronization primitives), as the Committee's goal is not to motivate programmers to use a potentially dangerous standard library instead of a secure but non-standardized library.
Another quote:
Could this atomic key word be used in place of mutex locks and semaphores? If the thread in execution cannot be interrupted, then basically it has locked out all other threads from executing until it finishes....although it is not completely the same as a mutex lock, it can have a similar effect.Atomic operations
Often, a thread needs to perform a task without being interrupted. For example, a thread might require exclusive access to a global variable or real-time access to a peripheral.
To perform such an atomic operation, a new keyword atomic has been proposed
ad Threads: that's news to me. Right now, the proposals to the committee are definitely headed towards low-level threading. Still library-based, but low-level.
ad Atomic: Haven't seen the proposal for this atomic keyword. If it works as described, it would simply be a single, global mutex. In other words, completely useless for most multi-threaded programs.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
