Merge pull request #44 from jonitis/fix_doc_typos

Fix doc typos
This commit is contained in:
Kenny Kerr 2016-11-23 08:50:04 -08:00 коммит произвёл GitHub
Родитель 4de91f9d14 b6f0b66c41
Коммит 3ead1e60ee
4 изменённых файлов: 18 добавлений и 18 удалений

Просмотреть файл

@ -33,7 +33,7 @@ The 'winrt' folder contains a header file for each WinRT namespace. The header f
Example: To use the C++/WinRT projection for the `Windows.Foundation.Collections.PropertySet` runtime class, you realize that the Windows Runtime defines it in the `Windows.Foundation.Collections` namespace. Therefore you include the respective header file by writing:
```C++
#include "winrt/Windows.Foundation.Collections.h"`.
#include "winrt/Windows.Foundation.Collections.h"
```
Every namespace header includes its parent
@ -44,7 +44,7 @@ It's common for types in a subordinate namespace to reference types in its immed
Lets walk through one example.
* The Universal API Contract defines types in the `Windows.Security.Cryptography.Certificates` namespace.
* The equivalent C++/WinRT type definitions reside in the `winrt\\Windows.Security.Cryptography.Certificates.h` header file.
* The equivalent C++/WinRT type definitions reside in the `winrt\Windows.Security.Cryptography.Certificates.h` header file.
* Types in the `Windows.Security.Cryptography.Certificates` namespace require types in the parent `Windows.Security.Cryptography` namespace.
* Additionally, types in that namespace could require types in its parent `Windows.Security` namespace, and so on.
@ -55,7 +55,7 @@ When you include `Windows.Security.Cryptography.Certificates.h`, it includes `Wi
Every namespace header includes its dependencies' declarations
--------------------------------------------------------------
Additionally, members of types in a namespace can reference one or more types in other, unrelated namespaces. In order for the compile to compile these member definitions successfully, the compiler needs to see the type declaractions for all the referenced types that reside in other, unrelated namespaces. You, however, don't need to worry about this. Each C++/WinRT header file will include the namespace headers it needs to *declare* any dependent types.
Additionally, members of types in a namespace can reference one or more types in other, unrelated namespaces. In order for the compiler to compile these member definitions successfully, the compiler needs to see the type declarations for all the referenced types that reside in other, unrelated namespaces. You, however, don't need to worry about this. Each C++/WinRT header file will include the namespace headers it needs to *declare* any dependent types.
However, note that this process does not pull in the *implementations* for referenced types that reside in another, unrelated namespace.

Просмотреть файл

@ -54,7 +54,7 @@ int main()
}
```
Even though the `GetAsyncInfo` function knowns nothing of the projected `IAsyncInfo` type used within the main function, capturing the resulting value is simple and reliable. It works equally well with other types like `winrt::hstring`:
Even though the `GetAsyncInfo` function knows nothing of the projected `IAsyncInfo` type used within the main function, capturing the resulting value is simple and reliable. It works equally well with other types like `winrt::hstring`:
```C++
HRESULT GetMessage(HSTRING * value);
@ -70,7 +70,7 @@ int main()
`winrt::attach` & `winrt::detach`
---------------
The `attach` function takes ownership of an ABI value. Assuming you have a value, such as a COM interface pointer that is not owned, you can use the `attach` function to given ownership of it to a C++/WinRT type. The `attach` function is complemented by the `detach` function that does the inverse. For example:
The `attach` function takes ownership of an ABI value. Assuming you have a value, such as a COM interface pointer that is not owned, you can use the `attach` function to give ownership of it to a C++/WinRT type. The `attach` function is complemented by the `detach` function that does the inverse. For example:
```C++
IAsyncInfo info = ...
@ -95,7 +95,7 @@ assert(message.size() == size);
`winrt::copy_to` & `winrt::copy_from`
-------------------
The `copy_to` and `copy_from` functions are similar to `attach` and `detach` except that they dont transfer ownership. Instead, they copy the underlying reference effectively calling `AddRef` or some equivalent. This is useful if you need to hold on to a reference but also need to return a reference-counted object to the caller. For example:
The `copy_to` and `copy_from` functions are similar to `attach` and `detach` except that they don't transfer ownership. Instead, they copy the underlying reference effectively calling `AddRef` or some equivalent. This is useful if you need to hold on to a reference but also need to return a reference-counted object to the caller. For example:
```C++
abi<IAsyncInfo> * ptr = ...

Просмотреть файл

@ -32,7 +32,7 @@ This is valid code but it's not as efficient as passing by const reference.
> Therefore, if all you do is simply remove the hat (\^) in the function declaration, you produce working, but unnecessarily slower code.
> Pass a C++/WinRT type by const reference avoids the copy, which eliminates the AddRef and Release calls.
> Passing a C++/WinRT type by const reference avoids the copy, which eliminates the AddRef and Release calls.
Variable and Field references
-----------------------------
@ -49,7 +49,7 @@ For example:
for (UINT32 iUser = 0; iUser < userList->Size; iUser++)
. . .
```
When converting to the equivalent C++/WinRT code, you basically remove the hats and change the arrow operator (-&gt;) to the dot operator (.). Our projected types are values and not pointers, therefore you deference them using the dot operator, not the arrow operator.
When converting to the equivalent C++/WinRT code, you basically remove the hats and change the arrow operator (-&gt;) to the dot operator (.). Our projected types are values and not pointers, therefore you dereference them using the dot operator, not the arrow operator.
For example, the equivalent to the preceding code is:
@ -65,7 +65,7 @@ For example, the equivalent to the preceding code is:
Properties
----------
The C++/CX Windows Runtime language extensions include the concept of properties. When writing C++/CX source code, you can properties of a Windows Runtime object as if it were a field. However standard C++ does not have the concept of a property. As a result, in C++/WinRT all calls to retrieve or set a Windows Runtime property translates to a call to the respective get or set method.
The C++/CX Windows Runtime language extensions include the concept of properties. When writing C++/CX source code, you can access properties of a Windows Runtime object as if it were a field. However standard C++ does not have the concept of a property. As a result, in C++/WinRT all calls to retrieve or set a Windows Runtime property translates to a call to the respective get or set method.
In the following, XboxUserId, UserState, PresenceDeviceRecords and Size are all properties.
@ -259,7 +259,7 @@ Here's another example where in C++/CX, we have a field of a class (m\_xboxLiveC
};
```
Subsequently, the field could subsequently by initialized like this:
Subsequently, the field could subsequently be initialized like this:
```C++
m_xboxLiveContext = ref new XboxLiveContext(m_user);
@ -322,7 +322,7 @@ Registering for events using a lambda
The C++/CX syntax for registering for an event notification is rather verbose. Here's an example:
```C++
User::SignInCompleted += ref new EventHandler<SignInCompletedEventArgs^> (
User::SignInCompleted += ref new EventHandler<SignInCompletedEventArgs^> (
[=] (Platform::Object^, SignInCompletedEventArgs^ args)
{
UpdateUsers();
@ -340,7 +340,7 @@ You can simplify it considerably when using C++/WinRT. Here's the equivalent. Yo
});
```
It's a big jump from the C++/CX example to the preceding C++/WinRT example so let's examime the example part by part.
It's a big jump from the C++/CX example to the preceding C++/WinRT example so let's examine the example part by part.
### The registration method
@ -368,7 +368,7 @@ With C++/WinRT, the compiler understands the type of the delegate parameter to t
```C++
( . . . );
```
Now we passed a lambda as the function that the C++/CX EventHandler encapsulates. So we needed to declared the signature of the lambda, which must match that expected by the SignInCompleted event:
Now we passed a lambda as the function that the C++/CX EventHandler encapsulates. So we needed to declare the signature of the lambda, which must match that expected by the SignInCompleted event:
```C++
[=] (Platform::Object^, SignInCompletedEventArgs^ args)
@ -443,7 +443,7 @@ Therefore, the C++/WinRT revocation call is:
Mapping C++/CX Platform types to C++/WinRT types
------------------------------------------------
The C++ Windows Runtime language extensions provides several C++/CX specific data types. These reside in the Platform namespace. When you disable Windows Runtime language extensions, you can't use the Platform types (as they aren't standard C++). Therefore, for each, we provide an equivalent type defined using standard C++.
The C++ Windows Runtime language extensions provide several C++/CX specific data types. These reside in the Platform namespace. When you disable Windows Runtime language extensions, you can't use the Platform types (as they aren't standard C++). Therefore, for each, we provide an equivalent type defined using standard C++.
| C++/CX | CX++/WinRT |
| ---- | ---- |
@ -455,7 +455,7 @@ The C++ Windows Runtime language extensions provides several C++/CX specific dat
`Platform::Object^` is the C++ Windows Runtime language extension type equivalent to the Windows Runtime IInspectable interface pointer. For C++/WinRT, the equivalent is `winrt::Windows::IInspectable`.
Like all C++/WinRT types, `winrt::Windows::IInspectable' is a value. Therefore, to declare a variable of that type to null, you write:
Like all C++/WinRT types, `winrt::Windows::IInspectable` is a value. Therefore, to declare a variable of that type to null, you write:
```C++
winrt::Windows::IInspectable var = nullptr;
@ -463,7 +463,7 @@ Like all C++/WinRT types, `winrt::Windows::IInspectable' is a value. Therefore,
### Platform::String\^
`Platform::String^` is the C++ Windows Runtime language extension type equivalent to the Windows Runtime HSTRING type. For C++/WiNRT, the equivalent is `winrt::hstring`.
`Platform::String^` is the C++ Windows Runtime language extension type equivalent to the Windows Runtime HSTRING type. For C++/WinRT, the equivalent is `winrt::hstring`.
However, you rarely need to define variables of type `winrt::hstring`. Generally, you can just use a C++ wide string type (i.e. std::wstring or a L"literal") and pass it directly to APIs that previously required a Platform::String.
@ -600,7 +600,7 @@ The only remaining change is the change of:
to
```C++
task<adapter>; const & resultTask
task<adapter> const & resultTask
```
Eliminating the hat and const reference changes, already discussed, we simply changed task&lt;XboxSocialRelationShipResult&gt; to task&lt;adapter&gt;.

Просмотреть файл

@ -1,7 +1,7 @@
Using standard C++ with C++/WinRT APIs
======================================
You use standard C++ data types, algorithms, and keywords when using the C++/WinRT projection of Windows Runtime APIs. This differs considerably from the C++/CX approach that requires you to learn and use its customs types, e.g. Platform::String\^, Platform::Vector\^ and others, custom keywords and syntax.
You use standard C++ data types, algorithms, and keywords when using the C++/WinRT projection of Windows Runtime APIs. This differs considerably from the C++/CX approach that requires you to learn and use its custom types, e.g. Platform::String\^, Platform::Vector\^ and others, custom keywords and syntax.
While C++/WinRT has its own custom data types, in most cases, you do not need to learn them as they provide appropriate conversions to/from standard C++ data types.