[모던 C++로 다시 쓰는 GoF 디자인 패턴 총정리 #27] 프록시(Proxy) 패턴: 상속 없이 람다와 Concepts로 대리 객체 구현하기

이전 글에서는 플라이웨이트(Flyweight) 패턴을 모던 C++ 관점에서 재해석하며, 상속 없이 값 기반 공유 로직을 단순히 구현하고, 조건부 처리, 비동기 로딩, 로깅, 에러 처리 등 다양한 요구에도 쉽게 대응할 수 있음을 확인했습니다. 이번에는 구조적 패턴 중 프록시(Proxy) 패턴을 다룹니다.프록시 패턴은 객체 접근을 제어하거나, 지연 로딩(Lazy Loading), 원격 호출(Remote Proxy), 캐싱(Caching), 권한 체크 등의 기능을 대리 객체를 통해 투명하게 추가하는 패턴입니다. 전통적으로는 상속 기반 인터페이스와 Proxy 클래스를 정의해 접근 로직을 구현했으나, 이는 클래스 증가, 유지보수 어려움, 에러 처리나 비동기 처리 시 복잡성을 초래합니다.C++20 이상에서는 Con..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 16.
• textsms

[PyTorch로 시작하는 강화학습 입문] 8편: Actor-Critic 접근 – A2C(Advantage Actor-Critic) 기초 구현

정책기반 접근(REINFORCE)은 정책을 직접 파라미터화하고, 에피소드가 끝난 후 누적보상을 이용해 정책 그래디언트를 업데이트합니다. 이 방법은 개념적으로 간단하지만, 다음과 같은 단점이 있습니다.고분산 업데이트: 에피소드 단위로 G(Return)를 계산하므로, 긴 에피소드나 복잡한 문제에서는 분산이 매우 커져 업데이트 효율이 떨어집니다.느린 반응: 에피소드가 끝나야만 업데이트가 이루어지므로 실시간 반응이 어려움.Actor-Critic 접근은 이러한 문제를 완화합니다. 여기서 에이전트는 두 가지 신경망(또는 하나의 공유 신경망)을 갖습니다.Actor(정책 네트워크): πθ(a|s)를 파라미터화하여, 상태에서 행동 확률분포를 출력 (정책기반)Critic(가치추정 네트워크): Vψ(s)를 파라미터화하여, ..

• format_list_bulleted 개발 이야기/PyTorch (파이토치)
• · 2024. 12. 15.
• textsms

러스트 언어 입문 시리즈 - 10편: 러스트 생태계, 문서화, 테스트, 크레이트 활용과 FFI, WebAssembly 연계

앞서 우리는 러스트의 기초 문법, 소유권과 빌림 규칙, 컬렉션과 이터레이터, 구조체와 열거형, 트레이트와 제네릭, 에러 처리, 동시성, 매크로와 클로저, 빌드 스크립트까지 폭넓게 살펴보았습니다. 이제는 러스트 생태계의 장점 중 하나인 크레이트(Crate) 시스템, 문서화와 테스트 기능, 그리고 FFI(Foreign Function Interface)와 WebAssembly를 통한 확장성과 실전 활용법을 알아보며, C++과의 연계까지 생각해보겠습니다.크레이트(Crate)와 생태계(Ecosystem)C++에서 서드파티 라이브러리를 사용할 때는 vcpkg, Conan, Hunter, Buckaroo 등 다양한 패키지 매니저나 수동 빌드를 고려해야 합니다. 반면 러스트는 표준으로 Crates.io라는 공식 패키..

• format_list_bulleted 개발 이야기/Rust (러스트)
• · 2024. 12. 15.
• textsms

[OpenCL 입문 시리즈 9편] 다중 디바이스 활용: 한 시스템 내 다양한 하드웨어 자원 사용하기

안녕하세요! 지난 글에서는 디버깅과 프로파일링 기초를 다루며 OpenCL 프로그램을 더 안정적이고 효율적으로 다루는 방법을 살펴봤어요. 이제 거의 시리즈의 끝이 보이는데요. 이번 글에서는 한 시스템 내 여러 디바이스(여러 개의 GPU, CPU, 또는 이종 디바이스)를 동시에 활용하는 방법을 간략히 살펴볼 겁니다.CUDA는 보통 하나의 GPU를 다루는 경우가 많지만, OpenCL은 다양한 벤더, 다양한 하드웨어를 동시에 활용할 수 있는 아키텍처적 장점이 있어요. 예를 들어, 한 PC에 NVIDIA GPU와 Intel GPU, 그리고 CPU 디바이스까지 있을 때, 이들을 모두 활용해 연산을 나누어 처리할 수도 있습니다. 이번 글에서는 다음 내용을 다룹니다.여러 디바이스 선택 방법멀티 디바이스 컨텍스트(Con..

• format_list_bulleted 개발 이야기/OpenCL
• · 2024. 12. 15.
• textsms

[C++ 스타일 마지막 편] 마무리: 다양한 스타일 가이드 사이에서 최선의 균형 찾기

지금까지 우리는 C++ 코드 스타일에 대한 다양한 관점을 주제별로 살펴보았습니다. 들여쓰기와 공백 규칙, 네이밍 컨벤션, 헤더 파일 구조, 클래스와 함수 인터페이스, 주석과 문서화, 템플릿과 메타프로그래밍, 예외 처리와 에러 관리, 현대 문법 사용법, I/O와 문자열 처리, 빌드 시스템과 모듈에 이르기까지 폭넓은 분야를 다루었습니다.각 편에서 특정 스타일 가이드(예: 구글 C++ 스타일 가이드, LLVM 스타일 가이드, 모질라 스타일 가이드)를 언급하고, 다양한 선택지와 그 장단점, 상황별 적합도를 논해보았습니다. 이제 이 시리즈를 마무리하며, "정답"이 없는 스타일 문제에서 어떻게 팀 합의와 문서화를 통해 최선의 균형을 찾을 수 있는지 정리해보겠습니다.정답은 없다, 하지만 일관성은 있다C++ 코드 스타..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 15.
• textsms

[C++ 스타일 10편] 빌드 시스템과 모듈: 헤더 가드에서 C++20 모듈로, 프로젝트 구조 스타일

C++20 모듈(Modules) 기능은 대규모 C++ 프로젝트의 빌드 속도와 의존성 관리를 획기적으로 개선할 잠재력을 지니고 있습니다. 과거에는 헤더 가드, 전방 선언, #pragma once를 통해 복잡한 인클루드 그래프를 관리해 왔지만, 모듈 도입으로 불필요한 중복 파싱을 줄이고, 빌드 시간 최적화를 이룰 수 있습니다. 그러나 아직 모듈은 모든 빌드 시스템과 툴체인에서 광범위하게 지원되지 않으므로, 전환 과정에서 스타일 가이드 정립이 필요합니다.이번 글에서는 구글 C++ 스타일 가이드, LLVM 스타일 가이드, 모질라 스타일 가이드 등 다양한 가이드와 실제 프로젝트 사례를 바탕으로, 빌드 시스템 선택(CMake, Bazel, Meson 등), 모듈 도입 전략, 프로젝트 디렉토리 구조, 그리고 모듈-헤..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 15.
• textsms

[C++ 스타일 9편] 입출력과 문자열 처리: std::format, iostream, 로깅, 그리고 문자열 뷰

C++20의 std::format 도입으로 문자열 포매팅이 한층 편리해졌습니다. 이전에는 printf 계열 함수나 iostream 기반의 이번 글에서는 구글 C++ 스타일 가이드, LLVM 스타일 가이드, 모질라 스타일 가이드 등 다양한 가이드에서 제안하는 I/O 스타일, 문자열 처리 방식, 로깅 규칙을 살펴보며, 상황에 따라 어떤 접근이 적합한지 논의합니다.다양한 스타일 가이드의 접근구글 C++ 스타일 가이드:iostream 사용에 신중. 복잡한 I/O 로직은 명시적 함수 사용 권장std::string_view 활용을 통해 함수 인자로 문자열을 넘길 때 복사 최소화로깅 시 가독성 높은 메시지 포맷, 필요 시 std::format 기반 형식 지정 가능LLVM 스타일 가이드:iostream 사용 가능하지만..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 15.
• textsms

[C++ 스타일 8편] 현대 문법의 활용: auto, 구조적 바인딩, 람다 캡처, 그리고 개선된 for 루프

C++11 이후로 언어에 다양한 현대 문법 요소가 추가되어 개발자들의 표현력을 풍부하게 해주었습니다. auto 타입 추론, 구조적 바인딩, 람다 캡처 개선, range-based for 루프 등은 코드 가독성, 유지보수성을 높이는 강력한 도구입니다. 하지만 이 도구들을 어떻게 스타일 있게 사용하는지는 여전히 논란이 될 수 있습니다. 적절히 사용하면 코드를 간결하고 직관적으로 만들지만, 남용하면 타입 정보를 숨겨 가독성을 해칠 수 있습니다.이번 글에서는 구글 C++ 스타일 가이드, LLVM 스타일 가이드, 모질라 스타일 가이드 등에서 현대 문법 요소 사용 관련 조언을 살펴보고, 상황에 따라 어떤 방식을 권장하는지, 장단점을 비교해봅니다.다양한 스타일 가이드의 접근구글 C++ 스타일 가이드:auto는 타입이..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 15.
• textsms

[C++ 스타일 7편] 예외 처리와 에러 관리: throw, std::expected, RAII, 그리고 에러 코드 스타일

C++에서 예외(exception)는 런타임 오류를 처리하는 핵심 메커니즘이지만, 모든 코드베이스가 예외를 선호하는 것은 아닙니다. 일부 프로젝트는 성능상 이유나 제약 때문에 예외를 비활성화하고, 에러 코드를 반환하거나 std::expected를 통한 명시적 에러 처리 방식을 선호하기도 합니다. 또한 RAII를 통해 예외 안전성을 확보하고, 리소스 누수를 방지하는 패턴도 중요한 스타일 이슈입니다.이번 글에서는 다양한 스타일 가이드와 프로젝트 사례를 바탕으로, 예외 사용 여부 결정, std::expected나 에러 코드 기반 접근, RAII 기법, noexcept 사용, 그리고 에러 처리 시 주석과 문서화 방법 등을 다뤄봅니다.다양한 스타일 가이드와 사례구글 C++ 스타일 가이드:과거에는 예외 사용을 금지..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 15.
• textsms

[C++ 스타일 6편] 템플릿, Concepts, 그리고 메타프로그래밍 코드의 스타일

C++ 템플릿과 메타프로그래밍은 코드 재사용성과 추상화의 강력한 수단이지만, 복잡하고 장황해지기 쉽습니다. C++20 Concepts를 도입함으로써 타입 제약을 명확히 표현할 수 있지만, 이 또한 스타일 유지에 도전 과제를 던집니다. 템플릿 파라미터 리스트의 길고 난해한 선언, SFINAE를 통한 조건부 활성화 코드, 개별 trait 구조체나 헬퍼 템플릿의 무질서한 배치 등은 코드 가독성을 해칠 수 있습니다.이번 글에서는 구글 C++ 스타일 가이드, LLVM 스타일 가이드, 모질라 스타일 가이드 등에서 언급하는 템플릿 및 메타프로그래밍 관련 스타일 이슈를 살펴봅니다. 또한 Concepts를 활용하는 방법, SFINAE 대신 Concepts를 사용하는 접근, 템플릿 파라미터 정렬, trait 정의 분리, ..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 15.
• textsms