(Mode non explicite) - Erreur furtive de syntaxe

[Micoute]

Ne pas oublier que PureBasic, n'a de basique que son nom !

[JohnJohnsonSHERMAN]

@ Zorro : Ou plutot une alerte "Impossible de multiplier une structure par un type différent..." parceque franchement je n'en vois pas l'intérêt! On ne peut pas multiplier une structure par un entier par exemple, ca n'a aucun sens, c'est comme multiplier un chien par deux chats, c'est stupide...

Par contre ce serait intéressant de pouvoir faire des opérations (multiplication, addition, division...) sur des structures identiques
Par exemple :

Code : Tout sélectionner

Position.Pos
Facteur.Pos
Position = Position * Facteur

au lieu de :

Code : Tout sélectionner

Position.Pos
Facteur.Pos

Position\x= Position\x * Facteur\x
Position\y = Position\y * Facteur\y

Vous imaginez quand y'a encore plus de champs, la perte de temps?! Ce serait une fonctionnalité intéressante a ajouter, je trouve.

[Fig]

Mov ebx,[adresse variable a] ;a=
imul ebx, [xx] ; a*c
Mov [adresse variable a],ebx ;a=a*c

Olivier>
Mais avant, on a chargé la variable 'a' dans ebx donc de toute façon le compilateur fait la gymnastique de chercher quelle variable va être destinataire avant de faire l'opération.

La syntaxe 'a=a*c' évite la confusion avec les index ayant le préfixe '*'.

Mais enfin, si on fait des opérations sur les index évidemment... Dans l'idéal il faudrait carrément changer le symbol '*', préfixe des index, par un autre en fait.

[djes]

@ Zorro : Ou plutot une alerte "Impossible de multiplier une structure par un type différent..." parceque franchement je n'en vois pas l'intérêt! On ne peut pas multiplier une structure par un entier par exemple, ca n'a aucun sens, c'est comme multiplier un chien par deux chats, c'est stupide...

Par contre ce serait intéressant de pouvoir faire des opérations (multiplication, addition, division...) sur des structures identiques
Par exemple :

Code : Tout sélectionner

Position.Pos
Facteur.Pos
Position = Position * Facteur

au lieu de :

Code : Tout sélectionner

Position.Pos
Facteur.Pos

Position\x= Position\x * Facteur\x
Position\y = Position\y * Facteur\y

Vous imaginez quand y'a encore plus de champs, la perte de temps?! Ce serait une fonctionnalité intéressante a ajouter, je trouve.

Ca s'appelle de la surcharge d'opérateurs, ailleurs (ou en tous cas, ça y ressemble...) Mais oui, ce ne serait pas mal en effet, assez moderne, si cela ne devient pas trop complexe ! Sinon, les débutants risquent d'être un peu déboussolés quand ils liront le code.

[Zorro]

bah moi, du moment que vous ne me retirez pas mon goto

[JohnJohnsonSHERMAN]

J'ai rien contre le Goto moi... enfin c'est plus pour des raisons sentimentales qu'autre choses, c'était une des seules instructions disponibles quand j'ai découvert la programmation y'a quelques années sur les calculatrices casio programmables...
Mais je l'utilise pas en PB, franchement...

[Marc56]

C'est pourtant bien utile le GOTO, notamment pour quitter (presque) proprement
Chose que tout prog PB devait mettre
OnErrorGoto()
Comme ça on sort en cas d'erreur fatale non-gérée sans avoir la boite Windows "le programme ne répond plus"

(désactivez le debuggeur)

Code : Tout sélectionner

EnableExplicit ; Yes! ever!

OnErrorGoto(?PfffCestFoutu)

PokeS(10, "Salut le Monde.") ; ça m..der ça :-)

End

PfffCestFoutu:
MessageRequester("AieAieAie! :-(", 
                 "C'est foutu, je préfère fermer ce binz, parce qu'il me dit:" + 
                 Chr(10) + Chr(10) + 
                 ErrorMessage(), 48)

GOTO++

Extrait du « Manifeste du Vrai Programmeur » (pour les 'tit jeunes, cherchez sur le net)

- Un VÉRITABLE ne craint pas d'utiliser les GOTOs.
- Un VÉRITABLE peut écrire une boucle DO de cinq pages sans se mélanger les pinceaux.
- Un VÉRITABLE préfère les IF arithmétiques, ça prend moins de place mémoire.
- Un VÉRITABLE est capable d'écrire du code auto-modifiant si cela fait gagner 20 nanosecondes.
- Un VÉRITABLE n'a pas besoin de commentaires, il préfère se fier au code.

[Zorro]

il manque :
"- Un VÉRITABLE pense Recursif !, et mange des Spaghettis "

[TazNormand]

Le Goto, n'en déplaise à Zorro et Marc56, est un héritage de la programmation linéaire, pour faire du code "spaghetti", il n'y a rien de mieux que les GOTO/GOSUB

et franchement le OnErrorGoto gagnerait à être remplacé par un "portage" des fonctions POO "Try... Catch...Throw...Finally".

[case]

c très bien comme c'est et pour la POO il y a des langages bien plus adaptés que le basic qui est je le rappelle un langage fait pour ne pas être trop compliqué...
le goto permet des branchements conditionnels qui dans certain cas peuvent êtres utiles
le goto est d'ailleurs toujours tres utilisé sous d'autre formes...

exemple JMP en assembleur

je rappelle que chaque instruction de pure basic est codée en assembleur et que donc tout programme fait des gotos qu'on le veuille ou pas...
après spaghetti ou pas c'est une autre histoire

[Zorro]

oui, il y a des maniacs, qui rangent les spaghettis en parallèle dans leur assiette

moi j'aime bien laisser une part au bazar , du Chaos naît l'ordre

tain j'ai la dalle




ps : a la base le " OnErrorGoto" etait un appel "en parallèle" a une procedure d'erreur
une interception d'une erreur pour la personnaliser , je crois meme qu'on a ça en PB non ?
pas grand chose a voir avec un Goto qui est un saut , mais pas sur interruption

.... en plus je bouffe des Spagghettes aujourd'hui

[Fig]

Pb a une programmation structurée donc dans la plupart des cas, le goto est à éviter.

Néanmoins, comme c'est rappelé plus haut, en assembleur tous les if/else sont des sauts conditionnels.
Donc c'est forcément un code spaghetti, on ne sait pas faire autrement en langage machine.

[Zorro]

a l'origine (ça y est le vieux radote ) un code spaghetti n'est pas forcement la présence de Goto
mais plutot la façon dont on s'en sert ...

voici typiquement un code Spaghettis : (parce que suivre le chemin parcouru par le code, c'est comme suivre le chemin
d'un spaghetti dans l'assiette......)

Code : Tout sélectionner

10 input "votre nom",nom$
20 goto 50
30 print "bonjour ";nom$ 
40 goto 60
50 a=20:goto 30
60 end

alors que ceci n'est pas un code Spaghetti malgres la présence d'un Goto :

Code : Tout sélectionner

10 input "votre nom",nom$
20 print "bonjour ";nom$
30  a=20
40 goto 60
50 Rem cette ligne ne sera jamais parcouru par l'execution
60 end

d'une certaine façon , il m'est deja arriver de voir des codes Purebasic
avec l'esprit Spaghettis ,dans la façon de résoudre un probleme , un algo, Alors meme qu'il n'y avait aucun GOTO
l'esprit Spaghettis est : pourquoi faire simple alors qu'on peut faire compliqué


bref, le Goto est une bonne chose, et n'implique pas un code Spaghetti
mais n'a t'on pas dérivé du sujet là ??

[djes]

Complètement d'accord avec Zorro. En objet aussi on peut faire du spaghetti, et même pire : c'est le jeu des poupées russes, sauf qu'à la fin la poupée fait 20 tonnes.

[Marc56]

et franchement le OnErrorGoto gagnerait à être remplacé par un "portage" des fonctions POO "Try... Catch...Throw...Finally".

+1

Ce serait effectivement sympa de voir PB doté du système de gestion des exceptions façon Delphi.
C'est plus facile à gérer, car plus lisible (IMHO) que les "sauts" avec OnError au niveau codage.

C'est peut-être même plus facile à implémenter niveau compilateur ? (ça, je ne sais pas)