C++ 타입 소거(Type Erasure): std::function 내부 원리와 Concept·Model 직접 구현

Type Erasure란?

Type Erasure (타입 소거) 는 타입 정보를 숨기고 통일된 인터페이스로 다양한 타입을 처리하는 디자인 패턴입니다. 상속 없이도 다형성을 구현할 수 있으며, std::any, std::function 등이 이 패턴을 사용합니다.

#include <any>
#include <iostream>
// 필요한 모듈 import
using namespace std;

int main() {
    any a = 10;
    cout << any_cast<int>(a) << endl;  // 10
    
    a = 3.14;
    cout << any_cast<double>(a) << endl;  // 3.14
    
    a = string("Hello");
    cout << any_cast<string>(a) << endl;  // Hello
}

std::any는 가장 극단적인 형태의 타입 소거입니다. 어떤 타입이든 담을 수 있지만, 꺼낼 때 정확한 타입을 다시 알려 줘야 하고 담긴 값으로 할 수 있는 일이 거의 없습니다. 이 글에서 주로 다루는 것은 그 중간 형태로, “draw()를 할 수 있는 것이면 무엇이든”처럼 필요한 동작만 남기고 나머지 타입 정보를 지우는 방식입니다. std::function<int(int, int)>가 “int 두 개를 받아 int를 반환하는 호출 가능한 것이면 무엇이든”을 담는 것과 같은 원리입니다.

왜 필요한가?:

• 상속 불필요: 기존 타입을 수정하지 않고 다형성 구현
• 유연성: 컴파일 타임에 타입을 알 수 없을 때
• 디커플링: 타입 간 의존성 제거
• 재사용성: 다양한 타입에 대해 동일한 인터페이스 제공

// ❌ 가상 함수: 상속 필요
// 타입 정의
class Shape {
public:
    virtual void draw() = 0;
};

class Circle : public Shape {  // 상속 필요
    void draw() override {}
};

// ✅ Type Erasure: 상속 불필요
class Drawable {
    // 내부 구현...
};

class Circle {  // 상속 불필요!
    void draw() {}
};

Drawable d = Circle();  // OK
d.draw();

Type Erasure의 구조:

아래 다이어그램은 Type Erasure의 구조를 보여줍니다. 각 부분의 역할을 이해하면서 살펴보시기 바랍니다.

graph TD
    A[Drawable 외부 인터페이스] --> B[DrawableConcept 추상 인터페이스]
    B --> C[DrawableModel Circle]
    B --> D[DrawableModel Rectangle]
    C --> E[Circle 객체]
    D --> F[Rectangle 객체]
    
    style A fill:#90EE90
    style B fill:#FFB6C1
    style C fill:#87CEEB
    style D fill:#87CEEB

Type Erasure vs 가상 함수:

특징	가상 함수	Type Erasure
상속	✅ 필요	❌ 불필요
기존 타입 수정	✅ 필요	❌ 불필요
유연성	❌ 제한적	✅ 높음
구현 복잡도	✅ 낮음	❌ 높음
성능	가상 호출 1회	가상 호출 1회 + 보통 힙 할당 1회
값 의미론	❌ 포인터로 다룸	✅ 값처럼 복사·이동 가능(구현 시)

표의 성능 행은 흔히 오해되는 부분입니다. 아래 “수동 구현”을 보면 알 수 있듯, 타입 소거도 내부적으로는 가상 함수를 씁니다. 차이는 가상 함수 계층을 사용자 대신 라이브러리 안에 숨긴다는 것입니다. 그래서 호출 비용은 가상 함수와 같고, 추가 비용은 객체를 감쌀 때의 힙 할당 정도입니다. 반대로 얻는 것은 값 의미론입니다. 가상 함수 방식은 std::vector<std::unique_ptr<Shape>>처럼 포인터를 다뤄야 하지만, 타입 소거 방식은 std::vector<Drawable>에 값처럼 넣고 꺼낼 수 있으며, Circle은 Shape의 존재조차 몰라도 됩니다. 서드파티 라이브러리의 타입이나 int 같은 기본 타입까지 같은 인터페이스로 묶을 수 있다는 것이 상속으로는 불가능한 부분입니다.

// 가상 함수: 상속 필요
class Shape {
public:
    virtual void draw() = 0;
};

class Circle : public Shape {
    void draw() override {
        std::cout << "원\n";
    }
};

// Type Erasure: 상속 불필요
class Circle {  // Shape 상속 안함
public:
    void draw() const {
        std::cout << "원\n";
    }
};

Drawable d = Circle();  // OK

std::function

#include <functional>

int add(int a, int b) { return a + b; }

int main() {
    // 함수 포인터
    function<int(int, int)> f1 = add;
    
    // 람다
    function<int(int, int)> f2 = [](int a, int b) { return a * b; };
    
    // 함수 객체
    struct Multiply {
        int operator()(int a, int b) { return a * b; }
    };
    function<int(int, int)> f3 = Multiply();
    
    cout << f1(2, 3) << endl;  // 5
    cout << f2(2, 3) << endl;  // 6
    cout << f3(2, 3) << endl;  // 6
}

함수 포인터, 람다, 함수 객체는 C++ 타입 시스템에서 전부 다른 타입입니다. 람다는 하나하나가 컴파일러가 만든 고유한 클래스라, 똑같이 생긴 람다 두 개도 타입이 다릅니다. 그런데도 셋을 같은 function<int(int, int)> 변수에 담을 수 있는 것은, std::function이 생성될 때 넘어온 구체 타입을 기억하는 내부 모델 객체를 만들고 바깥에는 호출 시그니처만 남기기 때문입니다. 아래 “수동 구현”과 “패턴 3: 함수 래퍼”가 바로 그 내부 구조입니다.

std::function을 쓸 때 알아 둘 제약이 두 가지 있습니다. 비어 있는 std::function을 호출하면 std::bad_function_call 예외가 나고, 담을 callable이 복사 가능해야 합니다. std::unique_ptr을 캡처한 람다처럼 이동만 가능한 callable은 std::function에 넣을 수 없어 “use of deleted function” 에러가 나는데, C++23의 std::move_only_function이 이 문제를 해결합니다.

수동 Type Erasure 구현

class Drawable {
private:
    struct DrawableConcept {
        virtual void draw() const = 0;
        virtual ~DrawableConcept() {}
    };
    
    template<typename T>
    struct DrawableModel : DrawableConcept {
        T object;
        
        DrawableModel(T obj) : object(move(obj)) {}
        
        void draw() const override {
            object.draw();
        }
    };
    
    unique_ptr<DrawableConcept> self;
    
public:
    template<typename T>
    Drawable(T obj) : self(make_unique<DrawableModel<T>>(move(obj))) {}
    
    void draw() const {
        self->draw();
    }
};

class Circle {
public:
    void draw() const {
        cout << "원 그리기" << endl;
    }
};

class Rectangle {
public:
    void draw() const {
        cout << "사각형 그리기" << endl;
    }
};

int main() {
    vector<Drawable> shapes;
    shapes.push_back(Circle());
    shapes.push_back(Rectangle());
    
    for (const auto& shape : shapes) {
        shape.draw();
    }
}

이 구현이 타입 소거 패턴의 전형입니다. 세 부분으로 나누어 보면 이해가 쉽습니다.

• Concept(DrawableConcept): 지원할 동작(draw)을 순수 가상 함수로 선언한 내부 인터페이스입니다. 사용자는 이 클래스를 볼 수 없습니다.
• Model(DrawableModel<T>): 템플릿으로 어떤 T든 감싸서 Concept를 구현합니다. draw()는 object.draw()를 그대로 호출할 뿐이라, T에 draw() const만 있으면 상속 없이 동작합니다. 이 부분이 “덕 타이핑”을 컴파일 타임에 검사하는 자리이기도 합니다. draw()가 없는 타입을 넣으면 “‘class Foo’ has no member named ‘draw’” 에러가 DrawableModel 내부를 가리키며 납니다.
• 외부 클래스(Drawable): 템플릿 생성자로 아무 타입이나 받아 Model을 만들고, unique_ptr<Concept>로 보관합니다. 생성자가 끝나는 순간 T라는 정보는 사라지고 “draw할 수 있는 무언가”만 남습니다. 이것이 “타입을 지운다”는 뜻입니다.

이 구현을 그대로 쓰면 곧 만나는 함정이 있습니다. 첫째, unique_ptr 멤버 때문에 Drawable은 이동만 가능하고 복사가 안 됩니다. vector<Drawable>에 넣는 것은 되지만 Drawable d2 = d1;은 컴파일되지 않습니다. 복사가 필요하면 Q7처럼 clone()을 추가해야 합니다. 둘째, 더 교묘한 문제로 생성자를 최적화하려고 template<typename T> Drawable(T&& obj)처럼 전달 참조로 바꾸는 순간 템플릿 생성자가 복사·이동 생성자를 가로챕니다. Drawable d2 = d1;에서 d1이 비const 좌측값이면 T = Drawable&인 템플릿이 const Drawable&를 받는 복사 생성자보다 더 정확히 일치해 선택되고, Drawable을 다시 DrawableModel<Drawable>로 감싸려다 알아보기 어려운 에러를 쏟아 내거나, 복사 가능한 구현이라면 에러 없이 감싼 것을 또 감싸는 이상한 객체가 만들어집니다. 위 코드처럼 값으로 받는 Drawable(T obj)는 표준 규칙상 T = Drawable로 인스턴스화되지 않아 이 문제를 피합니다. 전달 참조를 쓴다면 C++20의 template<typename T> requires (!std::same_as<std::remove_cvref_t<T>, Drawable>)처럼 자기 자신은 제외하는 제약을 거는 것이 정석입니다.

예시 1: 콜백 시스템

#include <functional>
#include <vector>

class EventSystem {
private:
    vector<function<void(int)>> handlers;
    
public:
    template<typename Func>
    void subscribe(Func&& handler) {
        handlers.push_back(forward<Func>(handler));
    }
    
    void trigger(int value) {
        for (auto& handler : handlers) {
            handler(value);
        }
    }
};

void globalHandler(int x) {
    cout << "전역 함수: " << x << endl;
}

int main() {
    EventSystem events;
    
    // 전역 함수
    events.subscribe(globalHandler);
    
    // 람다
    events.subscribe([](int x) {
        cout << "람다: " << x << endl;
    });
    
    // 함수 객체
    struct Printer {
        void operator()(int x) {
            cout << "함수 객체: " << x << endl;
        }
    };
    events.subscribe(Printer());
    
    events.trigger(42);
}

EventSystem은 핸들러를 어떤 형태로 받을지 전혀 신경 쓰지 않습니다. subscribe를 템플릿으로 만들고 std::forward로 넘긴 덕분에 임시 람다는 이동되고, 이름 있는 함수 객체는 복사되어 std::function 안에 저장됩니다. 이런 콜백 목록은 타입 소거가 가장 자연스럽게 쓰이는 곳입니다.

실무에서 이 구조를 쓸 때 문제가 되는 것은 해제입니다. std::function은 서로 비교할 수 없어서(operator==가 없음) 등록한 람다를 나중에 찾아서 지울 방법이 없습니다. 보통 subscribe가 id나 구독 토큰을 반환하게 하고, 토큰으로 해제하도록 설계합니다. 또 람다가 this나 지역 변수를 참조로 캡처한 채 등록되면, 객체가 먼저 파괴된 뒤 trigger가 호출될 때 댕글링 참조로 크래시합니다. 저는 이벤트 시스템에서 생기는 크래시의 대부분이 이 경우였는데, 등록한 쪽의 소멸자에서 반드시 구독을 해제하도록 RAII 토큰을 쓰는 것이 가장 확실한 해결책이었습니다.

예시 2: 타입 안전 any

class TypeSafeAny {
private:
    struct Holder {
        virtual ~Holder() {}
    };
    
    template<typename T>
    struct HolderImpl : Holder {
        T value;
        HolderImpl(T v) : value(move(v)) {}
    };
    
    unique_ptr<Holder> content;
    
public:
    template<typename T>
    TypeSafeAny(T value) : content(make_unique<HolderImpl<T>>(move(value))) {}
    
    template<typename T>
    T* get() {
        if (auto* holder = dynamic_cast<HolderImpl<T>*>(content.get())) {
            return &holder->value;
        }
        return nullptr;
    }
};

int main() {
    TypeSafeAny a = 42;
    
    if (int* p = a.get<int>()) {
        cout << *p << endl;  // 42
    }
    
    if (string* p = a.get<string>()) {
        cout << *p << endl;
    } else {
        cout << "타입 불일치" << endl;
    }
}

이 TypeSafeAny는 std::any의 원리를 보여 줍니다. Concept인 Holder에는 동작이 하나도 없고(가상 소멸자뿐) 값만 담습니다. 동작이 없으니 꺼낼 때 원래 타입을 물어보는 수밖에 없고, 여기서는 dynamic_cast로 “혹시 HolderImpl<T>인가?”를 확인합니다. 그래서 std::any류의 타입 소거는 정확히 같은 타입으로만 꺼낼 수 있습니다. int를 넣고 long으로 꺼내면 변환 가능한 타입인데도 실패합니다. 이 구현은 dynamic_cast를 쓰므로 RTTI가 꺼진 빌드(-fno-rtti)에서는 동작하지 않고, 실제 std::any는 typeid 비교나 타입별 고유 주소 같은 더 가벼운 방법으로 타입을 확인합니다.

예시 3: 플러그인 시스템

class Plugin {
private:
    struct PluginConcept {
        virtual void execute() = 0;
        virtual string getName() = 0;
        virtual ~PluginConcept() {}
    };
    
    template<typename T>
    struct PluginModel : PluginConcept {
        T plugin;
        
        PluginModel(T p) : plugin(move(p)) {}
        
        void execute() override {
            plugin.execute();
        }
        
        string getName() override {
            return plugin.getName();
        }
    };
    
    unique_ptr<PluginConcept> self;
    
public:
    template<typename T>
    Plugin(T plugin) : self(make_unique<PluginModel<T>>(move(plugin))) {}
    
    void execute() {
        self->execute();
    }
    
    string getName() {
        return self->getName();
    }
};

class AudioPlugin {
public:
    void execute() {
        cout << "오디오 처리" << endl;
    }
    
    string getName() {
        return "AudioPlugin";
    }
};

class VideoPlugin {
public:
    void execute() {
        cout << "비디오 처리" << endl;
    }
    
    string getName() {
        return "VideoPlugin";
    }
};

int main() {
    vector<Plugin> plugins;
    plugins.push_back(AudioPlugin());
    plugins.push_back(VideoPlugin());
    
    for (auto& plugin : plugins) {
        cout << plugin.getName() << ": ";
        plugin.execute();
    }
}

“플러그인 시스템”이라는 이름에는 주의가 필요합니다. 이 예제의 플러그인은 모두 같은 프로그램에서 컴파일되는 타입이라, 템플릿 생성자가 컴파일 시점에 PluginModel<AudioPlugin>을 만들 수 있습니다. 공유 라이브러리(.so, .dll)로 따로 빌드해 런타임에 불러오는 진짜 플러그인이라면 템플릿이 경계를 넘을 수 없으므로, 결국 C 함수로 노출된 팩토리와 순수 가상 인터페이스(또는 C ABI 함수 테이블)를 쓰게 됩니다. 타입 소거가 빛나는 곳은 한 프로그램 안에서 서로 관련 없는 타입들을 같은 컨테이너에 모아야 할 때입니다.

std::any 활용

#include <any>
#include <map>

class PropertyBag {
private:
    map<string, any> properties;
    
public:
    template<typename T>
    void set(const string& key, T value) {
        properties[key] = value;
    }
    
    template<typename T>
    T get(const string& key) {
        return any_cast<T>(properties[key]);
    }
    
    bool has(const string& key) {
        return properties.find(key) != properties.end();
    }
};

int main() {
    PropertyBag props;
    
    props.set("width", 800);
    props.set("height", 600);
    props.set("title", string("My App"));
    
    cout << props.get<int>("width") << endl;
    cout << props.get<string>("title") << endl;
}

PropertyBag은 편리하지만 함정이 세 개 숨어 있습니다. 첫째, "title"을 string("My App")이 아니라 "My App"으로 넘기면 T가 const char*로 추론되어 저장되므로, get<string>이 std::bad_any_cast를 던집니다. std::any는 넣을 때의 정확한 타입을 기억하기 때문입니다. 둘째, get이 properties[key]를 쓰므로 없는 키를 조회하면 빈 any가 맵에 새로 삽입된 뒤 캐스트가 실패합니다. 조회 함수가 컨테이너를 바꾸는 것은 예상하기 어려운 부작용이라 find나 at을 써야 합니다. 셋째, 값을 복사해 반환하므로 큰 객체라면 매번 복사 비용이 듭니다. 이런 이유로 설정처럼 들어갈 타입이 정해져 있다면 std::map<std::string, std::variant<int, double, std::string>>이 더 안전합니다. 타입 목록이 컴파일 타임에 정해지고, std::visit로 모든 경우를 처리하도록 강제할 수 있습니다.

자주 발생하는 문제

문제 1: any_cast 실패

// ❌ 크래시
any a = 42;
string s = any_cast<string>(a);  // bad_any_cast 예외

// ✅ 안전한 캐스트
if (a.type() == typeid(int)) {
    int x = any_cast<int>(a);
}

// ✅ 포인터 캐스트
if (int* p = any_cast<int>(&a)) {
    cout << *p << endl;
}

문제 2: function 복사 비용

// ❌ 큰 람다 캡처
vector<int> bigData(1000000);
function<void()> f = [bigData]() {  // 복사!
    // ...
};

// ✅ 참조 캡처
function<void()> f = [&bigData]() {
    // ...
};

값 캡처한 람다는 bigData 전체를 람다 객체 안에 복사하고, std::function은 그 람다를 내부 버퍼에 담을 수 없어 힙에 할당합니다. 그리고 std::function 자체를 복사할 때마다 람다와 캡처한 벡터도 통째로 복사됩니다. 콜백 목록을 값으로 넘기거나 vector<function<...>>가 재할당될 때 이 비용이 반복됩니다.

다만 ”✅ 참조 캡처”는 bigData가 f보다 오래 산다는 보장이 있을 때만 올바른 해결책입니다. f를 멤버 변수나 이벤트 목록에 저장하고 bigData가 먼저 사라지면 댕글링 참조가 됩니다. 소유권을 람다로 넘기고 싶다면 [data = std::move(bigData)]로 이동 캡처하고, 여러 콜백이 함께 써야 한다면 std::shared_ptr로 감싸 포인터만 캡처하는 편이 안전합니다. 이동 캡처한 람다도 std::function을 복사하는 순간 벡터가 복사되므로, 복사가 잦다면 앞서 말한 std::move_only_function이나 shared_ptr 방식을 고려하세요.

문제 3: 타입 정보 손실

// ❌ 타입 정보 손실
any a = Circle();
// Circle의 메서드를 직접 호출 불가

// ✅ Type Erasure 패턴으로 인터페이스 제공
Drawable d = Circle();
d.draw();  // OK

Type Erasure vs 가상 함수

// 가상 함수
class Shape {
public:
    virtual void draw() = 0;
};

class Circle : public Shape {
    void draw() override {}
};

// Type Erasure
class Drawable {
    // 내부 구현...
};

class Circle {  // 상속 불필요!
    void draw() {}
};

장점:

• 상속 불필요
• 기존 타입 수정 불필요
• 더 유연함

단점:

• 구현 복잡
• 약간의 오버헤드

실무 패턴

패턴 1: 타입 안전 메시지 큐

class Message {
private:
    struct MessageConcept {
        virtual void process() = 0;
        virtual ~MessageConcept() {}
    };
    
    template<typename T>
    struct MessageModel : MessageConcept {
        T message;
        
        MessageModel(T msg) : message(std::move(msg)) {}
        
        void process() override {
            message.process();
        }
    };
    
    std::unique_ptr<MessageConcept> self_;
    
public:
    template<typename T>
    Message(T msg) : self_(std::make_unique<MessageModel<T>>(std::move(msg))) {}
    
    void process() {
        self_->process();
    }
};

// 사용
struct TextMessage {
    std::string content;
    void process() const {
        std::cout << "텍스트: " << content << '\n';
    }
};

struct ImageMessage {
    std::vector<uint8_t> data;
    void process() const {
        std::cout << "이미지: " << data.size() << " bytes\n";
    }
};

std::queue<Message> queue;
queue.push(TextMessage{"Hello"});
queue.push(ImageMessage{{1, 2, 3}});

메시지 큐에 타입 소거를 쓰면 TextMessage와 ImageMessage가 공통 기반 클래스 없이 값으로 한 큐에 들어갑니다. 큐가 Message 객체를 소유하므로 new/delete를 직접 쓸 일도 없습니다. 각 메시지 타입은 process() 하나만 제공하면 되고, 새 메시지 종류를 추가해도 큐 코드는 바뀌지 않습니다. 여러 스레드가 이 큐를 쓴다면 std::queue는 스레드 안전하지 않으므로 뮤텍스로 감싸야 하고, Message가 이동 전용이라 queue.front()를 꺼낼 때는 auto msg = std::move(queue.front()); queue.pop(); 순서로 처리해야 합니다.

메시지 종류가 닫혀 있다면(모든 종류를 알고 있고 자주 늘지 않는다면) std::variant<TextMessage, ImageMessage>가 더 나은 선택일 수 있습니다. 힙 할당이 없고, std::visit가 모든 종류를 처리했는지 컴파일러가 검사해 줍니다. 타입 소거는 종류가 열려 있어서 큐를 정의하는 쪽이 모든 메시지 타입을 미리 알 수 없을 때 가치가 있습니다.

패턴 2: 커맨드 패턴

class Command {
private:
    struct CommandConcept {
        virtual void execute() = 0;
        virtual void undo() = 0;
        virtual ~CommandConcept() {}
    };
    
    template<typename T>
    struct CommandModel : CommandConcept {
        T command;
        
        CommandModel(T cmd) : command(std::move(cmd)) {}
        
        void execute() override {
            command.execute();
        }
        
        void undo() override {
            command.undo();
        }
    };
    
    std::unique_ptr<CommandConcept> self_;
    
public:
    template<typename T>
    Command(T cmd) : self_(std::make_unique<CommandModel<T>>(std::move(cmd))) {}
    
    void execute() { self_->execute(); }
    void undo() { self_->undo(); }
};

// 사용
struct AddCommand {
    int& value;
    int delta;
    
    void execute() { value += delta; }
    void undo() { value -= delta; }
};

int value = 0;
std::vector<Command> history;
history.push_back(AddCommand{value, 10});
history.back().execute();  // value = 10
history.back().undo();     // value = 0

커맨드 패턴은 실행 취소(undo) 기록을 남겨야 해서 서로 다른 커맨드 타입을 한 vector에 쌓아야 하므로 타입 소거와 잘 맞습니다. 이 예제에서 조심할 부분은 AddCommand가 int& value로 대상을 참조한다는 점입니다. 기록이 대상 객체보다 오래 살아남는 구조라면(문서를 닫았는데 undo 기록은 남아 있는 경우 등) 참조가 댕글링됩니다. 또 참조 멤버가 있는 구조체는 대입 연산자가 암시적으로 삭제되어 일부 컨테이너 연산에서 컴파일 에러가 날 수 있습니다. 실무에서는 대상을 id나 핸들로 가리키고 실행 시점에 찾아오는 방식이 더 안전합니다.

패턴 3: 함수 래퍼

template<typename Signature>
class Function;

template<typename R, typename... Args>
class Function<R(Args...)> {
private:
    struct Callable {
        virtual R call(Args... args) = 0;
        virtual ~Callable() {}
    };
    
    template<typename F>
    struct CallableImpl : Callable {
        F func;
        
        CallableImpl(F f) : func(std::move(f)) {}
        
        R call(Args... args) override {
            return func(std::forward<Args>(args)...);
        }
    };
    
    std::unique_ptr<Callable> callable_;
    
public:
    template<typename F>
    Function(F func) : callable_(std::make_unique<CallableImpl<F>>(std::move(func))) {}
    
    R operator()(Args... args) {
        return callable_->call(std::forward<Args>(args)...);
    }
};

// 사용
Function<int(int, int)> add = [](int a, int b) { return a + b; };
std::cout << add(2, 3) << '\n';  // 5

template<typename R, typename... Args> class Function<R(Args...)>는 부분 특수화로 함수 타입 int(int, int)를 반환 타입 R과 매개변수 목록 Args...로 분해합니다. std::function<int(int, int)>라는 익숙한 문법이 이렇게 만들어집니다. 이 최소 구현과 실제 std::function의 가장 큰 차이는 작은 객체 최적화(SBO)입니다. 이 구현은 캡처 없는 람다 하나를 담을 때도 make_unique로 힙 할당을 하지만, 표준 구현은 객체 안에 작은 버퍼를 두고 크기가 작은 callable(함수 포인터, 캡처 없는 람다, 포인터 한두 개를 캡처한 람다)은 그 버퍼에 직접 저장해 힙 할당을 피합니다. 버퍼 크기는 구현마다 다르며 대략 포인터 2~4개 분량입니다. 타입 소거를 직접 구현해 성능이 문제가 된다면 가장 먼저 도입하는 최적화가 이것입니다.

FAQ

Q1: Type Erasure는 언제 사용하나요?

A:

• 상속 없이 다형성: 기존 타입을 수정할 수 없을 때
• 유연한 인터페이스: 다양한 타입을 통일된 방식으로 처리
• 플러그인 시스템: 런타임에 타입이 결정될 때
• 콜백 시스템: 다양한 callable 객체 저장

// 상속 없이 다형성
class Circle {  // Shape 상속 안함
    void draw() const {}
};

Drawable d = Circle();  // OK

Q2: any vs variant?

A:

• any: 어떤 타입이든 가능 (런타임 체크, 느림)
• variant: 정해진 타입 중 하나 (컴파일 타임 체크, 빠름)

// any: 모든 타입
std::any a = 42;
a = std::string{"hello"};
a = std::vector<int>{1, 2, 3};

// variant: 정해진 타입만
std::variant<int, std::string> v = 42;
v = std::string{"hello"};
// v = std::vector<int>{};  // 에러

Q3: function의 오버헤드는?

A: 약간의 오버헤드가 있습니다. 가상 함수 호출과 유사합니다.

// 직접 호출: 컴파일러가 인라인해 호출 자체가 사라질 수 있음
int add(int a, int b) { return a + b; }
add(2, 3);

// std::function: 간접 호출 1회, 인라인 불가
std::function<int(int, int)> f = add;
f(2, 3);

호출 한 번의 차이는 수 나노초 수준이라 대부분의 코드에서는 의미가 없습니다. 비용이 드러나는 것은 호출 자체보다 인라인이 막힌다는 점입니다. 정렬 비교 함수처럼 한 줄짜리 함수가 수백만 번 호출되는 핫 루프에서는, 인라인되지 않으면 컴파일러가 루프 전체를 최적화하지 못해 차이가 커집니다. 정확한 수치는 CPU와 컴파일러에 따라 크게 달라지므로 필요하면 직접 측정하세요.

권장: 성능이 중요하면 템플릿 사용

Q4: Type Erasure 구현은 어렵나요?

A: 복잡합니다. 가능하면 std::any, std::function을 사용하세요.

// ✅ std::function 사용 (간단)
std::function<void()> callback = []() {
    std::cout << "Hello\n";
};

// ❌ 직접 구현 (복잡)
// Concept, Model, 외부 인터페이스 필요

Q5: 성능이 중요하면?

A: 가상 함수나 CRTP를 고려하세요.

// 가상 함수: 빠름, 상속 필요
class Shape {
    virtual void draw() = 0;
};

// CRTP: 매우 빠름, 복잡
template<typename Derived>
class Shape {
    void draw() {
        static_cast<Derived*>(this)->draw_impl();
    }
};

// Type Erasure: 유연함, 약간 느림
class Drawable {
    // ...
};

Q6: Type Erasure의 메모리 할당은?

A: 동적 할당이 필요합니다. 작은 객체는 Small Object Optimization (SOO)을 사용할 수 있습니다.

// 동적 할당
Drawable d = Circle();  // new로 할당

// std::function: SOO 사용
std::function<void()> f = []() {};  // 작은 람다: function 객체 내부 버퍼 (힙 할당 없음)
std::function<void()> f2 = [bigData]() {};  // 큰 람다: 힙

Q7: Type Erasure는 복사 가능한가요?

A: 구현에 따라 다릅니다. 복사를 지원하려면 clone() 메서드가 필요합니다.

struct DrawableConcept {
    virtual void draw() const = 0;
    virtual std::unique_ptr<DrawableConcept> clone() const = 0;  // 복사
    virtual ~DrawableConcept() {}
};

template<typename T>
struct DrawableModel : DrawableConcept {
    T object;
    
    std::unique_ptr<DrawableConcept> clone() const override {
        return std::make_unique<DrawableModel>(object);
    }
};

Q8: Type Erasure 학습 리소스는?

A:

• “C++ Software Design” by Klaus Iglberger
• Sean Parent의 “Inheritance Is The Base Class of Evil” 발표
• Boost.TypeErasure 라이브러리

관련 글: any, variant, std::function vs 함수 포인터, virtual-functions.

Type Erasure는 타입 정보를 숨기고 상속 없이 다형성을 구현하는 디자인 패턴입니다.

---

같이 보면 좋은 글

• C++17 std::any: any_cast 동작, variant·void*와의 차이, 성능 오버헤드
• C++ 기본 인자 규칙: 헤더에만 두는 이유와 가상 함수에서 생기는 함정
• C++ 반환 방식 고르기: 값·레퍼런스·포인터 반환, RVO를 막는 return std::move
• C++ std::function vs 함수 포인터
• C++ std::any vs void*
• C++ CRTP 패턴

---