Lokalen char* Zurückgeben
-
wolfcastle schrieb:
Umwandlung in std::strings kannste da vergessen, da der beim Umwandeln teilweise mist baut.
Und wie wärs mit std::vector<char> als Rückgabe?
-
[quote="joomoo"]
char *t = new char[123]; // 123 ist die Länge // Hier kannste was machen return t; // Achtung! Das ganze mit delete [] char; wieder löschen
Genaueres zu den operatoren new[] und delete[] findest du in vielen Tutorials.
Kurze Frage wieso
delete []char ?????
ich benutze dann immer
delete t;
oder war das damit gemeint?
das hat mich jetzt total aus der Bahn geworfen, bitte um Hilfe
-
hotblack schrieb:
joomoo schrieb:
char *t = new char[123]; // 123 ist die Länge // Hier kannste was machen return t; // Achtung! Das ganze mit delete [] char; wieder löschen
Genaueres zu den operatoren new[] und delete[] findest du in vielen Tutorials.
Kurze Frage wieso
delete []char ?????
ich benutze dann immer
delete t;
Ich hoffe du benutzt delete [] t, nicht nur delete t! Denn wenn man ein Array anlegt, muss man auch ein Array freigeben!
new[] T -> delete[] T
new T -> delete TMfG
GPC
-
Danke das du mir das sagst, ich habe das von meinen Lehrer so beigebracht bekommen.
Werde das gleich mal debuggen und wirklich in den Speicher gucken was da genau gelöscht wird.
-
Habe mir das gerade im Debugger angeschaut. Also ich habe mir ein Integer Arry mit 12 Elementen angelegt und es war egal ob ich
int * p = new int[12]; for(int i=0;i<12;i++) p[i]=i; delete [] p; oder (delete p;)
gemacht habe.
Also ich kann da keinen Unterschied im Speicher erkennen.
Vielleicht ist es nur ein dummer Zufall das es gerade funktioniert hat, aber im Moment sieht es so aus. Ich lasse mich gerne eines besseren belehren wenn meine Testmethode falsch war. (Ich habe mir im VS2005 das Memory fenster anzeigen lassen, auf p)
mfg Fabian
-
hotblack schrieb:
Habe mir das gerade im Debugger angeschaut. Also ich habe mir ein Integer Arry mit 12 Elementen angelegt und es war egal ob ich
int * p = new int[12]; for(int i=0;i<12;i++) p[i]=i; delete [] p; oder (delete p;)
gemacht habe.
Also ich kann da keinen Unterschied im Speicher erkennen.
Vielleicht ist es nur ein dummer Zufall das es gerade funktioniert hat, aber im Moment sieht es so aus. Ich lasse mich gerne eines besseren belehren wenn meine Testmethode falsch war. (Ich habe mir im VS2005 das Memory fenster anzeigen lassen, auf p)
Ich versichere dir, dass es nicht egal ist. Glaub mir, egal was der VS grad anzeigt. Es gibt diese Operatoren nicht umsonst.
MfG
GPC
-
Das ist Glück (und spätestens wenn du Arrays von Objekten anlegst und freigibst, wirst du den Unterschied bemerken)
-
Okay Leute, ich will euch ja prinzipiell glauben, die Begründung ist ja schließlich auch schlüssig. Allerdings kann ich den fehler nciht nachvollziehen. Sprich auch bei einem array aus komplexen Objekten hat er es mir richtig gelöscht.
Ich werde weiter probieren, und in Zukunft aber auch delete [] p;
schaden tuts ja definitv nichtmfg Fabian
-
hotblack schrieb:
Okay Leute, ich will euch ja prinzipiell glauben, die Begründung ist ja schließlich auch schlüssig. Allerdings kann ich den fehler nciht nachvollziehen. Sprich auch bei einem array aus komplexen Objekten hat er es mir richtig gelöscht.
hat er auch alle destruktoren in der richtigen reihenfolge ausgeführt?
-
Och, das kann ich dir leicht beweisen:
#include <iostream> using namespace std; struct Foo { Foo() { ++counter; } ~Foo() { --counter; } static int counter; }; int Foo::counter = 0; int main(int argc, char **argv) { Foo *f = new Foo[100]; cout<<"Vorher: "<<Foo::counter<<'\n'; delete [] f; cout<<"Nachher: "<<Foo::counter<<'\n'; return 0; }
Bei diesem Beispiel wird jedesmal, wenn ein Foo Objekt angelegt wird, counter eins hochgezählt. Wird eins zerstört, geht's eins runter. Hier werden alle 100 wieder gelöscht.
Ersetzt du das delete [] f; durch delete f; , dann ist counter bei 99. Überzeugt?MfG
GPC
-
jaja die Klasse funzt schon. habe gerade noch mal bei Bjarne Stroustrupp nachgelesen, der sagt auch delte[] ist zu verwenden. Aber ich habe das gerade mit einer etwas größeren klasse gemacht, ändert nichts dran???
kann das sein das der Compiler von VS2005 so schlau ist?
Um ehrlcih zu sein weiß ich gar nicht ob das nicht acuh ein alter Compiler ist in einer neuen IDE
-
Knock out
okay. ich gebe mich geschlagen
der schmiert bei mir sogar ab bei delete f
schön das wir das klären konnten
-
kann das sein das der Compiler von VS2005 so schlau ist?
Ne, Computer sind generell das dümmste was es gibt^^
Um ehrlcih zu sein weiß ich gar nicht ob das nicht acuh ein alter Compiler ist in einer neuen IDE
keine Panik, dem VS 05 liegt der aktuellste MS - Compiler bei.
MfG
GPC
-
der unterschied zwischen delete und delete[] ist nun mal "nur" das weiterleiten destruktuierens ...
Sprich bei Arrays von PODS (plain old data) wirst du keinen unterschied merken, selbst bei Klassen ohne kritische Funktion im deskruktor isses dann egal.
Kanst du deiner klasse ohne Desktruktur Aufruf einfach den speicher wegziehen und nix passiert, dann passiert auch bei nem falschen delete statt delete[] nix.
bei PODs macht der compiler allein schon nen performanteres delete drauss ...Ciao ...
-
Falsch - der Unterschied zwischen delete und delete[] ist etwas größer - die Compiler können beide Operationen völlig unabhängig voneinander umsetzen (z.B. kann es sein, daß delete tatsächlich nur ein Element an den Heap-Manager zurückgibt und der Rest der von new[] angelegten Arrays reserviert bleibt). D.h. ob die Zusammenarbeit von new[] und delete (oder new und delete[]) klappt, hängt auch von der Umsetzung des Compilers ab.