Changing the stream to `std::hex` mode should only affect the current character; otherwise printing some msgpack with a list like this: `[123, "string\\u0003", 123]` (123 decimal) ends up printing `[123, "string\\u0003", 7b]`, as `std::hex` is sticky.
In the case the target type is char[] or const char[],
If the array is '\0' teminated, msgpack-c packs the characters before
'\0', otherwise packs all characters.
When converting, the array has the size that is greater than
msgpack::object STR's size, msgpack-c adds '\0' to just after converted
characters. Otherwise msgpack-c doesn't add '\0'.
MSVC CLI defined their own nullptr and provides for __nullptr for standard C++11.
https://msdn.microsoft.com/en-us/library/4ex65770.aspx
msgpack-c introduce MSGPACK_NULLPTR for internal use, it is defined as __nullptr only if compiled on C++ CLI otherwise defined as nullptr.
Added lacked include files.
Added a test.
Added MSVC build settings on appveyor.
Added old MSVC workaround.
Fixed a variable definition point to meet ANSI-C.
msgpack::unpacked is a typedef of the msgpack::object_handle.
I recommend using msgpack::object_handle. It can be used not only
holding unpacked msgpack objects but also msgpack::objects that are
created by any types.
Replaced unpack() APIs in test codes and examples. They used to use old
APIs.
Replaced the inheriting constructor with a forwarding constructor.
Removed the template constructors that are covered by the forwarding constructor.
Added std::forward() to make_tuple.
Added conversion constructor.
Moved msgpack::type::tuple to
include/msgpack/v1/adaptor/detail/cpp11_msgpack_tuple_decl.hpp from
include/msgpack/v1/adaptor/detail/cpp11_msgpack_tuple.hpp.
msgpack::type::tuple_cat requires the class template tuple definition.
``#include <stdint.h>`` is invalid in MSVC 9 2008 . Using the system dependent header does work in my testing with MSVC9, and should be safe for other compilers I think.
Takatoshi Kondo