Merge pull request #2506 from mikeblome/mb-modern-cpp

Updates to Welcome Back to C++ node

Author: American-Dipper

.openpublishing.redirection.json

@@ -55,6 +55,11 @@
          "redirect_url": "/cpp/overview/visual-cpp-tools-and-features-in-visual-studio-editions",
          "redirect_document_id": true
       },
+      {
+         "source_path": "docs/cpp/string-and-i-o-formatting-modern-cpp.md",
+         "redirect_url": "/cpp/text/string-and-i-o-formatting-modern-cpp",
+         "redirect_document_id": true
+      },
       {
          "source_path": "docs/vcpkg.md",
          "redirect_url": "/cpp/build/vcpkg",
@@ -730,6 +735,21 @@
          "redirect_url": "/cpp/cpp/cpp-language-reference",
          "redirect_document_id": false
       },
+      {
+         "source_path": "docs/cpp/objects-own-resources-raii.md",
+         "redirect_url": "/cpp/cpp/object-lifetime-and-resource-management-modern-cpp",
+         "redirect_document_id": false
+      },
+      {
+         "source_path": "docs/cpp/algorithms-modern-cpp.md",
+         "redirect_url": "/cpp/cpp/welcome-back-to-cpp-modern-cpp",
+         "redirect_document_id": false
+      },
+      {
+         "source_path": "docs/cpp/containers-modern-cpp.md",
+         "redirect_url": "/cpp/cpp/welcome-back-to-cpp-modern-cpp",
+         "redirect_document_id": false
+      },
       {
          "source_path": "docs/cpp/cpp-exception-handling.md",
          "redirect_url": "/cpp/cpp/exception-handling-in-visual-cpp",
@@ -872,17 +892,17 @@
       },
       {
          "source_path": "docs/c-runtime-library/reference/cos-cosf-cosl-cosh-coshf-coshl.md",
-         "redirect_url": "/cpp/c-runtime-library/reference/cos-cosf-cosl.md",
+         "redirect_url": "/cpp/c-runtime-library/reference/cos-cosf-cosl",
          "redirect_document_id": false
       },
       {
          "source_path": "docs/c-runtime-library/reference/sin-sinf-sinl-sinh-sinhf-sinhl.md",
-         "redirect_url": "/cpp/c-runtime-library/reference/sin-sinf-sinl.md",
+         "redirect_url": "/cpp/c-runtime-library/reference/sin-sinf-sinl",
          "redirect_document_id": false
       },
       {
          "source_path": "docs/c-runtime-library/reference/tan-tanf-tanl-tanh-tanhf-tanhl.md",
-         "redirect_url": "/cpp/c-runtime-library/reference/tan-tanf-tanl.md",
+         "redirect_url": "/cpp/c-runtime-library/reference/tan-tanf-tanl",
          "redirect_document_id": false
       },
       {
@@ -962,7 +982,7 @@
       },
       {
          "source_path": "docs/ide/cmakesettings-reference.md",
-         "redirect_url": "/cpp/build/cmakesettings-reference.md",
+         "redirect_url": "/cpp/build/cmakesettings-reference",
          "redirect_document_id": true
       },
       {
@@ -13256,4 +13276,4 @@
          "redirect_document_id": false
       }
    ]
-}
+}

docs/cpp/algorithms-modern-cpp.md

@@ -202,7 +202,7 @@ int f(int x) { return x; }
 int main()
 {
     auto x = f(0);
-    const auto & y = f(1);
+    const auto& y = f(1);
     int (*p)(int x);
     p = f;
     auto fp = p;

docs/cpp/auto-cpp.md

@@ -1,60 +1,19 @@
 ---
-title: "Object Lifetime And Resource Management (Modern C++)"
-ms.date: "11/04/2016"
+title: "Object lifetime and resource management (RAII)"
+description: "Follow the principle of RAII in modern C++ to avoid resource leaks."
+ms.date: "11/19/2019"
 ms.topic: "conceptual"
 ms.assetid: 8aa0e1a1-e04d-46b1-acca-1d548490700f
 ---
-# Object Lifetime And Resource Management (Modern C++)
+# Object lifetime and resource management (RAII)
 
-Unlike managed languages, C++ doesn’t have garbage collection (GC), which automatically releases no-longer-used memory resources as a program runs. In C++, resource management is directly related to object lifetime. This document describes the factors that affect object lifetime in C++ and how to manage it.
+Unlike managed languages, C++ doesn't have automatic *garbage collection*. That's an internal process that releases heap memory and other resources as a program runs. A C++ program is responsible for returning all acquired resources to the operating system. Failure to release an unused resource is called a *leak*. Leaked resources are unavailable to other programs until the process exits. Memory leaks in particular are a common cause of bugs in C-style programming.
 
-C++ doesn’t have GC primarily because it doesn't handle non-memory resources. Only deterministic destructors like those in C++ can handle memory and non-memory resources equally. GC also has other problems, like higher overhead in memory and CPU consumption, and locality. But universality is a fundamental problem that can't be mitigated through clever optimizations.
+Modern C++ avoids using heap memory as much as possible by declaring objects on the stack. When a resource is too large for the stack, then it should be *owned* by an object. As the object gets initialized, it acquires the resource it owns. The object is then responsible for releasing the resource in its destructor. The owning object itself is declared on the stack. The principle that *objects own resources* is also known as "resource acquisition is initialization," or RAII.
 
-## Concepts
+When a resource-owning stack object goes out of scope, its destructor is automatically invoked. In this way, garbage collection in C++ is closely related to object lifetime, and is deterministic. A resource is always released at a known point in the program, which you can control. Only deterministic destructors like those in C++ can handle memory and non-memory resources equally.
 
-An important thing in object-lifetime management is the encapsulation—whoever's using an object doesn't have to know what resources that object owns, or how to get rid of them, or even whether it owns any resources at all. It just has to destroy the object. The C++ core language is designed to ensure that objects are destroyed at the correct times, that is, as blocks are exited, in reverse order of construction. When an object is destroyed, its bases and members are destroyed in a particular order.  The language automatically destroys objects, unless you do special things like heap allocation or placement new.  For example, [smart pointers](../cpp/smart-pointers-modern-cpp.md) like `unique_ptr` and `shared_ptr`, and C++ Standard Library containers like `vector`, encapsulate **new**/**delete** and `new[]`/`delete[]` in objects, which have destructors. That's why it's so important to use smart pointers and C++ Standard Library containers.
-
-Another important concept in lifetime management: destructors. Destructors encapsulate resource release.  (The commonly used mnemonic is RRID, Resource Release Is Destruction.)  A resource is something that you get from "the system" and have to give back later.  Memory is the most common resource, but there are also files, sockets, textures, and other non-memory resources. "Owning" a resource means you can use it when you need it but you also have to release it when you're finished with it.  When an object is destroyed, its destructor releases the resources that it owned.
-
-The final concept is the DAG (Directed Acyclic Graph).  The structure of ownership in a program forms a DAG. No object can own itself—that's not only impossible but also inherently meaningless. But two objects can share ownership of a third object.  Several kinds of links are possible in a DAG like this: A is a member of B (B owns A), C stores a `vector<D>` (C owns each D element), E stores a `shared_ptr<F>` (E shares ownership of F, possibly with other objects), and so forth.  As long as there are no cycles and every link in the DAG is represented by an object that has a destructor (instead of a raw pointer, handle, or other mechanism), then resource leaks are impossible because the language prevents them. Resources are released immediately after they're no longer needed, without a garbage collector running. The lifetime tracking is overhead-free for stack scope, bases, members, and related cases, and inexpensive for `shared_ptr`.
-
-### Heap-based lifetime
-
-For heap object lifetime, use [smart pointers](../cpp/smart-pointers-modern-cpp.md). Use `shared_ptr` and `make_shared` as the default pointer and allocator. Use `weak_ptr` to break cycles, do caching, and observe objects without affecting or assuming anything about their lifetimes.
-
-```cpp
-void func() {
-
-auto p = make_shared<widget>(); // no leak, and exception safe
-...
-p->draw();
-
-} // no delete required, out-of-scope triggers smart pointer destructor
-```
-
-Use `unique_ptr` for unique ownership, for example, in the *pimpl* idiom. (See [Pimpl For Compile-Time Encapsulation](../cpp/pimpl-for-compile-time-encapsulation-modern-cpp.md).) Make a `unique_ptr` the primary target of all explicit **new** expressions.
-
-```cpp
-unique_ptr<widget> p(new widget());
-```
-
-You can use raw pointers for non-ownership and observation. A non-owning pointer may dangle, but it can’t leak.
-
-```cpp
-class node {
-  ...
-  vector<unique_ptr<node>> children; // node owns children
-  node* parent; // node observes parent, which is not a concern
-  ...
-};
-node::node() : parent(...) { children.emplace_back(new node(...) ); }
-```
-
-When performance optimization is required, you might have to use *well-encapsulated* owning pointers and explicit calls to delete. An example is when you implement your own low-level data structure.
-
-### Stack-based lifetime
-
-In modern C++, *stack-based scope* is a powerful way to write robust code because it combines automatic *stack lifetime* and *data member lifetime* with high efficiency—lifetime tracking is essentially free of overhead. Heap object lifetime requires diligent manual management and can be the source of resource leaks and inefficiencies, especially when you are working with raw pointers. Consider this code, which demonstrates stack-based scope:
+The following example shows a simple object `w`. It's declared on the stack at function scope, and is destroyed at the end of the function block. The object `w` owns no *resources* (such as heap-allocated memory). Its only member `g` is itself declared on the stack, and simply goes out of scope along with `w`. No special code is needed in the `widget` destructor.
 
 ```cpp
 class widget {
@@ -75,7 +34,54 @@ void functionUsingWidget () {
   // as if "finally { w.dispose(); w.g.dispose(); }"
 ```
 
-Use static lifetime sparingly (global static, function local static) because problems can arise. What happens when the constructor of a global object throws an exception? Typically, the app faults in a way that can be difficult to debug. Construction order is problematic for static lifetime objects, and is not concurrency-safe. Not only is object construction a problem, destruction order can be complex, especially where polymorphism is involved. Even if your object or variable isn’t polymorphic and doesn't have complex construction/destruction ordering, there’s still the issue of thread-safe concurrency. A multithreaded app can’t safely modify the data in static objects without having thread-local storage, resource locks, and other special precautions.
+In the following example, `w` owns a memory resource and so must have code in its destructor to delete the memory.
+ 
+```cpp
+class widget
+{
+private:
+    int* data;
+public:
+    widget(const int size) { data = new int[size]; } // acquire
+    ~widget() { delete[] data; } // release
+    void do_something() {}
+};
+
+void functionUsingWidget() {
+    widget w(1000000);   // lifetime automatically tied to enclosing scope
+                        // constructs w, including the w.data member
+    w.do_something();
+
+} // automatic destruction and deallocation for w and w.data
+
+```
+
+Since C++11, there's a better way to write the previous example: by using a smart pointer from the standard library. The smart pointer handles the allocation and deletion of the memory it owns. Using a smart pointer eliminates the need for an explicit destructor in the `widget` class.
+
+```cpp
+#include <memory>
+class widget
+{
+private:
+    std::unique_ptr<int> data;
+public:
+    widget(const int size) { data = std::make_unique<int>(size); }
+    void do_something() {}
+};
+
+void functionUsingWidget() {
+    widget w(1000000);   // lifetime automatically tied to enclosing scope
+                // constructs w, including the w.data gadget member
+    // ...
+    w.do_something();
+    // ...
+} // automatic destruction and deallocation for w and w.data
+
+```
+
+By using smart pointers for memory allocation, you may eliminate the potential for memory leaks. This model works for other resources, such as file handles or sockets. You can manage your own resources in a similar way in your classes. For more information, see [Smart pointers](smart-pointers-modern-cpp.md).
+
+The design of C++ ensures objects are destroyed when they go out of scope. That is, they get destroyed as blocks are exited, in reverse order of construction. When an object is destroyed, its bases and members are destroyed in a particular order. Objects declared outside of any block, at global scope, can lead to problems. It may be difficult to debug, if the constructor of a global object throws an exception.
 
 ## See also