타입 안전이란 무엇입니까?
답변:
형식 안전성은 컴파일러가 컴파일하는 동안 형식의 유효성을 검사하고 변수에 잘못된 형식을 할당하려고하면 오류를 발생시킵니다.
몇 가지 간단한 예 :
// Fails, Trying to put an integer in a string
String one = 1;
// Also fails.
int foo = "bar";
명시적인 형식을 전달하기 때문에 메서드 인수에도 적용됩니다.
int AddTwoNumbers(int a, int b)
{
return a + b;
}
내가 그것을 사용하여 전화하려고하면 :
int Sum = AddTwoNumbers(5, "5");
문자열 ( "5")을 전달하고 있고 정수를 기대하기 때문에 컴파일러에서 오류가 발생합니다.
자바 스크립트와 같이 느슨하게 입력 된 언어로 다음을 수행 할 수 있습니다.
function AddTwoNumbers(a, b)
{
return a + b;
}
내가 이것을 이렇게 부르면 :
Sum = AddTwoNumbers(5, "5");
Javascript는 5를 문자열로 자동 변환하고 "55"를 반환합니다. 이는 문자열 연결에 + 기호를 사용하는 자바 스크립트 때문입니다. 형식을 인식하려면 다음과 같은 작업을 수행해야합니다.
function AddTwoNumbers(a, b)
{
return Number(a) + Number(b);
}
또는 아마도 :
function AddOnlyTwoNumbers(a, b)
{
if (isNaN(a) || isNaN(b))
return false;
return Number(a) + Number(b);
}
내가 이것을 이렇게 부르면 :
Sum = AddTwoNumbers(5, " dogs");
Javascript는 5를 문자열로 자동 변환하고 추가하여 "5 개"를 반환합니다.
모든 동적 언어가 자바 스크립트만큼 용서하는 것은 아닙니다 (사실 동적 언어가 느슨한 유형의 언어를 의미하지는 않습니다 (Python 참조)). 이들 중 일부는 실제로 유효하지 않은 유형 캐스팅에서 런타임 오류를 발생시킵니다.
편리하지만 쉽게 놓칠 수있는 많은 오류가 발생하며 실행중인 프로그램을 테스트해야만 식별 할 수 있습니다. 개인적으로, 나는 실수를 저지른 경우 컴파일러에게 알려주기를 선호합니다.
이제 C #으로 돌아가서
C #은 covariance 라는 언어 기능을 지원합니다. 이는 기본적으로 하위 유형을 기본 유형으로 대체하고 오류를 발생시키지 않을 수 있음을 의미합니다.
public class Foo : Bar
{
}
여기에서 Bar를 서브 클래스로 만드는 새 클래스 (Foo)를 만들었습니다. 이제 메소드를 작성할 수 있습니다.
void DoSomething(Bar myBar)
그리고 Foo 또는 Bar를 인수로 사용하여 호출하면 오류없이 작동합니다. 이것은 C #이 Bar의 모든 하위 클래스가 Bar의 인터페이스를 구현한다는 것을 알고 있기 때문에 작동합니다.
그러나 그 반대는 할 수 없습니다.
void DoSomething(Foo myFoo)
이 상황에서 컴파일러가 Bar가 Foo의 인터페이스를 구현한다는 것을 알지 못하므로 Bar를이 메소드에 전달할 수 없습니다. 자식 클래스는 부모 클래스와 크게 다를 수 있기 때문입니다.
물론, 이제는 원래 질문의 범위를 넘어서고 있지만 모든 좋은 점을 알고 있습니다. :)
타입 안전성을 정적 / 동적 타이핑 또는 강력 / 약한 타이핑과 혼동해서는 안됩니다.
형식 안전 언어는 데이터에서 실행할 수있는 유일한 작업이 데이터 형식에 의해 용인되는 언어입니다. 즉, 데이터가 유형 X이고 Xoperation을 지원하지 않으면 y언어에서 실행할 수 없습니다 y(X).
이 정의는 이것이 체크 될 때 규칙을 설정하지 않습니다 . 일반적으로 예외를 통해 컴파일 타임 (정적 타이핑) 또는 런타임 (동적 타이핑) 일 수 있습니다. 일부 정적으로 입력 된 언어의 하나 개의 유형에서 다른 캐스트 데이터를 허용하고, 캐스트의 유효성이 런타임 (당신이 캐스팅하려고하는 상상에서 점검해야합니다 : 그것은 모두의 비트 수 없다 ObjectA를 Consumer컴파일러는 더있다 - 그것이 수용 가능한지 아닌지를 아는 방법).
타입 안전은 반드시 강력하게 타입을 의미하는 것은 아니며, 일부 언어는 약한 타입이지만 악명 높은 타입은 안전합니다. 예를 들어, 자바 스크립트를 보자. 형식 시스템은 약하지만 여전히 엄격하게 정의되어있다. 데이터를 자동으로 캐스팅 할 수 있지만 (예 : 문자열을 int로) 잘 정의 된 규칙 내에서 가능합니다. Javascript 프로그램이 정의되지 않은 방식으로 작동하는 경우는 없으며, 영리한 사람이라면 (잘 모르겠습니다) Javascript 코드를 읽을 때 발생할 일을 예측할 수 있어야합니다.
형식이 안전하지 않은 프로그래밍 언어의 예는 C입니다. 배열 범위 외부에서 배열 값을 읽거나 쓰면 사양에 따라 정의되지 않은 동작 이 있습니다 . 일어날 일을 예측하는 것은 불가능합니다. C는 타입 시스템을 가지고 있지만 타입 안전하지 않은 언어입니다.
형식 안전성은 컴파일 시간 제약 조건이 아니라 런타임 제약 조건입니다. 이 모든 시간이 지나도 더 명확 해집니다.
유형 안전과 관련된 두 가지 주요 문제가 있습니다. 메모리 ** 및 데이터 유형 (해당 작업 포함).
기억**
A는 char일반적으로 문자 당 1 바이트 또는 8 개 비트를 요구 (16 개 비트를 필요로 언어, 자바 및 C # 저장소 유니 코드 문자에 따라 다름). 는 int4 바이트 또는 32 비트 (통상) 필요로한다.
시각적으로 :
char: |-|-|-|-|-|-|-|-|
int : |-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-|
타입 안전 언어는 런타임에 int를 char에 삽입 할 수 없습니다 (이는 일종의 클래스 캐스트 또는 메모리 부족 예외를 발생시켜야 함). 그러나 안전하지 않은 유형의 언어에서는 기존 데이터를 더 인접한 3 바이트의 메모리에 덮어 씁니다.
int >> char:
|-|-|-|-|-|-|-|-| |?|?|?|?|?|?|?|?| |?|?|?|?|?|?|?|?| |?|?|?|?|?|?|?|?|
위의 경우 오른쪽의 3 바이트를 덮어 쓰므로 예측 가능한 char 값을 얻을 것으로 예상되는 해당 메모리에 대한 포인터 (예 : 3 개의 연속 문자)는 이제 가비지가됩니다. 이로 인해 undefined프로그램에서 동작 이 발생 합니다 (또는 요즘 OS가 메모리를 할당하는 방식에 따라 다른 프로그램에서 더 악화 될 수 있습니다).
** 이 첫 번째 문제는 기술적으로 데이터 형식에 관한 것이 아니지만 형식 안전 언어는 기본적으로이를 해결하며 메모리 할당이 어떻게 보이는지 알지 못하는 사람들에게 문제를 시각적으로 설명합니다.
데이터 형식
보다 미묘하고 직접적인 유형 문제는 두 데이터 유형이 동일한 메모리 할당을 사용하는 것입니다. 정수와 부호없는 정수를 취하십시오. 둘 다 32 비트입니다. (char [4]와 int 일 수는 있지만, 가장 일반적인 문제는 uint와 int입니다.)
|-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-|
|-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-|
안전하지 않은 타입의 언어는 프로그래머가 32 비트의 적절하게 할당 된 범위를 참조 할 수있게하지만, 부호없는 int의 값을 int의 공간으로 읽어 들일 때 (또는 그 반대로), 우리는 다시 undefined동작을합니다. 뱅킹 프로그램에서 발생할 수있는 문제를 상상해보십시오.
"Dude! 나는 30 달러를 초과 인출했고 이제 $ 65,506가 남았습니다!"
... '물론 은행 프로그램은 훨씬 더 큰 데이터 유형을 사용합니다. ;) LOL!
다른 사람들이 이미 지적했듯이 다음 문제는 유형에 대한 계산 작업입니다. 그것은 이미 충분히 다루어졌습니다.
속도 대 안전
오늘날 대부분의 프로그래머는 C 또는 C ++과 같은 것을 사용하지 않는 한 그러한 것에 대해 걱정할 필요가 없습니다. 두 언어 모두 프로그래머가 위험을 최소화하려는 최선의 노력에도 불구하고 프로그래머가 런타임시 유형 안전을 쉽게 위반할 수 있습니다 (직접 메모리 참조). 그러나 이것은 모두 나쁜 것은 아닙니다.
이러한 언어가 계산 속도가 빠른 이유 중 하나는 Java와 같은 런타임 작업 중에 형식 호환성을 확인하여 부담을주지 않기 때문입니다. 그들은 개발자가 문자열과 정수를 함께 추가하지 않는 좋은 합리적 존재라고 가정하며, 이에 대해 개발자에게는 속도 / 효율이 보상됩니다.
여기에 많은 답변이 타입 안전성과 정적 타이핑 및 동적 타이핑을 혼동합니다. 스몰 토크와 같이 동적으로 유형이 지정된 언어도 유형에 안전합니다.
짧은 대답 : 작업이 정의되지 않은 동작을 유발하지 않으면 언어는 유형 안전으로 간주됩니다. 자동 변환은 때때로 잘 정의되지만 예기치 않은 / 직관적이지 않은 동작으로 이어질 수 있으므로 언어를 엄격하게 입력 하는 데 필요한 명시 적 유형 변환 요구 사항을 고려하는 사람들이 많습니다 .
if no operation leads to undefined behavior.
comp sci 전공이 아닌 교양 전공의 설명 :
사람들이 언어 또는 언어 기능이 유형 안전하다고 말하면, 언어가 정수가 아닌 무언가를 정수를 기대하는 논리에 전달하는 것을 방지하는 데 도움이된다는 의미입니다.
예를 들어 C #에서 함수를 다음과 같이 정의합니다.
void foo(int arg)
그런 다음 컴파일러는이 작업을 수행하지 못하게합니다.
// call foo
foo("hello world")
다른 언어에서는 컴파일러가 나를 멈추지 않거나 (또는 컴파일러가 없습니다 ...) 문자열이 논리에 전달되면 잘못된 것이 발생할 수 있습니다.
타입 안전 언어는 "컴파일 시간"에 더 많이 잡으려고합니다.
"123"과 같은 문자열이 있고 int처럼 조작하려면 문자열을 int로 변환하거나 int가있을 때 더 많은 코드를 작성해야합니다. 123 같은 "답은 123"같은 메시지에 사용하려면 문자열로 변환 / 캐스팅하기 위해 더 많은 코드를 작성해야합니다.
더 나은 이해를 위해 아래 안전 비디오 (C #) 및 NOT 형식 안전 언어 (javascript)의 코드를 보여주는 아래 비디오를 시청하십시오.
http://www.youtube.com/watch?v=Rlw_njQhkxw
이제 긴 텍스트입니다.
유형 안전은 유형 오류를 방지하는 것을 의미합니다. 한 유형의 데이터 유형이 다른 유형에 알 수 없을 때 유형 오류가 발생하여 원하지 않는 결과가 발생합니다.
예를 들어 JavaScript는 형식이 안전한 언어가 아닙니다. 아래 코드에서 "num"은 숫자 변수이고 "str"은 문자열입니다. Javascript를 사용하면“num + str”을 수행 할 수 있습니다. 이제 GUESS는 산술 또는 연결을 수행합니다.
이제 아래 코드의 결과는 "55"이지만 중요한 점은 어떤 종류의 작업을 수행하는지 혼란이 발생한다는 것입니다.
이것은 자바 스크립트가 형식에 안전한 언어가 아니기 때문에 발생합니다. 제한없이 한 유형의 데이터를 다른 유형으로 설정할 수 있습니다.
<script>
var num = 5; // numeric
var str = "5"; // string
var z = num + str; // arthimetic or concat ????
alert(z); // displays “55”
</script>
C #은 형식이 안전한 언어입니다. 한 데이터 유형을 다른 데이터 유형에 지정할 수 없습니다. 아래 코드는 다른 데이터 유형에서 "+"연산자를 허용하지 않습니다.
형식 안전은 프로그래밍 방식으로 변수, 반환 값 또는 인수에 대한 데이터 형식이 특정 기준에 맞아야한다는 것을 의미합니다.
실제로 이것은 7 (정수 유형)이 "7"(문자열 유형의 인용 문자)과 다르다는 것을 의미합니다.
PHP, Javascript 및 기타 동적 스크립팅 언어는 일반적으로 "7"+ 3을 추가하려고 할 때 (문자열) "7"을 (정수) 7로 변환한다는 점에서 약한 유형입니다. 명시 적으로 (그리고 Javascript는 연결에 "+"문자를 사용합니다).
C / C ++ / Java는이를 이해하지 못하거나 결과를 "73"으로 연결합니다. 형식 안전성은 형식 요구 사항을 명시 적으로 만들어 코드에서 이러한 유형의 버그를 방지합니다.
타입 안전은 매우 유용합니다. 위의 "7"+ 3에 대한 해결책은 캐스트 (int) "7"+ 3 (10과 같음)을 입력하는 것입니다.
이 설명을 시도해보십시오 ...
TypeSafe는 컴파일 타임에 변수가 적절한 할당을 위해 정적으로 검사됨을 의미합니다. 예를 들어 문자열 또는 정수를 고려하십시오. 이 두 가지 다른 데이터 유형은 교차 할당 할 수 없습니다 (즉, 정수를 문자열에 할당 할 수없고 문자열을 정수에 할당 할 수 없습니다).
비 유형 안전 동작의 경우 다음을 고려하십시오.
object x = 89;
int y;
이 작업을 시도하면 :
y = x;
컴파일러는 System.Object를 정수로 변환 할 수 없다는 오류를 발생시킵니다. 명시 적으로해야합니다. 한 가지 방법은 다음과 같습니다.
y = Convert.ToInt32( x );
위의 과제는 형식이 안전하지 않습니다. 타입 세이프 할당은 타입을 서로 직접 할당 할 수있는 곳입니다.
ASP.NET에는 형식이 안전하지 않은 컬렉션이 많이 있습니다 (예 : 응용 프로그램, 세션 및 viewstate 컬렉션). 이러한 컬렉션에 대한 좋은 소식은 여러 서버 상태 관리 고려 사항을 최소화하면서 세 가지 컬렉션 중 하나에 거의 모든 데이터 유형을 넣을 수 있다는 것입니다. 나쁜 소식 : 이러한 컬렉션은 형식이 안전하지 않기 때문에 값을 다시 가져올 때 값을 적절하게 캐스팅해야합니다.
예를 들면 다음과 같습니다.
Session[ "x" ] = 34;
잘 작동합니다. 그러나 정수 값을 다시 할당하려면 다음을 수행해야합니다.
int i = Convert.ToInt32( Session[ "x" ] );
타입 세이프 컬렉션을 쉽게 구현할 수있는 기능에 대한 제네릭에 대해 읽어보십시오.
C #은 형식이 안전한 언어이지만 C # 4.0에 대한 기사를주의하십시오. 흥미로운 역동적 가능성이 있습니다 (C #이 본질적으로 Option Strict : Off ...를 얻는 것이 좋은 것입니다).
타입 안전은 프로그램 변수에 할당 될 수있는 값 세트가 잘 정의되고 테스트 가능한 기준에 맞아야한다는 것을 의미합니다. 변수를 조작하는 알고리즘은 변수가 잘 정의 된 값 세트 중 하나만 취할 것이라고 신뢰할 수 있기 때문에 유형 안전 변수는보다 강력한 프로그램으로 이어집니다. 이러한 신뢰를 유지하면 데이터와 프로그램의 무결성과 품질이 보장됩니다.
많은 변수의 경우 변수에 할당 될 수있는 값 세트는 프로그램이 작성 될 때 정의됩니다. 예를 들어, "colour"라는 변수는 "red", "green"또는 "blue"값을 사용할 수 있으며 다른 값은 사용하지 않을 수 있습니다. 다른 변수의 경우 이러한 기준이 런타임에 변경 될 수 있습니다. 예를 들어, "color"라는 변수는 관계형 데이터베이스에서 "Colours"테이블의 "name"열에있는 값만 사용할 수 있습니다. 여기서 "red,"green "및"blue "는 3 개의 값입니다. "Colours"테이블의 "name"에 대한 것이지만 프로그램이 실행되는 동안 컴퓨터 프로그램의 다른 부분이 해당 목록에 추가 될 수 있으며 변수가 색상 테이블에 추가 된 후 새 값을 사용할 수 있습니다. .
많은 유형 안전 언어는 변수 유형을 엄격하게 정의하고 변수에 동일한 "유형"의 값만 할당 할 수 있도록하여 "유형 안전"의 환상을 제공합니다. 이 방법에는 몇 가지 문제가 있습니다. 예를 들어, 프로그램에는 사람이 태어난 연도 인 "yearOfBirth"변수가있을 수 있으며 짧은 정수로 형식 캐스트하려고합니다. 그러나 짧은 정수는 아닙니다. 올해는 2009 년보다 작고 -10000보다 큰 숫자입니다. 그러나이 세트는 프로그램 실행에 따라 매년 1 씩 증가합니다. 이것을 "short int"로 만드는 것은 충분하지 않습니다. 이 변수를 안전한 유형으로 만드는 데 필요한 것은 런타임 유효성 검사 기능으로, 숫자는 항상 -10000보다 크고 내년보다 적습니다.
Perl, Python, Ruby, SQLite 및 Lua와 같이 동적 입력 (또는 오리 입력 또는 매니페스트 입력)을 사용하는 언어에는 입력 변수 개념이 없습니다. 이를 통해 프로그래머는 모든 변수에 대해 런타임 유효성 검사 루틴을 작성하여 변수가 올바른지 확인하거나 설명 할 수없는 런타임 예외의 결과를 견뎌야합니다. 필자의 경험에 따르면 C, C ++, Java 및 C #과 같이 정적으로 형식이 지정된 언어의 프로그래머는 정적으로 정의 된 형식이 형식 안전성의 이점을 얻기 위해 수행해야하는 전부라고 생각하는 경우가 많습니다. 이것은 많은 유용한 컴퓨터 프로그램에는 해당되지 않으며 특정 컴퓨터 프로그램에 해당되는지 예측하기 어렵습니다.
길고 짧은 .... 타입 안전을 원하십니까? 그렇다면 런타임 함수를 작성하여 변수에 값이 지정 될 때 변수가 올바르게 정의 된 기준을 준수하는지 확인하십시오. 단점은 각 프로그램 변수에 대한 기준을 명시 적으로 정의해야하기 때문에 대부분의 컴퓨터 프로그램에서 도메인 분석이 실제로 어렵다는 것입니다.