1

Topic: Unified Pointer Library

I do such piece. Can still to whom it is useful. Unified Pointer Library (the description in Russian) - the library of unitized pointers (UPL), contains  and implementations of clever pointers which are intended for control of lifetime of objects. Gives pointers upl:: unique and upl:: shared for unique and joint possession of objects, weak references for them upl:: weak, and adds unitized type of possession upl:: unified. The public interface of unitized pointers is similar to the interface of clever pointers of standard library of a C ++. Key singularities: Possibility of the organization of the associative communications between objects according to UML. Are defined  which in compile-time allow to define floppy type of pointers UPL in the generalized algorithms. 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. With the help upl:: unified it is possible to prolong temporarily object lifetime in the given area of visibility that allows to complete correctly operation with it, even when all remaining pointers on this object are remote. Pointers with unary frequency rate which cannot be empty are added and always refer to one object. Library header-only, license MIT.

2

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT> I Do such piece. Can still to whom it is useful. VT> Unified Pointer Library (the description in Russian) - the library of unitized pointers (UPL), contains  and implementations of clever pointers which are intended for control of lifetime of objects. Gives pointers upl:: unique and upl:: shared for unique and joint possession of objects, weak references for them upl:: weak, and adds unitized type of possession upl:: unified. The public interface of unitized pointers is similar to the interface of clever pointers of standard library of a C ++. Cool! we Wait Unified Math Library, Unified GUI Libaray and Unified Coroutine and Threading Library.

3

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT> I Do such piece. Can still to whom it is useful. VT> Unified Pointer Library (the description in Russian) - the library of unitized pointers (UPL), contains  and implementations of clever pointers which are intended for control of lifetime of objects. Gives pointers upl:: unique and upl:: shared for unique and joint possession of objects, weak references for them upl:: weak, and adds unitized type of possession upl:: unified. The public interface of unitized pointers is similar to the interface of clever pointers of standard library of a C ++. What problems dared at creation of library which cannot solve standard pointers?

4

Re: Unified Pointer Library

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.

5

Re: Unified Pointer Library

Hello, ViTech, you wrote: NB>> what problems dared at creation of library which cannot solve standard pointers? VT> for example, with these two points I had difficulties at the decision by means of standard pointers: VT> the Pointer upl:: weak can refer to object which is under control upl:: unique. Whether that with such pointer it is possible to do except how to check up the object is live or not? VT> the Pointer upl:: unified allows to transfer unique possession of object in a chain where copying can be fulfilled. What thus happens with remaining ?

6

Re: Unified Pointer Library

Hello, night beast, you wrote: VT>> the Pointer upl:: weak can refer to object which is under control upl:: unique. Whether NB> that with such pointer it is possible to do except how to check up the object is live or not? It is possible: with the help upl:: unified it is possible to prolong temporarily object lifetime in the given area of visibility that allows to complete correctly operation with it, even when all remaining pointers on this object are remote. Usage example. VT>> the pointer upl:: unified allows to transfer unique possession of object in a chain where copying can be fulfilled. NB> that thus happens with remaining ? Unique possession from upl:: unique needs to be moved in upl:: unified which on the way can and be copied. At attempt to transfer possession in upl:: unique from other pointer, the exception if the object already is in someone's possession will be thrown out. Example TransferUnique.

7

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT>>> the Pointer upl:: weak can refer to object which is under control upl:: unique. Whether NB>> that with such pointer it is possible to do except how to check up the object is live or not? VT> It is possible: VT> VT> with the help upl:: unified it is possible to prolong temporarily object lifetime in the given area of visibility that allows to complete correctly operation with it, even when all remaining pointers on this object are remote. At attempt to use  the object from the core is moved and on termination of reverse is not returned? What real tasks are solved such by stranger ? VT>>> the Pointer upl:: unified allows to transfer unique possession of object in a chain where copying can be fulfilled. NB>> that thus happens with remaining ? VT> Unique possession from upl:: unique needs to be moved in upl:: unified which on the way can and be copied. At attempt to transfer possession in upl:: : unique from other pointer, the exception if the object already is in someone's possession will be thrown out. Example TransferUnique. .  it is all absolutely useless hogwash creating problems out of the blue.

8

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT> the Pointer upl:: weak can refer to object which is under control upl:: unique. Any  in the pure state. unique_ptr it is intended for situations when there should be only one pointer on object. And possession unique_ptr th defines object lifetime to which refer. And, from the point of view of efficiency of implementation (very important, as we in a C ++) the key moment that unique_ptr does not use any form of reference counting (i.e. there is no latent overhead charge). If it not so, i.e. on statements of the problem the strong object reference (for determination of time of his life) and, at the same time, weak references to you it is necessary not unique_ptr, and just  shared_ptr is necessary to you. What for it can be demanded unique which not unique, and essence shared, to understand from your pseudoscientific determinations resolutely it is not possible.

9

Re: Unified Pointer Library

Hello, night beast, you wrote: NB> at attempt to use  the object from the core is moved and on termination of reverse is not returned? NB> what real tasks are solved such by stranger ?  sudden death of the object which is in unique possession, in the presence of weak references to it. NB> .  it is all absolutely useless hogwash creating problems out of the blue. For you the hogwash, and for me is not present. Someone and raw pointers suffices.

10

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT> [] the Pointer upl:: weak can refer to object which is under control upl:: unique. That that at me the template a little 1 was tore. "upl:: unique" - explicitly assumes "uniqueness" of possession of storable object under the pointer 2. upl:: weak over upl:: unique - destroys this uniqueness as the specified object is accessible now more than from one pointer unique uniqueness turned out not?

11

Re: Unified Pointer Library

Hello, kov_serg, you wrote: _> we Wait Unified Math Library, Unified GUI Libaray and Unified Coroutine and Threading Library. And as Unified Qt Library, Unified STL Library and Unified Boost Library.

12

Re: Unified Pointer Library

Hello, so5team, you wrote: VT>> the Pointer upl:: weak can refer to object which is under control upl:: unique. S> Any  in the pure state. unique_ptr it is intended for situations when there should be only one pointer on object. And possession unique_ptr th defines object lifetime to which refer. And, from the point of view of efficiency of implementation (very important, as we in a C ++) the key moment that unique_ptr does not use any form of reference counting (i.e. there is no latent overhead charge). If such variant of usage is necessary to you, std:: unique_ptr for this purpose and is. If to look from the point of view of the associative communications UML uniqueness is a property of the associative communication in object-owner, instead of object to which refer. S> if it not so, i.e. On statements of the problem the strong object reference (for determination of time of his life) and, at the same time, weak references to you it is necessary not unique_ptr, and just  shared_ptr is necessary to you. S> What for it can be demanded unique which not unique, and essence shared, to understand from your pseudoscientific determinations resolutely it is not possible. These "pseudoscientific determinations" especially and not mine, they in UML are described. If to you the section the Associative communications is not clear, this library means to you is not necessary.

13

Re: Unified Pointer Library

Hello, ViTech, you wrote: NB>> at attempt to use  the object from the core is moved and on termination of reverse is not returned? NB>> what real tasks are solved such by stranger ? VT> Juzkejs of sudden death of the object which is in unique possession, in the presence of weak references to it. No. What  a case of weak references which take away possession?

14

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT> If such variant of usage is necessary to you, std:: unique_ptr for this purpose and is. If to look from the point of view of the associative communications UML uniqueness is a property of the associative communication in object-owner, instead of object to which refer. Or a brothel consequence in your head because of which you cannot spread out already existing types of clever pointers "on shelves" and invent the bicycles, being covered . Thus it is not eliminated that from UML you as do not understand associativity because of the same brothel. S>> what for it can be demanded unique which not unique, and essence shared, to understand from your pseudoscientific determinations resolutely it is not possible. VT> These "pseudoscientific determinations" especially and not mine, they in UML are described. Most likely there is a huge difference between: that is described in UML; that you perceived; how you the perception "supposed" on C possibility ++. VT> If to you the section the Associative communications is not clear, this library means to you is not necessary. A syndrome of not recognized genius? We admit that it not so that you really made the useful piece. Explain, please, in what conditions it to somebody generally can be demanded. While in all subject of made explanations yet was not.

15

Re: Unified Pointer Library

Hello, night beast, you wrote: NB> is not present. What  a case of weak references which take away possession? They do not take away possession. They allow to give access to object in function/method, and to support object life for this time, with the registration of that in other flow, during the same time, initial upl:: unique can be deleted. If to try from weak to receive unified and then unique the exception if on object there is other strict link should be thrown out.

16

Re: Unified Pointer Library

Hello, vopl, you wrote: V> Hello, ViTech, you wrote: VT>> [] the Pointer upl:: weak can refer to object which is under control upl:: unique. V> That that at me the template a little V> 1 was tore. "upl:: unique" - explicitly assumes "uniqueness" of possession of storable object under the pointer V> 2. upl:: weak over upl:: unique - destroys this uniqueness as the specified object is accessible now more than from one pointer V> unique uniqueness turned out not? If the object is under control std:: unique_ptr anybody is more and never can address to this object (except the owner)? I consider possession from the point of view of the associative communications UML where weak for unique is an opposite pole of association. From such point of view there is any contradiction?

17

Re: Unified Pointer Library

Hello, ViTech, you wrote: NB>> is not present. What  a case of weak references which take away possession? VT> they do not take away possession. They allow to give access to object in function/method, and to support object life for this time, with the registration of that in other flow, during the same time, initial upl:: unique can be deleted. If to try from weak to receive unified and then unique the exception if on object there is other strict link should be thrown out. That is for the period of access provision to object in function/method exists two  ( with the counter of links = 2)?

18

Re: Unified Pointer Library

Hello, night beast, you wrote: VT>> They do not take away possession. They allow to give access to object in function/method, and to support object life for this time, with the registration of that in other flow, during the same time, initial upl:: unique can be deleted. If to try from weak to receive unified and then unique the exception if on object there is other strict link should be thrown out. NB> that is for the period of access provision to object in function/method exists two  ( with the counter of links = 2)? It is necessary to divide concepts "possession" and "access". To the object which is in unique possession, other objects can get access? I consider, what yes, can. But they not can so to receive simply possession of it. So in function/method the owner will be one, and through unified it is possible to receive access many times, and to hold its (access), in case of need. In current implementation for strict possession (unique, shared) and for access (unified) different counters are used.

19

Re: Unified Pointer Library

Hello, so5team, you wrote: S> we Admit that it not so that you really made the useful piece. Explain, please, in what conditions it to somebody generally can be demanded. While in all subject of made explanations yet was not. 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. If to follow example TransferUnique I want that Car it is unique owned Engine. And that it was possible to transfer possession Engine or from factory, or removing from another Car, through queue of messages/commands. std:: unique_ptr in std:: function <void ()> does not climb. It is possible to send crude pointers, but it is not pleasant to me.

20

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT>>> [] the Pointer upl:: weak can refer to object which is under control upl:: unique. V>> That that at me the template a little V>> 1 was tore." upl:: unique "- explicitly assumes"uniqueness"of possession of storable object under the pointer V>> 2. upl:: weak over upl:: unique - destroys this uniqueness as the specified object is accessible now more than from one pointer V>> unique uniqueness turned out not? VT> if the object is under control std:: unique_ptr anybody is more and never can address to this object (except the owner)? I consider possession from the point of view of the associative communications UML where weak for unique is an opposite pole of association. From such point of view there is any contradiction? With such - contradictions are not present. The original question was not about an opposite pole. class Car; class Engine; class Car {upl:: unique <Engine> engineStrong;//we consider this unique as an association pole" the machine [0,1] - [0,1] engine "upl:: weak <Engine> engineWeak;//an alternative pole for engineStrong. Here about it speech. With it of a problem.} ; class Engine {unspecified <Car> car;//opposite for engineStrong+engineWeak, can be upl:: weak, and that another can that. Does not interest};

21

Re: Unified Pointer Library

Hello, ViTech, you wrote: S>> we Admit that it not so that you really made the useful piece. Explain, please, in what conditions it to somebody generally can be demanded. While in all subject of made explanations yet was not. 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. If to follow example TransferUnique I want that Car it is unique owned Engine. And that it was possible to transfer possession Engine or from factory, or removing from another Car, through queue of messages/commands. std:: unique_ptr in std:: function <void ()> does not climb. It is possible to send crude pointers, but it is not pleasant to me. Tell, and you can make task setting normal language? 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. 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?

22

Re: Unified Pointer Library

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? I.e. what happens in this example, in particular here, to you it is not clear? Well, here shorter variant: #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); function <void ()> bar_f = bind (&bar, move (u));//error: conversion from ' std:: _Bind_helper <false, void (*) (std:: unique_ptr <int>)... bar_f (); return 0;}

23

Re: Unified Pointer Library

Hello, vopl, you wrote: V> With such - contradictions are not present. The original question was not about an opposite pole. V> V> class Car; V> class Engine; V> class Car V> {V> upl:: unique <Engine> engineStrong;//this is considered unique as an association pole "the machine [0,1] - [0,1] engine" V> upl:: weak <Engine> engineWeak;//an alternative pole for engineStrong. Here about it speech. With it of a problem. V>}; V> class Engine V> {V> unspecified <Car> car;//opposite for engineStrong+engineWeak, can be upl:: weak, and that another can that. Does not interest V>}; V> It is admissible, there is a class which watches of the engine: class Monitor {upl:: weak <Engine> engineWeak;} 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?

24

Re: Unified Pointer Library

Hello, ViTech, you wrote: VT> I.e. that there is in this example a Code implements your sight at a problem, instead of describes a problem. So, whether you can describe task setting by normal language? And what exactly you imply, when speak: "for normal support of unique possession (composite aggregation) that integrity of communications" VT> Well, here shorter variant was observed: Now it is clear about what you.

25

Re: Unified Pointer Library

Hello, so5team, you wrote: S> And what exactly you imply when speak: "for normal support of unique possession (composite aggregation) that integrity of communications" 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?