sorte de self modifying code en C - Page 1

-

typeof(func1) func=condition?func1:func2;

si tu veux faire du C portable, il faudra remplacer "typeof(machin) func" par un truc de la forme "ret_type (*func)(arg1_type,arg2_type)"

-

Je parle du chargement de l'adresse, après pour l'appeler tu n'as qu'à faire func(arg1,arg2), et ça appelera soit func1 soit func2

Orion_ :
donc je me demandais si il était possible d'utiliser une variable avec l'adresse de la fonction à exécuter dedans.
[...]
le problème c'est comment le faire en C ?

Un pointeur ?

-

-

C'est normal, ce n'est pas n'importe quel pointeur : dans le type de pointeur tu dois avoir une description des arguments et de la valeur de retour...

Il faut mettre "typeof(monautrefunc) innerfunc" ou bien "void(*innerfunc)(void)"

arf, j'avais commencé un truc, et puis poum, plantage de la carte graphique. Le pc répond encore, mais c'est illisible. Bon, ben euh, c'est quoi la séquence de touches pour lancer un reboot déjà ?.... Bon, me revoilà alors je recommence, mais ce sera moins commenté.

typedef void (*pFn_t)(int);

void F1(int x) {
	printf("F1(%d)\n", x);
}

void F2(int x) {
	printf("F2(%d)\n", x);
}

void theloop() {
	int i;
	pFn_t pfn;

	pfn = dois_je_utiliser_F1 ? F1 : F2;
	for (i = 0; i < N; ++i)
		pfn(i);
}

Voilà. Bon, j'ai la flemme d'expliquer, alors je vais faire le contraire, tu dis ce que tu comprends pas.

[kk mode]une fois remis dans son contexte (notamment règler N et dois_je_utiliser_F1), ça compile avec -Wall -pedantic -ansi, donc ça doit etre bon[/kk mode]

spectras :
[kk mode]une fois remis dans son contexte (notamment règler N et dois_je_utiliser_F1), ça compile avec -Wall -pedantic -ansi, donc ça doit etre bon[/kk mode]

Non t'as oublié -W.

hum, il me semblait que -Wall était un surensemble de -W ?

Eh non.

ah, eh bien c'est noté alors.
Cela dit, ça marche aussi avec -W
Et meme, dédicacé tout spécialement à KK, -Werror

J'suis pas sûr que ce soit son truc...
Déjà que, la dernière fois que j'ai essayé (ça remonte), tigcclib.h ne passait pas en -std=c99.

spectras> ah non, pas -ansi Les extensions GNU sont là pour être utilisées

Pollux :
Les extensions GNU sont là pour être utilisées

Ah bon, je pensais qu'elles étaient là pour rendre ton programme incompatible avec les compilateurs qui respectent le standard. On m'aurait menti.

<emulation=on>

nitro
:

Pollux :
Les extensions GNU sont là pour être utilisées

Ah bon, je pensais qu'elles étaient là pour rendre ton programme incompatible avec les compilateurs qui respectent le standard. On m'aurait menti.

* on se fiche de la compatibilité avec ces compilateurs obsolètes
* le comité de standardisation ANSI est largement moins compétent que le lecteur de Slashdot moyen
* de même pour les mainteneurs de GCC
* de même pour les fabricants d'autres compilateurs obsolètes (à part Intel)
</>

J'adore.

j'avoue Pollux, que tu le fais vachement bien

nitro
: J'suis pas sûr que ce soit son truc...

En effet, j'ai horreur de -Werror. Un warning est un warning, une erreur est une erreur. Un warning, ça se lit, et on ne se plaint pas si le code ne marche pas quand il y a des warnings (sinon: RTFW!). Mais ce n'est pas obligatoirement à corriger: si le code marche, c'est bon. Une erreur est obligatoire à corriger.

Déjà que, la dernière fois que j'ai essayé (ça remonte), tigcclib.h ne passait pas en -std=c99.

Normal, il faut utiliser -std=gnu99 pour avoir du C99.
Le -std=c99, c'est l'équivalent de -ansi pour le C99. -ansi et -pedantic ne sont volontairement pas supportés par TIGCC et ne le seront vraisemblablement jamais.

Un warning sert précisement à détecter les erreurs probables, meme si elles sont interprétées correctement par le compilateur. -Werror t'aide à maintenir une ligne de conduite (particulièrement utile quand tu as des développeurs moins pointilleux qui ont pour habitude de laisser trainer des warnings partout - là ils sont obligés de corriger). Après, évidemment, y'a différentes valeurs pour la qualité d'un source...
D'autant plus que tout code générant un warning peut etre modifié pour faire exactement la meme chose de manière propre en un nombre de lignes équivalent.

-ansi et -pedantic ne sont volontairement pas supportés par TIGCC et ne le seront vraisemblablement jamais

C'est pas parce que tu ne veux pas de ces fonctions que tu dois te sentir obligé d'en priver ceux qui en trouvent l'intéret.

spectras :
Un warning sert précisement à détecter les erreurs probables, meme si elles sont interprétées correctement par le compilateur. -Werror t'aide à maintenir une ligne de conduite (particulièrement utile quand tu as des développeurs moins pointilleux qui ont pour habitude de laisser trainer des warnings partout - là ils sont obligés de corriger). Après, évidemment, y'a différentes valeurs pour la qualité d'un source...

Mais quelqu'un qui oblige à corriger tous les warnings n'a pas compris la différence entre un warning et une erreur, justement!

D'autant plus que tout code générant un warning peut etre modifié pour faire exactement la meme chose de manière propre en un nombre de lignes équivalent.

Pas nécessairement!

-ansi et -pedantic ne sont volontairement pas supportés par TIGCC et ne le seront vraisemblablement jamais

C'est pas parce que tu ne veux pas de ces fonctions que tu dois te sentir obligé d'en priver ceux qui en trouvent l'intéret.

Parce qu'on a besoin des extensions GNU pour nos headers.

Et je ne vois pas du tout l'intérêt de gérer des flags qui comprennent un sous-ensemble des programmes (bon, pour -ansi, ce n'est pas exactement un sous-ensemble, mais presque). Les mêmes programmes passent sans problèmes sans ses flags, donc pourquoi perdre notre temps à gérer ces flags? TIGCC n'est pas là pour vous apprendre le C standard.

Kevin Kofler
:

spectras :
Un warning sert précisement à détecter les erreurs probables, meme si elles sont interprétées correctement par le compilateur. -Werror t'aide à maintenir une ligne de conduite (particulièrement utile quand tu as des développeurs moins pointilleux qui ont pour habitude de laisser trainer des warnings partout - là ils sont obligés de corriger). Après, évidemment, y'a différentes valeurs pour la qualité d'un source...

Mais quelqu'un qui oblige à corriger tous les warnings n'a pas compris la différence entre un warning et une erreur, justement!

On peut très bien interdire les warning pour la compilation finale d'un truc tout en les autorisant pdt le beta-test (ça peut être pratique pour faire des trucs temporaires, mais pour un truc durable il vaut mieux s'arranger pour supprimer le warning)

D'autant plus que tout code générant un warning peut etre modifié pour faire exactement la meme chose de manière propre en un nombre de lignes équivalent.

Pas nécessairement!

La plupart du temps, mais c pour ça qu'il faut pouvoir désactiver certains warnings (VS est bien foutu de ce point de vue-là, puisque chaque warning a un numéro et que tu peux désactiver les numéros que tu veux, en plein milieu du code si besoin est ; GCC est plus bordélique, en demandant de spécifier le nom (tous n'ont pas un nom, et dans ce cas-là c'est DTC) et en le faisant de manière globale à chaque fichier)

D'autant plus que tout code générant un warning peut etre modifié pour faire exactement la meme chose de manière propre en un nombre de lignes équivalent.

1. Produisant du code aussi efficace ?
2. Sans rajouter de nouvelle variable ?

Personnelement, je suis un adepte du 0 warnings (Pour ca je compile souvent par G++ avec -Wall -W -pedantic -ansi plus d'autres trucs).
Mais corriger une comparaison entre un unsigned et un signed en castant l'un dans le type de l'autre, n'est juste qu'une maniere de se debarasser du warning, et pas de l'erreur potentielle (La maniere propre de comparer un signed s et un unsigned u est : (s < 0 || (unsigned) s < u).
Il faut corriger l'erreur potentielle sous-entendu, pas simplement enlever le warning.

M'enfin je reconnais qu'il y a des warnings particulierement delicats a enlever (Particulierement lorsqu'il croit que des variables sont non-intialisees, alors qu'elles le sont).

Pour le variables non-initialisées sous GCC, int x=x; fait l'affaire.

C'est exactement ce que j'appelle enlever des warnings juste pour enlever des warnings.
Un warning a sa raison d'etre et ne doit pas etre supprimer a la legere.

Je vois pas pkoi ça ne serait pas une correction valable (au moins dans les cas où le code est valide, hein)

PpHd> pour ton exemple sur les nombres signés / non signés, faire un cast revient à dire "je sais exactement les implications que ce que je fais va avoir, et je veux que ça se passe comme ça".
Quand je recontre ça, je fais au cas par cas. Mais en général, la résolution se fait en amont. Par exemple, le plus fréquent (chez moi en tous cas) c'est de faire
for (int i = 0; i < n; ++i)
alors que n est non signé. L'erreur vient de la déclaration du i, pas du test.

Pour int x = x, perso j'ai jamais rencontré le pb. Quand j'ai un warning sur une var non initialisée, il est toujours justifié il me semble. Cela dit, la bidouille me parait pas très propre.
Ah et j'oubliais :

1. Produisant du code aussi efficace ? 2. Sans rajouter de nouvelle variable ?

1) oui, parce que le compilateur est parfaitement capable d'éliminer les éléments ne servant qu'à la syntaxe et inutile dans la génération du code.
2) sans vérifier, je dirais que oui. Mais si tu as un contre-exemple je suis preneur.

PS: héhé, je compile avec les memes

Dans Backgammon, il y a 2 variables qui sont toujours initialisées (mais de manière bizarre) et GCC ne le reconnaît pas.

Voilà:

          short keypress=keypress;
          for (short i=0;i<6;i++) {
            Gray3PDBufSetActiveAMSPlane(i%3);
            DrawStr(Q(0,6),Q(46,59),"Really quit?",A_XOR);
            if (i==2) keypress=GetKeyInput();
          }
          FontSetSys(OldFont);
          if (keypress==KEY_ENTER) {victory=0;break;} else goto retry1;

      short keypress=keypress;
      for (short i=0;i<6;i++) {
        Gray3PDBufSetActiveAMSPlane(i%3);
        DrawStr(Q(0,6),Q(46,59),"Really quit?",A_XOR);
        if (i==2) keypress=GetKeyInput();
      }
      FontSetSys(OldFont);
      if (keypress==KEY_ENTER) {victory=0;break;} else goto retry;