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 !