2012-07-26 2 views
0

dynamic_casting에 대한 약간의 연구를했는데 RTT라는 이름의 무언가를 만들었습니다. 시작시 RAM에로드되는 이 생성됩니다. 일부 플랫폼에서는 이것이 지원되지 않습니다. 그래서 그것을 피할 수있는 좋은 해결책이 있는지 궁금 해서요.C++ dynamic_casting을 피하는 방법?

의 내가 문 클래스

class Statement 
{ 
    std::list<Operand*> operands; 
}; 

이 있고 피연산자 요법 같은 더 서브 클래스, 메모리 주소, 등록,있는 클래스입니다 가정 해 봅시다. (어떤 궁금한 점에 대해서는 어셈블러를 만들려고합니다 : P

dynamic_cast로 다운 캐스팅을 할 수는 없지만 나쁘면 나쁠 수는 없지만, 유형을 정의하는 피연산자에 열거 형을 추가하면 어떻게 될까요? 그래서 나는

나는 그것을 const를 만들 수 있습니다.이 유형의 사용에 의해 static_cast로 다운 캐스트, 나는 당신의 모든 생각을 기대 맞죠?

모든 서브 클래스의 생성자를 정의 할 수 있습니다.

크리스티앙

+7

다형성에 의지하고 객체의 구체적인 유형을 전혀 신경 쓰지 않는 것이 이상적입니다. 왜 당신은 다운 캐스트가 필요하다고 생각합니까? –

+0

어셈블러를 실행할 플랫폼은 무엇입니까? 개발자의 컴퓨터에서 실행해야한다면 RTTI의 효과가 무시 될 것이라고 가정하는 것이 안전합니다. (아주) 낮은 사양의 임베디드 타겟에서 실행해야한다면 올바른 경로에 있습니다. 이제 dynamic_cast를 잘못 사용하고있는 것처럼 느껴집니다. 일반적인 OOP 작업의 경우 dynamic_cast를 수행 할 필요가 없습니다. 기본 클래스에 정의 된 메소드 만 사용하면됩니다. –

+0

@ BjörnPollex에 동의합니다. 귀하의 문제가 유형 캐스팅없이 해결 될 수 없다면, 수업 설계가 잘못되었을 수 있습니다. 하지만 상관 없으면 방문객 패턴에 참여하는 것이 좋습니다. 그러나이 패턴은 열거 형과 동일한 기능을 제공하며 일반적으로 구성 요소 coopling으로 연결됩니다. –

답변

2

유형 만들기 - 옵션입니다.

Operand에 대해 일반 interface을 작성하는 것이 좋습니다. 따라서 memory address, register 등의 인터페이스가 해당 인터페이스를 구현하므로 다형성으로 처리 할 수 ​​있습니다.

interface을 발명 할 수없는 경우 공통 인터페이스가 필요하지 않으므로 클래스를 다시 설계하는 것이 좋습니다.

당신은 코드 재사용을해야하는 경우 - 당신은 당신이 캐스트를 아래로로 결정한 경우, composition하지 inheritance

2

를 이동, 당신은 적절한 유형에 도착하는 인터페이스를 사용하여 고려할 수 있습니다. 그러나 서브 클래스도 명시 적으로 나열 할 수 있습니다.

class Operand { 
public: 
    enum Type { OT_Address, OT_Register, /*...*/ }; 
    virtual Type type() const = 0; 
    virtual AddressOperand * isAddress() { return 0; } 
    virtual RegisterOperand * isRegister() { return 0; } 
    //... 
}; 

그런 다음 다운 캐스트 대신 해당 유형과 관련된 메소드를 호출하면됩니다. 파생 클래스는 다음과 같이 구현합니다.