[모던 C++ #10] 직접 구현한 알고리즘 대신 C++20 Ranges와 병렬 알고리즘으로!

과거 C++98/03 시절에는 표준 라이브러리가 제공하는 알고리즘도 제한적이었고, 특정 요구사항을 만족하기 위해 개발자가 직접 알고리즘을 구현하거나, 반복자 기반 STL 알고리즘을 복잡하게 조합해야 하는 경우가 많았습니다. 또한 병렬 처리나 고성능 연산을 위해서는 플랫폼별 스레드 관리나 OpenMP, TBB 같은 서드파티 라이브러리에 의존해야 했습니다.모던 C++20에서는 Ranges 라이브러리를 통해 알고리즘 파이프라인을 선언적으로 구성할 수 있으며, 병렬 알고리즘 지원을 통해 표준 라이브러리 레벨에서 병렬화를 쉽게 도입할 수 있습니다. 이렇게 하면 코드 가독성과 유지보수성이 대폭 개선되며, 성능 향상을 위한 병렬화도 간단히 적용할 수 있습니다.관련 참고 자료:C++20 RangesParallel al..

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

[모던 C++ #9] 직접 스레드 관리에서 std::jthread와 코루틴으로!

과거 C++98/03 시절, 멀티스레딩을 구현하기 위해서는 운영체제별 API(pthread, Win32 threads 등)를 직접 호출하거나, Boost Threads와 같은 서드파티 라이브러리에 의존해야 했습니다. 이는 코드 이식성을 저하시켰고, 스레드 생성, 종료, 동기화 관리가 번거롭게 이루어지는 경우가 많았습니다.C++11 이후 표준 라이브러리에 std::thread, std::mutex, std::lock_guard, std::async 등 기본적인 멀티스레딩 기능이 도입되었고, C++20에서는 std::jthread와 중단 요청(stop token) 메커니즘이 추가되어 스레드 관리가 더 단순해졌습니다. 또한 C++20 코루틴(coroutine)을 활용하면 비동기 처리를 더 간결하고 직관적으로 ..

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

[모던 C++ #8] 구식 function object와 std::bind를 버리고 람다와 std::function로!

과거 C++98/03 시절에는 함수 객체(function object) 클래스를 직접 정의하거나, std::bind를 통해 함수 호출을 커스터마이징하는 패턴이 흔했습니다. 하지만 이러한 방법은 코드가 장황해지고 의도를 분명히 드러내지 못하는 경우가 많았습니다. 호출 대상이 어디에 있는지, 어떤 인자를 바인딩했는지 일일이 추적해야 했으며, 이는 코드 가독성과 유지보수성에 악영향을 끼쳤습니다.모던 C++에서 이 문제를 해결하기 위해 람다(lambda) 표현식과 std::function을 사용할 수 있습니다. 람다는 익명 함수 객체를 간결한 문법으로 정의할 수 있고, 캡처를 통해 외부 변수를 자연스럽게 접근할 수 있습니다. 또한 std::function은 범용 함수 포인터 래퍼로, 다양한 호출 대상(람다, 함..

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

[개발자 영어] Golden Hammer

이번에 소개할 표현은 "Golden Hammer"입니다. "Golden Hammer"는 소프트웨어 개발에서 만병통치약처럼 하나의 기술, 툴, 패턴, 방법론만을 무조건적으로 선호하고, 모든 문제에 동일한 해법을 적용하려는 태도를 가리키는 표현입니다. 말 그대로 '금으로 된 망치(Golden Hammer)'가 있어서 마치 모든 문제가 못 박기처럼 보이는 상황을 풍자한 것입니다.1. 의미"Golden Hammer"는 특정 기술이나 아키텍처 패턴에 지나치게 집착해, 실제로는 다른 접근법이 더 합리적인 상황에서도 무조건 그 익숙한 방법을 사용하려는 경향을 나타냅니다. 이는 다양한 문제 해결 능력을 제한하고, 장기적으로 코드 품질과 팀 생산성을 떨어뜨리는 결과를 초래할 수 있습니다.예:"이 팀은 언제나 마이크로서비..

• format_list_bulleted 미국 빅테크/일일 영어
• · 2024. 12. 14.
• textsms

[모던 C++ #7] SFINAE 트릭을 떠나 Concepts로!

과거 C++ 템플릿 프로그래밍에서 타입 제약을 표현하기 위해 사용되던 기법 중 하나가 바로 SFINAE(Substitution Failure Is Not An Error)였습니다. 이는 템플릿 인자의 대입 과정에서 타입이 맞지 않을 경우 에러 대신 다른 오버로드를 시도하는 기법으로, 조건부로 템플릿을 선택하는 메타프로그래밍 트릭이었습니다.그러나 SFINAE는 코드가 복잡해지고, 컴파일 에러 메시지가 난해해진다는 단점이 있었습니다. 모던 C++20에서는 Concepts를 통해 이 문제를 해결했습니다. Concepts는 템플릿 인자에 대한 명확한 제약 조건을 선언적으로 표현할 수 있어 코드 가독성과 유지보수성, 그리고 에러 진단을 크게 개선합니다.관련 참고 자료:SFINAEConcepts (C++20)과거:..

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

[모던 C++ #6] printf에서 벗어나 std::format으로!

과거 C++98/03 시절, 문자열 형식 지정 출력은 주로 C 표준 라이브러리 함수를 이용했습니다. printf 계열 함수들은 간단히 사용할 수 있지만, 타입 미스매치 문제나 서식 문자열 관리가 번거로운 단점이 있었습니다. 예를 들어 %d, %f, %s 등의 포맷 지정자가 실제 매개변수와 불일치할 경우 런타임 버그가 발생할 수 있으며, 이는 디버깅하기도 까다롭습니다.모던 C++에서는 이러한 문제를 해결하기 위해 C++20부터 std::format 함수를 도입했습니다. 이는 타입 안전하고, Python의 f-string과 유사한 형식 지정 문법을 제공하며, 가독성과 유지보수성을 크게 향상시킵니다.관련 참고 자료:std::format (C++20)과거: printf 계열 함수의 문제점printf는 서식 문자..

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

[개발자 영어] Heisenbug

이번에 소개할 표현은 "Heisenbug"입니다. "Heisenbug"는 소프트웨어 테스트나 디버깅 과정에서 나타나는, 관측하기 어려운 특이한 버그를 가리키는 용어입니다. 이 버그는 물리학의 하이젠베르크 불확정성 원리(Heisenberg’s Uncertainty Principle)에서 이름을 따온 것으로, 관찰(또는 디버깅 도구를 사용)하려고 하면 증상이 사라지거나 달라져서 문제를 파악하기 힘든 버그를 의미합니다.1. 의미"Heisenbug"는 특정 조건에서만 발생하고, 디버깅이나 로깅을 강화하면 이상하게도 문제가 재현되지 않는 버그입니다. 즉, 관측 행위(코드 변경, 로그 추가, 디버거 접속) 자체가 버그의 상태에 영향을 미쳐, 원인을 파악하고 수정하기 더욱 까다로운 상황을 묘사합니다.예:"이 코드는 ..

• format_list_bulleted 미국 빅테크/일일 영어
• · 2024. 12. 14.
• textsms

[모던 C++ #5] C-Style 문자열을 넘어: std::string과 std::string_view로!

과거 C++98/03 시절에는 문자열 처리를 위해 C-Style 문자열(char*)을 직접 다루는 경우가 많았습니다. 그러나 C-Style 문자열은 널 종단 문자('\0')를 통해 문자열의 끝을 인식하고, 이를 다루는 과정에서 범위 초과, 메모리 누수, 버퍼 오버플로우 같은 위험이 상존했습니다. 또한 문자열 조작을 위해 std::strlen, std::strcpy 등 C 표준 라이브러리 함수를 반복적으로 사용하는 것은 번거롭고 오류를 내기 쉬운 방식이었습니다.모던 C++에서는 이러한 문제를 해결하기 위해 std::string과 C++17 이후의 std::string_view를 활용할 수 있습니다. 이로써 문자열 처리가 안전하고 직관적이며, 성능까지 고려한 형태로 진화했습니다.관련 참고 자료:std::st..

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

[모던 C++ #4] 옛날 for 루프를 버리고 range-based for와 C++20 Ranges로!

초창기 C++에서는 컨테이너를 순회하기 위해 전통적인 for 루프나 반복자(iterator)를 명시적으로 사용하는 패턴이 흔했습니다. 이런 방식은 인덱스나 반복자 관리에 번거로움이 있었고, 컨테이너 타입이 바뀌면 루프 조건을 바꾸는 등 유지보수가 어려웠습니다.모던 C++에서는 이러한 문제를 해소하기 위해 range-based for 루프와 C++20 Ranges 라이브러리가 등장했습니다. range-based for 루프를 통해 컨테이너 순회를 단순화하고, Ranges 라이브러리를 사용하면 필터링, 변환 등의 파이프라인 스타일 알고리즘을 선언적으로 표현할 수 있습니다. 이로써 코드 가독성과 유지보수성이 크게 향상됩니다.관련 참고 자료:Range-based for loopC++20 Ranges 라이브러리과..

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

[개발자 영어] Code Smell

이번에 소개할 표현은 "Code Smell"입니다. "Code Smell"은 코드 내에 존재하는 '버그는 아니지만 문제가 될 수 있는' 특이한 구조나 이상 징후를 가리키는 표현입니다. 즉, 겉보기에 작동은 하지만 어딘가 찜찜하고 유지보수나 확장에 장애가 될 수 있는 코드상의 불쾌한 냄새(Smell)를 비유한 것입니다.1. 의미"Code Smell"은 명확한 버그나 에러 상태가 아닌데도, 향후 문제를 야기하거나 복잡도를 키우는 코드를 가리킵니다. 예를 들어, 너무 길고 중복이 많은 함수, 불명확한 변수명, 관련 없는 기능들이 뒤엉킨 모듈 등은 당장은 돌아가지만, 이후 개발자가 이해하기 어렵고 변경하기 까다로운 상태를 만듭니다. 마치 음식이 상하기 직전 이상한 냄새를 풍기듯, 코드도 부패 직전의 신호를 '냄..

• format_list_bulleted 미국 빅테크/일일 영어
• · 2024. 12. 14.
• textsms