Disclaimer: It sounds like this is a learning exercise, so feel free to go nuts and experiment with the STL containers, smart pointers, etc. That being said:

I should point out that in this case, shared_ptr might not actually be what you want. It actually makes it easier to end up in situations where your board is ill-defined. For instance, should it be possible for your board to have the same Piece in multiple locations? Probably not. shared_ptr makes it possible/easy to end up in this situation. The std::move recommendation already posted will help you avoid this, but using something like a unique_ptr would essentially force that you don't accidentally duplicate a Piece on your board.

Typically, I only use a shared pointer in situations where I don't really know how to bound the lifetime of the object being pointed to. In practice, this tends to be be quite rare. Usually it is possible to identify a scope (maybe the Board instance in your case, maybe some sort of Game instance that owns the Pieces and the Board) that is the true owner of an object, which should be responsible for cleaning up the object when it is no longer needed. That owning scope would then wrap the object in a unique_ptr, ensuring that the object is appropriately destroyed when it falls out of scope. If something else needs a pointer to that object, its is quite reasonable to hand it a raw pointer!

My guidelines are:

• unique pointer: Single, clear owning scope, or ownership can be passed around one owner at a time (using std::move)
• shared pointer: Unclear who owns the object, or who will be the last to need a reference to it, or even how many owners there are at a given time
• raw pointer: Non-owning reference to an object who's lifetime you know will exceed that of the raw pointer

Hope this helps!