Development/Tutorials/Common Programming Mistakes (ko)

Development/Tutorials/Common Programming Mistakes

일반적인 프로그래밍 실수들

Tutorial Series	Getting Started
Previous	None
What's Next	n/a
Further Reading	n/a

개요

이 튜트리얼은 Qt와 KDE 프레임워크가 수행하고 수행하지 않는 것에 관하여 KDE 개발자들의 경험을 접목시키는 것을 목적으로 한다. 또 실제의 실수 이외에, "버그"는 아니지만 코드를 더 느리게 하거나 읽기 어렵게 만드는 것들을 포함한다.

This tutorial aims to combine the experience of KDE developers regarding Qt and KDE frameworks dos and don'ts. Besides actual mistakes, it also covers things which are not necessarily "bugs" but which make the code either slower or less readable.

일반적인 C++

이 섹션은 오용하는 경향이 있거나 자주 간단히 잘못을 경험하는 C++의 좀 재미없는 섹션을 통하여 당신을 안내한다.

This section guides you through some of the more dusty corners of C++ which either tend to be misused or which people often simply get wrong.

익명의 namespaces vs statics

만약 클래스에서 어떠한 멤버에도 접근하지 않으며, 그래서 오브젝트를 조작할 필요가 없는 메쏘드 하나를 가지고 있다면, 이것을 static으로 만들어라.추가적이로 이것이 파일의 외부에서 필요 없는 private helper 함수라면, 이것을 file-static 함수로 만들어라. 이것은 심볼을 완벽하게 숨겨준다.

If you have a method in a class that does not access any members and therefore does not need an object to operate, make it static. If additionally it is a private helper function that is not needed outside of the file, make it a file-static function. That hides the symbol completely.

익명의 namespace 안에 정의된 심불들은 내부 연결을 가지고 있지 않다. 익명의 namespace들은 translation unit과 심볼의 연결을 전혀 변경하지 않기 위해 unique한 이름을 제공한다. 연결은 변경되지 않는다. 왜냐하면 lookup이라는 두 단계 중 두번째 단계가 내부 연결로 함수들을 무시하기 때문이다. 또한 내부 연결에서 엔티티들은 템플릿 인자로서 사용되어질수 없다.

Symbols defined in a C++ anonymous namespace do not have internal linkage. Anonymous namespaces only give a unique name for that translation unit and that is it; they do not change the linkage of the symbol at all. Linkage is not changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments.

그러므로 export될 심볼을 원하지 않는다면, 익명의 namespace 대신 static을 사용하라.

So for now instead of using anonymous namespaces use static if you do not want a symbol to be exported.

NULL pointer issues

First and foremost: it is fine to delete a null pointer. So constructs like this that check for null before deleting are simply redundant:

if ( ptr ) {

  delete ptr;

}

Note however, that a null check is required when you delete an array - that's because a relatively recent compiler on Solaris does not handle it properly otherwise.

When you delete a pointer, make sure you also set it to 0 so that future attempts to delete that object will not fail in a double delete. So the complete and proper idiom is:

delete ptr; ptr = 0;

You may notice that null pointers are marked variously in one of three ways: 0, 0L and NULL. In C, NULL is defined as a null void pointer. However, in C++, this is not possible due to stricter type checking. Therefore, modern C++ implementations define it to a "magic" null pointer constant which can be assigned to any pointer. Older C++ implementations, OTOH, simply defined it to 0L or 0, which provides no additional type safety - one could assign it to an integer variable, which is obviously wrong.

In pointer context, the integer constant zero means "null pointer" - irrespective of the actual binary representation of a null pointer. This means that the choice between 0, 0L and NULL is a question of personal style and getting used to something rather than a technical one - as far as the code in KDE's SVN goes you will see 0 used more commonly than NULL.

Note, however, that if you want to pass a null pointer constant to a function in a variable argument list, you *must* explicitly cast it to a pointer - the compiler assumes integer context by default, which might or might not match the binary representation of a pointer. Again, it does not matter whether you cast 0, 0L or NULL, but the shorter representation is generally preferred.

Member variables

You will encounter four major styles of marking class member variables in KDE:

m_variable lowercase m, underscore and the name of the variable starting with a lowercase letter. This is the most common style and one prefered for code in kdelibs.
mVariable lowercase m and the name of variable starting with a uppercase letter
variable_ variable name starting with a lowercase letter and then an underscore
_variable underscore and the name of variable starting with a lowercase letter. This style is actually usually frowned upon as this notation is also used in some code for function parameters instead.

As it often happens there is not one correct way of doing it, so remember to always follow the syntax used by the application/library to which you are committing.

Static variables

Try to limit the number of static variables used in your code, especially when committing to a library. Construction and initialization of large number of static variables really hurts the startup times.

Do not use class-static variables, especially not in libraries and loadable modules though it is even discouraged in applications. Static objects lead to lots of problems such as hard to debug crashes due to undefined order of construction/destruction.

Instead, use a static pointer, together with K_GLOBAL_STATIC which is defined in kglobal.h and is used like this:

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

}

See the API documentation for K_GLOBAL_STATIC for more information.

Forward Declarations

You will reduce compile times by forward declaring classes when possible instead of including their respective headers. For example:

include <QWidget>     // slow
include <QStringList> // slow
include <QString>     // slow

class SomeInterface
{
public:

   virtual void widgetAction( QWidget *widget ) =0;
   virtual void stringAction( const QString& str ) =0;
   virtual void stringListAction( const QStringList& strList ) =0;

};

The above should instead be written like this:

class QWidget; // fast class QStringList; // fast class QString; // fast class SomeInterface { public:

   virtual void widgetAction( QWidget *widget ) =0;
   virtual void stringAction( const QString& str ) =0;
   virtual void stringListAction( const QStringList& strList ) =0;

};

Iterators

Prefer to use const_iterators over normal iterators when possible. Containers, which are being implicitly shared often detach when a call to a non-const begin() or end() methods is made (List is an example of such a container). When using a const_iterator also watch out that you are really calling the const version of begin() and end(). 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.

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

QValueList<SomeClass> container;

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

QValueListConstIterator end( container.end() );

for ( QValueListConstIterator itr( container.begin() );

    itr != end; ++itr ) {

}

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

Prefer to use pre-increment over post-increment operators on iterators as this avoids creating an unnecessary temporary object in the process.

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()) {

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

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

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, one recurring problem, which is generally easy to fix, is not using the technique of delayed initialization.

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.
Accumulate data chunks in the slots and process them each time a newline arrives or after some timeout passes. Example code
Wrap the process into a QTextStream and read line-wise. While this should work in theory, it does not work in practice currently.

QString and 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;
   }
   ...

}