대학 신입생들에게 C언어를 가르쳐야 할 것 같은데요.

studioego의 이미지

제가 06학번 애들에게 C언어를 가르쳐 줘야 할것 같습니다.
C언어를 배우는 입장에서는 선배한테서 If문, switch case문, break, 같은 조건문과 #include, #define과 같은 전처리문과 간단한 구조체정도를 배웠거든요
이제 가르치는 입장에서 하자니 막막하네요.
제가 C언어를 가르치게 될 입장이 되니까 걱정이 앞섭니다.
C언어를 가르칠때 책보고 책을 떼게 하는 식으로 가르칠까? 아니면 제 머릿속에서 생각나는 데로 할까?(공부 죽어라해야겠죠?) 아니면 책 던지고 나서 질문할것 질문하고 할까?
이런 생각들이 머리속에서 듭니다.

고수님들은 후배들에게 C언어 가르칠때 어떤 방식으로 가르쳤습니까?

dudungsil의 이미지

읽는 법부터 가르키세요.

모든 언어(프로그래밍 언어죠)는 쓰기전에 읽기와 듣기를 가르치는데 유독 프로그래밍언어는 쓰기부터 가르킵니다.

읽지도 못하고 말도 못하는데 소설부터 쓰라고 가르키는 것과 다를바 없다고 생각합니다.

무조건 main과 위에서 언급했던 if, switch, for같은 문법으로 시작하지 마시고 적당한 길이의 소스를 구하신후 그걸 읽고 코드의 형태등이 어느정도 눈에 익으면 그때 하나씩 알려주는게 더 낫다고 생각합니다.

산넘어 산

pleasantman의 이미지

열혈강의 C프로그래밍(윤성우저) 책을 추천하죠..
내용 쉽구요.. 인터넷 강의 먼저 들으시고.. 신입생에게
설명하시면 될 것 같습니다. 책 내용도 쉽구요...
인터넷 강의도 적절 한 것으로 보입니다. 아니면 머 먼저 인터넷
강의 듣게 하시고 모르는 것에 대해서 질의하는 것도 좋구요..

저도 비슷한 방법으로 사용해서 이 책으로 사내 C강의를 진행 했었는데.. 반응이 괜찮더군요..

plustag의 이미지

남을 가르치다보면.. 자신의 실력이 늘어납니다..

저도 동아리에서 리눅스하고 c언어 후배애들한테 세미나형식으로 가르쳐봤었는데..

애들이 배우는거 보다 제가 배우는게 더 많더군요..

우선 가르치려면 완벽하게 이해를 해야하니..

열심히 하시길 바랍니다..

참고로 c언어 같은 경우는..

윗분 말대로 간단한 소스 여러개를 일단 읽는 법 부터 배워놓고..

문법과 그에 따른 문제를 푸는 것이 좋을 듯 합니다..

누구냐 넌?

kooya의 이미지

06학번이라면 프로그래밍 랭귀지로써 C가 처음일듯 하군요.

C문법을 가르쳐줄수도 있지만 기본적인 자세를 가르쳐 주는것도 중요할거 같습니다.

저 같으면 소프트웨어공학론을 피면 나오는 개발단계에 대한 설명을(요구사항분석,설계,구현...,유지보수) 먼저하겠습니다.

그리고 프로그래밍이란건 사용자의 요구사항을 컴퓨터라는 매체를 통해서 구현한거라는 추상적인 표현을 사용해서 설명을 하겠습니다.

결과적으로 인풋 그리고 블랙박스 아웃풋이라는 접근을 시도해 보겠습니다.

#include <stdio.h>
int main()
{
printf("Hello World\n");
return 0;
}

#include <stdio.h>과 printf라는 것을 가지고 모듈이라는 것을 설명하겠습니다. 기본 라이브러리 없이 프로그래밍한다는게 얼마나 시간을 많이 필요로 하는것인지에 대한 접근을 해보는것도 좋을거 같습니다.

그 다음에 main펑션과 printf펑션이 메모리상에 어떻게 표현되는지 스택이라는 개념을 설명해보겠습니다. 여기서 자료구조란 개념에 대해서 간략히 설명해도 좋을거 같습니다.(스택,큐,트리등)

main과 printf에 대한 설명을 하면서 메모리상에서 실제로 어떻게 표현되는지 data와 code에 대한 접근을 시도해보겠습니다. 그리고 디지탈 세계에서 자료는 어떻게 표현되는지 설명을 하겠습니다. 그리고 C언어상에서 사용하는 자료형(정수형과 문자 그리고 포인터등)에 대한 접근을 하죠.
왜 저런 접근을 시도했는지 제가 이해하는 범위에서 설명을 하는 것입니다. 자료에 대해서 디지탈로 표현하면서 생기는 현상에 대한 설명을 다시 한번 강조하겠습니다. int형이 4byte를 차지할때 맥스값을 넘기면 어떻게 표현되는지 구체적인 예시를 들어서 설명을 하도록 하죠.
그리고 자료형과 연산자에 대해서 설명하면서 어떤 주의를 기울여야 하는지 그리고 C언어상에선 어떻게 표현하는지 설명을 하도록 하죠.
그리고 자료형과 연산자에 대해서 어떻게 접근하는지 설명을 하도록 하겠습니다.
------------------------------------------------------------------
이 이후에도 할말은 더 있지만 다른 분들 의견을 더 들어보죠. 사실은 지금 당장 할게 생겼습니다. 그리고 제가 위에서 말씀드린 사항은 제가 후배나 주위사람들에게 가르쳐줄때 사용한 하나의 접근 방법입니다.

greedy 알고리즘

yjwoo14의 이미지

저희 같은경우에는

어차피 전부다 컴퓨터 학부 생들만 들어오기 때문에
C수업이 있기 때문에 하나하나 자세히 짚고 넘어가기 보단
처음에 C에 대한 개념을 어느정도 (위에서 말한것 처럼 읽기??) 잡아준다음에

하나의 기본적인 목표를 (저희는 주로 .. 링크드를 이용한 주소록으로 하더군요;)
두고 그걸 코딩하기 위해 필요한 것들을 주로 가르쳐 줍니다 -_-;;;;;

누구에게나 자신의 상황이 제일 힘들다.. 즐기자!

죠커의 이미지

pleasantman wrote:
열혈강의 C프로그래밍(윤성우저) 책을 추천하죠..
내용 쉽구요.. 인터넷 강의 먼저 들으시고.. 신입생에게
설명하시면 될 것 같습니다. 책 내용도 쉽구요...
인터넷 강의도 적절 한 것으로 보입니다. 아니면 머 먼저 인터넷
강의 듣게 하시고 모르는 것에 대해서 질의하는 것도 좋구요..

저도 비슷한 방법으로 사용해서 이 책으로 사내 C강의를 진행 했었는데.. 반응이 괜찮더군요..

저는 이 책을 매우 비추하는 편입니다.

이 책을 읽고
int **(*(*pFunc)(double (*pParm1)(int *prm2, double prm3), char *(*pParm2)(int, char)))(float prm1)
이런 코드를 설명할 수 있습니까? 이 코드가 "귀찮아서" 못 풀어야지 "예외적이어서" 못푸는 책은 예외로 가득찬 "성문종합영어"에 불과합니다. 이외에도 이 책은 다른 한국책들처럼 나름대로 공식을 만들고 그 것에 벗어나는 사례들을 "예외"로 만들어 버립니다. 이 책의 의의는 다른 "성문종합영어"류 책보다 쉬운 "맨투맨 영어" 정도의 의의라고 할까요?

국내서 중에 이것을 제대로 푸는 책은 전웅씨가 쓴 책 밖에 본적이 없는 것 같습니다. 그러나 이 책으로 스터디를 하기에는 무리가 있겠군요.

PS: 나는 열혈강의 C 프로그래밍 밖에 보지 못했지만 이 책때문에 열혈강의란 브랜드 자체가 나쁘게 여겨집니다. 이번에 새로 나온 포인터 책 역시 시중에 나와있는 "포인터"를 다룬 다른 엉터리 책과 비슷하지 않을까 편견을 가지고 있습니다.

bigpooh의 이미지

대학이니 ABC가 좋지 않을까요?

creativeidler의 이미지

책을 정해서 책대로 진도 나가는 것이 가장 좋다고 봅니다. 그 분야를 오랫동안 가르쳐온 전문가들이 가장 합리적이라고 생각하는 과정을 엮은 것이 책입니다. 혼자서 아무리 열심히 해도 좋은 책 한 권보다 좋은 커리큘럼을 만들기란 정말 어려운 일입니다. C는 좋은 책이 많으니 잘 찾아보시기 바랍니다. 가급적 원서로 시작하는 것이 좋지 않을까 싶습니다.

SE적인 접근은 프로그래머에게 필수적인 것이기는 하지만 이것부터 가르치면 흥미를 잃을 수 있습니다. 몇 번 프로그래밍을 가르쳐본 경험에 의하면 내가 기초라고 생각하는 부분들부터 가르치면 사실 기초가 따분하고 응용보다도 더 어려운 경향이 있기 때문에 십중 팔구 흥미를 잃고 진도가 잘 안 나갑니다. 그보다 일단 처음에는 실습 위주로 무언가 결과를 눈으로 확인할 수 있도록 나가고 좀 익숙해지면 다시 기초를 다지는 방식이 효과가 좋았습니다.

예를 들자면, 포인터 개념을 처음부터 확실하게 잡아놓고 시작하기보다 포인터를 쓰는 코드를 몇 개 실습해본 후 포인터 개념을 다지는 것이 더 효과가 좋습니다. SE 같은 것도 처음부터 다루는 것보다 프로그래밍 경험이 쌓이면서 SE의 개념들이 필요하다는 것을 서서히 느낄 때쯤 본격적인 SE를 가르치는 것이 더 효과적입니다.

초보자가 아니라면 굳이 실습 위주로 할 필요는 없습니다. 경험 많은 프로그래머라면 기본서 하나 혼자서 읽기만 해도 언어 하나 배우는 건 일도 아니죠. 하지만 초보자는 실습이 없으면 개념도 제대로 안 박히고 무엇보다 흥미를 잃게 되므로 실습 과제를 잘 잡는 게 아주 중요합니다.

r0x2tk1t의 이미지

공통분모를 가지고 접근하는 것이 대체로 술술 풀립니다.
같은 책을 가지고 서로 공부하면서 가르치고 배우는 것이 좋습니다.

가장 중요한 것은!!
진도를 나가면서 계속 input을 넣으시고,
적절한 output을 받아내는 일입니다.

이 과정을 무시하신다면.. 결국 수업이 끝나고,
백지가 되어버린 06학번 후배님들의 상태를 보실지도 모릅니다 :twisted:

日新 日日新 又日新
Google Talk::chanju_dot_jeon(at)gmail_dot_com

theone3의 이미지

ABC든 다른 책이든 뭐든 원서로....

당신은 사랑받기 위해 태어난 사람.

violino의 이미지

The C programming language, Brian W. Kernighan and Dennis M. Ritchie, Prentice Hall, Inc., 1988

이거 넘 구닥다리라서 추천하는 사람이 없나요?
제가 이 책을 좋아하는 이윤 얇아서입니다.
얇다고 결코 무시할 책이 아닙니다.
기본적으로 필요한 것은 다 있습니다.
참고로 저자가 C 언어 개발한 사람중 하나이지요.

남을 갈친다는게 참 힘든 일입니다.
하지만, 지나고 보면 첫번째 수업 준비할때가 가장 열심이었던 것 같아요.
교재는 일단 간단한걸로 정하시고요,
갈치는 사람이 참고서를 많이 봐야 할거예요.
한 챕터 나갈때마다 참고서를 있는데로 다 봐서 꼭 먼저 이해하세요.
그리고, 매시간마다 꼭 진도에 맞는 숙제를 내 주시고요.
그럼

vio:

monovision의 이미지

CN wrote:
pleasantman wrote:
열혈강의 C프로그래밍(윤성우저) 책을 추천하죠..
내용 쉽구요.. 인터넷 강의 먼저 들으시고.. 신입생에게
설명하시면 될 것 같습니다. 책 내용도 쉽구요...
인터넷 강의도 적절 한 것으로 보입니다. 아니면 머 먼저 인터넷
강의 듣게 하시고 모르는 것에 대해서 질의하는 것도 좋구요..

저도 비슷한 방법으로 사용해서 이 책으로 사내 C강의를 진행 했었는데.. 반응이 괜찮더군요..

저는 이 책을 매우 비추하는 편입니다.

이 책을 읽고
int **(*(*pFunc)(double (*pParm1)(int *prm2, double prm3), char *(*pParm2)(int, char)))(float prm1)
이런 코드를 설명할 수 있습니까? 이 코드가 "귀찮아서" 못 풀어야지 "예외적이어서" 못푸는 책은 예외로 가득찬 "성문종합영어"에 불과합니다. 이외에도 이 책은 다른 한국책들처럼 나름대로 공식을 만들고 그 것에 벗어나는 사례들을 "예외"로 만들어 버립니다. 이 책의 의의는 다른 "성문종합영어"류 책보다 쉬운 "맨투맨 영어" 정도의 의의라고 할까요?

국내서 중에 이것을 제대로 푸는 책은 전웅씨가 쓴 책 밖에 본적이 없는 것 같습니다. 그러나 이 책으로 스터디를 하기에는 무리가 있겠군요.

PS: 나는 열혈강의 C 프로그래밍 밖에 보지 못했지만 이 책때문에 열혈강의란 브랜드 자체가 나쁘게 여겨집니다. 이번에 새로 나온 포인터 책 역시 시중에 나와있는 "포인터"를 다룬 다른 엉터리 책과 비슷하지 않을까 편견을 가지고 있습니다.

저는 어떠한 것이든 처음 배울때는 즐겁게~ 라는 생각을 가지고 있습니다.
실제로 입문서에서 저런 내용을 다룬다면 배우는 입장에서는 대부분 지레 겁먹고 포기하고 말겁니다.
대부분의 C 언어 입문서를 보면 공통적으로 등장하는 것이 있습니다.
그 유명한 "Hello World" 죠.
전 C 를 처음 배울때 그 소스를 가지고 제 이름도 출력해 보고, copy & paste 로 가족들 이름도 출력해보고...
신기하고 재밌다는 것을 느꼈습니다.

C 는 배우면 배울수록 아득하고, 끝이 없다는 것을 느낍니다. 예로 드신 영어도 비슷하죠. ( 저의 내공이 부족한 점이 가장 크지만.. )

배우는 것에는 단계가 있다고 생각합니다. 초보자에게는 초보자의 단계가 있고, 중급자, 고급자에게는 그에 따른 단계에
맞게 배우는게 순서가 옳지 않나 생각합니다.

전 열혈강의 C 를 보지는 않았지만 대부분의 서평은 아주 괜찮았던걸로 기억합니다. 입문서로서 말이죠.

예로 드신 전웅님의 책에 관한 서평을 보면 (전 현재 보고 있는 중입니다... 상당히 난해하네요...;;;.) 7-8년차의 현직 프로그래머조차도
몰랐던(헷갈렸던) 부분을 알게 해줄정도로 깊은 내용인데 그 책 혹은 그와 비슷한 수준의 책을
입문자용으로 요구하기에는 무리가 있다고 생각하며, 단지 그런 기준으로 좋은책과 나쁜책을 구분한다는 것은
이해하기가 힘듭니다.
( 참고로 열혈강의 TCP/IP 는 상당히 괜찮습니다. 입문자용으로서 말이죠... )

전 위의 coldState 님의 의견에 한표 던집니다.
처음 배우는 입장에서는 그 무엇보다 흥미를 가지게 하는 것이 중요하고 C 에서 그 부분은 적절한 output 이라 생각합니다.

docview의 이미지

처음 부터 왜 이 책을 보지 않았을까 후회를 했습니다
저는 이책을 독파 할 정도로 봤습니다. 구체적으로 더 말씀 드리지는 않겠습니다만 물론 그 이후에 책들도요.
초보의 입장에서 한권의 책으로 cn님이 말씀하신 내용을 이해 할 수 있는 책이 과연 몇 권이나 있는지 궁금합니다. 그런 책을 추천해 주신다면 저 같은 초보의 입장에서는 대 환영일 것입니다.
저도 coldState 님의 의견에 한표 던집니다.

나는오리의 이미지

kooya wrote:

#deifne <stdio.h>
int main()
{
printf("Hello World\n");
return 0;
}

제 머리로는 #define <stdio.h>가 오타라고 보는데요.
그 아래에 너무나도 열심히 설명하셔서 혹시 -_-; 되는게 아닐까?
라고도 생각했습니다. -_-;;;;

#define -> #include

#include <stdio.h>

익명 사용자의 이미지

c언어를 가르치는게 목적이냐, 그냥 단지 프로그래밍 언어 입문정도(신입생이라고 하셨으므로) 가르치냐는 목적에 따라서 약간의 접근적 차이가 있으리라 생각됩니다.

단지 프로그래밍 언어 입문이라면, (요즘은 대부분 학부제이므로) 학생들에게 호기심을 유발시켜서 학습 의욕을 상승시키는 부분이 가장 중요합니다.
(과제는 쉽게, 과제물 검사는 리포트 보다는 직접 시연으로 눈으로 확인,,)

c언어를 가르치는게 목적이라면, 하드웨어적 기초지식과 포인터 개념을 잡아야 하는게 중요하므로, 컴퓨터학 개론과도 접목시켜야 할것입니다.
(물론 컴퓨터학 개론이라는 과목이 따로 있을것이므로다 한 두강의 정도의 수박 겉ㅤㅎㅏㅌ기 정도겠지만)

사실 이런 류의 강의는 강의 그 자체보다 어떤 식의 과제를 적절히 내고, 그 과제에 대한 학생들의 충실도(얼마나 잘 풀어 내었느냐에 따라)를 지속적으로 체크해서
학생들의 수준에 맞게끔 실습을 잘 하는게 중요합니다.

실습하다보면 실력들이 보이고, 실력 있는 학생들은 미리 도우미로 선발하고 가산점을 주는 식으로,
(그리고, 실력이 뛰어난 학생은 교수님께 허락받아서 아예 실험실 텀 프로젝트만으로 때우게 할 수도 있겠습니다.)

이때 유닉스는 반드시 필수입니다. :)

sunyzero의 이미지

ABC로 시작하고, 간간히 간단한 숙제를 내주면 될듯 합니다.

대개 구구단이나 야구게임, 퍼즐 이런거 내주면 잘들합니다.

========================================
* The truth will set you free.

오호라의 이미지

sungdh86 wrote:

고수님들은 후배들에게 C언어 가르칠때 어떤 방식으로 가르쳤습니까?

이런 딜레마에는 답이 없는게 답인거 같습니다.

저 개인적으로 해본적은 없지만 차차리 PL을 가르쳐보시는게 장기적인 측면에서도... 앞으로 10년동안은 BNF세상이 아닐런지...

Hello World.

죠커의 이미지

monovision wrote:
CN wrote:
pleasantman wrote:
열혈강의 C프로그래밍(윤성우저) 책을 추천하죠..
내용 쉽구요.. 인터넷 강의 먼저 들으시고.. 신입생에게
설명하시면 될 것 같습니다. 책 내용도 쉽구요...
인터넷 강의도 적절 한 것으로 보입니다. 아니면 머 먼저 인터넷
강의 듣게 하시고 모르는 것에 대해서 질의하는 것도 좋구요..

저도 비슷한 방법으로 사용해서 이 책으로 사내 C강의를 진행 했었는데.. 반응이 괜찮더군요..

저는 이 책을 매우 비추하는 편입니다.

이 책을 읽고
int **(*(*pFunc)(double (*pParm1)(int *prm2, double prm3), char *(*pParm2)(int, char)))(float prm1)
이런 코드를 설명할 수 있습니까? 이 코드가 "귀찮아서" 못 풀어야지 "예외적이어서" 못푸는 책은 예외로 가득찬 "성문종합영어"에 불과합니다. 이외에도 이 책은 다른 한국책들처럼 나름대로 공식을 만들고 그 것에 벗어나는 사례들을 "예외"로 만들어 버립니다. 이 책의 의의는 다른 "성문종합영어"류 책보다 쉬운 "맨투맨 영어" 정도의 의의라고 할까요?

국내서 중에 이것을 제대로 푸는 책은 전웅씨가 쓴 책 밖에 본적이 없는 것 같습니다. 그러나 이 책으로 스터디를 하기에는 무리가 있겠군요.

PS: 나는 열혈강의 C 프로그래밍 밖에 보지 못했지만 이 책때문에 열혈강의란 브랜드 자체가 나쁘게 여겨집니다. 이번에 새로 나온 포인터 책 역시 시중에 나와있는 "포인터"를 다룬 다른 엉터리 책과 비슷하지 않을까 편견을 가지고 있습니다.

저는 어떠한 것이든 처음 배울때는 즐겁게~ 라는 생각을 가지고 있습니다.
실제로 입문서에서 저런 내용을 다룬다면 배우는 입장에서는 대부분 지레 겁먹고 포기하고 말겁니다.
대부분의 C 언어 입문서를 보면 공통적으로 등장하는 것이 있습니다.
그 유명한 "Hello World" 죠.
전 C 를 처음 배울때 그 소스를 가지고 제 이름도 출력해 보고, copy & paste 로 가족들 이름도 출력해보고...
신기하고 재밌다는 것을 느꼈습니다.

C 는 배우면 배울수록 아득하고, 끝이 없다는 것을 느낍니다. 예로 드신 영어도 비슷하죠. ( 저의 내공이 부족한 점이 가장 크지만.. )

배우는 것에는 단계가 있다고 생각합니다. 초보자에게는 초보자의 단계가 있고, 중급자, 고급자에게는 그에 따른 단계에
맞게 배우는게 순서가 옳지 않나 생각합니다.

전 열혈강의 C 를 보지는 않았지만 대부분의 서평은 아주 괜찮았던걸로 기억합니다. 입문서로서 말이죠.

예로 드신 전웅님의 책에 관한 서평을 보면 (전 현재 보고 있는 중입니다... 상당히 난해하네요...;;;.) 7-8년차의 현직 프로그래머조차도
몰랐던(헷갈렸던) 부분을 알게 해줄정도로 깊은 내용인데 그 책 혹은 그와 비슷한 수준의 책을
입문자용으로 요구하기에는 무리가 있다고 생각하며, 단지 그런 기준으로 좋은책과 나쁜책을 구분한다는 것은
이해하기가 힘듭니다.
( 참고로 열혈강의 TCP/IP 는 상당히 괜찮습니다. 입문자용으로서 말이죠... )

전 위의 coldState 님의 의견에 한표 던집니다.
처음 배우는 입장에서는 그 무엇보다 흥미를 가지게 하는 것이 중요하고 C 에서 그 부분은 적절한 output 이라 생각합니다.

전웅씨의 서적을 초급자가 접해야 한다는 글은 아니였습니다.

하나를 알더라도 제대로 알아야 한다는 것입니다.

한국 내의 프로그래머는 문법을 "초급자나 하는 것" 또는 "1학년때 보는 것"으로 취급하는 경향이 많아서 처음 본 책이 그 프로그래머의 미래를 결정할 수 도 있기 때문에 더 중요합니다.

익명 사용자의 이미지

CN wrote:

전웅씨의 서적을 초급자가 접해야 한다는 글은 아니였습니다.

하나를 알더라도 제대로 알아야 한다는 것입니다.

한국 내의 프로그래머는 문법을 "초급자나 하는 것" 또는 "1학년때 보는 것"으로 취급하는 경향이 많아서 처음 본 책이 그 프로그래머의 미래를 결정할 수 도 있기 때문에 더 중요합니다.

CN님의 말씀이 맞습니다.
초심자에게 C의 단맛을 가르치고 나서 제대로 가르쳐야 하는것이 맞습니다.
그러나 학교에서는 1학년 1학기때 C의 포인터도 안나가는 안타까운 사태를 벌이고 나서(대부분의 강사님들이 포인터가 있다고만 하고 넘어가는 경우들이 있습니다. 저는 강사님들 잘 만나서 포인터와 구조체와 Linked-List까지 배웠던 기억이 ㅡㅡ;) 2학기때에는 갑자기 객체지향프로그래밍이라고 C++를 가르치는 것을 보고......
제가 2학년으로 올라가는데 1학기때 바로 자료구조를 배운다고 하네요. 선배님들을 보면 1학년때 수박 겉핥기식으로 배워서 갑자기 2학년 자료구조가 어렵게 느껴지고 컴퓨터공학과에 OTL하는 경우들을 많이 봤습니다.

학교에서는 C언어를 잘 가르치려고 해도 일주일에 2~3시간 수업의 한계로 수박 겉ㅤㅎㅑㄾ기식으로 가르치는 것 같고 애들은 학점만 잘나오면 되지 이런 생각을 하는 것 같습니다.

다들 C언어를 학교에서 배운 것만 대충하면 되지 하는것을 보면서 실력은 자기가 쌓아야 한다는 교훈을 대학 다닌 1년의 기간동안얻었답니다.

C언어 펀더멘탈은 보지는 못했으나 아주 심화된 내용이 있는 것 같습니다. 책을 한번 사서 봐야겠습니다 :D

studioego의 이미지

위에 쓴 글은 제가 쓴 글입니다. 깜빡하고 로그인을 안했네요 :shock:

일찍 일어나는 새가 밥 잘 찾아 먹는다.:D

정태영의 이미지

CN wrote:
int **(*(*pFunc)(double (*pParm1)(int *prm2, double prm3), char *(*pParm2)(int, char)))(float prm1)
이런 코드를 설명할 수 있습니까?

오프토픽이지만 해석이 가능하고 말고 여부를 떠나서... 저런 코드를 만드는 개발자랑은 같이 일하고 싶지 않을 거 같군요. :oops:

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

나는오리의 이미지

Anonymous wrote:
학교에서는 C언어를 잘 가르치려고 해도 일주일에 2~3시간 수업의 한계로 수박 겉ㅤㅎㅑㄾ기식으로 가르치는 것 같고 애들은 학점만 잘나오면 되지 이런 생각을 하는 것 같습니다.

전 강사해본적도 없고 누굴 가르친 적도 없으나
그걸 수박 겉핥기식이라고 말하고 포기한다면 강사보단 학생에게 문제가 있는 겁니다.

대학교는 고등학교가 아닙니다.

kooya의 이미지

욕심많은오리 wrote:
kooya wrote:

#deifne <stdio.h>
int main()
{
printf("Hello World\n");
return 0;
}

제 머리로는 #define <stdio.h>가 오타라고 보는데요.
그 아래에 너무나도 열심히 설명하셔서 혹시 -_-; 되는게 아닐까?
라고도 생각했습니다. -_-;;;;

#define -> #include

#include <stdio.h>

욕심많은 오리님 감사합니다.. 말씀하시기 전까지 잘못 적은줄 몰랐습니다. 머리속에 #define이라는게 박혀 있나 봅니다.

greedy 알고리즘

kfmes의 이미지

violino wrote:
The C programming language, Brian W. Kernighan and Dennis M. Ritchie, Prentice Hall, Inc., 1988

이거 넘 구닥다리라서 추천하는 사람이 없나요?
제가 이 책을 좋아하는 이윤 얇아서입니다.
얇다고 결코 무시할 책이 아닙니다.
기본적으로 필요한 것은 다 있습니다.
참고로 저자가 C 언어 개발한 사람중 하나이지요.

남을 갈친다는게 참 힘든 일입니다.
하지만, 지나고 보면 첫번째 수업 준비할때가 가장 열심이었던 것 같아요.
교재는 일단 간단한걸로 정하시고요,
갈치는 사람이 참고서를 많이 봐야 할거예요.
한 챕터 나갈때마다 참고서를 있는데로 다 봐서 꼭 먼저 이해하세요.
그리고, 매시간마다 꼭 진도에 맞는 숙제를 내 주시고요.
그럼

vio:


저도 이책을 추천합니다 :D

----------------------------------------

익명 사용자의 이미지

정태영 wrote:
CN wrote:
int **(*(*pFunc)(double (*pParm1)(int *prm2, double prm3), char *(*pParm2)(int, char)))(float prm1)
이런 코드를 설명할 수 있습니까?

오프토픽이지만 해석이 가능하고 말고 여부를 떠나서... 저런 코드를 만드는 개발자랑은 같이 일하고 싶지 않을 거 같군요. :oops:

함수 포인터 두개를 인자로 받고 함수 포인터를 리턴하는 함수군요.

아니요, 전 같이 일해봤으면 좋겠습니다. :)
현업에서 일하는 분들도 저 정도 물어보면 대부분 잘 모릅니다. 하지만 현업에서 일할 정도면 알아야 한다고 봅니다. C 표준 함수에도 signal 같은 함수가 저런 프로토타입이니까요. 배열의 포인터, 포인터의 배열, 함수 포인터 배열, 배열의 포인터를 리턴하는 함수 등등... 이런 것을 자유롭게 해석할 수 있어야 한다고 봅니다.

그건 그렇고 초심자에게는 쉽게 하는게 저도 좋다고 봅니다. 그리고 제 경험도 마찬가지로 배우는 사람보다 가르치는 사람이 더 많이 배웁니다. 그래서 차라리 가르치는 입장에 서게 하는 것도 좋을 것 같네요.

체스맨의 이미지

웁스, 로긴 잊었네요. 윗글은 제글입니다.

함수 포인터 두개를 인자로 받고 함수 포인터를 리턴하는 함수의 포인터 네요. ^^

Orion Project : http://orionids.org

익명 사용자의 이미지

Anonymous wrote:
CN wrote:

전웅씨의 서적을 초급자가 접해야 한다는 글은 아니였습니다.

하나를 알더라도 제대로 알아야 한다는 것입니다.

한국 내의 프로그래머는 문법을 "초급자나 하는 것" 또는 "1학년때 보는 것"으로 취급하는 경향이 많아서 처음 본 책이 그 프로그래머의 미래를 결정할 수 도 있기 때문에 더 중요합니다.

CN님의 말씀이 맞습니다.
초심자에게 C의 단맛을 가르치고 나서 제대로 가르쳐야 하는것이 맞습니다.
그러나 학교에서는 1학년 1학기때 C의 포인터도 안나가는 안타까운 사태를 벌이고 나서(대부분의 강사님들이 포인터가 있다고만 하고 넘어가는 경우들이 있습니다. 저는 강사님들 잘 만나서 포인터와 구조체와 Linked-List까지 배웠던 기억이 ㅡㅡ;) 2학기때에는 갑자기 객체지향프로그래밍이라고 C++를 가르치는 것을 보고......
제가 2학년으로 올라가는데 1학기때 바로 자료구조를 배운다고 하네요. 선배님들을 보면 1학년때 수박 겉핥기식으로 배워서 갑자기 2학년 자료구조가 어렵게 느껴지고 컴퓨터공학과에 OTL하는 경우들을 많이 봤습니다.

학교에서는 C언어를 잘 가르치려고 해도 일주일에 2~3시간 수업의 한계로 수박 겉ㅤㅎㅑㄾ기식으로 가르치는 것 같고 애들은 학점만 잘나오면 되지 이런 생각을 하는 것 같습니다.

다들 C언어를 학교에서 배운 것만 대충하면 되지 하는것을 보면서 실력은 자기가 쌓아야 한다는 교훈을 대학 다닌 1년의 기간동안얻었답니다.

C언어 펀더멘탈은 보지는 못했으나 아주 심화된 내용이 있는 것 같습니다. 책을 한번 사서 봐야겠습니다 :D

대학생정도라면 C언어의 문법정도는 혼자서 알아서 터득해야하는것이 아닌가요? 중고등학생들도 혼자서 책보고 하던데.....
그런걸 대학에서 세세히 가르친다는게 낭비라는 생각입니다.

익명 사용자의 이미지

정태영 wrote:
CN wrote:
int **(*(*pFunc)(double (*pParm1)(int *prm2, double prm3), char *(*pParm2)(int, char)))(float prm1)
이런 코드를 설명할 수 있습니까?

오프토픽이지만 해석이 가능하고 말고 여부를 떠나서... 저런 코드를 만드는 개발자랑은 같이 일하고 싶지 않을 거 같군요. :oops:

입문자에게 저런것을 설명해야 할만한 책을 권해야 한다면

당연 틀렸다 라고 말씀 드릴수 있을것입니다

저런 코드를 쓰는건 대부분의 경우에 잘못된 프로그래밍이며

유지 보수가 불가능하고 , 이렇게 짜고도 스스로 왜 이렇게 짰을까 후회 할만한 코드입니다

문법을 위한 문법공부는 프로그래밍에서 정말 쓰레기라고 생각됩니다

논리가 있으면 그것을 이해하기 쉽고 확장성있게 코딩하는게
프로그래밍이지 문법을 위한 문법 공부는 껍데기에 목매는거와 같다고 생각합니다

익명 사용자의 이미지

CN wrote:
pleasantman wrote:
열혈강의 C프로그래밍(윤성우저) 책을 추천하죠..
내용 쉽구요.. 인터넷 강의 먼저 들으시고.. 신입생에게
설명하시면 될 것 같습니다. 책 내용도 쉽구요...
인터넷 강의도 적절 한 것으로 보입니다. 아니면 머 먼저 인터넷
강의 듣게 하시고 모르는 것에 대해서 질의하는 것도 좋구요..

저도 비슷한 방법으로 사용해서 이 책으로 사내 C강의를 진행 했었는데.. 반응이 괜찮더군요..

저는 이 책을 매우 비추하는 편입니다.

이 책을 읽고
int **(*(*pFunc)(double (*pParm1)(int *prm2, double prm3), char *(*pParm2)(int, char)))(float prm1)
이런 코드를 설명할 수 있습니까? 이 코드가 "귀찮아서" 못 풀어야지 "예외적이어서" 못푸는 책은 예외로 가득찬 "성문종합영어"에 불과합니다. 이외에도 이 책은 다른 한국책들처럼 나름대로 공식을 만들고 그 것에 벗어나는 사례들을 "예외"로 만들어 버립니다. 이 책의 의의는 다른 "성문종합영어"류 책보다 쉬운 "맨투맨 영어" 정도의 의의라고 할까요?

국내서 중에 이것을 제대로 푸는 책은 전웅씨가 쓴 책 밖에 본적이 없는 것 같습니다. 그러나 이 책으로 스터디를 하기에는 무리가 있겠군요.

PS: 나는 열혈강의 C 프로그래밍 밖에 보지 못했지만 이 책때문에 열혈강의란 브랜드 자체가 나쁘게 여겨집니다. 이번에 새로 나온 포인터 책 역시 시중에 나와있는 "포인터"를 다룬 다른 엉터리 책과 비슷하지 않을까 편견을 가지고 있습니다.

님과 같은분이 추천한 교재로 공부하고 , 님이 강의했다면 아마 전 프로그래머의 길을 가지 못했을거 같습니다

neatnet의 이미지

kfmes wrote:
violino wrote:
The C programming language, Brian W. Kernighan and Dennis M. Ritchie, Prentice Hall, Inc., 1988

이거 넘 구닥다리라서 추천하는 사람이 없나요?
제가 이 책을 좋아하는 이윤 얇아서입니다.
얇다고 결코 무시할 책이 아닙니다.
기본적으로 필요한 것은 다 있습니다.
참고로 저자가 C 언어 개발한 사람중 하나이지요.

남을 갈친다는게 참 힘든 일입니다.
하지만, 지나고 보면 첫번째 수업 준비할때가 가장 열심이었던 것 같아요.
교재는 일단 간단한걸로 정하시고요,
갈치는 사람이 참고서를 많이 봐야 할거예요.
한 챕터 나갈때마다 참고서를 있는데로 다 봐서 꼭 먼저 이해하세요.
그리고, 매시간마다 꼭 진도에 맞는 숙제를 내 주시고요.
그럼

vio:


저도 이책을 추천합니다 :D

제가 예전에 모 대학에서 강의할 때 사용했던 책이기도 한데요
아마 이 책으로 가르치시려면 만만치 않을겁니다.

책 자체는 추천할만 하지만 챕터 1에서 C의 전반적인 내용을
다 훑어보게 한다던가(처음 배우는 사람은 난감하죠)
각 챕터의 소스코드가 연계성이 있어서 초심자가 그냥 설명없이
각 페이지의 예제를 보고 바로 실행해보기 어렵다는 문제가 있죠.
게다가 상당히 효율적(?)인 코드로 작성된 예제라
초심자가 쉽게 파악하기에 어려운 코드도 꽤 되구요.

결정적으로 유닉스 상에서 C를 학습하는걸 기준으로 한 터라
윈도우 환경에서 C를 가르치는 경우에는 다소 부적합한
교재라고 할 수 있겠죠.

불량도ㅐㅈㅣ의 이미지

int **(*(*pFunc)(double (*pParm1)(int *prm2, double prm3), char *(*pParm2)(int, char)))(float prm1)

이거 실제로 많이 쓰는 문법입니까?

제가 보기에도 문법을 위한 문법 같은데요.

어차피 중요한 것은 알고리즘이지 않나요?

문근영 너무 귀여워~~

itsocool의 이미지

Anonymous wrote:
정태영 wrote:
CN wrote:
int **(*(*pFunc)(double (*pParm1)(int *prm2, double prm3), char *(*pParm2)(int, char)))(float prm1)
이런 코드를 설명할 수 있습니까?

오프토픽이지만 해석이 가능하고 말고 여부를 떠나서... 저런 코드를 만드는 개발자랑은 같이 일하고 싶지 않을 거 같군요. :oops:

함수 포인터 두개를 인자로 받고 함수 포인터를 리턴하는 함수군요.

아니요, 전 같이 일해봤으면 좋겠습니다. :)
현업에서 일하는 분들도 저 정도 물어보면 대부분 잘 모릅니다. 하지만 현업에서 일할 정도면 알아야 한다고 봅니다. C 표준 함수에도 signal 같은 함수가 저런 프로토타입이니까요. 배열의 포인터, 포인터의 배열, 함수 포인터 배열, 배열의 포인터를 리턴하는 함수 등등... 이런 것을 자유롭게 해석할 수 있어야 한다고 봅니다.

그건 그렇고 초심자에게는 쉽게 하는게 저도 좋다고 봅니다. 그리고 제 경험도 마찬가지로 배우는 사람보다 가르치는 사람이 더 많이 배웁니다. 그래서 차라리 가르치는 입장에 서게 하는 것도 좋을 것 같네요.

또다른 오프토픽이지만 한가지 덧붙이자면 인용된 코드를 이해할수 있는 능력은 있어야 겠지만 저런식의 코드는 현업에서 가장 피해야할 코드입니다. 저런식의 코드는 연구용 또는 학습용 그 이상도 그 이하도 아닙니다. 현업 이라 칭하는 곳에서는 연구나 공부 하는곳이 아닌 상품을 만드는 곳입니다. 그렇기에 저런 코드는 상업적으로 가치가 그다지 없다고 생각합니다. 프로그래머는 더이상 공대생이 아닌 회사원 이니까요.

언제나 먼저 고려해야할 대상은 사람이 아니던가?
안되면 대기하라.
즐길 수 없다면 피하라.

ironiris의 이미지

정말 그 코드를 국내서중에서는 전웅님이 적으신 책만이 설명가능한가요??
C입문서의 거의 전부는 "함수는 포인터를 인자로 받고 리턴할수 있다"고 가르치지 않나요??
그 내용의 확장으로 보입니다만..
(저는 사이비 코더라 저런 복잡한 코드를 지금 처음봤습니다. 기껏해야 함수 포인터 하나정도 쓴거만 봤죠)
---
조사 수정.

체스맨의 이미지

itsocool wrote:

저것을 이해할수 있는 능력은 있어야 겠지만 저런식의 코드는 현업에서 가장 피해야할 코드입니다. 저런식의 코드는 연구용 또는 학습용 그 이상도 그 이하도 아닙니다. 현업 이라 칭하는 곳에서는 연구나 공부 하는곳이 아닌 상품을 만드는 곳입니다. 그렇기에 저런 코드는 상업적으로 가치가 그다지 없다고 생각합니다. 프로그래머는 더이상 공대생이 아닌 회사원 이니까요.

예 저도 그렇게 생각합니다만, 때로는 저 정도 까지는 아니어도 비슷한 경우가 생기긴 해요. 이미 말씀드렸지만, signal 같이 C 표준함수에도 있는 것을 보면 분명이 필요할 때는 있으니까요.

signal 함수의 포인터를 변수에 넣으려면 저런식의 선언이 필요할텐데, 표현이 복잡해지길 원하지 않는다면 typedef 를 써야겠죠. 아무튼 경험상 저런 상황은 전체 개발 중에 극히 일부입니다.

하지만, 의아한 것은 저런 것을 해석하지 못하는 사람들이 현업에서 의외로 많다는 점입니다. 특히 저와는 달리 컴퓨터 관련 전공하신 분들인데요. C 언어는 대부분 마스터하고 나오시는 게 아닌가 하는 제 선입관일지도 모르겠네요.

어쨌든 배울때는 쉽고 재밌게! 저도 처음 독학할 때는 책읽다가 포인터를 만난뒤, 볼랜드 그래픽 라이브러리 함수 호출해보는 쪽으로 샜었거든요. 저런 표현이 아무리 책에 설명에 나온다 해도, 제 생각에는 저것을 쓰는 상황을 겪을만큼 세월을 쌓아야 한다고 봅니다.

Orion Project : http://orionids.org

doldori의 이미지

불량도ㅐㅈㅣ wrote:
int **(*(*pFunc)(double (*pParm1)(int *prm2, double prm3), char *(*pParm2)(int, char)))(float prm1)

이거 실제로 많이 쓰는 문법입니까?


현업에서 이 모양을 그대로 쓰지는 않습니다. 너무나 가독성이 떨어져서요.
보통 typedef를 해서 쓰죠. 그런데 기본적으로는 이 선언의 의미를 이해할 수
있어야 typedef도 쓸 수가 있습니다. typedef를 쓰면 이런 식이 됩니다.
typedef double (*Parm1)(int*, double);
typedef char*  (*Parm2)(int, char);
typedef int**  (*Ret)(float);

Ret (*pFunc)(Parm1, Parm2);
wkpark의 이미지

신입생에게 가르치는 것이 제가 생각하기엔 가장 중점적인 부분인 것 같군요.
c는 여기서 단지 도구일 뿐입니다.
c의 특정 문법을 이해하는데 힘을 쏟기 보다는,
프로그래밍이란 이런거다는 것을 신입생들에게 맛보게 하는게 가장 중요할 듯.
단지 문법만 이해한다고 마스터되는게 프로그래밍이 아니겠죠.

온갖 참된 삶은 만남이다 --Martin Buber

doldori의 이미지

neatnet wrote:
결정적으로 유닉스 상에서 C를 학습하는걸 기준으로 한 터라
윈도우 환경에서 C를 가르치는 경우에는 다소 부적합한
교재라고 할 수 있겠죠.

TCPL 마지막 장에 UNIX와 관련된 내용을 다루기는 하지만 나머지 내용은 모두
표준 C입니다. 윈도우 환경에서 익힌다고 해도 전혀 부적합한 내용이 아닙니다.
lifthrasiir의 이미지

wkpark wrote:
신입생에게 가르치는 것이 제가 생각하기엔 가장 중점적인 부분인 것 같군요.
c는 여기서 단지 도구일 뿐입니다.
c의 특정 문법을 이해하는데 힘을 쏟기 보다는,
프로그래밍이란 이런거다는 것을 신입생들에게 맛보게 하는게 가장 중요할 듯.
단지 문법만 이해한다고 마스터되는게 프로그래밍이 아니겠죠.

그렇지만 그 도구를 잘 이해하는 것도 중요하다고 생각합니다. 특히 컴공과나 전산학과라면 프로그래밍의 이해와 도구의 이해를 함께 중점적으로 다뤄야 할텐데 안타깝게도 그렇게 하지 못 하는 경우가 많은 걸로 압니다. (교양 프로그래밍이라면 파이썬이나 루비 쓰고 말겠습니다만)

- 토끼군

익명 사용자의 이미지

doldori wrote:
neatnet wrote:
결정적으로 유닉스 상에서 C를 학습하는걸 기준으로 한 터라
윈도우 환경에서 C를 가르치는 경우에는 다소 부적합한
교재라고 할 수 있겠죠.

TCPL 마지막 장에 UNIX와 관련된 내용을 다루기는 하지만 나머지 내용은 모두
표준 C입니다. 윈도우 환경에서 익힌다고 해도 전혀 부적합한 내용이 아닙니다.

물론 표준 C이기 때문에 윈도우 환경에서 해도 부적합하진 않죠.
그런데 도스/윈도우 환경에서 강의할때와
리눅스 환경에서 강의할때를 비교했을때
왠지 좀 껄끄럽더군요.

doldori의 이미지

Anonymous wrote:
doldori wrote:
neatnet wrote:
결정적으로 유닉스 상에서 C를 학습하는걸 기준으로 한 터라
윈도우 환경에서 C를 가르치는 경우에는 다소 부적합한
교재라고 할 수 있겠죠.

TCPL 마지막 장에 UNIX와 관련된 내용을 다루기는 하지만 나머지 내용은 모두
표준 C입니다. 윈도우 환경에서 익힌다고 해도 전혀 부적합한 내용이 아닙니다.

물론 표준 C이기 때문에 윈도우 환경에서 해도 부적합하진 않죠.
그런데 도스/윈도우 환경에서 강의할때와
리눅스 환경에서 강의할때를 비교했을때
왠지 좀 껄끄럽더군요.


그것은 손님의 OS 선호도에 관한 문제일 뿐, TCPL이 "윈도우 환경에서 C를 가르치는
경우에는 다소 부적합한 교재"인 이유는 될 수 없습니다.
doldori의 이미지

ironiris wrote:
정말 그 코드를 국내서중에서는 전웅님이 적으신 책만이 설명가능한가요??

그렇지는 않습니다. 이 코드를 이해하는 데는 입문서 수준의 지식만으로 충분합니다.

ironiris wrote:
C입문서의 거의 전부는 "함수는 포인터를 인자로 받고 리턴할수 있다"고 가르치지 않나요??
그 내용의 확장으로 보입니다만..

맞습니다. 이 선언을 이해하는 위해서는 함수 선언과 함수 포인터에 관한 입문서
수준의 문법을 기계적으로 적용하면 됩니다. 복잡한 선언이니만큼 그 의미를 이해하는 데
시간이 좀 더 걸릴 뿐입니다.
제가 보기에 복잡한 선언을 겁내는 이유는 익숙하지 않다는 단순한 이유인 것 같습니다.
서너 번 해보면 별 거 아니라는 것을 금방 아시게 될 겁니다.
죠커의 이미지

Anonymous wrote:
님과 같은분이 추천한 교재로 공부하고 , 님이 강의했다면 아마 전 프로그래머의 길을 가지 못했을거 같습니다

제대로 된 "입문서"가 있다면 그 입문서를 보고 혼자 생각해서 답을 얻을 수 있는 코드입니다.

Quote:
1+2+3+(4*2+(3-5*2-4)*6+2)-5

손님이 보시기에는 위의 수식이 어렵습니까?

많은 분이 말씀하셨듯 예전에 언급한 코드는 "쓰레기 같은 코드"이고 이번에 언급한 수식도 쓰레기 같은 수식입니다만 대부분의 사람들은 이 수식이 단지 귀찮은 것에 불과할 것입니다.

제대로 익혔다면 제가 언급한 쓰레기 코드 역시 단지 "귀찮은 것"에 불과했어야 옳습니다.

헐헐 wrote:
입문자에게 저런것을 설명해야 할만한 책을 권해야 한다면

당연 틀렸다 라고 말씀 드릴수 있을것입니다

헐헐님은 초등학생에게 구구단을 이야기하고 일반화된 사칙연산을 가르치는 일이 잘못된 일이라고 생각하십니까? 제대로된 입문서를 보았다면 "귀찮은 일"이 되었어야 하는 일입니다.

헐헐 wrote:
저런 코드를 쓰는건 대부분의 경우에 잘못된 프로그래밍이며

유지 보수가 불가능하고 , 이렇게 짜고도 스스로 왜 이렇게 짰을까 후회 할만한 코드입니다

일부러 "귀찮은 코드"를 고른 것입니다.

헐헐 wrote:
문법을 위한 문법공부는 프로그래밍에서 정말 쓰레기라고 생각됩니다

여기에 대해서는 동의하지 않습니다. 템플릿 부분 특화를 이해하지 못한다면 템플릿 메타 프로그래밍이 불가능합니다. 프로그래머라면 설계에 대해서도 심각하게 고민하면서 쉬지 않고 문법 그 자체를 공부해야 한다고 생각합니다.

헐헐 wrote:
논리가 있으면 그것을 이해하기 쉽고 확장성있게 코딩하는게
프로그래밍이지 문법을 위한 문법 공부는 껍데기에 목매는거와 같다고 생각합니다

템플릿을 이용한 수 많은 "효과적이고" "확장성있는" 코드는 문법에 대한 공부없이는 불가능합니다.

doldori wrote:
ironiris wrote:
정말 그 코드를 국내서중에서는 전웅님이 적으신 책만이 설명가능한가요??

그렇지는 않습니다. 이 코드를 이해하는 데는 입문서 수준의 지식만으로 충분합니다.

입문서 수준의 지식이 필요하다는 것에는 공감합니다만 국내서 중에서 제대로 된 서적을 거의 본 적이 없는 것 같습니다. doldori님이 보신 추천할만한 국내서는 어떤 것인가요?

xster의 이미지

입문서로 제대로 된 서적이 없다지만 책으로만 공부하는 것이 아니기 때문에 책 내용을 기반으로 잘못된 내용, 추가할 내용을 강의하시는 분의 능력 껏 추가, 수정하신다면 좋은 입문서 교제로 사용할 수 있을 거라 생각됩니다.

제가 입문서를 많이 안 봐서 어떤 책이 좋을지 언급하지는 않겠지만 전웅님의 책을 입문서로 쓰기엔 일반적으로 쉽지 않을 것 같습니다.

doldori의 이미지

CN wrote:
doldori wrote:
ironiris wrote:
정말 그 코드를 국내서중에서는 전웅님이 적으신 책만이 설명가능한가요??

그렇지는 않습니다. 이 코드를 이해하는 데는 입문서 수준의 지식만으로 충분합니다.

입문서 수준의 지식이 필요하다는 것에는 공감합니다만 국내서 중에서 제대로 된 서적을 거의 본 적이 없는 것 같습니다. doldori님이 보신 추천할만한 국내서는 어떤 것인가요?


음... 이렇게 물으시니 저도 대답할 말이 궁해지는군요. 국내서는 '터보 C 정복'과
'C 언어 펀더멘탈'밖에 보지 않았거든요. 전자는 너무 오래 되었고 걸러낼 내용이
많아서 추천하기는 힘들고, 후자는 자신있게 추천할 만한 책이지만 입문서라고
할 수는 없고...
제가 위에서 "입문서 수준의 지식"이라고 한 것은 설마 이 정도야 다들 다루겠지
하는 짐작에서 한 말인데, CN님이 보시기에는 그렇지도 않은가 봅니다.
무책임한 답변 죄송합니다. ^^;
죠커의 이미지

xster wrote:
제가 입문서를 많이 안 봐서 어떤 책이 좋을지 언급하지는 않겠지만 전웅님의 책을 입문서로 쓰기엔 일반적으로 쉽지 않을 것 같습니다.

전웅씨의 책을 입문서로 쓰기에 부적절하다는 것에는 동의합니다. 전웅씨의 이름을 꺼낸 것은 국내서의 현실이 나쁘다는 생각에 이야기를 꺼낸 것입니다.

doldori wrote:
음... 이렇게 물으시니 저도 대답할 말이 궁해지는군요. 국내서는 '터보 C 정복'과
'C 언어 펀더멘탈'밖에 보지 않았거든요. 전자는 너무 오래 되었고 걸러낼 내용이
많아서 추천하기는 힘들고, 후자는 자신있게 추천할 만한 책이지만 입문서라고
할 수는 없고...

그러고 보니 저도 터보 C 정복은 잘 보았던 것 같습니다. 표준에 맞지 않은 부분이나 컨벤션의 강요가 아쉬운 부분이지만 당시로서는 훌륭했던 책인 것 같습니다. 그만한 책이 요즘에는 없는 것 같으니깐요.

지리즈의 이미지

CN wrote:
그러고 보니 저도 터보 C 정복은 잘 보았던 것 같습니다. 표준에 맞지 않은 부분이나 컨벤션의 강요가 아쉬운 부분이지만 당시로서는 훌륭했던 책인 것 같습니다. 그만한 책이 요즘에는 없는 것 같으니깐요.

갑자기 생각나는데,
어느 일본 서적 번역본이었던 것 같은데,
포인터 완정정복인가 뭔가 제목은 기억안나는 책이었습니다.

하여튼 인상적인 것은
포인터에 관한 문제!가 500개인가 1000개인가 있는 겁니다.
내용 구성이 챕터별로 간단한 설명과 함께,
이해를 돕기위한 예제문제 2~3개..
그리고, 실전문제가 줄줄이... ㅎㅎ

대학 입학 직후 읽었는데,
고등학교때 입시에 단련된 실력으로 도전하니,
아주 이해도 빠르고, 재미도 있더군요...

하여튼, 한국입시문화나 일본 입시 문화나 똑같나 봅니다.

포인터는 완정정복했냐고 물으신다면,
뭐라고 말씀은 못드리겠지만,
적어도 주변사람들보다는 심도(?)있는 이해력을
가진 것은 확실하더군요...

There is no spoon. Neo from the Matrix 1999.

violino의 이미지

정태영 wrote:
CN wrote:
int **(*(*pFunc)(double (*pParm1)(int *prm2, double prm3), char *(*pParm2)(int, char)))(float prm1)
이런 코드를 설명할 수 있습니까?

오프토픽이지만 해석이 가능하고 말고 여부를 떠나서... 저런 코드를 만드는 개발자랑은 같이 일하고 싶지 않을 거 같군요. :oops:

역시 오프토픽이지만, 저런 코드 살다보면 많이 나옵니다.
돌도리님이 말씀하신대로 단지 포인터가 여러번 나올 뿐이지 난이도가 높은것은 아니라고 생각됩니다.
(저 역시 저런 것 보기는 싫습니다. 하지만 어쩝니까. 먹고 살려면..^^)

익명 사용자의 이미지

CN wrote:

Quote:
1+2+3+(4*2+(3-5*2-4)*6+2)-5

손님이 보시기에는 위의 수식이 어렵습니까?

많은 분이 말씀하셨듯 예전에 언급한 코드는 "쓰레기 같은 코드"이고 이번에 언급한 수식도 쓰레기 같은 수식입니다만 대부분의 사람들은 이 수식이 단지 귀찮은 것에 불과할 것입니다.

제대로 익혔다면 제가 언급한 쓰레기 코드 역시 단지 "귀찮은 것"에 불과했어야 옳습니다.

글세요 비유가 적절치 않은거 같습니다

님이 말씀하신 내용은 억지로 어렵게 쓴 내용인데 , 귀찬은 내용으로 비유하며 말씀하셨네요. 비슷한거 같지만 맞지 않은 비유입니다

그리고
제가 초보일때 이런 억지스러운 코드들을 알라고 강요한 책들은 어느정도 수준에 이른 저에게, 아직도 쓰잘때기 없는 내용이라 생각됩니다

CN wrote:

헐헐 wrote:
입문자에게 저런것을 설명해야 할만한 책을 권해야 한다면

당연 틀렸다 라고 말씀 드릴수 있을것입니다

헐헐님은 초등학생에게 구구단을 이야기하고 일반화된 사칙연산을 가르치는 일이 잘못된 일이라고 생각하십니까? 제대로된 입문서를 보았다면 "귀찮은 일"이 되었어야 하는 일입니다.

님은 수학에서 중요한게 암기라고 생각하나요 아니면 논리적인 생각이라고 생각하나요?

CN님은 중요한 우선 순위를 뒤바꿔 생각하시는거 같아서 말씀 드렸습니다 . 구구단 가르치는게 잘못됐다는것이 아니라 구구단 자체가 중요하다는 듯한 발언을 하시고 계신것에 대해 문제를 삼았습니다 특히 그 특이한 문법 자체를 설명하는 책이 없다고 해서 초보자들이 볼책이 없다는 식은 지나친 오바라는겁니다

CN wrote:

헐헐 wrote:
저런 코드를 쓰는건 대부분의 경우에 잘못된 프로그래밍이며

유지 보수가 불가능하고 , 이렇게 짜고도 스스로 왜 이렇게 짰을까 후회 할만한 코드입니다

일부러 "귀찮은 코드"를 고른 것입니다.

그래서 원하시는 봐가 정확히 무언가요?

CN wrote:

헐헐 wrote:
문법을 위한 문법공부는 프로그래밍에서 정말 쓰레기라고 생각됩니다

여기에 대해서는 동의하지 않습니다. 템플릿 부분 특화를 이해하지 못한다면 템플릿 메타 프로그래밍이 불가능합니다. 프로그래머라면 설계에 대해서도 심각하게 고민하면서 쉬지 않고 문법 그 자체를 공부해야 한다고 생각합니다.

저도 님에 말씀에 동의 하지 않는건 마찬가지입니다
문법을 익혀 특정 프로그래밍 방법을 익히는것은 좋지만

입문자에게 중요한건 알고리즘과 논리이지 입문자에게 템플릿 운운하는것 자체가 오바입니다.

CN wrote:

헐헐 wrote:
논리가 있으면 그것을 이해하기 쉽고 확장성있게 코딩하는게
프로그래밍이지 문법을 위한 문법 공부는 껍데기에 목매는거와 같다고 생각합니다

템플릿을 이용한 수 많은 "효과적이고" "확장성있는" 코드는 문법에 대한 공부없이는 불가능합니다.

님은 같은 이야기를 계속 반복하고 있습니다 , 님은 C++ 프로그래밍을 수준급으로 하려는 사람에게나 할만한 소리입니다

나는오리의 이미지

닭이 먼저일까요 달걀이 먼저일까요?

익명 사용자의 이미지

여담이지만 CN님이 C언어 배울려는 사람에게 왜 C++ 문법을 그리 강조하시는지 잘모르겠습다만

C언어를 배우는것은 아마 C언어 문법을통해 기초 알고리즘 및 자료구조를 배우려는게 목적이 아니겠습니까?

특정 문법을 마스터하여 그 언어의 고수가 되려는 사람에게 조언하는게 아니라면 CN님 주장은 부적절한게 아닌가 싶습니다

ps

CN님의 성향을 볼떄 , C++ 말 나오면 Object C++가 더 낫니 뭐니 C++ 깎아 내리기 여념이 없으신걸로 봤는데 , 드디어 C++의 맛을 깨닭으셨는지
계속 C++ 문법 비유를 하시네요

shji의 이미지

음.. 어차피 맘에 꼭 맞는 교재를 찾기는 힘들지 않을까요?
반대로 기본에 충실하고 오류가 별로 없는 책이라면 어떤 책이든
교재 사용에 무리가 없을 것으로 봅니다.
정말 중요한 것은 강의하시는 분이 전달하고자 하는 내용을
얼마나 잘 이해해고 효과적으로 전달하느냐일 듯...^^
프로그래밍 언어 교육은 단순한 문법의 숙지나 전달이 아니라
좋은 프로그램을 만들기 위한 위한 종합적 내용이 포함되야
한다고 생각합니다..
사실 프로그래밍 관련하여 받은 교육 중에서 정말 효과적이었다라고
생각되는 경우는 하나도 없었지만요.. 제가 비교적 오래전에 경험한
것들이라 지금은 훨씬 좋아졌을거라 생각합니다..^^;

lovewar의 이미지

sungdh86 wrote:
제가 06학번 애들에게 C언어를 가르쳐 줘야 할것 같습니다.
C언어를 배우는 입장에서는 선배한테서 If문, switch case문, break, 같은 조건문과 #include, #define과 같은 전처리문과 간단한 구조체정도를 배웠거든요
이제 가르치는 입장에서 하자니 막막하네요.
제가 C언어를 가르치게 될 입장이 되니까 걱정이 앞섭니다.
C언어를 가르칠때 책보고 책을 떼게 하는 식으로 가르칠까? 아니면 제 머릿속에서 생각나는 데로 할까?(공부 죽어라해야겠죠?) 아니면 책 던지고 나서 질문할것 질문하고 할까?
이런 생각들이 머리속에서 듭니다.

고수님들은 후배들에게 C언어 가르칠때 어떤 방식으로 가르쳤습니까?



학교 도서관에서 C언어관련 서적을 참조로 하여
정리한 문서를 가리치는 것이 좋을 것 같습니다.

책마다 장단점이 있으며 또한, 신입생들도 이해력이 다양하기
때문에 한 책으로 가리칠 필요는 없을것 같습니다.

방향을 잡아주는 선배가 있기 때문에
입문서를 볼 필요는 없을것 같습니다.

monovision의 이미지

플로우 챠트를 활용한 방법도 한번 생각해보면 좋을꺼 같습니다.
문법을 어느정도 배우고 프로그래밍에서 막히는 부분은 생각을 옮기는 과정같습니다. 그럴때 플로우 챠트나 다이어그램, UML (C에서는 좀 그렇나요 ?),
pseudocode 등을 활용하면 좋지 않을까요 ?

문법을 한 번 리뷰 정도로만 해주고
( for 문과 while 문은 구문을 반복해서 실행할 수 있고 그 문법은 이러이러하다눈 식이겠죠.. )
후에 간단한 문제에 대한 해결책을 플로우 챠트나 다이어그램으로 그려보게 하는 겁니다. 그리고 그 결과물을 보고 C 로 코딩하게 한다면
어디서 잘못 됐는지. 어떠한 부분을 고쳐야 하는지
( C 코드가 잘못 됐는지 아니면, 해결책 자체의 문제인지 )
보다 명확하게 알 수 있지 않나 생각합니다.

죠커의 이미지

Anonymous wrote:
여담이지만 CN님이 C언어 배울려는 사람에게 왜 C++ 문법을 그리 강조하시는지 잘모르겠습다만

실수를 인정합니다.

Anonymous wrote:
CN님의 성향을 볼ㅤㄸㅒㅤ , C++ 말 나오면 Object C++가 더 낫니 뭐니 C++ 깎아 내리기 여념이 없으신걸로 봤는데 , 드디어 C++의 맛을 깨닭으셨는지
계속 C++ 문법 비유를 하시네요

예전부터 C++ 언어에 관심이 있었지만 언제나 새로운 언어를 접할려고 노력했습니다. 무엇이 문제인가요? 내 글에 관심을 가져주신 것은 감사히게 생각합니다.

죠커의 이미지

Anonymous wrote:
글세요 비유가 적절치 않은거 같습니다

님이 말씀하신 내용은 억지로 어렵게 쓴 내용인데 , 귀찬은 내용으로 비유하며 말씀하셨네요. 비슷한거 같지만 맞지 않은 비유입니다

그리고
제가 초보일때 이런 억지스러운 코드들을 알라고 강요한 책들은 느정도 수준에 이른 저에게, 아직도 쓰잘때기 없는 내용이라 생각됩니다.

구구단 하나를 알면 사칙 연산은 아무리 꼬아두어도 "귀찮은 일"에 불과하듯이 (), [], *에 대한 "명칭"만 알고 있다면 포인터 역시 아무리 꼬아도 "귀찮은 일"에 불과합니다.

() 가 function returning이라는 것, []가 array of라는 것, *가 pointer to 라는 것. 이 것을 외우는 일이 그렇게 힘들고 비효과적이고 심지어는 쓰레기 같다고 생각하시는 것은 아니겠지요? 여기에 대해서 동의하지 않으신다면 더 이상 할말은 없습니다.

익명 사용자의 이미지

CN wrote:
Anonymous wrote:
여담이지만 CN님이 C언어 배울려는 사람에게 왜 C++ 문법을 그리 강조하시는지 잘모르겠습다만

실수를 인정합니다.

Anonymous wrote:
CN님의 성향을 볼ㅤㄸㅒㅤ , C++ 말 나오면 Object C++가 더 낫니 뭐니 C++ 깎아 내리기 여념이 없으신걸로 봤는데 , 드디어 C++의 맛을 깨닭으셨는지
계속 C++ 문법 비유를 하시네요

예전부터 C++ 언어에 관심이 있었지만 언제나 새로운 언어를 접할려고 노력했습니다. 무엇이 문제인가요? 내 글에 관심을 가져주신 것은 감사히게 생각합니다.

그랬던가요? ㅎㅎ
어째튼 다행입니다

나중에 C++ 언어에 대해 토론이 나오면 님의 C++에 대한 악플성 답글을 보지 않을거 같네요 ,

특히 C++ 토론하는데
object C 언급하며 C++ 비하할대면 승질이 많이 났거든요
예전보다 C++에 대해 이해도가 높아지신거 기쁘네요

앞으로 좀더 긍정적인 토론이 가능하겠군요

죠커의 이미지

Anonymous wrote:
나중에 C++ 언어에 대해 토론이 나오면 님의 C++에 대한 악플성 답글을 보지 않을거 같네요 ,

특히 C++ 토론하는데
object C 언급하며 C++ 비하할대면 승질이 많이 났거든요
예전보다 C++에 대해 이해도가 높아지신거 기쁘네요

앞으로 좀더 긍정적인 토론이 가능하겠군요

C++은 명백한 장점과 단점을 가진 흥미로운 언어라고 생각하기 때문에 C++을 옹호하기도 하고 비하하기도 할 것 같습니다. 본의 아니게 기분이 나쁘신 부분이 있었다면 사과드리며 건설적인 토론을 생각하겠습니다.

creativeidler의 이미지

Quote:
그랬던가요? ㅎㅎ
어째튼 다행입니다

나중에 C++ 언어에 대해 토론이 나오면 님의 C++에 대한 악플성 답글을 보지 않을거 같네요 ,

특히 C++ 토론하는데
object C 언급하며 C++ 비하할대면 승질이 많이 났거든요
예전보다 C++에 대해 이해도가 높아지신거 기쁘네요

앞으로 좀더 긍정적인 토론이 가능하겠군요

Objective C vs C++ 토론이라면 저와 CN님의 토론을 말씀하시는 것 같은데 제 기억으로는 그 쓰레드에서 CN님이 악플성 답글을 달았던 것 같진 않습니다. 나름대로 자신의 관점에서 C++이 단점이라고 생각되는 부분들을 지적한 것이고 토론에서 그런 건 당연한 것이죠. 이런 걸 악플로 받아들인다면 긍정적인 토론은 불가능합니다.

그리고 C++을 비하한다고 승질이 나는 상황..남의 감정 가지고 뭐라 할 얘기가 아닌 것 같기도 하지만 프로그래머에게는 바람직하지 않은 태도입니다. 프로그래머 중에 보면 자기가 사용하는 언어를 비판하면 마치 자기를 비판하는 것처럼 화를 내는 사람이 적지 않고 언어 간 비교 토론이 일어날 때마다 꼭 그런 경우가 보이는데 그런 태도는 자기 발전에 커다란 장애가 될 수 있습니다. 냉정하게 자신이 사용하는 도구의 문제점을 돌아볼 수 있는 여유가 필요한 것 같습니다.

익명 사용자의 이미지

CN wrote:

예전부터 C++ 언어에 관심이 있었지만 언제나 새로운 언어를 접할려고 노력했습니다. 무엇이 문제인가요? 내 글에 관심을 가져주신 것은 감사히게 생각합니다.

예전부터 거슬리는 것 한가지만 지적하겠습니다.

"내글"과 같은 표현이 상당히 많으신데, "제"글 맞는것 아닐까요?

표현을 원래부터 그렇게 일상적으로 하시는게 아니라면 "제"글이라고 쓰시거나, 아예 "내"라는 표현을 빼주시거나 하시길

매우 거슬립니다.

hiseob의 이미지

Quote:
예전부터 거슬리는 것 한가지만 지적하겠습니다.

"내글"과 같은 표현이 상당히 많으신데, "제"글 맞는것 아닐까요?

표현을 원래부터 그렇게 일상적으로 하시는게 아니라면 "제"글이라고 쓰시거나, 아예 "내"라는 표현을 빼주시거나 하시길

매우 거슬립니다.

일단 로그인부터 하시죠?

마침 포스트 하신분하고 비슷한 상황입니다. (전 교재 만들고 있습니다 -_-)

난감합니다, 포인터 내용 집어넣자니, 이걸 어렵다고 책을 안보진 않을까.. 하는 걱정이 들정도네요.

죠커의 이미지

Anonymous wrote:
"내글"과 같은 표현이 상당히 많으신데, "제"글 맞는것 아닐까요?

표현을 원래부터 그렇게 일상적으로 하시는게 아니라면 "제"글이라고 쓰시거나, 아예 "내"라는 표현을 빼주시거나 하시길

매우 거슬립니다.

어느 높임법을 어긴 것인가요? 마지막 "매우 거슬립니다."라는 문구에 보면 단순한 감정 표현이라 짐작되지만 확신을 가지기 위해 질문드립니다. 답변에 따라 새로운 토론의 시작이 될 수도 있고 토론의 끝이 될 수도 있을 것입니다.

죠커의 이미지

hiseob wrote:
난감합니다, 포인터 내용 집어넣자니, 이걸 어렵다고 책을 안보진 않을까.. 하는 걱정이 들정도네요.

generic한 방법으로 설명하되 기본적인 형태만 설명하시는 쪽이 무난할 것 같습니다. K&R의 포인터에 대한 내용의 분량 정도면 어떨까요?

익명 사용자의 이미지

creativeidler wrote:
Quote:
그랬던가요? ㅎㅎ
어째튼 다행입니다

나중에 C++ 언어에 대해 토론이 나오면 님의 C++에 대한 악플성 답글을 보지 않을거 같네요 ,

특히 C++ 토론하는데
object C 언급하며 C++ 비하할대면 승질이 많이 났거든요
예전보다 C++에 대해 이해도가 높아지신거 기쁘네요

앞으로 좀더 긍정적인 토론이 가능하겠군요

Objective C vs C++ 토론이라면 저와 CN님의 토론을 말씀하시는 것 같은데 제 기억으로는 그 쓰레드에서 CN님이 악플성 답글을 달았던 것 같진 않습니다. 나름대로 자신의 관점에서 C++이 단점이라고 생각되는 부분들을 지적한 것이고 토론에서 그런 건 당연한 것이죠. 이런 걸 악플로 받아들인다면 긍정적인 토론은 불가능합니다.

그리고 C++을 비하한다고 승질이 나는 상황..남의 감정 가지고 뭐라 할 얘기가 아닌 것 같기도 하지만 프로그래머에게는 바람직하지 않은 태도입니다. 프로그래머 중에 보면 자기가 사용하는 언어를 비판하면 마치 자기를 비판하는 것처럼 화를 내는 사람이 적지 않고 언어 간 비교 토론이 일어날 때마다 꼭 그런 경우가 보이는데 그런 태도는 자기 발전에 커다란 장애가 될 수 있습니다. 냉정하게 자신이 사용하는 도구의 문제점을 돌아볼 수 있는 여유가 필요한 것 같습니다.

님이 여신 Object C 와 C++ 쓰레드에 관한 내용에 대한 이야기가 아닙니다

참고로 말씀드리면 4년전부터 CN님이 C++를 잘 모르면서
, 그 모르는것에 대해 깍아내리기 글들을 많이 보았고

이 사람과는 더이상 C++에 관해서는 긍정적인 토론이 불가능하다고 판단해서 그후로 KLDP에서 이분이 답글을 단것에 대해서는 아예 글을 쓰지 않고 있습니다

오랜만에 와서 이번 CN님 글을 보고 느낀것은 C언어 이야기하는데 템플릿이라는 C++을 문법을 강조하시면서 C++에 대한 이해도가 많이 높아진거 같아 이제좀 대화가 될 수준의 C++ 이해도를 가지신게 아닌가 싶었던겁니다

예전 같았으면 이글에 C누가 C++ 템플릿 문법을 늘어놓으며 문법 강조한 글이 있었으면 CN님은 이런글을 썼겠죠

"C++은 템플릿 밖에 볼게 없는거 같습니다 , 그나마 제네릭하게 쓸수 있는 기법이지만 C++은 불필요하게 복잡하고 객체지향도 만족스럽지 못합니다 , 차라리 Object C 가 훨씬 깔끔한거 같고 좋을거 같습니다 "

익명 사용자의 이미지

그런분이 템플릿이라는 문법을 강조했다는것에서 전 다른분인줄 알았습니다

사진은 바뀌었지만 어째튼 같은분이네요 ;)

lifthrasiir의 이미지

Anonymous wrote:
CN wrote:

예전부터 C++ 언어에 관심이 있었지만 언제나 새로운 언어를 접할려고 노력했습니다. 무엇이 문제인가요? 내 글에 관심을 가져주신 것은 감사히게 생각합니다.

예전부터 거슬리는 것 한가지만 지적하겠습니다.

"내글"과 같은 표현이 상당히 많으신데, "제"글 맞는것 아닐까요?

표현을 원래부터 그렇게 일상적으로 하시는게 아니라면 "제"글이라고 쓰시거나, 아예 "내"라는 표현을 빼주시거나 하시길

매우 거슬립니다.

사람에 따라서 "나"라는 표현을 굳이 "저"라는 표현으로 바꿀 필요가 없다 생각하는 사람도 있습니다. 실제로 어느 정도 일리가 있는 주장인데다가, 제 기억이 맞다면 CN 님께서는 일상적으로 그런 표현을 쓰시는 걸로 알고 있습니다. 그 정도의 차이는 그냥 신경 쓰입니다 정도로 지적하고 넘어 가면 되지 않을까요.

- 토끼군

익명 사용자의 이미지

http://sosc.nuri.cc
한번 참조하세요 쉽게 되잇던데요?

notpig의 이미지

CN wrote:
Anonymous wrote:
"내글"과 같은 표현이 상당히 많으신데, "제"글 맞는것 아닐까요?

표현을 원래부터 그렇게 일상적으로 하시는게 아니라면 "제"글이라고 쓰시거나, 아예 "내"라는 표현을 빼주시거나 하시길

매우 거슬립니다.

어느 높임법을 어긴 것인가요? 마지막 "매우 거슬립니다."라는 문구에 보면 단순한 감정 표현이라 짐작되지만 확신을 가지기 위해 질문드립니다. 답변에 따라 새로운 토론의 시작이 될 수도 있고 토론의 끝이 될 수도 있을 것입니다.

원글을 쓴사람은 아니지만...제 경험적으론 ...

나란 표현은...나이혹은 직책이 나랑 같거나 아래인 사람에게 이야기 할때 쓰입니다.

저란 표현은 일반적으로 잘 모르는 사람에게 예의상 사용하거나
이야기 하는 사람보다 나이 혹은 직책이 높은 사람 에게 이야기 할때 사용하거나
불 특정 다수에게 이야기 할때 (연설같은거라고 하면 될까요??) 사용하는걸로 알고 있습니다.

그리고 글 내용중에 C programming language 를 추천 하신 분들이 있는데.
이건 생전 처음 볼 C 책으론 너무 어렵습니다.
두번째로 봐야하는 C 책 정도로 생각해야 하지 않을까요??

익명 사용자의 이미지

"내 글" 이야기를 보니 "죄송합니다" 대신에 꼭 "미안합니다"를 쓰는 사람들 생각이 나는군요. 뉘앙스가 다르다는 점을 강조하는...

이런 것도 개성의 하나인 것 같습니다. 성격이 드러나서 눈쌀찌푸려지는 것은 어쩔 수 없지만...요즘 신세대 중에는 이런 사람도 있는거겠죠.

죠커의 이미지

notpig wrote:
원글을 쓴사람은 아니지만...제 경험적으론 ...

나란 표현은...나이혹은 직책이 나랑 같거나 아래인 사람에게 이야기 할때 쓰입니다.

저란 표현은 일반적으로 잘 모르는 사람에게 예의상 사용하거나
이야기 하는 사람보다 나이 혹은 직책이 높은 사람 에게 이야기 할때 사용하거나
불 특정 다수에게 이야기 할때 (연설같은거라고 하면 될까요??) 사용하는걸로 알고 있습니다.

이 모든 경우에 "제가"라는 단어를 사용할 필요가 없습니다. 사장님 "말씀이"와 같이 불필요한 부분이라고 봅니다.

notpig의 이미지

CN wrote:

이 모든 경우에 "제가"라는 단어를 사용할 필요가 없습니다. 사장님 "말씀이"와 같이 불필요한 부분이라고 봅니다.

그럼 저란 표현은 전혀 쓸모 없는 표현이란 건가요???

"저는 동의 못하겠는데요"
"나는 동의 못하겠는데요"

http://sabbath.egloos.com/907894
구글에서 찾은 글입니다.
저랑 같은 생각입니다.

http://www.barunmal.com/board/korstory/korstoryview.php?no=9&infono=9&nowpage=9&searchword=&key=&ref=&boardname=korstory

공식적인 높임법은 아니지만....

Quote:

집단 구성원이 모두 손아랫사람이면 ‘나’라고 해도 괜찮다.

저같은 사람은 위의 상황으로 인식합니다.

마지막으로

Quote:
문제16] 다음 중 높임법이 옳은 것은?
① 그 분은 두 살 된 따님이 계시다. ② 선생님, 외투가 무겁죠?
③ 아버지, 큰형이 오늘 서울에 도착한대요. ④ 내가 짐을 들어다 드리겠습니다.
해설③
① 계시다(직접 높임에만 쓰인다.) 있으시다
② 무겁죠? 무거우시죠?
④ 내가 제가

http://72.14.203.104/search?q=cache:TBCc8TjL71EJ:bpgosi.com/official4.html+%EB%86%92%EC%9E%84%EB%B2%95+%EC%A0%9C%EA%B0%80+%EB%82%B4%EA%B0%80&hl=ko&gl=kr&ct=clnk&cd=78

다들 새해 복 많이 받으시길.

익명 사용자의 이미지

notpig wrote:
CN wrote:

이 모든 경우에 "제가"라는 단어를 사용할 필요가 없습니다. 사장님 "말씀이"와 같이 불필요한 부분이라고 봅니다.

그럼 저란 표현은 전혀 쓸모 없는 표현이란 건가요???

"저는 동의 못하겠는데요"
"나는 동의 못하겠는데요"

http://sabbath.egloos.com/907894
구글에서 찾은 글입니다.
저랑 같은 생각입니다.

http://www.barunmal.com/board/korstory/korstoryview.php?no=9&infono=9&nowpage=9&searchword=&key=&ref=&boardname=korstory

공식적인 높임법인지 아닌지 모르지만....

Quote:

집단 구성원이 모두 손아랫사람이면 ‘나’라고 해도 괜찮다.

저같은 사람은 위의 상황으로 인식합니다.

마지막으로

Quote:
문제16] 다음 중 높임법이 옳은 것은?
① 그 분은 두 살 된 따님이 계시다. ② 선생님, 외투가 무겁죠?
③ 아버지, 큰형이 오늘 서울에 도착한대요. ④ 내가 짐을 들어다 드리겠습니다.
해설③
① 계시다(직접 높임에만 쓰인다.) 있으시다
② 무겁죠? 무거우시죠?
④ 내가 제가

http://72.14.203.104/search?q=cache:TBCc8TjL71EJ:bpgosi.com/official4.html+%EB%86%92%EC%9E%84%EB%B2%95+%EC%A0%9C%EA%B0%80+%EB%82%B4%EA%B0%80&hl=ko&gl=kr&ct=clnk&cd=78

다들 새해 복 많이 받으시길.

죠커의 이미지

notpig wrote:
CN wrote:

이 모든 경우에 "제가"라는 단어를 사용할 필요가 없습니다. 사장님 "말씀이"와 같이 불필요한 부분이라고 봅니다.

그럼 저란 표현은 전혀 쓸모 없는 표현이란 건가요???

"저는 동의 못하겠는데요"
"나는 동의 못하겠는데요"

http://sabbath.egloos.com/907894
구글에서 찾은 글입니다.
저랑 같은 생각입니다.

http://www.barunmal.com/board/korstory/korstoryview.php?no=9&infono=9&nowpage=9&searchword=&key=&ref=&boardname=korstory

공식적인 높임법은 아니지만....

Quote:

집단 구성원이 모두 손아랫사람이면 ‘나’라고 해도 괜찮다.

저같은 사람은 위의 상황으로 인식합니다.

마지막으로

Quote:
문제16] 다음 중 높임법이 옳은 것은?
① 그 분은 두 살 된 따님이 계시다. ② 선생님, 외투가 무겁죠?
③ 아버지, 큰형이 오늘 서울에 도착한대요. ④ 내가 짐을 들어다 드리겠습니다.
해설③
① 계시다(직접 높임에만 쓰인다.) 있으시다
② 무겁죠? 무거우시죠?
④ 내가 제가

http://72.14.203.104/search?q=cache:TBCc8TjL71EJ:bpgosi.com/official4.html+%EB%86%92%EC%9E%84%EB%B2%95+%EC%A0%9C%EA%B0%80+%EB%82%B4%EA%B0%80&hl=ko&gl=kr&ct=clnk&cd=78

다들 새해 복 많이 받으시길.

필요없이 한 손님 덕분에 불필요한 논쟁을 계속하게 되었군요.

가장 아래의 문제는 문제자체가 틀려 보입니다. 이 문제가 맞춤법에 의거한 답으로 보이진 않습니다.

구글링에 의한 답이 아닌 근거가 포함된 답을 얻고 싶습니다.

notpig의 이미지

CN wrote:

필요없이 한 손님 덕분에 불필요한 논쟁을 계속하게 되었군요.

가장 아래의 문제는 문제자체가 틀려 보입니다. 이 문제가 맞춤법에 의거한 답으로 보이진 않습니다.

구글링에 의한 답이 아닌 근거가 포함된 답을 얻고 싶습니다.

http://www.kgosi.com/data/data_view.html?pds_num=921&page=6&p_part=0&p_item=&p_code=103&article_up_code_num=101

http://gosischool.com/board/board_exam/2000_x-01.htm

행자부 9급 기출 문제 라면 충분히 정답이라고 생각되지 않나요???
뭐~그정도론 정답이라는 근거가 부족하다면 먼저 틀렸단 근거를 제시해야 겠지요~

그리고
http://www.barunmal.com/board/korstory/korstoryview.php?no=9&infono=9&nowpage=9&searchword=&key=&ref=&boardname=korstory
는 근거가 되지 못하나요???

PD 수첩 식으로 이야기해서
불특정 다수에게 "나"란 표현을 사용해도 된다는 증거를 하나도 발견하지 못했습니다.

타당한 답변이 없음...더이상 글쓸 생각 없습니다.
지금까지 생활하신대로 생활하세요~

익명 사용자의 이미지

현재의 문법 기준으로만 본다면 누군지 모르는 상대에 대한 글이므로 처음 손님의 지적처럼 '제 글'이라고 하는 것이 맞긴 맞아 보입니다. 하지만 요즘 점점 높임법이 줄어드는 추세이고 '제'는 상대를 높이는 높임법이 아니라 자기를 낮추어 상대적으로 상대를 높이는 높임법이므로 동등한 인격간의 대화에 적절한 높임법은 아니라고 봅니다. 악습까지는 아니라해도 이런 식으로 자신을 낮추는 표현들은 우리말에서 사라졌으면 하는 게 제 생각입니다.

p.s.
로그인하기 은근히 귀찮군요-_-

lifthrasiir의 이미지

왜 주제가 호칭 얘기로 바뀌었는 지 모르겠습니다만 제 입장을 정리하자면,

"나"는 원래 나이가 비슷하거나 낮은 사람에게 자신을 가리킬 때 쓰는 말입니다. 조금 더 확장하면 상대방과 자신이 동격일 경우에도 쓸 수 있다는 말이 되겠죠. (물론 평교간이라는 말의 정의는 원래 나이입니다만, 이 정도 변화는 충분히 용인할 수 있다고 생각합니다.) 온라인 상에서 대부분의 사람들 사이의 관계는 동격이기 때문에 이 기준대로라면 일반적으로 게시판에서 글을 쓸 때 "나"로 자신을 가리키는 게 문제가 되진 않는다고 생각합니다.

물론 모든 사람이 이런 호칭을 의식적으로 쓰는 건 아니며, 심지어 다른 분께서 인용하신 SabBatH 님의 글처럼 기분 나빠하는 사람도 있을 수 있습니다. 제 경험으로는 이렇게 의식적으로 "나"를 쓰는 사람은 열 명 중 많으면 한 두 명 정도였습니다. 하지만 그 호칭이 토론에 영향을 주는 게 아닌 이상, -- 물론 "개X끼" 같은 말을 친밀감을 위해 사용하는 건 영향을 주겠지만 설마 그 정도겠습니까? -- 토론의 원래 주제와는 상관 없이 호칭 얘기로 얘기가 흘러 가는 건 기분이 별로 좋지 않습니다. 토론은 서로를 존중하는 데서 시작된다고들 하던데 이 정도의 차이를 인정할 수 없다면 토론 자체가 이루어질 수 없다고 생각합니다.

- 토끼군

덤: 또한 저는 맞춤법이 그리 절대적인 규칙이라고 생각하진 않습니다만, 이 얘기는 나중에 할 일이 있을 겁니다.

죠커의 이미지

notpig wrote:
타당한 답변이 없음...더이상 글쓸 생각 없습니다.
지금까지 생활하신대로 생활하세요~

그전부터 궁금했던 것에 답이 없군요. 높임법에 명기된 나를 낮출 이유를 알려주시면 됩니다.

notpig의 이미지

CN wrote:
notpig wrote:
타당한 답변이 없음...더이상 글쓸 생각 없습니다.
지금까지 생활하신대로 생활하세요~

그전부터 궁금했던 것에 답이 없군요. 높임법에 명기된 나를 낮출 이유를 알려주시면 됩니다.

http://bbs.kldp.org/viewtopic.php?t=57357
에 답글을 달았습니다.

zeon의 이미지

tokigun wrote:
왜 주제가 호칭 얘기로 바뀌었는 지 모르겠습니다만 제 입장을 정리하자면,

"나"는 원래 나이가 비슷하거나 낮은 사람에게 자신을 가리킬 때 쓰는 말입니다. 조금 더 확장하면 상대방과 자신이 동격일 경우에도 쓸 수 있다는 말이 되겠죠.
~
~
~
토론은 서로를 존중하는 데서 시작된다고들 하던데 이 정도의 차이를 인정할 수 없다면 토론 자체가 이루어질 수 없다고 생각합니다.

- 토끼군

덤: 또한 저는 맞춤법이 그리 절대적인 규칙이라고 생각하진 않습니다만, 이 얘기는 나중에 할 일이 있을 겁니다.


지나가다 덧붙입니다.

"나", "너"가 동격이 되는 경우는 상대와 관계가 가까울때 만으로 알고 있습니다.
CN님은 자신을 낮춰야 할 이유가 뭐냐고 하시지만 자신을 "나"라고 하면 상대는 "너"가 됩니다. 토끼군님도 그렇게 말씀 하셨잖습니까? "나"는 비슷한 나이와 상대를 낮출때 쓴다고...

차이를 인정해달라고 말 할 쪽은 대다수가 아닌 소수 쪽이지 않을까 하고 생각해 봤습니다. 제가 있는 쪽이 제가 말한 "대다수"에 속할 꺼라 믿고 싶네요.

ps. 맞춤법을 절대적인 규칙이라고 생각하지 않습니다. 다만 최대한 지키시는 쪽이 자신의 주장에 신뢰를 더 하지 않을까 싶네요.

여친이 길르는 용..

죠커의 이미지

zeon wrote:
CN님은 자신을 낮춰야 할 이유가 뭐냐고 하시지만 자신을 "나"라고 하면 상대는 "너"가 됩니다.

우리 누나의 반대말은 너희 누나가 됩니까? 자신을 낮추지 않는다 하여 상대방을 깔보는 것이 아닙니다.

notpig님은 겸양법을 말씀하셨는데 나는 이미 겸양법을 사용하고 있습니다. 바로 앞의 문장에서도 "겸양법을 말씀하셨는데"라고 겸양법을 사용하고 있습니다. 어째서 자신을 낮추지 않는 것이 상대를 낮추는 것이 된다고 생각하시는지 그것이 더 의아합니다. 겸양법의 경우에는 사용하지 않아서 상대에게 누가 되는 경우는 거의 없는 것으로 알고 있습니다. 예를 들어 사장님 말씀이 이러하셨습니다. 라는 것을 사장님 말이~ 로 바꾸어도 높임법에는 문제가 없는 것은 이미 여러 글을 통해서 많은 분들이 알고 계실 것입니다.

공무원 시험의 문제는 겸양법을 사용하지 않았을 때 낮춤말이 되는 것이 아님에도 불구하고 잘못된 해석을 하고 있지 않느냐 생각합니다.

이 쓰레드에 맞지 않는 답글은 더 이상 달지 않을 것입니다. 이미 내가 하고 싶은 말은 충분히 했고 의문을 이 쓰레드에서 풀어주는 분은 없을 것이라 생각합니다.

익명 사용자의 이미지

CN wrote:
zeon wrote:
CN님은 자신을 낮춰야 할 이유가 뭐냐고 하시지만 자신을 "나"라고 하면 상대는 "너"가 됩니다.

예를 들어 사장님 말씀이 이러하셨습니다. 라는 것을 사장님 말이~ 로 바꾸어도 높임법에는 문제가 없는 것은 이미 여러 글을 통해서 많은 분들이 알고 계실 것입니다.

말이~ 와 말씀이~ 는 아무곳에나 같이 사용되어서는 안됩니다.
말이 ~ 와 말씀이 ~ 는 상대에 따라서 분명히 다르게 이야기해야 합니다.
회장님앞에서는 사장님 말이~ 라고 해야하지만 사원들앞에서는
사장님 말씀이~ 라고 표현해야 합니다.
notpig의 이미지

CN wrote:

우리 누나의 반대말은 너희 누나가 됩니까?

그럼 뭐라고 합니까?

CN wrote:

높임법에 명기된 나를 낮출 이유를 알려주시면 됩니다.

CN wrote:

notpig님은 겸양법을 말씀하셨는데 나는 이미 겸양법을 사용하고 있습니다. 바로 앞의 문장에서도 "겸양법을 말씀하셨는데"라고 겸양법을 사용하고 있습니다. 어째서 자신을 낮추지 않는 것이 상대를 낮추는 것이 된다고 생각하시는지 그것이 더 의아합니다. 겸양법의 경우에는 사용하지 않아서 상대에게 누가 되는 경우는 거의 없는 것으로 알고 있습니다.

먼저는 알려달라고 하고, 알려줬더니 쓰는 경우가 없다고 하고...
국문학 전공하셨나요???쓰는 경우가 없으면 앞에서 제가 링크한 글은 소수의 의견 이겠군요
연설문 하나만 찾아서 읽어보시죠..."나"라고 된 연설문이 있는지.
자유게시판 보면 "우리" "저희" 때문에 말들이 많은데...이것도 사문화된 문법을 가지고 논란이 있는거네요~

CN wrote:

공무원 시험의 문제는 겸양법을 사용하지 않았을 때 낮춤말이 되는 것이 아님에도 불구하고 잘못된 해석을 하고 있지 않느냐 생각합니다.

축하합니다...공무원 시험의 오류를 찾으셨군요......
어떠한 근거도 없이요~

솔직히 더이상 이야기하면 서로 감정만 상할꺼 같습니다.
앞으로 여기에 답글을 안달겠습니다.

익명 사용자의 이미지

주제와 관련없는 이야기로 마무리 짓는데 별로 좋아보이지 않습니다

개인 스타일로 볼수 잇는거 까지 이렇게 걸고 넘어갈 필요가 있을까요?

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.