C 포인터를 위해 어셈블리어를 선행 학습하는 것에 대해 어떻게 생각하십니까?

bookworm의 이미지

C 언어에서 제일 어렵다고 가장 많이 말하는 것이 포인터입니다.

개인적으로는 C 언어를 공부할 때 포인터가 크게 부담스럽지 않더군요.

문득 요즘 C를 공부하는 사람들을 보면서 그때 당시를 다시 돌이켜보니 C 언어를 공부하기 전에 어셈블리어를 쓸 줄 알았다는 것이 포인터를 이해하는데 큰 도움이 되지 않았나 싶습니다.

문제는 그 당시에 어셈블리어의 활용도가 많았지만 요즘은 특별한 경우를 빼고 어셈블리어를 직접 쓸 일은 많지 않다는 것이 아닐까 합니다.

C 언어를 포기하게까지 한다는 포인터를 이해하기 위해 어셈블리어를 선행 학습하는 것이 효율적인 선택일지 의견을 나눠보고 싶습니다.

jachin의 이미지

컴퓨터 구조에 대해 이해하는 사람이 대상 장치에 대한 효율적인 프로그램을 생성할 수 있는 것을

생각한다면, 어셈블리어를 선행 학습하는 것도 좋다고 생각합니다.

그래야 왜 포인터를 쓰는지, 간접주소지정방식을 사용하여 구현되는지도 알게 되리라 생각합니다.

교육이라는 의미 안에선 중요한 부분이라 생각합니다.

대학교에서 '컴퓨터 교양' 같은 과목 줄이고, 대신 '컴퓨터 구조 개론' 같은 걸 넣어서

교육해도 좋다고 생각합니다. (그것이 진정한 컴퓨터 교양일지도...)
====
( - -)a 이제는 학생으로 가장한 백수가 아닌 진짜 백수가 되어야겠다.

grassman의 이미지

저도 상당히 삽질하면서 C언어를 공부했던 사람인데요...
나중에 어셈블리어를 공부하면서 포인터나 호출 규약 같은 것에 대해 개념이 잡혔습니다.
C언어의 포인터를 공부하기 전에 어셈블리어를 공부하면 확실히 효과가 있다고 생각합니다.

익명사용자의 이미지

어셈블리 뿐만 아니라, 완고한 또는 보수적인 다른 언어를 먼저 배운다면 거의 무감각하게 포인터의 개념이해와 활용에 익숙해지리라 봅니다.
전 베이직(zbasic?), 파스칼(tp)을 거쳐서 인지 포인터에 대해 심각하게 생각해 본 적이 없네요.
파스칼에서도 "참조에 의한 호출", 포인터를 사용하는 것이 불가능한 것은 아니지만
C 처럼 너저분하게 사용하려면 애로사항이 많습니다.

가려운 곳을 수월하게 북북 긁어주는 짜릿함이 있을 뿐,
무슨 어려움을 겪어 본 적은 없는 것 같습니다.

뱀다리,
zbasic 이 맞는지 모르겠습니다.
대략 청동기 시대쯤 되는 것 같은데...
금성에서 출시한 MSX 호환 FC-80 이라는 8bit PC 에 들어있는 ROM basic 입니다.
CPU 가 z-80 이었지않나 싶은데...

cjh의 이미지

FC-80 이면 MSX-BASIC 1.0 일 겁니다. :)

--
익스펙토 페트로눔

--
익스펙토 페트로눔

blueskya의 이미지

하지않습니다.

공부할 때 포인터가 어렵다고 생각해본적도 없고 이해하기 어려운개념도 아니고....

변수가 뭔지만 알면 될것같은데요...-_-;;

흠...변수가 뭔지 안다는게 어려울수도있겠군요....

일장일단이 있을듯 합니다.

----------------------------------------------------------------------
인생 뭐있어? 백수로 사는거야~ 가는거야~

----------------------------------------------------------------------
인생 뭐있어? 백수로 사는거야~ 가는거야~

불량도ㅐㅈㅣ의 이미지

저는 컴퓨터 구조 수업을 들으면서 포인터가 이해되기 시작했습니다.

C만 공부할 때는 왜 그것을 쓰는지 전혀 몰랐습니다. 또 짜증이 났군요.

하지만 컴퓨터의 구조를 이해하니 포인터를 이해할 수 있겠더군요.

정말 하드웨어 수업의 중요성을 많이 느꼈습니다.

그기에다가 어셈블리까지 하면 되겠네요.

문근영 너무 귀여워~~

문근영 너무 귀여워~~

bearchit의 이미지

저도 컴퓨터구조에 한표 얹습니다.
컴퓨터구조의 기본적인 내용을 이해하다보면,
포인터에 대한 이해가 더 깊어집니다.
하드웨어에 대한 깊은 이해까지는 아니더라도
CPU가 명령을 해석하는 전체적인 구조만 이해하더라도
충분히 도움이 될 듯 싶습니다.
(왜 CPU에서 indirect 명령어를 지원하는지 등...)

하지만 굳이 포인터 학습을 위해 어셈블리어를 공부할 필요가 있을까 하는 생각이 듭니다.
제가 컴퓨터구조 시간에 배운바로는 어셈블리어는 CPU에서 해석할 명령어들을
사람이 읽기 쉬운 단어로 1:1로 매핑한 것이었거든요.

익명사용자의 이미지

분명 도움은 되겠지만, 어셈블리어 배웠다고 깝죽거리면서 온갖 위험한 hack은 아무데나 함부로 쓰고 정작 C언어의 데이터 타입에 대한 개념은 전혀 없는 놈들을 많이 봐서 별로 바람직하단 생각이 안드는군요.

C언어가 아무리 CPU위에서 기계어로 구현된다 하더라도 컴퓨터 구조는 컴퓨터 구조, 어셈블리어는 어셈블리어, C언어는 C언어 입니다. 아무리 기계어에 가깝다고 해도 나름대로 추상화가 되어있는 언어죠.

어셈블리어, 그것도 특정 기계에 한정된 어셈블리어를 배우면 사고의 폭이 매우 좁아집니다. 뭐든지 자기가 배운 특정 하드웨어에만 뜯어맞추게 되죠. 게다가 실질적인 구현에만 집중하게 되기 때문에 추상적인 개념에 대해 도외시하게 되는 경우가 많습니다. 어셈블리어가 무슨 벼슬은 아닐텐데, 그렇게 생각하는 놈들이 꽤나 많더군요.

어셈블러가 도움은 되겠지만, 그게 만능이 아니란걸 명심하십시오.

익명사용자의 이미지

추상화... 이거 알면 포인터 아주 쉬워요. 재밌기도 하고요^^

c0d3h4ck의 이미지

컴퓨터 프로그램에 대한 기본 지식과 언어에 대한 좀 더 많은 이해를 하는 의미일 뿐..
어셈블리 배웠다고 깝죽 거릴 이유가 있는지 모르겠습니다..
지금 이나 커리큘럼에 없는 것이지 90 년대 중반 학번까지는 다 배운것들 아닌가요?
이해가 안되는데요..

jerry.so의 이미지

그렇죠. 그냥 수업시간에 배우는 것일 뿐...
그러나 이걸로 밥벌이를 할 줄을 몰랐습니다.ㅜ.ㅜ

___
Knowing me, knowing you...

___
Knowing Me, Knowing You...

죠커의 이미지

저 역시 깝죽거리다고 생각합니다. 포인터 얘기하면 32비트다라는 얘기부터 시작해서 상당 수 오해는 로우레벨만 파고 그 위의 레이어에 대한 이해는 게을리 해서 그렇다고 생각합니다. 제대로 그 레이어를 파지 않고 아래의 레이어만 판 후 아는 것 처럼 얘기하는 사람이 많아서 D모 사이트와 같은 곳에 더더욱 엉터리 답변이 많은 것입니다.

- CN의 낙서장 / HanIRC:#CN

c0d3h4ck의 이미지

>> "포인터 얘기하면 32비트다라는 얘기부터 시작해서 상당 수 오해는 로우레벨만 파고 그 위의 레이어에 대한 이해는 게을리 해서 그렇다고 생각합니다."

저 또한 포인터를 위해 어셈블리어를 선행 학습하는건 무리가 있다고 봅니다. 하지만 약간 다른 의견을 갖고 있습니다.

위 말씀하신 사람들은 말씀처럼 전체를 두루 알지 못한 사람들입니다. 하지만 어셈블리를 배우는것 자체는 C 언어 자체를 잘 이해하기 위한 지름길 중 하나일 수 있습니다.

상위 레이어의 개념만 이해한다면 전공자들은 뭣하러 몇년동안 컴구조니 운영체제를 배우는 걸까요? 사실 프로그래밍 언어만 두고 본다면 비 전공자들도 쉽게 배울 수 있지 않나요? 튼실한 기초없이 도구만 배우는 이런 사람들이 많이 양산되는건 결코 좋아보이지 않습니다.

그런면에서 어찌 어셈을 배우는것을 깝죽거리는것이라 생각할 수 있는지요?

죠커의 이미지

C언어를 이해하기 위해서 C언어만 공부해야 한다는 이야깁니다. 저학년때 순수히 개념적으로 C언어를 공부하는 것이 옳습니다. 계속 같은 얘기를 반복하게 되는데 전웅씨의 책이나 H&S를 한번이라도 읽어보셨다면 동의하실 지도 모르겠군요.

그리고 컴퓨터 구조나 운영체제가 저학년에 학습해야 하는 과목인가요?

- CN의 낙서장 / HanIRC:#CN

markboy의 이미지

전 basic - C - pascal - asm - C++ 순으로 익혔습니다. 상당한 삽질이었지요. :) 특히 포인터는 asm을 배우면서 확실하게 개념이 잡혔습니다. (포인터가 싫어서 pascal쪽으로 공부했었거든요 :) )

결론은, 가능하다면 asm을 먼저 배우는 쪽이 낫다 입니다. (좀 더 나아가면 하드웨어부터 공부 하는 것이 더 낫겠지요)

그리고 아무것도 없는 상태에서 디버깅할때 asm은 분명 도움이 됩니다. :)

Necromancer의 이미지

어셈블리부터 건드렸는데 ㅋㅋㅋ

Written By the Black Knight of Destruction

lieps의 이미지

어떤 어셈이요? z80 이나 pic 마이컴 계열의 어셈블리를 익힌다면.. 좀 괜찮을 듯도 합니다만,
x86 계열의 MASM 이나 NASM 같은걸 배우면.. 글쎄요.. 그걸 배울시간에 포인터를 익히는데 투자하면... 쿨럭... ^^;

개인적으론 포인터를 위해 어셈블리를 배울 필요는 없다고 봐요.
자바에서 레퍼런스를 이해하기 위해 C 의 포인터를 배울 필요는 없잖아요.(예시가 맞나요? 자바를 잘 몰라서..^^)

어쨌든. 어셈.. 배우면 좋겠으나, 개인적으론 그닥 추천하지는 않을듯 해요.

참.. markboy 님 말대로 어셈을 할려면 하드웨어를 공부해야 하니.. 꽤나 골치 아플꺼예요..ㅜㅜ (제가..oTL)
---
To solve an interesting problem,
start by finding a problem that is interesting to you.

---
To solve an interesting problem,
start by finding a problem that is interesting to you.

ㅡ,.ㅡ;;의 이미지


C 하기위해 어셈먼저해야한다는건 좀..그렇군요..

뭐 더욱잘하기위해 기초를 다진다고 생각한다면몰라..

포인터가 겁나.. 어셈이라... 그런건 아니라고 생각되는데요..

비유하자면... 갑짝스런 조깅에 감기걸릴까봐 새벽에 마라톤연습이라고 할까.ㅋㅋ

어셈에 비하면 C는 거저먹기 아닌가요..

제가볼때는 사람마다 다른것같습니다...

포인터가 있어야 코딩이 쉽다...VS 포인터가 있어 코딩이 어렵다...

포인터가 없으면... 빛이없는 암흑이라고 할까..


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

bookworm의 이미지

x86이 아니라 8051, z80, 6502와 8 bit cpu 어셈블리어는 어떨까요?

--

B/o/o/k/w/o/r/m/

B/o/o/k/w/o/r/m/

ㅡ,.ㅡ;;의 이미지

글쎄요.. 배워서 남주는게 아니니... 배워둬도 나쁠건 없겠지만..

C때문에 배운다는건 저로선 의문..


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

hogi2271의 이미지

;;;;;;

^^/

neogeo의 이미지

개인적으로 C 언어를 무지하게 사랑하는(?) 사람입니다만..

C 언어의 가장 지랄맞음은 포인터를 배우기도 전에 문자열을 건드릴 일이 반드시 생긴다는 거지요. ( char* , char[] ... )

도대체 왜 문자열 비교는 따로 strlen 따위를 써야하며 문자열은 그냥 복사가 안되고 문자열 조금만 건드리면 segment fault 가 나는지....

이해도 하기 전에 만지면 당연히 짜증이 날겁니다.

이건 반드시 이렇게 써야한다 라고 가르치다가 포인터 개념이 나오고나면 그때 다시 문자열을 가르치게 되는 상황도 우습구요...

어셈블리 배우기 전이나 후나 포인터 개념이 바뀐건 없습니다만, 어셈블리의 문자열 다루는걸 배우고 나면 C 언어 배우기가 훨씬 쉬워질 것 같습니다.

Neogeo - Future is Now.

Neogeo - Future is Now.

thyoo의 이미지

Ken Thompson이 어셈블리로 UNIX 짜다가
단순 노가다가 진저리가 나서 B언어를 만들게 되는데
나중에 Ritchie가 B에서 C를 만듭니다.
태생적으로 C언어는 Assembly의 지리한 Coding만을 면한 저급언어로
Assembly를 이해하는 사람이 C Code를 보면
Assembly로 직역할 수 있을 정도로 가깝습니다.

기초로서 나쁘지 않다고 생각합니다만,
회사에서 언제까지 코딩할 것도 아닌데
거기까지 알 필요가 있나는 회의도 듭니다.
___________________________________
Less is More (Robert Browning)

___________________________________
Less is More (Robert Browning)

magingax의 이미지

요즘 유행하는 단어군요..
초딩들이 중딩 과정 공부하고 뭐 이런거..우리땐 이런게 없었는데참
갈수록 살기 힘듦니다..

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

죠커의 이미지

저는 절대 반대합니다. C의 포인터 개념도 어셈블리/기계어 수준의 간접 지정보다 훨씬 추상화되어 있습니다. 로우레벨로 익히고 제대로된 개념을 익히려는 노력을 하지 않는다면 오히려 잘못된 지식만 쌓이고 맙니다. 배움에는 순서가 있습니다.

- CN의 낙서장 / HanIRC:#CN

winner의 이미지

C 언어의 속성상 정확히 이해할려면 low level 이 필요합니다.

물론 Quick Start 나 활용에 목적을 두고 공부하는 사람들은 모르겠습니다만
하나하나 정확히 이해하지 않으면 넘어가지 못하는 사람들도 있죠.

특히나 debug 를 해야 하는 경우가 생기면 성능을 중요시 여기는 C compiler 의
속성상 runtime 의 정확한 진단이 어렵기 때문에 low level 상황의
별의별 망상이 떠오를 수 밖에 없는 것 같습니다.

처음에는 다들 hardware, OS 나 C compiler 를 의심하게 되지 않던가요?
나중에 가서야 자신의 어이없는 바보짓을 알게 되지만...

죠커의 이미지

아닙니다. C언어를 이해하기 위해서는 개념만 있으면 됩니다. 포인터가 32비트 컴퓨터니 4바이트니 같은 언급들은 로우레벨에 대한 광신으로 제대로돈 개념을 익히지 못해서 발생한 것입니다.

- CN의 낙서장 / HanIRC:#CN

winner의 이미지

아, 물론 저도 이상적으로 추상적인 관점에서 이해하는 것이 제일 좋다고 봅니다.
그런 제 경험에 비추어 볼 때 그런 추상적인 pointer 의 이해를 도왔던 것은 STL 의 iterator 였습니다.
STL 을 공부하면서 pointer 에 대한 겁이라던지 오해가 많이 없어졌죠.

제가 생각하기에 C 에서 어떤 자료형은 몇 byte 이다라는 오해를 부른 것은
바로 sizeof 연산자라고 생각합니다.

물론 sizeof 는 반대로 자료형의 용량차이의 이식성을 얻기 위해 사용되는 것입니다만 반대로
이 연산자가 있음으로 인하여 오해 역시 남아 있다고 생각합니다.
sizeof 의 결과는 무부호정수형으로 눈으로 볼 수 있게 표현해 볼 수 있거든요.
연산자 이름 자체가 자료형의 크기를 얻는다라는 것이잖습니까.

제 경험상 sizeof 는 memory 동적할당과 bit 연산 이외에는 사용하지 않았습니다.
C++ 의 경우 template metaprogramming 에 쓰인다지만 추측컨데
역시 위의 두가지와 연관이 있을 것 같군요.

C++ 와 Java 에서는 new 를 쓰기 때문에 sizeof 가 필요없죠.
아마 Java 에서는 아예 없지 않나요?... 기억이....

sizeof 와 memory 정렬제한을 필두로 C 의 다양한 속성은 역시 low level 로
가는 학습자를 막기는 커녕 오히려 인도합니다.

C Rationale 에도 programmer 가 하고자하는 바를 막지 않는다라는 말이 있죠.
결국 이 말은 low level 의 관점을 이용하려는 programmer 를 포용한다고 생각합니다.

물론 C 를 이해하는데 있어 개념만 있으면 된다는 말은 공감합니다.

하지만 C 의 태생이 고급언어의 관점보다는 저급언어의 이식성 확보에서 출발했다는 점을
볼 때 여러가지로 low level 로 가는 학습자를 막는 것은 결코 바람직하지만은 않다고 생각합니다.
역사를 익히는 것도 언어 이해를 돕습니다.
비록 자연어와는 다르니 그 의미는 많이 약해지겠지만 programming 언어를 익힌다는 것
역시 단지 programming 하는 것만이 아닌 문화를 익히는 것이 어느 정도 있는 것 같습니다.
그렇지 않고서는 다른 programming 언어를 익히는 것이 쉽겠죠.
또 다른 programming 언어에 대한 이해의 부족으로 인해 flame 이 발생하지도 않을 겁니다.
(여기에는 언어만이 아닌 환경에 대한 이해도 포함되죠.)

뭐라고 할까요... 최종적으로 C programmer 가 가능한 추상적인 관점에서 programming 을
하는 것이 대부분의 환경에서 좋은 결과를 얻지만 그러한 상태를 위해 가는 길은 마치 평행선처럼
보이는 하지만 결국 같은 목표점을 갖는 두 길을 오가면서 도착한다고 생각합니다.

결코 low level 에 대한 이해가 추상적 개념의 이해를 막는다고 생각하지 않습니다.
결국 다양한 low level 이 있다는 것을 알게 되었을때 추상적 관점의 이해의 필요를 느끼고,
추상적 개념은 곧 low level 에 다양하게 적용할 때 의미가 있다고 생각합니다.

관점의 차이일 뿐 두 가지는 같다는 것이 제 생각이죠.
중요한 것은 다른 관점을 보게 되었을 때 대처하는 자세라고 생각합니다.
물론 추상적 개념을 갖고 있는 자가 문제되는 code 를 만드는 일은 드물겁니다.
Low level 만을 고집하는 자가 있다면 정말 문제겠죠.
하지만 추상적 개념만을 고집한다면 그것 역시 최상의 결과를 얻을 수 없을 겁니다.

수학교수가 말하죠.
수학을 익히는데 숫자를 쓰는 것은 좋지 않다고. 수학의 추상적 논리를 이해하는데 오히려
방해가 된다고 말입니다. 수학을 공부하는데 있어 연산과 x, y 등만 있으면 충분하다고 말입니다.
하지만 나중에 결국 이해를 돕는데 숫자를 쓰는 것이 도움이 될 수 있다는 것을 알았다라고...
어디서 봤던 글이더라... ^_^a

괜히 matrix 를 만들고, graph 를 그리는 것이 아니죠.

아, 그리고 이것은 어디까지나 제 생각이지만 배움에는 순서가 없다고 생각하니다.
다만 현재 수용할 수 있는 것과 그렇지 않은 것이 있을 뿐이라고 보거든요.
어떤 결론을 내기 위한 경로는 다양하고, 각자에게 있어 그 최적경로는 다를 수 있을 겁니다.

마지막으로 궁금한 것이 있는데요.
CN 씨의 글은 언제나 즐겁게 읽고 있습니다.
차분하면서도 다양한 각도에서, 해박한 지식으로 글을 쓰시고, 상대가 이해하기 편하게 해주시거든요.
상대의 흥분한 글을 위트있게 넘기는 것 역시 존경스러운 글 솜씨입니다.
그런 CN 씨가 현재에 이르기까지 특히 C 를 공부하는데 있어 어떠한 과정을 거쳤는지 알고 싶습니다.
정말, 정말 궁금합니다. ^_^

죠커의 이미지

제가 익혔던 과정은 제 주장을 뒷받침하기 힘들지만 winner님이 콕 찝어 얘기하셨으니 답변을 안 달수가 없네요. 흠 제가 C언어를 배울 때 로우레벨을 중시하지 않는 것은 몇 차례 얘기했기 때문에 더 얘기할 필요가 없을 것 같구요. 어떤 과정을 거쳤는지만 적어보겠습니다.

전 처음에 익혔던 언어가 베이직 계통이었습니다. 애플소프트 베이직 (이것도 MS것입니다.)와 MSX 베이직을 익혔고 그 이후에는 Z80 어셈블리와 기계어를 익혔습니다. 솔직히 말해 그것 밖에 팔 것이 없었던 머신이었습니다. 32비트 머신에서도 퀵 베이직을 익히고 그 후로 x86 어셈을 익혔습니다. PC에서 x86 어셈블리를 익힌 것은 램 상주 프로그램을 만들기 위해서였습니다. C언어는 20살이 되어서 처음으로 익히게 되었습니다. 제가 익힌 방법은 어이가 없는 방법인데 책의 내용을 제대로 읽지 않고 K&R의 소스코드만 계속 입력하고 컴파일 하는 것을 반복하는 것이었습니다. 그 시간은 이틀 밤과 낮이면 충분하더군요. 그 후로 그냥 친구들에게 C언어를 아는 척하다 뉴스그룹에서 전웅씨의 글을 보고 충격을 받아서 표준 스펙과 전웅씨의 글을 찾아서 읽고 전웅씨의 글을 읽었습니다. cinsk님이 번역하신 FAQ를 읽고 제가 얼마나 단편적으로 이해하고 있는지 깨달았습니다. 지금은 가끔 H&S를 참고하고 있습니다. 하지만 여전히 공부가 별로인 것 같습니다. C언어나 C++언어는 앞으로 잘하고 싶은 언어 중의 하나입니다.

- CN의 낙서장 / HanIRC:#CN

winner의 이미지

이상한 질문 답변해주셔서 감사한데 한가지 또 이상한 거 묻자면...

아버님댁에 보일러는 어떻게 됐나요?
올 겨울은 지금까지는 따뜻한 편이라 괜찮을 것도 같군요.
특히 오늘은 완전 봄이더군요.(^^)

이제 다른 것으로 효도할 때가 되지 않았는지... -_-a...
좀 주제넘은 참견이군요. 제가 생각해도.

인상적인 avatar 를 계속해서 보다보니 이 역시 궁금증이 생기는군요.

indra의 이미지

필요에 의해서 병행하는 쪽을 택합니다..
개인적으로도 그런 방식으로 많은 도움이 됐고요..
후임이나 후배에게 그런 질문을 받고 이야기 해 달라 요청받으면..
제 경험과 위에 거론된 단점 같은것을 이야기 해 주고 참조하라며 선택하라 말해 줄 겁니다..
모든 사람이 공부하는 방식이 똑같을 수 없는데..
또 공부를 하는 사람이 항상 올바르지 않는 길을 가는 것도 아닌거죠..
사람마다 다 다른 것 같습니다..

warpdory의 이미지

한때는 8051, z80 등의 어셈블러로 학비도 벌고 했던 입장이고 해서.. 좀 적자면 ...

배워서 나쁠 건 없습니다만 ... 배우는데, 너무 힘들지 않을까 싶습니다.

게다가 ... 경험상 .. x86 용, 8051, z80 .. 마다 다 달라서 ... 삽질했던 기억을 떠올리면 .... 흠..

뭐 다시 반복합니다만, 배워서 나쁠 건 없습니다.

---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.
http://akpil.egloos.com


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

coremaker의 이미지

어셈 지식을 취득하는게 올바른게 아닌가 생각합니다..
확실히 알아두면 좋은 지식이지만.. 그 것을 얻기위해.. 생각보다 많은 시간을 투자할 가능성(?)이 좀 있습니다..
많지 않은 C 소스들을 분석했지만... kernel 딴에서 Paging 하는 루틴이나.. CPU Register에 접근하는 경우가 아니라면..
거의 어셈은 사용하지 않는 것 같구요... 포인터 자체는 여러 Language를 다루다보면 자연스럽게.. 느껴지실 거라 생각합니다..
reference 니 copy 니 이런 것들 C에서 보단 다른 3세대 언어를 표방하는 C++, Java에서 더 와닿더군요...

lovewar의 이미지


처음에 C를 접할때, 포인터 부분만 책으로 나와 있어서 책을 덮었습니다.
아마도 그책에는 포인터를 활용하는 측면의 것들이 많이 나와 있을 것이라 지금은 생각합니다.

돌이켜보면, C언어의 자료형 체계(type system)을 어떻게 이해했는냐하는 생각을 해 봅니다.
즉, 기본적인 자료형들의 이해를 했는지와 왜 필요한지에 대한 부분이 그때 했어야 했는데,
그부분을 이해하지 못하고 프로젝트를 하면서 깨우친 것이 아마도 포인터형을 처음에 접근하기
힘들었던 것 같았습니다.

아마도 C언어를 배운다면 그 배우는 과정에서 자료형 체계를 이해할 수 있는 책(문서, 사람)이 필요 할것으로 봅니다.
달리 다른 언어를 빌려올 필요성은 없어 보입니다.

익명사용자의 이미지

어셈보다는 컴퓨터의 구조에 대해서 배우는게 더 낮지 않을까요 ?
포인터는 결국 메모리의 사용에 관한 문법인데 이 부분을 배우기 위해 어셈을 배운다는 것은
배보다 배꼽이 더 큰 것 같습니다.
컴퓨터의 구조, 메모리의 구조, OS 에서 메모리를 사용하는 법 등을 배운다면 포인터에 대한 이해가 더 높아지겠죠.
어셈 또한 C 언어와 같이 기계어를 사람들이 이해하기 쉽게 만들기 위한 언어일뿐.
다른 언어에 비해 그 이상도 그 이하도 아니라고 생각합니다.

yaru22의 이미지

지금 대학교에서 2학년 1학기 코스 중에서

컴퓨터 구조부터 시작해서 간단히 기계어 다뤄보고 어셈블리어 다뤄보고

자바로 어셈블러 만들고, 간단한 컴파일러도 만들어보는 코스를 들었는데요

저도 처음엔 왜 기계어 같은거 하는지 어셈블리어 같은거는 왜 하는지 생각이 들었는데

막상 듣고 나니깐 컴퓨터가 어떻게 돌아가는지에대해 많이 배운것 같고

포인터라는 개념이 왜 생겨났는지도 조금 이해가 가더라고요.

컴파일러 다 끝나고 나서 c언어 1~2주 정도 잠깐 맛보기를 했는데요

예전에 혼자 공부할때는 도대체 개념이 안잡히던 포인터가

머리에 잘 들어오는것 같던데요...

아무래도 컴퓨터 구조에 대해 배우고 어셈블리어를 써본 결과라고 생각합니다.

요번학기에서 가장 제가 좋아했던 코스에요 ^^ 교수님도 엄청 열정적이셨고...

어째든~ 저는 어셈블러 배우는데 찬성 :)

이 코스에서 저희는 MIPS architecture 를 이용한 어셈블러를 배웠는데

뭐 진짜 hardware board 를 사용한건 아니었고.. 교수님들이 만든 프로그램을 이용해서

간접적으로 체험해 본 정도였죠 ^^

이 코스 말고 다른 코스에서 ColdFire Board (M68000) 쓰면서 진짜 어셈블리 프로그래밍 해본것도 도움이 많이 된것 같습니다.

seunghoon의 이미지

주위에 보면 C공부하면서 포인터가 어려워서 헤매는 경우를 많이 봤는데 어차피 포인터도 꾸준히 자꾸 써보다 보면 이해가 가지 않나요?( ㅋㅋ 전 이해하지 못해도 무작정 따라 쓰다보니까 개념이 잡혔거든요... ) 뭐든 배워두면 좋지만 포인터를 위해 어셈 블리어를 먼저 공부할 필요는 없을것 같습니다. 8051을 하면서 어셈블리어를 약간 접해 봤는데 어셈블리어 먼저 공부하다 지치지 않을까 생각됩니다.
-----------------------------------------------------
퍼지지말자~~!!! 아자아자~~
불태우자~~ 모두 새하얗게 될때까지~~~
the frontier spirit

-----------------------------------------------------
퍼지지말자~~!!! 아자아자~~
불태우자~~ 모두 새하얗게 될때까지~~~
the frontier spirit

익명사용자의 이미지

난 이 결혼 반댈세..

jachin의 이미지

부디 어셈과 같이 결혼하게 해주십쇼! (응?)
====
( - -)a 이제는 학생으로 가장한 백수가 아닌 진짜 백수가 되어야겠다.

notnull의 이미지

C 를 배우기 전에 먼저 C++ 을 배울 필요성이 있다고 생각합니다.

C를 처음 공부해본 사람은 C++ 의 클래스 개념으로 넘어가는데 너무 힘들어 집니다.

C 를 한 시간이 오래되면 오래될 수록 c++ 은 정말 이해하기 힘든 언어입니다.

그래서 제 생각엔 c++ 을 먼저 하고 그 다음에 C 를 하고 그 다음에 어셈을 하는것이 좋다고 봅니다.

어떤 기계가 무슨 작동을 하는것인지도 모르는 상황에서 그 기계의 부속품 하나하나에 대해서 공부한다는것 자체가 너무 어렵지 않겠습니까?

nimbusob의 이미지

물론 많이 아는것이 중요하지만 'C의 포인터를 쉽게 이해하기 위해' 어셈블리어를 배우는 것은 어불성설이라 생각됩니다.

뭐 내가 짠 C언어가 어떻게 기계어로 바뀌고 실행되는가

이런 것에 대한 궁금증이 있으시다면 자연스레 컴퓨터 구조론과 어셈블리어를 배우게 되시겠지만요

'문자열' 은 단순한 문자열이 아니라 글자 하나하나의 *배열* 집합이다

보통 포인터 단원을 보면 위와 같은 대목이 많이 나오는데

위와 같은 설명 이후에 따라오는 코드만 봐서는 솔직히 모르는게 사실이고요

포인터를 잘 이해하고 싶으시면 말그대로 '가리킨다' 는 의미를 가진

그림을 그려가면서 이해하시는 것이 훨씬 더 빠른 이해를 돕는다고 생각합니다.

포인터와 일반 변수가 헷갈리는 이유는 선언방식이 매우 비슷하기 때문인데

코드를 읽어보실 때도 char* 는 캐릭터 포인터형 변수, char 는 캐릭터형 변수

이렇게 놓고 보시는 게 차라리 편합니다.

대부분의 c언어 입문서를 살펴보면

char *pChar /* myPchar 는 캐릭터 포인터형 변수 */
char myChar /* myChar 는 캐릭터형 변수 */

뭐 이런식으로 코드를 적고 포인터 변수에는 p를 붙여라 이런식의 설명이 많은데

차라리

char* myPchar /* myPchar 는 캐릭터 포인터형 변수 */

위와 같은 식의 설명이 훨씬 더 와 닿겠죠

익명사용자의 이미지

궁금해서 art of assembly를 약 1/8정도 읽은적이 있는데...
상당히 재밌습니다. 쏠쏠히 도움도 되구요.
지금은 집구석 어딘가 있을텐데...

shji의 이미지

어셈블리를 공부하는 것이 물론 포인터 이해에 도움은 되겠습니다만
C 포인터를 이해하기 위해서 꼭 필요하다고는 생각되지 않습니다.
대신 컴퓨터 구조와 메모리와의 관계.. 그리고 C 언어에서의 변수의
의뫄 실제로 사용되는 방법에 대해서 개념 설명하는 것만으로
포인터는 충분히 이해시킬 수 있다고 생각하는데요..
(설명하지 못한다면 자신이 정확히 이해하고 있지 못하다고도 할 수
있지 않을까요?..^^;;)

물론 임베디드 시스템이나 DSP에서 코드 최적화를 C 언어 수준에서
진행하려면 C - ASM의 관계, 프로세서의 구조와 동작 방법/특성을
알아야 합니다만.. 이러한 특수한 경우에는 어느정도의 어셈 지식이
필수겠죠..

그렇지 않고 하이레벨/어플리케이션 개발쪽 분야라면 어셈을 익히는
시간에 다른 공부를 하는 것이 좋을 듯 합니다.

(이 곳에서는 이미 어셈의 개념을 알고 계신 분들이 많은 듯 하지만요..
이미 알고 계시다면 뭐 좋은 거죠..)

묵검추의 이미지

사실 생각을 해보면...

소프트웨어나 프로젝트를 만드는것에 있어서 기획 설계가 중요하지 되지 굳이 DB나 자바를 몰라도 되죠..

자바를 이해함에 있어서 참조나 이런 개념 때문에 C 를 알 필요는 없구요.....

C를 이해할때 포인터 때문에 어셈을 할 필요는 없는거죠 뭐..

어셈을 잘 하기 위해서 컴터를 이해할 필요는 없는거구.. 컴터를 잘 이해하려고 수학을 알 필요도 없죠..

^^;

생각해 보면 아무것도 몰라도 프로그램을 완성할 수 있는데.. 괜히 이것저것 공부하나 봅니다. -_-;

ftfuture의 이미지

저 학교다닐때만 해도 전산쪽에선 컴퓨터 구조가 기본 커리큘럼 이었던것 같은데요..
그리고 그 수업하면서 어셈도 병행했었습니다.
자기 하는 일에 필요없을지도 몰라도 공부하는 입장이라면 배우는거에 한표입니다.