김 용묵의 절대공간 - 블로그

템플릿 얘기가 좀 길어졌는데.. 다음 주제는 가상 함수와 관련된 엉뚱한 생각이다.
C++이라는 언어는 앞서 잠깐 언급했던 바와 같이, '오버로딩과 오버라이딩' 사이에 뭔가 견제를 하는 게 있다.
그것과 비슷하달까, C++은 오버라이딩과 멤버 함수 포인터 사이에도 디자인 차원에서 선을 긋는 게 있어 보인다.

무슨 말이냐 하면.. 가상 함수가 존재하는 어떤 객체가 주어졌을 때, 이 객체가 참조하는 vtable 값을 직접 확인하는 것을 언어 차원에서 전혀 허용하거나 지원· 고려하지 않는다.
이 객체의 어떤 가상함수는 부모 클래스의 것과 같은지, 아니면 오버라이딩 됐는지.. 이런 것을 알 수 없다.

&obj->Foo == &TBase::Foo 이런 식으로 비교하는 거?? 가상과 비가상 불문하고 다 안 된다. 클래스의 non-static 멤버 함수의 주소를 얻는 건 컴파일 타임 바인딩이 가능한 &클래스::멤버 형태만 허용될 뿐, 런타임 바인딩인 &변수->멤버는 안 된다. 그냥 컴파일 에러로 처리된다.

멤버 함수 포인터를 이용해서 pFunc에다가 특정 클래스의 Foo를 집어넣었더라도.. (obj->*pFunc)()를 호출해 보면 obj->Foo()를 호출한 것과 동일하게 접수된다.
멤버 함수 포인터에는 자신의 vtable을 참조해서 그걸 호출해 주는 thunk 함수만 연결되기 때문이다. 그 아래의 vtable 상의 주소로 다이렉트 접근이나 제어는 안 된다! 신기하지 않은가?
(하긴, 다중 상속 체계에서는 this 오프셋 보정도 이런 thunk가 하는 일 중 하나이겠지만)

C++ 클래스에서 vtable이란 걸 바이너리 차원에서 꼭 이렇게 구현해야 한다고 C++ 표준에 규정돼 있지는 않다.
그러나 실제로 구현되는 방식은 컴파일러 불문하고 거의 뻔할 뻔자이다. 그렇기 때문에 다음과 같은 동작을 억지로 구현해 줄 수 있다.

class Base {
public:
  int x;
  virtual void VF1() {}
  virtual void VF2() {}

  void* GetFuncPtr(int n) { //0: VF1, 1: VF2
    void*** pppf = (void***)this;
    return (*pppf)[n];
  }
};

무려 삼중 포인터가 쓰인 GetFuncPtr이라는 저 함수를 주목하시라. void에 대한 포인터(1)의 배열(2)을 가리키는 포인터(3)이기 때문에 삼중이 된 것이다.
가상 함수가 들어있는 클래스는 맨 첫 멤버가 vtable 포인터이기 때문에 this에 대해 저런 형변환이 가능하다.

그 다음으로, Base에 대해 1번 함수를 오버라이드한 Derived1, 2번 함수를 오버라이드한 Derived2, 그리고 둘 다 오버라이드한 Derived3. 이 세 클래스를 다음과 같이 선언해 보자.

class Derived1 : public Base {
public:
  int y;
  virtual void VF1() {}
};

class Derived2 : public Base {
public:
  int z;
  virtual void VF2() {}
};

class Derived3 : public Base {
public:
  int w;
  virtual void VF1() {}
  virtual void VF2() {}
};

요렇게 한 뒤, Base, Derived1, Derived2, Derived3 아무 객체나 선언해서 GetFuncPtr(0)을 호출해 보면 Base와 Derived2는 같은 값을 되돌린다. Derived2는 VF1을 오버라이드 하지 않았기 때문이다.
GetFuncPtr(1)을 호출해 보면 Derived1이 Base의 것과 같은 값을 되돌린다. 이유는 동일.

그렇다고 이 주소값은 &Base::VF1, &Derived2::VF2 처럼 실존하는 멤버 함수의 주소를 C++ 연산자를 통해서 얻은 주소값과 일치하지 않는다. 이거는 멤버 함수 포인터에다가 대입해서 호출을 할 수 있지 않다.
애초에 멤버 함수 포인터는 일반 함수 포인터와 달리 임의의 정수형으로부터 대입하는 게 아예 불가능하지 싶다. reinterpret_cast나 C-style cast도 되지 않는다.
그러니 저 값은 그냥 클래스 간에 값이 같은지 다른지 비교 용도로만 써먹을 수 있을 뿐이다.

그리고 사실은 언제나 저렇게 가상 함수 2개짜리 vtable이 생긴다는 보장도 없다.
클래스를 만들어서 멤버 함수를 virtual로 선언했지만 실제 코드에서 이 클래스의 인스턴스를 한 번도 포인터로 접근하지 않아서 런타임(다이나믹) 바인딩이 필요하지가 않다면..
컴파일러가 최적화 스킬을 발휘해서 vtable을 곧이곧대로 만들지 않을 수도 있다. 그러면 우리가 저렇게 만든 GetFuncPtr 함수도 제대로 맞게 동작하지 않을 것이다.

일반적인 함수라면.. 형태가 너무 단순해서 컴파일러가 평소에는 인라이닝이나 인트린식으로 실컷 최적화한다고 하더라도 그 함수의 주소가 필요할 때는 일반적인 함수 포인터 값이 반드시 제공돼야 한다. 최적화는 부가 기능일 뿐이지만, 함수 포인터는 언어 스펙에서 제공되는 필수 기능이기 때문이다.
그러나 vtable에 명시된 함수 주소는 그렇게 공식적으로 제공되는 기능이 아니다. 프로그래머가 언제까지나 꼼수로.. at your own risk를 염두에 두고 써야 한다.

이상이다.
글을 맺으면서 문득 드는 생각인데.. C++의 RTTI (런타임 type info)가 내부적으로 구현되는 방식도 가상 함수가 구현되는 방식과 아주 밀접한 관계가 있으며, 서로 떼어서 생각할 수 없어 보인다.

vtable이라는 게 결국은 한 클래스와 무조건 일대일 대응하는 고유한 정보이니, 참조하는 vtable이 동일한 객체는 동일한 클래스의 인스턴스임이 보장되기 때문이다.
그러니 자기 클래스의 이름이라든가, 부모 클래스 목록 같은 RTTI도 vtable과 함께 두거나 최소한 RTTI를 가리키는 포인터를 vtable에다가 둘 법도 해 보인다. dynamic_cast 연산자는 그런 정보를 참조하면서 동작하면 될 테고.

아 그런데.. 이런 깔끔한 관계는 단일 상속 체계에서나 보장되겠다;;
다중 상속이라면 2개째 이후의 기반(부모) 클래스에 대해서 매번 vtable 포인터가 또 추가될 테니 일이 정말 복잡해지겠다.
단일 상속에서는 복잡도가 뭔가 1씩 더해지는 것만 생각하면 됐는데, 다중 상속에서는 2씩 곱해지는 수준으로 복잡도가 폭발적으로 증가한다.;;

그러니 C++ 표준화 이전부터 RTTI를 자체 구현했던 C++ 프레임워크들은(가령, MFC 같은 골동품) 그런 건 깔끔하게 포기하고 단일 상속만 염두에 두고 저런 기능들을 구현했지 싶다.

말이 길어져 버렸는데.. 암튼 이 글의 결론은
"이 ptr은 Base의 파생 클래스이긴 한데요, 특정 무슨 함수가 오버라이드 돼서 Base의 원래 것과는 달라졌는지 아닌지만 좀 알 수 있을까요?"
요건 언어 차원에서 알려주지 않는다는 것이다. 그런 건 query하는 함수를 사용자가 수동으로 구현해 줘야 한다.

Posted by 사무엘

객체지향 언어라면 파생 클래스 코드에서 기반 클래스의 멤버에 접근하는 것이야 너무 당연히 가능하다. 상속을 protected나 public으로 받기만 했다면 말이다.
기반 클래스의 scope에서 선언된 내부 클래스라 하더라도 마음껏 인스턴스를 만들고 참조할 수 있다.

class Base {
protected:
  int x;
  class InnerClass {
  public:
    int z;
  };
};

class Derived: public Base {
public:
  void Foo() {
    x = 100; //base 꺼
    InnerClass o; o.z = 100; //base 꺼
  }
};

그런데 이게 평범한 클래스가 아니라 ‘템플릿 클래스’라면 상황이 어찌 될까?

template<typename T>
class TBase {
protected:
  int x;
  class InnerClass {
  public:
    int z;
  };
};

template<typename T>
class TDerived : public TBase<T> {
public:
  void Foo() {
    x = 100;
    InnerClass o; o.z = 100;
  }
};

한동안은 이 코드는 잘 통용됐다. 문법적으로 아무 하자가 없어 보이지 않는가? 내가 아는 한 Visual C++ 2010 컴파일러 정도까지는 이상이 없었다.
그런데 2010년대에 C++ 표준이 바뀌었는지.. 저건 후대의 버전부터는 컴파일되지 않고 오류를 일으키기 시작했다.
2019/2022에서 말이다. 그 사이에(2012, 13, 15, 17??) 정확히 언제부터 변화가 생겼는지는 잘 모르겠다.

TDerived에서 기반 클래스 멤버인 x에 접근하는 것 자체가 언어 차원에서 봉쇄되고 금지된 건 아니다. 단지, 템플릿 클래스에서 코드의 의미 명료화를 위해 좀 깐깐한 조치가 취해진 것 같다.

TDerived에서 x에다 접근하려면
this->x 라고 일일이 쓰든가, 아니면 TBase<T>::x라고 타입을 명시해 줘야 한다. 그 x를 지칭하기 위해서 어쨌든 x 단독으로 방치만 하지 않으면 된다.

CInternalClass도 주변에다 좀 decoration을 해 줘야 한다. 얘는 멤버 변수나 함수가 아니라 타입이다 보니.. typename 내지 using 처방을 해 주면 된다.
참조할 때 매번 typename TBase<T>::InnerClass 이러던가..
아니면 TDerived의 선언부에다가 using InnerClass = TBase<T>::InnerClass 이렇게 박아 주고 나서 다음부터 InnerClass만 쓰면 된다.

흐음~~
내가 기억하기로 C++에서 템플릿이라는 건 처음 도입됐던 시절엔 거의 C++판 매크로나 마찬가지였다.
템플릿 인자가 무엇이 들어오느냐에 따라 코드의 의미가 귀에 걸면 귀걸이, 코에 걸면 코걸이(특히 값이냐 타입이냐)처럼 완전히 달라질 수 있었기 때문이다.

T가 int냐, double이냐, 1000바이트 짜리 뚱뚱한 클래스냐~ 이거는 컴파일러 입장에서 단순히 코드 생성이나 최적화 전략만을 좌우할 것이다.
그러나 T::member 이런 거는..? T에 어떤 클래스가 오느냐에 따라서 member는 멤버 변수? 멤버 함수? 심지어 내부의 다른 클래스/enum 이름이 될 수도 있다. 멤버라 하더라도 static 멤버가 될 수 있고, non-static이 될 수도 있다!

이러니 템플릿 코드는 그거 단독으로 문법 체크를 하는 게 매우 난감했다.
템플릿에다가는 그 어떤 아무말을 씨부려 놔도 그 자체는 컴파일러가 전혀 개의치 않고 넘어갔다. #define MACRO(x) 그 다음에 그 어떤 아무말을 씨부리건 이것만으로는 컴파일 에러가 발생하지 않는 것과 같은 이치이다. 에러는 이 매크로를 사용하는 곳에서 발생할 뿐..

템플릿도 TBase<int>건 TBase<POINT> 처럼 그 템플릿에다가 인자를 줘서 실제로 사용할 때에야 파싱과 코드 생성이 시작됐다. 그때에야 에러가 발생했다.

그랬는데.. 요즘 C++ 언어의 디자인 추세는 템플릿이 너무 무질서하고 자유도가 너무 높은 것을 통제하려는 것 같다.
특히 템플릿만을 단독으로도 최대한 분석한다. 템플릿 인자로 그 무엇을 넣더라도 그와 무관하게 무조건 구문 실패와 에러가 발생할 만한 것은 굳이 템플릿을 실제로 사용하지 않더라도 지적해 준다.

일례로, 위의 코드에서 TDerived::Foo() 안에다가 x=100이 아니라 y=100을 넣으면 바로 에러가 난다.
이렇게 하려다 보니 T::member라는 토큰은 템플릿 인자 T에 무엇이 들어오건 최소한 멤버인지 타입명인지 정도는 고정적으로 의미 보장이 돼야겠다. 그래서 typename T::member 같은 조치가 취해졌다.

그리고 T에 무엇이 들어오건 주변 문맥을 고정시켜야겠으니 implicit하게 부모 클래스 멤버에 접근 가능하던 혜택(?)도 없어진 것이다.
그 혜택을 다시 입고 싶으면 using을 활용해서 직접 요청을 해야 된다. using은 typedef의 상위 호환 대체제이기도 하니..

왜, 같은 이름의 함수로 오버로딩과 오버라이딩을 동시에 시도했을 때도(예: virtual void foo()와  void foo(int)를 동시 시도) 파생 클래스에서는 오버라이딩 되지 않은 부모 클래스 멤버로 자동 접근하는 건 "막힌다". 그런 것과 비슷한 느낌이 든다.
막힌 멤버로 접근하려면 역시 부모 클래스 이름을 일일이 써 주거나, using Base::foo 라고 자동 접근 요청을 해야 된다. 이 조치도.. 나중에 일부러 취해진 것이다.

C++ 템플릿은 임의의 타입들을 다 boxing해서 단일 바이너리(컴파일된 코드)만으로 모든 템플릿 인자를 담당하는 '제네릭' 같은 물건이 아니다. 하지만 그렇다고 정말 귀걸이 코걸이가 다 되는 C++판 매크로도 아니니.. 그 중간의 다른 무언가를 지향하는 것 같다.

자, 본인이 이 글을 쓰게 된 계기는..
이 홈페이지의 옛날 자료실에 있는 "정렬 알고리즘 모음집" C++ 코드가 최신 컴파일러에서는 컴파일되지 않는다는 걸 뒤늦게 발견했기 때문이다.
템플릿 클래스 사이에 상속을 구현했는데.. 이제는 코드를 한참 뜯어고쳐야 컴파일 될 것 같다. ㄲㄲㄲㄲㄲ
이 참에 옛날 자료실을 다 github로 옮기는 것도 생각해 봐야겠다.

Posted by 사무엘

※ C 언어는..

- 1972년에 '데니스 리치'라는 사람이 유닉스 운영체제를 개발하던 과정에서 고안했다. 지난 2011년에 스티브 잡스와 거의 1주일 간격으로 나란히 부고 소식이 전해졌던 그 사람 말이다.
- B라는 프로토타입을 거친 뒤, B 다음으로 C라는 이름이 붙었다. 참고로 B의 이전에는 알골(Algol)이라는 조상뻘 언어가 있었다.
- let it be 노래를 패러디한 write in C라는 개드립이 유행했었다.

- 초창기에는 const 지정자라는 게 없었다나 어쨌다나.. func(a) int a; 이런 기괴한 문법도 통용됐다.
- 그러다가 1989년에 처음으로 문법과 라이브러리에 표준화가 논의됐다. K&R C와 ANSI C의 구분이란 게 이때 처음으로 생겼다.
- 그 뒤 한참 나중에 C99가 나왔다. // 주석이라든가 inline 키워드는 그 전부터 C++에서 야금야금 가져온 아이템들이지만, 가변 길이 배열, 가변인자 매크로, restrict 같은 것은 C++과 무관하게 독자적으로 발생한 변화이다.

- C는 타 언어들과 달리 모든 정수형에 unsigned 구분이 철저히 존재하고, 초기화되지 않은 변수라는 게 존재하고, 런타임 에러 체킹이 별로 없고 생포인터를 직접 취급할 수 있고.. 독특했다.
이런 건 프로그래밍 언어 이념을 구현하기 위한 오버헤드를 최소화하고, 언어의 구현과 빌드된 바이너리를 최대한 가볍게 만들기 위한 노력의 산물이었다.

- C는 디자인 차원에서 type-safety가 낮은 축에 드는 언어인데, 첫 초창기에는 그게 더 낮았다. 변수나 매개변수, 함수의 리턴값 같은 데에 타입 지정을 생략하는 것에 엄청 관대했다. 포인터고 enum이고 논리값이고 문자고.. 개나 소나 int 정수 취급을 너무 좋아하는 언어였다.

- C의 장점으로 제기되는 "이식성이 뛰어나다"라는 말은.. 쌍팔년도 시절 어셈블리어에 비해서 C가 정말 참신하고 편했다는 걸 의미한다. 에 그러니까 "IBM PC 호환 기종"이라는 용어가 유의미한 변별력이 있던 시절, 게임기 전용 아키텍처라든가 슈퍼컴 전용 아키텍처도 있던 시절 말이다. ㄲㄲㄲ
오늘날 같은 언어 중립 바이트코드 가상머신(JVM, .NET..)까지 염두에 두고 나온 말은 아니다.

하긴, 컴퓨터는 16비트 정도 성능은 돼야 고급 언어 컴파일러를 돌릴 수 있지 않겠나 싶다. 8비트 컴에서 돌아가는 임베디드 급 프로그램을 C로 짜려면 아무래도 크로스 컴파일을 해야지, 8비트에서 바로 구동 가능한 건 어셈블러가 전부이지 않겠나.
Java/C# 같은 가상머신 바이트코드 언어는 당연히 32비트 이상의 CPU와 주소 공간이 필요할 테고 말이다.

뭐, 이식성이라는 게 중요하긴 하다. C를 주력 언어로 써서 개발된 Windows NT, Doom 게임 등등은 오만 가지 플랫폼으로 포팅되어 현재까지 살아남아 있는 반면,
어셈블리어만 썼던 OS/2, dBASE, Lotus 123 같은 고전 프로그램들은 오래 못 가고 역사 속으로 사라졌기 때문이다.
당대의 열악한 하드웨어에서는 온갖 성능 짜내면서 잘 돌아갔지만, 도무지 포팅이나 유지보수가 안 됐으니.. 하드웨어가 바뀌자 오늘만 살고 내일이 없는 프로그램으로 전락했다.

- Quake 3 arena는 1999년 말에 출시된 FPS 게임이지만, 이때까지만 해도 존 카맥 옹은 C++이 아닌 C만 써서 얘를 코딩하고 개발했던 걸로 잘 알려져 있다. 물론 그 뒤부터는 C++이 사용되기 시작했다;;
- C11에서는 해도 너무한 보안 빵점 함수이던 gets를 deprecated도 아니고 하위 호환성 따위 무시한 채, 그냥 처음부터 있지도 않았던 함수인양 존재를 없애 버렸다. 그리고 qsort의 콜백에다가 void* context 인자를 추가한 qsort_s도 정식으로 도입했다.

※ C++ 언어는..

- 비야네 스트로스트럽인지 어쩌구.. 이름이 난해한 분이 1979년에 C with classes라는 이름으로 맨 처음 발표했다.
- 그러다가 1983년에 이름이 C++로 바뀌어 확장됐다. C에다가 변수 증가 연산자 ++를 집어넣은 셈.
(참고로 C++ 이후에 나온 언어는 D도 있고 +의 개수를 더 늘려서 형상화한 C#도 있다. ㄲㄲㄲ)

- 다중· 가상 상속, placement new, const 함수, protected (public/private뿐만 아니라), 모든 연산자들의 오버로딩 같은 건 처음부터 있지는 않았고 1980년대 말에 추가로 도입됐다. 처음엔 대입 연산의 오버로딩 정도만 생각했대나 어쨌대나..
이때는 C++ 언어 자체에 대해 1.0, 2.0 하는 버전 넘버링이 있었다고 한다.

- 이 언어는 초창기에는 C++ 코드를 C 코드로 변환해 주는 컴파일러의 형태로 구현됐었다. 이름하여 CFront. 이건 기계어가 아니라 똑같은 고급 언어로의 번역이지만 전처리기 수준이 아니라 엄연히 컴파일러였다.
CFront는 1990년대 초까지 유지보수 되다가 중단됐다. 나중에 추가된 exception 기능을 넣는 게 C의 사고방식만으로는 도저히 무리였던 듯..

- PC 환경에서 최초의 기계어 직통 C++ 컴파일러는 1987~88년쯤.. VGA 그래픽 카드와 비슷한 타임라인 때 등장했다. C가 Lattice C가 거의 원조라면, C++은 Zortech C++가 원조다. (훗날 Symantec C++)
유명 제조사인 마소와 볼랜드는 1990년쯤 돼서야 C++ 컴파일러를 내놨다. 얘들이 1989년 전후해서 C 컴파일러의 버전업이 없었던 이유가 아마 C++을 첫 구현하느라 바빠서였지 싶다.;;

- 그러다가 1990년대 초에 기초적인 템플릿이 도입됐고 예외 기능도 추가됐고.. 언어와 라이브러리의 표준화가 논의되기 시작했다. 내가 도스 16비트 환경에서는 템플릿이나 예외는 못 써 봤다.;;
- 첫 표준 규격은 C++98이다. 이때 *_cast 형변환 연산자, namespace, explicit, typeid, true/false 등등이 들어갔다. C++이 C언어 물을 벗고 type safety를 뒤늦게나마 더 강화하기 시작했다.

- 이때쯤 기존 C++ 라이브러리들이 다 std namespace 안으로 들어가고, 헤더 파일 명칭에서 확장자 .h가 없어졌다.
- 그 뒤 2000년대 중반까지 C++은 10년 가까이 별 변화가 없었다. 중간에 템플릿 export 기능을 넣으려고 하다가 컴파일러 제조사들로부터 반발에 부딪혀 영구봉인해 버리는 흑역사가 있었다만.;;

- 그러다가 2010년대.. C++0x를 거쳐서 C++11에서 C++이 auto, nullptr, 람다(!!), R-value 참조자 등등을 도입하면서 modern C++이라는 새로운 언어로 환골탈태를 시작했다.
- C++11인지 14인지부터는 스마트 포인터도 auto_ptr 대신 unique_ptr, shared_ptr 등으로 세분화됐다.
- 지금 C++은 템플릿과 auto 람다에다가도 가변인자가 들어가고 <=> 우주선 연산자도 들어갔고 진짜 10년~20년 전과도 다른 난해하고 복잡한 언어가 됐다.

C++은.. 처음부터 치밀하게 설계된 언어가 아니라 오랫동안 점진적으로 자라고 진화하고 표준화도 꽤 늦게 된 언어이다. 이게 문제다.
이렇게 타이밍을 놓친 것 때문에 1990년대 초부터 개발됐던 C++ 라이브러리 프레임워크들은 자체적으로 제각기 중구난방 중복 구현해 놓은 범용 오브젝트, 문자열, 리스트/배열 컨테이너들이 넘쳐난다.;;; C#/Java의 세계에서는 상상도 할 수 없는 혼란일 것이다.;;

난 도스 시절에 글자를 찍을 때 C의 puts를 쓰면 exe 파일이 1만 바이트대밖에 안 나왔던 반면, C++ cout을 쓰면 파일이 4만 바이트를 넘는 거 보고는 cout을 안 쓰기 시작했던 기억이 있다.. ^^

Posted by 사무엘

1. 언어 고안자의 부고

일본에서 지진이 났던 올해 1월 1일 말이다.
파스칼 언어를 고안한 스위스의 컴퓨터 과학자 '니클라우스 비르트' (취리히 연방 공대 교수, 튜링 상 수상자)가 세상을 떠났다. ㄷㄷㄷㄷ
이거 뭐 뒷북 부고 소식을 연달아 전하는구나..;; 이번에는 분야가 신앙 쪽이 아니라 컴공이라는 점만 다르고 말이다.

지난 2011년 가을엔 C 언어를 고안한 '데니스 리치'가 세상을 떠났었다.
C야 워낙 대중적인 언어이고, 또 저 시기는 무려 스티브 잡스의 부고와도 시기가 비슷했다. (딱 1주일 차이) 그래서 데니스 리치의 부고는 이때 작게 잠깐이나마 주목을 받기도 했다.
그러나 지금은? 시기가 별 개연성 없고, 파스칼 언어도 C에 비해 아주 마이너하다 보니, 저 사람의 부고는 아무 존재감 없이 묻혀 지나간 것 같다. =_=;;;

파스칼과 C는 1970년을 전후한 비슷한 시기에, 비슷한 패러다임을 반영하여 만들어진 언어이다. 물론 C가 근소하게 더 나중이긴 하다만.
파스칼은 진짜 순수 학자가 만든 반면, C는 AT&T니 벨이니 유닉스니 하면서 학계보다는 더 실무 엔지니어 지향적인 사람이 만들었다. 물론 이것도 상대적인 차이일 뿐, 데니스 리치도 튜링 상 수상자이고 일반인 입장에서 넘사벽 천재인 건 마찬가지이다.

2. 파스칼 언어 구조에 대한 생각

(1) 파스칼은 블록을 begin end로 표현하는 반면, C는 간단히 중괄호 { }로 때운다. 그리고 C는 세미콜론이 문장을 종결하는 부호인 반면, 파스칼에서는 문장을 '구분'하는 부호이다.

그렇기 때문에 C에서 { 1,2,5 } 이렇게 5 다음엔 ,를 붙이지 않듯,
파스칼에서는 begin a(); b(); c() end. end 직전의 마지막 문장에는 세미콜론을 붙이지 않아도 된다.
아주 흥미로운 차이점이다. 세미콜론 ; 은 .와 ,로 이루어진 부호인데 C는 거기서 .의 특성을 더 중시한 반면, 파스칼은 ,의 특성을 더 중시했다고 볼 수 있다.

글쎄, 파스칼은 개념적으로 알골이라는 초창기 언어에서 영향을 받았고, Ada라는 엄청난 언어와도 유사점이 많다고 하는데.. 특히 이 begin end 말이다. 허나, 이 2000년대 관점에서는 저것들도 다 한물 간 언어가 돼 버리긴 했다.

(2) 파스칼은 program, unit, label, const, type, var 등 파트가 언어 문법 차원에서 나뉘어 있는 게 좀 구시대적이고 고지식하게 느껴지지만.. 한편으로 아주 깔끔하고 명료하게 느껴지기도 한다.
const도 말이다. C/C++에서는 그냥 type modifier의 일종일 뿐인 반면, 파스칼에서는 읽기 전용 상수값들만 선언하는 구간을 나타낸다. 의미는 같지만 용법은 요즘 언어들과는 완전히 다르다는 게 흥미롭다.

C++은 블록 아무 데서나 중구난방으로 타입 선언, 변수 선언, 실행문이 막 섞일 수 있다. 같은 문장이 명칭의 의미가 무엇인지에 따라서 변수(객체) 선언일 수도 있고 함수 선언일 수도 있다. 당장 타이핑 하기에는 간결하지만, 지저분하고 정신 없게 느껴질 수도 있다.

그에 비해 파스칼은 실행문이 있는 곳과 비실행 선언문이 있는 곳이 더 엄격하게 구분돼 있다. 여느 타입이나 변수뿐만 아니라 goto문 라벨조차도 선언을 미리 쭉 한 뒤에야 실제 문장에서 써먹을 수 있다.
이런 구조 덕분에 파스칼은 컴파일러를 만들기가 더 편하다. 언어 문법 차원에서 소스 코드를 두 번이 아니라 처음부터 끝까지 한 번만 쭉 읽으면서도 최적화 계획을 미리 세우면서 컴파일이 가능하다고 한다.

이런 특성이 있고, 또 파스칼은 C/C++ 같은 텍스트 인클루드가 난무하는 언어도 아니다 보니, 비슷한 분량의 코드를 컴파일하는 속도가 C/C++보다 훨씬 더 빠르다. 이런 점에서는 파스칼이 같은 네이티브 코드 생성 언어이면서 생산성이 더 뛰어나다.

(3) 파스칼은 C/C++ 계열 언어처럼 main 함수라는 게 따로 있는 게 아니며, 그냥 코드의 맨 마지막에 등장하는 begin end. 가 제일 먼저 실행된다. 요 begin end가 HTML로 치면 <body> </body> 태그나 마찬가지인 것 같다. 앞의 여러 uses, const, type 등의 선언들은 <head></head> 에 대응하고 말이다.

그리고 파스칼은 이 코드가 단독 실행형 프로그램인지, 아니면 라이브러리(= 파스칼 언어 용어로는 유닛)인지를 소스 코드 차원에서 명시하고 있다.
main 함수가 없는 대신, 맨 첫줄에 program 어쩌구; 아니면 unit 어쩌구; 이런다.
이건 Windows 프로그래밍의 관점에서 보면 모듈 def 파일의 내용을 일부 포함하는 거나 마찬가지이다. 신기하지 않은가?

그 뒤, 마지막 end 다음에 이어지는 마침표는 프로그램 코드의 완전한 끝을 의미한다. end.
이거 다음에 등장하는 텍스트들은 컴파일러가 몽땅 무시하고 짤라 버린다. 그렇기 때문에 주석이라고 감싸지 않아도, 파스칼 문법에 맞지 않은 텍스트가 등장해도 에러 처리되지 않는다!! 컴파일러에 따라서는 end. 이후에 또 whitespace가 아닌 문자가 있다고 경고 정도나 찍어 줄 뿐이다.

(4) 파스칼의 소스 코드는 C/C++처럼 헤더와 몸체의 구분이 없다. 그래도 단독 실행 프로그램이 아닌 유닛의 소스 코드는 내부적으로 선언부와 구현부의 구분이 존재한다. 그렇잖아도 파스칼은 모든 명칭에 대해서 사전 선언을 요구하는 언어이니.. 이런 구분이 존재하는 것이 자연스럽다.

그 구획을 나누는 키워드가 interface와 implementation이라는 길고 어려운 단어이다. 본인은 저 단어를 중학교 시절에 파스칼 언어의 예약어 명목으로 처음으로 접했었다.;;

(5) 표준 입출력 말고.. 텍스트의 입출력과 관련해서 플랫폼 종속적인 비표준 기능을 제공하는 라이브러리가 Turbo C에서는 conio.h였다. 그리고 Turbo Pascal에서는 uses crt.. 즉 CRT라는 이름의 모듈이었다.
그런데 C/C++에서는 CRT라는 게 C runtime library의 약자이며 conio는 console I/O를 뜻한다. 그럼 파스칼에서 저 CRT는 무엇의 이니셜일까?

그건 화면이라는 뜻에서 그냥 브라운관 CRT를 의미하는 듯하다.
그나저나 C건 파스칼이건 함수를 호출하는 건 동일할 텐데.. 역사적으로 함수 호출 컨벤션에 왜 PASCAL이라는 명칭이 붙어 있는지는 개인적으로 의문이다. 잘 모르겠다.;;

아무쪼록.. 파스칼은 이대로 묻히기에는 좀 아까운 독특한 언어이지만, 어쩌다 보니 오늘날 주류에서 밀려난 비운의 언어가 된 듯한 느낌이다.;;

3. 여담: 관련 타 언어들

(1) 안드로이드 진영에서 새로 채택한 언어인 Kotlin, 그리고 애플 진영에서 새로 채택한 언어인 Swift에서 모두 함수의 인자 나열을 C/Java 스타일인 (Type1 val1, Type2 val2)가 아니라..
파스칼 같은 (val1: Type1, val2: Type2)
요 문법을 채택해 있다. 따끈따끈 신흥 언어에서 나름 복고풍 파스칼이 느껴지는 것 같다. ㄷㄷㄷ

그리고 Kotlin은 변수를 선언할 때는 파스칼처럼 var 키워드를 쓰는데, 상수 명칭을 선언할 때는 그냥 '값'이라는 뜻에서 val 키워드를 쓴다.
정작 변수(var)는 L-value라고 여겨지는 반면, 값(var)은 R-value인데도 말이다~! L과 R의 교묘한 언어유희가 아닐 수 없다.

(2) 프로그래밍 언어 분야에는 의외로 미국 말고 유럽.. 그것도 서유럽 영프독이 아닌 다른 마이너(?) 국가 출신들이 기여한 게 많다.

• 파스칼은 저렇게 뜬금없이 스위스.
• 파이썬은 네덜란드 (귀도 반 로섬!!)
• C++은 덴마크 사람인 비야네 스트롭스트룹!!
• 그리고 볼랜드와 마소에서 펄펄 날았던 PL 전문가 겸 엔지니어인 Anders Hejlsberg도 덴마크!!

애초에 터보 컴파일러 씨리즈로 왕년에 이름을 날렸던 '볼랜드' 사 자체가 덴마크계 사람이 창립한 기업이었다.
한편, Lua는 브라질인지 포루투갈인지 아무튼 그쪽 바닥이다.

Posted by 사무엘

오랜만에 또 C/C++ 문법 잡생각들을 늘어놓아 본다.

1. elaborated type specifier

C에서는 struct, enum, union 타입의 변수를 지정하려면 말 그대로 저 '종류' 명칭을 먼저 지정하고 나서 타입 명칭을 명시해야 했다. 종류 명칭을 생략하고 타입 명칭만으로 해당 종류를 나타내려면 C에서는 typedef를 번거롭게 해 줘야 했다.
그래서 C 시절에는 typedef struct _XXX { ... } XXX; 이런 두벌일이 관행이었다. struct _XXX라고 하든가, XXX라고 하든가 둘 중 하나다.

그러던 게 C++에서는 class라는 종류가 또 추가되었으며, 타입을 선언할 때 종류 명칭을 생략해도 되게 바뀌었다. struct XXX { ... }; 만 해도 XXX를 단독으로 쓸 수 있는 셈이다.
종류 명칭 지정은 required가 아니라 optional이 된 건데.. 허나, C++에서도 종류 명칭을 반드시 지정해야 할 때가 있다. 이런 full 명칭을 "elaborated type specifier"이라고 부르는데, 이게 필요한 상황은 바로 타입 명칭과 변수 명칭이 겹칠 때이다.

굉장히 의외이고 사실 권장되지 않는 관행이기도 하지만, C/C++에서는 기존 타입명과 동일한 명칭으로 변수를 선언하는 게 가능하다. (int, float 같은 built-in 타입 예약어는 당연히 제외)
ABC라는 클래스가 있다면 ABC ABC;라고.. ABC라는 이름의 객체/변수를 그대로 선언할 수 있다는 것이다. '야마토 급 전함 야마토'처럼 말이다.

두 클래스 A, B가 있고 앞에서 A B; 라고 B라는 변수를 선점해 버렸다고 치자.
이때 나중에 B라는 클래스의 인스턴스를 또 선언하고 싶다면 그때는 class B 뭐시기.. 이렇게 명시함으로써 이 B는 변수가 아닌 타입 명칭임을 알려줄 수 있다. A라는 클래스 소속의 변수 B, B라는 클래스 소속의 변수 A라고 상호 참조시키는 건 불가능하지 않으나 너무 사악해 보인다. -_-;;

전역변수와 지역변수가 이름이 겹칠 때 구분을 위해 :: 연산자를 사용한다면(C++ 한정), 변수명과 타입명이 겹칠 때 저런 종류 지정자가 쓰인다는 것이다.
내 개인적으로는 저 때야말로 typename 키워드도 사용 가능해야 하지 않나 생각하는데.. 그건 허용되지 않는 것 같다. ㄲㄲㄲㄲ typename과 class가 혼용 가능한(interchangable) 곳은 템플릿 인자뿐이다.

그 반면, 저기서는 struct와 class가 혼용 가능하다. 즉, class A라고 선언해 놓고는 elaborated type specifier로 struct A라고 쓰는 건 가벼운 경고 하나만 나오고 허용이다. 흥미롭지 않은지? =_=;; typename은 템플릿 바깥에서 범용적인 elaborated type specifier로서는 아직 접점이 없는 셈이다.

아울러, class는 자체적인 scope도 생성하는 역할을 한다. 그래서 :: 연산자에 잘못된 명칭이 지정됐을 때의 컴파일 에러는 "XXXX는 class 또는 namespace의 명칭이 아닙니다"이다. 요럴 때는 class가 말 그대로 namespace와 엮인다.
"class vs struct / typename / namespace"라니.. 이것도 흥미로운 점이다.

하긴, 변수명과 타입명이 겹치는 게 가능하니까 망정이지, 겹칠 수가 없다면 C 라이브러리의 struct tm (time.h)은 당장 이름이 바뀌어야 했을 것이다. 너무 짧고 겹치기 쉽고 성의 없게 만들어진 명칭이다. -_-;;

2. 정수형의 다양한 alias들

C/C++은 boolean 타입조차 없이 전부 int로 퉁치는 정수 덕후였다. 하지만 세월이 흐르면서 type-safety에 대한 필요성이 부각되었고, 용도에 따라 다음과 같은 alias 타입들이 등장해서 쓰이게 됐다.

(1) wchar_t (문자열): 유니코드 때문에 등장했고 얘 자체는 언어 표준으로 등극했다. wcslen, wcscpy 함수라든가, L"" 리터럴까지..
하지만 문자의 크기가 플랫폼별로 2바이트 내지 4바이트로 심하게 파편화됐다. 이 때문에 코드의 이식성을 저해하고 프로그래머들에게 큰 혼란을 끼치게 됐다.
결국 직접적인 크기를 명시하는 char16_t, char32_t가 나중에 일일이 추가됐다. 하지만 이것도 각 타입별 함수라든가 리터럴의 표기 방법, 심지어 % 문자열의 형식이 플랫폼마다 완전히 통일돼 있지 않다. 이식성 문제가 완전히 해결되지는 않았다는 뜻이다.

참고로 얘들은 다 built-in type이며, 기존 부호 없는 정수형의 단순 typedef가 아니다. 가령, char16_t의 포인터는 unsigned short의 포인터와 호환되지 않는다.
그리고 char이야 플랫폼 불문하고 무조건 1바이트라는 게 언어 스펙 차원에서 정의돼 있으니 char8_t를 또 만들 필요는 없다. 하지만 1바이트 문자열을 가리키는 char*는 처음부터 부호 없는 정수형으로 만들었으면 깔끔했을 텐데 하는 아쉬움이 좀 있다.

(2) ssize_t size_t (컴퓨터 비트 수): charXX_t처럼 일반 정수형도 크기를 명시한 intXX_t, uintXX_t 같은 게 도입됐는데, 얘들은 charXX_t와 달리 그냥 typedef이다.
그리고 64비트에서는 int와 long의 크기가 플랫폼별로 파편화돼 버린 관계로, 어디서나 포인터 크기와 동일함이 보장되는 정수형이 따로 만들어졌다. size_t라든가 intptr_t, uintptr_t, ptrdiff_t 말이다.
int를 4바이트로 유지시킨 건 그렇다 쳐도, long까지 32비트 4바이트로 굳힌 플랫폼은 Windows가 유일하다. 하위 호환성에 정말 목숨을 건 결정이다.

(3) time_t (미래 시간): 얘는 문자열이나 컴퓨터와 직접적인 관계는 없지만.. 그래도 21세기보다 훨씬 더 먼 미래를 표현하기 위해서 64비트로 확장되었다. time_t가 32비트이던 시절 기준으로 빌드된 구닥다리 프로그램들은 15년쯤 뒤 2038년 이후부터는 제대로 쓰기가 어려워질 것이다.
참고로 얘는 언제나 부호 "있는" 정수로 정의된다. 시각뿐만 아니라 두 시각의 차인 '시간'을 표현할 때도 쓰이기 때문이다. 과거와 미래를 모두 분간하려면 당연히 부호가 필요하다.

이런 숫자 alias들은 %문자와는 영 어울리지 않는다는 걸 알 수 있다. 저 typedef의 유동적인 비트수에 맞게 printf/scanf의 % 문자가 모든 플랫폼에 맞게 바뀌게 하려면... % 리터럴도 #define 해 가면서 바꾸면서 정말 지저분한 짓을 해야 된다. %ls인지 %S인지..?? %Id인지 %lld인지 %I64d인지.. 알 게 뭔가?

물론 값을 출력할 때는 모든 가변인자들이 intptr_t 크기로 promote되기 때문에 상황이 조금은 단순해진다. 하지만 입력을 받을 때라든가 32비트 플랫폼에서 64비트 값을 다룰 때는 역시 % 문자와 실제 변수 짝을 조심해서 대응시켜야 한다. 이러느니 C++ stream을 쓰고 말지.. =_=;;
그래도 %문자를 쓰는 게 다국어 지원 localize 관점에서는 취급이 아주 편리하다는 장점도 있는데 말이다. 차라리 독자적으로 % 문자 해석기를 만들기라도 해야 하나 싶다.

3. <=> 연산자

C/C++엔 ? : 이라고 유일하게 3개의 피연산자를 받는 독특한 연산자가 있다. if else문을 연산식 하나에다 박아 넣은 것이고, 오버로딩이 되지 않는다. 얘는 그냥 if else문만큼이나 C/C++의 문법처럼 취급되기 때문이다.
그런데, C++20에서는 단일 토큰으로서 길이가 3자나 되면서 연산 결과도 boolean 2종류가 아니라 '3종류'인 참 독특한 연산자가 추가되었다. 바로 <=> ... a <=> b는 a와 b의 대소 관계에 따라 1 0 -1 중 하나를 되돌린다. (실제로는 정확하게 정수형이 아니라 저 세 종류를 나타내는 comparision 객체 타입)
쉽게 말해 a, b가 문자열이라면 이 연산자의 결과는 strcmp 함수의 결과와 같다.

연산식에서 이 연산자가 당장 막 쓰이지는 않을 수 있다. 그러나 어떤 클래스를 구현할 때 이 연산자는 굉장히 유용하게 쓰일 것 같다. 얘는 온갖 자잘한 비교 연산자들의 상위 호환이기 때문이다.
<=> 연산자 하나만 오버로딩 해 놓으면 > < >= <= == != 을 모두 유추할 수 있다. a==b는 a<=>b == 0 이렇게 말이다.

이 연산자가 지원되는 클래스는 Java로 치면 Comparable 인터페이스를 받아서 CompareTo 메소드를 구현한 거나 마찬가지일 것이다.
C의 사고방식이라면 이 함수의 리턴값은 그냥 int이겠지만.. 얘는 C++의 이념이 가미됐다 보니 built-in 연산자의 리턴 타입이 언어 차원에서 따로 정의돼 있다.

Visual C++에서도 최신 C++20 표준 문법 옵션을 켜 주면 바로 써 볼 수 있다.
외국에서는 <=> 가 무슨 우주선(!!!!)처럼 생겼다면서 spaceship operator이라는 애칭으로 불리는가 보다.
10여 년 전엔 R-value 참조자 &&가 아주 참신하게 느껴졌는데 지금은 쟤가 비슷하게 참신하게 느껴진다.

4. 나머지 C

(1) 비트필드에 배열이 지원됐으면 좋겠다는 생각을 하는데.. 5비트씩 n개 같은 식으로 말이다. 이건 너무 욕심 부린 걸까..?? ㅎㅎ
뭐, 컴파일러의 입장에서 코드를 생성하는 게 힘들 수는 있지만.. 그래도 불가능하지는 않을 텐데 말이다.
아키텍처에 따라서 멤버들 방향 지정을 자동화하는 것과 더불어 개인적으로 비트필드에 바라는 사항이다.

(2) 배열의 원소 개수를 구하는 arraysize, 그리고 배열에서 특정 멤버의 오프셋을 구하는 offsetof
이거는 언어의 기본 문법과 연산자만으로 구현 가능하기 때문에 딱히 예약어로 지정돼 있지는 않다.
하지만 최소한 표준 라이브러리에 채택돼서 표준 헤더에서 제공할 만은 해 보인다. 특히 arraysize의 경우, C에서는 그냥 x/x[0] 같은 매크로로 구현되겠지만 C++에서는 더 type-safe한 인라인 템플릿 함수로 제공되면 될 것이다.

(3) C에는 자기 번역 단위의 밖으로 노출되지 않는 static 변수와 함수가 C++ 사고방식으로 치면 private 멤버와 얼추 비슷한 지위이다.
static 함수가 한 소스 파일 안에서 선언되고 참조(= 호출)도 됐는데 그 함수의 몸체가 정의돼 있지 않으면?? 이건 링크 에러가 아니라 해당 번역 단위에 대한 컴파일 에러로 처리된다. 오오~!! 다른 번역 단위들을 뒤질 필요가 없기 때문이다.
C++로 치면 unnamed 익명 클래스라든가 함수 안의 local 클래스에서 멤버 함수의 몸체가 곧장 정의되지 않은 것과 비슷한 상황이다. 이런 일회용 클래스들은 함수의 몸체를 바깥 딴 데서 찾을 만한 여지가 없다. ^^

C와 C++에서 이런 캡슐화 패러다임의 차이가 드러날 때가 있다.
한 클래스 A의 내부에서만 쓰이고 마는 내부 클래스 B를 그냥 A.cpp 안에다가 global scope로 선언할지, 아니면 A가 선언된 A.h 헤더 파일에다가 A 내부의 scope로 private 선언할지 말이다.
객체지향 이념에 따르자면 헤더 파일에다가 선언하는 게 좋지만, 실용적으로는 그냥 cpp가 낫다. 헤더에다가 넣으면 외부에 노출되지 않는 클래스인데도 수정할 때마다 그 헤더 의존하는 소스 파일들이 다 빌드되니까 말이다.

5. 나머지 C++

(1) "한 번도 참조되지 않은 변수"라고 경고(컴파일러 또는 정적 분석에 의해)가 뜨는 걸 무시하기 위해서 [](...){}(a,b,c,d,e); 라는 람다가 쓰인다니 참 대단하다. 아울러,
auto convert(const istream &input)  -> void;
void convert(const istream &input);
클래스의 멤버 함수도 이렇게 람다 스타일로 선언할 수 있으며, 위의 둘은 완전히 동치라고 한다. typedef 대신 using을 쓰는 문법과 비슷해 보인다. ㄲㄲㄲㄲㄲ

(2) 그나저나 using은 typedef의 완벽한 상위 호환이어서 typedef는 이제 쓸 필요가 전혀 없어지는 건지? signed 같은 잉여가 되는 건가 싶다. 템플릿 인자에서 class가 typename으로 대체되고 static 함수가 익명 namespace 함수로 바뀌는 것과 비슷한 양상인데, typedef는 쟤 말고는 다른 용도가 전혀 없으니 말이다.
using A = B는 파스칼에서 type A = B와 형태가 아주 비슷해 보이기도 한다.

(3) C++의 iterator들은 어지간한 건 내부 구현이 그냥 포인터 하나와 다를 바 없을 텐데.. intptr_t 같은 정수 하나로 간단하게 reinterpret_cast가 가능했으면 좋겠다. 그래야 type-safe하지 않은 C 스타일 콜백 같은 데서도 내부적으로 C++ 컨테이너의 원소에 접근할 수 있기 때문이다.
특히 list, vector 말이다. hash는 모르겠다만.. 트리 기반 컨테이너인 set, map은 그 특성상 노드들이 parent 노드 포인터까지 갖고 있는데, iterator도 포인터 하나만 갖고 있어도 다음 진행 방향을 결정할 수 있지 않은가?
하지만 포인터 하나보다 크기가 더 큰 iterator도 심심찮게 보이는 것 같다.

(4) constexpr은 C++도 단순 read-only와 진정한 constant의 구분을 두려는 시도인 듯하다. 게다가 멀쩡한 함수를 '인라인화'도 모자라서 컴파일 시점에서의 상수로 바꾼다니..
팩토리얼이나 피보나치 수열 상수를 재귀적으로 구하는 건 예전에는 템플릿 클래스의 상수값 형태로나 가능했다. 하지만 이제는 C/C++ 상으로 멀쩡하게 생긴 함수의 호출 형태로도 표현 가능해졌다.
뭐, 템플릿에서도 static_assert와 더불어 많이 활약할 것으로 예상되는데, 자세한 건 더 공부해 봐야겠다.

(5) 객체를 초기화할 때 생성자 obj(arg)나 대입 연산 obj=arg 말고 중괄호는 배열이나 구조체를 초기화할 때에나 쓰이는 물건으로 여겨졌다. 하지만 C++11부터는 이게 initializer list라는 개념으로 리모델링되어 임의의 클래스의 public 멤버들을 순서대로 초기화할 때도 쓰고, 컨테이너에다 여러 원소들을 한꺼번에 집어넣을 때도 쓰일 수 있게 됐다.
참 혁신적이긴 하지만 용도가 너무 다양한 것 같다. 모호성이 발생하지는 않는지, {...}는 그럼 R-value 리터럴인 건지, 내가 만드는 클래스에서 저런 걸 받아들이려면 어떡해야 하는지 궁금한 게 많다. 이것도 공부 필요.. =_=;

(6) 인터페이스를 여러 개 받아서 구현한 클래스가 정작 그 인터페이스들의 base로는(예: IUnknown) 모호하다고 형변환 되지 않는 오류 말이다(Visual C++ 기준 C2594). 정말 아무 의미 없고 멍청한 페이크에 가까운 오류인데..
base가 고유한 vtbl이 없고 데이터 멤버도 없다면 그냥 자기 this에서 가장 가까운 base를 언어 차원에서 알아서 지정하게 하는 게 좋지 않을까? 애초에 자기 데이터가 없는데 가상 상속을 할 필요도 전혀 없는걸? 궁금하다.
이게 언어 차원에서 interface라는 게 없고 그 대신 무식한 다중/가상 상속을 지향하며 만들어진 C++의 맹점인 것 같다.

(7) 나는 C/C++ 문법을 어지간한 건 다 마스터 해서 머리에 숙지하고 있고, 아무 코드나 보면 머릿속으로 가상의 컴파일러를 돌려서 "얘는 이런 식으로 기계어로 번역되겠다, 구현 비용이 얼마나 되겠다, 이렇게 동작하겠다, 이런 문제가 있다" 같은 게 예측이 된다고 생각해 왔다. 넓은 의미에서 암산과 비슷한 경지일 것이다. 아 당연히 난해한 코드 출품작 급의 괴물 코드 말고, 평범한 코드 말이다. -_-;;
하지만 계속해서 새로운 기능, 기괴한 기능들이 추가되고 있는 modern C++을 보면 이런 자신감이 갈수록 줄어드는 것 같다. 배배 꼬인 템플릿에다 auto에 람다에, ...에 헥헥~ 이 기능은 어떤 문법적 근거를 통해 빌드 되는 건지부터가 파악이 안 되는 것도 있다. =_=;;

요즘 C++은 정말 옛날에 내가 알던 그 C++에서 갈수록 멀어져 간다. 그 경직된 정적 타입 네이티브 코드 컴파일 언어에서 어떻게 동적 타입 언어의 유연함을 집어넣은 걸까? 특히 가변 인자 템플릿 말이다.;; (튜플!!) ㄷㄷㄷ

Posted by 사무엘

4. 숫자 자리수 잉여 구분자

21세기 들어서 프로그래밍 언어들에 알음알음 몰래 도입돼 들어간 요소 중 하나로는.. 숫자 자리수를 구분하는 잉여 구분자가 있다.

가령, Java는 _ 밑줄을 이 용도로 지원한다.
그래서 a = 1234567890이라고 쓸 것을 a = 12_3456_7890이라고 써도 되고, a = 1_234_567_890이라고 써도 된다. 소수점도 3.141_592_653 이렇게 쓸 수 있고, 0xFFFF_0000처럼 타 진법도 마찬가지이다.

C++에서는 참 흥미롭게도 '(어퍼스트로피)를 동일 용도로 지원한다. C++11에서인가 추가됐다고 한다. a=1'234'567;
_은 공백을 염두에 둔 기호인 반면, '는 콤마를 염두에 둔 기호라는 차이가 있다.

이런 구분자는 컴파일러의 입장에서는 있건 없건 토큰을 인식하는 데 아무 차이가 없다. 주석과 동급으로 전혀 필요하지 않은 잉여일 뿐이다.
단지, 사람 입장에서의 가독성을 위해서 이 구분자만은 예외로 컴파일러가 이물질이라고 토해내지 않고 무시 처리해 주는 것이다.

64비트 double 부동소수점이야 16비트 시절부터 존재했겠지만, 64비트 정수 리터럴은 쌍팔년도에는 거의 볼 수 없는 물건이었지 싶다. 이 정도로 큰 수는 10진법으로 나타내도 글자 수가 거의 20자에 달하게 된다. 그러니 필요할 때 인위로 자리수를 끊어서 표기할 수 있다면 코드의 가독성 차원에서 깨알같은 도움이 될 것이다.
다만, 학술적인 의미가 있지 않고 사람이 값을 참조할 일이 없는 단순 난수표 같은 숫자 테이블이라면 굳이 자리수 구분해서 적을 필요가 없을 듯하다.

그러고 보니 C++에는 0b로 시작하는 2진법 리터럴 표기도 추가됐다. 얘는 아무래도 길이가 굉장히 길기 때문에 8자 단위로 '로 끊어서 표기하는 게 확실히 유용하겠다.
그에 비해 C 시절부터 존재했던 8진법 표기는 진짜 아무데서도 안 쓰이는 잉여가 된 것 같다. FTP 파일 권한 777 이런 것 말고 딴 데서는 도통 본 적이 없다.

참고로 C/C++에는 줄 바꿈 문자를 없애고 토큰을 한데 이어 주는 \ 역슬래시라는 강력한 기호가 있다.
C/C++은 태생적으로 줄 바꿈에 연연하지 않고 중괄호와 세미콜론으로 문장을 구분하기 때문에 \ 가 필요할 일이 그리 많지는 않다. 사실상 #define 매크로 함수를 여러 줄에 걸쳐 길게 선언하는 용도로만 쓰인다.
하지만 그 특성상,

int a=123\
456;
const char b[]="abc\
def";

이렇게 써 줘도 얘는 a=123456이라고 인식되며, b에는 "abcdef"가 들어간다. \는 컴파일러라기보다는 거의 전처리기 수준으로 소스 코드의 두 줄을 기계적으로 연결해 준다고 생각하면 된다.

이걸로 심지어 // 주석조차 다음 줄까지 계속되게 만들 수 있으니 말 다 했다.;;
참고로, 주석은 컴파일러의 입장에서 whitespace 하나로 간주된다. 그렇기 때문에 100/*ㅋㅋㅋㅋ*/00은 100과 00을 분리시키며, 100'00과 같은 역할을 할 수 없다.

객체 지향, 제네릭/메타프로그래밍, 함수형 등 갖가지 패러다임들이 C++, C#, Java 등 메이저 언어들에 다 도입되면서 프로그래밍 언어들은 서로 비슷해지는 '수렴 진화' 중인 것 같다. 물론 자기 고유한 정체성을 상실할 정도로 완전히 똑같아지지는 않겠지만 말이다.

5. 오타

현직 프로그래머 내지 소프트웨어 엔지니어는 코딩을 한다고 해서 맨날천날 시간 복잡도, 공간 복잡도 따지고 다이나믹이니 그리디니 하는 신선놀음 같은 알고리즘 고민을 하는 게 아니다.

현실에서는 알고리즘이야 이미 만들어져 있고 잘 돌아가는 검증된 라이브러리나 오픈소스를 가져와서 쓰는 게 훨씬 더 많다.
자기가 새로운 코드를 만들어 내는 것보다 남이 만든 기존 코드를 읽고 유지보수 하고 버그를 잡는 비중이 훨씬 더 크다.
그리고 그 와중에 그나마 새로운 코드를 작성하는 게 있다면.. "뭔가 이름을 붙이는 것"의 비중이 매우 크다. 동사구이든 명사구이든..

그러니 프로그래머가 자기 조직이 마음에 안 들 때 아주 교묘하게 사보타주를 하고, 자기 후임을 엿먹이고 생산성을 저해하는 효과적인 방법이 있다.
자기가 작성하는 각종 클래스, 함수 등의 이름에다가 고의로 오타를 교묘하게 집어넣는 것이다.
아주 간단하게 getUserAdress 라든가.. receiveIncommingMessage 따위.

...;; 프로그램이야 멀쩡하게 돌아가니까 그 당시에는 아무 문제가 없는데..
문제는 나중에 그 프로그램의 버그를 잡고 기능을 추가하는 등 유지보수를 할 때다.
대놓고 약어를 쓴 것도 아니고 원래 그대로 풀어 쓴 듯한 영단어가 미묘하게 스펠링이 여기저기 틀려 있으면..
나중에 "검색"이 안 되어서 미치고 펄쩍 뛰는 일이 야기된다.

이런 코드는 여러 사람을 거쳐 가며 작업을 하기 어려우며, 처음 짰던 사람이 아니면 구조를 쉽게 파악할 수 없게 된다.
도서관에서 책을 꺼냈다가 일련번호 순서가 아닌 아무데나 꽂아 넣는 것과 같은 일이 벌어진다. (잘못 꽂힌 책은 없는 책과 같습니다)

진짜.. 개발 환경에서는 프로그래밍 언어 차원에서 코드의 문법 오류만 빨간줄을 치는 게 아니라, 명칭의 영어 스펠링 오류를 체크하는 것도 꽤 도움이 되지 싶다.

먼 옛날에 컴퓨터가 너무 비싼 물건이고 텍스트 에디터의 인터페이스가 불친절· 불편하고 디스크 공간이 부족하던 시절에는
뭐든지 getpid() 이런 식으로 짧게 줄여 쓰는 게 관행이었다. PC통신 채팅이나 전보에서 '안냐쎄여' 등으로 필사적으로 줄이는 것의 코딩 버전이나 마찬가지이다.

그러나 디스크 용량 걱정이 없어지고, 한번만 명칭을 정한 뒤부터는 에디터에서 긴 명칭을 자동 완성해 주는 기능이 매우 편리하게 발달하고(거의 90년대 말.. =_=), 또 소프트웨어의 규모가 왕창 방대해지고 공동 작업의 중요성이 커진 뒤부터는 GetProcessID() 이렇게 길게 풀어 쓰는 게 더 바람직한 관행으로 정착했다.
소스 코드가 자연어와 더 비슷해지고 길어지고 나니 스펠링 오류에 대한 취약성도 더 커진 셈이다.

6. 함수 안에 함수, 클래스 안에 클래스

파스칼 내지 Ada 같은 옛날 구시대 언어 중에서는 함수 안에 함수를 만드는 걸 지원하는 경우가 있었다. 그에 비해 C는 함수 호출 구조를 단순화시키느라 그런 걸 제공하지 않았다. 한 함수 안에서만 잠깐 쓰이는 코드 반복 패턴을 표현하려면 그냥 매크로 함수를 쓰라는 취지였던 듯하지만.. 이건 막 깔끔한 해결책은 못 됐다.

오늘날은 함수형 프로그래밍이 도입되면서 람다 덕분에 함수 안에 함수를 넣는 게 '사실상' 가능해졌다. 다만, 예전에 생각했던 그런 문법이 아니라, 함수 몸체를 지역변수에다 대입하는 굉장히 이색적인 형태로 가능해졌다는 게 신기한 점이다.

함수와 달리, 클래스는 원래부터 자기 내부에 클래스를 또 가질 수 있다. 그래서 C++은 C와 달리 계층적인 다단계 scope을 구현할 수 있으며, 필요에 따라 이거 표현을 간소화하기 위해 using이라는 키워드도 도입됐다.

함수건 클래스건.. (1) 내부에 안겨 있는 녀석의 명칭은.. 걔를 품고 있는 outer의 문맥에서만 유효하고 거기서만 접근 가능하다. 이건 너무나 당연한 이치이다.
그런데 안겨 있는 녀석은.. (2) 반대로 자기를 안고 있는 outer의 멤버(클래스의 경우)나 변수(함수의 경우)에 접근 가능해야 한다.

C/C++은 (2)를 지원하는 것이 미흡하고 인색했다. 그래서 C 시절부터 함수 안에 함수 같은 건 골치 아프니 지원하지 않았으며, 클래스 안의 클래스도 바깥 클래스의 인스턴스 멤버로 접근을 지원하지 않았다. Java로 치면 static class밖에 지원하지 않은 것과 같다.
C/C++은 포인터를 그렇게도 좋아하는 언어인데, 저것들은 정수 하나짜리 날포인터만으로 구현할 수 없는 개념이어서 지원을 안 한 것이지 싶다.

static 함수야 클래스에만 소속됐지, 클래스의 각 인스턴스에 매여 있지는 않아서 this 포인터가 존재하지 않는 함수이다(0). 사실상 전역 함수이나 마찬가지이다.
그리고 일반적으로는 자기 자신을 가리키는 this는 메모리 주소 딱 1개만 가리키는 포인터이지만.. 하지만 객체지향을 제대로 구현하려면 this의 크기가 한 칸만으로 충분하다는 고정관념을 깨야 할 것 같다. inner class라든가 다중 상속은 이런 문제를 훨씬 더 복잡하게 만들기 때문이다.

하긴, 그래서 Java에서는 C++에 없는 Outer o = (new Inner()).new Outer(); 이런 코드가 가능하다. C++에서는 new 연산자를 오버로딩 하더라도 무조건 static 형태만 되는데, Outer는 this가 자기 자신뿐만 아니라 Inner까지 사실상 두 파트로 구성되는 셈이다.
이게 가능하니 C++ 같았으면 다중 상속을 해야 했을 것도 저렇게 퉁치고, 프로그래밍을 더 작은 객체 단위로 깔끔하게 할 수 있을 것 같다.

클래스는 그렇다 치고.. 함수가 outer의 변수에 접근하는 건 요즘 C++도 '캡처'라는 기능으로 제공하기 시작했다. 원래는 '클로저'라고 부르는 개념이었지 싶은데 말이다. 이건 프로그래머/사용자의 관점에서는 아주 편리한 기능이지만, 내부적으로는 역시 함수 실행 문맥을 가리키는 포인터를 집어넣고 어쩌구 하면서 꽤 힘든 과정을 거쳐서 구현된다.

Posted by 사무엘

1. C++이 C보다 편리한 결정적인 요인

C++은 템플릿, 람다 등 온갖 다양한 프로그래밍 패러다임이 추가되어 C보다 훨씬 더 방대하고 복잡한 언어가 되어 있다.
그러나 C++은 맨 처음에 객체지향 언어로 시작했기 때문에 C와의 근본적인 차이는 아무래도 이와 관련된 것들이다.
본인은 C++이 C에 비해서 더 편리하고 간결하게 코딩할 수 있고 사람의 실수를 줄여 주는 제일 강력하고 중요한 요소는 다음 세 가지라고 개인적으로 생각한다.

(1) 클래스 멤버 함수 안에서 this 포인터를 생략하고 바로 자기 멤버를 참조해도 된다.
즉, C의 함수와 비교했을 때, 복잡한 구조체의 포인터인 첫째 인자는 생략 가능하다는 뜻이다. 매번 obj->member 할 필요 없이 바로 member를 쓰면 된다.

(2) 어떤 객체 변수를 선언해 주면(지역/전역) 생성자와 소멸자를 호출하는 코드가 앞뒤에 자동으로 삽입된다.
함수나 블록의 실행이 중간에 끝나더라도(return, break) 메모리를 해제하거나 파일을 닫는 코드를 거치게 하려고 지저분한 goto문을 쓰지 않아도 된다. 예외를 던질 때에도 소멸자 처리가 자동으로 된다는 건 longjmp 따위로 결코 흉내 낼 수 없는 엄청난 축복이다.

(3) 상속이라는 걸 자동으로 제공하고, 포인터 형변환 때의 상위· 하위 상속 관계를 자동으로 맞게 판단해 준다.
파생에서 기반으로 가는 건 괜찮지만, 기반에서 파생으로 가는 건 바로 안 되고 최소한 static_cast라도 해 줘야 된다.
그에 비해 C언어는 void*냐 그렇지 않느냐 하나만 판단하고, void*가 아닌 다른 모든 타입의 포인터들은 서로 남남인 타입일 뿐이다.

2. C++과 Java의 enum class

컴퓨터 프로그램에서는 숫자가 산술 연산의 대상인 수가 아니라 그냥 이산적인 식별 번호로 취급되고, 각각의 값이 서로 완전히 다른 의미를 갖는 경우가 많다. 그래서 프로그래밍 언어에서는 범용적인 정수형뿐만 아니라 sub-range 내지 열거형이란 걸 제공하곤 한다.

sub-range는 파스칼이나 Ada 같은 옛날 언어 유행으로 끝나는 분위기이고, 요즘 대세는 열거형이다.
C언어는 열거형이란 게 있긴 했지만 모종의 이유로 인해 매크로 상수가 훨씬 더 많이 쓰였다. 하긴, 그쪽은 참/거짓 bool 형조차 없었고 그냥 다 int로 퉁쳐서 썼을 정도로 int 만능 덕후 성향이 좀 있었다. =_=

C++에서는 C++11 버전부터 enum class라는 것이 도입됐다. (1) scope을 반드시 지정해 줘야 하고, (2) 정수형으로 암시적으로 형변환이 되지 않아서 type-safety가 강화되니 굉장히 적절한 변화인 것 같다.
즉, 평범한 enum이라면 int를 받는 아무 곳에서나 ENUM_VALUE라고만 써도 됐을 텐데, enum class라면 반드시 static_cast<int>( EnumClass::ENUM_VALUE ) 라고 길게 지정해 줘야 하게 된 것이다. type safety가 강화되었다.

Java에도 enum이 있긴 하지만, 후대인 Java 5에서 추가로 도입된 물건이다. 그렇기 때문에 거기도 상수 명칭을 선언하는 용도로는 재래식 static final int 뭉치가 더 많이 통용돼 왔다.
같이 도입된 건지 또 나중에 추가된 건지는 모르겠지만, Java에도 enum class라는 게 존재한다. 그런데 이건 C++과는 관점이 전혀 다른 재미있는 물건이다.

public enum Planet {
    MERCURY (3.303e+23, 2.4397e6),
    VENUS   (4.869e+24, 6.0518e6),
    EARTH   (5.976e+24, 6.37814e6),
    MARS    (6.421e+23, 3.3972e6),
    JUPITER (1.9e+27,   7.1492e7),
    SATURN  (5.688e+26, 6.0268e7),
    URANUS  (8.686e+25, 2.5559e7),
    NEPTUNE (1.024e+26, 2.4746e7);

    private final double mass;   // in kilograms
    private final double radius; // in meters
    Planet(double mass, double radius) {
        this.mass = mass;
        this.radius = radius;
    }
   (... 이후 생략)
}

이렇게, enum {} 내부에는 명칭들을 쭈욱 쓴 뒤, 세미콜론을 찍으면 명칭 나열을 종결할 수 있다.
그 뒤, 다음부터는 클래스를 선언하는 것처럼 public이니 private니 어쩌구 하면서 멤버 함수와 멤버 변수를 쓰면 얘는 enum의 탈을 쓴 평범한 클래스가 된다.

허나, 이 enum 클래스는 new 연산자를 사용해서 임의의 인스턴스를 만들 수 없다. 이 enum의 인스턴스는 저 명칭으로 선언된 녀석들만이 허용된다. 그래서 enum 명칭을 선언과 동시에 저렇게 생성자 함수에다 전할 인자를 ()로 지정할 수 있다. 우와~~~

즉, 일반적으로 enum 명칭들은 0 1 2 3  같은 숫자의 alias에 불과한 반면, enum class는 각각의 명칭들이 이 클래스의 붙박이 인스턴스가 된다는 것이다.
enum은 상수를 나타내는 만큼, enum 클래스는 멤버들도 다들 final로 선언해서 실행 중에 값이 변경되지 않는 속성을 지정하게 하는 편이다.

enum 명칭이 하나밖에 없으면..?? 얘는 자연스럽게 이 클래스의 싱글턴/단일체가 된다. 그렇기 때문에 Java의 enum class는 싱글턴을 만드는 정석 디자인으로 통용되기도 한다.
생성자를 private로 감추는 등 별별 쑈를 해도 serialize나 reflect 같은 꼼수를 통해 싱글턴 객체를 여러 개 만드는 게 가능한 반면, enum class는 언어 차원에서 그런 일이 벌어지지 않는다는 게 보증된다.

정말 신기한 용법이다. C++의 enum class는 클래스처럼 취급되는 enum이지만, Java의 enum class는 enum처럼 생긴 클래스라고 볼 수 있겠다.

3. 이름이 붙지 않은 일회용 함수/클래스

2000년대 이후부터는 C++, C#, Java 같은 주류 프로그래밍 언어에 객체지향뿐만 아니라 함수형이라는 패러다임이 도입되었다. 덕분에 중괄호 {}로 둘러싸인 코드를 통째로 변수에 대입한다거나, 심지어 함수의 인자로 일회용으로 익명으로 전하는 게 가능해졌다. 인자를 받아서 리턴값을 주는 코드의 묶음이지만 굳이 함수의 형태로 선언· 정의하고 이름을 붙일 필요가 없다는 것이다.

심지어는 클래스까지 이렇게 간편하게 선언해서 그 인스턴스를 넘겨줄 수 있다.
Java에서 무슨 이벤트에 대한 handler나 listener를 인자로 넘겨줄 때, new XXXX { } 이러면서 객체 선언과 새 파생 클래스 선언과 주요 함수 오버라이딩을 한번에 하는 것 말이다.

그런데, 이렇게 이름 없는 함수나 이름 없는 클래스는 태생적으로 이름이 필요한 요소를 언어의 문법 차원에서 구현할 수 없다.
람다 함수는 자기 자신을 호출하는 재귀호출을 구현할 수 없다.
그리고 이름 없는 클래스는.. 정말 웃기게도 컴파일러가 기본 생성해 주는 것 말고 자신의 독자적인 생성자와 소멸자를 가질 수 없다. =_=;; 흠..

C++은 Java처럼 저렇게 함수 인자에서 새 파생 클래스를 즉석에서 만드는 것까지 지원하지는 않지만.. 새 클래스를 선언할 때 이름을 생략할 수 있다. 이건 반대로 Java에서 지원하지 않는 문법이다.
이름 없는 클래스나 함수를 만드는 게 가능하니 이름에 의존하지 않고 생성자· 소멸자나 함수 자기 자신을 지칭하는 방법이 있긴 해야 할 텐데.. 이건 그냥 언어 차원에서의 한계로 남겨 두려는가 보다.

참고로 C++은 이름 없는 namespace라는 것도 지원해서 얘는 C의 static의 상위 호환으로 간주하고 있다. 즉, 이 영역에 선언되는 함수나 변수는 다른 번역 단위에서는 인식되지 않는 private한 물건이 된다.
그 밖에 이름 없는 구조체· 공용체도 있는데, 개인적인 생각은 오프셋 보정을 위해 크기(자리)만 차지하는 용도이고 실제로 쓰이지는 않는 멤버에 대해서도 이름을 생략할 수 있었으면 좋겠다.

Posted by 사무엘

1. 비트필드

C언어의 구조체에는 다른 언어에서는 거의 찾을 수 없는 비트필드라는 물건이 있다.
얘는 굉장히 편리하고 강력한 프로그래밍 요소이다. 바이트 경계에 딱 떨어지지 않는 숫자를 일반 숫자 다루듯이 읽고 쓰게 해 주니 이 얼마나 대단한가? IEEE754 부동소수점이라든가, 과거 2바이트 조합형 한글 같은 건 비트필드 구조체를 잘 만들어서 내부 구조를 쉽게 분석해 볼 수 있다.

다만, 비트필드와 관련해서 언어 문법 차원에서 다음과 같은 점이 보완되거나 강화됐으면 좋겠다는 생각이 개인적으로 오래 전부터 들었다.

(1) 지정 가능한 자료형은 그냥 unsigned 아니면 signed 둘 중 하나로 굳혀 버리고, 나머지 쓰잘데기없는 키워드들은 몽땅 거부하고 에러 처리했으면 좋겠다. 어차피 이 필드의 크기는 뒤의 비트수에 의해서 결정될 텐데.. int니 char이니 long이니 하는 건 전혀 불필요하고 쓸데없는 정보이기 때문이다. 괜히 unsigned char _field: 10; 이런 거 체크해서 10이 8보다 더 클 때만 에러 처리하는 건 잉여스러운 짓이다.

사실 본인은 비트필드에서 부호 "있는" 자료형이 쓰이기는 하는지, signed조차도 필요는 한지 그것도 굉장히 회의적이다. 차라리 enum이 쓰일 가능성은 있을지 모르겠다.

(2) 비트필드에서 공간을 배치하는 순서는 결국 타겟 플랫폼의 비트 endianness의 영향을 받는다. unsigned member : 4 라고 해 주면.. little endian에서는 하위 0~3비트가 할당되며, big endian에서는 상위 4~7비트가 할당된다.
더구나 비트필드라는 건 결국 2~4바이트짜리 커다란 정수 하나를 잘게 쪼개기 위해 존재하는 물건인데, 쪼개는 순서 자체가 비트 endianness에 따라 달라진다.

결국 비트필드를 사용해서 특정 파일 포맷이나 패킷 구조를 기술해 놓은 구조체 선언을 보면.. 빌드 환경의 endianness에 따라 조건부 컴파일을 시켜서 little일 때는 같은 멤버를 abcd 순으로 배치하고, big일 때는 이를 dcba 순으로 무식하게 배열해 놓곤 한다.

이게 정형화된 패턴이니 프로그래머가 쓸데없는 삽질을 할 필요 없이, 언어 차원에서 문법을 지원을 좀 했으면 좋겠다.
"이 비트필드들은 16/32비트 기준으로 큰/작은 자리부터 순서대로 분해하는 것이다. 그러니 타겟 아키텍처의 endianness가 이와 정반대이면 컴파일러가 알아서 멤버들의 배치 순서를 뒤집어라" 이렇게 힌트를 준다.

이런 일이 컴파일러가 하기에는 너무 지저분하다면 #pragma 같은 걸로 빼내서 전처리기 계층에다 담당시켜도 된다.
핵심 요지는.. 똑같은 멤버를 프로그래머가 순서만 바꿔서 다시 써 주고 조건부 컴파일을 시키는 무식한 짓만은 좀 없어져야 한다는 것이다.

비트필드가 쓰일 정도의 상황이면.. 아마 이 공간 전체를 거대한 숫자 한 덩어리로 같이 취급하게도 해 주는 union, 그리고 구조체 멤버 배치를 어느 플랫폼에서나 비트 단위로 일치하게 강제 동기화시키는 #pragma pack도 같이 쓰이고 있을 가능성이 매우 높다.
#pragma pack과 #pragma once는 진짜로 사실상의 표준이니 C/C++에서 정식 표준으로 좀 등재시켜야 하지 싶다. char32_t / char16_t 같은 게 결국 built-in type으로 받아들여지고 정식 표준이 된 것처럼 말이다.

참, 당연한 얘기이다만.. 구조체 템플릿에서는 비트필드의 크기를 나타내는 숫자도 템플릿 인자로 공급해 줄 수 있다.
비트필드의 크기는 구조체 멤버에 들어있는 배열의 크기와 위상이 거의 같으니 말이다. 구조체의 크기에 영향을 주는 숫자이며 컴파일 시점에서 값이 상수로 결정되어야 한다.

template<size_t N> struct XXXX {
    unsigned _member: N;
};

아주 C스러운 요소와 C++스러운 요소가 한데 만난 것 같다. ㄲㄲㄲㄲㄲ 비트필드의 크기를 템플릿 인자로 지정할 일은 극히 드물 것이다.;;

교통 분야에서 좌측· 우측 통행이 국가별로 찢어져 있다면, 디지털 컴퓨터에서는 비트의 배치 순서 endianness가 통행 방향과 비슷한 개념이며 아키텍처별로 찢어져 있는 듯하다.
네트워크 표준은 big endian이지만, 컴퓨터들은 x86이 주류이다 보니 little endian이 주류이다. 이건 세계적으로 자동차 도로 우측 vs 좌측과 비슷한 비율이며, 안드로이드 vs iOS와 비슷한 비율인 것 같다. 본인은 big endian을 native로 사용하는 컴퓨터를 평생 한 번도 구경해 본 적이 없다.

2. C의 단순 평면성

C++에 비해, C는 마소에서 거의 아오안 취급을 하기 때문에 컴파일러의 버전이 바뀌어도 달라지는 게 거의 없다. 다만..

• C99에서 추가된 가변 길이 배열이 Visual C++에서는 지원되지 않는다.
• 구조체의 가장 마지막 멤버를 구조체 자체의 크기를 차지하지 않는 명목상의 멤버로.. char data[] 내지 data[0] 같은 형태로 선언해서 구조체의 뒷부분을 가변 길이로 활용하는 게.. 여전히 일부 컴파일러의 편법일 뿐, 정식 표준이 아닌 것 같다.
  
• 대소문자를 무시하고 문자열을 비교하는 함수가 의외로 표준이 아닌 것 같다. stricmp와 strcasecmp 부류가 혼재해 있다. C는 라이브러리 함수가 ANSI니 POSIX니 하면서 의외로 파편화된 게 좀 있어서 플랫폼 간의 이식성을 저해하는 중이다.
  

C는 클래스와 상속 계층이 없을 뿐만 아니라, 각종 명칭에 다단계 계층 scope이란 것도 없다. namespace나 using 같은 걸 신경쓸 필요 없이 모든 명칭이 오로지 local 아니면 global.. 그도 아니면 매크로 함수밖에 선택의 여지가 없다. 클래스라기보다는 번역 단위 자체가 클래스와 비슷하며 static이 외부로 노출되지 않는 private 역할을 얼추 담당한다.

그러니 뭔가 아주 단순하며, 입체적인 게 아니라 '평면적이고' 깔끔해 보이기는 하는데.. 한편으로 너무 중구난방이고 명칭이 충돌하기 쉽다.
새로 짓는 이름은 접두사에 목숨을 걸어야 할 것 같다. 이런 언어로 초대형 라이브러리를 만들고 대형 프로그램을 관리하는 데는 한계가 있을 수밖에 없다.

또한 매크로 함수를 너무 사악하게 남발 남용할 경우, 어지간히 복잡하게 꼬인 C++ 템플릿 이상으로 코드가 알아보기 어려워진다. 특히 전처리기의 존재를 알지 못하는 디버거는 매크로 함수와 완전히 상극이다.

매크로 함수 내부의 코드를 한 단계씩 실행할 수 없고, 또 ## 연산자에 의해 새로 생긴 토큰 명칭들은 어지간한 IDE에서 자동으로 파악도 못 해 준다. 이렇게 IDE와의 괴리가 커지고 붕 떠 버린 코드는 사람 입장에서도 짜증이 나서 제대로 들여다보고 유지 보수하기가 싫어진다. 이는 결국 생산성의 저하로 이어진다.
이런 게 C의 어쩔 수 없는 한계인 것 같다. -_-

3. C언어의 강력하고 자유로운 면모

• 지역 변수, 전역 변수, heap 등 어디든지 가리킬 수 있는 포인터
• 한 함수 안에서 어디로든 분기할 수 있는 goto문
• type이고 뭐고 다 씹어먹고서 메모리를 조작할 수 있는 memcpy, memmove (malloc, free 같은 생짜 수동 메모리 관리는 덤)
• 무슨 토큰이건 다 치환할 수 있는 전처리기 매크로

하지만 위의 요소들은 위험성과 복잡도도 너무 키운다. 저런 저수준 조작이 잔뜩 쓰인 복잡한 코드에서 버그를 찾아내야 된다면.. 정말 머리에서 연기가 피어오를 것이다.
오늘날의 프로그래밍 언어에서는 저것들은 최대한 금기시되고 봉인되고, 다른 형태로 대체되고 있다.

goto는 아무리 사악하다고 하지만 이중 for 문을 한꺼번에 빠져나가기, 그리고 switch와 while/for문을 한꺼번에 빠져나가기 같은 건 너무 아쉽다. 자기보다 뒤로만 goto가 가능하게 제한하는 것도 나쁘지 않을 것 같은데 말이다.
한편, 개발툴에서 define 전개된 결과 기준으로 문자열을 find in files 하는 기능이 있으면 좋겠다는 생각이 가끔 든다.

4. 전처리기 #if 의 동작 방식

C/C++에서 원래 있는 if문 말고, 전처리기의 #if에서는 소스 코드에 있는 변수들을 당연히 전혀 사용할 수 없다. 오로지 #define 심벌과 상수, 기성 연산자만이 사용 가능하며, #define 심벌들은 매크로 치환 후에 다들 상수로 바뀌어야만 한다.

변수나 type이라는 개념이 없기 때문에 대입 관련 연산자는 당연히 전혀 사용할 수 없으며 포인터도 아웃이요, sizeof 연산자도 지원되지 않는다. 그 대신, 어떤 심벌이 #define돼 있는지의 여부를 판별하는 defined라는 고유한 bool값 연산자가 있다.

sizeof는 피연산자가 값이 아닌 타입 명칭일 때는 피연산자를 ( )로 싸지 않아도 된다.
이와 비슷하게, defined도 피연산자가 다른 수식이 아니라 명칭 달랑 하나이기 때문에 ( )가 없어도 된다.

그리고 나도 지난 25년 가까이 전혀 몰랐던 특성이 하나 있는데..
#if 문에서는 정의되지 않은 아무 명칭/심벌을 들이대도 에러 처리되지 않는다. 그런 듣보잡 심벌은 그냥 곱게 상수 0과 동급으로 간주된다~!

무슨 포인터 역참조 할 때 if(ptr && *ptr==1) 이러듯이 #if defined SYMBOL && SYMBOL==1 같은 defined 가드를 설치할 필요가 없다.
SYMBOL 자체가 #define돼 있지 않다면 #if SYMBOL==1은 어차피 자동으로 false로 처리된다.
겨우 이런 사소한 사항 때문에 전처리기가 까탈스럽게 에러를 뱉지는 않으니 걱정하지 않아도 된다.

5. 특수한 코딩 요소

(1) 빌드 configuration이 맞지 않는다면 코드가 아예 빌드되지 않고 고의로 에러가 유발되게 하고 싶을 때가 있다. 이때는 일부러 무식하게 C/C++ 문법에 어긋난 문자열을 늘어놓을 필요가 없이 #error라는 전처리기 지시문을 쓰면 된다.
컴파일러에 따라서는 에러가 아니라 경고 메시지만 흉내 내고 빌드는 계속 진행되게 하는 #pagma message도 표준에 준하는 기능으로 쓰인다. deprecated API를 사용을 권장하지 않는다고 표시하는 것처럼.. 이런 건 언어 차원의 지원이 필요해 보인다.

(2) 파싱과 문법 체크만 할 뿐, 실제 코드를 생성하지 않고 아무 일도 하지 않는 허깨비 유령 함수라는 것도 필요하다. 디버그 로그를 찍는 함수를 조건부로 숨길 때, 템플릿 클래스에 인자가 제대로 주어졌는지 체크할 때 등(static_if 나 컴파일 타임 assert와 비슷)..
이건 _noop라는 컴파일러 인트린식 형태로 제공되는 편이다. 마치 인라인이나 매크로 함수처럼.. 외형은 함수이지만 실제로는 자기 주소가 존재하고 매개변수의 push/pop이 행해지는 함수가 아닌 셈이다.

(3) 내용을 깡그리 무시하고 컴파일러가 파싱하지 않게 하는 영역은 '주석'이라고 불리며, 이건 모든 프로그래밍 언어에 존재한다.
C/C++에서는 /* */ 와 //뿐만 아니라 전처리기를 이용한 #if 0 / #endif도 사실상 주석처럼 쓰일 수 있다.
게다가 얘는 /* */ 와 달리, 중첩이 가능하다. #if 0으로 막혀 있는 구간이라도 전처리기의 #if #else 로직은 무시되지 않기 때문이다. 그래서 중간에 또 #if 0이 섞여 있는 코드라도 한번에 싹 막았다가 해제할 수 있어서 편리하다.

Posted by 사무엘

사람의 정치 성향 스펙트럼이라고 해서 백지에다 4개의 구획을 만든 뒤, 좌우로는 말 그대로 좌파와 우파, 상하로는 권위주의와 자유주의(혹은 전체주의와 개인주의) 이렇게 두 축을 표시해 놓은 그림이 있다.

보다시피 둘은 서로 독립적인 변수이다. 좌파라고 해서 다 빨갱이가 아니며 그냥 무정부주의에 가까운 좌파도 있다. 우파 역시 맹목적인 자유뽕에 가까운 성향이 있는가 하면 ‘국익을 위해 멸사봉공’ 이러는 노선도 있다.
두 축에 대해서 하나는 개인에 대한 자유도(상하)이고, 다른 하나는 시장에 대한 자유도(좌우)라고 생각하면 딱 이해가 될 것 같다.

무슨 MBTI 검사하듯이 수십 가지 질문으로 설문 조사를 한 뒤, 자신의 정치 성향을 저 평면 위에다가 찍어 주는 웹 서비스가 많이 있다.
극좌와 극우에 대해서 "극과 극은 통한다" 같은 소리가 종종 나오는 건, 좌우 말고 상하 축이 '전체주의' 쪽으로 일치하기 때문일 가능성이 높다. 그건 좌와 우의 전체 입장을 대변하는 진술은 아닐 것이다.

그런데 사람의 이념뿐만 아니라 프로그래밍 언어의 설계 이념도 이런 식으로 분류 가능하다. 대표적으로 type을 취급하는 방식이다.

먼저 좌우로 static이냐 dynamic이냐 하는 속성이 있다.
변수의 type이 소스 코드에 미리 명시되어서 빌드 때 완전히 붙박이로 고정되는 건 static이다. 정수에는 정수만 집어넣을 수 있고, 문자열에는 문자열만 집어넣을 수 있다.

int a;
string b;
a = 100;
b = "Hello world!!";

그 반면, dynamic은 한번 변수를 선언했으면 거기에 아무 형태의 값이나 집어넣을 수 있다.

var a;
a = 100;
a = "Hello world!!";

우리가 접하는 '가벼운, 인터프리터' 성향의 프로그래밍 언어들은 dynamic type이다. 그러나 exe/dll 따위를 생성할 때 쓰이는 기계어 직통 컴파일 성향의 '무거운' 언어들은 대체로 static type인 편이다.

dynamic은 사람의 입장에서 입문과 코딩이 용이하다. 그러나 코드의 실행 성능은 타입을 꼼꼼히 지정해 주고 이 범위를 벗어나지 않는 static이 훨씬 더 뛰어나다. 코드의 양이 수백, 수천만 줄을 넘어갈 때의 유지보수 난이도과 총체적인 생산성도 static이 더 낫다.

둘의 차이는 똑같이 표 형태의 데이터를 입력하는데 엑셀(스프레드시트)과 전문 데이터베이스의 차이와 비슷하다.
엑셀은 아무 셀에나 아무 값을(숫자, 문자열, 날짜 시간 등..) 아주 자유롭고 편하게 입력할 수 있는 반면, DB는 각 셀별로 들어갈 수 있는 자료형과 크기를 정말 딱딱하게 미리 정해 놓고 그걸 지켜야 한다.

그러나 그 상태로 데이터의 개수가 수백· 수천만 개에 달하면? 데이터를 원하는 대로 검색하고 정렬하고 한꺼번에 변형하는 성능은 스프레드시트가 DB를 절대로 범접할 수 없을 것이다. 유도리, 자유도 같은 건 성능하고는 아무래도 상극이고 등가교환 관계일 수밖에 없다.

하지만 static 언어라 해도 타입이 뻔한 문맥에서 타입 명칭을 일일이 써 주는 건 귀찮고 번거롭다. 특히 변수를 선언과 함께 초기화할 때 말이다. 대입하려는 우변의 값에 타입을 암시하는 정보가 어지간해서는 이미 포함돼 있기 때문이다.

그렇기 때문에 C++에서는 auto라는 파격적인 키워드가 도입돼서 변수 자체의 타입은 static하게 결정되더라도 최소한 int, string 같은 타입명을 번거롭게 쓸 필요는 없게 하고 있다.
또, 템플릿 메타프로그래밍이니 제네릭이니 하는 것을 도입해서 static type 언어이더라도 한 코드를 다양한 type에 대해서 범용적으로 활용 가능하게 해 놓았다. dynamic type 언어라면 저런 물건이 태생적으로 존재할 필요가 전혀 없을 것이다.

함수를 호출할 때는 보통은 값을 인자로 넘기고 값을 리턴값으로 받는다. 그런데 저런 패러다임 하에서는 함수를 호출하거나 클래스의 인스턴스를 선언하면서 타입까지도 인자로 넘기게 된다. 물론 이건 여느 함수 인자와는 성격이 많이 다르기 때문에 통상적인 괄호가 아닌 < >로 감싸고 전달하는 위치도 따로 구분돼 있다.

부등호로만 쓰이던 이항 연산자 < >가 여닫는 괄호처럼 쓰이니 이건 굉장한 발상의 전환이다. 이제는 소스 코드의 파싱도 마냥 단순무식이 아니라 주변 문맥을 의식하면서 해야 하게 됐다.

외형은 비슷해 보여도 C++의 템플릿은 C#/Java 같은 언어들의 제네릭과는 성격이 완전히 극과 극으로 다른 물건이라는 것이 주지의 사실이다. C++ 템플릿이 제네릭보다 자유도가 더 높고 화끈=_=하기는 하지만.. 이건 템플릿의 소스를 몽땅 까고, 서로 다른 템플릿 인자에 대해서 컴파일과 코드 생성이 매번 다시 행해지는 무식한 댓가를 치르는 덕분에 제공되는 장점이다.;;;

참고로 값과 타입에 이어서 { }로 감싸는 함수 몸체 자체까지 함수의 인자와 리턴값으로 마구 주고받을 수 있는 건 그 이름도 유명한 함수형 패러다임이 된다. 이게 제일 나중에 도입돼 있다.

자, static과 dynamic 타입에 대한 소개는 이 정도로 된 듯하고, 다음으로 상하 세로축을 살펴보자.
strong이냐 weak냐 하는 속성은 type safety에 관한 것이다.
서로 관련이 없는 타입의 값끼리 형변환을 알아서 쓰윽 해 주고 위험한 형변환도 별 탈 없이 허용하는 편이면 type safety가 weak인 것이다.

그렇지 않고 뭐 하나 하려면 깐깐하게 형변환 함수를 수동으로 매번 호출해야 한다면, 타입 관련 오류는 대부분 컴파일 때 다 걸러지고 런타임 때 딱히 문제가 발생할 일이 없다면 그런 언어는 strong이다. 단적인 예로,

a = 200 + "abc";

이런 구문을 알아서 "200abc"라고 접수해 주면 weak이고, 숫자와 문자열을 한데 섞을 수 없다고 까칠하게 에러를 내뱉으면 strong인 편이다.
그러면 static인 언어가 strong인 편이고 dynamic인 언어가 weak가 아니겠냐고 편견을 가질 수 있지만.. 실제로는 꼭 그렇지 않다.

같은 dynamic type 언어 중에서도 Visual Basic, JavaScript, 문자열의 유연한 조작에 특화된 Pearl, 그리고 PHP..;; 같은 언어들은 weak로 분류된다.
그 반면, 파이썬은 dynamic type 언어이지만 strong이라고 여겨진다. 둘은 아까 정치 성향과 마찬가지로 서로 별개의 개념이다.

특히 C/C++은 static이면서 weak인 매우 이례적인 언어이다. 이 범주에 드는 언어 자체가 사실상 얘들밖에 없다.
타입 시스템이 static인 것이야 의심의 여지가 없는데, C는 그에 덧붙여 type safety가 굉장히 개판이고 안전 장치가 빈약하기 때문이다.

숫자에서는 enum과 int를 제멋대로 섞어 써도 아무 문제가 없는 것, 0이 포인터와 정수에서 모두 통용되는 것, bool과 숫자의 구분도 없는 것, 관련 없는 타입의 포인터끼리의 대입이 굉장히 관대한 것, 타입의 통제 따위는 전혀 받지 않는 무식한 memcpy와 malloc이라든가 매크로 함수..;; 그리고 부동소수점 숫자의 내부 구조까지 뜯어볼 수 있는 공용체와 비트필드는 C/C++ 말고 도대체 어느 언어에서 찾아볼 수 있을까???

그나마 C++에 와서 무질서도가 눈꼽만치 개선됐다. explicit와 enum class도 도입되고 true/false 상수라든가 nullptr도 도입되면서 type safety를 강화하려고 애쓰는 중이다. 하지만 C++의 type safety는 Java나 C#에 비할 바는 못 된다고 여겨진다.

현대의 언어들은 static/dynamic이야 언어의 취향과 용도에 따라 달라지지만 type safety에 대해서는 strong을 추구하는 쪽으로 바뀌는 추세이다. weak인 언어는 당장 표현은 간결하게 할 수 있고 자유도가 더 높지만.. 안전하다는 보장이 없기 때문이다. 방대한 코드에서 갑자기 버그· 오류가 발생했을 때 지뢰가 어디에 숨어 있는지를 알기가 너무 어려워진다.
따지고 보면 제네릭이 도입된 것도 무식한 void*나 Object 떡칠만 하는 것보다 더 안전하게 코드를 작성하기 위해서이다.

Posted by 사무엘

1. 스마트포인터를 인식하지 못하는 버그

회사에서 이미 작성된 C++ 클래스 멤버 함수를 사용하고 싶어서 호출을 했는데.. 컴파일러인지 링커인지가 도무지 말귀를 알아듣질 못하고 unreferenced external symbol 링크 에러를 내뱉곤 했다. 매크로 치환, namespace 그 어떤 문제도 없는데 왜?
더 골때리는 건.. 같은 코드가 Windows에서 Visual C++은 아무 문제 없이 빌드되고, 안드로이드의 NDK 빌드 환경에서만 저런다는 것이었다.

그 함수는 첫째 인자의 타입이 FOO const&이었는데, FOO는 스마트 포인터 std::shared_ptr<BAR>의 typedef였다.
스마트 포인터를 왜 value로 전달하지 않고 또 레퍼런스로 전달했는지, 그 이유는 모르겠다. 이 코드를 처음에 내가 작성한 게 아니니까..

그런데 문제는 저 스마트 포인터를 그냥 날포인터 BAR*로 바꿔 주니까 링크 에러 없이 빌드가 됐으며, 프로그램도 양 플랫폼 다 별 문제 없이 돌아가기 시작했다는 것이다.
어느 경우건 -> 연산자를 쓰면 BAR 내용을 참조할 수 있으며, 몇몇 곳에서만 ptr 대신에 ptr.get()을 호출해 주면 됐다.

결국 이 문제의 원인은 안드로이드 쪽의 컴파일러 내지 링커의 버그이긴 한 것 같다. 하나만 고르라면 링커보다도 컴파일러의 문제인지도? 복잡한 type의 decoration string가 양쪽에서 서로 동일하게 생성되지 못했던 것으로 보인다.

2. 변수에도 extern "C" 구분이 필요한가

C++ 코드에서 다른 C 소스 파일에 정의된(C 소스로부터 빌드된 obj, lib도 포함) 함수를 참조해서 호출하려면.. 그 함수의 prototype이 extern "C" 형태로 선언되어야 한다.
C++은 오버로딩이라는 게 존재하기 때문에 C와 달리 함수를 이름만으로 유일하게 식별할 수 없으며, 인자들의 개수와 타입들도 명칭 decoration에 다 들어가야 하기 때문이다.

이건 상식 중의 상식이다. 그렇기 때문에 C언어 방식으로 만들어진 라이브러리는 헤더 파일이 중복 include guard뿐만 아니라

#ifdef __cplusplus
extern "C" {
#endif

(.....)

#ifdef __cplusplus
}
#endif

이렇게 관례적으로 감싸져 있기도 하다. C++ 코드에서 인클루드 되더라도 여기 함수들은 C++이 아닌 C 방식으로 링크 하라고 말이다.

그런데.. 난 함수뿐만 아니라 전역 변수도 이런 decoration 방식이 차이가 존재하며, 서로 일치해야 한다는 걸 요 근래에야 처음으로 알게 됐다.
C++이 C 코드에서 선언된 전역 변수를 참조하려면.. 역시 extern "C" int Global_in_C_code; 이렇게 해 줘야 된다. extern "C"를 생략하면 링크 에러가 난다..;;

헐 왜 그렇지..?? 변수는 언어 문법 차원에서 decoration이 전혀 필요해 보이지 않는데..?? Visual C++만 그런가?

그러고 보니 Visual C++은 함수를 C++ 형태로 decoration을 할 때 인자뿐만 아니라 리턴 타입까지 그 함수의 prototype의 모든 정보를 써 넣는다.
함수의 리턴 타입은 오버로딩 변별 요소가 아니기 때문에 "굳이 써 넣을 필요가 없음에도 불구하고" 그리한다는 것이다.

그런 것처럼 그냥 completeness 차원에서.. 나중에 미래에 혹시 필요할지도 모르니까 변수도 C++ 방식에서는 자신의 type까지 다 꼼꼼히 써 넣는 게 아닐까? 나로서는 이렇게밖에 생각되지 않는다.
예전에 C++에서는 const 전역 변수는 반드시 extern을 명시해 줘야 다른 번역 단위에서도 참조 가능해진다는 걸 알지 못해서 오랫동안 컴파일러/링커의 난독증을 의심하며 짜증 냈던 적이 있었는데.. 이것도 좀 비슷한 상황인 것 같다.

심지어 extern "C" 다음에 { }를 쳐서 C 방식의 외부 전역 변수 선언을 여러 개 하려면 중괄호 안에다가 extern을 또 써 줘야 된다. extern "C" { extern int x,y,z; } 처럼.

extern "C" { int x,y,z; }
이렇게 하면 x,y,z가 이 번역 단위 안에서 몸체가 직접 정의돼 버린다. 그렇기 때문에 unresolved symbol 대신, 명칭 중복 선언 충돌이라는 링크 에러가 날 수 있게 된다.

즉, 선언만 하고 마는 것은 중괄호와 함께 extern을 또 명시한 extern "C" { extern int x,y,z; } 이거 아니면..
그냥 extern "C" int x,y,z; 둘 중 한 형태라는 것이다. 어휴~ ㄲㄲㄲㄲ

3. 에러 안내

(1) 컴파일 에러는 컴파일러가 지적해 준 부분의 주변만 유심히 살펴보면 대체로 쉽게 해결 가능하다. 아주 복잡하게 꼬인 템플릿 코드에서 컴파일러가 뜬구름 잡는 난해한 소리만 늘어놓는다면 그건 상황이 다르지만, 그 정도로 극단적인 상황은 흔치 않다.
그 반면, 컴파일 에러보다 훨씬 더 무질서도가 높고 난해한 에러는 링커 에러일 것이다.

요즘 컴파일러는 명칭의 오타 때문에 에러가 나면 근처의 스펠링이 비슷한 변수· 함수를 제안까지 하면서 "혹시 이걸 의도하셨습니까?" / "혹시 뒤에 세미콜론을 빠뜨렸습니까?" 이런 안내를 할 정도로 똑똑해졌다.
링커도 "동일한 명칭이 C 방식으로는 존재하는데 혹시 extern "C"를 빠뜨렸습니까?" 정도의 유사 명칭 안내는 해 줘야 하지 않나 싶다.

(2) 아 하긴, C++ 템플릿은 그 자체만으로는 컴파일러가 문법 검사를 전혀 하지 않으며, 그 구조상 할 수도 없다.
템플릿에 인자가 주어져서 어떤 타입에 대한 실체가 생겼을 때에만 컴파일러가 그에 대한 코드를 생성할 수 있으며, 이때 비로소 문법 검사가 행해진다.

템플릿과 관련해서 발생하는 컴파일 에러는 뭔가.. 한 박자 다음에 발생한다는 점으로 인해 링커 에러처럼 더욱 난해한 구석이 있다.
템플릿 인자가 그 어떤 형태로 주어지더라도 무조건 발생할 수밖에 없는 컴파일 에러는 템플릿 자체의 코드만 보고도 컴파일러가 먼저 딱 잡아낼 수도 있으면 좋겠다만.. C++ 컴파일러 업계에서 그런 건 아직 신경을 안 쓰는가 보다. 메타프로그래밍이란 건 아무래도 추상화 수준이 높고 매우 난해한 기술이기도 하니 말이다.

4. 버전이 올라가면서 달라지는 C++ 컴파일러 동작

cmake라고 플랫폼별로 파편화돼 있는 개발툴 프로젝트/빌드 스크립트를 한데 통합해 주는 프로그램이 있다.
이건 분명 현실에서의 난해하고 복잡한 문제를 단순화시키고 해결하기 위해 만들어진 도구이겠지만.. 본인은 오픈소스나 크로스 플랫폼 같은 쪽으로는 인연이나 경험이 없다시피한 Windows 토박이에 Visual Studio 매니아이다 보니 얘를 다루는 게 참 난감하고 버겁게 느껴졌다.

회사에서 굉장한 구닥다리인 Visual Studio 2013을 오랫동안 쓰고 있어서 이걸 2019로 올리고, 플랫폼도 x86뿐만 아니라 x64도 추가하고 싶은데.. 그러려면 cmake 스크립트를 어떻게 바꿔야 하는지 알 길이 없었다.

나중에 알고 보니 cmake 자체도 버전업을 해야 했다. 그런데 VS가 2013이 없고 2019만 있을 때 발생하는 에러 메시지들이 그 근본 원인과는 전혀 관계 없는 엉뚱한 것들이어서 에러 메시지가 짚어 주는 부분만 뒤져서는 문제의 원인을 도무지 알 수 없었다.

cmake 따위 없이 Visual Studio 솔루션과 프로젝트 파일만 있었으면 이건 뭐 일도 아니었을 텐데 이런 것들이 cmake 스크립트가 좀 유연하지 못한 구석이 있는 것 같았다. 특정 Visual Studio 버전과 특정 타겟 아키텍처에 매인 비중이 크다. 뭐, 사실은 본인이 cmake 사용법을 잘 몰라서 삽질하는 것이겠지만..
cmake나 git 같은 빌드 관련 툴들은 학교에서 가르치기에는 너무 남사스럽고, 학원도 아니고.. 천상 스스로 독학하거나 직장에서 알음알음 배우는 수밖에 없나 모르겠다.

그리고 이렇게 컴파일러를 업글 하고 나면.. 기존 코드가 자잘하게 컴파일이 안 되는 부분이 꼭 발생하곤 한다. 그런 건 내 경험상.. C++이 갈수록 type safety가 강화되어서 더 까칠 엄격해지기 때문인 것 같다.
직장에서의 경험을 회고해 보자면, 이 클래스가 이 상태로는 vector, list, set 같은 컨테이너에 들어가지 않아서 에러가 나곤 했다. 2013에서는 됐는데 2019에서는 안 되는 것이다.

operator =의 인자가 T였던 것을 const T&로 바꾸고, 복사 생성자가 정의돼 있지 않던 것을 명시적으로 넣어 주고, 원래는 생성자에다가 U라는 타입 값을 넣으면 자동으로 형변환이 됐는데 이제는 되지 않아서 명시적으로 형변환을 하는 등.. 에러를 해결하는 방식이 다들 이런 식이었다.

Posted by 사무엘