PEBKAC #3732

Ce soir, je tente de réparer un bout de code C++. Après plusieurs heures de tests, débogage et compilations à la chaine, je me suis enfin rendu compte que j'ai écrit : "if ( str[i] == str.size() )".
En gros, "si une lettre est égale à un nombre fait...". J'assume. PEBKAC.

PEBKAC #3732 proposé par Loy le 12/06/2011 | 60 commentaires | 👍🏽 👎🏽

Euh, ca doit faire trop longtemps que j'ai pas fait de C mais je croyais que c'était possible justement (un char, ce n'est pas entier codé sur 1 octet ?)

Commentaire #158797 écrit par undefined le 03/07/2011 à 17h50 | 👍🏽 👎🏽

Ben quoi, je vois pas où est le problème ? : http://pastebin.com/rpHnKNRj
;)

Commentaire #158798 écrit par kevin64 le 03/07/2011 à 17h52 | 👍🏽 👎🏽

Ah ! Ca me rassure, j'ai pas tout oublié :)

Accessoirement, ce genre code me laisse perplexe quant à son intérêt...

Commentaire #158799 écrit par undefined le 03/07/2011 à 17h59 | 👍🏽 👎🏽

v'là mon pastebin testable sous linux en ligne :) (cf commentaires)

http://pastebin.com/gAqRm1zA

Commentaire #158800 écrit par undefined le 03/07/2011 à 18h23 | 👍🏽 👎🏽

Erreur d'inattention classique, pas vraiment un PEBKAC à mon sens.
Par contre, je confirme le côté chronophage (bien que, pour la plupart de celles de ce genre que j'aie faite, elles ne m'ont pas pris tant de temps ...)

Commentaire #158801 écrit par Hizin le 03/07/2011 à 18h51 | 👍🏽 👎🏽

conclusion (dès fois que je n'étais pas clair) : @Loy c'est toi le PEBKAC ! car non seulement l'erreur n'était pas celle que tu as identifié mais en plus tu as posté ça ici !

Commentaire #158802 écrit par undefined le 03/07/2011 à 19h00 | 👍🏽 👎🏽

Dans le genre y'a aussi :
if(condition);
{actions}
point-virgule de mes deux...

Commentaire #158803 écrit par Luick le 03/07/2011 à 19h11 | 👍🏽 👎🏽

@undefined & kevin64: I'm not sure if trolling or very stupid.
<Captain Obvious>Loy ne parle pas d'une erreur de compilation, mais d'un bug ("plusieurs heures de tests, débogage").</Captain Obvious>

Commentaire #158804 écrit par Shirluban le 04/07/2011 à 01h00 | 👍🏽 👎🏽

@Shirluban: Qui parle de bug de compilation ? Avant de traiter les autres de trolls, apprend à comprendre un problème. Je la refais en plus clair, je cite:
"En gros, "si une lettre est égale à un nombre fait...". J'assume. "
Il sous-entend fortement que son bug vient du fait qu'on ne peut pas comparer une lettre et un nombre, non ? Hors, figure toi qu'on peut comparer sans soucis "si une lettre est égale à un nombre", la preuve là : http://pastebin.com/gAqRm1zA

Commentaire #158805 écrit par undefined le 04/07/2011 à 01h23 | 👍🏽 👎🏽

PS : non seulement, on peut le faire mais en plus c'est relativement courant (par exemple pour tester si une chaine ne contient que les caractères de l'alphabet).

PEBKAC ! pour toi aussi Shirluban

Commentaire #158806 écrit par undefined le 04/07/2011 à 01h52 | 👍🏽 👎🏽

[troll]
C++ = CACA !
[/troll]
Dans un langage plus civilisé t'aurais mis trois secondes à comprendre ton erreur...

Commentaire #158807 écrit par Renard le 04/07/2011 à 08h24 | 👍🏽 👎🏽

Hum juste pour en revenir au sujet de départ, n'ayant pas fait de c++, pour moi sa comparaison me semble étrange, il semble vouloir comparer une chaîne de caractère à la taille de celle ci, j'ai bien compris?
Auquel cas il n'a pas "correctement" identifié le problème, je me trompe?
En somme on à un double pebkac?

Commentaire #158808 écrit par Yimi le 04/07/2011 à 09h44 | 👍🏽 👎🏽

@undefined
Mais on parle d'un bug et non d'un problème de compilation !
Oui, le compilo va comprendre le caractère comme étant un nombre (son code ascii), et oui, cela peut être utile pour certains usages.
Mais d'un point de vue sémantique, comparer le code d'un caractère à une longueur de chaîne n'a aucun sens, et ne peut que provoquer un bug.

Commentaire #158809 écrit par BNX le 04/07/2011 à 09h49 | 👍🏽 👎🏽

+1 avec undefined : une variable n'est basiquement qu'une série de bit dont la valeur ne dépend que de la façon de le lire un test (-1==255) peut tout a fait être vrai, si on considère une variable codé sur 8 bit, dans un cas signé, dans l'autre non signé. Suffit d'associer une table de correspondance de caractère et ta série de bit devient un caractère.

Donc c'est toi le pebkac car même si tu a vraisemblablement écrit un code foireux, ta dernière phrase montre un gros défaut de compréhension du language C/C++

Commentaire #158810 écrit par Bear'sBeard le 04/07/2011 à 09h54 | 👍🏽 👎🏽

C'est correct d'un point de vue syntaxique (comparer deux entiers non signés), mais d'un point de vue sémantique, c'est bel et bien une erreur (comparer un nombre représentant un caractère et un nombre représentant une taille). Loy a juste simplifié un peu. La programmation, ce n'est pas juste une histoire de syntaxe.

Commentaire #158811 écrit par korinthen le 04/07/2011 à 10h05 | 👍🏽 👎🏽

@Yimi : c'est ce que je me tue à dire depuis le début.

@Bear'sBeard : Merci, enfin quelqu'un qui sait faire du C/C++ ici (mis à part kevin64).

Pour les autres et leur histoire de "sémantique", sachez que tous les langages n'ont pas des chaines à zero terminal. Confer par exemple cette page :
http://www.cybwarrior.com/2002/03/turbo-pascal-le-traitement-du-texte/
Je cite :
"Lindex 0 de la table correspond à la longueur de la chaîne de caractère"
Ca vous choque "sémantiquement" d'avoir un caractère qui contient une longueur ? On le faisait avant que vous soyez nés et on le fait encore...

Commentaire #158812 écrit par undefined le 04/07/2011 à 11h38 | 👍🏽 👎🏽

(soupir) Ouais enfin là, on ne parle pas de Pascal, mais de C++, et même précisemment de std::string. Or, comparer les valeurs de retour de std::string::operator[] avec std::string::size est bien une erreur.

D'ailleurs, Loy n'a pas dit qu'on ne pouvait pas le faire (il sait bien qu'on _peut_ le faire, puisqu'il l'a fait et que ca lui a coûté plusieurs heures). Et toi tu viens nous démontrer qu'on peut le faire, puisque ca compile. Ben oui, ca compile, on _peut_ le faire. Oui, oui, on _peut_ faire des programmes qui ne marchent pas, mais ca reste une erreur.

Commentaire #158813 écrit par korinthen le 04/07/2011 à 12h01 | 👍🏽 👎🏽

@korinthen: C'est Madame Soleil (paix a son âme) qui t'as que Loy utilisait std::string::size ? Je recite le PEBKAC supposé des fois que certains aurait du mal à le lire :
"En gros, 'si une lettre est égale à un nombre fait...'. J'assume. PEBKAC."

C'est faux, basta, on peut le faire et on le fait couramment, y'a rien à ajouter : Loy est nul en C et ne sait pas debugger un programme (et pas que lui...).

Commentaire #158814 écrit par undefined le 04/07/2011 à 12h12 | 👍🏽 👎🏽

@korinthen: Et histoire de finir en beauté :
Peux-tu me décrire le principe de ce programme ? http://pastebin.com/gAqRm1zA (c'est à la portée de n'importe quel débutant en C)
Pourquoi il affiche "n00b" dans la console et dans quel cas ? Est-ce invalide "sémantiquement" ?

Commentaire #158815 écrit par undefined le 04/07/2011 à 12h19 | 👍🏽 👎🏽

euh... ce qui me dit qu'il utilise std::string, c'est le code : str.size() (bon, d'accord, ca pourrait être une autre classe du même genre, mais ca ne change rien). Loy aurait sans doute mieux fait de dire que son erreur était d'avoir comparé une lettre et une taille, car effectivement un caractère n'est rien d'autre qu'un nombre en C++. Bon.

Dans le code que tu as donné en exemple, tu écris str[i] == 97. Ici, tu compares 2 nombres qui représentent la même chose (un caractère). Loy compare deux nombres qui ont deux significations différentes.

Commentaire #158816 écrit par korinthen le 04/07/2011 à 12h20 | 👍🏽 👎🏽

Le programme cherche la première occurence du caractère 'a' (97 dans la table ASCII) et s'arrête s'il la trouve en affichant "n00b" dans la console.
Mon programme aurait aussi pu définir une chaine de 97 caractères. Dans ce cas, j'aurais mis un appel à une fonction/méthode de calcul de taille de la chaine à la place du 97. Ca aurait été tordu dans ce contexte. Dans le cas de Loy, on ne sait pas pourquoi il fait ça (on n'a pas le contexte) et ça peut très bien avoir un sens fonctionnellement (cf exemple sur les chaines en pascal où le 0ième caractère stocke la longueur de la chaine en cours).

Commentaire #158817 écrit par undefined le 04/07/2011 à 12h31 | 👍🏽 👎🏽

@undifined : quand je vois ton code je tends a penser que tu n'es pas meilleur que Loy, inutile de te montrer desagreable avec ceux qui contestent ce que tu dis. Loy ne code pas necessairement en C++, mais ca n'est pas du C non plus comme indique par l'expression str.size() qui fait clairement reference a un langage object. Que ce soit du C++, du Java, du php, ou tout autre langage dans lequel les objets string ont une methode size(), effectivement ca compile et le programme se lance. N'empeche que la logique du truc est tordue et que le prog ne fait pas ce qu'il devrait faire.

Commentaire #158818 écrit par pwet le 04/07/2011 à 12h32 | 👍🏽 👎🏽

Je vais essayer de clarifier un peu ce que je veux dire. Dans ton programme, tu compares 2 int (ou plutôt un char et un int, mais il me semble que dans ce cas char est converti implicitement en int). Mais dans la sémantique de ton programme (aspect qui échappe totalement au compilateur), ces deux int représentent des lettres. Donc tu compares en fait 2 lettres. C'est valide syntaxiquement et sémantiquement.

Loy compare également deux int, mais le premier représente un caractère alors que le deuxième représente un nombre (une taille). C'est valide syntaxiquement, mais incorrect sémantiquement.

Commentaire #158819 écrit par korinthen le 04/07/2011 à 12h32 | 👍🏽 👎🏽

@pwet: tu m'écriras 100 fois dans le notepad undifined != undefined (et y'a interet à ce que ca compile et ca soit sémantiquement correct !)

"tu dis. Loy ne code pas necessairement en C++"
Einh ??? Où ?

Après je vois que vous avez décidé de réinterpréter le PEBKAC a votre manière : Loy aurait voulu dire que c'est le fait de comparer à la taille de la chaine qui est faux ("sémantiquement"), pas à un nombre en général. Soit. Moi je m'en tiens au fait et je n'extrapole pas.

Commentaire #158820 écrit par undefined le 04/07/2011 à 12h38 | 👍🏽 👎🏽

@korinthen : Et les chaines en pacal, elles sont invalides "sémantiquement" ? Faut arrêter un peu la mauvaise foi là, c'est un problème fonctionnel : donnez moi les specs et je vous dirai si ce genre de code (celui de Loy) à un sens. Sans elles, il est impossible de le savoir.

Commentaire #158821 écrit par undefined le 04/07/2011 à 12h41 | 👍🏽 👎🏽

@undefined : Desole pour la faute dans ton pseudo. La seule raison pour laquelle le code compile c'est que le compilateur realise un cast implicite entre un char et un int, mais le probleme reste que tu compares deux types differents entre eux. Pour l'aspect fonctionnel on peut tres bien imaginer ce qui se passe : une iteration sur une chaine de caractere, avec i comme compteur, et quand i atteint str.size(), ca break (je pense que c'est ce que Loy voulait faire). Sauf que Loy c'est trompe et du coup ca compare un caractere de la chaine avec sa longueur => faute de logique.

Commentaire #158822 écrit par pwet le 04/07/2011 à 12h55 | 👍🏽 👎🏽

Résumons:
Le PEBKAC aurait été un "Bel exemple de PEBKAC" (et encore...) si Loy avait écrit :
- En gros, "si l'indice d'un caractère (dans la table ASCII) d'une chaine est égal à la longueur de cette chaine fait...". J'assume

Mais là, Loy s'est royalement raté dans l'explication de son PEBKAC. Ironiquement, sur ce site quand quelqu'un avoue son PEBKAC, il se prend des "C'est toi le PEBKAC" en rafale. Là, on a un PEBKAC dans le PEBKAC et ca marche ! Ce PEBKAC est dans le positif alors que c'est un énorme "C'est toi le PEBKAC".

Commentaire #158823 écrit par undefined le 04/07/2011 à 14h01 | 👍🏽 👎🏽

@pwet le problème viens du fait que Loy ne voulait probablement pas comparer un caractère en particulier avec la longueur de la chaine.
Ce que Undefined et d'autres (dont moi) reprochent à l'auteur c'est qu'il sous entend que le problème est de vouloir comparer un nombre avec un caractère sous-entendant que ce test est forcément érroné.
Le bug ne viens donc pas du fait d'avoir fait un test qui ne pourrait jamais marcher (ce que je comprend de la dernière phrase du PEBKAC), mais d'avoir fait le mauvais test. D'ailleurs son test erroné pourrait être exact dans certaines applications.

Commentaire #158824 écrit par Bear'sBeard le 04/07/2011 à 14h08 | 👍🏽 👎🏽

Quand Loy écrit "En gros, "si une lettre est égale à un nombre fait..."." il vulgarise pour que les gens qui ne font pas couramment du C/C++ comprennent. Il a bien écrit "En gros", ce qui en français indique qu'il s'agit d'une approximation et donc qu'il ne faut pas tout prendre au pied de la lettre.

"donnez moi les specs et je vous dirai si ce genre de code (celui de Loy) à un sens"
De toute évidence Loy a les specs (puisque c'est son code), et il dit que son bug vient de là. Donc manifestement cette ligne n'a pas de sens dans son programme.

Commentaire #158825 écrit par Shirluban le 04/07/2011 à 14h12 | 👍🏽 👎🏽

J'avoue que je comprends pas vraiment pourquoi Loy ne c'est pas pris des "C'est toi le pebkac". Au final, qu'elle que soit la raison de sa boulette (incomprehension du langage ou faute d'inattention), c'est quand meme lui qui a commis une erreur.

Commentaire #158826 écrit par pwet le 04/07/2011 à 14h17 | 👍🏽 👎🏽

@ undefined
"si une lettre est égale à un nombre fait..."
Où as-tu lu que la "lettre" et le "nombre" faisaient référence au type de variables ? Et si ces deux appellations faisaient référence au contenu sémantique de la variable ?
Oui, à la lecture de son PEBKAC on comprend bien qu'il compare des choux et des carottes, d'un point de vue sémantique et non syntaxique encore une fois.
Et pas la peine de dire "donner moi les spec bla bla", Loy explique par sa dernière phrase l'absurdité de son code.

Commentaire #158827 écrit par BNX le 04/07/2011 à 14h18 | 👍🏽 👎🏽

@undefined
Pour le pascal, ça n'a tout simplement rien à faire ici, et ton explication me fait douter que tu comprenne le terme "sémantique". En pascal, str[0] signifie "longueur de chaîne", et str[1....] signifie "caractère", donc comparer str[0] à une longueur de chaîne est sémantiquement correct, str[0] == str[3] ne le serait pas (en pascal). Ce n'est pas le cas ici, sinon l'auteur n'aurait pas mis la dernière phrase.
Après si tu cherches à donner tord à l'auteur à tout prix en comprenant ce qu'il dit de la pire manière possible...

Commentaire #158828 écrit par BNX le 04/07/2011 à 14h21 | 👍🏽 👎🏽

@pwet: C'est le problème des auto-PEBKAC.
Comme il s'agit effectivement d'un PEBKAC, il faut voter "Bel exemple de PEBKAC !" (+).
Mais comme c'est l'auteur le PEBKAC, il faut voter "C'est toi le PEBKAC !" (-).
Au final, pour indiquer la même chose certains votent (+) et d'autres votent (-).

Pour rester cohérent avec les autres PEBKAC du site, il faudrait voter (+) quand l'anecdote décrit bien un PEBKAC et voter (-) quand il n'y a pas de PEBKAC, sans se soucier de savoir si le PEBKAC est commis par l'OP ou un autre.

Commentaire #158829 écrit par Shirluban le 04/07/2011 à 14h25 | 👍🏽 👎🏽

@BNX: Et qui te dit (Madame Soleil encore ?) que dans le cas présent str[i] ne représente pas la longueur de la chaine ? Pas Loy en tout cas... Il te faudrait ptet' les specs pour le savoir, non ? De la même manière que ces ont les specs de Pascal qui disent que str[0] représente la longueur de la chaine courante.

Commentaire #158830 écrit par undefined le 04/07/2011 à 14h29 | 👍🏽 👎🏽

PS : Il est où le bouton "C'est vous les PEBKACs" ?

Commentaire #158831 écrit par undefined le 04/07/2011 à 14h33 | 👍🏽 👎🏽

@BNX : En pascal, "str[0] == str[3]" pourrait tout a fait être "sémantiquement" correct si dans les specs, il est marqué : "le 3ème caractère de la chaine nommée str est égal à la taille de la chaîne codé sur 1octet"

Commentaire #158832 écrit par undefined le 04/07/2011 à 14h40 | 👍🏽 👎🏽

@undefined
"Et qui te dit (Madame Soleil encore ?) que dans le cas présent str[i] ne représente pas la longueur de la chaine ?"
Non, l'auteur, dans "si une lettre est égale à un nombre fait..."
Quand on voit str[i], on pense tout de suite à un caractère. Mais comme tu le dis, il peut y avoir des exceptions. Donc l'auteur a mis sa dernière phrase pour lever toute ambiguïté et confirmer le PEBKAC.

PS : s'il y avait un tel bouton, j'aurais cliqué sur tes comm, surtout pour les absurdités (ou mauvaise foi) que tu as posté sur tes contre-exemples d'interprétation sémantique.

Commentaire #158833 écrit par BNX le 04/07/2011 à 14h42 | 👍🏽 👎🏽

@undefined à 14:40
Je ne dis pas le contraire, mais ce n'est pas le cas.

On dirais que c'est de plus en plus dur de ne pas admettre que tu as eu tord...

Commentaire #158834 écrit par BNX le 04/07/2011 à 14h46 | 👍🏽 👎🏽

@BNX : "Ceci n'est pas une pipe"
Je cite http://fr.wikipedia.org/wiki/C_(langage)#Types :
"Le type char, généralement utilisé pour représenter un caractère, *est un type entier comme les autres*, si ce n'est que le standard ne précise pas si char équivaut à signed char ou unsigned char"

En C, une lettre n'existe pas, tout simplement.

Commentaire #158835 écrit par undefined le 04/07/2011 à 14h49 | 👍🏽 👎🏽

@BNX donc le PEBKAC de l'auteur c'est juste d'avoir testé a==b au lieu de a==c... heureusement que tout les développeurs ne viennent pas mettre un PEBKAC à chaque fois qu'ils se sont planté dans un test :/
(même si dans ce cas c'était sémantiquement absurde sa dernière phrase me fait craindre qu'il pense que son test soit syntaxiquement inexact).

Commentaire #158836 écrit par Bear'sBeard le 04/07/2011 à 14h51 | 👍🏽 👎🏽

@undefined
T'es lourd. Je sais très bien qu'un char n'est qu'une variable contenant un octet. D'ailleurs en info tout n'est que 0 et 1.
Mais quand on écrit str[i], (notons également le nom de la variable), on a affaire à un caractère dans 99% des cas. Et encore une fois la dernière phrase lève l'ambiguïté.

@Bear'sBeard
str[i] == str.size(), c'est une faute qui saute aux yeux. Après, est-ce que ça valait le coup d'en faire un PEBKAC ? je suis d'accord que ça fait un peu "j'ai oublié une virgule". Mais au pire, c'est une faute trop commune pour un PEBKAC, pas un "c'est toi le PEBKAC".

Commentaire #158837 écrit par BNX le 04/07/2011 à 15h03 | 👍🏽 👎🏽

+1Bear'sBeard

On a tous bien compris que Loy voulait écrire (sauf que personne l'a clairement écrit)
( i == str.size() )
C'était ça son erreur mais son explication, je regrette c'est un pur PEBKAC.

code de sécurité: duuff (ca donne envie de se boire une bonne bière)

Commentaire #158838 écrit par undefined le 04/07/2011 à 15h03 | 👍🏽 👎🏽

C'est vrai que ça ressemble à une collision entre "str[i]==0" et "i=str.size()", ce qui est la même chose à un +1 près.

Je propose de changer le sujet du troll : quelle est la meilleur des deux écritures ?

Commentaire #158839 écrit par BSK le 04/07/2011 à 15h59 | 👍🏽 👎🏽

@BSK : Je ne sais pas, je ne code plus en C/C++ depuis presque 10 ans ;D. Je préfère quand même str.size() car rien ne présume que la classe de l'objet str ne changera pas d'implémentation et qu'elle s'appuira éternellement sur une chaine AZT. Le plus simple, c'est de regarder... les specs ;)

Commentaire #158840 écrit par undefined le 04/07/2011 à 16h07 | 👍🏽 👎🏽

Sur une chaine a zéro terminal, le calcul de la longueur a une complexité linéaire alors que "str[i+1]==0" s'exécute en un temps constant.

Commentaire #158841 écrit par BSK le 04/07/2011 à 16h20 | 👍🏽 👎🏽

@BSK: Ah ben oui mais si la chaine change de taille c'est plus du jeu ! J'aurais mis str.size() en cache dans mon exemple si il y avait eu itération sur ce code (ptet que le compilo le fait tout seul).

Néanmoins, pour revenir sur mon argument, rien ne dit que l'implémentation de la classe string [1] s'appuie sur une chaine AZT... Donc y'aurait potentiellement un risque au niveau de la portabilité du code, non ?
[1] : http://www.cplusplus.com/reference/string/string/

Commentaire #158842 écrit par undefined le 04/07/2011 à 16h28 | 👍🏽 👎🏽

C'est vrai que "str[i]==0" c'est plus du C que du C++

Mais il n'y a pas besoin d'itérer sur le test pour que l'on gagne en perf : pas de parcours de la chaine est toujours plus rapide qu'un parcours :p Bon après c'est pas forcément une portion de code critique non plus...

Commentaire #158843 écrit par BSK le 04/07/2011 à 16h36 | 👍🏽 👎🏽

"Mais il n'y a pas besoin d'itérer sur le test pour que l'on gagne en perf : pas de parcours de la chaine est toujours plus rapide qu'un parcours :p"

Moui moui moui (tu ne t'en sortiras pas comme çà), et ta variable "i" tu l'initilialises à 42 et hop roule ma poule ? Faut ptet itérer un peu (i.e. parcourir la chaine) pour l'incrémenter, non ?

Commentaire #158844 écrit par undefined le 04/07/2011 à 16h45 | 👍🏽 👎🏽

En Pascal str[0] == str[3] ne serait pas correct, car il n'y a pas d'opérateur == en Pascal.

"quelle est la meilleur des deux écritures ?"
Aucune!
En C/C++ une string est pas convention terminée par le caractère nul '

Commentaire #158845 écrit par Shirluban le 04/07/2011 à 17h44 | 👍🏽 👎🏽

(tient! "antislash 0" met fin au commentaire! Pour la suite j'utilise ??/ à la place de l'antislash)
...par le caractère nul '??/0', qui ne vaut pas forcément 0 sur tous les systèmes. Il faut donc écrire str[i]=='??/0'.
Pour i=str.size(), c'est une affectation. On peut s'en servir dans un test logique, mais c'est moins pratique.

Pour str.size() VS parcours de la string, ça dépend de l'implémentation de la classe de str: peut-être que la taille est mise en cache et pas recaculée à chaque appel.

(Ca va, j'ai bon comme troll?)

Commentaire #158846 écrit par Shirluban le 04/07/2011 à 17h50 | 👍🏽 👎🏽

@Shirluban : (Ca va, j'ai bon comme troll?)

Ben oui, ca m'a l'air pas mal ! Je cite:
"le caractère nul 'antislash 0' qui ne vaut pas forcément 0 sur tous les systèmes"
Sur quel(s) système(s) ne vaut-il pas 0 ?

Commentaire #158847 écrit par undefined le 04/07/2011 à 18h21 | 👍🏽 👎🏽

Il me semble qu'une chaine AZT, comme son nom l'indique, est bel et bien toujours terminé par un octet nul (mais je me trompe peut-être). Par contre il n'est maqué nul part dans les spec du C que le pointeur nul vaut « (void*) 0 », même si c'est l'implémentation la plus courante (par contre un pointeur auquel on assigne la valeur 0 sera mis à null même si null n'est pas représenté par 0 physiquement).

Pour ce qui est du nombre de parcours de la chaine, comme « i » est présent dans les deux cas, s'il est obtenu par itération ça fait 1 itération vs 2 au lieu de 0 vs 1 : on y gagne quand-même.

Commentaire #158848 écrit par BSK le 04/07/2011 à 18h38 | 👍🏽 👎🏽

@undefined: Aucun, je suis con, en tant que une séquence déchappement indiquant la valeur du caractère en octal, '??/0' vaut forcément 0.

Commentaire #158849 écrit par Shirluban le 04/07/2011 à 21h52 | 👍🏽 👎🏽

PEBKAC parceque de toute façon tout le monde devrait utiliser wstring (avec des wchar ed'din) :-P

Commentaire #158850 écrit par nigaudouille le 04/07/2011 à 22h42 | 👍🏽 👎🏽

hmm...
http://www.youtube.com/watch?v=5dI6mPDCqEo

Commentaire #158851 écrit par Cartman34 le 04/07/2011 à 23h14 | 👍🏽 👎🏽

Les wchar c'est pas bien, mieux vaut stocker les chaines en utf8 : ça prends moins de place en mémoire et ça passe sans problème dans string.h (avec une nuance sur strlen).

Commentaire #158852 écrit par BSK le 05/07/2011 à 09h50 | 👍🏽 👎🏽

En tous cas, ce post m'aura permis de me rendre rendre compte que la gestion des chaines de caractères en C++, c'est un peu le foutoir :p. Pour le coup il faut reconnaître que des langages "récents" comme Java ont méchamment simplifié le problème.

Commentaire #158853 écrit par undefined le 05/07/2011 à 14h33 | 👍🏽 👎🏽

Par contre le risque c'est quand des gens ont justement appris à develloper sur ces langages "récents" et que tu leur demandent de faire du C...
Ca fait souvent peur.

Commentaire #158854 écrit par Bear'sBeard le 05/07/2011 à 15h24 | 👍🏽 👎🏽

@DSK:
l'UTF8 qui passe "sans problème" avec string.h ?
tu risque d'avoir des problèmes avec strlen mais aussi strncpy (si n est un nombre de caractères) , strchr (le caractère en paramètre est un 'int' et non une chaîne donc il faut d'une part que 'int' soit assez grand pour stocker le caractère en UTF8 donc jusqu'à 6 octets et que tu le calcules avant), ou même strcmp (car on peut encoder un même caractère en plusieurs longueurs en UTF8, même si déconseillé)...
Et la plupart des fonctions renverront une valeur qui n'est même pas multiple simple du nombre de caractères, belle source de bugs.

Commentaire #158855 écrit par nigaudouille le 05/07/2011 à 17h12 | 👍🏽 👎🏽

@nigaudouille : c'est BSK avec un B comme Bernard !
Pour ce qui est de strncpy, je voulais dire que l'on obtient la longueur en octets (sans le 0 terminal) plutôt qu'en caractères.
Je suis d'accord pour le problème avec strchr, mais on peut le remplacer par strstr si l'on ne cherche pas une constante étant un caractère de l'ASCII standard. Par contre chaque caractère a une unique représentation _valide_ en utf8 : la plus courte. Une implémentation correcte ne produit jamais les autres représentations et ne les accepte pas forcément. Si tu n'es pas sûr de la validité de ta chaine, convertis-là.

Commentaire #158856 écrit par BSK le 05/07/2011 à 19h06 | 👍🏽 👎🏽