C++17과 C++20을 거치면서 표준 라이브러리에 실용적인 타입들이 많이 추가됐습니다. 외부 라이브러리 없이도 "값이 없을 수 있음", "여러 타입 중 하나", "파일 시스템 조작" 같은 걸 표준으로 처리할 수 있게 됐습니다.이 편에서는 그 타입들을 한데 모아 정리합니다.std::optional (C++17)값이 있을 수도 없을 수도 있는 타입입니다. null 포인터나 -1 같은 sentinel 값 대신 의도를 명확하게 표현합니다.#include // 반환 타입으로 — "찾으면 값, 없으면 nullopt"std::optional find_index(const std::vector& v, int target) { for (int i = 0; i 모나딕 연산 (C++23)// and_then — 값이..

1편에서 컨테이너를 정리했습니다. 2편에서는 알고리즘, 이터레이터, 람다, 그리고 C++17/20에서 추가된 유틸리티들을 다룹니다.알고리즘 — STL 알고리즘은 이터레이터 범위를 받아서 동작합니다. 컨테이너에 직접 묶이지 않아서 어떤 컨테이너에도 쓸 수 있습니다.#include #include 정렬std::vector v = {3, 1, 4, 1, 5, 9, 2};std::sort(v.begin(), v.end()); // 오름차순std::sort(v.begin(), v.end(), std::greater()); // 내림차순std::sort(v.begin(), v.end(), [](int a, int b) { // 커스텀 비교 ret..

C++를 쓰다 보면 표준 라이브러리(STL)를 얼마나 잘 아느냐에 따라 코드 품질이 꽤 달라집니다. 직접 자료구조를 구현하지 않아도 되고, 이미 최적화가 잘 된 구현을 그냥 쓰면 됩니다. 그런데 너무 그 header 종류가 방대해서 맨날 까먹고... 정리를 해야겠다고 마음을 먹었습니다.STL은 크게 컨테이너, 알고리즘, 이터레이터, 유틸리티로 나뉩니다. 1편에서는 컨테이너를 정리합니다.헤더 포함각 컨테이너는 해당 헤더를 포함해야 씁니다.#include #include #include #include #include #include #include #include #include #include #include vector동적 배열입니다. 가장 자주 쓰는 컨테이너입니다. 연속된 메모리에 저장돼서 캐시 효율..

1편에서 워크플로우 구조, 트리거, job과 step을 다뤘습니다. 2편에서는 빌드 속도를 높이는 캐싱, 여러 환경을 한 번에 테스트하는 Matrix, 워크플로우를 재사용하는 방법, 그리고 실전에서 자주 쓰는 패턴들을 정리합니다.캐싱 — actions/cache의존성 설치는 매번 하면 시간이 많이 걸립니다. 캐시를 써두면 key가 같으면 다운로드 없이 복원합니다.- name: 의존성 캐시 uses: actions/cache@v4 with: path: ~/.npm key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }} restore-keys: | ${{ runner.os }}-node-key가 완전히 일치하면 캐..

Git을 다루고, Docker로 컨테이너를 만들고, Shell Script로 배포 스크립트를 짜고 나면 자연스럽게 "이걸 push할 때마다 자동으로 실행할 수 없을까"라는 생각이 생깁니다. GitHub Actions가 그 역할을 합니다.코드를 push하면 테스트가 돌고, PR이 열리면 빌드가 되고, 태그를 달면 배포가 나가는 흐름을 yaml 파일 하나로 정의할 수 있습니다. 별도 CI 서버 없이 GitHub에 붙어서 바로 쓸 수 있다는 것도 장점입니다.1편에서는 Actions의 핵심 개념, 워크플로우 파일 구조, 트리거, job과 step을 정리합니다.핵심 개념Workflow — 자동화의 단위입니다. .github/workflows/ 디렉토리에 yaml 파일로 정의합니다. 파일 하나가 워크플로우 하나입니..

1편에서 CMakeLists.txt 기본 구조, 타겟 정의, 빌드 타입을 다뤘습니다. 2편에서는 프로젝트가 커졌을 때 쓰는 서브디렉토리 구조, 외부 라이브러리를 끌어오는 방법, 그리고 현장에서 자주 쓰는 패턴들을 정리합니다.서브디렉토리 구조프로젝트가 커지면 디렉토리를 나눠서 관리합니다. 각 디렉토리마다 CMakeLists.txt를 두고, 루트에서 add_subdirectory()로 불러오는 방식입니다.디렉토리 구조 예시MyProject/├── CMakeLists.txt # 루트├── src/│ ├── CMakeLists.txt│ ├── main.cpp│ └── parser.cpp├── lib/│ ├── CMakeLists.txt│ └── utils.cpp└── tests..

C나 C++ 프로젝트를 처음 시작하면 빌드 시스템 얘기가 빠지지 않습니다. 파일이 하나면 g++ main.cpp -o app으로 끝나는데, 파일이 여러 개로 늘어나고 외부 라이브러리가 붙기 시작하면 컴파일 명령어가 감당이 안 됩니다.CMake는 그 빌드 과정을 기술하는 도구입니다. 정확히는 빌드 시스템을 생성하는 도구인데, CMakeLists.txt에 프로젝트 구조와 의존성을 정의해두면 플랫폼에 맞는 빌드 파일(Makefile, Ninja 파일, Visual Studio 솔루션 등)을 만들어줍니다.1편에서는 CMake의 기본 개념, CMakeLists.txt 작성 방법, 빌드 타입과 옵션을 정리합니다.빌드 흐름CMake의 빌드는 두 단계로 나뉩니다.Configure → Build(cmake) ..

1편에서 세션, 윈도우, 패널 개념과 기본 단축키를 다뤘습니다. 2편에서는 ~/.tmux.conf 설정으로 tmux를 실제로 쓰기 편하게 만드는 방법을 정리합니다.기본 설정 그대로 쓰는 것도 가능하지만, prefix 키 하나만 바꿔도 체감이 크게 달라집니다. 설정을 조금씩 손대다 보면 자기 흐름에 맞는 환경이 만들어집니다.~/.tmux.conftmux 설정 파일입니다. 없으면 만들면 됩니다.touch ~/.tmux.conf설정 변경 후 tmux 안에서 바로 반영하려면 아래 명령어를 씁니다.# tmux 안에서prefix + ::source-file ~/.tmux.conf# 또는 터미널에서tmux source-file ~/.tmux.confprefix 키 변경Ctrl+b는 기본값인데, 손 위치 때문에 불편하..