Shadoware.Org - Mot-clé - nokia

[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

[C++/Qt] Concaténation de chaînes de caractères

Ulrich Van Den Hekke — Wed, 22 Dec 2010 13:03:00 +0100

Présentation

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

Qt permet donc de faire des interfaces graphiques mais aussi d’accéder à des bases de données SQL, de faire de la communication réseau, une gestion simplifiée des threads, la lecture de fichier XML. Qt intègre aussi le moteur HTML Webkit.

Qt ajoute une couche supplémentaire au C++ permettant de faire de l’introspection de classe un peu plus poussée (comme l’appel d’une méthode dont on ne connaît le nom qu’à l’exécution). Qt permet également la gestion d’évènement par l’intermédiaire d’un système puissant de SIGNALS et de SLOTS.

Dans la suite de cet article nous allons nous concentrer sur une très petite partie de Qt mais qui est utilisée dans beaucoup d’applications écrites en Qt : les chaînes de caractères, et plus précisément, la concaténation de chaînes de caractères.

Concaténation de chaînes de caractères.

Comme dans d’autres langages, la concaténation de chaînes de caractères se fait à l'aide de l'opérateur +. Prenons un exemple simple :

#include <QString>
 
QString abc = "abc", def = "def";
QString result;
 
result = abc + def;

L'utilisation de l'opérateur + facilite l'écriture de la concaténation des chaînes de caractères (tout comme l'opérateur == permet de facilement comparer des chaînes de caractères de type QString).

Malheureusement cette écriture rend le code peu performant pour diverses raisons (que l’on peut retrouver dans la documentation de l’objet QString).

Concaténation rapide de chaînes de caractères

A partir de Qt 4.6, Nokia, a ajouté un template nommé QStringBuilder (cet objet fait beaucoup penser à l'objet StringBuilder de JAVA permettant d'accélérer les concaténations de chaînes de caractères).

Ce template ne s’utilise pas directement mais au travers de l'opérateur %. En remplaçant donc l'opérateur + par % on gagne en performance (dixit la doc de Qt).

Pour pouvoir utiliser l'opérateur, il suffit d'inclure le fichier QStringBuilder :

#include <QStringBuilder>
 
QString abc = "abc", def = "def", ghi = "ghi";
QString result;
 
result = abc % def % ghi;

Une autre possibilité est de définir (par exemple dans votre fichier .pro ou dans un include général de votre application) les définitions QT_USE_FAST_CONCATENATION, et QT_USE_FAST_OPERATOR_PLUS.

Ces définitions permettent de remplacer l'opérateur + par l'opérateur % dans toute l'application. Par contre cette opération peut demander quelques modifications de votre code.

#define QT_USE_FAST_CONCATENATION
#define QT_USE_FAST_OPERATOR_PLUS
 
#include <QString>
 
QString abc = "abc", def = "def";
QString result;
 
result = abc + def;

Benchmark

Nous allons donc dans la suite du document vérifier que l'opérateur % est plus rapide que l'opérateur +. Pour cela nous allons utiliser le module de benchmark de Qt.

Code source

Voici le petit programme permettant de tester la performance de la concaténation. Notre exemple simple va constituer à la concaténation de 26 chaînes de caractères créées au début. L'appel se fera une première fois en utilisant l'opérateur + et une seconde fois en utilisant l'opérateur %.

#include <QtCore/QString>
#include <QtTest/QtTest>
#include <QStringBuilder>
 
class TestPerf : public QObject
{
    Q_OBJECT
 
public:
    TestPerf();
 
private Q_SLOTS:
    void concat();
    void concat_data();
};
 
TestPerf::TestPerf()
{
}
 
void TestPerf::concat()
{
	QFETCH(bool, useStringBuilder);
	QString result;
 
	QString a("a"), b("b"), c("c"), d("d"), e("e"), f("f"), g("g"), h("h"), i("i"), j("j"), k("k"), l("l"), m("m"), n("n"), o("o"), p("p"), q("q"), r("r"), s("s"), t("t"), u("u"), v("v"), w("w"), x("x"), y("y"), z("z");
 
	if (useStringBuilder)
	{
		QBENCHMARK
		{
			// Concaténation en utilisant QStringBuilder
			// Dans ce cas la concaténation devrait être plus rapide
			result = a % b % c % d % e % f % g % h % i % j % k % l % m % n % o % p % q % r % s % t % u % v % w % x % y % z;
		}
	}
	else
	{
		QBENCHMARK
		{
			// Concaténation en n'utilisant pas QStringBuilder. On utilise alors la concaténation normal de chaînes de caractères en utilisant
			// QString
			result = a + b + c + d + e + f + g + h + i + j + k + l + m + n + o + p + q + r + s + t + u + v + w + x + y + z;
		}
	}
}
 
void TestPerf::concat_data()
{
	QTest::addColumn<bool>("useStringBuilder");
	QTest::newRow("Don't use QStringBuilder") << false;
	QTest::newRow("Use QStringBuilder") << true;
}
 
QTEST_APPLESS_MAIN(TestPerf);
 
#include "tst_testperf.moc"

Résultat du test

Le test a été fait en utilisant la version 4.6.3 de Qt. Le résultat est sensiblement le même avec la version 4.7.0

Sans QStringBuilder	0.00367 msec
Avec QStringBuilder	0.00046 msec

On voit dans ce test que la version en utilisant QStringBuilder est 8 fois plus rapide que sans. Bien sûr vu le temps que prend la concaténation de chaînes de caractères, ce test commence à avoir de l'intérêt uniquement à partir du moment où on fait beaucoup de concaténation dans la seconde, ou si les temps de réponses sont critiques.

Sur ce, je vous souhaite à tous un Joyeux noël et une bonne année.

[Qt] Transformation d'une vue tableau en une vue hiérarchique

Ulrich Van Den Hekke — Mon, 21 Sep 2009 13:50:00 +0200

Pour visualiser des données internes à l'écran, Nokia/Qt nous propose l'architecture MVC à l'aide des classes QAbstractItemModel et de ses sous classes (QAbstractListModel, QAbstractTableModel, ...). Le but de l'architecture MVC est de séparer la représentation mémoire des données, de l'affichage qu'elles auront.

Si les données sont par exemple issue d'une requête SQL, le modèle QSqlQueryModel permet de représenter la sélection SQL, à l'écran dans un composant QTableView. Ces données sont alors représentées sous forme d'un tableau deux dimensions.

Si l'on veut représenter les dossiers de l'ordinateur, le modèle QDirView permet d'afficher les données de façon hiérarchique.

Il est également possible d'écrire nos propres modèles pour représenter nos propres données.

Le but de cet article est de présenter l'écriture d'un modèle, transformant une vue plane (tableau deux dimensions) en vue hiérarchique. Pour cela nous allons prendre l'exemple de l'affichage d'une liste de catégorie^[1].

Notes

[1] La construction de notre objet s'est basé sur l'analyse de l'objet QSortFilterProxyModel de Nokia.

Présentation de l'exemple

Nous allons voir ci-dessous comment transformer une vue plane en une vue hiérarchique. Pour cela nous allons prendre l'exemple d'une liste de catégorie. Ces catégories seront stockées dans une base de données Sqlite. Ceci n'a pas d'importance mais permet d'expliquer pourquoi les données en mémoire ne sont pas déjà sous forme hiérarchique.

La description d'une catégorie passe donc par :

un identifiant unique appelé id
un nom de catégorie
un lien vers la catégorie parente appelé parent_id

C'est le champ parent_id qui permettra de déterminer dans quelle catégorie notre sous-catégorie se trouve. Dans notre cas, test3 a comme parent_id l'identifiant 11 qui est la catégorie test.

Dans notre exemple, nous allons nous conditionner à un modèle en lecture seul. Il est également possible de faire un modèle en lecture/écriture mais nous n'en parlerons pas dans cet article. Nous nous cantonnerons donc à un modèle lecture seul sur un modèle source de type QSqlTableView. (Un modèle en lecture/écriture peut nécessiter de mettre à jour notre structure, ce qui peut être assez compliqué, par exemple en cas de changement de la catégorie parente).

Déclaration d'un modèle

Qu'est qu'un proxy ?

Notre interface se basera sur la classe QAbstractProxyModel. Le but de cette classe est de permettre de faire une transposition entre un premier modèle et une vue. Elle peut par exemple (à l'aide de QSortFilterProxyModel) permettre de filtrer ou trier les données d'une vue.

Cette vue nous permettra de faire la transposition entre un modèle tableau et une vue arborescente.

Interface du proxy

Les méthodes à ré-implémenter pour faire fonctionner une proxy, sont les suivantes :

virtual QModelIndex index( int row, int column, const QModelIndex & parent ) const;
virtual QModelIndex parent( const QModelIndex & index ) const;
 
virtual int rowCount( const QModelIndex & parent = QModelIndex() ) const;
virtual int columnCount( const QModelIndex & parent = QModelIndex() ) const;
 
virtual QModelIndex mapFromSource ( const QModelIndex & sourceIndex ) const;
virtual QModelIndex mapToSource ( const QModelIndex & proxyIndex ) const;

Les quatre premières méthodes appartiennent à l'objet QAbstractItemModel et seront questionnées par la vue (liste, arbre, …) pour connaître la représentation à l'écran.

Les méthodes mapFromSource(), et mapToSource() sont à implémenter pour l'objet QAbstractProxyModel. Elles permettent de faire la liaison entre les indexes (QModelIndex) du modèle d'origine et les indexes du nouveau modèle.

Les méthodes data(), headerData(), flags() sont réimplémentées par l'objet QAbstractProxyModel et utilisent les méthodes mapFromSource() et mapToSource() pour, lors de l'appel d'une de ces méthodes, récupérer les informations stockées sur le modèle d'origine.

Des méthodes sourceModel() et setSourceModel() permettent de spécifier le modèle d'origine.

Implémentation de notre modèle

Structure interne

Nous allons, dans cette partie, parler de la structure interne utilisée par notre objet.

struct Mapping {
	int id, parrentId;
	int index, parentIndex;
	QVector<int> source_rows;
};
typedef QMap<int,Mapping*> IndexMap;
 
IndexMap m_sourcesIndexMapping;
QHash<int,int> m_categoryIdMapping;

Nous allons créer une structure Mapping qui associera pour une ligne dans le modèle source, les informations concernant :

l'identifiant de la ligne.
l'identifiant de la ligne parente.
l'index dans le modèle source.
l'index du parent dans le modèle source.
la liste des indexes dans le modèle source des enfants dans notre modèle.

Une table de hashage permettra de retrouver à partir d'un identifiant (id), la ligne dans le modèle source correspondante. On ne gardera que la seconde colonne (le nom de la catégorie), on ne fera donc l'association qu'entre le nom de la colonne de notre modèle et le modèle source en dure dans le programme.

createMapping()

Le but de cette méthode est de générer l'arborescence qui sera ensuite utilisée dans la suite des méthodes. Cette arborescence étant générée une fois pour toute (ou à chaque fois que le modèle source sera réinitialisé), il faudra parcourir l'ensemble des lignes du modèle source pour construire notre arbre. Parcourir l'ensemble des lignes du modèle source peut prendre du temps si ce dernier contient beaucoup de ligne.

Nous allons considérer dans la suite, que l'identifiant de ligne 1 (id) correspond à la catégorie de plus haut niveau (ci-dessus du nom de Categories). Nous allons créer une catégorie fictive 0 qui correspondra à la racine de notre modèle. Cette catégorie sera donc la catégorie parente de celle à l'identifiant 1. Dans notre modèle source, la catégorie 0 n'a pas d'équivalence parmi les lignes du modèle source. Nous allons donc lui associer la ligne -1 dans le modèle source.

Maintenant voyons la génération de la structure interne.

qDeleteAll( m_sourcesIndexMapping );
m_sourcesIndexMapping.clear();
m_categoryIdMapping.clear();

Nous commençons ci-dessous par nettoyer les différentes structures afin de les régénérer. Il faudra à la suite de la création du mapping appeler la méthode reset() afin de prévenir la vue que l'ensemble des indexes du modèle sont obsolètes.

int source_rows = m_sourceModel->rowCount();
for( int i = -1; i < source_rows; ++i ) {
	Mapping * m = new Mapping;
	IndexMap::const_iterator it = IndexMap::const_iterator( m_sourcesIndexMapping.insert( i, m ) );
	m->index = i;
	m->parrentId = 0;
	m->parentIndex = 0;
 
	if( i >= 0 ) {
		QSqlRecord record = m_sourceModel->record( i );
		m_categoryIdMapping[ record.value( list_id ).toInt() ] = i;
		m->id = record.value( list_id ).toInt();
	} else { // Create the root Item
		m->id = 0;
		m_categoryIdMapping[ 0 ] = -1;
	}
}

Nous récupérons le nombre de ligne dans le modèle source et commençons à initialiser notre structure. Le but de cette boucle est surtout d'initialiser dans notre correspondance identifiant/index (m_categoryIdMapping), l'emplacement des identifiants dans notre tableau. Ainsi dans la suite lorsque l'on essaiera d'associer une ligne à son parent, nous pourrons savoir à quel emplacement retrouver notre id dans la structure m_sourcesIndexMapping.

Nous profitons également de cette boucle pour initialiser les différents champs de notre structure comme l'index (qui correspond à la ligne dans le modèle source), et l'id qui correspond à un identifiant unique dans notre liste.

Nous n'oublions pas notre cas particulier que représente notre racine (ligne source -1 inexistante).

for( int i = 0; i < source_rows; ++i ) {
	QSqlRecord record = m_sourceModel->record( i );
 
	int parentCategoryId = record.value( list_parentid ).toInt();
	int parentCategoryIndex = m_categoryIdMapping.value( parentCategoryId, -2 );
	Q_ASSERT( parentCategoryIndex > -2 );
	Mapping * mapping = m_sourcesIndexMapping.value( i );
	mapping->parentIndex = parentCategoryIndex;
	mapping->parrentId   = parentCategoryId;
 
	Mapping * categoryMapping = m_sourcesIndexMapping.value( parentCategoryIndex );
	categoryMapping->source_rows.append( i );
}

Enfin pour chaque enregistrement de notre modèle source, nous récupérons l'identifiant du parent et recherchons dans la structure que nous venons de créer l'index dans le modèle source de la catégorie parente.

Ces valeurs sont alors renseignées dans le modèle. Nos ajoutons également dans la structure de mapping de la catégorie parent, notre ligne dans la liste des enfants.

Notre structure est ainsi complètement initialisé. Un identifiant connaît donc son parent, et la liste de ses enfants. C'est sur cette structure que se basera le reste des méthodes de notre modèle.

mapFromSource()

Le but de cette méthode est de convertir notre index venant du modèle source vers un index de notre modèle à nous.

L'index du modèle source nous donne l'emplacement de la donnée dans le modèle source sous forme (ligne, colonne) alors que l'index de notre modèle doit donner l'emplacement dans notre modèle sous la forme (ligne, colonne, pointeur indiquant le parent).

if( ! sourceIndex.isValid() ) return QModelIndex();
if( sourceIndex.model() != m_sourceModel ) {
	qWarning( "CategoryItemModel: index from wrong model passed to mapFromSource" );
	return QModelIndex();
}

Il faut donc d'abord vérifier que l'index du modèle source est valide. S'il n'est pas valide, alors il ne sera pas valide non plus dans notre modèle à nous.

int row = sourceIndex.row();
IndexMap::const_iterator it = m_sourcesIndexMapping.constFind( row );
Q_ASSERT( it != m_sourcesIndexMapping.constEnd() );

Nous récupérons l'index dans le modèle source, et à l'aide de notre tableau d'index source, nous allons retrouver l'objet Mapping correspondant. Cette objet Mapping correspondra à celui de notre index source. Ce dont nous avons besoin pour notre modèle est l'objet Mapping de l'objet parent (En effet, notre index est construit sous la forme : ligne, colonne, pointeur sur la structure Mapping du parent de notre index). Nous récupérons donc l'index de la ligne source dans l'objet parent.

int parentRow = it.value()->parentIndex;
IndexMap::const_iterator parentIt = m_sourcesIndexMapping.constFind( parentRow );
Q_ASSERT( parentIt != m_sourcesIndexMapping.constEnd() );
 
Mapping * m = parentIt.value();

Cela nous permet de récupérer l'objet Mapping de l'index parent.

int proxyRow    = m->source_rows.indexOf( row );
int proxyColumn = sourceColumnToProxy( sourceIndex.column() );
if( proxyColumn == -1 ) return QModelIndex();

La méthode sourceColumnToProxy() permet de transformer une colonne de l'objet source en une colonne de l'objet courant. Cela signifie que la colonne 2 sera convertie en colonne 1, et que les colonnes 1 et 3 ne seront pas converties (et cachées). Dans ce dernier cas, nous retournons QModelIndex().

L'index de la ligne dans notre modèle sera donné par la position dans la liste source_rows dans notre structure de conversion.

return createIndex( proxyRow, proxyColumn, *parentIt );

Nous pouvons alors créer notre index.

mapToSource()

De la manière inverse à la méthode mapFromSource(), cette méthode permet de convertir un index de notre objet en un index du modèle source.

if( ! proxyIndex.isValid() ) return QModelIndex();
if( proxyIndex.model() != this ) {
	qWarning( "CategoryItemModel: index from wrong model passed to mapToSource" );
	return QModelIndex();
}

Si le modèle est invalide dans notre modèle, il l'est aussi dans le modèle source. Il n'y a pas d'équivalent dans le modèle source de l'index racine.

Mapping * m = static_cast<Mapping*>( proxyIndex.internalPointer() );

Nous récupérons la structure dans le pointeur interne de notre index.

int sourceColumn = proxyColumnToSource( proxyIndex.column() );
if( sourceColumn == -1 ) return QModelIndex();

Nous récupérons également les informations sur notre colonne (Soit, conversion de la colonne 0 dans notre modèle, en la colonne 1 dans le modèle source).

int sourceRow = m->source_rows.at( proxyIndex.row() );

Nous recherchons dans notre liste source_rows la ligne dans le modèle source qui correspond à la ligne (relative au père) indiqué par notre index et nous construisons un index de type (ligne, colonne) correspondant au modèle source.

return m_sourceModel->index( sourceRow, sourceColumn );

L'implémentation des méthodes mapFromSource() et mapToSource() permettent de faire fonctionner les implémentations des méthodes data(), headerData(), et flags(). Il n'y aura donc aucun intérêt à ré-implémenter ces méthodes à moins de vouloir traiter les données de ces fonctions. Nous ne les décrirons donc pas ici, mais vous pourrez voir dans le fichier attaché, un exemple d'utilisation.

index()

Le principe de cette méthode est de générer un index pour notre modèle. L'index doit être valide et réutilisable dans les méthodes rowCount(), flags(), columnCount(), data(), mapToSource().

if( ( row < 0 ) || ( column < 0 ) ) return QModelIndex();

Si la ligne ou la colonne est inférieure à 0, l'index n'est pas valide.

IndexMap::const_iterator it = m_sourcesIndexMapping.constFind( -1 );
 
QModelIndex sourceParent = mapToSource( parent );
if( sourceParent.isValid() ) {
	it = m_sourcesIndexMapping.constFind( sourceParent.row() );
}

A partir de l'index parent nous retrouvons l'index qui correspond dans le modèle source (sourceParent'). Si l'on ne trouve pas d'index dans le modèle source, nous considérons être sur l'élément racine de notre arbre. Sinon nous recherchons dans la table de Mapping'' la structure qui correspond.

Q_ASSERT( it != m_sourcesIndexMapping.constEnd() );
if( it.value()->source_rows.count() <= row )
	return QModelIndex();

Nous vérifions le nombre d'élément dans la structure et nous retournons un index non valide si l'index demandé va au delà de la taille du tableau.

return createIndex( row, column, *it );

Finalement nous retournons l'index créé avec le pointeur vers la structure Mapping du père en internalData.

parent()

Cette méthode permet de retourner pour l'index donné du proxy, l'index du parent. Un index invalide n'a pas de parent.

if( ! index.isValid() ) return QModelIndex();
 
Mapping * m = static_cast<Mapping*>( index.internalPointer() );

On récupère la structure de correspondance stockée dans le pointeur interne de l'objet. Cette structure nous donne les informations du parent (en effet dans internalPointer(), on stock la structure Mapping du parent), et donc l'index dans le modèle source.

int sourceRow = m->index;
if( sourceRow == -1 ) return QModelIndex();
 
QModelIndex sourceParent = m_sourceModel->index( sourceRow, proxyColumnToSource( 0 ) );
QModelIndex proxyParent = mapFromSource( sourceParent );

On utilise alors notre méthode mapFromSource() pour retrouver l'index du parent dans le référentiel du proxy.

return proxyParent;

rowCount()

Le but de cette méthode est de retourner le nombre de ligne enfant pour un index. Dans le modèle source les indexes n'ont pas d'enfant. Lorsque l'index vaut QModelIndex(), cela signifie qu'il faut retourner le nombre de ligne pour notre racine.

if( index.column() > 0 ) return 0;

Seul la première colonne a des enfants.

if( ! index.isValid() ) {
	Mapping * rootMapping = m_sourcesIndexMapping.value( -1 );
	return rootMapping->source_rows.count();

Pour l'index racine, on récupère le nombre de ligne à la ligne -1 du modèle source.

} else {
	Mapping * parrentMapping = static_cast<Mapping*>( index.internalPointer() );
	int sourceRowIndex = parrentMapping->source_rows.at( index.row() );
	Mapping * rowMapping = m_sourcesIndexMapping.value( sourceRowIndex );
 
	return rowMapping->source_rows.count();

Sinon on récupère la structure stockée dans le pointeur interne. Cette structure est celle du parent de notre objet. On récupère à l'aide de la méthode row() de l'index l'emplacement de la ligne source. Cette ligne source nous permet de récupérer la structure de correspondance de notre index, et ainsi le nombre de ligne de notre index.

columnCount()

Notre modèle ne possède qu'une seule colonne.

return 1;

proxyColumnToSource()

Si la colonne du proxy vaut 0, alors on retourne la colonne 1, sinon on retourne la colonne -1 : la colonne n'est pas convertible, elle n'existe pas dans notre proxy.

if( proxyColumn == 0 )
	return list_name;
return -1;

sourceColumToProxy()

Si la colonne source est 1, alors nous convertissons celle-ci en la colonne 0. Sinon la colonne n'existe pas dans notre proxy.

if( sourceColumn == list_name )
	return 0;
return -1;

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

XINX - Editeur de feuille de style

Ulrich Van Den Hekke — Wed, 18 Feb 2009 19:00:00 +0100

Bonjours à tous,

Ce billet, parle de XINX, un logiciel libre que j'ai développé et que je continue à développer sur mon temps libre. Le but de se billet est de présenter XINX et d'être le début d'une longue série de billet parlant de son développement.

En effet, même si le programme est propre à une utilisation particulière pour un cercle de personne restreint, les méthodes, classes, et idées utilisées dans ce programme peuvent intéresser d'autres personnes.

Présentation

XINX est un éditeur de feuille de style sur lequel je travail depuis début 2006. En faite j'avais commencé un autre éditeur à l'aide de Borland/Delphi 7 mais il a été rapidement arrêté pour prendre une nouvelle direction dans un nouveau langage avec un nouveau départ^[1].

Cet éditeur de feuille de style à la particularité de pouvoir être utilisé dans le cadre de mon travail : sur l'application eGx (de la société Générix^[2]). XINX permet non seulement l'édition de feuille de style (XSL), en proposant une complétion intuitive, mais propose également un mode projet, dans lequel il est possible de dérivé une feuille de style plutôt que de la remplacer (de façon spécifique à notre méthode de travail en projet chez le client).

XINX est un acronyme récursive^[3] qui signifie XINX Is Not XDME. Ce nom a été choisis car XINX est le complément idéal à XDME (l'éditeur de fichier de configuration d'eGx).

Au niveau du choix du langage, a contrario des autres applications Generix écritent en JAVA, XINX a été programmé en C++. Le framework Qt de la société ~~Trolltech~~Nokia a été choisis pour simplifier la programmation. Pourquoi ce choix de langage :

XINX est une application écrite sur mon temps libre, j'ai donc choisis un langage que je souhaité apprendre. En faite la raison de l'existence de XINX, et la volonté d'apprendre à utiliser ce framework.
Le framework Qt est utilisé par l'environnement de bureau KDE. Cet environnement de bureau est celui que j'utilise tous les jours, pendant mon temps libre (chez moi), sous Gnu/Linux.
La version 4 de ce framework est utilisable sous MS/Windows, sans payer de licence, dans le cadre de l'écriture d'un logiciel libre (au bureau tout nos poste sont sous MS/Windows)^[4].

Architecture

XINX est décomposé en plusieurs parties :

la librairie de composant (contenant un gestionnaire de plugin en Qt, un combobox pour choisir une couleur, une liste de valeur avec les boutons pour ajouter ou supprimer des éléments, une barre d'édition pour faciliter l'édition de dossier)
la librairie principale (externalisant ce qui peut être nécessaire aux plugins).
une série de plugin permettant, dans XINX de
- gérer CVS
- gérer SubVersion
- gérer les extentions XSL, JS, XML, HTML
- gérer les WebServices
l'application elle-même
une application de migration de projet (pour migrer les fichiers projets XINX quand ces derniers changent)
une librairie gérant l'éditeur de code (l'éditeur utilisé pour la prochaine version est QCodeEdit^[5])
les librairies du framework Qt

Vous pouvez une documentation sur l'écriture de plugins sur le site de XINX ainsi qu'une documentation au format Doxygen des librairies.

Notes

[1] Borland/Delphi 7 étant limité à la plateforme de Microsoft, et l'application ayant pris dés le début une mauvaise direction (orienté fichier de configuration plutôt que feuille de style)

[2] Generix est un éditeur de logiciel de gestion d'entreprise, dit ERP

[3] Un acronyme qui contient l'acronyme même, comme Gnu pour Gnu Is not Unix

[4] XINX est un logiciel libre non parce que je n'avais pas le choix dû à la double licence de la librairie Qt mais bien par choix personnelle de développer du logiciel libre sur mon temps personnel.

[5] QCodeEdit est un éditeur de code écrit pour Qt. Il est très performant, et possède beaucoup de fonctionnalité utile.

Nouvelles fonctionnalités de Qt Designer 4.5

Ulrich Van Den Hekke — Sun, 19 Oct 2008 19:24:00 +0200

Sur ~~Trolltech~~Nokia Labs Blogs, Friedelann Kleint nous présente aujourd'hui les nouvelles fonctionnalités de Qt Designer 4.5^[1].

Au menu, on peut trouver l'ajout de filtre sur l'éditeur de propriétés ainsi que sur l'inspecteur d'objet (Ce qui peut permettre de sélectionner un composant et d'en modifier les propriétés plus rapidement).

L'arrangement de la boite à outil est également différent :

De plus il est maintenant possible de :

Sélectionner l'objet ancêtre d'un widget en sélectionnant Select ancestors du menu contextuel.
Changer le Layout sans casser et reconstruire le Layout de la feuille
Ajouter facilement une nouvelle ligne au layout (L'action Add form layout row ouvrant la boite de dialogue ci-dessous)
Créer des Assistants (Wizard) linéaires
Désactiver la traduction de certaine chaîne.
...

Enfin, pour terminer, comme le dit Friedemann : The general focus of the 4.5 release is on stability and performance. Soit : Le but principal de la version 4.5 est la stabilité et les performances.

Pour plus de précision, je vous conseille d'aller voir la page d'origine et/ou de télécharger la snapshot.

Notes

[1] Référence : http://labs.trolltech.com/blogs/200...

QT 4.4.2 puis QT 4.4.3 sont sorties

Ulrich Van Den Hekke — Mon, 06 Oct 2008 17:02:00 +0200

En une semaine sont sortie les versions 4.4.2 et 4.4.3 de Qt.

La version 4.4.2 corrige de nombreux bugs (dont des fuites mémoires sur la partie XmlPatterns). Vous pouvez trouver la listes des changements attachée au billet, ou dans l'archive Qt se trouvant sur le site Trolltech.

La version 4.4.3^[1] modifie chaque entête de fichiers, les icônes, ... pour refléter l'achat de Trolltech par Nokia. Par la même occasion le site de Trolltech a été complètement refait (http://trolltech.com).

Donc si vous avez la version 4.4.2, il n'est pas nécessaire de récupérer la 4.4.3 (sauf si vous souhaiter absolument la dernière version au nom de Nokia), par contre si vous êtes encore à la version 4.4.0 ou 4.4.1, il peut être intéressant d'installer la dernière version (suivant les fonctionnalités que vous utilisez).

Enfin, la question, sans réponse, est, est-ce que le site de Trolltech et de Nokia vont fusionner ou vont-il rester séparer^[2] ?

Notes

[1] http://trolltech.com/about/news/qt-4.4.3-released

[2] ce dernier est tout de même plus pratique, je trouve

Shadoware.Org - Mot-clé - nokia

[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

[C++/Qt] Concaténation de chaînes de caractères

Présentation

Concaténation de chaînes de caractères.

Concaténation rapide de chaînes de caractères

Benchmark

Code source

Résultat du test

[Qt] Transformation d'une vue tableau en une vue hiérarchique

Notes

Présentation de l'exemple

Déclaration d'un modèle

Qu'est qu'un proxy ?

Interface du proxy

Implémentation de notre modèle

Structure interne

createMapping()

mapFromSource()

mapToSource()

index()

parent()

rowCount()

columnCount()

proxyColumnToSource()

sourceColumToProxy()

Qt 4.5 est sortie

Notes

XINX - Editeur de feuille de style

Présentation

Architecture

Notes

Nouvelles fonctionnalités de Qt Designer 4.5

Notes

QT 4.4.2 puis QT 4.4.3 sont sorties

Notes

Comment utiliser `this`