nom de variables

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : nom de variables

yobbas

The Unit

Bonjour, je voudrais un petit renseignement, je me doute que c'est juste une question de syntaxe, mais je sèche... :pt1cable:
Je voudais créer plusieurs variables (bcp en fait) et déclarer par exemple, var1 = 1, var2 = 2, var3 = 3, etc.
mais comme il y en a bcp, je n'ai pas très envie de taper cinquante fois la déclaration.
J'aimerais donc avoir un code du genre:
for(int i = 0; i < nombre; i++)
int var'valeur_i' = i;
sans utiliser de vecteurs.
Merci d'avance pour votre aide.

Publicité

Elmoricq

Modérateur

Tableaux.

Exemple, avec un tableau à taille fixe :

int values[50];
unsigned i;

for (i = 0; i < 50; i++)
{
values[i] = i;
}

Exemple bis, avec un tableau de taille inconnue à la compilation :

int *values;
size_t size;

size = <calcul que tu veux>;

values = malloc(size * sizeof *values);
if ( values != NULL )
{
unsigned i;
for(i = 0; i < size; i++)
{
values[i] = i;
}
}
else
{
fprintf(stderr, "erreur d'allocation machin, gestion bidule\n" );
return code_erreur;
}

/* quand on est sur de ne plus utiliser notre tableau, on libere la memoire */
free(values), values = NULL;

Message cité 1 fois
Message édité par Elmoricq le 02-05-2006 à 17:51:56

franceso

Citation :

J'aimerais donc avoir un code du genre:
for(int i = 0; i < nombre; i++)
int var'valeur_i' = i;
sans utiliser de vecteurs.

C ne permet pas ce genre de choses. Mais ce serait de toutes façons une très mauvaise habitude à prendre. Il faut utiliser des tableaux comme te l'a montré Elmoricq.

---------------
TriScale innov

yobbas

The Unit

Merci pour vos réponses. A bientôt! ;-)

Sve@r

Elmoricq a écrit :

Je conseillerais tester l'erreur plutôt que la réussite

int *values;
size_t size;
unsigned i;

size = <calcul que tu veux>;

values = malloc(size * sizeof *values);
if ( values == NULL )
{
fprintf(stderr, "erreur d'allocation machin, gestion bidule\n" );
return code_erreur;
}

// Ici, on est certain que le malloc a réussi
for(i = 0; i < size; i++)
{
values[i] = i;
}

/* quand on est sur de ne plus utiliser notre tableau, on libere la memoire */
free(values), values = NULL;

1) ça permet de gérer immédiatement le pb (si t'as une gros code à mettre après le malloc, ça permet de ne pas gérer l'erreur 800 lignes plus loin
2) ça permet de garder l'indentation minimale (ça t'évite de programmer totalement à droite de ton écran quand t'as 50 malloc à faire et à vérifier)

Message cité 1 fois
Message édité par Sve@r le 03-05-2006 à 20:24:15

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

Emmanuel Delahaye

C is a sharp tool

Sve@r a écrit :

Je comprend ces arguments. Le problème, c'est que cette méthode crée des raccourcis dramatiques (goto cachés) qui font que certaines ressources pourraient très bien ne pas être libérées proprement (sockets, threads etc.)

Donc, je ne fais pas ça et je préfère traiter

Code :

if (ok)
{
}
else
{
problem();
}

même si il faut supporter quelques imbrications...

Code :

if (ok)
{
if (ok)
{
}
else
{
problem();
}
}
else
{
problem();
}

Evidemment il ne faut pas exagérer, et il faut probablement une fonction de plus si besoin est...

Problème de multiplication des appels de fonctions ? Oui, ça peut arriver (surtout en embarqué, pas assez de mémoire auto...).

Dans ce cas, il faut chercher un compromis acceptable qui fasse que quii qu'il arrive, les ressources soient correctement libérées.

Message cité 1 fois

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/

Sve@r

Emmanuel Delahaye a écrit :

Je comprends pas trop. Sortir d'une fonction avec "return" avant d'avoir atteint la dernière accolade peut faire que ces ressources automatiquement allouées par la fonction ne seront pas libérées ?

Message cité 1 fois

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

Emmanuel Delahaye

C is a sharp tool

Sve@r a écrit :

Oui, tout à fait. Disons, que par rapport à l'écriture naturelle, que génère l'imbrication des phases de 'construction', les raccourcis barbares risquent de brûler des étapes de 'déconstruction' naturelles... Exemple typique (pseudo-code):
Voilà ce que j'appelle un algorithme 'naturel' :

Code :

{
FILE *fp_in = fopen(...);
if (fp_in != NULL)
{
FILE *fp_out = fopen(...);
if (fp_out != NULL)
{
/* traitement */
fclose(fp_out);
}
else
{
perror();
}
fclose(fp_in);
}
else
{
perror();
}
}

La plupart des soi-disantes simplifications de ce genre de code que j'ai vues se traduisent par un fichier non fermé, un appel à fclose() avec un NULL etc.

Message cité 1 fois
Message édité par Emmanuel Delahaye le 03-05-2006 à 23:13:17

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/

skelter

comme ca par exemple

Code :

int f()
{
int * n;
FILE * f;
n = malloc(truc());
if( ! n )
return 1;
f = fopen("truc", "r" );
if( ! f )
/* erreur courante, la zone mémoire pointee par n n'est pas liberée */
return 2;
fclose(f);
free(n);
return 0;
}

pour parrer ca on peut aussi faire avec des goto, apres c'est juste une histoire de forme ?

Code :

int f()
{
int * n = NULL;
FILE * f = NULL;
int errno = 0;
n = malloc(truc());
if( ! n )
{
errno = 1;
goto end;
}
f = fopen("truc", "r" );
if( ! f )
{
errno = 2;
goto end;
}
end:
if( f )
fclose(f);
free(n);
return errno;
}

Message édité par skelter le 03-05-2006 à 23:15:54

Sve@r

Emmanuel Delahaye a écrit :

Code :

{
FILE *fp_in = fopen(...);
if (fp_in != NULL)
{
FILE *fp_out = fopen(...);
if (fp_out != NULL)
{
/* traitement */
fclose(fp_out);
}
else
{
perror();
}
fclose(fp_in);
}
else
{
perror();
}
}

La plupart des soi-disantes simplifications de ce genre de code que j'ai vues se traduisent par un fichier non fermé, un appel à fclose() avec un NULL etc.

Délit d'intention. Ma façon d'écrire ce code est toujours ceci :

Code :

{
FILE *fp_in;
FILE *fp_out;
char *buffer;
fp_in = fopen(...);
if (fp_in == NULL)
{
perror(...);
return -1;
}
fp_out = fopen(...);
if (fp_out == NULL)
{
fclose(fp_in);
perror(...);
return -1;
}
buffer=malloc(...);
if (buffer == NULL)
{
fclose(fp_in);
fclose(fp_out);
perror(...);
return -1;
}
/* traitement */
fclose(fp_in);
fclose(fp_out);
free(buffer);
}

Tu me rassures. Je croyais que c'était le "return" avant terme qui générait un pb alors que le pb dont tu parles ne vient que de la façon d'écrire du programmeur. Evidemment, ma façon d'écrire mêne à une redondance de code (partout où on libère les ressources). Comme quoi, rien n'est jamais parfait...

Message cité 2 fois
Message édité par Sve@r le 03-05-2006 à 23:39:04

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

Publicité

Emmanuel Delahaye

C is a sharp tool

Sve@r a écrit :

Délit d'intention. Ma façon d'écrire ce code est toujours ceci :

Ce que je fais en 21 lignes, tu le fais en 34 ? (bon OK, je ne retourne pas l'erreur...) Et il a fallu un effort supplémentaire de raisonnement pour placer les libérations de ressources au bon endroit (dont 3 fois fclose(fp_in) !) etc. Je préfère mon algo 'naturel'... Il induit moins d'erreurs. (Je deviens vieux, j'ai plus trop le temps penser aux details, alors ce qui se fait tout seul ça me va.....)

Message cité 2 fois
Message édité par Emmanuel Delahaye le 04-05-2006 à 00:01:18

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/

skelter

Emmanuel Delahaye a écrit :

passes au c++, raii et gestion d'erreurs par exceptions te soulageront

Message cité 1 fois

0x90

→

Sve@r a écrit :

Délit d'intention. Ma façon d'écrire ce code est toujours ceci :

Code :

{
FILE *fp_in;
FILE *fp_out;
char *buffer;
fp_in = fopen(...);
if (fp_in == NULL)
{
perror(...);
return -1;
}
fp_out = fopen(...);
if (fp_out == NULL)
{
fclose(fp_in);
perror(...);
return -1;
}
buffer=malloc(...);
if (buffer == NULL)
{
fclose(fp_in);
fclose(fp_out);
perror(...);
return -1;
}
/* traitement */
fclose(fp_in);
fclose(fp_out);
free(buffer);
}

Je crois que j'ai un set de macro dans un coin qui gère automatiquement le "défaisage du code", le pb c'est qu'elles nécessites de passer 2x le code dans cpp [:pingouino]

( bon ca va hein, j'aime bien jouer à aller trop loin avec le C )

Sve@r

Emmanuel Delahaye a écrit :

Ce que je fais en 21 lignes, tu le fais en 34 ?

Hum... j'ai un malloc en plus...

Emmanuel Delahaye a écrit :

Je préfère mon algo 'naturel'... Il induit moins d'erreurs. (Je deviens vieux, j'ai plus trop le temps penser aux details, alors ce qui se fait tout seul ça me va.....)

L'important c'est de se sentir bien avec sa façon de coder. Et puis, toi tu connais le C donc tu peux prendre les décisions en toute connaissance. Yobbas débute donc il était bon de lui montrer les différentes possibilités (avec des avantages... et des inconvénients pour chacune)

skelter a écrit :

passes au c++, raii et gestion d'erreurs par exceptions te soulageront

:heink: Tu devrais consulter son site avant de lui conseiller d'apprendre le C++

Message édité par Sve@r le 04-05-2006 à 07:35:21

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

FORUM HardWare.fr

Programmation

nom de variables

Sujets relatifs
Variables d'environnement Windows en C	plusieurs variables dans une variable
variables externes : passage en membres ou argument de methodes ?	[C++] programmation multilangues - variables externe
[PERL] Noms de variables variables ?	Variables HTML avec applet JAVA
XSLT / Xpath : Comparer deux variables!	variables membres sont des objets -> bonne/mauvaise idée ?
Enumérer les variables Javascript	JSP/JSTL et passage de variables...(débutant)
Plus de sujets relatifs à : nom de variables

Page générée en 0.089 secondes