爲什麼C++引入duration_cast而不是使用static_cast？

我在看一些使用duration_cast的代碼。看着它，我想知道爲什麼一個static_cast沒有使用，因爲static_cast的生活目的是在類型之間進行轉換。爲什麼C++引入duration_cast而不是使用static_cast？

爲什麼C++需要一個新的操作符來轉換時間？爲什麼static_cast未被使用？

也許我不理解的差異C++是毫秒，微秒，納秒等之間進行出於某種原因，我想答案應該是顯而易見的或堆棧溢出討論，但我還沒有找到它。

來源

2017-05-31 jww

duration_cast執行數學計算以不同的測量兩個持續時間之間進行轉換。 static_cast只能在相關層次中的類之間完成。 duration_cast翻譯兩個彼此絕對沒有關係的類。 –

主要區別在於static_cast內置於編譯器中，而duration_cast是標準庫中的模板。 – dasblinkenlight

謝謝@dasblinkenlight。我沒有想到'duration_cast'不是一個運算符（可怕的C++工程）。我應該刪除這個問題嗎？ – jww

當沒有精度損失的風險時，已經有時間間隔的直接轉換。當存在精度損失的風險時，需要duration_cast。

duration_cast因此不是一個經營者作爲故意轉換。

static_cast不合適，因爲不同的持續時間類型不相關。它們是完全不同的類，它們恰好支持相同的概念。

例如爲：

#include <chrono> 

int main() 
{ 
    using namespace std::literals; 

    // milliseconds  
    auto a = 10ms; 

    // this requires a duration-cast 
    auto lossy = std::chrono::duration_cast<std::chrono::seconds>(a); 

    // but this does not 
    auto not_lossy = std::chrono::nanoseconds(a); 
}

來源

2017-05-31 07:02:32

謝謝@Richard。部分（大部分？）我的困惑是因爲它被命名的方式而認爲它是一個內置的操作符。事實上，我在問題中稱它爲操作員，並且dasblinkenlight在其中提起。如果你補充說它不是一個運營商，那麼我應該能夠接受。 – jww

@jww我剛剛閱讀了評論。感謝您對命名的關注，但也要考慮'dynamic_pointer_cast'，'static_pointer_cast'等。這種非語言級別演員的概念具有以前的形式。 –

謝謝@理查德。冒着議論紛紛的風險（它真的只是一個天真的事物，因爲我並不處於最前沿）...... C++使用'X_cast'作爲運算符（如'static_cast'）;而C++ 11開始了'to_X'的趨勢（如'to_string'）。看起來，使用'to_duration'會減少混淆。 – jww

我已經重新被問到這個問題，多年來，我現在覺得可能是我的一個設計錯誤。

我目前正在嘗試更多地依賴顯式轉換語法來實現不應該隱式轉換的轉換，而不是「命名轉換語法」。

例如：

https://howardhinnant.github.io/date/date.html#year

year y = 2017_y; 
int iy = int{y}; // instead of iy = y.to_int()

來源

2017-05-31 13:19:58

有沒有pro/con的想法在網絡上的某個地方？ – bolov

我已經把它們寫在這裏和那裏，但沒有關於這個主題的論文。我看到的優勢是_uniform_ conversion語法。這不僅應該使泛型代碼更容易編寫，而且還應該讓學習新的API變得更容易，因爲您不再需要記住如何拼寫'to_int'，'as_int'或'get'等什麼。只有隱式轉換和顯式轉換：'T t = u;'和'auto t = T {u};'。 –

爲什麼C++引入duration_cast而不是使用static_cast？

回答

相關問題