Typ von Container-Element bestimmen.

314159265358979

Stimmt. Ich bin wohl schon etwas müde

Wie schon mehrfach erwähnt ist mir bewusst und klar, wie ich dies durch eine zusätzliches Funktions-Template bewerkstellige.

Aber ich schrieb ja:

...allerdings interessiert mich eben, ob es ausser durch eine weitere Templ.fkt. möglich ist für gegebene Containerobjekte...

Also nichts mit V::value_type

hustbaer

Also schön wird's fürchte ich nicht, und ich bin auch nicht sicher ob's wirklich standardkonform ist:

#include <vector>
#include <utility>

int main()
{
    std::vector<int> v;

    // 1
    typedef decltype(v) VT;
    VT(v).swap(v);

    // 2
    typename std::identity<decltype(v)>::type(v).swap(v);

    // 3 (sinnlos, da noch viel umständlicher als (2))
    std::vector<typename std::identity<decltype(v)>::type::value_type>(v).swap(v);
}

314159265358979

Ich steig hier gerade total aus. Wo liegt das Problem? Was habt ihr vor? Ich kapier den Aufwand nicht.

hustbaer

@314159265358979

Auftrag:

#include <vector>
// weitere includes die du brauchst

int main()
{
    std::vector<int> v;

    // Schreibe hier code hin, der ein neues Objekt vom Typ von "v" erzeugt,
    // mit dem Inhalt von "v" initialisiert, und ruft dann "neuesObjekt.swap(v)" auf.
    // Und zwar ohne Hilfsfunktionen bzw. Templates, und ohne dass der Typ des Vektors (hier int) eine Rolle spielt.
}

314159265358979

#include <vector>
#include <algorithm>

int main()
{
    std::vector<int> v;

    int size = sizeof(v.front());

    std::vector<char> v2(reinterpret_cast<char*>(&v.front()), reinterpret_cast<char*>(&v.back()) + size);
    v.clear();
    v.resize(v2.size() / size);

    std::copy(v2.begin(), v2.end(), reinterpret_cast<char*>(&v.front()));
}

Aus dem Kopf heraus, ungetestet :p

Edit: Ganz vergessen, dass clear() ja keinen Speicher frei gibt. Dann weiß ich's auch nicht, ohne decltype zu verwenden. (Edit2: Bzw ohne mich auf Internas der Implementierung zu verlassen.)

Edit #3:
Hier nochmal eine Möglichkeit. Standardkonform ist's nicht, aber sollte eigentlich bei allen Implementierungen zumindest im Release-Mode hinhauen.

#include <vector>

int main()
{
    std::vector<int> v;

    assert(sizeof(v) == sizeof(std::vector<char>));
    std::vector<char>(reinterpret_cast<char*>(&v.front()), reinterpret_cast<char*>(&v.back()) + sizeof(v.front()).swap(reinterpret_cast<std::vector<char>&>(v));
}

hustbaer

@314159265358979:
OMFG. Das ist einer der dümmsten Scherze die du seit langem gemacht hast.

Und "es sollte" auch nicht "eigentlich hinhauen".

314159265358979

hustbaer schrieb:

@314159265358979:
OMFG.

Gerade als ich auf "Zitieren" klicken wollte, hast du editiert. Ich dachte, wir hätten einen std::vector<int>, nur dürfen wir nirgens int hinschreiben. Das ist natürlich was anderes.

hustbaer

hustbaer schrieb:

// Und zwar ohne Hilfsfunktionen bzw. Templates, und ohne dass der Typ des Vektors (hier int) eine Rolle spielt.

Ich hatte angenommen dass das klar genug ist. War es anscheinend nicht. Aber gut, jetzt weisst du was gemeint ist

314159265358979

Beim zweiten mal lesen völlig klar. assert(PI.brain_state() != brain_state.TIRED); kabumm.

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

@hustbaer
Ich danke dir für die Lösungsvorschläge.
Auf Lösung 1 hätte ich natürlich auch schnell selber kommen können, allerdings ist mir völlig unklar warum

typedef decltype(v) VT;
VT(v).swap(v);

funktioniert,

der compiler bei

decltype(v)(v).swap(v)

rummeckert. Wird vermutlich damit zu tun haben, wie Ausdrücke geparst werden.

Lösung 3 hat keinen Vorteil gegenüber Lösung 2, und an std::identity hab ich überhaupt garnicht mehr gedacht. Danke für den Tip.

Inwiefern hast du bedenken, dass Lösung 2 nicht standardkonform ist?

Besten Dank nochmals für eure Vorschläge.

CStoll

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

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

314159265358979

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())?

314159265358979

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().

CStoll

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?

hustbaer

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.

314159265358979

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.