« Previous : 1 : 2 : 3 : 4 : 5 : ... 7 : Next »

본인은 최근에 직장일 때문에 이메일을 자동으로 생성해서 보내는 프로그램이란 걸 난생 처음으로 작성해 봤다. 소켓 API만 써서 말이다.
서식이고 첨부고 몽땅 다 생략한 최소한의 형태만 생각한다면, 이메일을 보내는 것 자체는 내 예상보다 굉장히 간편하게 쉽게 자동화할 수 있는 일이라는 걸 알 수 있었다. SMTP 서버 명령어 몇 개만 스펙대로 주고 받으면 된다.

발신자는 말할 것도 없고 수신자조차도 실제로 수신하는 대상과 화면에 표시되는 수신자가 서로 다르게 얼마든지 조작 가능하다. 스팸 메일을 대량으로 살포하는 건 일도 아니겠다는 걸 이제야 느꼈다. 이런 문제도 있고, 또 이메일 내용을 다른 해커가 가로챌 수도 있으니 이 바닥에도 온갖 복잡한 인증과 암호화 계층이 나중에 도입된 거지 싶다.

이메일과 관련하여 서버에다 요청을 보낼 때는 줄 바꿈 문자가 \n이 아니라 반드시 \r\n을 써야 한다는 게 인상적이었다. 이건 어째 유닉스가 아닌 DOS/Windows 진영의 관행과 일치한다. 그리고 메일 본문의 끝을 의미하는 게 도스의 copy con이 사용하는 Ctrl+Z 같은 제어 문자가 아니라 그냥 "빈 줄+마침표+빈 줄"이다.

또 주목할 만한 것은 DATA(본문)에 들어가는 발신 날짜였다. 난 메일을 보내면 발신 시각 정도는 메일 서버가 자기 시각을 기준으로 당연히 자동으로 넣어 줄 거라고 생각했다. 사람이 이메일을 보낼 때 발신 시각을 일일이 써 넣지 않듯이 말이다.
하지만 내부적으로는 그렇지 않았다. 보내는 쪽에서 알려 줘야 하며, 허위로 조작된 임의의 날짜· 시각을 보내는 것도 얼마든지 가능하다.

그리고 여기에 써 주는 날짜· 시각은 "Tue, 18 Nov 2014 13:57:11 +0000" 같은 형태로, 날짜와 시각, time zone을 모두 포함하고 있다. 심지어 요일이라는 일종의 잉여 정보도 있다.
이 형식은 RFC 2822에 표준 규격으로 정해졌는데, 보다시피 사람이 읽기 편하라고 만들어졌지 컴퓨터의 입장에서 간편하게 읽고 쓸 수 있는 형식은 아니다. 컴퓨터의 관점에서는 그냥 1970년 1월 1일 이래로 경과한 초수, 일명 Unix epoch 숫자 하나가 훨씬 편할 텐데 말이다. time zone도 무시하고 UTC만 통용시키고 말이다.

실제로 이 날짜· 시각 문자열은 그 형태 그대로 쓰이지 않는다. 어차피 이메일 클라이언트가 파싱을 해서 내부적으로 Unix epoch 같은 단순한 형태로 바꿔야 한다. 그래야 당장 메일들을 오래된 것-새것 같은 순서대로 정렬해서 목록을 뽑을 수 있을 테니 말이다. 또한 그걸 출력할 때는 "2014년 11월 18일 오후 10시 57분 11초"처럼 사용자의 언어· 로케일과 설정대로 형태가 또 바뀌게 된다.

그러니 사람보다는 기계가 더 활용하는 날짜 시각 문자열 포맷이 왜 저렇게 복잡한 형태로 정해진 건지 의문이 들지 않을 수 없다. 읽고 쓰기 위해서 달 이름과 요일 이름 테이블까지 참조해야 하고 말이다. 글쎄, SMTP 명령어를 사람이 직접 입력해서 이메일을 보내던 엄청난 옛날에 사람이 읽고 쓰기 편하라고 저런 형태가 정해진 건지는 모르겠다.

Windows API의 GetDateFormat/GetTimeFormat 내지 C 언어의 asctime/ctime 함수 어느 것도 이메일의 날짜· 시각 포맷과 완전히 일치하는 문자열을 되돌리지는 않는다. 특히 C 함수의 경우,

Tue Nov 18 13:57:11 2014

로, 년월일 시분초 요일까지 정보가 동일하고 맨 처음에 요일이 나오는 것까지도 일치하지만.. 이메일 포맷과는 일치하지 않는다. C 함수도 나열 순서와 글자수가 언제나 동일하고 불변인 것이 보장돼 있기 때문에 저걸 변경할 수는 없다. 저 결과값을 그대로 쓸 수도 없으니 답답하기 그지없다.

참고로 일반인이 저런 날짜· 시각 format 함수를 작성한다면 그냥 단순무식하게 sprintf "%02d %s" 같은 방식으로 코딩을 하겠지만, 프로그래밍 언어 라이브러리에서는 그런 짓은 하지 않고 성능을 최대한 중요시하여 각 항목들을 써 넣는 것을 한땀 한땀 직접 구현한다. 해당 라이브러리의 소스를 보면 이를 확인할 수 있다.

Windows API에는 SYSTEMTIME이라는 구조체가 있고, C에는 tm이라는 구조체가 있어서 날짜와 시각을 담는 역할을 한다. 그런데 tm이라니.. 구조체 이름을 무슨 변수 이름처럼 참 이례적으로 짧고 성의없게 지은 것 같다. -_-
C 시절에는 앞에 struct라는 표식을 반드시 덧붙이기라도 해야 했지만 C++은 그런 것도 없으니 더욱 난감하다. C++의 등장까지 염두에 뒀다면 이름을 절대로 저렇게 지을 수 없었을 것이다.

또한 tm 구조체의 멤버들 중 월(tm_mon)은 1이 아니라 0부터 시작한다는 것, 그리고 연도(tm_year)는 실제 연도에서 1900을 뺀 값을 되돌린다는 것도 직관적이지 못해서 번거롭다. 즉, 2019년 7월은 각각 119, 6이라고 기재된다는 것이다. 그에 반해 Windows의 SYSTEMTIME은 그렇지 않으며 wYear과 wMonth에 실제값이 그대로 들어가 있다.

월이 0부터 시작하는 건 쟤네들 문화권에서는 어차피 월을 숫자가 아닌 이름으로 취급하기 때문에 배열 참조의 편의를 위해서 그렇게 했을 것이다. 그런데 연도는.. 무슨 공간을 아끼려고 굳이 1900을 뺐는지 모르겠다. 16비트 int 기준으로 서기 32767년만 해도 정말 까마득하게 먼 미래인걸 말이다.

아 하긴, 20세기 중후반엔 연도의 마지막 두 자리(10과 1)만 써도 70이니 90이니 하면서 월과 일의 숫자 범위보다 월등히 컸기 때문에 변별력이 있었다. 연도도 두 자리만 쓰는 게 관행이었기 때문에 1900을 빼는 것은 그런 관행을 반영한 조치였을 것이다. Office 97은 있어도 Office 07은 없고 2007이니까 말이다.

엑셀 같은 스프레트시트들도 날짜 겸 시각을 저장하는 자료형의 하한이 1900년 1월 1일로 잡혀 있다. 그래서 한국 최초의 철도가 개통한 1899년 9월 18일 같은 날짜는 아슬아슬하게 날짜형으로 저장하지 못하며, 일반 문자열로만 취급된다. =_=;;

이렇게 인간 가독형 날짜· 시각 말고 기계 가독형으로 직렬화된 날짜· 시각을 저장하는 정수 자료형으로 Windows에는 FILETIME이 있고, C에는 time_t가 있다. FILETIME은 Windows NT 시절부터 64비트로 시작했지만 후자는 2000년대 이후에 와서야 2038년 버그를 미연에 방지하기 위해 각 플랫폼별로 64비트로 확장됐다. 사실, 이때부터 PC도 64비트로 바뀌어서 플랫폼에 따라서는 long 같은 자료형도 64비트로 바뀌기도 했다..

그리고 요일이야.. 두 구조체 모두 일요일이 0이고 토요일이 6이다.
요일도 이름이 아닌 숫자로만 취급하는 언어는 내가 알기로 중국어밖에 없는데 혹시 더 있는지 궁금하다. 물론 인간의 언어에는 설마 0요일이 있을 리는 없고 1부터 시작할 텐데.. 중국어의 경우 일요일은 日이어서 이게 0 역할을 하고, 월요일부터 토요일까지가 1요일~6요일에 대응한다.

이상이다. 이메일 얘기로 시작해서 날짜 시각 얘기로 소재가 바뀌었는데..
이메일(POP3/SMTP)을 비롯해 HTTP, FTP 같은 표준 인터넷 프로토콜들을 클라이언트와 서버를 모두 소켓 API만으로 직접 구현해 보는 건 코딩 실력의 향상에 도움이 될 것 같다. 일상생활에서야 이미 만들어져 있는 솔루션만 사용하면 되니까 실용적인 의미는 별로 없겠지만, 학교에서 학술..도 아니고 그냥 교육적인 의미는 충분히 있을 테니 말이다. 내부 구조를 직접 살펴보면, 이런 프로토콜의 secure 버전이 왜 따로 만들어져야 했는지 이유도 알게 될 것이다.

더구나 이를 응용해서 특정 메일에 대해 자동 회신을 보내는 프로그램, 한 FTP 서버의 파일을 다른 FTP 서버로 올리는 프로그램까지 만드는 건 시험이나 과제 용도로도 괜찮아 보인다. 요즘은 FTP 같은 거 명령어로 이용할 줄 아는 사람이 얼마나 될까? 당장 본인도 모른다. ㅎㅎ

이메일을 쓰지 않는다는 도널드 커누쓰 할배가 문득 생각난다. 이분이야 뭐 1970년대, 컴퓨터 네트워크라는 건 그냥 기업· 연구소, 정부 기관만의 전유물로 여겨졌고 이메일이란 게 처음으로 발명됐던 시절에 그걸 다뤄 왔던 분이다. 그러다가 현역 은퇴 후에 때려치우고 온라인 공간의 속세와 단절한 셈이다. 이젠 뭐가 아쉬워서 누구에게 이메일로 연락을 하거나 연락을 기다려야 할 처지도 전혀 아니고.. 그냥 아날로그 종이 편지를 취급하는 것만으로 충분하시댄다.

Posted by 사무엘

2019/12/18 08:32 2019/12/18 08:32
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1695

C/C++은 어떤 명칭에 대해 선언과 정의의 구분이 명확한 축에 드는 언어이다. 정의는 선언도 같이 포함하지만 그 역은 성립하지 않는다. 전자는 심판의 선고이고, 후자는 집행이라고 봐도 되겠다.

(1) 함수: 실행되는 코드를 담고 있기 때문에 {}에 둘러싸여 정의된 몸체의 존재감이 압도적인 물건이다. 또한 함수의 선언부는 자신의 프로토타입(인자의 개수와 타입, 리턴값의 타입)을 나타내기도 한다. 그렇기 때문에 얘는 소형 인라인 형태가 아닌 이상, 선언과 정의의 구분이 가장 명확하다.

(2) 자료형: 구조체나 클래스는 함수보다야 선언 따로 정의 따로일 일이 훨씬 드물다. 하지만 헤더에서는 포인터 형태만 사용하는데 쓸데없는 #include 의존성을 또 만들지 않기 위해 class Foo; 같은 불완전한 타입을 선언만 하는 게 가능은 하다. 마치 함수 선언처럼 말이다.
선언만 존재하는 불완전한 타입은 sizeof 연산자를 적용할 수 없으며, 포인터형의 경우 *나 ->로 역참조해서 사용할 수도 없다.

(3) static 멤버/전역 변수: 변수는 선언하는 것 자체 말고 딱히 {}로 둘러싸인 세부 정의가 존재하지 않는다. 생성자 인자라든가 초기화 값(initializer)이 쓰이긴 하지만 그건 definition, body와는 성격이 완전히 다른 정보이니 말이다.

다만, 지역 변수 말고 클래스의 static 멤버에 대해서는 static int bar와 int Foo::bar 같은 선언/정의 구분이 존재한다. 그리고 전역 변수도 extern이라고 선언된 놈은 정의가 아닌 선언 껍데기일 뿐이다. (실제 definition은 다른 translation unit에 존재한다는..)
사실, global scope에서 함수의 선언도 앞에 extern이 생략된 것이나 마찬가지이다. 지역 변수의 선언들이 모두 구 용법의 auto가 생략된 형태인 것처럼 말이다.

함수건 변수건 선언은 여러 군데에서 반복해서 할 수 있지만 몸체 정의는 딱 한 군데에만 존재한다. 이는 마치 분향소와 빈소의 관계와도 비슷해 보인다.
이런 선언부에서는 배열의 경우 그 구체적인 크기를 생략할 수 있다. * 대신 []을 써서 얘는 정확한 크기는 모르지만 어쨌든 포인터가 아닌 배열이라고 막연하게 선언할 수 있다는 것이다. 그리고 const 변수는 초기화 값이 선택이 아니라 필수인데, 이 역시 선언 단계에서 생략될 수 있다.

1. 함수와 구조체: 상호 참조를 위한 불완전한 전방 선언

(1) 함수나 (2) 구조체/클래스는 상호 참조를 할 수 있다. A라는 함수에서 B를 호출하고, B도 A를 호출할 수 있다. 또한, X라는 구조체에서 Y라는 구조체의 포인터를 멤버로 갖는데, Y도 내부적으로 X의 포인터를 갖고 있을 수 있다.

요즘 프로그래밍 언어들은 구조적으로 같은 소스 코드를 두 번 읽어서 파싱하게 돼 있기 때문에 한 함수에서 나중에 등장하는 다른 함수를 아무 제약 없이 참조할 수 있다. C++도 그런 요소가 있기 때문에 한 클래스의 인라인 멤버 함수에서 클래스 몸체의 뒷부분에 선언된 명칭에 곧장 접근할 수 있다. 즉, 다음과 같은 코드는 컴파일 된다.

class Foo {
public:
    void func1() {
        func2();
    }
    void func2() {
        func1();
    }
};

하지만 global scope에서 이런 코드는 적어도 C++ 문법에서는 허용되지 않는다.

void Global_Func1() {
    Global_Func2();
}
void Global_Func2() {
    Global_Func1();
}

맨 앞줄에 void Global_Func2(); 이라고 Global_Func2라는 명칭이 껍데기만이라도 forward(전방) 선언돼 있어야 한다. 파스칼 언어에는 이런 용도로 아예 forward라는 지정자 키워드가 있기도 하다.
매우 흥미로운 것은..

struct DATA1 {
    DATA2* ptr;
};
struct DATA2 {
    DATA1* ptr;
};

이렇게 구조체끼리 상호 참조를 하기 위해서는..
심지어 클래스 안의 구조체라 하더라도 앞에 struct DATA2는 반드시 미리 전방 선언이 돼 있어야 한다는 것이다. 클래스 안에 선언된 멤버 함수와는 취급이 다르다. 왜 그런 걸까? 멤버 함수의 몸체는 클래스 밖에 완전히 따로 정의될 수도 있지만 구조체의 몸체는 그럴 수 없다는 차이 때문인 듯하다.

원래 파스칼과 C는 옛날에 컴파일러의 구현 난이도와 동작 요구 사양을 낮추기 위해, 소스 코드를 한 번만 읽으면서 곧장 parsing이 가능하게 설계되기도 했다. 모든 명칭들은 사용되기 "전에" 정의까지는 아니어도 적어도 선언은 미리 돼 있어야 컴파일 가능하다. 아무 데서나 '정의'만 한번 해 놓으면 아무 데서나 그 명칭을 사용할 수 있는 그런 자유로운 언어가 아니라는 것이다.

함수와 전역 변수의 경우, 그 다음으로 몸체 정의를 찾아서 실제로 '연결'하는 건 잘 알다시피 링커가 할 일이다. 단지, 구조체/클래스는 몸체가 당장 컴파일 과정에서 그때 그때 쓰이기 때문에(멤버의 타입과 오프셋...) 링크가 아닌 컴파일 단계에서 실제 몸체를 알아야 한다는 차이가 있다.

불완전한 타입에 대해서 거기에 소속된 구조체/클래스를 불완전한 형태로 또 중첩 선언하는 것은 가능하지 않다.

class A;
class A::B;

A의 몸체를 모르는 상태에서 연쇄적으로 B를 저렇게 또 선언할 수는 없다는 것이다. 그걸 허용하는 건 C++을 동적 타입 언어급으로 만드는 너무 사악한(?) 짓이 될 것 같다. 특히 이미 자유도가 너무 높은 템플릿을 구현하는 것까지 생각했을 때 말이다.
실체가 없는 저런 자료형의 포인터를 무리하게 만들 바에야 아예 void* 포인터를 그때 그때 캐스팅해서 쓰고 말겠다. 아니면, 저런 식으로 다단계 scope 구분만 하는 게 목적이라면 클래스 대신 namespace라는 훌륭한 대체제가 있다.

2. 구조체: 전방 선언과 다중 상속 사이의 난감함

이렇게 몸체를 모르는 클래스를 불완전 전방 선언만 해서 쓰는 것은 일면 편리하지만.. C++이 제공하는 다른 기능 내지 이념과 충돌해서 난감한 상황을 만들 때도 있다.
즉, class X와 class Y라고 이름밖에 모르던 시절에는 X와 Y는 서로 완전히 남남이며, 포인터 형변환도 오프셋 보정 없이 단순무식한 C-style로만 하면 된다.

그런데 알고 보니 X와 Y가 다중 상속으로 얽힌 사이라면.. 몸체를 모르던 시절과 알고 난 뒤의 컴파일러의 코드 생성 방식이 서로 달라질 수밖에 없다. 특히 X 내지 Y의 멤버 함수를 가리키는 pointer-to-member 타입의 크기와 구현 방식도 달라지게 된다. X가 전방 선언만 돼서 아무런 단서가 없을 때가 제일 복잡하고 까다롭다.

Visual C++의 경우, 얘가 전방 선언만 됐지만 다중/가상 상속 같은 것 안 쓰는 제일 단순한 형태이기 때문에 pointer-to-member도 제일 단순한 형태로만 구현해도 된다고 단서를 제공하는 비표준 확장 키워드를 자체적으로 제공할 정도이다. 그만큼 C++의 스펙은 복잡 난해하고 패러다임이 서로 충돌하는 면모도 존재한다.

이렇듯, 명칭의 선언과 정의라는 간단한 개념을 고찰함으로써, C/C++ 이후의 언어들은 선배 언어의 복잡 난해함을 어떻게든 감추고 사용자와 컴파일러 개발자의 입장에서 다루기 편한 언어를 만들려고 어떤 개량을 했는지를 알 수 있다. 당장 Java만 해도 헤더/소스 구분 없이 한 클래스에서 각종 함수나 명칭을 수정하면 번거로운 재컴파일 없이도 그걸 다른 소스 코드에서 곧장 사용 가능하니 얼마나 편리한가 말이다.

3. 함수: extern "C"

앞서 살펴본 바와 같이 extern은 static library 형태이든 DLL/so 방식이든 무엇이건, 외부로 노출되는 전역 함수 및 변수 명칭을 선언하는 키워드이다. 그런데 기왕 대외 선언을 하는 김에 노출을 하는 방식도 옵션을 줘서 같이 지정할 수 있다.
모르는 사람에게는 굉장히 기괴해 보이는 문법인 extern "C"가 바로 그것이다. 이건 함수 명칭을 C++ 스타일로 decorate를 할지, 아니면 예전의 C 시절처럼 원래 이름을 변조 없이 그대로 선언할지를 지정한다.

C++에서 변조니 decorate니 해서 굳이 언어의 ABI 차원에서 호환을 깨뜨려야 하는 이유는.. C++에는 C와 달리 함수 인자를 기반으로 오버로딩이 존재하기 때문이다. 그러니 argument의 개수와 타입들에 대한 정보가 이름에 첨가돼야만 이 함수를 그 이름으로 유일하게 식별할 수 있다.

뭐, static 함수는 대외 노출이 아니니 한 번역 단위 안에서 함수 이름이야 어떻게 붙이건 전혀 상관없으며.. C++ 클래스 멤버 함수는 애초에 C언어에서 접근 불가능한 물건이이고 무조건 C++ 방식으로 decoration을 해야 한다. 그러니 extern "C" 옵션이 필요한 곳은 C와 C++이 모두 접근 가능한 일반 전역 함수 정도로 한정된다.

"C" 말고 쓸 수 있는 문자열 리터럴은 "C++".. 요 둘뿐이다. 그리고 "C++"은 디폴트 옵션이므로 signed만큼이나 잉여이고, 오늘날까지도 사실상 "C"만 쓰인다.
만들고 있는 라이브러리가 자기 제품 내부에서밖에 안 쓰이거나, 어차피 소스째로 통째로 배포되는 오픈소스여서 특정 컴파일러의 ABI에 종속되어도 아무 상관 없다면.. 함수를 C++ 형태로, 아니 C++ 클래스 라이브러리 형태로 선뜻 만들 수 있을 것이다.

그게 아니라면 외부 노출 함수 이름은 어느 언어에서나 쉽게 import 가능한 extern "C" 형태로 만드는 게 일반적이다. extern "C" 다음에는 이 구간에서 선언되는 명칭들을 모두 C 방식으로 노출하라고 중괄호 {}까지 줄 수 있으니 생소함과 기괴함이 더해진다.

이건 컴파일러의 구문 분석 방식을 변경하는 옵션이 아니다. {} 안의 코드는 C 문법으로만 해석하라는 말이 절대 아니다. extern "C" 방식으로 선언된 함수의 안에서도 템플릿, 지역 클래스 등 C++ 문법은 얼마든지 사용할 수 있고 타 C++ 객체를 참조할 수 있다. 단지 이 함수는 동일 명칭의 여러 오버로딩 버전을 만들어서 대외적으로 제공할 수 없을 뿐이다.

또한, 컴파일러의 최적화나 코드 생성 방식에 영향을 주지도 않는다. stdcall, pascal, cdecl 같은 calling convention이야 인자를 스택에다 올리는 순서 내지 스택 주소 복귀를 하는 주체(caller or callee)를 지정하는 것이니까 코드 생성 방식에 영향을 준다. 언어 문법 차원에서의 프로토타입이 동일하더라도 calling convention이 다른 함수끼리는 포인터가 서로 호환되지 않는다.
그에 반해 extern "C" 지정이 잘못되면 obj와 lib 사이에 공급된 명칭과 요청한 명칭이 일치하지 않아서 끽해야 링크 에러가 날 뿐이다. 개념이 이렇게 정리된다.

Posted by 사무엘

2019/11/16 08:32 2019/11/16 08:32
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1684

1. 문법 함정

C/C++에서 연산자로 쓰이는 토큰(문자)들 중에는 문맥에 따라서 의미가 중복될 수 있는 것이 있다.
예를 들어 * () [] 같은 토큰은 값을 계산하는 수식에서 쓰일 때와, 변수를 선언할 때 의미가 서로 다르다. 한쪽에서는 인근의 변수가 배열· 포인터· 함수 타입임을 나타내지만, 다른 쪽에서는 실제로 배열 첨자나 포인터를 역참조하고 함수를 호출하는 역할을 한다.

심지어 =조차도 int a=5; 와 그냥 a=5; 에서 =는 문법적인 의미가 서로 동일하지 않다. 똑같이 =를 썼더라도 중괄호를 동원하여 배열이나 구조체를 초기화하는 것은 일반 수식에서는 가능하지 않기 때문이다.

이런 것 말고도 콤마(,)의 경우.. 함수 인자 구분자와 쓰임이 완벽하게 겹친다. 그렇기 때문에 함수 인자에서 콤마 연산자를 쓰려면 수식을 괄호로 싸야 한다.

그리고 <>로 둘러싸인 템플릿 인자에서 부등호 내지 비트 이동 연산자를 쓸 때도 상황이 좀 난감해진다. 템플릿 인자에 typename만 올 때는 <>가 모호성을 전혀 일으키지 않지만, 문제는 템플릿 인자로 정수도 들어올 수 있다는 것이다. 그리고 값이 컴파일 타임 때 결정만 될 수 있다면 정수값을 만들어 내는 각종 연산자들도 당연히 쓰일 수 있다.

template class Foo<size_t N> { .... };

Foo<(a>b ? 5:3)> bar1;
Foo<(MAX>>3)> bar2;

그러니 위와 같은 상황에서는 수식 전체를 괄호로 싸야만 한다. 괄호가 단순히 같은 수식 안에서 연산 우선순위를 조절할 때만 쓰이는 게 아니라는 점이 흥미롭다. 수식 영역과 함수 및 템플릿 인자 영역을 구분할 때도 쓰인다.

std::vector<std::list<int>> vl;

요렇게 중첩되었던 템플릿 인자들이 한꺼번에 종결될 때 > 사이를 강제로 띄우지 않아도 되게 컴파일러의 동작 방식 지침이 달라진 때가 내 기억이 맞다면 C++03과 C++11사이였지 싶은데.. 정확하게는 모르겠다.

그 밖에 2[a]가 가능하다는 C/C++의 변태적인 특성상, 람다와 관련해서 또 변태 같은 중의성을 만들 수 있지는 않으려나 궁금한데, 너무 머리가 아파서 더 생각해 보지는 않으련다.
요즘 C++은 auto라든가 using, delete를 보면 =를 사용하는 새로운 문법이 여럿 생긴 것 같다.

2. 비표준이지만 표준처럼 쓰이는 함수

C언어 라이브러리에 있는 모든 함수들이 100% 표준이고 어느 플랫폼에서나 동일하게 사용 가능한 게 아니다.
본인은 평소에 Visual C++만 쓸 때는 이런 걸 전혀 의식하지 않고 지냈는데.. strlwr과 심지어 내 기억이 맞다면 strdup도 macOS에서는 지원되지 않는 걸 최근에 확인하고는 놀랐었다.
물론 저런 함수들이야 하는 일이 워낙 간단하니 3분 만에 직접 짤 수도 있다. 하지만 핵심은 저건 universal한 표준이 아니라는 것이다.

Visual C++도 세월이 흐를수록 '표준 준수'를 강조하는 쪽으로 라이브러리의 디자인이 바뀌다 보니, 관례적으로 제공되긴 했지만 엄밀히 말해 표준이 아닌 함수들에 대해서는 앞에 밑줄을 붙여서 구분하는 추세이다.
하긴 그러고 보니, Visual C++을 업그레이드 한 뒤에 기존 코드가 컴파일되지 않아서 수정하던 내역 중에도 멀쩡한 함수 앞에다가 _를 붙이는 게 많았다. 일례로, 이분 검색 함수는 bsearch가 당당히 표준으로 등재돼 있지만, 그에 상응하는 선형 검색 함수는 표준이 아니어서 그런지 _lfind이다.

3. 스택 메모리의 임의 할당

그러고 보니 비표준 함수 중에는.. malloc의 변종으로서 가변 길이(= 크기가 런타임 때 정해지는) 메모리를 heap이 아닌 무려 현재의 스택 메모리에서 얻어 오는 alloca이던가 malloca인가 하는 물건도 있었다. 옛날 16비트 Turbo C에만 있는 줄 알았는데 현재의 Visual C++에서도 지원은 하는가 보다. 물론 앞에 밑줄은 붙여서 말이다.

얘는 C에서 문법적으로 가능하지 않은 동적 배열을 heap이 아닌 스택 메모리에 구현해 준다. 메모리 할당 속도가 heap을 다루는 것보다 훨씬 더 빠르며, 함수 실행이나 scope이 끝날 때 해제도 자동으로 되어 memory leak 걱정을 할 필요 없으니 편리하다. 지금 실행 중인 함수의 stack frame을 조작하는 물건이니, 겉으로는 함수 호출 같지만 실제로는 컴파일러 인트린식 형태로 구현되지 싶다.

이렇게 생각하면 얘는 장점이 많아 보이지만.. 일단 할당 장소가 장소인 관계로 (1) 수 MB 이상급의 대용량 메모리를 할당할 수 없으며, (2) 할당 방식의 특성상 heap 메모리처럼 할당과 해제를 무순으로 임의로 자유자재로 할 수 없다. (3) C++ 언어의 보조를 받는 게 없기 때문에 해제와 C++ 객체 소멸을 한데 연계할 수도 없다.

이런 한계로 인해 스택에서의 동적 메모리 할당은 생각만치 그렇게 유용하지 않다. 본인도 지난 20여 년 동안 C/C++ 프로그래밍을 하면서 이걸 전혀 사용해 본 적이 전혀에 가깝게 없었다.
저 함수가 괜히 비표준이 아닌 셈이다. 마치 정수 기반 고정소수점과 비슷한 위상의 이단아인 것 같다. 다만, 그럼에도 불구하고 본인은 이런 상황은 어떨까 하는 생각을 해 보았다.

생성자에서 문자열을 인자로 받아들여 적절한 처리를 하는 기반 클래스가 있다.
이걸 상속받아 파생 클래스가 만들어졌는데, 얘는 자주 쓰이는 문자열 패턴을 손쉽게 생성하기 위해 여러 개의 문자열이나 숫자를 숫자를 인자로 받으며, 이로부터 단일 문자열을 생성하여 기반 클래스의 생성자에다가 전달한다. 즉, 이런 꼴이다.

Derived::Derived(string arg1, string arg2, int num):
 Base( prepareArgument(arg1, arg2, num) ) {}

예시를 보이기 위해 편의상 string이라는 자료형을 썼지만, 실제로 저기서 쓰이는 것은 const char * 같은 문자열 포인터이다.
즉, 나는 Derived의 생성자에서 char buf[128] 같은 스택 기반 지역변수 배열을 선언한 뒤, 거기에다 arg1, arg2, num의 정보를 담고 있는 문자열을 담고 그걸 Base의 생성자에다가 전달하고 싶으나.. 문법 구조상 그건 가능하지 않다. 기반 클래스는 파생 클래스의 생성자가 실행되기 전에 초기화가 완료돼야 하기 때문이다. 그러니 파생 클래스의 생성자 함수에서 확보해 놓은 스택 변수의 공간을 받을 방법도 존재하지 않는다.

이럴 때 prepareArgument(_alloca(len), arg1, arg2, num) 이런 식으로 static한 보조 함수를 만들면 굳이 힙 메모리 할당과 생성자· 소멸자가 뒤따르는 범용 string을 쓸 필요 없이 스택에다가 문자열을 담을 공간을 임시로 확보하여 소기의 목적을 달성할 수 있을 것으로 보인다.

4. 쓰레기값

'초기화되지 않은 변수, 쓰레기값'이라는 건 내가 아는 프로그래밍 언어들 중에는 C/C++에만 존재하는 개념이다. 물론 컴퓨터라는 기계에 본질적으로 존재하니까 C/C++에도 존재하는 것이지만 말이다.
이것 때문에 야기되는 버그의 황당함과 막장스러움은 뭐, 이루 말로 형용할 수 없다. 같은 소스 코드가 release 빌드와 debug 빌드의 실행 결과가 달라지는 건 애교 수준이다. 프로그램이 미묘하게 삑사리가 나고 있어서 몇 시간을 끙끙대며 디버깅을 했는데 원인이 고작 이것 때문인 일이 비일비재하다.

개인적으로는 부모 클래스의 멤버가 초기화되지 않았는데 그걸 자식 클래스에서도 초기화하지 않은 것, 처음에는 0 초기화가 보장되는 static 영역에 있던 오브젝트를 별 생각 없이 스택/힙으로 옮긴 것, 심지어 한 멤버를 초기화할 때 아직 초기화되지 않은 다른 멤버를 참조해서 망한 것이 기억에 남아 있다.

간단한 int 지역변수가 초기화되지 않은 건 컴파일러 차원에서 잡아 주지만 위와 같은 사항들, 복잡한 구조체의 멤버가 일부 초기화되지 않는 것, 스택이 아닌 힙에서 할당하는 동적 메모리가 돌아가는 사정은 컴파일러도 일일이 다 챙겨 주지 못하기 때문에 더 복잡한 정적 분석의 영역으로 가야 한다.

그런데 개인적으로 의문이 드는 건 초기화되지 않은 쓰레기값이란 건 어느 정도로 무질서하냐는 것이다. 무슨 수학적으로 균일한 난수 수준일 리는 없을 것이다.
그 쓰레기들의 값에 영향을 주는 것은 정확하게 무엇일까? (스택이냐 힙이냐에 따라 다르게 생각해야 할 듯) 컴파일 시점에서 결정되어서 한번 빌드된 프로그램은 동일한 동작 조건에서는 불변인 걸까? 혹은 운영체제에 따라 달라질 수 있을까?

마치 중간값 피벗 기반의 퀵 정렬이 최고 시간 복잡도가 나오게 공격하는 방법을 연구하는 것처럼 저것도 뭔가 컴퓨터공학적인 고찰이 필요한 의문인 것 같다.

5. 메모리 주소의 align 문제

"어..? 구조체의 크기가 왜 각 구조체 멤버들의 크기의 합보다 더 크지? 컴파일러의 버그인가?"
본인이 이렇게 크게 놀랐던 게 벌써 20여 년 전, 고딩 시절에 도스용 DJGPP를 갖고 놀던 때였다.
그때는 지금 같은 구글 검색도 없고 네이버 지식인도 없고.. 이런 시시콜콜한 이슈를 다루는 C언어 서적도 없었으니, 궁금하면 물어 볼 만한 곳이 PC 통신 프로그래밍 관련 동호회 게시판밖에 없었다.

메모리 취급에 매우 관대한 x86 물에서만 놀던 사람이라면 word align이라는 개념이 더욱 생소할 수밖에 없다. 더구나 그 경계에 맞지 않은 단위로 메모리 접근을 시도할 경우, CPU가 귀찮아서 예외까지 날린다면??
본인은 포팅이라는 걸 할 때 word align을 조심해야 한다는 것을 머리로는 들어서 알았지만 그 문제를 회사에서야 실제로 겪었다.

이제 네이티브 코드는 반드시 ARM64 기반으로 빌드해야 하니 해당 부분을 64비트로 다시 빌드했다. 그런데 동일한 엔진을 얹은 안드로이드 앱이 어떤 기기에서는 잘 돌아갔는데 다른 기기에서는 뻗었다.
죽은 지점이 어딘지는 stack dump를 통해 알아낼 수 있었지만 거기는 null pointer, buffer overflow 등 그 어떤 통상적인 메모리 문제가 발생할 여지도 없는 곳이었다.

알고 보니 거기는 파일 형태로 기록하는 조밀한 버퍼에다 wcsncpy( reinterpret_cast<wchar_t*>(buf+1), str, len) 이런 짓을 하고 있었으며, 타겟 포인터가 한눈에 보기에도 wchar_t의 크기 대비 word align이 되어 있지 않았다(buf 는 char* ㄲㄲㄲ).
그래서 wcsncpy를 memcpy로 교체함으로써 문제를 해결할 수 있었다. wchar_t는 long과 더불어 포팅을 어렵게 하는 주범이며, reinterpret_cast는 align과 관련된 잠재적 위험성을 발견하는 용도로도 쓰일 수 있다는 점을 알게 됐다.

복잡한 포인터 메모리 조작 코드에서 잠재적인 align 문제를 잡아내는 건 사람의 디버깅만으로는 한계가 있을 텐데, 정적 분석으로 가능한지 궁금하다. 그리고 반대로 레거시 코드를 돌리기 위해 컴파일러가 성능이 떨어지는 걸 감수하고라도 최소한 뻗지는 않게 align 보정 코드를 집어넣어 주는 옵션도 있을 텐데 그것도 궁금해진다.

6. 32비트 단위 문자열

C/C++에서 wchar_t 크기의 파편화로 인해 야기된 혼란과 원성이 워낙 장난이 아니었기 때문에 C++11에서는 아예 크기를 직접 명시하고 고정시킨 char16_t와 char32_t라는 자료형이 built-in으로 추가되었다. int는 32비트 시대에 크기가 변했고 long은 64비트 시대에 플랫폼별로 삐걱거리기 시작했다면, wchar_t는 유니코드와 함께 새로 등장하면서 저 지경이 된 셈이다.

개인적으로 인상적인 것은 char32_t는 U""라고 문자열 리터럴을 나타내는 접두사까지 언어 차원에서 새로 등장했다는 점이다. 드디어 확장 평면 문자도 취급하기 더 수월해지겠다.
그런데 그러면 Visual C++이라면 ""는 1바이트, L""는 2바이트, U""는 4바이트라고 자연스럽게 연결되는데, 처음부터 wchar_t가 4바이트였던 맥에서는 L과 U가 모두 4바이트이다. char16_t에 대응하는 2바이트 문자열은 리터럴로 표현하는 방법이 없나 궁금하다. 오히려 Objective C에서 사용하는 NSString의 @""가 2바이트 문자열 리터럴이다.

char32_t가 언어 차원에서 이렇게 지원되기 시작했는데 str*, wcs*처럼 32비트 문자열 버전에 대응하는 strlen, strcpy, sprintf 등도 있어야 하지 않나 싶다. C++이라면 char_traits 템플릿으로 땜빵할 수도 있겠지만 C에는 그런 게 없으니까..
그리고 템플릿이 없는 저쪽 동네 Java는 32비트 단위 문자열을 취급하는 string class 같은 것도 있어야 하지 않을까? 문자 하나도 확장 평면까지 감안해서 얄짤없이 int로 표기하는 건 직관적이지 못하고 불편하니 말이다.

7. 레퍼런스 사이트

C/C++은 마소의 C#, 애플의 Swift, 썬-오라클의 Java처럼 한 기업이 주도해서 개발하는 언어가 아니다. 그래서 C++ 라이브러리 레퍼런스 같은 걸 검색해도 딱 떨어지는 개발사의 홈페이지가 곧장 나오지는 않는다.
하지만 수 년 전부터 구글 검색에서 상위권으로 노출되고 있는 유명한 사이트는 아래의 딱 두 곳인 것 같다.

http://www.cplusplus.com
https://en.cppreference.com/w

얘들은 개인? 단체? 어디서 운영하는지 모르겠다. C++17, C++20 같은 최신 정보도 곧장 올라오는 걸 보니 유지보수도 활발히 되고 있고 만만하게 볼 퀄리티가 아니다.
마치 Doom 게임 관련 자료를 듬뿍 얻을 수 있는 위키 사이트가 doomwiki와 doom.fandom.com 요 두 계열로 나뉘듯이 말이다.

Posted by 사무엘

2019/11/13 08:33 2019/11/13 08:33
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1683

1. 스마트 포인터의 필요성

C/C++에서 포인터로 참조하는 동적 메모리가 안전하게 관리되기 위해서는.. 가장 간단하게는 포인터의 생명 주기와 그 포인터가 가리키는 메모리 실체의 생명 주기가 동일하게 유지돼야 할 것이다. 어느 한쪽이 소멸되면 다른 쪽도 소멸돼야 한다. C++에서는 이 정도 절차는 포인터를 클래스로 감싸고 그 클래스의 생성자와 소멸자 함수를 구현함으로써 자동화할 수 있다.

하지만 이것만으로 문제가 다 해결되는 건 아니다. 어떤 메모리에 대한 포인터의 ownership이 더 깔끔하게 관리되고 통제돼야 한다. 멀쩡한 주소값이 딴 걸로 바뀌어서 원래 가리키던 메모리로 접근 불가능해지거나(leak..), 이미 해제된 메모리를 계속 가리키고 있다가 사고가 나는 일도 없어야 한다.

그런 일을 예방하려면 여러 포인터가 동일 메모리를 참조하는 것을 완전히 금지하고 막든가, 아니면 reference count 같은 걸 따로 둬서 그런 상황에 대비를 해야 한다. 실행시켰을 때 뻑이 날 만한 짓은 아예 컴파일이 되지 않고 거부되게 해야 한다.
이런 메모리 관리를 자동으로 해 주는 클래스가 표준 C++ 라이브러리에도 물론 구현돼 있으며, 크게 두 가지 관점에서 존재한다.

  • 배열 지향: POD 또는 비교적 단순한 오브젝트들의 동적 배열로, 원소들의 순회, 추가· 삭제와 전체 버퍼 재할당 같은 동작에 최적화돼 있다. 원소 전체 개수와 메모리 할당량 정보가 별도로 들어 있으며, 문자열 클래스도 어찌 보면 배열의 특수한 형태라고 간주할 수 있다. [] 연산자가 오버로딩 돼 있다.
  • 오브젝트 지향: 단일 오브젝트 중심으로 메모리 할당 크기보다는 소유자(ownership) 관리에 더 최적화돼 있다. 그래서 구현 방식에 따라서는 원소 개수 대신 레퍼런스 카운트 정보가 있곤 한다. 담고 있는 타입 형태로 곧장 활용 가능하게 하기 위해, ->와 * 같은 연산자가 반드시 오버로딩 돼 있다.

C/C++은 배열과 포인터의 구분이 애매하니 helper class는 각 분야에 특화된 형태로 따로 구현되었다는 것을 알 수 있다.
배열 버전이야 std::vector라는 유명한 클래스가 있고, 오브젝트를 담당하는 물건을 우리는 smart pointer라는 이름으로 오랫동안 불러 왔다.

Windows 진영에서도 ATL 내지 WTL 라이브러리에는 일반 포인터뿐만 아니라 COM 인터페이스를 감싸서 소멸자에서 Release를 해 주고, 대입 연산자 및 복사 생성자에서 AddRef 따위 처리를 해 주는 간단한 클래스가 물론 있었다.
소멸자는 예외 처리가 섞여 있을 때 더욱 빛을 발한다. 함수의 실행이 종료되는 경로가 여럿 존재하게 됐을 때 goto문을 안 쓰고도 메모리 단속이 꼼꼼하게 되는 것을 언어와 컴파일러 차원에서 보장해 주기 때문이다. 그리고 이 정도 물건은 C++ 좀 다루는 프로그래머라면 아무라도 생각해 내고 구현할 수 있다.

2. 초창기에 도입됐던 auto_ptr과 그 한계

C++은 이런 스마트 포인터도 표준화하려 했으며, 그 결과로 auto_ptr이라는 클래스가 C++98 때부터 도입됐다. 선언된 헤더는 #include <memory>이다.
그러나 auto_ptr는 오늘날의 최신 C++의 관점에서 봤을 때는 썩 좋지 못한 설계 형태로 인해 deprecate됐다. 이미 이걸 사용해서 작성돼 버린 레거시 코드를 실행하는 것 외의 용도로는 사용이 더 권장되거나 지원되지 않게 되었다.

그 대신, C++11부터는 용도를 세분화한 unique_ptr, shared_ptr, weak_ptr이라는 대체제가 등장했다. 이거 마치 C-style cast와 C++ *_cast 4종류 형변환의 관계처럼 보이지 않는가? =_=;;

auto_ptr은 한 메모리를 오직 한 포인터만이 참조하도록 하고 포인터가 사라질 때 소멸자도 호출해 주는 최소한의 기본 조치는 잘 해 줬었다. auto_ptr<T> ptr(new T(arg1, ...)) 같은 꼴로 선언해서 사용하면 됐다. 하지만...

(1) 단일 포인터와 배열의 구분이 없었다.
물론 스마트 포인터는 전문적인 배열 컨테이너 클래스와는 용도가 다르니, 원소의 삽입· 삭제나 원소 개수 관리, 메모리 재할당 처리까지 할 필요는 없다.

하지만 클래스의 소멸자에서 호출해 주는 clean-up을 별도의 템플릿 인자로 추상화하지는 않았고 그냥 delete ptr로 고정해 놓았기 때문에.. 당장 delete와 delete[]조차도 구분할 수 없어서 번거로웠다. 다시 말해 auto_ptr<T> ptr(new T[100]) 이런 식으로 써먹을 수는 없다.

(2) 포인터의 ownership을 관리하는 것까지는 좋으나.. 그게 복사 생성자 내지 대입 연산자에서 우항 피연산자를 변조하는 꽤 기괴한 형태로 구현돼 있었다.
무슨 말이냐 하면.. auto_ptr<T> a(ptr), b에서 b=a 또는 b(a)라고 써 주면.. b는 a가 가리키는 값으로 바뀜과 동시에 a가 가리키는 값은 NULL로 바뀌었다. 즉, 포인터와 메모리의 일대일 관계를 유지시키기 위해, 소유권은 언제나 복사되는 게 아니라 이동되게 한 것이다.

그렇게 구현한 심정은 이해가 되지만, 대입 연산에서 A=B라고 하면 A만 변경되어야지, B가 바뀌는 건 좀 납득이 어렵다.
복사 생성자라는 것도 형태가 T::T(const T&)이지, T::T(T&)는 아니다. 차라리 임시 객체만 받는 R-value 이동 전용 생성자라면 T::T(T&&)이어서 우항의 변조가 허용되지만, 복사 생성자는 그런 용도가 아니다.

(3) 위와 같은 특성이랄지 문제로 인해.. auto_ptr은 call-by-value 형태로 함수의 인자나 리턴값으로 그대로 전달했다간 큰일 났다.
메모리의 소유권이 호출된 함수의 인자로 완전히 옮겨져 버리고, 그 함수가 끝날 때 그 메모리는 auto_ptr의 소멸자에 의해 해제돼 버리기 때문이다. 이 문제를 컴파일러 차원에서 잡아낼 수 없다. (뭐, 이미 free된 메모리를 이중으로 해제시키는 사고는 나지 않는다. 깔끔한 null pointer 접근 에러가 날 뿐.)

auto_ptr을 함수 인자로 전달하려면 그냥 call-by-reference로 하든가, 아니면 그 원래의 T* raw 포인터 형태로 전해야 했다.
아니, 함수 인자뿐만 아니라 값을 그대로 함수의 리턴값으로 전할 때, 혹은 vector 및 list 같은 컨테이너에다 집어넣을 때 등.. 임시 객체가 발생할 만한 모든 상황에서 동일한 문제가 발생하게 된다.

이게 제일 치명적이고 심각한 문제이다. 여러 함수를 드나들고 컨테이너에다 집어넣는 것도 raw pointer와 다를 바 없이 가볍게 되라고 smart pointer를 만들었는데 그러지 못한다면.. 이걸 만든 의미가 없다. 그러면 한 함수 안에서 달랑 소멸자 호출만 자동화해 주는 것 말고는 쓸모가 없다.
또한, 매번 call-by-reference로 전하는 건 엄밀히 말해 포인터의 포인터.. 즉, 포인터를 정수가 아니라 구조체 같은 덩치 큰 물건으로 취급하는 거나 마찬가지이고..

이런 이유로 인해 auto_ptr은 좋은 취지로 도입됐음에도 불구하고, 현재는 이런 게 있었다는 것만 알고 최신 C++에서는 잊어버려야 할 물건이 됐다.
(1) C 라이브러리 함수라든가(gets...) (2) C++ 키워드뿐만 아니라(export) (3) C++ 라이브러리 클래스 중에서도 흑역사가 생긴 셈이다.

auto_ptr이 무슨 보안상의 결함이 있다거나 성능 오버헤드가 크다거나 한 건 아니다. 21세기 이전에는 C++에 R-value 참조자 같은 문법이 없었으니 복사 생성자에다가 move 기능을 집어넣을 수밖에 없었다. 나중에 C++에 언어 차원에서 smart pointer의 불편을 해소해 주는 기능이 추가된 뒤에도 이미 만들어진 클래스의 문법이나 동작을 변경할 수는 없으니 새 클래스를 따로 만들게 된 것일 뿐이다.

3. unique_ptr

auto_ptr의 가장 직접적인 대체제는 unique_ptr이다.
얘는 최신 C++에서 새로 추가된 문법을 활용하여 단일 개체와 배열 개체를 구분할 수 있다. unique_ptr<T>와 unique_ptr<T []>로 말이다. 신기하다..;;
그리고 템플릿 가변 인자 문법을 이용하여 new를 생략하고 std::make_unique<T>(arg1, arg2..) 이렇게 객체를 생성할 수도 있다. 얘는 C++14에서야 도입된 더 새로운 물건이다.

unique_ptr은.. 말 많고 탈 많던 복사 생성자와 대입 연산자가 막혀 있다. 함수에 날것 형태로 전달하거나 컨테이너에 집어넣는 등의 시도를 하면.. 그냥 컴파일 에러가 나게 된다. 그래서 안전하다.
이전의 auto_ptr이 하던 것처럼 소유권을 옮기는 것은 R-value 이동 생성자라든가 std::move 같은 다른 방법으로 하면 된다.

어떤 클래스에 대해서 복사 생성자와 대입 연산자가 구현돼 있지 않으면 컴파일러가 디폴트, trivial 구현을 자동 생성하는 편이다. 각 멤버들에 대한 memcpy 신공 내지 대입 연산자 호출처럼 해야 할 일이 비교적 직관적으로 뻔히 유추 가능하기 때문이다. 하지만 클래스에 따라서는 그런 오지랖이나 유도리가 바람직하지 않으며 이를 금지해야 할 때가 있다. 인스턴스가 단 하나만 존재해야 하는 singleton 클래스, 또는 저렇게 반드시 1핸들, 1리소스 원칙을 유지해야 하는 클래스를 구현할 때 말이다.

그걸 금지하는 가장 전형적이고 전통적인 테크닉은 해당 함수를 private으로 선언해 버리는 것이 있다. (정의는 당연히 하지 말고)
하지만 이것도 friend 함수에서는 안 통하는 한계가 있기 때문에 최신 C++에서는 액세스 등급과 별개로 상속 받았거나 디폴트 구현된 멤버 함수의 사용을 그냥 무조건적으로 금지해 버리는.. = delete라는 문법이 추가되었다. 순수 가상 함수를 나타내는 = 0처럼 말이다! unique_ptr은 이 문법을 사용하고 있다.

그럼 unique_ptr은 컨테이너에 집어넣는 게 전혀 불가능한가 하면.. 그렇지 않다.

vector<unique_ptr<T> > lc;
lc.push_back( unique_ptr<T>(new T) );

처럼 push_back이나 insert에다가 T에 속하는 변수를 줄 게 아니라 저렇게 애초부터 R-value 임시 객체를 주면 된다.
그러면 임시 객체의 ownership이 컨테이너 안으로 자연스럽게 옮겨지고, 컨테이너 안의 unique_ptr만이 유일하게 T를 가리키고 있게 된다.

얘는 auto_ptr보다 상황이 훨씬 더 나아졌고 이제 좀 쓸 만한 smart pointer가 된 것 같다.
사실, 작명 센스조차도.. auto는 도대체 뭘 자동으로 처리해 준다는 건지 좀 막연한 구석이 있었다. 그게 unique/shared로 바뀐 것은 마치 '인공지능'이라는 막연한 용어가 AI 암흑기를 거친 후에 분야별로 더 구체적인 기계학습/패턴인식 같은 말로 바뀐 것과 비슷하게 들리기도 한다. ㅎㅎ

4. shared_ptr와 weak_ptr

그럼 다음으로, shared_ptr을 살펴보자.
얘는 마치 COM의 IUnknown 인터페이스처럼 reference counting을 통해 다수의 포인터가 한 메모리를 참조하는 것에 대한 대비가 돼 있다. 그래서 unique_ptr과 달리, 대입이나 복사를 자유롭게 할 수 있다.

(1) 날포인터는 그냥 대책 없이 허용하기 때문에 ownership 문제가 발생하고.. 아까 (2) auto_ptr은 무조건 ownership을 옮겨 버리고, (3) unique_ptr은 깔끔하게 금지하는데 (4) 얘는 참조 횟수를 관리하면서 허용한다는 차이가 있다. 소멸자는 가리키는 놈의 reference count를 1 감소시켜서 그게 0이 됐을 때만 실제로 메모리를 해제한다.

그래서 shared_ptr은 크기 오버헤드가 좀 있다.
unique_ptr은 일반 포인터 하나와 동일한 크기이고 기술적으로 machine word 하나와 다를 바 없는 반면, shared_ptr은 reference count 데이터를 가리키는 포인터를 추가로 갖고 있다. 일반 포인터 두 개 크기를 차지한다.

이는 static_cast보다 dynamic_cast가 오버헤드가 더 큰 것과 비슷한 모습 같다. 그리고 멤버 포인터가 다중 상속 하에서의 this 오프셋 보정 때문에 추가 정보를 갖고 있다면, 얘는 ownership 관리 때문에 추가 정보를 갖고 있다는 점이 비교된다.

끝으로, weak_ptr이라고, shared_ptr로부터 얻어 올 수 있는 포인터도 있다. 얘는 이름에서 유추할 수 있듯이 reference count를 건드리지 않으며 소멸자에서도 아무 처리를 하지 않는 포인터.. 즉 일반 포인터와 차이가 사실상 없는 물건이다. 순환 참조 문제를 예방하려면 A에서 B를 참조한 뒤에 B에서 또 A를 참조할 때는 레퍼런스 카운트를 건드리지 않아야 하기 때문이다.

그런데도 일반 포인터 대신 굳이 이런 자매품도 따로 만든 이유는 언어 차원에서의 무결성 보장처럼 for the sake of completeness 때문으로 보인다. 무결성 보장이란 게 무슨 말인지 예를 들자면, weak_ptr은 가리키는 주소가 반드시 shared_ptr로부터 유래되었고, unique_ptr과는 절대 섞이지 않는다는 것 말이다.

물론 COM 인터페이스도 아니고 일반 포인터에서 굳이 weak_ptr이 필요할 정도로 극단적인 상황은 현실에서는 거의 없을 것이다. 상상조차 잘 안 된다. 포인터 A가 다른 클래스 B를 가리키는데, 그 클래스 B 내부에 포인터 A가 소속된 다른 객체를 가리키는 포인터가 들어 있다던가.. 뭐 그런 상황 정도이다.
다만, 순환 참조는 단순히 A→B→A뿐만 아니라 A→B→C→A 같은 더 복잡한 형태로도 발생하고, 일단 발생한 것을 감지하기란 몹시 난감하다. 그러니 weak_ptr이라는 개념 자체는 반드시 필요하다.

이상이다. 그냥 생성자와 소멸자를 적절히 구현해 주고 ->와 *만 오버로딩 해 주면 끝일 것 같은 smart pointer도 깊게 들어가면 내막이 생각보다 더 복잡하다는 것을 알 수 있다.
Rust 언어는 garbage collector 기반이 아니면서 더 독특한 방식으로 메모리 소유권을 관리한다던데 그 내막이 어떠했던지가 다시 궁금해진다.

5. 여담

(1) = delete는 다시 봐도 참신하기 그지없다. delete라는 키워드가 연산자 말고 이런 용도로도 활용되는 날이 오더니!
배열 첨자 연산자이던 []와 구조체 참조 연산자이던 ->가 람다 선언에서 의미가 완전히 확장된 것만큼이나 참신하다.
하긴, 옛날에 템플릿이 처음 등장했을 때.. 그저 비교 연산자일 뿐이었던 <와 >가 완전히 새로운 여닫는 형태로 사용되기 시작한 것도 정말 충격적인 변화였을 것이다.

(2) 글쎄, 멤버 함수의 접근을 금지하는 방법이 저렇게 도입됐는데, 어떤 클래스에 대해서 Java의 final이나 C#의 sealed처럼 상속이 더 되지 않게 하는 옵션은 C++에 도입되지 않으려나 모르겠다. C++은 타 언어에 없는 protected, private 상속이 존재하지만 상속 자체를 금지하는 옵션은 없어서 말이다.

특히 내부 구조가 아주 간단하고 가상 함수가 존재하지 않는 것, 특히 소멸자가 가상 함수 형태로 별도로 선언되지 않은 클래스는 상속을 해도 어차피 polymorphism을 제대로 살릴 수 없다. 그냥 단순 기능 확장에만 의미를 둬야 할 것이다.
Java는 모든 함수가 기본적으로 가상 함수일 정도로 유연한데도 이와 별개로 상속을 금지하는 옵션이 있는데.. 그보다 더 경직된 언어인 C++은 의외로 그런 기능이 없다.

(3) C/C++의 사고방식에 익숙한 프로그래머라면 포인터란 곧 메모리 주소이고, 본질적으로 machine word와 동일한 크기의 부호 없는 정수 하나일 뿐이라는 편견 아닌 편견을 갖고 있다.
하지만 객체지향이라든가 함수형 등 프로그래밍 언어 이론을 조금이라도 제대로 구현하려면 숫자 하나만으로 모든 것을 표현하기엔 부족한 포인터가 얼마든지 등장하게 된다.

앞서 다뤘던 shared_ptr이라든가 다중 상속을 지원하는 멤버 함수 포인터..
그리고 자기를 감싸는 문맥 정보가 담긴 클래스 객체 포인터라든가 람다 함수 포인터 말이다.
C++은 전자를 기본 지원하지 않기 때문에 모든 클래스들이 Java 용어로 치면 개념적으로 static class인 거나 마찬가지이다.
그리고 후자를 기본 지원하지 않기 때문에 람다는 캡처가 없는 놈만 기존 함수 포인터에다 담을 수 있다.

그런 것들이 내부적으로 어떻게 구현되고 구현하는 시공간 비용이 어찌 되는지를 프로그래머라면 한 번쯤 생각할 필요가 있어 보인다.

(4) C++에서 class T; struct V; 처럼 이름만 전방 선언된 incomplete type에 대해서는 제일 단순한 직통 포인터, 그리고 무리수가 좀 들어간 멤버 포인터 정도만 선언할 수 있다. T나 V의 실체를 모르니 이런 타입의 개체를 생성하거나, 포인터를 실제로 참조해서 뭔가를 할 수는 없다.
그런데 이런 불완전한 타입을 가리키는 포인터를 상대로 delete는 가능할까? 난 이런 상황에 대해 지금까지 한 번도 생각해 본 적이 없었다.

sizeof(T)의 값을 모르더라도 포인터가 가리키는 heap 메모리 블록을 free하는 것은 얼마든지 가능하다. 애초에 malloc/void가 취급하는 것도 아무런 타입 정보가 없는 void*이니 말이다.
그러니 operator delete(ptr)은 할 수 있지만, 해당 타입에 대한 소멸자 함수는 호출되지 못한다.

컴파일러는 이런 코드에 대해서 경고를 띄우는 편이다. Visual C++의 경우 C4510이며, delete뿐만 아니라 delete[]에 대해서도 동일한 정책이 적용된다.

Posted by 사무엘

2019/10/09 08:35 2019/10/09 08:35
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1671

1. ? :에서 피연산자의 타입 동기화 방식

C/C++에서 포인터는 컴퓨터가 내부적으로 메모리를 다루는 메커니즘을 아무 보정 오버헤드 없이 쌩으로 노출하고 관리를 프로그래머에게 전적으로 맡기는 물건이다. 그러니 강력한 대신 매우 위험하기도 하며, 사용자의 실수가 들어가기 쉽다.

이런 한계를 극복하기 위해 C++에는 생성자와 소멸자, 템플릿, 연산자 오버로딩을 적극 활용하여 다양한 형태로 포인터를 컴파일 시점에서 자동 관리해 주는 클래스가 존재한다. 소멸자에서 자신에 대한 delete 내지 Release를 자동으로 클래스가 있으면 한결 편할 것이다. 대입도 기존 오브젝트가 없어지고 다른 걸로 대체되는 거나 마찬가지이니, 레퍼런스 카운팅 관리 같은 걸 해 주고 말이다.

함수가 실행이 실패해서 도중에 return을 해야 하는데 지금까지 할당했던 자원(메모리, 파일)들을 반환은 해야 하니.. 부득이하게 goto문을 쓰느라 코드가 지저분해지는 거 공감하실 것이다. 이런 간단한 것 하나만 생각해도 C++이 C에 비해 코딩을 얼마나 더 편리하게 해 주는지 알 수 있다.

본인은 날포인터를 써서 만들어졌던 옛날 코드를 그런 wrapper 클래스 형태로 리팩터링 했다. 가령, FOO *p = .... p->Release() 하던 것을 CAutoPtr<FOO> p 하나로 대체하는 식이다. 자원을 수동으로 해제하는 코드를 최대한 줄였다.

그런데 하루는 큰 문제 없이 이렇게 고쳐지고 컴파일 됐던 프로그램이 도저히 이해되지 않는 부분에서 뻗는 걸 발견했다.
한참을 디버깅한 끝에 알고 보니... 문제는 A ? B: C 연산자 안이었다. 원래 B와 C 모두 FOO* 타입인데, B만 CAutoPtr<FOO>로 바뀌었던 것이다. 다른쪽 C는 구조체의 멤버이다 보니 타입을 고칠 수 없었고 말이다.

내가 의도한 건 B가 operator FOO*()를 통해 FOO*로 암묵적으로 형변환되는 것이었다. 이 ? : 식은 함수의 인자로 전달되는 문맥에서 쓰였으며, 이 인자의 타입도 그냥 FOO*였다.
그러나 이때 B와 C의 타입을 동기화하기 위해 컴파일러가 한 일은.. CAutoPtr<FOO>(C), 다시 말해 C를 CAutoPtr로 승격시키고 임시 객체를 생성하는 것이었다. 그러고 나서는 그 CAutoPtr에 대해서 역으로 operator FOO*()를 호출하여 리턴값을 함수에다 전달했다.

이 클래스는 생성자에서는 딱히 하는 일 없이 인자로 주어진 메모리 주소를 대입만 하고, 소멸자에서 그 주소가 가리키는 영역을 해제했다.
그러니 임시 객체는 소멸자에서 멀쩡한 메모리를 예기치 않게 해제했으며, 이 부작용 때문에 프로그램이 죽은 것이었다. 아하, 이런 내막이 있었다니... 무릎을 쳤다.

그런데 이 문제를 깔끔하게 해결할 방법은 없는지 본인의 C++ 지식 범위에서는 답이 떠오르지 않는다. 이때는 부득이하게, B에다가 static_cast, (FOO*), operator FOO*() 같은 명시적 형변환을 지저분하게 집어넣어 줘야만 하는 걸까? (리팩터링 전에 날포인터만 쓰던 시절에는 할 필요 없던..)

아니면 CAutoPtr의 생성자를 어째 잘 만들어서 저런 형변환을 허용하지 않고 최소한 에러로 처리시킬 방법이라도 없나 궁금하다. 암시적인 R-value 임시 객체가 생기는 것만 금지하고 막으면 될 거 같은데..??
explicit을 지정하는 것만으로는 충분치 않고, 복사 생성자나 R-value 생성자 같은 걸 어설프게 건드리면 정상적인 객체 생성에 대해서도 에러가 발생하게 되더라.

FOO*를 받아들이는 상황에서도 컴파일러가 B와 C를 모두 일단 클래스로 만든 뒤에 다시 operator FOO*를 호출하는 것은 일종의 언어 차원에서의 디자인 원칙인 것 같다. C++이 함수 오버로딩도 인자의 개수와 타입만으로 판단하지, 리턴값의 타입은 전혀 감안하지 않는 것처럼 말이다. 일을 단순하게 만들기 위해 수식 내부의 토큰을 해석하는 데 수식 바깥 전체의 타입을 굳이 고려하지는 않기로 한 듯하다.

또한, template<T> void Foo(T, T) 이런 함수를 선언한 뒤, 템플릿 인자 없이 함수의 두 인자에다가 CAutoPtr<FOO>와 FOO*를 집어넣는 것은 통하지 않더라. 컴파일러가 어설프게 타입 유추와 동기화를 시도하지 않고 깔끔하게 에러를 내뱉었다. Foo<FOO*> 이렇게 T가 무엇인지를 명시적으로 써 줘야 했다. ? :와는 다른 동작으로 보인다.

? : 연산자에 대해서 본인은 먼 옛날에 대입 연산과 관련된 파싱 방식이 이해되지 않는 게 있어서 글을 쓴 적이 있는데.. 이번엔 다른 분야에서 알쏭달쏭한 게 생겼다. 흥미롭다.

A ? B:C에서 둘 중 하나가 기반 클래스이고 다른 하나가 파생 클래스라면, 이 수식의 결과값이 지칭하는 타입은 B와 C 어느 것이 걸리건 무관하게 당연히 더 범용적인 기반 클래스로 결정된다. 그런데 이것도 다중· 가상 상속이 개입하면 굉장히 골치아픈 문제가 될 것 같다. 파생 클래스가 자신의 실질적인 기반 클래스로 돌아가는 게 trivial한 일이 아니게 되기 때문이다.

2. 클래스 static 멤버 함수에서 non-static 멤버의 sizeof 구하기

C++에서 클래스의 static 멤버 함수는 그 정의상 this 포인터를 갖고 있지 않다. 명칭의 scope resolution만 빼면 기술적으로 일반 global 함수와 전혀 다를 바 없다. 그렇기 때문에 이런 함수의 내부에서 클래스의 non-static 멤버는 당연히 참조할 수 없다.

그런데 sizeof 연산자는 어떨까? 얘는 런타임 때의 메모리 값을 전혀 참조하지 않고, 컴파일 타임 때 결정되는 타입만을 기반으로 답을 구해 주는 답정너 연산자이다. 그러니 this 같은 게 전혀 필요하지 않다. 그럼에도 불구하고 아래의 코드는 옛날 컴파일러에서는 에러가 발생하며 컴파일 되지 않는다. (VC++ 기준 C2070 Illegal sizeof operand)

class Sample {
    int MEMB[4]; //일반 타입이건 배열이건 포인터건 모두 무관
public:
    static void Talk() {
        printf("%d\n", sizeof(MEMB));
    }
};

저 안에서 MEMB의 크기를 어떻게든 구하려면?
sizeof( ((Sample*)NULL)->MEMB) 라고 써 줘야 했다. 마치 구조체 내부에서 특정 멤버의 오프셋을 구할 때처럼.. Sample의 포인터를 야메로라도 만들어야 한 것이다.
sizeof의 피연산자는 실제로 실행되지는 않으니 저런다고 프로그램이 뻗지는 않는다. 하지만 미관상 깔끔하지 못하고 부자연스러운 건 어쩔 수 없다.

그런데 2015쯤 Visual C++ 후대 버전에는 sizeof(MEMB)라고 직통으로 요청하는 게 가능해졌다. 그래, sizeof 정도는 static 함수에서라도 non-static 멤버를 피연산자로 삼을 수 있는 게 이치에 맞다.
클래스 밖에서 sizeof(Sample::MEMB)라고 요청해도 된다. 다만, 위의 코드에서는 MEMB가 비공개 멤버이기 때문에 클래스 밖에서는 컴파일 에러가 나게 된다.

흥미로운 점은, VC++ 2010/2012의 경우 빌드용 메인 컴파일러와 인텔리센스용 컴파일러의 동작이 서로 다르다는 것이다.
전자는 저 문법을 지원하지 않고 에러 처리하지만, 인텔리센스 컴파일러는 그걸 인식하는지 코드에 빨간줄을 긋지 않는다. 두 말할 나위 없이 마소에서 자기 컴파일러를 C++ 표준 내지 인텔리센스용 EDG 컴파일러의 동작을 참고하여 추후에 개선한 셈이다.

3. 멤버 함수를 가리키는 템플릿 인자

수 년 전에 본인은 템플릿 인자에 단순 함수 포인터나 functor가 아니라 C++ 멤버 함수도 들어갈 수 있는 걸 발견하고 이게 신기하다고 글을 올린 적이 있다. (☞ 관련 링크)

요약하자면 template<typename T> class Foo에다가는 멤버 변수처럼 T bar를 선언한 뒤,
Foo<int(PCSTR)> f를 선언하고 template<> int Foo<int(PCSTR)>::Bar(PCSTR p) 라고 specialize된 함수 몸체를 정의하면 된다. 그러면 n = f.Bar("kekeke")를 할 수 있다.

그런데.. 이건 역시 너무 사기적이고 사악했는지.. 후대의 컴파일러에서는 지원이 끊기고 봉인됐다.
Visual C++의 경우 딱 2010까지만 지원되며, 2012부터는 C2207 a member of a class template cannot acquire a function type 에러와 함께 컴파일이 거부된다.

그리고 사실은 2010도 인텔리센스 컴파일러는 마소 컴파일러보다 시대를 앞서 갔는지, 이걸 에러로 처리하고 있었다. 단지, 에러가 발생하는 지점이 서로 다르다.
인텔리센스는 template<> int Foo<int (PCSTR)>::bar(PCSTR s) 요렇게 멤버 함수 몸체를 정의하는 부분에서 에러를 찍지만 VC++ 후대 컴파일러는 Foo<int(PCSTR)> obj; 이렇게 템플릿을 찍어내는 과정에서 에러를 찍더라.

템플릿의 인자가 :: 연산자와 함께 다른 명칭의 일부로 들어갔을 때, 그 전체 명칭이 타입명인지 변수명인지가 오락가락 한다는 이유로 typename이라는 키워드가 도입됐다.
그것처럼 템플릿 인자가 non-static한 멤버의 변수가 될 수도 있고 함수도 될 수 있는 건 무질서도가 너무 크긴 하다. static 멤버라면 함수라도 단순 포인터로 간편하게 취급할 수 있지만 non-static 멤버 함수는 그렇지 않으니까..

그러면 저 문법은 완전히 사용 금지됐는지, 아니면 멤버 함수를 템플릿 인자로 전하는 다른 방법이 있는지 그건 잘 모르겠다. 일단 멤버 포인터라는 물건 자체가 워낙 무시무시한 놈이어서 말이다.

4. friend 키워드의 클래스 명칭 인식 방식

어떤 헤더 파일 내부에.. global scope에서 class A가 먼저 선언되었다. 그 다음으로 namespace에 소속된 클래스 B가 선언되었고, B는 내부에서 class A를 friend로 선언했다 (friend class A).
Visual C++은 이 코드에서 우리 namespace에 속하지는 않지만 밖에서 먼저 정의되어 있는 A를 인식했으며, A의 멤버 함수가 B의 비공개 멤버에 접근하는 것을 허용했다.
그러나 xcode, 안드로이드 NDK 등 타 플랫폼의 C++ 컴파일러들은 A를 인식하지 못하고 에러를 내뱉었다.

이 문제의 해결 방법은 간단하다. 그냥 A라고 하지 말고 friend class ::A라고 써 주면 된다.
그럼 Visual C++은 함수 인자의 ADL 같은 것도 아닌 상황에서 왜 유도리를 발휘한 건지 궁금해진다. 심지어 이건 인텔리센스도 동일하게 맞는 문법으로 인정해 줬다.

어떤 클래스 B가 다른 클래스 A를 friend로 선언할 때, A의 명칭은 진짜 아무거나 적어 줘도 된다. friend 선언 당시에 A가 class A; 라고 달랑 전방 선언(forward)만 됐건, 아니면 심지어 전혀 선언되지 않은 듣보잡 이름이어도 된다. friend부터 맺은 뒤에 다음에 A를 선언해도 된다.
단, Visual C++의 경우, 친구 클래스 A를 인식하는 방식에서 다음과 같은 추가적인 특성이 있었다.

  • 앞의 경우처럼 A가 아닌 ::A라고 명시하려면 A는 그 전에 어떤 형태로든 global scope 어딘가에 선언이 돼 있어야 하더라. 그렇지 않으면 Visual C++이라도 에러가 난다.
  • A가 B와 동일한 namespace에 존재한다면 아무 문제 없다. B에서 friend class A만 해 준 뒤, A는 B의 앞에 있건 뒤에 있건 자유롭게 인식 가능하다.
  • A가 그냥 global scope에 있고 B와 동일한 namespace 소속이 아닌데 friend class A만으로 A가 인식되려면 A는 B보다 먼저 선언되어 있어야 한다. 안 그러면 B의 친구는 namespace에 소속돼 있는 가상의 A로 간주되고, ::A는 제외된다.

다시 말해 자신과 다른 namespace 소속의 클래스를 친구로 지목하려면 친구 대상을 반드시 먼저 선언해 주고 :: 연산자도 동원하는 등, 통상적인 friend에 비해 문법에 약간 제약이 걸린다는 걸 알 수 있다. Visual C++은 표준을 따르고 있는 건지는 잘 모르겠지만 그 과정에서 약간 더 유도리를 제공하고 있는 것 같다.

Posted by 사무엘

2019/01/10 08:37 2019/01/10 08:37
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1574

C++에는 using이라고.. class, namespace, template, virtual, operator 이런 것보다는 좀 생소하고 덜 쓰이는 키워드가 있다.
일반적인 프로그래머라면 타이핑 수고를 덜기 위해서 using namespace std; 정도 선언할 때나 사용했던 게 전부일 것이다.

얘는 C의 키워드로 치면 그나마 typedef와 성격이 얼추 비슷해 보인다. typedef는 여러 토큰으로 구성된 복잡한 타입 명칭을 한 단어(식별자) 한 토큰으로 축약해 준다.
타입 명칭이란 건 unsigned long처럼 예약어만으로도 두 단어 이상으로 구성될 수 있으며, 포인터형 *이라든가 const/volatile modifier 등이 붙어서 더욱 복잡해질 수 있다.

그러니 이런 걸 축약하는 기능은 단순히 토큰을 기계적으로 치환하는 #define 전처리기 계층이 아니라 컴파일러 계층에서 반드시 필요하다. 가령, PSTR a, b를 char *a, *b로 자동으로 인식되게 바꾸는 것은 #define만으로는 문법적으로 불가능하기 때문이다. 더구나 함수의 포인터 타입은.. 가리키는 함수가 받아들이는 인자들의 개수와 타입을 일일이 그런 식으로 나열해야 한다~!

C에서는 구조체형 변수를 선언할 때 반드시 struct를 일일이 붙여서 struct ABC 이런 식으로 선언해야 했다. struct를 생략하고 바로 ABC 한 단어만으로 쓰려면 이것조차도 typedef를 해 줘야 됐다.
그러니 C에서는 구조체를 typedef struct _ABC { ... } ABC; 이렇게 두벌일을 하면서 선언하는 게 관행이었으나..

C++에서는 객체지향 이념이 강화되면서 번거롭게 typedef를 안 해도 struct/class를 생략하고 곧바로 그 타입을 쓸 수 있게 됐다. 사실 이게 당연하고 더 자연스러운 조치가 아닌가 생각한다.

뭐 아무튼 typedef는 그런 중요한 역할을 하는 물건이다.
typedef를 통해 새로 만들어진 명칭은 사람이 보기에만 서로 다를 뿐, 컴파일러의 입장에서는 서로 완전히 동치이다. 전문 용어로 표현하자면 syntactic sugar이다.

내부적으로 담고 있는 물건은 동일하지만(똑같은 정수??) 서로 다른 타입으로 취급되어서 명시적인 형변환 없이는 서로 덥석 대입되지 않는 파생 타입.. 이런 걸 생성할 수 있으면 좋을 텐데 C/C++에서는 그게 쉽지 않다.
그러니 unsigned short/int와는 미묘하게 다른 wchar_t 같은 타입은 컴파일러가 언어 차원에서 직통으로 지원해 주지 않으면 사용자가 만들어 내기 난감하다.

그리고 HWND, HMODULE처럼 서로 호환되지 않는 다양한 핸들 타입도 내부적으로는 dummy 구조체의 포인터형을 일일이 typedef하는 편법을 동원해야 선언할 수 있다.
마치 include guard 삽질을 대체하기 위해 #pragma once가 사실상의 표준 형태로 등극한 것처럼.. 저것도 앞으로는 C++ 언어 차원에서 개선되어야 할 점이 아닌가 한다. 정수형에 대해서는 부분적이나마 type safety를 강화하려고 정수와 무작정 호환되지 않는 enum class 같은 것도 2010년대 들어서 도입된 바 있다.

아무튼, typedef는 통상적인 사유로 인해 길어진 type 명칭을 한데 줄이며, 축약된 명칭을 현재의 scope에다 도입해 준다.
그런데 using도 긴 명칭을 줄여 준다는 점에서는 역할이 비슷하다. 단지 그 배경이 typedef와는 완전히 다를 뿐이다.
바로, 지금 문맥과는 다른 namespace에 속한 명칭을 일일이 namespace를 명시하지 않고도 곧장 참조 가능하게 해 준다. 뭐, 개념은 그러하지만 구체적인 세부 문법과 용례는 생각보다 복잡하며, 본인 역시 이를 다 정확하게 알지는 못한다.

using은 크게 선언(declaration)과 지시(directive)라는 두 형태로 나뉘어서 문법적으로 서로 다르게 취급된다. 전자는..

using std::vector;

이런 식으로 구체적인 명칭을 써 주는 형태이다. 위의 경우 이 scope에서는 이제 앞에 std::를 안 붙여도 vector 클래스를 쓸 수 있게 된다. 사용되는 곳이 클래스의 내부라면 굳이 namespace 말고 기반 클래스 같은 타 클래스의 이름이 들어와도 된다.

std::vector를 vector로 줄여 쓰는 것은 기존의 #define이나 typedef로 가능하지 않다. 특히 typedef의 경우,

typedef std::vector<int> vector; //????

템플릿 인자가 모두 주어져서 온전한 type으로 실현된 놈이라면 저렇게 단축 명칭을 부여할 수 있겠지만, 그렇지 않은 추상적인 명칭을 축약하지는 못하기 때문이다. C++의 상속과 연계를 위해 dynamic_cast가 도입된 것처럼, C++에서 도입된 다단계 scope과의 연계를 위해 예전에는 없던 완전히 새로운 명칭 축약 기능이 필요해진 셈이다.

그리고 후자인 using 지시는.. using namespace라는 두 단어로 시작하여 이 namespace에 속하는 모든 명칭들을 곧장 자동 개방해 버린다.
선언이건 지시건 하는 일은 별 차이가 없다. 이것도 그냥 와일드카드에 속하는 ... 이나 * 를 써서 using std::...; 같은 선언으로 통합해 버려도 될 것 같은데, 미관상 보기 안 좋아서 그렇게 안 했나 보다.

물론 일부러 구분해 놓은 걸 당장 쓰기 편하다는 이유로 몽땅 개방해서 내 명칭과 뒤섞어 버리는 건 전역 변수, friend, public의 남발만큼이나 경계해야 할 일이다. 하지만 적절하게 활용하는 건 auto를 쓰는 것만큼이나 코드를 짧고 간결하게 만드는 약이 될 수도 있다.

C++ 표준 라이브러리의 경우 namespace가 도입되기 전 코드와의 호환을 지키기 위해 <iostream.h>는 std로 감싸져 있지 않고, <iostream>은 감싸져 있는 것으로 잘 알려져 있다. 물론 .h 버전은 앞으로 사용을 권하지 않는 deprecated로 철저히 봉인됐고 말이다.

요 두 가지가 using의 전통적인 기능이었다.
그런데 C++11 이후에는 using이 typedef의 기존 기능까지 흡수하여 본격적인 타입 alias 전담 키워드로 등극하기 시작했다. 바로, 등호를 이용해서

using P_INT = int*;
using PF_INT = int (*)();

위와 같이 써 주면 아래의 typedef와 완전히 동치가 된다.

typedef int* P_INT;
typedef int (*P_INT)();

굉장히 참신하다. 새 명칭과 치환 대상 타입이 =를 경계로 딱 분리되어 있다 보니 재래식 typedef보다 깔끔하고 알아보기도 더 쉽다.
using이라는 단어는 파스칼의 use 키워드와 비슷한 느낌이며, using A=B는 파스칼의 type A=B와 뭔가 닮은 것 같다. 또한 이 문법은 namespace에 대한 alias를 만드는 namespace A = B::C 같은 문법과도 일관성이 있다.

Visual C++에서는 한 2013쯤부터 지원되기 시작했다. 2010은 지원 안 하고, 2012는 인텔리센스 컴파일러는 지원하지만 본 컴파일러는 지원하지 않더라.
이름 없는 namespace를 선언해서 C의 static 전역 변수/함수를 표현하듯이, C++의 키워드를 이용해서 기존 C의 기능을 대체하는 예가 하나 더 생겼다. 최신 컴파일러에서는 using을 볼 일이 더 많아지겠다.

Posted by 사무엘

2018/12/15 08:32 2018/12/15 08:32
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1565

우리는 객체지향 프로그래밍 언어를 공부하면서 클래스 멤버들의 공개 등급이라는 개념을 접한다. 까놓고 말해 public, protected, private은 C++, C#, Java에 모두 공통으로 거의 동일한 용도로 쓰이는 키워드이다.

C++은 이런 공개 등급을 마치 case나 default처럼 뒤에다 콜론을 붙여 일종의 label 형태로 지정하지만, Java/C#은 멤버 함수 및 변수의 선언에 공개 등급이 같이 붙는다. 이 세 등급의 차이는 아래 표와 같다.

출처 \ 공개 등급 public protected private
외부 O X X
파생 클래스 내부 O O X
자기 클래스 내부 O O O

public이야 멤버의 접근에 아무 제약이 없는 등급이지만 pr*로 시작하는 나머지 두 등급은 그렇지 않다. 단지, protected는 파생 클래스의 내부에서 자기에게 접근을 허용하는 반면, private은 이마저도 허용하지 않는다. 상속 관계에서부터 둘의 차이가 발생하는 것이다. private은 사람으로 치면 자식에게도 물려주거나 공유하지 않는 개인 칫솔, 속옷, 복용하는 약 같은 급의 지극히 '사쩍'인 물건에다 비유할 수 있겠다.

물론 그 어떤 공개 등급이라도 자기가 선언해 놓고 자기 클래스의 멤버 함수에서도 사용하지 못하는 등급은 없다. 심지어 자기 자신 this뿐만 아니라 자기 클래스에 속하는 아무 객체라도 말이다.
즉, 아래의 코드에서 bar(함수)와 priv_member(변수)가 똑같이 Foo의 멤버라면, bar는 o라는 다른 인스턴스의 priv_member에도 저렇게 마음대로 접근할 수 있다.

void Foo::bar(Foo& o)
{
    priv_member += o.priv_member;
}

this 포인터가 아예 없는 static 멤버 함수도 있다는 점을 생각한다면 이는 당연한 귀결이라 하겠다. 선언은 자기가 했지만, 접근과 사용은 내가 곧장 못 하고 파생 클래스에서만 가능하다거나 하는 기괴한 개념은 없다.

오히려 반대로 부모 클래스에서는 공개였는데 파생 클래스에서는 부모의 멤버를 감추고, 외부에서는 오로지 파생 클래스가 새로 제공하는 public 멤버만 사용 가능하도록 클래스를 더 폐쇄적인 형태로 바꾸는 건 가능하다.

C++에서는 클래스를 상속할 때 별 생각 없이 파생 클래스의 이름 뒤에다 콜론을 찍고 public Base1, public Base2 이런 식으로 public을 붙이곤 한다. 이때 써 주는 공개 등급은.. 부모 클래스 멤버들의 공개 등급이 파생 클래스에서는 어떻게 되는지를 결정한다. 그 방식은 한편으로는 직관적이어 보이면서도 한편으로는 헷갈리고 어렵다.

상속 방식 \ 기존 공개 등급 public protected private
public public protected private
protected protected protected private
private private private private

public 상속은 부모 클래스 멤버들의 공개 등급을 파생 클래스에다가도 원래 지정되었던 형태 그대로 유지시킨다. 부모 때 public이었던 놈은 파생에서도 public, protected는 protected.. 그런 식이다.

그 반면, protected나 private 상속으로 가면 일단 부모 멤버들은 몽땅 private, 또는 잘해야 protected로 등급이 바뀐다. public 속성이 없어지기 때문에 외부에서 파생 클래스 객체를 대상으로 부모 클래스의 멤버에 접근은 할 수 없어진다. public, protected, private이라는 공개 등급을 각각 3, 2, 1이라는 수라고 생각한다면, 클래스를 상속하는 방식 N은 부모 멤버들의 공개 등급을 N보다 크지 않은 등급으로 재설정하는 셈이다.

다른 예로, 부모 클래스에서 protected였던 멤버가 있는데 자식이 부모를 private로 상속했다고 치자. 그러면 그 멤버는 부모에서의 공개 등급은 protected였기 때문에 자식 클래스의 내부에서 마음대로 접근이 가능하다. (참고로 public 멤버는 부모에서 public이었다 하더라도 non-public 상속을 거치면 파생 클래스에서의 외부 접근이 곧장 차단된다. 내부 접근과 외부 접근의 차단 시기가 서로 차이가 있다.)

하지만 private 상속된 protected 멤버는 파생 클래스에서의 등급이 private로 바뀌었다. 그렇기 때문에 얘로부터 상속받은 손자 클래스에서는 이 멤버에 더 접근할 수 없게 된다.
그리고 한번 private/protected 상속으로 인해 작아져 버린 공개 등급은 후속 파생 클래스가 다시 public으로 상속한다고 해서 다시 커지지 않는다. 상속 과정에서 기존 공개 등급을 동일하게 유지하거나 더 낮출 수는 있어도 도로 높일 수는 없다는 뜻이다.

부모 클래스에서 private 상태였던 멤버들은(처음부터 그리 됐든, 상속 방식 때문에 그리 됐든..) public 등 그 어떤 방식으로 상속을 받더라도 파생 클래스에서는 결코 접근할 수 없다. 위의 표에서 그냥 평범하게 private라고 명시된 놈은 현재 private이기 때문에 다음 파생 클래스에서는 감춰진다는 뜻이며, 취소선이 그어져 있는 private은 이미 접근 불가이고 파생 클래스의 입장에서는 그냥 없는 멤버가 됐음을 의미한다.

C++은 언어 차원에서 POD(단순 데이터 더미)와 객체(생성자 소멸자 가상 함수 등..)의 구분이 모호하다 보니, struct와 class의 언어적 구분도 없다시피한 것으로 잘 알려져 있다. 그냥 디폴트로 지정돼 있는 멤버의 공개 등급이 전자는 public이고 후자는 private이라는 차이만이 있을 뿐이다.

그것처럼, 클래스를 상속할 때 공개 등급을 안 쓰고 그냥 class Derived: Base {} 라고만 쓰면 Base는 private 방식으로 상속된다. C++의 세계에서는 디폴트 공개 등급이 어디서든 private인 셈이다.

class 대신 아예 struct Base { private: int a; } 이런 식으로 클래스를 선언해도 된다. 미관상 보기 좋지 않으니까 안 할 뿐이지.
얘는 클래스 선언 문맥에서는 struct라는 대체제가 있고, 템플릿 인자 문맥에서는 typename라는 대체제가 있으니 위상이 뭔가 애매해 보인다. 전자는 C 시절부터 있었던 키워드요, 후자는 C++98에서 추가된 키워드이다.

코딩을 하다 보면 범용적인 부모 클래스의 포인터로부터 자식 클래스로 static_cast 형변환을 하는 경우가 많다. 파생 클래스가 부모보다 멤버가 더 많고 할 수 있는 일도 더 많기 때문이다. 그런데 protected/private 상속을 한 파생 클래스는 자기만의 새로운 멤버/메소드가 있는 한편으로 부모에게 가능한 조작이 금지되어 버린다.

일반적으로 부모와 자식 클래스 관계는 is-a 관계라고 일컬어지고, 자식 포인터에서 부모 포인터로 형변환은 "당연히" 가능한 것으로 여겨지는데.. 그 당연한 건 public 상속일 때만으로 한정이다. 비공개 상속일 때는 정보 은닉을 제대로 보장하기 위해 자식에서 부모로 가는 게 허용되지 않으며, 심지어 static_cast로도 안 된다! Visual C++ 기준 C2243이라는 고유한 에러까지 난다.

기술적으로는, 객체 내부의 ABI 차원에서는 아무 위험할 것이 없음에도 불구하고 전적으로 객체지향 이념에 위배된다는 이유만으로 자식에서 부모로 못 간다. 무리해서 강제로 부모인 것처럼 취급하려면 reinterpret_cast라는 무리수를 동원해야 한다.

게다가 C++은 다중 상속(=가상 상속) 때문에 일이 더 크고 복잡해진다.

class A { public: int pub_mem; };

class B: virtual protected A {};

class C: virtual public A {};

class D: public B, private C {};

D o; o.pub_mem = 100;

위의 코드에서 저 멤버에다가 100을 대입하는 것은 가능할까?
이걸 판단하기 위해서는 컴파일러는 클래스 D의 가능한 상속 계통을 모두 순회하면서 최대 공개 등급(?)이 public이 되는지 따져 봐야 한다.
(참고로, 둘을 virtual로 상속하지 않았다면, 저 pub_mem이 B에 딸린 놈인지 C에 딸린 놈인지 알 수 없어서 모호하다고 어차피 컴파일 에러가 남..)

B는 A를 protected 상속했기 때문에 여기서 pub_mem이 protected가 되어 버려서 나가리. C는 A를 public으로 상속했지만, 최종 단계인 D에서 C를 private 상속해 버렸기 때문에 private가 된다.
요컨대 A에서 D까지 가는 동안 public이 계속 public으로 유지되는 상속 계통이 존재하지 않으며, 최대 공개 등급은 B 계열인 protected로 귀착된다. 그렇기 때문에 위의 구문은 컴파일 에러가 나게 되며, pub_mem은 D의 멤버 함수 내부에서나 건드릴 수 있다.

Visual C++의 경우, 가상 상속이 아닌 일반적인 상속 공개 등급 위반이라면 C2247 Not accessible because .. uses ... to inherit from 이라는 좀 단정적인 문구의 에러가 뜬다.
그러나 가상 상속 체계에서는 "접근 경로가 없다"라는 표현이 들어간 C2249 No accessible path to ... member declared in virtual base ... 에러가 난다. 공개 등급 체크를 위해서 더 복잡한 계산을 한 뒤에 판정된 에러이기 때문에 그렇다. 매우 흥미로운 차이점이다.

아무튼.. 참 복잡하기 그지없다.
그래서 C++ 이후의 언어들은 상속은 그냥 부모 멤버들의 공개 등급을 그대로 유지하는 public 상속만 생각하는 편이다. 다중 상속을 봉인해 버렸다는 건 더 말하면 입만 아플 것이고. C++이 객체지향 언어로서 여러 실험과 시행착오를 많이 했고 거기서 너무 무리수로 여겨지는 개념들이 후대의 언어에서는 짤렸다고 생각하면 되겠다.

Posted by 사무엘

2018/10/31 08:36 2018/10/31 08:36
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1549

1. HTTP 통신 고수준 API

오늘날 운영체제의 GUI API가 qt 같은 별도의 프레임워크가 나온 걸 제외하면 통일된 게 없고(통일이 될 수가 없음..) 그래픽 API가 통합된 게 없듯이..
네트워크, 특히 HTTP/HTTPS 기반 통신 API 역시 내가 아는 한 뭔가 ANSI/ISO 차원의 표준이 나온 게 없이 운영체제마다 다 파편화돼 있는 것 같다. 물론 제일 저수준의 소켓 API는 그럭저럭 표준화가 돼 있지만 오늘날 그것만 써서 밑바닥부터 프로그램을 짜는 건 클라이언트건 서버건 무리이니 말이다. 그러니 Windows, 안드로이드, iOS/macOS마다 또 API를 새로 익혀야 하는 게 다소 번거롭다.

요즘 인터넷에서 다른 프로토콜들은 거의 듣보잡이 돼 가고 HTTP/HTTPS만 남은 것 같다.
통합 라이브러리는 스위치만 달리해서 동일한 정보를 (1) GET와 POST 두 방식으로 간편하게 보낼 수 있으며, 이때 argument를 적절히 배치해 줘야 한다. 전자는 주소에다가 넣고 후자는 헤더에다가 넣어야 할 것이다.

URL 인코딩 처리를 적절히 해 줘야 하며, 바이너리 데이터 덤프를 base64로 인코딩, 또는 디코딩 하는 라이브러리도 덤으로 제공하면 좋을 것이다. post로 보낼 때는 Content-Type, Content-Length 같은 상투적인 헤더를 당연히 자동으로 넣어 줘야 한다.

Windows에서는 메시지를 보내는 방식이 post의 반대가 send인데, HTTP에서는 요청을 보내는 방식이 post의 반대가 get이다. get은 어떤 정보를 얻어 오기만 하는 read-only operation용으로 쓰고, post는 서버다 데이터를 등록하고 변경하고 삭제하는 등 side effect가 남는 요청을 할 때 쓴다. 일단은 그러하지만 홍보가 부족해서 현실에서는 그 용도가 엄밀하게 지켜지지는 않고 있다.

POST 방식 요청의 연장선이겠다만 (2) 다운로드뿐만 아니라 업로드도 당연히 지원해야 할 것이고, 받는 데이터 내지 올리는 데이터는 (3) 메모리, 파일명, 임의의 스트림 형태로 자유롭게 공급이 가능해야 한다. 전부 다 필요하기 때문이다.

그리고 아주 짤막한 파일을 주고받을 때나 UI 없이 그냥 명령줄 프로그램을 만들 때를 대비해서 그냥 (4) 동기형(응답이 올 때까지 block) + 짧은 대기 시간 형태도 지원하고, 별도의 스레드에서 돌아가는 비동기 방식도 자체 지원해야 한다.
비동기 방식은 결과가 왔을 때 콜백 함수 호출 하나로 끝나는 간편한 것을 생각할 수 있고, 한편으로 수십~수백 MB짜리 파일을 주고 받으면서 전송 상태를 늘 확인할 수 있는 복잡한 형태도 생각할 수 있는데, 둘 다 가능해야 한다.

단순 업데이트 체크 같은 건 굳이 지금 당장 안 돼도 상관 없는 것이니 프로그램의 반응성에 영향을 줘서는 안 될 것이다. 스마트폰 앱 같은 게 비행기 모드이거나 3G 데이터를 사용하고 있을 때는 괜찮은데 외부의 희미한 와이파이에 접속해 있을 때는 굼뜨는 경우가 있다. 이런 일이 없어야 할 것이다.

Java는 네트워크 쪽 클래스를 사용할 때는 try catch로 예외 처리가 무조건 돼 있어야 하고 안 그러면 컴파일조차 되지 않는데, 안드로이드에서는 그것도 모자라서 네트워크 통신은 무조건 별도의 스레드에서만 동작하게.. main GUI 스레드에서는 쓸 수도 없게 만들어 놓았다. 네트워크 에러 때문에 프로그램 전체의 동작· 반응이 멎는 걸 원천봉쇄하기 위한 조치인데, 이것 때문에 아주 간단한 소규모 통신에 대해서까지 일일이 스레드 만들고 함수 분리하는 건 번거롭기도 한 게 사실이다.

통신 API로 할 수 있는 일을 생각해 보니 이 정도인 것 같다. 이 모든 상황에 대한 대처가 가능하고 크로스 플랫폼까지 지원한다면 훌륭한 통신 API가 될 수 있을 것이다.

2. Windows CE 프로그래밍

회사에서는 이것저것 찝적대느라 안드로이드, macOS 코코아에 이어 근래엔 골동품인 Windows CE까지 만질 일이 있었다.
도스 기반의 Windows (1985), NT 커널(1993)에 비해 CE는 임베디드 환경을 타겟으로 나름 제일 나중에(1996) 등장했다. PC용 OS들과는 달리 CE는 리얼타임 OS이다.

그리고 CE는 훗날 Embedded Compact라고 이름이 미묘하게 바뀌었다가 2010년대부터 Windows Mobile, Windows Phone 등 스마트폰 OS로 변모하는가 싶더니.. 그냥 Windows 10 자체가 ARM용으로도 나오면서 모바일 분야를 흡수해 버렸다. 또한, 스마트폰 OS는 마소가 판단하기에도 Windows가 안드로이드와 iOS의 적수는 도저히 안 되겠다고 여겨져서 그냥 접어 버리고.. 그 대신 Visual Studio가 무려 안드로이드 개발도 지원하는 식으로, 완전히 다른 형태로 변화하게 되었다.

아무튼, 이 와중에 지금으로서는 좀 구닥다리가 된 Windows CE를 만져 봤다.
GUI에서 본인에게 아주 익숙한 Windows API로 프로그래밍 가능한 건 좋은 점이었다. 단, 같은 API를 사용하더라도 헤더 파일 구조가 PC와 동일하지는 않았으며, 생성되는 바이너리도 비록 PE 방식의 실행 파일이긴 하지만, PC Windows 버전처럼 kernel32, gdi32, user32 이런 DLL들 import가 있지는 않는 게 흥미로웠다.

그 대신 coredll.dll에 API들이 한데 몰빵돼 있는 듯하다. 그리고 메모리 절약을 위해 함수들은 이름이 아니라 ordinal 번호만으로 import하게 돼 있다.

static 라이브러리 같은 걸 만들어도 PC용과 CE 기기용을 동일 소스 기반으로 유지하기는 좀 어려워 보였다. 글쎄, #include 부분에 조건부 컴파일 로직을 정교하게 잘 짜 놓으면 불가능하지 않을지도 모르겠지만.. 거기까지는 잘 몰라서 말이다.
그러고 보니 옛날엔 Visual C++도 Embedded VC++라고 CE 개발 전용 에디션이 있긴 했다가 그건 2000년대 이후로 본가에 흡수됐다.

Visual Basic 6이라든가 Visual C++ 6은 후대 버전과 단절이 커서 꽤 오랫동안 쓰인 개발툴이라는 공통점이 있다. 그런데 Visual C++ 2008도 비슷한 면모가 있다. 바로 Windows Phone이 등장하기 전의 Windows CE 시절, 더 정확히는 Embedded Compact 6.5와 그 이전 버전 레거시 플랫폼의 개발을 지원하는 마지막 버전이라는 것이다.

자동차 내비에서도 이 운영체제가 돌아가는 경우가 있다.
PC용으로 오랫동안 개발되어 온 C++ 코드를 이 플랫폼과 컴파일러용으로 포팅하려다 보니 지금까지 편하게 써 왔던 auto와 lambda, nullptr 따위를 몽땅 구 문법으로 다시 써 주는 불편을 감수해야 했다. 저기서는 2010년대 이후에 새로 도입된 C++ 문법이 지원되지 않기 때문이다.

이 특정 플랫폼만 그런지는 모르겠지만, 인상적인 점은 뭔가 듬성듬성 빠진 함수가 많다는 것이었다. 덩치를 줄이기 위해서 다른 우회 대체제가 있다 싶은 건 몽땅 빼 버린 모양이다.
일례로, DrawText와 ExtTextOut은 있지만 더 단순한 함수인 TextOut은 없다(더 범용적인 대체제가 있으니까..). 파일 시스템도 도대체 뭐 어찌 되는지 GetCurrentDirectory, GetWindowsDirectory 이런 거 없다.

칼질은 C 함수 쪽도 예외가 아니다. 엄연히 ANSI 표준인 time 함수가 없어서 Windows API를 이용한 대체 함수를 직접 만들어야 했다.
그리고 어찌 된 일인지 FILE* 스트림 기반의 fopen 계열 말고, 정수형 파일 핸들을 주고 받는 저수준 _create, open 계열의 함수도 없더라. PC에서 쓰던 코드를 곧장 포팅하는 건 생각만치 쉽게 되지는 않았다.

제일 압권인 건 CE는 9x와는 정반대로.. API 함수에 W 버전만 있고 A 버전이 깔끔하게 없다는 것이었다.
9x는 W 버전도 껍데기는 있지만 실행이 에러 코드와 함께 몽땅 실패한다. CE에서는 A 버전이 컴파일은 되지만 링크가 되지 않고 곧장 실패했다. 1996년에 첫 개발된 신흥 OS이다 보니, 안 그래도 용량도 부족한데 구닥다리 레거시인 A는 처음부터 배제해 버린 셈이다.

Windows CE에는 W만 있고 A가 없다는 건 먼 옛날에 제프리 릭터 아저씨의 책에서 처음으로 봤는데 실제로 그렇다는 걸 그로부터 10수 년 이상 뒤에야 실제로 확인할 수 있었다.

3. 라이브러리의 형태의 변화

도스 시절에 프로그래밍에 필요한 무슨 라이브러리, API, 또는 SDK라 하면..
어셈블리어로 도스의 각종 특이한 인터럽트를 호출해서 하드웨어를 직통으로 건드리는 마우스 라이브러리, 그래픽/사운드 라이브러리, 심지어 한글 라이브러리 같은 게 많았다. 이런 기능들은 타 언어도 지원했지만 가장 먼저는 C/C++용 헤더와 라이브러리의 형태로 제공되었다.

Windows로 넘어가서는 어지간한 하드웨어 제어는 운영체제의 자체 API만 써도 커버가 되니 3rd party 라이브러리 같은 건 필요가 크게 줄어들었다. 그냥 MS Office와 Visual Studio의 외형을 흉내 내 주는 GUI 툴킷이라든가.. 이미지 파일 처리 라이브러리가 쓰였다. 아 그리고, DirectX SDK는 Windows 플랫폼 SDK로부터 완전히 분리 독립했기 때문에 따로 설치해야 하는 물건이 되긴 했다.

그런데 요즘은 그런 API, 라이브러리라는 게 용도와 형태가 바뀌고 있다. PC 안에서 혼자 돌아가는 프로그램이 고차원적인 하드웨어 제어 기능을 사용하는 게 아니라.. 웹사이트나 스마트폰 앱에서, (1) 특정 대규모 서버에서 제공하는 각종 실시간 정보 제공 기능(날씨, 버스와 지하철 위치, 지리 정보 등등)이라든가 (2) 아주 고수준의 인공지능 내지 패턴 인식 기능(이미지에서 사람 얼굴 인식, 음성 인식 등) 같은 것을.. 1인 개미 개발자가 자기 앱이나 사이트에서 곧장 사용할 수 있게 해 준다.

방대한 인공지능 데이터 검색과 계산은 서버가 담당한다. 바둑 AI로 치면 AI 코드가 라이브러리에 담겨 있는 게 아니라, 별도로 돌아가는 알파고 서버와 통신만 하는 거다.
언어는 무겁고 부담스러운 C/C++과는 거리가 멀며, JavaScript, Go, 파이썬 같은 것을 곧장 지원한다.
과금 체계도 과거의 전통적인 형태와는 사뭇 다르다. 비싼 라이브러리 제품을 몇만~몇십만 원 일시불로 지불하고 사 오는 게 아니라.. 월 얼마씩~ 사용 트래픽이 얼마까지는 무료이고 그 뒤부터는 한 건당 얼마 이런 식으로 매겨진다. 구매 대신 임대 형태이다.

기술은 그 자체는 온통 오픈소스다 뭐다 하면서 무료에 가깝게 공개되고 상향평준화되고 있다. Google API의 기능들을 개발하는 데 컴퓨터공학· 전산학 박사들이 얼마나 많이 투입됐을까..? 그 다음으로는 그냥 자본과 데이터 물량전이 대세이다.
그리고 소프트웨어로 돈 버는 건 기술과 기능 자체가 아니라 그걸로 온통 사용자들의 감성을 사로잡고, 자아· 정체성을 표현해 주는 대가로 형태가 바뀌는 것 같다. 온라인 게임의 부분 유료화라든가 각종 아바타가 대표적인 예이고 말이다.

아, 그렇다고 지금이 전통적인 형태로 판매되는 라이브러리· 미들웨어가 전멸했다는 얘기는 아니다. 게임에서 주로 쓰이는 네트워크 라이브러리, 동영상 캡처 라이브러리 같은 것들은 전적으로 로컬에서 기능이 동작하며, 단품 또는 출시되는 제품 타이틀의 규모 단위로 판매되고 있다. 돈을 한번 지불하고 끝인 것도 있고, 일정 주기로 꼬박꼬박 로얄티를 내는 형태인 것도 있다.

4. 함수 호출과 금융의 관계

좀 엉뚱한 생각을 하자면, 금융을 프로그래밍에다가 비유하고 돈이 오가는 걸 함수 호출과 데이터 전달에다가 비유할 수 있을 것 같다.

현금이 오가는 건 데이터 실물을 통째로 스택에다 얹는 call by value이다. 제일 단순하고 확실하지만 거액의 현금을 매번 들고 다니는 건 번거롭고 귀찮고 위험하다.
그러니 현금, 또는 가까운 미래에 들어올 예정인 돈에 대한 포인터가 등장하는데, 이것들이 바로 수표나 어음이다. call by reference가 현실 세계에도 존재하는 셈이다.
부도는 당연히 잘못된 포인터 접근으로 인한 page fault 내지 access violation과 직통 대응이다.

컴퓨터에는 지금 물리적으로 실제로 있는 메모리보다 더 많은 주소 공간을 끌어다 쓰고, 공간이 없으면 디스크 스와핑이라도 하는 '가상 메모리'라는 개념이 있다. 이게 어찌 보면 '대출'과 비슷한 개념으로 보인다.
물론 컴퓨터의 동작에 경제 용어인 '신용'과 정확히 대응하는 개념이 존재하지는 않는다. 그러니 완전 동일하게 대응하지는 않겠지만.. 그래도 이런 식으로 비유해 보면 생각보다 그럴싸하고 씽크가 맞아 보인다.

참고로, 성경이 말하는 헌금 원칙은 철저하게 리얼 모드이다. 빚을 내거나, 없는 돈을 미리 작정하는 보호 모드 가상 메모리 같은 개념은 없다.

5. 보안 정책

오래된 일이긴 하지만 마이크로소프트는 회사가 돌아가는 방식이 2002년 1월 1일 이전과 이후가 서로 싹 달라졌다. 더 엄격한 보안 정책과 더 일관성 있는 제품 지원 주기 정책이 적용되기 시작했기 때문이다.
일단, 이때를 기점으로 해서 모든 마소 제품에서 이스터 에그가 사라졌다. 문서화되지 않은 특정 동작을 하면 프로그램 개발자 명단이 나타나고 숨겨진 게임이나 애니메이션이 뜨는 것 말이다.

그리고 (a) 일반 지원은 제품 출시 후 몇 년 또는 차기 버전이 나온 지 몇 년 중 짧은 기간까지, (b) 연장 지원은 일반 지원이 종료된 뒤부터 5년간.. 요런 식의 규정이 추가되어 오늘날에 이르고 있다. 그와 함께 도스, Windows 3.x/95 같은 구닥다리 제품들은 지금까지 알음알음 지원되어 오던 것이 2001년 12월 31일을 끝으로 지원이 완전히 끊겼으며, 공식적으로 abandonware 판정을 받았다.

인터넷 덕분에 소프트웨어를 배포하는 데 물리적인 장벽은 사라지다시피한 반면, 원격으로 프로그램을 조종하고 컴퓨터를 장악할 수 있는 보안 위협이 커졌기 때문이다. 결국 소프트웨어라는 건 한번 만들고 나서 끝인 게 절대 아니라 계속해서 지원을 해야 하며, 굳이 기능과 컨텐츠에 아무 변화가 없더라도 보안 취약점이 발견되면 계속해서 고치고 지원해 줘야 하는 반제품 정도로 위상이 바뀌었다.

그러니 소프트웨어의 판매 비용에는 이런 잠재적 사후 지원 비용도 포함되어야 하며, 지원을 한도 끝도 없이 영원무궁토록 해 줄 수는 없으니 구체적인 기간이 법적으로 명시될 필요도 생긴 것이다.

그 뒤로 마소에서는 2000년 중반에 프로그램 개발의 기본 블록이라 할 수 있는 C 라이브러리에서부터 보안 결함을 잡겠다고 strcpy, gets 같은 함수들에 칼질을 가했으며, Visual Studio 2005에서 이를 최초로 적용했다. 컴파일러에 /GS 같은 검사 기능도 추가했다.
재래식 도움말인 WinHlp32 엔진은 너무 구닥다리 기능으로 전락한 데다, 이런 새로운 보안 기준을 충족하게 개량을 하기에는 가성비가 너무 안 맞는 관계(시간과 예산..)로 Windows Vista에서부터는 짤렸다.

Vista에서는 프로그램의 실행 주소를 그때 그때 랜덤화하는 보안 기능이 추가되기도 했다. Windows는 애초에 position independent code를 쓰지도 않는 운영체제인데, 오로지 보안을 위해 그 이념을 근본적으로 부정하고 성능을 희생하는 기능을 넣은 것이다.

이렇게 런타임 환경에다가는 예측 불가능한 요소를 일부러 가미한 반면, 빌드 타임 환경에는 정반대의 정책이 적용되고 있다. 같은 소스 코드를 같은 컴파일러 제품으로 빌드했으면 시간과 장소를 불문하고 바이너리 수준에서 언제나 완전히 동일한 실행 파일이 나오게 하자는 것이다. 이름하여 Reproducible builds이다.

단순히 생성되는 기계어 코드를 넘어서 객체들의 명칭과 배열 순서라든가 내부적으로 생성되는 각종 시그니처까지 완전히 똑같게.. 상상할 수 없을 정도로 다양한 환경에서 실행되는 프로그램을 테스트· 디버깅 할 때 문제를 재연하기 어렵게 만드는 변화 요인를 털끝만치라도 줄이겠다는 의도로 보인다.

시범타로 예전에 실행 파일의 헤더 차원에서 timestamp가 들어가던 곳에도 Windows 10에 들어가는 바이너리들은 그냥 고정된 hash값으로 바뀌었다고 한다. 시간이야 난수의 씨앗으로도 쓰일 정도로 매번 달라지는 값이니 말이다.
이렇게 21세기 들어서 세월이 흐를 수록 마소는 내부의 보안 정책이 갈수록 엄격해지는 것이 느껴진다. 그 와중에 실행 주소 랜덤화와 Reproducible builds라는 두 이념이 본인이 보기에 흥미로운 대조를 이루는 듯해 보였다.

Posted by 사무엘

2018/04/13 08:25 2018/04/13 08:25
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1478

코딩을 하다 보면 한 자료형(타입)에 속하는 값 내지 개체를 다른 타입으로 변환해야 할 때가 있다. 아주 직관적이거나(C에서 정수와 enum), 작은 타입에서 큰 타입으로 가기 때문에 정보 손실 염려가 없는 상황에 대해서는 해당 언어의 문법 차원에서 대입이나 함수 인자 전달이 곧장 허용되곤 한다. 바이트 수가 대등하더라도 signed보다는 unsigned가 더 큰 타입이고, 정수보다 실수가 더 큰 타입으로 여겨진다.

그렇지 않고 정보 소실의 여지가 있거나 서로 호환되지 않는 타입에다 값을 집어넣는 건 컴파일러의 경고나 에러를 유발한다. 이 상황에 대비하여 프로그래밍 언어들은 여러 형변환 함수들을 제공하는데, 씨크하게 괄호 안에다가 타입 이름만 달랑 쓰면 형변환 연산자로 인식되는 C/C++이 여기서도 참 유별난 면모를 보이는 것 같다.

형변환이란 건 값의 초기 타입과 목적 타입이 무엇이냐에 따라 내부에서 벌어지는 일이 매우 다양한 편이다.

(a) 없음: LPARAM에서 void*, void*에서 char* 같은 무식한 형변환은 소스 코드상의 의미만 매우 과격하게 바뀔 뿐, 내부적으로 행해지는 일은 전무하다! (클래스 상속 관계를 신경쓸 필요 없는 간단한 것 한정으로)

(b) 그냥 뒷부분 짜르거나 늘리기: int와 char 사이의 변환

(c) 정수와 실수 사이를 변환: 내부적으로 일어나는 일이 분명 간단하지는 않지만, 요즘은 이런 건 CPU 명령 한 줄이면 바로 끝난다. x86 기준으로 cvtsi2sd이나 cvttsd2si 같은 인스트럭션이 있다.

(d) 고정된 오프셋 보정: 단순한 형태의 다중 상속에서 제n의 부모 클래스 포인터를 얻으려면 이런 보정이 필요하다.

(e) 함수 호출: 해당 클래스에다 사용자가 구현해 놓은 operator 함수가 호출된다. 사실, 100과 "100"처럼 숫자와 문자열 사이의 변환도 컴퓨터의 관점에서 보면 이 정도의 cost가 필요한 작업이다.

(f) 상속 계층 관계 그래프 순회: 이건 객체지향 이념 때문에 형변환 연산이 언어 차원에서 가장 복잡해지는 상황이다. 위의 1~5와는 근본적으로 차원이 다르다. 가상 상속 체계에서 부모 클래스를 찾아가거나 dynamic_cast 형변환을 하려면 자기의 타입 정보 metadata를 토대로 주변 클래스 계층 그래프를 O(n) 시간 동안 순회해야 한다(n은 상속 단계).
사용자의 코드가 아닌 컴파일러의 코드만 실행됨에도 불구하고 런타임 가변적인 반복이 발생할 수 있으며, 객체와 메모리 상태가 어떤지에 따라서 형변환 결과가 dynamic하게 달라질 수 있다!

내부적으로 벌어지는 일은 대략 저렇게 분류 가능하고, 겉으로 소스 코드의 의미 차원에서도 형변환의 성격을 몇 가지로 분류할 수 있다.
처음에 C++에는 그냥 C-style cast밖에 존재하지 않았다. 그런데 그랬더니 형변환 연산이 발생하는 부분만 검색으로 뽑아내는 게 어려웠고, 또 단순한 형변환과 좀 위험한 형변환 같은 걸 따져 보기도 어려웠다. 표현 형태가 괄호와 타입 이름이 전부이니까..

그래서 1996~97년경, C++98의 발표를 앞두고 C++에는 길고 굉장히 기괴해 보이지만 용도별로 세분화된 형변환 연산자가 4종류나 추가되었다. namespace, bool, explicit, mutable 이런 키워드들과 같은 타이밍에 도입되었다. C++이 숫자는 몽땅 machine-word int로 어영부영 때우려던 C스러운 사고방식을 탈피하고, 예전에 비해 나름 type-safety를 따지기 시작한 그 타이밍이다. (예: C와 C++에서 sizeof('a')의 값의 차이는?)

새 연산자들은 모두 *_cast로 끝난다. 옛날의 재래식 형변환은 (NEWTYPE)value라고 썼고 C++ 문법으로는 NEWTYPE(value)도 허용되는 형태였다(NEWTYPE이 딱 한 단어 토큰으로 떨어지는 경우에 한해서).
그에 비해 새 연산자들은 *_cast<NEWTYPE>(value)라고 쓰면 된다. < > 안에다가 타입 이름을 쓰는 것은 템플릿 인자 문법에서 유래되었는데 나름 직관적이고 적절한 활용 같다.

1. static_cast

얘는 일상적으로 가볍고 큰 무리 없이 일어나는 일반적인 형변환을 거의 다 커버한다. (1) 큰 타입에서 작은 타입으로(실수에서 정수, UINT에서 int, long long에서 int 등..), 그리고 (2) 범용적인 타입의 포인터에서 더 구체적인 타입의 포인터로(void*에서 타 포인터, 기반 클래스*에서 파생 클래스 포인터) 말이다. 이게 대부분이다.

그리고 형변환 operator 호출이라든가, 다중· 가상 상속으로 인한 포인터 보정도 언어에서 보장돼 있는 메커니즘이므로 알아서 처리해 준다. 정말 대부분의 상황에서 앞서 나열했던 (a)에서 (f)까지, C-style cast를 대체할 수 있는 무난한 연산자이다. 단, f에서 typeid와 RTTI까지 동원되는 제일 비싸고 난해한 기능은 없으며, 이건 나중에 설명할 dynamic_cast가 전담하는 영역이다.

2. const_cast

얘는 값이 아니라 포인터/참조자형에서 C/C++ 특유의 한정자(qualifier) 속성만을 제거해서 더 범용적인 포인터로 만들어 준다. 그러므로 용도가 아주 제한적인 형변환 연산자이다.
C++에서 공식적으로 제공되는 qualifer는 const와 volatile이 있다. 이런 한정자는 가리키는 대상 타입과는 아무 상관 없고, 포인터를 이용해 그 메모리를 접근하는 방식 차원에서 제약을 부여할 뿐이다. 전자는 읽기 전용 속성이고, 후자는 멀티스레드에 의해 값이 언제든 바뀔 수 있음을 대비하라는 최적화 힌트이다.

Visual C++에는 __unaligned라는 확장 키워드도 저것들과 동급인 한정자이다. 이 포인터는 machine word 단위의 align이 맞춰지지 않은 주소가 들어올 수도 있으니 그렇더라도 뻗지 말고 보정하라는 뜻이다(성능 오버헤드 감수하고라도). align 보정을 알아서 너무 잘 해 주고 있는 x86 계열은 전혀 해당사항이 없고, 과거에 IA64를 지원하던 시절에 필요했던 키워드이다. 이것도 포인터 한정자 속성으로서는 굉장히 적절한 예이며, 이런 속성들을 const_cast로 제거할 수 있다.

3. reinterpret_cast

이건 의미론적으로는 제일 무식하고 생뚱맞고 위험하지만 내부 처리는 제일 할 것 없는 형변환 전문이다. (1) 정수와 포인터 사이를 전환하는 것, 그리고 (2) 서로 관련이 없는 타입을 가리키는 포인터끼리 전환하는 것.. 어디 범용적인 함수나 메시지로부터 아주 polymorphic한 데이터를 전달받아서 처리할 때에나 불가피하게 쓰일 법하다.

void*를 char*로 바꾸는 건 static_*으로도 되고 reinterpret_*으로도 된다. 하지만 const char*를 char*로 바꾸는 것은 static_*나 심지어 reinterpret_*로도 안 되고 반드시 const_*로만 해야 한다.
그런데 그래 봤자 reinterpret_*과 const_*는 어떤 경우에도 실질적인 내부 처리는 (a)뿐인(= 없음).. 참 허무한 연산자이다. 실질적인 처리가 없지만 이 숫자값을 해석하는 방식을 변경하는 이유는 분야별로 여럿 존재할 수 있다는 뜻이다.

재래식 C-style cast는 따지고 보면 1~3을 그냥 싸잡아서 구분 없이 수행해 준다. 그런데 가끔 드물게 다중· 가상 상속 관계의 타입 포인터끼리 형변환을 할 때 정석대로 보정 연산을 거친 포인터를 원하는지(static_*), 아니면 이것도 아무 보정 없이 동일한 메모리 주소에서 타입만 바꿔서 해석하고 싶은지(reinterpret_*) 모호해질 때가 있다.

이런 문제도 있고, 또 C++에다가 좀 제대로 된 객체지향 언어의 기능을 뒤늦게 갖추려다 보니 새로운 형변환 메커니즘이 필요해졌다. 이쯤 되니까 형변환 연산자도 별도의 예약어로 도입해서 구분하지 않고서는 도저히 버틸 수 없는 지경이 됐다. 그럼 다음으로 제일 괴물인 형변환 연산자에 대해서 살펴보도록 하자.

4. dynamic_cast

가상 함수를 쓰면 기반 클래스의 포인터를 주더라도 자신이 실제로 속한 파생 클래스에 해당하는 멤버 함수가 알아서 호출된다.
그리고 다중 상속 때 가상 상속을 쓰면, 여러 부모 클래스들이 동일한 조부모 클래스로부터 상속받았을 때 공통 조부모가 한 번만 상속되는 마술(?)이 일어난다. 물론 객체지향 언어에서 유연한 코드 재사용성을 보장하는 모든 마술에는 그에 상응하는 성능 오버헤드가 대가로 따른다는 점은 감안할 필요가 있다.

그런데 과거의 C++은 상속과 함수 호출에서 이렇게 언어 차원의 동적 바인딩이 지원되는 것과 대조적으로, 형변환에는 "동적 바인딩 + 무결성"을 보장하는 메커니즘이 딱히 없었다. 이놈이 A의 파생 클래스이긴 하지만 더 구체적으로 A의 자식들 중에 B가 아닌 C의 파생 클래스가 진짜로 맞는지, 이 멤버에 접근하고 이 함수를 호출해도 안전하겠는지 말이다.

C++은 void*가 있을지언정, 언어 차원에서 모든 클래스들의 공통 클래스(Java의 Object 같은)라는 개념이 없다. 그리고 클래스 내부의 vbtl에 직접 접근한다거나, 가상 함수의 포인터 값을 보고 클래스 종류를 판별할 수 있을 정도로 C++이 ABI가 몽땅 왕창 노출돼 있느냐 하면 그렇지도 않다(겉에는 공통의 썽킹 함수의 주소만 노출돼 있기 때문). 뭔가 어정쩡하다.

그러니 MFC 같은 옛날 라이브러리들은 자체적으로 CRuntimeClass 같은 타입 메타정보를 구비하고, 이놈이 CObject의 파생이긴 하지만 특정 클래스의 파생형이 정말 맞는지 런타임 때 확인하는 함수를 자체적으로 구현해야 했다.
C++이 아무리 C의 저수준 고성능 제어 이념을 계승했다 해도 명색이 객체지향 언어인데 그런 기능조차 없는 건 좀 아니라 여겨졌는지, 훗날 언어 차원에서 타입 식별 정보와 전용 형변환 연산자가 도입됐다. 그 결과물이 바로 dynamic_cast이다.

함수도 virtual, 상속도 virtual인 걸 감안하면 얘의 이름은 기술적으로 virtual_cast라 해도 과언이 아닐 듯하다. 하지만 static_* 이라는 단어가 이미 있으니 그것보다 더 값비싼 형변환이라는 의미로 dynamic_*이라는 이름이 최종적으로 붙었다. static_*은 이놈이 진짜 조상 관계가 맞는지 확인하지 않고 그냥 O(1) 복잡도짜리 기계적인 오프셋 보정만 해서(필요한 경우) 파생 클래스로 형변환해 주는 반면, dynamic_*은 타입 식별자를 직접 확인까지 한다는 것이다.

가상 함수의 구현을 위해서는 함수 포인터 테이블과 테이블의 포인터(멤버)가 필요하고, 가상 상속의 구현을 위해서는 기반 클래스의 포인터(멤버)가 필요하다. 그것처럼 동적 바인딩 형변환을 구현하려면 클래스 이름과 계층 관계를 기술하는 메타데이터와 함께 그놈의 포인터(멤버)가 필요하다.

가상 함수와 가상 상속 지원을 위한 데이터는 비공개로 꽁꽁 감춰져 있는 반면, 동적 바인딩 형변환을 위한 타입 식별자 데이터는 공식적으로 스펙이 공개돼 있고 일반 프로그래머들이 언어 요소를 통해 접근할 수 있다. 일명 RTTI (run-time type info)이다.
#include <typeinfo>를 한 뒤 typeid() 연산자로 const type_info&라는 구조체, 아니 클래스를 들여다보면 된다. typeid는...

  • sizeof와 마찬가지로 오버로딩 할 수 없다.
  • sizeof와 마찬가지로 타입 이름과 일반적인 값을 모두 받을 수 있다. 단, sizeof는 값이 올 때는 괄호를 생략할 수 있는 반면, typeid는 그렇지 않아서 언제나 뒤의 피연산자를 괄호로 싸야 한다.
  • sizeof는 결과값이 무조건 정적 바인딩으로 구해지는 반면, typeid는 바인딩이 정적과 동적 사이에서 어정쩡하다. 피연산자가 타입 이름이거나, 값이더라도 int 같은 primitive type 내지 상속이고 가상 함수고 아무것도 없는 구조체라면.. sizeof와 마찬가지로 수식을 실제로 evaluate하지 않는다. 그러나 뭔가 상속 관계 규명이 필요하다 싶은 개체라면 런타임 계산이 행해진다.

쉽게 말해 typeid는 MFC로 치면 obj->GetRuntimeClass()와 RUNTIME_CLASS(classnam)의 역할을 혼자 모두 수행한다는 뜻이다.
그럼 관련 타입들에 대해 DECLARE_DYNAMIC 내지 IMPLEMENT_DYNAMIC도 어딘가에 행해져야 할 텐데, 그건 C++ 컴파일러가 typeid 연산자가 쓰인 곳을 총체적으로 따져서 알아서 처리해 준다.

이런 RTTI 기능은 대다수의 C++ 컴파일러에서 사용 여부를 옵션으로 지정할 수 있게 돼 있다.
RTTI를 사용한 상태에서 dynamic_cast를 사용하면 실제 타입이 그게 아닌데 그 파생 타입으로 형변환을 시도하는 경우.. 피연산자가 포인터였다면 NULL이 날아오고, null이 가능하지 않은 참조자를 줬다면 예외(exception)를 날리게 된다.
이것도 다중 상속까지 생각한다면 상속 관계 그래프를 타고 오프셋을 보정하는 알고리즘이 가히 판타지가 될 것 같다.

이상.
객체지향 언어라는 게 그냥 구조체에다가 this가 자동으로 전달되는 함수가 같이 딸려 있고, 상속에 다형성 정도 지원되는 게 전부라고 생각하는 게 얼마나 순진한 생각인지 알 것 같다.
PC 환경에서 C를 초월하여 C++이 보급된 게 1990년대 초쯤인데, 이 무렵에 템플릿과 다중 상속도 도입됐다. 처음부터 있었던 게 아니다. 그리고 그때부터 C++은 뭐랄까, 괴물 같은 복잡도를 자랑하는 치떨리는 언어로 변모한 것 같다.

구리고 지저분한 면모가 많지만 그래도 그 정도 객체지향 이념에다가 고성능 저수준 제어까지 이만치 잡은 건 얘가 C++이 가히 독보적인 것 같다.
그러니 형변환 연산자도 언어를 따라 이렇게 복잡해진 것이다. 일례로, Java는 final이 있을지언정 포인터도 없고 const니 volatile 같은 건 신경 쓸 필요도 없는데 뭐 저런 구분이 필요하겠는가? 그러니 지금도 여전히 C-style cast만으로도 충분한 것이다.

Posted by 사무엘

2018/03/25 08:30 2018/03/25 08:30
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1471

1. Java 언어가 쓰이는 곳

Java는 C++과 달리 로컬 환경용으로는 그다지 재미를 못 본 언어 및 런타임 환경이다.
콘솔(게임기 말고, 명령 프롬프트..)용 프로그램이 Java로 만들어진 건 거의 못 봤다. 오히려 Java는 한때는 표준 입력으로부터 숫자 한 줄 입력받는 것조차도 온갖 패키지를 import하고 예외 처리 try catch까지 갖춘 뒤에야 가능한 불편한 언어였다.

GUI(프레임워크 이름이 Swing이던가?)로 넘어오면 VirtualBox나 OpenOffice처럼 일부 크로스 플랫폼 프로그램이 GUI 껍데기를 Java로 만든 경우가 좀 있다. (Windows 한정으로는 C#의 Windows Form와 경쟁?) 아, 직장에서 일정 관리 용도로 사용하는 ProjectLibre도 흔치 않은 Java 기반 로컬 GUI 프로그램이다.
하지만 Java가 제공하는 GUI는 외형이 네이티브 GUI에 비해 이질적이고 느리고 런타임 오버헤드가 커서 범용성 말고는 가성비가 좋지 않았다.

한편, Java는 애플릿(Applet)이라는 이름으로 웹(클라이언트)에서 돌아간 적도 있다. 웹에서 꽤 고차원적인 수학 그래픽, 화면 왜곡과 전환 애니메이션, 시뮬레이션(특히 교육용) 등을 출력할 목적으로 플래시와 경쟁하는 구도로 한때 쓰였으나.. 그것도 다 지나간 일이다. 현재는 망했으며, 개발사로부터 지원도 끊긴 지 오래다.

오늘날 Java는 로컬 PC가 아닌 안드로이드 앱, 그리고 jsp 기반 서버사이드 언어(웹 서버)로 회생해 있다.
뭐, Java 런타임을 컴퓨터에 설치해 보면 설치 중에 '전세계 수십억 개의 기기가 Java를 기반으로 돌아가고 있습니다'라고 자랑하는 문구가 뜨기도 하는데, 그것도 임베디드보다는 모바일을 말하는 게 아닌가 싶다.

Java는 오늘날 그렇게 됐고 로컬 PC 환경에서는 지금도 수많은 프로그래밍 언어들이 난립해 있지만, 웹에서는 그야말로 Java에서 이름만 빌려온 JavaScript로 대동단결 천하통일이 이뤄진 게 신기하기 그지없다.

2. 새로운 언어

애플에서 Objective-C에 한계를 느끼고 Swift라는 언어를 만들었더니,
그에 질세라 안드로이드 진영에서도 Java 대신 '코틀린'이라는 완전히 다른 언어를 만들었다. 왕년에 C++ 컴파일러를 열심히 만들었던 사람이 D 언어를 개발했듯, Java 기반 안드로이드 개발 환경을 열나게 만들었던 JetBrains라는 회사에서 전용 언어도 만들고 이를 Google에서도 채택한 것이다.

오늘날 베이직은 마소에서밖에 만들지 않는 언어가 됐고, 파스칼은 그냥 델파이의 전유물이 됐고 이제는 델파이라는 이름 자체가 RAD 툴 겸 프로그래밍 언어의 이름으로 등극했다. 언어가 워낙 많이 마개조됐기 때문이다. 또한 옵씨의 경우는 애초부터 애플이 언어에 대한 일체의 권리를 언어 고안자로부터 사 버려서 사유화했다.
저런 언어들에 비해, C/C++은 너무 심하게 파편화가 됐을지언정--언어 문법 자체보다는 라이브러리나 ABI 계층에서--, 특정 기업에 의해 좌지우지된다는 느낌은 상대적으로 덜 든다.

Visual Studio 등 요즘 IDE들은 프로젝트 전체에 존재하는 클래스들을 쭉 보여주는 기능이야 당연히 기본으로 갖추고 있다. 그런데 클래스들을 namespace 계층 + 이름의 알파벳 순으로만 보여주는 게 아니라, 기반 클래스별로 분류해서 보여주는 기능이 있으면 프로젝트들의 성격을 파악하는 데 더 도움이 될 것 같다. 그러면 그 클래스들의 성격을 파악할 수 있으니 말이다.

3. 간단한 자료형과 복잡한 자료형 or 클래스 객체

오늘날 객체지향을 표방한다는 많은 고급 언어들이 int 같은 (1) primitive type과 (2) 클래스 객체, 혹은 (1) 스칼라와 (2) 복합 자료형(리스트 같은)을 서로 구분해서 다루고 서로 다르게 취급한다. 함수 인자와 리턴값을 주고받을 때 (1)은 값을 그대로 전달하고 (2)는 메모리에 한 인스턴스만 둔 뒤 주소값만 주고받고 레퍼런스 카운팅을 하는 것이 대표적인 차이점 되겠다. Java, 파이썬 등 여러 언어들이 이런 정책을 사용한다.

순수 극한 객체지향 언어 중에는 1과 2의 구분조차 없애고 모든 것을 객체로 취급하여 타입 식별자라든가 기반 클래스 소속을 부여하는 물건도 있다. 하지만 그렇게까지 하기에는 속도와 메모리 오버헤드가 너무 크고 실용성도 떨어지니 많은 언어들이 최소한의 primitive type 정도는 허용하는 타협을 한다.

C++이야 어느 타입이건 어느 방식으로 전달할지(값, 주소/참조)를 몽땅 명시적으로 수동 지정이 가능하다. 그러나 포인터를 노출하지 않는 언어에서는 그런 구분이 프로그래머의 지정 없이 자동으로 행해진다. 포인터가 없는 언어라고 해서 포인터가 원래 하던 일 자체를 안 하는 것은 전혀 아니니까 말이다.

그런데 1과 2의 얼추 중간쯤에 속하는 물건은 문자열, 그리고 단순 구조체 정도다.
문자열이야 언어 차원에서 상수 리터럴도 존재하고 정말 기본 자료형과 복합 자료형의 중간에 속하는 독특한 물건인지라, 각 언어와 라이브러리마다 구현 형태가 제각각이다.

그리고 생성자, 소멸자, 상속, 가상 함수 따위 전혀 없고 레알 int 같은 primitive type의 묶음으로만 이뤄진 레알 C 스타일 구조체를 프로그래밍 용어로는 POD(plain old data)라고 한다. C++의 경우 POD 구조체만이 중괄호 { }를 이용한 멤버 별 값 초기화가 가능하다.
물론 POD도 개당 수십~수백 바이트를 차지하는 덩치 큰 놈이 될 수도 있지만 이는 논외로 하고..

단순 구조체를 클래스와 구분시킨 것은 C#의 신의 한수로 보인다. 사실, POINT, SIZE, COMPLEX(복소수)처럼 숫자 둘로만 달랑 이뤄진 간단한 구조체는 상속이 뭐고 없고 함수 인자도 그냥 값 형태로 전달하고 싶은 그런 물건들이니 말이다.

4. sizeof 연산자가 없음

개인적으로 Java를 쓰면서 C++에 비해 굉장히 특이하다고 오래 전부터 생각했던 점은..
가장 먼저, (1) int를 함수에다 주소/참조로 전달을 할 수 없어서 swap 함수를 구현할 수 없다는 것이다. int는 무조건 값으로만 전달되니 말이다.

(2) 클래스에 소멸자라는 게 없다 보니, 메모리는 GC 덕분에 뒷일 생각할 필요 없이 new만 늘어놔도 되는데 파일은 닫는 코드를 수동으로 매번 써 줘야 하는 게 처음엔 아주 웃기게 느껴졌었다.

(3) 그리고 끝으로.. sizeof 연산자가 없는 것에서 한번 더 경악했다. 수동 메모리 할당이 없고 포인터도 없고, sizeof마저 없다는 건 어떤 개체의 메모리 내부 덤프 같은 건 꿈에도 생각하지 말라는 얘기다.
primitive type이야 개별 크기가 어떤 기기의 JVM에서도 불변 동일하니(가령, int 4바이트, long 8바이트..) 굳이 sizeof에다 요청하지 않아도 되고..

하긴, 특정 개체의 메모리 주소 같은 걸 어디에다 낼름 누설해 줄수록 프로그램의 엔트로피가 커지고 Garbage collector가 추적해야 하는 영역이 넓어지고, 메모리 누수와 잘못된 포인터 에러가 날 확률이 높아지니.. 그런 건 최대한 애초에 할 필요가 없게 만들어야 할 것이다.
하지만 바이너리 덤프를 바로 못 하면 파일을 읽고 쓰는 작업도 좀 불편할 것 같다. 하다못해 과거에 베이직조차도 포인터는 없어도 숫자의 binary dump를 문자열 형태로 얻거나 그걸 디코딩하는 함수는 있었거늘 말이다.

C#은 Java처럼 가상 머신 기반에 자동 메모리 관리가 제공되는 언어이지만 이런 것들이 Java보다는 융통성이 있다. ref라는 키워드가 있어서 primitive type도 call by reference가 가능하다.
그리고 sizeof 연산자가 제한적으로 지원된다. primitive type과 단순 구조체 한정으로만 사용 가능하며, 자동 관리를 받는 자기 객체(managed class)에 대해서는 sizeof를 여전히 할 수 없다.

C#의 초창기 구버전에서는 아예 unsafe 코드 안에서만 sizeof를 사용할 수 있었지만 나중에 제약이 완화되었다.
그래도 C#과 Java 어느 경우든, sizeof라는 건 저수준 메모리 접근과 관계가 있는 기능이지, 가상 머신 고수준 코드와는 어울리지 않는 건 공통인 듯하다.

5. 객체의 배열

그러고 보니 Java는 클래스 객체들이 다 기본적으로 포인터 단위로 취급된다는 특성상, 객체의 동적 배열을 만드는 것도 좀 불편하다.

MyObject[] arr = new MyObject[n];

이건 MyObject들을 담을 배열 객체부터 하나 만드는 것이다. 그 뒤에 arr[0]부터 arr[n-1]에다가 MyObject의 인스턴스를 new로 할당하는 건 사용자가 또 직접 해야 한다.
C++이야 Java처럼 행동하고 싶으면 MyObject **arr을 하면 되고, 아니면 MyObject가 default 생성자만 있다면 곧장 MyObject *arr = MyObject[n]으로 객체의 배열을 만들 수 있으니 융통성이 있다.

그리고 한 객체가 여러 클래스들을 돌아다니면서 쓰이다 보면, 이 오브젝트가 값만 일치하는 게 아니라 본질적으로 그 오브젝트가 맞는지.. C++로 치면 주소값이 같은지, Java조차도 문자열은 equals 대신 ==를 써서 행하는 그 비교 대상값이 일치하는지.. 주소를 직접 확인하고 싶은 경우가 있다.

C/C++은 & 연산자가 있으니 일도 아닌 반면, Java는 디버거 창이 아닌 로그 확인을 위해서는 toString을 일일이 해 줘야 하는 것이 불편한 점으로 남는다.
포인터라는 게 위험하다고 직접 노출을 금기시하다 보니, 포인터로 직통으로 할 수 있는 일까지 좀 불편하게 바뀌는 건 어쩔 수 없나 보다.

6. 클로저

C++은 수동 메모리 관리뿐만 아니라 pointer-to-member(더 나아가 함수 포인터라는 것 자체까지)라는 것도 오늘날의 타 언어들이 제공하는 깔끔한 클로저와는 전혀 관계 없는 원시적이고 지저분한 물건이다. C/C++은(정확히는 C가) machine word를 정말 좋아하는 언어이며, '포인터' 하나만으로 간편하게 구현 가능하지 않은 요소는 쿨하게 제공 안 하는 게 전통적인 설계 철학이었다.

그러니 함수 안에 함수를 만드는 걸 지원하지 않으며(당대의 경쟁 언어이던 파스칼과 달리), C++도 클래스 안에 클래스, 함수 안에 지역 클래스 같은 건 전적으로 접근성 scope 구분만 할 뿐, 자기 밖에 있는 클래스 멤버나 함수 지역변수에 자동으로 접근하는 메커니즘 같은 건 제공하지 않는다. 즉, Java 용어로 말하자면 static class만 지원한다는 것이다.

C++만 쓰다가 Java나 Objective-C 같은 타 언어에서 this 내지 상부 클래스 멤버에 접근 가능한 함수를 스레드 콜백 등으로 자유자재로 넘겨줄 수 있는 걸 보니 아주 신기했다. 요즘은 함수형 언어 영향을 받아서 함수 몸체를 이름조차 안 붙이고 바로 넘겨줘도 되니 더 편하다.

이것도 타 언어들이 더 객체지향 철학에 따른 것이고, C++이 기괴하고 경직된 구조의 언어인 셈이다. 물론, C++의 사고방식은 저런 유연한(?) 함수 포인터(C++ 용어), 셀렉터(옵C 용어), 클로저(???)를 구현하기 위해 내부적으로 부과되는 시공간 성능 오버헤드가 무엇인지 생각하는 데는 도움이 될 듯하다.

C++은 저게 없는 대신에 P2M을 갖고 있는 셈인데.. C++의 또 다른 괴물 기능인 다중 상속과 연계하려다 보니 P2M도 도저히 '날포인터' 하나만으로 간편하게 구현할 수가 없어졌으니 참 아이러니이다. 이건 언어 설계 차원에서의 결함이나 마찬가지라고 봐도 할 말 없을 정도이며, 이와 관련하여 본인이 몇 년 전에 글을 쓴 적이 있다.

그나저나 Java의 상속 "extends A"는 C++로 치면 ": public A", 다시 말해 언제나 public 상속과 같은 것이겠지?
난 부모 멤버들에 대한 접근에 더 많은 제약을 가하는 private, protected 상속은 사용해 본 적이 없다.

7. 자동 메모리 관리, 동적 배열 등, 나머지 생각들

뭐, 직장에서 Java 개발도 좀 해 보니 깔끔한 1파일 1클래스 구조에다 헤더와 소스 구분이 없고 코드 파싱과 빌드가 정말 광속인 것(C++ 외의 타 언어들이 대부분 그렇지만), throw IllegalArgumentException("value must be >=0") 예외 처리가 사실상 assertion failure이나 마찬가지이니 assert(0 && "error") 이런 테크닉이 없어도 되는 것들은.. 마음에 든다.

ABI 계층이 파편화 없이 딱 잘 통합돼 있고, 무식한 헤더 파일 대신 패키지로부터 추출· 복원된 프레임워크 소스와 코딩 컨벤션.. 매번 다시 컴파일 되면서 특정 타입과 완전히 결합해 버리는 C++의 템플릿 대신에, 진짜로 유연한 void*를 캡슐화했다고 볼 수 있는 제네릭.. 이런 건 부럽기도 하고 현대의 프로그래밍 언어와 프로그래밍 환경이 얼마나 발전했는지를 뒷북으로나마 느낀다.

프로그래밍에서 "네이티브 코드 + 메모리 100% 수동 관리"(C/C++) 아니면 "가상 머신 + garbage collector 기반의 메모리 자동 관리"(C#/Java)의 차이는, 자동차 운전으로 치면 수동 vs 자동 변속기와도 비슷할 정도로 큰 차이인 것 같다. 자동차에서는 면허 조건이 달라질 정도로 큰 차이를 만들며, 프로그래밍에서도 뒷일 생각 안 하고 마음대로 new를 남발해도 되냐 그렇지 않느냐의 차이는 매우 크다.

(그럼 메모리가 자동 관리되는 언어에서는... 무슨 서버나 GUI 프로그램이 아니고 일체의 아이들 타임이 없이, 자기 할 일만 일괄 처리하고 끝나는 콘솔(명령 프롬프트)+단일 스레드 프로그램이라면 GC가 언제 어떻게 개입하여 동작하는지 의문이 든다. 뭐 그냥 메모리 할당 부분에서.. 자원 반납 없이 지금까지 메모리를 사용한 양이 도를 넘어선다 싶으면 그때 동작할 수도 있긴 하겠다.)

C++을 까는 사람들의 심정은 이해한다. 하지만 C++이 그렇게 지저분하고 자비심이 없는 대신에 어떤 넘사벽급의 강력한 네이티브 코드를 생산할 수 있는지, 그리고 Java가 편한 대신에 내부적으로 성능을 얼마나 많이 희생했고 런타임 오버헤드가 더해졌는지를 전부 논하지 않고 단편적인 비교만으로 언어 호불호를 논하는 것은 바람직한 태도가 아니라고 여겨진다. 둘 다 장단점이 있고 고유한 주 용도가 있는 법이다.

옛날에 잠깐 써 봤던 파스칼은 포인터도 있고 자유로운 call by reference도 지원했지만 그 포인터가 C처럼 막강하고 배열과 연계되는 건 절대 아니며, 동적 배열을 못 만들었다. 아무리 파스칼이 교육용 언어를 표방하고 만들어졌다 해도 베이직으로도 가능한 기능이 없는 건 말이 안 되니 저건 후대의 파생 언어에서 개선되었지 싶다.

Posted by 사무엘

2018/03/13 08:34 2018/03/13 08:34
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1467

« Previous : 1 : 2 : 3 : 4 : 5 : ... 7 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2020/01   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

Site Stats

Total hits:
1317500
Today:
317
Yesterday:
481