MicrosoftDocs · Colin Robertson (colin-home) · May 23, 2019 · May 14, 2019 · May 14, 2019 · May 14, 2019
diff --git a/.gitignore b/.gitignore
@@ -7,6 +7,7 @@ _themes.MSDN.Modern/
 _themes.VS.Modern/
 
 .openpublishing.buildcore.ps1
+.vscode/
 
 # Documentation build
 /docs/vcppdocs
diff --git a/docs/build/media/mathclient-project-name-2019.png b/docs/build/media/mathclient-project-name-2019.png
diff --git a/docs/c-runtime-library/reference/open-osfhandle.md b/docs/c-runtime-library/reference/open-osfhandle.md
@@ -1,6 +1,6 @@
 ---
 title: "_open_osfhandle"
-ms.date: "05/29/2018"
+ms.date: "05/21/2019"
 apiname: ["_open_osfhandle"]
 apilocation: ["msvcrt.dll", "msvcr80.dll", "msvcr90.dll", "msvcr100.dll", "msvcr100_clr0400.dll", "msvcr110.dll", "msvcr110_clr0400.dll", "msvcr120.dll", "msvcr120_clr0400.dll", "ucrtbase.dll", "api-ms-win-crt-stdio-l1-1-0.dll"]
 apitype: "DLLExport"
@@ -46,7 +46,7 @@ These manifest constants are defined in \<fcntl.h>:
 | **\_O\_TEXT** | Opens the file in text (translated) mode. |
 | **\_O\_WTEXT** | Opens the file in Unicode (translated UTF-16) mode. |
 
-The **_open_osfhandle** call transfers ownership of the Win32 file handle to the file descriptor. To close a file opened with **_open_osfhandle**, call [\_close](close.md). The underlying OS file handle is also closed by a call to **_close**, so it is not necessary to call the Win32 function **CloseHandle** on the original handle. If the file descriptor is owned by a **FILE &#42;** stream, then calling [fclose](fclose-fcloseall.md) on that **FILE &#42;** stream also closes both the file descriptor and the underlying handle. In this case, do not call **_close** on the file descriptor.
+The **_open_osfhandle** call transfers ownership of the Win32 file handle to the file descriptor. To close a file opened by using **_open_osfhandle**, call [\_close](close.md). The underlying OS file handle is also closed by a call to **_close**. Don't call the Win32 function **CloseHandle** on the original handle. If the file descriptor is owned by a **FILE &#42;** stream, then a call to [fclose](fclose-fcloseall.md) on that **FILE &#42;** stream closes both the file descriptor and the underlying handle. In this case, don't call **_close** on the file descriptor or **CloseHandle** on the original handle.
 
 ## Requirements
 

diff --git a/docs/c-runtime-library/reference/setmaxstdio.md b/docs/c-runtime-library/reference/setmaxstdio.md
@@ -1,6 +1,6 @@
 ---
 title: "_setmaxstdio"
-ms.date: "11/04/2016"
+ms.date: "05/21/2019"
 apiname: ["_setmaxstdio"]
 apilocation: ["msvcrt.dll", "msvcr80.dll", "msvcr90.dll", "msvcr100.dll", "msvcr100_clr0400.dll", "msvcr110.dll", "msvcr110_clr0400.dll", "msvcr120.dll", "msvcr120_clr0400.dll", "ucrtbase.dll", "api-ms-win-crt-stdio-l1-1-0.dll"]
 apitype: "DLLExport"
@@ -10,39 +10,39 @@ ms.assetid: 9e966875-9ff5-47c4-9b5f-e79e83b70249
 ---
 # _setmaxstdio
 
-Sets a maximum for the number of simultaneously open files at the **stdio** level.
+Sets a maximum for the number of simultaneously open files at the stream I/O level.
 
 ## Syntax
 
 ```C
 int _setmaxstdio(
-   int newmax
+   int new_max
 );
 ```
 
 ### Parameters
 
-*newmax*<br/>
-New maximum for the number of simultaneously open files at the **stdio** level.
+*new_max*<br/>
+New maximum for the number of simultaneously open files at the stream I/O level.
 
 ## Return Value
 
-Returns *newmax* if successful; -1 otherwise.
+Returns *new_max* if successful; -1 otherwise.
 
-If *newmax* is less than **_IOB_ENTRIES** or greater then the maximum number of handles available in the operating system, the invalid parameter handler is invoked, as described in [Parameter Validation](../../c-runtime-library/parameter-validation.md). If execution is allowed to continue, this function returns -1 and sets **errno** to **EINVAL**.
+If *new_max* is less than **_IOB_ENTRIES**, or greater than the maximum number of handles available in the operating system, the invalid parameter handler is invoked, as described in [Parameter Validation](../../c-runtime-library/parameter-validation.md). If execution is allowed to continue, this function returns -1 and sets **errno** to **EINVAL**.
 
 For information about these and other error codes, see [_doserrno, errno, _sys_errlist, and _sys_nerr](../../c-runtime-library/errno-doserrno-sys-errlist-and-sys-nerr.md).
 
 ## Remarks
 
-The **_setmaxstdio** function changes the maximum value for the number of files that might be simultaneously open at the **stdio** level.
+The **_setmaxstdio** function changes the maximum value for the number of files that may be open simultaneously at the stream I/O level.
 
-C run-time I/O now supports many more open files on Win32 platforms than in previous versions. Up to 2,048 files can be open simultaneously at the [lowio level](../../c-runtime-library/low-level-i-o.md) (that is, opened and accessed by means of the **_open**, **_read**, **_write**, and so forth family of I/O functions). Up to 512 files can be open simultaneously at the [stdio level](../../c-runtime-library/stream-i-o.md) (that is, opened and accessed by means of the **fopen**, **fgetc**, **fputc**, and so forth family of functions). The limit of 512 open files at the **stdio** level can be increased to a maximum of 2,048 by means of the **_setmaxstdio** function.
+C run-time I/O now supports up to 8,192 files open simultaneously at the [low I/O level](../../c-runtime-library/low-level-i-o.md). This level includes files opened and accessed using the **_open**, **_read**, and **_write** family of I/O functions. By default, up to 512 files can be open simultaneously at the [stream I/O level](../../c-runtime-library/stream-i-o.md). This level includes files opened and accessed using the **fopen**, **fgetc**, and **fputc** family of functions. The limit of 512 open files at the stream I/O level can be increased to a maximum of 8,192 by use of the **_setmaxstdio** function.
 
-Because **stdio**-level functions, such as **fopen**, are built on top of the **lowio** functions, the maximum of 2,048 is a hard upper limit for the number of simultaneously open files accessed through the C run-time library.
+Because stream I/O-level functions, such as **fopen**, are built on top of the low I/O-level functions, the maximum of 8,192 is a hard upper limit for the number of simultaneously open files accessed through the C run-time library.
 
 > [!NOTE]
-> This upper limit might be beyond what is supported by a particular Win32 platform and configuration.
+> This upper limit might be beyond what's supported by a particular Win32 platform and configuration.
 
 ## Requirements
 

diff --git a/docs/cpp/codesnippet/CPP/how-to-create-and-use-shared-ptr-instances_3.cpp b/docs/cpp/codesnippet/CPP/how-to-create-and-use-shared-ptr-instances_3.cpp
@@ -1,7 +1,7 @@
     vector<shared_ptr<Song>> v {
       make_shared<Song>(L"Bob Dylan", L"The Times They Are A Changing"),
       make_shared<Song>(L"Aretha Franklin", L"Bridge Over Troubled Water"),
-      make_shared<Song>(L"Thal�a", L"Entre El Mar y Una Estrella")
+      make_shared<Song>(L"Thalía", L"Entre El Mar y Una Estrella")
     };
 
     vector<shared_ptr<Song>> v2;

diff --git a/docs/cpp/codesnippet/CPP/how-to-create-and-use-shared-ptr-instances_4.cpp b/docs/cpp/codesnippet/CPP/how-to-create-and-use-shared-ptr-instances_4.cpp
@@ -1,6 +1,6 @@
     vector<shared_ptr<MediaAsset>> assets {
       make_shared<Song>(L"Himesh Reshammiya", L"Tera Surroor"),
-      make_shared<Song>(L"Penaz Masani", L"Tu Dil De De")),
+      make_shared<Song>(L"Penaz Masani", L"Tu Dil De De"),
       make_shared<Photo>(L"2011-04-06", L"Redmond, WA", L"Soccer field at Microsoft.")
     };
 
@@ -18,5 +18,5 @@
     {
         // We know that the photos vector contains only 
         // shared_ptr<Photo> objects, so use static_cast.
-        wcout << "Photo location: " << (static_pointer_cast<Photo>(p))->location_ << endl;
+        wcout << "Photo location: " << (static_pointer_cast<Photo>(p))->location << endl;
     }
diff --git a/docs/cpp/how-to-create-and-use-shared-ptr-instances.md b/docs/cpp/how-to-create-and-use-shared-ptr-instances.md
@@ -1,7 +1,7 @@
 ---
 title: "How to: Create and Use shared_ptr Instances"
 ms.custom: "how-to"
-ms.date: "11/19/2018"
+ms.date: "05/22/2019"
 ms.topic: "conceptual"
 ms.assetid: 7d6ebb73-fa0d-4b0b-a528-bf05de96518e
 ---
@@ -13,9 +13,60 @@ The following illustration shows several `shared_ptr` instances that point to on
 
 ![Shared pointer diagram](../cpp/media/shared_ptr.png "Shared pointer diagram")
 
+## Example setup
+
+The examples that follow all assume that you've included the required headers and declared the required types, as shown here:
+
+```cpp
+// shared_ptr-examples.cpp
+// The following examples assume these declarations:
+#include <algorithm>
+#include <iostream>
+#include <memory>
+#include <string>
+#include <vector>
+
+struct MediaAsset
+{
+    virtual ~MediaAsset() = default; // make it polymorphic
+};
+
+struct Song : public MediaAsset
+{
+    std::wstring artist;
+    std::wstring title;
+    Song(const std::wstring& artist_, const std::wstring& title_) :
+        artist{ artist_ }, title{ title_ } {}
+};
+
+struct Photo : public MediaAsset
+{
+    std::wstring date;
+    std::wstring location;
+    std::wstring subject;
+    Photo(
+        const std::wstring& date_,
+        const std::wstring& location_,
+        const std::wstring& subject_) :
+        date{ date_ }, location{ location_ }, subject{ subject_ } {}
+};
+
+using namespace std;
+
+int main()
+{
+    // The examples go here, in order:
+    // Example 1
+    // Example 2
+    // Example 3
+    // Example 4
+    // Example 6
+}
+```
+
 ## Example 1
 
-Whenever possible, use the [make_shared](../standard-library/memory-functions.md#make_shared) function to create a `shared_ptr` when the memory resource is created for the first time. `make_shared` is exception-safe. It uses the same call to allocate the memory for the control block and the resource, and thereby reduces the construction overhead. If you do not use `make_shared`, then you have to use an explicit new expression to create the object before you pass it to the `shared_ptr` constructor. The following example shows various ways to declare and initialize a `shared_ptr` together with a new object.
+Whenever possible, use the [make_shared](../standard-library/memory-functions.md#make_shared) function to create a `shared_ptr` when the memory resource is created for the first time. `make_shared` is exception-safe. It uses the same call to allocate the memory for the control block and the resource, which reduces the construction overhead. If you don't use `make_shared`, then you have to use an explicit `new` expression to create the object before you pass it to the `shared_ptr` constructor. The following example shows various ways to declare and initialize a `shared_ptr` together with a new object.
 
 [!code-cpp[stl_smart_pointers#1](../cpp/codesnippet/CPP/how-to-create-and-use-shared-ptr-instances_1.cpp)]
 
@@ -27,7 +78,7 @@ The following example shows how to declare and initialize `shared_ptr` instances
 
 ## Example 3
 
-`shared_ptr` is also helpful in C++ Standard Library containers when you are using algorithms that copy elements. You can wrap elements in a `shared_ptr`, and then copy it into other containers with the understanding that the underlying memory is valid as long as you need it, and no longer. The following example shows how to use the `replace_copy_if` algorithm on `shared_ptr` instances in a vector.
+`shared_ptr` is also helpful in C++ Standard Library containers when you're using algorithms that copy elements. You can wrap elements in a `shared_ptr`, and then copy it into other containers with the understanding that the underlying memory is valid as long as you need it, and no longer. The following example shows how to use the `replace_copy_if` algorithm on `shared_ptr` instances in a vector.
 
 [!code-cpp[stl_smart_pointers#4](../cpp/codesnippet/CPP/how-to-create-and-use-shared-ptr-instances_3.cpp)]
 
@@ -41,17 +92,17 @@ You can use `dynamic_pointer_cast`, `static_pointer_cast`, and `const_pointer_ca
 
 You can pass a `shared_ptr` to another function in the following ways:
 
-- Pass the `shared_ptr` by value. This invokes the copy constructor, increments the reference count, and makes the callee an owner. There is a small amount of overhead in this operation, which may be significant depending on how many `shared_ptr` objects you are passing. Use this option when the code contract (implied or explicit) between the caller and callee requires that the callee be an owner.
+- Pass the `shared_ptr` by value. This invokes the copy constructor, increments the reference count, and makes the callee an owner. There's a small amount of overhead in this operation, which may be significant depending on how many `shared_ptr` objects you're passing. Use this option when the implied or explicit code contract between the caller and callee requires that the callee be an owner.
 
-- Pass the `shared_ptr` by reference or const reference. In this case, the reference count is not incremented, and the callee can access the pointer as long as the caller does not go out of scope. Or, the callee can decide to create a `shared_ptr` based on the reference, and thereby become a shared owner. Use this option when the caller has no knowledge of the callee, or when you must pass a `shared_ptr` and want to avoid the copy operation for performance reasons.
+- Pass the `shared_ptr` by reference or const reference. In this case, the reference count isn't incremented, and the callee can access the pointer as long as the caller doesn't go out of scope. Or, the callee can decide to create a `shared_ptr` based on the reference, and become a shared owner. Use this option when the caller has no knowledge of the callee, or when you must pass a `shared_ptr` and want to avoid the copy operation for performance reasons.
 
-- Pass the underlying pointer or a reference to the underlying object. This enables the callee to use the object, but does not enable it to share ownership or extend the lifetime. If the callee creates a `shared_ptr` from the raw pointer, the new `shared_ptr` is independent from the original, and does not control the underlying resource. Use this option when the contract between the caller and callee clearly specifies that the caller retains ownership of the `shared_ptr` lifetime.
+- Pass the underlying pointer or a reference to the underlying object. This enables the callee to use the object, but doesn't enable it to share ownership or extend the lifetime. If the callee creates a `shared_ptr` from the raw pointer, the new `shared_ptr` is independent from the original, and doesn't control the underlying resource. Use this option when the contract between the caller and callee clearly specifies that the caller retains ownership of the `shared_ptr` lifetime.
 
-- When you are deciding how to pass a `shared_ptr`, determine whether the callee has to share ownership of the underlying resource. An "owner" is an object or function that can keep the underlying resource alive for as long as it needs it. If the caller has to guarantee that the callee can extend the life of the pointer beyond its (the function's) lifetime, use the first option. If you don't care whether the callee extends the lifetime, then pass by reference and let the callee copy it or not.
+- When you're deciding how to pass a `shared_ptr`, determine whether the callee has to share ownership of the underlying resource. An "owner" is an object or function that can keep the underlying resource alive for as long as it needs it. If the caller has to guarantee that the callee can extend the life of the pointer beyond its (the function's) lifetime, use the first option. If you don't care whether the callee extends the lifetime, then pass by reference and let the callee copy it or not.
 
-- If you have to give a helper function access to the underlying pointer, and you know that the helper function will just use the pointer and return before the calling function returns, then that function does not have to share ownership of the underlying pointer. It just has to access the pointer within the lifetime of the caller's `shared_ptr`. In this case, it is safe to pass the `shared_ptr` by reference, or pass the raw pointer or a reference to the underlying object. Passing this way provides a small performance benefit, and may also help you express your programming intent.
+- If you have to give a helper function access to the underlying pointer, and you know that the helper function will just use the pointer and return before the calling function returns, then that function doesn't have to share ownership of the underlying pointer. It just has to access the pointer within the lifetime of the caller's `shared_ptr`. In this case, it's safe to pass the `shared_ptr` by reference, or pass the raw pointer or a reference to the underlying object. Passing this way provides a small performance benefit, and may also help you express your programming intent.
 
-- Sometimes, for example in a `std:vector<shared_ptr<T>>`, you may have to pass each `shared_ptr` to a lambda expression body or named function object. If the lambda or function is not storing the pointer, then pass the `shared_ptr` by reference to avoid invoking the copy constructor for each element.
+- Sometimes, for example in a `std:vector<shared_ptr<T>>`, you may have to pass each `shared_ptr` to a lambda expression body or named function object. If the lambda or function doesn't store the pointer, then pass the `shared_ptr` by reference to avoid invoking the copy constructor for each element.
 
 ## Example 6
 

diff --git a/docs/linux/cmake-linux-project.md b/docs/linux/cmake-linux-project.md
@@ -1,7 +1,7 @@
 ---
 title: "Configure a Linux CMake project in Visual Studio"
 description: "How to configure, edit and compile a Linux CMake project in Visual Studio"
-ms.date: "05/03/2019"
+ms.date: "05/21/2019"
 ms.assetid: f8707b32-f90d-494d-ae0b-1d44425fdc25
 ---
 
@@ -147,9 +147,9 @@ You can use these optional settings for more control:
 
 ```json
 {
-      "remotePreBuildCommand": "",
+      "remotePrebuildCommand": "",
       "remotePreGenerateCommand": "",
-      "remotePostBuildCommand": "",
+      "remotePostbuildCommand": "",
 }
 ```
 

diff --git a/docs/mfc/reference/message-map-macros-mfc.md b/docs/mfc/reference/message-map-macros-mfc.md
@@ -78,7 +78,7 @@ END_MESSAGE_MAP()
 
 **Header:** afxwin.h
 
-## BEGIN_TEMPLATE_MESSAGE_MAP
+## <a name="begin_template_message_map"></a> BEGIN_TEMPLATE_MESSAGE_MAP
 
 Begins the definition of a message map on a class type containing a single template argument.
 

diff --git a/docs/mfc/reference/run-time-object-model-services.md b/docs/mfc/reference/run-time-object-model-services.md
@@ -53,7 +53,7 @@ Determines whether the Common Controls library implements the specified API.
 
 ### Syntax
 
-  ```
+```
 AFX_COMCTL32_IF_EXISTS(  proc );
 ```
 
@@ -158,7 +158,7 @@ See the example for [IMPLEMENT_DYNCREATE](#implement_dyncreate).
 
 **Header:** afx.h
 
-## DECLARE_OLECTLTYPE
+## <a name="declare_olectltype"></a> DECLARE_OLECTLTYPE
 
 Declares the `GetUserTypeNameID` and `GetMiscStatus` member functions of your control class.
 
@@ -181,7 +181,7 @@ The name of the control class.
 
 **Header:** afxctl.h
 
-## DECLARE_PROPPAGEIDS
+## <a name="declare_proppageids"></a> DECLARE_PROPPAGEIDS
 
 Declares that the OLE control provides a list of property pages to display its properties.
 
@@ -355,7 +355,7 @@ The OLE class ID is a unique 128-bit identifier for the object. It consists of o
 
 **Header:** afxdisp.h
 
-## IMPLEMENT_OLECTLTYPE
+## <a name="implement_olectltype"></a> IMPLEMENT_OLECTLTYPE
 
 Implements the `GetUserTypeNameID` and `GetMiscStatus` member functions of your control class.