Typ von Container-Element bestimmen.



  • Zählt "auto" eigentlich auch als Lösung?

    {
      auto tmp=v;
      tmp.swap(v);
    }
    


  • ernst34 schrieb:

    @PI
    Dass deine Lösung ein Satz mit x war, ist dir vermutlich selber klar 🙂

    Den hab ich jetzt nicht verstanden. Bitte nochmal für ganz doofe.



  • Ja zählt natürlich auch. Warum kompliziert, wenns auch einfach geht? 😃
    Argh - manchmal denkt man einfach viel zu kompliziert wenn man auf das Offensichtlichste nicht gleich zuerst kommt.

    Bleibt aber noch die Frage bezüglich der Bedenken zur Standardkonformität von hustbaers Lösungen 1 und 2, und warum Lösung 1 im Gegensatz zur gleichen Lösung ohne typedef funktioniert.
    (Lsg. 2 zählt eigentlich auch nicht wirklich, da ja wieder eine zusätzliche Templ.fkt. verwendet wird, aber das mag für die Frage egal sein).



  • @pi:

    Satz mit x: War wohl nix.

    Deine Lösung mit dem reinterpret-gecaste und copy etc. ist höflich gesagt für die Katz 😃

    Ausserdem garantiert mir das resize nicht, dass mein vector entsprechend getrimmt wird. Falls es so wäre, warum nicht einfach v.resize(v.size())?



  • ernst34 schrieb:

    Deine Lösung mit dem reinterpret-gecaste und copy etc. ist höflich gesagt für die Katz 😃

    Nein. Ich wollte bewusst keine Features wie auto und decltype verwenden. Dass das nur mit PODs funktioniert, ist ein unschöner Nebeneffekt. Dein Beispiel ist ja auch total schwachsinnig und realitätsfremd, also dürfen die Lösungen das ja wohl auch sein. So gesehen ist meine Lösung die korrekteste von allen.

    ernst34 schrieb:

    Ausserdem garantiert mir das resize nicht, dass mein vector entsprechend getrimmt wird. Falls es so wäre, warum nicht einfach v.resize(v.size())?

    Du hast meine letzte Lösung nicht gesehen, oder? Lies nochmal nach. Von wäre hab ich nichts. Siehe .clear().



  • 314159265358979 schrieb:

    ernst34 schrieb:

    Ausserdem garantiert mir das resize nicht, dass mein vector entsprechend getrimmt wird. Falls es so wäre, warum nicht einfach v.resize(v.size())?

    Du hast meine letzte Lösung nicht gesehen, oder? Lies nochmal nach. Von wäre hab ich nichts. Siehe .clear().

    Auch clear() gibt die Kapazität des vector<> nicht frei - das ist ein gieriger Geselle, der nichts gerne herausrückt, was er einmal in den Händen hält.

    Und bei der Lösung mittels reinterpret_cast<> kannst du dich auch ziemlich in die Nesseln setzen (sogar bei PODs), indem du dem Vektor seine Datengröße-Verwaltung kaputtschießt.

    PS Randfrage @ernst: Hat es einen tieferen Sinn, warum du das Problem unbedingt ohne Hilfsfunktionen lösen willst?



  • ernst34 schrieb:

    Ja zählt natürlich auch. Warum kompliziert, wenns auch einfach geht? 😃
    Argh - manchmal denkt man einfach viel zu kompliziert wenn man auf das Offensichtlichste nicht gleich zuerst kommt.

    Genau.
    auto ist gut 🙂

    Bleibt aber noch die Frage bezüglich der Bedenken zur Standardkonformität von hustbaers Lösungen 1 und 2, und warum Lösung 1 im Gegensatz zur gleichen Lösung ohne typedef funktioniert.
    (Lsg. 2 zählt eigentlich auch nicht wirklich, da ja wieder eine zusätzliche Templ.fkt. verwendet wird, aber das mag für die Frage egal sein).

    Meine Bedenken kommen daher, dass ich die genaue Syntax von declspec() nicht kenne - hab mir einfach noch nicht angesehen wo/wie man das verwenden kann/muss.
    Ich könnte mir auch gut vorstellen, dass GCC diesbezüglich noch nicht ganz Standardkonform ist, und auch die einfacheren Varianten vom Standard aus OK sind.



  • CStoll schrieb:

    Auch clear() gibt die Kapazität des vector<> nicht frei - das ist ein gieriger Geselle, der nichts gerne herausrückt, was er einmal in den Händen hält.

    Ich weiß - deshalb ja: Von wäre hab ich nichts.

    CStoll schrieb:

    Und bei der Lösung mittels reinterpret_cast<> kannst du dich auch ziemlich in die Nesseln setzen (sogar bei PODs), indem du dem Vektor seine Datengröße-Verwaltung kaputtschießt.

    Daran hab ich auch schon gedacht. Ist aber jetzt auch schon egal.



  • @PI
    Was ist, wenn der Vektor leer ist (Aufruf von &v.front() und &v.back())
    Was ist, wenn operator& überladen wurde?

    @CStoll
    Nein, es gibt keinen tieferen Sinn, und ich würde vermutlich der Einfachheit halber in der Praxis auch eine Hilfsfunktion nutzen. Es geht mir eher um die Möglichkeiten, die C++ bietet.
    Beispielsweise durch das von hustbaer gezeigte typedef, mit dem sich problemlos ein temporärer vector erstellen lässt, aber durch ein reines decltype(v), also ohne typedef nicht.

    Solches wissen ist vlt. grundsätzlich für das gezeigte Problem unnötig, aber kann ggf. bei anderen Problemen zu anderer Zeit hilfreich sein.



  • ernst34 schrieb:

    Was ist, wenn der Vektor leer ist (Aufruf von &v.front() und &v.back())

    Dann prüfe ich vorher darauf. Meine Fresse.

    ernst34 schrieb:

    Was ist, wenn operator& überladen wurde?

    Dann darf der Typ nicht in einen std::vector rein. Alternativ nehm ich einfach addressof.



  • 314159265358979 schrieb:

    CStoll schrieb:

    Auch clear() gibt die Kapazität des vector<> nicht frei - das ist ein gieriger Geselle, der nichts gerne herausrückt, was er einmal in den Händen hält.

    Ich weiß - deshalb ja: Von wäre hab ich nichts.

    Dein Code ist deshalb falsch. Er loest die Aufgabenstellung nicht, da du den Vector nie shrinkst. Sein capacity() bleibt immer gleich...

    Der Code ist also einfach nur dumm und loest keine Probleme.



  • Shade Of Mine schrieb:

    314159265358979 schrieb:

    CStoll schrieb:

    Auch clear() gibt die Kapazität des vector<> nicht frei - das ist ein gieriger Geselle, der nichts gerne herausrückt, was er einmal in den Händen hält.

    Ich weiß - deshalb ja: Von wäre hab ich nichts.

    Dein Code ist deshalb falsch. Er loest die Aufgabenstellung nicht, da du den Vector nie shrinkst. Sein capacity() bleibt immer gleich...

    Zum x-ten Mal: ICH WEISS DAS. -.-



  • Wir können glaube ich das 314-Bashing auf die Threads/Vorfälle beschränken, wo er Mist gebaut hat, ohne es zuzugeben 😉


Anmelden zum Antworten