Merge pull request #1235 from msebolt/porting-formatting-review-pr1

porting formatting review pr1

Author: GitHubber17

docs/porting/binary-compat-2015-2017.md

@@ -13,18 +13,14 @@ ms.workload: ["cplusplus"]
 ---
 # C++ Binary Compatibility between Visual Studio 2015 and Visual Studio 2017
 
-
 In previous versions of Visual Studio, binary compatibility between object files (OBJs), static libraries (LIBs), dynamic libraries (DLLs), and executables (EXEs) built by using different versions of the compiler toolset and runtime libraries was not guaranteed. This has changed in Visual Studio 2017. In Visual Studio 2015 and Visual Studio 2017, the C++ toolset major number is 14 (v140 for Visual Studio 2015 and v141 for Visual Studio 2017). This reflects the fact that both the runtime libraries and the applications compiled with either version of the compiler are--for the most part--binary compatible. This means, for example, that you can create a DLL in Visual Studio 2017, and consume it from an application compiled with Visual Studio 2015, or use the Visual Studio 2017 redistributable libraries with your application built by using the 2015 toolset.  
 
 There are two exceptions to this rule. Binary compatibility is not guaranteed in these cases:  
 
-1) When static libraries or object files are compiled with the /GL compiler switch.  
-
-2) When consuming libraries built with a toolset whose version is greater than the toolset used to compile and link the application. For example, a program that is compiled and linked with toolset 19.12 can consume libraries that are compiled with 19.0 up through 19.12. Linking 19.x programs with libraries produced by Visual Studio 2013 or earlier is not supported.
+1. When static libraries or object files are compiled with the `/GL` compiler switch.  
 
+2. When consuming libraries built with a toolset whose version is greater than the toolset used to compile and link the application. For example, a program that is compiled and linked with toolset 19.12 can consume libraries that are compiled with 19.0 up through 19.12. Linking 19.x programs with libraries produced by Visual Studio 2013 or earlier is not supported.
 
 ## See Also  
 
-[Visual C++ change history](..\porting\visual-cpp-change-history-2003-2015.md)
-
-
+[Visual C++ change history](..\porting\visual-cpp-change-history-2003-2015.md)

docs/porting/fix-your-dependencies-on-library-internals.md

@@ -23,9 +23,9 @@ The internal hash function `std::_Hash_seq(const unsigned char *, size_t)`, used
 
 To remove this dependency, you have a couple of options.  
 
--   If your intent is to put a `const char *` sequence into an unordered container by using the same hash code machinery as `basic_string`, you can do that by using the `std::hash` template overload that takes a `std::string_view`, which returns that hash code in a portable way. The string library code may or may not rely on use of an FNV-1a hash in the future, so this is the best way to avoid a dependency on a particular hash algorithm. 
+- If your intent is to put a `const char *` sequence into an unordered container by using the same hash code machinery as `basic_string`, you can do that by using the `std::hash` template overload that takes a `std::string_view`, which returns that hash code in a portable way. The string library code may or may not rely on use of an FNV-1a hash in the future, so this is the best way to avoid a dependency on a particular hash algorithm. 
 
--   If your intent is to generate an FNV-1a hash over arbitrary memory, we've made that code available on GitHub in the [VCSamples]( https://github.com/Microsoft/vcsamples) repository in a stand-alone header file, [fnv1a.hpp](https://github.com/Microsoft/VCSamples/tree/master/VC2015Samples/_Hash_seq), under an [MIT license](https://github.com/Microsoft/VCSamples/blob/master/license.txt). We've also included a copy here for your convenience. You can copy this code into a header file, add the header to any affected code, and then find and replace `_Hash_seq` by `fnv1a_hash_bytes`. You'll get identical behavior to the internal implementation in `_Hash_seq`. 
+- If your intent is to generate an FNV-1a hash over arbitrary memory, we've made that code available on GitHub in the [VCSamples]( https://github.com/Microsoft/vcsamples) repository in a stand-alone header file, [fnv1a.hpp](https://github.com/Microsoft/VCSamples/tree/master/VC2015Samples/_Hash_seq), under an [MIT license](https://github.com/Microsoft/VCSamples/blob/master/license.txt). We've also included a copy here for your convenience. You can copy this code into a header file, add the header to any affected code, and then find and replace `_Hash_seq` by `fnv1a_hash_bytes`. You'll get identical behavior to the internal implementation in `_Hash_seq`. 
 
 ```cpp  
 /*
@@ -77,4 +77,4 @@ inline size_t fnv1a_hash_bytes(const unsigned char * first, size_t count) {
   
 [Upgrading Projects from Earlier Versions of Visual C++](upgrading-projects-from-earlier-versions-of-visual-cpp.md)  
 [Overview of potential upgrade issues (Visual C++)](overview-of-potential-upgrade-issues-visual-cpp.md)  
-[Upgrade your code to the Universal CRT](upgrade-your-code-to-the-universal-crt.md)  
+[Upgrade your code to the Universal CRT](upgrade-your-code-to-the-universal-crt.md)  

docs/porting/floating-point-migration-issues.md

@@ -24,7 +24,7 @@ When the math functions were moved to the Universal CRT in Visual Studio 2015, s
 
 Many of the floating point math library functions have different implementations for different CPU architectures. For example, the 32-bit x86 CRT may have a different implementation than the 64-bit x64 CRT. In addition, some of the functions may have multiple implementations for a given CPU architecture. The most efficient implementation is selected dynamically at run-time depending on the instruction sets supported by the CPU. For example, in the 32-bit x86 CRT, some functions have both an x87 implementation and an SSE2 implementation. When running on a CPU that supports SSE2, the faster SSE2 implementation is used. When running on a CPU that does not support SSE2, the slower x87 implementation is used. You may see this when migrating old code, because the default x86 compiler architecture option changed to [/arch:SSE2](../build/reference/arch-x86.md) in Visual Studio 2012. Because different implementations of the math library functions may use different CPU instructions and different algorithms to produce their results, the functions may produce different results on different platforms. In most cases, the results are within +/-1 ulp of the correctly rounded result, but the actual results may vary across CPUs.  
 
-Code-generation correctness improvements in different floating point modes in Visual Studio can also affect the results of floating-point operations when old code is compared to new code, even when using the same compiler flags. For example, the code generated by Visual Studio 2010 when [/fp:precise](../build/reference/fp-specify-floating-point-behavior.md) (the default) or **/fp:strict** was specified may not have propagated intermediate not-a-number (NaN) values through expressions correctly. Thus, some expressions that gave a numeric result in older compilers may now correctly produce a NaN result. You may also see differences because the code optimizations enabled for **/fp:fast** now take advantage of more processor features. These optimizations can use fewer instructions, but may impact the generated results because some previously visible intermediate operations have been removed.  
+Code-generation correctness improvements in different floating point modes in Visual Studio can also affect the results of floating-point operations when old code is compared to new code, even when using the same compiler flags. For example, the code generated by Visual Studio 2010 when [/fp:precise](../build/reference/fp-specify-floating-point-behavior.md) (the default) or `/fp:strict` was specified may not have propagated intermediate not-a-number (NaN) values through expressions correctly. Thus, some expressions that gave a numeric result in older compilers may now correctly produce a NaN result. You may also see differences because the code optimizations enabled for `/fp:fast` now take advantage of more processor features. These optimizations can use fewer instructions, but may impact the generated results because some previously visible intermediate operations have been removed.  
 
 ## How to get identical results  
 
@@ -34,4 +34,4 @@ In most cases, the floating-point changes in the newest compilers and libraries
 
 [Upgrading Projects from Earlier Versions of Visual C++](upgrading-projects-from-earlier-versions-of-visual-cpp.md)  
 [Overview of potential upgrade issues (Visual C++)](overview-of-potential-upgrade-issues-visual-cpp.md)  
-[Visual C++ change history 2003 - 2015](visual-cpp-change-history-2003-2015.md)  
+[Visual C++ change history 2003 - 2015](visual-cpp-change-history-2003-2015.md)