※ 引述《lovejomi (JOMI)》之銘言：
: 這篇推文有些確實讓我不太理解 另開這篇問一下
: "所以 pass by value 的情況下不用加上 const 的原因是
: 使用者只有執行函式的執行緒, 所以要求行為一致是沒有意義的"
: 這句話我真的不太理解
: const跟 thread有什麼關聯?
: 意思是說 都已經複製了
: 裡面不管怎麼使用這物件 R/W
: 外面就算有其他thread 不管做什麼都已經跟這複製的物件無關了
: 所以const就沒意義
在函式參數裡加 const 是 caller 需要給 callee 的保證, 在下面
的程式碼裡開了兩條 thread, 其中一條看到的是 ref to const 但
連印兩次値都不一樣, 這就違反語意上的 constness (行為一致)
範例: https://wandbox.org/permlink/ywp3TcVYkHrVe3J6
pass-by-value 加上 const specifier 只是語法接近, 但它完全和
caller 的責任無關, 所以是沒意義的
: ======================
: "const 不是為了避免修改, 而是要求物件的行為 consistent"
: 這邊的consistent 我沒有很深刻的感受 這邊能多提供一些資訊嗎?
: 另一個觀點
: 如果對方沒有你這些認知 完全單純覺得 const就是語法上的不能修改
: 他才會有
: void Foo(int a) 留言要+ const
: void Foo(const string a) 留言覺得const useless
: 講到這邊都覺得有點矛盾了
: 如果不能修改 那const string a他不應該有意見....
: 所以我才推論他只有 primitive + const, non-trivial的就不加
: 這邊我想問 如果要說服他或是把你這串觀念用英文表達 有沒有文章說這呢?
: =====================================
就像我說的: const 是行為的保證. 你不能改變外顯行為的根本原
因是可用的介面被限縮了. 不需要糾結語法應該如何, 而該去思考
語意夠不夠精確.
: "需要 noexcept 的情況全用 noexcept(bool) 來決定"
: 這邊可否給我一些例子 我比較能理解用法
: void XD(string a) noexcept(std::is_nothrow_move_constructible<string>::value)
: {
: }
: 當我寫出這行時 我自己都不知道自己在幹嘛了
: 1. a不見得是by move 那by copy怎麼辦?
一般來說把敘述複製進 noexcept() 運算子就好, 建構子的判斷也
是大同小異:
struct From {};
struct To {
To(From&&) noexcept { }
To(const From&) { }
};
void foo(From from)
noexcept(
std::is_nothrow_constructible_v<To, decltype((from))>
)
{}
以上是測試直接把參數 (lvalue ref) 丟進建構子的情況 (注意
decltype 裡有多一層括號), 改成 std::move(from) 就可以測試另
外一版建構子.
: 2. 假設走by copy......這個XD函數 可能exception會發生在 參數傳遞時的呼叫...
: 這是不是表示 這函數已經不可能是noexcept了?
函式本身還是 noexcept, 但是呼叫敘述是不是 noexcept 取決於編
譯器 resolve 到的建構子版本:
void bar(std::string) noexcept;
std::string s;
static_assert(noexcept(bar(s))); // assertion failure
static_assert(noexcept(bar(std::move(s))));
: 3. 因為缺乏noexcept(bool)這用法上的經驗, 實在很難理解
: 雖然我不知道 exception specification為什麼被deprecated, 但沒了他
: 我怎麼知道這函數丟什麼exception? 如果他沒寫document 我根本無從得知 對吧?
: 當我在設計virtual function() 這時候 noexcept就已經要決定true or false了.
: 當決定了 derived 就被鎖死了, 這邊又讓我覺得 interface上限定noexcept似乎太硬了
: stackoverflow當然有一些方法 例如寫兩版
: 但我覺得這只是在找workaround沒有很能接受
: 以上
: 謝謝
因為實務上很難保證原本的 noexcept 性質, 而且能加上 noexcept
修飾符的通常是很簡短的函式 (拿來測試參數居多), 所以我覺得可
以不加.