Discussion :

[Mac LAK]

C'est là où tu ne connais pas suffisamment le C++ ! J'ai un code critique qui tourne tout aussi vite que la version C, pourtant j'ai de l'héritage et du polymorphisme. MAIS !! C'est de l'héritage simple, pas de fonctions virtuelles (c'est elles qui sont problématiques, les fonctions usuelles avec l'héritage n'impliquent AUCUN surcoût) et le polymorphisme que j'utilise est du polymorphisme statique. C'est d'ailleurs grâce à ce polymorphisme statique que le C++ est plus rapide que le C pour des bibliothèques existantes qu'on réutilise (ex le qsort). Et les templates n'ont pas de surcoût en taille, puisque ces fonctions qui sont réécrites par le compilateur seraient écrites par le développeur !

Et le this empilé tacitement, tu en fais quoi ? Cela ne marche que si tu as des méthodes statiques (= de classe)... Qui n'ont donc pas d'instance d'objet.

De même, tu compares deux fonctions standard implémentées dans les deux langages (qsort) : OK, la version C++ est, de base, meilleure que la version C++. On pourra toujours écrire la fonction en C et la faire aller plus vite que la version C++.

Pour les templates, le souci est surtout l'inlining qu'ils provoquent souvent, et non pas sur le template qui ne fait QUE simplifier l'écriture de code portant sur des données différentes.

Promis, j'ai souvent eu le cas concret dans mon boulot. OK, c'est sur du code ultra-critique (et embarqué), mais comme je l'ai précisé, la plupart des gens n'ont pas besoin d'un tel niveau d'optimisation.

Pour la petite histoire, j'ai même dû passer à l'assembleur, une fois...

[Matthieu Brucher]

Et le this empilé tacitement, tu en fais quoi ? Cela ne marche que si tu as des méthodes statiques (= de classe)... Qui n'ont donc pas d'instance d'objet.

Et alors ? Tu en as aussi besoin en C quand tu travailles sur une structure. Ca ne change strictement rien. Tu n'as pas de vtable si tu n'as pas de fonction virtuelle.

De même, tu compares deux fonctions standard implémentées dans les deux langages (qsort) : OK, la version C++ est, de base, meilleure que la version C++. On pourra toujours écrire la fonction en C et la faire aller plus vite que la version C++.

Et dans ce cas, je réécris ta fonction C en C++, et j'aurai les mêmes performances, si ce n'est meilleures.

Pour les templates, le souci est surtout l'inlining qu'ils provoquent souvent, et non pas sur le template qui ne fait QUE simplifier l'écriture de code portant sur des données différentes.

Oui, c'est toujours inliné, et dans le cas où tu as besoin de la performance (comme dans le cas des codes critiques que je rencontre), c'est indispensable.

Promis, j'ai souvent eu le cas concret dans mon boulot. OK, c'est sur du code ultra-critique (et embarqué), mais comme je l'ai précisé, la plupart des gens n'ont pas besoin d'un tel niveau d'optimisation.

Pour la petite histoire, j'ai même dû passer à l'assembleur, une fois...

Oui, sur du code embarqué, il va falloir faire attention, c'est surtout les bibliothèques de support qui posent problème, et là je suis d'accord qu'elles ne sont pas petites.

[Mac LAK]

Et alors ? Tu en as aussi besoin en C quand tu travailles sur une structure. Ca ne change strictement rien. Tu n'as pas de vtable si tu n'as pas de fonction virtuelle.

Sauf qu'en C, tu n'as pas forcément besoin de ladite structure... Tandis qu'en C++, sauf à faire du C++ qui n'en est pas, tu te fades la classe et donc le this.

Et dans ce cas, je réécris ta fonction C en C++, et j'aurai les mêmes performances, si ce n'est meilleures.

Ben non. Testé et vérifié à de nombreuses reprises, surtout si tu prends en compte le footprint au passage.

Je répète : je n'appelle pas "C++" du code C compilé avec un compilateur C++, où l'on ne trouve QUE des fonctions et pas une seule classe, ou des classes qui n'ont que des méthodes statiques et/ou en mode singleton...
Si le C continue à être plus représenté que le C++, il y a une raison, tu sais ?

Oui, c'est toujours inliné, et dans le cas où tu as besoin de la performance (comme dans le cas des codes critiques que je rencontre), c'est indispensable.

Et ça fait exploser le footprint. Le problème de l'inlining (déjà débattu sur le forum d'ailleurs), c'est qu'il n'est pas garanti : on peut seulement être certain de l'interdire, mais jamais de l'activer (il faut des macros pour l'assurer à 100%, ce qui pose d'autres problèmes).

Après, il y a critique et critique aussi : le "critique" d'un développeur d'IHM n'a pas grand-chose en commun avec le "critique" d'un dév bas niveau en embarqué... Moi, je suis dans la deuxième catégorie. C'est à dire que quand je parle de code critique, mon unité de référence temporelle la plus grande est la microseconde... Situation où l'on finit (parfois, heureusement ce n'est pas non plus constant) par vérifier plus que soigneusement ce que l'on empile, le nombre d'appels de fonctions et le footprint final (code comme données).

Or, le C++ possède un défaut majeur par rapport au C à ce niveau : le this, la VMT et l'inlining moins bien contrôlé qu'en C... Sauf, comme je l'ai précisé, à faire du C-- !
Entre parenthèses, c'est d'ailleurs souvent ce que je fais sur le code critique (C compilé en C++), pour des raisons de simplification de développement (un seul compilateur, pas de soucis de link).

Oui, sur du code embarqué, il va falloir faire attention, c'est surtout les bibliothèques de support qui posent problème, et là je suis d'accord qu'elles ne sont pas petites.

Tu as très exactement le même problème avec les templates, donc avec la STL de façon générale.



Bon, ceci étant dit, pour le traitement d'images tel que le veut l'OP, il y a quand même peu de chances que l'on en arrive à un tel niveau d'optimisation.

[Matthieu Brucher]

Sauf qu'en C, tu n'as pas forcément besoin de ladite structure... Tandis qu'en C++, sauf à faire du C++ qui n'en est pas, tu te fades la classe et donc le this.

Ben non, c'est faux. Le C++, ça s'utilise aussi avec des classes contenant des méthodes statiques, c'est même une des grandes caractéristiques grâce aux templates.

Ben non. Testé et vérifié à de nombreuses reprises, surtout si tu prends en compte le footprint au passage.

C'est sûr que si tu considères qu'en C++ il faut obligatoirement des instances, tu auras cette conclusion. En revanche, si tu te rends compte que le C++, c'est multi-paradigmes, tu verras qu'on peut faire mieux.

Je répète : je n'appelle pas "C++" du code C compilé avec un compilateur C++, où l'on ne trouve QUE des fonctions et pas une seule classe, ou des classes qui n'ont que des méthodes statiques et/ou en mode singleton...

C'est une erreur et une méconnaissance du C++. Le C++ permet d'avoir des performances monstrueuses avec une lisibilité sans pareille avec des classes et des méthodes statiques. Testé et vérifié.

Si le C continue à être plus représenté que le C++, il y a une raison, tu sais ?

Oui, le fait que le C++ nécessite dans certains cas une bibliothèque support imposante.

Et ça fait exploser le footprint. Le problème de l'inlining (déjà débattu sur le forum d'ailleurs), c'est qu'il n'est pas garanti : on peut seulement être certain de l'interdire, mais jamais de l'activer (il faut des macros pour l'assurer à 100%, ce qui pose d'autres problèmes).

Avec les templates, l'inlining est quasiment obligatoire. Et même, les compilateurs que j'ai utilisé se sont toujours bien comportés à ce niveau. L'inlining est efficace.

Après, il y a critique et critique aussi : le "critique" d'un développeur d'IHM n'a pas grand-chose en commun avec le "critique" d'un dév bas niveau en embarqué... Moi, je suis dans la deuxième catégorie. C'est à dire que quand je parle de code critique, mon unité de référence temporelle la plus grande est la microseconde... Situation où l'on finit (parfois, heureusement ce n'est pas non plus constant) par vérifier plus que soigneusement ce que l'on empile, le nombre d'appels de fonctions et le footprint final (code comme données).

Comme je te l'ai dit plusieurs fois, je ne bosse pas sur l'embarqué, en revanche, je bosse sur le plus gros calculateur de France... Je peux t'assurer que la performance et la lisibilité, c'est primordial.

Or, le C++ possède un défaut majeur par rapport au C à ce niveau : le this, la VMT et l'inlining moins bien contrôlé qu'en C... Sauf, comme je l'ai précisé, à faire du C-- !

Je vais me répéter une dernière fois : tu ne connais pas le C++ et ses différents paradigmes. Quand tu les connaitras, tu pourras te permettre se genre de réflexions.

Tu as très exactement le même problème avec les templates, donc avec la STL de façon générale.

Non. Il n'y a besoin d'aucune bibliothèque support, donc ça n'a RIEN A VOIR. Si les templates impliquent du code supplémentaire, en C, ce serait la même chose, sauf que tu devrais l'écrire toi-même.

Bon, ceci étant dit, pour le traitement d'images tel que le veut l'OP, il y a quand même peu de chances que l'on en arrive à un tel niveau d'optimisation.

Exact, mais il y a tout de même des erreurs assez énormes qui méritent d'être corrigées.

[Mac LAK]

C'est sûr que si tu considères qu'en C++ il faut obligatoirement des instances, tu auras cette conclusion. En revanche, si tu te rends compte que le C++, c'est multi-paradigmes, tu verras qu'on peut faire mieux.

Je sais, je les utilise d'ailleurs. Mais quand tu arrives à du "C++" qui passe sans problème sur un compilateur C, ton code, c'est quoi ? Du C++, ou du C ? Pour moi, c'est du C. Pour toi, c'est du C++. C'est le problème du verre à moitié plein, ou à moitié vide, et là, on entre dans la philo et non plus dans l'informatique.

Avec les templates, l'inlining est quasiment obligatoire. Et même, les compilateurs que j'ai utilisé se sont toujours bien comportés à ce niveau. L'inlining est efficace.

Je n'ai pas dit qu'il n'était pas efficace en terme de performances. Il peut par contre être désastreux sur le footprint. Cela n'a pas beaucoup d'importance sur un très gros système, ce n'est pas le cas d'une cible embarquée.
N'oublie pas que la criticité d'un code, c'est aussi bien ses performances brutes que sa consommation de ressources. Si, pour gagner 2% de perfs sur un code consommant 100 Mo de RAM tu multiplies par vingt la mémoire requise, ce n'est pas forcément rentable de façon globale.

Comme je te l'ai dit plusieurs fois, je ne bosse pas sur l'embarqué, en revanche, je bosse sur le plus gros calculateur de France... Je peux t'assurer que la performance et la lisibilité, c'est primordial.

C'est primordial aussi dans mon propre domaine (cf. normes de sûreté de fonctionnement diverses et variées), sauf que c'est de l'embarqué. Le terme "performance" est alors indissociable de "footprint".

Je vais me répéter une dernière fois : tu ne connais pas le C++ et ses différents paradigmes. Quand tu les connaitras, tu pourras te permettre se genre de réflexions.

Cf. premier paragraphe. Tu peux débattre autant que tu veux, ton code est alors autant du C que du C++.
Je connais les différents paradigmes du C++, merci. Mes projets utilisent conjointement du procédural, de l'objet statique, de l'objet virtuel, des templates et même un bout de métaprogrammation. L'utilisation de l'un ou l'autre paradigme dépend simplement du niveau de criticité du code.

Non. Il n'y a besoin d'aucune bibliothèque support, donc ça n'a RIEN A VOIR. Si les templates impliquent du code supplémentaire, en C, ce serait la même chose, sauf que tu devrais l'écrire toi-même.

Relis mes messages précédents. Je ne parle pas de l'utilisation d'un template comme on utiliserait une macro de préprocesseur pour générer du code dépendant d'un type / paramètre. Je parle du problème d'inlining des templates.

Gagner des perfs en faisant exploser la taille de l'exécutable et/ou la RAM consommée, c'est plutôt facile et ça n'apporte pas grand-chose, c'est surtout le compilateur qui bosse. Mais en gagner SANS surconsommer de mémoire, c'est un tout autre domaine d'optimisation, très largement différent.

[Matthieu Brucher]

Je sais, je les utilise d'ailleurs. Mais quand tu arrives à du "C++" qui passe sans problème sur un compilateur C, ton code, c'est quoi ? Du C++, ou du C ? Pour moi, c'est du C. Pour toi, c'est du C++. C'est le problème du verre à moitié plein, ou à moitié vide, et là, on entre dans la philo et non plus dans l'informatique.

Si tu utilises des classes avec des méthodes statiques, je ne vois pas comment ça peut passer en C ! Surtout quand je dis d'utiliser ça pour des templates. La STL et Boost sont pleins de ce genre d'astuces.

Cf. premier paragraphe. Tu peux débattre autant que tu veux, ton code est alors autant du C que du C++.
Je connais les différents paradigmes du C++, merci. Mes projets utilisent conjointement du procédural, de l'objet statique, de l'objet virtuel, des templates et même un bout de métaprogrammation. L'utilisation de l'un ou l'autre paradigme dépend simplement du niveau de criticité du code.

Ce que tu as posté précédemment montre ta méconnaissance du C++. Soit tu t'es mal exprimé, soit tu n'y connais pas autant que ce que tu dis. Tu dis que pour faire du C++, tu dois faire des objets avec une vtable. Excuse-moi, mais c'est faux.

Relis mes messages précédents. Je ne parle pas de l'utilisation d'un template comme on utiliserait une macro de préprocesseur pour générer du code dépendant d'un type / paramètre. Je parle du problème d'inlining des templates.

Tu parles donc de l'impact de l'instantiation du template, problème que tu peux résoudre facilement avec une définition du template et une instantiation externe. Très facilement contournable quand on connaît le C++. Je suis d'accord, c'est un problème de taille dans ton domaine.

Gagner des perfs en faisant exploser la taille de l'exécutable et/ou la RAM consommée, c'est plutôt facile et ça n'apporte pas grand-chose, c'est surtout le compilateur qui bosse. Mais en gagner SANS surconsommer de mémoire, c'est un tout autre domaine d'optimisation, très largement différent.

Et ? C'est le même problème avec les macros en C, non ? Et non, tu n'exploses pas la RAM avec les templates. Tu as un footprint plus important, mais tu n'exploses pas la RAM.

[Mac LAK]

Si tu utilises des classes avec des méthodes statiques, je ne vois pas comment ça peut passer en C ! Surtout quand je dis d'utiliser ça pour des templates. La STL et Boost sont pleins de ce genre d'astuces.

C'est ce que je te dis : on finit par arriver à du code purement fonctionnel, sans utiliser de templates... Le cas le plus récent que j'ai eu à gérer a été de virer un std::vector au profit d'un tableau "en dur", pour des raisons de perfs justement. A noter que pour améliorer la maintenabilité d'un bout de code non-critique, j'ai en même temps viré une structure en dur au profit d'une std::map indexée par une std::string... Sur du code d'initialisation, ça n'a pas d'importance mais ça simplifiait la maintenance.
Mais le code passé à l'optimisation est, d'un point de vue sémantique, du C et non plus du C++ : il compilerait sans broncher sur un compilateur C.

Ce que tu as posté précédemment montre ta méconnaissance du C++. Soit tu t'es mal exprimé, soit tu n'y connais pas autant que ce que tu dis. Tu dis que pour faire du C++, tu dois faire des objets avec une vtable. Excuse-moi, mais c'est faux.

Je dis que le C++ possède cette particularité (certes, lorsque l'on fait des instances de classe et du polymorphisme dynamique). Or, cette fonctionnalité est intéressante elle aussi, je pense que l'on est d'accord sur ce point.
Simplement, elle n'est pas à utiliser partout, notamment parce qu'elle induit une VMT et un paramètre caché supplémentaire.

Tu parles donc de l'impact de l'instantiation du template, problème que tu peux résoudre facilement avec une définition du template et une instantiation externe. Très facilement contournable quand on connaît le C++. Je suis d'accord, c'est un problème de taille dans ton domaine.

Je n'ai pas dit le contraire : c'est un problème de pur footprint, pas plus, pas moins.

Et ? C'est le même problème avec les macros en C, non ? Et non, tu n'exploses pas la RAM avec les templates. Tu as un footprint plus important, mais tu n'exploses pas la RAM.

Sauf qu'avec des macros C, tu garantis un inlining lorsque c'est nécessaire tout en garantissant tout autant de ne PAS inliner les fonctions qui ne doivent pas l'être. La directive inline n'est pas obligatoirement honorée par le compilateur, tu le sais aussi bien que moi. Sur les macros, il n'a pas le choix, et c'est là l'avantage. Pour rester objectif, il y a aussi des inconvénients bien entendu, que l'on trouvera dans tout bon cours sur le préprocesseur.

Côté footprint, ça te permet un meilleur contrôle de ton inlining. Côté RAM, hors cas de mise en ROM du code, ce que tu bouffes pour le code diminue ce qui est disponible pour les données, tout comme certains algos plus rapides sont également plus consommateurs de mémoire.

L'optimisation est toujours une affaire de compromis, entre le besoin client, le temps de développement et la difficulté de maintenance derrière. Tu parles d'optimisation globale, moi d'optimisation pointue, c'est à dire quand deux des trois facteurs précités sont jetés aux orties pour n'obtenir QUE des performances maximales, à n'importe quel prix ou presque.
Ce que tu ne peux pas te permettre globalement, bien entendu : c'est à limiter à des sections de code particulièrement critiques et très ciblées.

[_gabor]

Bonsoir tout le monde,

Je vois que mon topic a déchaîné un débat conséquent, dommage que je ne comprends rien

Matthieu tu me déconseille le livre que je suis entrain de lire, je suis plutôt content parce que je commençais à m'ennuyer Par contre de quel livre exactement parles-tu pour le remplacer ?

J'ai très franchement plus rien essayé en C++ depuis deux/trois jours, mais mes derniers essaies étaient de faire un minimum avec des librairies graphiques, j'ai essayé la libraire CImg et la librairie GD que je connais du PHP, mais la compilation, moi pas connaître, donc je n'ai rien pu en tirer... La compilation me retournait des erreurs à chaque fois... Pour information j'ai fait mes essais sur XCode (sous Mac Os X Leopard) et je faisais ma compilation simplement par le bouton "Build", donc sans paramètres particulières.

En gros lorsqu'on utilise une librairie en C++ on doit modifier les options de compilation ?

Vous avez aussi reparlé du Python, je ne connais absolument pas les performances que ça aurait dans l'utilisation que j'aimerais avoir.

L'absence de compilation me rebute uniquement pour la question de portabilité, que l'on doive installer Python sur chaque machine ou le programme sera exécuté. C'est comme si je restais au PHP, il faut obligatoirement avoir PHP sur la machine qui exécute.

Mais comme dit je ne connais pas les performances, si ça se trouve, pour l'imagerie ça surpasse de loin le PHP (ce qui m'étonnerait pas, mais j'aimerais qu'on me le confirme !).

Joyeux Noël !

[Matthieu Brucher]

Matthieu tu me déconseille le livre que je suis entrain de lire, je suis plutôt content parce que je commençais à m'ennuyer Par contre de quel livre exactement parles-tu pour le remplacer ?

Celui fourni par la rubrique C++ (regarde sur cpp.developpez.com)

J'ai très franchement plus rien essayé en C++ depuis deux/trois jours, mais mes derniers essaies étaient de faire un minimum avec des librairies graphiques, j'ai essayé la libraire CImg et la librairie GD que je connais du PHP, mais la compilation, moi pas connaître, donc je n'ai rien pu en tirer... La compilation me retournait des erreurs à chaque fois... Pour information j'ai fait mes essais sur XCode (sous Mac Os X Leopard) et je faisais ma compilation simplement par le bouton "Build", donc sans paramètres particulières.

Si tu as des problèmes de compréhension pour la compilation, mieux vaut donc que tu laisses tout ça de côté !

En gros lorsqu'on utilise une librairie en C++ on doit modifier les options de compilation ?

Non, mais il faut ajouter des includes et des bibliothèques à l'édition des liens.

Vous avez aussi reparlé du Python, je ne connais absolument pas les performances que ça aurait dans l'utilisation que j'aimerais avoir.

Comme tu ne nous en dis pas plus... Sache que Google utilise Python intensivement.

L'absence de compilation me rebute uniquement pour la question de portabilité, que l'on doive installer Python sur chaque machine ou le programme sera exécuté. C'est comme si je restais au PHP, il faut obligatoirement avoir PHP sur la machine qui exécute.

En C++, c'est la même chose, tu dois avoir les bibliothèques support installées, idem pour GD et CImg !

Mais comme dit je ne connais pas les performances, si ça se trouve, pour l'imagerie ça surpasse de loin le PHP (ce qui m'étonnerait pas, mais j'aimerais qu'on me le confirme !).

On fait de l'imagerie en Python au niveau recherche et industriel. On ne fait rien de tel en PHP.

[Mac LAK]

En gros lorsqu'on utilise une librairie en C++ on doit modifier les options de compilation ?

En général, on doit "installer" la librairie dans les chemins par défaut du compilateur, OU spécifier manuellement dans les options de compilation l'endroit où elle se trouve.
Par défaut, sur les systèmes de type Unix, c'est une "installation" que l'on effectue. Sur les systèmes Windows, il n'y a pas de "point central" pour les librairies, donc on spécifie leur chemin dans les options du projet.

Vous avez aussi reparlé du Python, je ne connais absolument pas les performances que ça aurait dans l'utilisation que j'aimerais avoir.

Moins bon que le C/C++ bien entendu, mais tout dépend de ce que l'on appelle "calcul intensif" bien sûr. Avec les machines actuelles, calculer un flou gaussien ou appliquer des convolutions complexes à une image n'est plus une opération que l'on mesure en minutes... La différence entre langage compilé et langage interprété assisté par une bonne base compilée (les librairies natives de support) est invisible à l'œil humain sur UN traitement. La différence se fait sentir sur des calculs à la chaîne, que ce soit le même sur plusieurs images différentes ou une suite complexe de traitements sur une image donnée.

Si ton but est, par exemple, d'avoir une sorte de Photoshop scripté pour faire de multiples essais très différents les uns des autres, un langage interprété sera plus pratique : la librairie de support ne change pas, seules les opérations que tu lui demande sont différentes à chaque fois.

Par contre, si tu SAIS ce que tu veux faire, et que tu dois le faire à "grande échelle" (par exemple, retoucher toutes tes photos numériques d'une certaine manière), alors un langage compilé sera plus performant.

En gros : si tu as de multiples traitements à faire, mais tous "uniques", un langage interprété est préférable (programmes "one-shot"), car tu gagneras plus en temps d'écriture desdits programmes que tu n'en perdras à l'exécution.
Inversement, si tu dois faire peu de traitements différents, mais les appliquer à de très nombreuses images, un langage compilé sera alors plus efficace car le surcoût en temps d'écriture sera compensé par le gain à l'exécution.

Mais comme dit je ne connais pas les performances, si ça se trouve, pour l'imagerie ça surpasse de loin le PHP (ce qui m'étonnerait pas, mais j'aimerais qu'on me le confirme !).

J'ai beau trouver PHP intéressant et pratique, ce ne sont sûrement pas ses performances à l'exécution qui m'ont le plus séduit... Python sera plus performant que PHP de façon générale, du moins en dehors du monde Web où les librairies PHP existantes redonneront l'avantage à ce langage.
Après, ça reste un avis strictement personnel bien sûr, mais je trouve Python plus bordélique que PHP de par son absence de blocs clairement délimités (ce sont les tabulations qui jouent ce rôle, si tu l'ignores)... Moi, ça me laisse un sale goût de vieux Makefile infernal à déplanter dans la bouche, mais je le répète : c'est un avis personnel.

[czar_m]

et qu'est ce que vous pensé du C# comme langage pour traitement d'image? surtout qu'on peut utiliser le pointeur en C# dans le "unsafe" mode

[Jack Sparrow]

Je reinterviens sur le mini débat C / C++ (et voir autres langages).

Je dis juste que quand je vois des logiciels comme Gimp (qui est en C) et la vitesse déplorable des filtres qu'il propose, je me dis que le problème C ou C++ ne vaut pas le coup d'être débattu (hors système embarqué).


J'ai déjà fait des implémentations de filtres de Gimp en Java qui sont énormement plus rapides, d'une part parce qu'il y a souvent des algos de meilleurs complexités qui existent et d'autre part parce que je sais comment ne pas faire n'importe quoi avec le langage que j'utilise (en java, ce serait typiquement, ne jamais appeler BufferedImage#s/getRGB)

(et pourtant c'est bien connu : Même s'il existait un meilleur langage tout problème confondu, cela n'empecherait surement pas de faire n'importe quoi avec).

[mailaka]

C'est un livre qui ne te permettra pas de programmer même un peu correctement en C++. On te propose dans la rubrique C++ un ouvrage traduit de l'anglais bien meilleur !

Salut. Ce serait pas mal de preciser lequel car la rubrique C++ est vaste.

[mailaka]

De même, tu compares deux fonctions standard implémentées dans les deux langages (qsort)

C'est le sort de <algorithm> pour C++ ?