ONNX Runtime으로 시작하는 C++ 머신러닝

발표자: 박문식(이스트소프트 유틸리티 개발팀)

기존의 머신러닝 모델 개발 및 배포 환경

• 고성능 서버 머신
• Python
• GPU 가속 사용
• PyTorch, Tensorflow 등의 머신러닝 프레임워크

왜? 이렇게 정형화 되었는가?

• 예전에는 CPU를 사용
• 때문에 연산 처리에 한계가 존재
• GPU의 등장으로 상황이 변하게 됨
  • 간단한 연산들을 병렬적으로 계산
  • 쿠다가 없었을 때, 그래픽 API만 노출되었기 때문에 쉐이더로 계산함

현재 하나의 패러다임이 추가됨

• (ML Model) Interface at the edge
• 기술이 발전함에 따라 머신러닝 모델들의 연산 요구량은 낮아졌고 정확도는 증가됨
• 엣지 디바이스의 연산 능력 향상, 전력 낮아짐
• 엣지 디바이스에서 모델을 돌리면 응답 속도, 보안성 강화
• 때문에 고성능 서버에서만 돌아가는 시절은 아니다. 클라이언트에서도 사용할 수 있게 됨

** 엣지 디바이스 특성**

• 우리가 관리하는 디바이스가 아니기 때문에 호환성 문제가 발생
  • CPU, GPU, 메모리 속도와 용량 등을 다 따져봐야 함
  • 휴대용 엣지 디바이스의 경우, 배터리 문제가 추가됨
  • 결국 연산 요구량이 적은 머신러닝 모델을 돌려야함

C++ 머신러닝 플랫폼

• libtorch
  • PyTorch 모델만 돌릴 수 있음
  • 바이너리 사이즈가 큼
  • 실제 모델에서 사용하기에는 아직 무리
• ggml
  • OpenAI Whisper(Speech to Text) -> whisper.cpp
  • Meta LLaMA -> llam.cpp
  • CPU에서 잘 돌아갈 수 있음(단, GPU만큼의 성능이 나온다고 볼 수 없음)
  • 유명 모델만 최적화가 들어가기 때문에 개발자가 추가적으로 최적화를 해야함

ONNX(Open Neural Network Excange)

• ONNX
  • MS에서 만듬
  • .NET과 Java와 같이 중간 언어라는 개념을 도입해서 만든 머신러닝 모델을 표준화하기 위해 제안된 규격
  • MS에서 만들었기 때문에 Windows 지원이 뛰어남
  • iOS, macOS, Linux, Android, Web도 지원
  • 많은 하드웨어 가속을 지원
  • 오픈 소스
• 특징
  • 플랫폼에 종속적이지 않음
  • 환경에 종속적이지 않아 ONNX Runtime이 지원하는 모든 환경에서 ONNX로 만들어진 모델을 돌릴 수 있음
  • 런타임 바이너리 크기가 작음 = 쉽게 배포 가능
  • 특정 연산에 대해 특정 환경에서 제공하는 다양한 최적화 모델 수정 없이 활용할 수 있음

실습

• github: microsoft/onnxruntime
• MNIST: ONNX에서 사용되는 머신러닝 필수 구조체
• tensor: ML에서 사용되는 추상화된? 행렬

QnA

Q1. 디바이스의 CPU에서만 돌아가는 것을 전제로 깔았는가?

A1. GPU는 환경 문제가 크기 때문에 CPU를 전제로 깔았다.

Q2. PyTorch, Tensorflow를 ONXX로 변경하기 위해서 따로 공부해야 하는가?

A2. ONNX에서 ONNX로 변경하는 기능을 제공하므로 굳이 공부할 필요는 없다. 
단, ONNX에서 아직 제공하지 못하는 일부 기능들이 있기 때문에 완벽하게 변경된다고 확신할 수 없다.

D3D12 Mesh Shader 소개

발표자: 유영천

프로젝트의 운명을 좌우하는 레서기 코드

발표자: 정민우

DBMS의 특징

• 매우 긴 소프트웨어의 수명
• 많은 개발자들이 참여
• 많은 개발자들이 퇴사...
• 고객사들의 변화에 매우 민감
• 회사의 지출 대부분이 유지 보수

레거시 코드란?

• 테스트 코드가 없는 코드
• 바꾸기 힘든 코드
• 정체를 알아볼 수 없는 코드

• 함부로 건들이지 못함

레거시 코드 Naming Issues

• 예시
  • 무책임한 이름
  • 약어의 남용
    • MInfo
    • 이름만으로는 어떤 역할인지 알 수가 없음...
    • 정답은 메인 정보를 담는 변수
  • 너무 일반적인 이름
    • 너무 범용적인 이름이라면 오히려 정확히 어떤 역할을 하는지 알 수 없음
    • 서로 구분하기 힘든 이름
      • 암시적인 규칙에 의한 함수 이름과 비슷한 작동을 하는 이름의 함수
• 좋지 않은 이름의 피해
  • 코드 구성 요소간의 역할 구분이 어려움
  • 코드를 이해하는 시간 증가
• 해결책
  • 이름 짓는 것에 조금 더 성의 있게...
  • 동료와 충분한 커뮤니케이션
    • 성의 있는 커밋 메시지
    • 코드 리뷰 시간
    • 문서화

함수

• 예시
  • 너무 많은 파라미터
    • 비슷한 동작을 하는 A, B 상황
    • 플래그를 이용해서 분기 적용
  • 전역 변수 사용
    • 유지.보수에서 최악
    • 함수 재사용이 까다로움
    • 함수를 바꾸기 어려워짐
    • 디버깅이 힘들어짐
    • 컴파일 시간 증가
• 해결책
  • 너무 많은 파라미터
  • 흠..
  • 당장의 쉬운 구현은 절대 정답이 아님
  • 이해하기 쉬운 함수를 작성했는지 항상 생각해야 함
  • 테스트 코드
  • 코드 리뷰 시간

지식의 중복

• 지식의 중복: 하나의 변수를 변경했을 때, 다른 변수까지 변경해야하는 것
• 왜 문제인가?
  • 문제 발생시, 디버깅이 너무 어려워짐
  • 여러 데이터간 정합성이 맞지 않아 에러...
• 해결책
  • Attribute를 Getter로 대체
• 교훈
  • 데이터 간 지식의 중복은 무조건 잊혀지기 마련
  • 지식의 중복은 반드시 피하거나 감춰야 함

직접 겪은 레거시 코드...

• 막대한 레거시 코드
• 고객사가 증가할 수록 유지.보수 비용 증가
• 95% 이상의 종사자들의 업무가 유지.보수
• 발전이 정체된 소프트웨어
• 업무 만족도 저하 -> 잦은 퇴사 -> 기존의 직원 업무 질 저하 -> 반복

해결책

• 바꾸기 쉬운 코드인지 항상 생각하자
• 좋은 개발 문화
  • 테스트 코드
  • 코드 리뷰
  • 문서화
  • 활발한 커뮤니케이션
• 주기적인 리팩토링
  • 기업 입장에서는 돈이 되지 않지만 유지.보수에는 매우 좋음

QnA

Q1. 가장 길었던 함수나 파일

A1. gdd를 많이 사용, 만줄이 넘어가는 파일 존재, 조금만 만져도 컴파일 시간이 너무 늘어난다.

Q2.
* 패키지 형태로 오랫동안 유지.보수하는 회사가 적은거 같다.
* 함수명, 변수명을 잘했으면 좋겠다고 생각을하지만 그러면 이름이 너무 길어진다.
* 문서화하는 것은 좋다 하지만, 현실의 괴리감이 자주 발생하게 된다(코드와 문서와 동기화 안됨).

A2-1.
* 너무 긴 것도 않좋다고 생각한다. 그래서 코드 리뷰를 통해 적절한 이름을 찾는 것도 한 방법이라 생각한다
* 모든 코드의 문서화 보단 핵심 부분(약어 규칙, 명명 규칙 등)을 정해, 다른 문서가 필요 없게...

A2-2. 다른 분의 답변
* 변수/함수명이 길어졌다면 코드 리팩토링을 해야 할 신호라고 생각
* 주석, 커밋 메시지를 현재와 미래의 팀원 뿐만 아니라 미래의 내가 봤을 때도 알아 볼 수 있게 작성해야 한다(경험담...).

Q3. 특별한 개발 문호가 존재하는가?

A3. 특출난 것은 없고 코드 리뷰 시간을 최대한 갖으려고 한다. 하지만 윗 분들은 잘 이해하지 못해서 아쉽다. 
책은 이상적이지만 그래도 배울 것이 많기 때문에 많이 읽어보려고 한다.

Q4. 우리 회사 같은 경우, Wrapping을 하고 구분이 더 힘들어 졌다.

A1. 제대로 못들음...

Q5. 코드 리뷰, 현업이 궁금하다. 참석자 모두가 리뷰하는가? 또는 몇 명만 하는가?

A5. 코드에 따라 다르다. 간단한 것은 몇 명만 집중적으로, 핵심적인 코드는 참석자 모두가 인지해야하기 때문에 모두 참여한다.
우리는 코드 리뷰 시간을 따로 할당해서 정식적으로 부정적인 생각 없이 참여하게 만들었다.

본 글은 std::weak_ptr의 소개와 간단한 사용법을 중심으로 설명합니다.

std::weak_ptr 클래스가 갖는 멤버 변수나 함수에 대한 자세한 내용은 시간이 되면 나중에 작성하겠습니다.

설명

std::weak_ptr란?

std::weak_ptr는 std::shared_ptr에 의해 관리되는 자원 객체를 공유하지만 소유하지 않는 (std::shared_ptr의 약점(순환 참조)를 보강해주는)스마트 포인터입니다. 자원 객체를 소유하지 않기 때문에 std::shared_ptr로 관리되는 자원 객체를 가리켜도 참조 개수에 영향을 미치지 않습니다(대신 약한 개수(weak count)에 영향을 미칩니다).

std::weak_ptr는 이름처럼 "약한" 포인터(자원 객체와의 관계가)이기 때문에 std::unique_ptr나 std::shared_ptr처럼 자체적으로 포인터로서의 역할을 수행할 수 없습니다.

또한 std::unique_ptr나 std::shared_ptr는 자신이 자원 객체를 관리하기 때문에 자원 객체가 살아있는지, 소멸했는지 알 수 있지만 std::weak_ptr는 자원 객체를 가리킬 뿐, 관리하지 않기 때문에 자신이 가리킨 자원 객체가 살아있는지 소멸했는지 알 수 없습니다. 하지만 std::weak_ptr는 std::shared_ptr와 같은 구조(자원 객체 + 제어 블록)이기 때문에 제어 블록을 통해 자원 객체가 살아있는지 소멸했는지 판단할 수 있습니다.

사용법

std::weak_ptr를 사용하기 위해선 <memory> 헤더를 포함해야 합니다.

생성자를 이용한 생성 및 초기화

std::waek_ptr는 위에서 언급했듯이 std::shared_ptr가 관리하는 자원 객체를 가리킵니다. 즉, 생성자, 복사 연산자, 복사 배정 연산자의 인자로 포인터 객체(std::shared_ptr, std::weak_ptr)를 넘겨주면 됩니다.

#include <iostream>
#include <memory>

class Person
{
private:
    std::string m_name;
    int m_age;

public:
    Person(std::string name, int age) : m_name(name), m_age(age)
    {
        std::cout << "생성자 호출" << std::endl;
    }

    ~Person()
    {
        std::cout << "소멸자 호출" << std::endl;
    }
};


int main()
{
    std::shared_ptr<Person> sPtr = std::make_shared<Person>("whale", 10);
    std::weak_ptr<Person> wPtr1(sPtr);
    std::weak_ptr<Person> wPtr2 = wPtr1;
    std::weak_ptr<Person> wPtr3;
    wPtr3 = wPtr2;

    std::cout << "sPtr 참조 개수: " << sPtr.use_count() << std::endl;
    std::cout << "wPtr1 참조 개수: " << wPtr1.use_count() << std::endl;
    std::cout << "wPtr2 참조 개수: " << wPtr2.use_count() << std::endl;
    std::cout << "wPtr3 참조 개수: " << wPtr3.use_count() << std::endl;
}

[출력 결과]

생성자 호출
sPtr 참조 개수: 1
wPtr1 참조 개수: 1
wPtr2 참조 개수: 1
wPtr3 참조 개수: 1
소멸자 호출

std::weak_ptr는 std::shared_ptr와 동일한 멤버 함수인 use_count를 갖고 있습니다. std::weak_ptr는 약한 개수에 관여하기 때문에 약한 개수의 수를 반환할 것 같지만 std::shared_ptr와 동일하게 참조 개수를 반환합니다.

std::weak_ptr가 가리키는 자원 객체 사용하기

std::weak_ptr는 자원 객체를 가리킬 뿐, 역참조를 할 수 없습니다. 때문에 포인터 객체를 std::shared_ptr로 업그레이드해서 사용해야 합니다. 하지만 그 전에 반드시 현재 가리키고 있는 자원 객체가 소멸되었는지 확인해야 합니다.

이를 위한 멤버 함수 expired가 존재하지만 원자적으로 연산되지 않기 때문에 멀티 쓰레드 환경에서 잘못 사용할 경우 미정의 행동이 발생할 수 있습니다.

이런 문제를 해결할 수 있는 것이 lock 멤버 함수입니다 lock 멤버 함수는 원자적으로 연산되며 std::weak_ptr가 가리키는 자원 객체가 소멸했다면 아무 것도 가리키지 않는 std::shared_ptr를 반환하지만 존재한다면 std::weak_ptr와 동일한 자원 객체를 가리키는 std::shared_ptr를 반환합니다.

#include <iostream>
#include <memory>

class Person
{
private:
    std::string m_name;
    int m_age;
    std::weak_ptr<Person> m_wPtrFirend;

public:
    Person(std::string name, int age) : m_name(name), m_age(age)
    {
        std::cout << "생성자 호출" << std::endl;
    }

    ~Person()
    {
        std::cout << "소멸자 호출" << std::endl;
    }

    void SetFirend(std::shared_ptr<Person>& sPtrFirend) { m_wPtrFirend = sPtrFirend; }

    const std::string GetName() { return m_name; }
    const int GetAge() { return m_age; }
    const std::weak_ptr<Person>& GetFirend() { return m_wPtrFirend; }

    void ResetFirend()
    {
        m_wPtrFirend.reset();
    }

    void AccessFirend()
    {
        auto sPtrFirend = m_wPtrFirend.lock();

        if (sPtrFirend)
        {
            std::cout << "접근 성공, firend 정보 { " << sPtrFirend->GetName() << ", " << sPtrFirend->GetAge() << " }";
        }
        else
        {
            std::cout << "접근 실패(참조한 객체가 소멸됨)" << '\n';
        }
    }
};

int main()
{
    std::shared_ptr<Person> sPtrWhale = std::make_shared<Person>("whale", 10);
    std::shared_ptr<Person> sPtrPark18 = std::make_shared<Person>("park18", 20);

    sPtrWhale->SetFirend(sPtrPark18);
    sPtrPark18->SetFirend(sPtrWhale);

    std::cout << "sPtrWhale 참조 개수: " << sPtrWhale.use_count() << '\n'
              << "sPtrPark18 참조 개수: " << sPtrPark18.use_count() << '\n';

    std::cout << std::boolalpha << "sPtrWhale의 firend 만료: " << sPtrWhale->GetFirend().expired() << '\n'
                                << "sPtrPark18의 firend 만료: " << sPtrPark18->GetFirend().expired() << '\n';

    sPtrWhale->AccessFirend();
    sPtrWhale.reset();

    sPtrPark18->AccessFirend();
}

[출력 결과]

생성자 호출
생성자 호출
sPtrWhale 참조 개수: 1
sPtrPark18 참조 개수: 1
sPtrWhale의 firend 만료: false
sPtrPark18의 firend 만료: false
접근 성공, firend 정보 { park18, 20 }소멸자 호출
접근 실패(참조한 객체가 소멸됨)
소멸자 호출

참고

cppreference - en

VisualC++ Docs

TCP School

모두의 코드

식빵맘(ansohxxn)

ozt88

Effective Modern C++

D3D Tiled Resources를 이용한 텍스처 스트리밍

발표자: 유영천

• 맵의 텍스처링 방법

  • 넓은 맵의 베이스 텍스처를 사용 -> 타일처럼 패턴이 보이게 됨.

• 거대 텍스처 맵핑의 특성

  • 언제나 텍스처의 모든 영역이 한 번에 보여지는 것이 아님.
  • 가까운 곳은 높은 해상도, 멀 수록 낮은 해상도

• 가상 텍스처링

  • 가상 메모리..?
  • DX11 이상부터 지원
  • GPU에서 가상 메모리는 OS에서 관리하지 않기 때문에 프로그래머가 관리해야 함.
  • 민맵?
  • Packed Mip
  • Tiled Pool
    • 페이지 관리
    • 프로그래머의 몫
      • 예) 인덱스 발급기 이용(맵핑)
      • 삭제 됐을 때, 메모리에 이가 빠지게 됨(배열).
      • 이가 빠진 곳을 활용하지 않으면 메모리 낭비 -> 효율적으로 관리하기 위해 인덱스로 관리

• File로 부터 읽어 이미지 데이터 로드

  • 파일 헤더를 읽어 위치 확인
  • 필요할 때, 헤더를 이용해 참조

• GPU 프로그래밍의 경우 로직에 따라 성능의 차이가 심함.

C++을 버린 유저가 이야기 하는 C++가 지향해야 하는 모습은?

발표자: 김두훈

• 왜 C++는 어려운가?

  • 너무 자유롭다 == 너무 높은 난이도
    • 템플릿
    • 컴파일러 설정
    • 코루틴

• 따라가기 힘든 표준

  • Peprecated, Feature가 추가되는게 너무 극단적으로 많음
    • 시간이 지날 수록 추가되는 양이 많아짐...

• 극악의 방대함, 더딘 지원

  • 지속적인 발전으로 기능은 방대해졌지만 컴파일러 지원이 늦음

• 그래서 지향해야 하는 것은?

  1. 퍼포먼스와 엄밀함 보다는 "사용성

     • 패키지에 대한 에코-시스템
       • vcpkg
       • conan

  2. 사용자 친화적

     • 이제 하위 호환성을 놓아줄 때가 됐다(이미 망한거 같으니...).
     • 한국에서 C++ 커뮤니티가 부족함.

클래스를 쓰지 않고 게임 개발하기 (ECS를 통한 게임 개발)

발표자: 옥찬호(@utilForever)

• ECS(Entity Component System)

  • 상태와 기능을 분리

  • 구성 요소

    • Entity(포인터)
      • 컴포넌트를 담아두는 곳
      • 행동(기능)이나 데이터 X
      • 어떤 데이터가 있는지 식별
    • Component(실제 데이터)
      • 실제 데이터를 저장하는 곳
      • 단순 태그, 값을 저장하는 컨테이너, 무언가를 참조하는 컨테이너 등
    • System
      • 컴포넌트의 데이터를 현재 상태에서 다음 상태로 변환하는 논리
      • 전체 인티티 중 특정 컴포넌트를 가리키는 엔티티만 필터링한 다음, 컴포넌트와 관련해 필요한 동작 수행
        • 데이터 변경
        • 새로운 컴포넌트 추가
        • 기존 컨테이너 삭제
    • 왜 사용하는가?
      • 객체지향에 비해 성능이 뛰어나다.
      • 데이터 지향 디자인
      • 지역성(Locality) 개념
        • 캐시가 효율적으로 동작하려면, 캐시에 저장할 데이터가 지역성을 가져야 함.
        • 지역성이란 데이터 접근이 시간적, 공간적으로 가깝게 일어나는 것.
        • 공간 지약성
          • 특정 데이터와 가까운 주소가 순서대로 접근되었을 경우 공간적 지역성이라고 한다.
        • 객체지향의 경우 이 공간 지약성이 떨어진다.

  • ECS 라이브러리

    • C++
      • entt
        • 마인크래프트 및 마인크래프트 어스에서 사용
      • entityX
      • Ffles

• 데모

  • 2021-CoMu-ECS-Development
  • 엔티티에서는 컴포넌트가 어떤 것인지 구별할 수 없기 때문에 태그 컴포넌트를 이용해 탐색용으로 사용함

• 정리

  • ECS는 데이터 지향 디자인을 통해 특정

커뮤니티의 어제와 오늘

발표자: 방기연(@giyeonbang)

Roku Korea 소개 및 C++ in Roku Korea (Server)

발표자: C++ in Roku Korea(Roku) 영상 링크: C++ Korea Youtube

Roku Korea 소개 및 C++ in Roku Korea (Client)

발표자: C++ in Roku Korea(Roku) 영상 링크: C++ Korea Youtube

CUDA Raytracing을 이용한 복셀오브젝트 가시성 검사

발표자: 유영천 영상 링크: C++ Korea Youtube

Objective-C Runtime을 사용해서 C++와 Swift 상호호출하기

발표자: 박동하 영상 링크: C++ Korea Youtube

Windows App SDK, WinUI 3 해봤습니다

발표자: 박동하 영상 링크: C++ Korea Youtube

vcpkg를 활용한 임베디드 어플리케이션 개발기

발표자: 정은식 영상 링크: C++ Korea Youtube

Struct vs Tuple 성능비교

발표자: 유양석 영상 링크: C++ Korea Youtube

SIMD 활용기

발표자: 정승호 영상 링크: C++ Korea Youtube

길고양이 이야기2

더 램지

리프트 스위퍼

리플 이펙트

스키드

이라

ChronoSword

Project BS

• 1인 인디 개발
• 소울라이크 장르
• 개발 기간 약 1년

본 글은 std::shared_ptr의 소개와 간단한 사용법을 중심으로 설명합니다.

std::shared_ptr 클래스가 갖는 멤버 변수나 함수에 대한 자세한 내용은 시간이 되면 나중에 작성하겠습니다.

설명

std::shared_ptr란?

std::shared_ptr는 std::unique_ptr와 달리 자원 객체에 대한 공유 소유권(shared ownership) 의미론을 체현한 스마트 포인터입니다. shared_ptr는 하나의 자원 객체를 여러 포인터 객체가 가리킬 수 있으며 모든 포인터 객체가 자원 객체를 필요하지 않을 때 자원 객체를 해제하도록 설계되어 있습니다.

하지만 어느 시점에 모든 포인터 객체가 자원 객체를 필요하지 않은지 알 수 없습니다. std::shared_ptr는 자원 객체를 가리키는 포인터 객체의 수를 참조 개수(reference count)라 명명하고 관리합니다. 참조 개수는 생성자가 호출되면 증가, 소멸자가 호출되면 감소 그리고 복사 배정 연산자가 호출되면 증가와 감소 모두를 수행합니다.

이러한 참조 개수 관리는 성능에 많은 영향을 미치게 됩니다.

• std::shared_ptr의 크기는 생 포인터의 두 배이다.
  자원 객체를 가리키는 생 포인터 뿐만 아니라 참조 개수를 가리키는 생 포인터도 저장해야 하기 때문에 생 포인터의 두 배의 크기를 가지게 됩니다.

• 참조 개수를 담는 메모리는 반드시 동적으로 할당해야 한다.
  개념적으로 참조 개수는 포인터 객체가 현재 자원 객체를 가리키는 포인터 객체의 수를 알기 위한 것이기 때문에 자원 객체가 현재 참조 개수를 담을 공간을 따로 마련하지 않습니다. 즉, 참조 개수는 std::shared_ptr가 관리해야 하며 정적 메모리로는 불가능하기 때문에 결국 동적 메모리를 이용해야 합니다. 만약 정적 메모리를 사용하면 참조 개수를 갱신하기 위해 같은 자원 객체를 가리키고 있는 모든 포인터 객체를 알아야합니다 즉, 참조 개수와 같은 자원 객체를 가리키는 모든 포인터 객체의 정보를 담은 공간이 필요하게 되므로 차라리 동적 메모리에 참조 개수를 저장해 같은 자원 객체를 가리키는 포인터 객체들이 접근하는 것이 이상적입니다.

• 참조 횟수의 증가와 감소가 반드시 원자적 연산이어야 한다.
  여러 스레드가 참조 개수에 동시 읽고 쓰려고 한다면 데이터 레이스가 발생할 수 있습니다. 이를 방지하기 위해 참조 개수는 원자적으로 연산됩니다. 그러다보니 비원자적 연산보다 느릴 수 밖에 없습니다.

std::shared_ptr는 std::unique_ptr과 다르게 오직 개별 객체(std::shared_ptr<T>)만을 지원합니다. 'std::shared_ptr<T>로 가리키되, 커스텀 삭제자로 배열 해제(delete[])하면 되지 않나?' 생각할 수 있지만 std::shared_ptr에서 operator[]를 제공하지 않기 때문만 아니라 설계 밖의 일이기 때문에 시스템에 구멍이 생기게 됩니다.

Control Block

std::shared_ptr는 생 포인터의 두 배의 크기이고 그 중 하나는 참조 개수를 저장하기 위한 것이라 설명했습니다. 정확히 설명하자면 참조 개수는 제어 블록(Control Block)이라 불리는 더 큰 자료구조에 저장되는 하나의 목록이고 std::shared_ptr는 이 제어 블록을 가리킵니다. 이 제어 목록에는 참조 개수뿐만 아니라 커스텀 삭제자, 약한 개수(weak count) 등이 저장됩니다. 이러한 구현 방법이 제일 이상적이라 생각됩니다. 만약 각 항목마다 별도로 관리하게 된다면 std::shared_ptr의 크기는 계속 커지기만 할 것입니다. 하지만 제어 블록에서 모두 관리하기 때문에 std::unique_ptr처럼 커스텀 삭제자를 지정해도 std::shared_ptr의 크기가 변하지 않습니다.

사용법

std::shared_ptr를 사용하기 위해선 <memory> 헤더를 포함해야 합니다.

생성자를 이용한 생성 및 초기화

• 자원 객체 초기화
• 소멸자 초기화

#include <iostream>
#include <memory>

class Person
{
private:
    std::string mName;
    int mAge;

public:
    Person(std::string name, int age) : mName(name), mAge(age)
    {
        std::cout << "생성자 호출" << std::endl;
    }

    ~Person()
    {
        std::cout << "소멸자 호출" << std::endl;
    }

    void doSomething()
    {
        // ...
    }
};

int main()
{
    std::shared_ptr<Person> sPtr1(new Person("whale", 10));
    std::shared_ptr<Person> sPtr2(sPtr1);
    std::shared_ptr<Person> sPtr3 = sPtr2;

    (*sPtr1).doSomething();
    sPtr2->doSomething();

    std::cout << "sPtr1 참조 개수: " << sPtr1.use_count() << std::endl;
    std::cout << "sPtr2 참조 개수: " << sPtr2.use_count() << std::endl;
    std::cout << "sPtr3 참조 개수: " << sPtr3.use_count() << std::endl;
}

[출력 결과]

생성자 호출
sPtr1 참조 개수: 3
sPtr2 참조 개수: 3
sPtr3 참조 개수: 3
소멸자 호출

std::shared_ptr도 std::unique_ptr처럼 생 포인터와 동일하게 사용할 수 있게 설계되어 있어 생 포인터처럼 사용하면 됩니다.

std::shared_ptr도 기본적으로 delete를 통해서 자원 객체를 해제하지만, 커스텀 삭제자를 설정할 수 있습니다. 하지만 커스텀 삭제자를 지원하는 구체적인 방식은 std::unique_ptr과 다릅니다. std::unique_ptr는 커스텀 삭제자를 템플릿의 두 번째 형으로 설정하고 생성자의 두 번째 인자로 전달해야 했지만 std::shared_ptr에서는 생성자의 두 번째 인자로 전달하기만 하면 됩니다.

#include <iostream>
#include <memory>

class Person
{
private:
    std::string mName;
    int mAge;

public:
    Person(std::string name, int age) : mName(name), mAge(age)
    {
        std::cout << "생성자 호출" << std::endl;
    }

    ~Person()
    {
        std::cout << "소멸자 호출" << std::endl;
    }
};

void FuncDeleter(Person* pPerson)
{
    std::cout << "함수 커스텀 소멸자 호출" << std::endl;

    delete pPerson;
}

int main()
{
    auto lambdaDeleter = [](Person* pPerson) {
        std::cout << "람다 커스텀 삭제자 호출" << std::endl;

        delete pPerson;
        };

    std::shared_ptr<Person> sPtr1(new Person("whale", 10), lambdaDeleter);
    std::shared_ptr<Person> sPtr2(new Person("park18", 10), FuncDeleter);
}

[출력 결과]

생성자 호출
생성자 호출
함수 커스텀 소멸자 호출
소멸자 호출
람다 커스텀 삭제자 호출
소멸자 호출

std::make_shared를 사용한 생성 및 초기화

std::shared_ptr도 std::unique_ptr과 동일한 이유로 생성자(정확히는 생 포인터를 넘겨 받는 생성자)를 이용한 초기화 방법을 권장하지 않습니다. std::shared_ptr는 생 포인터를 인자로 넘겨 받는다면 첫 번째 생성으로 판단하고 제어 블록을 생성합니다. 즉, 서로 다른 포인터 객체의 생성자가 같은 자원 객체를 가리키는 생 포인터를 넘겨받는다면 서로 다른 제어 블록을 갖게 되는 문제가 발생하게 됩니다.

두 포인터 객체가 같은 자원 객체를 가리키지만 서로 다른 제어 블록을 갖게 된다면 두 포인터 객체 중 한 포인터 객체의 참조 개수가 0이 되어 남은 포인터 객체가 아직 자원 객체를 가리키고 있음에도 불구하고 자원 객체를 해제시켜 버립니다.

만약 운 좋게 남은 포인터 객체에서 자원 객체를 참조하지 않았어도 결국 포인터 객체의 참조 개수가 0이 되어 이미 해제된 자원 객체를 다시 해제시켜 오류를 발생시키게 됩니다.

#include <iostream>
#include <memory>

class Person
{
private:
    std::string mName;
    int mAge;

public:
    Person(std::string name, int age) : mName(name), mAge(age)
    {
        std::cout << "생성자 호출" << std::endl;
    }

    ~Person()
    {
        std::cout << "소멸자 호출" << std::endl;
    }
};

int main()
{
    auto ptrPerson = new Person("whale", 10);

    std::shared_ptr<Person> sPtr1(ptrPerson);
    std::shared_ptr<Person> sPtr2(ptrPerson);

    std::cout << "sPtr1 참조 개수: " << sPtr1.use_count() << std::endl; 
    std::cout << "sPtr2 참조 개수: " << sPtr2.use_count() << std::endl; 
}

[출력 결과]

생성자 호출
sPtr1 참조 개수: 1
sPtr2 참조 개수: 1
소멸자 호출
소멸자 호출

<런타임 오류 발생>

이 같은 상황을 피하기 위해 포인터를 인자로 넘겨받는 생성자 초기화 방식을 지양하고 std::make_shared 함수의 사용을 지향해 안전하게 포인터 객체를 생성해야 합니다. 한 가지 주의점이 있는데 std::make_shared 함수는 항상 제어 블록을 생성하기 때문에 처음 포인터 객체를 생성하는 경우에만 사용해야 합니다.

std::make_shared 함수는 이 같은 상황을 예견?했던 것인지 모르겠지만 C++11부터 지원했습니다.

#include <iostream>
#include <memory>

class Person
{
private:
    std::string mName;
    int mAge;

public:
    Person(std::string name, int age) : mName(name), mAge(age)
    {
        std::cout << "생성자 호출" << std::endl;
    }

    ~Person()
    {
        std::cout << "소멸자 호출" << std::endl;
    }

    void DoSomething()
    {
        // ...
    }
};

int main()
{
    std::shared_ptr<Person> sPtr = std::make_shared<Person>("whale", 10);
    sPtr->DoSomething();
}

하지만 std::make_shared 함수 또한 std::make_unique 함수처럼 커스텀 삭제자를 지정할 수 없다는 단점이 존재합니다.

주의점

자기 자신을 가리키는 경우

프로그램을 개발하다보면 객체 내부에서 자기 자신을 가리키는 포인터 객체를 만들어야 하는 상황이 발생하기도 앖니다. 자기 자신을 가리키기 위해 std::shared_ptr의 생성자에 this를 전달하게 된다면 다음과 같은 상황이 발생합니다.

#include <iostream>
#include <memory>

class Person
{
private:
    std::string mName;
    int mAge;

public:
    Person(std::string name, int age) : mName(name), mAge(age)
    {
        std::cout << "생성자 호출" << std::endl;
    }

    ~Person()
    {
        std::cout << "소멸자 호출" << std::endl;
    }

    std::shared_ptr<Person> GetSelf() 
    {
        return std::shared_ptr<Person>(this);
    }
};

int main()
{
    std::shared_ptr<Person> sPtr1 = std::make_shared<Person>("whale", 10);
    std::shared_ptr<Person> sPtr2 = sPtr1->GetSelf();

    std::cout << "sPtr1 참조 개수: " << sPtr1.use_count() << std::endl;
    std::cout << "sPtr2 참조 개수: " << sPtr2.use_count() << std::endl;
}

[출력 결과]

생성자 호출
sPtr1 참조 개수: 1
sPtr2 참조 개수: 1
소멸자 호출

<런타임 오류 발생>

this 키워드 역시 생 포인터를 전달하는 것이기 때문에 두 포인터 객체는 서로 다른 제어 블록을 가지게 되면서 미정의 행위를 발생시키게 됩니다(예제에서는 간단하게 설명하기 위해 자신을 가리키는 포인터 객체를 생성해 반환했지만 벡터에 자신을 가리키는 포인터를 넣는 등의 상황도 있습니다).

이 문제는 std::enable_shared_from_this라는 기반 클래스 템플릿을 상속 받고 자신을 가리키는 포인터 객체를 생성해 반환하는 대신 shared_from_this 멤버 함수를 반환하는 것으로 간단하게 해결할 수있습니다.

한 가지 중요한 점은 shared_from_this 멤버 함수가 제대로 작동하기 위해선 해당 객체를 가리키고 있는 포인터 객체를 반드시 먼저 정의해야 한다는 것입니다. 왜냐하면 shared_from_this 멤버 함수는 해당 객체를 가리키고 있는 제어 블록을 확인할 뿐, 제어 블록을 생성하지 않기 때문입니다.

#include <iostream>
#include <memory>

class Person : public std::enable_shared_from_this<Person>
{
private:
    std::string mName;
    int mAge;

public:
    Person(std::string name, int age) : mName(name), mAge(age)
    {
        std::cout << "생성자 호출" << std::endl;
    }

    ~Person()
    {
        std::cout << "소멸자 호출" << std::endl;
    }

    std::shared_ptr<Person> GetSelf() 
    {
        return shared_from_this();
    }
};

int main()
{
    std::shared_ptr<Person> sPtr1 = std::make_shared<Person>("whale", 10);
    std::shared_ptr<Person> sPtr2 = sPtr1->GetSelf();

    std::cout << "sPtr1 참조 개수: " << sPtr1.use_count() << std::endl;
    std::cout << "sPtr2 참조 개수: " << sPtr2.use_count() << std::endl;
}

[출력 결과]

생성자 호출
sPtr1 참조 개수: 2
sPtr2 참조 개수: 2
소멸자 호출

순환 참조

std::shared_ptr은 참조 개수가 0이 되어야 자원을 해제할 수 있습니다. 하지만 객체를 더 이상 사용하지 않음에도 불구하고 참조 개수가 0으로 떨어지지 않는 상황이 존재합니다.

포인터 객체 sPtr1과 sPtr2가 있을 때, 자원 객체의 내부에서 서로를 가리키는 포인터 객체가 있다면 서로를 가리키는 포인터 객체 때문에 참조 개수가 0으로 떨어지지않아 포인터 객체가 소멸되지 않는 상황으로 이런 구조를 순환 구조라고 합니다.

#include <iostream>
#include <memory>

class Person : public std::enable_shared_from_this<Person>
{
private:
    std::string mName;
    int mAge;

    std::shared_ptr<Person> mSPtrFriend;

public:
    Person(std::string name, int age) : mName(name), mAge(age)
    {
        std::cout << "생성자 호출" << std::endl;
    }

    ~Person()
    {
        std::cout << "소멸자 호출" << std::endl;
    }

    std::shared_ptr<Person> GetSelf() 
    {
        return shared_from_this();
    }

    void SetFriend(std::shared_ptr<Person>& sPtrFriend)
    {
        mSPtrFriend = sPtrFriend;
    }
};

int main()
{
    std::shared_ptr<Person> sPtrPerson1 = std::make_shared<Person>("whale", 10);
    std::shared_ptr<Person> sPtrPerson2 = std::make_shared<Person>("park18", 20);

    sPtrPerson1->SetFriend(sPtrPerson2);
    sPtrPerson2->SetFriend(sPtrPerson1);
}

[출력 결과]

생성자 호출
생성자 호출

출력 결과를 보면 서로 파괴할 수 없는 상태가 되어 소멸자가 호출되지 않는 것을 확인할 수 있습니다.

이 문제는 std::shared_ptr의 설계 한계에 의한 문제이기 때문에 std::shared_ptr을 통해서 이 문제를 해결할 수는 없습니다. 대신 이 문제를 해결하기 위해 설계된 것이 std::weak_ptr입니다.

다음에는 std::weak_ptr에 대해 알아보겠습니다.

참조

cppreference - en

cppreference - ko

VisualC++ Docs

TCP School

모두의 코드

식빵맘(ansohxxn)

ozt88

Effective Modern C++

본 글은 std::unique_ptr의 소개와 간단한 사용법을 중심으로 설명합니다.

std::unique_ptr 클래스가 갖는 멤버 변수나 함수에 대한 자세한 내용은 시간이 되면 나중에 작성하겠습니다.

설명

std::unique_ptr란?

std::unique_ptr는 가리키는 자원 객체에 대한 유일한 소유권을 갖는 독점 소유권(exclusive ownership) 의미론을 체현한 스마트 포인터입니다. std::unique_ptr은 생 포인터(raw pointer)와 같은 크기로 볼 수 있으며, 대부분의 연산(역참조를 비롯해서)에서 std::unique_ptr는 생 포인터와 동일한 명령을 실행할 수 있습니다. 즉, 메모리와 CPU 주기가 넉넉하지 않은 상황에서도 생 포인터가 충분히 작고 충분히 빠른 상황이라면 std::unique_ptr를 사용해도 비슷한 성능을 낼 수 있습니다.

std::unique_ptr는 복사를 허용하지 않습니다(복사를 허용할 경우 같은 자원을 가리킬 수 있게 되면서 미정의 행동이 발생합니다). 하지만 소유권 이전은 허용합니다. 즉, 자원 객체의 소유권을 집 명의처럼 복사할 수는 없지만 이전시킬 수 있으며 소유권을 이전 시키려면 std::move 함수를 사용해야 합니다. 소유권이 이전되면 원본 포인터 객체는 널을 가리키게되며 대상 포인터 객체가 자원 객체를 가리키게 됩니다.

std::unique_ptr는 자원 객체를 소유하고 있을 때만, 자원 객체를 해제할 수 있는 권한을 가집니다. 또한 포인터 객체는 생성할 때 커스텀 삭제자(custom deleter)를 사용하도록 지정할 수도 있습니다. 다만, 커스텀 삭제자를 지정하게 되면 커스텀 삭제자를 위한 함수 포인터가 필요하므로 std::unique_ptr의 크기가 1 워드에서 2 워드로 증가하게 됩니다.

std::unique_ptr는 개별 객체(std::unique_ptr<T>)와 배열(std::unique_ptr<T[]>) 형태 모두 지원합니다. std::unique_ptr API는 사용 대상에게 잘 맞는 형태로 설계되어 있어 개별 객체 형태는 색인 적용 연산(operator[])를 제공하지 않으며, 배열 형태는 역 참조 연산자들(operator*와 operator->)제공하지 않습니다.

std::unique_ptr에서 배열 형태를 지원하지만 사용을 권장하지 않습니다. 배열 형태의 포인터 객체를 생성하기 보단 std::array나 std::vector, std::string을 사용하는 것이 거의 항상 더 나은 선택이기 때문입니다.

왜 엄격한 소유권을 지니는가?

std::unique_ptr가 이렇게 설계된 이유는 double-free 오류에 있습니다.

double-free 오류란 이미 해제한 자원 객체를 다시 해제하는 경우 발생하는 오류로 다음과 같은 상황에서 자주 발생합니다.

int* ptr1 = new int();
int* ptr2 = ptr1;

// ...

// ptr1 사용 끝, 해제
delete ptr1;

// ..

// ptr2 사용 끝, 해제
delete ptr2;

동일한 자원 객체를 가리키는 포인터 ptr1, ptr2가 존재합니다. ptr1이 자원 객체를 다 사용해, 해제합니다. ptr2는 이 사실을 모르고 있다가 이미 소멸된 자원 객체를 다시 해제하는 불상하가 일어납니다. 이런 경우 메모리 오류가 발생해, 프로그램이 죽게됩니다.

위의 문제가 발생한 이유는 동적 할당된 자원 객체의 소유권이 명확하지 않고 쉽게 접근할 수 있기 때문입니다. 만약 처음 초기화된 포인터에게만 소유권을 갖고 있었다면 위와 같이 자원 객체를 두 번 해제하는 일은 발생하지 않았을 것입니다.

즉, std::unique_ptr는 소유권이 명확하지 않아 발생하는 오류에 의해 발생하는 미정의 행동에서 벗어나기 위해 독점 소유권 의미론을 체현한 스마트 포인터로 설계된 것입니다.

사용법

std::unique_ptr를 사용하기 위해선 <memory> 헤더를 포함해야 합니다.

생성자를 이용한 생성 및 초기화

스마트 포인터는 모든 타입에 대한 자원 객체를 가리킬 수 있어야 하기 때문에 템플릿 클래스로 선언되어 있습니다. 즉, 스마트 포인터는 생성자를 통해 생성 및 초기화를 할 수 있습니다.

#include <iostream>
#include <memory>

class Person
{
private:
    std::string mName;
    int mAge;

public:
    Person(std::string name, int age) : mName(name), mAge(age)
    {
        std::cout << "생성자 호출" << std::endl;
    }

    ~Person()
    {
        std::cout << "소멸자 호출" << std::endl;
    }

    void doSomething()
    {
        // ...
    }
};

int main()
{
    std::unique_ptr<Person> uPtr(new Person("whale", 10));
    (*uPtr).doSomething();
    uPtr->doSomething();
}

위에서 언급했듯이 std::unique_ptr는 생 포인터와 동일하게 사용할 수 있게 설계되어 있어 생 포인터처럼 사용하면 됩니다.

또한 std::unique_ptr(와 shared_ptr)는 기본적으로 자원 객체의 해제는 delete를 통해서 일어나지만, 위에서 언급했듯이 커스텀 삭제자를 설정할 수 있습니다. 자원 객체의 해제 전, 로그를 기록하는 등의 작업이 필요할 때 사용합니다.

커스텀 삭제자를 설정하기 위해서는 포인터 객체를 선언할 때, std::unique_ptr의 두 번째 템플릿 형을 설정하고 생성자의 두 번째 인자로 함수 객체를 전달해야 합니다.

#include <iostream>
#include <memory>

class Person
{
private:
    std::string mName;
    int mAge;

public:
    Person(std::string name, int age) : mName(name), mAge(age)
    {
        std::cout << "생성자 호출" << std::endl;
    }

    ~Person()
    {
        std::cout << "소멸자 호출" << std::endl;
    }

    std::string GetName() { return mName; }
    int GetAge() { return mAge; }
};

void FuncDeleter(Person* pPerson)
{
    std::cout << "함수 커스텀 소멸자 호출" << std::endl;

    delete pPerson;
}

int main()
{
    auto lambdaDeleter = [](Person* pPerson) {
        std::cout << "람다 커스텀 삭제자 호출" << std::endl;

        delete pPerson;
    };

    std::unique_ptr<Person, decltype(lambdaDeleter)> uPtr1(new Person("whale", 10), lambdaDeleter);
    std::unique_ptr<Person, decltype(&FuncDeleter)> uPtr2(new Person("park18", 20), FuncDeleter);
}

[출력 결과]

생성자 호출
생성자 호출
함수 커스텀 소멸자 호출
소멸자 호출
람다 커스텀 삭제자 호출
소멸자 호출

lambdaDeleter와 FuncDeleter가 Person에 대한 커스텀 삭제자입니다. 모든 커스텀 삭제자 함수는 파괴할 자원 객체를 가리키는 포인터 하나를 받으며, 그 객체를 파괴하는데 필요한 일들을 수행합니다. 지금 예제에서 삭제자는 별도의 일을 하고 있지는 않지만 로그를 남기거나 세이브 파일을 저장하는 등 삭제 전에 필요한 일을 수행하는 코드를 작성할 수 있습니다. 모든 일을 마친 후에는 인자로 넘겨받은 자원 객체를 반드시 해제해야 합니다.

삭제자 함수는 통상적인 함수를 작성해 전달하는 방법도 있지만 람다 표현식을 이용해 작성하는 것이 더 효율적입니다.

커스텀 삭제자를 사용하기 위해 std::unique_ptr의 두 번째 템플릿 형을 지정해야 하며 이를 위해 decltype 키워드를 사용합니다. decltype 키워드는 auto 키워드와 비슷한 개념으로 주어진 표현식의 타입을 컴파일러가 추론해 결정하도록 합니다.

최상위 기본 클래스로 하위 파생 클래스를 관리할 목적으로 포인터 객체를 생성하는 것이라면 삭제자가 인자로 전달받는 것이 기본 클래스 타입이기 때문에 기본 클래스의 소멸자를 가상화 시켜야합니다. 만약 기반 클래스의 소멸자를 가상화 시키지 않았다면 기본 클래스의 소멸자만 호출되어 미정의 행위가 발생하게됩니다.

#include <iostream>
#include <memory>

class BaseClass
{
public:
    BaseClass()
    {
        std::cout << "(기본 클래스) 생성자 호출" << std::endl;
    }

    virtual ~BaseClass()
    {
        std::cout << "(기본 클래스) 소멸자 호출" << std::endl;
    }
};

class DerivedClass1 : public BaseClass
{
public:
    DerivedClass1()
    {
        std::cout << "(파생 클래스1) 생성자 호출" << std::endl;
    }

    ~DerivedClass1()
    {
        std::cout << "(파생 클래스1) 소멸자 호출" << std::endl;
    }
};

class DerivedClass2 : public BaseClass
{
public:
    DerivedClass2()
    {
        std::cout << "(파생 클래스2) 생성자 호출" << std::endl;
    }

    ~DerivedClass2()
    {
        std::cout << "(파생 클래스2) 소멸자 호출" << std::endl;
    }
};

int main()
{
    auto deleter = [](BaseClass* pBaseClass) {
        std::cout << "커스텀 삭제자 호출" << std::endl;

        delete pBaseClass;
    };

    std::unique_ptr<DerivedClass1, decltype(deleter)> uPtr1(new DerivedClass1, deleter);
    std::unique_ptr<DerivedClass2, decltype(deleter)> uPtr2(new DerivedClass2, deleter);
}

[출력 결과]

(기본 클래스) 생성자 호출
(파생 클래스1) 생성자 호출
(기본 클래스) 생성자 호출
(파생 클래스2) 생성자 호출
커스텀 삭제자 호출
(파생 클래스2) 소멸자 호출
(기본 클래스) 소멸자 호출
커스텀 삭제자 호출
(파생 클래스1) 소멸자 호출
(기본 클래스) 소멸자 호출

std::make_unique를 사용한 생성 및 초기화

std::unique_ptr를 생성자로 초기화하기 위해선 반드시 주소값이 필요합니다. 만약 인자로 다른 포인터 객체가 가리키고 있는 자원 객체의 주소를 전달하여 초기화하는 것이 가능한지 의문이 생깁니다.

#include <iostream>
#include <memory>

int main()
{
    int* pNumber = new int(5);
    std::unique_ptr<int> uPtr1(pNumber);
    std::unique_ptr<int> uPtr2(pNumber);
    std::unique_ptr<int> uPtr3;
    uPtr3.reset(pNumber);

    std::cout << "uPtr1: " << uPtr1.get() << std::endl;
    std::cout << "uPtr2: " << uPtr2.get() << std::endl;
    std::cout << "uPtr3: " << uPtr3.get() << std::endl;
}

[출력 결과]
uPtr1: 01450428
uPtr2: 01450428
uPtr3: 01450428

<런타임 오류>

놀랍게도 서로 다른 포인터 객체가 같은 자원 객체를 가리킬 수 있게 초기화하는 것이 가능합니다. 이렇게 되면 std::unique_ptr는 목적과 다르게 하나의 자원 객체를 여러 개의 포인터 객체가 소유하게 되며 double-free 문제까지 발생하게 됩니다.

std::unique_ptr가 다른 자원 객체를 가리키고 싶게 하고 싶다면 reset 멤버 함수를 호출하면 됩니다.

std::unique_ptr가 현재 가리키고 있는 자원 객체의 주소를 알고 싶으면 get 멤버 함수를 호출하면 됩니다.

이런 상황을 피하기 위해 C++14에서는 std::make_unique 함수를 제공합니다. std::make_unique 함수는 자원 객체의 생성자에게 전달할 인자들을 전달 받고 내부에서 std::unique_ptr를 생성해 반환하기 때문에 안전하게 포인터 객체를 생성할 수 있습니다.

#include <iostream>
#include <memory>

class Person
{
private:
    std::string mName;
    int mAge;

public:
    Person(std::string name, int age) : mName(name), mAge(age)
    {
        std::cout << "생성자 호출" << std::endl;
    }

    ~Person()
    {
        std::cout << "소멸자 호출" << std::endl;
    }

    void DoSomething()
    {
        // ...
    }
};

int main()
{
    std::unique_ptr<Person> uPtr = std::make_unique<Person>("whale", 10);
    uPtr->DoSomething();
}

이렇게 안전하게 포인터 객체를 생성해주는 std::make_unique 함수에도한 가지 단점이 존재합니다. 바로 커스텀 삭제자를 설정할 수 없다는 것입니다. 때문에 커스텀 삭제자를 지정해야 하는 경우에는 어쩔 수 없이 생성자를 통해 초기화해야 합니다.

같은 스마트 포인터인 std::shared_ptr의 경우에는 C++14가 아닌 C++11에 std::make_shared 함수가 존재합니다. 아마 C++11에는 이런 상황을 예상하지 못해 제외시킨 것 같습니다.

C++11 환경에서 개발 중이라면 std::make_unique의 기본 버전을 직접 작성하는 것이 어렵지 않기 때문에 걱정하지 않아도 됩니다.

template<typename T, typename... Ts>
std::unique_ptr<T> make_unique<Ts&... params>
{
    return std::unique_ptr<T>(new T(std::forward<Ts>(params)...));
}

단, 직접 구현할 경우 std:: 네임스페이스를 적성하지 않아야 합니다. 나중에 C++14로 업그레이드 했을 경우 표준 라이브러리와 이름 충돌이 발생하기 때문입니다.

복사

std::unqie_ptr은 복사할 수 없다고 설명했습니다. 그럼에도 불구하고 복사를 시도할 경우 어떻게 작동할까요?

#include <iostream>
#include <memory>

class Person
{
private:
    std::string mName;
    int mAge;

public:
    Person(std::string name, int age) : mName(name), mAge(age)
    {
        std::cout << "생성자 호출" << std::endl;
    }

    ~Person()
    {
        std::cout << "소멸자 호출" << std::endl;
    }
};

int main()
{
    std::unique_ptr<Person> uPtrOriginal = std::make_unique<Person>("whale", 10);
    std::unique_ptr<Person> uPtrCopy(uPtrOriginal);
}

<컴파일 오류>

심각도    코드    설명    프로젝트    파일    줄    비표시 오류(Suppression) 상태
오류    C2280    'std::unique_ptr<Person,std::default_delete<Person>>::unique_ptr(const std::unique_ptr<Person,std::default_delete<Person>> &)': 삭제된 함수를 참조하려고 합니다.

복사를 시도할 경우 위와 같은 오류가 발생하게 됩니다. 위 오류는 삭제된 함수를 사용하려 했을 때, 발생하는 것입니다.

삭제된 함수란 C++11에서 추가된 기능으로 프로그래머가 명시적으로 '이 함수는 사용하지 말 것!'을 표현한 것입니다. 혹시라도 삭제된 함수를 사용할 경우 위와 같이 컴파일 오류가 발생하게 됩니다.

std::unique_ptr의 경우 유일하게 소유하는 엄격한 소유권 때문에 복사 생성자와 대입 연산자(복사 기능 한정)를 명시적으로 삭제했습니다. 만약 복사 생성자나 대입 연산자를 사용할 수 있다면 유일한 소유권을 갖는 특성이 사라지게 되면서 std::unique_ptr는 존재 의의를 잃게 됩니다.

std::move 함수를 사용한 소유권 이전

std::unique_ptr는 복사는 불가능 하지만 소유권을 이전할 수 있습니다. 다만, 소유권을 이전하기 위해선, std::move 함수를 사용해야 합니다.

#include <iostream>
#include <memory>

int main()
{
    std::unique_ptr<int> uPtrOriginal = std::make_unique<int>(1);
    std::unique_ptr<int> uPtrTarget(nullptr);

    std::cout << "[Before] owner: uPtrOriginal" << std::endl;
    std::cout << "uPtrOriginal: " << uPtrOriginal.get() << ", uPtrTarget: " << uPtrTarget.get() << std::endl;
    std::cout << '\n';

    uPtrTarget = std::move(uPtrOriginal);

    std::cout << "[After] owner: uPtrTarget" << std::endl;
    std::cout << "uPtrOriginal: " << uPtrOriginal.get() << ", uPtrTarget: " << uPtrTarget.get() << std::endl;
}

[출력 결과]

[Before] owner: uPtrOriginal
uPtrOriginal: 00BF03F0, uPtrTarget: 00000000

[After] owner: uPtrTarget
uPtrOriginal: 00000000, uPtrTarget: 00BF03F0

std::move 함수를 사용해, uPtrOriginal의 소유권을 uPtrTarget에게 이전하였습니다. uPtrOriginal이 가리키던 주소는 널을 가리키게 되고 uPtrTarget은 uPtrOriginal이 가리키던 자원 객체를 가리키면서 소유권이 넘겨진 것을 확인할 수 있습니다.

소유권이 이전된 포인터 객체를 댕글리 포인터(dangling pointer)라고 하며 이를 재참조할 때, 런타임 오류가 발생합니다. 따라서 소유권 이전은 댕글링 포인터를 다시 참조하지 않겠다는 확신을 갖고 이동시켜야 합니다.

함수 인자로 전달하기

일반적으로 함수 인자를 전달하게 되면 복사가 발생하며 전달하게 됩니다. 하지만 std::unique_ptr은 위에서 설명했듯이 복사가 불가능합니다. 즉, std::unique_ptr은 함수 인자로 전달할 수 없다는 것입니다.

하지만 복사가 일어나지 않는 레퍼런스를 전달한다면 가능하지 않을까요?

#include <iostream>
#include <memory>

class Person
{
private:
    std::string mName;
    int mAge;

public:
    Person(std::string name, int age) : mName(name), mAge(age)
    {
        std::cout << "생성자 호출" << std::endl;
    }

    ~Person()
    {
        std::cout << "소멸자 호출" << std::endl;
    }

    std::string GetName() { return mName; }
    int GetAge() { return mAge; }
};

inline void PrintPersonalInfo(std::unique_ptr<Person>& uPtrReference)
{
    std::cout << "이름: " << uPtrReference->GetName() << std::endl;

    std::cout << "나이: " << uPtrReference->GetAge() << std::endl;
}

int main()
{
    std::unique_ptr<Person> uPtrOriginal = std::make_unique<Person>("whale", 10);
    PrintPersonalInfo(uPtrOriginal);
}

[출력 결과]

생성자 호출
이름: whale
나이: 10
소멸자 호출

포인터 객체를 레퍼런스로 전달할 경우 정상적으로 작동하는 것을 확인할 수 있습니다. PrintPersonalInfo 함수의 uPtrPerson 인자는 레퍼런스이기 때문에 함수가 종료되도 객체를 파괴되지 않고 main 함수가 종료되면서 파괴는 것을 확인할 수도 있습니다.

참고한 자료 중에서 레퍼런스이긴 하지만 유일하게 소유한다는 원칙을 벗어나기 때문에 문맥상 옳지 못하다고 의견을 내신 분도 있습니다.

위에선 값으로 전달하지 못한다고 했지만 정확하게 말하자면 불가능 한 것은 아닙니다. 소유권을 get 멤버 함수를 사용해 포인터 주소값을 전달하거나 std::move 함수를 사용해 소유권을 넘기는 것입니다. 하지만 소유권을 넘기게 된다면 함수가 끝날 때, 자원을 반환한다는 문제가 발생합니다.

컨테이너의 원소

C++는 std::array, std::vector 등의 다양한 STL을 지원하면서 C++로 프로그램을 개발하게 된다면 STL을 반드시 접하게 됩니다. 이 STL의 컨테이너의 원소로 std::unique_ptr를 저장할 수 있을까요?

기본적으로 std::vector의 push_back 멤버 함수 같이 컨테이너에 원소를 넣게 된다면 복사 과정이 발생하게 됩니다. 즉, std::unique_ptr는 컨테이너의 원소가 될 수 없다는 것을 의미합니다. 하지만 std::move 함수로 소유권을 이전 시킨다면 컨테이너의 원소로 넣을 수 있습니다.

다른 방법으로 std::vecto의 emplace_back 멤버 함수 같이 컨테이너 내부에서 생성하게 된다면 복사 과정이 발생하지 않기 때문에 컨테이너의 원소가 될 수 있습니다.

#include <iostream>
#include <memory>
#include <vector>

class Person
{
private:
    std::string mName;
    int mAge;

public:
    Person(std::string name, int age) : mName(name), mAge(age)
    {
        std::cout << "생성자 호출" << std::endl;
    }

    ~Person()
    {
        std::cout << "소멸자 호출" << std::endl;
    }

    std::string GetName() { return mName; }
    int GetAge() { return mAge; }
};

void funcDeleter(Person* pPerson)
{
    std::cout << "함수 커스텀 소멸자 호출" << std::endl;

    delete pPerson;
}

int main()
{
    std::vector<std::unique_ptr<Person>> vec;

    std::unique_ptr<Person> uPtr = std::make_unique<Person>("whale", 10);

    vec.push_back(std::move(uPtr));
    vec.emplace_back(new Person("park18", 20));

    for (auto& item : vec)
    {
        std::cout << "name: " << item->GetName() << ", age: " << item->GetAge() << std::endl;
    }
}

범위 기반 for문은 기본적으로 복사된 원소에 접근하는 것이기 때문에 사용하려면 레퍼런스로 지정해야합니다. 일반 for문은 인덱스를 이용해 직접 접근하는 것이기 때문에 평소처럼 사용하면 됩니다.

참고

cppreference - en

cppreference - ko

cplusplus.com

Runebook.dev

VisualC++ Docs

TCP School

모두의 코드

식빵맘(ansohxxn)

duragon.gitbooks.io

gamdekong

코드없는 프로그래밍

포프TV

Effective Modern C++

C#이나 Java같은 프로그래밍 언어에는 가비지 컬렉터(Garbage Collector:GC)라는 자원 청소기가 기본적으로 내장되어 있습니다. 이 가비지 컬렉터는 프로그램에서 더 이상 사용하지 않는 자원을 자동으로 해제하는 역할을 수행하기 때문에 프로그래머가 자원을 해제하는 것에 대한 신경을 쓰지 않아도 됩니다.

하지만 C++에는 이러한 개념이 존재하지 않아 프로그래머가 수동으로 메모리를 해제해야 합니다. 만약 사용한 자원을 해제하지 않으면 프로그램이 종료되기 전까지, 메모리에 계속 남아있는 메모리 누수(Memory leak)가 발생합니다.

'프로그래머가 신경 써서 메모리 해제만 했어도 일어나지 않았을 문제 아닌가?' 생각할 수 있습니다. 객관적으로 보자면 신경쓰지 못한 프로그래머의 잘못이 맞습니다. 하지만 우리는 사람이기 때문에 실수로 메모리 해제를 잊을 수도, 언어의 사양을 잘못 파악하거나 예상치 못한 곳에서 다른 흐름이 발생해 메모리가 해제되지 않는 실수를 할 수 밖에 없습니다.

예를 들어 소멸자를 이용해 메모리 해제하는 코드를 작성했지만 thrower() 함수로 발생한 예외로 인해, 흐름이 바뀌게 되어 메모리를 해제하지 못하고 넘어가 소멸자가 실행되지 못하는 경우가 있습니다.

#include <iostream>

class Socket
{
private:
    int* p_data;

public:
    Socket()
    {
        p_data = new int[100];
        std::cout << "Get Resource" << std::endl;
    }

    ~Socket()
    {
        delete[] p_data;
        std::cout << "Free Resource" << std::endl;
    }
};

inline void thrower()
{
    // 예외 발생
    throw 1;
}

inline void do_something()
{
    Socket* p_socket = new Socket();

    // ...

    thrower();

    // ...

    delete p_socket;
}

int main()
{
    try
    {
        do_something();
    }
    catch (int i)
    {
        std::cout << "Exception" << std::endl;
    }
}

[출력 결과]
Get Resource
Exception

이러한 문제를 해결하기 위해 C++에서 자원을 관리하는 방법으로 RAII(Resource Acquisition Is Initialization)라는 디자인 패턴을 권장합니다. 이는 자원 관리를 스택에 할당한 객체를 통해 수행하는 것입니다.

스택을 이용하는 이유는 스택에 할당된 객체는 스코프를 벗어나게 되면 자동으로 스택에서 제거되면서 소멸자가 호출되기 때문입니다. 예를 들어 위 예제에서 p_socket은 객체가 아니기 때문에 소멸자가 호출되지 않은 것입니다. 즉, p_socket을 일반적인 포인터가 아닌, 포인터 객체로 만들어서 자신이 소멸될 때, 자신이 가리키고 있는 자원을 해제하면 되는 것입니다.

이렇게 똑똑하게 작동하는 포인터 객체를 스마트 포인터라고 하며 C++11에서 언어 자체에서 스마트 포인터를 지원하게 됐습니다. C++11 이전에도 auto_ptr 이라는 스마트 포인터가 존재했지만, 문제가 많아 C++11로 개정되면서 memory 헤더에 정의된 unique_ptr, shared_ptr, weak_ptr로 개편되어 이제 사용하지 않습니다.

auto_ptr 키워드는 C++11 에서는 deprecated 되었고, C++17에서는 removed 되었습니다.

그렇다면 스마트 포인터를 사용하면 정말로 문제가 해결되는지 확인해보겠습니다.

#include <iostream>
#include <memory>

using namespace std;

class Socket
{
private:
    int* p_data;

public:
    Socket()
    {
        p_data = new int[100];
        std::cout << "Get Resource" << std::endl;
    }

    ~Socket()
    {
        delete[] p_data;
        std::cout << "Free Resource" << std::endl;
    }

    void something()
    {
        cout << "Socket's something..." << endl;
    }
};

inline void thrower()
{
    // 예외 발생
    throw 1;
}

inline void do_something()
{
    unique_ptr<Socket> p_socket(new Socket());
    p_socket->something();

    thrower();

    // ...
}

int main()
{
    try
    {
        do_something();
    }
    catch (int i)
    {
        std::cout << "Exception" << std::endl;
    }
}

[출력 결과]
Get Resource
Socket's something...
Free Resource
Exception

thrower에 의해 스코프를 벗어나자 스마트 포인터가 스택에서 해제되면서 소멸자를 호출하는 것을 확인할 수 있습니다.

참고

VisualC++ Docs

TCP School

모두의 코드

template <class Ty, size_t N>
class array;

설명

std::array 컨테이너는 C 스타일 배열과 같은 형식을 유지하면서, STL에서 추가된 반복자, 알고리즘, 대입 연산자 등을 사용할 수 있게 있어 많은 편리함을 제공하는 컨테이너입니다. 배열을 사용하기 하려면 array 헤더를 포함해야 합니다.

배열(array)은 STL의 컨테이너 중 하나이기 때문에 템플릿으로 정의되어 있습니다. 또한 고정된 길이의 선형 구조이기 때문에 길이에 대한 정보도 필요합니다. 즉, 배열을 선언하기 위해서는 저장할 타입과 배열의 길이의 정보가 필요합니다.

#include <array>

int main()
{
    std::array<int, 5> arr;
}

멤버 함수

STL에서 제공하는 컨테이너가 제공하는 멤버 함수는 거의 비슷합니다. 때문에 첫 번째인 현재 글 이후에는 간단하게 생략하겠습니다.

• 생성자

• operator=

• 반복자

  • begin() → 배열(또는 컨테이너)의 첫 번쨰 원소를 가리키는 반복자를 반환한다.
  • end() → 배열의 마지막 원소의 다음 원소를 가리키는 반복자를 반환한다.
  • rbegin() → 배열의 반대 방향의 첫 번째 원소를 가리키는 반복자를 반환한다.
  • rend() → 배열의 반대 방향의 마지막 원소의 다음 원소를 가리키는 반복자를 반환한다.
  • cbegin() → 배열의 첫 번째 원소를 가리키는 const 반복자를 반환한다.
  • cend() → 배열의 마지막 원소의 다음 원소를 가리키는 const 반복자를 반환한다.
  • crbegin() → 배열의 반대 방향의 첫 번째 원소를 가리키는 const 반복자를 반환한다.
  • crend() → 배열의 반대 방향의 마지막 원소의 다음 원소를 가리키는 const 반복자를 반환한다.

• 원소 접근

  • at(sizt_type pos) → pos 위치에 있는 원소를 반환한다.
  • operator[](size_type pos) → pos 위치에 있는 원소를 반환한다.
  • front() → 배열의 첫 번째 원소를 반환한다.
  • back() → 배열의 마지막 원소를 반환한다.
  • data() → 배열의 첫 번째 원소의 주소를 반환합니다.

• 크기

  • empty() → 배열이 비어있는지 확인한다.
  • max_size() → 배열의 최대 크기를 반환한다. → array에서는 size()와 같다.
  • size() → 배열의 크기를 반환한다. → array에서는 max_size()와 같다.

• 그 외

  • fill(Ty& val) → 배열의 모든 원소를 val로 바꾼다.
  • swap(array& right) → 두 배열의 내용을 바꾼다.

예제

예제: 생성자 및 초기화

#include <iostream>
#include <array>

using namespace std;

int main()
{
    array<int, 3> arr1 = { 1, 2, 3 };   // 지정된 값으로 초기화
    array<int, 2> arr2;                 // 쓰레기 값으로 초기화
    array<int, 4> arr3 = { 0 };         // 모든 원소 0으로 초기화
    array<int, 5> arr4 = { 10 };        // 첫 번째 원소만 10으로 초기화, 나머지 0으로 초기화
    array<int, 3> arr5{4, 5, 6};        // C++11에서 추가된 초기화 방법
    array<int, 4> arr6 = arr3;          // 대입 연산자를 사용한 초기화

    cout << "=====arr1=====" << endl;
    for (auto item : arr1)
        cout << item << endl;

    cout << "=====arr2=====" << endl;
    for (auto item : arr2)
        cout << item << endl;

    cout << "=====arr3=====" << endl;
    for (auto item : arr3)
        cout << item << endl;

    cout << "=====arr4=====" << endl;
    for (auto item : arr4)
        cout << item << endl;

    cout << "=====arr5=====" << endl;
    for (auto item : arr5)
        cout << item << endl;

    cout << "=====arr6=====" << endl;
    for (auto item : arr6)
        cout << item << endl;
}

[출력 결과]
=====arr1=====
1
2
3
=====arr2=====
-858993460
-858993460
=====arr3=====
0
0
0
0
=====arr4=====
10
0
0
0
0
=====arr5=====
4
5
6
=====arr6=====
0
0
0
0

array를 초기화 하는 방법은 변수 선언과 동시에 초기화하거나 선언 후, 인덱스를 통해 접근해 초기화 하는 등 C 스타일 배열과 동일하게 초기화할 수 있습니다. 초기화를 하지 않았을 경우 쓰레기 값이 들어가는 것 또한 동일합니다.

다른 점이 있다면 operator= 연산자를 사용한 덮어쓰기가 가능하다는 것입니다. 하지만 주의할 점이 존재합니다. 다른 컨테이너의 정보를 덮어쓸 경우에는 오버헤드가 발생하지 않지만 초기화 리스트를 덮어쓸 때는

다른 컨테이너의 정보를 operator= 연산자를 이용해 복사하는 것은 오버헤드가 발생하지 않지만 초기화 리스트를 복사할 경우, 초기화 리스트의 정보들을 복사한 후(새롭게 변수 선언 == 기본 생성자), 복사(복사 생성자)하는 오버헤드가 발생합니다.

#include <iostream>
#include <array>

using namespace std;

class Type
{
public:
    Type()
    {
        cout << "기본 생성자" << endl;
    }

    Type(Type& other)
    {
        cout << "복사 생성자" << endl;
    }
};

int main()
{
    Type type;
    array<Type, 1> arr;
    arr = { type };
}

[출력 결과]
기본 생성자
기본 생성자
복사 생성자

예제: 반복자

#include <iostream>
#include <array>

using namespace std;

int main()
{
    array<int, 5> arr = { 1, 2, 3, 4, 5 };

    cout << "=====begin - end=====" << endl;
    for (array<int, 5>::iterator iter = arr.begin(); iter != arr.end(); iter++)
        cout << *iter << endl;

    cout << "=====rbegin - rend=====" << endl;
    for (auto iter = arr.rbegin(); iter != arr.rend(); iter++)
        cout << *iter << endl;

    cout << "=====Range-for=====" << endl;
    for(auto item : arr)
        cout << item << endl;
}

[출력 결과]
=====begin - end=====
1
2
3
4
5
=====rbegin - rend=====
5
4
3
2
1
=====Range-for=====
1
2
3
4
5

반복자를 변수로 사용하기 위해서는 컨테이너 템플릿 선언문 :: iterator 구문으로 선언해야 합니다. 컨테이너 템플릿 선언문은 위의 예제로 설명하자면 arr의 변수 타입인 array<int, 5>입니다. 반복자를 사용할 때마다 이렇게 반복자를 선언하는 것음 참으로 귀찮고 오타로 인한 에러가 발생할 수도 있습니다. 때문에 C++11에서는 auto라는 강력한 추론 타입이 존재하기 때문에 auto를 사용하는 것을 권합니다.

STL에서 반복자는 포인터의 개념을 품은(또는 비슷한) 객체로 설명했습니다. 때문에 반복자로 데이터에 접근하기 위해서는 포인터 변수처럼 참조 연산자(*)를 사용해 접근해야 합니다.

또한 기본 시퀀스를 반환하는 반복자(begin, end 등)과 반전 시퀀스를 반환하는 반복자(rbegin, rend 등)는 서로 다른 타입이기 때문에 비교 연산자를 이용한 비교가 불가능합니다.

begin, end 등의 기본 시퀀스 반복자 타입: iterator rebgin, rend 등의 반전 시퀀스 반복자 타입: reverse_iterator

cbegin, cend, crbegin, crend는 begin, end, rbegin, rend에서 const만 적용한 것이기 때문에 생략했습니다.

예제: 원소 접근

#include <iostream>
#include <array>

using namespace std;

int main()
{
    array<int, 5> arr = { 1, 2, 3, 4, 5 };

    cout << "at(2): " << arr.at(2) << endl;
    cout << "[3]: " << arr[3] << endl;
    cout << "front: " << arr.front() << endl;
    cout << "back: " << arr.back() << endl;
    cout << "data: " << arr.data() << endl;
}

[출력 결과]
at(2): 3
[3]: 4
front: 1
back: 5
data: 00EFFC1C

data는 배열의 첫 번째 원소의 주소를 반환합니다. 그렇다는 것은 C 스타일 배열을 포인터로 접근한 것처럼 접근이 가능한 것일까요?

#include <iostream>
#include <array>

using namespace std;

int main()
{
    array<int, 5> arr = { 1, 2, 3, 4, 5 };

    cout << "*(data + 0): " << *(arr.data() + 0) << endl;
    cout << "*(data + 1): " << *(arr.data() + 1) << endl;
    cout << "*(data + 2): " << *(arr.data() + 2) << endl;
    cout << "*(data + 3): " << *(arr.data() + 3) << endl;
    cout << "*(data + 4): " << *(arr.data() + 4) << endl;
}

[출력 결과]
*(data + 0): 1
*(data + 1): 2
*(data + 2): 3
*(data + 3): 4
*(data + 4): 5

예제: 크기

#include <iostream>
#include <array>

using namespace std;

int main()
{
    array<int, 5> arr = {1, 2, 3, 4, 5};

    cout << "empty: " << std::boolalpha << arr.empty() << endl;
    cout << "max_size: " << arr.max_size() << endl;
    cout << "size: " << arr.size() << endl;
}

[출력 결과]
empty: false
max_size: 5
size: 5

예제: 그 외

#include <iostream>
#include <array>

using namespace std;

int main()
{
    array<int, 5> arr1 = {1, 2, 3, 4, 5};

    cout << "=====fill before=====" << endl;
    for (auto item : arr1)
       cout << item << endl;

    cout << "=====fill after=====" << endl;
    arr1.fill(10);
    for (auto item : arr1)
        cout << item << endl;
    cout << endl;

    array<int, 5> arr2 = { 6,7,8,9,0 };
    cout << "=====swap before=====" << endl;
    cout << "arr1" << '\t' << "arr2" << endl;
    for (size_t i = 0; i < arr1.size(); i++)
       cout << arr1.at(i) << '\t' << arr2.at(i) << endl;

    cout << "=====swap after=====" << endl;
    arr1.swap(arr2);
    cout << "arr1" << '\t' << "arr2" << endl;
    for (size_t i = 0; i < arr1.size(); i++)
       cout << arr1.at(i) << '\t' << arr2.at(i) << endl;
}

[출력 결과]
=====fill before=====
1
2
3
4
5
=====fill after=====
10
10
10
10
10

=====swap before=====
arr1    arr2
10      6
10      7
10      8
10      9
10      0
=====swap after=====
arr1    arr2
6       10
7       10
8       10
9       10
0       10

참고 자료

cpprefernce VisualC++ Docs 모두의 코드 소년코딩 BlockDMask

Standard Template Library란 C++에서 제공하는 표준 템플릿 라이브러리로 C++ template을 이용해 Generic(일반화: 타입에 무관한)한 프로그래밍이 가능합니다.

STL 구성요소

STL은 Container(컨테이너, 자료구조) Class, Iterator(반복자), Algorithm(알고리즘) 그리고 Function Object(함수자)라고 불리는 네 가지의 구성요소로 구성되어 있습니다.

컨테이너

컨테이너는 객체 또는 데이터를 담는 컬렉션 또는 자료구조로 크게 순차 컨테이너, 연관 컨테이너, 비정렬 연관 컨테이너, 컨테이너 어댑터로 나눠집니다.

• 순차(시퀀스) 컨테이너 → 특별한 규칙이 없는 컨테이너, 순서가 있는 선형구조

  • array : 배열
  • vector : 동적 배열
  • deque : 양방향 큐
  • list : 양방향 리스트
  • forward_list(C++11) : 단방향 리스트

• 연관 컨테이너 → 특정 규칙에 의해 정렬되는 컨테이너, 순서가 없는 비선형 구조

  • set : 정렬된 유일 Key 집합
  • map : 정렬된 유일 Key와 Value 집합
  • multiset : 정렬된 중복허용 Key 집합
  • multimap : 정렬된 중복허용 Key와 Value의 집합

• 비정렬 연관 컨테이너

  • unorder_set(C++11) : 유일 Key 해시
  • unorder_map(C++11) : 유일 Key와 Value의 해시
  • unorder_multiset(C++11) : 중복허용 Key 해시
  • unorder_multimap(C++11) : 중복허용 Key와 Value의 해시

• 컨테이너 어댑터 → 간결함과 명료성을 위해 인터페이스를 제한한 컨테이너, 반복자를 지원하지 않아 STL 알고리즘을 사용할 수 없다.

  • stack : 스택
  • queue : 큐
  • priority_queue : 우선순위큐

순차 컨테이너의 경우 요소가 언제 삽입되는지에 따라 배열안에서 요소의 순서가 결정된다. 즉, 연속되게 저장되는 배열과 같은 구조입니다. 하지만 특이하게 list는 다음 요소의 주소를 가리키는 노드구조를 가지고 있습니다.

연관 컨테이너는 어느 기준에 따라 자동으로 정렬하는 컨테이너 입니다. 따라서 순서가 없고 기준에 따라 다음 요소의 메모리 주소를 가리키는 노드구조입니다.

반복자

반복자는 포인터의 개념을 품은(또는 비슷한) 객체로 컨테이너에 저장된 요소를 반복적으로 순회하여 요소를 가리키고, 그 요소에 접근해 다음 요소를 가리키게합니다. 즉, 요소의 타입에 상관없이 독립적으로 요소를 순회하는 과정을 수행할 수 있습니다.

반복자는 다음과 같은 특징을 가집니다.

• 컨테이너 내부의 객체에 접근할 수 있어야 한다. → 참조 연산자(*)가 정의되어 포인터처럼 객체에 접근한다.
• 반복자는 다음 객체로 이동하고 컨테이너의모든 객체를 순회할 수 있어야 한다. → 증가 연산자(++)가 정의되어 포인터 변수처럼 증감 연산자로 다음 요소로 순회한다.
• 반복자의 위치를 판단할 수 있어야 한다. → =, ==, !=와 같은 반복자간의 대입, 비교 연산자가 정의되어 있어 반복자의 위치를 파악할 수 있어야 한다.

반복자는 다음과 같은 5가지로 구성되어있습니다.

• 입력 반복자(input iterator) → 현재 위치의 객체의 값을 읽어 오는 반복자로, 증가 연산자를 사용하여 순방향으로만 이동할 수 있다.
• 출력 반복자(output iterator) → 현재 위치의 객체의 값을 변경할 수 있는 반복자로, 증가 연산자를 사용하여 순방향으로만 이동할 수 있다.
• 순방향 반복자(forward iterator) → 입력, 출력 반복자의 기능을 모두 가진 반복자로, 순방향으로 이동이 가능하며 재할당이 가능하다.
• 양방향 반복자(bidirectional iterator) → 순방향 반복자 기능에 역방향으로 이동(--)이 가능한 반복자이다.
• 임의 접근 반복자(random access iterator) → 양방향 반복자 기능과 []를 사용해 임의의 요소에 접근이 가능한 반복자로 모든 컨테이너는 양방향 반복자와 임의 접근 반복자를 지원한다.

알고리즘

STL에서 제공하는 알고리즘은 검색이나 정렬같은 활동을 수행하는 것으로 대부분은 반복자의 특정한 수준을 요구합니다. 알고리즘은 다음과 같은 4가지로 구성되어 있습니다.

• 읽기 알고리즘 → 컨테이너를 변경하지 않으며, 컨테이너의 지정된 범위에서 특정 데이터를 읽기만 하는 알고리즘, algorithm 헤더에 정의되어 있다.
• 변경 알고리즘 → 컨테이너를 변경하지 않으며, 컨테이너의 지정된 범위에서 요소의 값만을 변경할 수 있는 알고리즘, algorithm 헤더에 정의되어 있다.
• 정렬 알고리즘 → 컨테이너의 지정된 범위의 요소들을 정렬되도록 컨테이너를 변경하는 알고리즘, algorithm 헤더에 정의되어 있다.
• 수치 알고리즘 → STL에 직접 속하지 않고 C++라이브러리로 분류되는 알고리즘으로 수치적 해석을 위해 사용, numeric 헤더에 정의되어 있다.

함수자

STL은 함수 호출 연산자(operator())를 오버로드하는 클래스들을 포함합니다. 이러한 클래스들의 인스턴스들은 함수자 또는 함수 객체라고 불립니다. 함수자들은 연관된 함수가 파라미터화되는 행동을 허용하고 (예를 들어 함수자의 생성자로 넘겨지는 인자를 통해서) 연관된 per-functor 상태를 함수와 함께 사용될 수 있게 유지합니다. 함수자와 함수 포인터 모두 함수 호출의 문법을 사용해서 유발될 수 있기 때문에, 이것들은 상응하는 파라미터가 오직 함수 호출 문맥에서만 보일 때 인자로서 교체될 수 있습니다.

참고 자료

cppreference VisualC++ Docs cpluscplus - stl cpluscplus - iterator 위키백과 나무위키 BlockDMask 소년코딩

New Input System은 다양한 기기와 플랫폼 전반에 걸친 사용 편의성과 일관성을 초점으로 개발된 새로운 입력 시스템으로 기존의 입력 시스템의 불편한 점이 개선됐습니다.

기존의 입력 시스템은 지금처럼 많은 플랫폼과 기기를 지원하기 이전에 설계되어 사용자 친화적이지 못했습니다. 때로는 파일을 실행한 후 컨트롤러를 연결하는 것과 같은 간단한 작업도 원할하게 처리하지 못하는 경우도 발생했습니다. 따라서 입력 시스템을 완전히 새로 구축하게 된 것입니다.

사용 편의성

입력 시스템의 새로운 워크플로는 간단한 인터페이스로 모든 플랫폼을 지원하며, 커스텀 기기 혹은 출시 예정인 기기까지 쉽게 확장 가능합니다.

액션(Action) 중심의 워크플로는 게임 코드와 상호 작용하는 논리적 입력과 사용자가 수행하는 물리적 액션을 구분하도록 설계되었습니다. 전용 에디터 또는 스크립트에서 액션을 정의하고, 이를 기기의 주요 동작 또는 마우스 왼쪽 버튼과 같이 추상적이거나 구체적인 입력에 모두 연동시킬 수 있습니다.

[출처: 유니티 블로그]

입력 시스템의 PlayerInput 컴포넌트를 사용하면, 게임 내 플레이어 수에 관계 없이 입력 액션을 GameObject 및 스크립트 액션 반응에 쉽게 연결할 수 있습니다.

New Input System 사용하기

1. InputActions 애셋 생성

기존의 입력 시스템은 프로그래머가 스크립트에 각각의 플랫폼에 맞는 API를 호출해 입력 여부를 확인했습니다. 하지만 새로운 입력 시스템은 애셋 형태로 관리되며 이 애셋은 InputActions 애셋이라 불립니다.

InputActions 애셋은 마우스 우클릭/생성/Input Actions로 생성할 수 있습니다.

2. 액션 에디터 사용

생성된 애셋을 더블 클릭하면 액션 에디터가 열립니다. 이 액션 에디터에서 모든 입력 방법과 입력에 대응하는 액션을 관리합니다.

3. InputActions 애셋 설정하기

이제 InputActions 애셋을 설정해보겠습니다. 크게 설정해야 하는 것은 Action Maps와 Actions 두 가지입니다.

3.1. Action Maps

Action Maps는 작업의 명명된 컬렉션입니다. 즉, 액션들의 집합이라 하며 각각의 요소들을 InputActionMap이라 부릅니다. '캐릭터 조작', 'UI 조작' 등을 예로 들 수 있습니다.

이 글에서는 '캐릭터 조작'을 예제를 들어보겠습니다. 눈치 빠른 분들은 이미 눈치 채셨겠지만 액션 에디터의 Action Maps 카테고리의 오른쪽 상단에 더하기 버튼이 있습니다. 이 더하기 버튼을 누르면 새로운 InputActionMap이 생성됩니다. 이름은 "PlayerControl"로 지정하겠습니다.

InputActionMap은 최소 하나 이상의 액션을 담고있어야 하기 때문에 자동으로 한 개의 Action이 생성됩니다.

New Action 왼쪽에 삼각형 토글을 눌러 출력된 <No Binding> 항목을 삭제합니다. 자세한 설명은 이후에 하겠습니다.

3.2. Actions

Actions는 행동을 정의하고 키를 바인딩합니다. 각각이 요소를 InputAction이라 부릅니다. '이동이라는 행동은 W,A,S,D로 입력받다'를 예로 들 수 있습니다.

'캐릭터 조작' 중에서 이동에 대해 다음과 같이 정의했습니다.

• 이동: W, A, S, D

InputAction을 생성하는 방법은 InputActionMap을 생성하는 방법과 동일합니다. 먼저 이동에 대해 설정하겠습니다. InputActionMap을 생성하며 같이 생성된 InputAction의 이름을 Move로 변경하겠습니다.

Action Properties의 액션/Action Type을 값으로 변경합니다. 값으로 변경하게 되면 아래의 Initial State Check 속성 대신 Control Type 속성이 생기게 됩니다. 이 값을 Vector2로 변경합니다.

이 Action Type은 어떠 것을 기준으로 키 입력이 됐는지 안됐는지를 정하는 옵션입니다.

• Value: 입력에 따른 값 반환(예. +: 오른쪽, -: 왼쪽)
• Button: 버튼이 눌렸는 지, 안눌렸는지에 따라 값 반환(예. 점프)

Control Type은 해당 키가 눌렀을 때, 스크립트에서 어떤 타입으로 반환받을 지, 설정하는 옵션이다. 이동의 경우, 바닥이라는 2차원을 이동하는 것이기 때문에 Vector2로 설정합니다.

이게 행동에 대한 키를 바인딩 해보겠습니다. Move의 오른쪽을 보면 더하기 버튼이 보입니다. 버튼을 누르면 바인딩 목록 중에 Add Up\Down\Left\Right Composite 항목을 선택하고 이름을 WASD로 설정합니다.

잠깐 정리하는 시간을 가져보겠습니다. 액션 에디터를 보면 각 항목들의 왼쪽에 노란색, 초록색, 파란색, 빨간색을 볼 수 있습니다. 각각의 색이 의미하는 것은 다음과 같습니다.

• 노란색: InputActionMap
• 초록색: InputAction
• 파란색: 바인딩 집합
• 빨간색: 바인딩 설정

유니티에서 InputActionMap, InputAction같은 명칭을 설명한 것은 있지만 아닌 것도 있어 색으로 잠시 정리해봤습니다.

이제 바인딩을 설정해보겠습니다. WASD의 항목 중 하나를 눌러보면 Binding의 Path 항목을 볼 수 있습니다. Path이라는 이름만 보면 경로를 생각하게 되지만 바인딩할 키를 의미합니다.

WASD란 이름에 맞게 UP: W, Down: S, Left: A, Right: D로 설정합니다.

키 입력에 대한 한 가지 팁을 드리자면 Path을 눌렀을 때, 왼쪽 상단의 Listen 버튼을 눌르면 입력 받은 키가 출력됩니다. 맞으면 해당 키를 선택하면 됩니다.

참고 자료

Unity Blog Unity Manual Dibrary

Line Renderer 컴포넌트는 3D 공간에서 두 개 이상의 지점 배열을 가져와 각각의 점 사이에 직선을 그리는 컴포넌트입니다. 라인 렌더러를 사용하여 간단한 직선에서부터 파형, 다각형 등의 복잡한 나선에 이르기까지 모든 것을 그릴 수 있습니다. 다만 그려지는 모든 라인은 연속적이어야 합니다. 두 개 이상의 완전히 분리된 선을 그려야하는 경우 라인 렌더러를 포함한 여러 개의 게임 오브젝트를 사용해야 합니다.

라인 렌더러는 픽셀 단위 너비의 라인같은 가는 선은 렌더링하지 않고 월드 공간 단위 너비의 폴리곤을 렌더링합니다. 또한 트레일 렌더러와 동일한 알고리즘을 라인 렌더링에 사용합니다.

라인 설정

라인 그리기

LineRenderer 컴포넌트는 Position 프로퍼티의 위치를 기반으로 인덱스 순서대로 라인을 연결합니다. positionCount 메소드로 Position의 개수를 설정한 후, SetPosition 메소드로 Position의 위치를 설정하면 됩니다.

using UnityEngine;

[RequreComponent(typeof(LineRenderer))]
public class LineGenerator : Monobehaviour
{
    private LineRenderer _lineRenderer;

    private void Awake()
    {
        _lineRenderer = GetComponent<LineRenderer>();
    }

    public void StopDraw()
    {
        _lineRenderer.enable = false;
    }

    /// <summary>
    /// start와 end를 잇는 라인을 그리는 메소드
    /// </summary>
    /// <param name="start">시작점</param>
    /// <param name="end">끝점</param>
    public DrawLine(Vector3 start, Vector3 end)
    {
        if (_lineRenderer.enabled == false)
                _lineRenderer.enabled = true;
        _lineRenderer.positionCount = 2;
        _lineRenderer.loop = false;

        _lineRenderer.SetPosition(0, start);
        _lineRenderer.SetPosition(1, end);
    }

    /// <summary>
    /// Positions의 정보로 라인을 그리는 메소드
    /// </summary>
    /// <param name="positions"></param>
    public void DrawLine(Vector3[] positions)
    {
        if (_lineRenderer.enabled == false)
            _lineRenderer.enabled = true;
        _lineRenderer.positionCount = positions.Length;
        _lineRenderer.loop = false;

        for(int i = 0; i < positions.Length; i++)
        {
            _lineRenderer.SetPosition(i, positions[i]);
        }
    }
}

정다각형 그리기

다각형 꼭지점

다각형의 특징은 원에 내접하며 각각의 내접한 꼭지점과 원점의 거리가 모두 같은 특징을 지닙니다. 이를 이용해 정다각형을 그릴 수 있고 크게 2가지 방법이 있습니다.

1. Vector3 X Rotation을 이용한 좌표 계산
2. 삼각 함수를 이용한 좌표 계산

첫 번재 방법은 정말 간단합니다. 초기값 $P_0$(0, 반지름)을 구한 다음, Quaternion.AngleAxis 메소드를 곱하면 $\theta$만큼 회전된 위치 값이 나옵니다.

주의점 'Vector3 X Rotation'이라 제목을 붙였지만 계산 순서는 Rotation X Vector3 순입니다. 역순으로 계산할 경우 에러가 발생합니다.

두 번째 방법은 약간의 수학 지식이 필요합니다. 반지름이 1일 때, $Sin(\theta)$, $Cos(\theta)$의 점 $P$의 좌표 값이 구해집니다. 즉, $x = Cos(\theta) * R$, $y = Sin(\theta) * R$ 이라는 것을 알 수 있습니다. 유니티에서는 Mathf 구조체에 게임 및 앱 개발에 일반적으로 필요한 삼각 함수, 로그 함수, 기타 함수를 필요한 일반적인 함수 컬렉션을 제공하기 때문에 이를 이용하면 쉽게 구현할 수 있습니다.

주의점 Mathf에서 제공하는 삼각 함수의 매개 변수는 라디안을 기준으로 작동합니다. angle * Mathf.Deg2Rad를 계산하면 각도가 라디안으로 변환됩니다(반대로 라디안 -> 각도로 변환할 땐, Mathf.Rad2Deg를 곱하면 됩니다).

public class PolygonPositionsGenerator
{
    /// <summary>
    /// Vector3 x Rotation 기반 Position 계산하는 메소드
    /// </summary>
    /// <param name="numberOfPolygonPoint">다각형 꼭지점 개수</param>
    /// <param name="radius">반지름</param>
    /// <returns>다각형 꼭지점 위치</returns>
    public static Vector3[] GetPolygonPoisitionsVectorMulRotation(int numberOfPolygonPoint, float radius)
    {
        List<Vector3> positions = new List<Vector3>();
        float angle = 360f / numberOfPolygonPoint;

        positions.Add(new Vector3(0, 0, radius));
        for(int i = 1; i < numberOfPolygonPoint; i++)
        {
            positions.Add(Quaternion.AngleAxis(angle, Vector3.up) * positions[i - 1]);
        }

        return positions.ToArray();
    }

    /// <summary>
    /// 삼각 함수 기반 Position 계산하는 메소드
    /// </summary>
    /// <param name="numberOfPolygonPoint">다각형 꼭지점 개수</param>
    /// <param name="radius">반지름 </param>
    /// <returns>다각형 꼭지점 위치</returns>
    public static Vector3[] GetPolygonPositionsAngleFunction(int numberOfPolygonPoint, float radius)
    {
        List<Vector3> positions = new List<Vector3>();
        float angle = 360f / numberOfPolygonPoint;
        float currentAngle = 0f;

        for (int i = 0; i < numberOfPolygonPoint; i++)
        {
            float radian = Mathf.Deg2Rad * currentAngle;

            float x = Mathf.Cos(radian) * radius;
            float z = Mathf.Sin(radian) * radius;
            currentAngle += angle;

            positions.Add(new Vector3(x, 0, z));
        }

        return positions.ToArray();
    }
}

참고 자료

Unity Documentation 고박사

nullptr 키워드는 null 포인터를 나타내는 상수 리터럴로 std::nullptr_t 타입의 prvalue입니다. nullptr 키워드는 헤더를 포함하지 않고 사용할 수 있지만 std::ptr_t 타입을 사용하려면 <cstddef> 헤더를 포함해야 합니다.

std::nullptr_t 타입은 암시적으로 모든 타입의 포인터로 형 변환이 가능합니다.

NULL의 문제

C++에 객체지향 패러다임이 적용되면서 오버로딩을 지원하게 되면서 NULL을 사용할 때, 문제가 발생하게 됩니다.

오버로딩을 간단하게 설명하면 똑같은 이름을 사용하지만 다른 매개 변수를 갖는 함수를 뜻합니다.

#include <iostream>

using namespace std;

void func(int n)
{
    cout << "call void func(int)" << endl;
}

void func(int* p)
{
    cout << "call void func(int*)" << endl;
}

int main()
{
    func(0);
    func(NULL);
    func(nullptr);
}

[출력 결과]
call void func(int)
call void func(int)
call void func(int*)

프로그래머는 NULL을 전달하며 void func(int*)가 호출되는 것을 의도했겠지만 NULL은 0으로 정의된 매크로이기 때문에 void func(int)가 호출됩니다. 하지만 nullptr을 전달할 경우 의도대로 void func(int*)가 호출되는 것을 볼 수 있습니다.

포인터를 초기화할 때, nullptr 키워드와 NULL은 똑같이 0으로 초기호되지만, 매개 변수로 전달될 때, NULL은 0으로 정의된 상수이기 때문에 컴파일러가 void func(int)로 호출하지만 nullptr은 std::nullptr_t 타입의 상수 리터럴이기 때문에 void func(int*)가 호출되는 것입니다.

nullptr을 사용해야 하는 이유

nullptr 키워드를 사용하면 위의 상황처럼 의도치 못한 오류의 가능성을 없애 안전성을 높일 뿐만 아니라 코드의 가독성까지 높이기 때문에 C++11 이후의 버전에서 nullptr 키워드 대신 NULL을 사용해야 할 이유가 없습니다.

NULL을 비어있다라는 의미로 초기화 하는 경우도 있기 때문에 NULL을 보고 null 포인터라고 판단할 수 없지만, nullptr 키워드는 null 포인터임을 알 수 있어 코드의 가독성이 높아집니다.

참고 자료

cppreference VisualC++ Docs BlockDMask 냉정과 열정 사이

for ( element-type element-name : data-list )

• element-type - data-list의 요소의 데이터 타입
• element-name - data-list의 요소에 접근할 변수명
• data-list - 배열, vector 등의 순회가 가능한 데이터 리스트

설명

배열, 벡터 등의 데이터 리스트 자료형을 순회해야 할 때, 보통 인덱스와 데이터 리스트의 길이를 이용합니다. 정확한 인덱스를 설정했다면 문제없지만 프로그래머의 실수로 잘못된 인덱스를 설정한다면 에러가 발생하게 됩니다.

범위기반 for 문은 기존의 for 문과 달리 스스로 데이터 리스트의 처음부터 끝까지 순회하는 반복문입니다. 스스로 순회 범위를 판단하기 때문에 인덱스 실수로 인한 에러를 줄일 수 있습니다.

#include <iostream>
#include <vector>

using namespace std;

int main()
{
    // 1. 배열
    int arr[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
    for(auto element : arr)
    {
        cout << element << endl;
    }

    // 2. STL
    vector<int> v = { 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 };
    for(auto element : v)
    {
        cout << element << endl;
    }
}

범위기반 for 문에서 접근한 요소는 값을 복사한 것입니다. 때문에 범위기반 for 문의 본문에서 요소를 변경하더라도 데이터 리스트에는 적용되지 않습니다. 또한 요소의 크기가 크다면 복사로 인한 성능 하락이 발생할 수도 있습니다.

범위기반 for 문에서 접근한 요소를 변경하고 복사로 인한 성능 하락을 피하는 방법은 간단합니다. 참조를 이용하는 것입니다.

#include <iostream>
#include <vector>

using namespace std;

int main()
{
    vector<int> v = { 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 };
    for(auto& element : v)
    {
        element += 1;
    }

    for(auto& element : v)
    {
        cout << element << endl;
    }
}

하지만 범위기반 for 문은 아이러니하게도 인덱스 때문에 기존의 for 문을 완전히 대체하지 못합니다. 범위기반 for문에는 인덱스를 나타내는 정보가 존재하지 않고 오직 요소의 정보만을 표시합니다. 때문에 인덱스를 분류나 연산을 할 수 없습니다.

굳이 하려면 할 수 있습니다. 하지만... '이럴거면 그냥 인덱스에 신경써서 기존의 for 문을 쓰는게 낮지 않나...?' 라는 생각이 들긴합니다.

#include <iostream>

using namespace std;

int main()
{
    int arr[] = { 1, 2, 3, 4 };
    int index = 0;
    for(auto& element : arr)
    {
        element += index++ * 2;
        cout << element << endl;
    }
}

참고 자료

VisualC++ Docs BlockDMask

[ capture ] ( params ) [:specifiers] [:exception] [:trailing return type] { body }

1. capture - 캡처
2. params - 매개 변수
3. [:specifiers] - 변경 가능한 사양
4. [:exception] - 예외 사양
5. [:trailing return type] - 후위 반환 형식
6. body - 본문

설명

lambda expression는 람다(lambda)라고 많이 불리며 함수 객체를 정의하는 편리한 방법입니다. 즉, 익명 함수를 뜻합니다. 람다 식은 일반적으로 알고리즘 또는 비동기 함수에 전달되는 몇 줄의 코드를 캡슐화하는데 사용됩니다.

#include <iostream>
#include <vector>
#include <algorithm>
#include <cmath>

using namespace std;

void absSort(vector<int>& origin)
{
    sort(origin.begin(), origin.end(),
        // 람다 식을 이용한 커스텀 Compare
        [](int left, int right) {
            return abs(left) < abs(right);
        }
    );
}

int main()
{
    vector<int> values = { -5, 4, 3, -2, 1 };
    absSort(values);
    for (auto value : values)
    {
        cout << value << endl;
    }
}

Capture

람다는 캡처를 이용해, 람다 외부에 정의되어 있는 변수나 상수를 람다 내부에서 사용할 수 있습니다. '매개 변수로 전달해 사용하면 되는 것 아닌가?' 의문이 들 수 있습니다.

외부에 있는 모든 변수와 상수에 대한 매개 변수를 정의할 수 없으며 STL을 사용할 경우, 제약이 발생할 수 있습니다. 때문에 이를 방지하기 위해 람다 내부와 소통할 수 있는 캡처 절을 제공하는 것입니다.

람대 외부에 정의된 변수나 상수를 캡처하는 방식으로 call-by-vaule, call-by-reference 두 가지가 존재합니다. 즉, 값으로 캡처하는가, 참조로 캡처하는가 차이입니다.

캡처 절에서는 다음과 같은 5가지 형태를 제공합니다(외부 변수 x, y, z가 존재).

1. [=] - 외부의 모든 변수나 상수들(x, y, z)을 값으로 가져온다.
2. [&] - 외부의 모든 변수나 상수들(x, y, z)을 참조로 가져온다.
3. [=, &x] - 외부의 모든 변수를나 상수들(y, z)을 값으로 가져오지만, x는 참조로 가져온다.
4. [&, y] - 외부의 모든 변수나 상수들(x, z)을 참조로 가져오지만, y는 값으로 가져온다.
5. [&y, z] - 선택한 변수나 상수(y z)를 지정한 방식(y: 참조, z: 값)에 따라 가져온다.

참조로 복사한 외부 변수는 대입 연산자를 통해 값을 변경할 수 있지만, 값으로 복사한 외부 변수는 대입 연산자를 통해 값을 변경할 수 없습니다.

params

람다는 결국 함수이기 때문에 매개 변수가 존재할 수 있습니다. 일반적인 함수들 처럼 매개 변수의 존재 여부에 상관 없이 소괄호(())를 사용해야 하지만 람다에서 매개 변수가 없을 경우, 소괄호를 생략할 수 있습니다.

// 매개 변수 X
[]() { cout << "매개 변수 X" << endl; }();
[] { cout << "매개 변수 X" << endl; }();

// 매개 변수 O
[](int a, int b) { cout << a + b << endl; }(1, 3);

람다 식을은 인수로 전달하거나 auto 키워드로 함수 포인터를 지정해 사용하지 않아도 본문을 정의한 중괄호({}) 뒤에 소괄호(())에 매개 변수를 전달하면 람다 식이 실행됩니다.

Specifiers

일반적으로 람다 식의 호출 연산자는 const-by-value이지만 mutable 키워드를 사용하면 이를 취소합니다.

exception

noxcept 키워드를 사용하여 람다 식이 예외를 throw하지 않음을 나타낼 수 있습니다. 일반 함수와 마찬가지로 람다 식이 noexcept 예외 사양을 선언하고 람다 본문이 예외를 throw하는 경우 에러가 발생합니다.

int main()
{
    [] () noexcept { throw 5; } (); // error!
}

trailing return type

람다 식의 반환 형식은 자동으로 추론되기 때문에 후행 반환 형식(trailing return type)을 지정하지 않아도 됩니다. 후행 반환 형식을 지정하고 싶은 경우 중괄호({}) 앞에 ->(후행 반환 형식) 키워드를 작성해 지정합니다.

[] { return 100; }();
[] () -> int { return 200; }();

body

람다 식의 본문은 일반 함수 또는 멤버 함수의 본문에 허용되는 모든 항목을 포함할 수 있습니다. 일반 함수와 람다 식 모두의 본문은 다음고 같은 종류의 변수에 접근할 수있습니다.

• 캡처 절에 의해 캡처된 변수
• 매개 변수
• 로컬 변수
• 클래스 내에서 선언되고 캡처되는 경우 클래스 this 데이터 멤버
• 정적 스토리지 기간에 있는 모든 변수(예: 전역 변수)

참고 자료

cppreference
VisualC++ Docs
BlockDMask
모두의 C++

auto variable-name = initializer ; auto variable-name = lambda expression|Function Pointer ;

• [variable-name] - 식별자
• initializer - 초기화 할 값
• expression - 람다식

설명

auto 키워드는 C++11 이전에는 다른 의미로 사용됐지만, 이후에는 컴파일러가 선언된 변수 또는 람다 식 매개 변수의 초기화 식을 사용하여 형식을 추록하도록 지시하는 키워드입니다.

즉, Java, C#의 'var' 키워드 처럼 초기화 값에 따라 타입을 정해주는 타입 추론 키워드입니다. char, int 등의 기본 타입형과 struct, class 등의 타입까지 추론 가능합니다. 또한 함수 포인터나 함수 자체(람다 함수)도 될 수 있습니다.

다음과 같은 이점을 제공하기 때문에 Visual C++에서는 대부분의 상황에서 auto 키워드를 사용하는 것을 권장하고 있습니다.

• 경고성 - 함수의 반환 형식이 변경되는 경우를 포함하여 식의 형식이 변경되어도 작동한다.
• 성능 - 변환이 없음을 보장한다.
• 유용성 - 형식 이름 맞춤법 오류 및 오타에 대한 걱정이 없다.
• 효율성 - 코딩이 더 효율적이다.

하지만 auto 키워드가 어느 곳에서나 사용되는 만능인 것은 아닙니다. 다음과 같은 제약사항이 존재합니다.

• auto 키워드는 다른 형식 지정자(int 등)와 결합할 수 없다.
• auto 키워드가 선언된 곳에는 이니셜라이저가 있어야 한다.
• 함수의 매개변수로 사용될 수 없다.
• 초기화 하기 전에 사용할 수 없다.
• auto 키워드 선언된 형식으로 캐스팅할 수 없다.
• auto 키워드에 sizeof 및 typeid 연산자를 사용할 수 없다.
• 구조체나 클래스 등의 멤버 변수로 사용할 수 없다.

Visual Studio 기준으로 auto로 선언한 변수명 위에 마우스를 가져다 대면 추론된 타입을 확인할 수 있습니다.

예) 값

auto type1 = 10;            // int
auto type2 = 10.f;            // float
auto type3 = 'c';            // char
auto type4 = "c";            // char const *
auto type5 = "String";        // char const *
auto type6 = { 1, 2, 3 };    // std::initializer_list<int>

auto 키워드는 C++11에서는 함수의 반환형으로 사용할 수 있지만 후행 반환 형식을 작성했을 경우에만 사용 가능합니다. 하지만 C++14 이상 부터는 제약없이 사용 가능합니다.

예) 함수

#include <iostream>
#include <vector>
#include <numeric>

using namespace std;

void increase(int value)
{
    cout << value + 1 << endl;
}

// `-> int`: 후행 반환 형식
// C++14 버전 이상이라면 작성하지 않아도 됨.
auto sum(vector<int> origin) -> int
{
    return accumulate(origin.begin(), origin.end(), 0);
}

int main()
{
    // 함수 포인터
    auto Increase = increase;

    // 람다 함수
    vector<int> indexList = { 1, 2, 3, 4, 5 };
    auto printIndexList = [&] {
        for (const auto& index : indexList)
            cout << index << endl;
    };

    Increase(5);
    printIndexList();
    cout << sum(indexList) << endl;
}

*, &, const

기본적으로 auto 키워드는 일반 타입 키워들과 동일한 문법을 공유하기 때문에 auto 키워드 앞과 뒤에 붙여서 사용할 수 있습니다.

#include <iostream>
#include <vector>

using namespace std;

int main()
{
    const auto target = 3;
    vector<int> indexList = { 1, 2, 3, 4, 5 };

    // 범위 기반 for문
    for(auto& index : indexList)
    {
        if(index >= target)
        {
            cout << index << endl;
        }
    }
}

참고 자료

cppreference VisualC++ Docs BlockDMask memOry

scoped enum: enum [class|struct] [variable-name] [:type] { [enum-list] } ;

• [class|struct] - 열거형의 범위(scope)를 지정
• [variable-name] - 열거형에 지정된 형식 이름
• [:type] (옵션, defalut: int) - 열거형의 기본 타입, 모든 열거자는 동일한 기본 형식을 갖고 모든 정수 계열 형식이 가능하다.
• enum-list - 열거형의 목록

설명

C++11 이전의 enum은 다음과 같은 3가지 문제점을 보여줍니다.

1. enum은 암시적으로 int로 형변환이 되어, 정수로써 작동되기 원하지 않을 때, 오류를 발생시킨다.
2. 허용 범위(scope) 밖에서도 열거자 이름들을 사용할 수 있기 때문에 이름 충돌이 발생한다.
3. 전진 선언(forward declaration)이 불가능하다.

enum class는 이러한 문제점을 보완하기 위해 추가된 기능입니다. 전통적인 enum의 특징(값을 가진 이름들)과 클래스의 특징(범위를 가진 멤버, 암시적 변환의 부재)을 함쳐 기존의 문제를 해결한 키워드이며 다음과 같은 특징을 지닙니다.

• enum class를 int로 형변환하고 싶다면 명시적으로 형변환을 해야 한다.
• 범위가 존재하며, 범위 밖의 열거자들의 이름 중복이 가능하다.
• 전진 선언이 가능하다.

// classic enum
// 이름 충돌 발생
enum AlertWindows { Green, Yellow, Election, Red };
//enum AlertLinux {  Green, Yellow, Election, Red };

// C++11 enum
enum class Color { Red, Blue, Green };
enum class TrafficLight : short { Red, Yellow, Green };
enum class HexColorCode : int;

int main()
{
    AlertWindows alertWindow = 1;                // 오류: 모든 C++ 버전에서 불가능

    int data1 = Red;                            // 암시적으로 int로 형변환 가능
    int data2 = AlertWindows::Red;                // 오류: C++11 이전 버전에서는 불가능
    int data3 = Blue;                            // 오류: 사용할 수 있는 범위를 밖이기 때문에 사용할 수 없음
    int data4 = Color::Blue;                    // 오류: enum class는 암시적으로 형변환 할 수 없음
    int data5 = (int)Color::Blue;                // 명시적으로 int로 형변환 가능
    int redHexCode = (int)HexColorCode::Red;    // C++11 부터 전방 선언 가능
}

enum class HexColorCode : int { Red, Blue, Green };

참고 자료

cppreference
VisualC++ Docs
BlockDMask
소년코딩