【Go】那麼多數值類型,應該選哪一個?

原文連接: blog.thinkeridea.com/201903/go/s…html

Go 內置不少種數值類型,每每初學者不知道編寫程序如何選擇,使用哪一種數值類型更有優點。編程

內置的數值類型有:uint8uint16uint32uint64uintint8int16int32int64intjson

從類型名稱上能夠很好了解到類型的大小,這個很是直觀,uintint 這兩種類型是不帶大小的,那麼它們的大小會根據編譯參數 GOARCH=amd64 平臺決定的。ide

我最先設計的一個go的項目,當時設計系統使用採用最小類型原則,幾乎使用了大多數數值類型,不多使用 uintint 類型,後來遇到不少問題,標準庫和三方庫函數都接收 intuintint64uint64, 一些代碼生成工具, 好比 protobuf 生成類型是 int32,一些三方系統大多數也是 int 類型,這時候與其它組件件的交互就須要 類型轉換, 類型轉換成本是很高的,致使程序性能並無預期的好。函數

上面一個小故事(事故)警醒你們不要一味的根據數據的大小選擇數值類型,而要考慮數值的用來作什麼,後面會有哪些交互,須要調用哪些函數等等,是否是選擇數值具體使用什麼類型很複雜呢?並非這樣,考慮的越少,選擇越簡單,下面有一些近些年的總結。工具

  • 須要原子操做的數值根據數據大小選擇 int32int64uint32uint64。由於原子類型的操做包天生支持這些類型。
  • 須要與代碼生成的交互的數據,能夠看生成的代碼具體使用哪一種類型,作一下參考。
  • 須要調用大多數標準庫函數進行處理,選這個 int (咱們的程序大多數跑在64位系統上,若是運行在32系統,且類型可能會超過 int32 能夠選擇 int64) 。
  • 有些時候可能咱們須要一個無符號數據且比較大優先選用 uintuint64
  • 只和本身的函數交互以及一些不關注具體類型的包(jsonfmt)交互式時,按數值使用範圍選擇最小類型。

我如今寫代碼一些特殊場景如原子操做會針對使用的包選擇具體類型,偶爾會使用uint64,每每是一些按位作一些複雜計算的數據,也都侷限在局部邏輯上,與其它模塊或者系統交互的都會使用 int 類型,這樣能夠大幅度下降數值類型的類型轉換問題,從而從空間換取時間,得到更好的程序性能。性能

不得不說說 Go 語言神奇的 int 類型,爲何須要這樣一個編程是沒法肯定具體長度的類型呢,而須要在編譯時肯定呢,有什麼好處呢。ui

每每咱們寫程序是不太關注數值類型的,或者說咱們程序中不少數值不會超過 int32 的最大值(每每咱們的程序運行在 32 或 64位平臺上),這個時候不少三方庫均可以使用 int 做爲交互類型,不用把一個函數爲每種類型數值都寫一遍,能簡化標準庫。咱們也能寫出更容易維護、簡潔的系統。idea

轉載:spa

本文做者: 戚銀(thinkeridea

本文連接: blog.thinkeridea.com/201903/go/s…

版權聲明: 本博客全部文章除特別聲明外,均採用 CC BY 4.0 CN協議 許可協議。轉載請註明出處!

相關文章
相關標籤/搜索