J'ai ouvert ce fil de discussion sur le conseil de gbdivers pour éviter qu'un autre fil ne soit surchargé. Il est composé d'une ancienne question, de le réponse de lmghs, puis d'une nouvelle question de ma part.
@lmghs : à titre de curiosité pour progresser (je sais que ça fait beaucoup de questions, mais ça m'intéresse de comprendre maintenant que j'ai fini le cours de Mateo21, car ces points ne sont pas dans son cours et avec la doc je n'ai pas compris) :
1) à quoi sert explicit dans cet exemple (tu l'as utilisé deux fois : une fois avec le constructeur et l'autre avec ton opérateur) ?
2) que signifie la notation : operator int() ?
3) qund tu parles de TODO ajouter : constexpr, et noexcept, peux-tu m'expliquer à quoi servent ces deux mots-clés ici ?
Merci
lmghs a écrit:
Ca fait beaucoup à expliquer, je passe en mode fainéant
2- opérateur de conversion, explicite (c++11) -- en gros, on converti dans l'autre sens.
3- Prends-ton temps, tu n'y es pas encore. Le premier permet d'exiger du compilateur la garantie que des expressions seront évaluées à la compilation. Le second garantit qu'une fonction ne lance pas d'exception -- c'est plus compliqué en vrai. Comprends et vis d'abord le RAII.
NOUVELLE QUESTION :
Dans ce message, nous parlions de noexcept et tu me disais que le second (noexcept) ne lance pas d'exception. Or pourquoi dans le cours de OC, dit-on que dans le code suivant :
class exception
{
public:
exception() throw(){ } //Constructeur.
virtual exception() throw(); //Destructeur.
virtual const char* what() const throw(); //Renvoie une chaîne "à la C" contenant des infos sur l'erreur.
};
la chose suivante :
"Les méthodes de la classe sont suivies du mot-clé throw(). Cela sert à indiquer que ces méthodes ne vont pas lancer d'exceptions... ce qui est plutôt judicieux parce que, si la classe exception commence à lancer des exceptions, on n'est pas sorti de l'auberge. Indiquer qu'une méthode ne lance pas d'exception est un mécanisme du C++ très rarement utilisé. En fait, cette classe est à peu près le seul endroit où vous verrez cela."
Quelle est dans ce cas, la différence entre throw() et noexcept ?
Merci pour les explications précises
- Edité par pseudo-simple 24 octobre 2018 à 13:34:13
Dans ce message, nous parlions de noexcept et tu me disais que le second (noexcept) ne lance pas d'exception. Or pourquoi dans le cours de OC, dit-on que dans le code suivant :
Parce que, encore une fois, le cours est obsolète: avant C++11, on pouvait indiquer la liste des exceptions susceptibles d'être lancées par une fonction, avec comme effet de bord que, si tu faisais appel à une fonction qui lancait une exception absente de la liste, le programme appelait automatiquement unexpected_error()
Du coup, la spécification des exceptions devait etre strictement exhaustive reprendre l'ensemble exceptions susceptibles d'être lancées par l'ensemble des fonctions appelées de manière directe ou indirecte qui n'avaient pas été gérées (ou qui avaient été relancées), ce qui laissait une grande place à "certains oublis" susceptible de foutre tout le système en l'air.
Si bien que le fait qu'une fonction proche de
void foo() trhow(){
/* ... */
}
ne puisse lancer aucune exception n'était qu'un effet secondaire du au fait qu'une fonction proche de
void bar() throw(std::bad_alloc){
/* ... */
}
ne pouvait pas lancer d'autre exception qu'une ... exception de / dérivée du type std::bad_alloc
C++11 a changé radicalement de point de vue, en disant que nous pouvons spécifiquement indiquer qu'une fonction ne peut lancer aucune exception, ce qui permet au compilateur
de n'accepter que l'appel de fonction qui se sont également engagées à ne pas lancer d'exceptions (et cela de manière récursives) si la fonction ne peut pas lancer d'exception
d'accepter que n'importe quelle exception soit lancée -- de manière directe ou indirecte -- si la fonction peut lancer une exception
Ce qui rend les choses beaucoup plus simples
- Edité par koala01 24 octobre 2018 à 13:57:39
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Tu es pénible quand même. Ce sont des questions de cours, que tu n'aurais pas besoin de poser si tu suivais un bon cours. Mais avec ta façon d'apprendre :
- tu sembles complètement passif, tu poses des questions sans faire de recherche de ton côté.
- tu ne suis pas une structure logique d'apprentissage, mais des fragments de syntaxes. Tu n'arriveras pas a voir une compréhension globale du pourquoi des syntaxes.
Mon avis est qu'il faudrait que les gens arrêtent de te répondre aussi vite. Qu'ils te laissent chercher un peu par toi meme.
En 2 secondes de recherche sur google, j'ai trouvé plusieurs liens en francais qui expliquent ce que c'est "explicit". Et meme en anglais, il n'y a aucun problème pour comprendre :
Specifies that a constructor or conversion function (since
C++11) is explicit, that is, it cannot be used for
implicit conversions and copy-initialization.
Au pire avec une traduction google :
Spécifie qu'un constructeur ou une fonction de conversion
(depuis C ++ 11) est explicite, c'est-à-dire qu'il ne peut
pas être utilisé pour les conversions implicites et
l'initialisation de copie.
Si tu as réellement cherché longtemps, c'est bien que tu as un gros problème dans ta façon d'apprendre. Tu n'as pas appris à etre autonome, a force de poser pleins de questions sur le forum. C'est bien là le problème avec toi.
J'essaie de comprendre l'utilité d'enlever les exceptions avec noexcept alors que c'est justement intéressant de les avoir selon moi, pour étudier les cas où il peut y avoir des anomalies dans le code.
EDIT : Scott Meyer, dans son livre , encouragerait à utiliser noexcept aussi souvent que possible, d'après un des titres de chapitre que j'ai vus ("if they won't emit exceptions"). Peut-on vraiment être sûr qu'une fonction donnée n'enverra jamais d'exceptions ?
- Edité par pseudo-simple 24 octobre 2018 à 15:25:12
A sa décharge, il a l'esprit un peu mal formaté par ce cours calamiteux.
Difficile de poser les bonnes questions et de comprendre les "bons" articles quand on a de mauvaises références (c'est bien pire que de ne pas avoir).
C'est pas faute de te l'avoir dit @YES, man.
En gros, les mecs de la norme C++ ont voulu piquer l'idée de JAVA sur la traçabilité des exceptions (très mauvaise et ils (ceux de JAVA) sont aussi revenus dessus). Ils (ceux du C++) se sont aperçus, et bien plus rapidement que ceux de JAVA, que c'était vraiment pas terrible (cf. tout un tas de discussion sur le sujet, aussi bien en C++ quand JAVA (mais c'était un truc plus mis en avant en JAVA donc plus de discussion sur son bien-fondé)).
La norme C++11 a gardé la compatibilité ascendante, mais à mis en place un truc bien plus simple (noexcept) et qui permet au compilateur de faire des trucs bien sympa.
EDIT :
>alors que c'est justement intéressant de les avoir selon moi,
C'est là, la fausse bonne idée, si vous le faite "bien" c'est extrêmement lourd, sinon vous le faite à l'arrache et tout cela se résume à la fin en "throw(exception)" partout, "super utile isn't it ?".
- Edité par bacelar 24 octobre 2018 à 14:50:52
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
En gros, les mecs de la norme C++ ont voulu piquer l'idée de JAVA sur la traçabilité des exceptions (très mauvaise et ils (ceux de JAVA) sont aussi revenus dessus). Ils (ceux du C++) se sont aperçus, et bien plus rapidement que ceux de JAVA, que c'était vraiment pas terrible (cf. tout un tas de discussion sur le sujet, aussi bien en C++ quand JAVA (mais c'était un truc plus mis en avant en JAVA donc plus de discussion sur son bien-fondé)).
C'est pas sorti en 96 le Java ? Là, on est sur du 95 pour le C++.
> > il ne s'agit pas d'enlever les exceptions mais de garantir que la fonction n'en renvoie pas. > plus précisement, que si une exception est lancée par une fonction noexcept, cela lance std::terminate
Voire plus: permettre aux compilateurs de voir que des zones 100% noexcept ne manipulent aucune exception, et donc de dégager entièrement le code et les tables de remontées d'exceptions. IOW de gratter des opportunités d'amélioration de performance. Sauf qu'à cause du std::terminate exigé, quand une fonction noexcept n'appelle pas que des trucs qui sont garantis noexcept, le compilo est dans l'obligation de "catcher" pour dérouter sur terminate...
Non, j'ai fait mon service (militaire) fin 95 et je faisais du JAVA "bien" avant de brosser mes rangeos, et j'étais pas un pionnier.
JAVA était "connu" bien avant sa "présentation officielle" début 1995.
La première norme C++ est en 1998 et je n'étais pas tombé sur des compilateurs qui supportaient ces trucs (et aussi avant que je connaissent cette possibilité ) avant pas mal de temps après.
Que les spécificateurs du C++ se soit inspirés de JAVA, d'une pré-version de JAVA, d'un langage pré JAVA comme Oak (1992), un autre langage "inspirant", cette fausse bonne idée était dans l'air du temps et JAVA était THE concurrent.
@YES, man, que tu penses que c'est une "bonne" idée, c'est normal, beaucoup beaucoup de monde ont cru que c'était une bonne idée, mais la pratique a montré l'inverse.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Cela aurait pu avoir une chance d'être une bonne idée si les vérifications avaient lieu à la compilation. Ce n'est pas le cas en C++, => idée exécrable.
En Java, que je connais moins, il en reviennent si je décortique bien les propos de bacelar, c'est ça?
C'est une bonne idée parce qu'on ne lisant que le prototype, on sait
que la fonction n'utilise que telles ou telles exception,
que le compilateur garanti l'affirmation précédente
que le compilateur nous indique que telle exception n'est pas convenablement traitée
Mais c'est une mauvaise idée parce que:
La fonction peut utiliser des sous-classes d'exception et on ne le sait pas (on se retrouve avec des catégorie et c'est souvent trop vague)
Le compilateur ne garantit pas que la fonction n'utilise pas d'autre exception (en c++, en java il me semble que c'est différent)
Le compilateur n'indique pas les exceptions non traitées parce que, primo il ne vérifie déjà pas, secundo on ne le veut pas forcement (il faudrait faire des niveaux d'importances d'exception et c'est vite le foutoir)
Il y a un coût non négligeable au runtime pour vérifier l'affirmation dans le throw(...) (catch automatique) et cela se termine par un std::terminate
C'est impossible à maintenir: le moindre ajout de fonction dans une implémentation parasite les prototypes qui l'utilise ce qui peut résulter à des milliers de lignes modifier. Si on modifie du code, on peut enlever ou ajouter des exceptions -> même conséquence. Les utilisateurs de lib seront dans l'incapacité de mettre à jour à chaque changement de fonctionnalité, même si les dites fonctionnalité ne les impactent pas.
Des exceptions qui ne sont pas connues par certaines bibliothèques peuvent les traverser. Exemple: un système de callback. Comment fait-on ?
Dans un contexte précis, on peut garantir l'absence de certaines exceptions, comment fait-on pour propager l'information ?
Finalement, le seul point intéressant est de savoir si oui ou non il y aura exception, car c'est un changement de comportement important vis-à-vis de l'utilisateur de la fonction.
Et je rejoins @gbdivers, tu ne fais aucun effort de recherche, la plupart de tes questions (surtout celle sur les mots clefs et comportement de fonctions standards) sont documentés et peuvent facilement se trouver sur cppreference.com.
@gbdivers : Si je pose cette question, c'est parce que j'ai cherché longtemps. Donc stp, ne recommence pas
Pourtant on t'as dit à plusieurs reprise que ce cours était obsolète enseignant des choses plus utilisées de nos jours. Normal qu'on se lasse de répondre à des questions que tu ne devrais pas poser.
git is great because Linus did it, mercurial is better because he didn't.
>il en reviennent si je décortique bien les propos de bacelar
Oui.
"Errare humanum est, perseverare diabolicum"
Et en JAVA, ils ont pas mal poussé le "diabolicum" parce que la subtile différence entre les "Trowable Error" qu'on n'indique pas dans les signatures et les "Trowable Exception" qu'on indique dans les signatures :
Et après, on peut toujours dire que le C++ est plus compliqué que le JAVA, mais quand on pousse un "diabolicum", il faut un peut lever la tête du guidon. (les concepteurs de JAVA 1.0 devaient déjà savoir que c'était un idée pas fameuse pour sortir ce genre d'usine à gaz)
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
La tracabilité des exceptions n'est pas forcément une mauvaise idée. En particulier, elle devient complètement nécessaire pour certaines tâches (preuve par exemple). Par contre, ça demande du boulot.
Nous, on fait du code jetable et pas cher, comme l'Ariane V.
Heuu, tu veux dire... du code exploisif ??
Bon... je suis déjà dehors...
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
@jo_link_noir: je te redis ce que j'ai dit à gbdivers : garde tes jugements pour toi. J'espère que tu comprends le français. Tu arrêtes ça. Si tu ne veux pas aider, tu n'aides pas. Mais je n'accepte pas que tu colles tes étiquettes sur moi ou sur d'autres. Tu intimides les gens qui ont des questions avec ton attitude. Ton savoir en C++ ne te donne aucun droit de juger quelqu'un que tu ne connais pas. Et même si tu connais les gens, garde tes étiquettes pour toi. Je le répéterai autant qu'il le faudra tout comme gbdivers revient périodiquement à la charge. Ces tentatives d'intimidation non volontaires et de dénigrement de tout ce qui ne correspond pas à la pensée du contradicteur, n'ont rien à faire sur un forum de C++, surtout à l'endroit de personnes faisant des efforts considérables.
- Edité par pseudo-simple 25 octobre 2018 à 6:21:01
@jo_link_noir: je te redis ce que j'ai dit à gbdivers : garde tes jugements pour toi. J'espère que tu comprends le français. Tu arrêtes ça. Si tu ne veux pas aider, tu n'aides pas. Mais je n'accepte pas que tu colles tes étiquettes sur moi ou sur d'autres.
Oh, c'est mignon tout plein quand tu t'énerves .
Mais sinon, il va falloir te rendre compte au bout d'un moment, que si tous les membres actifs d'un forum commencent à te faire remarquer que ta manière de bosser n'est pas la bonne, que tu ne fais pas assez de recherche (parce que bon comme l'a dit GB, c'est une recherche Google pour savoir ce que font throw et noexcept), et que tu commences doucement à gaver tout le monde, c'est peut être qu'il y a une raison.
Et il faut être clair : les gens font ce qu'ils veulent hein, donc tu peux faire ton apprentissage comme tu veux, mais les gens ont aussi le droit de te faire remarquer que c'est une mauvaise idée et que tu ne prends pas les choses dans le bon sens, et après tu es libre d'aller dans un sens ou dans un autre. Mais que tu le veuilles ou non, les gens ont le droit de participer à tes posts tant que ce qu'ils y mettent n'est pas contraire aux règles d'utilisation du forum.
Maintenant, si tu penses que les messages ne sont pas appropriés, tu les signales à la modération (il y a un bouton fait pour) qui décidera si oui ou non, c'est le cas.
YES, man a écrit:
Ces tentatives d'intimidation non volontaires et de dénigrement de tout ce qui ne correspond pas à la pensée du contradicteur, n'ont rien à faire sur un forum de C++, surtout à l'endroit de personnes faisant des efforts considérables.
Vu le temps qu'ont passé les membres de ce forum à aider un paquet de gens depuis des années (ici, et sur pas mal d'autres forums), tu es très mal placé pour leur expliquer ce qu'ils ont à faire. Et c'est pas un énergumène dans ton genre qui va les faire partir. On en a vu d'autres.
@Ksass Peuk, Et bien toi aussi tu te calmes , je ne t'ai pas qualifié d'énergumène. Donc modère ton langage car tes qualificatifs de ce genre n'ont aussi rien à faire sur un forum de C++ et infantiliser autrui parce que tu connais bien C++, c'est une stratégie qui ne marchera pas avec moi. ça doit être bien clair.
Je sais apprécier le bien que certains font.
Je dis qu'il faut arrêter d'intimider les gens comme moi qui font des efforts considérables.
Personnellement, je n'impose à personne d'aimer le cours de OC en C++(Mathieu Nébra), mais ce que je sais c'est que sa pédagogie m'a énormément apporté et que je ne ferai pas preuve d'ingratitude; même si il y a des améliorations notables à apporter à ce cours
- Edité par pseudo-simple 25 octobre 2018 à 8:51:03
Personnellement, je n'impose à personne d'aimer le cours de OC en C++(Mathieu Nébra), mais ce que je sais c'est que sa pédagogie m'a énormément apporté et que je ne ferai pas preuve d'ingratitude; même si il y a des améliorations notables à apporter à ce cours
C'est bête parce que tout ce que tu auras appris avec devra être oublié et réappris correctement.
Exemple:
Partie 1
1.1 using namespace std est une mauvaise pratique
1.2 je connais pas grand monde qui utilise code::blocks de leur plein gré
1.4 n'explique pas les mécanismes de base comme RAII
1.8 personne ne devrait utiliser des tableaux C en C++
1.11 je préfère pas commencer à en parler, j'aurais pas fini à midi
Partie 2
En fait, à revoir complètement.
Et avec ce cours tu ne verras pas : les smart pointers, les lambdas, les constructeurs de déplacement, les nouveaux conteneurs, les variadic templates, les fold expressions, auto, decltype, constexpr, initializer_list, brace-init, inclass-init, inline variables, UDL, nullptr, enum class, static_assert, override/final, std::regex, std::optional, std::variant, std::string_view, <random>.
Bon je pense que je vais m'arrêter là.
- Edité par markand 25 octobre 2018 à 9:21:13
git is great because Linus did it, mercurial is better because he didn't.
Je dis qu'il faut arrêter d'intimider les gens comme moi qui font des efforts considérables.
Justement, on a réellement du mal à voir tes efforts considérables et quand on voit tes réactions aux remarques il semblerait que tu n'apprécie pas l'aide qu'on t'apporte, donc évidemment que tout le monde se fatigue
- Edité par romantik 25 octobre 2018 à 9:18:53
Dream on, Dream on, Dream until your dream comes true
Si tu avais un minimum de jugeote, tu prendrais du recul. Tu cherches des excuses ("vous essayez d'intimider", "vous faites cela parce que vous connaissez bien le C++") pour évitez d'accepter que le problème vient de toi. C'est plus facile de s'imaginer que le problème, c'est les autres.
Tu ne réalises même pas que le nombre de messages que tu postes sur le forum montre bien qu'il y a un problème dans ton apprentissage.
@markand, le passage au C++ "complet" est en cours. J'ai fini le cours de openclassrooms. Et j'en suis vraiment fier. Dans la liste que tu as énumérée, il y a de nombreuses choses que je dois voir, mais grâce à vous tous et certaines de mes recherches personnelles, des choses que je connais déjà.
Je suis très optimiste pour la suite.
D'ailleurs, j'ai suivi le conseil de Gbdivers et je viens d'acheter la traduction en français de l'excellent livre de Scott Meyers.
Je vous remercie encore pour votre patience et pour les explications détaillées que vous m'apportez et qui m'enrichissent considérablement.
- Edité par pseudo-simple 25 octobre 2018 à 9:52:32
Tu peux garder tes courbettes et tes ronds de jambe, ce n'est pas le ton employé qui nous fait penser que tu te fiches de nous mais plutôt la non-attention que tu accordes à nos conseils. Si on te répète à chacune de tes questions de changer de cours, c'est parce qu'on sait pertinemment que cette question n'aurait pas existé si tu avais suivi une meilleure méthode d'apprentissage, et c'est extrêmement frustrant de te voir t'enfoncer de plus en plus à chaque fois qu'on essaie de t'en sortir un peu !
YES, man a écrit:
le passage au C++ "complet" est en cours.
Parle plutôt de C++ "correct" xD
YES, man a écrit:
Je suis très optimiste pour la suite.
Tant mieux pour toi, et j'espère tout de même sincèrement que tout se passera bien
Dream on, Dream on, Dream until your dream comes true
Merci romantik, c'est sympa. En fait, C++ correct = C++ à jour surtout car de son temps, ce C++ obsolète était considéré comme le bon en fait
En attendant de recevoir la version française du livre de Scott Meyers, je feuillete la version anglaise, et je commence à trouver des réponses à des questions que j'ai posées sur le forum récemment sur override, et les rvalues.
J'ai aussi eu une réponse comme quoi throw() est déprécié et que à partir de C++11, on le remplace par noexcept (page 90 de la version anglaise pour bien montrer que je CHERCHE)... avec des subtilités apparemment à apprendre.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
git is great because Linus did it, mercurial is better because he didn't.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
git is great because Linus did it, mercurial is better because he didn't.
Discord NaN. Mon site.