3. Frage zu auto_ptr und map der STL

Frage zu auto_ptr und map der STL

  • L

    Simon2 schrieb:

    Mein Schwerpunkt bei der Aussage war: Er wollte gerne (außerhalb der map) mit Heapobjekten hantieren (jedenfalls habe ich ihn so verstanden) ...

    Wenn ich mich da jetzt mal drauf versteifen darf, dass mit "hantieren" nicht zwangsläufig new/delete gemeint ist: Geht doch auch so, solang das Objekt in der Map noch existiert

    map<int, string> names;
names[10] = "Sascha";
string* p = &names[10]; // <- Zeiger auf Objekt auf Heap, vorausgesetzt die Map nutzt den Heap, was wie bereits festgestellt ist der wahrscheinlichste Fall sein dürfte.

    @Simon2:
    Aber nimm mich bitte nicht zu ernst 🤡

    @Illarion:
    Den äußerst unwahrscheinlichen Fall, dass die Map so wie von Simon skizziert angelegt ist, mal aussen vor gelassen, ist das so richtig 😉

    0
  • I

    Simon2 schrieb:

    Mein Schwerpunkt bei der Aussage war: Er wollte gerne (außerhalb der map) mit Heapobjekten hantieren (jedenfalls habe ich ihn so verstanden) ...

    Vielleicht habe ich mich doch nicht deutlich genug ausgedrückt.

    Die Objekte müssen nur "in der map liegen", also von außerhalb der map soll erst gar nicht auf diese Objekte zugegriffen werden. Jedoch ist es wichtig, dass die Objekte sich im Heap befinden.

    *Uff* anstrengend - alles Neuland für mich, meine Kentnisse beruhen auf c++ - Tutorials wie Schornboeck und Volkards C++ Kurs.

    Ich hoffe ich habs nun soweit alles verstanden^^

    0
  • A

    Jedoch ist es wichtig, dass die Objekte sich im Heap befinden.

    Warum?

    0
  • I

    Artchi schrieb:

    Jedoch ist es wichtig, dass die Objekte sich im Heap befinden.

    Warum?

    Weil ich verstehen möchte wie es funktioniert 🙂

    In meinem Beispiel ist es tatsächlich irrelevant, was allerdings, wenn besagte Objekte riesig sind (vllcht durch lange Strings, viele Membervariable (Unterobjekte etc.)) ? (schwer riesig genauer zu definieren, z.B. 50 kByte pro Objekt)
    Und wenn es dann noch entsprechend viele Objekte sind (10000+) ?

    Dann hab ich den Stack doch schnell voll und es lohnt auf den Heap auszuweichen.

    0
  • A

    Genau das meinte ich mit "Vielleicht denkt er nur, die Objekte sind groß.".

    Also, ein std::string selbst ist auf dem Stack nur klein, da er intern die Zeichenkette selbst auf dem Heap anlegt. Wenn du so willst, ist es auch ein Smart-Pointer für Zeichenketten. 💡

    Mach mal folgendes:

    #include <string>
#include <map>

int main()
{
	std::map<int, std::string> mymap;

	for(int i=0; i<1000000; i++)
	{
             std::string str("Hallo hjdshdjshduszuwe, ende!");
             mymap[i] = str;
	}
}

    Und dann mal ausführen. Du wirst dich wundern.

    Kannst auch Testhalber danach alles ausgeben, könnte aber bei 1 Mio. Strings lange dauern (ist langsam halt die Konsole). 😉

    0
  • I

    Stimmt, dass die Klasse string den String im Heap speichert hatte ich gelesen.
    Aber mir gehts wirklich nur um das Verstehen, das Gewußt-Wie. Alles theoretisch also. Später kann es ja trotzdem vorkommen, dass ein Objekt riesig wird und eben nicht alle Member von sich aus im Heap liegen wie die Klasse string. Also ist es eben nur eine theoretische Annahme: die Objekte der Klasse MeineKlasse sind riesig und gehören auf den Heap ⚠

    Wenn die Containerklassen der STL sowieso Ihre "Second-Werte" (dummer Begriff, i know) im Heap speichern und die Verwaltung übernehmen, dann ist die Sache damit eh erledigt 😉

    Ich brauche keine Zeiger, kein new/delete und die Objekte liegen - dank map - auf dem Heap 😃

    0
  • A

    Achja, bei 1 Mio. Strings braucht man natürlich genug RAM. Kann sein das es nicht klappt. Aber definitiv hat das nichts mit dem Stack zu tun. Habs hier auf einem 2 GB RAM PC mit MinGW getestet. Geht wunderbar.

    0
  • I

    Artchi schrieb:

    Achja, bei 1 Mio. Strings braucht man natürlich genug RAM. Kann sein das es nicht klappt. Aber definitiv hat das nichts mit dem Stack zu tun. Habs hier auf einem 2 GB RAM PC mit MinGW getestet. Geht wunderbar.

    Braucht gerade mal rund 30 000 000 Bytes an Speicher für die Strings auf dem Heap 😉

    0
  • S

    LordJaxom schrieb:

    ...
    @Simon2:
    Aber nimm mich bitte nicht zu ernst 🤡 ...

    Doch - z.B. fachlich nehme ich Dich absolut ernst (ich wäre schön blöd, wenn ich nix mehr lernen wollte, weil es von Dir kommt) !

    Aber ich weiß, dass Du mich mit Deinem Post nicht wirklich ärgern wolltest. 😃
    ... und Recht hast Du natürlich auch.

    Gruß,

    Simon2.

    0
  • S

    Artchi schrieb:

    Jedoch ist es wichtig, dass die Objekte sich im Heap befinden.

    Warum?

    Ich stelle immer mehr fest, dass diese Information tatsächlich ziemlich unwichtig ist. Am Anfang denkt man das vielleicht noch, aber später ist es eigentlich mehr ein kleiners Detail in der Frage der Lebenszeit und Eigenschaftsverhältnisse meiner Objekte ist ....

    Gruß,

    Simon2.

    0
  • C

    Illarion schrieb:

    In meinem Beispiel ist es tatsächlich irrelevant, was allerdings, wenn besagte Objekte riesig sind (vllcht durch lange Strings, viele Membervariable (Unterobjekte etc.)) ? (schwer riesig genauer zu definieren, z.B. 50 kByte pro Objekt)
    Und wenn es dann noch entsprechend viele Objekte sind (10000+) ?

    Also wenn du wirklich so große Objekte zusammengebaut hast, daß sie nicht mehr auf den Stack passen (ich erinnere mich dunkel an einen Wert von 64kB maximale Netto-Größe (sizeof), aber nagel mich jetzt bitte nicht darauf fest) und davon noch einen ganzen Haufen benötigst, dann stimmt etwas mit deinem Design nicht.

    0
Anmelden zum Antworten