51

Re: Unified Pointer Library

Hello, ViTech, you wrote: S>> Etit-bang. Well transfer in designer Car a copy std:: unique_ptr <Engine>, and inside Car will be std:: shared_ptr <Engine>. VT> It is admissible. weak_ptr for Monitor then whence to take (Car and Monitor do not know about each other, they know only Engine)? From Car. Right after how you Car somewhere in the program created with some Engine. Here the author: so5team Date: 18.06 16:05 all on fingers showed. VT> and if it wants to remove the engine from one car and to deliver in another how it to make? The Author See above: so5team Date: 18.06 16:05 - the elementary wrapper UniqueEngine (in which shared_ptr) allows you to close this strange scenario. As at you Engine will be in other Car, but in the same Monitor. That, unconditionally, just fine. And, there is a sensation, such idiotic cases you therein can to invent a heap still.

52

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT> the Pointer upl:: weak can refer to object which Who is under control upl:: unique VT> worked with a sheaf std:: weak_ptr <-> std:: shared_ptr, in my opinion, should understand, of what it is a question. And look for QPointer: A guarded pointer, QPointer <T>, behaves like a normal a C ++ pointer T *, except that it is automatically set to 0 when the referenced object is destroyed (unlike normal a C ++ pointers, which become "dangling pointers" in such cases). T must be a subclass of QObject. And? Instead of implicit  to use such notified not-owning the pointer. Well and a multiflow to resolve not prolongation of life and classically, locks.

53

Re: Unified Pointer Library

Hello, vopl, you wrote: V> And look for QPointer: It, is hardly closer Smart observers to use with unique_ptr

54

Re: Unified Pointer Library

Hello, so5team, you wrote: VT>> It is admissible. weak_ptr for Monitor then whence to take (Car and Monitor do not know about each other, they know only Engine)? S> From Car. Right after how you Car somewhere in the program created with some Engine. Here the author: so5team Date: to 18.06 16:05 you all on fingers showed. VT>> and if it wants to remove the engine from one car and to deliver in another how it to make? S> the Author See above: so5team Date: 18.06 16:05 - the elementary wrapper UniqueEngine (in which shared_ptr) allows you to close this strange scenario. All is good, only from UniqueEngine:: weak_ref () it is possible to receive std:: shared_ptr <Engine>, with all that it implies. And UniqueEngine becomes not such unique. S> As at you Engine will be in other Car, but in the same Monitor. That, unconditionally, just fine. Monitor tracks for Engine, instead of for Car, and I too consider that it is fine. Actually, it is model it is defined. S> And, there is a sensation, such idiotic cases you therein can to invent a heap still. Well, the correct cases only at you who would doubt. For example, here "case". Let everyone defines, how much it idiotic. #include <upl/pointer.h> #include <iostream> struct Engine {public: int rpm () {return ++ m_rpm;} private: int m_rpm {0};}; class Car {public: Car (upl:: unique <Engine> engine): m_engine {std:: move (engine)} {} void replaceEngine (upl:: unique <Engine> engine) {m_engine = std:: move (engine);} upl:: unique <Engine> releaseEngine () {return std:: move (m_engine);} private: upl:: unique <Engine> m_engine;}; class Monitor {public: Monitor (upl:: weak <Engine> engine): m_engine {engine} {} void replaceEngine (upl:: weak <Engine> engine) {m_engine = engine;} //This method is executed in a separate thread. void activate () {using namespace std; upl:: unified <Engine> engine_lock = m_engine.lock (); if (engine_lock) cout <<"Engine rpm =" <<(*engine_lock).rpm () <<endl; else cout <<"No engine" <<endl;} private: upl:: weak <Engine> m_engine;} ; int main () {using namespace std; upl:: unique <Engine> engine_1 {in_place}; upl:: unique <Monitor> monitor_1 {in_place, engine_1}; upl:: unique <Car> car_1 {in_place, move (engine_1)}; (*monitor_1).activate (); (*monitor_1).activate (); engine_1 = (*car_1).releaseEngine (); upl:: unique <Monitor> monitor_2 {in_place, engine_1}; upl:: unique <Car> car_2 {in_place, move (engine_1)}; (*monitor_1).activate (); (*monitor_2).activate (); upl:: unique <Engine> engine_2 {in_place}; (*monitor_2).replaceEngine (engine_2); (*car_2).replaceEngine (move (engine_2)); (*monitor_1).activate (); (*monitor_2).activate (); return 0;} the Output: Engine rpm = 1 Engine rpm = 2 Engine rpm = 3 Engine rpm = 4 No engine Engine rpm = 1

55

Re: Unified Pointer Library

Hello, vopl, you wrote: V> And look for QPointer: V> V> A guarded pointer, QPointer <T>, behaves like a normal a C ++ pointer T *, except that it is automatically set to 0 when the referenced object is destroyed (unlike normal a C ++ pointers, which become "dangling pointers" in such cases). T must be a subclass of QObject. V> It, is hardly closer Smart observers to use with unique_ptr V> And? Instead of implicit  to use such notified not-owning the pointer. Well and a multiflow to resolve not prolongation of life and classically, locks. From the notifying not owning pointer in a multiflow of sense it is not enough. The object can die after pointer check. For the same reason there is not enough sense from std:: shared_ptr:: use_count (). And std:: shared_ptr:: unique () deprecated in the C ++ 17 also will be removed in a C ++ 20. Operation lock () is necessary that. As as it will lokirovatsja/be locked there - can depend on implementation and demanded variants of usage. To Someone lock is necessary, to another - life prolongation. But, on good, the algorithm of operation with pointers should be identical. Also it is necessary to track, that it is simple so it was impossible to take away possession. That there was any logic what possession where it is possible to copy/move, and where it is impossible. It is desirable, that all it was with the homogeneous interface. Means of pointers With ++ it seemed to me insufficiently, therefore and the beginnings  with UPL.

56

Re: Unified Pointer Library

Hello, ViTech, you wrote: S>> the Author See above: so5team Date: 18.06 16:05 - the elementary wrapper UniqueEngine (in which shared_ptr) allows you to close this strange scenario. VT> All is good, only from UniqueEngine:: weak_ref () it is possible to receive std:: shared_ptr <Engine>, with all that it implies. And UniqueEngine becomes not such unique. It reminds a joke: "the Doctor when I do here so to me it is sick! - well also do not do so". These you Whence undertake "all following?" Only as a result of your actions inside Monitor. If you, receiving from weak_ptr a copy shared_ptr start to push it where not , that, unconditionally, all following to you are provided. VT> for example, here "case". Let everyone defines, how much it idiotic. At first, this case is straight off implemented for the account shared_ptr/weak_ptr from stdlib. Without any indirect bicycles. Yes, if someone curve hands in Monitor received shared_ptr <Engine> starts to use not on business on hands does not receive. It is necessary to understand only, whether there are such warranties of to involve your library. Secondly, as a matter of fact you would like to have the following dial-up of concepts: MasterPointer <T>." Owning "the clever pointer. Can be in singular. Moveable but not Copyable. From MasterPointer it is possible to receive WeakPointer. WeakPointer <T>. std:: weak_ptr, but the basic difference that from WeakPointer it is possible to receive only SlavePointer, but it is impossible to receive analog MasterPointer. Copyable + Moveable. SlavePointer <T>." Not owning "the clever pointer. It turns out from WeakPointer. Prolongs object life. But from SlavePointer it is impossible to receive MasterPointer. Copyable + Moveable. With such entities at you in Car will be it is stored MasterPointer <Engine>, in Monitor - WeakPointer <Engine> and when Monitor it is necessary to guarantee lifetime Engine on any interval Monitor from WeakPointer receives SlavePointer <Engine>. And, (MasterPointer, WeakPointer, SlavePointer) it is possible to make all these things very thin wrappers over std:: shared_ptr and std:: weak_ptr. And, it appears, it turns out to support automatically and std:: enable_shared_from_this. PS. Name SlavePointer hardly the successful. Instead of it it is possible to use something like TemporaryPointer or ProlongingPointer. Or generally to refuse this essence, adding in WeakPointer a type method: template <typename OnSuccess, typename OnFailure> decltype (auto) try_acquire_then_handle (OnSuccess on_success, OnFailure on_failure) {auto shptr = handle_. lock (); if (shptr) return on_success (*shptr); else return on_failure ();} That allows to do: void activate () {engine_. try_acquire_then_handle ([] (auto and engine) {cout <<"Engine rpm:" <<engine.rpm () <<endl;}, [] () {cout <<"No engine" <<endl;});}

57

Re: Unified Pointer Library

Hello, so5team, you wrote: <offtopic> master/slave today became outdated and are accused of racism. It is necessary to use other analogs, as for example, leader/follower https://github.com/django/django/pull/2692 </offtopic>

58

Re: Unified Pointer Library

Hello, so5team, you wrote: S> At first, this case is straight off implemented for the account shared_ptr/weak_ptr from stdlib. Without any indirect bicycles. Yes, if someone curve hands in Monitor received shared_ptr <Engine> starts to use not on business on hands does not receive. It is necessary to understand only, whether there are such warranties of to involve your library. It is possible. Actually about warranties and speech. Hands be not mandatory curves can, they can be inattentive or tired. Type: "Be compiled already and lag behind me. It was launched? Well. Tests transited? Remarkably!". It if tests generally are also they something useful check. Therefore it would be desirable more warranties from the compiler and basic tools. S> Secondly, as a matter of fact you would like to have the following dial-up of concepts: S> S> MasterPointer <T>." Owning "the clever pointer. Can be in singular. Moveable but not Copyable. From MasterPointer it is possible to receive WeakPointer. S> WeakPointer <T>. std:: weak_ptr, but the basic difference that from WeakPointer it is possible to receive only SlavePointer, but it is impossible to receive analog MasterPointer. Copyable + Moveable. S> SlavePointer <T>." Not owning "the clever pointer. It turns out from WeakPointer. Prolongs object life. But from SlavePointer it is impossible to receive MasterPointer. Copyable + Moveable. S> S> With such entities at you in Car will be it is stored MasterPointer <Engine>, in Monitor - WeakPointer <Engine> and when Monitor it is necessary to guarantee lifetime Engine on any interval Monitor from WeakPointer receives SlavePointer <Engine>. S> And, (MasterPointer, WeakPointer, SlavePointer) it is possible to make all these things very thin wrappers over std:: shared_ptr and std:: weak_ptr. And, it appears, it turns out to support automatically and std:: enable_shared_from_this. I transited these all stages. And the titles  the foolish invented. And thin wrappers over std:: shared_ptr and std:: weak_ptr did. Here for me anything new is not present. Only under all any basis should be it. I found a suitable theoretical basis in UML, it is necessary to apply optimally only it in a C ++, in its realities "not to pay that you do not use", and in multithreading realities. It would be desirable to project, and on the developed model normally to write programs, instead of on scraps and crutches. Equally as it would not be desirable to produce new entities and to write bicycles. S> PS. Name SlavePointer hardly the successful. Instead of it it is possible to use something like TemporaryPointer or ProlongingPointer. Here evolution was such: Locker-> Scoped-> Unified. S> Or generally to refuse this essence, adding in WeakPointer a type method:... It already a trick. When the necessary dial-up of entities and their operations will be defined. Concerning an example above. I hope all represent what associative communications between Engine/Car/Monitor. In particular that Car it is unique owns Engine and Monitor has a weak reference on Engine. This normal desire to have such UML model and is correct to implement it in a C ++? And all it works in a multithreading. We admit, such unique possession implemented any wrapper of a certain thickness, with usage UPL or without. The desire to suppose a command, for example, (*car_2).replaceEngine (move (engine_2)) is how much normal; in queue of commands? What means most easier to organize queue of commands?

59

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT> Therefore it would be desirable more warranties from the compiler and basic tools. Here there are two problems. At first, you unique is Copyable type. I.e. it any not unique and tired hands can make a superfluous copy unique and anybody on them does not strike. Hence, your attempts to receive any warranties fail your design choices. Secondly, you could not explain distinctly at once what for your library is necessary. It is an excellent marker of that you do not understand accurately what exactly to you it is necessary. Hence,  to take the library which author does not give itself the report in that, as what for it does. VT> I transited these all stages. And the titles  the foolish invented. And thin wrappers over std:: shared_ptr and std:: weak_ptr did. Here for me anything new is not present. Only under all any basis should be it. I found a suitable theoretical basis in UML, it is necessary to apply optimally only it in a C ++, in its realities "not to pay that you do not use", and in multithreading realities. It would be desirable to project, and on the developed model normally to write programs, instead of on scraps and crutches. Equally as it would not be desirable to produce new entities and to write bicycles. So you also made it. And the reason is clear: at you porridge in a head. Therefore you also think that concepts from UML (which not the fact that you generally understood) should be displayed naturally on a C ++. From here and consequences: the library of the bicycles, which essence to very few people except you is clear. VT> in particular that Car is unique owns Engine and Monitor has a weak reference on Engine. At you here a schizophrenia. If Car it is unique owns Engine Monitor cannot influence lifetime Engine. Any not unique, but joint possession otherwise turns out. At you other requirement: Engine can be installed only in one Car. Or can belong only to a warehouse. Or can is only in one workshop, and that is virtual, being disassembled on spare parts. It absolutely other requirement. Which not the fact that it is necessary to express through system of clever pointers. For example, you easily can use std:: shared_ptr/std:: weak_ptr for pointer storage on Engine. But for expression of concept of possession you can make any OwningToken <T>. To receive this OwningToken it is possible only from unique_ptr (or ancestor function make_owning_token). Accordingly, from std:: shared_ptr you OwningToken do not receive. Therefore can does not worry that in Monitor from weak_ptr it turns out shared_ptr, and this shared_ptr then will be used for support of "possession" by object.

60

Re: Unified Pointer Library

Hello, so5team, you wrote: S> Here there are two problems. S> At first, you unique is Copyable type. I.e. it any not unique and tired hands can make a superfluous copy unique and anybody on them does not strike. Hence, your attempts to receive any warranties fail your design choices. From what you took, what can make a copy upl:: unique? You tried? If it so, means it an error and I will correct it. In remaining, I understood your position, and I do not want to come on the next circle of arguing same. Thanks for your judgement and attempt to understand. It would be desirable to hear judgements of other participants of a forum.

61

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT> From what you took, what can make a copy upl:: unique? You tried? And here this conversion from unique in unified and is reverse as to perceive?: https://gitlab.com/UnifiedPointers/Exam … n.cpp#L139

62

Re: Unified Pointer Library

Hello, so5team, you wrote: VT>> From what you took, what can make a copy upl:: unique? You tried? S> and here this conversion from unique in unified and is reverse as to perceive?: https://gitlab.com/UnifiedPointers/Exam … n.cpp#L139 it needs to be perceived as relocation. If unified that refers on existing unique, at attempt will copy/move this unified in another unique the exception is thrown out.

63

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT> Hello, vopl, you wrote: V>> And look for QPointer: V>> V>> A guarded pointer, QPointer <T>, behaves like a normal a C ++ pointer T *, except that it is automatically set to 0 when the referenced object is destroyed (unlike normal a C ++ pointers, which become "dangling pointers" in such cases). T must be a subclass of QObject. V>> It, is hardly closer Smart observers to use with unique_ptr V>> And? Instead of implicit  to use such notified not-owning the pointer. Well and a multiflow to resolve not prolongation of life and classically, locks. VT> from the notifying notified not owning pointer in a multiflow of sense it is not enough. The object can die after pointer check. Well, if so in a forehead,  - it is finite, does not grow together anything It is supposed "not check-then-use and"capture-use-release".

64

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT> It needs to be perceived as relocation. If unified that refers on existing unique, at attempt will copy/move this unified in another unique the exception is thrown out. Well i.e. you also transfer checks from compile-time in run-time. One more big fat "plus".

65

Re: Unified Pointer Library

Hello, vopl, you wrote: V>>> It, is hardly closer Smart observers to use with unique_ptr V>>> And? Instead of implicit  to use such notified not-owning the pointer. Well and a multiflow to resolve not prolongation of life and classically, locks. VT>> from the notifying notified not owning pointer in a multiflow of sense it is not enough. The object can die after pointer check. V> well if so in a forehead,  - it is finite, does not grow together anything It is supposed "not check-then-use and"capture-use-release". It is possible, probably, in the control unit any  to drag, as an implementation variant why is not present. If I am not mistaken, prolongation of life of object, only not for the account of temporal capture of possession, and holding/blocking of possession at the owner too turns out. And, probably, it is necessary to wait on a visit deadlock'. Also, how much I know, to locking circuits are not so glad task based thread pool, Intel TBB type.

66

Re: Unified Pointer Library

Hello, so5team, you wrote: S> Hello, ViTech, you wrote: VT>> It needs to be perceived as relocation. If unified that refers on existing unique, at attempt will copy/move this unified in another unique the exception is thrown out. S> well i.e. you also transfer checks from compile-time in run-time. One more big fat "plus". All that can be checked up in compile-time - it is checked in compile-time. Remaining in run-time.

67

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT> Hello, so5team, you wrote: S>> Tell, and you can make task setting normal language? S>> and that phrases like "for normal support of unique possession (composite aggregation) that integrity of communications" was observed are not clear from a word absolutely. S>> Well and "std:: unique_ptr in std:: function <void ()> does not climb" as it would be advisable to decrypt. You are restricted by C frames ++ 11? And so does not go? #include <memory> #include <functional> #include <iostream> using namespace std; void foo (shared_ptr <int> ptr) {cout <<"foo shared:" <<*ptr <<endl;} void bar (unique_ptr<int>& ptr) {cout <<"bar unique:" <<*ptr <<endl;} int main () {auto s = make_shared <int> (7); function <void ()> foo_f = bind (&foo, move (s)); foo_f (); auto u = make_unique <int> (7); auto bar_f = bind (&bar, move (u)); bar_f (); return 0;}

68

Re: Unified Pointer Library

Hello, Igore, you wrote: I> And so does not go? I>... So goes, if it is necessary to cause or transfer at once Callable object in function which receives such object in sample parameter (for example, std:: thread:: thread ()). But in one container (std:: queue, std:: vector, etc.) it is impossible to suppose different bind or lambda (even with identical a problem). Such it can be necessary, if it is required to organize queue of commands. std:: function fulfills a role of the general-purpose container for various types of "commands": bind, lambda, etc. And further std:: function with different commands it is possible to add in one container (std:: queue, std:: vector). But: "std:: function satisfies the requirements of CopyConstructible and CopyAssignable." . I.e. it can be copied, and at the same time and all bound arguments among which can be and not copied objects. Though with "a command" high probability in the code will be moved only, instead of to be copied, but at compilation std:: function its designer of copying who will copy Callable the object, which not copied will gather. It is one of hitches which inclined a bowl of scales towards separate implementation of pointers upl, based not on usage std:: shared_ptr/weak_ptr in quality backend'. But I found other crutch for bypass of this situation which allows to return to implementation with usage std:: shared_ptr/weak_ptr. Thus it is necessary to sacrifice a part of possibilities of pointers upl, but implementation will be easier, and it will not be necessary to invent a bicycle for it.