Shadoware.Org - Mot-clé - kde

KMDAlert - Logiciel de surveillance de périphérique RAID - Version pour KDE 4.0

Ulrich Van Den Hekke — Sun, 14 Aug 2011 20:43:00 +0200

Présentation

Possédant chez moi des disques durs en RAID logiciels sous Gnu/Linux, en 2007 (cela fait déjà 4 ans), j'avais écrit un petit logiciel dont le but était de faire du monitoring RAID.

En cas de reconstruction du RAID ou de disque défectueux, le logiciel affiche une notification à l'utilisateur, et change le statut affiché dans la barre de notification (systray). L'icône change bien sur en fonction de l'état du RAID :

dégradé (avec un point d'exclamation)
en cours de synchronisation (avec une barre de progression)
disque RAID dans un état normal

Ce logiciel ne tournait que sous KDE 3.X.

Voici donc une nouvelle version (qui a mis le temps de sortir) qui est un portage de l'application sous KDE 4.X. Elle utilise donc le nouveau système de notification de KDE (pour l'instant en passant uniquement par les notifications standard). Quelques améliorations y seront apportées plus tard.

Requis

Pour fonctionner KMDAlert nécessite que le dossier /sys soit monté et que /sys/block/ soit renseigné pour chaque volume RAID (exemple /sys/block/md0, /sys/block/md1, ...). KMDAlert observe ensuite les modifications faites sur les fichiers pour informer l'utilisateur des modifications faites sur le volume RAID ou sur les disques le composant.

De nos jours le dossier /sys et /sys/block devraient être toujours présents.

L'application a été développée sur Gnu/Debian Squeeze, sur un KDE 4.4.5 avec un noyau 2.6.32.

KMDAlert ne nécessite pas de Inotify. KMDAlert lit le contenu de plusieurs fichiers dans le dossier /sys toutes les 6 secondes pour être informé de la modification de l'état du périphérique. Sur l'application d'origine, développé sous un noyau 2.6.18, Inotify n'est pas averti des modifications faites sur le système de fichier /sys. Les dates de ces fichiers ne sont pas non plus modifiées. Si quelqu'un a une autre méthode à me proposer, je reste ouvert à toutes propositions.

KMDAlert est une application écrite en utilisant les librairies de KDE, mais devrait tout de même fonctionner sous Gnome. Les messages de notification utilisent donc le système de notification de KDE (bien que je n'utilise pas toutes ses possibilités).

Compilation / Installation

La compilation et l'installation de KMDAlert se fait à l'aide du trio habituel :

# Décompression de KMDAlert
tar xjfv kmdalert-0.2-77c0d6b4d49f.tar.gz
cd kmdalert-77c0d6b4d49f
 
# Préparation de la compilation
mkdir build
cd build
 
# Comilation
cmake ../
make
 
# Installation
make install

La compilation nécessite les librairies de développement KDE et Qt3, ainsi que le compilateur GCC.

Licence

La licence choisie est la GNU GENERAL PUBLIC LICENSE

Téléchargement

Vous pouvez télécharger une archive déjà construite de l'application sur KDE-Apps.org.
Le dépôt officiel pour télécharger les sources et participer : http://hg.shadoware.org/kmdalert.
Vous pouvez également télécharger la version attachée au billet.

Système de suivi

Il n'y a actuellement plus de système de suivi pour ce logiciel. En cas de problème, vous pouvez laisser un message dans les commentaires ou m'envoyer un mail.

[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

KMyMoney - Logiciel de compte

Ulrich Van Den Hekke — Sat, 23 May 2009 12:31:00 +0200

Voilà un bon logiciel sur lequel on peut compter (mouarf ! mouarf ! mouarf !), KMyMoney est un éditeur de compte. Je l'utilise quotidiennement, et je décide donc d'en parler un peu, pour que d'autres personnes puissent s'intéresser aussi à ce logiciel.

KMyMoney est un logiciel de gestion de compte pour particulier. Il vous permet de gérer plusieurs de vos comptes en banque, en vous permettant de saisir les dépenses et les recettes sur chacun de vos comptes.

Vous pouvez également lui indiquer vos échéances (par exemple : forfait téléphone, prêt immobilier^[1], mais aussi salaire, vos virements internes ou externes, ...) qu'il s'occupera de mettre à jour dans le registre automatiquement ou à votre demande.

Après une année d'utilisation, il vous permet également de sortir un rapport détaillé sur vos dépenses et vos recettes suivant les catégories saisies pour vos opérations. Cette information peut vous être très utile pour voir où se trouve le "trou" de votre porte monnaie et ainsi faire une rustine. Il vous permet aussi de vous projeter vers l'avenir et de faire votre budget pour l'année prochaine. KMyMoney vous offre pour cela, la saisie de votre budget, ainsi que plusieurs rapports d'écart, vous permettant ainsi de retrouver facilement où vous avez finalement dépensé plus que le budget prévu, et où vous avez dépensé moins.

En plus de vos comptes en banque normaux, KMyMoney vous permet également de gérer vos comptes titre, et les actions que vous y avez mises. Vous pouvez alors facilement suivre la chute vertigineuse de la bourse et votre portefeuille fondre littéralement, mais aussi la remontée (on espère), des actions d'ici quelques ... siècles.

Enfin pour les paranos, vos comptes peuvent être cryptés à l'aide de votre clé GnuPG automatiquement par KMyMoney

Après cette courte présentation, je vous souhaite bon compte

Pour une vie équilibrée, n'oubliez pas de profiter du soleil, au lieu de passer votre temps sur votre ordinateur

Notes

[1] Il s'occupera d'ailleurs de calculer la durée des échéances, ... en fonction des différents chiffres que vous allez lui entrer.

KDE4 devient instable ...

Ulrich Van Den Hekke — Sat, 11 Apr 2009 11:29:00 +0200

Titre trolleur, cela ne veux pas dire que KDE 4 est moins stable qu'avant mais qu'il a passé une étape supplémentaire chez Debian.

Voilà quelques jours déjà que la distribution Gnu/Debian intègre KDE 4 dans sa version instable. C'est une grande nouvelle car cela va permettre à toute les personnes se trouvant en instable et n'ayant pas touchées à la branche expérimental de Debian de pouvoir tester KDE 4.

Malheureusement pour les traumatisé de KDE 4, l'intégration de ce dernier remplace KDE 3.5 et ne viens pas se positionner en parallèle. Il me semble pourtant que lors du passage de KDE 2 à KDE 3, il était possible d'avoir les deux bureaux en même temps sur sa machine et de switcher de l'un à l'autre sans difficulté. Cela signifie donc peut-être aussi la perte d'utilisateur pour KDE sous Gnu/Debian au profit d'un autre environnement de bureau.

Afin d'effectuer la migration en douceur, Gnu/Debian propose un assistant de migration de KDE du nom de Kaboom. Cet assistant, démarrer lors de la première connexion de l'utilisateur et vous propose alors de sauvegarder votre ancien dossier de configuration KDE 3 et de migrer le dossier .kde vers la version 4.

Je viens donc de passer à KDE 4 et m'émerveille des nouvelles fonctionnalités de KWin (cube, placement des fenêtres) que je n'avais pas avant, car n'avait jamais installé Compiz ...

Bonne installation,

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

Debian Lenny est sortie

Ulrich Van Den Hekke — Sun, 15 Feb 2009 11:41:00 +0000

Bonjours à tous,

Voici la grande nouvelle de ce Week-End : Hier, le jour de la St Valentin, la distribution stable Gnu/Debian est passé de Etch à Lenny^[1].

Cela annonce donc non seulement une nouvelle version stable de Gnu/Debian (ce qui est loin d'arriver tous les jours) mais aussi le déblocage de sid.

Attention lors des prochaines mises à jour, KDE 4 (ainsi que les dernières versions de tous les logiciels) arrivera doucement sur votre bureau^[2] si vous êtes en sid ou en testing. Cela va de même pour les dernières versions du noyau qui devrait arriver également.

La prochaine, future distribution stable (qui apparaîtra sûrement d'ici 5 ans) sera squeeze.

Notes

[1] http://blog.ganneff.de/blog/2009/02/14/lenny-release.html

[2] http://pusling.com/blog/?p=94

De retour

Ulrich Van Den Hekke — Sat, 04 Aug 2007 10:45:00 +0000

Salut tout le monde,

Cela fait très longtemps que je n'ai pas écrit sur ce blog^[1]. Donc me voilà de retour à écrire quelques lignes. Bon, je suis sûr que ma vie ne vous intéresse pas et que vous vous foutez de mon voyage à La Rochelle ou de celui que j'ai fait à Tours, mais je vais quand même vous en parler un peu. Mais rien qu'un peu.

Notes

[1] Et certaines personnes sont là pour me le faire constater

Les aléas du métier

Donc il y a environ 2 mois de cela, j'étais parti en clientel en Belgique. Bon, même si de par chez moi, la Belgique n'est pas loin, Bruxelles est quand même à 1 heure et demi de route. J'ai donc fait l'aller-retour presque tous les jours, et je n'ai pas trouvé beaucoup le temps d'écrire^[1]. Dur de rester éveillé avec 3 heures de voiture par jour, pendant plus d'un mois et demi .... Ce projet ne m'a, bien sûr, pas déplu, ayant appris pas mal de choses au cours de ce mois et demi, même si parfois il y avait un peu de pression dans la cocotte. Ensuite après cela, je me suis retrouvé sur un autre projet^[2], qui me prenaient jusqu'ici un peu (euphémisme ...) de temps. Je suis d'ailleurs pour l'instant toujours sur ce projet, projet que j'apprécie également.

Bref le soir, un peu crevé, je n'écris pas sur mon blog, et le week-end ....

Qt4

Depuis quelques temps je m'intéresse à Qt4 de la société Trolltech. Qt est un toolkit graphique permettant le développement d'application multi-plateforme (pour ceux qui ne connaissent pas). Qt est le toolkit graphique utilisé par l'environnement KDE sous Gnu/Linux.

Jusqu'ici KDE 3.5 utilisait la bibliothèque Qt3. Cette bibliothèque permettait le développement d'application libre^[3] sous Linux, et devenait payante pour des développements d'applications Windows (libre ou non) ainsi que pour faire des applications commerciales (Linux ou non).

La version 4 de Qt permet quant à elle la création d'application Windows et Linux sous licence libre^[4] à l'aide d'une version Opensource de Qt. Par contre pour le développement d'application commercial, il faut toujours payer une licence à la société Trolltech. (Un prêté pour un rendu). Cette bibliothèque est la base du future KDE 4.

J'ai donc décidé de m'intéresser à cette bibliothèque, et d'apprendre à l'utiliser. J'avais d'ailleurs écrit une application sous KDE 3 en utilisant l'ancienne version de Qt (programme dont je parle ici). Ce programme n'avance malheureusement pas beaucoup. Je n'en ai pas trop la motivation en ce moment^[5]. J'espère ainsi, en apprenant à utiliser cette techno qu'est Qt4 de pouvoir écrire plus tard des applications pour le futur KDE4^[6]

Pour cela je me suis lancé dans l'écriture d'une application en Qt4. Cette application étant projet personnel, n'est diffusée qu'à un nombre restreint de personne, pour le moment. Ce programme en Qt4 essaie d'utiliser toute la puissance du toolkit graphique^[7]. J'utilise les outils pour faire de la Complétion, pour faire de la coloration syntaxique, surveillance de la modification des fichiers, Thread, Processus, Model/View, .... Le but de l'application est un éditeur XSL et Javascript, un peu avancé. Je peux toujours vous montrer une petite capture d'écran, qui ne vous donne qu'un petit aperçu.

Mouais, pas très nette cette photo ....

Je passe donc depuis quelques temps déjà quelques heures le soir, et quelques heures le Week-end à écrire cet éditeur de fichier XML et Javascript. J'y ai même écris un petit module WebServices (qui ne comprend pas tout, mais bon ...). Bon celle-ci possède encore quelques malheureux bugs, mais à part cela elle est tout à fait fonctionnelle.

Projets

C'est RAID

Comme j'en ai déjà parlé précédemment, j'ai monté mes disques durs sur un RAID 1. Lors de coupure de courant (ou après le plantage de Gnu/Linux lors du réveil d'une mise en veille), le RAID se reconstruit. La reconstruction du RAID prend un peu de temps (presque deux heures). Je n'ai pour l'instant trouvé aucune application graphique qui permettrait de voir que le système reconstruit son RAID, où il en est, .... . Pour l'instant je dois faire un cat /proc/mdstat pour avoir toutes ces informations.

J'ai donc bien envie d'écrire un petit outil graphique qui permettrait de voir cela rapidement (EVMS ne me convient pas).

Enfin j'ai bien envie de faire marcher cette mise en veille, continuer un peu le programme que je nomme XINX.

Serveur dédié

Je réfléchis également à l'utilité d'avoir son propre serveur dédié. Je pense par exemple au billet suivant sur le site LinuxFR qui parle du serveur dédié http://www.kimsufi.com/

Hébergement site
Stockage d'un Subversion pour mes différents projets
Un serveur IMAP me permettant d'accéder à mes mails perso de n'importe où
Backup crypté.

Quel est également l'utilité par rapport à un serveur tournant 24h/24 dans son chez soi ?

Notes

[1] Bien que sans ça, je n'aurais pas forcément trouvé le temps non plus

[2] qui me permet de changer un peu des habituels projets.

[3] sous licence GPL

[4] toujours GPL

[5] surtout que je vois des applications tel que Clonzilla, Partimage, ... qui fonctionnent très bien, ils ne leur manquent plus qu'une bonne interface graphique

[6] Même si je n'écris pas énormément d'application pour la communauté, j'ai toujours la profonde motivation de le faire. Il ne reste plus qu'à trouver le projet qui me motive suffisamment.

[7] que je parle bien moi !!

Shadoware.Org - Mot-clé - kde

KMDAlert - Logiciel de surveillance de périphérique RAID - Version pour KDE 4.0

Présentation

Requis

Compilation / Installation

Licence

Téléchargement

Système de suivi

[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

KMyMoney - Logiciel de compte

Notes

KDE4 devient instable ...

Qt 4.5 est sortie

Notes

Debian Lenny est sortie

Notes

De retour

Notes

Les aléas du métier

Qt4

Projets

C'est RAID

Serveur dédié

Notes

Comment utiliser `this`