Discussion :

[id_rima]

Bonjour,

Il y a-t-il une personne qui peux m'aider sur un problème de listes chainées en C++ svp ?

Voila j'ai une liste chainée que j'ai appelé liste_segments (cette liste contient des segments)
sa déclaration est la suivante:

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
typedef struct _Liste_Segments
    {
    Segment *UnSegment;
    long Longueur;
    unsigned char R,V,B;
    int noclasse;
     _Liste_Segments *Segment_suivant;
} Liste_Segments;
 
typedef struct _Segment
    {
     long x;
     long y;
     _Segment *suivant;
} Segment;

mon but et de calculer la distance entre tous les extrémités des segments pour relier les segments qui sont proches les uns des autres. mais je ne sais pas faire ca je ne sais pas par ou commencer

dois je faire une boucle et comparer entre p->segment->x et p->segment+1->x' même chose pour y histoire d'avoir les variables dont on aura besoin pour calculer la distance euclidienne. car se sont deux listes chainées imbriquées liste_segments contient la liste chainée "segment ". aussi quelqu'un peut m'expliquer comment se pressentent les deux listes avec un petit schéma je n'ai aucune idée de ça?

encore une fois mille mercis pour votre aide

[Joel F]

std::list<Segment> et ca suffira. Pas besoin de reinventer la roue

[nikko34]

Sauf s'il fait du C et que c'est un exercice de cours...

[Joel F]

Sauf s'il fait du C et que c'est un exercice de cours...

moi je lis C++ dans le premier poste

[camboui]

J'vois deux listes, en C++ ça donnerait un truc comme ceci

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
struct Segment
{
     long x, y;
};
 
struct Liste_Segments
{
    std::list<Segment> UnSegment;
    long Longueur;
    unsigned char R,V,B;
    int noclasse;
};
 
...
 
std::list<Liste_Segments>

[3DArchi]

moi je lis C++ dans le premier poste

ça peut quand même être un exercice .

@id_rima : c'est un problème d'algorithme et non pas de C ou de C++. Quel algorithme souhaites-tu mettre en oeuvre et où n'arrives-tu pas ? En plus, cela doit-il être performant ou cela doit-il juste marcher ? Car dans un cas la solution peut être plus complexe que dans l'autre.

[Joel F]

ça peut quand même être un exercice .

un pas bon alors. Je comprends la manie des profs de faire reinventer la roue comme ça ...

[koala01]

Salut,

un pas bon alors. Je comprends la manie des profs de faire reinventer la roue comme ça ...

C'est peut être discutable dans une optique d'étude du C++, mais, d'un autre coté, à défaut d'arriver à faire en sorte de réformer complètement l'idée que les profs se font de l'étude d'un langage (quel qu'il soit) de programmation, il me semble important d'inciter les étudiants à réfléchir aux principaux algorithmes régulièrement mis en oeuvre, quel que soit le langage ou la technologie utilisé(e): les piles, les files, les listes et les arbres binaires font, typiquement, partie des structure dynamiques pour lesquelles les différents algorithmes sont utilisés de manière systématique.

L'idéal serait, effectivement, de séparer l'approche algorithmique ou l'approche de la conception de toute étude d'un langage en particulier, mais voilà... C'est (trop ) rarement le cas.

Or cette séparation s'avère pour ainsi dire indispensable si l'on veut suivre une approche qui permette l'utilisation systématique des possibilités propres au C++

[nikko34]

euh ben oui, faut quand même faire de l'algo. Je ne comprendrais pas un élève qui n'a jamais codé une liste chaînée.

Après il faut bien expliquer que ça existe dans la lib standard en C++.

[koala01]

euh ben oui, faut quand même faire de l'algo. Je ne comprendrais pas un élève qui n'a jamais codé une liste chaînée.

Après il faut bien expliquer que ça existe dans la lib standard en C++.

Mais ce que je voudrais mettre en évidence, par contre, c'est que c'est, justement le fait d'apprendre l'algorithmique en même temps que son premier langage (quel qu'il soit) qui donne cette impression que le langage et la programmation sont compliqués.

Apprenons donc l'algorithmique sans se rapporter à un langage particulier, puis apprenons un (des) langages procédural(aux).

Apprenons ensuite (éventuellement en même temps que le premier langage procédural) les principes de la programmation OO et / ou ceux de la programmation générique, éventuellement en parallèle avec une technique associée (UML , Agile, ...)

Apprenons enfin un / des lanage(s) OO et / ou multi paradigme(s) en nous attardant tout particulièrement sur

• ce qu'il fournit de manière standard
• Les éventuelles différences avec d'autres langages (OO ou non, multi paradigmes ou non) que nous aurions éventuellement appris
• Ses points de concordance avec les "principes généraux" appris et surtout
• Les points par lesquels il s'écarte des principes généraux

Au final, nous obtiendrons quelqu'un qui, bien sur, aura sa propre préférence pour un langage donné, mais qui connaitra et maitrisera (peut être) malgré tout plusieurs langages.

[atttchoum]

L'idéal serait, effectivement, de séparer l'approche algorithmique ou l'approche de la conception de toute étude d'un langage en particulier, mais voilà... C'est (trop ) rarement le cas.

Or cette séparation s'avère pour ainsi dire indispensable si l'on veut suivre une approche qui permette l'utilisation systématique des possibilités propres au C++

En fait à la fac c'est l'approche qu'ils privilégient (en tout cas dans la mienne), le langage n'est là que pendant les TP ou pour réaliser des projets. Mais il faut bien se rendre compte que manger de l'algo sans le mettre en œuvre est très vite chiant .

[koala01]

En fait à la fac c'est l'approche qu'ils privilégient (en tout cas dans la mienne), le langage n'est là que pendant les TP ou pour réaliser des projets. Mais il faut bien se rendre compte que manger de l'algo sans le mettre en œuvre est très vite chiant .

Ca dépend de comment c'est présenté...

C'est, en partie du moins, l'approche que j'ai eue en cours (du soir), et, comme mon prof arrivait à bien le faire vivre (faut dire qu'on n'était qu'une vingtaine ) c'était tout sauf chiant

Ensuite, il faut aussi voir la manière dont sont représentés les algorithmes...

• Le pseudo code, c'est pas mal sur un forum, mais, si c'est pour la création d'un algorithme, pourquoi passer par... du faux code
• Le flowchart ne permet pas de représenter toutes les possibilité de la programmation structurée et d'assurer une "traduction automatique"
• le nassi-schneiderman devrait presque être appris de manière systématique, car il permet, justement, d'assurer une traduction automatique, bien que d'aucuns n'aiment pas son aspect "petit dessin"
• Il est difficile d'envisager la gestion des ruptures si on ne pratique pas le jackson ou similaire
• ...

Mais bon, c'est un autre débat