Un code invalide peux compiler en C++, et l'utilisation de char* ainsi que de sscanf sont des choix invalides aux yeux de la compatibilite avec la STL.
Un code invalide peux compiler en C++, et l'utilisation de char* ainsi que de sscanf sont des choix invalides aux yeux de la compatibilite avec la STL.
Ca fait bien longtemps que je n'ai pas écrit de C++ (du temps où l'on se codait une class string soi-même). Les dernières normes C++ invalident-elles réellement une fonction comme sscanf, et surtout un type de base? Ce n'était pas du tout la philosophie de C++ à l'époque.
Ca fait bien longtemps que je n'ai pas écrit de C++ (du temps où l'on se codait une class string soi-même). Les dernières normes C++ invalident-elles réellement une fonction comme sscanf, et surtout un type de base? Ce n'était pas du tout la philosophie de C++ à l'époque.
La fonction sscanf est une fonction qui ne doit normalement pas être utilisée en C++ car il n'y a pas reconnaissance des types. Mais les compilateurs peuvent prendre des initiatives quand la chaîne de format est explicite, et indiquer des warnings si les paramètres ne sont pas conformes.
Ce n'est pas la norme qui invalide une fonction comme sscanf, c'est la pratique. sscanf laisse la possibilité d'introduire une incohérence entre la chaine de formatage et la va_list. A partir de l'instant où il existe une possibilité de faire une connerie, la loi de Murphy dit que tôt ou tard quelqu'un finira par la faire...
Sans même envisager la malveillance, nous ne sommes pas des dieux, on peut être fatigué, distrait, stessé... Il existe des infinités de situations où on va se trouver en position de commettre des erreurs.
Si on fait en sorte qu'il ne soit pas possible de commettre une erreur, personne ne la commettra. Les flux de c++ suppriment la nécessité de fournir une chaine de format, du coup il n'est plus possible qu'il y ait une incohérence, donc on a supprimé une possibilité d'erreur. Ensuite il peut quand même y avoir une erreur si le contenu du flux ne peut être converti, mais cette erreur pourra être détectée très tôt, car le flux va se mettre en erreur. Plus une erreur sera détectée tôt, plus vite elle sera corrigée, et plus ses conséquences ont de chance d'être faibles.
L'objectif premier de c++ est de produire du code robuste et fiable (et si possible, rapide), tout ce qui peut aider à réduire le risque d'erreur est bienvenu.
Tout cela est bel et bien. Ca n'empêche pas qu'un programmeur C++ doit donc continuer à connaître les fonctions de type scanf, sauf à être incapable de maintenir de l'ancien code (en production, stable et débugué depuis des décennies, ce qui n'empêche pas la nécessité de quelques modifications ponctuelles).
Oui et non, oui parce qu'effectivement ça existe, et que dans le cadre de la maintenance de code existant en production, il faut être capable de lire et de comprendre ce genre de chose. Non parce que la maintenance de code un peu ancien,n'est jamais confiée à des débutants pour une raison toute simple, c'est presque toujours du code critique et stratégique (le reste a été refactoré ou carrément réécrit depuis longtemps), il est absolument hors de question de laisser qui que se soit y toucher tant qu'on n'a pas la certitude qu'il est parfaitement au point sur le programme. Pour ce qui concerne la production nouvelle, les impératifs de qualité font que ce genre de fonctions seront bannies au profit de techniques plus safe, du coup ne pas connaître ces fonctions n'est pas vraiment un handicap, si je ne les connais pas, il est assez peu probable que je sois tenté de les utiliser...
× 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.
Architecte logiciel - Software craftsmanship convaincu.
Architecte logiciel - Software craftsmanship convaincu.
En recherche d'emploi.