Hello, night beast, you wrote: NB> what problems dared at creation of library which cannot solve standard pointers? A theoretical basis: the Purpose of project UPL is creation of instrumental library for improvement of quality and convenience of programming in C language ++ in style of OOP, in particular for the organization of the associative communications between objects in the multi-threaded environment. Introduction: UPL gives expanded semantics for concepts of possession and control of lifetime of objects, in comparison with clever pointers of standard library of a C ++. More attentions gives to pointers with unique possession (weak references for them, possibility of transmission to functors, which demand copying of arguments (std:: function)), provides prolongation of lifetime of object in the given area of visibility, adds pointers with unary frequency rate which always refer to one object. Pointers UPL are not changeover of clever pointers of standard library of a C ++ and can be used together with them (certainly, simultaneously the object can be under control only one library). UPL it is intended for cases when there is no functionality of clever pointers of standard library of a C ++ and additional possibilities for the organization of communications between objects in the multi-threaded environment are required. For example, with these two points I had difficulties at the decision by means of standard pointers: the Pointer upl:: weak can refer to object which is under control upl:: unique. The pointer upl:: unified allows to transfer unique possession of object in a chain where copying can be fulfilled. I will be grateful, if offer the decision of these points by means of standard pointers (with the operation registration in the multi-threaded environment). Hello, Alexander G, you wrote: VT>> the Pointer upl:: : weak can refer to object which is under control upl:: unique. AG> As it is made? All pointers are made over typical implementation shared, even unique? Yes, implementation typical - on counters of links. Moreover, now it naive enough not to run into premature optimization. upl:: unique too refers to the control unit with counters so it is heavier, than std:: unique_ptr. It would be good to make implementation on something ready, for example std:: shared_ptr, but at me it did not turn out, therefore it was necessary to invent a bicycle. It can is strange sounds, but now specific implementation not so is important. It can be and on other principle is based, not mandatory reference counting. For me it is more important to define, what dial-up of pointers is necessary and sufficient for an object in view (see above). For example, whether it is possible to do without upl:: unified. Also the task to define for pointers that sample algorithms have not been anchored to specific implementations of pointers was put.