For-Each-Schleife über verschiedene Template-Klassen?



  • Hi,

    folgende Klassenbeziehung gilt:

    class BaseOptionPacket
    {
    // ...
    };
    
    template<typename T>
    class OptionPacket : public BaseOptionPacket
    {
    // ...
    	void print_current_value();
    };
    

    Nun möchte ich einen Container anfertigen, der mitunter eine forall-Funktion anbietet:

    class OptionPacketContainer
    {
    	static std::map<OPTID, BaseOptionPacket*> option_packets;
    public:
    	inline void forall_do(void (*funcptr)(OptionPacket<T>*)) {
    		for(itr i = option_packets.begin(); i!= option_packets.end(); i++)
    		 (*funcptr)(static_cast<OptionPacket<T>*>(i->second));
    	}
    
    	template<typename T>
    	inline static void print_single_current_value(const BaseOptionPacket* p) {
    		(dynamic_cast<OptionPacket<T>*>(p))->print_current_value();
    	}
    
    	template<typename T>
    	inline void print_current_values() {
    		forall_do_const(print_single_current_value<T>);
    	}
    
    }
    

    Irgendwie war das aber nicht was ich wollte. print_current_values() sollte eigentlich kein Template mit sich mitschleppen, denn ich brauche ja eine Funktion, die alles macht (also alle OptionPacket<int>, OptionPacket<float>,...).

    Gibt es irgendeine Lösung für dieses große Problem? Ich wäre sehr froh, wenn jemand so lieb sein könnte, mir zu helfen!!

    Gruß,
    Johannes



  • Kannst du nicht eine rein virtuelle Funktion in BaseOptionPacket deklarieren und in den abgeleiteten Klassen implementieren?



  • voidpointer schrieb:

    Irgendwie war das aber nicht was ich wollte. print_current_values() sollte eigentlich kein Template mit sich mitschleppen, denn ich brauche ja eine Funktion, die alles macht (also alle OptionPacket<int>, OptionPacket<float>,...

    , OptionPacket<Wurstbrot>, Optionpacket<MeineKlasse>, OptionPacket<DeineKlasse>, OptionPacket<EineAndereKlasseDieIrgendwerInDreiJahrenSchreibenWill> - merkste was?

    Du kannst nicht wissen, was für OptionPackets irgendwann mal in deinem Container landen werden. Die OptionPackets müssen daher selber wissen, wie sie sich zu verhalten haben und müssen deshalb ihre Bearbeitungen selber mitbringen.



  • Super, das ist natürlich die Lösung!! Vielen Dank.



  • Das Visitor Pattern wäre noch eine alternative, kommt drauf an, welchen Fall du hast. Wenn abzusehen ist, dass über die Zeit mehr Klassen dazukommen sind virtuelle Methoden die bessere Alternative, wenn allerdings mehr Operationen dazukommen könnte das Visitor Pattern die bessere Wahl sein.


Anmelden zum Antworten