1. make_shared<T>(args): return a shared_ptr dynamically allocated object of type T. Use args to initialize the object.
shared_ptr<T> p(q): p is a copy of shared_ptr q. Increase the count in q. The pointer in q must be convertable to T.
p = q: p and q are shared_ptr holding pointers that are convertable to one another. Decrease p‘s reference count, and increase q‘s count; delete p‘s existing memory if p‘s count goes to zero.
p.use_count(): return the number of objects sharing with p. Intended for debug purpose.
2. Ordinarily we use auto to make it easier to define an object to hold the result of make_shared:
auto p1 = make_shared<revector<string>>(); auto p2 = make_shared<int>(42); auto p(q); // p and q point to the same object
3. The fact that the shared_ptr class automatically free dynamic objects when they are no longer needed makes it fairly easier to use dynamic memory.
// factory return a shared_ptr pointing to a dynamically allocated object
shared_ptr<Foo> factory(T arg)
{
// process arg as a appropriate
// shared_ptr will take care of deleting the memory
return make_shared<Foo>(arg);
}
void use_factory(T arg)
{
shared_ptr<Foo> p = factory(arg);
// use p
} // p goes out of scope. The memory to which p points is automatically free
4.If you put shared_ptrs into a container, you should be sure to erase shared_ptr elements once you no longer need those elements.
Programs tend to use dynamic memory for one of three purpose:
- They don‘t know how many object they will need
- They don‘t know the precise type of the object they need.
- They want to share data between serval objects.
So far, the classes we have used allocate resources that exist only as long as the corresponding object
vector<string> v1;
{
vector<string> v2 = {"a", "aa", "bbb"};
v1 = v2; // copies the elements in v2 to v1
} // v2 is deleted, which destroys the elements in v2
// v1 has three new copied elements
Two operators allocate and delete dynamic memory:
- new: allocates memory
- delete: frees memory allocated by new.
Use these two operator is more error-prone than using a smart pointer.
A dynamic object managed through a build-in pointer exists until it is explictly deleted
Foo factory(T arg)
{
return new Foo(arg); // caller is responsible for deleting this memory
}
void use_factory(T arg)
{
Foo *p = use_factory(arg);
// use p but do not delete it
} p goes out of scope, but the memory to which p points is not freeed.
In this example, p was the only pointer to memory allocated by factory. Once use_factory returns, the program has no way to free the memory. Then memory leak.
There are three common problem with using new and delete to manage dynamic memory:
- Forgetting to delete memory, which is known as memory leak
- Using a object after it has been deleted
- Deleting the same object twice
We should use smart pointers rather than plain pointers
If we do not initialize a smart pointer, it is initialized as a null pointer. We can also initialize a smart pointer from a pointer return from new
shared_ptr<double> p1; shared_ptr<int> p2(new int(42));
The smart pointer constructors that take pointers are explict. We can not implictly conver a build-in pointer to a smart pointer.
shared_ptr<int> p1 = new int(1024); // error shared_ptr<int> p2(new int(1024)); // ok. use direct initilization
A function that return a shared_ptr cannot implictly return a plian pointer in its return statement
shared_ptr<int> clone(int p)
{
return new int(p); // error
}
shared_ptr<int> clone(int p)
{
// ok; explicitly create a shared_ptr from int *
return shared_ptr<int>(new int(p));
}
Don‘t mix ordinary pointers and smart pointers.
When we bind a shared_ptr to a pain pointer, we give responsibility for that memory to the shared_ptr, and we should no longer use a build-in pointer to access the memory to which the shared_ptr now points.
Don‘t use get to initilize or assign another smart pointer.