pourquoi les "char" sont "néfastes" pour les débutants é le sont-ils vraiment ????????
Version imprimable
pourquoi les "char" sont "néfastes" pour les débutants é le sont-ils vraiment ????????
Le type "char" n'est absolument pas nocif pour un débutant...
Ce qui est nocif, car sujet à de nombreux problèmes qui peuvent ete évités, c'est l'utilisation d'un tableau de char pour créer une chaine de caractères au lieu de la classe std::string...
En effet, un tableau de caractères fournis une chaine "C style", qui est soumise à - entre autres - tous les problèmes rencontrés avec les tableaux:
- comportement indéfinis en cas de mauvaise initialisation,
- problèmes propres au dépassement de capacité (11 caractères dans un tableau prévu pour en contenir 10)
- ...
La classe std::string est suffisemment robuste pour permettre d'éviter risquer de se "tirer dans le pieds" et pour limiter ce genre de problème, tout en permettant, finalement, tout ce qui est possible avec les chaine "C style".
En cela, les chaines de caractères C style sont "nocives" (disons plutot: moins bien adaptée, moins faciles à utiliser, plus source d'erreur) mais ce n'est nullement un point de vue à élargir au type char ;)
Le type char est à utiliser chaque fois que, réellement, tu veux travailler sur un caractère qui, d'une manière ou d'une autre, peut etre considéré comme étant pris séparément de l'ensemble des caractères composant une chaine ;) (ou pour toute valeur ayant une fouchette comprise dans celle correspondant au type char)
Je seconde globalement les propos du phascolarctidé, et ajoute juste un autre risque, cette fois-ci lié aux chars eux même : Certains font des suppositions sur la façon dont certains caractères sont codés, et utilises ces suppositions peu fondées (même si ça a l'air de marcher avec le compilateur courant), pour par exemple dire que 'A' + 1 serait égal à 'B' ou que l'ordre des char est un ordre alphabétique, ou pour passer en majuscules à base de c - 'a' + 'A'. Ce genre de choses est d'autant plus gênant dans un contexte internationnal.
Bonjour,
Je ne pense pas que les std::string donnent la solution à ce problème, ou alors un gros truc m'a échappé.Citation:
Envoyé par JolyLoic
A mon tour.
Le principal problème des char* et autres char[] pour un débutant, c'est que ces types l'éloignent de ce qui est vraiment important à son niveau => l'agorithmie.
De plus, pour qu'il soit à même de produire un semblant de quelque chose, les cours reposant sur ces types primitifs prennent quantité de raccourcis qui introduisent des vulnérabilités, ou des limitations d'un autre âge. Un code correct étant souvent d'une compléxité à dégouter n'importe qui à ce niveau -- voire même après.
Et donc pourquoi s'embéter vu qu'il y a un type chaîne qui s'avère très simple à utiliser correctement ?
Ca, c'est pour les débutants.
Concernant les gens expérimentés. Vu que l'on a autre chose à faire que de se prendre le choux à toujours refaire les mêmes TDs dans nos codes de production, on laisse tomber ces 2 types primitifs au profit de types encapsulant toute la partie pénible liée à la gestion des chaines de caractères.
Au passage, ces types nous offrent une plus grande robustesse et une maintenabilité accrue.
std::string est le type standard pour cela -- diverses bibliothèques graphiques se sentent obligées de définir leur propre type pour les chaînes de caractères.
Après, il nous arrive ponctuellement de revenir à des char* pour des raisons d'optimisation quand on sait qu'il y a à y gagner dans des situations bien précises. Ou pour s'interfacer avec certaines API.
NB: le moment venu, ce débutant enfin initié, et à vocation de devenir informaticien professionnel, devra faire ces TDs où l'on manipule des buffers de char à la main. Le temps de quelques TDs incontournables histoire de comprendre comment ça marche dedans.
Lectures:
-> FAQ, chapite sur les std::string
-> un article de Bjarne Stroustrup au sujet qu'il faut apprendre le C++ comme un langage à part entière, et indépendant, sans s'encombrer de bagages et autres oeillières. (je résume à ma sauce). Le lien est dispo dans un des points de la FAQ qu'il maintient sur son site (google!)
Comprenons nous bien, en informatique, il n'y a rien de "nocif", rien d'obligatoire, et rien d'interdit...
Par contre, il y a une optique qui est, toujours néfaste et nocive: c'est celle du "pourquoi faire simple quand on peut faire compliqué"...
C'est pour cette simple et unique raison qu'on *conseille tres largement* aux débutants de se tourner vers les std::string plutot que vers les char[]... Et, chose bizare, c'est aussi la raison qui fait que les personnes mieux initiées continuent à utiliser les string plutot que des tableaux de caractères ;)
Bref, autant le dire, il n'est nullement question (du moins de mon point de vue) de "diaboliser" une pratique ou une autre...
Il est plutot question d'utiliser LA technique qui, dans une situation donnée, me donnera le meilleur résultat dans un minimum de temps...
Au fait, savais tu que la grosse majorité du retard intervient, non pas en période de codage, mais du fait du débuggage :question:
Il ne faut pas pour autant sacrifier flexibilité, généricité et maintenabilité.Citation:
Il est plutot question d'utiliser LA technique qui, dans une situation donnée, me donnera le meilleur résultat dans un minimum de temps...
Mais je crois que, là, on rentre déjà dans un autre débat...Citation:
Envoyé par loufoque
Si je suis - globalement - d'accord avec le principe, ca reste malgré tout au concepteur d'analyser ses besoin en flexibililté et en généricité de manière honnete...
Faire du flexible, oui... mais dans une situation donnée exceptionnelle, ce peut ne pas etre nécessaire...
De meme, faire du "générique" pour le plaisir de faire du générique sans avoir *forcément* intérêt à le faire dans une situation donnée *peut* ressembler à une optique du fou qui se tappe sur la tete avec un marteau...
La maintenabitilité, en fin, viendra bien plus de la lisibilité du code et de la qualité de la conception que de la simple décision d'utiliser des char ou des string...
Le C++ et le C fourmillent de "raccourcis" qui permettent au codeur de s'éviter quelques caractères d'écriture.
Sans vouloir diaboliser ces "racourcis", je trouve que leur abus est bien plus de nature à compliquer la maintenance du code que le simple fait d'utiliser un tableau de char là où le besoin s'en fait réellement sentir.
<DISGRESSION>
C'est tout à fait hors cadre, mais:
- L'homéopathie: aux bonne doses, rien n'est forcément bon ni forcément mauvais... mais l'abus de toutes choses, y compris des meilleures, s'avere fatal dans tous les cas...
- On entend régulièrement parler de "bautox" du coté des chirurgiens esthétiques... C'est, en réalité, une dillution du germe responsable de la maladie "botulisme", l'une des maladies les plus dangereuses et offrant une mort parmis les moins enviables...
Là encore, on se rend compte que, dans le cadre d'une utilisation strictement comprise et controlée, meme quelque chose de mortel peut s'avérer etre "utile" pour la santé (si l'on considère comme utile de faire disparaitre ses rides)
</DISGRESSION>
En informatique, en général, et concernant les char et tableaux de char en particulier (vu que c'est le theme de ce thread) c'est exactement pareil:
Leur utilisation sans avoir compris et maitrisé l'ensemble des restrictions qu'ils implique risque de transformer la vie du programmeur en véritable cauchemard, mais, dans certaines situations, avec, comme prérequis le fait de maitriser les capacités et les limitations propres aux tableaux de caractères, leur utilisation peut s'avérer être la meilleure solution à apporter à un problème donné...
Si, très clairement, dans la grosse majorité des cas, l'utilisation des std::string peut s'avérer être la solution la plus simple pour arriver à ses fins, cela ne veut malgré tout pas dire qu'il faille considérer l'utilisation de tableaux de caractères comme à bannir systématiquement...
Le principe de la programmation est tout de même de faire des composants réutilisables.
Et pour ça il faut qu'ils soient suffisamment génériques.
Cela dépend de quel type de tableaux tu parles. Les tableaux en tant que type sont toujours utiles, bien qu'avantageusement remplacés par array<T, N>. Les tableaux dynamiques, eux, sont à éviter, ne serait-ce que pour des questions d'exception-safety. On a vector<T> pour ça. Et si vraiment on a besoin d'optimiser l'utilisation mémoire ou de faire des constructions en place, on utilise scoped_array.Citation:
Si, très clairement, dans la grosse majorité des cas, l'utilisation des std::string peut s'avérer être la solution la plus simple pour arriver à ses fins, cela ne veut malgré tout pas dire qu'il faille considérer l'utilisation de tableaux de caractères comme à bannir systématiquement...