12강. const 정확성: 읽기 전용 약속과 API 설계

?이번 강의에서 해결할 문제

읽기만 하는 함수가 비-const 참조를 요구하면 호출자는 불필요하게 수정 가능성을 열어야 합니다. 반대로 캐시처럼 관찰상 값이 같다는 이유로 아무 멤버나 mutable로 만들면 스레드 안전성과 불변식이 흐려집니다.

✓학습 목표

✓이 강의를 마치면

• const T, const T&, const T*, T* const를 구분합니다.
• const 멤버 함수가 객체의 논리 상태를 수정하지 않는 계약임을 설명합니다.
• const_cast와 과도한 mutable을 피하는 API를 만듭니다.

◇먼저 알아야 할 핵심 개념

const는 타입의 어느 부분을 읽기 전용으로 보는지에 따라 의미가 달라집니다. const Task*는 포인터로 대상 값을 수정할 수 없지만 다른 주소를 가리킬 수 있습니다. Task* const는 포인터 값은 바꿀 수 없지만 대상 수정은 가능합니다. const 멤버 함수는 this가 const 대상처럼 취급됩니다.

§왜 이 문제가 위험한가

const를 제거해 실제 const 객체를 수정하면 UB가 될 수 있습니다. 읽기 함수가 내부 상태를 임의로 바꾸면 같은 입력에서 결과가 달라지고 멀티스레드 읽기 안전성도 오해하게 됩니다. const는 보안 장치가 아니라 컴파일 가능한 사용 범위를 제한하는 계약입니다.

§가장 작은 예제로 시작하기

const_task.cpp

#include <iostream>
#include <string>
#include <utility>

class Task {
public:
    explicit Task(std::string name) : name_{std::move(name)} {}

    const std::string& name() const noexcept { return name_; }
    bool isCompleted() const noexcept { return completed_; }
    void complete() noexcept { completed_ = true; }

private:
    std::string name_;
    bool completed_{};
};

void printTask(const Task& task) {
    std::cout << task.name() << ':' << std::boolalpha
              << task.isCompleted() << '\n';
}

int main() {
    Task task{"build"};
    printTask(task);
    task.complete();
    printTask(task);
}

§코드 한 줄씩 이해하기

1. name()과 isCompleted()는 관찰 함수라 const 객체에서도 호출할 수 있습니다.
2. name()은 내부 문자열을 읽기 전용 참조로 돌려 불필요한 복사를 피합니다.
3. 반환 참조는 Task보다 오래 보관하면 안 됩니다.
4. complete()만 논리 상태를 수정하므로 비-const 멤버 함수입니다.
5. printTask는 읽기만 하므로 const Task&를 받습니다.

§실행 결과와 메모리·동작 흐름

첫 출력은 build:false, 완료 후는 build:true입니다. 관찰 함수는 상태를 바꾸지 않고 명령 함수만 불변식을 변경합니다. 반환된 이름 참조는 각 호출 표현식 안에서 즉시 사용됩니다.

✎단계별 실습

✎직접 실습

실습 목표

읽기와 변경 API를 const 계약으로 분리합니다.

시작 전 상태와 실행 방법

위 코드를 C++17로 빌드하고 const 멤버 함수의 끝 const를 하나씩 제거해 호출 가능 범위를 비교합니다.

1단계: 최소 코드 작성

name, isCompleted, complete를 구현하고 두 상태를 출력합니다.

2단계: 값 또는 조건을 바꿔 결과 비교

const Task view{"test"};를 만들고 읽기 함수는 호출되지만 complete()는 막히는지 확인합니다.

3단계: 작은 기능 확장

priority() const 관찰자와 raisePriority(int) 변경 함수를 추가하고 음수 입력을 거부합니다.

4단계: 스스로 해결하기

현재 클래스의 모든 멤버 함수를 query와 command로 분류하고 query에 const를 적용할 수 없는 이유가 있다면 기록합니다.

막혔을 때

• “discard qualifiers” 오류는 const 객체에서 비-const 함수를 호출했는지 확인합니다.
• 반환 참조가 지역 임시 문자열을 가리키지 않게 합니다.
• const_cast로 오류를 숨기지 말고 API 수정 책임을 다시 분리합니다.

!흔한 실수와 해결 방법

!자주 하는 실수

• getter에 const 누락: const 참조로 받은 객체에서 호출할 수 없습니다.
• const 참조 반환을 영구 보관: 소유 객체가 파괴되면 댕글링입니다.
• mutable로 설계 문제 숨김: 캐시도 동기화와 논리 const 기준을 문서화해야 합니다.

§언제 사용하고 언제 피할까

관찰 API와 읽기 전용 입력에는 const를 기본으로 사용합니다. 단순히 컴파일 오류를 우회하려고 const_cast를 사용하지 않습니다. 캐시는 외부 관찰 상태와 스레드 안전성을 검토한 제한적 경우에만 mutable을 고려합니다.

§게임 개발 연결

상태 조회와 상태 변경을 분리하면 업데이트 순서와 테스트가 명확해집니다. const만으로 멀티스레드 안전이 보장되지는 않지만 잘못된 수정 경로를 줄입니다.

?이해 점검 질문 3개

1. const Task*와 Task* const는 무엇을 바꿀 수 없나요?
2. const 멤버 함수가 논리 상태를 바꾸지 않는 계약이 테스트에 어떤 도움을 주나요?
3. const 참조 반환값을 소유 객체보다 오래 보관하면 왜 위험한가요?

■핵심 요약

■핵심 요약

const 정확성은 읽기와 변경 의도를 타입에 기록합니다. 호출자는 수정 가능성을 최소한으로 받고 컴파일러는 계약 위반을 더 일찍 찾습니다.

§다음 강의 연결

13강. 값·참조·포인터 전달에서 const와 소유권 기준에 성능 판단을 더합니다.