diff --git a/docs/atl/reference/category-macros.md b/docs/atl/reference/category-macros.md index ecb6b7b4a5..2520af5960 100644 --- a/docs/atl/reference/category-macros.md +++ b/docs/atl/reference/category-macros.md @@ -2,7 +2,7 @@ description: "Learn more about: Category Macros" title: "Category Macros" ms.date: "11/04/2016" -f1_keywords: ["atlcom/ATL::BEGIN_CATEGORY_MAP", "atlcom/ATL::END_CATEGORY_MAP", "atlcom/ATL::IMPLEMENTED_CATEGORY", "atlcom/ATL::REQUIRED_CATEGORY"] +f1_keywords: ["ATLCOM/BEGIN_CATEGORY_MAP", "ATLCOM/END_CATEGORY_MAP", "ATLCOM/IMPLEMENTED_CATEGORY", "ATLCOM/REQUIRED_CATEGORY", "atlcom/ATL::BEGIN_CATEGORY_MAP", "atlcom/ATL::END_CATEGORY_MAP", "atlcom/ATL::IMPLEMENTED_CATEGORY", "atlcom/ATL::REQUIRED_CATEGORY"] ms.assetid: 223578cb-6180-4787-a8d8-ba3787a5d3ee --- # Category Macros diff --git a/docs/atl/reference/com-map-macros.md b/docs/atl/reference/com-map-macros.md index cb755491ea..6734604721 100644 --- a/docs/atl/reference/com-map-macros.md +++ b/docs/atl/reference/com-map-macros.md @@ -2,7 +2,7 @@ description: "Learn more about: COM Map Macros" title: "COM Map Macros" ms.date: "11/04/2016" -f1_keywords: ["atlcom/ATL::BEGIN_COM_MAP", "atlcom/ATL::END_COM_MAP"] +f1_keywords: ["atlcom/ATL::BEGIN_COM_MAP", "atlcom/ATL::END_COM_MAP", "ATLCOM/BEGIN_COM_MAP", "ATLCOM/END_COM_MAP"] helpviewer_keywords: ["COM interfaces, COM map macros"] ms.assetid: 0f33656d-321f-4996-90cc-9a7f21ab73c3 --- diff --git a/docs/atl/reference/composite-control-macros.md b/docs/atl/reference/composite-control-macros.md index 2d9e4e9fee..9721f16031 100644 --- a/docs/atl/reference/composite-control-macros.md +++ b/docs/atl/reference/composite-control-macros.md @@ -2,7 +2,7 @@ description: "Learn more about: Composite Control Macros" title: "Composite Control Macros" ms.date: "05/06/2019" -f1_keywords: ["atlcom/ATL::BEGIN_SINK_MAP", "atlcom/ATL::END_SINK_MAP", "atlcom/ATL::SINK_ENTRY"] +f1_keywords: ["atlcom/ATL::BEGIN_SINK_MAP", "atlcom/ATL::END_SINK_MAP", "atlcom/ATL::SINK_ENTRY", "ATLCOM/BEGIN_SINK_MAP", "ATLCOM/END_SINK_MAP", "ATLCOM/SINK_ENTRY", "ATLCOM/SINK_ENTRY_EX", "ATLCOM/SINK_ENTRY_EX_P", "ATLCOM/SINK_ENTRY_INFO", "ATLCOM/SINK_ENTRY_INFO_P", "BEGIN_SINK_MAP", "END_SINK_MAP", "SINK_ENTRY", "SINK_ENTRY_EX", "SINK_ENTRY_EX_P", "SINK_ENTRY_INFO", "SINK_ENTRY_INFO_P"] helpviewer_keywords: ["composite controls, macros"] ms.assetid: 17f2dd5e-07e6-4aa6-b965-7a361c78c45e --- @@ -15,7 +15,7 @@ These macros define event sink maps and entries. |[BEGIN_SINK_MAP](#begin_sink_map)|Marks the beginning of the event sink map for the composite control.| |[END_SINK_MAP](#end_sink_map)|Marks the end of the event sink map for the composite control.| |[SINK_ENTRY](#sink_entry)|Entry to the event sink map.| -|[SINK_ENTRY_EX](#sink_entry_ex)|Entry to the event sink map with an additional parameter.| +|[SINK_ENTRY_EX](#sink_entry_ex)|Entry to the event sink map with an extra parameter.| |[SINK_ENTRY_EX_P](#sink_entry_ex)| (Visual Studio 2017) Similar to SINK_ENTRY_EX except that it takes a pointer to iid.| |[SINK_ENTRY_INFO](#sink_entry_info)|Entry to the event sink map with manually supplied type information for use with [IDispEventSimpleImpl](../../atl/reference/idispeventsimpleimpl-class.md).| |[SINK_ENTRY_INFO_P](#sink_entry_info)| (Visual Studio 2017) Similar to SINK_ENTRY_INFO except that it takes a pointer to iid.| @@ -43,7 +43,7 @@ BEGIN_SINK_MAP(_class) ### Remarks -CE ATL implementation of ActiveX event sinks only supports return values of type HRESULT or void from your event handler methods; any other return value is unsupported and its behavior is undefined. +CE ATL implementation of ActiveX event sinks only supports return values of type HRESULT or void from your event handler methods. Any other return value is unsupported and its behavior is undefined. ## END_SINK_MAP @@ -59,7 +59,7 @@ END_SINK_MAP() ### Remarks -CE ATL implementation of ActiveX event sinks only supports return values of type HRESULT or void from your event handler methods; any other return value is unsupported and its behavior is undefined. +CE ATL implementation of ActiveX event sinks only supports return values of type HRESULT or void from your event handler methods. Any other return value is unsupported and its behavior is undefined. ## SINK_ENTRY @@ -86,7 +86,7 @@ SINK_ENTRY( id, dispid, fn ) ### Remarks -CE ATL implementation of ActiveX event sinks only supports return values of type HRESULT or void from your event handler methods; any other return value is unsupported and its behavior is undefined. +CE ATL implementation of ActiveX event sinks only supports return values of type HRESULT or void from your event handler methods. Any other return value is unsupported and its behavior is undefined. ## SINK_ENTRY_EX and SINK_ENTRY_EX_P @@ -120,7 +120,7 @@ SINK_ENTRY_EX_P( id, piid, dispid, fn ) // (Visual Studio 2017) ### Remarks -CE ATL implementation of ActiveX event sinks only supports return values of type HRESULT or void from your event handler methods; any other return value is unsupported and its behavior is undefined. +CE ATL implementation of ActiveX event sinks only supports return values of type HRESULT or void from your event handler methods. Any other return value is unsupported and its behavior is undefined. ## SINK_ENTRY_INFO and SINK_ENTRY_INFO_P @@ -153,7 +153,7 @@ SINK_ENTRY_INFO_P( id, piid, dispid, fn, info ) // (Visual Studio 2017) ### Remarks -The first four macro parameters are the same as those for the [SINK_ENTRY_EX](#sink_entry_ex) macro. The final parameter provides type information for the event. CE ATL implementation of ActiveX event sinks only supports return values of type HRESULT or void from your event handler methods; any other return value is unsupported and its behavior is undefined. +The first four macro parameters are the same as the ones for the [SINK_ENTRY_EX](#sink_entry_ex) macro. The final parameter provides type information for the event. CE ATL implementation of ActiveX event sinks only supports return values of type HRESULT or void from your event handler methods. Any other return value is unsupported and its behavior is undefined. ## See also diff --git a/docs/atl/reference/connection-point-macros.md b/docs/atl/reference/connection-point-macros.md index 5fb40db7d0..490abb2c38 100644 --- a/docs/atl/reference/connection-point-macros.md +++ b/docs/atl/reference/connection-point-macros.md @@ -2,7 +2,7 @@ description: "Learn more about: Connection Point Macros" title: "Connection Point Macros" ms.date: "11/04/2016" -f1_keywords: ["atlcom/ATL::BEGIN_CONNECTION_POINT_MAP", "atlcom/ATL::END_CONNECTION_POINT_MAP"] +f1_keywords: ["atlcom/ATL::BEGIN_CONNECTION_POINT_MAP", "atlcom/ATL::END_CONNECTION_POINT_MAP", "ATLCOM/BEGIN_CONNECTION_POINT_MAP", "ATLCOM/END_CONNECTION_POINT_MAP", "ATLCOM/CONNECTION_POINT_ENTRY", "ATLCOM/CONNECTION_POINT_ENTRY_P", "BEGIN_CONNECTION_POINT_MAP", "END_CONNECTION_POINT_MAP", "CONNECTION_POINT_ENTRY", "CONNECTION_POINT_ENTRY_P"] helpviewer_keywords: ["connection points [C++], macros"] ms.assetid: cc3a6dd3-5538-45df-b027-1f34963c31e5 --- diff --git a/docs/atl/reference/debugging-and-error-reporting-macros.md b/docs/atl/reference/debugging-and-error-reporting-macros.md index 59543bc784..463ef4c007 100644 --- a/docs/atl/reference/debugging-and-error-reporting-macros.md +++ b/docs/atl/reference/debugging-and-error-reporting-macros.md @@ -2,7 +2,7 @@ description: "Learn more about: Debugging and Error Reporting Macros" title: "Debugging and Error Reporting Macros" ms.date: "05/06/2019" -f1_keywords: ["atldef/ATL::_ATL_DEBUG_INTERFACES", "atldef/ATL::_ATL_DEBUG_QI", "atldef/ATL::ATLASSERT", "afx/ATL::ATLENSURE", "atltrace/ATL::ATLTRACENOTIMPL", "atltrace/ATL::ATLTRACE"] +f1_keywords: ["atldef/ATL::_ATL_DEBUG_INTERFACES", "atldef/ATL::_ATL_DEBUG_QI", "atldef/ATL::ATLASSERT", "afx/ATL::ATLENSURE", "atltrace/ATL::ATLTRACENOTIMPL", "atltrace/ATL::ATLTRACE", "ATLDEF/_ATL_DEBUG_INTERFACES", "ATLDEF/_ATL_DEBUG_QI", "ATLDEF/ATLASSERT", "AFX/ATLENSURE", "ATLTRACE/ATLTRACENOTIMPL", "ATLTRACE/ATLTRACE", "ATLDEF/ATLSTATIC_ASSERT"] helpviewer_keywords: ["macros, error reporting"] ms.assetid: 4da9b87f-ec5c-4a32-ab93-637780909b9d --- diff --git a/docs/atl/reference/exception-handling-macros.md b/docs/atl/reference/exception-handling-macros.md index b68a348f62..44f9993452 100644 --- a/docs/atl/reference/exception-handling-macros.md +++ b/docs/atl/reference/exception-handling-macros.md @@ -2,7 +2,7 @@ description: "Learn more about: Exception Handling Macros" title: "Exception Handling Macros" ms.date: "11/04/2016" -f1_keywords: ["atldef/ATL::_ATLCATCH", "atldef/ATL::_ATLCATCHALL", "atldef/ATL::_ATLTRY"] +f1_keywords: ["atldef/ATL::_ATLCATCH", "atldef/ATL::_ATLCATCHALL", "atldef/ATL::_ATLTRY", "ATLDEF/_ATLCATCH", "ATLDEF/_ATLCATCHALL", "ATLDEF/_ATLTRY"] helpviewer_keywords: ["exception handling, macros", "C++ exception handling, macros"] ms.assetid: a8385d34-3fb0-4006-a42a-de045cacf0f4 --- diff --git a/docs/atl/reference/message-map-macros-atl.md b/docs/atl/reference/message-map-macros-atl.md index 5752c16d10..99775caee5 100644 --- a/docs/atl/reference/message-map-macros-atl.md +++ b/docs/atl/reference/message-map-macros-atl.md @@ -2,7 +2,7 @@ description: "Learn more about: Message Map Macros (ATL)" title: "Message Map Macros (ATL)" ms.date: "11/04/2016" -f1_keywords: ["atlwin/ATL::ALT_MSG_MAP", "atlwin/ATL::BEGIN_MSG_MAP", "atlwin/ATL::CHAIN_MSG_MAP_ALT", "atlwin/ATL::CHAIN_MSG_MAP_ALT_MEMBER", "atlwin/ATL::CHAIN_MSG_MAP", "atlwin/ATL::CHAIN_MSG_MAP_DYNAMIC", "atlwin/ATL::CHAIN_MSG_MAP_MEMBER", "atlwin/ATL::COMMAND_CODE_HANDLER", "atlwin/ATL::COMMAND_HANDLER", "atlwin/ATL::COMMAND_ID_HANDLER", "atlwin/ATL::COMMAND_RANGE_CODE_HANDLER", "atlwin/ATL::COMMAND_RANGE_HANDLER", "atlwin/ATL::DECLARE_EMPTY_MSG_MAP", "atlwin/ATL::DEFAULT_REFLECTION_HANDLER", "atlwin/ATL::END_MSG_MAP", "atlwin/ATL::FORWARD_NOTIFICATIONS", "atlwin/ATL::MESSAGE_HANDLER", "atlwin/ATL::MESSAGE_RANGE_HANDLER", "atlwin/ATL::NOTIFY_CODE_HANDLER", "atlwin/ATL::NOTIFY_HANDLER", "atlwin/ATL::NOTIFY_ID_HANDLER", "atlwin/ATL::NOTIFY_RANGE_CODE_HANDLER", "atlwin/ATL::NOTIFY_RANGE_HANDLER", "atlwin/ATL::REFLECT_NOTIFICATIONS", "atlwin/ATL::REFLECTED_COMMAND_CODE_HANDLER", "atlwin/ATL::REFLECTED_COMMAND_HANDLER", "atlwin/ATL::REFLECTED_COMMAND_ID_HANDLER", "atlwin/ATL::REFLECTED_COMMAND_RANGE_CODE_HANDLER", "atlwin/ATL::REFLECTED_COMMAND_RANGE_HANDLER", "atlwin/ATL::REFLECTED_NOTIFY_CODE_HANDLER", "atlwin/ATL::REFLECTED_NOTIFY_HANDLER", "atlwin/ATL::REFLECTED_NOTIFY_ID_HANDLER", "atlwin/ATL::REFLECTED_NOTIFY_RANGE_CODE_HANDLER", "atlwin/ATL::REFLECTED_NOTIFY_RANGE_HANDLER"] +f1_keywords: ["atlwin/ATL::ALT_MSG_MAP", "atlwin/ATL::BEGIN_MSG_MAP", "atlwin/ATL::CHAIN_MSG_MAP_ALT", "atlwin/ATL::CHAIN_MSG_MAP_ALT_MEMBER", "atlwin/ATL::CHAIN_MSG_MAP", "atlwin/ATL::CHAIN_MSG_MAP_DYNAMIC", "atlwin/ATL::CHAIN_MSG_MAP_MEMBER", "atlwin/ATL::COMMAND_CODE_HANDLER", "atlwin/ATL::COMMAND_HANDLER", "atlwin/ATL::COMMAND_ID_HANDLER", "atlwin/ATL::COMMAND_RANGE_CODE_HANDLER", "atlwin/ATL::COMMAND_RANGE_HANDLER", "atlwin/ATL::DECLARE_EMPTY_MSG_MAP", "atlwin/ATL::DEFAULT_REFLECTION_HANDLER", "atlwin/ATL::END_MSG_MAP", "atlwin/ATL::FORWARD_NOTIFICATIONS", "atlwin/ATL::MESSAGE_HANDLER", "atlwin/ATL::MESSAGE_RANGE_HANDLER", "atlwin/ATL::NOTIFY_CODE_HANDLER", "atlwin/ATL::NOTIFY_HANDLER", "atlwin/ATL::NOTIFY_ID_HANDLER", "atlwin/ATL::NOTIFY_RANGE_CODE_HANDLER", "atlwin/ATL::NOTIFY_RANGE_HANDLER", "atlwin/ATL::REFLECT_NOTIFICATIONS", "atlwin/ATL::REFLECTED_COMMAND_CODE_HANDLER", "atlwin/ATL::REFLECTED_COMMAND_HANDLER", "atlwin/ATL::REFLECTED_COMMAND_ID_HANDLER", "atlwin/ATL::REFLECTED_COMMAND_RANGE_CODE_HANDLER", "atlwin/ATL::REFLECTED_COMMAND_RANGE_HANDLER", "atlwin/ATL::REFLECTED_NOTIFY_CODE_HANDLER", "atlwin/ATL::REFLECTED_NOTIFY_HANDLER", "atlwin/ATL::REFLECTED_NOTIFY_ID_HANDLER", "atlwin/ATL::REFLECTED_NOTIFY_RANGE_CODE_HANDLER", "atlwin/ATL::REFLECTED_NOTIFY_RANGE_HANDLER", "ATLWIN/ALT_MSG_MAP", "ATLWIN/BEGIN_MSG_MAP", "ATLWIN/CHAIN_MSG_MAP_ALT", "ATLWIN/CHAIN_MSG_MAP_ALT_MEMBER", "ATLWIN/CHAIN_MSG_MAP", "ATLWIN/CHAIN_MSG_MAP_DYNAMIC", "ATLWIN/CHAIN_MSG_MAP_MEMBER", "ATLWIN/COMMAND_CODE_HANDLER", "ATLWIN/COMMAND_HANDLER", "ATLWIN/COMMAND_ID_HANDLER", "ATLWIN/COMMAND_RANGE_CODE_HANDLER", "ATLWIN/COMMAND_RANGE_HANDLER", "ATLWIN/DECLARE_EMPTY_MSG_MAP", "ATLWIN/DEFAULT_REFLECTION_HANDLER", "ATLWIN/END_MSG_MAP", "ATLWIN/FORWARD_NOTIFICATIONS", "ATLWIN/MESSAGE_HANDLER", "ATLWIN/MESSAGE_RANGE_HANDLER", "ATLWIN/NOTIFY_CODE_HANDLER", "ATLWIN/NOTIFY_HANDLER", "ATLWIN/NOTIFY_ID_HANDLER", "ATLWIN/NOTIFY_RANGE_CODE_HANDLER", "ATLWIN/NOTIFY_RANGE_HANDLER", "ATLWIN/REFLECT_NOTIFICATIONS", "ATLWIN/REFLECTED_COMMAND_CODE_HANDLER", "ATLWIN/REFLECTED_COMMAND_HANDLER", "ATLWIN/REFLECTED_COMMAND_ID_HANDLER", "ATLWIN/REFLECTED_COMMAND_RANGE_CODE_HANDLER", "ATLWIN/REFLECTED_COMMAND_RANGE_HANDLER", "ATLWIN/REFLECTED_NOTIFY_CODE_HANDLER", "ATLWIN/REFLECTED_NOTIFY_HANDLER", "ATLWIN/REFLECTED_NOTIFY_ID_HANDLER", "ATLWIN/REFLECTED_NOTIFY_RANGE_CODE_HANDLER", "ATLWIN/REFLECTED_NOTIFY_RANGE_HANDLER"] ms.assetid: eefdd546-8934-4a30-b263-9c06a8addcbd --- # Message Map Macros (ATL) diff --git a/docs/atl/reference/object-map-macros.md b/docs/atl/reference/object-map-macros.md index c9ebdbdbbe..e0d53e8236 100644 --- a/docs/atl/reference/object-map-macros.md +++ b/docs/atl/reference/object-map-macros.md @@ -2,7 +2,7 @@ description: "Learn more about: Object Map Macros" title: "Object Map Macros" ms.date: "11/04/2016" -f1_keywords: ["atlcom/ATL::DECLARE_OBJECT_DESCRIPTION", "atlcom/ATL::OBJECT_ENTRY_AUTO", "atlcom/ATL::OBJECT_ENTRY_NON_CREATEABLE_EX_AUTO"] +f1_keywords: ["atlcom/ATL::DECLARE_OBJECT_DESCRIPTION", "atlcom/ATL::OBJECT_ENTRY_AUTO", "atlcom/ATL::OBJECT_ENTRY_NON_CREATEABLE_EX_AUTO", "ATLCOM/DECLARE_OBJECT_DESCRIPTION", "ATLCOM/OBJECT_ENTRY_AUTO", "ATLCOM/OBJECT_ENTRY_NON_CREATEABLE_EX_AUTO"] ms.assetid: 680087f4-9894-41dd-a79c-6f337e1f13c1 --- # Object Map Macros diff --git a/docs/atl/reference/object-status-macros.md b/docs/atl/reference/object-status-macros.md index 81f8189659..06a9bdb39f 100644 --- a/docs/atl/reference/object-status-macros.md +++ b/docs/atl/reference/object-status-macros.md @@ -2,7 +2,7 @@ description: "Learn more about: Object Status Macros" title: "Object Status Macros" ms.date: "11/04/2016" -f1_keywords: ["atlcom/ATL::DECLARE_OLEMISC_STATUS"] +f1_keywords: ["atlcom/ATL::DECLARE_OLEMISC_STATUS", "ATLCOM/DECLARE_OLEMISC_STATUS"] ms.assetid: 727dbef2-a342-4157-9d64-a421805d9747 --- # Object Status Macros diff --git a/docs/atl/reference/property-map-macros.md b/docs/atl/reference/property-map-macros.md index 038b525d2f..a871dd49ab 100644 --- a/docs/atl/reference/property-map-macros.md +++ b/docs/atl/reference/property-map-macros.md @@ -2,7 +2,7 @@ description: "Learn more about: Property Map Macros" title: "Property Map Macros" ms.date: "11/04/2016" -f1_keywords: ["atlcom/ATL::BEGIN_PROP_MAP", "atlcom/ATL::PROP_DATA_ENTRY", "atlcom/ATL::PROP_ENTRY_TYPE", "atlcom/ATL::PROP_ENTRY_TYPE_EX", "atlcom/ATL::PROP_PAGE", "atlcom/ATL::END_PROP_MAP"] +f1_keywords: ["atlcom/ATL::BEGIN_PROP_MAP", "atlcom/ATL::PROP_DATA_ENTRY", "atlcom/ATL::PROP_ENTRY_TYPE", "atlcom/ATL::PROP_ENTRY_TYPE_EX", "atlcom/ATL::PROP_PAGE", "atlcom/ATL::END_PROP_MAP", "ATLCOM/BEGIN_PROP_MAP", "ATLCOM/PROP_DATA_ENTRY", "ATLCOM/PROP_ENTRY_TYPE", "ATLCOM/PROP_ENTRY_TYPE_EX", "ATLCOM/PROP_PAGE", "ATLCOM/END_PROP_MAP"] helpviewer_keywords: ["property maps"] ms.assetid: 128bc742-2b98-4b97-a243-684dbb83db77 --- diff --git a/docs/atl/reference/registry-data-exchange-macros.md b/docs/atl/reference/registry-data-exchange-macros.md index 06dce60c45..98857707a3 100644 --- a/docs/atl/reference/registry-data-exchange-macros.md +++ b/docs/atl/reference/registry-data-exchange-macros.md @@ -2,7 +2,7 @@ description: "Learn more about: Registry Data Exchange Macros" title: "Registry Data Exchange Macros" ms.date: "11/04/2016" -f1_keywords: ["atlplus/ATL::BEGIN_RDX_MAP", "atlplus/ATL::END_RDX_MAP", "atlplus/ATL::RDX_BINARY", "atlplus/ATL::RDX_CSTRING_TEXT", "atlplus/ATL::RDX_DWORD", "atlplus/ATL::RDX_TEXT"] +f1_keywords: ["atlplus/ATL::BEGIN_RDX_MAP", "atlplus/ATL::END_RDX_MAP", "atlplus/ATL::RDX_BINARY", "atlplus/ATL::RDX_CSTRING_TEXT", "atlplus/ATL::RDX_DWORD", "atlplus/ATL::RDX_TEXT", "ATLPLUS/BEGIN_RDX_MAP", "ATLPLUS/END_RDX_MAP", "ATLPLUS/RDX_BINARY", "ATLPLUS/RDX_CSTRING_TEXT", "ATLPLUS/RDX_DWORD", "ATLPLUS/RDX_TEXT"] helpviewer_keywords: ["RegistryDataExchange function, macros"] ms.assetid: c1bc5e79-2307-43d2-9d10-3a62ffadf473 --- diff --git a/docs/atl/reference/registry-macros.md b/docs/atl/reference/registry-macros.md index 930c43fb1a..f18617f0fe 100644 --- a/docs/atl/reference/registry-macros.md +++ b/docs/atl/reference/registry-macros.md @@ -2,7 +2,7 @@ description: "Learn more about: Registry Macros" title: "Registry Macros" ms.date: "08/19/2019" -f1_keywords: ["atlcom/ATL::_ATL_STATIC_REGISTRY", "atlcom/ATL::DECLARE_LIBID", "atlcom/ATL::DECLARE_NO_REGISTRY", "atlcom/ATL::DECLARE_REGISTRY", "atlcom/ATL::DECLARE_REGISTRY_APPID_RESOURCEID", "atlcom/ATL::DECLARE_REGISTRY_RESOURCE", "atlcom/ATL::DECLARE_REGISTRY_RESOURCEID"] +f1_keywords: ["ATLBASE/_ATL_STATIC_REGISTRY", "ATLBASE/DECLARE_LIBID", "ATLBASE/DECLARE_NO_REGISTRY", "ATLBASE/DECLARE_REGISTRY", "ATLBASE/DECLARE_REGISTRY_APPID_RESOURCEID", "ATLBASE/DECLARE_REGISTRY_RESOURCE", "ATLBASE/DECLARE_REGISTRY_RESOURCEID", "_ATL_STATIC_REGISTRY", "DECLARE_LIBID", "DECLARE_NO_REGISTRY", "DECLARE_REGISTRY", "DECLARE_REGISTRY_APPID_RESOURCEID", "DECLARE_REGISTRY_RESOURCE", "DECLARE_REGISTRY_RESOURCEID"] helpviewer_keywords: ["registry, ATL macros"] ms.assetid: 3ee041da-c63b-42a4-89cf-2a4b2a6f81ae --- diff --git a/docs/atl/reference/service-map-macros.md b/docs/atl/reference/service-map-macros.md index 76906d95cc..b42010306a 100644 --- a/docs/atl/reference/service-map-macros.md +++ b/docs/atl/reference/service-map-macros.md @@ -2,7 +2,7 @@ description: "Learn more about: Service Map Macros" title: "Service Map Macros" ms.date: "11/04/2016" -f1_keywords: ["atlcom/ATL::BEGIN_SERVICE_MAP", "atlcom/ATL::END_SERVICE_MAP", "atlcom/ATL::SERVICE_ENTRY", "atlcom/ATL::SERVICE_ENTRY_CHAIN"] +f1_keywords: ["atlcom/ATL::BEGIN_SERVICE_MAP", "atlcom/ATL::END_SERVICE_MAP", "atlcom/ATL::SERVICE_ENTRY", "atlcom/ATL::SERVICE_ENTRY_CHAIN", "ATLCOM/BEGIN_SERVICE_MAP", "ATLCOM/END_SERVICE_MAP", "ATLCOM/SERVICE_ENTRY", "ATLCOM/SERVICE_ENTRY_CHAIN"] ms.assetid: ca02a125-454a-4cf6-aac2-1c5585025ed4 --- # Service Map Macros @@ -115,7 +115,7 @@ STDMETHOD(QueryService)( ### Return Value -The returned HRESULT value is one of the following: +The returned HRESULT is one of the following values: |Return value|Meaning| |------------------|-------------| @@ -123,23 +123,23 @@ The returned HRESULT value is one of the following: |E_INVALIDARG|One or more of the arguments is invalid.| |E_OUTOFMEMORY|Memory is insufficient to create the service.| |E_UNEXPECTED|An unknown error occurred.| -|E_NOINTERFACE|The requested interface is not part of this service, or the service is unknown.| +|E_NOINTERFACE|The requested interface isn't part of this service, or the service is unknown.| ### Remarks -`QueryService` returns an indirect pointer to the requested interface in the specified service. The caller is responsible for releasing this pointer when it is no longer required. +`QueryService` returns an indirect pointer to the requested interface in the specified service. The caller is responsible for releasing this pointer when it's no longer required. When you call `QueryService`, you pass both a service identifier (*guidService*) and an interface identifier (*riid*). The *guidService* specifies the service to which you want access, and the *riid* identifies an interface that is part of the service. In return, you receive an indirect pointer to the interface. -The object that implements the interface might also implement interfaces that are part of other services. Consider the following: +The object that implements the interface might also implement interfaces that are part of other services. Consider the following possibilities: - Some of these interfaces might be optional. Not all interfaces defined in the service description are necessarily present on every implementation of the service or on every returned object. -- Unlike calls to `QueryInterface`, passing a different service identifier does not necessarily mean that a different Component Object Model (COM) object is returned. +- Unlike calls to `QueryInterface`, passing a different service identifier doesn't necessarily mean that a different Component Object Model (COM) object is returned. -- The returned object might have additional interfaces that are not part of the definition of the service. +- The returned object might have other interfaces that aren't part of the definition of the service. -Two different services, such as SID_SMyService and SID_SYourService, can both specify the use of the same interface, even though the implementation of the interface might have nothing in common between the two services. This works, because a call to `QueryService` (SID_SMyService, IID_IDispatch) can return a different object than `QueryService` (SID_SYourService, IID_IDispatch). Object identity is not assumed when you specify a different service identifier. +Two different services, such as SID_SMyService and SID_SYourService, can both specify the use of the same interface, even though the implementation of the interface might have nothing in common between the two services. This approach works, because a call to `QueryService` (SID_SMyService, IID_IDispatch) can return a different object than `QueryService` (SID_SYourService, IID_IDispatch). Object identity isn't assumed when you specify a different service identifier. ## See also diff --git a/docs/atl/reference/snap-in-object-macros.md b/docs/atl/reference/snap-in-object-macros.md index 434f4d34ca..380f4cf116 100644 --- a/docs/atl/reference/snap-in-object-macros.md +++ b/docs/atl/reference/snap-in-object-macros.md @@ -2,7 +2,7 @@ description: "Learn more about: Snap-In Object Macros" title: "Snap-In Object Macros" ms.date: "11/04/2016" -f1_keywords: ["atlsnap/ATL::BEGIN_EXTENSION_SNAPIN_NODEINFO_MAP", "atlsnap/ATL::BEGIN_SNAPINTOOLBARID_MAP", "atlsnap/ATL::END_EXTENSION_SNAPIN_NODEINFO_MAP", "atlsnap/ATL::END_SNAPINTOOLBARID_MAP", "atlsnap/ATL::EXTENSION_SNAPIN_DATACLASS", "atlsnap/ATL::EXTENSION_SNAPIN_NODEINFO_ENTRY", "atlsnap/ATL::SNAPINMENUID", "atlsnap/ATL::SNAPINTOOLBARID_ENTRY"] +f1_keywords: ["atlsnap/ATL::BEGIN_EXTENSION_SNAPIN_NODEINFO_MAP", "atlsnap/ATL::BEGIN_SNAPINTOOLBARID_MAP", "atlsnap/ATL::END_EXTENSION_SNAPIN_NODEINFO_MAP", "atlsnap/ATL::END_SNAPINTOOLBARID_MAP", "atlsnap/ATL::EXTENSION_SNAPIN_DATACLASS", "atlsnap/ATL::EXTENSION_SNAPIN_NODEINFO_ENTRY", "atlsnap/ATL::SNAPINMENUID", "atlsnap/ATL::SNAPINTOOLBARID_ENTRY", "ATLSNAP/BEGIN_EXTENSION_SNAPIN_NODEINFO_MAP", "ATLSNAP/BEGIN_SNAPINTOOLBARID_MAP", "ATLSNAP/END_EXTENSION_SNAPIN_NODEINFO_MAP", "ATLSNAP/END_SNAPINTOOLBARID_MAP", "ATLSNAP/EXTENSION_SNAPIN_DATACLASS", "ATLSNAP/EXTENSION_SNAPIN_NODEINFO_ENTRY", "ATLSNAP/SNAPINMENUID", "ATLSNAP/SNAPINTOOLBARID_ENTRY"] ms.assetid: 4e9850c0-e395-4929-86c9-584a81828053 --- # Snap-In Object Macros diff --git a/docs/atl/reference/string-conversion-macros.md b/docs/atl/reference/string-conversion-macros.md index 9930172187..9b67e45e5f 100644 --- a/docs/atl/reference/string-conversion-macros.md +++ b/docs/atl/reference/string-conversion-macros.md @@ -2,7 +2,7 @@ description: "Learn more about: String Conversion Macros" title: "String Conversion Macros" ms.date: "11/04/2016" -f1_keywords: ["atlconv/ATL::DEVMODEA2W", "atlconv/ATL::TEXTMETRICA2W", "atlconv/ATL::DEVMODEOLE2T", "atlconv/ATL::TEXTMETRICOLE2T", "atlconv/ATL::DEVMODET2OLE", "atlconv/ATL::TEXTMETRICT2OLE", "atlconv/ATL::DEVMODEW2A", "atlconv/ATL::TEXTMETRICW2A"] +f1_keywords: ["atlconv/ATL::DEVMODEA2W", "atlconv/ATL::TEXTMETRICA2W", "atlconv/ATL::DEVMODEOLE2T", "atlconv/ATL::TEXTMETRICOLE2T", "atlconv/ATL::DEVMODET2OLE", "atlconv/ATL::TEXTMETRICT2OLE", "atlconv/ATL::DEVMODEW2A", "atlconv/ATL::TEXTMETRICW2A", "ATLCONV/DEVMODEA2W", "ATLCONV/TEXTMETRICA2W", "ATLCONV/DEVMODEOLE2T", "ATLCONV/TEXTMETRICOLE2T", "ATLCONV/DEVMODET2OLE", "ATLCONV/TEXTMETRICT2OLE", "ATLCONV/DEVMODEW2A", "ATLCONV/TEXTMETRICW2A"] ms.assetid: 2ff7c0b6-2bde-45fe-897f-6128e18e0c27 --- # String Conversion Macros diff --git a/docs/atl/reference/window-class-macros.md b/docs/atl/reference/window-class-macros.md index 1e0a546539..4804e4b723 100644 --- a/docs/atl/reference/window-class-macros.md +++ b/docs/atl/reference/window-class-macros.md @@ -2,7 +2,7 @@ description: "Learn more about: Window Class Macros" title: "Window Class Macros" ms.date: "11/04/2016" -f1_keywords: ["atlwin/ATL::DECLARE_WND_CLASS", "atlwin/ATL::DECLARE_WND_SUPERCLASS", "atlwin/ATL::DECLARE_WND_CLASS_EX"] +f1_keywords: ["atlwin/ATL::DECLARE_WND_CLASS", "atlwin/ATL::DECLARE_WND_SUPERCLASS", "atlwin/ATL::DECLARE_WND_CLASS_EX", "ATLWIN/DECLARE_WND_CLASS", "ATLWIN/DECLARE_WND_SUPERCLASS", "ATLWIN/DECLARE_WND_CLASS_EX"] ms.assetid: ce18681a-2bab-4453-9895-0f3ea47c2b24 --- # Window Class Macros diff --git a/docs/atl/reference/windows-messages-macros.md b/docs/atl/reference/windows-messages-macros.md index 3bcec790e6..0675305320 100644 --- a/docs/atl/reference/windows-messages-macros.md +++ b/docs/atl/reference/windows-messages-macros.md @@ -2,7 +2,7 @@ description: "Learn more about: Windows Messages Macros" title: "Windows Messages Macros" ms.date: "11/04/2016" -f1_keywords: ["atlbase/ATL::WM_FORWARDMSG"] +f1_keywords: ["atlbase/ATL::WM_FORWARDMSG", "ATLBASE/WM_FORWARDMSG"] ms.assetid: 63abd22c-372d-4148-bb04-c605950ae64f --- # Windows Messages Macros diff --git a/docs/build/reference/headername.md b/docs/build/reference/headername.md index 25bb89d596..3082639be6 100644 --- a/docs/build/reference/headername.md +++ b/docs/build/reference/headername.md @@ -1,7 +1,7 @@ --- title: "/headerName (Build a header unit from the specified header)" description: "Use the /headerName compiler option to establish a mapping between a header file and the header unit to build." -ms.date: 04/13/2021 +ms.date: 04/21/2022 author: "tylermsft" ms.author: "twhitney" f1_keywords: ["/headerName"] @@ -39,7 +39,7 @@ Given a project that references a header file it defines called `m.h`, the compi cl /std:c++latest /exportHeader /headerName:quote m.h /Fom.h.obj ``` -The `/headerName:{quote,angle}` option acts like a flag and does not explicitly need an argument. The following examples are valid: +The `/headerName:{quote,angle}` option acts like a flag and doesn't need an argument. The following examples are valid: ```Bash cl /std:c++latest /exportHeader /headerName:angle /MP /Fo.\ vector iostream algorithm @@ -68,6 +68,6 @@ cl /std:c++latest /exportHeader /headerName:angle /MP /Fo.\ vector iostream algo ## See also [`/exportHeader` (Create header units)](module-exportheader.md)\ -[`/headerUnit` (Create header units)](headerunit.md)\ +[`/headerUnit` (Use header unit IFC)](headerunit.md)\ [`/reference` (Use named module IFC)](module-reference.md)\ [`/translateInclude` (Translate include directives into import directives)](translateinclude.md) diff --git a/docs/build/toc.yml b/docs/build/toc.yml index 84bff49e66..ae2e11b2a8 100644 --- a/docs/build/toc.yml +++ b/docs/build/toc.yml @@ -308,10 +308,10 @@ items: href: ../build/how-to-enable-a-64-bit-visual-cpp-toolset-on-the-command-line.md - name: Common MSVC 64-bit migration issues href: ../build/common-visual-cpp-64-bit-migration-issues.md - - name: x64 software conventions + - name: x64 ABI conventions expanded: false items: - - name: x64 software conventions + - name: Overview of x64 ABI conventions href: ../build/x64-software-conventions.md - name: x64 calling convention href: ../build/x64-calling-convention.md @@ -705,7 +705,7 @@ items: href: ../build/reference/rtc-run-time-error-checks.md - name: /scanDependencies (List module dependencies in standard form) href: ../build/reference/scandependencies.md - - name: /sdl (Enable additional security checks) + - name: /sdl (Enable more security checks) href: ../build/reference/sdl-enable-additional-security-checks.md - name: /showIncludes (List include files) href: ../build/reference/showincludes-list-include-files.md @@ -1123,10 +1123,10 @@ items: href: ../build/reference/error-handling-and-notification.md - name: Understand the delay load helper function href: ../build/reference/understanding-the-helper-function.md - - name: Additional MSVC build tools + - name: Other MSVC build tools expanded: false items: - - name: Additional MSVC build tools + - name: Other MSVC build tools href: ../build/reference/c-cpp-build-tools.md - name: NMAKE reference expanded: false diff --git a/docs/build/x64-calling-convention.md b/docs/build/x64-calling-convention.md index f410bbead9..2b6f213619 100644 --- a/docs/build/x64-calling-convention.md +++ b/docs/build/x64-calling-convention.md @@ -1,8 +1,7 @@ --- title: "x64 calling convention" -description: "Details of the default x64 calling convention." -ms.date: "07/06/2020" -ms.assetid: 41ca3554-b2e3-4868-9a84-f1b46e6e21d9 +description: "Learn about the details of the default x64 calling convention." +ms.date: 04/21/2022 --- # x64 calling convention @@ -16,13 +15,13 @@ There's a strict one-to-one correspondence between a function call's arguments a The x87 register stack is unused. It may be used by the callee, but consider it volatile across function calls. All floating point operations are done using the 16 XMM registers. -Integer arguments are passed in registers RCX, RDX, R8, and R9. Floating point arguments are passed in XMM0L, XMM1L, XMM2L, and XMM3L. 16-byte arguments are passed by reference. Parameter passing is described in detail in [Parameter passing](#parameter-passing). These registers, and RAX, R10, R11, XMM4, and XMM5, are considered volatile. Register usage is documented in detail in [Register usage](../build/x64-software-conventions.md#register-usage) and [Caller/callee saved registers](#callercallee-saved-registers). +Integer arguments are passed in registers RCX, RDX, R8, and R9. Floating point arguments are passed in XMM0L, XMM1L, XMM2L, and XMM3L. 16-byte arguments are passed by reference. Parameter passing is described in detail in [Parameter passing](#parameter-passing). These registers, and RAX, R10, R11, XMM4, and XMM5, are considered volatile. Register usage is documented in detail in [x64 register usage](x64-software-conventions.md#x64-register-usage) and [Caller/callee saved registers](#callercallee-saved-registers). For prototyped functions, all arguments are converted to the expected callee types before passing. The caller is responsible for allocating space for the callee's parameters. The caller must always allocate sufficient space to store four register parameters, even if the callee doesn't take that many parameters. This convention simplifies support for unprototyped C-language functions and vararg C/C++ functions. For vararg or unprototyped functions, any floating point values must be duplicated in the corresponding general-purpose register. Any parameters beyond the first four must be stored on the stack after the shadow store before the call. Vararg function details can be found in [Varargs](#varargs). Unprototyped function information is detailed in [Unprototyped functions](#unprototyped-functions). ## Alignment -Most structures are aligned to their natural alignment. The primary exceptions are the stack pointer and `malloc` or `alloca` memory, which are 16-byte aligned to aid performance. Alignment above 16 bytes must be done manually. Since 16 bytes is a common alignment size for XMM operations, this value should work for most code. For more information about structure layout and alignment, see [Types and Storage](../build/x64-software-conventions.md#types-and-storage). For information about the stack layout, see [x64 stack usage](../build/stack-usage.md). +Most structures are aligned to their natural alignment. The primary exceptions are the stack pointer and `malloc` or `alloca` memory, which are 16-byte aligned to aid performance. Alignment above 16 bytes must be done manually. Since 16 bytes is a common alignment size for XMM operations, this value should work for most code. For more information about structure layout and alignment, see [x64 type and storage layout](x64-software-conventions.md#x64-type-and-storage-layout). For information about the stack layout, see [x64 stack usage](../build/stack-usage.md). ## Unwindability diff --git a/docs/build/x64-software-conventions.md b/docs/build/x64-software-conventions.md index 48fb2b2292..d1136eff59 100644 --- a/docs/build/x64-software-conventions.md +++ b/docs/build/x64-software-conventions.md @@ -1,43 +1,44 @@ --- -description: "Learn more about: x64 software conventions" -title: "x64 software conventions" -ms.date: "12/17/2018" -helpviewer_keywords: ["x64 coding conventions", "Visual C++, x64 calling conventions"] -ms.assetid: 750f3d97-1706-4840-b2fc-41a007329a08 +description: "Learn more about: x64 ABI conventions" +title: "x64 ABI conventions" +ms.date: 04/21/2022 +helpviewer_keywords: ["x64 coding conventions", "x64 abi", "Visual C++, x64 calling conventions"] --- -# x64 software conventions +# Overview of x64 ABI conventions -This section describes the C++ calling convention methodology for x64, the 64-bit extension to the x86 architecture. +This topic describes the basic application binary interface (ABI) for x64, the 64-bit extension to the x86 architecture. It covers topics such as the calling convention, type layout, stack and register usage, and more. -## Overview of x64 calling conventions +## x64 calling conventions -Two important differences between x86 and x64 are the 64-bit addressing capability and a flat set of 16 64-bit registers for general use. Given the expanded register set, x64 uses the [__fastcall](../cpp/fastcall.md) calling convention and a RISC-based exception-handling model. The **`__fastcall`** convention uses registers for the first four arguments and the stack frame to pass additional arguments. For details on the x64 calling convention, including register usage, stack parameters, return values, and stack unwinding, see [x64 calling convention](x64-calling-convention.md). +Two important differences between x86 and x64 are: +- 64-bit addressing capability +- Sixteen 64-bit registers for general use. -## Enable optimization for x64 +Given the expanded register set, x64 uses the [__fastcall](../cpp/fastcall.md) calling convention and a RISC-based exception-handling model. + +The **`__fastcall`** convention uses registers for the first four arguments, and the stack frame to pass more arguments. For details on the x64 calling convention, including register usage, stack parameters, return values, and stack unwinding, see [x64 calling convention](x64-calling-convention.md). + +## Enable x64 compiler optimization The following compiler option helps you optimize your application for x64: - [/favor (Optimize for Architecture Specifics)](../build/reference/favor-optimize-for-architecture-specifics.md) -## Types and storage +## x64 type and storage layout -This section describes the enumeration and storage of data types for the x64 architecture. +This section describes the storage of data types for the x64 architecture. ### Scalar types -Although it's possible to access data with any alignment, it's recommended to align data on its natural boundary, or some multiple, to avoid performance loss. Enums are constant integers and are treated as 32-bit integers. The following table describes the type definition and recommended storage for data as it pertains to alignment using the following alignment values: +Although it's possible to access data with any alignment, align data on its natural boundary, or a multiple of its natural boundary, to avoid performance loss. Enums are constant integers and are treated as 32-bit integers. The following table describes the type definition and recommended storage for data as it pertains to alignment using the following alignment values: - Byte - 8 bits - - Word - 16 bits - - Doubleword - 32 bits - - Quadword - 64 bits - - Octaword - 128 bits -|Scalar Type|C Data Type|Storage Size (in bytes)|Recommended Alignment| +|Scalar type|C data type|Storage size (in bytes)|Recommended alignment| |-|-|-|-| |**`INT8`**|**`char`**|1|Byte| |**`UINT8`**|**`unsigned char`**|1|Byte| @@ -53,7 +54,7 @@ Although it's possible to access data with any alignment, it's recommended to al |**`__m64`**|**`struct __m64`**|8|Quadword| |**`__m128`**|**`struct __m128`**|16|Octaword| -### Aggregates and unions +### x64 aggregate and union layout Other types, such as arrays, structs, and unions, have stricter alignment requirements that ensure consistent aggregate and union storage and data retrieval. Here are the definitions for array, structure, and union: @@ -63,13 +64,13 @@ Other types, such as arrays, structs, and unions, have stricter alignment requir - Structure - Contains an ordered group of data objects. Unlike the elements of an array, the data objects within a structure can have different data types and sizes. Each data object in a structure is called a *member*. + Contains an ordered group of data objects. Unlike the elements of an array, the members of a structure can have different data types and sizes. - Union An object that holds any one of a set of named members. The members of the named set can be of any type. The storage allocated for a union is equal to the storage required for the largest member of that union, plus any padding required for alignment. -The following table shows the strongly suggested alignment for the scalar members of unions and structures. +The following table shows the strongly recommended alignment for the scalar members of unions and structures. |Scalar Type|C Data Type|Required Alignment| |-|-|-| @@ -95,11 +96,11 @@ The following aggregate alignment rules apply: - Structure size must be an integral multiple of its alignment, which may require padding after the last member. Since structures and unions can be grouped in arrays, each array element of a structure or union must begin and end at the proper alignment previously determined. -- It is possible to align data in such a way as to be greater than the alignment requirements as long as the previous rules are maintained. +- It's possible to align data in such a way as to be greater than the alignment requirements as long as the previous rules are maintained. -- An individual compiler may adjust the packing of a structure for size reasons. For example [/Zp (Struct Member Alignment)](../build/reference/zp-struct-member-alignment.md) allows for adjusting the packing of structures. +- An individual compiler may adjust the packing of a structure for size reasons. For example, [/Zp (Struct Member Alignment)](../build/reference/zp-struct-member-alignment.md) allows for adjusting the packing of structures. -### Examples of Structure Alignment +### x64 structure alignment examples The following four examples each declare an aligned structure or union, and the corresponding figures illustrate the layout of that structure or union in memory. Each column in a figure represents a byte of memory, and the number in the column indicates the displacement of that byte. The name in the second row of each figure corresponds to the name of a variable in the declaration. The shaded columns indicate padding that is required to achieve the specified alignment. @@ -160,21 +161,21 @@ _declspec(align(8)) union { ### Bitfields -Structure bit fields are limited to 64 bits and can be of type signed int, unsigned int, int64, or unsigned int64. Bit fields that cross the type boundary will skip bits to align the bitfield to the next type alignment. For example, integer bitfields may not cross a 32-bit boundry. +Structure bit fields are limited to 64 bits and can be of type signed int, unsigned int, int64, or unsigned int64. Bit fields that cross the type boundary will skip bits to align the bitfield to the next type alignment. For example, integer bitfields may not cross a 32-bit boundary. ### Conflicts with the x86 compiler -Data types that are larger than 4 bytes are not automatically aligned on the stack when you use the x86 compiler to compile an application. Because the architecture for the x86 compiler is a 4 byte aligned stack, anything larger than 4 bytes, for example, a 64-bit integer, cannot be automatically aligned to an 8-byte address. +Data types that are larger than 4 bytes aren't automatically aligned on the stack when you use the x86 compiler to compile an application. Because the architecture for the x86 compiler is a 4 byte aligned stack, anything larger than 4 bytes, for example, a 64-bit integer, can't be automatically aligned to an 8-byte address. Working with unaligned data has two implications. - It may take longer to access unaligned locations than it takes to access aligned locations. -- Unaligned locations cannot be used in interlocked operations. +- Unaligned locations can't be used in interlocked operations. If you require more strict alignment, use `__declspec(align(N))` on your variable declarations. This causes the compiler to dynamically align the stack to meet your specifications. However, dynamically adjusting the stack at run time may cause slower execution of your application. -## Register usage +## x64 register usage The x64 architecture provides for 16 general-purpose registers (hereafter referred to as integer registers) as well as 16 XMM/YMM registers available for floating-point use. Volatile registers are scratch registers presumed by the caller to be destroyed across a call. Nonvolatile registers are required to retain their values across a function call and must be saved by the callee if used. @@ -220,11 +221,11 @@ For information on the conventions and data structures used to implement structu ## Intrinsics and inline assembly -One of the constraints for the x64 compiler is to have no inline assembler support. This means that functions that cannot be written in C or C++ will either have to be written as subroutines or as intrinsic functions supported by the compiler. Certain functions are performance sensitive while others are not. Performance-sensitive functions should be implemented as intrinsic functions. +One of the constraints for the x64 compiler is no inline assembler support. This means that functions that can't be written in C or C++ will either have to be written as subroutines or as intrinsic functions supported by the compiler. Certain functions are performance sensitive while others aren't. Performance-sensitive functions should be implemented as intrinsic functions. -The intrinsics supported by the compiler are described in [Compiler Intrinsics](../intrinsics/compiler-intrinsics.md). +The intrinsics supported by the compiler are described in [Compiler intrinsics](../intrinsics/compiler-intrinsics.md). -## Image format +## x64 image format The x64 executable image format is PE32+. Executable images (both DLLs and EXEs) are restricted to a maximum size of 2 gigabytes, so relative addressing with a 32-bit displacement can be used to address static image data. This data includes the import address table, string constants, static global data, and so on. diff --git a/docs/cpp/align-cpp.md b/docs/cpp/align-cpp.md index b54bddaf18..3f3a3411d6 100644 --- a/docs/cpp/align-cpp.md +++ b/docs/cpp/align-cpp.md @@ -4,9 +4,8 @@ title: "align (C++)" ms.date: "12/17/2018" f1_keywords: ["align_cpp"] helpviewer_keywords: ["align __declspec keyword", "__declspec keyword [C++], align"] -ms.assetid: 9cb63f58-658b-4425-ac47-af8eabfc5878 --- -# align (C++) +# `align` (C++) In Visual Studio 2015 and later, use the C++11 standard **`alignas`** specifier to control alignment. For more information, see [Alignment](../cpp/alignment-cpp-declarations.md). @@ -20,7 +19,7 @@ Use `__declspec(align(#))` to precisely control the alignment of user-defined da ## Remarks -Writing applications that use the latest processor instructions introduces some new constraints and issues. Many new instructions require data that's aligned to 16-byte boundaries. Additionally, by aligning frequently used data to the processor's cache line size, you improve cache performance. For example, if you define a structure whose size is less than 32 bytes, you may want 32 byte alignment to make sure that objects of that structure type are efficiently cached. +Writing applications that use the latest processor instructions introduces some new constraints and issues. Many new instructions require data that's aligned to 16-byte boundaries. Aligning frequently used data to the processor's cache line size improves cache performance. For example, if you define a structure whose size is less than 32 bytes, you may want 32-byte alignment to make sure that objects of that structure type are efficiently cached. \# is the alignment value. Valid entries are integer powers of two from 1 to 8192 (bytes), such as 2, 4, 8, 16, 32, or 64. `declarator` is the data that you're declaring as aligned. @@ -42,7 +41,7 @@ __declspec(align(32)) struct Str1{ }; ``` -This type now has a 32-byte alignment attribute. It means that all static and automatic instances start on a 32-byte boundary. Additional structure types declared with this type as a member preserve this type's alignment attribute, that is, any structure with `Str1` as an element has an alignment attribute of at least 32. +This type now has a 32-byte alignment attribute. It means that all static and automatic instances start on a 32-byte boundary. Other structure types declared with this type as a member preserve this type's alignment attribute. That is, any structure with `Str1` as an element has an alignment attribute of at least 32. Here, `sizeof(struct Str1)` is equal to 32. It implies that if an array of `Str1` objects is created, and the base of the array is 32-byte aligned, each member of the array is also 32-byte aligned. To create an array whose base is correctly aligned in dynamic memory, use [`_aligned_malloc`](../c-runtime-library/reference/aligned-malloc.md). Or, write your own allocator. @@ -63,16 +62,12 @@ The compiler uses these rules for structure alignment: For more information, see: - [`align` Examples](#vclrfalignexamples) - - [Defining New Types with `__declspec(align(#))`](#vclrf_declspecaligntypedef) - - [Aligning Data in Thread Local Storage](#vclrfthreadlocalstorageallocation) - - [How `align` Works with Data Packing](#vclrfhowalignworkswithdatapacking) +- [x64 structure alignment examples](../build/x64-software-conventions.md#x64-structure-alignment-examples) -- [Examples of Structure Alignment](../build/x64-software-conventions.md#examples-of-structure-alignment) (x64 specific) - -## align Examples +## `align` Examples The following examples show how `__declspec(align(#))` affects the size and alignment of data structures. The examples assume the following definitions: @@ -150,7 +145,7 @@ struct S7 { `S6` and `S7` have identical alignment, allocation, and size characteristics. -In this example, the alignment of the starting addresses of a, b, c, and d are 4, 1, 4, and 1, respectively. +In this example, the alignment of the starting addresses of `a`, `b`, `c`, and `d` are 4, 1, 4, and 1, respectively. ```cpp void fn() { @@ -161,7 +156,7 @@ void fn() { } ``` -The alignment when memory is allocated on the heap depends on which allocation function is called. For example, if you use `malloc`, the result depends on the operand size. If *arg* >= 8, the memory returned is 8 byte aligned. If *arg* < 8, the alignment of the memory returned is the first power of 2 less than *arg*. For example, if you use `malloc(7)`, the alignment is 4 bytes. +The alignment when memory is allocated on the heap depends on which allocation function is called. For example, if you use `malloc`, the result depends on the operand size. If *arg* >= 8, the memory returned is 8-byte aligned. If *arg* < 8, the alignment of the memory returned is the first power of 2 less than *arg*. For example, if you use `malloc(7)`, the alignment is 4 bytes. ## Defining new types with `__declspec(align(#))` diff --git a/docs/cpp/alignof-operator.md b/docs/cpp/alignof-operator.md index 3dab06ff18..85de366870 100644 --- a/docs/cpp/alignof-operator.md +++ b/docs/cpp/alignof-operator.md @@ -4,9 +4,8 @@ title: "alignof Operator" ms.date: "12/17/2018" f1_keywords: ["__alignof_cpp", "alignof_cpp", "__alignof", "_alignof"] helpviewer_keywords: ["alignas [C++]", "alignment of structures", "__alignof keyword [C++]", "alignof [C++]", "types [C++], alignment requirements"] -ms.assetid: acb1eed7-6398-40bd-b0c5-684ceb64afbc --- -# alignof Operator +# `alignof` operator The **`alignof`** operator returns the alignment in bytes of the specified type as a value of type **`size_t`**. @@ -56,15 +55,11 @@ S* p = (S*)aligned_malloc(n * sizeof(S), alignof(S)); For more information on modifying alignment, see: -- [pack](../preprocessor/pack.md) - -- [align](../cpp/align-cpp.md) - -- [__unaligned](../cpp/unaligned.md) - -- [/Zp (Struct Member Alignment)](../build/reference/zp-struct-member-alignment.md) - -- [Examples of Structure Alignment](../build/x64-software-conventions.md#examples-of-structure-alignment) (x64 specific) +- [`pack`](../preprocessor/pack.md) +- [`align`](../cpp/align-cpp.md) +- [`__unaligned`](../cpp/unaligned.md) +- [`/Zp` (Struct member alignment)](../build/reference/zp-struct-member-alignment.md) +- [x64 structure alignment examples](../build/x64-software-conventions.md#x64-structure-alignment-examples) For more information on differences in alignment in code for x86 and x64, see: @@ -78,5 +73,5 @@ For compatibility with previous versions, **`_alignof`** is a synonym for **`__a ## See also -[Expressions with Unary Operators](../cpp/expressions-with-unary-operators.md)
+[Expressions with Unary Operators](../cpp/expressions-with-unary-operators.md)\ [Keywords](../cpp/keywords-cpp.md) diff --git a/docs/cpp/for-statement-cpp.md b/docs/cpp/for-statement-cpp.md index c2f73186fe..b331d9227e 100644 --- a/docs/cpp/for-statement-cpp.md +++ b/docs/cpp/for-statement-cpp.md @@ -1,14 +1,14 @@ --- title: "for statement (C++)" description: "Reference to the Standard C++ for statement in Microsoft Visual Studio C++." -f1_keywords: ["for_cpp"] -ms.date: 07/31/2020 +f1_keywords: ["for_CPP"] +ms.date: 04/15/2022 helpviewer_keywords: ["for keyword [C++]"] ms.assetid: 6c7d01b3-c4c1-4c6a-aa58-e2d198f33d4a --- # `for` statement (C++) -Executes a statement repeatedly until the condition becomes false. For information on the range-based **`for`** statement, see [Range-based `for` statement (C++)](../cpp/range-based-for-statement-cpp.md). +Executes a statement repeatedly until the condition becomes false. For information on the range-based **`for`** statement, see [Range-based `for` statement (C++)](../cpp/range-based-for-statement-cpp.md). For information on the C++/CLI **`for each`** statement, see [`for each`, `in`](../dotnet/for-each-in.md). ## Syntax @@ -68,10 +68,11 @@ int main(){ cout << "i + j = " << (i + j) << '\n'; } } - // Output: +/* Output: i + j = 15 i + j = 17 i + j = 19 +*/ ``` *`loop-expression`* can be incremented or decremented, or modified in other ways. @@ -88,7 +89,8 @@ for (int i = 10; i > 0; i--) { for (int i = 10; i < 20; i = i+2) { cout << i << ' '; } - // Output: 10 12 14 16 18 +} +// Output: 10 12 14 16 18 ``` A **`for`** loop terminates when a [`break`](../cpp/break-statement-cpp.md), [return](../cpp/return-statement-cpp.md), or [`goto`](../cpp/goto-statement-cpp.md) (to a labeled statement outside the **`for`** loop) within *`statement`* is executed. A [`continue`](../cpp/continue-statement-cpp.md) statement in a **`for`** loop terminates only the current iteration. @@ -121,9 +123,9 @@ for (int i = 0 ; i < 5 ; i++) { // i is now out of scope under /Za or /Zc:forScope ``` -By default, under [/Ze](../build/reference/za-ze-disable-language-extensions.md), a variable declared in a **`for`** loop remains in scope until the **`for`** loop's enclosing scope ends. +By default, under [`/Ze`](../build/reference/za-ze-disable-language-extensions.md), a variable declared in a **`for`** loop remains in scope until the **`for`** loop's enclosing scope ends. -[/Zc:forScope](../build/reference/zc-forscope-force-conformance-in-for-loop-scope.md) enables standard behavior of variables declared in for loops without needing to specify `/Za`. +[`/Zc:forScope`](../build/reference/zc-forscope-force-conformance-in-for-loop-scope.md) enables standard behavior of variables declared in for loops without needing to specify `/Za`. It's also possible to use the scoping differences of the **`for`** loop to redeclare variables under `/Ze` as follows: @@ -141,8 +143,8 @@ This behavior more closely mimics the standard behavior of a variable declared i ## See also -[Iteration statements](../cpp/iteration-statements-cpp.md)
-[Keywords](../cpp/keywords-cpp.md)
-[while statement (C++)](../cpp/while-statement-cpp.md)
-[do-while statement (C++)](../cpp/do-while-statement-cpp.md)
-[Range-based for statement (C++)](../cpp/range-based-for-statement-cpp.md) +[Iteration statements](../cpp/iteration-statements-cpp.md)\ +[Keywords](../cpp/keywords-cpp.md)\ +[`while` statement (C++)](../cpp/while-statement-cpp.md)\ +[`do-while` statement (C++)](../cpp/do-while-statement-cpp.md)\ +[Range-based `for` statement (C++)](../cpp/range-based-for-statement-cpp.md) diff --git a/docs/cpp/unaligned.md b/docs/cpp/unaligned.md index dca6404c9e..ab25505fd0 100644 --- a/docs/cpp/unaligned.md +++ b/docs/cpp/unaligned.md @@ -4,31 +4,26 @@ title: "__unaligned" ms.date: "12/17/2018" f1_keywords: ["__unaligned_cpp", "__unaligned", "_unaligned"] helpviewer_keywords: ["__unaligned keyword [C++]"] -ms.assetid: 0cd83aad-1840-47e3-ad33-59bfcbe6375b --- -# __unaligned +# `__unaligned` -**Microsoft-specific**. When you declare a pointer with the **`__unaligned`** modifier, the compiler assumes that the pointer addresses data that is not aligned. Consequently, platform-appropriate code is generated to handle unaligned reads and writes through the pointer. +**Microsoft-specific**. When you declare a pointer with the **`__unaligned`** modifier, the compiler assumes that the pointer addresses data that isn't aligned. So, platform-appropriate code is generated to handle unaligned reads and writes through the pointer. ## Remarks -This modifier describes the alignment of the data addressed by the pointer; the pointer itself is assumed to be aligned. +This modifier describes the alignment of the data addressed by the pointer. It is assumed that the pointer itself is aligned. -The necessity for the **`__unaligned`** keyword varies by platform and environment. Failure to mark data appropriately can result in issues ranging from performance penalties to hardware faults. The **`__unaligned`** modifier is not valid for the x86 platform. +The necessity for the **`__unaligned`** keyword varies by platform and environment. Failure to mark data appropriately can result in issues ranging from performance penalties to hardware faults. The **`__unaligned`** modifier isn't valid for the x86 platform. For compatibility with previous versions, **`_unaligned`** is a synonym for **`__unaligned`** unless compiler option [`/Za` \(Disable language extensions)](../build/reference/za-ze-disable-language-extensions.md) is specified. For more information about alignment, see: - [`align`](../cpp/align-cpp.md) - - [`alignof` Operator](../cpp/alignof-operator.md) - - [`pack`](../preprocessor/pack.md) - - [`/Zp` (Struct Member Alignment)](../build/reference/zp-struct-member-alignment.md) - -- [Examples of Structure Alignment](../build/x64-software-conventions.md#examples-of-structure-alignment) +- [x64 structure alignment examples](../build/x64-software-conventions.md#x64-structure-alignment-examples) ## See also diff --git a/docs/docfx.json b/docs/docfx.json index 3802eb1e63..11e30e03f9 100644 --- a/docs/docfx.json +++ b/docs/docfx.json @@ -45,12 +45,13 @@ "ms.topic": "conceptual", "audience": "developer", "ms.prod": "visual-cpp", - "ms.tgt_pltfrm": "", + "ms.tgt_pltfrm": "Windows", "ms.workload": [ "cplusplus" ], "dev_langs": [ - "C++" + "C++", + "cpp" ], "searchScope": [ "C++" diff --git a/docs/dotnet/for-each-in.md b/docs/dotnet/for-each-in.md index 9d7743eed0..0d805f1c48 100644 --- a/docs/dotnet/for-each-in.md +++ b/docs/dotnet/for-each-in.md @@ -1,13 +1,13 @@ --- title: "for each, in" description: "C++/CLI for each, in statement description and examples." -ms.date: 09/25/2020 +ms.date: 04/15/2022 ms.topic: "reference" -f1_keywords: ["cliext::foreach", "for", "each", "in"] +f1_keywords: ["cliext::foreach", "each_CPP", "in_CPP", "for each_CPP", "for each", "in"] helpviewer_keywords: ["for each keyword [C++]"] ms.assetid: 0c3a364b-2747-43f3-bb8d-b7d3b7023f79 --- -# for each, in +# `for each`, `in` Iterates through an array or collection. This non-standard keyword is available in both C++/CLI and native C++ projects. However, its use isn't recommended. Consider using a standard [Range-based for Statement (C++)](../cpp/range-based-for-statement-cpp.md) instead. @@ -15,29 +15,29 @@ Iterates through an array or collection. This non-standard keyword is available ### Syntax -> **for each (** *type* *identifier* **in** *expression* **) {**\ ->     *statements*\ -> **}** +> **`for each (`** *`type`* *`identifier`* **`in`** *`expression`* **`) {`**\ +>  *`statements`*\ +> **`}`** ### Parameters -*type*
+*`type`*\ The type of `identifier`. -*identifier*
+*`identifier`*\ The iteration variable that represents the collection element. When `identifier` is a [Tracking Reference Operator](../extensions/tracking-reference-operator-cpp-component-extensions.md), you can modify the element. -*expression*
+*`expression`*\ An array expression or collection. The collection element must be such that the compiler can convert it to the `identifier` type. -*statements*
+*`statements`*\ One or more statements to be executed. ### Remarks The `for each` statement is used to iterate through a collection. You can modify elements in a collection, but you can't add or delete elements. -The *statements* are executed for each element in the array or collection. After the iteration has been completed for all the elements in the collection, control is transferred to the statement that follows the `for each` block. +The *`statements`* are executed for each element in the array or collection. After the iteration has been completed for all the elements in the collection, control is transferred to the statement that follows the `for each` block. `for each` and `in` are [context-sensitive keywords](../extensions/context-sensitive-keywords-cpp-component-extensions.md). @@ -45,7 +45,7 @@ The *statements* are executed for each element in the array or collection. After ### Requirements -Compiler option: **/ZW** +Compiler option: **`/ZW`** ### Example @@ -89,14 +89,14 @@ Testing The CLR syntax is the same as the **All Runtimes** syntax, except as follows. -*expression*
-A managed array expression or collection. The collection element must be such that the compiler can convert it from to the *identifier* type. +*`expression`*\ +A managed array expression or collection. The collection element must be such that the compiler can convert it from to the *`identifier`* type. -*expression* evaluates to a type that implements , , or a type that defines a `GetEnumerator` method that either returns a type that implements or declares all of the methods that are defined in `IEnumerator`. +*`expression`* evaluates to a type that implements , , or a type that defines a `GetEnumerator` method that either returns a type that implements or declares all of the methods that are defined in `IEnumerator`. ### Requirements -Compiler option: **/clr** +Compiler option: **`/clr`** ### Example diff --git a/docs/preprocessor/pack.md b/docs/preprocessor/pack.md index e748047b17..cd667b9879 100644 --- a/docs/preprocessor/pack.md +++ b/docs/preprocessor/pack.md @@ -50,7 +50,7 @@ For more information about how to modify alignment, see these articles: - [`__unaligned`](../cpp/unaligned.md) -- [Examples of structure alignment](../build/x64-software-conventions.md#examples-of-structure-alignment) (x64 specific) +- [x64 structure alignment examples](../build/x64-software-conventions.md#x64-structure-alignment-examples) > [!WARNING] > In Visual Studio 2015 and later you can use the standard **`alignas`** and **`alignof`** operators, which unlike **`__alignof`** and **`__declspec( align )`** are portable across compilers. The C++ standard doesn't address packing, so you must still use **`pack`** (or the corresponding extension on other compilers) to specify alignments smaller than the target architecture's word size.