Bonjour ,svp c'est quoi le problème dans cette fonction?
Je veux insérer un élément au milieu de la liste après une valeur existe déjà .Le problème est lorsque je compile le nombre que j'ai ajouté est répété plusieurs fois on dirait un boucle infini
typedef struct Element Element;
struct Element
{
int nombre;
Element* suivant;
};
typedef struct Liste Liste;
struct Liste
{
Element* premier;
};
Liste* AjoutAuMilieu(Liste* liste, int valeurExist, int nvlValeur)
{
if (liste == NULL)
{
exit(EXIT_FAILURE);
}
else
{
Element* nvelemnt = (Element*)malloc(sizeof(*nvelemnt));
nvelemnt->nombre = nvlValeur;
while (liste != NULL && liste->premier->nombre != valeurExist)
{
liste->premier = liste->premier->suivant;
if (liste->premier->nombre == valeurExist)
{
liste->premier->suivant = nvelemnt;
nvelemnt->suivant = liste->premier->suivant;
}
}
}return liste;
}
Ensuite, dans ton while, tu modifies la liste à chaque itération !
Ce n'est pas ce que tu veux. Toi, tu aimerais lire (et non écrire) les éléments de ta liste jusqu'à trouver l'élément après lequel insérer.
Il faut donc oublier
liste->premier = liste->premier->suivant;
Finalement, demandes toi ce qu'il se passe si le premier élément de ta liste a pour valeur `valeurExist`
Je ne te donne pas de réponse toute faite mais seulement des indications, car la manipulation de listes chaînées est un bon exercice pour appréhender les pointeurs.
lemonnTree te donne une bonne indication. Crée-toi un pointeur qui sera égal au premier au départ et qui sera son suivant quand on avance dans la boucle.
Que se passe-t-il si l'élément cherché n'est pas dans la liste?
Le nouvel élément pointe vers quoi? Et qui pointe vers lui?
@lemonnTree: C'est aussi un bon exercice pour les pointeurs vers pointeur si on veut simplifier.
- Edité par PierrotLeFou 13 juin 2022 à 14:26:21
Le Tout est souvent plus grand que la somme de ses parties.
Bonjour ,svp c'est quoi le problème dans cette fonction?
[...]- Edité par KhaoulaKhichi il y a environ 8 heures
Bonjour,
Normalement, quand on fait appel à un forum, il faut au minimum décrire :
ce que tu attendais comme comportement ;
quel comportement ta fonction exhibe ;
les conditions de tes tests ;
les recherches que tu as entrepris avant de poser ta question ;
là où tu bloques.
On est pas obligé de faire semblant de pas comprendre non plus, si la personne vient sur un forum pour demander de l'aide, elle a déjà un problème à résoudre, on va pas lui en rajouter un quand même ? Ici c'est assez clair, le comportement attendu est d'insérer une valeur dans la liste. Ce qu'il a entrepris, on le voit, et le comportement de la fonction on le voit aussi. On est pas des machines justement, on a la capacité de comprendre ce qu'il faut faire même si on a pas la consigne exacte, et parfois même sans connaitre le résultat attendu, c'est la magie de la conscience humaine
Cette fonction n'a aucun problème, puisqu'elle fait exactement ce que son code lui dit de faire.
Par contre, toi tu as peut être un problème parce qu'elle ne fait pas ce que tu voudrais. Mais comme tu ne nous dis pas quoi, on ne peut pas te dire à quoi est due la différence.
Si on tient à dire quelque chose du code présenté, on a toujours ça : dans
aussi : éviter les identificateurs à syntaxe tordue. Pourquoi enlever un e à element ? Les autres mots sont du français simple, pourquoi pas "nouvel_element" ou tout simplement "nouveau" ?
Ici c'est assez clair, le comportement attendu est d'insérer une valeur dans la liste.
Oui mais où ?
Au milieu comme le nom de la fonction pourrait l'indiquer ? (mais ce n'est pas ce que semble indiquer le code un peu confus). Parce que moi au milieu, je compte les éléments et j'insert à mi chemin ! Mais je ne suis pas sur que ce soit ce que veux KhaoulaKhichi ?
Ici c'est assez clair, le comportement attendu est d'insérer une valeur dans la liste.
Oui mais où ?
Au milieu comme le nom de la fonction pourrait l'indiquer ? (mais ce n'est pas ce que semble indiquer le code un peu confus). Parce que moi au milieu, je compte les éléments et j'insert à mi chemin ! Mais je ne suis pas sur que ce soit ce que veux KhaoulaKhichi ?
Oui la fonction est mal nommée, elle devrait s'appeler juste "insert" ou quelque chose comme ça, mais ça ne nous empêche pas de comprendre exactement ce qu'il veut, c'est à dire ajouter un nouvel élément après la valeur existante (valeurExist). Ce qui est bien avec l'intelligence, contrairement aux "machines" c'est que même en cas d'ambiguité ou d'incohérence, on peut s'en sortir. Evidemment si c'est pour faire décoller une fusée on va vouloir être précis dans ce qu'on fait, mais quand un élève vient sur un forum poser une question, j'ai presque envie de dire qu'il n'a même pas besoin de la poser, on comprend quand même ce qu'il veut faire. Même Copilot a compris comment écrire cette fonction sans aucune indication, vous allez pas me dire qu'une IA est plus intelligente que nous maintenant ??
EDIT : donc si je devais répondre à la question de l'auteur, à savoir "c'est quoi le problème dans cette fonction", voilà la réponse :
Quand on parcours la liste pour rechercher l'élément existant, il ne faut pas modifier directement "liste->premier", car sinon ça modifie la liste elle-même, il faut se faire une variable, par exemple nommée "courant" comme suggéré par Copilot, et c'est elle qu'on modifie
Au moment de "chainer" le nouvel élément à la liste, il faut mettre le "suivant" du nouveau AVANT de modifier le suivant du courant
Je passe sur le nom des variables et sur le fait qu'en cas de doublon dans la liste, la nouvelle valeur sera ajoutée après la première occurrence seulement, c'est peut être pas ce qu'on veut
Sinon j'aurais pu répondre "j'en sais rien car le comportement attendu n'est pas spécifié" mais la vérité c'est qu'on voit ce qu'il veut faire. C'est comme si je vous disais de trouver le nombre suivant dans cette suite :
1 2 3 4 _
Oui sans autre indication, ça pourrait être 1, 738, 2787736, et pourtant, parmi l'infinité de réponses possibles, on a tous envie de répondre précisément 5, c'est la magie de l'intuition humaine !
On est pas obligé de faire semblant de pas comprendre non plus, si la personne vient sur un forum pour demander de l'aide, elle a déjà un problème à résoudre, on va pas lui en rajouter un quand même ? Ici c'est assez clair, le comportement attendu est d'insérer une valeur dans la liste.
C'est assez clair pour nous, la boule de cristal permet de deviner à peu près. vu que ça ressemble à des exercices hyper-classiques.
Mais fournir directement une correction, c'est facile, malheureusement ce n'est pas la bonne approche pour lui rendre service. Pour que le débutant devienne autonome, il faut qu'il adopte une certaine démarche, qui commence par poser lui même la définition précise de ce qu'il veut que le code fasse, pour que ça ne soit pas flou - auquel cas il n'y arrivera jamais.
Si tu supposes que ça va lui rajouter un problème supplémentaire, c'est que tu penses qu'il ne sait pas dire ce qu'il veut ce que son code fasse. C'est très embêtant comme point de départ.
Ha je pensais que c'était par flemme. Si c'est car on ne sait pas du tout comment exprimer le problème ou les besoins, c'est effectivement problématique.
Mais de toute façon de nos jours ça sert plus à grand chose de savoir faire les choses soi même, car comme je le montre dans la vidéo, Copilot crache la fonction tout seul, même avec les noms de variable un peu bizarres, et ça ne va faire que s'améliorer à l'avenir, je pense qu'il n'y aura plus besoin de programmeurs (l'IA pourra aussi se maintenir et évoluer toute seule)
Ha je pensais que c'était par flemme. Si c'est car on ne sait pas du tout comment exprimer le problème ou les besoins, c'est effectivement problématique.
Mais de toute façon de nos jours ça sert plus à grand chose de savoir faire les choses soi même, car comme je le montre dans la vidéo, Copilot crache la fonction tout seul, même avec les noms de variable un peu bizarres, et ça ne va faire que s'améliorer à l'avenir, je pense qu'il n'y aura plus besoin de programmeurs (l'IA pourra aussi se maintenir et évoluer toute seule)
Bon, alors autant fermer le forum ....
- Edité par edgarjacobs 13 juin 2022 à 20:39:33
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Je veux insérer un élément au milieu de la liste après une valeur existe déjà Le problème est lorsque je compile le nombre que j'ai ajouté est répété plusieurs fois on dirait un boucle infini
Avec pointeur vers pointeur de l'endroit où on sauve l'endroit où on placera le pointeur vers le nouveau. Clair,non?
On insère à la fin si on ne trouve pas. Fonctionne avec une liste vide. - void insert(List *list, int searched, int newValue) { Element *current = list->first; Element **previous = &list->first; // Adresse où on placera le pointeur vers le nouveau. while(current && current->value != searched) { previous = ¤t->next; // Nouvel endroit où placer l'adresse du nouveau. current = current->next; } // Si on veut insérer après la valeur cherchée. if(current) { previous = ¤t->next; current = current->next; }
Element *newNode = malloc(sizeof(Element)); if(newNode == NULL) { printf("Problème de mémoire\n"); exit(EXIT_FAILURE); } newNode->value = newValue; newNode->next = current; *previous = newNode; // On place l'adresse du nouveau au bon endroit. }
- Edité par PierrotLeFou 14 juin 2022 à 8:34:28
Le Tout est souvent plus grand que la somme de ses parties.
Je veux insérer un élément au milieu de la liste après une valeur existe déjà Le problème est lorsque je compile le nombre que j'ai ajouté est répété plusieurs fois on dirait un boucle infini
- Edité par KhaoulaKhichi il y a environ 1 heure
Donc il est clair que si la liste contient, dans, l'ordre, (1 2 4 5) et qu'on dit d'ajouter 6 après 4, on devra obtenir (1 2 4 6 5).
C'est vrai aussi que si on dit d'ajouter 6 apres 5, on obtient (1 2 4 5 6), ce qui n'est pas exactement " au milieu de la liste".
Donc on peut enlever l'indication fausse : en réalité le but est d'ajouter une valeur après une autre qui est présente dans la liste.
Le titre montre que tu t'es focalisé à tort sur cette histoire de milieu (Qui est juste la pour différencier l'exercice de traditionnels "insérer au debut" et "Ajouter à la fin") en zappant le point important : APRES UNE VALEUR INDIQUEE.
Ce qui nous laisse encore du flou, que faire si ladite valeur
N'est pas dans la liste. Faut--il ajouter ? Et où ? Au début ? À la fin ? Ou pas ?
Est présente plusieurs fois ? Après la première occurrence ? Après chaque ? La dernière ?
Pour ce qui est du programme qui boucle, une bonne nouvelle : tu vas trouver très rapidement pourquoi grâce à un crayon et un bout de papier sur lequel le tu gribouilleras l'evolution des variables sur un petit exemple (insertion dans une liste a 2 element)
Bonjour ,svp c'est quoi le problème dans cette fonction?
[...]- Edité par KhaoulaKhichi il y a environ 8 heures
Bonjour,
Normalement, quand on fait appel à un forum, il faut au minimum décrire :
ce que tu attendais comme comportement ;
quel comportement ta fonction exhibe ;
les conditions de tes tests ;
les recherches que tu as entrepris avant de poser ta question ;
là où tu bloques.
On est pas obligé de faire semblant de pas comprendre non plus, si la personne vient sur un forum pour demander de l'aide, elle a déjà un problème à résoudre, on va pas lui en rajouter un quand même ?[...]
Non. Ce comportement est non seulement infantilisant, mais également réellement non productif.
Déjà c'est un signe de politesse que de ne pas poser une bouse pour qu'on se démerde avec. De plus, essayer de deviner un problème qui n'est pas un minimum expliqué c'est dépenser inutilement de l'énergie pour comprendre et souvent comprendre de travers. Quand on fait appel à un forum, il y a une manière d'expliquer son problème. Ce n'est pas un souci qu'un débutant fasse ce genre d'erreur, c'en est un si les intervenants ne lui expliquent pas. Le PO est un débutant, et son principal problème c'est la communication. Donc oui, ce n'est pas faire son vieux réac que de l'aider à mieux utiliser un outil qu'il ne maîtrise pas.
LucieNottin1 a écrit:
[...]
Mais de toute façon de nos jours ça sert plus à grand chose de savoir faire les choses soi même, car comme je le montre dans la vidéo, Copilot crache la fonction tout seul, même avec les noms de variable un peu bizarres, et ça ne va faire que s'améliorer à l'avenir, je pense qu'il n'y aura plus besoin de programmeurs (l'IA pourra aussi se maintenir et évoluer toute seule)
[...]
Ce qui explique pourquoi plus personne ne marche puisqu'on a des voitures qui seront bientôt autonomes.
Même Copilot a compris comment écrire cette fonction sans aucune indication, vous allez pas me dire qu'une IA est plus intelligente que nous maintenant ??
Je me suis amusé à retaper ton code et je m’aperçois que ton Copilot à quelques lacunes !
1) Si l'élément n'est pas inséré, il oubli de libérer la mémoire alloué !
2) Si on insert un élément identique à celui recherché --> boucle infinie (il trouve à la position suivante celui qu'il vient d’insérer, il en insert donc un autre ect...) !
PS : Faut-il faire entièrement confiance aux machines ?
On est pas obligé de faire semblant de pas comprendre non plus, si la personne vient sur un forum pour demander de l'aide, elle a déjà un problème à résoudre, on va pas lui en rajouter un quand même ?[...]
Non. Ce comportement est non seulement infantilisant, mais également réellement non productif.
Tout à fait. D'un point de vue tout à fait pragmatique, pour expliquer quelque chose à quelqu'un sans lui faire perdre son temps, il faut avoir une idée de ce qu'il sait déjà, et de ce qu'il n'a pas bien compris.
En général ce sont les mauvaises conceptions (plutôt que l'ignorance consciente) qui causent les problèmes de compréhension.
Dans notre exemple, l'idée qu'il faut insérer "au milieu" de la liste fait partir de travers (puisque l'ajout peut très bien se faire au début, si la liste est vide, cas qui sera donc probablement oublié).
Par contre si on démarre sur "ajouter après une valeur", on va voir émerger naturellement la notion de "cellule qui contient la valeur", puis de pointeur qui sert à localiser cette cellule, d'accrochage d'une nouvelle valeur après cette cellule, puis des cas à envisager si on n'a pas trouvé, etc.
Donc, quand un débutant pose une question, il faut qu'il s'exprime un peu pour qu'on voit où il en est. Sinon on n'avancera à rien.
Et il arrive souvent que quand ils commencent à commenter et préciser, ils trouvent eux-mêmes la solution. Incroyable, non ?
l'ajout de la nouvelle valeur ne se fait que dans la boucle.
donc il ne se fait pas si on n'y rentre pas
on ne rentre dans la boucle que si
liste != NULL && liste->premier->nombre != valeurExist
et donc on n'y rentre pas quand liste->premier->nombre == valeurExist
c'est à dire si on demande à ajouter après la valeur qui est la première de la liste.
Déjà avec ça, ça ne va pas marcher.
2. ensuite, la première instruction de la boucle est d'altérer le contenu de liste->premier, ce qui modifie systématiquement le pointeur de début. Il va de soi que la structure chaînée de départ (liste avec un champ qui pointe sur la première cellule etc) prend du plomb dans l'aile.
Assez souvent, ça conduit à se construire une structure circulaire, ce qui expliquerait la boucle. C'est peut être le cas ici, j'ai la flemme d'analyser sachant qu'il y a des erreurs en amont
Solution : utiliser une autre variable pour parcourir la chaine.
=> reprendre calmement.
1. on commence par parcourir la liste à la recherche de la valeur, ou de la dernière (pour le cas de l'absence)). Résultat: dans un pointeur l'adresse de la cellule en question, ou NULL (pour le cas de la liste vide)
2. Ensuite, on accroche une nouvelle cellule derrière celle qu'on a trouvé, ou en début de liste si la liste était vide
en effet, j'ai pris une option non spécifiée pour ce cas particulier.
--
Cette histoire de copilot est délirante. Faire des manipulations de listes chaînées en C, c'est pour apprendre à programmer.
Pour écrire des programmes qui servent à quelque chose, on prend un vrai langage de programmation, et on utilise des conteneurs qui font le job. La vraie difficulté, c'est de savoir ce qu'on veut que ça fasse. Et c'est un vrai métier.
Mais de toute façon de nos jours ça sert plus à grand chose de savoir faire les choses soi même, car comme je le montre dans la vidéo, Copilot crache la fonction tout seul, même avec les noms de variable un peu bizarres, et ça ne va faire que s'améliorer à l'avenir, je pense qu'il n'y aura plus besoin de programmeurs (l'IA pourra aussi se maintenir et évoluer toute seule)
-
C'est hors sujet mais je tenais à répondre à ceci. L'idiocratie commence par là. En s'appuyant exclusivement sur ce genre d'outils, on finira par perdre la technologie car les connaissances seront oubliées. Pas dans 10 ans, ni 20 mais ce sera la finalité. Et on voit déjà les dégats en école d'ingénieurs avec des mecs qui ne savent pas écrire 2 lignes de code en seconde ou troisième année ou à pleurer pour faire un pauvre makefile.
De plus, ça n'arrivera jamais. Il y aura toujours des développeurs pour la simple et bonne raison qu'il y a dans ce monde une magnifique notion, défendue par le droit, qui s'appelle "propriété intellectuelle".
Copilot se base sur les milliards de lignes de code, de paramètres de fonctions, etc, qui composent les dépôts Git publics (et il y a déjà eu un doute sur le fait que des codes privés ont été pompés par l'IA). Le jour où il n'y aura plus de développeurs, ce sera le jour où toutes les entreprises du monde renonceront à leur droit à la propriété intellectuelle et à la protection de leurs technologies. C'est à dire : "jamais".
> C'est hors sujet mais je tenais à répondre à ceci. L'idiocratie commence par là. En s'appuyant exclusivement sur ce genre d'outils, on finira par perdre la technologie car les connaissances seront oubliées.
Je pense qu'il n'y a pas trop de danger. Avoir un assistant qui vérifie/complète le code, c'est un outil qui peut beaucoup aider (quand je vois ce qu'on fait avec le refactoring dans les IDE, des trucs qui prenaient des plombes genre extraire une méthode, renommer intelligemment, etc).
Par contre c'est si on peut dire de la "micro-programmation" (au sens de micro management). Ca vient s'occuper des détails, ça fait les trucs répétitifs (comme GAP RPG à la vieille époque pour ne pas avoir à se taper tout le cobol à la main) mais c'est pas ça qui va concevoir les applications.
Même au niveau de "l'autocomplétion de code", si le logiciel suggère un truc ou plusieurs, il faut assez de neurones pour comprendre ce qu'il propose, et choisir la bonne option (ou voir qu'aucune ne convient). Quand on pique un truc dans StackOverflow, il faut aussi que ça soit vraiment la solution à ce qu'on veut faire.
Pour ce qui est des singes qui pissent du code sans trop comprendre, on a déjà ça, depuis des décennies.
---
les étudiants de 2ieme ou 3ieme année qui ne savent pas faire ceci cela, c'est un problème classique. D'abord, pendant toute leur formation depuis le collège, ils sont conditionnés à apprendre des trucs pour le DS d'après, qu'ils peuvent souvent oublier ensuite. Ensuite, ils voient plein de nouveaux trucs en même temps, surcharge cognitive, ils n'arrivent pas à connecter les pointillés et ça ressort par l'autre oreille.
Quand on a un peu plus de recul, on apprend un truc parce qu'on a vu qu'on en avait besoin, et à partir de là on l'utilise régulièrement, et ça finit par coller au fond de la boite crânienne.
Évidemment, quand ils vont en stage ou en premier emploi, c'est agaçant d'avoir à leur réapprendre des trucs qu'ils sont censés savoir, et dont ils ne se rappellent même pas qu'ils les ont vus.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Status 418
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Status 418
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.