C’est un paragraphe qui parle du paradigme fonctionnel justement. Il faudra ajouter une remarque sur le fait que l’exemple n’est que partiellement fonctionnel, mais que ce mélange est une force du langage.
Le chapitre sur la documentation avance bien. Il reste la partie sur les bonnes pratiques à écrire. Ensuite, dans le chapitre d’après, nous aborderons la compilation.
Bonjour les agrumes !
La bêta a été mise à jour et décante sa pulpe
à l’adresse suivante :
Remarque: dans le dépôt Fedora, il faut installer un autre paquet que doxygen pour avoir doxywizard (doxygen-doxywizard) donc il faudrait peut-être le préciser (peut-être le même problème dans d’autres distros GNU/Linux)
@warning permet d’ajouter des avertissements. On peut vouloir prévenir, par exemple, qu’une fonction ne doit pas être utilisée en même temps qu’une autre ==> thread-safe/réentrance ?
un mauvais commentaire peut paraitre ==> paraître(accent circonflexe)
Voilà c’est tout ce que j’ai comme remarque pour l’instant, mais sur le contenu c’est nickel.
Bonne soirée,
EDIT: Dans la partie III - 3 - Installer une bibliothèque: Vous allez parlez de Boost ou genre autre lib' type SFML ? (peut-être parler des header-only et des Shared Lib et Static)
J’ai ajouté le paquet supplémentaire ainsi qu’une note pour indiquer de se référer à la documentation de leur distribution.
C’est juste French, mais j’ai ajouté.
Merci.
Je ne pensais pas à ça, plutôt des fonctions qui font un peu le même travail et qui ne doivent pas s’utiliser en même temps pour ne pas se marcher sur les pieds.
C’est un oubli de notre part, on va rajouter les énumérations dans le chapitre consacré.
Merci.
Je chipote, mais si on se base sur la nouvelle orthographe, le î n’est plus obligatoire.
Merci beaucoup pour les retours et les encouragements.
Oui c’est prévu de parler de tout ça. Boost on y a pensé, mais pas SFML. J’avoue que ça peut être amusant de montrer son installation aussi.
Entièrement d’accord (à bas la réforme !)
HS: vive les nénuphares!
En tout cas ça me fait extrêmement plaisir de contribuer à aider sur ce fabuleux site qui est ZdS!
EDIT: il y a aussi le fait de ne pas avoir mentionner le switch mais il me semble avoir vu que c’était fait exprès car au final on ne s’en sert que dans des cas très particuliers (je suivais ce sujet depuis Janvier sans m’inscrire et puis … j’ai sauté le pas )
En tout cas ça me fait extrêmement plaisir de contribuer à aider sur ce fabuleux site qui est ZdS!
Et ça nous fait très plaisir que tu nous aides, merci et bienvenue !
EDIT: il y a aussi le fait de ne pas avoir mentionner le switch mais il me semble avoir vu que c’était fait exprès car au final on ne s’en sert que dans des cas très particuliers (je suivais ce sujet depuis Janvier sans m’inscrire et puis … j’ai sauté le pas )
Petit à petit, le chapitre sur la compilation avance. Il nous reste encore à parler des options de compilation, ainsi que d’aborder la partie sur les fichiers objets et le linker. On compte aussi aborder rapidement CMake, pour montrer qu’on est pas obligé de taper toutes les commandes à la main à chaque fois, mais qu’on peut automatiser ça.
Bonjour les agrumes !
La bêta a été mise à jour et décante sa pulpe
à l’adresse suivante :
Implicitement, utiliser constexpr sur une variable revient à la déclarer const, ce qui est logique. Personnellement, dans le but d’être explicite, je précise également const, mais ce n’est pas une obligation, simplement une question de goût.
Typiquement, les assertions sont désactivées en release.
Mais comment on les désactive au fait ?
Pour faire simple, c’est une macro préprocesseur qui lance une assertion en mode Debug et une noop (no-operation) en Release. On ajoutera que c’est grâce au préprocesseur.
Implicitement, utiliser constexpr sur une variable revient à la déclarer const, ce qui est logique. Personnellement, dans le but d’être explicite, je précise également const, mais ce n’est pas une obligation, simplement une question de goût.
Je me demande si il faudrait pas parler de constexpr if(...) ou si c’est un peu le même principe que pour switch.
Alors non, c’est pas comme pour switch. La raison est que le constexpr if ne sert pas à ça. On peut mettre des if normaux dans des fonctions constexpr, ça marche sans problème (et c’est même mieux puisque ça permet à la fonction de pouvoir être appelée avec des arguments non constexpr).
Non, if constexpr est un outil de méta-programmation template, il sert à sélectionner des blocs de code à partir de conditions plus simplement qu’avec d’autres techniques. Il sera abordé dans le cours, mais à un moment plus opportun.
Btw, la syntaxe c’est if constexpr (...), pas constexpr if (...).
Mais du coup pour une fonction constexpr ou inline il n’y a pas vraiment de différence non ?
Si si, c’est différent. Une fonction constexpr donne la garantie d’être évaluée à la compilation si ses arguments sont constexpr, inline n’offre en aucun cas cette garantie.
Je crois voir d’où peut venir la confusion. « Historiquement », inline sert à dire au compilateur qu’on préfère remplacer l’appel de fonctions par le code de la fonction directement, pour éviter le surcoût qui vient de l’appel de fonctions. Mais :
Rien ne dit que ce code sera exécuté à la compilation, c’est juste que l’appel de fonctions est remplacé par un « copié-collé » du code.
Ceci n’est qu’un « conseil » pour le compilateur, qui en fait fait ce qu’il veut pour optimiser : il peut très bien laisser l’appel de fonction si ça lui chante.
Du fait de la liberté du compilo, inline sert finalement surtout à dire que plusieurs définitions de la fonction sont permises.
Si tu veux aller plus loin, je te suggère de jeter un oeil à la doc.
J’espère que c’est plus clair !
EDIT : Je précise qu’une fonction constexpr est implicitement déclarée inline, de même qu’une variable static constexpr.
Ceci n’est qu’un « conseil » pour le compilateur, qui en fait fait ce qu’il veut pour optimiser : il peut très bien laisser l’appel de fonction si ça lui chante.
Je me souviens de ça en C.
Du coup faut laisser le compilateur optimiser tout seul.
Merci de m’avoir éclaircit.
EDIT:
il ne faut pas se le cacher, avoir une certaine maîtrise du C++ est très long et demandera des années d’expérience
Un gros morceau de fini avec le chapitre sur la compilation qui est terminé. N’hésitez pas à nous faire des retours dessus.
Au programme maintenant, le chapitre sur le débuggage. Ensuite, on parlera de l’installation de bibliothèques externes et on finira cette partie avec un chapitre sur des outils bien pratiques, comme CMake, git et tout ça, dans une idée d’automatisation et de partage de son code.
Bonjour les agrumes !
La bêta a été mise à jour et décante sa pulpe
à l’adresse suivante :
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte