Auteur Sujet: Programmation : Le GOTO c'est le maaaaaaal  (Lu 50599 fois)

0 Membres et 1 Invité sur ce sujet

EMegamanu

  • Abonné Orange Fibre
  • *
  • Messages: 416
  • FTTH sur Villeurbanne et Oullins (69)
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #36 le: 06 mars 2015 à 21:09:46 »
kgersen laisse tomber... Nous sommes en train de nourrir un troll...

Ça beau être habituel avec corrector, ça me déprime quand même.
Autre chose à faire de mes soirées que de partir dans un débat stérile où un mot aléatoire est retenu dans une phrase et les arguments intéressants ignorés.

Les vrais curieux iront se documenter...

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #37 le: 06 mars 2015 à 21:11:27 »
C'est surtout un bug qui aurait été détecté si les SRI (systèmes de référence inertiels) avaient été validés avec la trajectoire simulée d'Ariane 5.
Ou si les SRI avaient été testés en boucle fermée.
Disons que les bugs existent, qu'est-ce qui justifiait que ce bug provoque cette conséquence?

Rien!

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #38 le: 06 mars 2015 à 21:11:57 »
On parle de 'bas niveau' pour désigner un langage qui est "proche" du cpu, c'est a dire proche de l'assembleur. Par 'proche' on entend la complexité qu'il faut pour le compiler et le traduire en assembleur et le faible niveau d'abstraction qu'il offre.

A l'inverse on parle de 'haut niveau' pour les langages qui sont 'loin' du cpu, qui ont un haut niveau d'abstraction et sont souvent interprétés au lieu d'être compilés et dont la compilation, quand elle a lieu, est souvent complexe. D'ailleurs en pratique on compile souvent un langage de haut niveau vers un langage de bas niveau qu'on compile ensuite en assembleur pour générer du code exécutable. Cela permet de simplifier la portabilité et les optimisations: en générant du C on peut après le compiler et l'optimiser avec les outils propres a chaque OS et au passage, on profite des décennies de progrès faites sur la compilation du C.

Il fréquent d'ailleurs dans le code C généré par les compilateurs (et les "transpileurs") de haut niveau de générer énormèment de goto.
Qu'est-ce que tu appelles "complexe"?

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 481
  • Malissard (26)
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #39 le: 06 mars 2015 à 21:12:49 »
C'est surtout un bug qui aurait été détecté si les SRI (systèmes de référence inertiels) avaient été validés avec la trajectoire simulée d'Ariane 5.
Ou si les SRI avaient été testés en boucle fermée.

Suffisait de relire le cahier des charges pour se rendre compte qu'aucun des systèmes inertiels n'était prévu pour la poussée d'Ariane 5.



corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #40 le: 06 mars 2015 à 21:14:33 »
Suffisait de relire le cahier des charges pour se rendre compte qu'aucun des systèmes inertiels n'était prévu pour la poussée d'Ariane 5.
Pourquoi le composant était toujours actif?

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 481
  • Malissard (26)
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #41 le: 06 mars 2015 à 21:16:51 »
Quel composant ?

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #42 le: 06 mars 2015 à 21:17:59 »
Qu'est-ce que tu appelles "complexe"?

l'antonyme de simple

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #43 le: 06 mars 2015 à 21:25:17 »
l'antonyme de simple
On est bien avancé...

eruditus

  • Client Orange adsl
  • Modérateur
  • *
  • Messages: 11 015
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #44 le: 06 mars 2015 à 21:31:52 »
On est bien avancé...
C'est pourtant simple ou pas complexe.

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #45 le: 06 mars 2015 à 21:44:24 »
GCC C est "simple", oui oui oui...

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #46 le: 06 mars 2015 à 22:27:52 »
kgersen laisse tomber... Nous sommes en train de nourrir un troll...

Ça beau être habituel avec corrector, ça me déprime quand même.
Autre chose à faire de mes soirées que de partir dans un débat stérile où un mot aléatoire est retenu dans une phrase et les arguments intéressants ignorés.
Pardon, mais les arguments que j'ai vu était pas vraiment intéressants, et même plutôt à coté de la plaque pour être gentil.

C n'est pas du tout un langage adapté ni pour être proche du matériel (voir le merdier du C dans les parties proche du matériel de linux) ni pour être efficace. D'ailleurs être efficace et être de bas niveau sont des objectifs incompatibles pour un langage de programmation primaire comme le C.

A contrario : Ada

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #47 le: 06 mars 2015 à 22:33:00 »
On parle de 'bas niveau' pour désigner un langage qui est "proche" du cpu, c'est a dire proche de l'assembleur. Par 'proche' on entend la complexité qu'il faut pour le compiler et le traduire en assembleur et le faible niveau d'abstraction qu'il offre.

A l'inverse on parle de 'haut niveau' pour les langages qui sont 'loin' du cpu, qui ont un haut niveau d'abstraction et sont souvent interprétés au lieu d'être compilés et dont la compilation, quand elle a lieu, est souvent complexe. D'ailleurs en pratique on compile souvent un langage de haut niveau vers un langage de bas niveau qu'on compile ensuite en assembleur pour générer du code exécutable.
Ce serait sympa de donner des exemples.

Cela permet de simplifier la portabilité et les optimisations: en générant du C on peut après le compiler et l'optimiser avec les outils propres a chaque OS et au passage, on profite des décennies de progrès faites sur la compilation du C.
Le C est très difficilement optimisable. Il n'a pas été conçu pour être optimisable. Et quand un compilateur décide de s'amuser à vraiment optimiser il casse énormèment de code, voir linux par exemple. La "sémantique" est un vrai merdier.

Il fréquent d'ailleurs dans le code C généré par les compilateurs (et les "transpileurs") de haut niveau de générer énormèment de goto.
Oui parce que goto est l'opération élèmentaire qui défini les "structures" de la soi-disant programmation structurée.