const函數和在C++接口

我將使用下面的（簡單）接口作爲一個例子：const函數和在C++接口

struct IObject 
{ 
    virtual ~IObject() {} 

    virtual std::string GetName() const = 0; 
    virtual void ChangeState() = 0; 
};

從邏輯上講，GetName應該是一個const成員函數而ChangeState不應該。

儘管我目前看到的所有代碼都不遵循這個邏輯。即上述示例中的GetName不會被標記爲const成員函數。

這是懶惰/粗心還是有正當理由呢？在邏輯上要求我的客戶執行const成員函數時，我的主要缺點是什麼？

編輯：感謝您的答覆大家。我認爲這幾乎是一致的：懶惰/無知是我所看到的原因。

來源

2010-05-19 58gh1z

無能/懶惰/不小心 – 2010-05-19 16:39:28

不要忘記無知 - 在我的經驗糟糕的代碼的主要原因。 – 2010-05-19 16:43:25

@尼爾：不幸的是我必須同意......我現在正在咆哮：p – 2010-05-19 16:58:45

我認爲這是懶惰/粗心。 GetName()應該對該對象的狀態沒有影響，並且IObject的合同應明確說明該事實。

如果繼承類被強制讓GetName()擁有（隱藏！）副作用，他們總是可以聲明相應的字段爲mutable。

來源

2010-05-19 16:36:43 Thomas

我認爲人們忘記了'const'並不是要說對象的內部狀態不應該改變，而是外部狀態不應該改變。我應該能夠存儲一個實例的副本，調用const函數，並且原始和副本仍然應該相等。假設平等實際上意味着平等，其他任何事情都可以改變 – 2010-05-19 17:00:20

@Noah Roberts：也想象一下像緩存。更改緩存不會改變外部狀態，並且在const方法中是安全的。 – mmmmmmmm 2010-05-19 17:05:49

+1提及'mutable'的原因。 – 2010-05-19 18:47:47

這是懶惰/粗心還是有正當理由呢？

前者。 如果你真的沒有看到任何代碼這樣做，立即得到一份新工作。

什麼是我強迫我的客戶來實現const成員函數，當他們在邏輯上呼籲的主要缺點是什麼？

它可以讓編譯器發現漏洞共同在編譯時。（沒有什麼比在編譯時，一切都在於你的辦公桌上未能發現錯誤的更好，不會在客戶端的站點失敗。）

十幾年前，不久後我加入了一個新的公司，並得到了黑客攻擊他們的一個項目，我發現應該是const的方法不是，阻止我的一些const正確的代碼進行編譯。我認爲只是將我的const丟掉，然後繼續前進，但我自己卻不能這樣做。
所以我做了const的方法 - 只是發現它調用了其他方法，它本應該是const的，但它們都不是。所以我改變了他們 - 只是爲了發現...
最後，我花了好幾天的時間尋找所有的項目，增加const左右。
同事們嘲笑我 - 直到我向他們展示了編譯器發現的一些錯誤，因爲我添加了const。有趣的是，之後沒有人花時間進行徹底調查的一些長期存在的錯誤不再可以重現。

來源

2010-05-19 16:36:01 sbi

+1沒有什麼比非常量正確代碼的修復常量正確性更具靈魂破壞力了。 – 2010-05-19 16:39:32

@尼爾，如此正確 - 層疊效應變成了悲傷的瀑布。 – 2010-05-19 16:42:44

呃。我只能想象一個龐大的代碼基地的連鎖反應...... – 58gh1z 2010-05-19 16:47:14

const函數和在C++接口

回答

相關問題