C++에서 'enum class' (스크 scoped enum) 메커니즘에 대해 설명해 주세요. 일반 열거형과 어떤 점이 다르며 왜 도입되었나요? 기존의 enum에서 enum class로 전환할 때 일반적인 오류는 무엇인가요?

답변

C++11에서 'scoped enums' 메커니즘이 도입되었습니다 — 키워드 enum class.

전통적인 enum과의 주요 차이점:

• enum class의 내용은 고유한 범위(scope)를 가지며, 전역 네임스페이스가 오염되지 않습니다.
• 열거자가 int로 암시적으로 변환되지 않습니다 (명시적으로 형 변환이 필요합니다).
• enum class의 기본 타입은 int이지만, 다른 타입을 지정할 수 있습니다 (예: enum class MyE : uint8_t { ... };).

필요한 이유: 타입 안전성을 높이고, 이름 충돌 및 잘못된 비교를 방지하며, 저장 관리를 명시적으로 제어하기 위해.

예시:

enum Color { Red, Green };
Color c = Red;        // 일반 enum, Red는 전역적으로 보입니다.
enum class State { Off, On };
State s = State::On;  // State::On을 명시적으로 지정해야 합니다.

작성할 수 없는 코드:

enum class State { Off, On };
int x = State::On; // 오류! 명시적인 변환이 필요합니다.
int y = static_cast<int>(State::Off); // 괜찮습니다.

속임수 질문

왜 enum class의 값이 이름과 기본 타입이 같은 경우에도 서로 다른 enum class의 값들끼리 논리 비교를 할 수 없나요?

답변:

타입 안전성: 각 enum class는 고유한 타입을 가지며, 기본 타입이 동일하고 열거자가 이름이 동일하더라도 컴파일러는 이를 다른 타입으로 인식하고 암시적인 비교를 허용하지 않습니다.

주제의 세부 사항에 대한 무지로 인한 실제 오류 사례.

---

사례

기계 제어 프로젝트에서 enum에서 enum class로 전환할 때, 로그 출력 시 명시적 변환을 추가하는 것을 잊어버렸습니다. 로그는 "이질적인" 값을 보여주기 시작하여 (State::On을 숫자로 인식하지 못함) 디버깅이 복잡해졌습니다.

---

사례

REST 서비스에서 일반 enum을 enum class로 마이그레이션한 후, 코드가 서로 다른 enum class의 다양한 열거형 값을 비교했습니다. 컴파일러는 이를 허용하지 않아 자동 테스트가 실패했습니다.

---

사례

감사 시스템에서 개발자들이 구형 및 신형 구문을 혼동 — 때때로 실수로 enum class를 선언했지만, 자격 없는 열거자를 사용하여 컴파일되는 코드가 다르거나 동일한 이름으로 인해 링킹 오류가 발생했습니다.