Discussion :

[Iradrille]

Ce qui passe en Core, ce sont les modules avec la modularisation totale des macros, qui ne franchiront donc pas les frontières d'un module, ni dans un sens ni dans l'autre (c'est ce qui était proposé par Gaby). Par contre, plusieurs personnes pensent qu'une telle isolation est extrémiste, et que quelques macros, c'est une bonne chose (et que la manière proposée qui consiste à continuer avec des #include quand on ne veut pas de l'isolation n'est pas satisfaisante). C'est surtout une position défendue par les gens de Clang.

Il resterait possible de définir des macros globales ? Je pense notamment à des macros comme DEBUG.

[JolyLoic]

L'idée de base d'un module, c'est qui puisse être compilé indépendamment, et que l'ordre d'inclusion ne compte pas. Donc si tu définis NDEBUG dans ton code, même si tu le fais avant d'importer des modules, les modules en question ne seront pas impactés. Seul ton code le sera. Si tu veux un module en mode debug, récupère une version différente du module compilée avec des options différentes.

Je ne sais pas trop si la proposition des gens de Clang gèrerais cette situation, j'ai l'impression qu'ils se focalisent plus sur le fait qu'un module puisse exporter une macro à son utilisateur que par le fait qu'un module dépende d'une macro définie par son utilisateur.

[Aurelien.Regat-Barrel]

Tu m'as fait très peur quand j'ai lu ça !
J'ai consulté les notes prises en réunion, et mon interprétation est fort heureusement différente !

Désolé de t'avoir fait si peur ! Effectivement j'ai du lire trop vite les notes car je n'étais pas là au moment des débats. En revanche j'étais là au moment des échanges sur les détails d'implémentation, et c'était assez tendu comme échanges, notamment à cause du format binaire utilisé par l'implémentation de Gaby pour les modules. Ce format devrait être ouvert et documenté, et paradoxalement, tout le monde ne voit pas cela d'un bon oeil.
Je vais voir avec Gaby dans un futur proche pour faire un petit récapitulatif de tout ça.

Qu'entends-tu par là ? Tu sais qu'il y a quelques français qui participent régulièrement à ces discussions, et qu'on est en train de voir pour obtenir à nouveau la possibilité de voter lors des réunions. Tu voudrais faire quelque-chose autour de ça, ou bien tu as autre chose en tête ?

Je sais qu'il y a des échanges en cours avec l'AFNOR en ce sens, et j'apprends aujourd'hui que pour le langage C ils sont apparemment pas loin de pouvoir monter un groupe aussi. Je pense juste organiser des rencontres pour qu'on puisse mieux faire connaissance et voir comment on peut mieux collaborer tous ensemble !

[Aurelien.Regat-Barrel]

A propos de la programmation par contrat

Il y a eu deux sessions du soir sur le sujet, et les échanges ont été très intenses. Au final, tout le monde était satisfait des avancées. La piste explorée pour la PpC est de spécifier les pré-conditions via des attributs, dans ce genre:

Code :

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

1
2
3
[[pre: n >= 0 && n < size()]]
T & operator[](int n) noexcept {
}

Le point qui a posé beaucoup de problèmes est de savoir quoi faire quand le contrat n'est pas respecté.

Il a été discuté de pouvoir spécifier l'exception levée au niveau du contrat, dans ce genre: [[pre(logic_error): n >= 0 && n < size()]]. Mais la distinction entre préciser le contrat d'une part, et préciser que faire quand le contrat est rompu d'autre part a été faite. En effet, préciser comment réagir dans le contrat modifie le contrat de départ.

L'autre point de discussion intense concerne le fait que l'utilisateur remplace le handler par défaut par son propre handler. Que se passe-t-il si l'utilisateur lance une exception depuis ce handler, alors que la fonction dont le contrat a été rompu est marqué noexcept?

Un consensus a été trouvé qu'une fonction noexcept doit toujours rester noexcept, et donc si le handler lance une exception dans un tel cas, alors le programme est terminé.

De ce que j'ai pu en comprendre, il semble que les bases aient été posées pour pouvoir discuter de l'intégration de la PpC à C++ lors des prochains meetings.

Pour ceux que ce sujet intéresse, il est important de regarder la conférence de John Lakos "Defensive programming done right" pour avoir toutes les notions de base. A noter que les post-condition ne semblent pas être au menu. D'après John tester les post-conditions revient à tester son propre code et les gens veulent le faire juste par mimétisme avec les pre-conditions même si ça n'a pas grand sens (c'est ma compréhension de ce qu'il m'a dit).

[Luc Hermitte]

Il y a eu deux sessions du soir sur le sujet, et les échanges ont été très intenses. Au final, tout le monde était satisfait des avancées.
a- La piste explorée pour la PpC est de spécifier les pré-conditions via des attributs, dans ce genre:

Code :

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

1
2
3
[[pre: n >= 0 && n < size()]]
T & operator[](int n) noexcept {
}

b- Le point qui a posé beaucoup de problèmes est de savoir quoi faire quand le contrat n'est pas respecté.

Il a été discuté de pouvoir spécifier l'exception levée au niveau du contrat, dans ce genre: [[pre(logic_error): n >= 0 && n < size()]]. Mais la distinction entre préciser le contrat d'une part, et préciser que faire quand le contrat est rompu d'autre part a été faite. En effet, préciser comment réagir dans le contrat modifie le contrat de départ.

L'autre point de discussion intense concerne le fait que l'utilisateur remplace le handler par défaut par son propre handler. Que se passe-t-il si l'utilisateur lance une exception depuis ce handler, alors que la fonction dont le contrat a été rompu est marqué noexcept?

Un consensus a été trouvé qu'une fonction noexcept doit toujours rester noexcept, et donc si le handler lance une exception dans un tel cas, alors le programme est terminé.

c- De ce que j'ai pu en comprendre, il semble que les bases aient été posées pour pouvoir discuter de l'intégration de la PpC à C++ lors des prochains meetings.

d-Pour ceux que ce sujet intéresse, il est important de regarder la conférence de John Lakos "Defensive programming done right" pour avoir toutes les notions de base. A noter que les post-condition ne semblent pas être au menu. D'après John tester les post-conditions revient à tester son propre code et les gens veulent le faire juste par mimétisme avec les pre-conditions même si ça n'a pas grand sens (c'est ma compréhension de ce qu'il m'a dit).

a- J'aime bien. Cela a l'avantage d'être présent dans le prototype des fonctions. On rejoint pleins de papiers (hormis ceux de John Lakos qui n'exploraient que la piste de la vérification dynamique)

b- L'idéal est bien évidemment le support par des outils d'analyse statique de code/de preuve formelle. Mieux vaut savoir avant la première exécution que sqrt(sin(x)-1) peut poser des problèmes. C'est là que la spécification dans les signatures importe. Ainsi du code client peut savoir ce qu'il doit respecter. Si on embarque la spec uniquement dans l'implémentation (voie des assertions), c'est plus compliqué pour annoter les binaires de façon portable (sur une même machine) ... déjà que l'on n'a même pas d'ABI.

Les autres possibilités sont
- les assertions, déjà utiles et utilisées pour la vérification des préconditions en phase de dev & test -- mais cela sous entend des modes de compilation (sans vérifications, avec vérifications légères, avec toutes les vérifications (même si elles coutent très cher))
- les TU pour les post-conditions (cf la conf de John Lakos)
- les exceptions pour passer en mode défensif en production quand on n'a pas confiance. Si on passe la phase d'analyse statique, j'ai envie de dire que cette approche n'aura plus grand intérêt. De plus, ce mode si pratique pour des TU qui exécutent plein de choses, il est beaucoup moins pratique pour investiguer dans de bonnes conditions -- assert est parfait pour un coredump, avec les exceptions, il faut feinter. Reste qu'il semble que ce soit elle qui mette la pagaille d'après ce que tu nous rapportes.

c- J'ai vu à ce propos qu'ils confiaient la rédaction des prochains papiers à des gens qui n'étaient pas encore impliqués sur le sujet, histoire de garder une neutralité.

d- Et les 3 derniers billets de mon blog aussi


A noter qu'avec ces évolutions, le pattern NVI va perdre son utilisation principale.

[Aurelien.Regat-Barrel]

Pour être sûr d'avoir été bien compris pour /b, ce qui a été débattu c'est de la possibilité, dans le contrat, de spécifier le nom de l'exception levée si le contrat est violé, dans ce genre :

[[pre(logic_error): n >= 0 && n < size()]].

en cas de violation du contrat, std::logic_error serait levée... c'est ce point là qui a suscité beaucoup de controverse avant de pouvoir formuler correctement que la gestion du non respect du contrat n'avait pas à se trouver mélangée avec la spécification même du contrat.

[white_tentacle]

Pour ceux que ce sujet intéresse, il est important de regarder la conférence de John Lakos "Defensive programming done right" pour avoir toutes les notions de base. A noter que les post-condition ne semblent pas être au menu. D'après John tester les post-conditions revient à tester son propre code et les gens veulent le faire juste par mimétisme avec les pre-conditions même si ça n'a pas grand sens (c'est ma compréhension de ce qu'il m'a dit).

J’ai l’impression que John Lakos est passé à côté de l’intérêt principal des postconditions. Dans sa présentation (que je recommande chaudement à tout le monde par ailleurs, en complément des billets de luc et de l’article sur ce site), il détaille les postconditions comme l’explication sémantique de la valeur de retour (cf son exemple sur sqrt). Effectivement, ça ne sert pas à grand chose.

En revanche, il est tout à fait possible de définir des postconditions « utiles ». Ces postconditions doivent plutôt être de la forme « qu’est-ce que je garantis sur mes valeurs de retour ? ». Par exemple, une postcondition « utile » de sqrt et « return_value >= 0 ». C’est beaucoup plus utile car cela peut être utilisé derrière par un analyseur de code statique (qui va pouvoir détecter un appel correct avec une fonction dont la précondition est x >= 0). Dans la même veine, on peut citer la garantie de non-nullité d’un pointeur retourné.

en cas de violation du contrat, std::logic_error serait levée... c'est ce point là qui a suscité beaucoup de controverse avant de pouvoir formuler correctement que la gestion du non respect du contrat n'avait pas à se trouver mélangée avec la spécification même du contrat.

C’est une très bonne chose qu’ils soient arrivés à ce consensus. Faire l’inverse aurait entraîné une grande confusion entre programmation par contrats et programmation défensive (déjà que les gens ont du mal à voir la différence…).

[Iradrille]

Code :

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

1
2
3
[[pre(logic_error): n >= 0 && n < size()]]
T & operator[](int n) noexcept {
}

J'espère que ça verra jamais le jour cette forme là : un contrat qui contredit le prototype, ça ne devrait pas compiler tout simplement.

[Luc Hermitte]

John Lakos n'a pas tord de dire que la post-condition de sqrt est de renvoyer un nombre telle que son élévation au carré vaut la paramètre entrant, à un epsilon près. Après les maths font que x*x est positif. Sur sqrt ce n'est pas très flagrant, mais sur sort() ou sur sin(), cela devient plus complexe et il peut être intéressant de pouvoir disposer de la post-condition complète.
Si nous avons une propriété sur chaque élément d'un conteneur et que l'on trie ces éléments, si on a la garantie qu'il n'y ait pas de synthonisation de nouveaux éléments ou d'altération de ceux déjà en place, alors cette garantie est gardée après le sort(). e.g. Un conteneur de nombres positifs que l'on trie est un conteneur trié de nombres positifs et pas juste un conteneur trié.

Souvent on se contente de la garantie utile évidente, mais dans de la preuve formelle, je ne vois pas pourquoi nous ne pourrions pas aller plus loin.
Après, John Lakos me semblait plus dans la voie des assertions et des tests unitaires que celle de la preuve formelle que d'autres ont réintroduit dans les discussions.

-----
J'ai eu la même conclusion pour le mélange spécification des exceptions dans le contrat : ouf!

[Luc Hermitte]

Code :

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

1
2
3
[[pre(logic_error): n >= 0 && n < size()]]
T & operator[](int n) noexcept {
}

J'espère que ça verra jamais le jour cette forme là : un contrat qui contredit le prototype, ça ne devrait pas compiler tout simplement.

J'ai l'impression que l'on commence à retomber sur les problématiques qu'un langage très axé sur la programmation défensive a déjà rencontrées. En Java, les runtime errors (si je me souviens bien du vocabulaire, et si je ne dis pas de bétise) échappent aux spécifications obligatoires d'exceptions. Et il se trouve que justement, les erreurs de logiques (comme des paramètres invalides, des null pointers) sont celles appelées "runtime error".

[Iradrille]

J'ai l'impression que l'on commence à retomber sur les problématiques qu'un langage très axé sur la programmation défensive a déjà rencontrées. En Java, les runtime errors (si je me souviens bien du vocabulaire, et si je ne dis pas de bétise) échappent aux spécifications obligatoires d'exceptions. Et il se trouve que justement, les erreurs de logiques (comme des paramètres invalides, des null pointers) sont celles appelées "runtime error".

Je connais très mal Java, mais en C++ ça pose un problème :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
[[pre(logic_error): n >= 1]]
void bar(int n) noexcept {
 
}
 
struct Foo { };
 
int main() {
   Foo *foo =  new Foo(); // si ça throw pas de leak
   bar(0); // si ça throw, on leak foo, mais c'est noexcept donc on devrait être tranquille
   delete foo;
   return 0;
}

[Luc Hermitte]

Je sais bien. Mais ma question sous-entendue : les exceptions de logiques devraient-elle vraiment aller dans le même sac que les autres exceptions ? -- certes le C++ a une spécification technique des exceptions et de fait, cela ne va pas être possible de faire autrement.

Ceci dit ... AMA, la meilleure chose que l'on puisse faire d'une exception de logique : un core-dump (comment ça c'est ce que fait déjà assert et je suis un peu extrémiste en matière d'erreurs de programmation ?)

[Iradrille]

Ceci dit ... AMA, la meilleure chose que l'on puisse faire d'une exception de logique : un core-dump (comment ça c'est ce que fait déjà assert et je suis un peu extrémiste en matière d'erreurs de programmation ?)

J'aime beaucoup aussi, plein d'infos pour debug, et de toutes façons ce sont des erreurs de programmation / algo qui ne devraient pas arriver et qu'on ne peut pas récupérer (généralement).

[prgasp77]

Ceci dit ... AMA, la meilleure chose que l'on puisse faire d'une exception de logique : un core-dump (comment ça c'est ce que fait déjà assert et je suis un peu extrémiste en matière d'erreurs de programmation ?)

J'aime beaucoup aussi, plein d'infos pour debug, et de toutes façons ce sont des erreurs de programmation / algo qui ne devraient pas arriver et qu'on ne peut pas récupérer (généralement).

Une application ayant des contraintes de stabilité ne devrait pas core-dumper si elle rencontre une erreur, même grave, sur une partie du service rendu. Dans la majorité des cas, le core-dump est préférable ; mais dans la poursuite de la logique C++ ça ne devrait pas être imposé. Après tout, pour avoir un core-dump ne suffit-il pas de lever une exception catché nulle part ?

[ternel]

Et on ne peut pas juste rien faire, et laisser planter comme ca le sans contrat?

Il suffirait d'attendre que les respects de contrats soit détectables à la compilation.

[Iradrille]

Une application ayant des contraintes de stabilité ne devrait pas core-dumper si elle rencontre une erreur, même grave, sur une partie du service rendu. Dans la majorité des cas, le core-dump est préférable ; mais dans la poursuite de la logique C++ ça ne devrait pas être imposé. Après tout, pour avoir un core-dump ne suffit-il pas de lever une exception catché nulle part ?

Je suis bien d'accord avec ça (contrainte de stabilité), je parlais du cas spécifique

Code :

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

1
2
3
4
[[pre(logic_error): n >= 1]]
void bar(int n) noexcept {
 
}

Soit c'est noexcept, soit ça l'est pas.

Après de manière générale je trouve que les exceptions sont trop utilisées, il y à pas mal de cas où un assert est meilleur (à mon goût).

[white_tentacle]

Une application ayant des contraintes de stabilité ne devrait pas core-dumper si elle rencontre une erreur, même grave, sur une partie du service rendu. Dans la majorité des cas, le core-dump est préférable ; mais dans la poursuite de la logique C++ ça ne devrait pas être imposé.

Ça ne l’est pas (imposé). C’est pour ça qu’une rupture de contrat doit rester un UB.

Cela dit, la contrainte de stabilité impose que tu aies une vraie politique de gestion de tes propres bugs. Un seul gros try/catch tout en haut, c’est complètement insuffisant.

Après tout, pour avoir un core-dump ne suffit-il pas de lever une exception catché nulle part ?

Le problème est que des gens se sont dit que c’était une bonne idée de tout catcher. Par exemple, la boucle principale d’une QApplication catche tout --> assert est nettement meilleur que throw pour détecter les problèmes.

[prgasp77]

Un seul gros try/catch tout en haut, c’est complètement insuffisant.

100% d'accord.

Le problème est que des gens se sont dit que c’était une bonne idée de tout catcher.

100% d'accord.

Bon, je pense que je viens d'écrire mon message sur dvp avec le moins de valeur ajoutée depuis dix ans !

[Aurelien.Regat-Barrel]

J’ai l’impression que John Lakos est passé à côté de l’intérêt principal des postconditions.

Si j'ai bien compris sa position, les post-conditions devraient être testées dans des tests unitaires. Ou dit autrement : tester les post-cond directement dans son code, c'est embarquer des TU dans son code.

Soit c'est noexcept, soit ça l'est pas.

C'est bien ce qui a été décidé, après avoir un certain temps exploré une piste où y'aurait 2 version de noexcept en C++

Il suffirait d'attendre que les respects de contrats soit détectables à la compilation.

La vérification des contrats par analyse statique de code est une fonctionnalité supplémentaire attendue en complément de l'analyse dynamique par le langage (certainement désactivable au niveau du compilo).

Le problème est que des gens se sont dit que c’était une bonne idée de tout catcher. Par exemple, la boucle principale d’une QApplication catche tout --> assert est nettement meilleur que throw pour détecter les problèmes.

Dans la cas de QApplication, c'est une contrainte technique. En effet, le code C++ [d'un slot] est appelé en tant que callback depuis une dll C du système (suite à un event, genre clic de souris). Si une exception C++ remonte jusqu'à l'appelant C, alors ça va mal se passer. C'est pour ça qu'elles doivent toutes être capturées.

[white_tentacle]

Si j'ai bien compris sa position, les post-conditions devraient être testées dans des tests unitaires. Ou dit autrement : tester les post-cond directement dans son code, c'est embarquer des TU dans son code.

Sur ce point, il a parfaitement raison. Les postconditions sont avant tout utiles pour l’analyse statique et pour la doc.

Néanmoins, compte tenu des limitations des TUs (on ne teste jamais pour l’ensemble des entrées possibles), cela a du sens de garder la vérification des postconditions / invariants dans une build « debug ».