1. 실제 객체에 static_cast 를 사용하면 무슨 일이 일어날까?

C++에서 static_cast 를 실제 객체에 적용하면, 대상 타입의 임시 객체(temporary object)가 새로 생성됩니다.
즉,

• 복사 생성자 또는 변환 연산자를 통해 원본 객체의 해당 부분(예를 들어, 파생 클래스의 Base 부분)만 복사합니다.
• 이때, 파생 클래스에서 추가된 멤버들은 복사되지 않으며, 그 결과 객체 슬라이싱(object slicing)이 발생하게 됩니다.

아래 예시 코드를 통해 이를 살펴볼 수 있습니다:

#include <iostream>
using namespace std;

class Base {
public:
    int base_val;
    Base(int val = 0) : base_val(val) {}

    virtual void show() const {
        cout << "Base: " << base_val << "\n";
    }
};

class Derived : public Base {
public:
    int derived_val;
    Derived(int base, int derived) : Base(base), derived_val(derived) {}

    // Derived 클래스의 show()는 파생 클래스의 추가 정보를 출력합니다.
    void show() const override {
        cout << "Derived: " << base_val << ", " << derived_val << "\n";
    }
};

int main() {
    Derived d(1, 2);

    // 객체를 값으로 static_cast 하면, 새로운 Base 객체(임시 객체)가 생성되고,
    // Derived의 추가 멤버(derived_val)는 잘려나갑니다.
    Base b = static_cast<Base>(d);
    cout << "After object static_cast (객체 슬라이싱 발생):\n";
    b.show();  // Base::show() 호출, 결과: "Base: 1"

    // 포인터나 참조를 static_cast 하면, 원본 객체를 가리키므로 슬라이싱이 발생하지 않습니다.
    Base& b_ref = static_cast<Base&>(d);
    cout << "After reference static_cast (슬라이싱 없음):\n";
    b_ref.show();  // Derived::show() 호출, 결과: "Derived: 1, 2"

    return 0;
}

위 코드에서 Base b = static_cast<Base>(d); 는 Derived 객체 d 의 Base 부분만을 복사하여 임시 객체를 만들고, 그 결과로 객체 슬라이싱이 발생합니다. 반면, Base& b_ref = static_cast<Base&>(d); 는 단순히 원본 객체를 참조하기 때문에, 가상 함수 호출 시 실제 객체인 Derived 의 함수가 호출됩니다.

2. 복사 생성자를 삭제하면 어떻게 될까?

만약 객체의 복사 생성자가 명시적으로 삭제되었다면, static_cast 를 통해 값 변환(즉, 임시 객체 생성을 요구하는 변환)을 수행할 때 컴파일 오류가 발생합니다.
즉, static_cast 로 객체를 값으로 변환하려고 하면 내부적으로 복사 생성자(또는 이동 생성자)가 호출되는데, 복사 생성자가 삭제된 경우 그 호출이 불가능하여 컴파일러가 에러를 내게 됩니다.

예를 들어보면:

#include <iostream>
using namespace std;

class Base {
public:
    int base_val;
    Base(int val = 0) : base_val(val) {}

    // 복사 생성자를 명시적으로 삭제
    Base(const Base&) = delete;

    virtual void show() const {
        cout << "Base: " << base_val << "\n";
    }
};

class Derived : public Base {
public:
    int derived_val;
    Derived(int base, int derived) : Base(base), derived_val(derived) {}

    void show() const override {
        cout << "Derived: " << base_val << ", " << derived_val << "\n";
    }
};

int main() {
    Derived d(1, 2);

    // 아래 코드는 컴파일 에러를 발생시킵니다.
    // static_cast 를 사용하면 임시 객체 생성을 위해 복사 생성자가 호출되는데, 
    // 복사 생성자가 삭제되어 있으므로 컴파일 되지 않습니다.
    // Base b = static_cast<Base>(d);

    // 반면, 참조를 이용한 캐스팅은 임시 객체 생성을 요구하지 않으므로 정상적으로 작동합니다.
    Base& b_ref = static_cast<Base&>(d);
    b_ref.show();  // 올바르게 Derived::show() 호출, 결과: "Derived: 1, 2"

    return 0;
}

이처럼 복사 생성자가 삭제된 클래스에 대해 객체를 값으로 static_cast 하려고 하면 복사 생성자가 필요하기 때문에 컴파일 오류가 발생합니다.
반면, 포인터나 참조를 사용한 캐스팅은 객체 복사가 일어나지 않으므로 이러한 문제가 발생하지 않습니다.

3. 객체 슬라이싱과 가상 함수 포인터(virtual function pointer)의 메모리 레이아웃

객체 슬라이싱이 발생하면, 파생 클래스의 추가 데이터는 새로 생성된 임시 객체에 복사되지 않습니다. 이와 함께 가상 함수 포인터(vptr) 의 관리에도 중요한 변화가 있습니다.

• 메모리 레이아웃 측면: 일반적으로 C++ 객체의 메모리 레이아웃은 vptr(만약 가상 함수가 있다면)와 데이터 멤버들로 구성됩니다.

  • Derived 객체는 자신만의 vptr(보통 Derived 클래스의 vtable을 가리킴)과 추가 멤버들을 포함합니다.
  • 하지만, 객체 슬라이싱을 통해 Base 임시 객체가 생성되면, 이 객체는 Base 클래스의 복사 생성자를 통해 만들어집니다.

• 가상 함수 호출과 vptr의 역할: 임시 Base 객체는 Base 타입의 객체로서 생성되기 때문에,

  • 생성 과정에서 Base 클래스의 생성자(또는 복사 생성자)가 실행되고,
  • 이에 따라 vptr은 Base 클래스의 vtable을 가리키도록 초기화됩니다.

  결과적으로, 임시 객체에서는 가상 함수 호출 시 Base 클래스의 구현이 사용됩니다.
  즉, Derived 객체였던 원본과는 달리, 임시 객체는 오직 Base 클래스의 특성만을 반영하게 됩니다.

이러한 메모리 레이아웃 관리 방식은 C++ 컴파일러가 객체의 타입 안전성을 보장하기 위해 내부적으로 처리하는 부분이며, 개발자가 직접 개입할 수 없는 구현 세부사항입니다.

4. C++ 이와 같이 설계된 이유

C++는 값(value) 세만틱스를 기본 원칙으로 채택하고 있습니다. 이 설계 철학에는 몇 가지 중요한 이유가 있습니다.

• 명시적 복사와 불변성: 객체를 값으로 전달하거나 복사할 때, 원본 객체와는 독립적인 새로운 객체가 생성되는 것이 일반적입니다.
  이는 프로그램의 다른 부분에서 발생할 수 있는 부작용(side effect)을 줄이고, 객체의 불변성을 유지하는 데 기여합니다.

• 객체 슬라이싱의 명시성: 파생 클래스의 추가 멤버나 특성을 의도적으로 사용하지 않고, 기본 클래스의 부분만 필요할 때 객체 슬라이싱이 발생하도록 하여,
  개발자가 슬라이싱의 결과를 명확하게 인지하고 처리할 수 있도록 합니다.

• 안전한 다형성 구현: 만약 원본 객체의 다형적 특성을 그대로 유지하고 싶다면, 포인터나 참조를 사용하도록 유도합니다.
  이렇게 함으로써, 개발자가 의도한 경우에만 다형성을 활용할 수 있게 하여, 예기치 않은 동작을 방지합니다.

즉, static_cast 가 임시 객체를 생성하여 슬라이싱을 발생시키는 설계는,

• 값 복사 시 명확한 독립 객체 생성
• 개발자에게 명시적 의도 전달
• 다형적 동작의 선택적 활용
  등의 C++ 설계 철학과 부합합니다.

결론

실제 객체에 static_cast 를 사용하면,

• 대상 타입에 맞는 임시 객체가 생성되고,
• 이 과정에서 객체 슬라이싱이 발생하여 파생 클래스의 추가 멤버와 가상 함수 정보가 손실됩니다.

이때, 새로 생성된 임시 객체의 가상 함수 포인터(vptr) 는 Base 클래스의 vtable을 가리키도록 설정되어, 가상 함수 호출 시 Base 클래스의 구현이 실행됩니다.
이러한 설계는 C++의 값 세만틱스와 명시적 복사 원칙에 기반한 것으로, 개발자에게 보다 명확한 의도 표현과 안전한 다형성 사용을 유도합니다.

new[]와 delete[]의 내부 동작

C++에서 new[] 연산자로 동적 배열을 할당하면, 컴파일러는 단순히 필요한 메모리 크기만을 할당하는 것이 아니라, 추가적인 메타데이터를 함께 저장합니다. 이 메타데이터에는 일반적으로 배열에 할당된 요소의 개수 또는 배열의 길이와 같은 정보가 포함됩니다.

예를 들어, 아래와 같이 배열을 할당한다고 가정해봅니다.

MyClass* arr = new MyClass[3];

이때 실제로 메모리에는 다음과 같은 구조로 저장될 가능성이 있습니다.

// memory layout
| meta data (len=3) | arr[0] | arr[1] | arr[2] |

이 메타데이터의 위치와 저장 방식은 구현체에 따라 다를 수 있지만, 많은 컴파일러에서 배열의 앞부분에 저장됩니다.

그렇다면 delete[] 연산자는 무엇을 할까요? delete[] 연산자는 전달받은 포인터를 기준으로, 배열 앞에 숨겨진 메타데이터를 읽어 배열의 길이를 알아내고, 각 요소에 대해 적절히 소멸자(destructor)를 호출한 후 메모리 전체를 해제합니다.

왜 일반 delete로는 안 되는가?

만약 new[]로 할당한 배열에 대해 단순히 delete를 사용하면, 메타데이터에 저장된 배열 길이 정보를 참조하지 않고 단일 객체만 해제하려고 시도하게 됩니다. 이 경우, 다음과 같이 요소의 소멸자가 올바르게 호출되지 않아 정의되지 않은 동작(Undefined Behavior)이 발생할 수 있습니다.

MyClass* arr = new MyClass[3];
delete arr;  // 잘못된 사용: 첫 번째 요소만 소멸자 호출되고 나머지는 무시됨

따라서 동적 배열을 해제할 때는 반드시 delete[] 를 사용해야 합니다.

결론

new[] 연산자: 동적 배열 할당 시 내부에 배열의 길이 등 메타데이터를 함께 저장합니다. delete[] 연산자: 전달받은 포인터의 앞부분에 저장된 메타데이터를 참조해 배열의 길이를 알아내고, 각 요소의 소멸자를 호출한 후 메모리를 해제합니다. 이 메커니즘은 구현 세부 사항이므로, 프로그래머는 단지 올바른 대응(delete[])을 사용하기만 하면 됩니다.

1. 멤버 변수를 접근하는 멤버 함수 호출
2. 멤버 변수를 접근하지 않는 멤버 함수 호출
3. static 멤버 함수 호출
4. 멤버 변수를 접근하지 않는 가상 함수 호출
5. 멤버 변수를 접근하는 가상 함수 호출

1. 멤버 변수에 접근하는 멤버 함수 호출

멤버 함수 내에서 멤버 변수에 접근하는 경우, this 포인터가 nullptr이면 즉시 nullptr 역참조가 발생하여 segmentation fault 등 런타임 에러가 발생합니다.

#include <iostream>

struct MyClass {
    int value = 42;

    void accessMember() {
        // 멤버 변수에 접근하므로, this가 nullptr면 런타임 에러 발생!
        std::cout << "value: " << value << std::endl;
    }
};

int main() {
    MyClass* ptr = nullptr;
    // ptr->accessMember() 호출 시 nullptr를 역참조 → UB 발생
    ptr->accessMember();
    return 0;
}

2. 멤버 변수를 접근하지 않는 멤버 함수 호출

멤버 함수 내부에서 멤버 변수나 this를 사용하지 않는 경우, 실행 결과가 문제없이 보일 수 있습니다. 하지만 표준상 이 경우에도 여전히 this 포인터는 암시적으로 전달되므로 정의되지 않은 동작(UB)임에 주의해야 합니다.

#include <iostream>

struct MyClass {
    void noAccess() {
        // 멤버 변수를 사용하지 않음.
        std::cout << "Hello from noAccess()" << std::endl;
    }
};

int main() {
    MyClass* ptr = nullptr;
    // 정상적으로 출력될 수도 있으나, UB에 해당합니다.
    ptr->noAccess();
    return 0;
}

3. static 멤버 함수 호출

static 멤버 함수는 클래스에 속한 일반 함수와 같아서, this 포인터가 전달되지 않습니다. 따라서 객체의 유효성 여부와 무관하게 호출할 수 있습니다.

#include <iostream>

struct MyClass {
    static void staticFunc() {
        std::cout << "Hello from staticFunc()" << std::endl;
    }
};

int main() {
    MyClass* ptr = nullptr;
    // ptr을 통해 호출해도, 내부적으로 this를 사용하지 않으므로 안전합니다.
    ptr->staticFunc();
    // 권장하는 호출 방법: MyClass::staticFunc();
    return 0;
}

4. 멤버 변수를 접근하지 않는 가상 함수 호출

가상 함수는 런타임에 호출할 함수 주소를 결정하기 위해 vtable lookup 을 수행합니다. 비록 가상 함수의 본문 내에서 멤버 변수를 접근하지 않더라도, vtable lookup 과정에서 암시적으로 전달되는 this 포인터가 필요합니다. 따라서 this가 nullptr인 경우, vtable 조회 시 nullptr 역참조가 발생하여 정의되지 않은 동작(UB)이 발생할 수 있습니다.

#include <iostream>

struct MyClass {
    virtual void virtualNoAccess() {
        // 멤버 변수에 접근하지 않지만, 호출 시 vtable lookup을 위해 this가 필요합니다.
        std::cout << "Hello from virtualNoAccess()" << std::endl;
    }
};

int main() {
    MyClass* ptr = nullptr;
    // vtable lookup 시 nullptr 역참조 → UB 발생
    ptr->virtualNoAccess();
    return 0;
}

추가 설명: 4번의 경우, "명시적으로" 오류 메시지가 출력되거나 즉시 크래시가 발생한다고 보장할 수 없습니다. 실제로 시스템이나 컴파일러에 따라 동작이 달라질 수 있지만, UB임에는 변함이 없습니다.

5. 멤버 변수를 접근하는 가상 함수 호출

이 경우는 1번과 4번의 문제가 모두 복합되어 발생합니다. 즉, vtable lookup 과정에서 this 포인터가 필요하고, 그 이후 멤버 변수 접근으로 인해 추가적인 nullptr 역참조가 일어납니다. 따라서 매우 위험하며, 정의되지 않은 동작입니다.

#include <iostream>

struct MyClass {
    int value = 100;

    virtual void virtualAccess() {
        // vtable lookup 이후, 멤버 변수 접근 → UB 발생
        std::cout << "value: " << value << std::endl;
    }
};

int main() {
    MyClass* ptr = nullptr;
    // vtable 조회와 멤버 변수 접근 모두 문제를 일으킵니다.
    ptr->virtualAccess();
    return 0;
}

결론

nullptr 객체에서 non-static 멤버 함수를 호출하는 것은 멤버 변수에 접근 여부와 관계없이 UB를 발생시킬 수 있습니다. 특히 가상 함수 호출은 내부적으로 vtable lookup을 위해 this 포인터를 사용하므로, 멤버 변수를 사용하지 않더라도 UB에 해당합니다.

안전한 코딩 습관

• 객체 포인터의 유효성 검사: 멤버 함수를 호출하기 전에 항상 포인터가 nullptr 인지 확인합니다.
• static 함수 활용: 객체 상태와 무관하게 동작해야 하는 함수라면, static 멤버 함수나 전역 함수를 사용하는 방법을 고려해보세요.
• 명시적 호출: 가상 함수의 특정 구현을 호출하고자 한다면, 명시적으로 클래스 이름을 사용하여 호출하는 방법도 있으나, 기본적으로 호출 대상 객체가 유효한지 항상 확인해야 합니다.

기본 문법

class Shape {
public:
    virtual void draw() {
        cout << "Drawing a shape" << endl;
    }
};

class Circle : public Shape {
public:
    void draw() override {
        cout << "Drawing a circle" << endl;
    }
};

동작 원리

가상 함수는 vtable(virtual table)이라는 특별한 테이블을 사용하여 동적으로 바인딩됩니다. 객체의 타입을 실행 시간에 결정하여 적절한 함수를 호출합니다.

사용 예

Shape* shape = new Circle();
shape->draw(); // 출력: "Drawing a circle"

기반 클래스 포인터(shape)를 사용하여 파생 클래스(Circle)의 draw 메서드를 호출할 수 있습니다. 이렇게 하면 다양한 Shape 파생 클래스를 동일한 인터페이스로 처리할 수 있습니다.

가상포인터와 가상함수 테이블

가상함수는 C++에서 다형성을 구현할 때 사용되며, 가상포인터는 가상함수 테이블을 가리킵니다. 객체가 생성될 때, 가상포인터는 해당 클래스의 가상함수 테이블을 가리키게 설정됩니다. 가상함수가 호출될 때, 가상포인터를 통해 올바른 함수를 찾아 실행합니다. 이렇게 해서 런타임 다형성이 구현됩니다.

[Base Class Object]
+------------------+
|  vptr            | ----> [Base VTable]
+------------------+       +------------------+
|  Base members    |       |   Base::func1()  |
+------------------+       +------------------+
                           |   Base::func2()  |
                           +------------------+

[Derived Class Object]
+------------------+
|  vptr            | ----> [Derived VTable]
+------------------+       +------------------+
|  Base members    |       | Derived::func1() |
+------------------+       +------------------+
|  Derived members |       | Derived::func2() |
+------------------+       +------------------+

• vptr: 가상포인터, 객체가 생성될 때 설정됩니다.
• VTable: 가상함수 테이블, 가상함수들의 주소를 저장합니다.

vptr는 객체마다 고유하며, 각 객체의 vptr는 해당 객체의 타입에 따른 VTable을 가리킵니다. 반면에 VTable은 클래스 당 하나만 생성되어 해당 클래스의 모든 객체에 의해 공유됩니다. 즉, 같은 클래스의 객체들은 같은 VTable을 사용하게 됩니다. 가상함수를 호출할 때, vptr를 사용해 적절한 VTable을 찾고, 그 테이블에서 함수의 주소를 찾아 실행합니다. 이렇게 런타임 다형성이 가능해집니다.

// Assuming SomeFunction() is a virtual functions, this call

ptr->SomeFunction();

// will be tranformed into something like this:

(*ptr->__vptr[n])(ptr)

ptr->SomeFunction();이라는 가상함수 호출은 컴파일러에 의해 내부적으로 다른 형태로 변환됩니다. 이 변환된 형태가 (*ptr->__vptr[n])(ptr)입니다.

1. ptr->__vptr: ptr이 가리키는 객체의 가상포인터(vptr)를 의미합니다. 이 vptr는 해당 객체의 가상함수 테이블(VTable)을 가리킵니다.
2. ptr->__vptr[n]: vptr가 가리키는 VTable에서 n번째 위치에 있는 함수의 주소를 가져옵니다. n은 SomeFunction()의 VTable 내 위치입니다.
3. (*ptr->__vptr[n])(ptr): n번째 위치에 있는 함수를 호출합니다. ptr는 this 포인터로 전달됩니다.

이렇게 하면 런타임에 적절한 함수가 호출됩니다. 이는 다형성을 구현하는 데 필수적인 메커니즘입니다.

typeid 연산자와 가상함수

typeid 연산자와 가상함수는 C++의 런타임 타입 정보(RTTI) 시스템에서 밀접한 관계를 가집니다. 가상함수가 있는 클래스의 객체에 typeid를 사용하면, 런타임에 객체의 실제 타입을 확인할 수 있습니다.

1. 가상함수가 있는 클래스: 객체의 vptr (가상 포인터)를 통해 가상함수 테이블(VTable)에 접근하고, VTable에 저장된 RTTI 정보를 사용하여 객체의 실제 타입을 알아냅니다.
2. 가상함수가 없는 클래스: typeid는 컴파일 타임에 객체의 타입을 결정합니다. 이 경우에는 VTable과 RTTI가 필요하지 않습니다.

typeid를 사용하여 런타임에 타입을 확인할 때, 가상함수와 VTable이 없으면 다형성을 지원하지 않는 클래스의 객체에 대해서는 정적 타입만을 반환합니다. 가상함수와 VTable이 있는 경우에는 런타임에 객체의 실제 타입을 확인할 수 있습니다.

SomeObject:                 VTable
  +--------+          +---------------+ 
  | __vptr |----+     | offset_to_top | -2
  +--------+    |     +---------------+
  |   p    |    |     |      RTTI     | -1
  +--------+    |     +---------------+
  |   q    |    +---> |     ~Foo()    | 0
  +--------+          +---------------+
                      | SomeFunction  | 1
                      +---------------+

음수 인덱스에 RTTI 정보가 저장되는 것은 구현 세부사항이므로 모든 컴파일러에서 보장되지는 않습니다. 그러나 많은 C++ 컴파일러 구현에서는 이러한 방식으로 동작합니다.

단일 상속

class Base {
public:
    virtual ~Base() {}
    virtual void func1() {}
};

class Derived : public Base {
public:
    virtual ~Derived() {}
    virtual void func1() override {}
    virtual void func2() {}
};

[Base Class]
+------------------+
|  vptr            | ----> [Base VTable]
+------------------+       +------------------+
|  Base members    |       |  Base::~Base()   |
+------------------+       +------------------+
                           |  Base::func1()   |
                           +------------------+

[Derived Class]
+------------------+
|  vptr            | ----> [Derived VTable]
+------------------+       +--------------------+
|  Base members    |       | Derived::~Derived()|
+------------------+       +--------------------+
| Derived members  |       |  Derived::func1()  |
+------------------+       +--------------------+
                           |  Derived::func2()  |
                           +--------------------+

• vptr: 가상 포인터, 객체의 VTable을 가리킵니다.
• VTable: 가상함수와 가상 소멸자의 주소를 저장합니다.

1. Base 클래스의 객체는 Base VTable을 가리키는 vptr를 가집니다.
2. Derived 클래스의 객체는 Derived VTable을 가리키는 vptr를 가집니다.

Derived::func1()은 Base::func1()을 오버라이딩하므로, Derived VTable에서는 Derived::func1()의 주소가 저장됩니다.

Derived::func2()는 Derived 클래스만의 고유한 가상함수이므로, Derived VTable에 추가됩니다. 이렇게 해서 다형성이 구현됩니다.

다중 상속

class Base0 {
public:
    virtual void func0() {}
};

class Base1 {
public:
    virtual void func1() {}
};

class Derived : public Base0, public Base1 {
public:
    virtual void func0() override {}
    virtual void func1() override {}
};

이 예시에서 Derived 클래스는 Base0과 Base1을 상속받습니다. 따라서 Derived 객체는 두 개의 vptr를 가지며, 각각은 해당 기반 클래스의 VTable을 가리킵니다. 이렇게 다중 상속에서는 복잡한 메모리 레이아웃과 VTable 구조를 가질 수 있습니다.

[Derived Class]
+------------------+       +------------------+
|  vptr to Base0   | ----> | Derived::func0() |
+------------------+       +------------------+
|  vptr to Base1   | ----> | Derived::func1() |
+------------------+       +------------------+
|  Derived members |
+------------------+

• 각 기반 클래스마다 별도의 vptr가 필요합니다.
• 각 기반 클래스마다 별도의 VTable이 필요합니다.
• 객체를 특정 기반 클래스 타입으로 변환할 때 주소 조정이 필요할 수 있습니다.

다중 상속에서 주소 조정

// For this:
Derived* d = new Derived;
Base1* b = d;

// the compiler will transform the code to (via vtable):
Base1* b = d + sizeof(Base0);

다중 상속 상황에서, Derived 클래스의 객체를 Base1 클래스의 포인터로 변환하려면, 포인터의 주소를 Base0의 크기만큼 조정해야 합니다. 이런 조정은 런타임에 이루어지며, function_thunk가 이 역할을 합니다.

// then for a virtual function call needing pointer adjustment:
ptr->function();

// becomes:
ptr->__function_thunk(ptr);

__function_thunk:
    ptr += offset;
    function(ptr);

function_thunk는 "thunk" 함수의 한 예입니다. Thunk는 일반적으로 런타임에 주소나 포인터의 조정이 필요할 때 사용되는 작은 코드 조각입니다. 이 경우, function_thunk는 실제 가상 함수(function)를 호출하기 전에 필요한 포인터 조정을 수행합니다. 처리되는 객체의 유형이 컴파일 타임에 알려지지 않기 때문에 이러한 변환은 모두 런타임에 발생합니다.

다중 상속 객체의 가상함수 테이블

                         +----------------+
                         | offset_to_top  |
Derived:                 +----------------+
  +-------------+        |  Derived RTTI  |
  | _vptr_Base0 |---+    +----------------+
  +-------------+   +--> | Base0 virtuals |
  |     ...     |        +----------------+
  +-------------+        |      ...       |
  | _vptr_Base1 |---+    +----------------+
  +-------------+   |    | offset_to_top  |
  |     ...     |   |    +----------------+
  +-------------+   |    |  Derived RTTI  |
                    |    +----------------+
                    +--> | Base1 virtuals |
                         +----------------+
                         |      ...       |
                         +----------------+

다중 상속을 사용하는 Derived 클래스의 경우, 각 기반 클래스(Base0, Base1 등)의 VTable에는 해당 기반 클래스의 가상 함수들에 대한 정보가 들어가고, 추가로 Derived에서 오버라이드한 가상 함수에 대한 정보도 들어갈 수 있다는 점입니다.

예를 들어, Derived 클래스가 Base0의 func0()을 오버라이드하고, Base1의 func1()을 오버라이드했다면, Derived 클래스의 Base0과 Base1에 대한 VTable은 각각 Derived::func0()과 Derived::func1()에 대한 정보를 포함할 것입니다.

이렇게 각 VTable에는 Derived 클래스에서 오버라이드한 함수에 대한 정보가 들어가므로, 어떤 기반 클래스의 포인터로도 Derived 객체의 적절한 함수를 빠르게 호출할 수 있습니다.

가상 상속

가상 상속(virtual inheritance)의 주된 목적은 다중 상속을 사용할 때 "다이아몬드 문제"를 해결하는 것입니다. 다이아몬드 문제란, 두 개 이상의 클래스가 같은 부모 클래스를 상속받을 때, 그 부모 클래스의 멤버가 중복으로 존재하는 문제를 말합니다.

    ClassA
    /     \
ClassB   ClassC
    \     /
    ClassD

예를 들어, ClassA를 상속받는 ClassB와 ClassC가 있고, 이 두 클래스를 다시 상속받는 ClassD가 있다면, ClassD는 ClassA의 두 개의 인스턴스를 가지게 됩니다. 이렇게 되면, ClassA의 멤버에 접근할 때 어떤 인스턴스의 멤버에 접근해야 하는지 모호해집니다.

이 경우, ClassD의 메모리 레이아웃은 다음과 같이 두 개의 ClassA 인스턴스를 포함하게 됩니다.

ClassD: [ ClassB [ ClassA ] ] [ ClassC [ ClassA ] ]

가상 상속을 사용하면, 이러한 문제를 해결할 수 있습니다. 가상 상속을 통해 ClassB와 ClassC가 ClassA를 상속받으면, ClassD는 ClassA의 단 하나의 인스턴스만을 가지게 됩니다. 즉, ClassA의 멤버는 ClassD 내에서 단일 인스턴스로만 존재하게 되어, 모호함이 해결됩니다.

가상 상속을 사용하면, ClassD의 메모리 레이아웃은 다음과 같이 단 하나의 ClassA 인스턴스만을 포함하게 됩니다.

ClassD: [ ClassB ] [ ClassC ] [ ClassA ]

여기서 [ ClassB ]와 [ ClassC ]는 ClassA를 가상으로 상속받기 때문에, ClassA의 단일 인스턴스가 ClassD에 직접 포함됩니다. 이렇게 하면 ClassA의 멤버에 대한 모호함이 해결됩니다.

가상 기본 클래스가 하나만 있는 간단한 경우를 고려해 보겠습니다.

class Base {
public:
    ~Base();
    int p { 5 };
};

class Derived : virtual public Base {
public:
    ~Derived();
    int q { 7 };
};

Derived d;

Derived 의 실제 메모리 레이아웃은 아래와 같습니다.

(lldb) p sizeof(d)
(unsigned long) $0 = 16
(lldb) x/4w &d
0x7fff5fbffb68: 0x00001028 0x00000001 0x00000007 0x00000005
                |                   | |        | |        |
                ..................... .......... ..........
                   virtual pointer        q          p

위의 간략화된 메모리 레이아웃의 특성과 같이 부모 클래스의 비정적 데이터 멤버가 파생 클래스의 멤버 메모리뒤에 배치되는 것을 확인할 수 있습니다.

객체의 메모리 레이아웃은 컴파일 시점에 결정되며, 이는 컴파일러와 플랫폼, 그리고 클래스의 상속 구조에 따라 달라집니다. 가상 상속을 사용하는 경우, 일반적으로 가상 베이스 클래스의 멤버 변수들은 파생 클래스의 메모리 레이아웃에서 가장 아래에 위치하게 됩니다. 이는 가상 상속의 특성 때문에 가상 베이스 클래스의 멤버 변수들이 단 한 번만 인스턴스화되어야 하기 때문입니다.

생성자 호출 순서와 메모리 레이아웃은 별개의 문제입니다. 생성자는 객체가 생성될 때 초기화 작업을 수행하는 역할을 하며, 메모리 레이아웃은 컴파일러가 결정합니다. 따라서, 생성자가 호출되는 순서와는 무관하게, 각 클래스의 멤버 변수는 컴파일러가 결정한 메모리 레이아웃에 따라 적재됩니다

VTT(Virtual Table Table)

VTT(Virtual Table Table)는 C++의 가상 상속에서 중요한 역할을 하는 데이터 구조입니다. VTT는 각 클래스의 생성자와 소멸자가 호출될 때 해당 클래스의 vptr(virtual pointer)가 올바른 vtable을 가리키도록 도와줍니다. 이는 다중 상속과 가상 상속이 복합적으로 이루어진 복잡한 상속 구조에서 특히 중요합니다.

VTT(Virtual Table Table)의 역할을 이해하기 위해 간단한 예를 들어보겠습니다. 다음과 같은 클래스 구조를 가정해봅시다.

class Base {
public:
    virtual void func() { /* ... */ }
};

class Derived1 : virtual public Base {
public:
    virtual void func() override { /* ... */ }
};

class Derived2 : virtual public Base {
public:
    virtual void func() override { /* ... */ }
};

class MostDerived : public Derived1, public Derived2 {
public:
    virtual void func() override { /* ... */ }
};

이 경우, MostDerived 객체를 생성할 때 다음과 같은 과정이 일어납니다.

1. Base의 생성자가 호출됩니다. 이 때, Base의 vptr는 Base의 vtable을 가리킵니다.
2. Derived1의 생성자가 호출됩니다. Derived1의 vptr는 Derived1의 vtable을 가리키도록 변경됩니다.
3. Derived2의 생성자가 호출됩니다. Derived2의 vptr는 Derived2의 vtable을 가리키도록 변경됩니다.
4. 마지막으로 MostDerived의 생성자가 호출됩니다. MostDerived의 vptr는 MostDerived의 vtable을 가리키도록 변경됩니다.

이 과정에서 VTT는 각 단계에서 어떤 vtable을 가리켜야 하는지 정보를 제공합니다. 즉, 생성자와 소멸자가 호출될 때마다 VTT를 참조하여 vpointer를 올바른 vtable로 설정합니다.

VTT(Virtual Table Table)가 없다면, 다중 상속과 가상 상속이 복합적으로 사용될 때 문제가 발생할 수 있습니다. 예를 들어, 위와 같이 MostDerived 객체를 생성하는 상황에서 Derived1이 먼저 생성되었다고 가정하면, Base 클래스의 vptr(virtual pointer)는 Derived1의 vtable을 가리킬 것입니다.

이후에 Derived2의 생성자가 호출되면, Derived2의 vptr도 설정되어야 하지만, Base의 vptr는 이미 Derived1의 vtable을 가리키고 있을 것입니다. 이 상태에서 MostDerived의 생성자가 호출되면, Base의 vptr가 어떤 vtable을 가리켜야 할지 모호해집니다.

이러한 문제는 VTT를 사용함으로써 해결됩니다. VTT는 객체의 생성과 소멸 과정에서 각 클래스의 vptr가 올바른 vtable을 가리키도록 도와줍니다.

MostDerived 객체 메모리 레이아웃:

+-------------------+
| MostDerived::vptr | ----> MostDerived::vtable
+-------------------+
| Derived1::vptr    | ----> Derived1::vtable
+-------------------+
| Derived2::vptr    | ----> Derived2::vtable
+-------------------+
| Base::vptr        | ----> MostDerived::vtable (가상 상속 때문)
+-------------------+
| MostDerived 멤버  |
+-------------------+
| Derived1 멤버     |
+-------------------+
| Derived2 멤버     |
+-------------------+
| Base 멤버         |
+-------------------+

MostDerived 객체가 생성되는 과정에서 Base의 생성자가 호출되면, 이 시점에서 Base의 vptr는 MostDerived의 vtable을 가리키게 설정됩니다. 이렇게 하면, MostDerived 객체를 통해 Base의 가상 함수를 호출할 때 올바른 함수가 실행됩니다.

따라서, MostDerived 객체 내에서 Base의 vptr는 MostDerived의 vtable을 가리키게 됩니다. 이는 VTT(Virtual Table Table)를 통해 관리될 수 있으며, 이로 인해 다중 상속과 가상 상속이 복합적으로 사용될 때도 가상 함수 호출이 올바르게 작동합니다. 이렇게 하면, Base의 vptr는 최종적으로 MostDerived의 vtable을 가리키게 됩니다.

따라서, VTT가 없으면 다중 상속과 가상 상속이 복합적으로 사용될 때 vptr 설정이 제대로 이루어지지 않아, 가상 함수 호출 등에서 문제가 발생할 수 있습니다.

이렇게 VTT는 복잡한 상속 구조에서도 객체가 올바르게 생성되고 소멸될 수 있도록 도와줍니다. 이는 컴파일러가 자동으로 관리하는 부분이므로 일반적으로 개발자가 직접 다루지는 않습니다.

참고자료

• https://anderberg.me/2016/06/26/c-virtual-functions/

내 코드에서는 Event 를 관리하는 클래스를 Event System 이라고 이름은 붙였지만 Event Manager 와 같이 다양하게 불릴 뿐 역할은 모두가 동일하다고 본다. 이 포스트를 작성하기 전까지 C# 에도 Event 가 있는 줄 몰랐는데 포스트 작성을 위해 Event 관련 자료를 찾아보니 C# 의 기능까지 확인하게 되었다. 내가 필요한 기능만 적당히 구현해놓은 Event System 과는 달리 좀더 세분화되고 사용하기 좋게 되어있던 것 같아서 내가 만든 Event System 을 개선할때 참고하려고 한다. (참고로 Microsoft C++ 에도 __event 라는 키워드가 존재하는데 아직 공부한 영역이 아니라서 자세히 보진 않았지만 비슷한 기능을 하는 듯 하다.)

처음 구현해본 Event System 로써 아직 보완할 점이 상당히 많이 보인다. 멀티스레드로도 사용할 수 있을 것 같고, 사용 편의성을 더욱 늘릴 필요가 있을 것 같으며(C# 스타일의 이벤트 처럼) 외부에서 이벤트를 등록/제거 하기 쉽게 만들 필요가 있는 것 같다(현재는 자신의 클래스에 국한하여 이벤트를 처리하는 방식). 여유가 있다면 이 형태에서 점점 개선하여 사용할 예정이다.

Event 란 + 사용하는 이유

내가 받아들인 Event 는 핵심만 말하자면 특정한 Event 가 발생했을 때, 그 Event 를 구독한 객체가 그에 맞는 행동을 하는 것이다. 여기서 Event 는 개별적으로 구분이 가능한 무엇이든 상관이 없다. 내 엔진의 특성상 wstring을 사용할 일이 많아서 wstring_view 객체로 사용하였으나 int , string 등 고유한 값을 가지고 있는 것이면 무엇이든 가능하다 (사실 고유하지 않아도 되지만 그러면 의도치 않은 일이 벌어질 수 있을테니). 그렇다면 'Event 를 왜 쓰는걸까?' 라는 의문이 생길 수 있다. 내가 받아들인 Event 의 가장 큰 장점은, 클래스간의 결합도를 낮추는 것이라고 생각한다. 단적인 예를 들어보겠다. 똑같은 방식으로 생성된 몬스터 100 마리가 있을 때, 그 중 68 번째로 생성된 몬스터에게 특별한 의미를 부여하려고 한다. 그 몬스터가 사망했을 때 플레이어에게 500 골드를 주는 것이다. 가장 직관적으로 구현한다고 하면 68번째 생성된 몬스터를 그것을 관리하는 시스템 차원의 클래스에서 직접 들고 있다가, 그 몬스터가 죽었는지 계속 확인하면서 죽는다면 우리가 원하는 행위를 수행하는 것이다. 글로는 쉽게 설명했지만 직접 구현하다보면 이런 생각이 들며 머리가 아파오기 시작할 것 같다. '굳이 이 한마리 때문에 이걸 멤버 변수로 들고 있어야 한다고?' 게다가 필드에 몬스터가 이 한 종류 뿐이라는 보장도 없다. 몬스터의 종류는 수도 없이 많을텐데 그리고 발생하는 행위가 모두 같다는 보장도 없기 때문에 개별적인 모든 것을 위해서 멤버변수를 하나하나 들고 있자니 벌써 하기가 싫어진다. 이런 문제를 Event 로 쉽게 해결이 가능하다. 객체가 Event 를 받았을 때, 해야할 일을 객체에게 등록 해주면 되기 때문이다. 위의 예를 보자면, 68 번째 몬스터에게 "사망시 플레이어에게 500골드 지급" 이라는 함수를 구현해서 넣어주는 것이다. 등록 이라는 표현을 사용했는데, 이에 대한 구현 방식은 정말 개인의 자유인 것 같다. 본론으로 돌아가서, 위와 같이 Event 를 사용한다면 관리자 클래스에서 몬스터 객체를 개별적으로 알 필요가 없게 되어 클래스간 결합도가 떨어지는 결과를 얻을 수 있다. 당연히 플레이어에게 500골드를 주는 행위 조차도 Event 로 처리한다면 몬스터가 플레이어도 알 필요가 없기에 같은 맥락으로 볼 수 있다.

코드 및 설명

코드 진행 방식

0. 특정 EventID 를 받았을 때 반응하고 싶은 클래스가 EventHandler 클래스를 다중 상속을 받은 후, 자신의 멤버 함수를 EventFunction 시그니처 std::function<void(std::any)> 에 맞춰서 특정 EventID 에 반응하는 함수를 EventHandler::MakeListenerInfo 함수의 인자로 넣는다.
1. EventID 를 발행하고 싶은 객체가 EventSystem 의 싱글톤 객체에 접근하여 EventSystem::PublishEvent 을 사용한다.
2. EventSystem::m_CustomEvents 에 (1) 에서 발행된 Event 객체가 push_back 되고, 해당 프레임의 마지막(실행 주기 상 EventSystem 이 가장 마지막에 위치함)에 EventSystem::Update -> EventSystem::ProcessEvent 을 통해 Event 객체에 대한 처리를 한다. 기본적으로 m_CustomEvents 컨테이너는 선입선출의 형태(Queue)를 가지기 위해 먼저 들어온 Event 객체부터 처리하지만, 지연 시간이 존재하는 Event 객체는 해당 시간이 만료될 때 까지 나중에 들어온 Event 객체보다 늦게 처리된다.
3. 객체의 실행 조건(지연 시간 만료)이 만족하면 EventSystem::ProcessEvent 에는 내부적으로 EventSystem::DispatchEvent 가 실행되는데, 이 함수가 실제로 EventFunction 을 실행하는 부분이다.
4. EventSystem::DispatchEvent 에서 EventFunction 이 실행되면, (0) 에서 등록한 함수가 실행된다. (실제 코드는 사용 예시 참조)

EventSystem.h

#pragma once

#include <functional>
#include <queue>
#include <map>
#include <string_view>
#include <any>

namespace McCol
{
    class EventHandler;

    struct Event
    {
        std::wstring_view EventID;                        // 이벤트명
        std::any Parameter;                                // 매개변수(필요시 적절한 캐스팅으로 사용)
        float DelayedTime;                                // 지연 시간(기본값 0)

        Event(std::wstring_view id, std::any param, const float& delayed)
            : EventID(id), Parameter(param), DelayedTime(delayed) {}
    };

    struct ListenerInfo
    {
        const EventHandler* Listener = nullptr;                // 이벤트를 받을 객체(dangling 포인터를 방지하기 위한 객체 검사용, 실제 사용 X)
        std::function<void(std::any)> EventFunction;        // 이벤트를 받을 시 수행할 함수

        ListenerInfo(const EventHandler* listener, const std::function<void(std::any)>& func)
            : Listener(listener), EventFunction(func) {}
    };

    class EventSystem
    {
    private:
        EventSystem();
        ~EventSystem() = default;

    private:
        static EventSystem* m_Instance;
        std::vector<Event> m_CustomEvents;                        // 사용자 정의 이벤트
        std::multimap<std::wstring_view, ListenerInfo> m_Listeners;        // 이벤트 구독자 정보 컨테이너

    public:
        static EventSystem* GetInstance()
        {
            if (m_Instance == nullptr)
                m_Instance = new EventSystem;

            return m_Instance;
        }

        void Initialize();
        void Update(const float& deltaTime);
        void Finalize();

    public:
        // 이벤트 발행
        void PublishEvent(std::wstring_view evtID, const std::any& param = nullptr, const float& delayed = 0.0f);
        void Subscribe(std::wstring_view evtID, const ListenerInfo& listenerInfo);            // 이벤트 구독

        void Unsubscribe(std::wstring_view evtID, const EventHandler* listener);            // 해당 이벤트 구독 해지
        void RemoveListener(const EventHandler* listener);                                    // 해당 리스너가 구독한 모든 구독 취소
        void RemoveListenersAtEvent(std::wstring_view evtID);                                // 해당 이벤트 모든 구독자 제거
        void RemoveAllEvents();                                                                // 모든 이벤트 제거
        void RemoveAllSubscribes();                                                            // 모든 구독 취소

    private: // 내부 함수
        void ProcessEvent(const float& deltaTime);                                            // 이벤트 큐 확인
        void DispatchEvent(const Event& evt);                                                // 이벤트 처리
        bool CheckSubscribe(std::wstring_view evtID, const EventHandler* listener);            // 이벤트 중복 구독 확인
    };
}

Event

• EventSystem 안에서만 사용되는 구조체로, 구성요소는 식별하기 위한 EventID 값, Event 를 발행하는 객체가 발행할 때 해당 Event 를 받는 객체에서 필요로 하는 인자를 전달하기 위한 Parameter , 원하는 시간 뒤에 수행하기 위한 DelayedTime 이다.
• 세가지 멤버 변수 모두 Event 객체를 이루는 필수적인 요소이기 때문에 생성자로 모두 받고 있다.

ListenerInfo

• 마찬가지로 EventSystem 안에서만 사용되는 구조체. 하지만 생성은 Event 를 구독하는 객체가 직접하고 EventSystem 이 그걸 넘겨받는 형식이다. 구성요소는 Event 를 받을 객체의 주소값 Listener , 특정 Event 를 받을 시 수행하는 함수 EventFunction (문법 참조 : std::function) 이 있다.
• Listener 는 함수를 수행하는데 사실 필요가 없지만, dangling pointer 를 방지하기 위해 저장한다. 내가 찾아본 바에 의하면 std::function 에는 함수 주인의 정보를 알 수 없었다. 따라서 주인의 주소값 Listener 을 통해 std::function 과 생명 주기를 동일시 하기 위해 사용한다. 즉 주인이 사라지면 연결된 std::function 도 함께 삭제하기 위함이다. 실제로 사용되는 방식은 EventHandler.h 의 소멸자를 확인하길 바란다.
• EventFunction 의 타입으로 std::function 을 사용한 이유는 함수를 하나의 객체처럼 다루기 위해서이다. EventSystem 에서 함수를 관리 할 때 함수에 수행 명령을 내리는 것은 EventSystem 이기 때문에 하나의 객체처럼 저장할 수 있어야 하는데 이 방법을 위한 적절한 C++ 문법이 std::function 이었다.
• 형태가 std::function<void(std::any)> 인 이유 : 내 EventSystem 특성상 해당 EventID 를 Subscribe(구독) 한 객체가 설정한 함수 EventFunction 이 수행되었을 때, 객체는 그 EventID 를 알 필요가 없다. 이미 등록한 함수 EventFunction 이 수행되었다는 것 부터가 그 함수에 대응하는 EventID 가 Publish(발행) 되었다는 뜻이기 때문이다. (Subscribe, Publish 에 대한 설명은 EventSystem.cpp 에서 추가 후술) 그렇다면 인자가 굳이 std::any 일 필요가 있나 싶겠지만 EventFunction 중 특정 함수는 매개변수를 반드시 필요로 하는 함수가 있을 수 있기 때문에 그 매개변수를 std::any 로 지정하여 어떤 타입이든 올 수 있게 한 것이다. 하지만 인자로 들어 올 수 있는 것은 하나 뿐이기에 인자로 넘겨야 할 것이 여러개라면 구조체화 해서 넘겨야 한다는 단점이 있다. 반환형이 void 인 이유는 단순하다. 내가 생각하기에 EventFunction 이 무언가를 반환할 이유가 없었고 함수 수행은 해당 객체가 하지만 수행 명령을 내리는 객체는 EventSystem 이기 때문이다.

EventSystem Member Variable

• m_Instance : Event 를 Subscribe 하거나 Publish 하는 행위는 프로그램 전체에서 광범위하게 일어나기 때문에 사용 편의성을 위해서 Singleton Pattern 을 사용하였다.
• m_CustonEvents : 사용자가 정의한 Event 가 저장되는 컨테이너. Event 는 ProcessEvent 라는 내부 함수가 수행될 때 마다 모두 비워지는게 맞기 때문에 처음에는 std::vector 가 아닌 std::queue 였으나 지연 처리 DelayedTime 기능을 추가하게 되면서 특정 Event 만 처리되어야 했고, pop 방식을 사용할 수 없게 되었기 때문에 변경하게 되었다.
• m_Listeners : 구독자(Subscribe 한 객체들) 정보를 담는 컨테이너(std::multimap). 구독자 정보이기 때문에 multimap<std::wstring_view, ListenerInfo> 타입을 갖고 있는데 여기서 wstring_view 는 Event::EventID 이다.
• 각 멤버 함수에 대한 개별적인 설명은 cpp 에서 후술.

EventSystem.cpp

#include "pch.h"
#include "EventSystem.h"

McCol::EventSystem* McCol::EventSystem::m_Instance = nullptr;

McCol::EventSystem::EventSystem()
{
}

void McCol::EventSystem::Initialize()
{
}

void McCol::EventSystem::Update(const float& deltaTime)
{
    ProcessEvent(deltaTime);
}

void McCol::EventSystem::Finalize()
{
    RemoveAllEvents();
    RemoveAllSubscribes();

    SAFE_DELETE(m_Instance)
}

void McCol::EventSystem::PublishEvent(std::wstring_view evtID, const std::any& param, const float& delayed)
{
    m_CustomEvents.push_back({evtID, param, delayed});
}

void McCol::EventSystem::Subscribe(std::wstring_view evtID, const ListenerInfo& listenerInfo)
{
    // 유효성 및 중복 검사
    if(listenerInfo.Listener == nullptr || CheckSubscribe(evtID, listenerInfo.Listener))
    {
        return;
    }

    m_Listeners.emplace(evtID, listenerInfo);
}

void McCol::EventSystem::Unsubscribe(std::wstring_view evtID, const EventHandler* listener)
{
    auto [first, last] = m_Listeners.equal_range(evtID);

    for(auto& it = first; it != last;)
    {
        if(it->second.Listener == listener)
        {
            it = m_Listeners.erase(it);
        }
        else
        {
            ++it;
        }
    }
}

void McCol::EventSystem::RemoveListener(const EventHandler* listener)
{
    // info : EventHandler 를 상속받은 객체가 소멸될 경우 자동으로 호출되는 함수
    // info : listener 의 구독목록을 받아온다면 성능상 개선의 여지가 있음, 현재는 O(N)
    for(auto it = m_Listeners.begin(); it != m_Listeners.end();)
    {
        if(it->second.Listener == listener)
        {
            it = m_Listeners.erase(it);
        }
        else
        {
            ++it;
        }
    }
}

void McCol::EventSystem::RemoveListenersAtEvent(std::wstring_view evtID)
{
    auto [first, last] = m_Listeners.equal_range(evtID);

    for (auto& it = first; it != last;)
    {
        it = m_Listeners.erase(it);
    }
}

void McCol::EventSystem::RemoveAllEvents()
{
    while(!m_CustomEvents.empty())
    {
        m_CustomEvents.clear();
    }
}

void McCol::EventSystem::RemoveAllSubscribes()
{
    m_Listeners.clear();
}

void McCol::EventSystem::ProcessEvent(const float& deltaTime)
{
    std::vector<McCol::Event> tempEvents = m_CustomEvents;
    m_CustomEvents.clear();

    for (auto& evt : tempEvents)
    {
        evt.DelayedTime -= deltaTime;

        if (evt.DelayedTime <= 0)
        {
            DispatchEvent(evt);
        }
        else
        {
            m_CustomEvents.push_back(evt);
        }
    }
}

void McCol::EventSystem::DispatchEvent(const McCol::Event& evt)
{
    auto [first, last] = m_Listeners.equal_range(evt.EventID);

    for (auto& it = first; it != last; ++it)
    {
        // 이벤트 함수 호출
        // EventFunction : 해당 이벤트를 구독한 Listener 가 실행할 함수
        // evt.Parameter : 해당 이벤트에 대한 매개변수
        it->second.EventFunction(evt.Parameter);
    }
}

bool McCol::EventSystem::CheckSubscribe(std::wstring_view evtID, const EventHandler* listener)
{
    auto [first, last] = m_Listeners.equal_range(evtID);

    for (auto& it = first; it != last; ++it)
    {
        if (it->second.Listener == listener)
        {
            return true;
        }
    }

    return false;
}

EventSystem Member Function

• EventSystem::EventSystem : 생성자에서는 딱히 해줄 일이 없다.
• EventSystem::Initialize : 초기화에서도 딱히 해줄 일이 없다. (시스템 관련 함수의 모양새를 맞추기 위해 있는 함수)
• EventSystem::Update : 매 프레임(실행 주기)마다 이벤트 처리 함수 ProcessEvent 를 수행한다.
• EventSystem::Finalize : 시스템이 종료(Finalize)된다는 것은 게임이 끝난 다는 것이기 때문에 모든 이벤트를 삭제하고, 모든 구독자를 삭제한다. 이후 싱글톤 객체를 삭제한다. SAFE_DELETE 는 단순히 들어온 포인터를 delete 하고 nullptr 로 바꾸어주는 매크로(pch.h 에 정의됨). (소멸자에서 처리해도 되지만 시스템 관련 함수의 모양새를 맞추기 위해 있는 함수)
• EventSystem::PublishEvent : 외부에서 싱글톤 객체에 접근하여 사용하는 함수로 Event 를 발행할 때 사용한다. 인자로 식별값(ID), 파라미터, 지연 시간을 가지며 지연 시간은 기본 값으로 0.0f 를 갖는다. 인자는 모두 Event 객체의 생성자에 그대로 들어간다. 생성된 Event 객체는 m_CustomEvents 에 push_back 으로 들어가기 때문에 복사되어 들어간다. 복사라는 단점이 있음에도 불구하고 emplace_back 대신 push_back 을 사용한 이유는 참조 형식으로 받아온 param 객체의 수명이 불분명하기 때문에 Event 가 실제로 수행 될 때 까지 param 객체가 존재한다는 보장이 없기 때문이다.
• EventSystem::Subscribe : 외부에서 싱글톤 객체에 접근하여 사용하는 함수로 Event 를 구독할 때 사용한다. 중복 구독할 이유는 없기 때문에 유효성과 중복 검사를 해주고 문제가 없다면 m_Listeners 에 넣어준다.
• EventSystem::ProcessEvent : 지연 시간을 확인하여 적절한 Event 객체들을 처리하는 함수. range-based for loop 을 사용하여 순회하는데, 순회 함과 동시에 조건이 만족하는 Event 객체는 EventSystem::DispatchEvent 로 넘겨서 실행하게 된다. 실행 도중 Event 를 생성하는 EventFunction 이 존재 할 수 있으므로 EventSystem::Pusblish 를 통해 m_CustonEvents 에 새로운 Event 객체가 추가 될 수 있다. 이로 인해 for loop 순회에 문제가 생기게 된다. 따라서 m_CustomEvents 를 tempEvents 에 복사하여 생성하고 m_CustomEvents 는 clear 를 통해 비워준다. 그 뒤 tempEvents 를 순회하며 DelayedTime 을 deltaTime 만큼 빼주고 DelayedTime 의 값을 확인해가며 DispatchEvent 의 수행 여부를 결정한다. 수행하지 않는다면 다시 m_CustomEvents 에 넣어주어 다음 프레임에 같은 행위를 반복하도록 한다. 함수가 종료되면 tempEvents 는 수명이 만료되어 삭제되고 m_CustomEvents 에는 아직 지연 시간이 남은 Event 객체만 유지되게 된다.
• EventSystem::DispatchEvent : m_Listeners 의 equal_range 를 사용하여 key 값(evt.EventID) 이 일치하는 std::pair<wstring_view, ListenerInfo> 객체를 가르키는 iterator 를 [first, last] 형태로 가져온다. 이후 first ~ last 를 순회하며 해당 iterator.second 의 EventFunction 에 매개변수로 들어온 evt.Parameter 를 넣어주고 실행한다.
• 이외 함수 : EventSystem.h 함수 주석 참조

EventHandler.h

#pragma once
#include <functional>
#include "EventSystem.h"

namespace McCol
{
    class EventHandler
    {
    public:
        // EventHandler 로 등록된 모든 이벤트를 제거
        virtual ~EventHandler()
        {
            EventSystem::GetInstance()->RemoveListener(this);
        }

        // EventSystem 에 등록하기 위한 Callable 생성
        template <typename T>
        ListenerInfo MakeListenerInfo(void (T::* func)(std::any))
        {
            // 유효성 검사
            static_assert(std::is_base_of_v<EventHandler, T>, "T must be derived from EventHandler");
            // Callable 반환 (인자 설명은 ListenerInfo 구조체 참조)
            return ListenerInfo(this, [this, func](std::any handler) { (static_cast<T*>(this)->*func)(handler); });
        }
    };
}

EventHandler Member Function

• EventHandler::~EventHandler : EventSystem 싱글톤 객체에 접근하여 이 객체로 등록된 모든 ListenerInfo 를 제거한다.
• EventHandler::MakeListenerInfo : ListenerInfo 객체를 생성한다. [this, func](std::any handler) { (static_cast<T*>(this)->*func)(handler); } 부분은 람다식으로 [ ] 캡처 부분에서 this 는 함수를 수행하는 객체를, func 는 수행되는 멤버 함수를 나타내며 (std::any handler) 는 handler 라는 std::any 타입의 매개변수를 받아오는 것을 의미한다. 그리고 이를 이용하여 람다식의 본문인 { (static_cast<T*>(this)->*func)(handler); } 부분을 작성한다. 본문은 this 를 T* 로 캐스팅하여 사용하는데 그 이유는 MakeListenerInfo 함수가 템플릿 함수이기 때문이다. this 는 EventHandler 객체를 가르키므로 func 를 알 수가 없기 때문에 이를 캐스팅하여 func 를 수행할 수 있도록 한다. 또한 매개변수로 handler 를 넣어준다. 이 함수가 템플릿 함수인 이유는 어떤 클래스던 간에 해당 클래스가 Event 를 구독할 필요가 있다면 EventHandler 클래스를 상속받아 MakeListenerInfo 를 사용할 수 있도록 하기 위해서이다.

사용 예시

#include "EventSystem.h"
#include <iostream>

class Player : public McCol::EventHandler
{
public:
    Player()
    {
        McCol::EventSystem::GetInstance()->Subscribe(L"PlayerDied", MakeListenerInfo(&Player::OnPlayerDied));
    }

    void OnPlayerDied(std::any data)
    {
        int lives = std::any_cast<int>(data);
        std::wcout << L"Player died with " << lives << L" lives remaining." << std::endl;
        if (lives <= 0)
        {
            McCol::EventSystem::GetInstance()->PublishEvent(L"GameOver");
        }
    }
};

class Game : public McCol::EventHandler
{
public:
    Game()
    {
        McCol::EventSystem::GetInstance()->Subscribe(L"GameOver", MakeListenerInfo(&Game::OnGameOver));
    }

    void OnGameOver(std::any data)
    {
        running = false;
    }

    void Run()
    {
        int lives = 3;
        running = true;
        while (running)
        {
            McCol::EventSystem::GetInstance()->Update(0.0f);
            // 게임 로직 (생략)
            // ...
            lives--;
            McCol::EventSystem::GetInstance()->PublishEvent(L"PlayerDied", lives);
        }
        std::wcout << L"Game Over!" << std::endl;
    }

private:
    bool running;
};

int main()
{
    McCol::EventSystem::GetInstance()->Initialize();

    Player player;
    Game game;

    game.Run();

    McCol::EventSystem::GetInstance()->Finalize();

    return 0;
}

직접 사용한 코드를 가져오려고 했으나 해당 이벤트를 처리를 이해하는데 수반되는 코드가 많기 때문에 이벤트의 처리 과정을 보여주는데는 적합하지 않다고 판단되어 따로 만들었다. 편의상 이곳의 EventSystem::Update 의 인자로 0.0f 를 주었지만 원래는 지연 시간 처리를 위해 게임 엔진상의 실제 델타 타임을 주는게 옳다. 위에서 언급한 코드 진행 방식에 기반하여 설명하자면 Player 가 구독한 EventID 를 Game 에서 발행하는 형식이다. 포스트의 도입부에서 이야기 했던 Event 의 필요성에서 나온 사용 방향과는 조금 다르지만 이렇게도 사용할 수 있고 다른 방식으로도 얼마든지 응용이 가능하다. 모두 같은 결론을 도출해 낼 수 있는데, 객체간 의존성이 적어진다는 것이다!

0. Player 생성자에서 L"PlayerDied" 를 구독하고 실행할 함수를 지정한다.
1. Game 생성자에서 L"GameOver" 를 구독하고 실행할 함수를 지정한다.
2. 매 실행 주기(프레임)마다 Game::Run 이 실행되고 lives 값이 줄어들며 이에 해당하는 L"PlayerDied" 를 발행하며 인자로 남은 lives 를 넘겨준다.
3. Player::OnPlayerDied 에서 이 함수가 수행 될 때마다 인자로 받은 남은 lives 를 출력한다.
4. 출력 도중 lives 가 if (lives <= 0) 조건을 만족하면 L"GameOver" 를 발행한다.
5. Game::OnGameOver 함수가 L"GameOver" 를 받고 자신이 속한 객체의 running 을 false 로 변경하여 게임을 종료한다.

참고 자료

Youtube : C++ - Event System

정적 링크 예시

// MyClass.h
class MyClass {
private:
    int m_garbage1;
    int m_garbage2;

public:
    void MyFunction();
    void GarbageFunction1();
    void GarbageFunction2();
};

// main.cpp
#include "MyClass.h"

int main() {
    MyClass obj;
    obj.MyFunction();
    return 0;
}

동적 링크 예시

#include <opencv2/opencv.hpp>

int main() {
    cv::Mat image = cv::imread("image.jpg", cv::IMREAD_COLOR);
    cv::imshow("Image", image);
    cv::waitKey(0);
    return 0;
}

정적 링크는 컴파일 단계에서 내가 필요한 코드가 있는 파일 전체를 포함하는 것이다. 동적 링크는 런타임 단계에서 내가 필요한 코드 부분만 포함하는 것이다.

위 코드로 정적 링크의 예를 들면 다음과 같다. 나는 MyClass 의 MyFunction 만 실행하고 싶은데 MyFunction 뿐만 아니라 MyClass 에 있는 모든 변수나 함수(mgarbage_, GarbageFunction)들이 포함되어 메모리의 낭비가 발생한다.

동적 링크는 정적 링크와 반대 되는 상황이라고 생각하면 된다. 내가 opencv 를 사용하지 않기 때문에 opencv 가 일반적으로 동적 링크 되는지는 알지 못하지만 동적 링크로 사용된다고 가정하겠다. cv::imread 할 때, cv::imshow 할 때, cv::waitKey 를 수행할 때 마다 각각 함수 실행에 필요한 코드 영역들이 메모리 상에 로드된 후 수행이 끝나면 해제되는 것이 동적 링크가 가지는 차이점이다. 동적 링크는 운영체제 단계에서 관리하므로 정확히 언제 해제하는지 알 수 없지만 아마도 더 이상 자주 사용되지 않는다고 판단되는 시점에 알아서 메모리에서 해제하는 것으로 보인다.

항상 이득일까?

동적 링크가 항상 이득일지 의문이 들어서 ChatGPT 에게 물어보았다.

결론적으로 말하자면 완벽한 이득은 아니지만 그럼에도 불구하고 정적 링크를 사용하였을 때 얻는 이득이 동적 링크를 사용하였을 때에 비해 미미하기 때문에 동적 링크를 사용하는 것이 이득이라고 한다.

재밌었고 힘들었던 게임인재원 1학기를 마치고 첫 방학이 끝나간다. 간략하게 1학기(1Q)를 마치면서 느꼈던 것들을 정리하고자 한다. 23년 3월부터 5월 말까지 게임인재원에서 보낸 3개월에 대한 후기를 적어본다.

처음 왔을 때는 대부분이 이곳의 정보를 잘 모르고 왔기 때문에 무엇을 가르쳐주는지도 잘 모르고 어떤 교육과정이 있는지도 잘 모르는 상태였다. 하지만 수업을 들으면서 느껴지는 교수님, 강사님들의 자신감과 강의력이 이곳을 계속 다녀도 괜찮겠다는 확신을 주어서 3월부터 5월 말까지 계속 달려왔던 것 같다. 사실 이곳에 대한 정보는 오래전부터 알고 있었지만 그때는 지금보다 더 정보도 없었고 내 생각도 어려서 두려운 마음에 지원하지 않았다. 시간이 흘러 어느정도 생각이 정립되고, 미래에 대한 불안감과 나의 실력이 사회가 요구하는 기준치에 한참 부합하지 못한다는 것을 깨달아 이곳에 지원하게 되었다. 우연찮게도 혼자 지원하려 했던 이곳에 친한 친구와 함께 등록하게 되었는데 그 또한 지금 생각해보면 정말 좋은 결과를 가져다 주었다고 생각한다.

한 학기 동안 얕고 넓게 배웠다고 생각한다. 누군가는 '깊게 배우지 않았느냐', 또는 '좁게 배우지 않았느냐'라고 말할지도 모르지만 내 생각은 그렇지 않다. 얕다의 의미는 기존에 내가 알던 부분에서는 아직까지 내가 아예 모를정도로 깊게까지는 나아가지 않았고 간간이 헷갈리더라도 과거에 공부했던 내용이기에 어렵지 않았다는 뜻이다. 넓다고 생각한 이유는 내가 공부하지 않았던 영역(기획, 아트)에 대해서는 조금씩 맛을 본 느낌이었기 때문이다. 결코 수준에 대한 평가가 아니며 전공자로써 느끼는 1 학기 수업에 대한 감상일 뿐이니 오해하지 않기를 바란다. 이것이 게임인재원에서 요구하는 1 학기의 적절한 학습상인지는 모르겠으나 2 학기에는 더, 3 학기에는 훨씬 더 어려워질 것이라는 교수님의 말씀 또한 새겨 들으며... 만족하며 학기를 마무리 지었다.

사실 내가 생각하는 게임인재원의 꽃은, 대학교에서 쉽게 배울 수 없는 게임에 특화된 수업이나 현업에서 일하던 분들을 만나 학습자에게 부족한 부분을 지적해주는 그런 것들이 아니다. 다른 사람의 의견을 빌리자면 학습 분위기가 좋은 곳이라고도 했지만, 나에게 이곳이 좋은 이유가 무엇인지 묻는다면 매 학기말에 하는 프로젝트라고 말할 것이다. 단순히 무언가를 계획을 잡고 만드는 거에 그치는 것이 아니라 게임에 필요한 3 분야 기획, 아트, 플밍이 모두 뭉쳐 하나로 만드는데 큰 의미가 있기 때문이다.

1 학기도 당연하게도 프로젝트로 마무리가 된다. 1 학기 동안 배운 것과 WinAPI 를 사용하여 3 개 학과가 모여 게임을 하나 만든다. 물론 WinAPI 를 직접적으로 사용하는 것은 프로그래밍 뿐이지만 그로 인해 많은 것들에 제한점이 있었고 자연스럽게 다른 학과들과 함께 이에 맞춰서 진행하는 프로젝트가 되었다. WinAPI 사용에 있어서 개인적으로 느꼈던 가장 큰 불편한점은 GPU를 사용할 수 없다는 것이었다. 잘 아는것은 아니지만 GDI(WinAPI에 쓰이는 그래픽 디바이스 인터페이스)는 CPU 만을 사용하기 때문에 우리가 생각하는 게임 그래픽에 적합한 출력 방법을 가진 장치는 아니라고 한다. 따라서 CPU 가 그만큼 과부하를 받는 것이고 프로그래밍 입장에서 프레임 걱정을 많이 해야했다. 사실 현재 하는 프로젝트가 많은 연산을 요구하는 게임이 아니기 때문에 프레임이 쉽게 떨어질 일은 없었지만 몇몇 WinAPI 함수의 사용은 주의를 필요로 했기 때문에 마냥 쉽게 받아들일 것은 아니었다고 생각한다.

우연히 프로그래밍 팀의 팀장을 맡게 되었는데 생각보다 힘들었다. 먼저 나의 수준이 높지 않아서 팀원들의 역량을 파악하는게 어려웠고, 때문에 역할 배분에서 적지 않은 고생을 했다. 나름대로 계획을 짜서 진행했음에도 불구하고 앞서 말한 문제 때문에 계획이 틀어지는 경우도 자주 있었고 당연히 기획에서 의도한 모든 것들을 해낼 수는 없었다. 개개인의 실력 부족도 이유라고 할 수 있겠지만 잘못된 역할 분배로 인한 시간 낭비로 소모되는 기간이 적지 않았던게 주된 이유라고 생각이 들어서 함께 했던 프로그래밍 팀원과 기획 팀원 모두에게 미안한 마음이 있었다.

개인적으로 아쉬운 점도 있었다. 평소에 기능에 대해 최대한 구상을 한 후에 코드를 짜는 게 깔끔한 코드가 나온다고 생각하는 편인데, 프로젝트 기간에는 그럴 여유가 많이 없어서 닥치는대로 기능을 구현하고 나중에 추가적인 부분이 있다면 끼워 맞추는 식으로 진행했다. 그러다 보니 어느샌가 코드는 괴물이 되어있었고 확장성도 매우 떨어지는 코드가 되어버렸다. 마치 만화에서 보이는 물이 새는 배수관처럼 한 곳을 막으면 다른 곳이 터지는 일도 비일비재했다.

또한 프레임워크에 대해 공부하지 않고 프레임워크를 만들려고 하다 보니 인터넷에 나와 있는 쉬운 정보를 무작정 따라하게 되었고 내 코드가 아니다 보니 완전히 이해하지 않고 쓰는 기능들도 종종 있었다. 때문에 제작하고 있는 게임에 적합하지 않는 부분도 몇몇 있었고 고치기 힘들었던 부분도 정말 많았다. 다음에도, 그리고 그 다음에도 나는 프로그래밍을 담당할 것이고 당연히 다시 프레임워크를 만들게 될텐데 어떻게든 나만의 프레임워크에 대한 정립을 마무리 짓는것이 올해의 목표이다. 절대 쉽게 될거라고 생각하지 않기에 천천히 길게 보며 공부할 예정이다.

아쉬웠던 점과는 별개로 프로그래밍 팀, 아트 팀, 기획 팀 모두가 제 역할을 잘해주었고 만족할만한 결과물이 나왔다고 생각한다. 기획에서 나왔던 많은 기믹들을 일부 구현하지 못해서 아쉬웠지만 그 아쉬움이 없어질만큼 깔끔했던 레벨 디자인과 게임의 전체적인 느낌과 너무 잘 어우러지는 아트가 만나 좋은 게임을 만들 수 있는 토대가 되었다. 프로그래밍 팀 또한 그에 부합하기 위해 모두가 노력했고 기분 좋은 프로젝트로 끝마칠 수 있어서 정말 좋았다.

!youtube[zIlGfcm2qls]

나에게 정말 큰 경험이 되었던 프로젝트였다. 내 손길이 온전히 들어간 게임을 만들 수 있는 기회가 얼마나 될까 싶기도 하고, 현재 하는 공부가 재밌기에 앞으로도 열심히 하고 싶다. 끝으로 정말 좋았던 게임인재원이지만 한가지 아쉬웠던 점이 있다. 바로 홍보가 정말 안되어있다는 것이다. 사실 이런 글을 적는 성격이 아니지만 이 글을 보고 열정을 가진 많은 사람들이 이곳에 왔으면 좋겠기에 후기를 남겨보았다. 자주는 안되더라도 한 학기마다 최소 하나씩은 후기를 남겨보려고 한다.

처음 위 코드를 작성했을 때 compare1 에서 굳이 번거롭게 void* -> const char* 로 직접 변환하면 될 것을 ** 로 변환하고 다시 역참조를 하는지 이해가 안갔다. 주변에 자문을 구해봤지만 잘 이해가 안가서 다른 변수를 인자로 받는 코드를 만들어 보았고 그것이 compare2 다.

compare2 로 만들면서 느꼈던 것은 당연히 * 로 변환하고 역참조를 해야한다고 생각했다는 것이다. compare1 에서 주장했던 것과 같은 논리를 해보자면 void* 로 들어온 값을 억지로 int 로 변환한다는 것인데 포인터로 들어온 자료형을 갑자기 int 로 바꾼다는 발상 자체가 말이 안된다는 것이다.

포인터를 상당히 오랜만에 다시 공부하게 되어서 헷갈리는 상황이 많이 발생하는데 종종 포인터에 국한하지 않고 다른 자료형으로 생각해보면 납득이 가는 경우가 꽤 있었다.

시연 영상

(이미지클릭)

코드

using System;
using System.Collections;
using System.Collections.Generic;
using System.Linq;
using BackEnd;
using LitJson;
using UnityEngine;
using Random = UnityEngine.Random;

// DB Function Naming Rule
// DB -> User = Get...
// User -> DB = Update...

public class BackendManager : MonoBehaviour
{
    private static BackendManager instance = null;

    private void Awake()
    {
        if (instance is null)
        {
            instance = this;
            DontDestroyOnLoad(gameObject);
        }
        else
        {
            Destroy(gameObject);
        }
    }

    public static BackendManager Instance
    {
        get
        {
            if (instance is null)
                return null;

            return instance;
        }
    }

    public Dictionary<string, RankItem> GetRank(int stageNum)
    {
        var rankItemList = new Dictionary<string, RankItem>();
        var uuid = GetRankId(stageNum);

        Debug.Log("Before GetDetailedRank");

        foreach (var id in uuid)
        {
            rankItemList.Add(id.Key, GetDetailedRank(id.Value));
        }

        Debug.Log("After GetDetailedRank");

        return rankItemList;
    }

    private Dictionary<string, string> GetRankId(int stageNum)
    {
        // BlockTypeCount, BlockLength, AveargeStep
        var rankTableItemList = new List<RankTableItem>();
        string[] rankTypeArray = { $"S{stageNum}_BL", $"S{stageNum}_BTC", $"S{stageNum}_AS" };
        var rankId = new Dictionary<string, string>();

        var bro = Backend.URank.User.GetRankTableList();

        if (bro.IsSuccess())
        {
            JsonData rankTableListJson = bro.FlattenRows();

            for (int i = 0; i < rankTableListJson.Count; i++)
            {
                RankTableItem rankTableItem = new RankTableItem();


                rankTableItem.rankType = rankTableListJson[i]["rankType"].ToString();
                rankTableItem.date = rankTableListJson[i]["date"].ToString();
                rankTableItem.uuid = rankTableListJson[i]["uuid"].ToString();
                rankTableItem.order = rankTableListJson[i]["order"].ToString();
                rankTableItem.isReset = rankTableListJson[i]["isReset"].ToString() == "true" ? true : false;
                rankTableItem.title = rankTableListJson[i]["title"].ToString();
                rankTableItem.table = rankTableListJson[i]["table"].ToString();
                rankTableItem.column = rankTableListJson[i]["column"].ToString();

                if (rankTableListJson[i].ContainsKey("rankStartDateAndTime"))
                {
                    rankTableItem.rankStartDateAndTime =
                        DateTime.Parse(rankTableListJson[i]["rankStartDateAndTime"].ToString());
                    rankTableItem.rankEndDateAndTime =
                        DateTime.Parse(rankTableListJson[i]["rankEndDateAndTime"].ToString());
                }

                if (rankTableListJson[i].ContainsKey("extraDataColumn"))
                {
                    rankTableItem.extraDataColumn = rankTableListJson[i]["extraDataColumn"].ToString();
                    rankTableItem.extraDataType = rankTableListJson[i]["extraDataType"].ToString();
                }

                rankTableItemList.Add(rankTableItem);
                Debug.Log(rankTableItem.ToString());
            }

            foreach (var type in rankTypeArray)
            {
                var result = rankTableItemList.Find(a => a.title.Equals(type));

                if (result is null)
                {
                    Debug.Log("No Rank Table Item Error");
                    break;
                }

                Debug.Log($"GetRankId Success. {type} : {result.uuid}");
                rankId.Add(type, result.uuid);
            }
        }

        return rankId;
    }

    private RankItem GetDetailedRank(string uuid)
    {
        RankItem rankItem = new RankItem();

        var bro = Backend.URank.User.GetMyRank(uuid);

        if (bro.IsSuccess())
        {
            Debug.Log("@GetDetailedRank Start");
            JsonData rankListJson = bro.GetFlattenJSON();
            string extraName = string.Empty;

            rankItem.gamerInDate = rankListJson["rows"][0]["gamerInDate"].ToString();

            if (rankListJson["rows"][0]["nickname"] != null)
                rankItem.nickname = rankListJson["rows"][0]["nickname"].ToString();
            else
                rankItem.nickname = "Unknown";

            rankItem.score = rankListJson["rows"][0]["score"].ToString();
            rankItem.index = rankListJson["rows"][0]["index"].ToString();
            rankItem.rank = rankListJson["rows"][0]["rank"].ToString();
            rankItem.totalCount = rankListJson["totalCount"].ToString();

            if (rankListJson["rows"][0].ContainsKey(rankItem.extraName))
            {
                rankItem.extraData = rankListJson["rows"][0][rankItem.extraName].ToString();
            }

            Debug.Log(rankItem.ToString());
        }

        return rankItem;
    }

    public Dictionary<string, Dictionary<string, List<string>>> GetOtherUserCode(int stageNum)
    {
        var topThreeCodes = new Dictionary<string, Dictionary<string, List<string>>>(); // <rankType, Dict<nickname, code>>
        var rankId = GetRankId(stageNum);

        foreach (var id in rankId)
        {
            var bro = Backend.URank.User.GetRankList(id.Value, 3, 0);

            if (bro.IsSuccess() == false)
            {
                Debug.Log("GetOtherUserCode Error : " + bro);
                return null;
            }

            var rankListJson = bro.GetFlattenJSON();
            var userCodeDict = new Dictionary<string, List<string>>();

            for (int i = 0; i < rankListJson["rows"].Count; i++)
            {
                var gamerRank = rankListJson["rows"][i]["rank"].ToString(); // key
                var gamerNickname = rankListJson["rows"][i]["nickname"].ToString(); // value
                var gamerCode = rankListJson["rows"][i]["UserCode"].ToString(); // value

                var list = new List<string>();
                list.Add(gamerNickname);
                list.Add(gamerCode);

                userCodeDict.Add(gamerRank, list);
                // Debug.Log($"{id.Key}, {i + 1} : {rankListJson["rows"][i]["UserCode"]}");
            }


            topThreeCodes.Add(id.Key, userCodeDict);
        }

        return topThreeCodes;
    }

    public void UpdateScore(int stageNum, int blockLength, int blockTypeCount, float averageStep, string userCode)
    {

        var rankId = GetRankId(stageNum);
        var tableName = $"STAGE_{stageNum}";
        var rowInDate = string.Empty;

        Param param = new Param();
        param.Add("BlockLength", blockLength);
        param.Add("BlockTypeCount", blockTypeCount);
        param.Add("AverageStep", averageStep);
        param.Add("UserCode", userCode);

        SendQueue.Enqueue(Backend.GameData.GetMyData, tableName, new Where(), bro =>
        {
            if (bro.IsSuccess() == false)
            {
                Debug.Log(bro);
                return;
            }

            if (bro.GetReturnValuetoJSON()["rows"].Count <= 0)
            {
               SendQueue.Enqueue(Backend.GameData.Insert, tableName, param, callback =>
                {
                    if (callback.IsSuccess() == false)
                    {
                        Debug.Log(callback);
                        Debug.Log("UpdateScore-Insert Error");
                        return;
                    }

                    if (callback.FlattenRows().Count > 0)
                        rowInDate = callback.GetInDate();

                    foreach (var item in rankId) // Dic <rankType , uuid>
                    {
                        InnerUpdate(item.Value, tableName, rowInDate, param);
                    }
                });
            }
            else
            {
               SendQueue.Enqueue(Backend.GameData.Update, tableName, new Where(), param, callback =>
                {
                    if (callback.IsSuccess() == false)
                    {
                        Debug.Log(callback);
                        Debug.Log("UpdateScore-Update Error");
                        return;
                    }

                    rowInDate = bro.GetInDate();        

                    foreach (var item in rankId) // Dic <rankType , uuid>
                    {
                        InnerUpdate(item.Value, tableName, rowInDate, param);
                    }
                });
            }
        });


    }

    private void InnerUpdate(string uuid, string tableName, string rowIndate, Param param)
    {
        SendQueue.Enqueue(Backend.URank.User.UpdateUserScore, uuid, tableName, rowIndate, param, bro =>
        {
            if (bro.IsSuccess() == false)
            {
                Debug.Log(bro);
                Debug.Log("UpdateScore-UpdateUserScore Error");
            }
        });
    }

    public (bool isValid, string message) CreateNickname(string nickname)
    {
        var bro = Backend.BMember.CreateNickname (nickname);

        return (bro.IsSuccess(), bro.GetMessage());
        // Error cases -> https://developer.thebackend.io/unity3d/guide/bmember/nickname/ 
    }

    public void UpdateMyInfo(UserInfo userInfo)
    {
        Param param = Param.Parse(userInfo);
        var tableName = "USER_INFO";

        SendQueue.Enqueue(Backend.GameData.GetMyData, tableName, new Where(), bro =>
        {
            if (bro.IsSuccess() == false)
            {
                Debug.Log(bro);
                return;
            }

            if (bro.GetReturnValuetoJSON()["rows"].Count <= 0)
            {
                SendQueue.Enqueue(Backend.GameData.Insert, tableName, param, callback =>
                {
                    if (callback.IsSuccess() == false)
                    {
                        Debug.Log(callback);
                        Debug.Log("UpdateMyInfo-Insert Error");
                        return;
                    }
                    Debug.Log("UpdateMyInfo-Insert Success");
                });
            }
            else
            {
               SendQueue.Enqueue(Backend.GameData.Update, tableName, new Where(), param, callback =>
                {
                    if (callback.IsSuccess() == false)
                    {
                        Debug.Log(callback);
                        Debug.Log("UpdateMyInfo-Update Error");
                        return;
                    }
                    Debug.Log("UpdateMyInfo-Update Success");
                });
            }
        });
    }

    public UserInfo GetMyInfo()
    {
        var bro = Backend.GameData.GetMyData("USER_INFO", new Where(), 1);

        if (bro.IsSuccess() == false)
        {
            Debug.Log("IsSuccess Error");
            Debug.Log(bro);
            return null;
        }
        if (bro.FlattenRows()["rows"].Count <= 0)
        {
            Debug.Log("No data");
            Debug.Log(bro);
            return null;
        }

        var myInfoJson = bro.FlattenRows();

        var userInfo = JsonMapper.ToObject<UserInfo>(myInfoJson.ToJson());
        Debug.Log(userInfo.ToString());

        return userInfo;
    }

    public string CreateRandomNickname()
    {
        var frontWord = new[] {"신나는", "멋진", "행복한","슬픈","우울한","재수없는","고생하는","귀여운", "오른손이 커다란", "밥을 좋아하는"};
        var backWord = new[] {"바지", "옷걸이", "얼음", "코끼리", "개미핥기", "빨대", "가방", "눈꺼풀", "의자", "팔꿈치"};

        var randFront = Random.Range(0, frontWord.Length);
        var randBack = Random.Range(0, backWord.Length);

        return frontWord[randFront] + backWord[randBack];
    }
}

목표 선정 및 피드백

1.시작

목표

- GPGS 로그인

활동

- 안드로이드 빌드 이슈 해결
- GPGS 이슈 해결
- 로그인 구현 시도

2.중간 발표

목표

- GPGS 로그인
- 뒤끝 SDK 활용 → 유저 정보 저장
- 랭킹 생성 / 갱신

    → 팀원 피드백 : 랭킹 랜덤 조회 → 상위 3명 조회로 변경 요청


활동

- GPGS 로그인 활성화
- 뒤끝 서버 유저 정보 저장 완료

3.팀 발표

목표

- 랭킹 생성 / 갱신
- 랭킹 조회
- 유저 정보 생성 / 갱신
- 유저 정보 조회

활동

- 랭킹 조회에 대한 피드백 반영
- 각종 이슈 해결

4.최종

목표

- 기존 목표 기능 보완

활동

- 기존 목표 기능 추가 발생 이슈 해결
- 다른 팀원의 이슈 해결 도움

5.느낀점

백엔드 개발은 처음이었는데, 처음부터 끝까지 디버깅과의 전쟁이었다고 생각이 듦. GPGS 특성상 구글 플레이 콘솔에 Android App Build 파일(이하 aab)을 업로드 하지 않으면 해당 버전을 실행 조차 할 수 없어서 디버깅하는데 상당한 시간을 소요함. 특히나 안드로이드 빌드는 컴퓨터의 성능에 의해 시간이 많이 좌지우지 되어 불편함이 많았음. 백엔드의 특성상 클라이언트가 요구하는 객체만 넘겨주면 되기 때문에 적절한 객체를 약속하고 그 객체가 올바르게 반환 될 때까지 스스로 디버깅하면서 작업하는 일의 반복이기 때문에 상대적으로 팀원들과의 소통이 적었고 이로 인해 야기되는 불편한 점이 종종 있었음. 예를 들면 스테이지의 인덱스 번호를 0부터 시작할지, 1부터 시작할지 정도나 반환되는 객체가 복잡해져서 이를 다시 설명해야되는 경우 등 몇몇 불편한 경우를 겪고 소통의 중요성을 체감함.

6.개선점

디버깅 및 기능 변경 요구를 거치면서 코드에 수정을 거듭하게 되었는데, 이로 인해 시각적으로 보기에 안좋아진 코드들이 생기게 되었음. 다음부턴 디자인 패턴을 고려하며 수정하더라도 기존의 코드를 재사용할 수 있게끔 만들고 싶음. 팀 프로젝트 초반에는 느끼지 못했지만 후반에 데드라인이 가까워짐에 따라 소통의 부재가 아쉬웠음. 다음에는 좀 더 적극적으로 소통에 참여하기로 다짐함. 이번 프로젝트에서는 주로 API 를 다루었기 때문에 짜여진 코드를 잘 조립해서 원하는 모양을 만들어내는 것에 그쳤지만 다음에 다시 백엔드를 맡게 된다면 서버만 얻은 채로 직접 밑바닥부터 개발해보고 싶음.

구현 세부사항

1. 구현 방식

서버의 주요 기능은 Assets/Scripts/Backends/BackendManager.cs 에 구현 됨.

싱글톤 패턴으로 BackendManger.Instance.함수명 으로 사용 가능.

각 함수가 리턴하는 객체의 사용 여부에 따라 객체를 반드시 함수 실행 이후에 사용해야 한다면 동기 방식으로, 실행 순서에 관계없다면 SendQueue(비동기와 유사) 방식으로 사용함.

동기 방식 적용 함수

GetRankId, GetDetailedRank, GetOtherUserCode, CreateNickname, GetMyInfo

주로 서버로부터 클라이언트가 객체를 전달받을 때 적용

SendQueue 방식 적용 함수

UpdateScore, InnerUpdate, UpdateMyInfo

주로 클라이언트가 서버로 객체를 전달할 때 적용

2. 구현 기능

• 유저 가입

  GPGS + 뒤끝 서버 SDK 사용

  Assets/Scripts/Backends/GoogleLogin.cs 참조

  1. 유저가 사용중인 플레이스토어 아이디로 자동으로 회원 가입 시도

  2. 회원 가입 요청이 정상적으로 이루어 졌다면 Social.localUser.Authenticate((bool success))

     1. 기존 회원의 가입 요청의 경우

        BackendManager.Instance.GetMyInfo() 로 서버에서 로드

        2. 신규 회원의 가입 요청의 경우

           랜덤한 닉네임을 생성한 후 기본 정보를 서버에 업데이트 및 로드

           UpdateMyInfo(NewuserInfo) : 새로 생성된 정보를 USER_INFO 테이블에 저장함

           CreateNickname(nickname) : 새로 생성된 닉네임을 뒤끝 서버에 전달함

생성된 유저 테이블은 위의 `DB - 유저 테이블` 이미지와 같은 형식

• 유저(자신) 정보 조회

  뒤끝 서버 SDK 사용

  Assets/Scripts/Backends/BackendManager.cs 참조

  GetMyInfo 로 사용 가능하며 USER_INFO 테이블에서 유저 고유 값(uuid)에 맞는 정보를 가져와 클라이언트에 로드함.

• 랭킹 생성 / 갱신

  뒤끝 서버 SDK 사용

  Assets/Scripts/Backends/BackendManager.cs 참조

  UpdateScore 로 사용 가능하며 생성과 갱신의 기능을 동시에 담당할 수 있게끔 SDK 를 변형하여 적용함.

  1. 클리어한 스테이지 정보를 서버로부터 가져옴(GetRankId)

  2. 서버에 자신의 데이터가 있는지 검사(Backend.GameData.GetMyData)

     1. 정보가 없다면

        Backend.GameData.Insert → InnerUpdate 를 통해 정보를 삽입함

     2. 정보가 존재한다면

        Backend.GameData.Update → InnerUpdate 를 통해 정보를 갱신함

생성(삽입)과 갱신을 하나의 함수에서 처리한 이유

두 기능의 공통점은 정보를 바꾼다는 것인데, 뒤끝 서버에서 제공하는 함수는 같은 역할을 할 수 있는 하나의 함수가 없기 때문에 개발의 편의를 위해 두 기능을 하나의 함수로 묶음

`InnerUpdate` 의 역할

내부적으로 `Backend.URank.User.UpdateUserScore` 를 SendQueue 방식으로 수행함

• 랭킹 조회

  뒤끝 서버 SDK 사용

  Assets/Scripts/Backends/BackendManager.cs 참조

  1. 자신의 랭킹 조회

     GetRank 로 사용 가능

     Dictionary<string, RankItem> 형태로 반환하며 key값(분야)에 따른 자신의 순위를 RankItem.rank 로 조회 가능

  2. 상위 3명의 코드 조회

     GetOtherUserCode 로 사용 가능

     Backend.URank.User.GetRankList 의 파라미터를 적절하게 입력하여 분야별로 1등부터 상위 3명의 랭킹 정보를 가져옴

     가져온 Json 타입 정보 중 필요한 정보만 분리하여 클라이언트에게 전달함

     전달하는 객체 : Dictionary<string, Dictionary<string, List<string>>>

     → < 분야 , < 랭킹(인덱스) , 코드리스트 > >

유니티에서 더블 클릭을 구현하기가 여간 귀찮다. 방법이야 정말 여러개가 있지만 업데이트 문에서 감지한다던가 UniRx 를 써서 감지한다던가 하는 것도 가능하지만 성능상의 단점, 구현의 한계 등으로 몇번 시도해보다가 다른 방향으로 틀게 되었다. 이 문제의 핵심은 대쉬 구현이 아닌 키보드 더블 탭 구현이다. 그리고 이번도 저번과 마찬가지로 New Input System 을 활용한다.

해결방법

Actions - Dash 의 Binding Properties 를 보면 Interactions - Multi Tap 기능이 있다. 간략히 설명을 하자면 다음과 같다. 상세 정보는 링크를 확인

Tap Count - 상호작용을 위해 필요한 탭 수 Max Tap Spacing - 탭 사이의 입력이 없어도 되는 시간 Max Tap Duration - 탭의 최대 입력 시간 Press Point - (정확한 정보 확인시 추가)

몇번 테스트 해본 결과 아주 만족스러운 디폴트 값이었기에 그냥 쓰기로 했다. 기존의 New Input System 과 마찬가지로 SendMessage 방식으로 작동하기에 OnDash 함수를 구현해주고 코루틴으로 애니메이션과 쿨다운을 넣었다.

더블 탭은 유니티에서 구현해주었으니 우리는 대쉬만 구현하면 된다.

작동방식

1. New Input System -> OnDash() 실행
2. 대쉬가 가능하면 애니메이션을 실행하고 코루틴을 시작
3. 대쉬 불가능 처리 및 현재 gravity 저장 후 순간 속도 증가
4. 대쉬 애니메이션이 끝나면 현재 위치에 따라 적절한 애니메이션으로 변경
5. 대쉬 전 변수들을 복구 후에 특정 시간이 지나면 대쉬 가능 처리

코드

    private void OnDash() // 1
    {
        if (isAbleDash)
        {     // 2
            anim.Play("Dash", -1, 0);
            StartCoroutine(DashStart());
        }
    }

    private IEnumerator DashStart()
    {
        Debug.Log("Dash!");
        Debug.Log("Dash Cool Time Start");

        // 3
        isAbleDash = false;
        isDashing = true; // isDashing 동안 사용자의 입력을 받지 않음
        var originalGravity = rigid.gravityScale;
        rigid.gravityScale = 0f;
        rigid.velocity = new Vector2(transform.localScale.x * dashPower, 0);

        // 4
        while (anim.GetCurrentAnimatorStateInfo(0).normalizedTime <= 1.0f)
        {
            yield return null;
        }

        if (isGrounded)
            anim.Play("Idle", -1, 0);
        else
            StartCoroutine(JumpAnimation());

        // 5
        isDashing = false;
        rigid.gravityScale = originalGravity;
        rigid.velocity = new Vector2(0, 0);
        yield return new WaitForSeconds(dashCooldown); // 1초
        isAbleDash = true;

        Debug.Log("Dash Cool Time Finished");
    }

실행 결과

다른 실행 장면을 각기 녹화한것이라 결과의 모습이 다르지만 잘 되는 걸 확인 할 수 있다.