Updated v2_0_cpp_unpacker (markdown)

v2_0_cpp_unpacker.md

@@ -157,7 +157,7 @@ result = unpack(data, len); // since C++11
 ```
 
 
-If the buffer countains multiple msgpack data, use the following function:
+If the buffer contains multiple msgpack data, use the following function:
 
 ```C++
 object_handle result;
@@ -237,7 +237,7 @@ public:
 };
 ```
 
-The default limits are 0xffffffff. They are the maximum value of the msgpack format. Strigtly speaking, the limit of the depth is not defined by msgpack format.
+The default limits are 0xffffffff. They are the maximum value of the msgpack format. Strictly speaking, the limit of the depth is not defined by msgpack format.
 
 If the number of elements is over unpack_limit, unpack functions throw the following exceptions:
 
@@ -301,7 +301,7 @@ namespace type {
 }
 ```
 
-When msgpack unpacking object from a buffer, unpack_reference_func is called with 'type' as the unpacking type, 'length' as the payload size, and 'user_data' as the argument user_data  when you pass to msgpack::unpack(). You may get STR, BIN, and EXT as a type parameter. Other types are never appeared becaulse the msgpack::object that have other types are created by conversion. On the contrary, STR, BIN, and EXT's payloads can be used directly from msgpack::object.
+When msgpack unpacking object from a buffer, unpack_reference_func is called with 'type' as the unpacking type, 'length' as the payload size, and 'user_data' as the argument user_data  when you pass to msgpack::unpack(). You may get STR, BIN, and EXT as a type parameter. Other types are never appeared because the msgpack::object that have other types are created by conversion. On the contrary, STR, BIN, and EXT's payloads can be used directly from msgpack::object.
 
 'size' means a payload size. The payload size for STR and BIN, it is actual data size. For EXT, it is EXT's type and data size.
 
@@ -370,7 +370,7 @@ If referenced is true, msgpack::object refer to the buffer that is passed as the
 
 ## msgpack controls a buffer
 
-msgpack provides a buffer management functionality named msgpack::unpacker. msgpack::unpacker is sutable for the following motivations:
+msgpack provides a buffer management functionality named msgpack::unpacker. msgpack::unpacker is suitable for the following motivations:
 * msgpack data is chopped, and the client doesn't know when it will complete. This is a typical situation when you develop streaming applications.
 * You want to minimize copy operations without careful memory management.
 
@@ -442,7 +442,7 @@ inline bool unpacker::default_reference_func(type::object_type type, uint64_t le
 }
 ```
 
-You can also customize unpack_reference_func. Even if you use references, you don't need to control buffer's lifetime. The buffers' lifetime is controled by msgpack using msgpack::zone's finalizer_array and msgpack::unpacker's reference counting mechanism.
+You can also customize unpack_reference_func. Even if you use references, you don't need to control buffer's lifetime. The buffers' lifetime is controlled by msgpack using msgpack::zone's finalizer_array and msgpack::unpacker's reference counting mechanism.
 
 So, in most cases, the default behavior is enough. If you want to control the peak of memory consumption when receiving msgpack data patterns are predictable, customizing unpack_reference_func might be useful.
 
@@ -456,4 +456,4 @@ However, mostly you don't need to use that version of next() because referenced
 
 ![unpacker behavior](v2_0_fig_unpacker.png)
 
-If you want to know in detail about an internal mechanism, see [internal mechanism](http://www.slideshare.net/taka111/msgpackc), the slides were wrintten when ext support and unpack_reference_func was not implemented.
+If you want to know in detail about an internal mechanism, see [internal mechanism](http://www.slideshare.net/taka111/msgpackc), the slides were written when ext support and unpack_reference_func was not implemented.