[Reflection Project] C++ 17 Reflection Project

C++ 20에서 리플렉션 구현 : https://xtozero.tistory.com/8

C++에서 리플렉션 구현하기

 

위의 사이트를 참고해서, C++17에서 리플렉션을 구현해보았다.

Github : https://github.com/Winteradio/Reflection

GitHub - Winteradio/Reflection: Project for reflection system on C++ like unreal engine

 

진행하면서 겪었던 문제점은 주로, 타입 추론과 템플릿이었다.

타입 추론은 "decltype"의 한계점이 어디까지인지를 명확히 아는게 중요했다.

 

예를 들어서, 오버로딩되는 함수들이 있다고 했을 때 해당 함수들의 타입을 "decltype"으로만 추론하기엔 한계점이 있다.

또한, 함수와 변수의 타입 추론에서 const 키워드의 존재 유무도 조금씩 다른 측면이 있었다.

 

해당 부분들은 주로 템플릿 특수화를 통해서 해결하는 식으로 진행했다.

 

가장 큰 문제점인 템플릿이었다.

제일 먼저 "SFINAE(Substitution failure is not an error)"의 개념을 파악하는 게 중요했다.

쉽게 얘기하면, 치환 실패를 통한 기능을 사용하기 위해선, 템플릿 정의문에 한번 감싸진 템플릿을 사용하면 된다.

그래서, std::enable_if 같은 템플릿을 많이 사용했다.

 

또, 함수와 객체 템플릿의 특수화에 대한 차이점이었다.

함수 템플릿은 부분 특수화가 되지 않는다. 하지만, 객체 템플릿에선 부분 특수화가 된다.

그래서, 함수로 구현해서 특수화 시키려고 했던 부분들 (MethodCall 생성)과 같은 부분들은

객체 부분 특수화 후, 객체 내부의 static 함수를 호출해서 사용하는 식으로 해결했다.

 

마지막으론, 템플릿 매개인자에 대한 순서이다.

초창기에 템플릿을 사용할 때 (Variant 구현)는 타입 파라미터 팩이 제일 마지막에서만 사용할 수 있는 걸로 알고 있었다.

하지만, 구현하다보니 타입 매개인자-> 타입 파라미터 팩 -> 비타입 매개인자 순으로 구현이 가능했다.

또한, 비타입 매개인자는 템플릿 특수화의 매개인자로는 못 들어간다.

 

그리고, 좀 신기했던 부분은 static 변수에 대한 초기화 순서다.

현재 프로젝트에선 TypeManager가 static 변수로써 싱글톤 패턴으로 사용하고 있다.

그래서 처음엔, 그냥 static 변수를 외부에 노출시키고, Handle만 반환하는 식으로 구현했었는데,
만일, 특정 헤더에서 싱글톤 패턴을 호출하고, 실제 static 변수의 초기화가 소스 파일에서 진행된다면,
해당 static 변수가 초기화 되기 전에 이미 헤더에서 접근하고 있으므로 잘못된 접근이 된다.

그래서, Handle을 가져가는 함수 내부에서 static 변수를 만들고 반환하는 식으로 해당 문제를 해결했다.

아직 남은 문제점들이 많다.

위의 글 작성자께서 언급하셨던 문제점들이 대부분 남아있는 상태이다.

• 함수 오버로딩 불가 (객체 내부, 동일 명칭 함수들에 대한 타입 추론 불가로, 오버로딩 지원하지 않음)
• 멤버 변수의 const 유지 불가 (정확한 원인 모르겠음, const 멤버 변수 타입이 일반 타입으로 추론되어, const 여부 판단 불가)
• TypeManager의 스레드 안전성 (Register를 하는 시점이 과연 안전한가? Mutex 처리를 해야되나? 프로그램 시작할 때, 여러 스레드에서 타입 정보를 등록할 일이 있을까?)
• typeid 사용 (컴파일러마다 네임 맹글링이 다르기에, 유저 입장에선 플랫폼마다 리플렉션되는 정보들이 다를 수 있다)
  
  

이런 문제들을 생각하면서, UHT는 정말 잘 만든 툴이구나 싶었다.

아무튼... 전 회사에서 이 프로젝트를 과제로 받았을 땐 엄두가 안 났는데,
지금 시점에서라도 확인해보고 싶어서 진행한 프로젝트다.

잘 구현된 프로젝트인지는 사용해보면서 알아야 할 것 같지만, 그래도 템플릿에 대해서 보다 깊게 알게 된 것 같다.