Bonsoir,
 
Dans ma classe Map, j'ai une méthode de tri (pour trier un tableau de taille fixe connue) dont voici le code :

Et la fonction de tri est :

Et là où j'ai un problème c'est que Visual C++ 6.0 me dit :

J'ai bien essayé de mettre, à tout hasard, (__cdecl *) (un cast) devant le 4ème argument de qsort ("Map_comparaison_croissant<Enreg>" ), mais il me sort un : syntax error : '__cdecl'.
 
J'ai fait des tests et j'arrive à faire fonctionner un qsort tant que la fonction de comparaison n'est pas sur un type générique.
Est-ce peine perdue ?

pas de sqort. utilise std::sort

Je comprends pas ?
Je ne peux pas employer le tri rapide dans ce cas là ?
 
Qu'est-ce que std::sort ? (je ne suis pas encore très très familier avec toutes les librairies C/C++).

std::sort c'est le tri C++. qsort c'est du C avec tous ses défauts.

et de toute façon pour obtenir l'adresse d'une méthode le & devant est obligatoire. Il est optionnel pour les fonctions globales "à la C".
 
Mais Taz a raison, en C++ il faut utiliser std::sort qui marche avec des itérateurs. Sachant qu'un pointeur est un itérateur, c'est pas trop contraignant. Les algos présents dans le C++ sont bien + nombreux que ceux du C. D'ailleurs en C, à part qsort...
 
exemple :

 
le tri se fait avec l'operator< par défaut.
 
edit : ta fonction de comparaison semble bien être un fonction et pas une méthode. Dans ce cas :

devrait marcher à vu de nez. mais ça reste mauvais.

 
Sans vouloir sodomiser des dyptéres, il me semble qu'il y a quand même une *légére* différence masi si leur sémantique est identique  

il sert à quoi ton extern C ?

En effet, "Map_comparaison_croissant()" n'est pas une méthode de classe mais bien une fonction.
 
jesus_christ, pour ton exemple, j'obtiens "'std' : is not a class or namespace name", quelle librairie dois-je inclure avant d'utiliser std::sort ?

la bibliothèque <algorithm>
 
lis la doc bon sang !

à ce que le type du pointeur de fonction soit bien (__cdecl*) sous visual c++
 
Joel F : c'est pas seulement sémantique, les pointeurs sont un cas particulier des itérateurs.
Souvent (avant) vector<T>::iterator était défini comme T*, même si ça ne ce fait plus trop et que ça peut inciter à faire du code pas portable.
Bien sur à part sur les tableaux et les vecteurs* (et dans le sens normal, pas reverse) les pointeurs ne vont pas très loin.
 
* : si les vecteurs stockent de façon contigue, ce qui doit normalement être le cas.

j'y comprends rien à votre compilo de merde.

visual c++ n'est peut-être pas le compilo le + conforme à l'ISO98 mais c'est un des meilleurs sous win et il a de très loin le meilleur debugger.
Sans compter que VC6 a été écrit en 97 et a donc une bonne excuse pour pas être conforme, quant à VC7 et VC8 il sont très proches du standard. Microsoft a isolé toutes ses "exotismes" dans .net/C# et a laissé le C++ "pur".
 
VC type les fonctions selon leur convention d'appel. __cdecl pour le C, __thiscall pour les méthodes C++, __stdcall pour les appels standard win(utile pour linker avec du VB par exemple, diff sur callee-save et caller-save) et __fastcall pour passer les paramètres par les registres.

je m'en fout. extern "C" autour d'un truc C++ c'est un non-sens.

c'est pourtant cité dans le Stroustrup. extern défini un linkage et pas un langage -> chap (9.2) En plus son explemple c'est justement le qsort avec une fonction extern "C"

justement ... tu ferais mieux de le lire le stroustrup. Du code C++ ne peut avoir un linkage C.

j'ai vérifié et il dit bien que toutes les combinaisons sont possible. Et puis du code C++ c'est vite fait, genre

c'est du C++ et pas du C89, pourtant le linkage extern "C" marche. En cas de template ou de pointeur de méthode, enfin des trucs "très C++" peut-être qu'il n'existe pas de linkage C. Du code C++ peut dans certains cas ne pas être linké en C, mais c'est la plupart du temps possible.
Trouve moi un compilo ou une ligne du Stroustrup qui interdit ça :

et on en reparle.

t'as toujours pas lu le stroustrup ça fait plaisir. t'as toujours pas compris à quoi ça servait. laisse tomber.

je l'ai sur les genou, le stroustrup 3e edition. Dis moi où il définit les interdictions dont tu parles au lieu de décréter que j'ai pas compris. C'est peut-être vrai, mais argumente.
En attendant l'intro du chapitre 9.2.4 dit bien que la directive extern "truc" sert aussi bien à exporter qu'à importer des symboles de ou vers du C++.

tu ne peux pas obtenir un symbol C++ avec un truc template, c'est ça que je veux dire ...

Tu fais bien de préciser
 
D'ailleurs, j'ai quand même regardé dans la norme, je n'ai trouvé aucun qui paragraphe qui mentionne cette interdiction, même si elle parait logique ... Mais j'ai peut etre pas les yeux en face des trous.

c'est pas une interdiction, c'est un non-sens. Tu  ne peux avoir dans un bloc extern "C" que des symboles C. qsort a un linkage C, mais pas besoin de linkage C pour son argument fonction de comparaison.

ah là je suis d'accord, donc mon code est effectivement erroné, on ne peut pas obtenir de symbole C à partir d'un template. Mais on peut à partir d'une fonction C++ passablement proche du C.
 
Fab++ : idem, j'ai lu et relu (le stroustrup, pas la norme), ça ne me semble pas être écrit explicitement. Dans le même genre le fait que les classes locales aux fonctions ne soient pas linkables (même en C++ pur), je l'ai trouvé dans le lexique du site de stroustrup mais pas dans son livre.

Un symbole C++ ayant un sens en C (ni class ni objet ni template ni pointeur de méthode ni operator...) peut avoir un symbole C, c'est d'ailleur surtout à ça que ça sert.
 
si t'écris void f() {} dans un fichier compilé en tant que C++ c'est du C++ même si ça pourrait exister en C.

 
Oui, je voie mal un code C inclure un header dans lequel figure : extern "C" template<class T> void(T);
D'ailleurs, ça parait logique que ce soit mentionné nul part finalement.
Par contre, histoire de couper un cheveux en 4, qsort n'a pas forcément un linkage C ...

pourtant c'est le code qui a été proposé.

j'ai mis ta remarque dans mon code qui est effectivement erroné.