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

Subject: Re: [boost] [move][unique_ptr] c++14 unique_ptr comes to town
From: Peter Dimov (lists_at_[hidden])
Date: 2014-08-26 17:36:08

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 <move/core_utility.hpp>.)

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 <T[N]> 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?