Subject index:
First, analyze C standard library smart pointer (std :: auto_ptr) 1.Do you smart pointer? 2.std :: auto_ptr Design principle 3.std :: auto_ptr Advanced User Guide 4. Do you think std :: auto_ptr is not enough? perfect?
Second, C conditions, find a strategy for constructing more powerful smart pointers 1. Support for a number of design strategies for reference score 2. Support to process multiple resources 3. Support SubClassing 4. Support for multithreading conditions, thread security A variety of design strategies 5. Other special requirements, re-construct
Third, Generic Programming Basic Technology and Smart Pointer 1. Looking back to Traits Technology in Resources 2. Looking back over multithreaded support
Fourth, COM implementation, Smart Pointer design principle
V. Status of Smart Pointer in the famous C library (standard and non-standard)
-------------------------------------------------- -------------------
First, analyze C standard library smart pointer (std :: auto_ptr) 1.Do you smart pointer? Smart Pointer, Chinese name: smart pointer, shipping? It is undeniable, resource leaks, once a big nightmare for C programs. Garbage Collection (Garbage Collection) is very eye-catching. However, the garbage automatic recycling mechanism does not meet the instantaneous and visibility of memory management, often makes the proud programmer feel uncomfortable. Moreover, C implementation does not introduce this mechanism In the exploration, C programmers have created sharp "Smart Pointer". A certain extent, solving resource leakage problems.
Perhaps, often, you will write this code: // x intend to Class: // Class X {// public: // int m_idata; // public: // x (int m_paramin): m_idata (m_paramin) { } // void print () {cout << m_idata << Endl;} // .....//} // void fook () {x * m_ptrx = new a (m_paramin); m_ptrx-> dosomething () ; // # 2 delete m_ptrx;}
Yes, there may be no problem here. You can guarantee that you will not forget DELETE M_PTRCLASSOBJ in complex, N row, m_ptrclassobj, you will notify you don't forget DELETE M_PTRCLASSOBJ? In life, we often don't have too many Oral guarantee, we need to do something that is really useful. There is also a more sensitive question: exception. If the execution period is abnormal, the function is terminated, then the object of New is leaked. So, you may Will say: So capture an exception to ensure good security. You write such a program:
Void fook () {a * m_ptrx = new a (m_paramin); try {m_ptrx-> dosomething ();} catch (..) {delete m_ptrx; throw;} delete m_ptrx;} Oh! God! Imagine, you Whether it is designed to capture an exception. One day, some people give you recommendations: "It is safe.". You can write your program like this: void fook () {auto_ptr
OK! You don't believe it. Don't use DELETE? Yes. Don't use it all day to ask yourself: "Is I all DELETE?", And more secure than your delete strategy.
Then, someone tells you that can be used: ok1. Auto_ptr
Power1. auto_ptr1 (new x (100)); auto_ptr2-> m_smptr2 = m_smptr1; m_smptr2-> print (); // Output: 100. m_smptr1-> print (); //!! illegal. Power2. auto_ptr
// In the top # 5, I want to tell you that the object ownership is transferred twice. / / What is the object ownership? 2. Std :: auto_ptr Design principle The above correct usage, what are they doing? Illegal, what is the crime? What is the right to transfer, what is the internal wit? Oh! A fog? Let's draw on the realization mechanism. Basic knowledge: a. Smart pointer key technology: Tunctional stack The life of the object controls the life of the objects that constructs on the pile. Because the pointer of the object is stored inside the smart pointer, the delete behavior is called in the paxy function. The general mechanism is as follows: x * m_ptrx = new x (100 ); // # 1 Template
# 4 public: # 5 typedef _Tp element_type; // related type definition # 6 explicit auto_ptr (_Tp * __p = 0) __STL_NOTHROW: _M_ptr (__ p) {} # 7 auto_ptr (auto_ptr & __a) __STL_NOTHROW: _M_ptr (__ a.release () ) {} # 8 Template
// wrong! /// # 9 auto_ptr & operator = (auto_ptr & __a) __stl_nothrow {# 10 if (& __ a! = this) {delete _m_ptr; _m_ptr = __a.release ();} # 11 return * this; # 12} # 13 Template
// According to the C standard, these conversions are required. Most // present-day compilers, however, do not enforce that requirement --- and, // in fact, most present-day compilers do not support the language // FEATURES THAT THESE CONVERSITIONS RESELY ON. // This clip is used for type conversion, there is currently no compiler support // The specific technical details do not respond. # ifdef __sgi_stl_use_auto_ptr_conversions
# 27 private: # 28 template
# 30 public: # 31 auto_ptr (auto_ptr_ref <_Tp> __ref) __STL_NOTHROW: _M_ptr (__ ref._M_ptr) {} # 32 template
// // Const_T2 & __Value) { // // New (__P) _T1 (__ value); // } Part3. Template
// // Const_TP & __X) // {IF (_M_FINISH, * (_ M_FINISH - 1)); _ M_Finish ;
// //_TP __X_copy = __x; //
copy_backward (__ position, _M_finish - 2, _M_finish - 1); * __ position = __x_copy;} else {const size_type __old_size = size (); const size_type __len = __old_size = 0 2 * __old_size:!? 1; iterator __new_start = _M_allocate (__ len ); iterator __new_finish = __new_start; __STL_TRY {__new_finish = uninitialized_copy (_M_start, __position, __new_start); construct (__ new_finish, __x); __ new_finish; __new_finish = uninitialized_copy (__position, _M_finish, __new_finish);} __STL_UNWIND ((destroy (__ new_start, __new_finish), _M_deallocate (__ new_start, __ len))); destroy (begin (), end ()); _M_deallocate (_M_start, _M_end_of_storage - _M_start); _M_start = __new_start; _M_finish = __new_finish; _M_end_of_storage = __new_start __len;}} from the extract VECTOR code, PART1 can be seen, Push_Back's operation behavior. The soldiers are divided into two ways, but then look down, you will find that there is no exception, all through constell TP & Copy behavior, then send a field from the fragment raised from Auto_Ptr. But you know, auto_ptr always insists on object index. That must modify the object of maintenance, and the vector behavior requires const_tp &, so natural meeting Generate problems. General compilers can find such errors.
In fact, all containers in STL use const _tp & strategy. // Two articles in Sutter and Josuttis are mentioned: STL container does not support auto_ptr reasons The object of COPY is just a object of ownership, This object does not conform to the requirements of STL. But I always feel that it is not a real copy object, but I use Vector
NO5. The constructor that rely on the incoming object pointer is declared as explicit, disable implicit conversion.
3.Auto_ptr Advanced User Guide A. Class member Auto_PTR, disable constructor to build "full object" Program1: struct structX {int m_idata; char m_chrdata; / * and so on * /}; for object programming, we will Structx playing parcel: class StructWrapper {private: Structx * m_STRTxptr; public: StructWrapper (): m_STRTxptr (new Structx) {} ~ StructWrapper () {delete m_SMRTxptr;} public: void Soperator1 () {/ * for Structx object characteristics of operation * /} void Soperator2 () {/ * characteristic operation for Structx object * /} / * and so on * /}; Programme2: class StructWrapper {private: auto_ptr
In the need to construct the need to be intelligent maintenance in the heap. We transform the programme1 to Program2: Good, the object is smart to maintain. For the StructWrapper, you will have such a construct or assignment: StructWrapper m_SMPTRWrapper2 (m_SMPTRWrapper1); StructWrapper mSMPTRWrapper2 = m_SMPTRWrapper1; please note: when you calm to a: M_SMPTRWrapper1-> Soperator1 (); when the system crashes Not surprisingly, ownership or ownership ask yourself: when programme2.. When the default copy constructor functions, the default constructor of Auto_PTR is called, then all the default behaviors of Auto_Ptr follows the independent strategy. Yes, this way. M_SmptrWrapper1 object ownership transfer to m_smptrwrapper1-> soperator1 (); then The operation becomes on NULL. Oh! The system does not collapse. Then you need to think that Programme3 uses Auto_Ptr's Promotion Operation to construct "complete object" .b. Use the const keyword to prevent unrecriminal privileges Transfer From above, you can see that all ownership can make a big disaster everywhere. And for general applications, independent security strategy. So we use const to modify auto_ptr, no business Error. Of course, the above mentioned: does not mean that auto_ptr is not modified. In need, from two const semanties, you can achieve modifications.
Of course, you also hope that in the process of passing auto_ptr, then you can pass the reference of Auto_Ptr, then there is no loss: Void Fook (const auto_ptr
4. Do you think std :: auto_ptr is not perfect enough in practice, std :: auto_ptr can meet your needs? Andrei AlexandRescu mentioned in an article, mentioned: The technology about Smart Pointer is like witchcraft. Smart Pointer As the core of C garbage recovery mechanism, it must be strong enough to have industrial strength and safety. But in order to others, we still need to draft thorns to continue to explore.
Below, on the requirements level, what else we think about? A. Std :: auto_ptr can handle arrays? Can we use smart pointers to manage other resources? For example, a thread handle, a file handle and SO ON! B. Do you really implement an independence policy? C .ur intelligent pointer also needs to play power on inheritance and virtual levels! d. Often, you need to extend the function of the OUR smart pointer to meet the dynamics Need! E. Maybe, there are still many.
-------------------------------------------------- ------------- [Continue]
Second, C conditions, find a strategy for constructing more powerful smart pointers 1. Support for a number of design strategies for reference score 2. Support to process multiple resources 3. Support SubClassing 4. Support for multithreading conditions, thread security Multiple design strategies 5. Other special requirements, thus three, Generic Programming Basics and Smart Pointer 1. Looking back to TRAITS technology in resource 2. Back to multithreaded support
Fourth, COM implementation, Smart Pointer design principle
V. Status of Smart Pointer in the famous C library (standard and non-standard)
-------------------------------------------------- ---------
-------------------------------------------------- ------------ Solemn statement: Allow copy, modification, delivery or other behavior but is not allowed for any commercial use. Writing 20/3/2003 Last modified: 20/3/2003 by redstar81 81_redstar@163.com--------------------------------------------- ----------------
