유닛의 구조와 문법

출처: http://tech.devgear.co.kr/delphi_news/8116

프로그램은‘유닛’이라는 소스 코드 모듈들로 구성됩니다. 유닛들은 program, library 혹은

package 헤더로 시작되는 특수한 소스 코드 모듈에 의해 함께 묶이게 됩니다. 각 유닛은 각

각의 파일로 저장되고 별도로 컴파일되며, 컴파일된 유닛이 링크되어 애플리케이션이 만들

어집니다. 델파이는 계층적인 네임스페이스를 도입하여 유닛들을 구성하는 데에 더 큰 유연

성을 제공합니다. 네임스페이스와 유닛을 사용함으로써 다음과 같은 일들이 가능해집니다.

 - 큰 프로그램을 별도로 편집 가능한 모듈들로 나눌 수 있습니다.

 - 프로그램들 사이에 공유할 수 있는 라이브러리를 만들 수 있습니다.

 - 소스 코드 없이 다른 개발자에게 라이브러리를 배포할 수 있습니다.

이 장에서는 program 헤더, 유닛 선언 문법, uses 절 등 델파이 애플리케이션의 전반적인

구조를 다룹니다.

프로그램의 구조와 문법

완전한 델파이 애플리케이션은 여러 유닛 모듈들로 구성되며, 그 유닛들은 프로젝트 파일이

라고 불리는 단일 소스 코드 모듈로 묶여집니다. 전통적인 파스칼 프로그래밍에서는 메인 프

로그램을 포함한 모든 소스 코드는 .pas 파일들에 저장되었습니다. 코드기어 개발툴에서는

메인 프로그램 소스 모듈을 지정하는 .dpr 파일을 사용합니다. 대부분의 다른 소스 코드는 전

통적인 .pas 확장자를 가진 유닛 파일들에 저장됩니다. 컴파일러가 프로젝트를 빌드하려면

프로젝트 소스 파일과 함께 각 유닛들의 소스 파일이나 컴파일된 유닛 파일이 필요합니다.

실행 가능한 델파이 애플리케이션의 소스 코드 파일에는 다음과 같은 내용이 들어 있습니다.

 - program 헤더

 - uses 절 (선택적)

 - 선언과 문장 블럭

추가적으로, RAD 스튜디오 프로그램은 제네릭 유닛들을 검색하기 위한 추가적인 네임스페

이스들을 지정하기 위해 네임스페이스 절을 포함할 수도 있습니다.

컴파일러와 IDE는 이들 세가지 파일들을 단일 프로젝트(.dpr) 파일에서 찾으려고 하게 됩니다.

program 헤더

program 헤더는 실행 가능한 프로그램의 이름을 지정합니다. 예약어 program에 유효한

식별자, 그리고 세미콜론(;) 순으로 구성됩니다. 코드기어 툴로 개발된 애플리케이션의 경

우 이 식별자는 프로젝트 소스 파일 이름과 반드시 일치해야 합니다.

다음의 예제는 Editor라는 이름의 프로그램을 위한 프로젝트 소스를 보여줍니다. 이 프로그

 

램의 이름이 Editor이므로, 프로젝트 파일도 Editor.dpr이어야 합니다.

첫 라인은 program 헤더입니다. 이 예제의 uses 절에서는 Forms, ReAbout, ReMain의

세 유닛에 의존함을 알려줍니다. $R 컴파일러 지시자는 이 프로젝트의 리소스 파일을 프로

그램에 링크시킵니다. 마지막으로, begin과 end 예약어 사이의 문장들의 블럭은 프로그램

이 기동될 때 실행됩니다. 다른 모든 델파이 소스 파일들과 마찬가지로 프로젝트 파일도 (세

미콜론이 아닌) 마침표(.)로 끝납니다.

프로그램의 로직 대부분은 유닛 파일에 있기 때문에, 델파이 프로젝트 파일은 대체로 길이

가 짧습니다. 델파이 프로젝트 파일은 일반적으로 애플리케이션의 메인 윈도우를 띄우고 이

벤트 처리 루프를 시작하는 정도의 간단한 코드만 가지고 있습니다. 프로젝트 파일은 IDE

에서 자동으로 생성되고 유지 관리되므로 직접 편집할 필요가 있는 경우는 드뭅니다.

표준 파스칼에서는, 프로그램 헤더의 프로그램 이름 뒤에 다음과 같이 파라미터가 올 수 있

습니다.

 

델파이 컴파일러에서는 이 파라미터는 무시됩니다.

program 헤더는 자신만의 네임스페이스를 시작합니다. 이것을 프로젝트 기본 네임스페이

스라고 합니다.

프로그램의 uses 절

uses 절은 프로그램으로 통합될 유닛들을 나열합니다. 이러한 유닛들도 자체 uses 절을 가질

수 있습니다. uses 절에 대한 자세한 내용은 2장의“유닛 참조와 uses 절”을 참조하십시오.

블럭

블럭에는 프로그램을 실행할 때 실행되는 단순 문장 또는 구조 문장이 있습니다. 대부분의

프로그램에서 블럭은 예약어 begin과 end 쌍으로 묶인 복합문으로 구성되는데, 단순히 프

로젝트의 Application 객체의 메소드 호출입니다. 모든 프로젝트는 TApplication,

TWebApplication 혹은 TServiceApplication의 인스턴스를 가지는 Application 변수를

가지고 있습니다. 블럭은 상수, 타입, 변수, 프로시저 및 함수의 선언도 포함할 수 있습니다.

이러한 선언은 반드시 블럭의 문장 부분보다 앞에 있어야 합니다.

-----------------------------------------------------------------------------------------------------

유닛은 타입(클래스 포함), 상수, 변수 및 루틴(함수와 프로시저)으로 구성됩니다. 각 유닛

은 자체 유닛(.pas) 파일에서 정의합니다.

유닛 파일은 unit 헤더로 시작되고, 뒤이어 interface 예약어가 나옵니다. interface 예약어

에 이어 uses 절에서 유닛 의존성을 기술합니다. 다음으로 implementation 섹션이 오고,

선택적으로 initialization 및 finalization 섹션이 올 수 있습니다. 유닛 파일 구조는 다음과

같습니다.

 

유닛은 반드시 end와 마침표(.)로 끝나야 합니다.

unit 헤더

unit 헤더는 유닛의 이름을 지정합니다. 유닛 헤더는 예약어 unit, 유효한 식별자, 세미콜론 순

으로 구성됩니다. 코드기어 툴을 사용하여 개발된 애플리케이션의 경우 식별자는 반드시 유닛

파일 이름과 일치해야 합니다. 따라서 MainForm.pas이라는 이름의 소스 파일의 유닛 헤더는,

 

와 같을 것이며, 컴파일된 유닛 파일의 이름은 MainForm.dcu가 됩니다.

유닛 이름은 반드시 프로젝트 내에서 유일해야 합니다. 유닛 파일이 다른 디렉토리에 있더

라도 같은 이름을 가진 두 개의 유닛을 한 프로그램에서 사용할 수 없습니다.

interface 섹션

유닛의 interface 섹션은 interface 예약어로 시작해서 implementation 섹션이 시작될 때

까지입니다. 인터페이스 섹션에는 다른 유닛이나 프로그램에서 사용 가능한 상수, 타입, 변

수, 프로시저 및 함수를 선언합니다. 다른 유닛의 코드가 마치 자신의 유닛 안에서 선언된

것처럼 호출할 수 있기 때문에 이런 항목들을 public이라고 합니다.

프로시저나 함수의 인터페이스 선언은 루틴의 시그니처(signature), 즉 해당 루틴의 이름,

파라미터들, 그리고 리턴 타입(함수의 경우)만을 포함합니다. 프로시저나 함수의 실행 코드

블럭은 임플먼테이션 섹션에 위치합니다. 그러므로 인터페이스 섹션의 프로시저와 함수 선

언은 forward 선언과 비슷하다고 할 수 있습니다.

클래스의 인터페이스 선언은 필드, 속성, 프로시저, 함수 등 모든 클래스 멤버의 선언을 포

함해야 합니다.

인터페이스 섹션은 자체의 uses 절을 포함할 수 있으며, 반드시 예약어 interface 바로 뒤에 나

타나야 합니다. uses 절에 대한 자세한 내용은 2장의“유닛 참조와 uses 절”을 참조하십시오.

implementation 섹션

유닛의 implementation 섹션은 예약어 implementation로 시작하여 initialization 섹션이

시작할 때까지, initialization 섹션이 없는 경우에는 유닛의 끝까지입니다. 임플먼테이션 섹

션은 인터페이스 섹션에 선언된 프로시저와 함수를 정의합니다. 임플먼테이션 섹션 내에서

이러한 프로시저와 함수는 순서에 상관없이 정의하고 호출할 수 있습니다. 임플먼테이션 섹

션에 public 프로시저와 함수 헤더를 정의할 때 파라미터 리스트를 생략할 수도 있지만, 파

라미터 리스트를 포함할 경우에는 인터페이스 섹션의 선언과 반드시 일치해야 합니다.

임플먼테이션 섹션은 public 프로시저 및 함수들의 정의 외에도, 해당 유닛 내에서만 사용

가능한(private) 상수, 타입(클래스 포함), 변수, 프로시저 및 함수를 선언할 수 있습니다.

다시 말해, 인터페이스 섹션과 달리 임플먼테이션 섹션에서 선언된 항목들은 다른 유닛들에

서는 접근할 수 없다는 것입니다.

임플먼테이션 섹션은 자체의 uses 절을 포함할 수 있는데, 반드시 implementation 바로 뒤

에 나타나야 합니다. 임플먼테이션 섹션에서 지정된 유닛들의 식별자들은 임플먼테이션 섹

션에서만 사용 가능하며 인터페이스 섹션에서는 참조할 수 없습니다.
uses 절에 대한 자세한 내용은 2장의“유닛 참조와 uses 절”을 참조하십시오.

initialization 섹션

initialization 섹션은 선택적으로 사용됩니다. 이니셜라이제이션 섹션은 initialization 예

약어로 시작하여 finalization 섹션이 시작될 때까지, finalization 섹션이 없는 경우에는 유

닛의 끝까지 계속됩니다. 이니셜라이제이션 섹션에는 프로그램이 시작될 때 실행될 문장들

을 포함하며, 나타나는 순서대로 실행됩니다. 그러므로 예를 들면 초기화해야 할 데이터 구

조를 정의했을 경우, 이니셜라이제이션 섹션에서 초기화를 할 수 있습니다.

인터페이스 uses 리스트의 유닛들의 경우, 외부로부터 uses된 유닛들의 이니셜라이제이션

섹션들은 uses 절에 나타난 순서대로 실행됩니다.

finalization 섹션

finalization 섹션은 선택적이며 initialization 섹션이 있는 유닛에서만 사용할 수 있습니

다. 파이널라이제이션 섹션은 finalization 예약어로 시작하여 유닛의 끝까지 계속됩니다.

파이널라이제이션 섹션에는 메인 프로그램이 종료될 때 실행될 문장이 들어 있습니다(프로

그램 종료를 위해 Halt 프로시저를 호출한 경우는 예외). 파이널라이제이션 섹션을 사용하

면 이니셜라이제이션 섹션에 할당했던 리소스를 해제할 수 있습니다.

파이널라이제이션 섹션은 이니셜라이제이션 섹션과 반대로 실행됩니다. 예를 들어 애플리

케이션에서 유닛을 A, B, C 순으로 초기화했다면 C, B, A 순으로 유닛을 해제합니다.

일단 어떤 유닛의 이니셜라이제이션 코드가 실행되기 시작하면, 애플리케이션 종료 시에는

해당 유닛의 파이널라이제이션 섹션의 실행이 보장됩니다. 런타임 에러가 발생하면 이니셜

라이제이션 코드가 완전히 실행되지 않을 수도 있기 때문에, 파이널라이제이션 섹션은 불완

전하게 초기화된 데이터도 처리할 수 있어야 합니다.