Referenz Wert verschwindet



  • DuffCola schrieb:

    Aber was macht man, wenn man mit Großen objekten Arbeitet?
    Wenn ich jetzt als ID zum Beispiel String habe, dann müsste der ja in der Funktion toTexture einen kompletten String zurückgeben...

    Gib alles by value zurück. Der Compiler kann das optimieren. copy elision, named return value optimization, etc. Vertrau einfach darauf. Und wenn du in einem konkreten Fall nicht sicher bist, frag im Forum nach.



  • DuffCola schrieb:

    Aber was macht man, wenn man mit Großen objekten Arbeitet?
    Wenn ich jetzt als ID zum Beispiel String habe, dann müsste der ja in der Funktion toTexture einen kompletten String zurückgeben...

    Ja, dann muss die Funktion halt einen kompletten String zurückgeben.
    Aber der Compiler kann da schon massig optimieren, mach dir da mal keine Sorge.



  • Also ich habs gerade nochmal getestet, wenn ich eine Kopie in der to Texture Funktion zurückgebe geht alles wunderbar.
    Gibt es wirklich keine andere Lösung ?

    Könnte ich vielleicht statt extra eine Funktion toTexture zu machen die Switch anweisung direkt im Konstruktor machen?



  • DuffCola schrieb:

    Also ich habs gerade nochmal getestet, wenn ich eine Kopie in der to Texture Funktion zurückgebe geht alles wunderbar.
    Gibt es wirklich keine andere Lösung ?

    Was ist denn das Problem!?

    Könnte ich vielleicht statt extra eine Funktion toTexture zu machen die Switch anweisung direkt im Konstruktor machen?

    Du willst doch den Konstruktor von mSprite in der Initialisierungsliste aufrufen, nein, dann musst du das offensichtlich auslagern.



  • Was ist denn das Problem!?

    Dass, wenn ich ein Großen Typ als id benutze, die toTexture funktion einmal ein großes Objekt kopieren muss.
    Kla ist es jetzt in diesem Fall egal, trotzdem würde ich gerne ein Lösung, die ohne Kopieren funktioniert.



  • DuffCola schrieb:

    Was ist denn das Problem!?

    Dass, wenn ich ein Großen Typ als id benutze, die toTexture funktion einmal ein großes Objekt kopieren muss.

    Und weiter? Wie wäre es, sich darüber Gedanken zu machen wenn es soweit ist?

    Kla ist es jetzt in diesem Fall egal, trotzdem würde ich gerne ein Lösung, die ohne Kopieren funktioniert.

    Wieso? Der Compiler kann viel optimieren. Darüber musst du dir keine Gedanken machen.



  • Sone schrieb:

    DuffCola schrieb:

    Also ich habs gerade nochmal getestet, wenn ich eine Kopie in der to Texture Funktion zurückgebe geht alles wunderbar.
    Gibt es wirklich keine andere Lösung ?

    Was ist denn das Problem!?

    Eben.
    Selbst wenn der Compiler die Optimierung nicht macht, ints (nichts anders sind enums) zu kopieren, macht der Computer im Schlaf, das geht so schnell.

    Aber beschäftige dich nicht so sehr mit Geschwindigkeit:

    Es ist viel einfacher ein korrektes Programm schnell zu machen, als ein schnelles Programm korrekt.

    We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil

    Denk einfach nicht drüber nach, optimiere erst wenn du einen Grund hast und dann dort, wo es wirklich nötig ist (Profiler!)
    Und erst recht nicht in der Rückgabe von ints!
    Wenn du optimieren musst, dann ersetz deine Map in ResourceHolder durch einen Hashtable oder einen sortierten Vektor, das bringt viel mehr.

    PS: Jetzt sag nicht, du verwendest aus diesem Grund auch keine Smart Pointer. 🙄



  • DuffCola schrieb:

    Was ist denn das Problem!?

    Dass, wenn ich ein Großen Typ als id benutze, die toTexture funktion einmal ein großes Objekt kopieren muss.

    Wenn du unsere Posts gelesen hättest, wüsstest du, dass das nicht stimmt.



  • Nathan schrieb:

    Aber beschäftige dich nicht so sehr mit Geschwindigkeit:

    Dieser Komentar ist völlig unangemessen. Bitte nicht die Leute zur premature pessimization ermutigen.



  • ongsthrtr schrieb:

    Nathan schrieb:

    Aber beschäftige dich nicht so sehr mit Geschwindigkeit:

    Dieser Komentar ist völlig unangemessen. Bitte nicht die Leute zur premature pessimization ermutigen.

    preamature pessimization ist was anderes als nicht vorzeitig zu Optimieren, aber das sollte man wissen.
    Mein Kommentar ruft lediglich dazu auf, sich nicht bei jedem Codefetzen über Optimierungen nachzudenken.
    Dinge wie ++i anstatt i++ o.ä macht man ohne nachzudenken und sind deswegen ausgeschlossen.



  • ongsthrtr schrieb:

    Nathan schrieb:

    Aber beschäftige dich nicht so sehr mit Geschwindigkeit:

    Dieser Komentar ist völlig unangemessen. Bitte nicht die Leute zur premature pessimization ermutigen.

    Das tut er nicht. Er sagt, der TE soll sich nicht so sehr mit Geschwindigkeit befassen - bspw. dass er sich nicht traut einen Enumerator per Kopie zurückzugeben.


Anmelden zum Antworten