Special class design

Please design a class , Cannot be copied

The copy will only be placed in two scenarios ： Copy constructor and assignment operator overload , So you want a class to prohibit copying , Just make the class unable to call copy constructor and assignment operator overload

C++98
Overloading the copy constructor and assignment operator only declares that it does not define , And set its access rights to private .

class CopyBan
{
    
private:
	CopyBan(const CopyBan&);
	CopyBan& operator=(const CopyBan&);
};

reason ：

1. Set private ： If only declaration is not set to private, If the user defines it outside the class , You can't prohibit copying
2. Just declare not define ： Not defined because the function does not call , It doesn't make any sense to define it , It's easy not to write , And if defined, it will not prevent internal copy of member functions .

C++11
C++11 Expand delete Usage of ,delete Except release new In addition to the resources requested , If followed by the default member function =delete, Means to let the compiler delete the default member function .

class CopyBan
{
    
	CopyBan(const CopyBan&) = delete;
	CopyBan& operator=(const CopyBan&) = delete;
};

Please design a class , Objects can only be created on the heap

Method 1 ：
1. Private the constructor of the class , The copy construct is declared private . Prevent others from calling copy to generate objects on the stack .
2. Provide a static member function , Complete the creation of heap object in the static member function

#include<iostream>
using namespace std;

class OnlyHeap
{
    
public:
	
	static OnlyHeap* CreateObj()
	{
    
		return new OnlyHeap;
	}
private:
	//  Constructor privatization 
	OnlyHeap()
		:_a(0)
	{
    }
	//OnlyHeap(const OnlyHeap& oh);
	//OnlyHeap& operator=(OnlyHeap oh);

	OnlyHeap(const OnlyHeap& oh) = delete;
	OnlyHeap& operator=(OnlyHeap oh) = delete;
private:
	int _a;
};

int main()
{
    
	//OnlyHeap oh;
	//OnlyHeap* ptr = new OnlyHeap;
	OnlyHeap* ptr = OnlyHeap::CreateObj();
	//OnlyHeap copy(*ptr);

	delete ptr;

	return 0;
}

Be careful ：

• It is recommended to mainly use this method , Because this design idea is very general
• Provide a static member function after privatizing the constructor , Complete the creation of heap object in the static member function , Otherwise you will fall into “ The thinking of chicken or egg first ” In the middle （ The compiler will report an error ）
• This kind of thinking should pay attention to a dead end —— Copy can be used to construct 、 Assign copies to create objects on the stack
• C++98 in Anti copy —— Only declare , Don't realize , Declare private （ But this method can be implemented outside the class , Or you can use improper means to create objects on the stack （ It's not safe ））
• C++11 in Anti copy —— OnlyHeap(const OnlyHeap& oh) = delete; 、OnlyHeap& operator=(OnlyHeap oh) = delete; Whatever the access qualifier is

Method 2 ：

1. Private the destructor of the class
2. Provide a member function of , Complete the memory release of the heap object in this member function

#include<iostream>
using namespace std;

class OnlyHeap
{
    
public:
	void DestoryObj()
	{
    
		
		delete this;
		//this = nullptr; // Cannot leave empty inside a class 
	}
private:
	~OnlyHeap()
	{
    
		cout << "~OnlyHeap()" << endl;
	}
private:
	int _a;
};

int main()
{
    
	//OnlyHeap oh; // Cannot create on stack 
	OnlyHeap* ptr = new OnlyHeap;
	ptr->DestoryObj();
	// In this way, objects cannot be created by copying 

	//delete ptr; // Release failed 

	return 0;
}

Be careful ：

• This method does not consider copy construction 、 Copy... Copy , As long as the constructor creates a class object, the destructor will be called by default , When the destructor is set to private , Constructor cannot be adjusted , Therefore, objects cannot be created on the stack

Please design a class , Objects can only be created on the stack

Method 1 ： Privatization of constructors , Then design static methods to create objects and return .

class StackOnly
{
    
public:
	static StackOnly CreateObj()
	{
    
		return StackOnly();
	}

private:
	StackOnly()
		:_a(0)
	{
    }
private:
	int _a;
};

int main()
{
    
	StackOnly so=StackOnly::CreateObj();
	//  There are some loopholes in this way , Cannot prohibit the creation of objects in static areas 
	static StackOnly sso=so;

	return 0;
}

Method 2 ： shielding new because new Call... At the bottom void* operator new(size_t size) function , Just mask the function .

Be careful ： To prevent positioning new

class StackOnly
{
    
public:
	StackOnly()
		:_a(0)
	{
    }
private:
	void* operator new(size_t size) = delete;
	void operator delete(void* ptr) = delete;
private:
	int _a;
};

int main()
{
    
	StackOnly so;
	//StackOnly* ptr = new StackOnly;
	//  There are some loopholes in this way , Cannot prohibit the creation of objects in static areas 
	//static StackOnly sso;
	//StackOnly* n = (StackOnly*)malloc(sizeof(StackOnly));
	//new(n)StackOnly; // location new
	return 0;
}

Be careful ： There are some loopholes in these two methods , Cannot prohibit the creation of objects in static areas

Please design a class , uninheritable

C++98 The way ： C++98 Privatization of constructors in , The constructor of the base class cannot be derived from the derived class. . Cannot inherit

class NonInherit
{
    
public:
	static NonInherit GetInstance()
	{
    
		return NonInherit();
	}
private:
	//  Constructor private 
	NonInherit()
	{
    }
};

class Derive : NonInherit
{
    };

int main()
{
    
	Derive d;

	return 0;
}

summary ： C++98 This way is not direct enough , Here is something that can be inherited , however Derive Cannot create object , because Derive Constructor for , You must call the parent class NonInherit structure , however NonInherit The constructor of is private , Private is not visible in subclasses , Then the inheritance here will not report an error , Creating an object of an inherited subclass will report an error

C++11 Method ：final keyword ,final decorator , Indicates that the class cannot be inherited .

class NonInherit final
{
    };

class Derive : NonInherit // Cannot inherit 
{
    };

int main()
{
    
	Derive d;
	return 0;
}

C++11 In a way that cannot be inherited , intuitive 、 Simple and clear

Please design a class , Only one object can be created ( The singleton pattern )

Design patterns （Design Pattern） It's a set that's been used over and over again 、 Most people know that 、 classified 、 Summary of code design experience .
The purpose of using design patterns ： For code reusability 、 Make code easier to understand 、 Ensure code reliability . Design patterns make coding really Engineering ; Design pattern is the foundation of software engineering , Like the structure of a building .

Add ： Design patterns ： Iterator pattern 、 Adapter pattern 、 Factory mode 、 Observer mode 、 The singleton pattern ……

The singleton pattern ：
A class can only create one object , That is, singleton mode , This pattern ensures that there is only one instance of this class in the system , And provide a global access point to access it , The instance is shared by all program modules . For example, in a server program , The configuration information for this server is stored in a file , This configuration data is read uniformly by a singleton object , This singleton object is then used by other objects in the service process to obtain the configuration information , This approach simplifies configuration management in complex environments .

Singleton mode has two implementation modes ：

Starving model

That is, whether you use it or not in the future , When the program starts, a unique instance object is created .

The whole situation is unique Singleton Instance object , Then the members in him are the single instance
Starving model

• advantage ：

• 1. Simple
• 2. If this singleton object is multithreaded （main After the function ） Frequently used in high concurrency environments , High performance requirements , So it's obvious to use the hungry man model to avoid resource competition , Better response speed .

• shortcoming ：

• 1. Singleton objects main Function before creating an initialized , This may cause the process to start slowly ,
• 2. If there are multiple instances of singleton class objects, the starting order is uncertain .
• 3. If there are multiple singleton classes , And they had dependencies before , So the hungry man model can't guarantee to better control these problems
• 4. Cannot actively free object space

The sluggard model

Not prepared in advance , On first visit , To create a singleton

If singleton object construction is time-consuming or takes up a lot of resources , Such as loading plug-ins , Initialize the network connection , Read files, wait , It is possible that the object will not be used when the program runs , Then it should also be initialized at the beginning of the program , It will cause the program to start very slowly . So in this case, lazy mode is used （ Delay loading ） Better .

The sluggard model The first call GetInstance when , Will create and initialize the singleton object , Compared with the hungry man , There is no problem that may lead to slow startup , You can also control the problem of sequence dependence

The sluggard model ：

• advantage ：
• 1. When using an instance object for the first time , Create objects . Process startup no load . The startup sequence of multiple single instance instances is freely controlled .
• 2. Compared with the hungry man model , The memory space of the instance object can be automatically released
• shortcoming ：
• 1. It's a little more complicated , In particular, we need to control the problem of thread safety （ To use Double-Check Lock by , To ensure efficiency and thread safety .）

Add ：

• The singleton pattern ： Define a global object , But this method has great defects , This object can only be defined in one .h In file , If this .h In more than one .cpp contain , Then the link will report an error , The reason is that there are many different objects when linking , There will be problems when merging .
• Solution ：
• 1. stay .h of use extern Declare global objects , In a .cpp Creating objects in
• 2. stay .h of use static Decorate global objects , But the middle plan is not feasible , Because in multiple .cpp Many different objects will be created in , This is contrary to the problem （ Not an option ）