Development/Tutorials/Common Programming Mistakes (de)

Häufige Programmierfehler

Anleitungsserie	Grundlagen
Voriges Kapitel	None
Nächstes Kapitel	n/a
Weiterführende Texte	n/a
Navigation	Deutsche Startseite

Zusammenfassung

Diese Anleitung gibt ein paar Tips aus dem Erfahrungsschatz von KDE Entwicklern bezüglich was man in Qt und KDE machen und was lieber sein lassen sollte. Neben aktuellen Fehler behandelt es auch Dinge, die nicht unbedingt als Fehler gelten jedoch den Code langsamer oder weniger lesbar machen.

C++ allgemein

Dieses Kapitel beschäftigt sich mit einigen dunklen Ecken von C++, die gerne falsch benutzt oder schlicht und einfach falsch verstanden werden.

Anonyme Namensräume vs. statics

Wenn Sie eine Methode in einer Klasse haben, die nicht auf Members zugreift und daher kein Objekt zu seiner Arbeit benötigt, machen Sie es static. Wenn diese Methode dann zusätzlich nur eine private Hilfsfunktion ist, welche außerhalb dieser Datei nicht benötigt wird, machen Sie daraus eine file-static Funktion, dadurch wird das Symbol komplett verborgen.

Symbole die in C++ in einem anonymen Namensraum definiert werden, haben keine interne Verknüpfung. Anonyme Namensräume vergeben nur einen eindeutigen Namen für diese Übersetzungseinheit und das ist alles. Die Verknüpfung des Symbols wird überhaupt nicht verändert, weil die zweite Phase einer zwei-Phasen Namenssuche Funktionen mit interner Verknüfung ignoriert. Weiterhin können Elemente mit interner Verknüpfung nicht als Argumente für Templates benutzt werden.

Wenn Sie also nicht wollen, dass ein Symbol exportiert wird, benutzen Sie statt anonymen Namensräumen statische.

NULL Zeiger Probleme

Als erstes und wichtigstes: Es ist OK einen Null Zeiger zu löschen. Daher sind Konstrukte, die einen Zeiger auf Null testen redundant:

if ( ptr ) {
   delete ptr;
}

Beachten Sie jedoch, dass ein Null-Check erforderlich ist, wenn Sie ein Array löschen - das liegt daran, dass ein relativ neuer Compiler auf Solaris-Systemen das anderweitig nicht richtig behandelt.

Wenn Sie einen Zeiger löschen, stellen Sie sicher, dass sie ihn auf 0 setzen, so dass zukünftige Löschversuche nicht mit einer doppelten Löschung fehlschlagen. Der entsprechende Code dazu:

delete ptr; 
ptr = 0;

Ihnen mag aufgefallen sein, dass Null-Zeiger auf eine von drei Arten bezeichnet werden können: 0, 0L und NULL. In C ist NULL als null void Zeiger definiert. In C++ ist dies jedoch nicht möglich aufgrund einer strengeren Typprüfung. Daher definieren moderne C++ Implementationen eine "magische" Null-Zeiger Konstante, die einem beliebigen Zeiger zugewiesen werden kann. Ältere C++ Implementationen definierten es einfach als 0L oder 0, was keine zusätzliche Typsicherheit bietet - man könnte es einer Integervariable zuweisen, was offensichtlich falsch ist.

Bei Zeigern bedeutet die Integerkonstante Null "Null-Zeiger" - unabhängig von der aktuellen Binärdarstellung eines Null-Zeigers. Daher ist die Entscheidung zwischen 0, 0L und NULL eine Frage des persönlichen Stils und der Gewohnheit statt technischer Gegebenheiten - was den Code in KDE's SVN betrifft, werden Sie mehr 0 als NULL verwendet sehen.

Beachten Sie jedoch, das wenn Sie eine Null-Zeiger Konstante an eine Funktion mit variabler Parameterliste übergeben, Sie diese explizit in eine Zeiger-Variable ändern müssen - der Compiler nimmt per Voreinstellung den Integerkontext an, was möglicherweise nicht der Binärdarstellung eines Null-Zeigers entspricht. Wieder ist es egal, ob Sie 0, 0L oder NULL verwenden, im Allgemeinen wird die kürzere Darstellung bevorzugt.

Member Variablen

Sie werden vielleicht vier Hauptstile bemerkt haben, wie in KDE-Klassen Member-Variablen benannt werden:

• m_variable kleines m, Unterstrich und der Name der Variable mit einem Kleinbuchstaben am Anfang. Das ist der am meisten verwendete Stil und wird im Code von kdelibs bevorzugt.
• mVariable kleines m und der Name der Variable mit einem Großbuchstaben am Anfang
• variable_ Name der Variable mit einem Kleinbuchstaben am Anfang und variable einem Unterstrich am Ende
• _variable Unterstrich und der Name der Variable mit einem Kleinbuchstaben am Anfang. Dieser Stil wird nicht so gerne gesehen, da diese Notation auch in Code für Funktionsparameter verwendet wird.

Wie immer gibt es nicht nur einen korrekten Weg es zu machen, so folgen Sie einfach der Syntax der Applikation/Bibliothek zu welcher Sie Code ergänzen.

Static variablen

Versuchen Sie die Anzahl der static Variablen in Ihrem Code zu limitieren, besonders wenn Sie an einer Bibliothek arbeiten. Konstruktion und Initialisierung einer großen Anzahl von static Variablen kann die Startzeit stark verlängern.

Benutzen Sie keine class-static Variablen, besonders nicht in Bibliotheken und ladbaren Modulen obwohl es sogar in Applikationen nicht empfohlen wird. Static Objekte führen zu einer Menge Problemen wie schwer zu verolgende Abstürze wegen einer undefinierten Reihenfolge des Konstruktion/Destruktion.

Benutzen Sie stattdessen einen static Zeiger, zusammen mit K_GLOBAL_STATIC welches in kglobal.h definiert wird und wie folgt benutzt wird:

class A { ... };

K_GLOBAL_STATIC(A, globalA)

void doSomething()
{
     A *a = globalA;
     ...
}

void doSomethingElse()
{
    if (globalA.isDestroyed()) {
        return;
    }
    A *a = globalA;
    ...
}

void installPostRoutine()
{
    qAddPostRoutine(globalA.destroy);
}

Sehen Sie auch API Dokumentation für K_GLOBAL_STATIC, um weitere Informationen zu erhalten.

Forward Deklarationen

Die Übersetzungszeit kann reduziert werden, indem man Klassen forward deklariert anstatt den entsprechenden Header einzubinden. Ein Beispiel:

#include <QWidget>     // langsam
#include <QStringList> // langsam
#include <QString>     // langsam
class SomeInterface
{
public:
    virtual void widgetAction( QWidget *widget ) =0;
    virtual void stringAction( const QString& str ) =0;
    virtual void stringListAction( const QStringList& strList ) =0;
};

Das obige sollte statt dessen folgendermaßen formuliert werden:

class QWidget;     // schnell
class QStringList; // schnell
class QString;     // schnell
class SomeInterface
{
public:
    virtual void widgetAction( QWidget *widget ) =0;
    virtual void stringAction( const QString& str ) =0;
    virtual void stringListAction( const QStringList& strList ) =0;
};

Iteratoren

Bevorzugen Sie const_iterators vor normalen Iterationen wann immer es möglich ist.

noframe

Dieser Abschnitt muss verbessert werden: Bitte hilf mit, verwirrende Abschnitte zu bereinigen und Abschnitte zu reparieren die ein todo beinhalten

Einige Abschnitte in diesem Kapitel konnte ich leider nicht übersetzen.

Warnung

Containers, which are being implicitly shared often detach when a call to a non-const begin() or end() methods is made (List ist ein Beispiel eines solchen Containers).

Wenn Sie einen const_iterator benutzen, achten Sie auch darauf, wirklich die const-Version von begin() und end() aufzurufen.

Unless your container is actually const itself this probably will not be the case, possibly causing an unnecessary detach of your container. So basically whenever you use const_iterator initialize them using constBegin()/constEnd() instead, to be on the safe side.

Speichern Sie den Rückgabewert des end() Methodenaufrufs zwischen bevor Sie eine Iteration in großen Containern ausführen. Zum Beispiel:

QValueList<SomeClass> container;

//Code, der eine große Anzahl von Elementen in den Container einfügt.

QValueListConstIterator end( container.end() );

for ( QValueListConstIterator itr( container.begin() );
     itr != end; ++itr ) {
}

Dadruch wird die unnötige Erzeugung eines temporären Rückgabe Objektes für end() in jedem Schleifendurchlauf vermieden und dadurch die Ausführung beschleunigt.

Benutzen Sie anstatt von Post-Increment Operatoren besser Pre-Increment Operatoren bei Iteratoren, da dies das Erzeugen von unnötigen, temporären Objekten in diesem Prozess vermeidet.

Seien Sie vorsichtig wenn Sie Elemente innerhalb einer Schleife löschen

Wenn Sie einige Elemente aus der Liste löschen wollen, könnten Sie vielleicht einen Code wie folgenden benutzen wollen:

QMap<int, Job *>::iterator it = m_activeTimers.begin();
QMap<int, Job *>::iterator itEnd = m_activeTimers.end();

for( ; it!=itEnd ; ++it )
{
    if(it.value() == job)
    {
        //A timer for this job has been found. Let's stop it.
        killTimer(it.key());
        m_activeTimers.erase(it);
    }
}

Dieser Code wird eventuell wegen eines hängenden Iterators nach dem Aufruf von erase() einen Crash erzeugen. Sie müssen den Code folgendermaßen umschreiben:

QMap<int, Job *>::iterator it = m_activeTimers.begin();
while (it != m_activeTimers.end())
{
    QMap<int, Job *>::iterator prev = it;
    ++it;
    if(prev.value() == job)
    {
        //A timer for this job has been found. Let's stop it.
        killTimer(prev.key());
        m_activeTimers.erase(prev);
    }
}

Dieses Problem wird auch in Qt documentation for QMap::iterator diskutiert, trifft aber auf alle Qt Iteratoren zu.

Programm Design

In diesem Abschnitt beschäftigen wir uns mit einigen allgemeinen Problemen im Zusammenhang mit den Design von Qt/KDE Applikationen.

Verspätete Initialisierung

Obwohl das Design von modernen C++ Applikationen sehr komplex sein kann, ist ein immer wieder auftretendes Problem - was jedoch leicht zu beheben ist - die Tatsache nicht die Technik der verspäteten Initialisierung zu benutzen.

Zunächst sehen wir uns den Standardweg einer Initialisierung einer KDE Applikation an:

int main( int argc, char **argv )
{
    ....
    KApplication a;

    KCmdLineArgs *args = KCmdLineArgs::parsedArgs();

    MainWindow *window = new MainWindow( args );

    a.setMainWidget( window );
    window->show();

    return a.exec();
}

Beachten Sie, dass window vor dem Aufruf von a.exec(), der die Ereignisschleife startet, erzeugt wird. Das bedeutet, dass wir es vermeiden sollten, nicht-triviales im obersten Konstruktor durchzuführen, da dieser Läuft bevor das Fenster überhaupt dargestellt werden kann.

Die Lösung ist einfach: Wir müssen die Konsruktion von Dingen außer der GUI solange verzögern, bis die Ereignisschleife startet. Hier ist ein Beispiel, wie der Konstruktor eines MainWindows aussehen sollte, um das zu erreichen:

MainWindow::MainWindow()
{
    initGUI();
    QTimer::singleShot( 0, this, SLOT(initObject()) );
}

void MainWindow::initGUI()
{
    /* Erzeugen Sie Ihre Widgets hier. Beachten Sie das die Widgets
     * die Sie hier erzeugen, keine komplexe Initialisierung beötigen sollten
     * da ansonsten die Ganze Aktion nicht viel Sinn macht. Alles was
     * hier geschehen sollte, ist die Erzeugung der GUI Objekte und das
     * Verknüfen via QObject::connect der entsprechenden Signals mit deren  
     * Slots
     */
}

void MainWindow::initObject()
{
    /* Dieser Slot wird aufgrufen sobald die Ereignisschleife startet. 
     * Implementieren Sie hier alles was sonst noch getan werden muss,
     * inklusive dem Wiederherstellen von Werten, dem Lesen von Dateien, 
     * Wiederherstellung von Sitzungen, etc. 
     * Das wird immer noch eine Zeit dauern, aber wenigstens ist Ihr 
     * Fenster in dieser Zeit sichtbar und so macht die Applikation
     * einen aktiven Eindruck.
     */
}

Diese Technik gibt ihnen keinen Zeitvorteil (es läuft nichts schneller dadurch), aber die Applikation macht für den Benutzer den Eindruck, als würde sie schneller starten. Das wird dadurch bewerkstelligt, dass der Benutzer eine schnelle Antwort auf das starten der Applikation erhält.

Wenn (und nur dann) der Start nicht in einem vernünftigen Zeitrahmen erfolgen kann, überlegen Sie sich, ein KSplashScreen einzusetzen.

Daten Strukturen

In this section we will go over some of our most common pet-peeves which affect data structures very commonly seen in Qt/KDE applications.

non-POD typen übergeben

Nicht-POD ("plain old data") Typen sollten als const Referenz übergeben werden, wann immer das möglich ist. Das beinhaltet alle Datentypen außer char und int.

Nehemen Sie zum Beispiel QString. Diese sollten als Parameter an Methoden immer als const QString& übergeben werden. Auch wenn QString implicitly shared ist, ist das immer noch effizienter (und sicherer) es als const Referenz zu übergeben statt als Wert.

So allgemein sollte eine Methode, die QString als Argument nimmt, so aussehen:

void myMethod( const QString & foo, const QString & bar );

QObject

Sollten Sie jemals eine von QObject abgeleitete Klasse aus den eigenen Methoden heraus löschen sollen, löschen Sie es nicht folgendermaßen:

   delete this;

Das wird früher oder später in einen Absturz führen, da eine Methode dieses Objektes aus der Qt-Ereignisschleife heraus via slots/signals aufgerufen werden könnte, nachdem Sie es gelöscht haben.

Nutzen Sie statt dessen immer QObject::deleteLater(), was das gleiche wie delete this erledigt jedoch in einer sicheren Art und Weise.

Leere QStrings

Häufig muss geprüft werden, ob ein QString leer ist. Hier sind drei Ansätze das zu prüfen, wobei nur die ersten beiden korrekt sind:

// Richtig
if ( mystring.isEmpty() ) {
}

// Richtig
if ( mystring == QString() ) {
}

// Falsch! ""
if ( mystring == "" ) {
}

Obwohl es ein Unterschied zwischen "null" QStrings und leeren gibt, ist das nur ein historisches Artefakt, neuer Code sollte das nicht mehr benutzen.

QString und das Lesen aus Dateien

Wenn Sie aus einer Datei lesen, ist es schneller, in einem Rutsch von der lokalen Verschlüsselung nach Unicode (QString) zu konvertieren als zeilenweise. Das bedeutet, dass Methoden wie QIODevice::readAll() meist eine gute Lösung sind, gefolgt von einer einizigen QString instantierung.

Bei größeren Dateien sollte sich in Betracht ziehen, einen Block von Zeilen zu lesen und dann zu konvertieren. Auf diese Art und Weise haben Sie die Möglichkeit ihre GUI zu aktualisieren. Das kann bewekstelligt werden, indem Sie wieder in die Ereignisschleife eintreten und gleichteitig mittels eines Timers die Blöcke im Hintergrund lesen oder indem Sie eine lokale Ereignisschleife definieren.

Man könnte auch qApp->processEvents() aufrufen, davon wird jedoch abgetraten, da es leicht zu zum Teil fatalen Problemen führt.

QString aus einem KProcess lesen

KProcess löst das Signal readyReadStandard{Output|Error} aus, sobald Daten eintreffen.

Ein häufiger Fehler ist es, alle verfügbaren Daten im verbundenen Slot zu lesen und sofort in ein QString zu konvertieren: Die Daten könnten in kleineren unregelmäßigen Portionen einreffen, daher könnten multi-byte Zeichen in Stücke geschnitten und daher ungültig werden. Mehrere Ansätze existieren:

• Müssen Sie die Daten wirklich sofort verarbeiten sobald sie eintreffen? Wenn nicht, benutzen Sie lieber readAllStandard{Output|Error} nachdem der Prozess beendet wurde. Anders als in KDE3 ist KProcess nun in der Lage, die Daten zu sammeln.
• Sammeln Sie die Datenbrocken im Slot und bearbeiten Sie sie immer dann, wenn ein Newline kommt oder ein bestimmter Timeout auftritt.Example code (KDE3 based)
• Fügen Sie den Prozess in ein QTextStream ein und lesen Sie diesen zeilenweise. Während das zumindest theoretisch funktionieren sollte, funktioniert das in der Praxis derzeit nicht.

QString und QByteArray

Während QString das Werkzeug der Wahl für viele Situationen ist, in denen mit Zeichenketten gearbeitet wird, gibt es eine Situation, wo dies äußerst ineffizient ist. Wenn Sie mit Daten arbeitet, die in einem QByteArray gespeichert sind, sehen Sie sich vor, dass Sie diese nicht an Methoden übergeben, die einen QString Parameter benötigen und daraus wieder ein QByteArray macht.

For example:

QByteArray myData;
QString myNewData = mangleData( myData );

QString mangleData( const QString& data ) {
    QByteArray str = data.toLatin1();
    // mangle 
    return QString(str);
}

Der kostspielige Teil hier ist die Konvertierung nach QString, was intern als Konvertierung in Unicode durchgeführt wird. Das ist unnötig, da das erste, was die Methode tut, eine Rückkonvertierung nach toLatin1() ist. Wenn Sie sich also sicher sind, dass eine Unicode Konvertierung nicht bennötigt wird, versuchen sich Zwischenschritte mit QString zu vermeiden.

Das obige Beispiel sollte statt dessen geschrieben werden als:

QByteArray myData;
QByteArray myNewData = mangleData( myData );

QByteArray mangleData( const QByteArray& data )

QDomElement

When ein XML Dokument geparst wird, benötigt man häufig eine Iteration über alle Elemente. Man könnte versucht sein, folgenden Code dafür zu benutzen:

for ( QDomElement e = baseElement.firstChild().toElement();
      !e.isNull();
      e = e.nextSibling().toElement() ) {
       ...
}

Das ist jedoch nicht korrekt: Die obige Schleife wird vorzeitig beendet wenn es auf einen QDomNode trifft, der etwas anderes als ein Element ist (zum Beispiel ein Kommentar).

Die korrekte Schleife sieht so aus:

for ( QDomNode n = baseElement.firstChild(); !n.isNull();
      n = n.nextSibling() ) {
    QDomElement e = n.toElement();
    if ( e.isNull() ) {
        continue;
    }
    ...
}