Discussion :

[Pitou5464]

Salut a tous,

jessaye de trier une liste chainee avec ce code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
int     sort_in_list(t_list *begin)
{
  char          *str;
  t_list        *i;
  t_list        *j;
  t_list        *b;
 
  i = begin;
  while(i->next != 0)
    {
      j = begin;
      while (j->next != 0)
        {
          if (my_strcmp(j->next->data, j->data) < 0)
            {
              str =j->data;
              j->data = j->next->data;
              j->next->data = str;
            }
          j = j->next;
        }
      i = i->next;
    }
  return (0);
}

le probleme c'est quand jappelle la fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
sort_in_list(begin)
j->next->data est vide et j->data contient le dernier element inserer dans la liste

Dou ma question comment remettre begin a son orirgine

[Emmanuel Delahaye]

le probleme c'est quand jappelle la fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
sort_in_list(begin)
j->next->data est vide et j->data contient le dernier element inserer dans la liste

Dou ma question comment remettre begin a son orirgine

Impossible. Il ne fallait pas modifier begin (modifier la valeur d'un paramètre est souvent le signe d'une erreur de codage).

Il faut laisser begin tranquille et utiliser un pointeur local (initialisé avec begin).

En relisant ton code, je vois que tu n'as en fait pas modifié begoin. Alors je ne comprend pas ta question. Tu as su faire une fois

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

  i = begin;

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

  j = begin;

Tu ne peux pas le refaire ?

[Pitou5464]

jai essaye comme ca mais jai toujours un seg fault

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
int     sort_in_list(t_list *begin)
{
  char          *str;
  t_list        *i;
  t_list        *j;
  t_list        *b;
 
  i = begin;
  while(i->next != 0)
    {
      j = begin;
      while (j->next != 0)
        {
          b = begin;
          if (my_strcmp(b->next->data, b->data) < 0)
            {
              str =b->data;
              b->data = b->next->data;
              b->next->data = str;
            }
          j = j->next;
        }
      i = i->next;
    }
  return (0);
}

[Pitou5464]

Jai l'impression que begin pointe sur le dernier element rentre dans la liste donc c'est normal qu'il n'y ai rien dans j->next->data car j = begin->data contient le dernier element dans la liste.
Que je reintialise un autre pointeur local fera la meme chose non?

[InOCamlWeTrust]

(modifier la valeur d'un paramètre est souvent le signe d'une erreur de codage).

Entièrement pas d'accord (mais on reste copains, hein !).

Modifier un paramètre peut être un très bon moyen pour écrire un code concis et souvent très lisible. La quasi entièreté des fonctions de ma librairie AVL, par exemple, sont écrites en modifiant les paramètres, et le résultat est souvent très surprenant en termes d'économie de variables, d'instructions, et d'identificateurs. Mais c'est sûr (et comme beaucoup de choses), si c'est utilisé dans de mauvais contextes, ça peut mener à des erreurs graves.

[Emmanuel Delahaye]

Modifier un paramètre peut être un très bon moyen pour écrire un code concis et souvent très lisible. La quasi entièreté des fonctions de ma librairie AVL, par exemple, sont écrites en modifiant les paramètres, et le résultat est souvent très surprenant en termes d'économie de variables, d'instructions, et d'identificateurs. Mais c'est sûr (et comme beaucoup de choses), si c'est utilisé dans de mauvais contextes, ça peut mener à des erreurs graves.

Si on sait ce qu'on fait, pourquoi pas... Les débutants savent rarement ce qu'ils font...

[InOCamlWeTrust]

Oh... il ne faut pas être aussi catégorique non plus ! Il faut bien un jour se lancer et se mouiller un peu !

C'est une "astuce" que mon prof de TP de C m'avait apprise : ce mec sait réellement très bien coder en C. D'après lui, quand on peut s'en sortir en employant les paramètres comme variables, il faut le faire... et je trouve, avec le recul et un peu de pratique, qu'il n'a pas tort.

[Thierry Chappuis]

(modifier la valeur d'un paramètre est souvent le signe d'une erreur de codage).

Dans ce cas particulier, ce ne serait pas une bonne idée de changer la valeur de begin. Mais, en général, quelles sont les raisons qui te poussent à estimer que modifier la valeur d'un paramètre est une erreur de codage?

Les paramètres sont initialisés dès l'appel de la fonction en copiant leur valeur sur la pile et sont ensuite utilisés comme des variables locales. Le seul danger que je vois concerne les effets de bord lorsqu'on modifie la valeur pointée par un pointeur passé en paramètre. Je n'est pas l'expérience pour comprendre quels dangers cela peut entraîner de modifier un paramètre, pourrais-tu donner un exemple?

Thierry

[Pitou5464]

est ce que je pourrai avoir un exemple pour mieux comprendre

[Emmanuel Delahaye]

Dans ce cas particulier, ce ne serait pas une bonne idée de changer la valeur de begin. Mais, en général, quelles sont les raisons qui te poussent à estimer que modifier la valeur d'un paramètre est une erreur de codage?

Les paramètres sont initialisés dès l'appel de la fonction en copiant leur valeur sur la pile et sont ensuite utilisés comme des variables locales. Le seul danger que je vois concerne les effets de bord lorsqu'on modifie la valeur pointée par un pointeur passé en paramètre. Je n'est pas l'expérience pour comprendre quels dangers cela peut entraîner de modifier un paramètre, pourrais-tu donner un exemple?

Déjà, le bon sens. Si on s'est KC le Q pour passer une valeur à la fonction, c'est pas pour la détruire... On vient d'en avoir un exemple frappant.

Il y a aussi le cas des fonctions genre strcpy(), qui retournent la valeur d'un des paramètres. (Le premier qui me dit qu'il suffit de sauvegarder la valeur se prend un coup de pied au Q virtuel).

Ensuite, un débutant croit souvent qu'en modifiant la valeur du paramètre, il va modifier l'original, ce qui est évidemment faux. Une telle tentative est donc une erreur de conception. Un const sur le paramètre protège de ce genre d'erreur.

Une fois le ménage fait, on constate que les cas où changer la valeur d'un paramètre est utile sont rares et doivent être, AMA, clairement justifiés (genre gagner 2 bytes en mémoire... Supair !).

[InOCamlWeTrust]

Une fois le ménage fait, on constate que les cas où changer la valeur d'un paramètre est utile sont rares et doivent être, AMA, clairement justifiés (genre gagner 2 bytes en mémoire... Supair !).

Je saisis clairement les dangers, et sur le fond il n'y a pas de problèmes... à ceci près que gagner quelques octets pour une fonction faisant de la récursivité non terminale... c'est gagner tout de même, au bout du compte, pas mal d'espace mémoire car économiser les variables automatiques qui se logent dans la pile peut, au bout de quelques centaines de milliers d'appels récursifs, être intéressant. Mais il y a aussi le gain en lisibilité, surtout pour les fonctions qui sont très courtes.

[Emmanuel Delahaye]

gagner quelques octets pour une fonction faisant de la récursivité non terminale...

La récursivité, c'est le Diable.

[diogene]

Le code d'origine a l'air correct sous réserve que my_strcmp fonctionne correctement et que beginsoit bien en début de la liste. Peut-il y avoir problème avec my_strcmp dans le cas où un des pointeurs passés en argument est malencontreusement NULL ?

[fearyourself]

Une fois le ménage fait, on constate que les cas où changer la valeur d'un paramètre est utile sont rares et doivent être, AMA, clairement justifiés

Entièrement d'accord.
Question de lisibilité, ah oui, pour une fonction courte c'est clair que déclarer une variable de plus, cela va nous compliquer la vie...

Par contre, chacun son style, je ne le fais jamais par exemple, cela relève généralement de "hack" rapide qu'on fait et après on oublie et on aura des mauvaises surprises plus tard.

(genre gagner 2 bytes en mémoire... Supair !).

Faux dans l'idée que déclarer une variable et s'en servir va forcément changer la facon dont le compilateur va voir le code. Je ne vois pas pourquoi ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
int myrec(int a)
{
    int b = 4*a+3;
    if(b>0)
        return 0;
    else {
        myrec(b);
    }
}

serait vu différemment que :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
int myrec(int a)
{
    a = 4*a+3;
    if(a>0)
        return 0;
    else {
        myrec(a);
    }
}

voici ce que j'obtiens :

$ ls -al
105 Nov 9 14:17 rec1.c
690 Nov 9 2006 rec1.o
101 Nov 9 14:17 rec2.c
690 Nov 9 14:17 rec2.o

entre les deux, mon choix est fait.

Jc

[Emmanuel Delahaye]

voici ce que j'obtiens

Je parlais du code compilé en éxécution, pas du code source (on s'en tape du code source).

Une variable locale en plus, ça peut utiliser quelques bytes en plus dans la mémoire automatique... (ou 0 si elle est en registre...)

[fearyourself]

Je parlais du code compilé en éxécution, pas du code source (on s'en tape du code source).

Une variable locale en plus, ça peut utiliser quelques bytes en plus dans la mémoire automatique... (ou 0 si elle est en registre...)

Hmm je parlais surtout des .o, les .c cela m'est égal aussi.

Mon point était de dire que le compilateur n'est pas idiot non plus. Les 2 fichiers .o ont la même taille et cela va de soit. Généralement (et surtout en O2 ou O3), en interne, il va réutiliser le registre contenant le paramètre dès que celui-ci n'est plus utile.

Le faire dans le code C ne changera pas grand chose. Donc la question est plus d'ordre esthétique et on ira dans un troll.

Jc

[Médinoc]

Ensuite, c'est non seulement une question esthétique, mais aussi une question sémantique. Il peut être pertinent (ou paraitre pertinent à quelqu'un, l'auteur en premier) qu'un paramètre soit directement réutilisé:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
struct dblchn * GetLast(struct dblchn * pElem)
{
	if(pElem==NULL)
		return NULL;
	while(pElem->pNext != NULL)
	{
		pElem = pElem->pNext;
	}
	return pElem;
}

Dans cette fonction (qui retourne le dernier chaînon d'une liste doublement chaînée), j'aurais pu créer une variable locale pour l'utiliser à la place de pElem dans la boucle, mais quel intéret ?

Edit: Ici, je me demande même si ajouter une variable n'aurait pas nuit à la lisibilité ou à la simplicité du code...

[Emmanuel Delahaye]

Hmm je parlais surtout des .o, les .c cela m'est égal aussi.

Arf, j'avais pas vu les .o. Normal que ça ne change rien. La mémoire automatique n'apparait pas dans le code !

[fearyourself]

Arf, j'avais pas vu les .o. Normal que ça ne change rien. La mémoire automatique n'apparait pas dans le code !

Oui mais la taille du .o est la même et il n'y a aucune différence entre les .o donc le code est le même (j'ai vérifié à coup de diff mais je ne l'ai pas mis donc c'est ma faute, je n'ai pas été assez explicite).

Tu ne vas pas me dire que si le code binaire est le même, la mémoire automatique entre les deux versions peut différer, si ?

Jc

[Emmanuel Delahaye]

Oui mais la taille du .o est la même et il n'y a aucune différence entre les .o donc le code est le même (j'ai vérifié à coup de diff mais je ne l'ai pas mis donc c'est ma faute, je n'ai pas été assez explicite).

Tu ne vas pas me dire que si le code binaire est le même, la mémoire automatique entre les deux versions peut différer, si ?

Je ne pense pas, mais ça dépend de l'implémentation...

http://fr.wiktionary.org/wiki/botter_en_touche

Attention quand même, dans un .o, il n'y a pas que du code...