Discussion :

[Invité]

Bonjour

Je rajouterais :
- la portabilité toute relative.
- le dédain de la STL par les librairies graphiques ( qui chacune redéfinissent les types de bases, chaînes, listes, tableaux...)
- la complexité à intégrer des modules développés par des moyens différents

JB

Le mot est faible.

La STL est tellement mal implémentée que même Electronic Arts a dû la réécrire pour ses besoins.

Je ne vois pas l'intérêt d'avoir plusieurs syntaxes pour les pointeurs (celle héritée du C et celle propre au C++ avec "&") ni l'intérêt des pointeurs puisque laisser cet accès bas niveau à la mémoire est surtout dangereux d'une part et empêche (ou complique notablement) l'implémentation de certaines optimisations mémoire au niveau du compilateur. C'est une des raisons qui explique que C++ n'est pas indétrônable en terme de vitesse d'exécution et de gestion mémoire.

Le préprocesseur est pour ma part aussi un point négatif. On ne sait plus trop ce qu'on a à la fin, je préférerais pouvoir détecter l'OS à l'exécution (et mettre du code dépendant d'une plateforme dans un branchement conditionnel) au lieu de jouer avec les #ifdef. Cependant, avec le compilateur GNU, il me semble qu'il existe une option pour voir le code source après traitement des directives du préprocesseur ce qui peut s'avérer rudement utile.

Globalement, je trouve qu'au fil du temps, la syntaxe de C++ permet de faire tellement de choses de tellement de façons que ça rend certains codes très difficiles à lire.

Je sais que c'est très subjectif mais je trouve que Visual Studio n'arrive toujours pas à la cheville d'Eclipse bien que j'arrive à déboguer le code pas à pas de manière assez similaire.

Enfin, à choisir, je préférerais avoir un vrai garbage collector et une gestion unifiée des objets à la place d'un type de pointeur distinct (smart pointer).

[zul]

La STL est tellement mal implémentée que même Electronic Arts a dû la réécrire pour ses besoins.

Ça ne veut rien dire comme phrase. À la rigueur, l'implémentation de la STL par tel compilateur est tellement mauvaise que EA a du la réecrire pour ses besoins, ou bien, EA n'a rien compris au fonctionnement de la STL et a préféré réecrire sa version. (La STL est plutôt bien pensé en général, on peut à la rigueur avoir des reproches sur les streams mais bon c'est pas vraiment dans la STL).

Je ne vois pas l'intérêt d'avoir plusieurs syntaxes pour les pointeurs (celle héritée du C et celle propre au C++ avec "&") ni l'intérêt des pointeurs puisque laisser cet accès bas niveau à la mémoire est surtout dangereux d'une part et empêche (ou complique notablement) l'implémentation de certaines optimisations mémoire au niveau du compilateur. C'est une des raisons qui explique que C++ n'est pas indétrônable en terme de vitesse d'exécution et de gestion mémoire.

Les deux n'ont pas la même sémantique, et ont des usages différents. Je sais, c'est difficile à comprendre. L'usage de pointeur bas-niveau peut être utile, surtout quand on utilise le C++ comme un langage systeme. Sinon, j'aimerai bien savoir quelle langage détrone un bon compilateur C++ en terme de perfo (et un mec qui code raisonnablement évidemment).

Enfin, à choisir, je préférerais avoir un vrai garbage collector et une gestion unifiée des objets à la place d'un type de pointeur distinct (smart pointer).

Tu fais trop de Java Si tu veux un garbage collector, personne ne t'empeche d'en utiliser un (ça fait longtemps qu'il en existe ....). Quand la "gestion unifié des objets", je ne sais pas ce que tu entends, mais le RAII est bien plus homogène que GC + finally + ... pour gérer les différents types de ressources.

Le problème majeur de C++, c'est manifestement que ce n'est pas du Java ou du C# , voire pire qu'on ne raisonne pas pareil en C++ que dans les deux autres sus-cités.

EDIT : LINQ on peut faire des choses proches en C++, sans changer de normes / compilateur (voir Linq++ par exemple http://hjiang.net/archives/229, ou Oven : http://p-stade.sourceforge.net/oven/doc/html/index.html. Pour WPF, je ne sais pas ce que tu regrette (je ne fais pas bcp de dev graphique), mais Qt intègre aussi un langage déclaratif pour décrire des interfaces, voir faire des choses hautement dynamiques (et ça a le bon goût d'être portable)). C'est à mon avis hors du scope de C++ d'avoir une spec graphique, (et vu ce que ça a donné en Java, non merci)).

[gorgonite]

je suis pas sûr d'avoir bien compris, mais si c'est d'adapté le type de la variable selon le type de retour de la fonction, le D le fait grace au mot clé auto (le vala aussi)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

auto maVar = funcReturnChar();

euh, ça n'a rien à voir avec le fait d'avoir des signatures prenant en compte le type de sortie... ce serait plus proche de la forme la plus basique qu'on puisse imaginer de l'inférence de type

par ailleurs, tant qu'il n'y a aucun mécanisme d'unification, ou un non respect de l'objet "classique", j'ai beaucoup de mal à voir comment le compilo pourrait se débrouiller seul (quid de l'objet et de l'inférence de type sous F#, ou alors cf modèle inférence objet de OCaml)

[Invité]

Son processus très lent de normalisation. J'ai l'impression qu'il se passe un peu la même chose qu'avec l'OpenGL 3.0. ça fait maintenant un paquets d'années qu'on entend parler de C++0X puis C++1X sans en voir le bout (2010 ou 2011 c'est promis !) donc les attentes sont grandes vu que pendant ce laps de temps les language concurrent (C#) progresse rapidement et par bonds importants (Linq, WPF, ...).
En plus de même qu'avec l'OpenGL (je sais que les deux approches ne sont pas tout a fait comparables) il y a un risque d'obtenir un consensus mou au final : concepts exclu de la prochaine norme par exemple.
J'utilise pourtant avec le compilo de VS2010 les nouveautés du draft (auto, rvalue, lambda expression principalement ) mais il me manque encore le GC facultatif notamment.

Signé un C++iste impatient qui voit autour de lui les nouveaux projets démarrer en C# et qui craint de devenir le dernier des mohicans.

J'adhère : ta solitude est grande ôô mohican

Je réalise qu'en défendant C++ et ses lourdeurs, j'irais à l'encontre du grand topic et risquerais de m'attirer les foudres du roi des âmes dont la lumière blafarde des dalles lcd cache l'immense quète d'idées neuves..

C'est vrai que pour faire bouger cette montagne de c++, il faut plus ou moins obtenir le consensus entre tous les grands éditeurs de la planète. La plupart des propositions doivent recueillir beaucoup de contestation et le standard fait du sur-place.

Cela dit, à mon niveau, peu de projets 100% C++ mais beaucoup de projets multi languages auxquels le C/C++ apportent leur performance imbattable alors que les parties back office sont programmées sur visual studio, java ou n'importe quel language moins contraignant.

En retournant le problème, on reproche fréquemment la petitesse de la librairie. La conclusion que j'en tire est que pour laisser un maximum de liberté aux éditeurs très jaloux de leurs méthodes, on les incite à créer leur propre extensions alors que le "core" du langage reste minimaliste.

On peut aussi reprocher à certains langage de rendre obligatoire l'utilisation d'un produit de l'éditeur qui va affecter toute l'activité de l'éditeur :Windows, Android, Iphone sont aussi d'énormes librairies dont l'usage n'est pas anodin

On pert d'un coté l'avantage d'une librairie intégrée au core qui rend l'IDE très confortable, mais on grade le choix du system d'exploitation, du processeur ou contrôleur, etc... Dans les faits, c'est vrai que le C est le dernier qui reste quand on fait une carte à processeur (solutions hard+soft)

ma conclusion :
Pour un developpement PC , à moins de disposer de budgets énormes (que je n'ai jamais vu en France) développer un front office 100% C/C++ me semble quasi impossible. Donc je confie les parties ultra sensibles au C et le reste à C# (dans mon cas) mais ça peut aussi être du C++ managé ce qui revient au même et ne transforme pas complètement le pur mohican en "rat des villes" si tu vois ce que je veux dire.

Vu que je pense comme ça, le C garde ma préférence et C++ devient un peu bancal car quitte à faire de l'objet, j'aime autant profiter des dernières avancées en terme de productivité..

Si je devais un jour (incertain) gérer un projet pharaonique en full C++ (genre mozilla) , je changerais drastiquement mon fusil d'épaule et je serais sans doute, comme toi, plus sévère avec la lenteur de l'évolution du language. J'ai dû laisser un peu de la philosophie en chemin pour des raisons assez business je l'avoue

[ManusDei]

Sinon, j'aimerai bien savoir quelle langage détrone un bon compilateur C++ en terme de perfo (et un mec qui code raisonnablement évidemment).

FORTRAN il me semble.

[bioinfornatics]

Le D très très proche niveaux perf

[bacelar]

Sinon, j'aimerai bien savoir quelle langage détrone un bon compilateur C++ en terme de perfo (et un mec qui code raisonnablement évidemment).

Ce n’est pas un langage mais un développeur qui utilise les bons outils et qui n'a pas deux mains gauches.

[JPLAROCHE]

bin moi rien a reprocher

peut être parce je code comme sur l'AS400

par contre j'ai mis plus de 8 mois à choisir et tester
l ' EDI la bibliothèque le type de base de donnée (simple & complexe) et la Librairie de référence pour le designer pour faire les écrans et édition,
la librairie pour faire du décimal (là peut être une chose qui devrait être implémenté par défaut)

puis bâtir les routines de fond pour accès BD AS400

je pense que le temps est à prendre avant de commencer quoi que ce soi

le C ou C++ peut être très propre rapide et simple

hier on apprenait la méthode AXIAL chez IBM ( 1980 OBJET le tout OBJET pas ++) bien sur pas de ce coté de l'atlantique mais ont y avait accès
et j'ai été formé à cela c'était révolutionnaire ...... 1976

ps( je signal que ADA est de 1980) l' OBJET par excellence


le concurrent AXIAL --> MERISE


aujourd'hui on devrait faire AXIAL et apprendre la théorie des ensembles (raisonner avec) ainsi garder un oeil sur MERISE (cohérence de la base de données)


-----------------------------------------------------------------------
le tout objet avec héritage c'est bien mais c'est comme pas du tout

alors C++ OUI de tout façon il est notre assembleur d'aujourd'hui et notre LG3 si les LIB. sont présentes


@plus de vous lire intéressant les articles.

[Guulh]

On peut bien imaginer qu'un binaire C++ contienne aussi l'équivalent des .h ?

Ce serait catastrophique

Tu imagine le nombre de données inutiles qu'il faudrait placer dans un fichier qui est, en toute logique, destiné uniquement au processeur

Donc c'est bien un choix, lié à des problématiques de performance, pas une conséquence du fait que le code soit natif. Le surcoût en poids des jar et des assemblies (et plus généralement, je suppose, pour les langages avec des API d'introspection) est-il rédhibitoire ?
Dans le binaire ou à côté d'ailleurs, si la taille du fichier est un problème. Comme un header me direz-vous , oui, mais généré tout seul.

Je comprends bien tout ce que tu me dis, mais je trouve cher payé de devoir saisir du code en double (voire en triple ou plus, si comme le dit gorgonite on écrit aussi un .h "d'export" à destination des utilisateurs du binaire) pour de seules problématiques de compilation.

Il y a un tel écart entre C/C++ et Java/C# (je ne parle que de ce que je connais même vaguement, d'où l'association honnie entre C et C++ dans mon raisonnement ) qu'il est difficile de savoir quels aspects découlent d'un choix de design particulier (ce qu'implique l'usage de bytecode, par exemple), et quels autres sont des choix volontaires.

C'est ce que j'ai constaté en travaillant en C++ : quand quelque chose paraît inutilement compliqué pour la tâche à accomplir, difficile de faire le tri entre les aspects nécessaires au code bas niveau, les idiosyncracies du langage, sa quasi-compatibilité avec C, les problématiques de portabilité, de performance, et les délires mystiques de Stroustrup

[Oussapik]

Je ne vois pas l'intérêt d'avoir plusieurs syntaxes pour les pointeurs (celle héritée du C et celle propre au C++ avec "&")

Ce ne sont pas plusieurs syntaxes pour des pointeurs, c'est que ce ne sont pas du tout les mêmes choses. Leur utilité est bien différente. Ou alors, je n'ai pas compris ta remarque.

ni l'intérêt des pointeurs puisque laisser cet accès bas niveau à la mémoire est surtout dangereux d'une part et empêche (ou complique notablement) l'implémentation de certaines optimisations mémoire au niveau du compilateur.

Laisser de l'accès à la mémoire te semble faire perdre la possibilité d'implémenter des optimisations mémoire ? Je pense complètement le contraire. Certains langages ont fait le choix de la mémoire gérée automatiquement. Je pense alors que c'est dans ce cas que l'on perd les possibilité d'optimisation. Les algos d'optimisations des dits-langages sont comme tout, il peuvent comporter des failles. Et c'est là tout l'intérêt de gérer ça à la main, on peut adapter la gestion de la mémoire au contexte.

[Invité]

bin moi rien a reprocher

peut être parce je code comme sur l'AS400

par contre j'ai mis plus de 8 mois à choisir et tester
l ' EDI la bibliothèque le type de base de donnée (simple & complexe) et la Librairie de référence pour le designer pour faire les écrans et édition,
la librairie pour faire du décimal (là peut être une chose qui devrait être implémenté par défaut)

puis bâtir les routines de fond pour accès BD AS400

je pense que le temps est à prendre avant de commencer quoi que ce soi

le C ou C++ peut être très propre rapide et simple

hier on apprenait la méthode AXIAL chez IBM ( 1980 OBJET le tout OBJET pas ++) bien sur pas de ce coté de l'atlantique mais ont y avait accès
et j'ai été formé à cela c'était révolutionnaire ...... 1976

ps( je signal que ADA est de 1980) l' OBJET par excellence


le concurrent AXIAL --> MERISE


aujourd'hui on devrait faire AXIAL et apprendre la théorie des ensembles (raisonner avec) ainsi garder un oeil sur MERISE (cohérence de la base de données)


-----------------------------------------------------------------------
le tout objet avec héritage c'est bien mais c'est comme pas du tout

alors C++ OUI de tout façon il est notre assembleur d'aujourd'hui et notre LG3 si les LIB. sont présentes


@plus de vous lire intéressant les articles.

Salut JP , bienvenue ici, homme avisé et qui a juste l'age qui m'arrange le plus (moi 46)

Je ne comprends pas tout mais pour ce je reconnais, le fait d'avoir un vécu et d'avoir connu l'avant C++ rend philosophe quant à ses limites

Je crois qu'à l'origine de ce topic (passionnant au demeurant), est la complainte d'un gars qui pond du code C++ toute la journée ce qui explique le caractère un peu léger de la question posée.

Celui qui a le choix de l'architecture replace C++ là où il est le plus utile et utilise autre chose pour les tâches récurrentes où la productivité est importante.

Mais on ne peut pas ignorer que les grands éditeurs mondiaux font du full C++ et que dans ce cas, ses limites prennent une toute autre dimension
La façon dont la question est posée pèse sur les réponses

Je crois deviner ce que tu dis concernant merise , je suis bien d'accord même si la jeunesse a usé ses neurones sur le couple java/design patterns. La priorité à merise nous semble évidente puisque elle concerne tous les cas de figure alors que patterns prèche le religion de l'objet au point de perdre le contact avec l'objectif initial : un programme rapide robuste capable de monter en charge.
Je peux me tromper mais, il me semble que merise n'est pas très compatible avec l'héritage multiple qui est un des points les plus controversés de C++ .

D'ailleurs personne ici ne nous a fait le coup du "j'utilise l'héritage multiple tous les jours et c'est génial !"

Bon, la question posée était donc un peu plus légère que certains l'ont laissé entendre.

[pseudocode]

Ce ne sont pas plusieurs syntaxes pour des pointeurs, c'est que ce ne sont pas du tout les mêmes choses. Leur utilité est bien différente. Ou alors, je n'ai pas compris ta remarque.

Vous avez tous les deux raisons et je pense que c'est le problème.

Visiblement il y a une incompréhension entre les personnes qui ont des critiques sur l'utilisation du langage C++, et les personnes qui défendent les solutions techniques proposées par le langage.

Personnellement, je ne remet pas en cause les choix "techniques" qui ont été fait, ni les contraintes qu'ils engendrent. Je m'interroge plutôt sur les raisons "pratiques" qui ont amené a faire ces choix : sont-elles toujours d'actualité, ont-elles évolué, ou disparu.

[Invité]

On parle beaucoup de langage, mais peu de développement.
Il y a eu une petite tentative hier, qui consistait à mettre les choses sur la table (je parle de copies d'écran par exemple) le suggestion n'a pas été relevée.

Par ailleurs, un objet est un ensemble d'éléments divers groupés sous une seule identité, une classe. Si cette affirmation est juste, je voudrais bien qu'on m'explique comment on peut comparer deux objets. Soit ils sont identiques, et donc il y en a un de trop, soit ils des caractères communs, ou semblables ou pareils, alors on pourra écrire des fonctions comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
class Quelconque
{
  ...
  float Longueur();
  float Aire();
  bool IsMemeLongueur(Quelconque &c); 
  bool IsMemeAire(Quelconque &c);
};

Mais que pourrait-il y avoir dans un code de surcharge de l'opérateur == ?
Remarque : ceci n'est pas un exemple comme dans ma précédente question.
Il s'agit tout de même de la même question, mais pas la peine de répondre sur l'exemple.
Quel est l'opérateur que l'on peut surcharger pour tester un parallélisme de deux vecteurs?

[Invité]

Concernant les perfs, il n'y a pas 36 chemins. Il est impossible de dépasser la performance d'une routine en assembleur bien faite et optimisée.
C a été appelé "l'assembleur procédural" à une époque. Des éditeurs comme Borland avaient ajouté des librairies assembleur et communiquaient beaucoup là dessus.
D'autres approches que le C sont convaincantes mais elles passent toutes par une utilisation encore plus directe de l'assembleur (je pense à PureBasic)

Maintenant il est parfaitement ridicule de gagner un cycle machine par seconde sur un pc de bureau et c'est là que commence le malentendu.
Car il est très important de gagner un cycle CPU sur le déroulement d'une boucle infinie dans un programme qu'on instancie 200 fois sur un serveur de data center qui en contient 2000 !

Cette priorité à l'optimisation utile (profiling) est une affaire de design et requiert une connaissance du métier, du marché et même une culture générale. Tous les languages se disent rapides (sauf le Shell script ) mais quand il s'agit de limiter la consommation électrique du processeur , la selection devient plus dure (cf : Apple ipad)

L'embarqué a remis cette question de perf au goût du jour alors que plus personne n'en parlait depuis la sortie des dual core

Ceux qui comme moi , ont beaucoup travaillé sur les perfs (straight coding, calculs en matrice, latence telecom, ...) reconnaissent assez vite leurs pairs ! Même si l'industrie a dépensé bien plus à optimiser javascript que les programmes de M tout-le-monde. C est la seule approche raisonnable en la matière. Ne me parlez pas d'objet alors que même le procédural est optimisable. Chaque récursion est couteuse et le fait que le monde entier ait opté pour le C/C++ est quand même plus parlant que les prétentions de tel ou tel éditeur.

Ceci dit il est aussi ridicule d'optimiser le déroulement d'un language qui se chiffre en µsecondes si on fait des accès disques sans arrèt ou qu'une tâche concurrent le fait.

9 fois sur 10 l'optimisation ultime consiste à grouper les tâches autour d'une zone cpu+cache(register) / RAM / disque / réseau

[bacelar]

Par ailleurs, un objet est un ensemble d'éléments divers groupés sous une seule identité, une classe

Bin non.
On peut avoir les mêmes données mais avec des méhodes complétement différentes qui implémente les mêmes interfaces.

Le cas pathologique de la sémantique "==" est la comparaison de chaine de caractère.
"==" donne vrai si c'est le même pointeur ou que le contenu est le même (sans compter les problèmes d'encodage, de culture, de case sensitivité etc..).
C# a réglé le problème par un choix qui est au niveau de l'implémenteur de la classe.

Vous n'imaginez pas la complexité de l'implémentation de la class string de C# pour avoir une sémantique de comparaison qui correspond au contenu tout en ayant de très bonne performance.
Je dis ça, car j'ai l'impression que les C++ puristes ont tendance à prendre les autres pour des nains de jardins.

[guillaume07]

Quand je vois "void*" dans un code en C++, je commence à m'inquièter sérieusement à la base.

Pourquoi ? quel est le problème avec les void* ?

[bacelar]

Pour les performances, je pense que là on a un choc de culture.
Les C++ puristes pensent qu'ils peuvent toujours faire mieux qu'une implémentation standard (du GC par exemple).
Moi, je suis bien plus circonspect. Je teste le GC et s'il ne me convient pas je le customise. En C++, mais aussi en C#, car vous ne devez pas prendre les fonctionnalités .NET pour une boite fermé. Vous pouvez plus ou moins facilement tout customiser.
Cela permet de dégager bien plus de temps pour l'algorithmie, les optimisations adaptatives ou encore prendre en compte les besoins clients fluctuants.

[bacelar]

Pourquoi ? quel est le problème avec les void* ?

C'est juste tyleless, c'est juste encore plus dangereux et immaintenable que du typage dynamique.

[bacelar]

9 fois sur 10 l'optimisation ultime consiste à grouper les tâches autour d'une zone cpu+cache(register) / RAM / disque / réseau

Avec des GPGPU, SMP, multi-core etc... cela devient un peu plus complexe, donc n'ayez pas peur d'utiliser l'expériences des implémenteurs de Framework et autres VM.

[Invité]

Pour les performances, je pense que là on a un choc de culture.
Les C++ puristes pensent qu'ils peuvent toujours faire mieux qu'une implémentation standard (du GC par exemple).
Moi, je suis bien plus circonspect. Je teste le GC et s'il ne me convient pas je le customise. En C++, mais aussi en C#, car vous ne devez pas prendre les fonctionnalités .NET pour une boite fermé. Vous pouvez plus ou moins facilement tout customiser.
Cela permet de dégager bien plus de temps pour l'algorithmie, les optimisations adaptatives ou encore prendre en compte les besoins clients fluctuants.

J'ai écrit mon msg en même temps que le vôtre. Comme j'y parle de cas extrèmes en embraqué alors que je fais du c# toute la journée, je veux juste préciser :
Certes la GC n'est pas en soi une optimisation de perf mais plutôt une aide à la programmation (merci basic !) Cela dit, vu le temps que ça fait gagner au developpeur, il est très utile de la gérer ou d'en tenir compte. Comme le collector de C# utilise Marshal pour parcourir tous les symboles en séquence et que je n'ai jamais trouvé de moyen de grouper les zones de mémoire en C#, il reste surtout à faire les Dispose(); avec astuce pour EMPECHER le collector de se lancer trop souvent..

Noter que j'adore ce langage, même si je peste sans cesse sur le peu de contrôle qu'on a sur l'agencement du segment de données et de la pile (qui est énorme sous .net)