2011-03-03 2 views
1

Qt 플러그인을 일반 구성원 함수 및 변수로 컴파일하는 데 문제가 있습니다. 아이디어는 다음과 같습니다. A (다른 인터페이스) 지정되지 않은 유형의 다른 플러그인을 사용하는 플러그인 A1이 있습니다. A1은 인터페이스 (추상 클래스)를 구현합니다. A. 다른 플러그인을 전달하는 함수가 필요합니다.C++ Qt 플러그인 인터페이스의 템플릿 클래스 대체

그것은 다음과 같습니다

template <typename T> 
class A { 
public: 
    void setPlugins(QList<T*>* plugins) 
    { 
    plugins_ = plugins; 
    } 
private: 
    QList<T*>* plugins_; 
}; 

내가 바로 템플릿을 이해하지만이 정상적으로 작동해야한다고 생각 바랍니다. 문제는 이제 플러그인 인터페이스 (A)를 Qt의 플러그인 개념을 가진 템플릿 클래스로 정의하는 것이 불가능한 것 같습니다. 내가 원하는 것을 할 수있는 또 다른 방법이 있습니까?


편집 : 내가 RTTI없이 솔루션을 선호합니다. 내가 대답하려고합니다

답변

1

...

는 Qt는에서 모든 플러그 인 클래스 QObject를 상속한다.
따라서, 당신은 템플릿을 삭제할 수 있으며, 플러그인 저장 QObjects 포인터의 목록을 사용하면 유형 정보를 잃게됩니다 어떻게 든 플러그의 유형을 추론해야합니다이 경우 그러나

QList<QObject*> plugins_; 

을 나중에 QObject 포인터에서부터 플러그인의 목록에있는 특정 플러그인을 사용해야 할 때 사용할 수 있습니다.
QObject는 다형성 유형이므로 dynamic_cast를 사용하여 필요할 때 정확한 플러그인 유형을 결정할 수 있습니다. 희망이 도움이됩니다.

+0

...'-fno-rtti'를 사용하지 않으면. –

+0

아이디어가 좋고 잘 작동해야하지만, 설정해야 할 플러그인의 인터페이스는 QObject가 아니라 해당 구현 만 상속받습니다. 즉, 호출자 목록을 QObject * 목록으로 선언해야한다는 것을 의미합니다. ecPecially이 목록을로드 된 플러그인에 넣지 않을 때 처리 할 수있는 것은 좋지 않습니다 (내가 지금하는 것처럼). 그러나 어쩌면 이것이 그럴 가능성이 있습니다. – FunkyClaude

+0

@Mike DeSimone : 당신 말이 맞아요. 누군가 RTTI가없는 해결책을 알고 있을까요? – FunkyClaude

0

하나의 문제는 A가 클래스가 아니라 클래스의 템플릿이라는 것입니다. 귀하의 인터페이스에 콘크리트 A <x>을 사용해야 할 것입니다.