我知道爲什麼要使默認構造函數和複製構造函數專用於在C++中實現單例類。但我不明白的是爲什麼要使複製賦值運算符是私人的，因爲不會有兩個現有的對象開始。爲什麼重載C++中的單例類的複製賦值操作符？
我的探索帶來了兩點：
據Alexandrescu的「現代C++設計」，賦值 運營商進行私人防止自賦值。
其次，根據rule of three，如果定義構造函數中的一個， 拷貝構造函數和賦值操作符的一類，你應該定義 明確所有三個。那麼，是否僅僅遵循這個規則 。
那麼，你對此有何看法呢？
號
在辛格爾頓要管理所有可能的建設，分配和破壞。通過執行所有這些操作private，您實際上只是防止他人使用它們。
另外請注意，通常拷貝構造和拷貝分配將被聲明爲private，以防止從外部調用，但不會被定義，因爲它們在實踐中不被使用...並且因此如果它們是鏈接器將會抱怨。
在C++ 11中，您將聲明覆制構造和複製分配爲delete d。
如果我正確理解OP，如果構造函數是私有的，則不能使用複製賦值，因爲沒有人能夠構造有效的lhs - 分配情況）。 – Vlad 2012-04-15 12:27:35
@Matthieu：是否有必要聲明op =還是這是一個樣式問題？ – 2012-04-15 12:38:26
@RajendraUppal：它不只是一個風格問題。應該禁止無意義的操作，以便消息清晰：用戶被警告說他做了一些無意義的事情，並且可以做出適當的反應。 – 2012-04-15 13:02:47
我認爲，禁止分配的必要性更多的是語義考慮：因爲單身人士是唯一，它的分配沒有任何意義。因此，如果以合理的方式實現分配在技術上甚至是可能的，那麼無論如何您需要禁止它。
所以正是因爲一定不會需要複製一個單例，所以必須禁止該操作。否則就會出現混淆和錯誤的空間：開發者將嘗試使用它（如果允許的話）（並想知道什麼是錯的）。
良好的設計最大限度地減少了WTF的數量。
但是，讓我們決定不提供它，即使客戶端程序員正在做類似於p1 = p2的操作（兩者都從調用GetInstance（）中接收到），自我分配將靜默運行並且沒有傷害，因爲它們都指向同樣的例子。 – 2012-04-15 12:34:48
@Rajendra：好的，他們會想知道爲什麼他們的代碼不起作用 - 哪個不好。雖然從技術上講它可能是可能的。良好的設計不僅關乎技術的正確性，而且還關乎幫助人們看到發生了什麼。 – Vlad 2012-04-15 12:37:49
那麼，他們在編譯和運行之前就已經意識到了嗎？ – 2012-04-15 12:39:36
我不質疑Alexandrescu的解釋！我想知道是否存在技術原因，或只是告知客戶程序員分配已被阻止？因爲如果我們不聲明op =，那麼程序員的構造就像p1 = p2會默默地傳遞。 – 2012-04-15 12:26:49
如果你使用Singleton，那麼你的設計已經非常糟糕，可以試着遵循三法則。 – Puppy 2012-04-15 14:32:29
你真的想讓它編譯嗎？ 'S :: getInstance（）= S :: getInstance（）;' – 2012-04-15 16:18:25