use make_unique in cpp example

[philipcraig]

As it's more vernacular due to exception safety (no naked news)

[philipcraig]

Looks like this is failing as it needs C++14 or higher.

Seeing as I'm working on adding support for std::optional, which will require C++17 or higher, @dtolnay what restrictions or not would you like on C++ standard versions supported and used?

The default currently on all the platforms is C++11.

Using make_unique in the demo code would require C++14

Supporting std::optional would require C++17

[dtolnay]

The demo code can use any standard, that doesn't matter.

The main library should be opt-in for particular standards (and other interop like absl) as discussed in #80.

[philipcraig]

The demo code can use any standard, that doesn't matter.

The main library should be opt-in for particular standards (and other interop like absl) as discussed in #80.

Got it. I can see how to do opt-in feature detection in the C++ code, like it has been done at

cxx/include/cxx.h

Lines 17 to 36 in b01e5ac

	#ifdef __has_include
	#if __has_include(<string_view>) && __cplusplus >= 201703L
	#define CXX_HAVE_STD_STRING_VIEW 1
	#endif
	#endif
	// For MSVC, `__has_include` is supported in VS 2017 15.3, which is later than
	// the support for <optional>, <any>, <string_view>, <variant>. So we use
	// _MSC_VER to check whether we have VS 2017 RTM (when <optional>, <any>,
	// <string_view>, <variant> is implemented) or higher. Also, `__cplusplus` is
	// not correctly set by MSVC, so we use `_MSVC_LANG` to check the language
	// version.
	#if defined(_MSC_VER) && _MSC_VER >= 1910 && \
	((defined(_MSVC_LANG) && _MSVC_LANG > 201402) || __cplusplus > 201402)
	#define CXX_HAVE_STD_STRING_VIEW 1
	#endif
	#ifdef CXX_HAVE_STD_STRING_VIEW
	#include <string_view>
	#endif

However, I don't know of a way to get the knowledge that a developer has deliberately opted-in to a C++17 feature (by e.g. using a std::optional or std::string_view) into the build.rs files to set the standard flag correctly for the C++ compilers.

What do you think about this? It would mean that whilst the actual C++ code that is generated would be opt-in, the build.rs lines would have to force C++17, just in case a developer used a C++17 feature such as std::string_view or std::optional.

The documentation could state that the later C++ language standard versions are opt-in, as could a comment in the build.rs files.