Discussion :

[Invité]

Code :

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

1
2
3
4
5
if(topology.isValid())
{
    do_something_that_require_topology_is_valid();
    do_something_else_that_require_topology_is_valid();
}

Ben pour moi, c'est correct. Il faut topology is valide, on vérifie que topology est valide. (à supposer qu'on ne le sait pas déjà valide). (j'ose espérer que topology
étant une globale, soit valide...).

Le seul défaut qu'on pourrait faire, c'est que fonctionnellement parlant, ca suppose qu'il existe un traitement pour le else. Alors qu'il s'agit peut être ici, d'un cas d'erreur. (dans le sens, topology ne devrait jamais etre non valide).
Auquel cas, exception.

Code :

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

1
2
3
4
5
6
 
if(!topology.isValid()){
 throw;
}
do_something_that_require_topology_is_valid();
do_something_else_that_require_topology_is_valid();

mais je vois pas le lien.

[white_tentacle]

Code :

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

1
2
3
4
5
if(topology.isValid())
{
    do_something_that_require_topology_is_valid();
    do_something_else_that_require_topology_is_valid();
}

Ben pour moi, c'est correct. Il faut topology is valide, on vérifie que topology est valide. (à supposer qu'on ne le sait pas déjà valide). (j'ose espérer que topology étant une globale, soit valide...).

Et pourtant, rien ne te garantit que ta première fonction n’invalide pas topology… Du coup, même hors multithread, le code peut potentiellement être faux. La correction « à minima », c’est

Code :

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

1
2
3
4
if(topology.isValid())
    do_something_that_require_topology_is_valid();
if(topology.isValid()) // ma topology est-elle toujours valide ?
    do_something_else_that_require_topology_is_valid();

Mais si do_something_that_require_topology_is_valid prend un const topology& en paramètre, alors, tu es tranquille et tu n’as pas besoin de répéter ton test. Et tu peux même rajouter un appel à do_something_completely_different(), tu sais que cela n’affectera pas topology.isValid().

Et s’il n’est pas const, alors, tu dois te référer à la documentation, qui seule est à même de t’informer. Et avec un peu de chance, le programmeur pensera à documenter les postconditions de sa fonction, et notamment si elle garantit topology.isValid(). Je t’accorde qu’il y a de bonnes chances qu’il ne le fasse pas, mais ce qui est sûr, c’est qu’il ne le fera pas si topology est une globale.

Si tu penses que j’en***e les mouches, c’est que tu as eu plus de chance que moi sur le code que tu as rencontré dans ta vie. Loïc a cité l’exemple de strtok. J’ai vu des cas avec des handle de connexion à la base de données invalidé par des fonctions (certes, douteuses) dont on ne se serait pas douté qu’elles touchaient à ça. Et ça donne des problèmes difficile à débugger.

[Invité]

nan mais si ta fonction invalide topology, elle doit le préciser dans son contrat. Sinon tu violes le gars qui a fait l'implémentation.
La programmation défensive comme ca c'est une plaie.

edit: et oui je pense que t'**** des mouches
Si tu dois tester dans toutes tes fonctions que topology isValid, on est pas rendu!

edit2: je comprends bien l'idée sous jacente de la signature de fonction qui montre explicitement qu'on va modifier l'objet.
Après si topology présente plusieurs états...avec des comportements différents quelquesoit l'architecture,