Objective C ++ Study Notes chapter 4 (1)

Chapter 4: Design and statement

Item18: Making the interface easy to use and misuse
Ideally, if compilation is successful, the interface will be able to implement what you want, otherwise compilation will fail.

Assume that a constructor of the class indicating time data is being designed: Date (INT month, int day, int year); in this case, two problems will occur. First, the sequence of passing parameters is incorrect, the value range of the passed parameter is incorrect.

1) The order of parameters is incorrect. OK. You may have thought of using struct and do not allow implicit conversion. As follows:

 
Struct day {explicit Day (int d): Val (d) {} int Val ;};
 

Similarly, a struct similar to month and year is defined, which seems to solve the problem.
PS: it is better to put day, month, and year in a fully encapsulated data than to define a struct separately. For details, see item22.

 
Date D (30, 3, 1995); // error! Wrong typesdate D (Day (30), month (3), Year (1995); // error! Wrong typesdate D (month (3), Day (30), Year (1995); // okay, types are correct
 

2) The data range is incorrect when the user transmits the parameter. How can a variable reasonably represent its value range. For example, there are only 12 months. OK, which can be defined as follows:

 class month {public: static month Jan () {return month (1 );} // functions returning all valid static month FEB () {return month (2);} // month values; see below... // why these are functions, not objects, because the initialization sequence of non-local static variables cannot be guaranteed. This ensures that all variables have been initialized with static month Dec () {return month (12 );}... // other member functionsprivate: explicit month (INT m); // prevent creation of new month values... // month-specific data}; 

then call date D (month: Mar (), Day (30), Year (1995) directly.
3) Try to make the design type consistent with built-in types. To avoid incompatibility with built-in types, it is actually an interface that provides behavior consistency.
4) any interface that requires customers to remember to do something is prone to "incorrect use", because customers may forget to do that. For example, in the Dynamic Allocation of item13, in order to avoid Memory leakage, we will hand over the returned pointer to only one pointer to release the memory.
STD: tr1: shared_ptr createinvestment ();
what if the customer forgets to use smart pointers. A good design principle here is to preemptively make it directly return a smart pointer. This almost completely eliminates the possibility of forgetting to release resources.
5) as described in item14, tr1: shard_ptr allows binding a resource release function, but this may result in "attempt to use the wrong resource destructor ". For example, the resource destructor we want to use is getridofinvestment, rather than Delete. To avoid errors, we can return a tr1: shared_ptr pointer that binds getridofinvestment to the deleteer. In this case, we try to create a null tr1: shared_ptr in createinvestment and use getridofinvestment as the delete tool.
like this: STD: tr1: shared_ptr pinv (0, getridofinvestment);
but it cannot be compiled because 0 is of the int type, it cannot be converted to a pointer, even if it can be converted. Forced conversion can be used here. In this way, the Code becomes:

STD: tr1: shared_ptr <investment> createinvestment () {STD: tr1: shared_ptr <investment> pinv (static_cast <investment *> (0), getridofinvestment ); pinv = ...; // point to a correct object; return pinv ;}
 

6) Of course, if the original pointer managed by pinv can be determined before pinv is established, it is better to "pass the original pointer to the pinv constructor" than "initialize pinv to null first and then assign a value to it". For details, see item26.
7) Another good property of tr1: shared_ptr is that it will automatically use its "exclusive delimiters for each Pointer ", eliminate another potential customer error-"cross-DLL problem ". This problem occurs when "the object is created by new in a dynamic link library DLL, but deleted by delete in another dynamic link library DLL ". on many platforms, this kind of "cross-DLL new/delete pair application will cause runtime error. Tr1: shared_ptr can avoid this problem because the default deletetool is the delete from the DLL created by "tr1: shared_ptr. That is to say, the created tr1: shared_ptr can be passed to any other DLLs without worrying about "cross-DLL problem ". this tr1: shared_ptrs will track the record. When the number of resource applications changes to 0, the bound DLL's delete will be called.