標題不好下
主要問題是
一個class被標註 copy constructor = delete的時候
我卻透過by value的語意 使用他
具體code
我用lock_guard<...>來舉例
https://wandbox.org/permlink/kNmQm9tWjXAJEbVH
看到不少code, 有人這樣使用
lock_guard<mutex> getLock(){return lock_guard<mutex>{m};}
這種code 貼到ideone C++14就不給過
兩個問題
1. 因為C++17 copy elision, 這種使用方式 是完全沒問題的嗎?
2. 假設沒問題, 因為只有C++17後才能這樣寫, 我自己會覺得寧可不要寫這種 code
盡量維持 backward compatible.
3. 如果好的包法 要怎麼做呢?
以前通常是把get set包出去 內部用lock去r/w member
struct
{
void GetX(){ lock_guard...}
void SetX(...){lock_guard....}
private:
int x;
mutex m;
}
但這樣變成 要提供get/set...
所以我猜才會有人想要提供一個RAII Locker的getter
讓外面先acquire lock 直接把member public出去給外面操作
該怎麼做比較好呢?
謝謝

https://stackoverflow.com/questions/43546213提供 lock、unlock是說 getLock 這樣寫好怪，有連結可以讓我觀摩一下嗎？

沒有連結耶 內部的code 不只一個人這樣寫 @@

可能第一個人寫下去後後面的接著抄吧...

也許是這樣 但我是想探討 這種方式是否沒任何問題，如果沒有 這感覺很鑽漏洞的感覺

我是覺得不行啦，寫這種意圖怪怪的 code...

你先想寫類別的目的是什麼? 是提供抽象化. 而 mutex目的就是要確保抽象化有被達成, 具體來說就是物件的狀態改變不會有意外發生. 你為了 mutex 反而增加和類別責任無關的方法, 你同事都不會覺得奇怪嗎? 一般有mutex 也會經過封裝, 讓使用者傳入 callback 來間接存取物件, 實作可以參考 boost::with_lock_guard(),多做一層封裝在之後確定存取都在同一個 thread 之後也可以直接把 mutex 拿掉, client code 不需要做調整所以你會看到有些函式庫進 critical section 是給callback 而不是明確地寫 lock 敘述https://wandbox.org/permlink/zLuj9ynXtafalAYi當你在傳東西給 callback 的時候, 最好是用限縮後的介面, 看是要用 std::forward_as_tuple() 或是允取存取的成員放在 base class 內, 再怎麼樣都不會搞到把所有成員都變成 public, 那這樣你還寫 C++ 幹嘛呢

抱歉我沒有跟上 請問寫一個Access inner class有什麼好處嗎? 為什麼不直接散裝getX/setX在Foo就好?我還沒理解精隨~ 這樣看起來caller必須多.access()如果有多個data member也是必須開getA getB 多個嘛?

https://wandbox.org/permlink/PF98F9AhlvpqsIgr不做特別處理的單個成員 setter/getter 還不如不寫access 是一個概念, 雖然本來的物件無法複製, 但存取權是可以被任意複製轉移的, 這是 OO 的設計, 仔細思考一個問題: 如果一個物件只允許你存取部分的資料成員, 那存取的介面是否應該直接開在這個類別裡? 還是把 "特定資料成員的存取權" 這個概念抽象化出來, 未如果要做 composition 也可以做在這個 Access 類別裡, 和目標物件無關