Discussion :

[Seabirds]

Bonjour � toutes et � tous!

J'ai cod�/bricol� une petite lib pendant ma th�se, que j'ai utilis� sur Ubuntu, et aujourd'hui on a collabor� avec une chercheuse du domaine qui code sur mac. Outre le sentiment fort agr�able que le travail des trois ans de th�se va peut �tre pas partir de suite aux oubliettes ( ) , y'a quand m�me quelques sp�cificit�s du travail � plusieurs � prendre en compte. Notamment le changement d'OS... Bon je m'attendais � ce qu'on rencontre quelques bricoles �videmment, et heureusement dans l'ensemble �a a �t� vite r�gl�.

Par contre j'avoue avoir �t� un peu surpris de voir la nature des probl�mes, je m'attendais pas � des probl�mes de cet ordre.

Par exemple je d�clarais ce constructeur par d�placement:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
class MyClass {
  MyClass(MyClass&& other) noexcept = default;
};

Ca passait sur mon syst�me mais pas sur mac. J'ai pas dit que �a aurait du passer incognito jusque l�: � vrai dire vous allez peut �tre br�ler ce constructeur pour h�r�sie. Je dis juste que c'est �tonnant de voir que le code qui passe sans souci chez A plante superbement chez B. Par contre ceci met tout le monde d'accord (je vais sans doute surprendre personne � part moi )

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
class MyClass {
  MyClass(MyClass&& other) = default;
}

Idem, j'avais oubli� un #include<functional> quelque part: �a passait cr�me chez moi, et �a plantait chez l'autre. Comment �a se fait que ce soit pass� inaper�u alors qu'on a compil� exactement le m�me code de tests unitaires ?

Bref, au final c'est assez ironique, j'ai perdu beaucoup de temps � d�bugger �a parce que justement je pensais pas qu'un code qui compile quelque part puisse �tre en fait blind� de probl�mes. Ca m'a rappeler le temps perdu il y a un an � chercher une erreur au mauvais endroit parce que je partais du principe que mes tests �taient exhaustifs: ce matin je partais du principe que le compilateur de mon syst�me avait d�j� trouv� tous les d�fauts de mon code.

C'est ce genre de trucs auquel il faut s'attendre � l'avenir quand on va essayer de coder des truc Linux-mac compatibles ? Ou bien �a c'�tait juste le c�t� p�te-�-choux et y'a des truc horribles qui vont nous tomber sur les dents ?

PS: on le dit jamais assez mais vivent les batteries de tests unitaires
PPS: il faut vraiment que j'assainisse cette batterie de tests unitaires
PPS: encore merci � vous tous d'avoir insister pour que je fasse des tests unitaires

[Bktero]

Salut,

�a fait 2 ans que je travaille sur des projets pour micro-contr�leur (MCU) pour lesquelles une grosse partie du code est compil� sur PC pour faire des tests unitaires. Et franchement tu trouves souvent des choses qui clochent entre les deux. En ce moment, c'est du GCC sur MCU et sur PC, les deux cibles sont des processeurs 32 bits, et pourtant on a des diff�rences. Notamment le fait que std::(u)int32_t soit un alias pour (unsigned) int d'un c�t� et (unsigned) long de l'autre. Ce qu'il faut retenir c'est que quand tu changes de cible (processeur + OS + compilateur), il faut s'attendre � des diff�rences. Ce sont des options qui ne sont pas toujours exactement les m�mes (ou qui des fois n'ont pas d'�quivalents directs), des biblioth�ques standards qui ne sont pas impl�ment�es de la m�me mani�re (c'est l� que ton histoire de header non inclus peut arriver ; des fois �a donne des trucs assez relou), ton code qui utilisent des undefined behaviors ou implementation-defined behaviors, ton code qui contient des bugs qui ne s'�taient pas encore exprim�s jusque l�, des compilateurs avec des bugs(oui �a existe) ou des comportements assez �tranges ou des comportements pas toujours exactement coll�s � la norme. La norme des fois laisse aussi des latitudes qui peuvent amener des choses funs (comme par exemple le fait que dans <cstdio>, tu puisses avoir ou pas printf() dans le namespace global ou pas).

Bref, les probl�mes t'attendent au tournant.

Les tests unitaires te permettent effectivement d'avoir une r�f�rence pour ex�cuter ton code sur une nouvelle plateforme. Il faut pas oublier pour autant que ce n'est pas une m�thode compl�te de validation de code. En vrac, faire lire son code � des gens, relire soi-m�me son code, se reposer sur son compilateur r�gl� en mode parano�aque et des outils comme valgrind ;)

[Bousk]

- la compilation n'est pas propre a l'OS mais a la chaine de compilation (qui varie d'un OS a l'autre, mais au sein d'un meme OS egalement)
- toutes les implementations ne sont pas strictement identiques

Apres, ca c'est le niveau 0 de la portabilite. D'autres problemes peuvent survenir
- implementation manquante
- comportements differents avec les memes appels
- devoir rearchitecturer certains pans parce qu'une plateforme propose qu'une API asynchrone
- bug de compilateur sur une plateforme donnee
la liste continue et s'etoffe au fur et mesure des experiences

[Invit�]

Compl�tement d'accord avec Bousk. Sur Ubuntu, tu as une toolchain GCC par d�faut alors que sur Mac c'est du Clang. Les options de compilation et les includes par d�faut ne sont pas les m�mes, et j'imagine que c'est encore diff�rent sur windows/msvc.
Pour r�soudre ce genre de probl�me, il faut essayer de respecter les normes au maximum et surtout tester la compilation sur les diff�rentes toolchains. Tester toutes les toolchains � la main sur sa machine est plut�t difficile. Une meilleure solution est de mettre en place de l'int�gration continue avec TravisCI, Appveyor, Gitlab-CI ou autres.

[ternel]

Et aussi �tudier les r�glages de la chaine de compilation.
Il y a souvent une option pour choisir la norme � utiliser, mais elle n'est pas la m�me pour tous les compilateurs.

Il peut aussi y avoir des diff�rences entre les versions d'un m�me compilateur.

[Seabirds]

Merci de vos r�ponses

- la compilation n'est pas propre a l'OS mais a la chaine de compilation (qui varie d'un OS a l'autre, mais au sein d'un meme OS egalement)
la liste continue et s'etoffe au fur et mesure des experiences

Hum oui c'est bien l� le souci: l'exp�rience ... seabirds apt-get update experience

Tester toutes les toolchains � la main sur sa machine est plut�t difficile. Une meilleure solution est de mettre en place de l'int�gration continue avec TravisCI, Appveyor, Gitlab-CI ou autres.

Mhh ok depuis quelques mois d�j� je sentais venir le moment o� mes scripts bash lanc�s � la main pour les tests allait atteindre une limite. J'ai jet� un coup d'oeil � TravisCI, et j'avoue que je n'arrive pas � savoir si c'est overkill, ou si je peux facilement le mettre en place. Je vais regarder d'un peu plus pr�s merci. Pour l'instant, j'ai une solution faite � la main un peu d�gueu ou des scripts bash s'appellent en cascade � travers les diff�rents modules de la lib pour compiler/ex�cuter des fichiers de tests. Franchement � une �poque j'�tais assez fier du service rendu � ma communaut� de 1 personne, mais l� �a me saoule assez clairement, notamment parce que:

• le nombre de scripts bash explose ces derniers temps, puis c'est relou � �crire.
• que ces tests m�langent un peu deux buts � la fois: i) fournir un code simple et fonctionnel d'exemple d'utilisation pour la classe, et ii) tester le code avec des asserts un peu d�gueu. Du coup je fais un compromis et au final c'est pas super rigoureux.
• que ma collabratrice a tout un pan des tests qui marchent pas � cause d'une option -I �crite en dur dans la commande de compilation des scripts bash.

Moui en �crivant ces lignes �a devient assez �vident qu'il faut changer �a

son compilateur r�gl� en mode parano�aque

g++ -o UTest -Wall -std=c++17 test.cpp c'est assez parano�aque ?

Ternel: Les r�glages de la cha�ne de compilation... Je vais chercher �a merci

[Bktero]

g++ -o UTest -Wall -std=c++17 test.cpp c'est assez parano�aque ?

Euh non �a c'est le minimum vital

En ce moment je compile avec �a :

-pedantic
-Wall
-Wextra

-Wsuggest-override

-Wold-style-cast
-Wuseless-cast

-Wdouble-promotion

-Wmissing-declarations
-Wshadow=compatible-local

-Wswitch-default
-Wswitch-enum

Si tu veux vraiment te faire mal, regarde ce d�p�t Github qui te donne des listes d'options pour diff�rents compilateurs https://github.com/jonathanpoelen/cpp-compiler-options Au hasard (presque), utilise cette gcc-8.0-warnings_strict:

-pedantic
-pedantic-errors
-Wall
-Wextra
-Wcast-align
-Wcast-qual
-Wdisabled-optimization
-Wfloat-equal
-Wformat-security
-Wformat-signedness
-Wformat=2
-Wmissing-declarations
-Wmissing-include-dirs
-Wnon-virtual-dtor
-Wold-style-cast
-Woverloaded-virtual
-Wpacked
-Wredundant-decls
-Wundef
-Wuninitialized
-Wunused-macros
-Wvla
-Wconversion
-Wswitch-default
-Wswitch-enum
-Wsuggest-attribute=noreturn
-Wzero-as-null-pointer-constant
-Wlogical-op
-Wvector-operation-performance
-Wdouble-promotion
-Wtrampolines
-Wuseless-cast
-Wconditionally-supported
-Wfloat-conversion
-Wopenmp-simd
-fsized-deallocation
-Warray-bounds=2
-Wconditionally-supported
-Wnoexcept
-Wsized-deallocation
-Wstrict-null-sentinel
-Wsuggest-override
-Wduplicated-cond
-Wnull-dereference
-Waligned-new
-Walloc-zero
-Walloca
-Wformat-overflow
-Wshadow=compatible-local
-Wclass-memaccess
-Wsign-conversion
-Wcast-align=strict

[Pyramidev]

Bonjour,

Je rejoins Bktero : il faut plus d'avertissements que -Wall.

En fait, le nom -Wall est trompeur, car il n'active pas tous les avertissements.
D'ailleurs, avec GCC, il n'est pas souhaitable d'activer tous les avertissements qui existent car, par exemple, il existe m�me -Wtemplates qui r�le quand on d�clare un template et -Wnamespaces qui r�le quand on �crit du code dans un espace de nom !

Avec GCC, je conseille d'utiliser au moins -Wall -Wextra -pedantic-errors ainsi que -Winvalid-pch si tu as des ent�tes pr�compil�s.

Personnellement, j'utilise :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
-Wall -Wextra -pedantic-errors -Winvalid-pch -Wshadow -Weffc++
-Wold-style-cast -Wconversion -Woverloaded-virtual -Wpointer-arith
-Wzero-as-null-pointer-constant -Winit-self -Wredundant-decls -Wcast-align
-Wfloat-equal -Wunreachable-code -Wmissing-include-dirs

Cela dit, l'inconv�nient des listes d'avertissements � rallonge comme la mienne, c'est que, quand on inclut des ent�tes cod�s par d'autres personnes, on se ramasse plein d'avertissements dans la tronche. Par exemple, voici un extrait d'un de mes codes, simplement pour inclure un ent�te de Boost :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Weffc++"
#pragma GCC diagnostic ignored "-Wold-style-cast"
#pragma GCC diagnostic ignored "-Woverloaded-virtual"
#pragma GCC diagnostic ignored "-Wzero-as-null-pointer-constant"
# include <boost/test/unit_test.hpp>
#pragma GCC diagnostic pop

[Seabirds]

Aouch la claque. Ok donc le -Wall c��tait le verre d'eau qui cache l'incendie de foret.

Bon, la conclusion de l'affaire c'est que je sais meme pas compiler un code. C'est fantastique, on apprend chaque jour.

Bon allez "hackeur vaillant, rien d'impossible", on retrousse les manches hop hop hop

Merci encore de vos conseils !

[Invit�]

Mhh ok depuis quelques mois d�j� je sentais venir le moment o� mes scripts bash lanc�s � la main pour les tests allait atteindre une limite.

J'aime beaucoup le bash mais pour compiler/tester un projet, �a ne me semble plus trop adapt� aujourd'hui. Tu ne peux pas faire tes tests via le syst�me de build + tests unitaires (genre cmake + google-test) ?

[Seabirds]

Tu ne peux pas faire tes tests via le syst�me de build + tests unitaires (genre cmake + google-test) ?

Bonne question. Je ne fais jamais de cmake parce que ma lib c'est juste un petit paquet de headers a inclure dans le main.cpp , que je compile a la main.

Comme tout est template, j'ai des petits fichiers de tests du genre:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
// Compiles with g++ -o test merger_test.cpp -std=c++14 -Wall
 
#include "../../merger.h" // le code a "tester"
 
//! [Example]
 
#include <vector>
#include <list>
#include <string>
#include <algorithm>
#include <iostream>
#include <iterator>
#include <random>
#include <cassert>
 
int main () {
 
  using node_type = std::string;
  using quetzal::coalescence::occupancy_spectrum::on_the_fly;
  using SMM = quetzal::coalescence::SimultaneousMultipleMerger<on_the_fly> ;
 
  std::vector<node_type> nodes = {"a", "b", "c", "d"};
 
  unsigned int N = 3;
 
  std::mt19937 gen;
 
  std::cout << "\nNodes at sampling time :\n";
  std::copy(nodes.begin(), nodes.end(), std::ostream_iterator<node_type>(std::cout, "\n"));
  std::cout << "\n";
 
  auto last = SMM::merge(nodes.begin(), nodes.end(), N, gen);
 
  std::cout << "\nAfter one simultaneous multiple merge generation:\n";
  for(auto it = nodes.begin(); it != last; ++it){
    std::cout << *it << std::endl;
  }
 
  return 0;
}
 
//! [Example]

Un ficher bash compile, l�ex�cute, enregistre l'output. L'output et le code source sont r�cup�r�s par Doxygen.

On est bien d'accord que c'est assez �loign� du test unitaire id�al et c'est sans doute crado, mais bon, �a m'a jusque la permis a moindre co�t de tester des modules ind�pendamment les uns des autres tout en pouvant retourner dans la doc voir comment utiliser telle ou telle classe, tout en me permettant de tester tous les modules avec un petit ./run_all_tests avant de merger mes betises sur la branche master du depot git.

Ma nature parano�aque (pas encore assez pour le compilo semble-t-il) m�encourage a mettre des asserts partout et a v�rifier chaque fonction, et les attendus statistiques des simulations, ce que j'ai fait dans certains cas qui fleurait bon le casse-gueule, mais pas partout non plus parce que [ironie]des tests unitaires complets c'est un luxe que je ne peux pas me permettre et puis �a ruinerait la doc [/ironie].

Voila pour ce que j'ai fait, mais je ne sais pas comment j'aurais du proc�der au mieux. Ce qui est certain c'est que aujourd'hui ce bricolage ne tient plus bien la route. La petite ligne de compilation me semblait tellement minimaliste qu'utiliser Cmake pour �a me paraissait un peu accablant en comparaison.

[jo_link_noir]

Cela dit, l'inconv�nient des listes d'avertissements � rallonge comme la mienne, c'est que, quand on inclut des ent�tes cod�s par d'autres personnes, on se ramasse plein d'avertissements dans la tronche. [...]

Seulement si les paths sont ajout�s avec -I. Avec -isystem, il n'y a pas d'avertissement. Mais c'est vrai que je fais pareil sur un fichier complet lorsque je suis oblig� de passer par des macros C qui sont garnis de cast et pointeur initialis� avec 0.

@Seabirds: L'avantage des syst�mes de build, c'est qu'ils sont pr�vus pour fonctionner sur plusieurs environnements ce qui permet de changer les options et le compilateur assez facilement, ce qui est beaucoup plus souple qu'un script bash avec des valeurs en dures qui m�langent configuration et cible. Il y a aussi un vrai syst�me de d�pendance qui permet de ne compiler que le n�cessaire comme une cible pr�cise ou les tests impact�s par la modification d'un fichier X (m�me si je trouve ctest une catastrophe sur ce point).

Un framework de test est aussi beaucoup plus souple qu'une comparaison d'output. Il poss�de divers macro de comparaison de valeur (�galit�, inf�riorit�, etc) ce qui permet d'avoir tr�s t�t les erreurs avec un affichage beaucoup plus pratique qu'un diff. J'imagine mal comment v�rifier qu'une valeur est diff�rente d'une autre avec une comparaison d'output. Apr�s il y a plus ou moins de chose comme la v�rification d'exception, la s�paration en sc�nario, plein d'options sur la mani�re de lancer les tests, etc. Clairement, c'est un investissement qui vaut le coup.

[Seabirds]

L'avantage des syst�mes de build, c'est qu'ils sont pr�vus pour fonctionner sur plusieurs environnements ce qui permet de changer les options et le compilateur assez facilement, ce qui est beaucoup plus souple qu'un script bash avec des valeurs en dures qui m�langent configuration et cible.

Capito.

Un framework de test est aussi beaucoup plus souple qu'une comparaison d'output.

Beaucoup plus rigoureux aussi, la j'en �tais plut�t au stade du "si d�j� tous ces fichiers compilent et tournent sans casser les 223 assertions �parpill�es ici et la dans le code alors c'est d�j� encourageant". Le saint-graal c'est si en plus avec ces miettes de code pas tr�s bien test�es je peux me d�p�cher d'�crire un programme pas garanti tr�s correct dont la valeur de sortie converge vers la vraie valeur attendue et publier un article sur ma m�thode stat tr�s intelligente avant ma soutenance (sur ce point par contre c'est un �chec)

Il poss�de divers macro de comparaison de valeur (�galit�, inf�riorit�, etc) ce qui permet d'avoir tr�s t�t les erreurs avec un affichage beaucoup plus pratique qu'un diff.

Oui c'est ce que j'avais commence a faire avec Boost test. D'ailleurs, mon d�faut avait �t� de tester trop de trucs et pas forcement les plus pertinents.

J'imagine mal comment v�rifier qu'une valeur est diff�rente d'une autre avec une comparaison d'output.

A vrai dire je ne compare mes output a rien. Histoire de d�finitivement perdre en cr�dibilit� il y a m�me une ou deux section "output" de la doc qui sont vide parce que le code de "test" a planter quelque part...

Clairement, c'est un investissement qui vaut le coup.

Maintenant oui, clairement Mais il y a 1-2 ans, perdu au large de ma th�se sur mon rafiot de code en pleine temp�te, bah j'ai fait des compromis et j'ai pas v�rifi� que mon compas pointait le Nord

Donc si je r�sume bien...

• Ce que j'ai pour l'instant ressemble plut�t a un ensemble de codes d'illustration pour la doc. Dans l'esprit j'ai voulu faire un peu ce qu'on trouve dans la partie Example de cppreference.com: �a teste rien mais y'a garantie que "�a tourne" et �a illustre super bien l'utilisation de la classe (wah d'ailleurs y'a une option "run this code" que j'avais jamais vu!)
• J'aimerai retourner dans le framework de test de boost pour pouvoir me l�cher sur des tests unitaires plus rigoureux
• Et je commence a avoir besoin de tests d�int�grations parce que c'est quand m�me bien pratique de v�rifier que le module A parle bien au module B
• Et j'ai besoin que tout ce joli monde puisse tourner sur diff�rents OS.

Si j'ai bien lu entre les lignes de vos r�ponses, c'est que tout �a c'est faisable/pr�f�rable avec un framework de tests. Et que m�me ce framework de test aura besoin d'un syst�me de build comme CMake, parce que c'est a ce point la que ce fait l'interface avec les diff�rents environnements.

Si oui, bah y'a un peu de boulot ahah

[Invit�]

@Seabirds: je confirme tout � fait ce que dit jo_link_noir. De plus, cmake s'interface assez bien avec doxygen et avec les syst�mes de tests unitaires. Un autre avantage est que c'est facile de r�utiliser un projet cmake dans un autre projet cmake. Et si tes projets sont dans des d�p�ts git, tu peux les int�grer via des sous-modules et c'est tr�s pratique.

[Bktero]

Je valide le couple CMake + Google Test !

Et je valide aussi totalement -isystem � la place / en compl�ment de -I !