C++ *new Alternative

Gast #2620761
Lesenswert?

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 #2620825
Lesenswert?

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?
Gast #2620844
Lesenswert?

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 #2620906
Lesenswert?

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,...
#2620963
Lesenswert?

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 #2620982
Lesenswert?

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 #2621559
Lesenswert?

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.
#2621585
Lesenswert?

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.
#2621598
Lesenswert?

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 #2623846
Lesenswert?

Gast #2641283
Lesenswert?

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 #2641418
Lesenswert?

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 #2641648
Lesenswert?

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
#2642287
Lesenswert?

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

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren