Après l’avoir lu, vous faites comme moi confiance à l’auteur et choisissez la bibliothèque CxxTest et essayez de l’intégrer dans votre application. Si vous aussi vous utilisez CMake comme outil de construction, vous aurez remarqué que l’intégration de CxxTest est plus que sommaire, je vous propose donc une solution plus complète.

Nous allons supposer que vous avez organisé vos fichiers comme suit :

• dossier src : contient toutes les sources ainsi que vos headers ;
• dossier test : va contenir vos tests unitaires ;
• dossier build : contiendra le fichier généré par CxxTest (il est très important que le dossier existe).

Voici maintenant un build minimaliste avec quelques commentaires pour vous expliquer son fonctionnement :

Tout d’abord vous aurez besoin du fichier FindCxxTest.cmake que j’ai repiqué d’ici et « amélioré ». Ma version se trouve ici.

Pourquoi l’avoir modifié ? Et bien parce que la version normale suppose que notre programme test n’ait pas besoin de l’ensemble de notre projet pour fonctionner or normalement quand vous faites un test unitaire sur une classe très importante, vous aurez besoin de la définition de presque toutes vos classes. La version normale ne vous permet pas cela.

Comment alors faire pour linker notre test unitaire à notre programme ? La première chose serait de faire un exécutable contenant toutes les sources de notre projet sauf le fichier contenant la fonction main (main.cc) :

Vous comprenez au passage pourquoi j’ai décidé de prendre l’extension main.cc au lieu de cpp, quand je fais ma liste de sources :

Je prends ainsi automatiquement toutes les sources de mon projet sauf le fichier main.cc…

Le problème avec cette solution est qu’elle va faire compiler tous nos fichiers deux fois (une fois pour test-unit et une autre fois pour mon-projet. Pour éviter cela il suffit de faire une bibliothèque statique temporaire et de la linker aux deux comme proposé dans ma solution ; ainsi les fichiers ne seront compilés qu’une fois.

Et voilà, l’intégration est terminée ! On peut sûrement amélioré tout ceci et je vous encourage à me contacter si vous avez trouvé quelque chose de plus élégant :).

Attention : Bien sûr je suppose que vous avez mis dans les variables d’environnements le dossier d’include de CxxTest et le dossier racine pour trouver les scripts python. Voici comment c’est chez moi :

CUDA et les ray-tracers

Je m’étais déjà fait les dents sur un mini-raytracer en Java en suivant l’excellentissime tutoriel de LeGreg et j’étais arrivé aux performances de 700ms sur un simple rendu de 3 sphères avec une lumière en gérant les réflexions. Et comme d’habitude, une fois le principe compris, je ne le finis pas et décida de passer à autre chose.

Mais, quelques mois plus tard, en lisant sur le forum ompf (soi-dit en passant : une des meilleurs sources d’informations pour le lancer de rayon en général) que certaines personnes avaient réussi à faire des raytracers en temps réel en CUDA. Là, la mouche me pique et je décide moi aussi d’en faire un.

J’ai donc commencé à me renseigner sur CUDA et 3 jours après j’avais mes 3 boules sur l’écran avec un rendu à 40 fps. Voici le résultat :

J’étais donc satisfait : sans vraiment trop essayer d’optimiser, j’obtenais des performances bien meilleures que si je les avais faites sur un simple CPU (en sachant qu’on peut faire beaucoup mieux). De plus, j’ai été agréablement surpris par la transparence de CUDA et sa prise en main rapide.

CUDA et le C++ (oui, oui… vous avez bien lu)

Mais je ne me suis pas arrêté là, j’ai décidé de pousser le compilateur nvcc jusqu’à ses derniers retranchements après avoir découvert la bibliothèque stdcuda qui utilise CUDA avec du langage C++ et des templates ! En effet, officiellement, CUDA supporte le langage C avec quelques extensions dans les fonctions qui seront exécutées dans la carte graphique.

Que Nenni ! CUDA supporte en fait presque tout le C++ mis à part le polymorphisme (en effet, à cause de l’architecture GPU, c’est très difficile de faire du polymorphisme). Vous pouvez donc utiliser presque toute la puissance du C++ notamment la surcharge des opérateurs (j’aime mes classes Real3 et Matrix4 dans mon code CUDA…) ce qui permet de simplifier énormément votre code et de le factoriser au maximum sans rien perdre en performance. Néanmoins, CUDA étant jeune, j’ai réussi à faire planter le compilateur sur certains bouts de code et il faut avouer que parfois les messages d’erreurs qu’il nous renvoie sont carrément inutiles ou nous font chercher au mauvais endroit, ce qui est encore pire.

CUDA et la non-édition de liens (oui, oui… là aussi vous avez bien lu :D)

Dernier soucis et pas des moindres, CUDA ne supporte pas l’édition de liens à la compilation. Vous ne pourrez donc pas séparer votre code en plusieurs fichiers .cu (vous pouvez par contre avoir autant de fichiers de déclarations que vous voulez) ou alors vous devrez vous assurer de tous les inclure dans un seul fichier (workaround dégueulasse, mais workaround qui fonctionne)… C’est bien dommage mais je pense que dans les prochaines versions cette limitation sera corrigée, il n’y a pas de raison.

En résumé : essayez CUDA ! Ce ne sera pas une perte de temps !

Récupération du code source

Vous pouvez récupérer le code source ici. Ou essayez une de ces commandes :

Il y a également un viewer de source par navigateur web sur le site web.

Et pour ceux qui utilisent Qt, il existe même un add-on pour importer un projet .pro automatiquement et faire pleins d’autres choses. Seulement cela ne marche pas avec les dernières versions de logiciels et vous avez peut-être rencontré cette erreur :

Unable to satisfy dependency from com.trolltech.qtcpp.feature.feature.group 1.4.3 to requiredCapability: org.eclipse.equinox.p2.iu/com.trolltech.qtcpp.linux.x86/[4.4.1,4.4.1].

Nous allons voir comment résoudre ce problème.

Tout d’abord je vous réfère à la documentation existante pour installer la dernière version :

http://labs.trolltech.com/blogs/2007/07/11/develop-qt-applications-in-eclipse

Ensuite une fois que vous avez fait tout ce qu’il faut, lors de l’activation du plugin Qt, l’intégration plante avec le message d’erreur donné précédemment. Le problème vient du fait qu’il attend la version 4.4.1 de com.trolltech.qtcpp.linux.x86 alors que si vous allez dans votre répertoire de eclipse vous trouverez la version 4.4.2 (eclipse/plugins/com.trolltech.qtcpp.linux.x86_4.4.2). Pour se faire, il suffit de modifier le fichier eclipse/features/com.trolltech.qtcpp.feature_1.4.3/feature.xml et de lui dire que ce n’est pas la version 4.4.1 qu’il doit attendre mais la 4.4.2 et le tour est joué !

Voici la modification à faire :

Dans version changer la valeur 4.4.1 en 4.4.2.

http://julian-ibarz.developpez.com/tutoriels/jeux/introduction-VTK/

Bonne lecture !

PS : J’hésite à faire un article sur l’utilisation de VTK en Java. Si cela vous intéresse n’hésitez pas à me contacter pour me motiver ;).

jCAE est un environnement codé en Java pour des applications de CAO. Il est distribué sous la licence libre LGPL. Il propose un logiciel de maillage et de visualisation de CAOs ainsi qu’un binding Java de la célèbre librairie C++ OpenCascade. Il est utilisé par les équipes de Recherche & Développement de EADS notamment pour faire de la simulation acoustique et électromagnétique.

Le plus gros du travail a été sa migration vers la bibliothèque VTK qui permet de corriger certains bugs et de rajouter certaines fonctionnalités demandées.

Voici les nouveautés en détail :

• Remplacement de Java3D par VTK.
• Sélection dans l’arbre qui met en surbrillance la géométrie dans la vue 3D.
• Sélection des faces, patchs et points pour les CAOs.
• Sélection des triangles dans les maillages.
• Rajout de bindings occjava pour importer des labels dans les fichiers STEP.
• Sélection par rectangle élastique dans la vue 3D.
• Migration vers Netbeans 6.1.