26

Re: Unified Pointer Library

Hello, ViTech, you wrote: S>> And what exactly you imply when speak: "for normal support of unique possession (composite aggregation) that integrity of communications" VT> Hardly above an example with Car, Engine and Monitor was observed. For example, I want, that Car is unique owned Engine, and Monitor could watch for Engine. How suggest it to do by standard pointers With ++ in the multi-threaded environment to avoid a problem with dangling pointers? Or and it is not necessary so to do this strange desire? The most simple method is to use std:: shared_ptr. Because joint possession of object Engine (both in Car, and in Monitor) is real at you. As Engine cannot be destroyed earlier, than both die is both Car and Monitor. More difficult - to provide time supervision of life Car any with other means. For example, it is explicit in the program to destroy at first Monitor, then Car.

27

Re: Unified Pointer Library

Hello, ViTech, you wrote: Clearly. You stretched the settled terminology from one area on other area, it strongly confuses. Replace titles on what  closer to UML-association with associates, becomes much better and more organic.

28

Re: Unified Pointer Library

Hello, so5team, you wrote: S> the Most simple method is to use std:: shared_ptr. Because joint possession of object Engine (both in Car, and in Monitor) is real at you. As Engine cannot be destroyed earlier, than both die is both Car and Monitor. Really at me Monitor does not own Engine in the code (upl:: weak), in model UML. If dies Engine Monitor it normally worries. He does not own Engine, only prolongs time of his life at the moment of operation with it if addressed to even existing object. And if the object was already deleted, and at reversal to it about it it will be known. All Is possible through std:: shared_ptr to do, if it is not necessary to observe unique communications. Well and models UML it will not correspond, if composite aggregation is registered in it. S> more difficult - to provide time supervision of life Car any with other means. For example, it is explicit in the program to destroy at first Monitor, then Car. Well so. But not the fact what to provide control of life of objects by other means is easier, than to invent weak for unique.

29

Re: Unified Pointer Library

Hello, ViTech, you wrote: S>> the Most simple method is to use std:: shared_ptr. Because joint possession of object Engine (both in Car, and in Monitor) is real at you. As Engine cannot be destroyed earlier, than both die is both Car and Monitor. VT> it is real at me Monitor does not own Engine in the code (upl:: weak), in model UML. At you porridge in a head. There is it because you cannot reconcile that there is a rupture between UML-models and singularities of their embodiment in the code in specific language. VT> if dies Engine Monitor it normally worries. Focus that at you both Car, and Monitor own Engine, you only do not find forces to yourselves in it to admit. Present a situation that on one worker thread Monitor  the link on Engine with weak on strong. And after that on other worker thread it will be destroyed Car. After all at you Engine remains it is live until in Monitor the string-reference on Engine does not die. And it is that other as influence on lifetime, i.e. that joint possession, which presence you cannot recognize in any way. And instead of calling things by their proper names you do own bicycle which repeats functionality shared_ptr, but tangles the programmer pseudo-concepts upl:: unique and upl:: universal (or as they there at you are called).

30

Re: Unified Pointer Library

Hello, XOOIOOX, you wrote: XOO> Hello, kov_serg, you wrote: _>> we Wait Unified Math Library, Unified GUI Libaray and Unified Coroutine and Threading Library. XOO> And as Unified Qt Library, Unified STL Library and Unified Boost Library. It is necessary to eat an elephant in parts

31

Re: Unified Pointer Library

Hello, vopl, you wrote: V> it is clear. You stretched the settled terminology from one area on other area, it strongly confuses. Replace titles on what  closer to UML-association with associates, becomes much better and more organic. Contact of areas is described in section Possession. We admit, instead of upl:: unique there will be a title upl:: composite, what title offer for the pointer which expresses AggregationKind:: none? I suspect that on questions: "That it for upl:: composite the such?", it should to answer:" Well it as std:: unique_ptr ". And in general not all so is simple, as can seem at first sight. In library UPL terminology of pointers is used specially not to load concepts UML and was customarier to pass/use together with clever pointers of a C ++. It is necessary to specify only that these pointers express semantics of the associative communications. Also can be, roughly speaking, as std:: optional and gsl:: not_null. UPL is the facilitated dial-up, with a minimum of dependences and without jungle UML. For jungle UML there is a separate project: CppUml.

32

Re: Unified Pointer Library

Hello, so5team, you wrote: S> At you porridge in a head. There is it because you cannot reconcile that there is a rupture between UML-models and singularities of their embodiment in the code in specific language. I look, you very well know that at others in heads happens. S> focus that at you both Car, and Monitor own Engine, you only do not find forces to yourselves in it to admit. Present a situation that on one worker thread Monitor  the link on Engine with weak on strong. And after that on other worker thread it will be destroyed Car. S> After all at you Engine remains it is live until in Monitor the string-reference on Engine does not die. And it is that other as influence on lifetime, i.e. that joint possession, which presence you cannot recognize in any way. Focus what such behavior also is necessary for me. That in an operating time with Engine in Monitor there was no embarkation in the middle of method operation. As a variant, it is possible to lock a flow which wants to delete object while with it other flows work. It is not assured that this variant is better. It is possible to try, before removal Engine in Car to delete all weak-references to it, but it too can be uneasy. Thus, I want to separate unique possession Engine in Car from the joint. Yes, I want to write programs according to models UML. S> And instead of calling things by their proper names you do own bicycle which repeats functionality shared_ptr, but tangles the programmer pseudo-concepts upl:: unique and upl:: universal (or as they there at you are called). If functionality std:: shared_ptr suffices you, and any pseudo-concepts and it is fine are not necessary. Also we will consider that you unmasked me, and other programmers notified about heresy in UPL.

33

Re: Unified Pointer Library

Hello, ViTech, you wrote: S>> After all at you Engine remains it is live until in Monitor the string-reference on Engine does not die. And it is that other as influence on lifetime, i.e. that joint possession, which presence you cannot recognize in any way. VT> focus what such behavior also is necessary for me. Focus what such behavior both gives you shared_ptr. Also there is no need for the invention of its analogs with misleading names. If you so want to have "the owning pointer", instead of bare shared_ptr there is nothing difficult in wrapper creation: class UniqueEngine {std:: shared_ptr <Engine> engine _; public: UniqueEngine (const UniqueEngine) = disable; UniqueEngine (UniqueEngine &&) = default; UniqueEngine (std:: unique_ptr <Engine> en): engine _ (std:: move (en)) {}... std:: weak_ptr <Engine> weak_ref () {return {engine _};}...} ;... class Car {UniqueEngine engine _;... public: auto engine () {return engine_. weak_ref ();}}; class Monitor {std:: weak_ptr <Engine> engine _;...}; But also it already  any. You generally need simply something like: class Car: public std:: enable_shared_from_this {Engine engine _; public: std:: weak_ptr <Engine> engine () {return {std:: shared_ptr <Engine> (shared_from_this (), &engine)};};}; VT> Yes, I want to write programs according to models UML. Write. Only at first understand what naturally concepts from UML lay down on a C ++, instead of invent bicycles. VT> if functionality std:: shared_ptr suffices you, and any pseudo-concepts and all right it is not visible the objective reasons to invent still something moreover are not necessary. And you cannot result sensible arguments.

34

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT> Hello, vopl, you wrote: V>> it is clear. You stretched the settled terminology from one area on other area, it strongly confuses. Replace titles on what  closer to UML-association with associates, becomes much better and more organic. VT> contact of areas is described in section Possession. We admit, instead of upl:: unique there will be a title upl:: composite, what title offer for the pointer which expresses AggregationKind:: none? I suspect that on questions: "That it for upl:: composite the such?", it should to answer:" Well it as std:: unique_ptr ". Yes even if it will be called composite (though probably it is possible and to find is better a name) - is assured, it is easier to person to esteem in advance the specification on this composite and at once to start it to think correctly, than seeing the is more common-common name of type unique pointer to start it to use with intuitive waitings and then to find out that it at all that.

35

Re: Unified Pointer Library

Hello, vopl, you wrote: V> Yes even if it will be called composite (though probably it is possible and to find is better a name) - is assured, it is easier to person to esteem in advance the specification on this composite and at once to start it to think correctly, than seeing the is more common-common name of type unique pointer to start it to use with intuitive waitings and then to find out that it at all that. It is possible to make is better much all, therefore it would be desirable to hear sentences under names. Also what confuses in behavior upl:: unique? What the object under its control is deleted not at once, and hardly  when with it methods of objects which have a weak reference to it stop to work? It and can be deleted at once, if with it at a present situation nobody works.

36

Re: Unified Pointer Library

Hello, ViTech, you wrote: What for bind if it is possible a simple lambda? bind assumes copying which is not present. What will do with other not copied classes? To create copied analogs as yours unique? function <void ()> foo_f = [and] {foo (move (s));}; function <void ()> bar_f = [and] {bar (move (u));};

37

Re: Unified Pointer Library

Hello, _NN _, you wrote: _NN> What for bind if it is possible a simple lambda? _NN> bind assumes copying which is not present. std:: bind just copying does not assume, it is possible to make auto some = bind (...); with relocation in it std:: unique_ptr. But here further this some in std:: function <void ()> to place it does not turn out, copying there is required. _NN> _NN> function <void ()> foo_f = [and] {foo (move (s));}; _NN> function <void ()> bar_f = [and] {bar (move (u));}; _NN> that happens, when the pointer quits visibility area? #include <memory> #include <functional> #include <vector> #include <iostream> using namespace std; void bar (unique_ptr <int> ptr) {cout <<"bar unique:" <<*ptr <<endl;} int main () {vector <function <void ()>> commands; {auto u = make_unique <int> (7); commands.push_back ([and] {bar (move (u));});} commands [0] (); return 0;} _NN> That will do with other not copied classes? To create copied analogs as yours unique? I will do Nothing. Clever pointers work with not copied classes. Pointers, instead of object are copied.

38

Re: Unified Pointer Library

Hello, ViTech, you wrote: V>> Yes even if it will be called composite (though probably it is possible and to find is better a name) - is assured, it is easier to person to esteem in advance the specification on this composite and at once to start it to think correctly, than seeing the is more common-common name of type unique pointer to start it to use with intuitive waitings and then to find out that it at all that. VT> It is possible to make is better much all, therefore it would be desirable to hear sentences under names. Unfortunately, did not like principles upl to depth, therefore hardly I can generate effective names VT> And what confuses in behavior upl:: unique? What the object under its control is deleted not at once, and hardly  when with it methods of objects which have a weak reference to it stop to work? It and can be deleted at once, if with it at a present situation nobody works. Well, here continuous ambushes You simply superimpose  on what bowl of scales that of the latent case. But it is necessary to understand that if you on the bowl that added that - that with another took away. For example, you killed determinancy of lifetime of specified object, and there is a great number of application-oriented cases in which such determinancy is necessary/is useful. For example, you essentially increased the expenditure of resources because for your case it not essentially, but for many the over-expenditure will be fatal. I drive to that "unifications" did not turn out. It turned out what that especially specific . Moreover and another's terminology used, than forced down all with sense, and with so5team even fought

39

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT> This piece, first of all, is necessary to me. It is necessary to me in working conditions in the multi-threaded environment for the organization of the associative communications between objects. In particular, for normal support of unique possession (composite aggregation) that integrity of communications was observed. It is a tin, certainly. I always thought that in UML there are three relationship types: aggregation, a composition and association (the general case of aggregation and a composition).

40

Re: Unified Pointer Library

41

Re: Unified Pointer Library

Hello, Maniacal, you wrote: M> It is a tin, certainly. I always thought that in UML there are three relationship types: aggregation, a composition and association (the general case of aggregation and a composition). Aside UML I heard one of critical remarks such that the specification is written by the too general words which everyone can interpret in own way. The only thing that I can make, so it to ask to read attentively sections "11.5 Associations" and "9.5 Properties" in edition UML 2.5. I was based on this edition, and, probably, something understood in own way.

42

Re: Unified Pointer Library

43

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT> That happens, when the pointer quits visibility area? It is the relocation contract. You use std:: move, know that you do.  it is possible and to write certainly bad code without relocation: vector <int> a; a.push_back (1); int* x = &a [0]; a.clear (); *x = 1; If it is necessary to hold some object references we transform unique_ptr in shared_ptr. auto a = unique_ptr <int> (new int (1)); auto b = shared_ptr <int> (move (a)); foo (b);//we can copy b without problems Also it is useful for function not to know more than it is necessary about life of objects. For example void bar (unique_ptr <int> ptr) {cout <<"bar unique:" <<*ptr <<endl;} can Quite accept the link/value: void bar (int value) {cout <<"bar unique:" <<value <<endl;}

44

Re: Unified Pointer Library

Hello, ViTech, you wrote: V>> Well, here continuous ambushes You simply superimpose  on what bowl of scales that of the latent case. But it is necessary to understand that if you on the bowl that added that - that with another took away. For example, you killed determinancy of lifetime of specified object, and there is a great number of application-oriented cases in which such determinancy is necessary/is useful. For example, you essentially increased the expenditure of resources because for your case it not essentially, but for many the over-expenditure will be fatal. I drive to that "unifications" did not turn out. It turned out what that especially specific . Moreover and another's terminology used, than forced down all with sense, and with so5team even I fought VT> in Introduction like the main singularities painted. Also did not speak: "Throw defective pointers of a C ++ and pass to the unitized pointers best in the world! Without  and registration!" . On the contrary, separately marked: VT> VT> 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. VT> a case too like not especially hidden: 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. Here, by the way, here dudes too stretched something from world UML on c ++. Simply as an example probably it will be interesting  theory UML  on syntax with ++ reduced all together

45

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT> If the engine will suddenly be deleted, the monitor should process such situation correctly. If in Car it will be used std:: unique_ptr <Engine> as suggest Monitor to write? To use std:: shared_ptr <Engine> for Car and std:: weak_ptr <Engine> for Monitor. In most Engine it is possible to manage or the normal pointer, or std:: weak_ptr.

46

Re: Unified Pointer Library

Hello, vopl, you wrote: V> Here, by the way, here dudes too stretched something from world UML on c ++. Simply as an example probably it will be interesting V>  theory UML V>  on syntax with ++ V> reduced Thanks all together for links. In With ++ from the different worlds much all stretched. But here  unique <-> weak (similar shared <-> weak) I something did not find a sheaf. Probably badly searched.

47

Re: Unified Pointer Library

Hello, sergii.p, you wrote: VT>> If the engine will suddenly be deleted, the monitor should process such situation correctly. If in Car it will be used std:: unique_ptr <Engine> as suggest Monitor to write? SP> to use std:: shared_ptr <Engine> for Car and std:: weak_ptr <Engine> for Monitor. In most Engine it is possible to manage or the normal pointer, or std:: weak_ptr. It is possible. But what to do, if it is necessary to provide requirement observance "one Engine it is possible to install only in one Car"?

48

Re: Unified Pointer Library

Hello, _NN _, you wrote: _NN> Hello, ViTech, you wrote: VT>> That happens, when the pointer quits visibility area? _NN> it is the relocation contract. _NN> you use std:: move, know that you do. _NN> Edak it is possible and to write certainly bad code without relocation: _NN> _NN> vector <int> a; _NN> a.push_back (1); _NN> int* x = &a [0]; _NN> a.clear (); _NN> *x = 1; _NN> _NN> If it is necessary to hold some object references we transform unique_ptr in shared_ptr. _NN> _NN> auto a = unique_ptr <int> (new int (1)); _NN> auto b = shared_ptr <int> (move (a)); _NN> foo (b);//we can copy b without problems _NN> _NN> Also it is useful for function not to know more than it is necessary about life of objects. _NN> for example _NN> _NN> void bar (unique_ptr <int> ptr) {cout <<"bar unique:" <<*ptr <<endl;} _NN> _NN> can Quite accept the link/value: _NN> _NN> void bar (int value) {cout <<"bar unique:" <<value <<endl;} _NN> Perhaps, I will simply agree with you. All of you correctly wrote.

49

Re: Unified Pointer Library

Hello, ViTech, you wrote: SP>> to use std:: shared_ptr <Engine> for Car and std:: weak_ptr <Engine> for Monitor. In most Engine it is possible to manage or the normal pointer, or std:: weak_ptr. VT> It is possible. But what to do, if it is necessary to provide requirement observance "one Engine it is possible to install only in one Car"? Etit-bang. Well transfer in designer Car a copy std:: unique_ptr <Engine>, and inside Car will be std:: shared_ptr <Engine>.

50

Re: Unified Pointer Library

Hello, so5team, you wrote: VT>> It is possible. But what to do, if it is necessary to provide requirement observance "one Engine it is possible to install only in one Car"? S> Etit-bang. Well transfer in designer Car a copy std:: unique_ptr <Engine>, and inside Car will be std:: shared_ptr <Engine>. We admit. weak_ptr for Monitor then whence to take (Car and Monitor do not know about each other, they know only Engine)? And if it wants to remove the engine from one car and to deliver in another how it to make?