Folly, la bibliothèque C++ de Facebook

[Klaim]

Envoyé par Ekleog

Auquel cas, un équivalent exceptions qui permet de conserver la remontée de pile automatique (bien sûr, si on ne cherche de travail que pour les assertions ça ne servira à rien, mais bon...) :

Ca depends. Une simple macro d'assertion (quelle que soit son comportement) "poluera" moins le code que ce que tu proposes, sauf dans les parties qui sont censes logger les erreurs. Comme souvent ce log se passe dans une macro d'assertion, ce que tu proposes deviens moins efficace.

Dans tous les cas, personnellement je preferes avoir des macro d'assertion testables, qui potentiellement peuvent lancer des exception..ou pas, mais qui log puis debugbreak avant de faire quoi que ce soit d'autre.

(je sens qu'on a completement change de sujet au passage).

Où est donc le coût des exceptions ? (A part dans le poids mémoire du runtime __cxa_*, qui sera probablement de toute façon inclus, sauf peut-être si -fno-exceptions est passé.)

Je vais omettre la memoire un instant et suggerer que tu testes sur le code d'un projet de la complexite d'un jeu. Je veux dire, un jeu ou les perfs sont importantes. Genre.. par exemple prends Ogre, compile avec et sans et lance les tests.
L'exemple que tu donnes n'a aucun interet parcequil est evident meme pour le le compilateur, tandis que si tu commences a complexifier c'est un autre sujet.

Cela dit je n'ai pas le temps de faire le test moi meme, pardon.

En revanche il est important de signaler que beaucoup d'ameliorations (en particulier dans gcc) ont ete faites pour effacer ce probleme, aucours des dernieres annees.

Je n'ai pas compare aujourdhui mais ca serait interessant de faire un test complet, avec msvc, clang et gcc, voir l'impact aujourdh'ui, sur un projet de jeu.

J'aurais bien propose un de mes projets comme sujet, peut 'etre ce prototype? http://radiantlasercross.com mais je n'ai jamais pris le temps de le compiler pour autre chose que msvc.

[Freem]

Envoyé par Ekleog

=> ?
Là, je ne comprense pas.
C'est de l'humour, peut-être ?

Non, je me suis juste mal exprimé... je pensais aux contrôle d'erreur au sens large du terme, c'est à dire que je pense que mettre un saut classique vaut toujours mieux que rien, même si je préfère les exceptions au sauts classiques.

Envoyé par Klaim

Cela étant dis, hors du contexte d'un jeu console, pour une console des anciennes générations du moins, cet argument ne tiens plus.

Reste à définir le terme ancienne génération, alors, je suppose.
Effectivement, dans le cas d'un environnement maîtrisé à 100%, les exceptions n'ont pas lieu d'être. Mais maîtrisé à 100% implique 0 connectivité au monde extérieur.
Je n'ai jamais été un "consoleux" mais il me semble que la DS permet le multi-joueur en connectant plusieurs consoles, non?
De ce fait, il y a un réseau qui se crée...
Sinon, il y a aussi l'option ou le dev ne fait pas d'allocation dynamique, et que du coup, il n'y a pas de risque de buffer overflow. Sinon, risque d'explosion, encore une fois.
Cela dis, pour tempérer mes propos, j'ajouterai qu'en plus de ne jamais jouer sur console que chez quelques potes, je n'ai jamais non plus développé de jeux pour console (et de façon générale, un part un casse-brique en basic sur ma TI82 au lycées, pas vraiment fait de jeux... et clairement l'environnement était contrôlé à 95% sur TI - restait le dépassement de capacité a éviter lors des copies de matrices qui représentaient les niveaux/sauvegardes mais je n'avais de toute façon aucune façon de les gérer - )

Pour le point sur l'activation des exceptions: en théorie on est censé ne pas payer si il n'y a aucun throw de fait. Dans la pratique on paye mémé dans ce cas.

Ma mémé a plus de sous que moi, c'est p'tet pour ça
Blague à part (c'était juste pour me dérider en ce jeudi au temps pourri) il y a ce thread sur SO:
http://stackoverflow.com/questions/6...n-handling-add

Et les 2 premiers posts, avec leurs scores semblent montrer que globalement, le surcoût des exception est négligeable, tant au niveau de la taille du binaire que de l'exécution.

Envoyé par Klaim

Oui mais la encore il y a subtilité.
Quel est l'effet d'une assertion? Log + crash souvent.

C'est aussi ainsi que les profs que j'ai eus me décrivaient le rôle d'une exception. Le but du jeu n'était pas que le programme survive, selon leurs explications, juste que le dev ait un rapport de bug plus complet limite... En même temps, on ne les as que survolées (et il n'a jamais été précisé que printf/scranf ont des valeurs de retours)...
La ou j'ai commencé à comprendre leur rôle, c'est le jour ou je suis tombé sur un document traitant de l' "exception safety" de Boost.

Envoyé par Klaim

Enfin bref, ce que je veux dire c'est que comprendre l'ampleur et du sujet mais aussi comprendre que les termes employés ont tendance à englober trop de choses qui ne sont pas forcément sous entendues par toutes les parties de la discussion, fait que les discussions tournent rapidement steriles sur le sujet...

C'est sûr.
Personnellement, quand je pense aux assertions, je pense à "assert()".
Du coup, c'est automatiquement supprimé quand je passe en mode release.
Depuis C++11, je devrais aussi penser à "static_assert()" (ou un truc du genre) qui permet juste une vérification par le compilo, et n'a donc aucune influence dans le binaire.
Donc, du code censé contrôler les problème de code, les bugs introduits par le dev.

Ah, c'est vrai, on pourrait aussi penser aux exceptions "std::logic_error" mais je ne sais pas quels sont leurs rôles et cas d'utilisations, donc j'ai tendance à ne pas y penser.
Surtout qu'en général, en cas d'erreur de logique, ça me mène au crash peu après
Donc je vois plus les exceptions, et contrôles d'erreurs en if, comme un moyen de prévenir et traiter les évènements sur lesquels on a aucune prise lors de la programmation:
_ mémoire insuffisante pour traiter une opération
_ rupture de réseau
_ fichier d'entrée corrompu
_ saisie utilisateur foireuse (genre il entre un texte dans un champ où on lui demande de mettre un nombre, et la conversion foire en lançant une exception)

Envoyé par Klaim

(je sens qu'on a completement change de sujet au passage).

En effet

PS: ta démo pourrait devenir un jeu d'arcade relativement fun

[Luc Hermitte]

Envoyé par Klaim

Oui mais la encore il y a subtilité.

Quel est l'effet d'une assertion? Log + crash souvent.

Mais pour un jeu ça peut etre problématique. Une série d'assertions peuvent donner plus d'indices sur l'ampleur d'un probleme qu'une seule assertion qui fait tout crasher.

Du coup beaucoup d'assertions sont implémentées pour logger et etre evaluable optionellement, pour quand meme generer du code dans le cas ou l'assertion ne passe pas OU pour crasher OU pour lancer une exception.
En plus les assertions sont rarement gardées dans le code d'un jeu, ils sont utilisés seulement dans des versions "debug" ou "release debug" du jeu, pour des soucis de performances.

[...]

Enfin bref, ce que je veux dire c'est que comprendre l'ampleur et du sujet mais aussi comprendre que les termes employés ont tendance à englober trop de choses qui ne sont pas forcément sous entendues par toutes les parties de la discussion, fait que les discussions tournent rapidement steriles sur le sujet...

Il y a un truc qui me perturbe dans ta réaction à mon intervention.
Et je crois que j'ai enfin trouvé : une assertion en phase de dév va non seulement crasher, mais aussi et surtout provoquer un core dump (man ulimit pour ceux sous *nix qui n'ont pas de core générés).
Et un fichier core, c'est juste royal car la pile d'appel (sur tous les threads) est stockée au moment du crash.
Nul besoin d'avoir une série de logs quand on dispose d'un état complet du programme au moment du plantage (et donc l'état de toutes les variables qui étaient encore en train de vivre).

Il n'y a de fait pour moi aucune subtilité.
- erreur de prog -> assertions => core dump => état complet (au détail des optims faites à notre insu et de certaines résolutions de meta-prog template) au moment du plantage.
- erreur dans le contexte (très bien explicité par Freem) -> 110000 ifs, ou des exceptions. Et ça, ce n'est pas désactivable dans le produit final.
Et ici même la question initiale se pose : "if ou exception?" ; "Quel est le mécanisme qui coute le moins cher -- quand non buggué -- sur la plateforme ciblée ?"
(et effectivement, deux des articles traduits (/en cours de) couvrent ce sujet)


Maintenant si les consoles ne peuvent pas générer de fichiers core (ou équivalent), je comprends que la situation soit pourrie et que vous deviez pervertir le fonctionnement des assertions pour tracer des choses comme la pile d'appel. Car je suis d'accord, un crash sans fichier core, cela n'apporte rien.

(oui on peut forker la discussion)



Reste le sujet connexe de la programmation défensive qui n'a pas encore été proprement abordé.

[Klaim]

Ce que j'essayais vainement d'expliquer c'est que a part tester une verite, l'implmentation d'une assertion est vraiment totalement dependante de ce qu'on veut qu'elle fasse. Par exemple j'ai vu des assertions qui font ce que tu decris, mais aussi des assertions qui ne font que logger (quelle que soient les infos et leur forme, ca peut ne pas etre du texte) et continuer ensuite, ou bien crasher, ou bien juste declencher un debugbreak, etc.

Selon les types de jeux avoir des assertions qui stoppent le programme peut 'etre problematique meme si c'est bon pour que les programmeurs continuent a bosser.

Du coup toutes les assertions ne sont pas equivalentes, et beaucoup de gens basent leur definition sur ce qu'ils ont vu et manipule alors que dans la pratique la variete de comportement des assertions est suffisamment importante pour facilement embrouiller une discussion comme celle ci.