레이블이 C++인 게시물을 표시합니다. 모든 게시물 표시
레이블이 C++인 게시물을 표시합니다. 모든 게시물 표시

2018-05-13

2018년 19번째 주

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.


C Primer

Primer를 입문서라고 번역하는 게 맞는지 모르겠지만, 어쨌든 C 입문서라고 이름 붙인 문서 중에서 가장 마음에 든다. 다른 언어는 잘 추상화된 모델을 다루는 것이 중요하지만 C는 아니라고 생각한다. C는 내가 사용한 코드가 어떻게 변환되어 실행되는지 기계 단위로 이해하고 있어야 한다. 그럴 필요가 없는 상황에서는 C가 아닌 다른 언어를 써야 한다.

C Is Not a Low-level Language

C가 low-level 언어는 아니라는 글이다. 전통적으로 low-level 언어는 머신에 대한 추상화 없이 기계어와 일대일 대응되는 언어를 의미한다. 당연히 이런 의미에서 C는 low-level 언어가 아니다. C는 나름의 abstract machine을 가지고 있다. 특히 C11 이후로는 멀티 쓰레드에 대한 개념도 abstract machine에 들어갔기 때문에 전통적인 의미에서 low-level 언어는 아니다.

그렇다고 해서 C가 다른 high-level 언어와 같다는 의미는 아니다. 다른 high-level 언어들은 실제 기계어로 어떻게 번역되는지 몰라도 될 정도로 abstract machine을 정의한다. 하지만 C는 아니다. 사실 나는 C의 abstract machine도 기계를 몰라도 사용할 수 있을 정도로 잘 정의돼있다고 생각한다. 문제는 C를 사용하는 사람들이 실제 기계에서 어떻게 돌아가는지 고려하면서 코드를 작성한다. 이건 C언어 커뮤니티의 문제는 아니다. 사실 기계 레벨에서 어떻게 돌아가는지 고려하지 않아도 되는 프로젝트에서 C를 사용하는 것은 얻는 것에 비해서 비용이 크기 때문이다.

카카오스토리 웹팀의 코드리뷰 경험

코드리뷰 없는 프로젝트는 있을 수 없다고 생각한다. 하지만 발표자가 말하듯이 시스템적으로 반드시 리뷰해야 머지할 수 있는 시스템은 별로라고 생각한다. 경험적으로 이런 시스템은 반드시 문제가 생긴다. 간단한 예로 휴가철에 급하기 hotfix를 넣어야 하는데 휴가 안 간 사람이 한 명밖에 없을 때, 휴가 간 사람이 강제로 업무를 하게 되는 경우가 있다. 굳이 휴가철이 아니더라도 급한 버그를 위해 야근이나 주말 근무를 하는 경우도 마찬가지다. 시스템적으로 머지에 리뷰를 강제하게 되면, 버그를 잡고 머지 하기 위해서 버그 잡는 사람 외에 누군가가 남아있어야 한다. 결코 바람직하지 않은 상황이다.

리뷰를 받을지 말지 패치를 만든 사람의 판단으로 선택해야 한다. 그 패치가 리뷰를 받아야 할지 안 받아도 되는지는 패치를 작성한 사람이 가장 잘 안다. 이건 패치 만드는 사람의 판단을 따라야 한다. 만약 이 정도 판단을 믿지 못한다면, 그 사람에게는 코딩을 맡기면 안 된다. 바람직한 개발 프로세스는 상호 신뢰에서 나온다고 생각한다. 기본적인 신뢰 관계가 없는 팀에서는 아무리 좋은 프로세스를 선택하더라도 유지될 수 없다.

개발 스타일은 툴로 체크해야 한다는 것에도 동의한다. 툴로 체크할 수 있는 걸 사람이 보고 있는 건 시간 낭비다. 다만 윗글에서 나온 대로 수정한 코드에 대해서만 체크할 수 있는 툴은 찾기 어렵다. 그래서 나는 한 번 대대적으로 프로젝트의 스타일을 수정하고 시작하는 것을 더 선호한다. 이렇게 되면 작업하고 있던 사람들과 컨플릭이 나거나 blame으로 찾을 수 있는 이력이 더럽혀진다는 문제가 있다. 하지만 이런 문제가 통일되지 않은 스타일로 프로젝트가 계속 진행되거나, 리뷰마다 스타일을 눈으로 체크하는 것보다는 더 싸게 먹힌다고 생각한다.

By the numbers: Python community trends in 2017/2018

2017, 2018년도 python community를 분석한 글이다. 개인적으로는 Types of Python development 파트에 나오는 파이썬 사용자를 분야별로 나눈 파트다. 보면 파이썬 사용자는 크게 data scientist와 웹 개발자로 나눠진다는 것을 알 수 있다. 특히 data scientist를 다 합치면 웹 개발자보다 많은 비중을 차지한다. 이는 파이썬이 사용하기 편하다는 점도 있지만, numpy, PyTorch, TensorFlow 등 다른 언어에서는 찾기 힘든 좋은 툴들이 많이 있기 때문이라고 생각한다. 당장 나만 해도 개발할 때는 정적 타입 언어를 선호하지만, 자료 분석이나 수치 분석을 할 때 파이썬 외에 다른 언어를 사용하지 않는다.

그 다음으로 눈에 보이는 것은 파이썬과 함께 사용하는 언어로 JavaScript가 1위를 차지했다는 것이다. 개인적으로는 파이썬의 반대되는 컴파일된느 언어나 정적 타입 언어들과 함께 사용할 것이라고 생각했고, 언어적 특성이 비슷한 JavaScript와 함께 사용할 것이라고 생각하지 않았다. 2위가 HTML/CSS인 것을 보면 이는 파이썬 사용자의 절반 정도가 웹 개발을 하기 때문으로 보인다.

다음으로 인상적인 것은 Python 3의 사용자가 Python 2의 3배쯤 사용된다는 것이다. 몇 년 전만해도 많은 Python 2 사용자들이 Python 3로 넘어가지 않고 버티고 있었고, 많은 라이브러리가 Python 2만 지원했었던 것을 생각하면 시대가 많이 좋아진 것 같다.

가장 놀라운 것은 VCS를 안 쓰는 사람이 38%나 된다는 것이다. VCS를 안 쓰고 개발이 관리가 되나 싶은데 안 쓰는 사람이 38%나 된다. 심지어 테스트를 안 짜는 사람(19%)보다 많다.

Quantum resource estimates for computing elliptic curve discrete logarithms

일반적으로 현대 컴퓨터에서 elliptic-curve cryptography(a.k.a. ECC)는 같은 길이의 키를 가지는 RSA 방식보다 더 풀기 어렵다고 말한다. 예를 들어 키 크기가 256 bit인 ECC와 같은 보안 레벨을 가지려면 RSA는 3072 bit 키를 사용해야 한다고 한다. 하지만 양자 컴퓨터가 도입되면 이야기가 달라진다. 양자 컴퓨터로 쇼어 알고리즘을 사용하면 비대칭키 암호화 방식을 깰 수 있는데, 3072 bit RSA를 깨는데 6146 qubit이 필요하지만, 256 bit ECC를 깨는 데는 2330 qubit밖에 필요하지 않다. 여전히 같은 키 크기에서 RSA보다 ECC가 안전하지만, 기존에 안전하다고 여겨지던 것보다는 차이가 많이 줄어든다. 다행이도 아직은 양자컴퓨터가 수십 qubit 수준에서 연구 중이기 때문에 최소한 십 년 운 좋으면 몇십 년 내에서는 별문제 없을 것이라고 생각한다.

Announcing Rust 1.26

Rust 1.26이 나왔다. 일단 눈에 띄는 변화는 다음이 있다.

함수의 인자와 리턴 타입으로 impl Trait 허용

Rust의 trait은 크기가 없기 때문에, 함수의 인자로 받거나 리턴할 수 없었다. 이런 경우 Box로 싸거나, generic을 써야 했다. 이를 impl Trait라는 문법을 추가해서 간단하게 사용할 수 있도록 했다.

레퍼런스 타입 match 할 때, 자동으로 dereference

기존에는 레퍼런스 타입을 매칭하면 패턴 부분에도 전부 레퍼런스라는 것을 명시해야 했다. 이제는 레퍼런스를 자동으로 dereference하기 때문에 &ref를 쓸 필요가 없다.

main 함수가 Result 리턴할 수 있도록 허용

ErrDebug를 구현해야 한다는 제약이 있지만, 이제는 main 함수가 Result를 리턴할 수 있다. 리턴한 값이 Err라면 리턴한 Err를 출력하고 종료한다.

2018-04-22

2018년 16번째 주

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.


ISO week date

오늘이 올해의 몇 번째 주인지 정하는 기준은 말하는 사람마다 다르다. 그래서 이 요약정리 시리즈는 ISO 8601 기준으로 몇 번째 주인지 표기한다. ISO 8601에 따르면 1월 4일이 포함된 주를 그 해의 첫 번째 주로 취급한다. 다른 말로 한 주의 시작을 월요일로 봤을 때 4일 이상 포함된 첫 번째 주가 그 해의 첫 번째 주인 것이다.

TextQL

머신 러닝이나 데이터 마이닝을 할 때 데이터의 경향성을 대강 파악하고 싶을 때가 있다. 이럴 때 사용되는 데이터는 보통 매우 큰 데이터이기 때문에 에디터로 열어서 보는 것은 무리가 있고, 간단하게 스크립트를 짜서 실행하게 된다. 근데 이때 하는 일은 대부분 비슷한 일이기 때문에 꽤나 귀찮은 작업이었는데, 스크립트를 짜지 않고 파일을 SQL을 실행시켜주는 프로젝트가 있었다.

아직 사용해보지는 않아서 직접 스크립트를 짜는 것과 비교하면 어떨지는 모르겠지만 꽤 많은 사람이 쓰고 있는 것 같다.

Writing

수학을 배워야 하는 이유가 사고하는 법을 익히기 위해서이듯이, 글쓰기를 배우는 이유는 무엇을 생각했는지 명확하게 하기 위해서다. 사람은 모든 것을 기억할 수 없기 때문에 자신이 생각한 것을 써서 정리해야 한다는 것이다. 게다가 글을 쓰는 것은 내가 글 쓰는 주제에 대해 나보다 모르는 독자를 가정하고 글을 쓰게 된다. 그래서 평소에는 당연하게 생각하고 넘어갔던 것들에 대해서도 한 번 더 생각하고 넘어갈 시간을 가지게 한다.

How quantum computing could wreak havoc on cryptocurrency

양자 컴퓨터가 상용화되면 현재 사용되는 암호화 기법 중 많은 것들이 쉽게 풀리게 된다. Cryptocurrency들은 이날을 대비해서 post-quantum cryptography로 넘어갈 준비를 해야 한다는 글이다. NSA는 수십 년 안에 양자 컴퓨터가 실제 암호를 해킹할 수 있을 정도로 발전할 것이라는 보고서를 작성한 적이 있다. 하지만 윗글의 글쓴이는 수십 년까지 가지 않고 십수 년 내에 양자 컴퓨터가 암호학에 실질적인 위험이 될 것이니 대비를 해두어야 한다고 주장한다.

OLPC’s $100 laptop was going to change the world — then it all went wrong

10년 전쯤 유행했던 OLPC라는 프로젝트가 있다. One Laptop Per Child라는 이름 그대로 모든 아이에게 노트북을 제공하겠다는 프로젝트였다. XO-1이라는 100$짜리 노트북을 제작하여 개발도상국의 어린이에게 노트북을 하나 더 제공하겠다는 프로젝트였다.

하지만 모든 아이에게 XO-1을 제공하겠다는 프로젝트는 결국 실패했다. XO-1 이후 출시할 계획이었던 XO-2는 나오지도 못했다. 실패한 원인은 여러 가지 있다. 애초에 목표했던 100$ 가격에 도달하지 못하기도 했고, 인텔에서 나온 넷북이 XO-1보다는 비싸지만, 훨씬 훌륭한 성능과 보편성 때문에 더 인기 있었다.

나는 이것을 뜻은 크지만, 기술이 뒤받쳐주지 못해서 생긴 OLPC의 완벽한 실패라고 생각한다. 하지만 윗글의 저자는 OLPC가 넷북의 보급을 가지고 왔고 덕분에 저가형 노트북 시장이 커졌으므로 어느 정도 목표를 이루었다고 보는듯하다.

The latest trend for tech interviews: Days of unpaid homework

최근 유행하고 있는 테크회사들이 인터뷰 시 단순히 면접으로 끝내는 것이 아니라 시간이 오래 걸리는 과제를 내는 것을 비판하는 글이다. 말하고자 하는 바는 이해하지만, 딱히 더 좋은 해결법은 생각나지 않는다. 나는 회사에서 줄 수 있는 가장 큰 복지 중 하나는 좋은 팀을 구성해주는 것이라고 생각한다. 그런 면에서 충분히 검증되지 않은 사람과 일하고 싶지 않다. 물론 검증에 필요한 비용을 구직자에게 전가하는 방식은 옳지 못하다. 개선할 필요가 있다. 하지만 그게 윗글에서 말하는 한 시간 내외의 코딩면접인지는 잘 모르겠다.

Why Is SQLite Coded In C

SQLite가 어째서 C를 사용하는지에 관한 글이다. 개인적으로 C를 좋아하지는 않지만, 이 글에서 주장하는 바는 전부 타당하다고 생각한다.

Conceptual compression means beginners don’t need to know SQL — hallelujah!

Ruby on Rails(a.k.a. RoR)의 제작자, DHH가 쓴 글이다. RoR은 잘 만들어진 ORMActive Record로 유명하다. 사실 지금까지 Active Record 외에는 쓸만한 수준으로 동작하는 ORM을 본 적이 없다. 하지만 여전히 ORM이 SQL을 대체할 수 있는가에 대해서는 회의적이다. 아마 DHH도 완전히 대체할 것으로 생각하지는 않았는지 beginners에 한정시켜 말하기는 했다.

하지만 나는 여기에도 회의적이다. 프로그래머가 쓰는 시간 대부분은 사실 코딩이 아니라 전체적인 구조를 설계하는 것과 문제가 생겼을 때 디버깅하는데 들어간다. SQL을 모른다는 것은 사실 RDBMS(Relational database management system)의 동작을 이해하지 못했다는 것인데 아무리 적절한 수준의 추상화가 문제를 단순화시키는 데 도움을 준다고 해도, 내부 동작을 모른 채로 적절한 설계를 하거나, 문제가 생겼을 때 원인을 찾아낼 수 있다고 생각되지 않는다.

Analysis of the Bitcoin UTXO set

Bitcoin은 Unspent Transaction Output(a.k.a. UTXO) set을 이용해 현재 상태를 표현한다. 위 논문은 bitcoin에서 UTXO를 어떻게 저장하고 UTXO set이 어떻게 변해왔는지를 분석했다.

2018-02-09

[C] tagged pointer - 포인터에 정보 담기

 Tagged pointer는 메모리 크기를 줄이기 위한 고전적인 테크닉이다. 기본적인 아이디어는 포인터의 모든 값이 의미 있는 값은 아니라는 것이다. 예를 들어 4 byte 단위로 align 되는 객체의 32-bit 포인터를 생각해보자. 그렇다면 이 객체의 주소는 4로 나누어 떨어지는 값이 돼야 하니 LSB(Least Significant Bit)으로 부터 2 bit은 언제나 0b00으로 고정될 것이다. 그렇다면 이 2 bit을 다른 정보를 담는 데 써도 아무 문제가 없다. 조금 더 구체적으로 경우 포인터의 값이 0x5678FFF0, 0x5678FFF1, 0x5678FFF2, 0x5678FFF3인 경우 모두 0x5678FFF0에 있는 객체를 가리키도록 하고, 0x5678FFF4, 0x5678FFF5, 0x5678FFF6, 0x5678FFF7인 경우 모두 0x5678FFF4를 가리키는 포인터로 해석하는 것이다.

 Tagged pointer를 만드는데 LSB 만 쓸 수 있는 건 아니다. 보통 user space에서 쓸 수 있는 최대 메모리가 제한돼 있다. 예를 들어 32-bit 윈도우에서 user space는 최대 3GB 까지 늘릴 수 있지만, 기본적으로 2GB이다. 즉, 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 pointer를 리턴하는 함수로 만들면, 리턴값이 하나의 레지스터에 들어가게 돼서 더 빨라지기도 한다.

 Tagged pointer는 사용하기 불편한 테크닉이지만 놀랍게도 아직 종종 사용된다. 하지만 사용하기 전에 정말로 필요한지 고민해봐야 한다. Tagged pointer는 사용하는 메모리 크기를 줄이지만, 구현이 쓸데없이 복잡해진다. 구현이 복잡하다는 것은 버그가 발생할 확률이 높다는 것이고, 게다가 디버거는 tagged pointer의 의미를 알지 못 하므로 디버깅도 많이 귀찮아진다. 이 개발 비용을 감수하면서도 tagged pointer가 주는 이득이 충분한지 따져보고 사용해야 한다.

2016-03-04

멀티 쓰레드 환경에서 fork는 조심해야 한다.

 리눅스나 유닉스 같은 POSIX 시스템에서는 fork를 이용해서 자신과 똑같은 프로세스를 만들 수 있다. 이때 fork를 호출한 프로세스를 부모 프로세스라고 하고, 새로 생성된 프로세스를 자식 프로세스라고 부르는데, 자식 프로세스는 부모 프로세스의 모든 메모리를 복사한다.

 fork는 그 뒤 exec을 해서 다른 바이너리를 실행시키는 fork-exec이 일반적인 사용법이다. 하지만 자식 프로세스부모 프로세스와 완전히 같은 메모리를 가지기 때문에, 스레드가 존재하지 않던 시절에는 exec을 하지 않고 병렬 처리를 하기 위해서도 자주 사용되었다. 지금은 스레드를 사용하는 것이 더 사용하기 쉽고 가벼운 방식이기에 스레드를 병렬처리를 위해 스레드를 주로 사용하지만, 스레드보다 서로 간에 독립적이기 때문에 일을 분리하기 위해서 사용하기도 한다.

 분명히 fork는 없어서는 안 될 기능이지만 fork에는 태생적 한계가 있다. 애초에 fork는 스레드라는 개념이 존재하지 않던 시절에 만들어졌기 때문에 thread-safe 하지 않다. 따라서 멀티스레드 환경에서 사용하려면 조심해서 사용해야 한다.

 fork가 멀티스레드 환경에서 문제를 일으키는 이유는 fork부모 프로세스의 메모리를 전부 복사하지만, fork를 호출한 스레드를 제외한 나머지 스레드들은 죽어버리기 때문이다. 따라서 fork를 호출한 스레드 이외의 스레드에서 획득한 자원은 아무것도 해제되지 않는다. 메모리 릭도 충분히 문제지만, 이는 단순한 메모리 릭만을 의미하지 않는다.  fork가 복사한 메모리에는 힙이나 스택 이외에 mutexcondition variable 들도 포함된다. 만약 mutexcondition variable이 다른 스레드에서 사용된 채로 fork 된다면 해당 변수로 보호되는 critical section에는 다시는 진입할 수 없게 된다. 특히나 malloc 같은 thread-safe 한 함수는 대부분 내부적으로 글로벌한 mutex를 사용하기 때문에 내 코드에 mutex가 없어도 안심할 수 없다. 따라서 멀티스레드 환경에서는 fork 하기 전에 다른 스레드가 전부 멈추는 것을 확인하는 것이 좋다.

 하지만 fork 후 바로 exec 하면 이런 것을 신경 쓸 필요 없다. exec의 경우 메모리를 완전히 새로 만들기 때문에 이런 문제가 발생하지 않는다.

2015-04-02

C는 C++의 부분집합이 아니다

 오늘 황당한 글을 봤다.

잘 짜인 C 프로그램은 C++ 프로그램이다. 따라서 잘 짜인 C 프로그램은 C++ 컴파일러로 컴파일할 수 있어야 한다.

 일단 저 말은 C++의 창시자인 비야네 스트롭스투룹이 한 말이다. 하지만 저 말은 틀린 말이다. "네가 뭔데 감히 비야네님을 틀리다고 하느냐"라는 생각이 들겠지만 잠시만 진정하자. 나는 비야네님이 틀렸다고 하지 않았다. 내가 틀리다고 하는 것은 아무런 문맥도 없이 그냥 저 문구만 따와서 말하는 사람을 틀리다고 하는 것이다.

 저 말은 분명히 1999년 이전까지는 맞았던 말이다. 분명히 비야네 스트롭스트룹은 C++을 만들면서 C와의 호환성을 고려하였고, 당시의 표준(ANSI C)을 잘 지킨 C 코드는 C++ 컴파일러로 정상적으로 컴파일 되었다. 하지만 그것은 어디까지나 C99가 나오기 전의 이야기다.

 C99에서는 여러 가지 새로운 기능을 도입하였고, C++은 그것을 이미 다른 방식으로 구현하고 있었거나, 혹은 필요하지 않은 기능이라고 생각하여 가지고 오지 않았다. 게다가 새로운 표준인 C11이 나오고, C++도 새로운 표준인 03, 11을 거쳐 14까지 나오면서 둘 사이의 간극은 이미 어떻게 할 수 없을 정도로 커졌다.

 그런 연유로 비야네 스트롭스트룹은 잘 짜인 C 프로그램이 C++ 프로그램이라고 말할 때 조건을 붙인다. "단, 이건 C89에 한정한다."라고. 하지만 요새 C89를 쓰는 프로그램이 얼마나 있나? 액티브하게 작업이 진행되는 프로젝트 중에서 C89를 쓰는 프로그램 있으면 가지고 와봐라. 찾으려고 노력해본 적은 없지만 찾기 어려울 것이다.

 따라서 요새 저런 말을 하는 사람은 그냥 공부를 안 한 사람이다. 그것도 한 20년 전에 공부했던 사람이니 대선배님일 수도 있겠다. 그 사람에게 C99 이후 C++과 스펙이 변경되어 C99 표준을 지킨 코드는 C++컴파일러로 컴파일 안 될 수도 있다고 했더니, 거기에 달린 답변은 더 황당했다.
표준이 문제가 아니라 잘 짜인 C 코드라면 C++ 컴파일러로 컴파일할 수 있어야 한다. C++ 컴파일러로 컴파일되지 않는 코드라면 잘 짜인 C 코드가 아니다.
 아.... 정말 충격과 공포다.
 무슨 생각을 하면 잘 짜인 C코드의 기준을 C++에서 찾는지 모르겠다. 둘은 이미 다른 언어로 분화되었다. 한동안 비야네는 C와 C++을 합치려고 노력하던 시절도 있지만, 요새는 포기한 듯이 보인다. 심지어 그는 C/C++은 아무것도 모르는 사람들이나 쓰는 용어로 C와 C++을 합쳐서 불러서는 안된다고 말하기도 한다. C와 C++은 이미 같은 언어가 아니다.

 C++ 컴파일러로 컴파일 가능한 코드만을 잘 짜인 C 코드라고 말한다면, C99 이후에 새로 추가된 기능을 전부 포기하는 것밖에 되지 않는다.

 분명하게 말하건대 표준을 지키면서 잘 짜인 C 코드는 C++ 컴파일러로 컴파일되지 않을 것이다.


p.s. 아쉽게도(혹은 다행히도) 비공개 커뮤니티에 올라온 글이라 원본 링크는 못 올렸다.