Forum: Mikrocontroller und Digitale Elektronik C++ - Operatoren überladen auf µC?


von Fabian S. (jacky2k)


Lesenswert?

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?

von Gast (Gast)


Lesenswert?

oop geht nicht auf AVRs ohne weiteres..

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Fabian S. (jacky2k)


Lesenswert?

Ähhh... Öhhh...
Glaube ich habe das aber schon gemacht...
Wozu gibts denn dann bitte im WinAVR den avr-g++??

von P. S. (Gast)


Lesenswert?

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.

von Fabian S. (jacky2k)


Lesenswert?

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?

von Norgan (Gast)


Lesenswert?

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=

von Fabian S. (jacky2k)


Lesenswert?

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.

von Gerard C. (gerardchoinka)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

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.