C와 객체지향 – 01 – 시작

C언어에 대한 글을 쓰고 있다. 리눅스 환경에서 동작하는 C언어를 쓰면서 C언어의 기본적인 내용을 작성하였고, 리눅스 환경에서 C언어를 개발하는데 이용하는 라이브러리들, 그리고 gcc와 make에 관한 글을 작성하고 있습니다.

그런데 문득 작업 진행이 제대로 이루어지고 있지 않는다는 것을 깨달았다. 이젠 리눅스 환경에서의 사용이 중점이기 때문에 그쪽 자룔 정리해서 올리는 작업이다 보니 언어에 관한 작업이 더뎌지고 해서 그런지 작업 속도가 늘지 않았다. 졸업논문 쓰고 난 후의 피로감도 있고…

그래서 이와는 별개로, C에 대한 내용을 작성하였으니 이젠 C 자체만에 추가적인 내용을 적어보고자 합니다. 그게 바로 고급지게 쓰는 C입니다.

그 중에 첫번째로 바로 C와 객체지향에 대해서 작성해 보려고 합니다.

C는 절차지향적 언어라고 기본적으로 배우죠. 따라서 프로그램의 흐름이 중요하고, 그에 맞도록 함수를 잘 써서 분할하고 하는 작업에 대해서 중요하게 여깁니다. 그러다 보니 아무리 몇만 라인의 코드를 작성하더라도 코드 자체가 상당히 평평한 구조를 가지게 됩니다. 함수 하나만 해도 몇백 라인이 되기 일쑤고, 비슷한 기능 하는 함수들 미친듯이 만들고, 그런 함수들이 뒤에 숫자 2,3,4 이런 식으로 막 붙은 그런 함수들… 양산하기 무지 쉽습니다. (이 글을 읽어야 할 수준이라면 내 이야기 아니라고 생각하는 분 없을겁니다.)

내부 처리 로직 중에서는 공통으로 처리할 수 있는 부분은 공통으로 처리할 수 있지만, 동작 제어 함수들은 좀 사정이 다릅니다. 다양한 인자가 필요한 함수, 사용하는 데이터가 전역 변수로 연결, 독립성 결여된 함수들, 서로 의존관계가 너무 깊어 개별적인 테스트 할 수 없는 함수들….

사실 C에서는 특정 내용을 처리하기 위해 함수라는 것이 존재하고 이를 이용해 프로그램을 구조화할 수 있어야 한다고 가르치는데 왜 이런 현상이 발생할까요?

바로 디자인 패턴의 부재 때문입니다. 소프트웨어 개발에서 말하는 디자인 패턴은, 프로그램 개발에서 자주 나타나는 과제를 해결하기 위한 방법 중 하나로, 과거의 소프트웨어 개발 과정에서 발견된 설계의 노하우를 축적하여 이름을 붙이고, 이를 재사용하기 좋은 형태로 특정 규약을 묶어서 정리한 내용을 말합니다. 문제 해결을 위해 해결 방법을 제시하고, 이를 사용 가능한 구조로 묶고 코드로 만들 수 있는 단계를 알고리즘이라고도 하기 때문에 알고리즘을 가르치는 것인가를 생각하기 쉽지만 디자인 패턴에서는 구조적으로 이미 정의된 문제를 해결하는 방식을 알려줍니다. 이미 정형화된 패턴을 문제에 적용하는 점이 아무것도 없는 상태에서 하나 하나 설계하는 중에 최적화 작업을 하는 알고리즘과는 접근 방법이 조금 다르죠.

그리고 이런 디자인 패턴의 많은 부분이 객체 지향 언어에서 사용하는 것을 전제로 하기 때문에 C랑은 상당히 무관하다는 듯이 배우고, 가르치는 분들 또한 그렇게 가르칩니다. 컴퓨터공학 전공한 분들을 아시겠지만, 객체 지향 프로그래밍 과목을 수강한 후에 디자인 패턴에 대한 강의를 들을 수 있다는 것을 알 수 있습니다.

그러나, C에서도 객체지향을 실현할 수 있습니다. 객체 지향을 잘 활용하면 프로그램의 구조가 기존의 C 프로그램들과는 달리 크게 변하게 됩니다. 또한 각 함수들이 독립적으로 작동하게끔 만들 수 있습니다. 이를 위해서는 C로 객체 지향을 염두해 두고 설계하고 프로그래밍할 수 있어야 합니다. 특히, 현대의 임베디드 시스템들과 C 프로그래밍에서는 이런 사고가 상당히 많이 적용되어 있기 때문에 C를 할 수 있다고 하려면 이런 수준까지 할 수 있어야 합니다.

그래서, C로 객체 지향과 같은 설계와 프로그래밍을 할 수 있는 방법을 포스팅하려 합니다.

p.s. 기존의 리눅스 환경에서의 C 프로그래밍과 별도로 활동합니다.

Advertisements

117 – make 규칙 1: 암시적 규칙

make 파일을 작성할 때는 컴파일에 필요한 각 처리 단계와 의존성을 분명히 지정해주었다. 이와 같이 make가 해야 할 일을 분명히 지정하는 것을 명시적 규칙(explicit rules)이라고 한다. 이와 반대로, make 내에 미리 정의된 규칙을 이용해 make 파일을 단순화시키는 규칙을 암시적 규칙(inference rules)이라고 한다.

이를 보여주기 위해서 전에 작성하던 make 파일을 상당히 줄여서 예시로 보여주겠다.

20180116_234757.png

소스 파일에서 오브젝트 파일로 컴파일하도록 하는 단계를 빼고 그냥 바로 test를 오브젝트로 만들어서 빌드하도록 하였다. 전에 글들의 코드를 보고 비교하면 상당히 단축시킨 것을 볼 수 있다. 이 코드는 실행하면 그대로 컴파일 된다. 그 결과가 아래의 화면이다.

20180116_234811.png

대상이 되는 test를 생성하기 위해 make는 의존하는 파일들을 살필 것이다. 그러나 대상이 의존하는 test1.o test2.o test3.o 이 세 파일이 존재하지 않기 때문에 make는 다시 저 파일들의 대상으로 있는 곳을 찾으려 한다. 이때, 찾지 못할 경우에는 오류를 내고 중단할 것 같지만, 실제로는 암시적 규칙에 따라 오브젝트 파일을 gcc가 생성할 수 있는 것을 알기 때문에, test1.o test2.o test3.o 파일을 생상하기 위해 의존하는 파일을 스스로 찾고 컴파일러 호출까지 알아서 수행한다. 이때, 실행 결과에 찍힌 규칙을 보면 알겠지만 gcc를 호출하는 것이 아니라 cc 컴파일러를 호출하였다.

이 과정을 보고 싶다면 make -p 라고 해서 -p 옵션을 통해서 볼 수 있다. 실행하면 아래와 같이 쭉 나온다. 아래 화면에 스크롤 바를 주목해라. 내용 장난 아니게 많다. 암시적 규칙으로 어떤 것들이 불러지는지 알고 싶다면 계속 스크롤을 내려서 살펴보는 것도 좋을 것이다. 근데 당장은 이해 못한다.

20180116_234940

20180116_234956.png

20180116_235008

116 – make 매크로 수정

이미 정의된 매크로 부분을 다음과 같이 바꿔봤다.

20180108_175146

OB 매크로에 test3를 추가하는 형태로 OBJF를 바꾼 것이다. 그러면 일전에 모든 것을 다 선언했던 매크로와 동일한 효과가 있다.

그렇다면 이제 프로그래밍 좀 해본 분들은 한 번 정도는 생각해 볼 만한 것이 바로 변수에 변수 뒤엎어 쓰듯이 매크로도 그런 식으로 쓸 수 있지 않을까 하는 생각을 할 것이다. 예를 들어 이렇게 말이다.

20180108_175537.png

확대해서 보일 수 있도록 캡쳐를 하였다. 위의 화면과 같이 하면 되겠지? 라는 생각들 할 수도 있다. 결론부터 말하면 안된다. 아래처럼 된다.

20180108_175639

매크로가 정의되는 방식에는 두 가지 방식이 존재한다. 재귀 확장형 매크로와 단순 확장형 매크로가 존재하는데, 우리가 지금 이용하는 make의 경우에는 재귀 확장형 매크로이다. 따라서 이미 선언한 OBJF에 대해서 불러오는 부분에서 이용한 $(OBJF) 부분에서 재귀 콜이 불러져서 다시 참조하는 형태, 즉 다른 매크로를 포함하면 같이 확장을 하는 형태로 만들어졌기 때문에 오류를 낸 것이다. 똑똑한 매크로 실행기가 먼저 알아서 멈춰진 것이다.

그럼 이걸 단순 확장으로 만들 수 없는 걸까? 당연히 있다. 단순 확장 매크로는 말 그대로 단순히 확장만 되는 형태로 만들어지고, 매크로의 정의 차이에 따라서 이걸 판단하게 된다. 우선 단순확장에 대해서만 살펴보려고 하는데, 단순 확장의 경우에는 :=를 통해 확장하면 된다. 아래처럼 해주면 된다.

20180108_180207

간단하다. 설명만 힘들 뿐이다. (ㅠㅠ) 이를 실행해보면 오류 없이 진행될 수 있는 것을 볼 수 있다.

20180108_180225.png

그렇다면 기존에 있는 내용에 대해서 치환할 수 있는 매크로도 존재한다. 기본식이 다음과 같다.

$(M_NAME:old=new)

old가 기존에 있던 부분이고, new가 치환하려는 부분이다. 이건 예시 코드를 만들어서 보여주겠다. OBJF에 있는 .o 확장자를 .c 확장자로 변경해 보겠다.

20180108_181120

위의 화면과 같이 SRCS라고 하는 소스코드 파일들을 매크로 선언으로 하였다. 그 다음에 이걸 확인하기 위해서 명령어를 하나 추가해서 보여주려고 한다. 아마 오류가 날 코드이다.

20180108_181144.png

실제 실행한 화면이다. 예상대로 오류가 났다. (이거에 대해서는 나중에 글을 추가하겠다.) 그러나, 실행하려는 구문에 보면 뒤에 확장자가 .c로 바뀐 것을 볼 수 있다.