auto
關鍵字的推導過程徹底處於 compile-time,因此並不會影響程序性能。應該放心大膽的使用。python
cppauto i = 1; // i will become int auto l = 1LL; // l will become long long auto d = 1.0; // d will become double auto f = 1.0f; // f will become float std::vector<int> ivec{1, 2, 3, 4, 5}; for (auto i : ivec) std::cout << i << " "; // 1 2 3 4 5
這樣使用 auto
可能會要求你記住一些字面量的類型標識:數組
標識 | 含義 | 類型 |
---|---|---|
u | Unicode 16 character | char16_t |
U | Unicode 32 character | char32_t |
L | wide character | wchar_t |
u8 | utf-8(string literals only) | char |
可能常常用 VS 和 Windows API 的人比較熟悉 L
,用來標識寬字符。(不得不說,這一點,微軟仍是挺超前的)ide
字面量 | 標識 | 類型 |
---|---|---|
整型 | u / U |
unsigned |
整型 | l / L |
long |
整型 | ll / LL |
long long |
浮點 | f / F |
float |
浮點 | l / L |
long double |
這些與 C 語言一脈相承,應該比較熟悉了。性能
特殊狀況設計
cppauto str = "hello";
請問,str
是什麼類型?最近才發現,不少初學者居然想固然的認爲str
是std::string
.(尤爲是沒有 C 語言基礎的)code
實際上,str
此時是 const char *
.utf-8
因此當你對 str
進行 range for 的時候,就會傻眼。string
cppfor (auto c : str) { // error! str 沒有 begin() 和 end() //... }
上述狀況應該如何避免?it
cppauto& str = "hello";
請問,str
是什麼類型?table
是 const char[6]
. 這是一個數組了,那麼 range for 固然沒問題了。
還有別的方法嗎?
固然,右值引用不是吃閒飯的:
cppauto&& str = "hello";
range for 照樣沒問題。請問 str
此刻是什麼類型?
是 const char(&)[6]
.
這都是很是基礎的內容,你都清楚嗎?
另外補充一個:
cppauto il = {1, 2, 3, 4, 5, 6};
不要以爲 il
會是 std::array
或 普通數組,甚至是 std::vector
. 它的類型應該是: std::initializer_list
。
auto
auto
的地方都該用。(尤爲是受到 python
等動態語言影響的人)。auto
會讓代碼變得不直觀,在一個強類型的語言中,會搞得人莫名其妙。通過一段時間的瘋狂實踐。我以爲上述兩種觀點都有失偏頗。
其實,開始我是支持第一種觀點的,因而開始大量使用 auto
, 直到有一天 review 本身的代碼時。居然發現不少變量徹底看不出是什麼類型。如:
cppauto foo = bla(); // 請問 foo 你能看出類型來嗎?
這就傻眼了。違反了最基本的程序設計原則——「清晰易懂,方便擴展」,看都看迷糊了,擴展毛啊。
但有些狀況,其實極大程度上的簡化了程序,使之簡潔明瞭:
cppauto foo = std::make_shared<Foo>(); // 一看就知道類型 for (auto iter = vec.cbegin(); iter != vec.cend(); ++iter) {} // 一看就知道類型
上述兩種狀況下,把 auto
擴展開來,會顯得重複、冗長。
這兩個例子,應該可以說明使用 auto
的那條 「金線」 在哪了。咱們的目的不是爲了用而用,而是儘量的讓本身的程序,易於維護,保持新鮮。
故,不要濫用,不要避諱。