Passage de parametres explicite

Version imprimable

Bonjour,

je suis quelqu'un de très étourdi, et je me plante souvent lors de l'appel de mes méthodes en inversant un paramètre avec une autre. J'ai vu/lu je ne sais plus qu'il est possible (peut être pas en C) d'expliciter le nom du paramètre lors de l'appel d'une méthodes. Est-ce possible en C ou C99?

grosso-modo est-il possible d'arriver a faire compiler ce code ?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 #include <stdio.h> static void testpassageparam(int a, int b); int main() { testpassageparam( .a(2), .b(-6)); return 0; } static void testpassageparam(int a, int b) { printf("test a : %d b : %d\n",a,b); }
L'explicitation des paramètres avec .nom_du_param(valeur_du_param) est tirée de Verilog (qui syntaxiquement proche du C)

Est-ce possible de faire çà, ou dois-je très vite oublier cette idée?

Mith

Bonjour,

Tel que tu l'écris, cela ne fonctionnera pas.

En revanche, tu pourrais utiliser des struct pour arriver à tes fins :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
typedef struct {
    int a;
    int b;
} param_fonction;
 
void ma_fonction(param_fonction par) {
    printf("a = %d\n, b = %d\n", par.a, par.b);
}
 
int main(void) {
    param_fonction mes_parametres;
    mes_parametres.a = 5;        
    mes_parametres.b = -156;
 
    ma_fonction(mes_parametres);
 
    return 0;
}

19/07/2010, 18h04
mith06

Effectivement l'utilisation d'une structure est un bon moyen de contourner le problème. :ccool:

Mais à force de taper des ligne codes comme un bourrin, il viendra forcement le moment ou une méthodes prendra plusieurs structures en paramètres, et la on retombe sur le même soucis (vrai uniquement pour les mal-adroits comme moi) :aie:

Je crois que mon problème est tout simplement que je n'aime pas la syntaxe du C :?, mais j'aime bien pouvoir programmer en très bas niveau :D
19/07/2010, 18h12
ok.Idriss

Salut.

Citation:

Envoyé par mith06

Je crois que mon problème est tout simplement que je n'aime pas la syntaxe du C

Pourtant c'est une syntaxe dont s'inspirent pas mal de langages (indirectement ou pas) ...

Tu aurais le même problème en Java, en PHP (même s'ils ne sont pas typés ça peut poser problème), etc. AMHA, il faut tout simplement t'habituer à respecter l'ordre des paramètres.

Cordialement,
Idriss

Citation:

Envoyé par mith06

Effectivement l'utilisation d'une structure est un bon moyen de contourner le problème. :ccool:

Mais à force de taper des ligne codes comme un bourrin, il viendra forcement le moment ou une méthodes prendra plusieurs structures en paramètres, et la on retombe sur le même soucis (vrai uniquement pour les mal-adroits comme moi) :aie:

Je crois que mon problème est tout simplement que je n'aime pas la syntaxe du C :?, mais j'aime bien pouvoir programmer en très bas niveau :D

Rien ne t'empêche d'imbriquer tes structures aussi
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 typedef struct { int a; int b; } param_fonction1; typedef struct { int c; int d; } param_fonction2; typedef struct { param_fonction1 fcn1; param_fonction2 fcn2; } param_fonction; void ma_fonction1(param_fonction1 par) { printf("a = %d\n, b = %d\n", par.a, par.b); } void ma_fonction2(param_fonction2 par) { printf("c = %d\n, d = %d\n", par.c, par.d); } void ma_fonction(param_fonction par) { ma_fonction1(par.fcn1); ma_fonction2(par.fcn2); } int main(void) { param_fonction mes_parametres; mes_parametres.fcn1.a = 5; mes_parametres.fcn1.b = -156; mes_parametres.fcn2.c = 7; mes_parametres.fcn2.d = -314; ma_fonction(mes_parametres); return 0; }
Ensuite il te faut un découpage cohérent de tes structure/fonction pour les faire correspondre a quelque chose de logique dans ton modèle de données, sinon tu perd en lisibilité.

19/07/2010, 20h07
mith06

Citation:

Ensuite il te faut un découpage cohérent de tes structure/fonction pour les faire correspondre a quelque chose de logique dans ton modèle de données, sinon tu perd en lisibilité.

C'est a mon sens ce qu'il y a de plus important dans l'écriture d'un programme surtout si celui-ci devra être maintenu par une tierce personne.

Citation:

il faut tout simplement t'habituer à respecter l'ordre des paramètres.

Après plusieurs heures passées devant l'écran j'ai du mal à mi retrouver...Et justement respecter cet ordre demande un effort de concentration supplémentaire qui je pense pourrai être compensé par une syntaxe explicite. Mais je ne connais pas de langage parfait...

Cordialement Mith
19/07/2010, 20h33
ram-0000

Utilise Ada :P. Ce que tu demandes est possible avec ce langage, tu peux passer les paramètres dans l'ordre que tu veux en les nommant. Mais bon, c'est un peu cher payé (à mon avis).
19/07/2010, 21h31
mith06

Ha si seulement j'avais le droit de faire l'ADA...
je viens du monde VHDL, dont la syntaxe est tirée de l'ADA (ou inversement je ne sais plus), et c'est un langage que j'apprécie beaucoup.
Pour moi un programme en C ca se décode, alors qu'un programme en ADA ca se lit ;) Mais bon de toute façon je n'ai jamais vraiment eu l'occasion de faire de l'ADA.

C'est dommage le C est un bon langage mais je lui reproche certaines choses (Cela pourrais faire l'objet d'un nouveau topic) :

Utiliser l'opérateur d'égalité '=' pour une affectation :marteau: (si il y avait une chose à changer cela serait ca)

Ne pas pouvoir utiliser l'affectation explicite des paramètres :twisted:

Utiliser le même opérateur pour les dé-référencement et la multiplication cad '*', ce n'est pas judicieux a mon sens...

La persistance du langage pré-processeur, qui est source d'erreurs, et rend les programmes illisibles.

Le fait de pouvoir évaluer les affectations : if(a = b) est correcte en C :marteau: Cela serait normale si '=' était un opérateur d'égalité en C mais ce n'est pas le cas...(on peut lever un Warning à la compilation sur ce genre de chose avec -Wextra)

Cependant le C99 amène des améliorations syntaxiques appréciables:

La standardisation des booléens dans stdbool.h :ccool:
Le mot clef inline qui permet de limiter l'utilisation des macros pré-processeurs :ccool:
Une définition claires des types primitifs entiers avec intypes.h :ccool:

Tout ceux-ci n'est qu'une histoire de gout, et n'a dans un sens que peux d'importance. Mais qu'il serait bon d'avoir un lange de prog sur mesure :lol:

Cordialement
19/07/2010, 23h30
diogene

Citation:

Le fait de pouvoir évaluer les affectations : if(a = b) est correcte en C Cela serait normale si '=' était un opérateur d'égalité en C mais ce n'est pas le cas...(on peut lever un Warning à la compilation sur ce genre de chose avec -Wextra)

C'est une question de "philosophie" du langage : en C, il faut penser en terme d'évaluation des expressions, plutôt qu'en terme d'instruction. Si on excepte les instructions de contrôle du flux d'exécution du programme (for, if,...), tout est évaluation d'expressions, l'évaluation pouvant éventuellement provoquer un effet de bord (comme dans l'évaluation de l'expression a = b).

Si on considère que a=b est simplement une affectation, alors évidemment écrire if(a=b) semble un non-sens. Mais c'est parce qu'on se limite en considérant uniquement l'effet de bord de l'évaluation de l'expression a=b, évaluation qui produit une valeur.
Il n'y a qu'un cas (je crois) où l'évaluation d'une expression ne donne pas de valeur, c'est l'expression constituée par un appel à une fonction retournant void (et dans ce cas, la fonction doit produire un effet de bord, sinon l'appel ne fait rien et est inutile).
20/07/2010, 21h48
orfix

Cela n'a absolument rien à voir avec le langage C, tu peux toujours choisir un IDE pour t'assister (complétion automatique, suggestions, génération de code ...).