Guten Abend,
ich habe gestern mal wieder mein altes STK500 rausgekramt und bin am
basteln. Nun funktionert C++ ja mitlerweile auf dem AVR, allerdings ohne
"Funktionen" wie *new, bzw. sind nicht sehr sinnvoll, wie ich dem Forum
entnommen habe. Die Frage ist nun, wie schreibe ich so eine Funktion
anders. z.B. diese hier,.. war auch aus einem Forum Beitrag:
suchmal bei AVR-freaks im forum.. da findeste beispielcode wie du die
operatoren über malloc/free definierst...
trotzdem sollte man new nicht verwenden (gerade anfänger..)
lieber:
Erstmal danke Euch für die Antwort.
Also ich möchte es aufjedenfall ohne new machen, nur weiß ich nicht so
recht wie ich meinen Code umschreiben soll, wir haben damals alles mit
new programmiert.
Was ändert sich denn, wenn ich statt new, nur noch something a(); oder
something a; schreibe. Den Zeiger kann ich dann gar nicht mehr benutzen
oder?
something a(); geht nicht, Du deklarierst damit eine funktion a(void),
die ein something zurückgibt.
"something a;" ist der richtige Weg, ganz ohne Pointer. Oder schreibst
du auch jedesmal "int* i = new int;" ?
Dominik S: ganz übersehen, warum C++.Bins einfach gewohnt. Haben in der
Schule alles damit programmiert, ich finds angenehmer und soviel ich
weiß gibts in C auch keine Klassen,.. oder?
Werd das gleich mal probieren, das mit dem Pointer stimmt natürlich. Was
mir noch nicht klar ist, welchen Vorteil habe ich bei dem Ausdruck oben
mit dem *new? Bzw. welche Nachteile ergeben sich mit dieser "something
a;" "Methode"? Wir haben das damals wie gesagt immer mit new gemacht,
weshalb ich davon ausging, dass ich new auch unbedingt brauche.
gruss
Mit Referenzen geht das wunderbar, also auch ohne Zeiger. Ich mache das
oft so ähnlich wie im Anhang, const-correctness habe ich mal
weggelassen.
In Test2 kann man natürlich auch Pointer speichern und dem Konstruktor
die Adresse von z1 und z2 mit dem &-Operator übergeben.
Grüße
verhält sich das auf dem stk500 auch so, dass ein mit New erzeugtes
Objekt im heap liegt und ein einfach deklariertes bzw. definiertes
Objekt auf dem Stack?
Bösler schrieb:> Werd das gleich mal probieren, das mit dem Pointer stimmt natürlich. Was> mir noch nicht klar ist, welchen Vorteil habe ich bei dem Ausdruck oben> mit dem *new?
gar keinen. Zumindest nicht in diesem Fall.
> Bzw. welche Nachteile ergeben sich mit dieser "something> a;" "Methode"?
Das du etwas dynamisch allokierst ohne die Notwendigkeit dafür zu haben.
Dadurch musst du dich um die Lebensdauer deines Objektes selbst kümmern,
während du im anderen Fall durch den einschliessenden Block automatisch
vom Compiler ein Lebensdauermanagement bekommst.
> Wir haben das damals wie gesagt immer mit new gemacht,
Entweder dein Lehrer ist eine Flasche ersten Ranges, oder aber du hast
gar nicht C++ programmiert sondern Java.
Hm Flasche, k.a. und C++ wars aufjedenfall. Ich weiß auch nicht warum
wir das immer benutzt haben. Aber seitdem hab ich das drin. Und da ich
jetzt bisl aufm AVR programmiere (n will) muss das natürlich weg.
Danke nochmal für Eure Hilfe!
@Tom K.: Vielen Dank! Werde das sofort mal in die Tat umsetzen und
versuchen mein Programm dementsprechend umzuschreiben. Werd mich
aufjedenfall nochmal melden, auch wenn alles klappt, wobei ich jetzt
davon mal nicht ausgehe.
gruss
Karl Heinz Buchegger schrieb:> Entweder dein Lehrer ist eine Flasche ersten Ranges, oder aber du hast> gar nicht C++ programmiert sondern Java.
Respektive C#
Bösler schrieb:> wir haben damals alles mit> new programmiert.
habt ihr dann auch immer das passende delete hingeschrieben? Und wir
habt ihr das dann mit exception sauber hinbekommen?
Karl Heinz Buchegger schrieb:>> Wir haben das damals wie gesagt immer mit new gemacht,>> Entweder dein Lehrer ist eine Flasche ersten Ranges, oder aber du hast> gar nicht C++ programmiert sondern Java.
Die Frage ist: Wann war damals? Es gab BS, bei denen es nur 64k
Variblenspeicher pro Modul gab. Da macht es durchaus Sinn, große Objekte
auf dem Heap anzulegen.
Good Old Boy schrieb:> Karl Heinz Buchegger schrieb:>>> Wir haben das damals wie gesagt immer mit new gemacht,>>>> Entweder dein Lehrer ist eine Flasche ersten Ranges, oder aber du hast>> gar nicht C++ programmiert sondern Java.>> Die Frage ist: Wann war damals? Es gab BS, bei denen es nur 64k> Variblenspeicher pro Modul gab. Da macht es durchaus Sinn, große Objekte> auf dem Heap anzulegen.
Anfänger haben es nicht mit 'großen Objekten' zu tun.
Als Anfänger lernt man, dass man mit
1
intmain()
2
{
3
inti;
4
MyClassa;
5
}
ein Objekt namens 'i' vom Datentyp 'int' und in völliger Analogie ein
Objekt namens 'a' vom Datentyp 'MyClass' erzeugt.
Arbeiten mit dynamisch erzeugten Objekten und Pointer kommt später. Viel
später.
Karl Heinz Buchegger schrieb:> Anfänger haben es nicht mit 'großen Objekten' zu tun.>>> Arbeiten mit dynamisch erzeugten Objekten und Pointer kommt später. Viel> später.
Du warst dabei? Oder hast Du eine funktionierende Glaskugel? Dann hätte
ich gerne die Lottozahlen für nächsten Samstag. ;-)
Good Old Boy schrieb:> Karl Heinz Buchegger schrieb:>> Anfänger haben es nicht mit 'großen Objekten' zu tun.>>>>>> Arbeiten mit dynamisch erzeugten Objekten und Pointer kommt später. Viel>> später.>> Du warst dabei?
Ich hab genügend Leute ausgebildet um zu wissen, was eine sinnvolle
Reihenfolge beim erlernen von C++ ist. Objekte von Anfang an mittels new
anzulegen ohne zuerst den einfachsten Fall bis zum Exzess auszureizen
ist nicht sinnvoll. Daher die 'Flasche'.
Du fängst ja in der Physik auch nicht mit Quantentheorie an, sondern
beginnst mit der klassischen Mechanik.
Erst kommt das Einfache und dann handelt man sich zu den schwierigeren
Dingen vor.
Und ja. Ich hab auch genügend Lehrer gesehen, zu denen man am liebsten
sagen würde: Mach doch bitte selbst erst mal einen C++ Kurs, ehe du
versuchst andere zu unterrichten.
Also ich werd den Code jetzt mal von neu auf mit Zeigern schreiben, habe
versucht den bestehenden abzuändern, aber da geht hinten und vorne nix
mehr, dafür ist er einfach zu groß.
Karl Heinz Buchegger schrieb:> Ich hab genügend Leute ausgebildet um zu wissen, was eine sinnvolle> Reihenfolge beim erlernen von C++ ist.
Das kann jeder Lehrer von sich behaupten. Nur ist das kein Beweis, wie
viele schlecht ausgebildete Schueler beweisen.
> Du fängst ja in der Physik auch nicht mit Quantentheorie an, sondern> beginnst mit der klassischen Mechanik.>> Erst kommt das Einfache und dann handelt man sich zu den schwierigeren> Dingen vor.
Eben - und deswegen faengt man nicht mit C++ an, sondern mit Assembler,
dann lehrt man C, dann den Umgang mit dynamisch verwalteten Resourcen
und Modularitaet und dann braucht man C++ gar nicht mehr zu lehren -
dafuer tut's dann ein Buch und einen guten Wunsch fuer die Zukunft.
Marwin schrieb:> Eben - und deswegen faengt man nicht mit C++ an, sondern mit Assembler,> dann lehrt man C, dann den Umgang mit dynamisch verwalteten Resourcen> und Modularitaet und dann braucht man C++ gar nicht mehr zu lehren -> dafuer tut's dann ein Buch
und so sehen die Programme dann auch aus. Echte Kerle schreiben
Fortran-Programme in jeder Programmiersprache...
Oliver
Um beim Thema zu bleiben..C++ *new Alternative
Zusammenfassend:
in C
gibt es zum Anlegen und Freigeben eines Speicherbereichs am Heap nur
malloc(...) bzw.
free(...)
in C++
sollte man IMMER new und delete verwenden, da new und delete mehr als
nur Speicher am Heap anlegt, besonders im Bezug auf
Klassen (wird der Konstruktor bzw. der Dekonstruktor aufgerufen),
Vererbung(wird die virtuelle Methoden-Tabelle aufgebaut),
dynamische Bindung(wird mittels der virtuellen Methoden Tabelle, die
richtige Methode aufgerufen, je nach Klassen-Vererbungshierarchie),
Polymorphismus und vieles andere was ich nicht weiß (und wahrscheinlich
nicht wissen will :)
Ich weiß nicht wie sich das jetzt auf einen uC verhält, aber eines ist
sicher und da FÄHRT DER ZUG DRÜBER. C++ am Rechner sollte man nur new
und delete bei Anlegen eines Speicherbereichs am Heap verwendet werden.
Kala
Kala schrieb:> in C++> sollte man IMMER new und delete verwenden, da new und delete mehr als> nur Speicher am Heap anlegt, besonders im Bezug auf> Klassen (wird der Konstruktor bzw. der Dekonstruktor aufgerufen),> Vererbung(wird die virtuelle Methoden-Tabelle aufgebaut),> dynamische Bindung(wird mittels der virtuellen Methoden Tabelle, die> richtige Methode aufgerufen, je nach Klassen-Vererbungshierarchie),> Polymorphismus und vieles andere was ich nicht weiß (und wahrscheinlich> nicht wissen will :)
Alles richtig.
Aber du hast das Grundproblem nicht verstanden.
Denn die erste Frage lautet NICHT, malloc oder delete?
Die erste Frage muss lauten: Muss ich überhaupt dynamisch allokieren?
Und bis jetzt habe ich vom Fragesteller keinen irgendwie gearteten
Hinweis darauf gelesen, der eine dynamische Allokierung erfordern würde.
"Wir haben das immer so gemacht" ist kein Argument. Genausowenig wie:
"Die Funktion erwartet einen Pointer, also muss ich dynamisch
allokieren."