0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

Goの組込みデータ型を整理した

Posted at

コードらしいコードは書いてない...

概略

  • 論理型

    • bool
  • 文字列型

    • string
  • 整数型

    • 符号付き整数型
      • int
      • int8
      • int16
      • int32 ( = rune)
      • int64
    • 符号なし整数型
      • uint
      • uint8 ( = byte)
      • uint16
      • uint32
      • uint64
      • uintptr
  • 浮動小数点型

    • float32
    • float64
  • 複素数型

    • complex64
    • complex128
  • エラー型

    • Error

論理型

bool

trueまたはfalseしか取りうる値が存在しない最も単純なデータ型

文字列型

string

  • 8bit/byteの文字列型
  • UTF-8 encodedではない場合もある
  • 空文字でもnilでもよい
  • immutableである

整数型

符号付き整数型

int

最低32bit以上の符号付き整数型だが、int32型のエイリアスではない。

int8

8bitの符号付き整数型で、-128~127の範囲の整数を表現できる。

int16

16bitの符号付き整数型で、-32768~32767の範囲の整数を表現できる。

int32 ( = rune)

32bitの符号付き整数型で、-2147483648~2147483647の範囲の整数を表現できる。

runeint32型のエイリアスで、これについてはThe Go Blogに記述がある。

To summarize, here are the salient points:

  • Go source code is always UTF-8.
  • A string holds arbitrary bytes.
  • A string literal, absent byte-level escapes, always holds valid UTF-8 sequences.
  • Those sequences represent Unicode code points, called runes.
  • No guarantee is made in Go that characters in strings are normalized.

和訳した。

要約すると、以下のようになります。

  • Goのソースコードは常にUTF-8です。
  • 文字列は任意のバイトを保持します。
  • 文字列リテラルは、バイトレベルのエスケープを除いて、常に有効な UTF-8 シーケンスを保持します。
  • これらのシーケンスは、runeと呼ばれる Unicode コードポイントを表しています。
  • Goでは、文字列内の文字が正規化されていることを保証するものではありません。

まだちょっとわからないので調べると、こんな記述を見つけた。(出典:String と Rune — プログラミング言語 Go | text.Baldanders.infoにて)

文字列を文字単位で扱うには rune 型を使う2

この記事も見ると良さそう。

int64

64bitの符号付き整数型で、-9223372036854775808~9223372036854775807の範囲の整数を表現できる。

符号なし整数型

uint

最低32bit以上の符号なし整数型だが、uint32型のエイリアスではない。

uint8 ( = byte)

8bitの符号なし整数型で、0~255の範囲の整数を表現できる。

byteuint8のエイリアスで、公式Docでは以下のように説明されている。

byte is an alias for uint8 and is equivalent to uint8 in all ways. It is used, by convention, to distinguish byte values from 8-bit unsigned integer values.

byte は uint8 の別名であり、すべての点で uint8 と同等です。慣習的に、バイト値を8ビットの符号なし整数値と区別するために使用されます。

uint16

16bitの符号なし整数型で、0~65535の範囲の整数を表現できる。

uint32

32bitの符号なし整数型で、0~4294967295の範囲の整数を表現できる。

uint64

64bitの符号なし整数型で、0~18446744073709551615の範囲の整数を表現できる。

uintptr

ドキュメントを直訳すると「uintptr は、任意のポインタのビットパターンを保持するのに十分な大きさの整数型です。」となる(DeepL様様)。

どんな場面で使うんだ...と思ってたが、StackOverflowで触れられていた。

The short answer is "never use uintptr". 😀

The long answer is that uintptr is there to bypass the type system and allow the Go implementors to write Go runtime libraries, including the garbage collection system, in Go, and to call C-callable code including system calls using C pointers that are not handled by Go at all.

If you're acting as an implementor—e.g., providing access to system calls on a new OS—you'll need uintptr. You will also need to know all the special magic required to use it, such as locking your goroutine to an OS-level thread if the OS is going to do stack-ish things to OS-level threads, for instance. (If you're using it with Go pointers, you may also need to tell the compiler not to move your goroutine stack, which is done with special compile-time directives.)

どうやら低レイヤーの処理を実装しない限りはめったに使うことがないらしい。

当面は気にしないことにした。

浮動小数点型

IEEE-754式については 以下を参照。

float32

IEEE-754式の32bit浮動小数点型

float64

IEEE-754式の64bit浮動小数点型

ちなみに数学計算するためのmathパッケージで定義された関数のほとんどは引数も返り値もfloat64型でしか定義されていないで、注意が必要。まあGoにはオーバーロードがないので当然っちゃぁ当然。

複素数型

複素数型の扱いを確認するならこの辺の記事を見ると良さそう。

complex64

実部と虚部をfloat32型で表現する複素数型

complex128

実部と虚部をfloat64型で表現する複素数型

エラー型

error

Goにはtry-catch-finallyといったエラーハンドリング表現が存在しないので、このerror型のinterfaceに対してエラー処理を実装する。

type error interface {
    Error() string
}
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?