cs_Patrice99
Messages postés1221Date d'inscriptionjeudi 23 août 2001StatutMembreDernière intervention 9 septembre 2018 16 janv. 2007 à 11:19
Oui il sert surtout à faciliter l'écriture de code DotNet2, et je crois bien que c'est la seule solution pour le tri à clés multiples en RAM. Pour les pointeurs, je n'en sais rien du tout, ça fait des années que j'ai définitivement oublié ces trucs pour se torturer (probablement) inutilement les méninges.
xkamen
Messages postés26Date d'inscriptionvendredi 8 avril 2005StatutMembreDernière intervention31 janvier 2008 16 janv. 2007 à 10:45
En fait, je viens de regarder ce que c'était le IComparer. Ce comparateur universel est un comparateur seulement qui permet facilement d'écrire comment est effectué le tri en spécifiant les clefs (avec l'ordre ascendant ou descendant). Mais la méthode de tri reste celle du compilateur. Est ce que cette méthode tri est vraiment la plus efficace ? là, je ne sais pas, il faudrait la comparer aux méthodes inclues dans ma source.
Par contre, ce que je pourrais rajouter, c'est le fait d'utiliser un comparateur universel plutot que les comparateurs définis par 'int (*comp)(void *elem1, void *elem2)', ce qui permettrait de rendre le tout plus facilement utilisable. En gros, il faut que j'améliore mon comparateur pour le rendre universel. :D
xkamen
Messages postés26Date d'inscriptionvendredi 8 avril 2005StatutMembreDernière intervention31 janvier 2008 16 janv. 2007 à 08:51
Ceci n'implique t-il pas de programmer en C# ? Car ici, le code est en C++. De plus, si j'ai bien compris, les données sont représentées sous la forme d'un tableau : dans ce cas, je comprends que ce soit très pratique. Mais que se passe t-il si les données à trier sont de la forme :
class Data
{
int Quantite;
SubData *Value;
};
class SubData
{
float Value;
... // Avec encore des pointeurs vers d'autres données
};
Ici, j'ai pris un exemple que montre des données qui pointent vers d'autres données en chaine. Est ce qu'il sera pratique d'utiliser le comparateur universel dans ce cas ? Si je demande cela, c'est que je ne connais pas trop le C# ni le comparateur universel, donc je voulais savoir si ce comparateur universel pouvait s'appliquer dans n'importe quel cas, même si les performances peuvent décroitre dans certains cas.
cs_Patrice99
Messages postés1221Date d'inscriptionjeudi 23 août 2001StatutMembreDernière intervention 9 septembre 2018 16 janv. 2007 à 08:37
Tout à fait exact ! Cependant, dans l'hypothèse où tu ne gardes qu'un seul algorithme dans le cas le plus général qui soit (ce que feront sans doute 95% des développeurs), alors si tu n'as pas besoin de trier sur 2 clés comme dans une requête SQL et que la performance compte, mieux vaut ne pas utiliser le comparateur universel. Dans les autres cas, c'est une classe passe partout super pratique.
xkamen
Messages postés26Date d'inscriptionvendredi 8 avril 2005StatutMembreDernière intervention31 janvier 2008 15 janv. 2007 à 19:22
Merci, je vais regarder ça et je complèterai. C'est normal que ce ne soit pas toujours performant. Selon les situations, un algorithme de tri peut etre plus performant qu'un autre. Donc je ne m'inquiète pas. Si un utilisateur désire utiliser un de ces algorithmes, il devra tout d'abord regarder si ce qu'il désire trier est dans une situation particulière ou non, c'est à dire soit partiellement trié, soit disposant d'un faible nombre de valeurs, etc...
S'il existait un algorithme qui soit toujours performant quelque soit le type de données, alors je ne vois pas pourquoi on garderait les autres algorithmes. :D
cs_Patrice99
Messages postés1221Date d'inscriptionjeudi 23 août 2001StatutMembreDernière intervention 9 septembre 2018 15 janv. 2007 à 16:12
Salut, si ça peut t'intéresser, j'ai trouvé un comparateur universel en DotNet2 capable de trier sur plusieurs clés (mais pas toujours très performant, ce qui est dommage) :
www.dotnet2themax.com/ShowContent.aspx?ID=05c3d0c3-ac44-4a20-92d9-16cdae040bc3
UniversalComparer comp = new UniversalComparer(typeof(Person), "LastName, FirstName");
Array.Sort(persons, comp)
xkamen
Messages postés26Date d'inscriptionvendredi 8 avril 2005StatutMembreDernière intervention31 janvier 2008 14 janv. 2007 à 21:28
Salut,
Je te remercie, je viens de corriger l'erreur dans le PDF. Heureusement, je n'avais pas fait l'erreur dans la source elle-même. :)
The_Void
Messages postés4Date d'inscriptiondimanche 24 décembre 2006StatutMembreDernière intervention14 janvier 2007 14 janv. 2007 à 18:59
Salut,
J'ai jeté un coup d'oeil à ton pdf, et il a l'air d'être très complet :)
Par contre, pour l'algo de tri Comb, j'ai remarqué qu'il n'y a pas de "permut = false" dans la boucle (il est juste avant) , d'où une boucle infini ;)
16 janv. 2007 à 11:19
16 janv. 2007 à 10:45
Par contre, ce que je pourrais rajouter, c'est le fait d'utiliser un comparateur universel plutot que les comparateurs définis par 'int (*comp)(void *elem1, void *elem2)', ce qui permettrait de rendre le tout plus facilement utilisable. En gros, il faut que j'améliore mon comparateur pour le rendre universel. :D
16 janv. 2007 à 08:51
class Data
{
int Quantite;
SubData *Value;
};
class SubData
{
float Value;
... // Avec encore des pointeurs vers d'autres données
};
Ici, j'ai pris un exemple que montre des données qui pointent vers d'autres données en chaine. Est ce qu'il sera pratique d'utiliser le comparateur universel dans ce cas ? Si je demande cela, c'est que je ne connais pas trop le C# ni le comparateur universel, donc je voulais savoir si ce comparateur universel pouvait s'appliquer dans n'importe quel cas, même si les performances peuvent décroitre dans certains cas.
16 janv. 2007 à 08:37
15 janv. 2007 à 19:22
S'il existait un algorithme qui soit toujours performant quelque soit le type de données, alors je ne vois pas pourquoi on garderait les autres algorithmes. :D
15 janv. 2007 à 16:12
www.dotnet2themax.com/ShowContent.aspx?ID=05c3d0c3-ac44-4a20-92d9-16cdae040bc3
UniversalComparer comp = new UniversalComparer(typeof(Person), "LastName, FirstName");
Array.Sort(persons, comp)
14 janv. 2007 à 21:28
Je te remercie, je viens de corriger l'erreur dans le PDF. Heureusement, je n'avais pas fait l'erreur dans la source elle-même. :)
14 janv. 2007 à 18:59
J'ai jeté un coup d'oeil à ton pdf, et il a l'air d'être très complet :)
Par contre, pour l'algo de tri Comb, j'ai remarqué qu'il n'y a pas de "permut = false" dans la boucle (il est juste avant) , d'où une boucle infini ;)