Skip to content

Commit 9c80769

Browse files
ktoliverktoliver
authored
Merge pull request MicrosoftDocs#1998 from mikeblome/mb-conformance-161
More conformance updates for 16.0 and 16.1
2 parents 0983b9d + 8a7b434 commit 9c80769

8 files changed

+517
-192
lines changed

‎docs/build/reference/zc-alignednew.md‎

Lines changed: 6 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
---
22
title: "/Zc:alignedNew (C++17 over-aligned allocation)"
3-
ms.date: "02/28/2018"
3+
ms.date: "05/18/2019"
44
f1_keywords: ["/Zc:alignedNew"]
55
helpviewer_keywords: ["/Zc:alignedNew", "Zc:alignedNew", "-Zc:alignedNew"]
66
---
@@ -10,13 +10,15 @@ Enable support for C++17 over-aligned **new**, dynamic memory allocation aligned
1010

1111
## Syntax
1212

13-
> **/Zc:alignedNew**[-]
13+
> **/Zc:alignedNew**\[-]
1414
1515
## Remarks
1616

17-
Visual Studio version 15.5 enables compiler and library support for C++17 standard over-aligned dynamic memory allocation. When the **/Zc:alignedNew** option is specified, a dynamic allocation such as `new Example;` respects the alignment of *Example* even when it’s greater than `max_align_t`, the largest alignment required for any fundamental type. When the alignment of the allocated type is no more than that guaranteed by the original operator **new**, available as the value of the predefined macro **\_\_STDCPP\_DEFAULT\_NEW\_ALIGNMENT\_\_**, the statement `new Example;` results in a call to `::operator new(size_t)` as it did in C++14. When the alignment is greater than **\_\_STDCPP\_DEFAULT\_NEW\_ALIGNMENT\_\_**, the implementation instead obtains the memory by using `::operator new(size_t, align_val_t)`. Similarly, deletion of over-aligned types invokes `::operator delete(void*, align_val_t)` or the sized delete signature `::operator delete(void*, size_t, align_val_t)`.
17+
The MSVC compiler and library support C++17 standard over-aligned dynamic memory allocation. When the **/Zc:alignedNew** option is specified, a dynamic allocation such as `new Example;` respects the alignment of *Example* even when it’s greater than `max_align_t`, the largest alignment required for any fundamental type. When the alignment of the allocated type is no more than the alignment guaranteed by the original operator **new**, available as the value of the predefined macro **\_\_STDCPP\_DEFAULT\_NEW\_ALIGNMENT\_\_**, the statement `new Example;` results in a call to `::operator new(size_t)` as it did in C++14. When the alignment is greater than **\_\_STDCPP\_DEFAULT\_NEW\_ALIGNMENT\_\_**, the implementation instead obtains the memory by using `::operator new(size_t, align_val_t)`. Similarly, deletion of over-aligned types invokes `::operator delete(void*, align_val_t)` or the sized delete signature `::operator delete(void*, size_t, align_val_t)`.
1818

19-
The **/Zc:alignedNew** option is only available when [/std:c++17](std-specify-language-standard-version.md) or [/std:c++latest](std-specify-language-standard-version.md) is enabled. Under **/std:c++17** or **/std:c++latest**, **/Zc:alignedNew** is enabled by default to conform to the ISO C++17 standard. If the only reason you implement operator **new** and **delete** is to support over-aligned allocations, you may no longer need this code in C++17 mode. To turn this option off and revert to the C++14 behavior of **new** and **delete** when **/std::c++17** or **/std:c++latest** is specified, specify **/Zc:alignedNew-**. If you implement operator **new** and **delete** but you are not ready to implement the over-aligned operator **new** and **delete** overloads that have the `align_val_t` parameter, use the **/Zc:alignedNew-** option to prevent the compiler and Standard Library from generating calls to the over-aligned overloads. The [/permissive-](permissive-standards-conformance.md) option does not change the default setting of **/Zc:alignedNew**.
19+
The **/Zc:alignedNew** option is only available when [/std:c++17](std-specify-language-standard-version.md) or [/std:c++latest](std-specify-language-standard-version.md) is enabled. Under **/std:c++17** or **/std:c++latest**, **/Zc:alignedNew** is enabled by default to conform to the ISO C++17 standard. If the only reason you implement operator **new** and **delete** is to support over-aligned allocations, you may no longer need this code in C++17 mode. To turn off this option and revert to the C++14 behavior of **new** and **delete** when you use **/std::c++17** or **/std:c++latest**, specify **/Zc:alignedNew-**. If you implement operator **new** and **delete** but you're not ready to implement the over-aligned operator **new** and **delete** overloads that have the `align_val_t` parameter, use the **/Zc:alignedNew-** option to prevent the compiler and Standard Library from generating calls to the over-aligned overloads. The [/permissive-](permissive-standards-conformance.md) option doesn't change the default setting of **/Zc:alignedNew**.
20+
21+
Support for **/Zc:alignedNew** is available starting in Visual Studio 2017 version 15.5.
2022

2123
## Example
2224

‎docs/cpp/trivial-standard-layout-and-pod-types.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ ms.assetid: 2b23a7be-9bad-49fc-8298-31a9a7c556b0
55
---
66
# Trivial, standard-layout, POD, and literal types
77

8-
The term *layout* refers to how the members of an object of class, struct or union type are arranged in memory. In some cases, the layout is well-defined by the language specification. But when a class or struct contains certain C++ language features such as virtual base classes, virtual functions, members with different access control, then the compiler is free to choose a layout. That layout may vary depending on what optimizations are being performed and in many cases object might not even occupy a contiguous area of memory. For example, if a class has virtual functions, all the instances of that class might share a single virtual function table. Such types are of course very useful, but they also have limitations. Because the layout is undefined they cannot be passed to programs written in other languages, such as C, and because they might be non-contiguous they cannot be reliably copied with fast low-level functions such as `memcopy` or serialized over a network.
8+
The term *layout* refers to how the members of an object of class, struct or union type are arranged in memory. In some cases, the layout is well-defined by the language specification. But when a class or struct contains certain C++ language features such as virtual base classes, virtual functions, members with different access control, then the compiler is free to choose a layout. That layout may vary depending on what optimizations are being performed and in many cases the object might not even occupy a contiguous area of memory. For example, if a class has virtual functions, all the instances of that class might share a single virtual function table. Such types are very useful, but they also have limitations. Because the layout is undefined they cannot be passed to programs written in other languages, such as C, and because they might be non-contiguous they cannot be reliably copied with fast low-level functions such as `memcopy`, or serialized over a network.
99

1010
To enable compilers as well as C++ programs and metaprograms to reason about the suitability of any given type for operations that depend on a particular memory layout, C++14 introduced three categories of simple classes and structs: *trivial*, *standard-layout*, and *POD* or Plain Old Data. The Standard Library has the function templates `is_trivial<T>`, `is_standard_layout<T>` and `is_pod<T>` that determine whether a given type belongs to a given category.
1111

‎docs/overview/2017/cpp-conformance-improvements-2017.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -64,7 +64,7 @@ New syntax to enable only a single namespace identifier in an attribute list. Fo
6464

6565
### Structured bindings
6666

67-
It is now possible in a single declaration to store a value with individual names for its components, when the value is an array, a std::tuple or std::pair, or has all public non-static data members. For more information, see [Structured Bindings](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0144r0.pdf) and [Returning multiple values from a function](../../cpp/functions-cpp.md#multi_val).
67+
It is now possible in a single declaration to store a value with individual names for its components, when the value is an array, a `std::tuple` or `std::pair`, or has all public non-static data members. For more information, see [Structured Bindings](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0144r0.pdf) and [Returning multiple values from a function](../../cpp/functions-cpp.md#multi_val).
6868

6969
### Construction rules for enum class values
7070

‎docs/overview/2017/what-s-new-for-visual-cpp-in-visual-studio.md‎

Lines changed: 0 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -10,8 +10,6 @@ ms.author: "mblome"
1010

1111
Visual Studio 2017 brings many updates and fixes to the C++ environment. We've fixed over 250 bugs and reported issues in the compiler and tools, many submitted by customers through the [Report a Problem and Provide a Suggestion](/visualstudio/how-to-report-a-problem-with-visual-studio-2017) options under **Send Feedback**. Thank you for reporting bugs! For more information on what's new in all of Visual Studio, please visit [What's new in Visual Studio 2017](/visualstudio/ide/whats-new-in-visual-studio).
1212

13-
<!--The compiler and tools version number in Visual Studio 2017 is 14.10.24629. -->
14-
1513
## C++ compiler
1614

1715
### C++ conformance improvements

0 commit comments

Comments
 (0)