@32:30 Rather than use weak_ptr to signal that an object is read-only, you can just actually make it read-only by converting the shared_ptr to a shared_ptr to const. std::shared_ptr writeable = std::make_shared(4); std::shared_ptr read_only {writeable};
But that is hardly the same thing, is it? The main purpose of a weak pointer is not to prevent a resource from being modified, but to allow the resource be disposed. Weak pointers are non-blocking whereas shared pointers are blocking, meaning that once a resource is held (co-shared) be a shared pointer it will not be disposed. Weak pointers, on the other hand, do not prevent resources from being destroyed. They only monitor the resource's existence. If the resource is not expired, one can get a shared resource from it, and such a shared pointer can be either to a non-const resource or const resource - the distinction can be achieved via const_pointer_cast.
There is a set of confusing statements in two places referring to the lock() method of a weak pointer if it is called on an already expired shared pointer. At first the presenter states that it returns "Default initialization of the object". That statement is later corrected to "Shared Pointer of the default object", before it gets corrected again to "Default initialized Shared Pointer of the object". The correct statement, however, ought to be: "default-constructed shared_ptr of type T". Since "type T" is generally not the same thing as "Object", I believe the statement needs this correction to avoid further confusing the audience.
The lecturer does not recommend "passing shared pointer to a function", as stated in the Q&A section. I would argue that it is not generally a good recommendation, since there is as many cases for it as it is against it. Too many to mentioned them all, but one could be: if the function cannot be guaranteed that the object passed in will last as long as the function needs it, for whatever reasons, than the argument probably should be a shared pointer. If, on the other hand, the function designed does not feel it has a strong guarantee the object is not going to expire, then and only then the taken argument could be a native pointer or reference (or a copy, of course, if that makes more sense).
