3. virtual+templates-das verfeindete paar

virtual+templates-das verfeindete paar

  • O

    huhu ihr alle 😉
    ich weis ja, dass virtual+templates probleme macht, aber das es soweit geht das

    virtual TexturePointer<PDIRECT3DTEXTURE9> getTexture(std::string TextureName)=0;

    nicht akzeptiert wird, hätte ich nie gedacht.

    wieso wurden diese beiden techniken, also templates +virtual nicht so aufeinander abgestimmt, dass sie wenigstens begrenzt-wenn nicht sogar problemlos miteinander auskommen können?

    Irgendwann nervt die ganze umprogrammiererrei schon 🙄

    0
  • S

    Dir ist klar, dass Templatefunktionen zur Compiletime erstellt werden.

    Es kann nicht fuer jeden moeglichen Typen eine Funktion erstellt werden - das wuerde den Code ja masslos aufblaehen.

    Aber virtuelle Funktionen werden zur Laufzeit ausgewaehlt - wie kann der Compiler wissen, fuer welche Typen er die Funktionen erstellen muss?

    0
  • ?
     

    virtual TexturePointer<PDIRECT3DTEXTURE9> getTexture(std::string TextureName)=0;

    Sollte eigentlich gehen, da es ja keine Templatefunktion ist. Also sowas schluck mein Compiler ohne weiteres:

    virtual lock_ptr<File>load(lock_ptr<File>,istream&)=0;

    Bist du sicher, dass du nicht in der Zeile obendrüber ein ; vergessen hast? Das führt oft zu den eigenartigsten Fehlermeldungen.

    0
  • O

    ne, bei mir wars eine "}" ich hasse den bcb 🙄

    thx

    trotzdem nervt mich die sache mit virtual+templates.

    0
  • S

    Shade Of Mine schrieb:

    Es kann nicht fuer jeden moeglichen Typen eine Funktion erstellt werden - das wuerde den Code ja masslos aufblaehen.

    Das interressiert mich jetzt aber wie sieht das denn aus? Ich dachte es werden alle Funktionen die im Code benötigt werden erstellt und dass dies der Nachteil von Templates ist, da es den Code massiv aufbläht.

    0
  • S

    @SirLant: Das ist ja auch richtig. Aber bei virtual steht ja vorher der Typ noch nicht fest, könnte ja Basisklasse sein, genauso gut aber irgendeine abgeleitete Klasse. Und der Typ muss aber zur Compiletime feststehen, bzw. der Compiler würde (ist aber nicht so) für jeden möglichen Typ diese Funktion erstellen - das würde das Programm furchtbar aufblähen.

    MfG SideWinder

    0
  • B

    So'n Quark. Ich wette, du schaffst es nicht, ein Programm zu konstruieren, das genau aufgrund dieses "Problems" nicht compiliert wird.

    Den einzigen Reibungspunkt zwischen Templates und virtuellen Funktionen gibt es bei Template-Memberfunktionen, die -- mehr oder weniger willkürlich festgelegt -- nicht virtuell sein dürfen. Könnte damit zu tun haben, dass der Compiler die VTable konstruiert und nicht der Linker. Wenn das erlaubt wäre, würde das Layout der VTable von allen Instanziierungen des Templates, also von potentiell mehreren Übersetzungseinheiten, abhängen.

    0
  • S

    Bashar schrieb:

    Wenn das erlaubt wäre, würde das Layout der VTable von allen Instanziierungen des Templates, also von potentiell mehreren Übersetzungseinheiten, abhängen.

    Stellt sich dann nur die Frage, wie man es mit Klassen die dynamisch aus zB einer DLL oder SO geladen werden, macht.

    Denn die _koennen_ nicht wissen, fuer welche Typen die virtuelle Template Methoden bereitstellen muessen.

    0
Anmelden zum Antworten