현대 컴퓨터의 언어의 성향과 C++

목차

-강력한 자료형의 구현(Strong data typing)

-엄격한 자료형의 검토(Strong type checking)

-메모리의 참조(Refence)기능

-자료형의 추상화(Data abstraction)

-자료형의 캡슐화(Data encapsulation)

-접근의 제한(Access Restricition)

-정보은폐(Infomation hiding)

-자동초기화 및 소멸(Automatic Initialization and Cleanup)

- 상속성(Inheritance)

-동적 결합(Dynamic Binding)

-가변적인 형의 형태(Parametic type)

-예의처리(Exception handing)

본문내용

는 gotoxy 함수가 어떤 주소에 있는지 알고 있으며 그래서 gotoxy 호출문을 이 함수의 주소로 점프하는 코드로 번역할 것이다. 컴파일하는 시점(정확하게는 링크 시점)에 이미 어디로 갈 것인가가 결정되는 이런 결합 방법을 정적 결합(Static Binding) 또는 이른 결합(Early Binding)이라고 한다. 결합(Binding)이란 함수 호출문에 대해 실제 호출될 함수의 번지를 결정하는 것을 말하는데 지금까지 작성하고 사용했던 일반적인 함수들은 모두 정적 결합에 의해 번역된다.
그런데 가상 함수는 포인터가 가리키는 객체의 타입에 따라 호출될 실제 함수가 달라지므로 컴파일시에 호출할 주소가 결정되는 정적 결합으로는 정확하게 호출할 수 없다. 왜냐하면 포인터가 실행중에 어떤 타입의 객체를 가리킬지 컴파일 중에는 알 수 없기 때문이다. 대입은 실행중에 회수에 상관없이 얼마든지 할 수 있는 연산이고 포인터는 타입만 일치하면 얼마든지 다른 대상을 가리킬 수 있다. 컴파일러는 앞 예제의 Message 함수의 본체를 특정 번지로의 점프문으로 번역할 수 없으며 조건에 따라 호출할 함수를 결정하는 문장으로 번역해야 한다.
void Message(Base *pB)
{
if pB가 Base 객체를 가리키면 Base::OutMessage 호출
if pB가 Derived 객체를 가리키면 Derived::OutMessage 호출
}
실행중에 호출할 함수를 결정하는 이런 결합 방법을 동적 결합(Dynamic Binding) 또는 늦은 결합(Late Binding)이라고 한다. pB->OutMessage 호출문을 미리 고정된 번지로의 점프문으로 번역하는 것이 아니라 pB가 가리키는 객체의 타입에 따라 적절한 함수를 선택해서 점프하는 코드로 번역해야 하는 것이다. 이렇게 해야 전달된 객체에 따라 각기 다른 동작을 할 수 있는 다형성을 구현할 수 있다.
동적 결합은 멤버 함수를 포인터(또는 레퍼런스)로 호출할 때만 동작한다. 객체로부터 함수를 호출할 때는 설사 그 함수가 가상 함수라 할 지라도 컴파일 시에 호출할 함수를 정확하게 결정할 수 있다. 왜냐하면 객체는 자신이 소속된 클래스 타입일 뿐이지 다른 타입이 될 수 없기 때문이다. 포인터는 부모 타입의 포인터가 자식을 가리킬 수 있기 때문에 정확한 함수를 호출하기 위해 동적 결합을 해야 하지만 객체로 직접 호출할 때는 호출 객체의 타입을 분명히 알 수 있으므로 그럴 필요가 없다. 다음 코드는 어떤 함수를 호출할지 분명히 알 수 있다.
B.OutMessage();
D.OutMessage();
만약 누군가가 여러분에게 가상 함수란 무엇인가라는 질문을 한다면 어떻게 대답할 수 있겠는가? 이 질문에 대한 가장 짧고도 정확한 대답은 "동적 결합을 하는 함수"일 것이다. 사실 가상 함수를 칭하는 vitrual이라는 키워드는 상당히 잘못 선택되었으며 이 말을 한국어로 번역한 결과인 "가상"이라는 말도 마찬가지이다. 가상이라는 말은 "~이 아니다"라는 뜻이므로 이 말을 처음 들었을 때 누구나 함수가 아닌 것처럼 오해할 소지가 있으며 독자의 직관력을 전혀 쓸모없게 만들어 버린다. virtual이라는 용어에 뜻이 분명히 표현되지 않으므로써 안그래도 어려운 개념을 더 어렵게 만든다. "가상"이라는 단어에서 의미를 찾으려고 하면 헷갈리기만 할 뿐이다.
차라리 애초부터 "동적 결합 함수"라고 칭하고 runbinding이나 dynamic 또는 overridable같은 키워드를 사용했더라면 훨씬 이해하기 쉬웠을 것이다. 이 함수에 virtual이라는 용어를 쓴 이유는 전통적인 함수처럼 정적 결합을 하지 않으며 파생 클래스가 재정의해도 안전하다는 뜻이다. virtual이라는 용어의 또 다른 잘못된 사용예는 가상 기반 클래스를 지정할 때 사용되는 virtual 키워드이다. 이때 사용된 virtual과 가상 함수로 지정할 때 사용되는 virtual은 아무런 연관이 없고 비슷도 아니하다. 그래서 더 혼란스럽다. 이 문제는 여러 번 지적되었지만 표준 위원회는 새로운 키워드 도입에 대해 사용자의 명칭 선택권을 제한할 수도 있다는 이유로 부정적인 입장이다. C언어에도 이런 예가 있는데 정적변수와 외부 정적변수를 선언할 때 사용하는 키워드 static도 사실은 키워드를 중복해서 사용하는 것이다.
-가변적인 형의 형태(Parametic type)
-예의처리(Exception handing)
프로그램이 비정상적인 동작을 하는 데는 두 가지 원인이 있습니다. 첫째는 개발자가 실수로 코드를 잘못 작성해서 프로그램이 오동작을 하는 경우입니다. 이런 것을 버그라고 한다. 둘째는 외적인 요인이 프로그램의 정상 동작을 방해하는 경우이다. 이런 것을 예외라고 한다.
예를 들어, 데이터를 파일에 쓰려고 하는데 하드디스크가 가득 차서 쓸 수 없는 경우, 프론트를 하려고 하는데 프린터에 종이가 떨어진 경우, 통신을 하려고 하는데 네트워크 케이블이 빠진 경우, 사용자가 숫자를 입력해야 하는 곳에 문자를 입력한 경우 등 수많은 종류의 예외가 있을 수 있다.
예외는 개발자의 실수라기 보다는 외적인 요인에 의해 발생하는 것이지만, 이럴 때 적절한 처리를 해서 프로그램이 오동작을 하지 않도록 하는 것은 개발자의 책임입니다. 개발자 입장에서는 야박하다고 생각되겠지만, 예외 처리를 잘못해서 프로그램이 오동작하는 것도 버그로 간주된다.
예외는 발생 빈도는 낮지만, 경우의 수는 매우 다양하다는 것이 특징이다. 따라서 발생 하능한 모든 예외에 대해 완벽한 대비를 하는 것은 매우 어려운 일이다. 완벽한 예외처리를 하는 프로그램을 만드는데 드는 노력은 예외처리에 전혀 신경 쓰지 않고 기능만 구현하는데 드는 노력의 세배 정도 된다고 할 정도다.
취미 삼아 만드는 프로그램이라면 예외처리에 크게 신경 쓰지 않아도 무방하다. 특히 내가 만든 프로그램을 나 혼자 쓰는 경우에는 예외처리를 하는 것보다 예외 상황이 발생하지 않도록 조심해서 쓰는 편이 훨씬 쉬울 수 있습니다. 하지만 상용 프로그램을 만들 때는 철저한 예외 처리를 해야 합니다. 아무리 사소한 예외라도 간과했다가는 이로 인한 불만이 고객 센터에 쌓이게 될 것입니다.

키워드

현대 컴퓨터,   언어,   성향,   C++