1. コピーできないクラス

クラスがコピーされないようにするには、コピーコンストラクタと代入演算子のオーバーロード関数をクラスから呼び出せないようにするか、クラスのコピーコンストラクタと代入演算子のオーバーロード関数を直接privateに設定するか、C++11を使用する必要があります。これらの 2 つの機能は削除できます

class Test
{
public:
	Test() {}
	//...
private:
	//C++98
	Test(const Test&);
	Test& operator=(const Test&);
	//C++11
	//Test(const Test&) = delete;
	//Test& operator=(const Test&) = delete;
};

2. オブジェクトはヒープ上にしか作成できない

方法1

オブジェクトはヒープ上にのみ作成できます。つまり、オブジェクトは次のように new 演算子を介してのみ作成できます。

コンストラクターをプライベートとして設定して、コンストラクターへの外部直接呼び出しがスタック上にオブジェクトを作成するのを防ぎます
オブジェクトを外部に取得するための静的インターフェースを提供し、ヒープ上にオブジェクトを作成して返す
コピーコンストラクターは宣言されるだけで実装されず、プライベートアクセス許可として設定され、外部呼び出しがスタック上にオブジェクトを作成するのを防ぎます。

#include <iostream>
using namespace std;
class HeapOnly
{
public:
	//提供公有的获取对象的静态方法
	static HeapOnly* CreateObj(){
		return new HeapOnly;
	}
private:
	HeapOnly() :_data(0) {};
	HeapOnly(const HeapOnly& tmp) = delete;
private:
	int _data;
};
int main()
{
	HeapOnly* obj = HeapOnly::CreateObj();
	delete obj;
	return 0;
}

方法 2

デストラクタは非公開にすることができ、デストラクタを介してオブジェクトリソースを解放することはできません。つまり、強制的にヒープ上にオブジェクトを作成し、delete 演算子を使用してオブジェクトリソースを解放することしかできません。

#include <iostream>
using namespace std;
class HeapOnly
{
public:
	void Delete() { delete this; }
private:
	~HeapOnly() {}
private:
	int _data;
};
int main()
{
	HeapOnly* p = new HeapOnly;
	p->Delete();
	return 0;
}

3.オブジェクトはスタック上でのみ作成できます

コンストラクターをプライベートとして設定して、ヒープ上にオブジェクトを作成するためのコンストラクターへの外部直接呼び出しを防ぎます
オブジェクトを外部に取得するための静的インターフェースを提供し、スタック領域にオブジェクトを作成して返す
operator new() 関数と operator delete() 関数をシールドします (コピー構築を呼び出してヒープ領域にオブジェクトを作成するのを防ぐため)

#include <iostream>
using namespace std;
class StackOnly
{
public:
	static StackOnly CreateObj() {
		return StackOnly();
	}

	void* operator new(size_t size) = delete;
	void operator delete(void* p) = delete;
private:
	StackOnly():_data(0) {};
private:
	int _data;
};
int main()
{
	StackOnly so = StackOnly::CreateObj();

	static StackOnly s1(so);//无法完全实现要求
	return 0;
}

しかし、この方法には欠点があります。データセグメントにオブジェクトを作成するためのコピーコンストラクターへの外部呼び出しを防ぐことはできません。

ただし、CreateObj() 関数はローカルオブジェクトを作成し、ローカルオブジェクトを返すプロセスでコピーコンストラクターを呼び出す必要があるため、コンストラクターをプライベートとして設定することはできず、コピーコンストラクターを =delete によって削除することはできません。

4. 継承できないクラス

方法 1 (C++98)

サブクラスのコンストラクターが呼び出されると、親クラスのメンバーの一部を初期化するために親クラスのコンストラクターを呼び出す必要があるため、このクラスのコンストラクターをプライベートとして設定するだけですが、親クラスのプライベートメンバーはサブクラスでは表示されないはい、サブクラスオブジェクトを作成するときに、サブクラスは親クラスのコンストラクターを呼び出して親クラスのメンバーを初期化できないため、サブクラスはクラスが継承された後にオブジェクトを作成できません

class Perent
{
public:
	static Perent CreatePerentObj() {
		return Perent();
	}
private:
	Perent() {};
};

方法 2 (C++11)

C++98 のこのメソッドは完全ではありません。このクラスは引き続き継承できますが (コンパイラはエラーを報告しません)、継承後にオブジェクトをインスタンス化することはできません。そこで C++11 では final キーワードが用意されている. final で修飾されたクラスを final クラスと呼ぶ. final クラスは継承できない. 継承後にオブジェクトを作成しなくてもコンパイルエラーになる.

class NonInherit final
{
	//...
};

5.Singleton モード (オブジェクトは 1 つしか作成できません)

5.1 コンセプト

シングルトンパターンはデザインパターンです (デザインパターン). デザインパターンは、繰り返し使用され、ほとんどの人に知られ、カタログ化され、コード化されたコード設計経験の要約です。デザインパターンを使用する目的は、コードを再利用可能にし、コードを他の人が理解しやすくし、コード信頼性プログラムの再利用性を確保することです。
シングルトンモードとは、クラスが 1 つのオブジェクトしか作成できないことを意味します。このモードでは、システム内にクラスのインスタンスが 1 つだけ存在することが保証され、それにアクセスするためのグローバルアクセスポイントが提供されます。このインスタンスは、すべてのプログラムモジュールによって共有されます。
たとえば、サーバープログラムでは、サーバーの構成情報がファイルに格納され、これらの構成データがシングルトンオブジェクトによって読み込まれ、サービスプロセス内の他のオブジェクトがこのシングルトンオブジェクトを介して構成情報を取得します。複雑な環境での構成管理を簡素化
シングルトンモードを実装するには、ハングリーマンモードとレイジーマンモードの 2 つの方法があります。

5.2 ハングリーマンモード

コンストラクターをプライベートにし、コピーコンストラクターと代入演算子のオーバーロードされた関数をプライベートまたは削除して、オブジェクトの外部作成またはコピーを防ぎます。
シングルトンオブジェクトへの静的ポインターを提供し、プログラムエントリの前にシングルトンオブジェクトの初期化を完了します。
シングルトンオブジェクトのグローバルアクセスポイントを提供します

class SingleTon
{
public:
	static SingleTon* GetInstance() {//全局访问点
		return _inst;
	}
private:
	SingleTon() {};//构造函数私有
	//防拷贝
	SingleTon(const SingleTon&) = delete;
	SingleTon& operator=(const SingleTon&) = delete;
	static SingleTon* _inst;//指向单例对象的static指针
};
SingleTon* SingleTon::_inst = new SingleTon;//在程序入口前完成单例对象的初始化

スレッドの安全性に関する問題:

ハングリーモードでは、プログラムがメイン関数を実行する前にシングルトンオブジェクトの作成が完了します. main() 関数の前にマルチスレッド化がないため、ハングリーモードでのシングルトンオブジェクトの作成プロセスはスレッドセーフです.
このシングルトンオブジェクトへの後続のマルチスレッドアクセスはすべて、GetInstance() 関数を呼び出して取得する必要があります。これは読み取り操作であるため、この取得プロセスをロックする必要はありません。

5.3 レイジーパターン

コンストラクターをプライベートにし、コピーコンストラクターと代入演算子のオーバーロードされた関数をプライベートまたは削除して、オブジェクトの外部作成またはコピーを防ぎます。
シングルトンオブジェクトへの静的ポインターを提供し、プログラムエントリの前に空に初期化します。
シングルトンオブジェクトを取得するためのグローバルアクセスポイントを提供し、グローバルアクセスポイントへの初回アクセス時にシングルトンオブジェクトの初期化を完了する

#include <thread>
#include <mutex>
using namespace std;
class SingleTon
{
public:
	static SingleTon* GetInstance() {//全局访问点
		if (nullptr == _inst)
		{
			unique_lock<mutex>(_mtx);
			if (nullptr == _inst) {
				_inst = new SingleTon;
			}
		}
	}
private:
	SingleTon() {};//构造函数私有
	//防拷贝
	SingleTon(const SingleTon&) = delete;
	SingleTon& operator=(const SingleTon&) = delete;
	static SingleTon* _inst;//指向单例对象的static指针
	static mutex _mtx;
};
SingleTon* SingleTon::_inst = nullptr;
mutex SingleTon::_mtx;//定义，在程序入口前完成初始化

スレッドの安全性に関する問題:

遅延モードは、プログラムの実行前にシングルトンオブジェクトを作成しませんが、スレッドがこのシングルトンオブジェクトを使用する必要があるまで待ってから作成します。つまり、GetInstance() 関数は、最初に呼び出されたときにシングルトンオブジェクトを作成します。
そのため、シングルトンオブジェクトを取得するために GetInstance() 関数を呼び出す場合、静的ポインタが空であるかどうかを確認する必要があります.空の場合は、シングルトンオブジェクトが作成されていないことを意味します.このとき、シングルトンオブジェクトは、最初に作成する必要があり、その後シングルトンオブジェクトが返されます
GetInstance() 関数が初めて呼び出されるとき、静的ポインタに書き込む必要があります. 複数のスレッドが同時に GetInstance() 関数を呼び出す可能性があるため、このプロセスはスレッドセーフではありません.保護されているため、この時点で複数のスレッドがそれぞれオブジェクトを作成します

ダブルチェックロック:

GetInstance() 関数でシングルトンオブジェクトを作成するプロセスを保護するには、本質的にミューテックスの導入が必要です. ロックする最も簡単な方法は、if 判定の前にロックし、if ステートメント全体の後にロックを解除することです
しかし実際には、最初に GetInstance 関数が呼び出されるだけです. シングルトンオブジェクトを作成する場合、保護のためにミューテックスが必要です. シングルトンオブジェクトを取得するための以降の GetInstance 関数の呼び出しは、読み取り操作のみであり、その必要はありません。保護のためにミューテックスを使用します。
ロックとロック解除操作が if ステートメントの前後にあるだけだと、作成されたシングルトンオブジェクトを取得するために GetInstance() 関数が呼び出されると、無意味なロック操作とロック解除操作が大量に実行され、スレッドが継続的に切断されます。 in と out 、これはプログラムの効率に影響します
このような初回のみロックする必要があるシーンでは、ダブルチェックを使用してロックすることができます. ダブルチェックは、現在のロックの外で別の if 判定を行い、静的ポインタが空であるかどうかを判定するロック解除を行います.
その後、GetInstance() 関数を呼び出して作成されたシングルトンオブジェクトを取得すると、外側のレイヤーで新しく追加された if 判定が有効になり、その後の無意味なロックおよびロック解除操作が回避されます。
new 演算子が例外をスローし、ロックが解除されない可能性があるため、ロックするときは unique_lock を使用することをお勧めします。

その他の実装

シングルトンクラスの GetInstance(0 関数で静的なシングルトンオブジェクトを定義し、戻ります
この静的なシングルトンオブジェクトは、GetInstance() 関数が初めて呼び出されたときにのみ実際に定義されるため、これにより、一意のインスタンスがグローバルに 1 つだけ存在することも保証されます。
ここでのシングルトンオブジェクトの定義プロセスはスレッドセーフです。これは、現在の C++ 標準が、静的変数のマルチスレッド初期化がデータ競合を引き起こさないことを保証しているためです。これは、アトミック操作と見なすことができます。
プログラムがメイン関数を実行する前にローカル静的変数が初期化されず、GetInstance() 関数が初めて呼び出されたときに初期化されるため、このメソッドは遅延モードに属します。

このバージョンの怠け者には、次の主な欠点があります。

シングルトンオブジェクトは static 領域で定義されるため、大きすぎるシングルトンオブジェクトはこのメソッドには適していません。
シングルトンオブジェクトが静的領域に作成された後、アクティブに解放する方法はありません。
このメソッドは、C++11 バージョン以降でのみ使用できます。

class SignleTon
{
public:
	static SignleTon* GetInstance() {
		static SignleTon inst;
		return &inst;
	}
private:
	SignleTon() {}
	SignleTon(const SignleTon&) = delete;
	SignleTon& operator=(const SignleTon&) = delete;
};

5.4 ハングリーマンとレイジーマンの比較

ハングリーマンモードの利点はシンプルさですが、欠点も明らかです。ハングリーマンモードでは、プログラムがメイン関数を実行する前にシングルトンオブジェクトが作成されます. シングルトンクラスのコンストラクタがさらに多くの作業を行うと、プログラムがメイン関数に長時間入ることができなくなります.外部からのプログラム。
シングルトンオブジェクトを作成する必要がある複数のシングルトンクラスがあり、それらの初期化の間に特定の依存関係がある場合、たとえば、シングルトンオブジェクト A はシングルトンオブジェクト B の後に作成する必要がある場合、ハングリーマンモードでも問題が発生します。複数のシングルトンオブジェクトのうち、どのオブジェクトが最初に作成されるかは保証されません。
怠惰な人モードはハングリーマンモードの上記の欠点を非常によく解決できます。怠惰な人モードは最初からシングルトンオブジェクトの作成を完了しないため、プログラムがメイン関数に入ることができなくなることはありません。長い時間、怠け者モードの各ケースオブジェクトの作成順序は、各シングルトンクラスの GetInstance() 関数が最初に呼び出される順序によって決定されるため、制御可能です。
レイジーマンモードの欠点は、コーディングがハングリーマンモードよりも複雑であり、シングルトンオブジェクトを作成するときにスレッドセーフの問題を考慮する必要があることです。

6. シングルトンオブジェクトのリリース

シングルトンオブジェクトが作成されると、プログラムの実行中に使用される可能性があるため、シングルトンオブジェクトの解放は無視でき、プログラムが正常に終了すると、リソースはオペレーティングシステムに自動的に返されます。

シングルトンオブジェクトのリリースを検討するには、次の 2 つの方法を参照できます。

1. シングルトンクラスに DelInstance() 関数を記述し、この関数でシングルトンオブジェクトを解放するシングルトンオブジェクトが不要になったら、積極的に DelInstance() を呼び出してシングルトンオブジェクトを解放できます。

static void DelInstance()
{
	unique_lock<mutex>(_mtx);
	if (_inst != nullptr)
	{
		delete _inst;
		_inst = nullptr;
	}
}

2. シングルトンクラスに埋め込みガベージコレクションクラスを実装し、ガベージコレクションクラスのデストラクタでシングルトンオブジェクトの解放を完了します。singleton クラスに static ガベージコレクションクラスオブジェクトを定義し、オブジェクトがリサイクルされるとデストラクタが呼び出され、この時点で singleton オブジェクトが解放されます。

class CGarbo//垃圾回收类
{
public:
	~CGarbo()
	{
		if (_inst != nullptr) {
			delete _inst;
			_inst = nullptr;
		}
	}
};

特別クラスのデザイン