Taeguk's Blog

34개월간의 산업기능요원 현역을 시작하게 됐다. 정당한 절차를 거친 것이긴 하지만, 다른 사람들에 비해 특혜를 누리는 것이기 때문에, 복무기간동안 사회를 위한 활동이나 기부같은 걸 해야겠다는 의무감이 든다. '진짜 현역'으로 군복무를 하신 분들에게 진심으로 존경과 감사를 표하며, 주변에 군복무를 당당하게 마친 친구들에게 식사나 술이라도 대접해야겠다고 생각하고 있다. 아무튼, 기나긴 병특 기간동안 개인적으로도 의미있고, 주변사람들에게도 도움이 될 수 있는 시간들을 보내고 싶다.

http://book.naver.com/bookdb/book_detail.nhn?bid=7405945 https://www.amazon.com/API-Design-C-Martin-Reddy/dp/0123850037 올해 9월 중순~말쯤에 내가 회사에 입사하고 나서, 팀장님께서 읽으라고 던져주신 책이다. C++언어를 이용해 API를 디자인하는 것에 대해 다루고 있다. 하지만, 비단 C++이나 API 디자인에 국한된 내용들은 아니다. 전반적인 소프트웨어 설계에 대해 영감을 얻을 수 있는 부분들이 많이 있다. 결론부터 말하면, 책이 굉장히 좋다...     이 책은 C++언어 자체적으로 고급적인 문법이나 스킬적인 부분, 그리고 디자인패턴적으로 고급적인 내용들을 다루지는 않는다. 다만, 내가 느끼기에는 다른 책들과는 다르게 좀 더 '현실적인' 관점에서 어떻게 소프트웨어를 잘 설계하고 프로젝트를 진행할 수 있는지에 대해 다루고 있다는 생각이 들었다.     "화려하고 기괴한, 마법같은" 과 같은 단어들은 이 책과 어울리지 않는다. 내가 이 책을 읽으면서 머릿 속에 떠올랐던 건 "투박하고 현실적인, 그렇지만 효과적인" 이런 단어들이다. C++쪽은 언어의 특성 탓인지 사용자들의 특성 탓인지, 다른 언어들에 비해 각종 기괴하고 마법같은 '언어적 기술'들이 많이 존재하고, 극단적으로 overhead를 없애거나 설계를 완벽하게 하려는 그런 점들이 많이 존재한다. 그런 것들은 기술적인 호기심을 자극하긴 하지만, 실제 팀내의 모든 사람들이 그것에 열의가 있거나 그것을 받아들일 역량이 있는 것은 아니기 때문에, 현실적으로 프로젝트에 적용하는 것이 쉽지 않다. 반면에 이 책은 그런 것들과는 다르게, 책 내용을 이해하고 활용하는데 고급적인 C++지식들이 필요하지 않고, 내용들이 상당히 유용하기 때문에, 진짜 현업에서 당장 적용할 수 있고, 당장 회사의 프로젝트와 팀에게 큰 도움을 줄 수 있을 것 같다는 생각

https://www.amazon.com/Optimized-Proven-Techniques-Heightened-Performance/dp/1491922060 올 봄~여름쯤에 CppKorea에서 주최하는 스터디에 참가해서 읽었던 책이다. 'Optimized C++' 이라는 "자극적인" 책 제목에 이끌려서 읽게 됐는데, 결과적으로 말하자면 상당히 실망이다. 1. 내용이 깊지 않다. 책의 난이도를 의미하는 것이 아니다. 책의 난이도와 내용의 깊이는 엄밀히 말하면 별개이다. 아무튼, 책 내용의 깊이 측면에서 이 책은 매우 실망적이였다. Optimized C++ 이라는 책 이름에 걸맞는 내용들이 아니였다. 단순히, C++의 good practice들을 performance측면에서 서술한 것이 전부였다. 나는 뭔가 새롭고 고급스러운 스킬들이나 기술들을 원했는데, 내용은 단순히 겉핡기만 하고 있었다. custom memory allocator에 대한 부분으로 예를 들자면, 나는 그것을 활용한 실질적인 고급기술들이나 실제 응용들이 궁금한건데, 책은 단순히 custom memory allocator의 basic example만 가지고 그게 뭔지만 간단하게 설명하고 넘어간다. 2. 설명이 부실하다. 위에서 내용이 깊지 않다고 했는데, 사실 깊지 않은 내용이더라도 그것을 잘 전달하면 그것은 초심자 혹은 특정 level의 독자들을 위한 상당히 좋은 서적이 된다. 근데 이 책의 문제는 내용이 깊지도 않은데 설명도 부실하다. custom memory allocator로 예를 들자면, 책에서는 basic example만 가지고 간단하게 설명하고 넘어가는데, 문제는 저걸 이미 아는 사람은 읽을 필요가 없고, 저걸 모르는 사람은 책만 읽고서는 이해하기가 어렵다는 것이다. 즉, 뭔가 책의 target 독자층이 애매하다. 3. 영어가 뭔가 이상하다?? (지극히 주관적 생각임에 주의!) 이건 나의 문제일 수도 있는데.... 뭔가 영어가 너무

여름동안의 Google Summer Of Code 2017를 성공적으로 끝마쳤다. Final Evaluation를 통과하고, 멘토님에게도 칭찬을 들어서 기분이 좋다. 아무튼 GSoC를 계기로 오픈소스에 직접 기여하면서 C++실력도 상당히 많이 늘게 되어서 뿌듯하다. 역시 실력을 키우는데에는 오픈소스 코드를 보는 게 가장 빠르고 효율적인 것 같다. 아래는 내가 GSoC에서 한 활동에 대한 Abstract이다. (자세한 건 https://summerofcode.withgoogle.com/projects/#5151083935563776 참고) HPX is “The C++ Standards Library for Concurrency and Parallelism”. So, implementing C++17 parallelism like N4409 is very important. Most of parallel algorithms are already implemented. But, still some algorithms have not been implemented. My main objective is implementing as many as possible of the remaining parallel algorithms and adapt them to Ranges TS and add container versions of them. And I add unit tests and benchmark codes for them. Associated with mainly parallel algorithms, I also catch and suggest many issues and resolve them.  비록, GSoC는 끝났지만 계속에서 HPX 오픈소스에서 활동을 하며 contribution을 이어나갈 생각이다. 오픈소스 활동을 통해 얻을 수 있는게 많기 때문이다. C++ 차세대 표준을 공부하고 구현하면서 C++ 실력을 상당히 많이 키울 수 있고,

    이번 학기에 학교에서 '임베디드 시스템 소프트웨어'란 과목을 수강하였다. 학기의 마지막에 간단한 자유 프로젝트 과제가 주어졌다. 근데 기간이 빠듯해서 프로젝트를 진행할 수 있는 시간이 사실상 2일밖에 없었다. 그냥 평범하게 학교수업에서 배운 내용을 바탕으로 할까 하다가 이미 아는 내용을 반복하는 것은 의미가 없다는 생각이 들었다. 그래서 무작정 Android Framework 소스를 수정해서 뭔가 해보는 걸로 프로젝트의 방향을 잡았다. Android 기기의 Display 화면을 6x6으로 쪼개서 뒤섞은 모습 ㄷㄷㄷ          위는 이번 미니 프로젝트에서 구현한 2가지 기능중에 한 가지인 Display Puzzle 기능이다. Android 기기의 Display 화면을 NxM 의 형태로 쪼개서 퍼즐처럼 뒤섞어 버린다. 이 것을 구현하기 위해 Hardware Abstraction Layer에서 gralloc 관련 부분을 수정했다. 프레임버퍼로 나가기 직전에 화면을 가로채서 뒤섞어버린다. 정상적인 화면 캡처를 했을 때, 화면이 오른쪽으로 90도 돌아가고 왼쪽부분에 투명한 회색 선이 생긴 상태로 캡처가 되게 된다.         위는 2번째 기능을 보여준다. 사용자가 캡처를 하게되면, 화면이 오른쪽으로 90도 돌아가고 왼쪽부분에 투명한 회색 선이 생긴 상태로 캡처가 되게 된다. 물론 원래 화면을 그대로 두고 캡처만 저렇게 되게 된다. 출처 : http://cdn.edureka.co/blog/wp-content/uploads/2013/01/Android-Stack1.jpg         아무튼, 별 의미는 없지만 안드로이드 프레임워크를 수정해야 할 수 있는 기능 2가지를 구현해보았다. 쉽게 할 수 있을 줄 알았는데 생각보다 이상현상들이 많이 발생해서 힘들었다. 개발 기간이 2일 밖에 안되서 어쩔 수 없이 야매로 해결하긴 했다. 안드로이드 프레임워크를 한번 분석해보고 싶었는데, 이번

Chapter 8. 다듬기 항목 41. 이동이 저렴하고 항상 복사되는 복사 가능 매개변수에 대해서는 값 전달을 고려하라. 왼값 참조와 오른값 참조 버전 2개를 모두 만드는 것은 코드 중복, 유지보수 측면에서 단점이고, 보편 참조 전달 버전은 항목 26/27/30 에서 말했던 것들과 같은 문제들이 발생할 수 있다. 따라서 약간의 효율성을 포기하면 이러한 단점들을 피할 수 있는데, 그것이 바로 값 전달을 활용하는 것이다. (효율성 : 보편 참조 버전 >= 왼값 참조 버전 + 오른값 참조 버전 >= 값 전달 버전) 그러나, 값 전달의 경우에도 주의해야 할 점들이 있다. 1. 잘림 문제 (slicing problem) 2. 값 전달 함수들이 꼬리를 물고 호출되면, 전체적인 성능이 급격히 하락할 수 있다. 3. "값 전달 (복사 생성) -> 이동 배정" 의 경우 "참조 전달 -> 복사 배정" 보다 훨씬 비쌀 가능성이 있다. (예를 들면, std::string이나 std::vector등의 memory allocation 때문에) 흠, 나는 값 전달 버전이 얼마나 유용할 지 의문이 든다. 일단 이동 연산 하나가 불필요하게 낭비된다. 사실 이동이 저렴한 경우에는 유지보수, 코드중복 해결의 장점을 봤을 때 이러한 사소한 낭비를 무시할 수 있다. 그러나 사실 큰 문제는 이동이 저렴하다고 생각했는데 저렴하지 않을 수 도 있다는 것이다. std::string이나 std::vector같은 경우, memory allocation 때문에 값 전달 후 이동 배정을 하는 것이 상당히 느려질 수 있는데, 코드를 짤 때 이러한 점을 간과하거나 실수 할 가능성이 크다. 또한, 잘림 문제도 주의해야 한다. 즉, 값 전달을 사용하는 것은 참조 버전보다 실수할 가능성이 더 크기 때문에 일단 기본적으로는 피해야 한다고 생각한다. 내 생각에는 일단 우선적으로 왼값/오른값 참조 버전을 사용하다가, 성능을 더 강화할 필요가 있을 경우

Chapter 7. 동시성 API 항목 35. 스레드 기반 프로그래밍보다 과제 기반 프로그래밍을 선호하라. 확실히 과제 기반 프로그래밍은 스레드 기반 프로그래밍보다 더 쉽고 가독성이나 설계 측면에서 더 우월하다. 하지만, 과하게 마구잡이로 사용하는 것을 주의해야 한다고 느꼈다. 스레드를 쓰면 간단하게 되는 것을 과제 기반으로 하려고 억지로 짜 맞추는 것은 좋지 않다. 그리고 과제 기반 프로그래밍은 스레드 기반 보다 더 높은 추상화로서, 내부적으로 스레드 고갈, over subscription, load balancing등의 문제를 해결해줄 수 도 있다. 실제로 현재에는 std::async가 visual studio에서는 PPL을 바탕으로 위와 같은 것을 어느 정도 해결해주고 있다. 그러나, libc++ (llvm의 std 구현)과 libstdc++ (gcc의 std구현)의 경우 비효율적인 방법으로 구현되어 있다. (관련 내용 : http://rpgmakerxp.tistory.com/63 ) 정말 비동기 작업을 효율적으로 진행해야 하고, 더 많은 부분들(thread priority, affinity, thread pool등)을 직접 컨트롤 해야하는 경우에는 std::async가 적합하지 않다. 이런 경우는 std::thread 혹은 Windows API / pthreads 등을 사용해야 한다. 그리고, 아직 C++11/14의 과제 기반 프로그래밍은 빈약한 편이므로, 좀 더 본격적인 과제 기반 프로그래밍이 필요한 경우에는 TBB, PPL, HPX등을 사용하는 것이 좋아 보인다. (그러나, C++의 향후 표준들에서 점차 강력해질 것이다.) [기억해 둘 사항들]  - std::thread API에서는 비동기적으로 실행된 함수의 반환값을 직접 얻을 수 없으며, 만일 그런 함수가 예외를 던지면 프로그램이 종료된다.  - 스레드 기반 프로그래밍에서는 스레드 고갈, 과다구독, 부하 균형화, 새 플랫폼으로의 적응을 독자가 직접 처리해야 한다.  - std

Chapter 6. 람다 표현식 항목 31. 기본 갈무리 모드를 피하라. 참고로, 갈무리는 'capture'를 의미한다. (첨엔 어색했으나 나도 이제 완전히 이 번역에 익숙해져버렸다.) 기본 갈무리 모드 (default capture mode)는 '참조 갈무리 모드'와 '값 갈무리 모드'가 있다. 기본 갈무리 모드를 피해야 하는 이유는 크게 dangling reference 위험과 명시적이지 않다는 점(그래서 착각/실수 할 수 있다는 점) 때문이다. 일단, 참조 갈무리 모드에서 dangling reference 문제가 발생할 수 있다는 것은 너무 당연하고, 값 갈무리 모드에서도 pointer가 capture되는 경우에 그러한 문제가 발생 할 수 있다는 것은 당연하다. 사실 결정적인 문제는 명시적이지 않다는 점이다. 이로 인해 문제가 발생 할 수 있을 만한 상황을 정리하면 다음과 같다. 1. this pointer의 캡처     - 숨겨져있던 this pointer가 캡처됨으로 인해 dangling pointer 등의 문제가 발생할 수 있다. 2. 람다표현식을 복붙(Copy&Paste) 할 경우, 실수할 가능성이 커진다.     - 유용한 람다표현식을 그대로 다른 곳에서 쓸 경우가 있을 수 있다. 이 경우, capture list가 명시적이지 않아서 문제들이 발생할 소지가 있다. 3. 전역 변수나 static 같이 global scope를 가진 변수들 (즉, non-automatic variable들)의 값이 복사로서 capture될 것이라는 착각을 할 수 있다.     - 오직 automatic variable들(즉, 지역변수들) 만 capture될 수 있는데, 기본 값 갈무리 모드를 사용하면, non-automatic variable들도 값 복사로서 capture될 것이라는 착각을 할 여지가 있다. 즉, 기본 갈무리 모드의 문제는 결국 '명시적이지 않다'는 것이다. 필

그 동안 PyPy를 단순히 JIT을 지원하는 빠른 python implementation 이라고만 알고 있었다. 그런데 알고 보니 단순한 python implementation 이상의 의미를 갖는 상당히 멋있는 프로젝트였다. PyPy는 2가지 파트로 나뉜다. 1. RPython 문법으로 작성된 Python Interpreter 2. RPython Translation Toolchain 1번의 python interpreter를 2번의 toolchain에 넣으면, JIT, garbage collector 등의 기능이 첨가된 C언어로 된 interpreter가 결과로서 나온다. ???!!  매우 놀라울 것이다. 2번의 toolchain은 Python 소스 코드나 syntax trees 에 대한 정보는 전혀 가지고 있지 않는다. 그런데 JIT과 garbage collector를 비롯한 기능들을 첨가해준다니?! 그래서 내가 멋있다고 한 것이다... (출처 : https://www.toptal.com/python/why-are-there-so-many-pythons) PyPy의 구조를 그림으로 보자면 위와 같다. (PyPy Interpreter가 1번, PyPy compiler가 2번에 해당한다.) (출처 : http://rpython.readthedocs.io/en/latest/translation.html) RPython translation toolchain의 실제 플로우를 그림으로 보자면 위와 같다. 기본적으로 RPython으로 작성된 interpreter 코드가 필요하고 추가적으로 low level hint들을 통해 세부적인 과정에 참여할 수 있다. 그리고 translation toolchain의 backend는 현재 C언어만 가능하지만, 설계 상 더 추가가 가능한 구조이다. 그리고 이러한 RPython Translation Toolchain을 이용하면 Python 뿐만 아니라 모든 언어들의 'JIT'ed Interp

Chapter 5. 오른값 참조, 이동 의미론, 완벽 전달 항목 23. std::move와 std::forward를 숙지하라. #include <iostream> class Example { public: Example() = default; Example(const Example &) { std::cout << "copy constructor" << std::endl; } Example(Example &&) { std::cout << "move constructor" << std::endl; } Example(const Example &&) { std::cout << "const move constructor" << std::endl; } }; /* std::forward is meaningful only for universal reference in template. */ void test1(Example ex) { std::cout << "Test 1" << std::endl; Example a(std::forward<Example>(ex)); // move constructor Example b(std::forward<Example&>(ex)); // copy constructor Example c(std::forward<Example&&>(ex)); // move constructor } void test2(Example& ex) { std::cout << "Test 2" << std::endl; Example a(std::forward<Exam

Chapter 4. 똑똑한 포인터 (Smart Pointer) 항목 18. 소유권 독점 자원의 관리에는 std::unique_ptr를 사용하라. 보통 smart pointer를 처음 접한 사람들은 std::shared_ptr만을 남용(?)하는 경향이 있다. 그러나 std::shared_ptr이 매우 강력한 존재이긴 하지만 크게 2가지 측면에서 단점이 있다. 첫 번째는 overhead이다. 참조 계수를 관리하기 위해 어쩔 수 없이 overhead가 존재한다. 두 번째는 돌이킬 수 없다는 점이다. 한번 std::shared_ptr에 pointer를 물리고 나면 다시는 일반 pointer로 복귀할 수 없다. (단순히 .get()을 쓰면 raw pointer를 받을 수 있을 뿐이다. 여전히 프로그램 어딘가에서 포인터를 참조할 수 있을 수 있다.) 이러한 단점들 때문에 나는 기본적으로 std::unique_ptr을 사용한다. std::unique_ptr은 덜 강력하지만 위 2가지 단점이 없다. 추가적인 메모리를 요구하는 커스텀 삭제자를 지정하지 않는다면 performance는 raw pointer와 사실상 동일하고, std::unique_ptr를 사용하다가 적합하지 않은 상황이 오면 언제든지 정책을 raw pointer나 std::shared_ptr등으로 바꿀 수 있다. 참고) raw pointer, std::unique_ptr, std::shared_ptr의 '생성 및 삭제' 성능 비교 : http://www.modernescpp.com/index.php/memory-and-performance-overhead-of-smart-pointer 특히 어떻게 쓰일 지 모르는 포인터를 반환해야 하는 경우는 std::unique_ptr를 쓰는 것이 좋다. std::unique_ptr은 어떤 형태로든지 변환이 가능하기 때문이다. 특별한 목적이 있는 경우가 아니라면, 팩토리 함수등에서 std::shared_ptr 을 반환하는 것은 좋지 않은 습관이다.

Chapter 3. 현대적 C++에 적응하기 항목 7. 객체 생성 시 괄호(())와 중괄호({})를 구분하라. 내 경험과 개인적인 의견에 따르면,,, 객체 생성 시 왠만하면 괄호를 사용하고, 클래스 내에서 멤버 변수의 기본 값을 설정할 때와 std::initializer_list 를 매개변수로 받는 생성자를 호출 할 때에만 중괄호 초기치를 사용하는 것이 좋다. 이러면 별 문제가 없다. 중괄호 초기치의 장점은 아래와 같다. 1. 가장 광범위하게 적용할 수 있는 초기화 구문이다. 2. 좁히기 변환을 방지할 수 있다. 3. C++의 most vexing parse에서 부터 자유롭다. ("선언으로 해석 할 수 있는 것은 항상 선언으로 해석해야 한다.") 일단 1번 경우와 2번의 장점으로 인해 클래스 내에서 멤버 변수의 기본 값을 설정할 때에는 중괄호 초기치를 사용하는 것이 좋다. 그리고 2번 장점의 경우, 대부분 auto의 올바른 사용으로 인해 장점이 무색해진다. 어차피 auto 를 사용하면 암시적인 좁히기 변환이 불가능하기 때문이다. 오히려 auto와 중괄호 초기치의 결합은 type deduction에 있어서 혼란을 가져올 수 있기 때문에 좋지 않다. 따라서 chapter 2의 교훈에 따라 auto를 적극적으로 그리고 잘 활용한다면, 일반적으로 중괄호 초기치보다 괄호를 쓰는 것이 훨씬 좋다. 그러면 3번의 장점을 봐보자. 3번 부분은 ReturnValue obj(); 같은 구문의 경우 이 것이 함수 선언으로 해석되는 것인데, 중괄호 초기치를 사용하면 그럴 일이 없기 때문에 좋다는 것이다... 글쌔... 그냥 ReturnValue obj;와 같이 사용하는 게 낫지 않을 까 싶다. 이제 한번 템플릿 안에서 객체를 생성할 때는 괄호와 중괄호 중 어떤 걸 사용할 지 생각해보자. 내 생각에는 템플릿에서는 더더욱 괄호를 쓰는 게 옳다. 템플릿 매개변수로 어떤 타입이 올지 모르는데 만약 그 타입의 생성자 중에 매개변수로 std::init

Chapter 2. auto 항목 5. 명시적 형식 선언보다는 auto를 선호하라. 진짜 auto는 상당히 좋다. 그 근거를 대자면 여러가지가 있다. 일단, 거의 반드시 auto를 사용해야만 하는 경우도 있다. (클로저의 형식같이 컴파일러만 알고있는 타입의 경우) 그리고 형식 불일치로 인한 효율적, 이식성문제가 발생하지 않는다. std::size_t getSize() { ... } int size = getSize(); 간단한 예시로서 위 코드 같은 경우, 32bit system에서 컴파일했을 때는 문제가 없지만 64bit system에서 컴파일했을 때는 문제가 있을 수 있다. (예를 들어, windows 64bit의 경우 LLP64를 채택하기 때문에 문제가 생긴다.) 그 외에도 책의 다른 예제들에서 볼 수 있듯이 명시적 형식 선언은 이식성과 효율성 측면에서 문제가 생길 수 있는 여지가 많다. 그러나 auto를 사용하면 이런 문제들이 발생하지 않는다. 또 심미적(?)인 측면에서도 auto를 쓰는 게 기다랗고 복잡한 타입이름을 늘어놓는 것 보다 훨씬 좋다. 결론적으로, 굳이 명시적 형식 선언을 해야 할 필요성을 찾지 못한다면 auto를 사용하는 것이 옳다. 그러나 가독성 측면에서 auto를 사용하면 타입이 정확하게 드러나지 않기 때문에 코드를 읽기 힘들다는 반론도 존재한다. 하지만 내 생각에는 어차피 거의 항상 IDE의 도움을 받게 되기 때문에 큰 문제는 없다고 본다. 오히려 장황하게 늘어져 있는 명시적 타입이 괜시리 눈과 머리를 피로하게 만들어 가독성이 떨어진다. [기억해 둘 사항들]  - auto 변수는 반드시 초기화해야 하며, 이식성 또는 효율성 문제를 유발할 수 있는 형식 불일치가 발생하는 경우가 거의 없으며, 대체로 변수의 형식을 명시적으로 지정할 때보다 타자량도 더 적다.  - auto로 형식을 지정한 변수는 항목 2와 항목 6에서 설명한 문제점들을 겪을 수 있다. 항목 6. auto가 원치 않은 형식으로 연역될

Chapter 1. 형식 연역 (Type Deduction) 항목 1. 템플릿 형식 연역 규칙을 숙지하라. 아래에 적어놓은 코드를 보면 C++11/14에서의 Template Type Deduction 규칙을 파악할 수 있을 것이다. 대부분 직관과 거의 잘 맞아떨어진다. 그래도 주의 할 점 몇가지를 살펴보면, 일단 첫번째는 함수와 배열의 decay 부분이다. 일반적으로 C에서 배열은 포인터로 붕괴되고, 함수도 포인터로 붕괴된다. C++에서도 이는 마찬가지인데, 주의할 점이 참조(&) 가 사용될 때는 붕괴가 되지 않는다. 따라서 template type deduction에 있어서도 ParamType이 &일 경우에는 배열과 함수가 decay되지 않는다. 그리고 두번째로는 보편 참조(universal reference) 이다. 구체적인 것들은 아래 코드를 열심히 보면 이해가 될 것이다. #include <utility> template <typename T> void func_ref(/*ParamType*/ T &) {} template <typename T> void func_ptr(/*ParamType*/ T *) {} template <typename T> void func_unv_ref(/*ParamType*/ T &&) {} template <typename T> void func_val(/*ParamType*/ T) {} template <typename T, std::size_t N> void func_arr_ref(/*ParamType*/ T (&)[N]) {} int main() { /**********************************************/ const volatile int a = 3; func_ref(a); // T -> const volatile int

http://book.naver.com/bookdb/book_detail.nhn?bid=9566417 Effective Modern C++ 에 대해서 블로그에 정리해보고자 한다. 책은 이미 다 읽은 상태이고, 대부분 실전에 적용을 해보았기 때문에 좀 더 알찬 포스팅이 가능하지 않을까 싶다. 포스팅은 작년에 Effective C++을 포스팅했을 때와 비슷한 형태로 갈꺼 같다. Effective 시리즈 자체가 핵심 요약본 같은 느낌이라서 책을 단순 요약하는 것은 솔직히 쓸데없다고 생각하기 때문에,,, 책 내용과 더불어 내 개인적인 궁금증 및 실험, 그리고 내 개인적인 견해들이 많이 들어갈 꺼 같다. 못해도 일주일에 1챕터는 포스팅하도록 하겠다. <포스팅 리스트> Chapter 1. 형식 연역 (Type Deduction) [항목 1~4] Chapter 2. auto [항목 5~6] Chapter 3. 현대적 C++에 적응하기 [항목 7~17] Chapter 4. 똑똑한 포인터 (Smart Pointer) [항목 18~22] Chapter 5. 오른값 참조, 이동 의미론, 완벽 전달 [항목 23~30] Chapter 6. 람다 표현식 [항목 31~34] Chapter 7. 동시성 API [항목 35~40] Chapter 8. 다듬기 [항목 41~42] 포스팅에 사용한 코드들은 모두 Github에 올릴 것이다. ( https://github.com/taeguk/Effective-Cpp-Series ) 단, 포스팅에 사용한 것과 약간 차이가 있을 수 있다.

기간 : 1월 16일 - 2월 28일 (순수 6주) 회사 : http://www.sualab.com Deep learning based industrial image analysis toolkit의 알파버전을 개발했다. (시장에서의 선점 기업은 https://www.vidi-systems.com/ 이다.) 구체적으로 내가 무엇을 했는 지는 https://www.linkedin.com/in/taeguk/ 에 적어놓았다. 회사는 되게 좋다. 우리나라에 이 만한 회사 몇 없을 것이다. 회사가 궁금한 사람은 아래 방송을 보는 것도 좋을 것이다. http://sbscnbc.sbs.co.kr/read.jsp?pmArticleId=10000849000 그리고,, 인턴하면서 느낌점 -> 도메인에 대한 지식과 요구사항 분석은 매우 중요하다.   아무리 C++을 잘하고 소프트웨어 설계를 잘하는 사람이더라도 만약 비지니스 도메인을 파악하지 못한채로 개발을 시작하면, 아무 쓸데없는 결과물이 나올 것이다. 설계를 잘한다는 것은, 고급적인 디자인 패턴이나 어려운 언어 스킬들을 많이 쓴다고 되는 것이 아니다. 기술은 2순위이고, 1순위는 '요구사항'을 정확하게 분석하는 것이다. 요구사항이 정확하게 분석되고나서 기술은 그 뒤를 받쳐주는 것이다. 이번에 가장 뼈져리게 느낀 것이다. 고객들이 어떠한 것들을 요구하는지, 무엇이 중요하고 우선순위인 것인지 파악하고 구체화하는 게 가장 먼저 그리고 충분한 시간을 들여서 해야할 일이다. 요구사항과 도메인에 대한 분석이 충분히 선행되고 나서 소프트웨어적인 설계, 즉 클래스를 어떻게 설계할 것이고 어떤 기술들을 사용할 것이고 하는 것들이 고려되야 한다. 아무도 필요로 하지 않는 기능을 아무리 잘 만들어봐야 전혀 쓸모가 없다.   그리고 소프트웨어를 설계할 때 크게 3가지 점에서 trade-off할 일이 많다. 개발시간 / 유지보수 / 성능 이다. 빨리 개발하고, 유지보수하기 좋은 코드를 짜고, 성능을