Re: [boost] [move][unique_ptr] c++14 unique_ptr comes to town

Ion Gaztañaga wrote:

Evidently, if tests are finer grained separated then we can push Boost.Move out of many tests. In any case, it will be included by boost/move/unique_ptr.hpp ;-)

This is an implementation detail. We may decide (either now or at some point in the future) to not include Boost.Move in C++11 mode at all in unique_ptr.hpp. And if we do that, it will help if we test whether both p1 = std::move( p2 ); and p1 = boost::move( p2 ); work (the former in C++11 mode, the latter in both 03 and 11 with appropriate #include .) Stated differently, I want boost::unique_ptr, on a C++11 compiler, to work without any inclusion or mention of Boost.Move in user code, if that's what the user wants (even though it wouldn't make much sense to not use std::unique_ptr there except perhaps for the extension, but still.)

I didn't port the "fail" tests from Howard's test suite...

We'll have to add fail tests, but I didn't mention that because it can be a later, incremental addition. shared_ptr has a number of those that check, f.ex. whether undesired conversions can occur.

...

I don't understand how the deleter can be a pointer to a binary function. It's always called with one argument, the pointer.

The trait was imported from Intrusive, where binary and unary functions are used in containers. I was just too lazy to rename/rework it.

It's also possible to use is_class instead. Technically, we also have to check is_empty, but in this case that's not strictly necessary. Something I missed in my post is that I think that default_delete should be in its own header (and its test should be named default_delete_test.) In principle, it might be good to also have tests for the type traits, even though they are implementation details. But that can wait until we stabilize the contents of the type traits header. Incidentally, addressof is in core. Is Boost.Move so completely free of dependencies now so that even core is considered too much?