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

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #132 le: 11 mars 2015 à 04:24:03 »
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.
Tu as des exemples de ce qui est complexe à compiler?

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #133 le: 11 mars 2015 à 04:27:04 »
Hey, t'as raison, les deux mots clefs ne sont pas rigoureusement identiques !
longjmp n'est pas un mot clef!

Comme c'est toi, je vais faire un peu de mauvaise foi pour la route : ça reste un goto, au sens sémantique du terme  8)
Ben déjà commence par expliquer comment on utilise setjmp/longjmp.

corrector

  • Invité
Lalala, je suis un petit poney lalala
« Réponse #134 le: 11 mars 2015 à 04:29:56 »
L'idée est d'utiliser la mémoire du processus courant via procfs.
Une solution linux-only n'est pas une solution.

Je te propose donc d'utiliser directement /proc/kcore : tant qu'à utiliser un truc pratique et à ne surtout pas être de mauvaise fois, autant y aller jusqu'au bout !
N'importe quoi!

Mais bon, même en restant théorique : comment peut-on faire pour qu'un programme se coupe volontairement afin d'obtenir des choses du noyau ?
Couper quoi?

Tu veux dire attendre un évènement? Lequel?

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #135 le: 11 mars 2015 à 04:35:40 »
"blablablablablabla"

L'assembleur que j'ai sous les yeux me donne raison;

Je te présente mes condoléances.
Dans ta splendide incompétence, je pense que tu essaies de dire que ça marche dans un cas particulier donc que ton code est correct donc que tu as raison.

No comment...

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #136 le: 11 mars 2015 à 04:39:01 »
4 c'est un entier non ?

donc toto + 4 est une opération entre entiers, juste ?
4 c'est un entier non ?

Donc (en PHP je crois, ou dans un de ses frères) 4*"hello" est une opération entre entiers, juste ?

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #137 le: 11 mars 2015 à 04:43:29 »
Et sortir d'un for comme un malpropre casse le prédicteur de boucle : https://fr.wikipedia.org/wiki/Pr%C3%A9diction_de_branchement#Pr.C3.A9dicteur_de_boucle
Je ne comprends pas.

Qu'est-ce que tu suggères?

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #138 le: 11 mars 2015 à 04:44:03 »


C'est sale car tu sors de la boucle avant la condition de fin.

En gros, tu devrais faire un while et intégrer ton test dans la condition.
Tu pourrais mais je ne vois pas l'intérêt. C'est une vraie boucle for standard (avec une variable de contrôle initialisée, testée et modifiée uniquement dans le "for( ; ; )") avec parfois une sortie anticipée.

Bien sûr ce n'est plus "SESE" et donc il ne faut pas mettre du code de nettoyage en fin de bloc, mais si on peut respecter cette condition, quel est le souci?

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #139 le: 11 mars 2015 à 04:51:43 »
Je m'explique: il y a longtemps, lorsque j'étais étudiant, je programmais sur Solaris avec le compilo de Sun des programmes avec des appels à la Xlib. Ca fonctionnait sans problème.

Un peu plus tard, j'ai re-compilé ces programmes sur Linux m68k (mon Amiga) : avec gcc, aucun problème.

J'arrive sous Linux x86 : je re-compile et ... ça core dump.

Le code était on ne peut plus "normal" sans manipulations complexes, juste avec des tableaux et des variables typées.

Le problème venait du mécanisme d'allocation de gcc 2.95 (Red Hat 5 en 2000) sur la pile: suivant les options d'optimisations, on faisait planter le code à différents endroits sans raison. J'ai longtemps cherché la cause : en fait, à un endroit, j'avais un indice qui débordait d'un tableau.

J'ai reproduit le phénomène avec un simple TP: mon code plantait systématiquement sur Linux x86 et gcc 2.95 et fonctionnait à merveille sous Linux m68k avec une version de gcc plus ancienne. Je l'avais aussi re-compilé sous SAS/C sur AmigaOS: aucun problème non plus (meme pas un warning).
Et ça n'a rien à voir avec le fait que le langage dit qu'un accès hors d'un tableau a un comportement indéfini et n'oblige pas le compilateur à au moins proposer un mode de test avec vérification de ces accès?

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #140 le: 11 mars 2015 à 05:09:39 »
C'est ce que fait GCC avec ses extensions Ada.
Tu peux expliciter ce que fait GCC?

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #141 le: 11 mars 2015 à 05:15:28 »
@Jack: un pointeur est un pointeur, pas en entier. Mais C s'en tape, la preuve:
char *tata = toto + 4;Ca marche car le compilateur s'en moque bien et sait comment s'y retrouver.
Le compilateur ne fait pas d'ironie et applique la sémantique du langage.

La langage C définit l'addition sur un pointeur en fonction du tableau dans lequel pointe ce pointeur.

Un pointeur n'est pas considéré comme un entier en C.

corrector

  • Invité
Lalala, je suis un petit poney lalala
« Réponse #142 le: 11 mars 2015 à 05:17:17 »
Ben justement: il peut parfaitement utiliser %i.
Tu veux dire, s'il ne veut aucune garantie que son programme fonctionne, il peut faire n'importe quoi?

Ada l'interdirait mais C s'en tape. Les types c'est pour les peureux.
Ton savoir concernant le C vient de quel prof maboul?

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #143 le: 11 mars 2015 à 05:19:19 »
Rien qu'a lire ces 2 choses on voit clairement que tu as une connaissance plus que superficiel sur ses sujets...
C difficilement optimisable, pas concu pour être optimisable?! soit tu confond avec optimisation au niveau du source (source-level optimisation) et encore C est aussi tres optimisable a ce niveau, soit t'as carrèment aucune idée de comment un compilateur fonctionne.
Explique-nous "comment un compilateur fonctionne."

A défaut d'être intelligent ça sera amusant.