Page 1 sur 1
bug ou non ? 5.42 LTS 32/64
Publié : jeu. 03/mars/2016 11:52
par Anonyme2
J'ai cherché un moment car je n'arrivais pas à obtenir le résultat que j'attendais sur des chaines (mauvais placement d'une parenthèse).
Je ne sais pas si le traitement des chaines a changé alors...
Voilà le code, je pense à bug
le code OK
Code : Tout sélectionner
Texte$ = LSet("", 31, "*")
Debug Texte$
Texte1$ = Left( Texte$, (( Len(Texte$)-Len(" PUREBASIC ") )/2) +1 ) + " PUREBASIC "
Debug Texte1$
Dans le code qui suit c'est le même sauf que j'ai sorti le +1 des parenthèse mais ce 1 est pris comme une chaine.
Vous pouvez remplacer le 1 par 33 ou 170.1 le résultat est que ce nombre est considéré comme une chaine
Code : Tout sélectionner
Texte$ = LSet("", 31, "*")
Debug Texte$
Texte1$ = Left( Texte$, ( ( Len(Texte$) - Len(" PUREBASIC ") )/2 ) ) + 170.1 + " PUREBASIC "
Debug Texte1$
Même chose avec
Re: bug ou non ? 5.42 LTS 32/64
Publié : jeu. 03/mars/2016 12:08
par Ar-S
Salut Denis,
Je ne pense pas que ce soit un bug.
Pour simplifier l'affichage des données et du coup pour éviter d'avoir à taper STR(valeur) ou Val("chaine") cette méthode est en place depuis un moment.
Tu demandes à PB d'afficher une chaine de caractères (Texte$), c'est ce qu'il fait.
Par contre si tu demandes un affichage d'une valeur (dans mon exemple, "d"), il affichera bien la somme de 20+20 dans la chaine.
Code : Tout sélectionner
a = 10
b.s = "chiffre = "
c.s = " suivant = "
d = 20 + 20
Debug b.s + a + c.s + d ; marche, il affiche une suite de données prés établies
Debug "chiffre = " + 10 + " suivant = " + 20 + 20 ; ici il n'affiche que du string donc le calcule ne s’opèrera pas, on ne lui a pas demandé.
Debug "chiffre = " + 10 + " suivant = " + Str(20 + 20) ; ici ça marche car mon lui demande un affichage de string d'une addition.
Dans ton exemple tu t'es effectivement trompé dans tes parenthèses.
Comme tu l'as vu comme ça ça fonctionne
Code : Tout sélectionner
Texte1$ = Left( Texte$, (Len(Texte$)-Len(" PUREBASIC ") /2) + 10) + " PUREBASIC "
Re: bug ou non ? 5.42 LTS 32/64
Publié : jeu. 03/mars/2016 13:54
par Marc56
J'ai découvert aussi ça (par hasard) il y a peu. (5.4x ?)
C'est très commode pour gagner du temps, mais que ça ne marche que si la sortie
debug commence par une chaine
Code : Tout sélectionner
i = 1
Debug "a" + i ; OK plus besoin de faire un transtypage: Debug "a" + Str(i)
Debug i + "a" ; KO: Message: « Impossible de combiner chaines de caractères et valeurs numériques. »
; Il faut alors écrire de manière classique
Debug Str(i) + "a"
; Ou forcer la chaine
Debug "" + i + "a"
Re: bug ou non ? 5.42 LTS 32/64
Publié : jeu. 03/mars/2016 13:58
par Anonyme2
Salut Ar-S,
ok je comprend pour l'affichage mais ca marche aussi avec le code que j'ai posté :
Code : Tout sélectionner
Texte$ = LSet("", 31, "*")
Debug Texte$
Texte1$ = Left( Texte$, (( Len(Texte$)-Len(" PUREBASIC ") )/2) +1 ) + " PUREBASIC "
Debug Texte1$
ici c'est pas le debug le problème (affichage) mais c'est l'affectation de la chaine c'est-à-dire affecter une variable numérique à une chaine sans les "", mais peut-être que c'est normal.
Je n'avais pas trouvé dans la doc mais je viens de recommencer et j'ai trouvé ceci depuis la 5.10
Ajouté: Autocast les valeurs numériques lorsque des chaînes sont impliquées, ce qui permet de concaténer des chaînes et des nombres dans les constantes
Bon, je ne suis pas sur vu que j'ai du mal à comprendre la phrase mais bon ...
Re: bug ou non ? 5.42 LTS 32/64
Publié : jeu. 03/mars/2016 14:11
par Ar-S
Je ne pense toujours pas que ce soit un bug, vue que lorsque les parenthèses sont bien placée ça fonctionne. Mais je vois ce que tu veux dire, l'absence de guillemets prête à confusion.
Il faudrait voir ce que Fred pourrait dire sur ça.
Re: bug ou non ? 5.42 LTS 32/64
Publié : jeu. 03/mars/2016 14:15
par Marc56
Je ne vois pas où est le problème, la syntaxe est correcte
(ou alors j'ai rien compris
)
Mis à part que cet empilage de () c'est pour vouloir ressembler à du Lisp ?
(Dixit Wikipedia: Cette utilisation des parenthèses donne lieu à des moqueries sur le nom de LISP : « Lots of Irritating and Silly Parentheses » (« Des tas de parenthèses irritantes et idiotes »), ou « Lots of Insipid and Stupid Parentheses » (« Des tas de parenthèses insipides et stupides »).
PS. C'est vrai que
Autocast, ce n'est ni un nom, ni un verbe français. Il y aurait peut être matière à voir si ça peut se remplacer (un jour) par autre chose de plus parlant ? (ceux qui n'ont jamais fait fait de C ne vont pas forcement comprendre)
Re: bug ou non ? 5.42 LTS 32/64
Publié : jeu. 03/mars/2016 14:22
par Anonyme2
Marc56 a écrit :Je ne vois pas où est le problème, la syntaxe est correcte
(ou alors j'ai rien compris
)
Mis à part que cet empilage de () c'est pour vouloir ressembler à du Lisp ?
Ce n'est que l'absence de guillemets qui me gène mais vu la phrase de la doc qui peut-être se rapporte à ça ... (mais je ne suis pas sur de comprendre).
Sinon l'exemple est un exemple type.
Mon code ou j'avais l'erreur est plus long et avec plus de parenthèses
Dans de long codes, pour éviter les problèmes, je sépare les expressions par des parenthèses et ça me va bien
vu qu'elles sont faites pour ça
Re: bug ou non ? 5.42 LTS 32/64
Publié : jeu. 03/mars/2016 14:34
par Fred
PureBasic permet cette syntaxe depuis 2-3 versions de mémoire, pour caster automatiquement les nombres en chaines (et eviter trop de Str()).
Re: bug ou non ? 5.42 LTS 32/64
Publié : jeu. 03/mars/2016 14:44
par Anonyme2
Ok Fred.
Peut-être faudrait-il remettre la phrase de la doc de manière à ce qu'elle soit mieux comprise.