Speicherleak?
-
Hmm das meinte ich :D. Hab das irgendwie impliziert.
-
Für global: Design ändern, globale Variablen sind in viele Fällen Pfui.
Für konstant: Dann halt std::vector<std::string const>
-
pumuckl schrieb:
std::vector<std::string const>
Standard 23.1.3 schrieb:
The type of objects stored in these components must meet the requirements of CopyConstructible types (lib.copyconstructible), and the additional requirements of Assignable types.
-
Wenn
char* fs[] = {"shader1.frag", "shader2.frag"};die Variablen global anlegt, dann ist das vielleicht kein direktes Speicherleak aber irgendwie ja trotzdem nicht das, was man gerne hätte, wenn das dann bis zum Beenden des Programms irgendwo rumschwirrt.
Aber das müsste doch eigentlich nur lokal gültig sein, wenn es innerhalb einer Funktion angelegt wurde, oder?
Ich persönlich würde auch vector und string benutzen aber dann würde aus obigem schön kurzen Code folgendes:
std::vector<std::string> fs; fs.push_back(string("shader1.frag"); fs.push_back(string("shader2.frag");Was den Code irgendwie unschön aufbläht.
-
Hallo,
Jiddoo schrieb:
Wenn
char* fs[] = {"shader1.frag", "shader2.frag"};die Variablen global anlegt, dann ist das vielleicht kein direktes Speicherleak aber irgendwie ja trotzdem nicht das, was man gerne hätte, wenn das dann bis zum Beenden des Programms irgendwo rumschwirrt.
Aber das müsste doch eigentlich nur lokal gültig sein, wenn es innerhalb einer Funktion angelegt wurde, oder?
Entscheidend ist, was hier lokal definiert wurde: Ein Zeiger-Array, also wird das Array mit den Zeigern wieder abgeräumt, aber die Zeichenketten verbleiben noch in einem schreibgeschützten Speichersegment, wie jedes Zeichenkettenliteral.
MfG,
Probe-Nutzer
-
KasF schrieb:
pumuckl schrieb:
std::vector<std::string const>
Standard 23.1.3 schrieb:
The type of objects stored in these components must meet the requirements of CopyConstructible types (lib.copyconstructible), and the additional requirements of Assignable types.
Jup, natürlich. Allerdings kann man den darauf folgenden Abschnitten und den Beschreibungen der vector-Methoden auch entnehmen, dass kein op= aufgerufen wird, wenn außer Ctor und const-methoden nur push/pop_back benutzt werden. Ist eine Frage der Implementation (Compiler bzw. STL), ob solch eine "bedingt standardkonforme" Verwendung toleriert wird. Mir ist noch kein Compiler über den Weg gelaufen der nicht kulant genug wäre...
-
Was den Code irgendwie unschön aufbläht.
Imo ist das kein Grund das nicht so zu machen. Klar ist es ein wenig mehr Schreibarbeit, aber wenn du es so machst, dann hast du da viel mehr Klarheit, was du vor hast und was du damit gedenkst zu tun. Zum anderen kannst du da sehr viel einfacher dynamisch laden, was bei einem realistischem Programm eher der Fall sein wird, als das du das im hardcodest. Das ist mit Array's nämlich gar nicht möglich, ohne ein vector/list-ähnliches Gebilde nachzuprogrammieren.
Im übrigen brauchst du den Konstruktor von string nicht explizit aufzurufen. std::string hat einen nicht expliziten Konstuktor für const char* .
-
aber die Zeichenketten verbleiben noch in einem schreibgeschützten Speichersegment, wie jedes Zeichenkettenliteral.
Der Standard macht keine Aussage darüber wo string literals leben und ob dieser Bereich schreibgeschützt ist oder nicht.
-
Hallo,
hustbaer schrieb:
aber die Zeichenketten verbleiben noch in einem schreibgeschützten Speichersegment, wie jedes Zeichenkettenliteral.
Der Standard macht keine Aussage darüber wo string literals leben und ob dieser Bereich schreibgeschützt ist oder nicht.
Das ist klar, aber in der Praxis wird man diesen Fall oft genug finden.
MfG,
Probe-Nutzer
-
hustbaer schrieb:
aber die Zeichenketten verbleiben noch in einem schreibgeschützten Speichersegment, wie jedes Zeichenkettenliteral.
Der Standard macht keine Aussage darüber wo string literals leben und ob dieser Bereich schreibgeschützt ist oder nicht.
Jo, und die Aussage impliziert dann auch das gute undefinierte Verhalten, wenn man auf einem Literal rumschreibt. Deshalb sollte man es besser sein lassen.
-
pumuckl schrieb:
Jup, natürlich. Allerdings kann man den darauf folgenden Abschnitten und den Beschreibungen der vector-Methoden auch entnehmen, dass kein op= aufgerufen wird, wenn außer Ctor und const-methoden nur push/pop_back benutzt werden. Ist eine Frage der Implementation (Compiler bzw. STL), ob solch eine "bedingt standardkonforme" Verwendung toleriert wird. Mir ist noch kein Compiler über den Weg gelaufen der nicht kulant genug wäre...
Der Compiler(g++) steigt bei mir auch schon viel vorher, beim Allocator aus:
pointer address(reference __x) const { return &__x; } const_pointer address(const_reference __x) const { return &__x; }Da durch ein const T im Container, die zweite Funktion versucht die Erste zu redefinieren. Beim Comeau genauso.
Welcher Compiler, bzw welche Implementation lässt es denn zu ?
-
Hallo,
KasF schrieb:
Welcher Compiler, bzw welche Implementation lässt es denn zu ?
VS2005, SP1 hat nichts daran auszusetzen.
MfG,
Probe-Nutzer
-
Probe-Nutzer schrieb:
VS2005, SP1 hat nichts daran auszusetzen.
VS08 genauso, lässt sogar folgendes durchgehen:
vector<const int> a(2); a[0] = 6;
-
