Well, Unit Testing is only one part. Integration tests help you with the problem of your team. Integration Tests can be written for all kinds of applications, also for native and OpenGL applications. You should check out "Growing Object Oriented Software Guided by Tests" by Steve Freemann and Nat Pryce (e.g. http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Signature/dp/0321503627). It leads you step by step through the development of an application with GUI and network communication.
Testing Software that was not test driven is another story. Check Michael Feathers "Working Effectively with Legacy Code" (http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052).
In my previous company we started generating documentation and having a CI job run nightly and post it as a set of webpages which our team's wiki would then refer to.
As was suggested in comments to your question, we used doxygen. One thing I really liked that was introduced in version 1.8 was ability to have a directory (or whole tree) of markdown documents whereas before that doxygen was generated purely from source files.
The structure we had was a welcome screen (markdown) which had links to various places. One of them was a product architecture which showed 30,000 foot view of the product and highlighted major services. Then from that page, there were likes to other markdown pages that expanded each of the services and presented very high level design of each one (10k foot view?).
Also from the main page, we had links to collections of user guides that we wrote to explain how to use some common utility/framework code.
And we slowly started migrating existing design documents (written in MS Word and stored in share point) into doxygen format which actually proved easier than one would expect. If not for the diagrams, which had to be exported individually and saved as JPEGs, a 20-30 page design document could be converted into doxygen markup format in about 15-30 minutes and it was so simple a co-op could do it (*).
The beauty which I loved about using doxygen for this type of documentation besides that it could generate HTML or PDF from the same source, was that we could tie all our documentation directly to class/function reference pages that were generated by parsing header files. So it was a very nice structure that would go from "welcome" -> "architecture" -> "design" -> right down to class-level documentation.
And as the whole thing was in markdown, it was very simple to generate content (much easier than attempting to explain to a team of engineers how to correctly use MS Word Styles) and documentation was checked in right there with the source code, so as new versions were introduced and design/architecture modified, documentation would always stay synced up with it.
(*) - j/k we had great co-ops (for the most part) and they made many awesome contributions to the product, but I did make one of them do some of the doc conversion.
Best Answer
A common use case is the “move constructor,” invoked when an object is being copied from a temporary that’s about to expire (a rvalue). An example is
foo = bar + baz;wherebar + bazis a temporary on the right-hand side of an assignment statement.Before rvalue references, objects that made deep copies of their contents had to construct their data in one place, then copy it all to another, then destroy the first copy. This was slow and wasteful.
When the source is a rvalue reference, the move constructor or assignment operator will typically make a shallow copy of the source’s data, then remove the source’s references so that it will be an empty shell when it’s deleted a moment later and the data will now have a new owner. This is safe, because a rvalue reference won’t be used for anything else before it’s destroyed, much faster, and saves memory.