Forum: Compiler & IDEs C++ *new Alternative


von Bösler (Gast)


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

von Dominik S. (dasd)


Lesenswert?

Bösler schrieb:
> Nun funktionert C++ ja mitlerweile auf dem AVR

Ach das gibt's? Nicht gewusst...
Aber warum willst du überhaupt C++ verwenden?

von TestX .. (xaos)


Lesenswert?

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:
1
something a();

und gut..

von Stefan E. (sternst)


Lesenswert?

Wie wäre es mit:
1
int main()
2
{
3
  something a;
4
...

von Bösler (Gast)


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?

von Tom K. (ez81)


Lesenswert?

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;" ?

von Bösler (Gast)


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

von Bösler (Gast)


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,...

von Bösler (Gast)


Lesenswert?

... nur das jetzt eben ohne *new...

von Tom K. (ez81)


Angehängte Dateien:

Lesenswert?

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

von facebook (Gast)


Lesenswert?

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?

von Karl H. (kbuchegg)


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.

von Bösler (Gast)


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

von Dominik S. (dasd)


Lesenswert?

Karl Heinz Buchegger schrieb:
> Entweder dein Lehrer ist eine Flasche ersten Ranges, oder aber du hast
> gar nicht C++ programmiert sondern Java.

Respektive C#

von Peter II (Gast)


Lesenswert?

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?

von Good Old Boy (Gast)


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.

von Karl H. (kbuchegg)


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.

von Good Old Boy (Gast)


Lesenswert?

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. ;-)

von Karl H. (kbuchegg)


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.

von Karl H. (kbuchegg)


Lesenswert?

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.

von Bösler (Gast)


Lesenswert?

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ß.

von was? (Gast)


Lesenswert?


von Marwin (Gast)


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.

von Oliver (Gast)


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

von Kala (Gast)


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

von Karl H. (kbuchegg)


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."

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.