Shadoware.Org - Mot-clé - qmake

[C++/Qt] CMake et Qt

Ulrich Van Den Hekke — Sun, 26 Jun 2011 14:41:00 +0200

Suite à un billet datant de 2008, je reviens vers vous pour ajouter quelques précisions sur la compilation de programme Qt avec CMake. En effet, pour mon programme XINX, j'ai modifié la chaîne de compilation actuelle utilisant QMake par une chaîne de compilation CMake.

CMake est un puissant générateur de Makefile, il permet de remplacer les anciens (mais pas complètement révolus) autotools. CMake ne remplace donc pas le programme make mais vient se placer en amont.

CMake permet de compiler un programme à différents endroits du dossier des sources, ce qui permet de garder le répertoire des sources propre.

Nous allons considérer dans la suite le dossier projet suivant :

projet
- source
- build

Compilation

Nous passerons sous silence la compilation d'un programme non Qt qui peut être retrouvé dans la documentation et nous nous limiterons aux explications liées aux programmes écrits en ''Qt' (qui peuvent également être retrouvés dans d'autres tutoriels sur Internet).

Package à utiliser

Pour utiliser Qt4 avec CMake, il faut inclure le package Qt4 :

project(lenomdemonprojet) 
cmake_minimum_required(VERSION 2.8.0)
find_package(Qt4 REQUIRED)

Définir les modules Qt à utiliser :

Il est ensuite possible d'activer ou de désactiver les différents modules de Qt à utiliser suivant le programme que vous écrivez :

set(QT_DONT_USE_QTCORE TRUE)
set(QT_DONT_USE_QTGUI TRUE)
set(QT_USE_QT3SUPPORT TRUE)
set(QT_USE_QTASSISTANT TRUE)
set(QT_USE_QAXCONTAINER TRUE)
set(QT_USE_QAXSERVER TRUE)
set(QT_USE_QTDESIGNER TRUE)
set(QT_USE_QTMOTIF TRUE)
set(QT_USE_QTMAIN TRUE)
set(QT_USE_QTNETWORK TRUE)
set(QT_USE_QTNSPLUGIN TRUE)
set(QT_USE_QTOPENGL TRUE)
set(QT_USE_QTSQL TRUE)
set(QT_USE_QTXML TRUE)
set(QT_USE_QTXMLPATTERNS TRUE)
set(QT_USE_QTWEBKIT TRUE)
set(QT_USE_QTSVG TRUE)
set(QT_USE_QTTEST TRUE)
set(QT_USE_QTUITOOLS TRUE)
set(QT_USE_QTDBUS TRUE)
set(QT_USE_QTSCRIPT TRUE)
set(QT_USE_QTASSISTANTCLIENT TRUE)
set(QT_USE_QTHELP TRUE)
set(QT_USE_PHONON TRUE)

Par exemple pour faire un programme utilisant le module Xml, XmlPatterns, et Webkit il faut ajouter :

set(QT_USE_QTXML TRUE)
set(QT_USE_QTXMLPATTERNS TRUE)
set(QT_USE_QTWEBKIT TRUE)

Quelques déclarations supplémentaires

Après avoir compilé les différentes parties du programme avec le générateur de Makefile de Qt (QMake), j'ai relevé les différentes définitions à ajouter lors de la compilation. De plus une fois les modules définis, il faut inclure également le module UseQt4.

add_definitions(-DUNICODE)
# Les Q_ASSERT, Q_ASSERT_X, ... sont désactivés en mode Release
if(CMAKE_BUILD_TYPE STREQUAL "Release")
	add_definitions(-DQT_NO_DEBUG)
endif()
 
# Include utilisé par Qt (du style include (UseQt4))
include(${QT_USE_FILE})
# Ajoute les définitions propres à Qt (suivant les modules ajoutés)
add_definitions(${QT_DEFINITIONS})

Macros pour générer les fichiers `moc`.

Macro par défaut

La facilité de programmation en Qt est due à l'ajout par le framework de la notion de méta-objet. Cette notion se fait à l'aide d'un générateur propre à ce framework : moc^[1].

Pour générer les méta-objets, il faut définir sur les objets descendants de QObject, une macro Q_OBJECT. Cette macro ajoute, côté interface, la déclaration de méthodes supplémentaires pour la gestion des méta-informations, et coté implémentation, ajoute l'implémentation de ces méta-informations ainsi que la déclaration des signaux et de slots de l'objet^[2].

Pour générer les fichiers d'implémentation générés par le compilateur moc, il est possible d'utiliser la macro suivante pour une liste de fichier sources (extension .cpp, ou .cxx, ...) :

qt4_wrap_cpp(outfiles inputfile ... OPTIONS ...)

Cette macro générera un fichier de type moc_nomfichier.cxx qu'il faudra inclure dans le ficher CPP (car il n'est pas inclus automatiquement dans la liste des fichiers à compiler.

#include "moc_nomfichier.cxx"

Une autre macro

Autre possibilité, faire comme avec les fichiers .pro de QMake et générer un fichier moc pour chaque fichier .h possédant une macro Q_OBJECT. Pour cela j'ai écrit la petite macro suivante :

macro(xinx_automoc outfiles)
  qt4_get_moc_flags(moc_flags)
  qt4_extract_options(moc_files moc_options ${ARGN})
 
  foreach (it ${moc_files})
    get_filename_component(it ${it} ABSOLUTE)
 
    if ( EXISTS ${it} )
		file(READ ${it} _contents)
 
		string(REGEX MATCHALL "Q_OBJECT" _match "${_contents}")
		if(_match)
			qt4_make_output_file(${it} moc_ cxx outfile)
			qt4_create_moc_command(${it} ${outfile} "${moc_flags}" "${moc_options}")
			macro_add_file_dependencies(${it} ${outfile})
			set(${outfiles} ${${outfiles}} ${outfile})
		endif(_match)
    endif ( EXISTS ${it} )
  endforeach(it)
endmacro(xinx_automoc)

Elle s'utilise ainsi :

xinx_automoc(moc_headers ${headers})

Macro pour générer les fichiers en tête d'interface graphique.

Les interfaces graphiques sont développées à l'aide de Qt-Designer. Ces fichiers sont au format XML.

La macro CMake suivante permet de transformer ces fichiers XML en fichier d'entête C.

qt4_wrap_ui(outfiles inputfile ...)

Macro pour compiler les fichiers de resources

La macro CMake suivante permet de compiler le fichier de ressource (extension *.qrc) en fichier cpp qui sera ensuite compilé avec le reste du programme :

qt4_add_resources(outfiles inputfile ... OPTIONS ...)

Macro pour compiler les fichiers de traduction

La macro CMake suivante est utilisée pour compiler un fichier de traduction ts en fichier de traduction compilé qm. Ce dernier est ensuite à inclure dans le programme (soit par un fichier de ressource, soit dans un dossier à coté).

qt4_add_translation(qm_files ts_files ...)

Compilation d'un plugin

En plus des options décrites ci-dessus, pour compiler un plugin, il faut ajouter quelques définitions supplémentaires.

Il faut bien faire attention à ce que le plugin soit compilé en mode Release si le programme l'est aussi (Ce qui n'est pas forcément pratique pour faire du debug).

Plugin dynamique

add_definitions(-DQT_PLUGIN)
add_definitions(-DQT_SHARED)
add_library(webplugin SHARED ${webplugin_SRCS} ${webplugin_MOC_SRCS})

Plugin Static

add_definitions(-DQT_PLUGIN)
add_definitions(-DQT_STATICPLUGIN)
if(CMAKE_SIZEOF_VOID_P MATCHES 8)
	add_definitions(-fPIC)
endif()
add_library(webplugin STATIC ${webplugin_SRCS} ${webplugin_MOC_SRCS})

Ajout d'un fichier RC pour windows

Les fichiers RC Windows contiennent des informations, comme par exemple, la version et le nom du programme.

Ces informations peuvent être utilisées par les programmes d'installation sous Windows ou aussi par Windows lui-même.

Afin de pouvoir ajouter un fichier RC file au programme, on peut ajouter ceci :

if(MINGW)
	set(CMAKE_RC_COMPILER_INIT windres)
	enable_language(RC)
	set(CMAKE_RC_COMPILE_OBJECT "<CMAKE_RC_COMPILER> <FLAGS> <DEFINES> -O coff -o <OBJECT> <SOURCE>")
endif(MINGW)

Ensuite le fichier RC se compile comme tout autre fichier (C++, ...)

Compilation d'une librairie static

add_definitions(-DQT_SHARED)
add_library(xinxplugins STATIC ${xinxplugins_SRCS} ${xinxplugins_MOC_SRCS})

Utiliser le programme CMake

Une fois le programme configuré, il est possible de compiler ce dernier à l'aide des commandes suivantes :

mkdir build
cd build
 
cmake ../sources
 
make
make install

Sous Windows, il est possible de compiler en utilisant MinGW pour compiler ou d'utiliser le compilateur de Visual Studio.

Il est également possible de définir un emplacement pour l'installation différent du dossier par défaut :

cmake -DCMAKE_INSTALL_PREFIX=/home/login/usr/

Notes

[1] C'est ce qui fait tout l'avantage de Qt mais est aussi son inconvénient car il ajoute une couche supplémentaire. C'est ensuite une question de goût.

[2] facilitant la gestion des évènements dans Qt

[C++/Qt] Performance de l'utilisation de QSharedPointer

Ulrich Van Den Hekke — Tue, 25 Jan 2011 12:00:00 +0100

Présentation

Qt est un framework orienté objet écrit en C++ et permettant de faire des interfaces graphiques. Ce framework est utilisé par le projet KDE depuis ses débuts pour en faire un environnement de bureau très complet.

Qt fournit un ensemble de pointeur intelligent^[1] permettant de gérer plus facilement la mémoire. Le but est alors de ne plus avoir à supprimer des objets. La suppression se fera soit par un pointeur intelligent soit par le système de hiérarchie d'objet existant en Qt (l'objet père qui supprime l'ensemble des objets fils qui lui sont rattachés).

Qt propose l'ensemble des pointeurs intelligents suivants:

QSharedDataPointer / QSharedData : ces deux classes utilisées ensemble permettent d'écrire un objet avec partage implicite. Cela signifie que l'objet fonctionnera comme la classe QString. Tant que l'objet est copié, passé en paramètre, .... l'objet n'est pas dupliqué (tous les objets pointes vers le même espace mémoire). Au moment où l'objet est modifié, l'objet est dupliqué. C'est ce qu'on appelle le COW^[2].
QExplictlySharedDataPointer / QSharedData : QExplicitlySharedDataPointer est une variante de QSharedDataPointer. Ce pointeur intelligent, comme son nom l'indique, est détaché uniquement lorsque la méthode detach() est appelée explicitement. Cette classe permet de faire des objets qui fonctionnent comme des pointeurs mais qui sont utilisés sans la notion de pointeur (le *). La suppression des données partagées se fait donc quand tous les objets ne sont plus utilisés.
QScopedPointer : Ce pointeur est le plus simple. Il permet de déclarer un pointeur sur le tas et s'occupe de la destruction de l'objet, lorsque le programme sort de la portée du bloc. Cela permet de ne plus se soucier de la libération du pointeur dans les cas d'erreur (exception, retour avant la fin de la fonction car le fichier n'a pu être ouvert, ...).
QSharedPointer : Le pointeur dont on parlera dans la suite de ce billet. Il permet de partager non plus des données (comme le fait QSharedData) mais de partager un pointeur^[3]. Nous allons voir dans la suite du billet, comment simplement utiliser ce pointeur, et les performances de ce pointeur par rapport à un pointeur standard.

Sommaire

Notes

[1] en anglais : smart-pointer

[2] COW = Copy On Write

[3] Ce pointeur est l'équivalent du pointeur intelligent boost::shared_ptr du projet Boost. Boost est une librairie qui ajoute beaucoup de facilité pour les programmes en C++, comme par exemple les smart-pointer dont certains seront inclus dans C++0x, ou de la boucle std::for_each.

Utilisation de QSharedPointer

A quoi sert-il ?

L'objet QSharedPointer fait partie des pointeurs intelligents. Ces pointeurs permettent de gérer automatiquement la libération de la mémoire (plus besoin de faire delete ptr; quand le pointeur n'est plus utilisé) tout en restant utilisable comme un pointeur normal.

QSharedPointer fonctionne par comptage de référence. Après la déclaration, à chaque affectation, on augmente le compteur de référence, lorsqu'on quitte la portée du bloc, on décrémente le compteur de référence. QSharedPointer détruit donc automatiquement le pointeur quand il n'existe plus aucune référence vers ce pointeur. QSharedPointer vient donc comme une encapsulation de notre pointeur.

Comment l'utiliser ?

La déclaration d'un pointeur en C, se fait en écrivant MyObject*. La syntaxe en utilisant un QSharedPointer se fait en écrivant QSharedPointer<MyObject>. Par la suite dans le programme, l'utilisation du pointeur QSharedObject se fera de la même manière qu'un pointeur C. (Avec l'opérateur -> pour appeler un membre, une méthode, ...) . Appelons dans la suite pointeur C, les pointeurs standards et QSharedPointer, le pointeur intelligent.

Afin d'éviter d'avoir un pointeur normal pouvant être supprimé à tout moment dans l'application, lors de l'utilisation de QSharedPointer, il ne faut utiliser le pointeur C résultant du new que pour la création du QSharedPointer. On peut donc directement créer le QSharedPointer en utilisant le constructeur QSharedPointer ( T * ptr ) qui prend en paramètre le pointeur C. C'est entre ces parenthèses que nous allons créer le pointeur C^[1].

{
  // Création du pointeur intelligent à partir d'un pointeur normal.
  QSharedPointer<MyObject> ptr(new MyObject());
 
  // Utilisation du pointeur intelligent comme un pointeur normal.
  if (ptr)
  {
    ptr->setMembre(maValeur);
  }
 
  // Appel d'une méthode utilisant ce pointeur
  maMethode(ptr);
}

Lorsque l'on quitte le bloc, si le comptage de référence tombe à 0, on supprime le pointeur. A l'intérieur de maMethode() le nombre de référence sera passé à 2. Si la méthode utilise le pointeur mais ne l'assigne nul part, le nombre de référence devrait être retombé à 1 et donc ici sera décrémenté à 0.

Si par contre, maMethode() fait des opérations d'assignation de ptr et conserve une copie, le comptage ne tombera pas à 0 tant que l'objet restera utilisé (assigné) ailleurs.

Regardons un exemple de maMethode() :

void maMethode(QSharedPointer<MyObject> ptr)
{
  ptr->setMembre2(maValeur);

Au début du bloc, ici le comptage de référence est à 2 et sera décrémenté à la sortie de la méthode. On peut modifier les membres de ptr, et dans ce cas pas de changement du comptage de référence.

this->monPtr = ptr;
}

Au contraire, on peut également l'assigner à un autre objet. Dans ce cas le comptage de référence de cet objet passera à 3. A la sortie de la méthode il sera décrémenté et passera alors à 2. L'objet ne sera pas supprimé tant qu'on ne fera pas un this->monPtr.clear() ou que this ne sera pas détruit.

Si on veut garder une référence d'un pointeur mais qu'on ne souhaite pas que celle-ci incrémente le nombre de référence du QSharedPointer, il est possible de créer un pointeur faible. Ce pointeur passe par l'objet QWeakPointer. Pour obtenir ce type de pointeur, il suffit de faire :

QWeakPointer<MyObject> ptrW = ptr->toWeakRef ();

ptrW n'incrémente donc pas le comptage de référence, cela signifie donc que le pointeur peut être détruit même si un objet QWeakPointer existe. Il sera alors possible de faire un ptrW.isNull() pour savoir si le pointeur est toujours valide. Si l'utilisateur a également besoin d'avoir accès à un membre de l'objet, il pourra le transformer en QSharedPointer avant de l'utiliser sauf si le pointeur est null.

QSharedPointer<MyObject> ptr2 = ptrW->toStrongRef ();
if (ptr) 
{
   ptr->maMethodePtr();
}

Il faut tester que ptr2 est encore valide, car tant que la transformation du pointeur faible vers le QSharedPointer n'a pas encore été fait, il est possible que le nombre de référence vers l'objet soit tombé à 0 et qu'il ait été supprimé.

Comment utiliser `this`

Un des points peu pratique de l'utilisation de QSharedPointer est que le comptage de référence ne fonctionne pas si plusieurs QSharedPointer pointent vers le même objet mais ont tous été créés à partir du pointeur C. Prenons par exemple, le cas suivant :

MyObject * ptr = new MyObject();
 
QSharedPointer<MyObject> ptr1 = QSharedPointer(ptr);
QSharedPointer<MyObject> ptr2 = QSharedPointer(ptr);

Le problème d'écrire ces lignes ainsi, et que pour ptr1 comme pour ptr2, l'objet n'est référencé qu'une fois. Ainsi le premier qui tombera à 0 détruira l'objet, alors que l'autre pourrait encore l'utiliser. Il faut donc écrire les choses comme suite :

QSharedPointer<MyObject> ptr1 = QSharedPointer(new MyObject());
QSharedPointer<MyObject> ptr2 = ptr1;

Ainsi ptr1 et ptr2 ont bien chacun connaissance de l'existence de l'autre. Cela contraint donc à remplacer toutes les déclarations du type MyObject* par QSharedPointer<MyObject>. Ceci est donc à faire dans les paramètres des méthodes, dans les membres, dans la déclaration des variables locales, ... . On ne peut donc plus utiliser le pointeur C MyObject* directement, mais seulement au travers de QSharedPointer ou de QWeakPointer.

Cela commence à poser problème lors de l'utilisation de this dans un objet. Imaginons une méthode d'un objet mettant à jour des membres fils avec en paramètre le père. Nous aurions alors tendance à écrire ceci :

void Object2::setParent(QSharedPointer<MyObject> parent)
{
...
}
 
....
 
void MyObject::setMember(Object2 * obj)
{
  _membre = obj;
  if (obj)
  {
    obj->setParent(QSharedPointer<MyObject>(this));
  }
}

Ceci ne marchera pas car on créerait un nouvel objet QSharedPointer commençant son comptage de référence à 1, alors que nous en avons déjà au moins un autre pointant vers notre instance^[2]. MyObject pourrait alors être détruit alors qu'il est encore utilisé par Object2.

Pour éviter cela, il faut alors passer par un pointeur intelligent this. Pour cela nous allons utiliser deux choses :

Un membre nommé _this de type pointeur intelligent QWeakPointer, contenant une référence à l'objet lui même. (Nous n'utilisons pas un QSharedPointer, pour éviter une référence circulaire, voir le paragraphe suivant).
Une méthode statique utilisée pour la création (nous n'allons plus utiliser le constructeur, car à ce moment, il n'existe pas encore de QSharedPointer pointant vers notre objet).

Voici un exemple de comment écrire le constructeur maison :

class MyObject
{
public:
  static QSharedPointer<MyObject> create(QString parametre)
  {
    QSharedPointer<MyObject> ptr(new MyObject(parametre);
    ptr->_this = ptr.toWeakRef();
    return ptr;
  }
private:
  MyObject(QString parametre)
  {
    ...
  }
 
  QWeakPointer<MyObject> _this;
};

Le constructeur devient alors privé (ou protégé si on a besoin de la notion d'héritage) afin d'obliger l'utilisateur de la classe à utiliser notre méthode de création. Dans notre nouvelle méthode de création create, qui est une méthode statique, nous allons créer le pointeur et initialiser le QWeakPointer de notre objet avec le pointeur intelligent que nous venons de créer. Nous retournons un QSharedPointer. La méthode create devient alors notre nouveau constructeur, mais créant des instances d'objets de type QSharedPointer<MyObject> et non plus des instances d'objet MyObject*.

Notre méthode setMember() peut alors être ré-écrite :

void MyObject::setMember(Object2 * obj)
{
  _membre = obj;
  if (obj)
  {
    obj->setParent(_this.toStrongRef());
  }
}

Comment éviter les références circulaires

Le principe d'une référence circulaire est qu'un objet A référence l'objet B et l'objet B référence l'objet A.

Voici par exemple, un cas de référence circulaire :

class A
{
public:
  static create()
  {
    QSharedPointer<A> ptr(new A());
    return ptr;
  }
  ~A()
  {
  }
private:
  A()
  {
    b = B::create();
    b->setA(_this);
  }
  QSharedPointer<B> b;
  QWeakPointer<A> _this;
};
 
class B
{
public:
  static QSharedPointer<B> create() 
  {
    QSharedPointer<B> ptr(new B());
    return ptr;
  }
  void setA(QSharedPointer<A> b);
  QSharedPointer<A> getA();
private:
  QSharedPointer<A>  a;
};

Cela peut-être aussi le cas, si par exemple une instance d'objet C référence des instances d'objets fils C, qui possèdent eux-même un pointeur vers l'objet C père.

class C
{
public:
  static QSharedPointer<C> create()
  {
    QSharedPointer<C> ptr(new C());
    _this = ptr.toWeakPtr();
    return ptr;
  }
 
  ~C()
  {
  }
 
  void addChild(QSharedPointer<C> c)
  {
    _childs.append(c);
    c->setParent(_this);
  }
 
  void setParent(QSharedPointer<C> c);
  QSharedPointer<C> getParent();
private:
  C()
  {
  }
 
  QWeakPointer<C> _this;
  QSharedPointer<C> _parent;
  QList< QSharedPointer<C> > _childs;
};

Dans ces cas là, on a : - L'objet A possède la référence vers l'objet B - L'objet B possède une référence vers l'objet A. - Même principe avec l'objet C

Dans ce cas, il restera alors toujours une référence vers A, et une vers B, même si plus aucune variable ne référence ces objets. Cette référence circulaire fait que l'objet ne sera jamais détruit même si on n'a plus besoin de l'objet.

Si on décide que l'objet A sera l'objet maitre (donc que sa destruction engendrera la destruction de l'objet B), on peut alors écrire les choses ainsi pour l'objet B :

class B
{
public:
  static QSharedPointer<B> create() 
  {
    QSharedPointer<B> ptr(new B());
    return ptr;
  }
  void setA(QWeakPointer<A> b);
  QWeakPointer<A> getA();
private:
  QWeakPointer<A>  a;
};

Dans ce cas, avec l'utilisation d'un QWeakPointer, lorsque qu'il n'existera plus de référence vers l'objet A, le pointeur faible a sera mis à jour comme ne contenant plus de référence^[3]. L'instance de l'objet A sera réellement détruite. Il n'y aura alors plus aucune référence vers l'objet B qui sera alors également détruit^[4].

Utilisation dans les applications multi-thread.

L'utilisation de QSharedPointer simplifie l'écriture des applications multi-thread (les objets QSharedPointer et QWeakPointer sont thread-safe).

Dans ces applications il n'y a alors plus besoin de se soucier si l'objet est en cours d'utilisation ailleurs dans l'application avant de le supprimer^[5]. Lorsqu'un pointeur ne devient plus utilisé dans un thread donné, il ne sera détruit que s'il n'y a pas d'autres références dans d'autres threads de l'application^[6].

Avec l'utilisation de QWeakPointer, un thread pourra tester l'existence du pointeur avant d'effectuer une opération et pourra aviser le cas échéant sans faire planter toute l'application^[7].

Utilisation d'un pool

Si la création et la destruction d'un objet est coûteux, il est envisageable de diminuer le coût de destruction et de création d'un thread en utilisant un Pool d'objet. Dans ce cas l'objet QQueue pourra être utilisé pour représenter notre Pool.

Lors de la demande de création, en utilisant notre méthode create ci-dessus, on prend alors une valeur du pool (si disponible) et on la retourne sous forme d'un QSharedPointer.

QSharedPointer<MyObject> MyObject::create()
{
  MyObject * c_ptr;
  if (_queue.size())
  {
	c_ptr = _queue.dequeue();
  }
  else
  { 
	c_ptr = new MyObject();
  }
  QSharedPointer<MyObject> ptr(c_ptr, ReturnToPool);
  ptr->_this = ptr.toWeakRef();
  return ptr;
}

Dans l'exemple ci-dessus^[8], on demande à la queue, qui doit être une variable globale ou statique, un élément, et si ce n'est pas possible, on crée un nouvel objet de type MyObject (dont on suppose la création coûteuse).

Lors de la création du QSharedPointer on utilise alors le constructeur QSharedPointer ( T * ptr, Deleter deleter ) sur lequel on définit une méthode Deleter nommée ReturnToPool dont le but est de remettre les objets en pool.

static void ReturnToPool(MyObject *obj)
{
  if (_queue.size() < MAX_SIZE_QUEUE)
  {
	_queue.enqueue(obj);
  }
  else
  {
	delete obj;
  }
}

Dans ce cas de retour au pool, si le pool est rempli, on détruit l'objet (pour éviter de consommer trop de mémoire), sinon on l'ajoute au pool. Dans ce cas, le pool est agrandi au fur et à mesure des besoins, jusqu'à une taille limite.

Bien sûr il faut que la performance de l'utilisation d'un pool soit plus intéressante que celle de la création de l'objet et de son initialisation.

Attention : Ce point ne fonctionne, par contre, pas si l'objet (MyObject) est un descendant de QObject. En effet QObject garde une référence du QSharedPointer en mémoire et lors de la réutilisation du QObject une erreur indique que l'objet n'a pas été détruit et est déjà utilisé par un QSharedPointer. On n'a pas le problème avec std::tr1::shared_ptr

Benchmark

Le but du benchmark est de se faire une idée sur les performances d'une application utilisant des QSharedPointer à la place des pointeurs normaux. Attention, ce bench ne prend pas en compte le besoin potentiel de Mutex, de comptage de référence manuel, ... dans les applications multi-thread qui pourrait être nécessaire pour ne pas supprimer le pointeur si besoin.

Dans ce test nous allons tester également (en comparaison), le pointeur intelligent du C++0x^[9].

Nous allons donc tester les opérations courantes de création, destruction, modification, affectation.

Code source

Le code source est disponible, attaché au billet. Dans la suite du billet, seuls les morceaux intéressants du benchmark seront décris. Le benchmark utilise QTest. Nous avons créé un objet bidon ObjetTest qui dans le constructeur allouera un pointeur et remplira une liste, et le destructeur supprime ce pointeur (et forcément la liste).

Pour que chaque test soit indépendant, le jeu de test sera initialisé avant le début de chaque QBENCHMARK et détruit à la fin du bloc. Nous aurons quatre méthodes :

Allocation
Modification
Affectation
Nettoyage

Pour chaque test nous allons faire le test avec

un pointeur C standard
le pointeur QSharedPointer de Qt
le pointeur std::tr1::shared_ptr de C++0x

Pour le test d'allocation et le test de nettoyage, nous allons également utiliser l'optimisation possible, vu ci-dessus, d'un Pool d'objet. Nous allons faire le test avec :

le pointeur QSharedPointer de Qt
le pointeur std::tr1::shared_ptr de C++0x

Le jeu de test

Test de l'allocation

La création du pointeur en utilisant QSharedPointer instancie le pointeur ainsi que le QSharedPointer. Le temps d'exécution est donc potentiellement deux fois plus long (voir le benchmark à la fin de ce billet).

Pour la création du pool, nous allons utiliser une méthode qui créera le pointeur s'il n'est pas dans le pool, et sinon prendra le pointeur du pool. Dans notre cas de test, il y aura toujours une valeur dans le pool, que l'on aura rempli au préalable.

La méthode createFromPool() et createFromBoostPool() est sensiblement identique :

QSharedPointer<ObjetTest> createFromPool()
{
        ObjetTest * c_ptr;
        if (_queue.size())
        {
          c_ptr = _queue.dequeue();
        }
        else
        {
          c_ptr = new ObjetTest();
        }
 
        QSharedPointer<ObjetTest> ptr(c_ptr, returnToPool);
        return ptr;
}

C Pointer
ObjetTest* ptr = new ObjetTest();
Qt Smart Pointer
QSharedPointer<ObjetTest> ptr(new ObjetTest());
Qt Smart Pointer as Pool
QSharedPointer<ObjetTest> ptr = createFromPool ();
C++0x Smart Pointer
std::tr1::shared_ptr<ObjetTest> ptr(new ObjetTest());
C++0x Smart Pointer as Pool
std::tr1::shared_ptr<ObjetTest> ptr = createFromBoostPool ();

Test de Modification d'une donnée

Pour la modification d'une donnée, on génère un nombre aléatoire que l'on va stocker (toujours le même pour chaque test, cela n'a pas d'importance). La génération du nombre aléatoire se fait en dehors du bloc, pour éviter de polluer le test avec le calcul d'un nombre aléatoire. Ici il n'y a pas création d'affectation du pointeur, juste une affectation d'une valeur dans le contenu du pointeur. La syntaxe pour le C, et pour le pointeur intelligent est identique.

C Pointer / Qt Smart Pointer / C++0x Smart Pointer
obj->value = random_number;

Test d'affectation

Pour l'affectation nous allons créer une nouvelle variable qui pointera sur le même pointeur, et sur lequel on fera une modification. La création d'un pointeur peut arriver par exemple lors du passage du pointeur à une fonction, ou lors de la déclaration d'une variable devant contenir la même valeur. Cette déclaration supplémentaire a peu d'impact pour un pointeur C mais pour un pointeur intelligent oblige la création d'un objet, et l'incrément d'un nombre d'instance (qu'on décrémente ici dans la même boucle).

C Pointer
ObjetTest * obj2 = obj; obj2->value = random_number;
Qt Smart Pointer
QSharedPointer<ObjetTest> obj2 = obj; obj2->value = random_number;
C++0x Smart Pointer
std::tr1::shared_ptr<ObjetTest> obj2 = obj; obj2->value = random_number;

Test de destruction

Pour ce test, nous allons initialiser une liste de pointeur, et pour le benchmark, nous allons supprimer un à un chaque élément de la liste. La destruction du pointeur en C se fait par un delete. Pour le pointeur ''intelligent', il n'y a pas de destruction explicite. Nous allons juste supprimer le pointeur de la liste, le pointeur sera alors automatiquement détruit car il n'y aura plus de référence vers ce pointeur.

Pour le cas de test utilisant la notion du Pool, on aura créé le pointeur avec le delete returnToPool() :

void returnToPool(ObjetTest *obj)
{
        _queue.enqueue(obj);
}

Cette méthode ne fait pas de réelle destruction, mais juste un ajout de l'objet au pool.

C Pointer
delete c_ptr_list.at(0); c_ptr_list.removeFirst ();
Qt Smart Pointer / Qt Smart Pointer as Pool / C++0x Smart Pointer / C++0x Smart Pointer as Pool
smart_ptr_list.removeFirst ();

Résultat du test

Le test a été fait en utilisant la version 4.6.3 de Qt. Test effectué pour 5 000 000 itérations.

	Pointeur C	Pointeur Qt	Pointeur C++0x	Pool en utilisant QSharedPointer	Pool en utilisant std::tr1::shared_ptr
Allocation	0.0004275 msec	0.0007692 msec	0.0006604 msec	0.0002590 msec	0.0002286 msec
Modification	0.000010 msec	0.000012 msec	0.000012 msec
Affectation	0.000010 msec	0.0000386 msec	0.0000230 msec
Destruction	0.000190 msec	0.0003161 msec	0.0003359 msec	0.0004003 msec	0.0003601 msec

Conclusion que l'on peut en tirer, le pointeur C est ce qu'il y a de plus rapide à partir du moment où on fait de l'allocation de l'affectation ou de la destruction. Par contre il n'apporte pas la souplesse qu'apporte les pointeurs intelligents entre autre pour les applications multi-threadé.

On remarque que le pointeur C++0x est plus rapide pour la création, mais apparemment plus lent en destruction. Il est également possible avec le pool de gagner en performance (surtout en création). Par contre le coût de destruction de l'objet n'est pas encore assez fort pour y gagner en utilisant le pool.

Ensuite il est important de se faire son propre jugement selon ses besoins. Si besoin le source est attaché, vous pouvez faire vos propres tests.

Notes

[1] Si à un moment donné il faut utiliser le pointeur C pour une raison quelconque, on peut utiliser ptr.data() mais il faut s'assurer que le pointeur ne sera pas détruit en déclarant un QSharedPointer dans le même bloc utilisant le pointeur C. Le QSharedPointer ne devra être détruit qu'après utilisation du pointeur C. Ceci peut être fait dans certain cas pour des raisons de performance.

[2] Sinon nous ne serions plus là pour lancer la méthode

[3] Le QWeakPointeur ne gardant pas d'instance d'objet, car il n'incrémente pas le compteur de référence

[4] s'il n'existe pas de référence vers l'objet B ailleurs dans l'application

[5] Attention quand même, QSharedPointer protège le pointeur mais pas le contenu

[6] d'autres threads pouvant inclure le thread principal

[7] Si l'objet est supprimé, QWeakPointer, sera alors remis à null

[8] Dans le code en question, il faudrait ajouter la notion de mutex autour de la gestion de la queue, en cas de création parallèle.

[9] Le pointeur intelligent shared_ptr de C++0x à pour origine le pointeur Boost

Qt 4.5 est sortie

Ulrich Van Den Hekke — Tue, 03 Mar 2009 16:42:00 +0100

Voilà quelques heures que la dernière version de Qt est sortie. Cette version, numéroté 4.5, est essentiellement orienté performance.

Elle contient entre autre ^[1]

Une mise à jour de QtWebKit vers un version de WebKit plus récente (avec un nouveau moteur JavaScript plus rapide, la possibilité d'ajouter des greffons comme Flash...). Il est également possible d'utiliser les balises d'HTML 5.
Amélioration des performances sur le moteur de rendu ainsi que sur le rendu du texte. Une librairie permettant de faire des tests de performance a été incluse : QtBenchLib.
Le support de Mac OS X Cocoa
La possibilité de faire des transformations XSLT
Un débuggeur QtScript^[2]

Le support du format OpenDocument (ODF version 1.0, ne supportant que le texte et les images)
Amélioration du support des proxys
Amélioration de QtDesigner, QtLinguist
Une meilleur intégration au thème Gtk

Cette nouvelle version apporte également une grande nouveauté puisqu'elle est LGPL. Il est donc désormais possible de faire une application propriétaire à l'aide de cette librairie sans prendre une licence chez Qt Software. Par contre si une entreprise souhaite un support pour la librairie, il faudra tout de même acheter une licence.

La sortie de Qt 4.5 est accompagné de Qt Creator 1.0. Qt Creator est l'outil dernier né de chez Qt Software (branche de Nokia) et est un IDE de développement de programme Qt. Un paquet est proposé contenant Qt, Qt Creator, ainsi que MinGW et permettant d'avoir une installation tout en un d'un poste de développement.

Vous pouvez donc aller télécharger la dernière version de Qt, ainsi que de Qt Creator (attention les serveurs sont surchargés) à cette adresse.

Je remercie toute l'équipe de nouvellement Qt Software de cette nouvelle version.

Notes

[1] pour plus de détail voir http://doc.trolltech.com/4.5/qt4-5-intro.html

[2] L'image du debugger viens du site Qt Software

Paquet Debian et Qt

Ulrich Van Den Hekke — Mon, 08 Sep 2008 20:45:00 +0000

A titre personnel je fabrique quelques programmes en Qt. Comme j'utilise un système Gnu/Debian, j'ai cherché à fabriquer des paquets pour mon système (plus pour le plaisir qu'autre chose, car la plus grande partie de mes utilisateurs sont sous MS/Windows).

Ce billet explique la création de paquet Gnu/Debian pour des applications Qt 4 utilisant QMake

Installation des paquets

Pour la création des paquets pour des programmes utilisant qmake, il faut cdbs, dh_make, dpkg-buildpackage.

aptitude install cdbs dh-make fakeroot devscripts

Création du paquet

Préparation

Vous pouvez donc choisir un de vos programmes que vous voulez empaqueter. Pour cela vous allez commencer par nettoyer l'arborescence de votre projet pour retirer les fichiers de sauvegarde ainsi que les fichiers de construction (*~ *.o, ...). Ce petit nettoyage va permettre d'avoir un paquet source propre.

Il faut que vous placiez les sources dans un dossier du nom de <programme>-<version>.

Voici un exemple de fichier projet :

TARGET = qgenconfig
TEMPLATE = app

CONFIG += exceptions warn_on qt
QT += xml

HEADERS += src/loadconfigimpl.h \
   src/setupfile.h \
   src/configfile.h \
   src/p_configfile.h
SOURCES += src/loadconfigimpl.cpp \
   src/setupfile.cpp \
   src/main.cpp \
   src/configfile.cpp
FORMS = ui/loadconfig.ui

DESTDIR = bin
MOC_DIR = build
OBJECTS_DIR = build
UI_DIR = build

Pour générer le Makefile, vous pouvez faire comme d'habitude :

qmake-qt4 qgenconfig.pro

Création des scripts

Pour créer les paquets, il faut un ensemble de script dans le dossier debian. Pour se faciliter la vie, il est possible de créer les scripts avec dh_make.

DEBFULLNAME="Ulrich Van Den Hekke" dh_make -e ulrich.vdh@shadoware.org -n -s -c gpl

Voici la description de la liste des paramètres :

DEBFULLNAME indique le nom du mainteneur.
-e Permet de préciser l'email (suivis de l'email).
-n Produit un paquet natif pour Gnu/Debian (quand l'auteur fait ses paquets lui-même).
-s Indique que le paquet ne va contenir qu'un simple exécutable (si vous voulez faire plusieurs paquets, il suffit de ne pas mettre cette option).
-c Indique la licence d'utilisation (ici gpl).

Vous pouvez ensuite supprimer les fichiers exemples (mais pas nécessairement si vous voulez les étudier).

rm debian/*.ex  debian/*.EX  debian/docs  debian/dirs

Paquet simple

Nous allons commencer par créer un paquet simple. Cela signifie qu'il n'y aura qu'un seul exécutable dans le paquet (pas de librairie, ...).

Dans le fichier control, il faut que vous renseignez les informations du paquet que vous allez créer.

Source: qgenconfig
Section: devel
Priority: extra
Maintainer: Ulrich Van Den Hekke <ulrich.vdh@shadoware.org>
Build-Depends: debhelper (>= 7)
Standards-Version: 3.7.3
Homepage: http://projects.shadoware.org/qgenconfig

Package: qgenconfig
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Create a config class in Qt after loading a XML file.
 Load an XML description file of a settings object and create a class
 that can be used to load and save information in a QSettings class. To
 load information structure are used.

Dans le paquet ci-dessus, on créait un paquet binaire et un paquet source. Les variables de dépendance (dans Depends) sont remplacées automatiquement à la génération du paquet. La description est celle écrite dans aptitude. La première ligne est la description courte, les suivantes (précédées d'un espace) sont la description longue.

Ensuite on va remplacer le fichier debian/rules en utilisant cdbs :

#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/qmake.mk
QMAKE=qmake-qt4
 
install/qgenconfig::
	mkdir $(DEB_DESTDIR)/usr/
	mkdir $(DEB_DESTDIR)/usr/bin/
	cp $(CURDIR)/bin/qgenconfig $(DEB_DESTDIR)/usr/bin/

En premier lieu on définit les variables pour la compilation, puis ensuite on définit les opérations d'installations dans la cible install/qgenconfig^[1]. Dans les opérations, vous allez copier votre exécutable dans le dossier de génération de debian (dossier debian/<cible>).

Paquet multiple

Créer plusieurs paquets à partir d'une même source avec cdbs est assez simple. Il suffit de rajouter des cibles, correspondantes au fichier control, dans le fichier rules .

Dans le fichier de control on va avoir plusieurs paquets binaires pour un seul paquet source.

Source: xinx
Section: devel
Priority: extra
Maintainer: Ulrich Van Den Hekke <xinx@shadoware.org>
Build-Depends: debhelper (>= 7)
Standards-Version: 3.7.3
Homepage: http://xinx.shadoware.org/

Package: xinx
Section: devel
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, xinx-scripts (>= 0.7.2.0)
Recommends: xinx-plugins-services, xinx-plugins-cvs, xinx-plugins-svn
Suggests: xinx-doc
Description: XSL/JS/HTML editor for Generix
 XINX is an editor of XSL stylesheet, JavaScript, Cascading Style Sheet.
 This editor is used with egx.

Package: xinx-doc
Section: doc
Architecture: all
Depends: xinx (>= 0.7.2.0)
Description: Documentation for xinx
 Technical Documentation of XINX

Nous allons définir dans le fichier rules les différentes cibles que nous avons dans le fichier control^[2].

#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/qmake.mk
QMAKE=qmake-qt4 project.pro
 
install/xinx::
	mkdir $(CURDIR)/debian/xinx/usr/
	mkdir $(CURDIR)/debian/xinx/usr/bin/
	cp $(CURDIR)/xinx/xinx $(CURDIR)/debian/xinx/usr/bin/
	cp $(CURDIR)/xinxprojectwizard/xinxprojectwizard $(CURDIR)/debian/xinx/usr/bin/
 
	mkdir $(CURDIR)/debian/xinx/usr/lib/
	cp -a $(CURDIR)/libxinx/libsharedxinx* $(CURDIR)/debian/xinx/usr/lib/
	cp -a $(CURDIR)/components/libxinxcmp* $(CURDIR)/debian/xinx/usr/lib/
 
install/xinx-doc::
	mkdir $(CURDIR)/debian/xinx-doc/usr/
	mkdir $(CURDIR)/debian/xinx-doc/usr/share/
	mkdir $(CURDIR)/debian/xinx-doc/usr/share/doc/
	mkdir $(CURDIR)/debian/xinx-doc/usr/share/doc/xinx-doc/
	cp -a $(CURDIR)/doc/* $(CURDIR)/debian/xinx-doc/usr/share/doc/xinx-doc/
	rm -rf $(CURDIR)/debian/xinx-doc/usr/share/doc/xinx-doc/html/.svn

Ici on génère deux paquets, le paquet binaire et la documentation.

Génération du paquet

Mise à jour des informations du paquets

Pour modifier le changelog sur la version courante

dch -a

Pour créer une nouvelle version

dch -i

Création du paquet

dpkg-buildpackage -rfakeroot

L'application va signer le paquet s'il trouve la clé assignée à l'utilisateur.

Création d'un dépôt

Après avoir créé des paquets, il peut-être intéressant de créer un dépôt pour installer ces paquets. voici la marche à suivre pour créer le dépôt.

Sur votre serveur internet (nous ne parlerons pas ici de la mise à disposition sur Internet), vous allez devoir créer un dossier contenant votre référentiel (exemple : /www/sites/apt).

Création de l'arborescence

Vous allez devoir créer une arborescence comme suite :

dists
   +- main 
       |- binary-i386
       |- binary-amd64
       +- source

Parmi les fichiers générés vous allez devoir mettre le fichier .deb dans le dossier binaire, et les fichiers .changes, .dsc, et .tar.gz dans le dossier source.

Création d'un fichier apt-ftparchive.conf

Nous allons commencer par créer un fichier apt-ftparchive.conf dans lequel nous allons définir les fichiers à créer.

Dir {
	ArchiveDir ".";
	CacheDir ".";
};

Tree "dists/unstable" {
	Sections "main";
	Architectures "amd64 source";
};

BinDirectory "dists/unstable/main/binary-amd64" {
	Packages "dists/unstable/main/binary-amd64/Packages";
	Contents "dists/unstable/Contents-amd64";
	SrcPackages "dists/unstable/main/source/Sources";
};

Création du fichier apt-unstable-release.conf

APT::FTPArchive::Release::Origin	"shadoware.org";
APT::FTPArchive::Release::Label		"shadoware.org";
APT::FTPArchive::Release::Suite		"unstable";
APT::FTPArchive::Release::Codename	"unstable";
APT::FTPArchive::Release::Architectures	"amd64 source";
APT::FTPArchive::Release::Components	"main";
APT::FTPArchive::Release::Description	"Paquets du site Shadoware.Org";

Création du fichier update-archive.sh

Ce fichier est celui que l'on doit exécuter pour la génération du contenu de l'arborescence :

apt-ftparchive generate apt-ftparchive.conf
apt-ftparchive -c apt-unstable-release.conf release dists/unstable > dists/unstable/Release

Notes

[1] D'autres cibles sont disponibles (cf la doc de cdbs).

[2] A cause d'un bogue, ou d'une mauvaise utilisation, la variable $(DEB_DESTDIR) ne me ramenait pas la bonne valeur, je l'ai donc remplacée par $(CURDIR)/debian.

Shadoware.Org - Mot-clé - qmake

[C++/Qt] CMake et Qt

Compilation

Package à utiliser

Définir les modules Qt à utiliser :

Quelques déclarations supplémentaires

Macros pour générer les fichiers moc.

Macro par défaut

Une autre macro

Macro pour générer les fichiers en tête d'interface graphique.

Macro pour compiler les fichiers de resources

Macro pour compiler les fichiers de traduction

Compilation d'un plugin

Plugin dynamique

Plugin Static

Ajout d'un fichier RC pour windows

Compilation d'une librairie static

Utiliser le programme CMake

Notes

[C++/Qt] Performance de l'utilisation de QSharedPointer

Présentation

Sommaire

Notes

Utilisation de QSharedPointer

A quoi sert-il ?

Comment l'utiliser ?

Comment utiliser this

Comment éviter les références circulaires

Utilisation dans les applications multi-thread.

Utilisation d'un pool

Benchmark

Code source

Le jeu de test

Test de l'allocation

Test de Modification d'une donnée

Test d'affectation

Test de destruction

Résultat du test

Notes

Qt 4.5 est sortie

Notes

Paquet Debian et Qt

Installation des paquets

Création du paquet

Préparation

Création des scripts

Paquet simple

Paquet multiple

Génération du paquet

Mise à jour des informations du paquets

Création du paquet

Création d'un dépôt

Création de l'arborescence

Création d'un fichier apt-ftparchive.conf

Création du fichier apt-unstable-release.conf

Création du fichier update-archive.sh

Notes

Macros pour générer les fichiers `moc`.

Comment utiliser `this`