Hallo zusammen!
Der avr-libc fehlt ja „new“. Was mache ich aber, wenn ich mehr als nur ein Objekt einer Klasse benötige?
Normalerweise würde ich folgendes schreiben:
ding* arr[10]; // die 10 ist willkürlich gewählt. Da könnte auch 1000 stehen.
for(uint8_t index=0; index<10; index++)
{
arr[index]=new ding();
}
Aber das geht ja nicht. Wie bekomme ich trotzdem ein solches Array zustande?
Vielen Dank vorweg!
Gregor
new wird von der Arduino IDE implementiert. Macht aber auch nur malloc():
void *operator new(size_t size) {
return malloc(size);
}
void *operator new[](size_t size) {
return malloc(size);
}
void operator delete(void * ptr) {
free(ptr);
}
void operator delete[](void * ptr) {
free(ptr);
}
Wieso aber dynamischer Speicher? Du kannst auch Arrays von Objekten statisch anlegen
Da könnte auch 1000 stehen.
Eher unwahrscheinlich... 
Was spricht gegen
ding arr[10];
Wobei traditionell Klassen gern mit Großbuchstaben geschrieben werden.
Ding dinge[100];
for (byte index=0; index < 100; index++)
dinge[index].machwas();
michael_x:
- fehlt new nicht
Also in der Referenz finde ich das nicht und wenn ich mich recht erinnere, ist in der Doku zur avr-libc erwähnt, dass new und delete nicht implementiert sind (weshalb es da auch keine STL gibt). Habe ich da etwas falsch verstanden?
michael_x:
Was spricht gegending arr[10];
Äh ... öh ... Du hast recht. Ich bin wohl zu sehr gewöhnt, sowas mit Zeigern zu machen.
Gruß
Gregor
Es wird wie gesagt von der Arduino Software implementiert. Die macht da aber nur malloc() und delete macht free(). Also direkt aus C.
Die macht da aber nur malloc() und delete macht free(). Also direkt aus C.
Ein entsprechender Konstruktor würde wohl auch noch durchlaufen.
Was heisst schon "nur". Interessanter ist eher, dass es keine Exceptions gibt und traditionell Fehlerbehandlung bei Arduino "uncool" ist, weil nicht klar ist was man überhaupt tun könnte.
RAM der vor setup() nicht da ist, wird auch später nicht nachwachsen. Das schränkt sinnvolle Anwendungsfälle für dynamische Heap-Zerstückelung ziemlich ein.
-> Wer an new denkt, hat schon einen Design-Fehler gemacht.
String-Objekte brauchen new öfter als man denkt.
michael_x:
-> Wer an new denkt, hat schon einen Design-Fehler gemacht.
So naseweis, wie Du das mal wieder behauptest, kannst Du das doch bestimmt ein bisschen erläutern. Vielleicht gehöre ich ja zu den Idioten, die seit Jahren keine Ahnung von Software-Design haben.
Gilt das für alle Programmierer?
Oder nur für alle C++-Programmierer?
Oder nur für alle, die den Arduino in C++ programmieren?
Oder nur für alle, die eine bestimmte Sache auf dem Arduino in C++ programmieren wollen?
Oder ...?
Würde mich echt mal interessieren. Auch, ob Du Lektüre dazu hast.
Gruß
Gregor
Es gilt für µC und vor allem für kleine µC die kaum RAM haben. Ein PC ist einfach was ganz anderes.
Schlimm wird es bei new/delete erst wirklich wenn man Speicher in willkürlicher Folge anlegt und wieder freigibt. Wenn man 2 Blöcke anlegt und in der gleichen Reihenfolge frei gibt bevor man anderen Speicher anlegt wird auch nichts fragmentiert.
Jedoch ist es in den meisten Fällen eben völlig unnötig. Wie hier wo man Speicher auch ganz einfach statisch anlegen kann und dann auch noch beim Kompilieren sieht, dass er auch belegt wird (Anzeige freier Speicher). Was anderes ist wenn die Größe des Arrays erst zur Laufzeit bekannt wäre.
Serenifly:
Es gilt für ...
So eingeschränkt ist das vermutlich schon richtig.
Gruß
Gregor
So wörtlich darfst du mein Gemecker nicht nehmen 8)
Deine Vermutung c) ist richtig
Gilt nur beim Arduino programmieren, und auch da umso wichtiger, je kleiner...
Ein attiny13 hat 64 Byte RAM, ein attiny45 immerhin 256 Byte, und die 2048 beim Uno sind auch schnell verbraten, wenn man sich keine Gedanken macht.
Der Design-Fehler liegt evtl. darin, dass man in java oder c# denkt, und daher sofort ein new schreibt, wo eigentlich keins gebraucht wird.
Und dass man in der Regel bei µControllern besser in "ewig" laufenden Automaten denken sollte.
P.S. Serenifly war schneller
michael_x:
So wörtlich darfst du mein Gemecker nicht nehmen 8)
Wenn das so ist, kann ich sowas künftig besser ignorieren.
michael_x:
Der Design-Fehler liegt evtl. darin, dass man in java oder c# denkt, und daher sofort ein new schreibt, wo eigentlich keins gebraucht wird.
Ich „denke“ beim Design von Programmen meistens gleich an Objekte. Das kommt wahrscheinlich daher, dass ich C++ mit einem Buch gelernt habe, das den Objektgedanken vom Start weg unterstreicht. Daher wahrscheinlich auch meine „new“-Denke.
Dem Gedanken, das „new“ bei µC grundsätzlich blöd wäre, kann ich weiterhin nicht zustimmen. Bei einer gestrigen Spielerei habe ich eine Klasse programmiert, die lediglich 6 Bytes benutzt hat. Von so einer Klasse kann man auch bei nur 1 oder 2 kB RAM mehrere zehn instanzieren. Warum man dann nicht mit dynamisch erzeugten Objekten arbeiten soll, will mir auch heute nicht einleuchten.
Gruß
Gregor
PS: Ein Filmchen meiner kleinen Spielerei gibts da: test.szaktilla.de/imgp4314.mpeg
Warum man dann nicht mit dynamisch erzeugten Objekten arbeiten soll, will mir auch heute nicht einleuchten.
Ja!
unbekannt:
Wer einmal begriffen hat, wie ein Hammer funktioniert, für den sieht die ganze Welt plötzlich wie ein Nagel aus.
Im Grunde kann ich dir zustimmen...
Aber andererseits auch nicht.
Und zwar:
Es ist sowieso böse die new wild im Programm zu verstreuen, egal, welche Sprache, egal welches System. news haben sich in Fabriken zu befinden!
Jedes vermeidbare new ist sowieso eins zuviel.
Immer.
Im Grunde bleibt uns auf unseren kleinen µC nur ein einziger OOP Vorteil, den wir bedenkenlos nutzen können, die Kapselung.
Und von deiner dynamischen Speicherverwaltung bist du sofort geheilt, wenn du in die schon genannten Probleme rennst. Fragmentierung und die damit auf dem Fuße folgenden Stack/Heap Kollisionen.
Viel Spass beim Debuggen.
Die modernen großen CPUs haben alle Speicherschutz Mechanismen. Unsere AVRs nicht.
Bei einer gestrigen Spielerei habe ich eine Klasse programmiert, die lediglich 6 Bytes benutzt hat. Von so einer Klasse kann man auch bei nur 1 oder 2 kB RAM mehrere zehn instanzieren.
derselbe:
ding* arr[10]; // die 10 ist willkürlich gewählt. Da könnte auch 1000 stehen.
1000 Pointer auf ding geht ganz knapp bei 2kB RAM , die dinger selber aber schon nicht mehr.
Und das ohne Fehlermeldung!
gregorss:
Ich „denke“ beim Design von Programmen meistens gleich an Objekte
Abgesehen davon dass C++ eine Multi-Paradigma Sprache ist, und man daher OOP und prozedurala Programmierung je nach Bedarf Mischen kann ist das völlig ok.
Aber OOP sagt erst mal nichts über den Speicher aus. Man kann Objekte eben genauso auf dem Stack statt auf dem Heap erzeugen.
michael_x:
1000 Pointer auf ding geht ganz knapp bei 2kB RAM , die dinger selber aber schon nicht mehr.
Und das ohne Fehlermeldung!
Ja 
Das mit der Zahl Tausend war gewürfelt. Da hätte auch 1 Mio. stehen können (oder drei).
Gruß
Gregor