복잡한 포인터

C언어는 확실히 복잡한 선언을 쓰기에 이해가 안 가는 형태를 가지고 있습니다. 이것은 표현식에서 사용되는 방식(declaration mimics use)으로 선언을 하기 때문입니다. 따라서 C 선언을 이해하기 위해서는 유도자료형을 만드는 가장 작은 단위를 알고, 전체를 이해하는 방식으로 하면 이해가 안 갑니다. 거꾸로 이름(Java에서는 식별자, 여기서는 x를 말합니다.)에서부터 연산자를 통해 최종적으로 어떤 기본자료형으로 이끌어지는를 파악해야 합니다.
즉 bottom-up으로 이해하지 말고, top-down으로 이해해나가는 방식을 써야 합니다. 어찌보면 객체지향언어에서 type보다는 interface를 파악할려는 형태로 C 선언을 바라봐야 이해하기 편합니다. 그렇다고 객체지향언어의 polymorphism이라는 기능이 C에서 그대로 쓸 수 있는 것은 아닙니다만... 이건 언어가 사용하는 사람입장에서 제작된게 아니라서 compiler 제작자 입장에서 바라봐야 하는 요소일 뿐입니다.

이제까지 올리신 글을 보면 C 기초를 계속해서 연구하는 것으로 보입니다. K&R2를 읽는 것도 C 기초연구에 매우 중요합니다. C 기초연구를 하시는데 도움을 주는 다른 책을 알려드리겠습니다. C 함정과 실수(Andrew Koenig), C언어 펀더멘탈(전웅), The C++ Programming Language(Bjarne Stroustrup), C: A Reference Manual('C 프로그래밍 언어'라는 이름의 번역서가 있습니다). 그리고 중요한 전자문서로 C 표준과, C FAQs가 있습니다. C FAQs는 여기서 blog를 쓰시는 cinsk님이 번역하신게 있으니 공부하는데 도움이 많이 될 겁니다. 서적은 품절된 것도 있을텐데 그래도 국내번역이 되었던 것들로 그나마 구하기 쉬울 겁니다.
그리고 이런 것을 전문적으로 다루는 mailing list로 comp.lang.c.moderated, comp.lang.c++.moderated 를 구독하시기 바랍니다. 특히 C++ mailing list 쪽에서는 유명한 책 저자들도 간혹 보이곤 합니다.
KLDP의 질문게시판의 품질도 물론 훌륭합니다만 아무래도 전문적으로 다루는 곳보다는 속시원하지 못하겠죠. 제 생각에는 이곳에 하나하나 의문사항을 올리고 해답을 얻는 것도 좋지만 중요서적과 전자문서를 탐독하는 것이 C를 체계적으로 이해하는데 더 많은 도움을 줄 것 같습니다.

그리고 마지막의 실습 source는 gcc로 compile해본 결과 여러 개의 경고문을 내더군요. Compile이 되고, 실행되지만 이식성을 보장하는 정확한 source라고는 할 수 없습니다. 위에 나열한 책들을 읽어보시면 왜 그런지 아실 수 있을 겁니다.

전웅씨가 지금은 망한 han.comp.lang.c에서 자주 이야기했던 것 중 하나가 공부는 시험을 한 후 추측을 하는게 아니라 시험과 이론적 이해를 병행해야 한다고 했습니다. 기존의 잘된 문서를 찾는 것은 매우 힘들 일일지도 모릅니다만(때로는 없기도 하고...) 정확하고 체계적인 학습을 통해 실력이 일취월장할 수 있게 되는 기회를 제공해줍니다.

제가 생각하기에는 알지비님에게 대립각을 세우는 것이 아니라 기술적 정확성에 대해서 cinsk님이 철저한 면이 있기 때문입니다. 그리고 이런 것은 과학자, 기술자들에게는 일반적입니다. 솔직히 기술적인 질답을 할 때 상대방의 감정같은 것도 일일이 고려하면서 쓰는 것은 피곤한 일입니다.
컴퓨터기술의 다른 분야는 어떨지 모르지만(알지비님의 homepage에 가보니 오라클 관련 책의 저자시더군요.) C언어에 있어서 알지비님과 cinsk님은 기술적 격이 달라 보입니다. 그런데 알지비님이 C언어에 대한 글을 자주 올리다보니 cinsk님이 정확한 표현으로 수정하는 글을 올리게 된 것 뿐입니다. cinsk님의 글은 단지 기술적 내용에 대해서 말씀드린 것일 뿐 알지비님에게 대립각을 세우는 것은 절대 아니라고 봅니다.
cinsk님과 비슷한 연배라고 하시니 제가 이런 말을 하는 것은 주제넘은 것일지 모릅니다만 분명 이런 형태로 특정인에게 자신의 글이 지적당하다보면 기분이 상할 수도 있습니다. 하지만 알지비님은 기술지식에 대한 열망이 있기 때문에 계속 글을 올리시는 것일테고, 그렇다면 기분이 상하는 것은 물론 자신보다 대가인 분에게 접어둘 것은 접어두고, 배우게 된 것에 대해 감사하는 것이 배우는 사람으로서 더 도움이 될 것 같습니다.

웬만하면, 이런 일을 많이 당해서, 답변 안 합니다. 귀찮으니까요.

사람마다 느끼는 바가 다르겠지만, 여긴 "정보전달 > 친목"이 목적인 곳입니다.
잘못된 정보가 존재하면 치명적인 곳이죠.

> 실습 결과로 말씀드리면,
> "char (*(*x())[])(); 와 char *x(); 는 동일하다" 입니다.
> 간단하게 해석해서 포인터를 반환하는 함수입니다.

앞에서도 말했지만, 올리신 이 글에 답글이 하나도 없었다고 가정해보기 바랍니다. 해당 분야에 정확히 아는 사람이 없을 수도 있고, 바빠서 못 볼 수도 있습니다.

이 후, 어떤 사람이 포인터에 관한 글을 검색해서 위 문장을 봤다고 생각해보세요. 어차피 잘 몰라서 이 글을 찾아 읽은 사람이기에, 앞에 올리신 그 글만 읽는다면, 당연히 두 이름 'x'가 같은 것이라고 생각할 겁니다. 제가 우려하는 것은 바로 이런 상황입니다. 정보 전달을 목적으로 하는 곳에서, 불확실한 정보가 올라오는 것은, 아예 정보가 없는 것보다 못합니다.

차라리,
> "char (*(*x())[])(); 와 char *x();의 차이점이 뭘까요?
> 만약 서로 다르다면 아래 코드가 동작하는 이유는 먼가요?

라고 올리셨다면, 답변이 안달리더라도, 타인이 봤을때, 오해가 생길 가능성이 줄어들거라는 겁니다.

입장을 바꿔 말해보죠.
저는 커널을 잘 알지 못합니다. (사실 거의 모릅니다.) 하지만 printk(...)가 있다는 것은 알고 있죠. 만약 제가 다음 글을 올렸다고 생각해보세요.

linux:
  printk("value of i = %x\n", i);
 
hello.c:
  printf("value of i = %x\n", i);

실험해 보니, "printk()와 printf()는 동일하다" 입니다. 왜 다른 이름을 썼을까요?

여기 뿐만 아니라, kernel mailing list, news group에 위와 같이 질문을 올린다면, 호의적이거나 친절한 답변이 달릴 확율이 얼마나 될 것 같나요? 위 질문에 대답을 해 줄 수 있는 정도의 지식이 있는 사람이라면, 질문을 끝까지 읽기도 전에 "printk()와 printf()는 동일하다" 이 말만 보고 풋~ 이거나, 대답할 의욕?이 사라질 겁니다.

같은 질문을 아래처럼 한다면:

실험해 보니, printk()와 printf()는 크게 다른 것 같지 않은데요, 차이점이 뭘까요?

이 경우, 서로 답변할려고 아우성칠 확율은 적지만, 그래도 앞 질문보다 공격적인 답변을 받을 확율은 줄어들 겁니다.

지식 전달이 목적이 아니라면 상관없겠지만, 맞다면, 타인이 자신의 질문만 보고, 잘못된 해석할 우려가 없는 쪽으로 올려야 합니다. 그게 싫다면, 공격적으로 보이는 답변을 감수해야겠죠.

--
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Korean Ver: http://www.cinsk.org/cfaqs/

VS 로부터의 피드백이라니.. 이건 생각지도 못했군요.
그리고 이건 부탁인데, 실습이라는 단어의 사용을 지양해주셨음 하네요.
저는 학생도 아니고, 여긴 학원도 아닐뿐더러, 칭찬받기 위해 만든 코드도 아니고 누군가를 가르치기 위해 만든 코드도 더더욱 아닙니다.
근데 마치 숙제검사 받으려고 제출한것처럼 왠지 찜찜한 기분이 들게 하는군요.

되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』