I'd like to optimize my code. I have one class that has a shared_ptr data member. In some methods of this class, I create objects that need to use this member (just to get information from the object pointed by shared_ptr). I know that lifetime of these created objects is lower than in my main class.
How to pass this pointer? I think another shared_ptrs is unnecessary (because I have a warranty that the object will exist). So what should get my created classes? Should they get raw pointer? Weak_ptr? Or the best solution is getting shared_ptr (and incrementing its reference counter)? What is the most standard solution?
In this case when you know the life-time of your shared resource will outlive those that you pass the pointer to the correct thing to do is pass a reference or a raw pointer:
void func(object* o)
{
// do stuff with o
}
// ...
std::shared_ptr<object> sp;
// ...
func(sp.get()); // pass raw pointer
The main reason for this is that the function can be useful no matter what kind of smart pointer is managing the resource. By accepting the raw pointer your function is able to accept objects from shared pointers as well as unique pointers and any other third party smart pointer.
There is no benefit to passing in the smart pointer unless the function needs to modify the smart pointer itself.
A good set of guidelines being produced by Bjarne Straustrup & Herb Sutter can be found here: CppCoreGuidelines
The rule about passing raw pointers (or references):
F.7
Passing a smart pointer transfers or shares ownership and should only be used when ownership semantics are intended. A function that does not manipulate lifetime should take raw pointers or references instead.
Passing by smart pointer restricts the use of a function to callers that use smart pointers. A function that needs a widget should be able to accept any widget object, not just ones whose lifetimes are managed by a particular kind of smart pointer.
When passing the shared_ptr into a function that will not store the resource, pass it by reference:
void foo(const shared_ptr<T>& ptr)
{
// Basically just a pointer dereference
std::cout << ptr->bar() << '\n';
}
int main()
{
std::shared_ptr<T> ptr{std::make_shared<T>()};
foo(ptr);
}
That won't increment the reference count, but that's fine — you're effectively treating it as a raw pointer (because you're just temporarily inspecting the pointee) but in a way that's safe because if you accidentally copy it then you'll get the reference count increment that can save your life. :)
However, if foo needs to store any sort of handle to this object, then you should pass in the shared_ptr by copy … or consider using weak_ptr so that you at least get some semblance of safety.
The above contrived example is so simple that I'd actually make it the following:
void foo(const T& ptr)
{
std::cout << ptr.bar() << '\n';
}
int main()
{
std::shared_ptr<T> ptr{std::make_shared<T>()};
foo(*ptr.get());
}
Related
Suppose that we have
void UsePointer (auto_ptr <CSomeClass> spObj)
{
spObj->DoSomething();
}
and we have a main function:
int main()
{
auto_ptr <CSomeClass> spObject (new CSomeClass ());
UsePointer (spObject);
// spObject->DoSomthing (); would be invalid.
}
The book says "the object was destroyed when UsePointer() returned, because variable spObj went out of scope, hence destroyed"
My question is:
Is the pointer copied when passed into UsePointer function? Hence the owernship is transferred?
What do I need to if want spObject not be destroyed? Do I need to pass this pointer by reference?
Also this book is a bit outdated - does the same hold for unique_ptr in c++ 11?
Is the pointer copied when passed into UsePointer function? Hence the owernship is transferred?
Yes. Unless the function parameter is reference qualified, arguments pass by value. For auto_ptr that involves copying, and thus passing ownership.
What do I need to if want spObject not be destroyed? Do I need to pass this pointer by reference?
You could. But better yet, pass a reference to the object itself. A function shouldn't accept smart pointers unless manipulation of the ownership is involved. If it just needs to do something with pointee, accept a CSomeClass const& and pass *spObject.
Also this book is a bit outdated - does the same hold for unique_ptr in c++ 11?
Yes. With the difference that unique_ptr is not copyable, and so cannot pass its ownership away implicitly. To pass a unique_ptr, it must be moved explicitly. The appearance of std:move in the code that passes the pointer into the function gives an explicit visual cue that ownership changes.
i'm using the new smart-pointer from C++ 11. I'm now confused what's the best way to pass and input value to an function.
The standard rule for method/function signatures is
inputs: prefer const reference and pointer where you must (f.e. nullptr is a legal input)
outputs: should b e pointers.
But with smart-pointer things are more "complicated".
I understand that you should not pass the input as ...
unique_ptr where the ownership is not transfered
shared_ptr where the object should not be share the ownership.
... and use referece or pointer instead.
For me the problem with the standard rule is that the developer who is using the function must dereference the pointer from the smart-pointer and he should always check if the result is not nullptr, so there is an "always" manual checking code.
void foo(const MyClass& obj)
{
...
}
void main()
{
auto a = make_unique<MyClass>();
if(*a) // always check dereference
{
foo(*a);
}
}
Instead, passing the input as const pointer, the usability is easier, but nullptr would be an "legal" value.
void foo(const MyClass* obj)
{
...
}
void main()
{
auto a = make_unique<MyClass>();
foo(a.get()); //easier to use, but nullptr is a "legal" value
}
Can anybody share his opinion when you use pointer, when references and how do you deal with deref's in that case.
Thanks in advance
If you are trying to check if the pointer points to an allocated object or if it is instead null, use std::unique_ptr::operator bool which will return true if the pointer is valid and false if there is no object created yet:
http://en.cppreference.com/w/cpp/memory/unique_ptr/operator_bool
This is better, and simpler, than using get() for this purpose.
Generally, with unique_ptr you do not pass the smart pointer itself to any functions, but when you want to pass a true pointer, you pass the return of get(), which is a non-owning normal pointer that the non-owning function can use. The pointer is still managed by the owning smart pointer. Common C++ guidelines encourage use of a normal pointer only for non-owning functions or classes that receive this pointer from a smart pointer elsewhere.
I have a C++ project where I store objects in cells in a grid container. Every cell may contain one or zero objects stored in a std::unique_ptr. Naturally all methods having these objects as arguments should take a const std::unique_ptr reference to maintain the "uniqueness".
Secondly, when something happens to the objects they emit a signal with themselves as one of the arguments; these signals are caught by the grid container in a single handler (therefore we need the object reference). The handler may take some action on the object or emit its own signal, passing the object reference further.
The problem is that the objects themselves obviously cannot return a std::unique_ptr reference to themselves, while all other methods operating on them expects one. Is there a way to solve this, or do I have to let go of unique pointers and use raw ones?
Here's a code example using the sigc++ library (please allow for minor errors since I haven't tested it):
class Inhabitant
{
public:
void sos()
{
signal_distress.emit (*this);
}
// Signals
sigc::signal<void, Inhabitant &> signal_distress;
};
class Cell
{
public:
std::unique_ptr<Inhabitant> set_inhabitant (std::unique_ptr<Inhabitant> inhabitant)
{
// Set new inhabitant, return previous one...
}
private:
std::unique_ptr<Inhabitant> m_inhabitant;
};
class Grid
{
public:
void add_inhabitant_at (std::unique_ptr<Inhabitant> inhabitant,
unsigned int x, unsigned int y)
{
// Connect the inhabitant to our rescue team
inhabitant->signal_distress.connect (sigc::mem_fun (*this,
&Grid::on_inhabitant_distress));
// Place in cell
m_cells[x][y].set_inhabitant (std::move (inhabitant));
}
private:
// Data
Cell m_cells[100][100];
// Helpers
void help_inhabitant (const std::unique_ptr<Inhabitant> &inhabitant)
{
// Do something helpful
}
// Signal handlers
void on_inhabitant_distress (Inhabitant &inhabitant)
{
// Now, how do I call help_inhabitant(), or any other function that expects
// a unique_ptr reference?
}
};
It is a best practice not to pass smart pointers such as unique_ptr to functions that do not need to take (or share) ownership of the resource managed by the unique_ptr. Put another way, I don't think you would ever want to pass a unique_ptr by const reference. Instead, all the functions that are taking these unique_ptr references really only need to take a const Inhabitant &. For example:
void help_inhabitant (const Inhabitant &inhabitant) {
// do stuff with the inhabitant directly
}
Naturally all methods having these objects as arguments should take a const std::unique_ptr reference to maintain the "uniqueness".
No, the object still has a single unique owner, no matter how many other pieces of code can access it via non-owning pointers or references. Your idea that passing around const unique_ptr<T>& maintains any kind of invariant or enforces a policy is an illusion.
Is there a way to solve this, or do I have to let go of unique pointers and use raw ones?
You don't have to give it up competely, just where it's inappropriate. Use unique_ptr for managing ownership and lifetime, use raw pointers for simply referring to an object that is managed by some other piece of code.
surely the whole point about unique_ptr is that you pass references to it, rather than a raw pointer?
No, definitely not.
The unique_ptr manages the ownership of the object, but not doesn't have to be used for access to the object.
If you want to refer to the object without owning it then passing references or pointers to the object is fine (as long as the code receiving those pointers or references doesn't think it is taking ownership and try to delete the object). The code that just wants to use Inhabitant doesn't need to care that it is owned by a unique_ptr, it just wants to use the object. How its lifetime is managed is someone else's concern, and the code that doesn't own the object should not be made dependent on the ownership policy. Avoiding that dependency would allow you to change the owner to use shared_ptr or some other mechanism, and the signal handlers would be unaffected because they do not have to change how they access the object.
Pass a unique_ptr by value (or rvalue reference) to transfer ownership. Do not pass a unique_ptr by const-reference, because it's completely useless, the caller can't do anything with it that can't be done with a raw pointer.
Using a reference to a unique_ptr actually introduces a new class of bug that wouldn't exist otherwise:
void register_callback(func_type f, const unique_ptr<T>& obj);
unique_ptr<T> p(new T);
register_callback(func, p); // stores reference to p
unique_ptr<T> p2 = std::move(p);
Now the signal handler still refers to p which is going to be empty when the callback happens. The identity of the unique_ptr is completely irrelevant, all that matters is that exactly one unique_ptr object owns the pointer, it doesn't matter which one owns it. But you have made the callback depend on the exact instance of unique_ptr by binding a reference to it, so you cannot move that (so you can never move a Cell, which means you can't store it in a container such as vector that might reallocate and move its elements)
If you do it this way instead the callback refers to the object, and it doesn't matter precisely where it's stored:
void register_callback(func_type f, T* obj);
unique_ptr<T> p(new T);
register_callback(func, p.get()); // stores p.get()
unique_ptr<T> p2 = std::move(p);
The callback's copy of the p.get() pointer remains valid even though ownership of it transfers from one object to another.
OK, solved the problem when I realized there is no reason why the cell inhabitants should send a reference to themselves with the signal. Instead the listener (the grid) can bind a reference to the inhabitant (the unique_ptr to it, that is) when registering with the signal:
inhabitant->signal_distress().connect (std::bind (&Grid::on_inhabitant_distress,
this,
std::cref (inhabitant));
This way the signal handler can take a unique_ptr:
void on_inhabitant_distress (const std::unique_ptr<Inhabitant> &inhabitant)
{
// Now everything is fine!
help_inhabitant (inhabitant);
}
and the "uniqueness" chain stays intact.
In C++11, you can use a shared_ptr<> to establish an ownership relation with an object or variable and weak_ptr<> to safely reference that object in a non-owned way.
You can also use unique_ptr<> to establish an ownership relation with an object or variable. But what if other, non-owning objects want to also reference that object? weak_ptr<> isn't helpful in this case. Raw pointers are helpful but bring various downsides (e.g. they can be automatically initialized to nullptr but this is accomplished through techniques that are not consistent with the std::*_ptr<> types).
What is the equivalent of weak_ptr<> for non-owning references to objects owned via unique_ptr<>?
Here's a clarifying example that resembles something in a game I'm working on.
class World
{
public:
Trebuchet* trebuchet() const { return m_trebuchet.get(); }
private:
std::unique_ptr< Trebuchet > m_trebuchet;
};
class Victim
{
public:
Victim( Trebuchet* theTrebuchet ) : m_trebuchet( theTrebuchet ) {}
~Victim()
{
delete m_trebuchet; // Duh. Oops. Dumb error. Nice if the compiler helped prevent this.
}
private:
Trebuchet* m_trebuchet; // Non-owning.
};
shared_ptr< Victim > createVictim( World& world )
{
return make_shared< Victim >( world.trebuchet() );
}
Here we use a raw pointer to maintain a non-owning relationship with an object owned via unique_ptr<> elsewhere. But is raw the best we can do?
The hope is a type of pointer that:
Looks like the other modern pointer types. E.g. std::raw_ptr<T>.
Replaces raw pointers so that a codebase that uses modern pointer types throughout can find all pointers via a search for _ptr< (roughly).
Auto-initializes to nullptr.
Thus:
int* p; // Unknown value.
std::raw_ptr< int > p; // null.
Does this type already exist in C++ now, is it proposed for the future, or is another implementation broadly available in e.g. Boost?
The "notify" behavior of shared_ptr requires reference counting the reference count control block. shared_ptr's reference count control block(s) use separate reference counts for this. weak_ptr instances maintain references to this block, and weak_ptrs themselves prevent the reference count control block from being deleteed. The pointed-to object has its destructor called when the strong count goes to zero (which may or may not result in deleteion of the memory where that object was stored), and the control block is deleteed only when the weak reference count goes to zero.
unique_ptr's tenet is that it has zero overhead over a plain pointer. Allocating and maintaining reference count control blocks (to support weak_ptr-ish semantics) breaks that tenet. If you need behavior of that description, then you really want shared semantics, even if other references to the object are non-owning. There's still sharing going on in that case -- the sharing of the state of whether or not the object has been destroyed.
If you need a generic nonowning reference and don't need notification, use plain pointers or plain references to the item in the unique_ptr.
EDIT:
In the case of your example, it looks like Victim should ask for a Trebuchet& rather than a Trebuchet*. Then it's clear who owns the object in question.
class World
{
public:
Trebuchet& trebuchet() const { return *m_trebuchet.get(); }
private:
std::unique_ptr< Trebuchet > m_trebuchet;
};
class Victim
{
public:
Victim( Trebuchet& theTrebuchet ) : m_trebuchet( theTrebuchet ) {}
~Victim()
{
delete m_trebuchet; // Compiler error. :)
}
private:
Trebuchet& m_trebuchet; // Non-owning.
};
shared_ptr< Victim > createVictim( World& world )
{
return make_shared< Victim >( world.trebuchet() );
}
There is a genuine need for a standard pointer type to act as a non-owning, inexpensive, and well-behaved counterpoint to std::unique_ptr<>. No such pointer has been standardized yet, but a standard has been proposed and is under discussion by the C++ standards committee. The "World's Dumbest Smart Pointer", aka std::exempt_ptr<> would have the general semantics of other modern C++ pointer classes but would hold no responsibility either for owning the pointed-to object (as shared_ptr and unique_ptr do) or for correctly responding to the deletion of that object (as weak_ptr does).
Assuming that this feature is ultimately ratified by the committee, it would fully meet the need highlighted in this question. Even if it isn't ratified by the committee, the above linked document fully expresses the need and describes a complete solution.
unique_ptr's non-owing analog is a plain C pointer. What is different - C pointer doesn't know if the pointed data is still accessible. weak_ptr on the other hand does. But it is impossible to replace raw pointer with a pointer knowing about the validity of data without additional overhead (and weak_ptr does have that overhead). That implies C-style pointer is the best in terms of speed you can get as a non-owing analog for unique_ptr.
While you can't get a "weak" pointer to a uniquely owned object for free, the concept is useful and is used in a couple systems. See Chromium's WeakPtr and QT's QPointer for implementations.
Chromium's WeakPtr is implemented intrusively by storing a shared_ptr inside the weak-referenceable object and marking it invalid when the object is destroyed. WeakPtrs then reference that ControlBlock and check whether it's valid before handing out their raw pointer. I assume QT's QPointer is implemented similarly. Because ownership isn't shared, the original object is destroyed deterministically.
However, this means that dereferencing the WeakUniquePtr isn't thread-safe:
Thread 1:
unique_ptr<MyObject> obj(new MyObject);
thread2.send(obj->AsWeakPtr());
...
obj.reset(); // A
Thread2:
void receive(WeakUniquePtr<MyObject> weak_obj) {
if (MyObject* obj = weak_obj.get()) {
// B
obj->use();
}
}
If line A happens to run concurrently with line B, thread 2 will wind up using a dangling pointer. std::weak_ptr would prevent this problem by atomically taking a shared owning reference to the object before letting thread 2 use it, but that violates the assumption above that the object is owned uniquely. That means that any use of a WeakUniquePtr needs to be synchronized with the destruction of the real object, and the simplest way to do that is to require that they're done in a message loop on the same thread. (Note that it's still completely safe to copy the WeakUniquePtr back and forth across threads before using it.)
One could imagine using a custom deleter in std::unique_ptr to implement this using standard library types, but that's left as an exercise for the reader.
boost::optional<Trebuchet&>
As Billy ONeal pointed out in his answer you likely want to pass a Trebuchet& instead of a pointer. The problem with the reference is that you cannot pass a nullptr, boost::optional provides a way to have the equivilent of a nullptr. Further details on boost::optional are here: http://www.boost.org/doc/libs/1_54_0/libs/optional/doc/html/boost_optional/detailed_semantics.html
See also this question: boost::optional<T&> vs T*
Note: std::optional<T> is on track to make it into C++14 but std::optional<T&> is a separate proposal that is not in the current C++14 draft. Further details here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html
In the new C++ world with shared_ptr, weak_ptr, and unique_ptr you should not be storing long lived references to objects, like your trebuchet, using raw pointers or references. Instead World should have a shared_ptr to the trebuchet and Victim should store either a shared_ptr or a weak_ptr, depending on whether the trebuchet should stick around with the victim if the world goes away. Using a weak_ptr allows you to tell if the pointer is still valid (i.e. the world still exists), there is no way to do this with a raw pointer or reference.
When you use a unique_ptr you are declaring that only the World instance will own the trebuchet. Clients of the World class can use the World object's trebuchet by calling the "get" method but should not hold on to the reference or pointer returned by the method when they are done using it. Instead they should "borrow" the trebuchet every time they want to use it by calling the "get" method.
The above being said there could be instances where you want to store a reference or raw pointer for future use to avoid the overhead of the shared_ptr. But those instances are few and far between and you need to be completely sure that you won't use the pointer or reference after the World object that owns the trebuchet has gone away.
otn::raw::weak (from C++ Object Token Library) is non-owning, inexpensive, and well-behaved counterpoint to std::unique_ptr. Also in the library there is otn::safe::unique, a unique owner which can "notify" a non-owning otn::safe::weak about the deletion of the object.
#include <otn/all.hpp>
#include <iostream>
int main()
{
using namespace std;
using namespace otn;
raw::weak_optional<int> raw_weak;
if (!raw_weak)
cout << "raw_weak is empty" << endl;
cout << "--- create object in std_unique..." << endl;
auto std_unique = std::make_unique<int>(42);
raw_weak = std_unique;
if (std_unique)
cout << "std_unique is not empty" << endl;
if (raw_weak)
cout << "raw_weak is not empty" << endl;
cout << "--- move std_unique to safe_unique..." << endl;
safe::unique_optional<int> safe_unique = std::move(std_unique);
if (!std_unique)
cout << "std_unique is empty" << endl;
if (raw_weak)
cout << "raw_weak is not empty, it is observs safe_unique" << endl;
safe::weak_optional<int> safe_weak = safe_unique;
if (safe_unique)
cout << "safe_unique is not empty" << endl;
if (!safe_weak.expired())
cout << "safe_weak is not expired" << endl;
cout << "--- destroy object in safe_unique..." << endl;
utilize(std::move(safe_unique));
if (!safe_unique)
cout << "safe_unique is empty" << endl;
if (safe_weak.expired())
cout << "safe_weak is expired, it is not dangling" << endl;
if (raw_weak)
cout << "raw_weak is not empty, it is dangling!!!" << endl;
}
Output:
raw_weak is empty
--- create object in std_unique...
std_unique is not empty
raw_weak is not empty
--- move std_unique to safe_unique...
std_unique is empty
raw_weak is not empty, it is observs safe_unique
safe_unique is not empty
safe_weak is not expired
--- destroy object in safe_unique...
safe_unique is empty
safe_weak is expired, it is not dangling
raw_weak is not empty, it is dangling!!!
A function taking a raw pointer or reference implicitly promises not to hold on to a copy of that pointer after the function has returned. In return the caller promises that the pointer is valid (or nullptr) until the callee has returned.
If you want to hold on to the pointer, you are sharing it (and should use shared_ptr). A unique_ptr manages a single copy of the pointer. You use raw pointers (or references) to refer to call functions involving that object.
This is the same for shared_ptr objects. weak_ptr only comes into play when you want to have an additional reference to the pointed too object that outlives the involved function. The main purpose of weak_ptr is to break reference cycles where two objects hold references to each other (and are therefore never released).
Remember however that taking shared_ptr or weak_ptr implies that the function taking that parameter will (optionally) modify some other object to retain a reference to the pointed to object that outlives the invocation of the function. In the vast majority of cases you use raw pointer (if nullptr is a valid value) or ref (when a value is guaranteed) even for shared_ptr or weak_ptr.
now you hava noshared_ptr --
https://github.com/xhawk18/noshared_ptr
noshared_ptr<T> -- a new type of unique ptr
noweak_ptr<T> -- weak ptr for the noshared_ptr
I have some code that currently uses raw pointers, and I want to change to smart pointers. This helps cleanup the code in various ways. Anyway, I have factory methods that return objects and its the caller's responsibility to manager them. Ownership isn't shared and so I figure unique_ptr would be suitable. The objects I return generally all derive from a single base class, Object.
For example,
class Object { ... };
class Number : public Object { ... };
class String : public Object { ... };
std::unique_ptr<Number> State::NewNumber(double value)
{
return std::unique_ptr<Number>(new Number(this, value));
}
std::unique_ptr<String> State::NewString(const char* value)
{
return std::unique_ptr<String>(new String(this, value));
}
The objects returned quite often need to be passed to another function, which operates on objects of type Object (the base class). Without any smart pointers the code is like this.
void Push(const Object* object) { ... } // push simply pushes the value contained by object onto a stack, which makes a copy of the value
Number* number = NewNumber(5);
Push(number);
When converting this code to use unique_ptrs I've run into issues with polymorphism. Initially I decided to simply change the definition of Push to use unique_ptrs too, but this generates compile errors when trying to use derived types. I could allocate objects as the base type, like
std::unique_ptr<Object> number = NewNumber(5);
and pass those to Push - which of course works. However I often need to call methods on the derived type. In the end I decided to make Push operate on a pointer to the object stored by the unique_ptr.
void Push(const Object* object) { ... }
std::unique_ptr<Object> number = NewNumber(5);
Push(number.get());
Now, to the reason for posting. I'm wanting to know if this is the normal way to solve the problem I had? Is it better to have Push operate on the unique_ptr vs the object itself? If so how does one solve the polymorphism issues? I would assume that simply casting the ptrs wouldn't work. Is it common to need to get the underlying pointer from a smart pointer?
Thanks, sorry if the question isn't clear (just let me know).
edit: I think my Push function was a bit ambiguous. It makes a copy of the underlying value and doesn't actually modify, nor store, the input object.
Initially I decided to simply change the definition of Push to use
unique_ptrs too, but this generates compile errors when trying to use
derived types.
You likely did not correctly deal with uniqueness.
void push(std::unique_ptr<int>);
int main() {
std::unique_ptr<int> i;
push(i); // Illegal: tries to copy i.
}
If this compiled, it would trivially break the invariant of unique_ptr, that only one unique_ptr owns an object, because both i and the local argument in push would own that int, so it is illegal. unique_ptr is move only, it's not copyable. It has nothing to do with derived to base conversion, which unique_ptr handles completely correctly.
If push owns the object, then use std::move to move it there. If it doesn't, then use a raw pointer or reference, because that's what you use for a non-owning alias.
Well, if your functions operate on the (pointed to) object itself and don't need its address, neither take any ownership, and, as I guess, always need a valid object (fail when passed a nullptr), why do they take pointers at all?
Do it properly and make them take references:
void Push(const Object& object) { ... }
Then the calling code looks exactly the same for raw and smart pointers:
auto number = NewNumber(5);
Push(*number);
EDIT: But of course no matter if using references or pointers, don't make Push take a std::unique_ptr if it doesn't take ownership of the passed object (which would make it steal the ownership from the passed pointer). Or in general don't use owning pointers when the pointed to object is not to be owned, std::shared_ptr isn't anything different in this regard and is as worse a choice as a std::unique_ptr for Push's parameter if there is no ownership to be taken by Push.
If Push does not take owenrship, it should probably take reference instead of pointer. And most probably a const one. So you'll have
Push(*number);
Now that's obviously only valid if Push isn't going to keep the pointer anywhere past it's return. If it does I suspect you should try to rethink the ownership first.
Here's a polymorphism example using unique pointer:
vector<unique_ptr<ICreature>> creatures;
creatures.emplace_back(new Human);
creatures.emplace_back(new Fish);
unique_ptr<vector<string>> pLog(new vector<string>());
for each (auto& creature in creatures)
{
auto state = creature->Move(*pLog);
}