I present here a piece of code taken from a book about mastering Qt5. it's the use of unique_ptr in the way shown below which I found to be suspicious and unusual(IMO). class AlbumDao{public:    AlbumDao(QSqlDatabase& database);    void init() const;    void addAlbum(Album& album) const;    void updateAlbum(const Album& album) const;    void removeAlbum(int id) const;    std::unique_ptr<std::vector<std::unique_ptr<Album>>> albums() const;private:    QSqlDatabase& mDatabase;};here is the implementation of albums() where we allocate dynamic memory even for std::vector.unique_ptr<vector<unique_ptr<Album>>> AlbumDao::albums() const{    QSqlQuery query(SELECT * FROM albums, mDatabase);    query.exec();    unique_ptr<vector<unique_ptr<Album>>> list(new vector<unique_ptr<Album>>());    while(query.next()) {        unique_ptr<Album> album(new Album());        album->setId(query.value(id).toInt());        album->setName(query.value(name).toString());        list->push_back(move(album));    }    return list;}//Album is just a Data holder class.so, my question are:is the use of unique_ptr in this way is correct?unique_ptr is not copyable, so does the compiler move it automaticly?(without an explicit std::move)why allocation of dynamic memory for std::vector?so in short, I am asking to review this code and decide whether is it correct to use unique_ptr in code like so. 
is this interface correct and use of unique_ptr correct?
c++;comparative review;c++14
Is the use of unique_ptr in this way correct?Yes, it's correct, but it's not idiomatic. There are two reasons I can think of to use unique_ptr<Album> instead of Album directly:If Album is not default-constructible, not copyable, or not moveable  that is, if Album is not a value-semantic and/or regular type  then you may find you can't manipulate Albums in all the ways you want to. A good example of this use-case is std::mutex: you can't meaningfully create a std::vector<std::mutex>, but you could create a std::vector<std::unique_ptr<std::mutex>>.As a special case of not copyable: if Album is a polymorphic class, then you might need to heap-allocate the individual Albums. You can't create a heterogeneous vector in C++, but you can create a vector<Base*> where each Base* points to an instance of a different derived class.However, neither of these use-cases applies to the code you posted, so all I can think is that the programmer was cargo-culting some code from an environment in which most classes he dealt with were polymorphic.(Notice that Album does not have a virtual destructor, so it can't meaningfully be polymorphic.)unique_ptr is not copyable, so does the compiler move it automaticly?(without an explicit std::move)Yes, in most cases. For example, the construct return foo; (when foo is a parameter or local variable) automatically treats foo as if it were an rvalue. Idiomatic C++ code contains very few explicit std::moves, especially at the business-logic level. (If you're implementing hardcore template-metaprogramming libraries, it's a different story.)Why allocation of dynamic memory for std::vector?Again, it smells to me like the author was cargo-culting the practice from some codebase where every object is heap-allocated was just a rule of thumb. Perhaps their codebase was automatically translated from Java or C# (two languages where that rule of thumb is actually baked into the language semantics: in many OO languages, you simply cannot create class instances that aren't heap-allocated).This is not good C++ practice, and you should not copy it.Lastly, note that this code:unique_ptr<vector<unique_ptr<Album>>> list(new vector<unique_ptr<Album>>());is particularly bad C++03-style C++11. In idiomatic C++14, it would beauto list = std::make_unique<std::vector<std::unique_ptr<Album>>>();and of course without all the heap-allocation one would hope the entire function could be juststd::vector<Album> result;while (query.next()) {    result.emplace_back(  // assuming Album has the appropriate constructor        query.value(id).toInt(),        query.value(name).toString()    );}return result;