발아 바라 프로그래밍

항목 26에서 나온 문제에 대하여 해결 방법을 알아보자. 2019/12/01 - [C++/Effective Modern C++] - [Effective Modern C++] 항목 26. 보편 참조에 대한 중복적재를 피하라 불러오는 중입니다... 중복적재를 포기한다 항목 26에서 사용한 logAndAdd 함수를 중복적재를 사용하다보니 문제가 발생하였다. 문제가 발생하는 함수에 대하여 함수 명을 logAnddAddNameIdx 와 같이 변경하면 문제를 해결할 수 있다. 그렇지만 생성자의 경우에는 함수명을 변경할 수 없기 때문에 해결할 수 없는 경우도 있다. const T& 매개변수를 사용한다. 보편 참조 매개변수 대신에 const에 대한 왼값 참조 매개변수를 사용할 수 있다. 이는 항목 26에서 사용한 방법..

이전 항목에서 우리는 보편 참조에 대한 중복적재의 문제점에 대해 이야기하였고 문제를 해결하기도 하였다. 다음과 같이 말이다. template void logAndAdd(T&& name) { auto now = std:;chrono::system_clock::now(); log(now, "logAndAdd"); names.emplace(std:;forward(name)); } std::string petName("Darla"); logAndAdd(petName); logAndAdd(std::string("Persephone")); logAndAdd("Patty Dog"); 위의 코드는 어떤 상황에서든 함수 하나로 우리가 원하대로 수행해준다. 그런데 여기서 오버로딩 함수 하나를 더 추가한다고 해보자. voi..

오른값 참조는 이동할 수 있는 객체에만 묶인다. 다시 말하면 어떤 매개변수가 오른값 참조라면, 객체를 이동할 수 있다는 의미이다. 오른값 참조로 캐스팅해주는 객체가 바로 std::move 함수이다. 반면에 보편 참조는 오른값 참조일수도 있지만 아닐수도 있다. 오른값일때만 오른값으로 캐스팅해주어야하는데 이 역할을 하는 함수가 std::forward 이다. 오른값 참조일때도 std::forward 를 사용할 수 있지만, 실수의 여지가 생기며 관용구에서 벗어나기 때문에 사용하지 않는것이 좋다. 그런데 보편 참조에 std::move 를 사용하는 것은 매우 위험하다. 코드를 살펴보자. class Widget { public: template void setName(T&& newName) // 보편 참조 { nam..

오른값 참조를 사용할 때, 우리는 &&를 뒤에 붙여 오른값 참조임을 명시한다. 하지만 보편 참조의 경우에도 &&를 붙이기 때문에 구분해서 사용해야만 한다. 예시를 살펴보자. void f(Widget&& param); // 오른값 참조 Widget&& var1 = Widget(); // 오른값 참조 auto&& var2 = var1; // 오른값 참조 아님 template void f(std::vector&& param); // 오른값 참조 template void f(T&& param); // 오른값 참조 아님 언뜻보기에는 오른값 참조처럼 보이지만 보편 참조인 경우가 상당히 많다. 보편 참조의 의미는 오른값 참조이거나 왼값 참조 중 하나라는 의미이다. 보편 참조는 일반적으로 두 가지 문맥에서 나타난다. ..

C++11 에 등장한 move semantic 에 중요한 함수 두가지가 있다. 바로 std::move 와 std::forward 함수이다. std::forward 는 std::move 함수를 이해하면 쉽게 이해할 수 있으므로 먼저 std::move 에 대해서 알아보자. std::move 함수의 이름만 보면 std::move 가 이동을 수행해줄 것처럼 보이지만 사실 타입 캐스팅이 전부이다. 그런데도 이 함수의 이름이 move 인 이유는 오른값으로 캐스팅을 하기 때문이다. std::move 를 구현하면 다음과 같이 구현할 수 있다. template decltype(auto) move(T&& param) { using ReturnType = remove_reference_t&&; return static_ca..

Pimpl 이란 "pointer to implementation" 을 의미한다. 코드를 먼저 살펴보자. 기존코드 class Widget { public: Widget(); ... private: std::string name; std:;vector data; Gadget g1, g2, g3; }; Pimpl 적용 코드 class Widget { public: Widget(); ~Widget(); ... private: struct Impl; Impl *pImpl; }; Pimpl 적용 코드를 보면 std::string, std::vector, Gadget 을 선언하지 않고 있기 때문에 #include 할 필요가 없어졌다. 덕분에 컴파일 속도가 빨라지게 되었다. 이렇게 선언만 하고 정의를 하지 않는 형식을..

선호 이유 간결한 코드 설명을 하기 전에 코드를 먼저 살펴보자. auto spw1(std::make_shared()); std::shared_ptr spw2(new Widget()); 먼저 코드의 길이부터 약간이지만 더 짧아진 것을 확인할 수 있다. 또한 타입 선언을 한 번만 작성하는 곳을 볼 수 있는데, 이는 소프트웨어 공학의 핵심 교의 중 하나인 "코드 중복을 피하라"를 잘 지키는 것이다. 소스 코드의 중복이 많으면 컴파일 시간이 늘어나며 일관성이 없는 코드로 진화하기 일쑤이다. 코드의 비일관성은 버그로 이어지는 경우가 많다. 예외 안정성 이 역시 코드를 먼저 살펴보자. void processWidget(std::shared_ptr spw, int priority); int computePriorit..

앞서 살펴본 스마트 포인터들 중에서 가장 이해하기 어려운 것이 weak_ptr 이다. unique_ptr 와 shared_ptr 는 목적이 분명하지만 weak_ptr 는 경험하지 않는다면 언제 써야하는지 알기 어렵다. 이 포스트에서 weak_ptr 를 사용해야하는 경우를 살펴보자. 사용법 weak_ptr 는 언제든 소멸될 수 있는 객체를 사용할 때 쓰는 스마트 포인터이다. weak_ptr 는 shared_ptr 와 함께 사용하는 스마트 포인터이지만 reference_count 를 증가시키지 않는다. 다시 말하면 객체의 소멸에 관여하지 않는다는 뜻이다. 그로 인한 문제로 사용하려고 하는 순간 이미 객체가 소멸될 수도 있는 것이다. 만약 객체를 사용할 때, 객체가 소멸되는 경우 crash 가 발생하게 되는 ..