Discussion :

[AoCannaille]

Bonjour à tous,

J'aimerais savoir s'il y a un framework, même simpliste, inclut dans les dernières version de C++ ( par dernières, j'entends après C++11)

Mes conditions de travail font que je ne peux rien (absolument rien) changer à mon environnement de développement. J'ai donc accès à un gcc 6.5 et rien d'autre.

J'ai cherché un peu sur C++ références, sur wiki, la fac DVP... et je ne tombe que sur des frameworks externes...

J'espère que c'est parce que j'ai mal cherché, parce que pour l'instant j'en conclu qu'il n'y a rien de prévu dans la STL

Est-ce que quelqu'un qui suit mieux les actualités du langage peut me confirmer/infirmer cette impression très désagréable?


Merci d'avance

[Bousk]

Non il n'y a pas de trucs de tests dans la std.
Il existe plusieurs libs de tests dont je ne me souviens plus les noms...
Après ça dépend ce que tu veux et veux faire ? Pour mes dévs simples, de simple macro me suffisent.

[AoCannaille]

Non il n'y a pas de trucs de tests dans la std.
Il existe plusieurs libs de tests dont je ne me souviens plus les noms...
Après ça dépend ce que tu veux et veux faire ? Pour mes dévs simples, de simple macro me suffisent.

Merci pour la triste confirmation

Je voulais éviter les macros parce qu'elles ne sont pas type safe et que ça date d'un autre temps ^^

Bon bah comme d'hab dans les environnements limités, la b*te et le couteau ^^

[Bousk]

Les macros ne datent pas d'un autre temps et permettent des choses impossible autrement (comme stringifier n'importe quoi).
La plupart des frameworks de TU utilisent des macros.

[AoCannaille]

J'en ai conscience, mais entre utiliser des macro robustes et développer les miennes en sachant que ça reste toujours plus ou moins indébuggable, j'aurais préféré avoir un truc déjà prêt

[koala01]

Salut,

Ceci dit, si toi, tu n'as pas le droit de modifier ton système (ce que l'on peut comprendre du point de vue du patron, mais qui pose quand même pas mal de problème du point de vue du développeur ), il te reste toujours la possibilité de "faire ch...er" celui qui a le droit de le faire pour qu'il t'installe un environnement "correct"; par exemple, en insistant pour qu'il t'installe boost, googletest ou, "plus simplement" Catch2 en précisant que tu ne pourras rien faire de bon dans qu'elles n'auront pas été installées .

Et, qui sait, les deux premières bibliothèques sont assez difficiles à installer pour que tu puisse faire comprendre au responsable que, s'il veut que tu puisse travailler "correctement", sans devoir venir le "faire chier" à chaque fois que tu as besoin d'un outil particulier (si cela ne suffit pas, demande lui juste après de t'installer CMake, et, après, Doxygen et GraphViz, et enfin git juste pour rire ) et attendre qu'il ait le temps de s'occuper de ta demande (tout à fait raisonnable et nécessaire), il serait utile qu'il comprenne que tu n'est pas vraiment le premier clampain auquel il fournit un ordinateur, et qu'il devra "te faire confiance" pour ne pas aller installer toi-même les outils dont tu as besoin (qui sont tout à fait spécifiques par rapport à n'importe quel employé) sans aller installer n'importe quelle cochonnerie,

En tant que développeur, il faut bien comprendre (et arriver à faire comprendre au responsable) que tu as besoin d'utiliser des outils et des éléments dont les "utilisateurs classiques" n'ont jamais même entendu parler, et que ces besoins apparaissent souvent au fil du temps.

Plutôt que de t'engueuler simplement avec le responsable, je te proposes de lui en faire prendre conscience "en douceur", en le faisant chier pour qu'il installe ces outils au fur et à mesure .

Et si cela ne suffit pas, il te reste toujours le choix de changer de travail pour arriver dans une société qui sera consciente de tes besoins spécifiques .

Car il n'y a rien à faire, j'ai travaillé dans des grandes boîtes, qui sécurisaient elles aussi "autant que faire ce peut" les ordinateurs qu'elles mettent à disposition de leur employés. Mais toutes avaient bien compris que le développeur n'est pas un utilisateur lambda, et qu'il doit disposer d'une "certaine liberté" de mouvement.

La possibilité d'installer (ou de mettre à jour) des outils spécifiques et, surtout, de bibliothèque tierce fait partie de cette liberté de mouvement et des besoins qui lui sont propres pour pouvoir faire son travail correctement

[Pyramidev]

J'en ai conscience, mais entre utiliser des macro robustes et développer les miennes en sachant que ça reste toujours plus ou moins indébuggable, j'aurais préféré avoir un truc déjà prêt

Ben, voilà :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
#include <iostream>
 
#ifdef CHECK
# error CHECK is already defined.
#endif
#define CHECK(cond) \
	if((cond) == false) { \
		++errorCount; \
		std::cerr << "Fail: " << __func__ << ": " << #cond << '\n'; \
	} else \
		static_cast<void>(0)

Exemple de code :

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
#include <iostream>
 
#ifdef CHECK
# error CHECK is already defined.
#endif
#define CHECK(cond) \
	if((cond) == false) { \
		++errorCount; \
		std::cerr << "Fail: " << __func__ << ": " << #cond << '\n'; \
	} else \
		static_cast<void>(0)
 
int test_add() {
	int errorCount = 0;
	CHECK(1 + 2 == 3);
	CHECK(4 + 5 == 9);
	return errorCount;
}
 
int test_minus() {
	int errorCount = 0;
	CHECK(10 - 1 == 9);
	CHECK(1 - 10 == -9);
	return errorCount;
}
 
int test_all() {
	int errorCount = 0;
	errorCount += test_add();
	errorCount += test_minus();
	return errorCount;
}
 
int main() {
	int errorCount = 0;
	errorCount += test_all();
	if(errorCount == 0)
		std::cout << "Success.";
	else
		std::cout << "Error count: " << errorCount << '.';
	return errorCount;
}

Il n'y a pas autant de fonctionnalités que dans un framework de tests unitaires, mais ça marche et ça compile vite.
Dans mon code perso, j'ai fini par laisser tomber Boost.Test dont le temps de compilation excessif dissuadait de recompiler les tests unitaires.
Je ne sais pas quel est le meilleur framework de tests unitaires en C++. Mais je rejoins Bousk sur un point : parfois, de simples macros suffisent.