Existe t-il un langage qui supporte le système de "labels" ?

Bonsoir,

A part le Batch, je ne connais pas d'autres langages qui supportent le système de "labels". Pour ceux qui ne savent pas ce que c'est, voici un pseudo-code d'un logiciel qui affiche le message "Hello World!" à l'infini.

Code:

---

1 2 3

label("ma_boucle"); echo "Hello World!"; goto("ma_boucle");

---

J'éspère que vous avez compris du premier coup de quoi il s'agit. Enfin bref, pourquoi les langages les plus connus ne supportent pas ce système ? Est-il pratiquement impossible de le faire dans un langage comme le C ?

Enfin j'aimerais avoir votre avis.
Merci d'avance,

Hoffa.

Citation:

---

Envoyé par Hoffa

Bonsoir,

A part le Batch, je ne connais pas d'autres langages qui supportent le système de "labels".
[...] Enfin bref, pourquoi les langages les plus connus ne supportent pas ce système ? Est-il pratiquement impossible de le faire dans un langage comme le C ? [...]
Hoffa.

---

8O le C ne peut pas faire de goto ? Si...
En fait quasiment tous les langages impératif ont un mécanisme dans ce genre. Pour les langages fonctionnels il y a les continuations qui mènent à la même chose.

Où as-tu vu que tu ne pouvais pas le faire en C?

Code:

---

1 2 3

etiquette: printf("Hello World!\n") ; goto etiquette;

---

Bien sûr, on te déconseille les goto parce qu'en général ils sont mal utilisés. Et vu ta question, je suppose que tu ne sais pas concevoir correctement des programme (manque d'expérience pas de qualité personnelle) et, par conséquent, tu devrais éviter de les utiliser -_- C'est une mine d'erreurs et d'horreurs !

En effet ce programme

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

int main () { int n = 0; etiquette: printf("Hello world\n"); if ( n < 10 ) { n++; goto etiquette; } return 0; }

---

montre que tu ne sais pas concevoir correctement tes programmes car tu n'as pas conceptualisé ta boucle sans une forme logique et abstraite. En gros, tu as voulu programmer sans réflechir avant d'agir.

Code:

---

1 2 3 4 5 6 7 8 9

int main () { int i; for (i=0; i<10; i++) printf ("Hello world\n") ;   return 0; }

---

est la bonne façon de faire.

Évites aussi d'être aussi sûr de toi quand tu ne sais pas. Ça évites d'avoir l'air bêbette par la suite ;) Parce que là, tu viens finalement de démontrer que tu ne connais pas d'autres langages :mrgreen:

Garulfo: En fait non, je n'ai JAMAIS utilisé le système de labels, jamais. Si j'ai demandé cette question, c'était juste pour m'instruire. Je ne compte pas utiliser ce système, c'était juste que... je voulais savoir. Enfin après tout, ça ne fait jamais de mal d'apprendre une nouvelle chose. Si je n'ai pas su que quasiment tous les langages supportaient ceci, eh bien c'est parce que je ne suis pas encore assez expérimenté, ou bien parce que je ne me suis pas intéressé auparavant. :)

Citation:

---

Envoyé par Garulfo

Bien sûr, on te déconseille les goto parce qu'en général ils sont mal utilisés.

---

disons que les saletés doivent ne pas être enseignées aux débutants... voire être interdites dans 90% des cas où l'on voit les gens s'en servir

mais à partir d'un certain niveau, ces saletés deviennent extrêmement utiles car elles permettent de faire énormement de choses sans vérification, et donc de gagner beaucoup en perf

exemple : sans les goto, aurait-on un moyen rapide de faire un interprète threaded code ?
il faut bien avouer que ça permet de gagner un facteur 2 sur le fonctionnement de la machine virtuelle, mais qu'il faut refléchir correctement dès la conception car ça devient très dur à déboguer ;)

Citation:

---

Envoyé par gorgonite

[...]
exemple : sans les goto, aurait-on un moyen rapide de faire un interprète threaded code ?
il faut bien avouer que ça permet de gagner un facteur 2 sur le fonctionnement de la machine virtuelle, mais qu'il faut refléchir correctement dès la conception car ça devient très dur à déboguer ;)

---

J'espère que par « un moyen rapide » tu n'entends pas « développer vite fait ». Car, en général, les erreurs potientielles vont, statistiquement, augmenter le temps de développement. C'est pourquoi même si c'est plus long, même si on y perd en performance, il vaut mieux passer par de la programmation « propre ». Que celle-ci puisse être parfois faite avec un goto, c'est une chose et j'y adhère. Mais la plupart du temps, on peut très bien, sans réel perte passer par un autre mécanisme. Et c'est là le problème : les gens cèdent à la facilité.

Donc comme tu le dis « il faut réfléchir correctement dès la conception car ça devient très dur à déboguer, » c'est souvent là que le bât blesse ^_^

Sinon, je reviens dessus et j'insiste, les études montrent que les besoins de modification liées aux performances insuffisantes représentent moins de 3% des efforts alors que ceux liés au besoin insatisfait ou à une conception qui ne respecte pas la spécification sont de 40%. On s'entend bien donc que s'il faut viser quelque chose c'est la fiabilité et la propreté de conception plus que des bonnes performances.

Citation:

---

Envoyé par Garulfo

On s'entend bien donc que s'il faut viser quelque chose c'est la fiabilité et la propreté de conception plus que des bonnes performances.

---

et c'est là que tous les concepteurs de langages un peu évolués se plantent, et obligent les domaines de niche à rester sur de l'asm ou des sous-ensembles c...

j'ai pris un exemple très précis, celui des machines virtuelles, et là le fait d'économiser en mémoire et en temps de calcul peut avoir des incidences énormes, car elles permettront ensuite à des programmeurs moins expérimentés de concevoir des programmes plus simples, sans barbarie inutile, car 80% des perfs seront gagnées au niveau inférieur

on peut se demander pourquoi kaffe se vend moins bien que la vm d'esmertec dans le domaine de Java pour systèmes mobiles... réponse : parce que Sun a laissé un boulot de stagiaire arriver en prod, et qu'une seule personne peut les mettre mal en moins de 6 mois : ce fut mon cas, je leur pris un facteur entre 2 et 5 alors que je ne suis pas un pro des optimisations bas niveau, et j'ai moins de bugs que celle d'origine ^^


donc au risque de me répéter : tous les débutants doivent apprendre des choses propres, privilégier l'algorithmie, la modularité et la lisibilité...
mais passer un certain cap, dans certains domaines, ils seront obligés de faire des choses plus sales, et là il aurait mieux valu qu'on leur ait expliqué ce qu'ils peuvent faire, et surtout comment ils doivent s'y prendre pour ne pas déboguer un projet durant un mois :aie:

Citation:

---

Envoyé par gorgonite

[...]
donc au risque de me répéter : tous les débutants doivent apprendre des choses propres, privilégier l'algorithmie, la modularité et la lisibilité...

---

Ça oui... on est d'accord

Citation:

---

mais passer un certain cap, dans certains domaines, ils seront obligés de faire des choses plus sales

---

Non pas forcément. Tu généralises trop à ce que tu vis je pense.
En exemple, plus de 50% des informaticiens au Canada, par exemple, travaille sur des systèmes d'information où les performances ne sont pas dans les priorités... En fait, la majorité des travaux des informaticiens portent sur des tâches où on peut relèguer les performances en seconde ligne. Donc, sur le terrain, peu sont obligés de faire des choses sales ! C'est souvent qu'ils ne savent pas construire une architecture digne de ce nom. C'est donc leurs lacunes en conception qui réapparaît. Très peu de domaine ont réellement besoin qu'on aille se mouiller les mains dans le cambouis des tweakages. Maintenant, il y a des domaines où tu as complètement raison. Mais la majeure partie de la production en informatique ne nécessite pas autre chose que de bien comprendre ce qu'est une conception et de savoir agir au niveau de l'architecture.

Et je suis aussi complètement en accord quand tu dis qu'il faut que les concepteurs de langages ouvrent leurs esprits pour offrir des concepts de hauts niveaux et travailler sur leurs optimisations en sous-couches. En fait, je suis tellement d'accord que c'est ma branche d'une certaine manière. :mrgreen:

L'autre chose est qu'on vise à faire de l'informatique ce qu'il devrait être : un outil pour les non-informaticiens. Mais c'est un autre débat.

Salut à tous :)

Citation:

---

Envoyé par gorgonite

exemple : sans les goto, aurait-on un moyen rapide de faire un interprète threaded code ?
il faut bien avouer que ça permet de gagner un facteur 2 sur le fonctionnement de la machine virtuelle, mais qu'il faut refléchir correctement dès la conception car ça devient très dur à déboguer ;)

---

gorgonite, est-ce que tu peux expliquer d'avantage cette idée ? merci d'avance :)

enfin, dans le genre horrible, COBOL permet les GO TO, mais aussi les ALTER - qui changent la cible du GO TO. Absolument illisible et inmaintenable. Pouark.

Citation:

---

Envoyé par Chatbour

gorgonite, est-ce que tu peux expliquer d'avantage cette idée ? merci d'avance :)

---

bien sûr... étant donné que c'est une partie de mon stage de master, ça devrait être possible ;)


commençons par présenter le schéma classique d'interprétation de bytecode :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

bytecodes = enumération de taches (add, mul, ifeq, ..., end) programme = tableau de bytecode indice = 0 tant que (instr = programme[indice++]) != end selon la valeur de instr faire cas add : ... cas mul : ... cas par défaut : "erreur de bytecode" fin selon fin tant que

---

on remarque qu'il y a 3 instructions de controle pour 1 instruction de bytecode (ratio 3:1)

1. test sur le bytecode courant au niveau du "while"
2. saut indirect grâce à une table des valeurs du "switch"
3. saut pour revenir en début de boucle

c'est le principe de fonctionnement de la j2ME (kaffe)



le threaded code permet de réduire le ratio à 1:1 au prix de l'allocation de l'adresse du début de la séquence de chaque bytecode

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

bytecodes = enumération de taches (add, mul, ifeq, ..., end) table_addr = [addresse add, addresse mul, ...] // indexée selon l'enum bytecode programme = tableau de bytecode indice = 0 aller à l'étiquette : table_addr[programme[indice++] etiquette add: ... aller à l'étiquette : table_addr[programme[indice++] etiquette mul: ... aller à l'étiquette : table_addr[programme[indice++] etiquette end: sortir de la fonction d'interpretation

---

on voit qu'on a juste un "goto" à la fin de chaque exécution de bytecode




maintenant si l'on considère que les bytecode sont "bas niveau", donc ne font pas grand chose individuellement, on voit que le cout des traitements de controle peut être significatif par rapport au cout du bytecode
=> donc le threaded code peut rapporter beaucoup sur de tels langages (la jvm est un bon exemple)


le hic : avec l'augmentation des longueurs de pipelines et les prédictions de branchements hasardeux sur certaines architectures, on peut se retrouver avec un threaded code plus lent qu'un interprète classique (c'est le cas sur une architecture Prescott alors qu'une architecture amd64 s'en sort grâce une mémorisation asticieuse des branchements antérieurs)


pour aller plus loin : la ratio 1:1 peut être réduit à 1:N si l'on considère la notion de basic bloc d'instructions successives sans branchement... on va alors générer des buffer code exécutable, mais il faudra faire attention à la gestion mémoire, au cout de la génération, à la réutilisation éventuelle, etc
par ailleurs, si tu ajoutes des optimisations à la volée dans les basic bloc générés, tu te retrouves avec une compilation JIT (Just-In-Time) comme sur la j2se (jvm pour machine de bureau) ou une DAC (Dynamic and Adaptative Compilation) comme avec la jvm embarquée d'esmertec

Citation:

---

Envoyé par gorgonite

mais passer un certain cap, dans certains domaines, ils seront obligés de faire des choses plus sales, et là il aurait mieux valu qu'on leur ait expliqué ce qu'ils peuvent faire, et surtout comment ils doivent s'y prendre pour ne pas déboguer un projet durant un mois :aie:

---

Citation:

---

Envoyé par Garulfo

Non pas forcément. Tu généralises trop à ce que tu vis je pense.

---

100% d'accord avec Garulfo.

Je crois, Gorgonite , que ton expérience, aussi grande soit-elle, reste limitée (et d'ailleurs ton post précédent le prouve) à un certain domaine et langage et environnement.

Quand on doit faire des choses "sales", c'est en général qu'on maîtrise parfaitement son domaine (pour de l'optimisation par exemple).

Mais je suis au regret de te dire qu'en 28 ans de carrière, à part dans mes premiers programmes en Fortran, je n'ai JAMAIS utiisé de goto.

Si maintenant des soi-disant "chefs de projets" mettent des quasi-débutants à faire de l'optimisation, tant pis pour eux. Mais ce ne doit pas être un exemple ni à donner ni à suivre..

Et si, pour utliser certains langages, on est obligés de faire des choses "sales" tout de suite afin d'avoir un temps réponse correct, alors la conclusion est qu'il faut changer de langage ou de paradigme (dans ton cas, plus de machine virtuelle, mais un véritable langage compilé).

Citation:

---

Envoyé par souviron34

(.../...) Mais je suis au regret de te dire qu'en 28 ans de carrière, à part dans mes premiers programmes en Fortran, je n'ai JAMAIS utiisé de goto.

Si maintenant des soi-disant "chefs de projets" mettent des quasi-débutants à faire de l'optimisation, tant pis pour eux. Mais ce ne doit pas être un exemple ni à donner ni à suivre..
(.../...)

---

A mon grand regret, je viens d'en coder un aujourd'hui. Mais j'avais le choix entre refondre un paragraphe de 200 lignes que je ne savais pas tester et faire un GO TO pour le contourner..... Si j'avais su tester l'ensemble du bidule, je me serais risqué à refondre.

D'une manière générale, j'essaie de ne pas détruire un programme qui existe(et je n'ai pas le temps de le refaire proprement). Il est hélas très sale. Alors je suis obligé de gérer avec ce dont je dispose. Mais quand je crée du nouveau, évidemment, je fais au plus propre(et si certains considèrent que le GO TO FIN-PARAGRAPHE est acceptable, moi pas). Après, il est possible que mon code apparaisse comme sale à d'autres, on est tous le crado de quelqu'un.....

Citation:

---

Envoyé par el_slapper

A mon grand regret, je viens d'en coder un aujourd'hui. Mais j'avais le choix entre refondre un paragraphe de 200 lignes que je ne savais pas tester et faire un GO TO pour le contourner..... Si j'avais su tester l'ensemble du bidule, je me serais risqué à refondre.

D'une manière générale, j'essaie de ne pas détruire un programme qui existe(et je n'ai pas le temps de le refaire proprement). Il est hélas très sale. Alors je suis obligé de gérer avec ce dont je dispose. Mais quand je crée du nouveau, évidemment, je fais au plus propre(et si certains considèrent que le GO TO FIN-PARAGRAPHE est acceptable, moi pas). Après, il est possible que mon code apparaisse comme sale à d'autres, on est tous le crado de quelqu'un.....

---

Ton choix est compréhensible. Et là on retombe sur la remarque de Gorgonite (quelque peu transformée, mais l'esprit est le même) : où sont les outils qui nous permettrait de faire un meilleur reformatage ? Pourquoi les langages ne sont-ils pas plus designés pour être de plus haut niveau ?

Je pense qu'il manque de travail en ce sens. La plupart du temps ceci surgit d'un effort plus personnel que réellement conscientisé hélas.