[모던 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

[모던 C++ #3] 매크로 상수를 버리고 constexpr와 enum class로!

과거 C++98/03 시절에는 정적 상수를 정의할 때 매크로를 사용하는 경우가 흔했습니다. 매크로는 전처리 단계에서 단순한 텍스트 치환을 수행하므로, 타입 정보가 없고 디버깅도 까다롭다는 문제가 있었습니다. 또한 범위(scope) 개념이 없어 어디서나 무분별하게 확장되며, 심지어 이름 충돌 문제도 야기할 수 있었습니다.모던 C++에서는 이러한 문제를 해결하기 위해 constexpr, const 정적 상수, 그리고 enum class를 적극적으로 활용할 수 있습니다. 이를 통해 타입 안전성과 가독성을 향상시키고, 컴파일 시간 상수 평가를 통한 성능 최적화도 기대할 수 있습니다.관련 참고 자료:constexpr specifierenum class과거: 매크로 상수의 문제점C-Style 매크로를 통해 상수를 ..

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

[모던 C++ #2] C-Style 배열을 벗어나: std::array, std::vector 그리고 std::span으로!

과거 C++98/03 시절, 정적 크기를 갖는 C-Style 배열은 흔하게 사용되었지만, 실제로는 다양한 문제를 안고 있었습니다. 배열의 크기를 코드 곳곳에 명시해야 하거나, 함수 인자로 전달할 때 크기 정보를 잃기 쉽고, 범위 초과 액세스를 검증하기 어렵다는 점 등이 대표적입니다. 이러한 방식은 대규모 프로젝트에서 메모리 안전성을 저해하고, 유지보수를 어렵게 만들었습니다.모던 C++에서는 이 문제를 해결하기 위해 여러 대안들이 등장했습니다. std::array는 정적 크기 배열을 안전하게 감싸며, std::vector는 동적 크기 배열을 편리하게 관리하고, C++20의 std::span은 기존 배열이나 컨테이너의 뷰(view) 역할을 하여 범위 정보를 담은 인터페이스를 제공합니다.관련 참고 자료:std..

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

[모던 C++ #1] 이제는 버려야 할 레거시: auto_ptr를 내려놓고 unique_ptr로!

2025년 현재, 모던 C++ 개발자는 더 이상 std::auto_ptr를 사용하는 모습을 보기 어렵습니다. auto_ptr는 C++98/03 시절 스마트 포인터의 초기 시도로 등장했으나, 그 독특하고 혼란스러운 소유권 전이(transfer) 방식으로 인해 많은 문제를 야기했습니다. 결국 C++11 이후 auto_ptr는 사용이 권장되지 않는(deprecated) 상태가 되었고, C++17에서는 완전히 제거되었습니다.이 글에서는 과거에 auto_ptr가 어떻게 사용되었는지, 그리고 그것이 어떤 문제를 일으켰는지 살펴봅니다. 이후 std::unique_ptr 및 std::shared_ptr가 등장함으로써 C++ 메모리 관리가 어떻게 개선되었는지, 그리고 이 변화가 왜 필수적이었는지 분석하겠습니다.관련 참고..

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

[개발자 영어] Death March

이번에 소개할 표현은 "Death March"입니다. "Death March"는 소프트웨어 개발 프로젝트에서 터무니없이 빡빡한 일정, 과도한 요구사항, 현실성 없는 목표로 인해 팀원들이 지칠 대로 지치고, 결국 생산성뿐 아니라 사기까지 바닥나는 상황을 비유적으로 표현한 말입니다. 즉, 마치 불가능에 가까운 여정을 강제로 행군(march)하듯, 고통스럽고 지속 불가능한 업무 강도를 뜻합니다.1. 의미"Death March"는 프로젝트가 비합리적인 요구조건 하에 진행되면서, 개발자가 주말, 야근 할 것 없이 일을 몰아치지만, 결과적으로 품질 저하, 번아웃, 일정 지연이 발생하는 악순환을 가리킵니다. 프로젝트 관리 상의 문제로 인해 "죽음의 행군"을 강요당하는 셈입니다.예:"이번 릴리즈까지 남은 시간이 일주일..

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

[개발자 영어] Not Invented Here (NIH) Syndrome

이번에 소개할 표현은 "Not Invented Here (NIH) Syndrome"입니다. "NIH Syndrome"은 외부에서 만든 기술, 라이브러리, 툴을 쉽게 받아들이지 않고, 오직 내부에서 직접 만들어야만 가치 있다고 여기는 태도를 나타냅니다. 즉, 이미 검증된 솔루션이 있음에도 "우리가 직접 만들어야 한다"는 근거 없는 자부심 혹은 편견으로 인해 재발명(reinventing the wheel)에 시간을 소모하고 기술 부채를 쌓는 행위를 뜻합니다.1. 의미"NIH Syndrome"은 타인이 만든 것을 신뢰하지 않고, 외부 솔루션 채택을 기피하는 경향을 가리킵니다. 이로 인해 팀은 기존에 잘 작동하는 라이브러리를 두고 굳이 내부 구현을 시작하거나, 오픈소스 솔루션을 외면하고 비슷한 기능을 스스로 개..

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

[개발자 영어] Rubber Duck Debugging

이번에 소개할 표현은 "Rubber Duck Debugging"입니다. "Rubber Duck Debugging"은 디버깅 기법 중 하나로, 문제를 해결하기 위해 실제 오리 인형(고무오리)에게 문제 상황을 단계별로 설명하는 과정을 의미합니다. 즉, 단순히 자신의 생각을 누군가(또는 무언가)에게 소리 내어 설명하는 것만으로도 머릿속을 정리하고 논리적 허점을 발견할 수 있다는 개념입니다.1. 의미"Rubber Duck Debugging"은 대상을 꼭 사람일 필요 없이, 말 못하는 오리 인형이라도 괜찮다는 점에 초점을 맞추고 있습니다. 핵심은 문제를 말로 풀어가는 과정에서 스스로 논리를 재검토하고, 숨겨진 오류나 잘못된 가정을 스스로 깨닫게 된다는 것입니다. 이렇게 함으로써 다른 사람을 귀찮게 하지 않고도 자..

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

[개발자 영어] Cargo Cult Programming

이번에 소개할 표현은 "Cargo Cult Programming"입니다. "Cargo Cult Programming"은 소프트웨어 개발에서 특정 코드나 패턴을 왜 사용하는지 정확한 이해 없이, 단지 형식적으로 베끼고 따르기만 하는 행위를 의미합니다. 마치 화물이 실린 비행기를 다시 불러오기 위해 가짜 활주로를 만드는 '카고 컬트(Cargo Cult)' 부족의 의식처럼, 그럴싸해 보이는 관행을 이유 없이 흉내내지만, 실제 문제 해결이나 품질 개선에는 별 도움이 되지 않는 상황을 비유합니다.1. 의미"Cargo Cult Programming"은 '무의미한 모방'을 가리킵니다. 개발자가 어떤 라이브러리나 프레임워크, 디자인 패턴을 적용할 때, 그 의도를 이해하지 않은 채 겉모습만 따라 하는 경우입니다. 이런 ..

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