Skip to content

Commit fd7879e

Browse files
GitHubber17GitHubber17
authored
Merge pull request #1235 from msebolt/porting-formatting-review-pr1
porting formatting review pr1
2 parents 03da20a + ae67954 commit fd7879e

21 files changed

Lines changed: 1194 additions & 1286 deletions

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

Lines changed: 3 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -13,18 +13,14 @@ ms.workload: ["cplusplus"]
1313
---
1414
# C++ Binary Compatibility between Visual Studio 2015 and Visual Studio 2017
1515

16-
1716
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.
1817

1918
There are two exceptions to this rule. Binary compatibility is not guaranteed in these cases:
2019

21-
1) When static libraries or object files are compiled with the /GL compiler switch.
22-
23-
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.
20+
1. When static libraries or object files are compiled with the `/GL` compiler switch.
2421

22+
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.
2523

2624
## See Also
2725

28-
[Visual C++ change history](..\porting\visual-cpp-change-history-2003-2015.md)
29-
30-
26+
[Visual C++ change history](..\porting\visual-cpp-change-history-2003-2015.md)

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

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -23,9 +23,9 @@ The internal hash function `std::_Hash_seq(const unsigned char *, size_t)`, used
2323

2424
To remove this dependency, you have a couple of options.
2525

26-
- 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.
26+
- 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.
2727

28-
- 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`.
28+
- 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`.
2929

3030
```cpp
3131
/*
@@ -77,4 +77,4 @@ inline size_t fnv1a_hash_bytes(const unsigned char * first, size_t count) {
7777
7878
[Upgrading Projects from Earlier Versions of Visual C++](upgrading-projects-from-earlier-versions-of-visual-cpp.md)
7979
[Overview of potential upgrade issues (Visual C++)](overview-of-potential-upgrade-issues-visual-cpp.md)
80-
[Upgrade your code to the Universal CRT](upgrade-your-code-to-the-universal-crt.md)
80+
[Upgrade your code to the Universal CRT](upgrade-your-code-to-the-universal-crt.md)

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

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -24,7 +24,7 @@ When the math functions were moved to the Universal CRT in Visual Studio 2015, s
2424

2525
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.
2626

27-
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.
27+
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.
2828

2929
## How to get identical results
3030

@@ -34,4 +34,4 @@ In most cases, the floating-point changes in the newest compilers and libraries
3434

3535
[Upgrading Projects from Earlier Versions of Visual C++](upgrading-projects-from-earlier-versions-of-visual-cpp.md)
3636
[Overview of potential upgrade issues (Visual C++)](overview-of-potential-upgrade-issues-visual-cpp.md)
37-
[Visual C++ change history 2003 - 2015](visual-cpp-change-history-2003-2015.md)
37+
[Visual C++ change history 2003 - 2015](visual-cpp-change-history-2003-2015.md)

0 commit comments

Comments
 (0)