데이터 형식 요약(Visual Basic)
다음 표에서는 Visual Basic 데이터 형식, 지원되는 공용 언어 런타임 형식, 명목 스토리지 할당 및 값 범위를 보여 줍니다.
Visual Basic 형식 | 공용 언어 런타임 형식 구조 | 명목 스토리지 할당 | 값 범위 |
---|---|---|---|
Boolean | Boolean | 플랫폼 구현에 따라 다름 | True 또는 False |
Byte | Byte | 1바이트 | 0~255(서명되지 않음) |
Char (단일 문자) | Char | 2바이트 | 0~65535(서명되지 않음) |
날짜 | DateTime | 8바이트 | 0001년 1월 1일 오후 0:00:00(자정) ~ 9999년 12월 31일 오후 11:59:59 |
10진수 | Decimal | 16바이트 | 0에서 +/-79,228,162,514,264,337,593,543,950,335 (+/-7.9...E+28) † 소수점 없음; 0에서 +/-7.9228162514264337593543950335 소수점 오른쪽에 28개 위치; 가장 작은 0이 아닌 숫자는 +/-0.000000000000000000000000001(+/-1E-28) † |
Double (배정밀도 부동 소수점) | Double | 8바이트 | -1.79769313486231570E+308 ~ -4.94065645841246544E-324 음수 값에 대한 † ; 4.94065645841246544E-324 ~ 1.79769313486231570E+308 † 양수 값 |
정수 | Int32 | 4바이트 | -2,147,483,648 ~ 2,147,483,647(서명) |
Long (long 정수) | Int64 | 8바이트 | -9,223,372,036,854,775,808 ~ 9,223,372,036,854,775,807(9.2...E+18 †)(서명) |
Object | Object (클래스) | 32비트 플랫폼의 4바이트 64비트 플랫폼의 8바이트 |
모든 형식을 형식의 변수에 저장할 수 있습니다. Object |
SByte | SByte | 1바이트 | -128~127(서명됨) |
Short (short 정수) | Int16 | 2바이트 | -32,768 ~32,767(서명됨) |
단일 (단정밀도 부동 소수점) | Single | 4바이트 | -3.4028235E+38 ~ -1.401298E-45 † 음수 값; 1.401298E-45~ 3.4028235E+38 † 양수 값 |
문자열 (가변 길이) | String (클래스) | 플랫폼 구현에 따라 다름 | 0~약 20억 개의 유니코드 문자 |
UInteger | UInt32 | 4바이트 | 0~4,294,967,295(서명되지 않음) |
ULong | UInt64 | 8바이트 | 0~18,446,744,073,709,551,615(1.8...E+19 †)(서명되지 않음) |
사용자 정의 (구조) | (에서 ValueType상속) | 플랫폼 구현에 따라 다름 | 구조체의 각 멤버는 데이터 형식에 따라 결정되는 범위와 다른 멤버의 범위와 무관합니다. |
UShort | UInt16 | 2바이트 | 0~65,535(서명되지 않음) |
†과학적 표기법에서 "E"는 10의 힘을 나타냅니다. 따라서 3.56E+2는 3.56 x 102 또는 356을 의미하고 3.56E-2는 3.56/102 또는 0.0356을 의미합니다.
참고
텍스트가 포함된 문자열의 경우 함수를 StrConv 사용하여 한 텍스트 형식에서 다른 텍스트 형식으로 변환합니다.
선언문에 데이터 형식을 지정하는 것 외에도 형식 문자를 사용하여 일부 프로그래밍 요소의 데이터 형식을 강제로 적용할 수 있습니다. 문자 형식을 참조하세요.
메모리 소비
기본 데이터 형식을 선언하는 경우 메모리 사용량이 명목 스토리지 할당과 동일하다고 가정하는 것은 안전하지 않습니다. 이는 다음과 같은 고려 사항 때문입니다.
스토리지 할당. 공용 언어 런타임은 애플리케이션이 실행되는 플랫폼의 현재 특성에 따라 스토리지를 할당할 수 있습니다. 메모리가 거의 가득 차면 선언된 요소를 가능한 한 가깝게 압축할 수 있습니다. 다른 경우에는 메모리 주소를 자연 하드웨어 경계에 맞춰 성능을 최적화할 수 있습니다.
플랫폼 너비입니다. 64비트 플랫폼의 스토리지 할당은 32비트 플랫폼의 할당과 다릅니다.
복합 데이터 형식
구조체 또는 배열과 같은 복합 데이터 형식의 각 멤버에 동일한 고려 사항이 적용됩니다. 형식 멤버의 명목 스토리지 할당을 함께 추가하는 것만으로는 사용할 수 없습니다. 또한 다음과 같은 다른 고려 사항이 있습니다.
오버 헤드. 일부 복합 형식에는 추가 메모리 요구 사항이 있습니다. 예를 들어 배열은 배열 자체 및 각 차원에 대해 추가 메모리를 사용합니다. 32비트 플랫폼에서 이 오버헤드는 현재 각 차원에 대해 12바이트 및 8바이트입니다. 64비트 플랫폼에서 이 요구 사항은 두 배로 증가합니다.
스토리지 레이아웃. 메모리의 스토리지 순서가 선언 순서와 동일하다고 안전하게 가정할 수 없습니다. 2 바이트 또는 4 바이트 경계와 같은 바이트 맞춤에 대한 가정도 할 수 없습니다. 클래스 또는 구조를 정의하고 멤버의 스토리지 레이아웃을 제어해야 하는 경우 클래스 또는 구조체에 StructLayoutAttribute 특성을 적용할 수 있습니다.
개체 오버헤드
Object
기본 또는 복합 데이터 형식을 참조하는 경우 데이터 형식에 포함된 데이터 외에 4바이트를 사용합니다.