Fix feedback issues

Author: Colin Robertson

docs/c-runtime-library/secure-template-overloads.md

@@ -40,72 +40,76 @@ translation.priority.ht:
   - "zh-tw"
 ---
 # Secure Template Overloads
-Many CRT functions have been deprecated in favor of newer, security-enhanced versions (for example, `strcpy_s` is the more secure replacement for `strcpy`). The CRT provides template overloads to help ease the transition to the more secure variants.  
+Microsoft has deprecated many C Runtime library (CRT) functions in favor of security-enhanced versions. For example, `strcpy_s` is the more secure replacement for `strcpy`. The deprecated functions are common sources of security bugs, because they do not prevent operations that can overwrite memory. By default, the compiler produces a deprecation warning when you use one of these functions. The CRT provides C++ template overloads for these functions to help ease the transition to the more secure variants.  
 
- For example, this code generates a warning because `strcpy` is deprecated:  
+For example, this code snippet generates a warning because `strcpy` is deprecated:  
 
- `char szBuf[10];`  
+```cpp  
+char szBuf[10];  
+strcpy(szBuf, "test"); // warning: deprecated  
+```
   
- `strcpy(szBuf, "test"); // warning: deprecated`  
+The deprecation warning is there to tell you that your code may be unsafe. If you have verified that your code can't overwrite memory, you have several choices. You can choose to ignore the warning, you can define the symbol `_CRT_SECURE_NO_WARNINGS` before the include statements for the CRT headers to suppress the warning, or you can update your code to use `strcpy_s`:  
   
- You can ignore the warning. Define the symbol `_CRT_SECURE_NO_WARNINGS` to suppress the warning, or update the code to use `strcpy_s`:  
+```cpp  
+char szBuf[10];  
+strcpy_s(szBuf, 10, "test"); // security-enhanced _s function  
+```
 
- `char szBuf[10];`  
+The template overloads provide additional choices. If you define `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` to 1, this enables template overloads of standard CRT functions that call the more secure variants automatically. If `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` is 1, then no changes to your code are necessary. Behind the scenes, the call to `strcpy` is changed to a call to `strcpy_s` with the size argument supplied automatically.  
 
- `strcpy_s(szBuf, 10, "test"); // security-enhanced _s function`  
+```cpp  
+#define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1  
 
- The template overloads provide additional choices. Defining `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` to 1 enables template overloads of standard CRT functions that call the more secure variants automatically. If `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` is 1, then no changes to the code are necessary. Behind the scenes, the call to `strcpy` will be changed to a call to `strcpy_s` with the size argument supplied automatically.  
+// ...  
 
- `#define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1`  
+char szBuf[10];  
+strcpy(szBuf, "test"); // ==> strcpy_s(szBuf, 10, "test")  
+```  
   
- `...`  
-  
- `char szBuf[10];`  
-  
- `strcpy(szBuf, "test"); // ==> strcpy_s(szBuf, 10, "test")`  
-  
- `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` does not affect the functions that take a count, such as `strncpy`. To enable template overloads for the count functions, define `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_COUNT` to 1. Before doing so, however, make sure that your code passes the count of characters, not the size of the buffer (a common mistake). Also, code that explicitly writes a null terminator at the end of the buffer after the function call is unnecessary if the secure variant is called. If you need truncation behavior, see [_TRUNCATE](../c-runtime-library/truncate.md).  
+The macro `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` does not affect the functions that take a count, such as `strncpy`. To enable template overloads for the count functions, define `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_COUNT` to 1. Before doing so, however, make sure that your code passes the count of characters, not the size of the buffer (a common mistake). Also, code that explicitly writes a null terminator at the end of the buffer after the function call is unnecessary if the secure variant is called. If you need truncation behavior, see [_TRUNCATE](../c-runtime-library/truncate.md).  
   
 > [!NOTE]
 >  The macro `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_COUNT` requires that `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` is also defined as 1. If `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_COUNT` is defined as 1 and `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` is defined as 0, the application will not perform any template overloads.  
   
- Defining `_CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES` to 1 enables template overloads of the secure variants (names ending in "_s"). In this case, if `_CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES` is 1, then one small change must be made to the original code:  
-  
- `#define _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES 1`  
+When you define `_CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES` to 1, it enables template overloads of the secure variants (names ending in "_s"). In this case, if `_CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES` is 1, then one small change must be made to the original code:  
   
- `...`  
+```cpp  
+#define _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES 1  
   
- `char szBuf[10];`  
+// ...  
   
- `strcpy_s(szBuf, "test"); // ==> strcpy_s(szBuf, 10, "test")`  
+char szBuf[10];  
+strcpy_s(szBuf, "test"); // ==> strcpy_s(szBuf, 10, "test")  
+```  
 
- Only the name of the function needs to be changed (by adding "_s"); the template overload will take care of providing the size argument.  
+ Only the name of the function needs to be changed (by adding "_s"); the template overload takes care of providing the size argument.  
 
  By default, `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` and `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_COUNT` are defined as 0 (disabled) and `_CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES` is defined as 1 (enabled).  
 
  Note that these template overloads only work for static arrays. Dynamically allocated buffers require additional source code changes. Revisiting the above examples:  
 
- `#define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1`  
+```cpp  
+#define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1  
 
- `...`  
+// ...  
 
- `char *szBuf = (char*)malloc(10);`  
-  
- `strcpy(szBuf, "test"); // still deprecated; have to change to`  
-  
- `// strcpy_s(szBuf, 10, "test");`  
+char *szBuf = (char*)malloc(10);  
+strcpy(szBuf, "test"); // still deprecated; you have to change it to  
+                       // strcpy_s(szBuf, 10, "test");  
+```  
   
  And this:  
   
- `#define _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES 1`  
-  
- `...`  
-  
- `char *szBuf = (char*)malloc(10);`  
+```cpp  
+#define _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES 1  
   
- `strcpy_s(szBuf, "test"); // doesn't compile; have to change to`  
+// ...  
   
- `// strcpy_s(szBuf, 10, "test");`  
+char *szBuf = (char*)malloc(10);  
+strcpy_s(szBuf, "test"); // doesn't compile; you have to change it to  
+                         // strcpy_s(szBuf, 10, "test");  
+```  
 
 ## See Also  
  [Security Features in the CRT](../c-runtime-library/security-features-in-the-crt.md)   

docs/cpp/exception-specifications-throw-cpp.md

@@ -37,29 +37,29 @@ translation.priority.ht:
   - "zh-tw"
 ---
 # Exception Specifications (throw, noexcept) (C++)
-Exception specifications are a C++ language feature that indicate the programmer's intent about the exception types that can be propagated by a function. You can specify that a function may not exit by an exception by using an *exception specification*. The compiler can use this information to optimize calls to the function, and to terminate the program if an exception escapes the function. There are two kinds of exception specification. The *noexcept specification* is new in C++11. It specifies whether the set of potential exceptions that can escape the function is empty. The *dynamic exception specification*, or `throw(optional_type_list)` specification, is deprecated in C++11 and is only partially supported by Visual Studio. This exception specification was designed to provide summary information about what exceptions can be thrown out of a function, but in practice it was found to be problematic. The one dynamic exception specification that did prove to be somewhat useful was the unconditional `throw()` specification. For example, the function declaration:  
+Exception specifications are a C++ language feature that indicate the programmer's intent about the exception types that can be propagated by a function. You can specify that a function may or may not exit by an exception by using an *exception specification*. The compiler can use this information to optimize calls to the function, and to terminate the program if an unexpected exception escapes the function. There are two kinds of exception specification. The *noexcept specification* is new in C++11. It specifies whether the set of potential exceptions that can escape the function is empty. The *dynamic exception specification*, or `throw(optional_type_list)` specification, is deprecated in C++11 and is only partially supported by Visual Studio. This exception specification was designed to provide summary information about what exceptions can be thrown out of a function, but in practice it was found to be problematic. The one dynamic exception specification that did prove to be somewhat useful was the unconditional `throw()` specification. For example, the function declaration:  
 
 ```cpp  
 void MyFunction(int i) throw();  
 ```  
   
  tells the compiler that the function does not throw any exceptions. It is the equivalent to using [__declspec(nothrow)](../cpp/nothrow-cpp.md). Its use is considered optional.  
   
-In the ISO C++11 Standard, [noexcept](../cpp/noexcept-cpp.md) operator was introduced and is supported in Visual Studio 2015 and later. Whenever possible, use `noexcept` to specify whether a function might throw exceptions. For example, use this function declaration instead of the one above:  
+In the ISO C++11 Standard, the [noexcept](../cpp/noexcept-cpp.md) operator was introduced as a replacement. It is supported in Visual Studio 2015 and later. Whenever possible, use a `noexcept` expression to specify whether a function might throw exceptions. For example, use this function declaration instead of the one above:  
   
 ```cpp  
 void MyFunction(int i) noexcept;  
 ```  
 
- Visual C++ departs from the ISO C++ Standard in its implementation of dynamic exception specifications.  The following table summarizes the Visual C++ implementation of exception specifications:  
+While Visual C++ fully supports the `noexcept` expression, it departs from the ISO C++ Standard in its implementation of dynamic exception specifications.  The following table summarizes the Visual C++ implementation of exception specifications:  
 
 |Exception specification|Meaning|  
 |-----------------------------|-------------|  
 |`noexcept`<br/>`noexcept(true)`<br/>`throw()`|The function does not throw an exception. However, if an exception is thrown out of a function marked `throw()`, the Visual C++ compiler calls `std::terminate`, not `std::unexpected`. See [std::unexpected](../c-runtime-library/reference/unexpected-crt.md) for more information. If a function is marked `noexcept`, `noexcept(true)`, or `throw()`, the Visual C++ compiler assumes that the function does not throw C++ exceptions and generates code accordingly. Because code optimizations might be performed by the C++ compiler based on the assumption that the function does not throw any C++ exceptions, if a function does throw an exception, the program may not execute correctly.|  
-|`nothrow(false)`<br/>`throw(...)`<br/>No specification|The function can throw an exception of any type.|  
-|`throw(type)`|The function can throw an exception of type `type`. In Visual C++, this syntax is accepted, but it is interpreted as `throw(...)`.|  
+|`noexcept(false)`<br/>`throw(...)`<br/>No specification|The function can throw an exception of any type.|  
+|`throw(type)`|The function can throw an exception of type `type`. In Visual C++, this syntax is accepted, but it is interpreted as `noexcept(false)`.|  
 
- If exception handling is used in an application, there must be a function in the call stack that handles thrown exceptions before they exit a function marked `noexcept`, `noexcept(true)`, or `throw()`. If any functions called between the one that throws an exception and the one that handles the exception are specified as `noexcept`, `noexcept(true)`, or `throw()`, the program is terminated when the noexcept function propagates the exception.  
+ If exception handling is used in an application, there must be a function in the call stack that handles thrown exceptions before they exit the outer scope of a function marked `noexcept`, `noexcept(true)`, or `throw()`. If any functions called between the one that throws an exception and the one that handles the exception are specified as `noexcept`, `noexcept(true)`, or `throw()`, the program is terminated when the noexcept function propagates the exception.  
 
  The exception behavior of a function depends on the following factors:  
 
@@ -76,8 +76,8 @@ void MyFunction(int i) noexcept;
 |Function|/EHsc|/EHs|/EHa|/EHac|  
 |--------------|------------|-----------|-----------|------------|  
 |C++ function with no exception specification|Yes|Yes|Yes|Yes|  
-|C++ function with `nothrow`, `nothrow(true)`, or `throw()` exception specification|No|No|Yes|Yes|  
-|C++ function with `nothrow(false)`, `throw(...)`, or `throw(type)` exception specification|Yes|Yes|Yes|Yes|  
+|C++ function with `noexcept`, `noexcept(true)`, or `throw()` exception specification|No|No|Yes|Yes|  
+|C++ function with `noexcept(false)`, `throw(...)`, or `throw(type)` exception specification|Yes|Yes|Yes|Yes|  
 
 ## Example  
 

docs/cpp/noexcept-cpp.md

@@ -37,30 +37,32 @@ translation.priority.ht:
 
 ## Syntax  
 
-> **noexcept**  
-> **noexcept(** *constant_expression* **)**  
+> *noexcept-expression*:  
+>     **noexcept**  
+>     **noexcept(** *constant-expression* **)**  
   
 ### Parameters  
- *constant_expression*  
+ *constant-expression*  
  A constant expression of type `bool` that represents whether the set of potential exception types is empty. The unconditional version is equivalent to `noexcept(true)`.  
 
 ## Remarks  
- Unary conditional operator `noexcept(true)` and its unconditional synonym `noexcept` specify that the function never throws an exception and never allows an exception to be propagated from any other function that it invokes either directly or indirectly. More specifically, a function is `noexcept` only if all the functions that it calls are also `noexcept` or `const`, and there are no potentially evaluated dynamic casts that require a run-time check, typeid expressions applied to a glvalue expression whose type is a polymorphic class type, or `throw` expressions. However, the compiler does not necessarily check every code path for exceptions that might bubble up to a `noexcept` function. If an exception does reach a function marked `noexcept`, [std::terminate](../standard-library/exception-functions.md#terminate) is invoked immediately, and there is no guarantee that destructors of any in-scope objects will be invoked.  
+ A *noexcept expression* is a kind of *exception specification*, a suffix to a function declaration that represents a set of types that might be matched by an exception handler for any exception that exits a function. Unary conditional operator `noexcept(`*constant_expression*`)` where *constant_expression* yeilds `true`, and its unconditional synonym `noexcept`, specify that the set of potential exception types that can exit a function is empty. That is, the function never throws an exception and never allows an exception to be propagated outside its scope. The operator `noexcept(`*constant_expression*`)` where *constant_expression* yeilds `false`, or the absence of an exception specification (other than for a destructor or deallocation function), indicates that the set of potential exceptions that can exit the function is the set of all types.  
+ 
+ Mark a function as `noexcept` only if all the functions that it calls, either directly or indirectly, are also `noexcept` or `const`. The compiler does not necessarily check every code path for exceptions that might bubble up to a `noexcept` function. If an exception does exit the outer scope of a function marked `noexcept`, [std::terminate](../standard-library/exception-functions.md#terminate) is invoked immediately, and there is no guarantee that destructors of any in-scope objects will be invoked. Use `noexcept` instead of the dynamic exception specifier `throw`, which is deprecated in C++11 and later and not fully implemented in Visual Studio. We recommended you apply `noexcept` to any function that never allows an exception to propagate up the call stack. When a function is declared `noexcept`, it enables the compiler to generate more efficient code in several different contexts.    
 
- A function declared by using a conditional `noexcept` expression that evaluates to `false` (or a function that has no `noexcept` expression, other than a destructor or deallocation function) specifies that it does permit exceptions of all types to propagate. For example, a template function that copies its argument might be declared `noexcept` on the condition that the object being copied is a plain old data type (POD). Such a function could be declared like this:  
+## Example  
+A template function that copies its argument might be declared `noexcept` on the condition that the object being copied is a plain old data type (POD). Such a function could be declared like this:  
 
 ```cpp  
 #include <type_traits>  
 
 template <typename T>  
-T copy_object(T& obj) noexcept(std::is_pod<T>)  
+T copy_object(const T& obj) noexcept(std::is_pod<T>)  
 {  
    // ...   
 }  
 ```  
   
- Use `noexcept` instead of the dynamic exception specifier `throw`, which is deprecated in C++11 and later. We recommended you apply `noexcept` to any function that never allows an exception to propagate up the call stack. A function that is declared `noexcept` enables compilers to generate more efficient code in several different contexts.  
-  
 ## See Also  
  [C++ Exception Handling](../cpp/cpp-exception-handling.md)
  [Exception Specifications (throw, noexcept)](../cpp/exception-specifications-throw.md)