1. auto_ptrs can not share ownership.An auto_ptr must not refer to an object is owned by another auto_ptr (or otherobject). Otherwise, if the first pointer deletes the object, the other pointer suddenly refersto a destroyed object, and any further read or that write access may result in disaster.2. auto_ptrs are not provided for arrays.An auto_ptr is not allowed to refer to arrays. This is because an auto_ptr callsdelete instead of delete [] for the object it owns. Note that there is no equivalentclass in the C standard library that has the auto_ptr semantics for arrays. Instead, the library provides several container classes to handle collections of data (see Chapter5) .3. auto_ptrs are not "universal smart pointers." An auto_ptr is not designed to solve other problems for which smart pointers might beuseful. In particular, they are not pointers for reference counting. (Pointers for referencecounting ensure that an object gets deleted only if the last of several smart pointers thatrefer to that object gets destroyed.) 4. auto_ptrs do not meet the requirements for container elements.An auto_ptr does not meet one of the most fundamental requirements for elements ofstandard containers. That is, after a copy or an assignment of an auto_ptr, source andsink are not equivalent. In fact, when an auto_ptr is assigned or copied, the sourceauto_ptr gets modified because it transfers its value rather than copying it. So youshould not use an auto_ptr as an element of a standard container. fortunately, thedesign of the language And Library Prevents this Misuse from Compiling In A StandardConformingenvironment. Final Conclusion: Using NonConstant Auto_PTRS IS No Safer Than Using Ordinary Pointers. So use of auto_ptr to try to use const as possible
