Go는 정적인 자료형을 사용하는 언어라 한다. 정적 자료형은 컴파일 시점에 자료형이 결정되는 것이고 동적 자료형은 코드가 실행될 때 자료형이 결정되는 것이다.
자신이 사용하는 프로그래밍 언어를 두 가지 기준으로 생각하면 되는데 코드를 실행하는 방법이 컴파일(compile)인지 인터프리터(interpreter)인지 구분만 할 수 있으면 정적인지 동적인지 쉽게 알 수 있을 것이다. 그리고 Go는 meth모듈에서 자료형의 MaxValue와 MinValue를 사용할 수 있다.
math모듈의 상수
boolean( true / flase ) boolean type은 명시적으로 변수 선언 시 bool이라는 예약어를 사용하고 묵시적으로도 변수를 선언할 수 있다. 묵시적으로 변수를 선언 시 무조건 변수의 값을 초기화시켜야 하기 때문에 기본값을 지정해줘야 하는데 명시적으로 변수 선언 시 값을 초기화 안 해도 false로 값이 초기화된다. booelan type variable
부호 있는 정수(signed int) java와 달리 go는 int [8, 16, 32, 64]이런 식으로 자료형의 크기를 나타낸다. 부호가 있는 정수 타입은 bit의 왼쪽에서 첫 번째 bit(msb [most significant bit])는 음수, 양수를 표현하기 때문에 1이면 음수, 0이면 양수를 표현한다.int keyword
부호 없는 정수(unsigned int) 부호가 없으니 음수를 표현 못 하지만 부호 있는 정수와 같은 bit지만 더 큰 값을 사용할 수 있다. go에도 java와 같이 byte예약어가 있는데 go에선 부호 없는 정수인 uint8의 다른 이름으로 정의됐다고 한다. go의 byte는 java의 char와 같다. unsigned int keyword
부호 있는 정수와 부호 없는 정수의 최대 표현할 수 있는 값이 다른데 그 이유는 msb 자리에 부호가 아닌 2의 제곱으로 표현할 수 있어서 이다.
환경(운영체제?)에 의존하는 정수 자료형 이건 잘 모르겠지만 go로 코딩하면서int64를int로 묵시적 형 변환을 안 해줘서 짜증 낫던 부분이 있었는데int가int64보다 표현할 수 있는 bit가 작아서 묵시적 형 변환을 안 해줬나? 하고 대충 이해했는데 책을 읽고 이유를 알았다. go언어는 이상하게int~몇unint~몇이렇게 정수를 선언해야 하는데int와unint은 별도로 존재하는 부분이 이해가 안 됐다. 간단하게 설명하자면 64bit 운영체제에서는int64나uint64를 사용할 수 있는데 32bit 운영체제에선 사용할 수 없기 때문에int와uint예약어를 지원해서 각각의 운영체제에 맞게 최대 사용할 수 있는 정수를 사용할 수 있도록 지원한다는 것이다. go는 pointer를 지원하는 언어이기 때문에uintptr예약어도 있는데 CPU나 OS에 따라 포인터가 사용하는 메모리 주소의 크기가 다르기 때문에 지원한다 하고 "특수한 형태로 포인터 값을 그대로 저장하는 데 충분한 크기의 부호 없는 정수라고 정의"라고 책에 나와있다.
정수 데이터 표현 Go나 java나 정수를 표현할 때 8, 10, 16진수를 사용할 수 있다. 숫자 0으로 시작하면 8진수 0x로 시작하면 16진수 그 외 10진수이다. 예를 들어 10진수의 15는 8진수의 017이고 16진수는 0xF이다. 16진수를 표현할 때 a부터 f까지 대소문자 상관없이 입력이 가능하다. 8, 10, 16진수로 10진수 15를 표현
자료형 변환(casting) Go는 java와 달리 묵시적 형 변환을 해주지 않는다.
위 사진처럼 Go는 명시적 자료형 변환을 해야 하기 때문에 답답할 수도 있지만 그건 충분히 해결할 수 있는 문제이다. Go는 묵시적 선언을 통해 컴파일 시점에서 타입 추론으로 인해 타입이 정해지기 때문이고 정수형의 기본 타입은 int이기 때문에 운영체제에 따라 최대 표현할 수 있는 정수까지 사용할 수 있다. 굳이 자료형 변환을 할 필요가 없다는 뜻이다. 만약 메모리를 무조건 적게 만들어야 하고 입력값이 정해져 있다면 해야겠지만 ㅎㅎ;;;
오늘은 여기까지 하고 다음 시간에는 unsigned int와 정수 자료형 변환에 의한 문제와 랩어라운드(wrap around)를 포스트 하겠다.
