 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
5 messages in org.openoffice.fr.progRe: [prog] Une bizarerie| From | Sent On | Attachments |
|---|---|---|
| Fabien | Mar 31, 2008 7:31 am | |
| Bernard Marcelly | Mar 31, 2008 11:52 am | |
| Fabien | Apr 1, 2008 7:37 am | |
| Serge Potteck | Apr 1, 2008 1:56 pm | |
| Fabien | Apr 2, 2008 3:48 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [prog] Une bizarerie | Actions... |
|---|---|---|
| From: | Serge Potteck (serg...@cegetel.net) | |
| Date: | Apr 1, 2008 1:56:50 pm | |
| List: | org.openoffice.fr.prog | |
Bonjour,
Est-ce si étonnant ?
Dans le premier cas, il compare un texte et un entier. Forcément false. Dans le second cas, il y a un changement implicite de type lors de la déclaration de SansEspace. Du coup, à la comparaison, il compare deux entiers, et c'est true.
Non ?
Serge
Fabien wrote:
Le Monday 31 March 2008 22:52:37 Bernard Marcelly, vous avez écrit :
Message de Fabien date 2008-03-31 16:31 :
Bonjour,
Que pensez-vous du petit programme suivant:
Sub main dim texte as string dim SansEspace as string texte = " 3" print CBool(Ltrim(texte) = CInt(texte)) SansEspace = Ltrim(texte) print CBool(SansEspace = CInt(texte)) end sub
Pour le premier "print", j'obtiens "False", pour le deuxième "True". Etonnant, non?
Oui, le comportement de Basic est un peu étrange. Mais ce codage est d'abord incorrect. On compare des oranges et des carottes! Un des termes de la comparaison est du type String, l'autre est du type Integer. Un codage correct est: print CBool(Ltrim(texte) = CStr(CInt(texte)))
On doit toujours se rappeler que Basic fait des conversions implicites pour faire une réponse "intelligente" (à la place du programmeur). Et des fois il se trompe.
Pourquoi la deuxième expression donne True ? Je remarque que si SansEspace est déclaré comme Variant, le résultat est False. Peut-être que LTrim() renvoie un variant. Un variant n'a pas de type figé, ça déroute un peu Basic pour évaluer?
Merci pour la réponse. En fait, c'est en testant comment Basic gère ces incohérences de type que je suis tombé sur ce test. J'avais remarqué que l'on pouvait concaténer une chaîne de caractère et un entier, l'entier étant automatiquement converti en chaîne. De même que comparer un entier et une chaîne, l'entier étant convertie en chaîne (donc 100<"99" pour OOo). Je me demandais s'il était pertinent d'utiliser ces possibilités. Je crois que la réponse est non! Ceci dit, je trouve tout de même étonnant les résultats donnés par le programme. Et le fait que la réponse soit différente selon que SansEspace soit déclaré comme Variant ou comme String est d'autant plus étonnant que si l'on demande le type de SansEspace (avec TypeName) après l'instruction "SansEspace = Ltrim(texte)" la réponse est "String" quelque soit la définition initiale.
Je reconnais que ça n'a pas beaucoup d'importance, mais ça m'interpelle...
Cordialement,
Fabien.
______ Bernard