cplusplus: 실전적 클래스 설계와 구현

요약TPSMeter에서 락 사용 여부를 런타임 bool로 판단하던 걸 → Non-type template parameter로 바꿔서 컴파일 타임에 결정되게 함if constexpr로 분기해서 런타임 오버헤드를 완전히 제거근데 중복 코드가 생기니까 → constexpr_lock_guard를 11줄로 만들어서 중복 제거std::monostate + RVO + 타입 추론 활용한 제로 코스트공수와 오용(misuse)을 줄이고 가독성을 높이면서도 기존 방식 대비 약 5.1배의 성능향상 시작C++17에 도입된 if constexpr은 기존의 const 보다 더 나은 퍼포먼스를 제공합니다. constexpr은 컴파일 타임에 평가를 보장합니다. 따라서 constexpr로 사용된 if문으로 분기되는 런타임 오버헤드를 없..

생각보다 현업에서 많이 사소하게 사용하는 게 bool flag입니다. 단순한 상태 저장용으로 쓰기 시작하지만 복잡한 루프나 멀티스레드 환경을 만나면 간단했던 플래그가 만만치 않게 됩니다. 또 상태 하나를 체크하기 위해 이전값과 같은지 수동으로 비교하고 값을 업데이트해주어야 합니다. 일반적인 Flag 사용bool is_active = false; // 이전 상태 저장용void on_receive_signal(bool status){ // 켜지는 시점 감지: "현재는 true인데, 이전엔 false였나?" if (status == true && is_active == false) { is_active = true; // 상태 수동 갱신 std::cout 생각보다 현업에서 사소하게 사용되는..

여기서 사용된 C++ 기법들더보기템플릿 관련- 함수 템플릿: `template` 로 타입별 함수 자동 생성- 템플릿 특수화: `template struct parser` 처럼 특정 타입에 대한 별도 구현- 비타입 템플릿 파라미터: `std::ios_base &(*in_type)(std::ios_base &) = std::dec` - 함수 포인터를 템플릿 인자로 사용컴파일 타임 기법- `static_assert`: 컴파일 타임에 잘못된 타입 사용 차단- `if constexpr` (C++17): 컴파일 타임 분기, 조건에 맞지 않는 코드는 아예 컴파일 안 됨- `std::conditional_t`: 조건에 따라 타입 선택 (메타프로그래밍)타입 트레이트 (Type Traits)- `std::is_arithm..

클래싱 포인트SFTPCurl / SFTPCurlTemplate 클래스를 정의해 libcurl 옵션 설정과 에러 처리 캡슐화CRTP(Curiously Recurring Template Pattern)을 사용해 템플릿으로 추상화, 파생 클래스를 정적으로 확장Fluent Interface (메서드 체이닝) 패턴을 사용하여 user(...).password(...).url(...) 와 같은 인터페이스 설계단일 책임 원칙(SRP)와 인터페이스 분리 원칙(ISP)을 적용하여 업로드, 다운로드 기능 클래스 분리예외 클래스(SFTPCurl::exception) 로 CURL 오류를 객체 지향적으로 처리프록시 패턴을 이용한 실행(perform())RAII를 활용한 스마트 포인터(unique_ptr)와 ScopeExit를 ..

UDP는 송수신 시 데이터를 패킷(덩어리) 단위로 주고받습니다. 따라서 UDP를 사용할 때는 여러 가지 위험 요소를 고려하여, 데이터 크기가 MTU(Maximum Transmission Unit)에서 IP 및 UDP 헤더 크기를 뺀 값을 초과하지 않도록 설계합니다. by NotebookLM UDP 소켓을 통해 데이터를 수신할 때는 일반적으로 다음과 같은 recvfrom 함수를 사용합니다:ssize_t recvfrom(int sockfd, void buf[restrict .len], size_t len, int flags, struct sockaddr *_Nullable restrict src_addr, ..

어플리케이션에서 흔히 볼 수 있는 코드 중 하나가 마스터 정보를 메모리에 두고 다수의 쓰레드가 검색하는 것입니다. 이런 Read-Only 데이터셋은 굳이 Lock을 만들 필요가 없습니다. 하지만 이 마스터 정보가 간헐적으로 업데이트된다면 하는 수 없이 Lock을 사용해야 하는데요,간헐적으로 일어나는 업데이트 때문에 다수의 쓰레드도 데이터셋에 접근시마다 Lock을 사용할 수밖에 없습니다. 이렇게 되면 싱글쓰레드에서 검색하는 게 오히려 더 빠릅니다. C++ std::mutex보다 빠른 RCU(Lock-free) 라이브러리: cppurcuC++ Lock-free library faster than std::mutex: cppurcu 읽기 작업이 많은 프로세스멀티스레드 환경에서 특정 자료는 거의 읽기가 대부분..

들어가며 모던 C++을 사용하지 않은 코드에서는 std::string이나 std::array보다는 문자 기반의 배열을 자주 사용합니다. 이러한 방식은 코딩 실수가 발생하기 쉬우며, 그로 인해 의도치 않은 동작이나 비정상적인 종료로 이어질 수 있습니다. 특히 구조체에 이런 배열을 십수 개 이상 선언하는 관습에서는, 배열 복사 과정에서 발생하는 오류를 찾기가 쉽지 않습니다. 테스트를 진행하더라도 오류가 발생한 지점에서 즉시 종료되지 않는 경우가 많기 때문에, 문제를 더욱 찾기 어렵게 만듭니다. 이러한 배열 복사는 오늘날 실무에서도 여전히 자주 사용되고 있습니다. 때문에 모던 C++을 잘 모르는 많은 개발자들은 아직도 배열을 하나하나 확인하는 고통을 받고 있습니다. :( 여기서는 모던 C++을 이용하여 자동..

C의 getopt는 프로그램에서 인자 호출 시 많이 사용합니다. 보통은 아래와 같이 사용하는데요, 이렇게 하면 인자 처리하는데 많은 코드 양과 다른 부분들이 뒤섞이면서 좀 복잡해집니다. 고전 C 스타일#include #include #include #include #include int main(int argc, char *argv[]) { int opt; int a_flag = 0, b_flag = 0, c_flag = 0; int a_value = 0; int b_value = 3; // 기본값 char c_value[256] = {0}; // 명령줄 인수 파싱 while ((opt = getopt(argc, argv, "a:b:c:v")) != -1) { switch ..

프로젝트에 참여해서 일을 하다 보면 TPS를 측정해야 할 일이 종종 있습니다. 이미 프로젝트에 사용되던 TPS소스를 사용하려 했지만 사용이 쉽지 않았습니다. TPS측정 소스를 보면 시간별 버킷을 이용하는 게 일반적이고, 유독 이런 소스들을 보면 복잡도가 상당히 높은 경향을 보였습니다. 이건 사실 측정 방식의 문제와는 다른 문제 이긴 합니다. by NotebookLM 난해한 코드아래 코드는 어떤 회사에서 사용됐던 TPS 계산 코드입니다,더보기int get_TPS(vector& vecTPS, std::atomic& nCurSec, int nRef){ int nCurIndex = (nCurSec/(nRef*1000))%TPS_MAX_INDEX; int PreIndex = (nCurIndex+TPS_MA..

C++ 강력한 동시성 제어(1) - BlockingQueue 이해C++ 강력한 동시성 제어(2) - BlockingQueue 구현C++ 강력한 동시성 제어(3) - BlockingQueue을 이용한 Logger 이 글에서는 이전 포스팅 "C++ 강력한 동시성 제어(1) - BlockingQueue" 에서 구현해야 할 BlockingQueue를 std::deque가 아닌 std::vector기반으로 구현합니다. 이 구현은 boost::lockfree::queue보다 빠르며 표준 라이브러리를 이용한 구현으로 안정성과 편의성(자유로운 데이터형식, 디버깅)이 높고 외부 의존성을 피할 수 있습니다. std::vector기반의 BlockingQueue 벤치마크는 "C++ Lockfree Queue 항상 좋은 선택일..

C++ 강력한 동시성 제어(1) - BlockingQueue의 이해C++ 강력한 동시성 제어(2) - BlockingQueue 구현C++ 강력한 동시성 제어(3) - BlockingQueue을 이용한 Logger 멀티쓰레드 환경에서의 어플리케이션은 쓰레드간 데이터 교환을 안전하고 효율적으로 주고받아야 하며 이러한 생산자와 소비자의 속도를 조절하는 등 동시성 문제를 해결하는 데 대한 이해는 매우 중요합니다. 특히 BlockingQueue는 동시성 프로그래밍이 필요한 어플리케이션 개발에서는 꼭 알아야 할 지식이라고 할 수 있습니다. 동시성 문제를 해결하는 가장 대표적이고 효과적인 방법 중 하나이기 때문입니다. 국내에서 많이 사용되는 언어인 JAVA(java.util.concurrent.BlockingQueu..

C++은 11 버전부터 Thread Local Storage를 지원하기 시작했습니다. 그 이전에는 Windows NT (__declspec(thread)) - 1994, POSIX threads (pthread_key_*) - 1995, GCC (__thread) - 2002에서 지원하기 시작했습니다. 이 오래된 Thread Local Storage(이하 TLS)는 그만큼 매우 유용한 기능이라 볼 수 있습니다. errno도 대표적인 TLS변수입니다. TLS의 장점은 각 개별 쓰레드가 필요한 리소스 경쟁을 피하면서도 성능과 사용성에 유리하게 적용할 수 있다는 점입니다. 같이보면 좋은 글C++ 멀티쓰레드: Read-Only 데이터셋의 업데이트와 락프리 접근C++ std::mutex보다 빠른 RCU(Lock..

std::thread의 실전적 랩핑 - thread 클래스 구현std::condition_variable의 안전한 시그널링들어가며C++11에서 std::thread가 도입된 이후, 많은 개발자들이 멀티쓰레딩 프로그래밍을 더 쉽게 할 수 있게 되었습니다. 하지만 실제 프로덕션 환경에서는 std::thread를 직접 사용하는 것보다는 적절히 랩핑 하여 사용하는 것이 더 안전하고 유지보수하기 좋습니다. 이 글에서는 실전에서 사용할 수 있는 쓰레드 래퍼 클래스를 처음부터 구현해 보면서, 각 단계에서의 설계 결정과 그 이유를 살펴보겠습니다. by NotebookLM std::thread 사용 시의 실제 문제점들실제 프로젝트에서 std::thread를 직접 사용하면서 마주치는 주요 문제들이 있습니다: 쓰레드 시작/..

std::condition_variable의 안전한 시그널링std::thread의 실전적 랩핑 - thread 클래스 구현 C++17로 진화하기: std::condition_variable 안전한 랩핑 C++17로 진화하기: std::condition_variable의 안전한 랩핑이전에 아래 내용을 C++11로 랩핑 하였는데요, std::condition_variable의 안전한 시그널링앞서 소개한 위 코드를 C++17로 다시 랩핑 하려 합니다. 특히 std::condition_variable에서의 C++11의 복잡했던 템플릿식cplusplus.tistory.com [[아래 글은 C++11 기준]] 쓰레드 간 동기화와 시그널링은 멀티쓰레드 프로그래밍에서 가장 기본적이면서도 까다로운 문제 중 하나입니다..

RAII(Resource Acquisition Is Initialization)는 현대 언어에 와서는 없어서는 안 될 필수 개념으로 자리 잡았습니다. 그리고 현대 언어들에게 많은 영향을 끼쳤습니다. 하지만 이를 적극 활용하여 개발하는 C++개발자는 게임 이외의 산업에서는 드문 편입니다. 한국은 젊은 C++개발자들이 없어서 일까요? 아니면 C개발자들이 마지못해 JAVA나 C++시장으로 밀려들어와서 일까요. C99 부터는 C++과 호환되지 않습니다. C는 C23표준에 와서야 자동해제를 지원하기 시작했습니다.) C개발자들이 C++ 생태계에 참여하는 것은 매우 환영할 만한 일입니다. 하지만 이 과정에서 C++의 현대적 특성이 이해되지 않고, 단순히 'C의 확장' 정도로 취급되는 현실은 비판적으로 바라볼 필요가 ..

동시성 프로그래밍에서 락-프리(queue) 데이터 구조는 매력적으로 보일 수 있습니다. 블로킹이 없는 비블로킹 설계 덕분에 높은 성능과 낮은 지연 시간을 기대할 수 있기 때문입니다. 그러나 락-프리 큐가 항상 최선일지는 정말 고려할 점이 생각보다 많습니다.장점 - 블로킹 없는 높은 성능, 지연시간 감소, 교착상태 없음단점 - 구현시 복잡도(CAS경합, 메모리 관리, ABA문제), 대기 시 CPU소모량, 제약조건들 또는 외부 라이브러리 의존성.락프리 알고리즘을 구현하려면 하드웨어부터 운영체제, 컴파일러, 그리고 애플리케이션 레벨까지 모든 계층에서 세심한 주의가 필요합니다. C++ Core Guidelines에서는 락프리 프로그래밍을 정말 필요치 않으면 사용하지 말라고 권고하고 있으며 이런 구현상의 난이도 ..