Development/Tutorials/Common Programming Mistakes/pt-br

Erros Comuns de Programação

Tutorial Series	Iniciando
Previous	None
What's Next	n/a
Further Reading	APIs to avoid

Resumo

Este tutorial tem como objetivo combinar a experiência dos desenvolvedores KDE em relação aos prós e contras dos frameworks Qt e KDE. Além de erros reais, ele também cobre coisas que não são necessariamente "bugs", mas que tornam o código mais lento ou menos legível.

C ++ em geral

Esta seção te guia por alguns dos cantos mais empoeirados do C ++ que tende a ser mal utilizado ou que as pessoas também simplesmente erram.

Anonymous namespaces vs statics

Se você possui um método em uma classe que não acessa nenhum membro e, portanto, não precisa de um objeto para operar, torne-o estático. Se, além disso, for uma função auxiliar privada que não é necessária fora do arquivo, torne-a uma função estática do arquivo. Isso esconde o símbolo completamente.

Os símbolos definidos em um anonymous namespace C++ não têm ligação interna. Os anonymous namespaces fornecem apenas um nome exclusivo para essa unidade de tradução e é isso; eles não alteram a ligação do símbolo. A ligação não é alterada naquelas porque a segunda fase da pesquisa de nome em duas fases ignora as funções com ligações internas. Além disso, entidades com ligação interna não podem ser usadas como argumentos de template.

Portanto, dessa vez, ao invés de usar anonymous namespaces, use static se você não quiser que um símbolo seja exportado.

Problemas de ponteiro NULL

Em primeiro lugar: tudo bem excluir um ponteiro nulo. Portanto, construções como esta que verificam se há nulo antes de excluir são simplesmente redundantes:

if ( ptr ) {
   delete ptr;
}

Observe, no entanto, que a null check é necessária quando você exclui uma matriz - isso ocorre porque um compilador relativamente recente no Solaris não lida com isso adequadamente.

Ao excluir um ponteiro, certifique-se de defini-lo também como 0, para que futuras tentativas de excluir esse objeto não falhem em uma exclusão dupla. Portanto, a maneira completa e adequada é:

delete ptr; 
ptr = 0;

Você pode perceber que ponteiros nulos são variavelmente marcados em uma das quatro maneiras: 0, 0L, NULL e nullptr. Em C, NULL é definido como um ponteiro void. No C ++, é possível maior segurança devido a uma verificação mais rigorosa de tipo. As implementações modernas do C++11 (e todas as implementações do C++14) definem NULL para igual ao valor especial nullptr. Nullptr pode ser convertido automaticamente para booleano false, mas uma conversão para um tipo inteiro falhará. Isso é útil para evitar acidentes. As implementações mais antigas do C++ anteriores ao c++11 simplesmente definiam NULL como 0L ou 0, o que não fornece segurança de tipo adicional - é possível atribuí-lo a uma variável inteira, o que está obviamente errado. Para código que não precisa suportar compiladores desatualizados, a melhor opção é nullptr.

No contexto de ponteiro, a constante inteira zero significa "ponteiro nulo" - independentemente da representação binária real de um ponteiro nulo. Observe, no entanto, que se você deseja passar uma constante de ponteiro nulo para uma função em uma lista de variáveis como argumentos, você *deve* convertê-la explicitamente em um ponteiro - o compilador assume o contexto inteiro por padrão, o que pode ou não corresponder a representação binária de um ponteiro.

Variáveis membro

Você encontrará quatro estilos principais de marcação de variáveis membro de classe no KDE, além de membros não marcados:

• m_variable m minúsculo, sublinhado e o nome da variável começando com uma letra minúscula. Este é o estilo mais comum e o preferido para o código no kdelibs.

• mVariable m minúsculo e o nome da variável iniciada com uma letra maiúscula

• variable_ nome da variável começando com uma letra minúscula e, em seguida, um sublinhado

• _variable sublinhado e o nome da variável começando com uma letra minúscula. Esse estilo geralmente é desaprovado, pois essa notação também é usada em algum código para parâmetros de função.

Membros não marcados são mais comuns no caso de classes que usam d-pointers.

Como muitas vezes acontece, não há uma maneira correta de fazer; lembre-se de sempre seguir a sintaxe usada pelo aplicativo/biblioteca com a qual você está se comprometendo. Se você estiver criando um novo arquivo, siga o estilo de codificação da biblioteca ou módulo ao qual está adicionando o arquivo.

Observe que os símbolos que começam com sublinhados são reservados para a biblioteca C (sublinhado seguido por Maiúscula ou sublinhado duplo são reservados ao compilador); portanto, se você puder, evite usar o último tipo.

Variáveis estáticas

Tente limitar o número de variáveis estáticas usadas no seu código, especialmente ao comitar para uma biblioteca. A construção e a inicialização de um grande número de variáveis estáticas realmente prejudicam os tempos de inicialização.

Não use variáveis estáticas de classe, especialmente em bibliotecas e módulos carregáveis, mesmo que isso seja desencorajado em aplicativos. Objetos estáticos levam a muitos problemas, como falhas difíceis de depurar devido a ordem indefinida de construção/destruição.

Em vez disso, use um ponteiro estático, junto com K_GLOBAL_STATIC, definido em kglobal.h e usado da seguinte forma:

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);
}

Consulte a API documentation para K_GLOBAL_STATIC para obter mais informações.

dados Constantes

Se você precisar de alguns dados constantes do tipo de dado simples em vários locais, faça melhor definindo-os uma vez em um local central, para evitar um erro de digitação em uma das instâncias. Se os dados mudarem, também há apenas um lugar que você precisa editar.

Mesmo que exista apenas uma instância, você faz bem definindo-o em outro lugar, para evitar os chamados "números mágicos" no código que são inexplicáveis (cf. 42). Geralmente, isso é feito na parte superior de um arquivo para evitar procurá-lo.

Defina os dados constantes usando os construtores da linguagem C ++, não as instruções do pré-processador, como você pode estar acostumado a partir do C puro. Dessa maneira, o compilador pode ajudá-lo a encontrar erros fazendo a verificação de tipo.

// Correct!
static const int AnswerToAllQuestions = 42;
// Wrong!
#define AnswerToAllQuestions 42

Se definir uma matriz constante, não use um ponteiro como tipo de dados. Em vez disso, use o tipo de dados e anexe à matriz o símbolo com comprimento indefinido, [] , atrás do nome. Caso contrário, você também define uma variável para alguns dados const. Essa variável pode ser atribuída por engano a um novo ponteiro, sem que o compilador se queixe. E ao acessar a matriz teria um engano, porque primeiro o valor da variável precisa ser lido.

// Correct!
static const char SomeString[] = "Example";
// Wrong!
static const char* SomeString = "Example";
// Wrong!
#define SomeString "Example"

Declarações Forward

Você reduzirá o tempo de compilação ao declarar classes forward quando possível, em vez de incluir seus respectivos cabeçalhos. As regras para quando um tipo pode ser usado sem ser definido são um pouco sutis, mas intuitivamente, se o único aspecto importante é o nome da classe, não os detalhes de sua implementação, uma declaração forward é permitida. São dois exemplos ao declarar ponteiros para a classe ou ao usar a classe como argumento de função.

Por exemplo:

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

O trecho acima deve ser escrito assim:

class QWidget;     // fast
class QStringList; // fast
class QString;     // fast
class QIcon;      // fast
class SomeClass
{
public:
    virtual void widgetAction( QWidget *widget ) =0;
    virtual void stringAction( const QString& str ) =0;
    virtual void stringListAction( const QStringList& strList ) =0;
private: 
    QIcon *icon;
};

Iteração

Preferir iteradores const e cache end()

Prefira usar const_iterators sobre iteradores normais, quando possível. Os contêineres que estão sendo compartilhados implicitamente geralmente são desconectados quando é feita uma chamada para um método non-const begin() ou end() (QList um exemplo desse contêiner). Ao usar um const_iterator, observe também que você está realmente chamando a versão const de begin() e end(). A menos que seu contêiner seja realmente const, provavelmente não será esse o caso, possivelmente causando uma desconexão desnecessária do contêiner. Então, basicamente, sempre que você usa const_iterator, inicialize-os usando constBegin()/ constEnd() em vez disso, para estar seguro.

Cache the return of the end() (or constEnd()) method call before doing iteration over large containers. For example:

QList<SomeClass> container;

//code which inserts a large number of elements to the container

QList<SomeClass>::ConstIterator end = container.constEnd();
QList<SomeClass>::ConstIterator itr = container.constBegin();

for ( ; itr != end; ++itr ) {
    // use *itr (or itr.value()) here
}

This avoids the unnecessary creation of the temporary end() (or constEnd()) return object on each loop iteration, largely speeding it up.

When using iterators, always use pre-increment and pre-decrement operators (i.e., ++itr) unless you have a specific reason not to. The use of post-increment and post-decrement operators (i.e., itr++) cause the creation of a temporary object.

Take care when erasing elements inside a loop

When you want to erase some elements from the list, you maybe would use code similar to this:

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);
    }
}

This code will potentially crash because it is a dangling iterator after the call to erase(). You have to rewrite the code this way:

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

This problem is also discussed in the Qt documentation for QMap::iterator but applies to all Qt iterators

memory leaks

A very "popular" programming mistake is to do a new without a delete like in this program: mem_gourmet.cpp

class t
{
    public:
      t() {}
};

void pollute()
{
    t* polluter = new t();
}

int main()
{
    while (true) pollute();
}

You see, pollute() instantiates a new object polluter of the class t. Then, the variable polluter is lost because it is local, but the content (the object) stays on the heap. I could use this program to render my computer unusable within 10 seconds.

To solve this, there are the following approaches:

• keep the variable on the stack instead of the heap:

t* polluter = new t();

would become

 
t polluter;

• delete polluter using the complementing function to new:

 
delete polluter;

• stop the polluter in an [1] (which will automatically delete the polluter when returning from the method)

 std::unique_ptr<t> polluter = new t();

There's also std::shared_ptr and QSharedPointer. This is the generally preferred way to do it in modern C++; explicit memory management should be avoided when possible.

Qt code involving QObject generally uses parent/child relations to free allocated memory; when constructing a QObject (e.g. a widget) it can be given a parent, and when the parent is deleted it deletes all its children. The parent is also set when you add a widget to a layout, for example.

A tool to detect memory leaks like this is Valgrind.

dynamic_cast

You can only dynamic_cast to type T from type T2 provided that:

• T is defined in a library you link to (you'd get a linker error if this isn't the case, since it won't find the vtable or RTTI info)

• T is "well-anchored" in that library. By "well-anchored" I mean that the vtable is not a COMMON symbol subject to merging at run-time by the dynamic linker. In other words, the first virtual member in the class definition must exist and not be inlined: it must be in a .cpp file.

• T and T2 are exported

For instance, we've seen some hard-to-track problems in non-KDE C++ code we're linking with (I think NMM) because of that. It happened that:

• libphonon loads the NMM plugin

• NMM plugin links to NMM

• NMM loads its own plugins

• NMM's own plugins link to NMM

Some classes in the NMM library did not have well-anchored vtables, so dynamic_casting failed inside the Phonon NMM plugin for objects created in the NMM's own plugins.

Program Design

In this section we will go over some common problems related to the design of Qt/KDE applications.

Delayed Initialization

Although the design of modern C++ applications can be very complex, application windows can be loaded and displayed to the user very quickly through the technique of delayed initialization. This technique is relatively straightforward and useful at all stages of an interactive program.

First, let us look at the standard way of initializing a KDE application:

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();
}

Notice that window is created before the a.exec() call that starts the event loop. This implies that we want to avoid doing anything non-trivial in the top-level constructor, since it runs before we can even show the window.

The solution is simple: we need to delay the construction of anything besides the GUI until after the event loop has started. Here is how the example class MainWindow's constructor could look to achieve this:

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

void MainWindow::initGUI()
{
    /* Construct your widgets here.  Note that the widgets you
     * construct here shouldn't require complex initialization
     * either, or you've defeated the purpose.
     * All you want to do is create your GUI objects and
     * QObject::connect
     * the appropriate signals to their slots.
     */
}

void MainWindow::initObject()
{
    /* This slot will be called as soon as the event loop starts.
     * Put everything else that needs to be done, including
     * restoring values, reading files, session restoring, etc here.
     * It will still take time, but at least your window will be
     * on the screen, making your app look active.
     */
}

Using this technique may not buy you any overall time, but it makes your app seem quicker to the user who is starting it. This increased perceived responsiveness is reassuring for the user as they get quick feedback that the action of launching the app has succeeded.

When (and only when) the start up can not be made reasonably fast enough, consider using a KSplashScreen.

Data Structures

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.

Passing non-POD types

Non-POD ("plain old data") types should be passed by const reference if at all possible. This includes anything other than the basic types such as char and int.

Take, for instance, QString. They should always be passed into methods as const QString&. Even though QString is implicitly shared it is still more efficient (and safer) to pass const references as opposed to objects by value.

So the canonical signature of a method taking QString arguments is:

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

QObject

If you ever need to delete a QObject derived class from within one of its own methods, do not ever delete it this way:

delete this;

This will sooner or later cause a crash because a method on that object might be invoked from the Qt event loop via slots/signals after you deleted it.

Instead always use QObject::deleteLater() which tries to do the same thing as delete this but in a safer way.

Empty QStrings

It is common to want to see if a QString is empty. Here are three ways of doing it, the first two of which are correct:

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

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

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

While there is a distinction between "null" QStrings and empty ones, this is a purely historical artifact and new code is discouraged from making use of it.

QString and reading files

If you are reading in a file, it is faster to convert it from the local encoding to Unicode (QString) in one go, rather than line by line. This means that methods like QIODevice::readAll() are often a good solution, followed by a single QString instantiation.

For larger files, consider reading a block of lines and then performing the conversion. That way you get the opportunity to update your GUI. This can be accomplished by reentering the event loop normally, along with using a timer to read in the blocks in the background, or by creating a local event loop.

While one can also use qApp->processEvents(), it is discouraged as it easily leads to subtle yet often fatal problems.

Reading QString from a KProcess

KProcess emits the signals readyReadStandard{Output|Error} as data comes in. A common mistake is reading all available data in the connected slot and converting it to QString right away: the data comes in arbitrarily segmented chunks, so multi-byte characters might be cut into pieces and thus invalidated. Several approaches to this problem exist:

• Do you really need to process the data as it comes in? If not, just use readAllStandard{Output|Error} after the process has exited. Unlike in KDE3, KProcess is now able to accumulate the data for you.

• Wrap the process into a QTextStream and read line-wise. This should work starting with Qt 4.4.

• Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. Example code

QString e QByteArray

While QString is the tool of choice for many string handling situations, there is one where it is particularly inefficient. If you are pushing about and working on data in QByteArrays, take care not to pass it through methods which take QString parameters; then make QByteArrays from them again.

For example:

QByteArray myData;
QString myNewData = mangleData( myData );

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

The expensive thing happening here is the conversion to QString, which does a conversion to Unicode internally. This is unnecessary because, the first thing the method does is convert it back using toLatin1(). So if you are sure that the Unicode conversion is not needed, try to avoid inadvertently using QString along the way.

The above example should instead be written as:

QByteArray myData;
QByteArray myNewData = mangleData( myData );

QByteArray mangleData( const QByteArray& data )

QDomElement

When parsing XML documents, one often needs to iterate over all the elements. You may be tempted to use the following code for that:

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

That is not correct though: the above loop will stop prematurely when it encounters a QDomNode that is something other than an element such as a comment.

The correct loop looks like:

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