C++ *new Alternative

Gast #2620761
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:
1
class something
2
{
3
int test1;
4
int test2;
5
...
6
};
7
 
8
int main()
9
{
10
  something *a = new something();
11
  return 0;
12
}

Dank Euch schonmal

gruss
Gast
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;" ?
Gast
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
Gast
Vlt. erkläre ich auch einfach mal kurz was ich vor habe, hoffe ich bring 
das rüber,... und zwar habe ich 2 Klassen.

1
class Test1 {
2
public:
3
  Test1(char Zeichen, int Zahl);
4

5
...
6

7

8
class Test2 {
9
public:
10
  Test2(Z *z1, Z *z2);
11

12
...
13

14
};
in meiner Main "initialisiere" ich Test1, bisher so,..
1
Test1 *z1=new Test1(A,1);
2
Test1 *z2=new Test1(B,2);

dann Test2, mit Klasse1, da ich diese dann auch in den Funktionen der 2. 
Klasse verwende.
1
Test2 *Test=new Test2(z1, z2);

hoffe ich habe jetzt nix vergessen, oder verdreht,...
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
Angehängte Dateien:
Gast
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.
Gast
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
Gast
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
int main()
2
{
3
  int i;
4
  MyClass a;
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.
Gast
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.
Gast
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ß.
Gast
Gast
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.
Gast
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
Gast
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."

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 14 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.