3. Rückgabewert überladen

Rückgabewert überladen

  • W

    @hustbaer: Mir ist bloß schleierhaft, wieso er meint, er könne einen wxString in einen myvector<T> konvertieren. Schließlich gibt es bloß den Konstruktor myvector::myvector(size_t i = 0).
    Es müsste ja wxString zu myvector<const char[]> konvertiert werden und dass der Compiler das zweite Argument matcht und dann gleich alle Template-Funktionen des ersten Arguments instantiiert, glaube ich nicht.

    0
  • F

    Warum nicht boost::any und boost::any_cast benutzen?

    0
  • W

    EDIT: Hier stand Müll.

    0

  • wxSkip schrieb:

    @hustbaer: Mir ist bloß schleierhaft, wieso er meint, er könne einen wxString in einen myvector<T> konvertieren. Schließlich gibt es bloß den Konstruktor myvector::myvector(size_t i = 0).

    Da myvector<T> ein Template ist, könnte erstmal grundsätzlich eine Konvertierung möglich sein.
    Könnte ja eine Spezialisierung myvector<char[13]> geben, oder myvector<char[N]> oder was auch immer. Und so eine Spezialisierung könnte einen ctor(wxString cosnt&) haben.

    Und um herauszufinden welche Konstruktoren die Template-Klasse myvector<char[13]> hat, muss der Compiler myvector<char[13]> instanzieren. Dabei werden natürlich nicht alle Memberfunktionen von myvector<char[13]> instanziert.

    Das Instanzieren von myvector<char[13]> ist auch nicht das Problem, sondern das Instanzieren des operator + Templates.

    Der Compiler muss nämlich auch alle eventuell in Frage kommenden operator + Templates instanzieren, damit er sein Overload-Set bilden kann, damit er mit dem fertigen Overload-Set dann die Overload-Resolution starten kann. Um rauszubekommen ob er einen "besten" Kandidaten findet, mehrere gleich gute, oder gar keine.

    Vermutlich ergibt sich das Problem dadurch, dass der operator+(myvector<T>, T) irgendwo eine (Member)funktion von myvector<T> verwendet, die T als Returntyp hat. Hab ich eigentlich schon geschrieben. Und da operator+(myvector<T>, T) mit T = char[13] instanziert wird, knallt es an der Stelle.

    Und, jetzt fällt es mir wieder ein: SFINAE "erlaubt" diesen Fehler nicht, da er sich (vermutlich) im Funktionsrumpf befindet, und nicht schon im "Prototyp" zuschlägt. (Zumindest ist das das Verhalten das ich öfters beobachtet habe, wie gesagt: SFINAE ist für mich ganz dunkle Magie, muss ich mich erst noch weiter damit befassen um das halbwegs gut zu überglicken)

    0

  • @FrEEzE2046:
    deswegen 🙂

    ccquestions schrieb:

    hustbaer schrieb:

    Ähnliche Funktionalität gibt es übrigens bereits fertig in der Boost, nennt sich boost::any .

    Ich habe mich bis jetzt bezüglich der boost Bibliothek und sogar der standard Bibliothek etwas zurückgehalten, da ich mich, auch wenn das alles verlockend klingt, noch selbst persönlich mit den Basics an der Quelle rumschlagen will, um so mein Verständnis zu verbessern. Gleich selbst aufwändigere Template Containerklassen etc zu schreiben hat mir persönlich jetzt trotz einiger immer wieder mal auftretender Probleme schon viel gebracht. Schreibe gerade zum ersten Mal an einem Programm, das den Namen auch wirklich langsam verdient hat... ( 10'000+ Zeilen ).

    0
  • W

    hustbaer schrieb:

    Vermutlich ergibt sich das Problem dadurch, dass der operator+(myvector<T>, T) irgendwo eine (Member)funktion von myvector<T> verwendet, die T als Returntyp hat. Hab ich eigentlich schon geschrieben. Und da operator+(myvector<T>, T) mit T = char[13] instanziert wird, knallt es an der Stelle.

    Nein, sieht nicht so aus. Ich frage mich aber sowieso, warum der Compiler dann nicht einfach erstmal nach der eventuellen Spezialisierung myvector<const char[13]> Ausschau halten kann, anstatt gleich die Funktionen zu spezialisieren. Hätte die Funktion gar kein zweites Argument mit dem Typ T, wäre er ja auch nicht auf die Idee gekommen, nach myvector<const char[13]> zu suchen.

    0
  • F

    hustbaer schrieb:

    @FrEEzE2046:
    deswegen 🙂

    Nun, boost::any kann man sich doch auch recht schnell selber schreiben 😉

    0
  • T

    Wäre b oost.variant da nicht besser geeignet?

    0

  • wxSkip schrieb:

    Ich frage mich aber sowieso, warum der Compiler dann nicht einfach erstmal nach der eventuellen Spezialisierung myvector<const char[13]> Ausschau halten kann, anstatt gleich die Funktionen zu spezialisieren.

    Ich glaube mich zu erinnern, dass der Standard das vorschreibt. Müsste in der Sektion Overload-Resolution (Sektion 13 IIRC) zu finden sein.

    Hätte die Funktion gar kein zweites Argument mit dem Typ T, wäre er ja auch nicht auf die Idee gekommen, nach myvector<const char[13]> zu suchen.

    Äh. Huch? Hat sie aber. Verstehe jetzt nicht was du damit meinst. Lies im Standard nach, da stehen die genauen Regeln was das alles betrifft.

    0
  • W

    Na ja, gut. Ich belasse es jetzt mal bei einer Umbenennung in AddVectors().

    0
Anmelden zum Antworten