클래스 템플릿이 컴파일에서 실행될 때까지의 과정이 어떻게 되나요?
글쓴이: dltkddyd / 작성시간: 목, 2014/06/05 - 7:18오후
클래스 템플릿이 컴파일에서 실행될 때까지의 과정에 대해서 궁금한 점이 몇 가지 있습니다.
첫째, 클래스 템플릿의 정의는 언제 바이너리 코드로 변환되나요?
둘째, 해당 클래스 템플릿으로 선언된 객체가 있을 때 그에 대한 클래스의 정의와 멤버함수들은 어떠한 방식으로 두 번째 코드와 결합되는 것인가요? 그리고 그 시점이 컴파일시인가요? 그리고 인자로 받은 타입들에 따른 정의와 멤버함수바이너리 코드를 만들어내는 것인가요? 아니면 정의부에 타입을 껴맞우어서 그에 해당하는 멤버함수 코드를 찍어내는 것인가요?
셋째, 명시적 구체화라는 것은 객체의 선언 없이 정의부와 멤버함수를 바이너리리 코드로 만드는 것인가요? 그리고 그 시점은 컴파일시인가요?
넷째, 특수화라는 것도 객체의 선언 없이 정의부와 멤버함수를 바이너리 코드로 만드는 것인가요? 그리고 그 시점은 컴파일시인가요? 이 경우에는 왠지 컴파일 시점같긴 한데요.
Forums:
책 좀
책 좀 읽으세요.
http://www.amazon.com/C-Templates-The-Complete-Guide/dp/0201734842
낚였네요.
낚시중이신가요. 책 사서 보라고요? 답변이나 좀 주시지.
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
클래스 템플릿은 그것이 구체화될 때 그 구체화된
클래스 템플릿은 그것이 구체화될 때 그 구체화된 인스턴스가 그것이 정의된 소스파일에 대응하는 오브젝트 파일 안에 생성되고, 클래스 템플릿의 인스턴스 클래스와 다시 그것의 인스턴스 객체가 결합되는 건 일반 클래스가 그 클래스의 인스턴스와 결합되는 것과 다르지 않게, 즉 일반적인 컴파일러의 코드가 그것이 다루는 데이터를 찾아 결합하는 것과 다르지 않게, 정적 데이터는 링크 시에 동적 데이터는 런타임에 코드가 데이터의 주소를 알고 있음으로써 결합되며, (템플릿) 인자로 받은 타입들과 템플릿으로 생성되는 인스턴스 코드/데이터는 템플릿이 구체화될 때 구체화되는 코드들이 그보다 선행하여 구체화되었을 인자 타입들의 주소 - 혹은 주소의 오브젝트 파일 내 주소 - 혹은 실행 중인 컴파일러 주소 공간 내 특정한 테이블의 주소 - 를 참조함으로써 이루어지며, 네 명시적 구체화는 템플릿이 그것을 묵시적으로 사용하지 않고서도 주어진 인자들로 구체화된 인스턴스의 바이너리 코드와 정적 데이터를 명시화가 이루어진 소스코드에 대응하는 오브젝트 파일 내에 생성하며, 특수화는 템플릿의 구체화와는 상관이 없으며 단지 해당 템플릿이 특정한 인자에 대해 어떻게 구체화할 것인지를 일반 정의와는 달리 하라는 것을 명시하는 것일 뿐으로 컴파일러 실행 단계에서야 일반 정의의 해석과 특수화의 해석은 선후 관계이겠으나 그것은 컴파일러 구현 내부의 일로서 사용자로서는 알 바 아니겠습니다. 그리고 이 모든 건 '컴파일' 중에 일어납니다. 인터프리터 구현이 아닌 이상은요. 그리고 그 각각의 단계들은, 언어 명세와 구현을 가르는 높고도 유용한 벽 너머에서 구분되는 단계들로서 구현마다, 구현의 버젼마다 다릅니다.
분명 님은 이 말을 자세히 읽은 뒤, 대충 무슨 말인지 알았다고 생각할 겁니다. 천만에요. 그건 벽 너머에 가보지 않은 채 벽 너머의 정해지지 않은 변화무쌍한 것들에 대해 누군가가 그렇다고 하는 말을 듣고 머릿속으로만 상상하는 것에 불과합니다.
정말로 알고 싶으면 실제 구현을 들여다보세요. 구현을 들여다 볼 실력이 안되면, 대학에서 시스템 프로그래밍/컴퓨터 아키텍쳐와 컴파일러 과목을 들으시면 되겠습니다. 그것들을 댓글로 가르쳐 달라는 생떼는 그만두시고요.
그런데 클래스 템플릿이 구체화될 때 코드 비대화가 초래되는 이유는 뭘까요?
-제 질문 -
클래스 템플릿이 컴파일에서 실행될 때까지의 과정에 대해서 궁금한 점이 몇 가지 있습니다.
첫째, 클래스 템플릿의 정의는 언제 바이너리 코드로 변환되나요?
둘째, 해당 클래스 템플릿으로 선언된 객체가 있을 때 그에 대한 클래스의 정의와 멤버함수들은 어떠한 방식으로 두 번째 코드와 결합되는 것인가요? 그리고 그 시점이 컴파일시인가요? 그리고 인자로 받은 타입들에 따른 정의와 멤버함수바이너리 코드를 만들어내는 것인가요? 아니면 정의부에 타입을 껴맞우어서 그에 해당하는 멤버함수 코드를 찍어내는 것인가요?
셋째, 명시적 구체화라는 것은 객체의 선언 없이 정의부와 멤버함수를 바이너리리 코드로 만드는 것인가요? 그리고 그 시점은 컴파일시인가요?
넷째, 특수화라는 것도 객체의 선언 없이 정의부와 멤버함수를 바이너리 코드로 만드는 것인가요? 그리고 그 시점은 컴파일시인가요? 이 경우에는 왠지 컴파일 시점같긴 한데요.
-------------------------------------------------------------
첫 번째에 대해서, 클래스 템플릿은 목적파일에 생성된다. 그러니까 컴파일시 바이너리 코드로 전환이 된가고 이해하면 되겠네요.
두 번째에 대해서, 객체는 일반 변수를 이해하는 방식(스택 또는 힙 또는 데이터 영역)으로 결합된다고 알면 되겠군요, 인자는 미리 컴파일 되어 특정 공간을 참조하는 것으로 알면 되겠구요. 그런데 책에는 인자가 다른 경우에 코드 비대화가 초래된다고 하는군요. 즉 답변 주신대로 인자를 참조만 한다고 한다면(설명해 주신 것이 틀렸다는 뜻이 아닙니다) 코드 비대화라는 설명을 책에서 하지 않을 텐데요. 책(Effective C++, 스콧 마이어스 저)에는 이런 식으로 설명을 합니다.
Test 안에는 여러 벌의 멤버함수가 존재합니다. 위와 같이 선언할 경우 obj1과 obj2에 대해 코드 비대화를 초래한다고 합니다. Test에 afun이라는 함수가 있다면, obj1.afun()과 obj2.afun()은 다른 것입니다. 그리고 클래스 템플릿이 구체화될 때 코드 비대화가 초래된다고 했으니, 코드를 컴파일시에 박아넣었다는 것을 전제하고 말하는 듯 하던데요. 여기서 코드 비대화가 일어나는 이유는 뭔가요? 단순히 템플릿 인수를 참조만 하는 것이라면 코드 비대화가 일어나지 않을텐데.
Effective C++ p320(스콧 마이어스 저, 제3판) p320
-이것만은 잊지 말자-
템플릿을 사용하면 비슷비슷한 클래스와 함수가 여러 벌 만들어집니다. 따라서 템플릿 매개변수에 종속되지 않은 템플릿 코드는 비대화의 원인이 됩니다.
이렇게 언급되 있군요.
세 번째, 네 번째도 컴파일시에 일어나는 동작으로 알면 되겠군요.
님께서 "정말로 알고 싶으면 실제 구현을 들여다보세요. 구현을 들여다 볼 실력이 안되면, 대학에서 시스템 프로그래밍/컴퓨터 아키텍쳐와 컴파일러 과목을 들으시면 되겠습니다. 그것들을 댓글로 가르쳐 달라는 생떼는 그만두시고요. "라고 말씀하셨는데, 또 언급하지 않은 말씀을 하고 계시군요. 그 구현들을 알려달라고 한 적 없습니다. 제 질문에 그 구현이 어떻게 되느냐는 내용은 없었는데. 컴파일러 제작이나 설계자가 아니라면 불필요하게 그런 일에 매달릴 필요가 없지 않겠느냐는 것이 제 생각입니다. 그리고 내가 언제 생떼를 부렸을까? 괜한 트집좀 잡지 맙시다.
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
님아, 적어도 컴파일 언어와 인터프리터 언어의 차이는
님아, 적어도 컴파일 언어와 인터프리터 언어의 차이는 이해하고서 질문해야 답변의 각이 나오죠 ㅋ
"그리고 클래스 템플릿이 인스턴스화될 때(이 때는 컴파일시인가요? 실행시인가요? 그러니까 바이터리 코드가 생성되는 시점이 클래스의 경우는 인스턴스라고 하는 것인지요?)도 GDB로 확인할 수 있는지 궁금합니다."
틀림없이 님이 그간 읽은 책들의 1장 부근에 나와있을 내용만 이해했어도 이런 골때리는 질문-하지만 이번 건 재밌다는 건 인정-을 하진 않았겠죠. 아니, 잘 이해 못한다고 타박하는 게 아니라, 공부에는 순서와 방법이 있는 건데.. 질문도 답도 참 돌고 돌아 힘드네요. 실은 정말 간단한 건데.
님이 말한 건 전부 컴파일 단계에서 일어납니다. 템플릿이고 클래스고 자시고 간에 님이 알고 있는 C++과 관련된 모든 건 C++ 컴파일러(와 링커)가 처리하는거고, 머신은 인스트럭션 코드 - 기계어 - 밖에 몰라요. 님이 디버거로 열어봤을 때 접한 이상한 짧은 영문 코드들이 그 기계어(에 1:1 대응하는 어셈블리어 코드)입니다.
GDB는 메모리에 로드된 프로그램의 디버깅 정보 영역을 참조해서 현재 실행 중인 메모리 상의 이진 주소가 어느 소스 파일의 몇번째 줄인지를 알아내서 보여줄 뿐, 그리고 단지 사용자가 입력한 심볼 이름과 expression을 제한적으로 이해해서 실행시간에 출력해줄 뿐, 인터프리터와는 근본적으로 출발하는 곳이 다릅니다.
무슨 책?
그리고 GDB가 디버거 아닌가? 다른 건가.
그리고 인터프리터에 대해서는 질문한 적 없는데. 인터프리터는 실행시 한 줄 한 줄 기계어로 해석하는 해석기를 말하는 것이야. 그 정도는 알고 있어. 반드시 알고 있어야 하는 다른 차이점이 있니?
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
"그리고 클래스 템플릿이 인스턴스화될 때(이 때는
"그리고 클래스 템플릿이 인스턴스화될 때(이 때는 컴파일시인가요? 실행시인가요? 그러니까 바이터리 코드가 생성되는 시점이 클래스의 경우는 인스턴스라고 하는 것인지요?)도 GDB로 확인할 수 있는지 궁금합니다."
님이 이미 알고 계신 그 차이에 비추어 생각해보시면 저 시점이 언제인지는 자명하지 않느냐는 말씀입니다. GDB로 그 시점을 확인해보려는 발상이 좀 재밌어서요 ㅎㅎ 아직 개념이 정립되지 않은 상태에서 접한 GDB는 마치 C++ 인터프리터처럼 느껴질 수도 있겠다 싶어서 드린 말씀입니다.
다른 카테고리에 올린 GDB글을 보고 하는 말씀이시군.
이 글 카테고리는 프로그램이라 다른 카테고리에 GDB 질문을 올렸는데.
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
template<class T, int nun>
이 소스코드를
로 컴파일하면, a.o라는 목적파일이 생성됩니다. 이를
로 조사해보세요. 그리고 이를 (1)과 (2)를 하나 씩 주석처리하고 컴파일한 다음에도 해보시길. 그러면
에 대해 답을 본인 눈으로 직접 확인하실 수 있을 겝니다 ㅋ
저런, 코드 포매팅이 이상하게 되었군요. 상대방이
저런, 코드 포매팅이 이상하게 되었군요. 상대방이 해보라고 할 때는 정확한 코드를 올려야 하는데..
Test::get()
함수에서 깨진 부분은return x [ index ];
입니다.그렇군요.
이상하더라 했습니다. 고쳐보면 되겠군요. 올릴 때는 먼저 본인이 실행부터 하고 올리셔야죠.
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
ㅋㅋㅋㅋㅋ 안됐지만 이번에도 꽝입니다. 댓글달기 할
ㅋㅋㅋㅋㅋ
안됐지만 이번에도 꽝입니다. 댓글달기 할 때 나오는 "입력형식" 열어보시고, BBCode가 뭔지 알아보셔요.
엔지니어들은 님 같지 않아요 ㅋ 답변이 틀리면 쪽팔리기 때문에라도 당연히 미리 다 확인해보고 올립니다. 개념 없는 질문자들은 대충 생각나는대로 온라인에서 끄적여서 올리는 것 같지만.
대책 없는 사람이군요. 그쵸.
당신 같은 사람도 엔지니어라고 하는군요. 저 간단한 코드도 틀릴 정도로 어설플 사람이 엔지니어라. 그쪽을 보면 엔지니어 별것 아니라는 생각이 드는군. 쪽팔린 짓(본인 입으로)을 하고도 쪽팔리지 않다. 이거 또 모순이네. 모순 덩어리 엔지니어가 짠 코드에 대해서는 별로 관심이 없습니다.
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
저게 컴파일이 되더이까?
코드 비대화와는 상관이 없는데, 님이 언급한 get을 한 번 보시죠. 참 어이없는 꼬라지군요. 저걸 멤버라고 만든건가. ㅋ.
.
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
ㅋㅋㅋㅋㅋㅋ 아쉽다, 그쵸? ㅋㅋㅋㅋㅋㅋ
ㅋㅋㅋㅋㅋㅋ
아쉽다, 그쵸?
ㅋㅋㅋㅋㅋㅋ
먼저 손을 쓰셨군요.
ㅋ
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
질문 올리실 때 말로 어렵게 길게 설명하면서 코드는
질문 올리실 때 말로 어렵게 길게 설명하면서 코드는 글 쓰는 순간에 대충 쓰시는 경향이 있던데요, 그러지 말고 내가 컴파일 해본 바로 그 코드를 고대로 복사해서 올리시면 설령 질문이 부정확하더라도 사람들이 그 코드를 보고 님 질문의 의도를 알아낼 수 있습니다. 질문하는데 그 정도 성의는 보여야죠 ㅋ
물론 답변하는 사람들이 그 정도 성의를 보이지 않았다고 뭐라 할 순 없죠.
저 질문은 지극히 이론적인 것이죠.
코드를 올릴 부류의 질문이 아니기에 그렇게 한 거죠. 코드를 올릴 필요가 있는 질문인 경우에는 코드를 올리죠. 너가 코드 올릴 때는 먼저 실행부터 하고 올려야죠. ㅋ. 물론 성의있는 답변을 주시면 감사하겠죠. 그런데 그런 차원의 문제가 아니라 기본적으로 상대방을 대하는 태도가 바르지 못하기 때문에 그렇지.
그리고 저 질문이 어렵다고 한다면 님이 처음에 답변하신 글을 한 번 보시죠. 글이란 것은 이어서 길게 쓴다고 좋은 글이 아닙니다. 상대방이 알아듣기 쉽게 간결해야지. 국어 공부가 부족하신가?
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
질문이 어려운 건
질문이 어려운 건, 님이 표현하고자 하는 개념들에 비해 님이 사용하는 용어들이 부정확한데, 질문 할 때 충분히 시간을 들여 가다듬으려 하지도 않기 때문이죠. 그러니 읽는 사람도 어려운 거고.
그러니 걍 코드를 정확히 올리시는게 편하실거라, 그 말씀입니다 ㅋ 말 나온김에 얘기한 거죠. 이번 질문 얘기가 아니라.
어셈블리어도 하시나요?
get이 껴들어 가는군요. 쏟아지는 코드들이 assembly 코드인가요?
ABS
.text
.data
.bss
.note.GNI-stack
.eh_frame
.comment
.group
도대체 알아들을 수 없는 단어들이군요. 또 영문법 책보라는 말씀은 하지 마세요. 그리고 연이은 숫자들은 주소인가요?
제 눈에 띄는 것은 주석 처리 안 할 경우에는
두 벌의 get이 박히고
주석 처리 할 경우에는
get이 온데 간데 없다는 겁니다.
그리고 objdump는 어셈블리 출력명령인가? 그 뜻은 아실지? 모르면서 해보라고 한 거 아닌가요?
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
어셈블리어는 아닙니다. objdump는
어셈블리어는 아닙니다.
objdump
는gcc
/g++
이 생성한 바이너리 파일들(ELF 포맷이라 합니다)의 내부를 조사하는 명령입니다. 컴파일된 실행 파일이나 목적 파일 내부를 들여다보는거죠.지금은 저것들이 뭔지 공부하시기엔 버거우실테고, 눈에 띄신대로
Test::get()
이 템플릿 인자에 따라 두 벌 생겼다는 것, 즉 하나의 템플릿에서 두 개의 구체화된 바이너리 코드가 목적 파일 내에 생성되었다는 것만 확인하시면 됩니다..text
영역에요. 정적 변수를 정의하면.data
영역에 나타나겠죠. 짐작하시겠지만 저 두 영역이 코드 영역과 데이터 영역입니다.심볼 이름 앞의 숫자는 -
main
앞에도 붙어있죠 - 각 영역에서의 오프셋 주소를 나타냅니다. 이 주소들이 실제 주소는 아닙니다 -g++ a.o b.o c.o -o myprog
이런 식으로 목적 파일들을 링크하는 과정을 거쳐야 실제 주소가 나오죠.이번에는 맨 앞의 주소가 0이 아닐 겁니다. main과 두 Test::get()의 주소를 기억해뒀다가, 다음을 실행해봅니다
저 주소를 virtual address라고 합니다. 실행중인 프로세스의 메모리 주소 공간에서 각 심볼들이 갖는 주소값입니다. 포인터는 이 값들을 가집니다.
오프셋이 아니라 사이즈군요 ㅋ 잘못된 정보 죄송
오프셋이 아니라 사이즈군요 ㅋ 잘못된 정보 죄송
얘도 결국 더티잡 앞에서 작아지는 전형들의 한계를
얘도 결국 더티잡 앞에서 작아지는 전형들의 한계를 그대로 보일까? ㅋ
존재감 없는 인간들이란...
자신이 하는 일에 대한 자부심은 없고, 남에 대한 존중감도 없는 쓰레기 같은 인격의 극치를 보이는 군상들이다. 제 눈에 안경이라고 빨간 안경 끼면 세상이 온통 빨갛게 보이지. 쓰레기 같은 곳에 몸담고 있으니 남도 그럴 것이라는 섣부른 판단. 아이 같은 짓거리는 그만 하거라. 엔지니어면 뭐 할거고, 산을 무너트릴 만한 힘이 있은 들 무엇하겠냐? 벌써 말하는 폼이 저러한데.
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
글쎄요 ㅋ 사람 사이는 결국 상호작용 아니겠습니까?
글쎄요 ㅋ 사람 사이는 결국 상호작용 아니겠습니까? ㅎㅎ
결국 본인의 세계관을 벗어나지 못한다는 것이지.
익명은 역시 그다지 존재감이 없어요. 별반 크게 도움 받을 것도 없고. 먼저 해놓고는 오리발 내미는 식이지. 너희 같은 부류 한테는 별반 본받을게 없다. 꺼져라.
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
그냥 웃지요. 전 여기까지! ㅎㅎ
그냥 웃지요. 전 여기까지! ㅎㅎ
말을 해...
뭔지를.. 그래야 무슨 더티잡인지 알 것 아닌가. ㅋ. 개 같이 코를 킁킁대는 부류겠지. 네가 하는 일이 더티잡이라 그리 말한 것이구나. ㅋ.
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
더티잡이란 손에 기름밥 묻히는 작업을 말한
더티잡이란 손에 기름밥 묻히는 작업을 말한 답니다~
그냥 가면 결국 끝까지 모를거 같아서~ 마지막으로 요것만 남겨요
https://kldp.org/node/143019#comment-604380
이 한마디 했다고 님이 뭐라고 했는지 함 보셔요 ㅋㅋ
쩝 그래도 요 위에 건 미안합니다 ㅎ 공부 잘
쩝 그래도 요 위에 건 미안합니다 ㅎ 공부 잘 하셔요~
이렇게 됐어도 일단 제 실수로 인한 당치 않은 오해는
이렇게 됐어도 일단 제 실수로 인한 당치 않은 오해는 제대로 풀어야 되니까.
기술을 배울 때, 특히 주어진 일반적인 설명이나 방식에 만족하지 못하고 깊이 파고들고자 하는 사람이라면, 결국 잘 만들어진 범용 도구 대신 특수한 도구를 쓰게 됩니다. 도구는 - 인간이 하는 모든 기예가 그렇지만 - 그 과정에 필수적이면서도, 딱히 어떤 매끈하고 우아한 어떤 이론이 있는 것도 아니고 잡다 난해하고 익히려면 많이 써보는 수 밖에 없어서, 접근하기에 부담이 되죠. 개념틀을 착실하게 닦으며 나름 성실하게 공부해온 이들도, 의외로 이 문턱 앞에서 지레 겁먹고 잘 접근하려 하지 않는 경우들을 종종 봅니다. 특히나 축적해온 도메인 지식이 부족한 초보나 비전문가들에게는 더 그렇습니다. 알고 보면 별 것 아니고, 처음에는 낯설어 보이던 기호들을 차츰 알아볼 수 있게 되면서 내가 활용할 수 있는 것들이 늘어나는 재미 또한 쏠쏠한데 말입니다 ㅎㅎ 뭐, 그런 의미였습니다. 조금 도발의 의도를 섞긴 했지만, 원래 의도와 전혀 다른 의미로 받아들이신 모양이라 아차 싶었습니다 ㅎㅎ 모욕적으로 느껴진 것 같은데, 의도는 아니었어도 제 실수가 맞습니다. 미안함 전하며.
그쪽이 어떻게 했는지를 보세요.
https://kldp.org/node/143019#comment-604370
-너의 말씀-
고집만 쌓인 결과물이라 할 수 있습니다.
호기심이 많으면 뭐하나요? 그걸 자의적으로 해석해서 잘못된 지식만 잔뜩 쌓았는데.
요샌 귀찮은지 검색도 안하고 그냥 바로 kldp에 올려버리는듯 하더군요.
그리고 설명해주는 사람들과 싸우죠. 왜 내가 생각한 대로 안움직이냐고.
'초보자/일반인'(라지만 결국 자기 자신)에게 익숙한 방식으로 동작되어야 마땅하지 않냐고.
꼭 저분만 그러는게 아니고 이런 식으로 성내는 사람들이 대대로 꽤 많았습니다.
가장 골치아픈게 어셈 코드 들고오는 부류죠.
-------------------------------------------------------------------------------------
넘겨 짚어서 아무렇게나 말합니까? 전문가는 전문가라서 골치아프고, 쉬워 보이는 사람에 대해서는(지가 보기에만 그렇지) 만만해서 니 맘대로 넘겨짚어서 비하하고. 뭐 이런 부류가 다 있나.
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
ㅋㅋㅋㅋ 이보세요. 제 댓글이 지금 이 댓글에
ㅋㅋㅋㅋ
이보세요. 제 댓글이 지금 이 댓글에 반론을 제기하는 거 잖아요?
다시 읽어보세요.
아유 부끄러워라~ 상대가 익명이라고 넘겨짚고 말 함부로 했다가 이게 무슨 꼴이람~
시끄럽다.
집어치워버려라.
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
국어 공부 다시 하셔야겠어요~ 어쩌나 이거 ㅋㅋㅋㅋㅋ
국어 공부 다시 하셔야겠어요~ 어쩌나 이거 ㅋㅋㅋㅋㅋ
완전히 XXX돼시면 안됩니다.
정신 차리세요. 요 위쪽의 '그쪽이 어떻게 했는지를 보세요' 글은 님의 먼저 올린 글에 대해 언급한 글입니다. 님이 먼저 어떻게 말을 했는지. 익명 뒤에 숨어서 비겁하게 남을 비하한 것은 그 쪽입니다.
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
ㅋㅋㅋ 제가 "디스어셈블 해보세요"라고 하니까,
ㅋㅋㅋ
제가 "디스어셈블 해보세요"라고 하니까, 누군가가-지금 님이 링크한 댓글-을 달았죠. 그래서 제가 거기에다가 '제대로 파보면 된다'라고 다시 댓글을 달았죠. 거기에 님이 댓글을 달았고요.
ㅇㅋ?
ㅎㅎ
이걸 도대체 어쩌면 좋아... 아이고 ㅋㅋㅋㅋㅋㅋ
이걸 도대체 어쩌면 좋아... 아이고 ㅋㅋㅋㅋㅋㅋ
질문자도....
어쩌고 저쩌고라고 한 것은 누굴 지칭한 겁니까? 글에는 그 사람의 독특한 문체가 녹아 있습니다. 동일인인데. 어디서 어설프게 속아넘기려고.
본인 맞습니다.
인증샷
우헤헤헤... 로 대신합니다.
됐고요. 걍 잘 살아요 ㅋ 안녕~
됐고요. 걍 잘 살아요 ㅋ 안녕~
위의 분들께서는 왜 이사람에게 굳이 답변을 해주려
위의 분들께서는 왜 이사람에게 굳이 답변을 해주려 애쓰시는지 모르겠군요.
전 개인적으로, 이사람에게 도움이 되는 답변은 일체 작성하지 않겠다고 정한 상태입니다.
어차피 답변 해줘도 못알아듣고, 거기서 말꼬리 잡아서 시비 걸 생각만 만만한 사람입니다.
모든 질문에 답변해주려는 엔지니어적인 근성이 사람 한명 버릇을 망친 셈입니다.
위에도 썼지만 결국 상호작용이라 생각합니다. 고집은
위에도 썼지만 결국 상호작용이라 생각합니다.
고집은 근성의 다른 표현이기도 합니다. 미리 가본 사람들이 거기 돌이 있다, 그 길로 가면 헤맨다고 알려줘도, 제 발로 가서 꼭 걸려 넘어져 봐야, 꼭 헤매봐야 직성이 풀리는 사람들이 있죠. 시간과 노력의 낭비임에 틀림없으나 그만큼 확실하게 이해하는 법이 없기도 하죠, 포기하지 않는다면, 그리고 결국 인정할 수 있다면. 가끔 보이는 가당 찮은 만용이야, 계속 그러면 결국 제 발목을 잡을 거고. 하지만 개발자들은 기본적으로 다 그런 성향 갖고 있지 않나요 ㅋ 그거야 흠이 안된다고 생각하지만, 기술적 소통에 필요한 엄밀함의 필요를 잘 인정치 않으려는거나 본인이 세운 가설을 남을 통해 확인하려는 건 좀..
어떤 사람인지야 익명의 글들만으로 어찌 다 알겠습니까마는, 사람들한테 이런 저런 냉정한 지적을 들을 때마다 자존심에 반발은 해도, 본인이 합리적이다 싶은 것들은 행동에 변화를 조금씩 보이는 것 같아 또 모른다고 생각하기도 합니다. 한편으로 자기가 불리할 때만 쏙 들어가거나 필요한 걸 알려줘도 credit을 인정하는데 인색한 걸 보면서는 - 이유야 짐작이 가지만 그렇다면 나라면 둘 중 하나만 선택할텐데 - 뭐 그런가 싶기도 하고요. 하여간 뭐~ 전 이제 아웃.
댓글 달기