Hab ich hier eventuell etwas nicht berücksichtigt?
-
ness schrieb:
Btw: Das nennst sich smart pointer, kannst ja mal danach googlen.
Da wird zwar auch Speicher freigegeben, aber das hier ist immer noch ein Container und ein std::string/vector<char> Ersatz.
mfg
-
terraner schrieb:
Du musst einen Copyconstructor und einen operator= definieren.
oder deine Klasse von boost::noncopyable erben lassen
-
@Ynnus
ich würde dir auch raten, dich mit den stl-klassen vector und string zu befassen. das ist zwar erst mal ein gewisser lernaufwand, der zahlt sich aber in jedem fall aus!
-
Wenn du weiter so programmierst wird dein Programm aber nicht gut!
Ok, ich hab ja schon verstanden, dass ich das nur unnötig kompliziert mache und besser auf vorhandene C++ Klassen zurückgreifen. Aber mal ganz unabhängig vom Gefallen am Programmierstil, solange keine Fehler drinne sind, hat es doch keine Auswirkungen darauf, wie gut das Programm wird.
Vielleicht darauf, dass es ein bisschen mehr Rechenleistung benötigt oder weniger Schleifendurchläufe pro Sekunde hinlegt. Aber sonst hat doch der Stil des Programmes wenig Auswirkungen auf das Resultat.
Wo genau ist denn der Knackpunkt (außer, dass ich C unc C++ mische) der das Programm so schlecht macht? Irgendwelche groben Verstöße beim Speichermanagement? Und das Variablen mal public sind lässt sich manchmal leider (scheinbar?) nicht umgehen. Beispiel: Die WinAPI benötigt des öffteren einen Speicherbereich um dort Werte hinein zu schreiben. Wenn ich nun den Pointer im Private Bereich des Objekts habe, wie kann ich den dann übergeben? Dann wird mir das Programm wohl mit einem Schreibsfehler abschmieren weil jemand in den Private-Bereich eines Objekts schreiben wollte. Oder gibt es da mir unbekannte Möglichkeiten, doch in die Private Variablen zu schreiben von Außerhalb? Ist ja auch nicht Sinn von OOP, daher hab ich die Variable gleich public gesetzt.
-
was spricht gegen eine get-memberfunktion?
-
public var schrieb:
was spricht gegen eine get-memberfunktion?
Ist der Private-Breich eines Objekts nicht in so fern geschützt, dass man Veränderungen NUR innerhalb der Klasse und deren Methoden vornehmen kann? Selbst wenn ich dann den Pointer per return zurückgebe und an die WinAPI-Funktion übergebe, sobald die Funktion den Inhalt ändern will, stürzt das Programm ab. Oder liege ich da falsch?
-
Liegst falsch!
-
Ich bin ja froh, dass einige hier so humorvoll sind. Hast du keinen Nick oder wie?
Ich hab's jetzt umgestellt, der Pointer ist nun private und wird per get_pointer() zurückgegeben. Ich hatte wohl damals was unglücklich falsch gemacht wodurch ich nun irrtümlich dachte, der Speicherbereich sei besonders geschützt, sodass man da eben nur durch klasseneigene Methoden reinschreiben kann. Damals gabs eben, wie gesagt, einen Speicherfehler, damit hatte sich das dann für mich erledigt.
Aber ich habs jetzt umgeändert.
-
Würde nicht auto_ptr aus der STL (memory) das selbe machen?
-
gurru schrieb:
Würde nicht auto_ptr aus der STL (memory) das selbe machen?
hier is es etwas doof, da der pointer keinen op[] hat.(Ansonsten is es natürlich ok, wenn man mit dem vergleicht, was der threadstarter benutzt
)
-
otze schrieb:
gurru schrieb:
Würde nicht auto_ptr aus der STL (memory) das selbe machen?
hier is es etwas doof, da der pointer keinen op[] hat.(Ansonsten is es natürlich ok, wenn man mit dem vergleicht, was der threadstarter benutzt
)Es wäre aber einfacher, die Klasse dann von auto_ptr abzuleiten, und dann darin den Operator[] zu definieren.
-
otze schrieb:
Ansonsten is es natürlich ok, wenn man mit dem vergleicht, was der threadstarter benutzt
das ist noch doofer, hier std::auto_ptr zu benutzen, als was threadstarter vorgeschlagt hat
Werf mal enen Blick in std::auto_ptr::~auto_ptr. Da findest zu sowas:~auto_ptr() { delete _M_ptr; }
Das nennt sich Undefined behaviour, da hier operator delete [] benutzt werden muss. Also bitte boost::scoped_array anstatt std::auto_ptr benutzen!!!
-
gurru schrieb:
Es wäre aber einfacher, die Klasse dann von auto_ptr abzuleiten, und dann darin den Operator[] zu definieren.
-
Es wäre aber einfacher, die Klasse dann von auto_ptr abzuleiten, und dann darin den Operator[] zu definieren.
Ja ne is klar...
-
ssm schrieb:
das ist noch doofer, hier std::auto_ptr zu benutzen, als was threadstarter vorgeschlagt hat
Werf mal enen Blick in std::auto_ptr::~auto_ptr. Da findest zu sowas:~auto_ptr() { delete _M_ptr; }OK, das hab ich übersehen. (Also vergessen)