ich hätte mal eine Frage bezüglich des C/C++ Standards.

Wenn ich mir mittels folgendem Code ein Array an chars anlege, welche ich brauche um die entsprechenden Dateien zu laden:

char* fs[] = {"shader1.frag", "shader2.frag"};

Muss ich für fs noch ein delete aufrufen? Oder ist das eine lokale Variable?

Ich hab über das Program mal valgrind laufen lassen, welches mir keinerlei Speicherleaks gemeldet hat.
Aber rein von der Intuition her müsste doch eines entstehen, oder?

Felix

[...] Aber rein von der Intuition her müsste doch eines entstehen, oder?

Wieso denn das?

fs ist ein Array aus char * . Die Elemente des Arrays zeigen auf Zeichenkettenliterale.

cheers, Swordfish

Muss ich für fs noch ein delete aufrufen? Oder ist das eine lokale Variable?

Ich hab über das Program mal valgrind laufen lassen, welches mir keinerlei Speicherleaks gemeldet hat.
Aber rein von der Intuition her müsste doch eines entstehen, oder?

Grundsätzlich:
Für jedes new/new[] ein delete/delete[]. Du allozierst nichts mit new/new[] also ist auch kein deallozieren nötig.

Persönlich würde ich dennoch eher std::string als char* verwenden...

Persönlich würde ich dennoch eher std::string als char* verwenden...

Und wenn wir schon dabei sind, gerade std::vector statt Arrays. Wobei ich bei Konstanten und Literalen manchmal auch eher zu const char* und C-Arrays greife...

Da die char's wohl global sind wuerde ich hier nicht auf std::string zurueckgreifen.

Was hat das mit global zu tun? Eigentlich sollte man dann erst recht std::string verwenden, weil globale Objekte noch von viel mehr Orten beeinträchtigt werden können...

Oder meinst du konstant? Also als Literale?

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.

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.

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

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.

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

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.

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 ?

KasF schrieb:

Welcher Compiler, bzw welche Implementation lässt es denn zu ?

VS2005, SP1 hat nichts daran auszusetzen.

MfG,

Probe-Nutzer

VS2005, SP1 hat nichts daran auszusetzen.

VS08 genauso, lässt sogar folgendes durchgehen:

vector<const int> a(2);
a[0] = 6;