라벨 이 C 인 게 시물 표시 
 2018 년 19 번 째 주 
 - 5 월 13 , 2018 
 보통 하 는 일 과 관련 된 글 들 이 올라오 겠 지만 딱히 정해둔 주제 는 없 고 , 그때 그때 관심 있 었 던 것 을 읽 었 기 때문 에 지난주 에 쓰인 글 일 수 도 있 고 몇 년 전 에 쓰인 글 일 수 도 있 습니다 . C PrimerPrimer 를 입문서 라고 번역 하 는 게 맞 는지 모르 겠 지만 , 어쨌든 C 입문서 라고 이름 붙인 문서 중 에서 가장 마음 에 든다 . 다른 언어 는 잘 추상 화 된 모델 을 다루 는 것 이 중요 하 지만 C 는 아니 라고 생각 한다 . C 는 내 가 사용 한 코드 가 어떻게 변환 되 어 실행 되 는지 기계 단위 로 이해 하 고 있 어야 한다 . 그럴 필요 가 없 는 상황 에서 는 C 가 아닌 다른 언어 를 써야 한다 . C Is Not a Low - level LanguageC 가 low - level 언어 는 아니 라는 글 이 다 . 전통 적 으로 low - level 언어 는 머신 에 대한 추상 화 없이 기계어 와 일 대 일 대 응 되 는 언어 를 의미 한다 . 당연히 이런 의미 에서 C 는 low - level 언어 가 아니 다 . C 는 나름 의 abstract machine 을 가지 고 있 다 . 특히 C 11 이후 로 는 멀티 쓰레드 에 대한 개념 도 abstract machine 에 들어갔 기 때문 에 전통 적 인 의미 에서 low - level 언어 는 아니 다 . 그렇 다고 해서 C 가 다른 high - level 언어 와 같 다는 의미 는 아니 다 . 다른 high - level 언어 들 은 실제 기계어 로 어떻게 번역 되 는지 몰라도 될 정도 로 abstract machine 을 정의 한다 . 하 지만 C 는 아니 다 . 사실 나 는 C 의 abstract machine 도 기계 를 몰라도 사용 할 수 있 을 정도 로 잘 정의 돼 있 다고 생각 한다 . 문제 는 C 를 사용 하 는 사람 들 이 실제 기계 에서 어떻게 돌아가 는지 고려 하 면서 코드 를 작성 한다 . 이건 C 언어 커뮤니티 의 문제 는 아니 다 . 사실 기계 레벨 에서 어떻게 돌아가 는지 고려 하 지 않 아도 되 는 프로젝트 에서 C 를 사용 하 는 것 은 얻 는 것 에 비해서 비용 이 크 기 때문 이 다 . 카카 … 
 - 4 월 22 , 2018 
 보통 하 는 일 과 관련 된 글 들 이 올라오 겠 지만 딱히 정해둔 주제 는 없 고 , 그때 그때 관심 있 었 던 것 을 읽 었 기 때문 에 지난주 에 쓰인 글 일 수 도 있 고 몇 년 전 에 쓰인 글 일 수 도 있 습니다 . ISO week date 오늘 이 올해 의 몇 번 째 주 인지 정하 는 기준 은 말 하 는 사람 마다 다르 다 . 그래서 이 요약정리 시리즈 는 ISO 8601 기준 으로 몇 번 째 주 인지 표기 한다 . ISO 8601 에 따르 면 1 월 4 일 이 포함 된 주 를 그 해 의 첫 번 째 주로 취급 한다 . 다른 말 로 한 주 의 시작 을 월요일 로 봤 을 때 4 일 이상 포함 된 첫 번 째 주 가 그 해 의 첫 번 째 주인 것 이 다 . TextQL 머신 러닝 이나 데이터 마이닝 을 할 때 데이터 의 경향 성 을 대강 파악 하 고 싶 을 때 가 있 다 . 이럴 때 사용 되 는 데이터 는 보통 매우 큰 데이터 이 기 때문 에 에디터 로 열 어서 보 는 것 은 무리 가 있 고 , 간단 하 게 스크립트 를 짜 서 실행 하 게 된다 . 근데 이때 하 는 일 은 대부분 비슷 한 일 이 기 때문 에 꽤 나 귀찮 은 작업 이 었 는데 , 스크립트 를 짜 지 않 고 파일 을 SQL 을 실행 시켜 주 는 프로젝트 가 있 었 다 . 아직 사용 해 보 지 는 않 아서 직접 스크립트 를 짜 는 것 과 비교 하 면 어떨지는 모르 겠 지만 꽤 많 은 사람 이 쓰 고 있 는 것 같 다 . Writing 수학 을 배워야 하 는 이유 가 사고 하 는 법 을 익히 기 위해서 이 듯이 , 글쓰기 를 배우 는 이유 는 무엇 을 생각 했 는지 명확 하 게 하 기 위해서 다 . 사람 은 모든 것 을 기억 할 수 없 기 때문 에 자신 이 생각 한 것 을 써서 정리 해야 한다는 것 이 다 . 게다가 글 을 쓰 는 것 은 내 가 글 쓰 는 주제 에 대해 나 보다 모르 는 독자 를 가정 하 고 글 을 쓰 게 된다 . 그래서 평소 에 는 당연 하 게 생각 하 고 넘어갔 던 것 들 에 대해서 도 한 번 더 생각 하 고 넘어갈 시간 을 가지 게 한다 . How quantum computing could wreak havoc on cryptocurrency 양자 컴퓨터 가 상용 화 되 면 현재 사용 … 
 - 2 월 09 , 2018 
 Tagged pointer 는 메모리 크기 를 줄이 기 위한 고전 적 인 테크닉 이 다 . 기본 적 인 아이디어 는 포인터 의 모든 값 이 의미 있 는 값 은 아니 라는 것 이 다 . 예 를 들 어 4 byte 단위 로 align 되 는 객체 의 32 - bit 포인터 를 생각 해 보 자 . 그렇 다면 이 객체 의 주소 는 4 로 나누 어 떨어지 는 값 이 돼야 하 니 LSB ( Least Significant Bit ) 으로 부 터 2 bit 은 언제나 0 b 00 으로 고정 될 것 이 다 . 그렇 다면 이 2 bit 을 다른 정보 를 담 는 데 써도 아무 문제 가 없 다 . 조금 더 구체 적 으로 경우 포인터 의 값 이 0 x 5678 FFF 0 , 0 x 5678 FFF 1 , 0 x 5678 FFF 2 , 0 x 5678 FFF 3 인 경우 모두 0 x 5678 FFF 0 에 있 는 객체 를 가리키 도록 하 고 , 0 x 5678 FFF 4 , 0 x 5678 FFF 5 , 0 x 5678 FFF 6 , 0 x 5678 FFF 7 인 경우 모두 0 x 5678 FFF 4 를 가리키 는 포인터 로 해석 하 는 것 이 다 . Tagged pointer 를 만드 는데 LSB 만 쓸 수 있 는 건 아니 다 . 보통 user space 에서 쓸 수 있 는 최대 메모리 가 제한 돼 있 다 . 예 를 들 어 32 - bit 윈도우 에서 user space 는 최대 3 GB 까지 늘릴 수 있 지만 , 기본 적 으로 2 GB 이 다 . 즉 , MSB ( Most Significant Bit ) 1 bit 를 tag 에 쓸 수 있 다 . 64 - bit 리눅스 라면 , 프로세스 당 최대 메모리 스페이스 는 256 TB 까지 이 므로 48 bit 만 사용 된다 . 즉 , MSB 로부터 16 bit 를 tag 에 사용 할 수 있 다 . 하지만 위 의 두 예 시 에서 보 았 듯이 tag 에 이용 할 수 있 는 MSB 의 크기 는 시스템 별 로 다르 다 . 따라서 MSB 를 tagged pointer 로 사용 하 는 경우 portable 한 코드 를 만들 기 어려워진다 . Tagged pointer 를 모든 포인터 에 일반 적 으로 적용 하 지 않 아도 된다 . 그 보다 는 테이블 같 은 것 에 저장 할 포인터 에 만 사용 하 거나 포인터 를 리턴 하 는 함수 에 대해서 만 사용 하 는 것 이 일반 적 이 다 . 특히 포인터 와 추가 정보 를 리턴 하 는 함수 를 tagged poi … 
 - 3 월 04 , 2016 
 리눅스 나 유닉스 같 은 POSIX 시스템 에서 는 fork 를 이용 해서 자신 과 똑같 은 프로세스 를 만들 수 있 다 . 이때 fork 를 호출 한 프로세스 를 부모 프로세스 라고 하 고 , 새로 생성 된 프로세스 를 자식 프로세스 라고 부르 는데 , 자식 프로세스 는 부모 프로세스 의 모든 메모리 를 복사 한다 . fork 는 그 뒤 exec 을 해서 다른 바이너리 를 실행 시키 는 fork - exec 이 일반 적 인 사용법 이 다 . 하지만 자식 프로세스 는 부모 프로세스 와 완전히 같 은 메모리 를 가지 기 때문 에 , 스레드 가 존재 하 지 않 던 시절 에 는 exec 을 하 지 않 고 병렬 처리 를 하 기 위해서 도 자주 사용 되 었 다 . 지금 은 스레드 를 사용 하 는 것 이 더 사용 하 기 쉽 고 가벼운 방식 이 기에 스레드 를 병렬 처리 를 위해 스레드 를 주로 사용 하 지만 , 스레드 보다 서로 간 에 독립 적 이 기 때문 에 일 을 분리 하 기 위해서 사용 하 기 도 한다 . 분명히 fork 는 없 어서 는 안 될 기능 이 지만 fork 에 는 태생 적 한계 가 있 다 . 애초 에 fork 는 스레드 라는 개념 이 존재 하 지 않 던 시절 에 만들 어 졌 기 때문 에 thread - safe 하 지 않 다 . 따라서 멀티 스레드 환경 에서 사용 하 려면 조심 해서 사용 해야 한다 . fork 가 멀티 스레드 환경 에서 문제 를 일으키 는 이유 는 fork 가 부모 프로세스 의 메모리 를 전부 복사 하 지만 , fork 를 호출 한 스레드 를 제외 한 나머지 스레드 들 은 죽 어 버리 기 때문 이 다 . 따라서 fork 를 호출 한 스레드 이외 의 스레드 에서 획득 한 자원 은 아무것 도 해제 되 지 않 는다 . 메모리 릭 도 충분히 문제 지만 , 이 는 단순 한 메모리 릭 만 을 의미 하 지 않 는다 . fork 가 복사 한 메모리 에 는 힙 이나 스택 이외 에 mutex 나 condition variable 들 도 포함 된다 . 만약 mutex 나 condition variable 이 다른 스레드 에서 사용 된 채 로 fork 된다면 해당 변수 로 보호 되 는 critical section 에 는 다시 는 진입 할 수 없 게 된다 . 특히 나 malloc 같 은 thread - safe 한 함수 는 대부분 내부 적 으로 글로벌 한 mutex 를 사용 하 기 때문 에 내 코드 에 mutex 가 없 어도 안심 … 
 C 는 C ++ 의 부분 집합 이 아니 다 
 - 4 월 02 , 2015 
 오늘 황당 한 글 을 봤 다 . 
 잘 짜인 C 프로그램 은 C ++ 프로그램 이 다 . 따라서 잘 짜인 C 프로그램 은 C ++ 컴파일러 로 컴파일 할 수 있 어야 한다 . 
 일단 저 말 은 C ++ 의 창시자 인 비야 네 스트롭 스투 룹 이 한 말 이 다 . 하지만 저 말 은 틀린 말 이 다 . " 네 가 뭔데 감히 비야 네 님 을 틀리 다고 하 느냐 " 라는 생각 이 들 겠 지만 잠시 만 진정 하 자 . 나 는 비야 네 님 이 틀렸 다고 하 지 않 았 다 . 내 가 틀리 다고 하 는 것 은 아무런 문맥 도 없이 그냥 저 문구 만 따 와서 말 하 는 사람 을 틀리 다고 하 는 것 이 다 . 
 저 말 은 분명히 1999 년 이전 까지 는 맞 았 던 말 이 다 . 분명히 비 야 네 스트롭 스트룹 은 C ++ 을 만들 면서 C 와 의 호환 성 을 고려 하 였 고 , 당시 의 표준 ( ANSI C ) 을 잘 지킨 C 코드 는 C ++ 컴파일러 로 정상 적 으로 컴파일 되 었 다 . 하지만 그것 은 어디 까지 나 C 99 가 나오 기 전 의 이야기 다 . 
 C 99 에서 는 여러 가지 새로운 기능 을 도입 하 였 고 , C ++ 은 그것 을 이미 다른 방식 으로 구현 하 고 있 었 거나 , 혹은 필요 하 지 않 은 기능 이 라고 생각 하 여 가지 고 오 지 않 았 다 . 게다가 새로운 표준 인 C 11 이 나오 고 , C ++ 도 새로운 표준 인 03 , 11 을 거쳐 14 까지 나오 면서 둘 사이 의 간극 은 이미 어떻게 할 수 없 을 정도 로 커졌 다 . 
 그런 연유 로 비 야 네 스트롭 스트룹 은 잘 짜인 C 프로그램 이 C ++ 프로그램 이 라고 말 할 때 조건 을 붙인다 . " 단 , 이건 C 89 에 한정 한다 . " 라고 . 하지만 요새 C 89 를 쓰 는 프로그램 이 얼마나 있 나 ? 액티브 하 게 작업 이 진행 되 는 프로젝트 중 에서 C 89 를 쓰 는 프로그램 있 으면 가지 고 와봐라 . 찾 으려고 노력 해 본 적 은 없 지만 찾 기 어려울 것 이 다 . 
 따라서 요새 저런 말 을 하 는 사람 은 그냥 공부 를 안 한 사람 이 다 . 그것 도 한 20 년 전 에 공부 했 던 사람 이 니 대선배 님 일 수 도 있 겠 다 . 그 사람 에게 C 99 이후 C ++ 과 스펙 이 변경 되 어 C 99 표준 을 지킨 코드 는 C ++ 컴파일러 로 컴파일 안 될 수 도 있 다고 했 더니 , 거기 에 달린 답변 은 더 황당 했 다 . 
 표준 이 문제 가 아니 라 잘 짜인 C 코드 …