Hallo, ich muss auf nem AVR (atmega8 oder 32) mit Vektoren rechnen und da würde es sehr gelegen kommen wenn ich das ganze mit Klassen machen würde um dann Operatoren zu überladen. Frage nun: Wie stark bremst das den µC aus, wie viel RAM/ROM braucht das?
Gast
#988143
oop geht nicht auf AVRs ohne weiteres..
Das Überladen selbst verursacht keinen Overhead. Was Overhead erzeugt ist das "late binding", d. h. zu einem Objekt lässt sich erst zur Laufzeit feststellen, welche konkrete Implemen- tierung zuständig ist. Erstens kostet die Entscheidung Zeit, und zweitens legt der AVR-GCC die virtuellen Methodentabelle im SRAM ab. Andererseits: wenn man wirklich late binding benötigt, wird die manuelle Implementierung auch nicht performanter ausfallen.
Ähhh... Öhhh... Glaube ich habe das aber schon gemacht... Wozu gibts denn dann bitte im WinAVR den avr-g++??
Gast
#988159
Gast wrote: > oop geht nicht auf AVRs ohne weiteres.. Wenn du mit "oop" overloaded operators meinst, kann das sein (Ich hab's noch nicht versucht). Meinst du aber object oriented programming, ist das voelliger Quatsch. OOP ist eine Frage des Programmierprinzips und eine Sprache kann das mit diversen Features unterstuetzen oder vereinfachen, prinzipiell ist objektorientierte Programmierung aber auch in Assembler moeglich. Nach meiner Erfahrung hat der AVR-GCC ein Problem mit virtuellen Methoden - ich hab zumindest selbst einfachste Beispiele nicht hinbekommen, sondern nur obskurste Compiler-Fehler bekommen. Das betrifft zwar nicht direkt ueberladene Operatoren, aber was Fabian machen will, wird wahrscheinlich auch virtuelle Methoden benoetigen. Ansonsten: Einfach mal ausprobieren.
Naja manuell ist zwar dann genau so langsam oder schneller, aber dafür deutlisch unübersichtlicher... Dises late bindung, passiert das nicht nur bei Vererbung und sowas? Und da ich das nicht vor habe zu machen sollte es auch nicht so viel langsamer werden oder?
Gast
#988176
Dem avr-gcc fehlen für die C++ Standard-Bibliotheken und es fehlen new und delete. Letztere kann man nachrüsten: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=59453&start=0&postdays=0&postorder=asc&highlight=
Jo das ist mir klar, new und delete werde ich nicht verwenden und wenn ich mich recht entsinne sollte man das auch lieber lassen, da der AVR ja nix zum aufräumen des RAMs hat, geschweige denn Paging...da wird der RAM schnell fragmentiert und irgendwann nippelt er ab. Ich brauche nur die Strukturen von C++ und die Operatorenüberladung.
Fabian S. wrote: > Naja manuell ist zwar dann genau so langsam oder schneller, aber dafür > deutlisch unübersichtlicher... > Dises late bindung, passiert das nicht nur bei Vererbung und sowas? > Und da ich das nicht vor habe zu machen sollte es auch nicht so viel > langsamer werden oder? Ich glaube selbst mit Vererbung gibt es kein Problem, solange kein virtuelen Methoden im Spiel sind.
Fabian S. wrote: > Dises late bindung, passiert das nicht nur bei Vererbung und sowas? Ja, es ist nur mit abgeleiteten Klassen möglich. Das Prinzip besteht darin, dass man eine allgemeine Basisklasse definiert, von dieser weitere Klassen abgeleitet werden. Die Basisklasse enthält jedoch gar keine Implementierung von Methoden oder implementiert nicht alle Methoden: die konkrete Implementierung obliegt den abgeleiteten Klassen. Von der Basisklasse (die sich dann eine abstrakte Klasse nennt) kann man kein Objekt instanziieren, aber instanziierte Objekte der abgeleiteten Klassen sind zuweisungskompatibel mit Variablen (oder Parametern) der Basisklasse. Dadurch kann man mit ihnen hantieren, ohne zur Compilezeit wissen zu müssen, welche konkrete Implementierung die dahinter liegenden Objekte zur Laufzeit haben werden. Ja, klingt alles sehr abstrakt. ;-) > Und da ich das nicht vor habe zu machen sollte es auch nicht so viel > langsamer werden oder? Es wird gar nicht langsamer.
Fabian S. wrote: > ...da wird der RAM > schnell fragmentiert und irgendwann nippelt er ab. Er kann fragmentieren. Er muss es aber nicht. Wenn nur immer Objekte gleicher Größe angefordert werden, dann kann er nicht einmal fragmentieren dabei.