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

corrector · « **Réponse #84 le:** 07 mars 2015 à 09:35:33 »

Citation de: EMegamanu le 06 mars 2015 à 19:39:53

Il entend bas niveau dans le sens abstraction :
- gestion manuelle de la mémoire du tas vs les garbage collector du C# ou du Java,

Tu peux utiliser un GC en C. Beaucoup de gens le font.

Tu peux faire des désallocations explicites en Java. Beaucoup de gens le font, surtout au début parce que le GC était monstrueusement inefficace.

Les autres ressources que la mémoire doivent bien être gérée manuellement!

kgersen · « **Réponse #85 le:** 07 mars 2015 à 09:36:50 »

Citation de: BadMax le 07 mars 2015 à 09:25:56

Bon je vous ressers des cahuètes mais faudrait consommer messieurs.

ben soit on insiste juste qu'a ce qu'il pète les plombs comme d'hab et le sujet va être fermer
soit on n'insiste pas et il va se lasser et trouver un autre sujet a polluer.
Le tout est donc de bien doser la provoc pour l'occuper ici le plus longtemps possible comme ca il ne viendra pas polluer les sujets intéressants.
C'est tout un art de manipuler le Corrector

corrector · « **Réponse #86 le:** 07 mars 2015 à 09:42:37 »

Citation de: EMegamanu 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.

Je comprends. Si tu ne veux pas que je te mouche, ben va ailleurs.

corrector · « **Réponse #87 le:** 07 mars 2015 à 09:43:21 »

Citation de: kgersen le 07 mars 2015 à 09:36:50

ben soit on insiste juste qu'a ce qu'il pète les plombs comme d'hab et le sujet va être fermer
soit on n'insiste pas et il va se lasser et trouver un autre sujet a polluer.
Le tout est donc de bien doser la provoc pour l'occuper ici le plus longtemps possible comme ca il ne viendra pas polluer les sujets intéressants.
C'est tout un art de manipuler le Corrector

Tu argumentes ou tu t'écrases.

corrector · « **Réponse #88 le:** 07 mars 2015 à 09:43:48 »

Citation de: kgersen le 06 mars 2015 à 21:00:41

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.

N'importe quoi. Tu es la seule personne au monde à utiliser cette définition.

Citation de: kgersen le 06 mars 2015 à 21:00:41

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.

Donc C et C++ sont de haut niveau : la compilation de C est souvent complexe! (Pour C++ on peut enlever le souvent.)

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.

Non. On ne compile presque jamais vers un langage qui est utilisé par des humains.

Citation de: kgersen le 06 mars 2015 à 21:00:41

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 faut une très très grande prudence pour écrire du code portable en C, il y a énormèment de pièges, énormèment de différences entre les compilateurs et les environnements.

Enfin même en Java ce n'est pas évident d'écrire du code portable...

Citation de: kgersen le 06 mars 2015 à 21:00:41

Il fréquent d'ailleurs dans le code C généré par les compilateurs (et les "transpileurs")

Je n'ai jamais vu ce terme!

BadMax · « **Réponse #89 le:** 07 mars 2015 à 11:12:07 »

Citation de: corrector le 07 mars 2015 à 09:43:48

N'importe quoi. Tu es la seule personne au monde à utiliser cette définition.

Non on doit etre deux. Je ne compte pas les gens qui m'ont appris cela.

Citer

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.

Non. On ne compile presque jamais vers un langage qui est utilisé par des humains.

C'est ce que fait GCC avec ses extensions Ada.

Citer

Il faut une très très grande prudence pour écrire du code portable en C, il y a énormèment de pièges, énormèment de différences entre les compilateurs et les environnements.

En pratique, les problèmes viennent des compilateurs, pas du langage.

Citer

Je n'ai jamais vu ce terme!

Demande à GCC.

corrector · « **Réponse #90 le:** 07 mars 2015 à 11:37:38 »

Citation de: BadMax le 07 mars 2015 à 11:12:07

En pratique, les problèmes viennent des compilateurs, pas du langage.

Trop. Drôle.

Il croit que les compilateur n'ont aucun rapport avec le langage.

Je crois qu'on a touché quelque chose.

jack · « **Réponse #91 le:** 07 mars 2015 à 11:40:15 »

Citation de: kergsen

De toute façon le sujet est, encore une fois, déjà torpillé.

Désolé

Code: [Sélectionner]

#include <stdio.h>

int main(){
        char toto[]= "azertyuiop";
        printf("toto[5]: %c\n", toto[5]);

        char *tata = toto + 4;
        printf("tata[1] : %c\n", tata[1]);

        printf("toto = %i, tata = %i\n", toto, tata);

        printf("toto[5] = %i, tata[1] = %i\n", &toto[5], &tata[1]);
        return 0;
}

4% [jack:/tmp]gcc -o main test.c
5% [alex:/tmp]./main 
toto[5]: y
tata[1] : y
toto = -1391393456, tata = -1391393452
toto[5] = -1391393451, tata[1] = -1391393451

Est-ce que toto = tata ? Non.
Est-ce que toto[p] = tata[q] ? Oui.

On appelle cela des tableaux.
C'est un simple exemple. Un langage qui n'autorise pas cela, qui interdit donc, plus globalement, deux pointeurs de pointer sur la même chose, est un langage défaillant (java ?).

Citation de: corrector

Tu peux aussi dire : char* est un entier.

Sisi, char* est un entier (plus ou moins gros en fonction de ton espace mémoire). Le reste n'est que sémantique propre au langage (taille de la zone pointée, ce que je devrais pouvoir faire avec etc).

Citation de: corrector

lle fait un appel système. Elle contribue donc à la progression du thread en cours d'exécution.

Pour x86:

Citation de: https://en.wikipedia.org/wiki/INT_%28x86_instruction%29

INT is an assembly language instruction for x86 processors that generates a software interrupt.

IO : Input/Output : entrée/sortie : lecture/écriture sur un périphérique; Fait par le noyau (sauf si ce dernier exporte ledit périphérique en userspace, ce qui est rare, si je ne m'abuse, mais faisable, si je ne m'abuse guère plus).

Citer

Qu'est-ce que "goto (au sens sémantique)"?

Go to bed corrector!

Citation de: corrector

EXPLICATION

Sauf cas particulier, après un appel à write vous n'avez pas la garantie que des données ont été physiquement écrites, juste qu'une zone mémoire a été copiée ailleurs et que l'écriture physique ou ce qui doit être fait va se produire sous peu.

Donc on pourrait tout à fait avoir une fonction write qui ne fait aucun appel système dans certains cas.

Vraiment ?
Comment ton kernel va savoir qu'il doit copier cette zone mémoire pour l'envoyer sur le dev ?

Citation de: corrector

Il faut une très très grande prudence pour écrire du code portable en C, il y a énormèment de pièges, énormèment de différences entre les compilateurs et les environnements.

La première règle: programmer en C

C'est déjà pas mal, t'as fait le gros du boulot avec ça.

Citation de: corrector

Si tu savais à qui tu t'adresses... lol

Vas-y, raconte moi ?

BadMax · « **Réponse #92 le:** 07 mars 2015 à 11:46:08 »

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).

corrector · « **Réponse #93 le:** 07 mars 2015 à 11:49:54 »

-ffast-math
Sets the options -fno-math-errno, -funsafe-math-optimizations, -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and -fcx-limited-range.
This option causes the preprocessor macro __FAST_MATH__ to be defined.

This option is not turned on by any -O option besides -Ofast since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications.

-fno-math-errno
Do not set errno after calling math functions that are executed with a single instruction, e.g., sqrt. A program that relies on IEEE exceptions for math error handling may want to use this flag for speed while maintaining IEEE arithmetic compatibility.
This option is not turned on by any -O option since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications.

The default is -fmath-errno.

On Darwin systems, the math library never sets errno. There is therefore no reason for the compiler to consider the possibility that it might, and -fno-math-errno is the default.

-funsafe-math-optimizations
Allow optimizations for floating-point arithmetic that (a) assume that arguments and results are valid and (b) may violate IEEE or ANSI standards. When used at link-time, it may include libraries or startup files that change the default FPU control word or other similar optimizations.
This option is not turned on by any -O option since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications. Enables -fno-signed-zeros, -fno-trapping-math, -fassociative-math and -freciprocal-math.

The default is -fno-unsafe-math-optimizations.

-fassociative-math
Allow re-association of operands in series of floating-point operations. This violates the ISO C and C++ language standard by possibly changing computation result. NOTE: re-ordering may change the sign of zero as well as ignore NaNs and inhibit or create underflow or overflow (and thus cannot be used on code that relies on rounding behavior like (x + 2**52) - 2**52. May also reorder floating-point comparisons and thus may not be used when ordered comparisons are required. This option requires that both -fno-signed-zeros and -fno-trapping-math be in effect. Moreover, it doesn't make much sense with -frounding-math. For Fortran the option is automatically enabled when both -fno-signed-zeros and -fno-trapping-math are in effect.
The default is -fno-associative-math.

-freciprocal-math
Allow the reciprocal of a value to be used instead of dividing by the value if this enables optimizations. For example x / y can be replaced with x * (1/y), which is useful if (1/y) is subject to common subexpression elimination. Note that this loses precision and increases the number of flops operating on the value.
The default is -fno-reciprocal-math.

-ffinite-math-only
Allow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs.
This option is not turned on by any -O option since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications.

The default is -fno-finite-math-only.

-fno-signed-zeros
Allow optimizations for floating-point arithmetic that ignore the signedness of zero. IEEE arithmetic specifies the behavior of distinct +0.0 and −0.0 values, which then prohibits simplification of expressions such as x+0.0 or 0.0*x (even with -ffinite-math-only). This option implies that the sign of a zero result isn't significant.
The default is -fsigned-zeros.

-fno-trapping-math
Compile code assuming that floating-point operations cannot generate user-visible traps. These traps include division by zero, overflow, underflow, inexact result and invalid operation. This option requires that -fno-signaling-nans be in effect. Setting this option may allow faster code if one relies on “non-stop” IEEE arithmetic, for example.
This option should never be turned on by any -O option since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions.

The default is -ftrapping-math.

Source : https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Bon, vous arrivez à voir que les optimisations sont plus ou moins possibles selon la sémantique plus ou moins précise du dialecte compilé?

corrector · « **Réponse #94 le:** 07 mars 2015 à 11:58:15 »

Citation de: jack le 07 mars 2015 à 11:40:15

On appelle cela des tableaux.

Super.

Citation de: jack le 07 mars 2015 à 11:40:15

C'est un simple exemple. Un langage qui n'autorise pas cela, qui interdit donc, plus globalement, deux pointeurs de pointer sur la même chose, est un langage défaillant (java ?).

N'importe quoi.

Citation de: jack le 07 mars 2015 à 11:40:15

Sisi, char* est un entier

Hein? Tu parles de quoi? Du langage C? D'un compilateur particulier?

C'est quoi être un entier? Est-ce qu'un flottant est un entier?

Tu as la moindre notion de ce dont il est question?

En C un pointeur n'est pas un entier. Point final.

Citation de: jack le 07 mars 2015 à 11:40:15

(plus ou moins gros en fonction de ton espace mémoire). Le reste n'est que sémantique propre au langage (taille de la zone pointée, ce que je devrais pouvoir faire avec etc).

Hein? Tout est de la sémantique.

Citation de: jack le 07 mars 2015 à 11:40:15

Pour x86:
IO : Input/Output : entrée/sortie : lecture/écriture sur un périphérique; Fait par le noyau (sauf si ce dernier exporte ledit périphérique en userspace, ce qui est rare, si je ne m'abuse, mais faisable, si je ne m'abuse guère plus).

Tu veux dire sur une mémoire de masse?

corrector · « **Réponse #95 le:** 07 mars 2015 à 12:06:50 »

Citation de: jack le 07 mars 2015 à 11:40:15

Vas-y, raconte moi ?

Disons que s'il y a un sujet où il n'est pas avisé d'essayer de me piéger, c'est la définition de certains langages dont le C.

Il y a très peu de chance que quelqu'un pris en hasard maîtrise mieux le sujet que moi.

(Après, je ne peux pas empêcher les forumeurs de passer pour des andouilles.)

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

corrector

Programmation : Le GOTO c'est le maaaaaaal

kgersen

Programmation : Le GOTO c'est le maaaaaaal

corrector

Programmation : Le GOTO c'est le maaaaaaal

corrector

Programmation : Le GOTO c'est le maaaaaaal

corrector

Programmation : Le GOTO c'est le maaaaaaal

BadMax

Programmation : Le GOTO c'est le maaaaaaal

corrector

Programmation : Le GOTO c'est le maaaaaaal

jack

Lalala, je suis un petit poney lalala

BadMax

Programmation : Le GOTO c'est le maaaaaaal

corrector

Programmation : Le GOTO c'est le maaaaaaal

corrector

Lalala, je suis un petit poney lalala

corrector

Lalala, je suis un petit poney lalala