Arduino Framework Klassen

[kenny (Gast)]

Hallo zusammen,

ich bin kein Experte was die Programmierung angeht, aber bei weitem auch 
nicht ahnungslos (Assembler, C, C++, Basic, ..).
Beim betrachten einer Arduino Lib für einen SPI Port Expander (MCP23008) 
kamen mir ein paar Fragen bezüglich der Klassen.

Ich habe mal fein gelernt das man Variablen in einer private Klasse 
durch Setter (setzten) und Getter (lesen) Funktionen schützt (vor 
un-plausiblen Eingaben).

Ist das unsauber programmiert, oder macht man das heutzutage so?

Weiter ist mir aufgefallen das es keinen Destruktor gibt.

Ist das beim Arduino Framework nicht nötig, oder wurde auch hier 
unsauber gearbeitet.

[Totomitharry (Gast)]

Hätte jetzt mal ohne Ahnung aber mit Programmierkenntnissen gesagt, das 
ist bei uC in der Größenordnung egal.

Da kommt ja niemand Public an und will jetzt einen Zugriff auf eine 
Private Variable haben sondern der Programmierer bestimmt es selbst was 
worauf zugreift.

[Niklas G. (erlkoenig)]

kenny schrieb:
> Ich habe mal fein gelernt das man Variablen in einer private Klasse
> durch Setter (setzten) und Getter (lesen) Funktionen schützt (vor
> un-plausiblen Eingaben).

Die private Variable ist doch geschützt, denn sie ist privat. Es gibt 
keine Setter weil man von außen überhaupt nicht drauf zugreifen soll. 
Interne (private) Setter sind eher unüblich.

kenny schrieb:
> Ist das beim Arduino Framework nicht nötig

Doch, aber was sollte in den Destruktor dieser Klasse hinein? Wenn eine 
Klasse nichts aufzuräumen hat, braucht's auch keinen expliziten 
Destruktor. In C++ bekommen Klassen automatisch einen impliziten 
Destruktor, welcher einfach nur die Destruktoren der Member-Variablen 
aufruft. Da "uint8_t" keinen Destruktor hat, passiert hier also gar 
nichts. Außerdem werden von dieser Klasse wahrscheinlich nur globale 
Instanzen angelegt, deren Destruktoren ohnehin niemals aufgerufen 
werden, weil Mikrocontroller-Programme sich (normalerweise) nie beenden!

Es gibt aber ein ganz anderes Problem: Die Datei definiert ein Makro 
namens "_ADAFRUIT_MCP23008_H". Bezeichner, die mit 
Unterstrich+Großbuchstabe oder 2 Unterstrichen beginnen, sind aber der 
Umgebung, d.h. Compiler+C++ Standard Bibliothek, vorenthalten. Auch wenn 
dies in diesem Fall wahrscheinlich keine Probleme verursacht, ist es 
trotzdem inkorrektes C++. Außerdem ist es nicht sehr schön, die 
Bitmasken für die Register mit Makros ("#define") zu definieren. In C++ 
ist es möglich und sauberer, Konstanten (mit "const") zu verwenden.

Totomitharry schrieb:
> Da kommt ja niemand Public an und will jetzt einen Zugriff auf eine
> Private Variable haben sondern der Programmierer bestimmt es selbst was
> worauf zugreift.

Exakt genau so ist es beim PC aber auch. "private" schützt auch da nicht 
zur Laufzeit, sondern immer nur vor versehentlichen Fehlern...

[Einer K. (Gast)]

kenny schrieb:
> Ich habe mal fein gelernt das man Variablen in einer private Klasse
> durch Setter (setzten) und Getter (lesen) Funktionen schützt (vor
> un-plausiblen Eingaben).

Was ist eine private Klasse?

Die Regel sagt eher: Keine public Eigenschaften/Variablen

kenny schrieb:
> Weiter ist mir aufgefallen das es keinen Destruktor gibt.
Ein Destruktor ist nur nötig wenn wenn auch was dekonstruiert werden 
soll/muss.
z.B. reservierter Speicher freigeben.
So reicht auch der default Destruktor.

Niklas G. schrieb:
> Es gibt aber ein ganz anderes Problem: Die Datei definiert ein Makro
> namens "_ADAFRUIT_MCP23008_H". Bezeichner, die mit
> Unterstrich+Großbuchstabe oder 2 Unterstrichen beginnen, sind aber der
> Umgebung, d.h. Compiler+C++ Standard Bibliothek, vorenthalten.

Ganz abgesehen von dem Fehler:
Den alten IncludeGuard könnte man sowieso durch #pragma once ersetzen.

[Wilhelm M. (wimalopaan)]

kenny schrieb:
> Ich habe mal fein gelernt das man Variablen in einer private Klasse
> durch Setter (setzten) und Getter (lesen) Funktionen schützt (vor
> un-plausiblen Eingaben).

Da keine der Elementfunktion const ist, sind das alles Modifikatoren aka 
setter. DAS halte ich für unsauber.

kenny schrieb:
> Weiter ist mir aufgefallen das es keinen Destruktor gibt.

Doch, es gibt den default-dtor. Warum sollte der nicht ok sein?

[Stefan F. (Gast)]

kenny schrieb:
> Ich habe mal fein gelernt das man Variablen in einer private Klasse
> durch Setter (setzten) und Getter (lesen) Funktionen schützt (vor
> un-plausiblen Eingaben).

Das wurde gerade in einem anderen Thread kontrovers diskutiert. Es kommt 
auf den persönlichen Geschmack an.

> Weiter ist mir aufgefallen das es keinen Destruktor gibt.

Dito.

[Wilhelm M. (wimalopaan)]

Arduino Fanboy D. schrieb:
> Was ist eine private Klasse?

Mit "privater Klasse" könnte eine private Deklaration einer 
geschachtelten Klasse gemeinst sein. Bin aber ziemlich sicher, dass der 
TO das nicht meint, sondern einfach nur von non-static Datenelementen 
spricht.