티스토리 뷰
프로그램 개발할때 선언문이 필요한 이유
@시간@ 2019. 12. 19. 01:09
머리말형 선언과는
이 말의 의미가 통하지 않는 사람은 별로 없다고는 생각하지만, 어쩌면 인터프리타계열의 언어밖에 이 없는 분은 애초에 "형선언"자를 잘 모를지도 모릅니다.그래도 틀이라고 하지다짐은 의식하고 있는 일이니까, 이 자리에서는 형선언이란 형을 기술해서 명시하는 것이라고 이해해주면 된다고 생각합니다.여기서 말하는 것은 의 정의를 행할 때 인의 정의에 형을 명시한다는 것입니다.> VBA라면 이하의 같은 느낌이 됩니다.Func1(Arg1 As Integer)머리말Arg1에그리고 Integer라는 틀을 선언하고 있습니다."VBA 같은 건 몰라요"라는 사람이 많을 수도 있지만, 특별히 언어에 의존할한 이슈가 아니니 너무 우습게 보지 마세요.밀하게 VBA 문법에 음도 아니고, 념적인 기술이라서요. 이번 이야기는 이 Integer의 기술은 왜 필요하냐는 이야기입니다.
선언한 경우 아닌 경우와의 차이점은 뭔가
그럼, 왜 형선언이 필요한지를 생각해에, 형선언하지 않는 경우로 했을 경우에 어떠한 차이가 생기는지를 살펴보려고 합니다.사실 VBA에는 형을 명시하지 않는 형이라는 것이 존재합니다.Variant형이라는 것입니다. 일형이기 때문에 다른 형과 동에 기술할 수 있습니다.즉 이하의 에 기술할 수 있습니다.Func1(Arg1 As Variant)그러나 형식적으로는 틀로서 기술하고있습니다만라고는 어떤 형태인지는 불명입니다.과연 Arg1이값형인지 문자형인지, 아무것도 모릅니다. 그리고 쉽게 상상이 가도록 이하의에 형의 기술을 생략한 경우는 이 Variant형을 할당할 수 있습니다.
Func1(Arg1)이 Variant형의 시의 틀이 결정되는 것은 행시입니다.즉 다음과에 Func1에 머리말 사랑을 지정하고 불렀을 때, 그 내용에 변하여 Arg1의때의 형(Integer)이 확정합니다.
Main() Func1(1230)즉 형을 선언하는 언어에도 어긋나지 않고, Variant를 사용하면 형선언이 없는 인터 프리타에 부적으로 자동적으로 형이리된다고 입니다. 그러면 명시적으로 Integer와 형 선언했을 경우와 Variant로 했을 경우에는 어떤 차이가 일어나는 것일까요그 사랑에는 Func1이치의 내용도 필요한 것으로 여기에서는 이하의에 Arg1을 두배로 할까이치라고 합니다.Result는 라고 생각해주세요.
Func1(Arg1) Result=Arg1*2그럼 이 전제로 형선언이 있는 경우와 없는 경우로 문자형(String)의 을 인으로 지정해서 호출하면 어떻게 되는지 보고싶다고 생각합니다.
형 선언이 있는 경우
Main() Value As String Func1(Value)
Func1(Arg1 As Integer) Result=Arg1*2이 경우 컴파일 엘라호출의 기술인"Func1(Value)"부분이 형의 부정합으로 에러.입니다. 다음으로 형선언이 없는 경우입니다.
형 선언이 없는 경우
Main() Value As String Func1(Value)
Func1(Arg1) Result=Arg1*2컴파일은 엘라가 되지 않습니다.Arg1의 형이행 안 한다고 확정하지 않으니깐요. 가면 Arg1의 형태가 문자형(String)에서 확정하고이치의 부분의 "Arg1*2"에서 형의 부정합으로 에러.입니다. 즉 형 선언을 하면 컴파일 시에 엘라 형선언을 해야지 행시에 엘라 는 결과가 됩니다. VBA는 인터 프리타이기 때문에 컴파일하고 행 형식의 파일을 생성할 수 있는 방법은 없습니다.그러나 디버깅용 기능에 "컴파일을 한다"는 기능이 있어, 이것을 사용하면 사전에 컴파일에라를 확인할 수 있습니다.
선언하는 이유
이상의 일로부터 알 수 있니에 인의 형 선언은행시 엘라를 회피하기 위해
라고 할 수 있습니다. 그리고 왜 그인 필요가 있냐면, 보다 근본적인 대원칙이다.
> 문제점은 보다 상류공정에서 으깨는
입니다. 만약 제조의 문제점을 제조 공정에서 퇴치하지 못하고 도려내서, 테스트 공정에 가버리면 거기서 찌르는 것은 몇 배나 파워가 든다는 것입니다.정말로구에서 밝혀진 일이고, 감적으로도 충분히 납득이 가는 일이 아닐까요리스 후의 유자앞으로의 운용이 가장 하류의 공정이라고 생각하면, 거기까지 문제점이 흘러들어 간다면, 얼마나 여분의 파워가 필요하게 될지는 누가 봐도 분명할 것입니다.그리고 형의 선언을 해야 행시에밖에 엘라를 모르기 때문에, 혹시 테스트때도 찾지 못했다면 시에 유자 앞까지 가버릴 가능성이 있습니다. 이번에는 인서의 형 선언을 예로 들어 밝혔습니다만, 사실 이 대원칙은 곳곳에서 뵙겠습니다.예를 들어 클래스의 정의로 속성을 만드는 것을 단절하여 인으로 해 버리면 같은 구조가 됩니다.
사각형의 요의 괘선의 ON/OFF를 각각 속성으로 정의하는
Border.Left = TRUE이름(Left)이 틀리면 컴파일 엘라가 된다.
을 잔뜩로 지정하는
Border("Left") TRUE이름이 틀린 경우는 행시가 되어야 엘라가 나온다. 모든 것은 문제점을 하류로 흘리지 않아라고 할 수 있습니다.
왜 선언을 하지 않는가
이상과 같이 인의 형 선언은 개공정전에서 봤을때의 파워를 삭감할래라고 할 수 있습니다.따라서 기본적으로는 선언해야 하지만, Variant의인 것이 준비되어 있는 대로, 선언하지 않는 경우도 있습니다."형이 확정되지 않는다"고 하는 형을 의식하지 않아도 된다"는 때입니다.그러한 때라는 것은 설계되어 그러한 사양이 될 그렇기 때문에, 결코 "형을 의식하는 것이 큰이기 때문"이라든지 "기술이 귀찮아서"라든지 아닙니다.만약 그렇게을 하고 싶은 것이 이유라면, 그것은 문제를 뒷공정으로 미루어 더 큰 쓴맛을 낳고 있을 뿐입니다.애초에 설계를 하지 않고 제대로 움직이는 것을 할 수 있을 리는 없고, 기술이라고 해도 코딩으로 준에 키를 두드리고 있는 시간 등이라는 것은 개공정전으로 보면 미미한 것입니다.영문 문서를 그냥기할래에 키보드로 쳐할 때의 속도를 상상하면, 준에게 문자를 치는 시간은 지극히 단시간이라는 것을 알 수 있지 않을까요대부분은 생각하고 있는 시간입니다) 라고 올바르게 형을 선언해야 하고, 올바르게 선언하지 않으면 안됩니다. 인터프리터 계열의 스크립트 등으로 형이 필요 없는 것은 그러한 용도의 범에 한정되어 있기 때문입니다.그러한 언어로, 만약 시비어한 시스템을 짜려고 한다면, 순간적으로 어려운 일이 생깁니다.오히려 틀이 갖고 싶어집니다."자동"은 간이 아니다" 하지만 흔들렸지만 자동이라는 것은 매우 어렵기 때문에, 모든 국면에서 형을 자동으로리하는 것은 어렵습니다.앞으로 기술이 발전하여 틀이 세상에서 없어지면 개척자에게 고마운 일이지만... 자기 자신의 로서 C언어의 이러한천을한 적이 있습니다.처음 C언어를 배웠을 때는 이른바 "K&R(가니한과 리치)"의 시대였습니다.(참고로 데니스리치는 스티부산잡스가 숨진 사흘 후에 죽었대요)이때는 기술에 비교적 자유라는르주의인 측면이 있었는데, 그 후 ANSI에서 규격화된 C로 이행하면, 프로토 타입 선언이라며책와 별도로 I/F만을 사전에 선언하는 것이 의무화되었습니다.이로 인해 의 호출에 대해서는 꽤나 현격하게 컴파일 체크를 하게 되었는데, 다들 굉장히 귀찮아해서 불평하던 것을 말해주고 있습니다.그러나 ANSI-C가 되고 나서한 신인은 물논문구 따위는 말하지 않고, 불평하던 사람들도 금방 익숙해져버렸습니다. 코딩에 해서 말하면 아무 일도 정해버리면 때는 크게 붐비지 않는다는 인상입니다.
댓글