Reprise du message précédent :
le gros probleme c'est que beaucoup ne savent pas programmer en objet, s'ils font du C++, c'est en fait du C encapsule dans une classe... Passer du C++ au C est difficile, passer du C au C++ est difficile egalement. Ces deux languages sont differents, et la presence de la lettre C dans les deux est malvenue. On peut tout faire dans les deux langages, on a tous nos preferences, nos affinites. Dire le C c'est mieux c'est plus rapide est aussi stupide a mon gout que de dire "C++ ou pas de salut". Si tu veux programmer objet, commence par le C++, sinon fait du C. La discussion devrait s'arreter la je pense.

C'est quoi ce vieux post !!
 
(les inlines, c'est pas que du C++, c'est aussi du C99)

 
ben les deux langages utilisent le meme concept, mais ca reste quand meme deux langages differents. Il y a des variables en Perl et en C, ce sont tout de meme deux langages differents mais qui utilisent le concept de variable. non ?

De toute façon, la vrai puissance du C++ viens de la combinaison "template+inline".

c'est un peu réducteur quand-même!
dans beaucoup de cas l'intérêt du C++ c'est de faire des objets qui facilitent le travail d'équipe: chacun son code et il est facile d'utiliser un objet fait par un autre, objet qui est protégé contre toute utilisation incorrecte. C'est énorme comme avantage.
 
Et puis le inline j'y vois pas tellement de rapport avec le C++.
 

 
Je rappelle que le C++ ne fait qu'apporter des possibilités supplémentaires par rapport au C, sans rien lui enlever.

 
C'est simple, la seule chose qui permet vraiment au C++ de se démarquer par rapport à d'autres langages objets ( le Delphi me viens en tête comme ça ), c'est la combo templates+inline qui permet de faire du code de super haut niveau avec des perfs qui font rougir le C.
 
Pour cette histoire de perf, c'est pas difficile. Il suffit de comparer un tri en C++ avec la STL contre le même tri en C.

en C si tu programmes toi-même tu fais exactement ce que tu veux. Alors je vois pas comment faire une comparaison, ça dépend totalement de la manière dont tu programmes ton tri.
Quand à ce qui distingue le C++ d'autres langages objets, tu oublies beaucoup de choses importantes dont principalement la compatibilité ascendante avec le C.
A la base on comparait le C et le C++, pas le C++ avec les autres langages objet.

Pour le tri c'est facile, la seule chose qui permet au C d'atteindre les perfs de tri en C++, c'est de coder une fonction de tri pour chaque fonction de comparaison. En effet, utiliser une fonction de tri générique en C qui reçoit un pointeur de fonction vers l'operateur de comparaison, c'est très couteux. En C++, template+inline et tout ça c'est fait automatiquement.

y'a tellement d'algo de tri possibles, et enore + de manières de les programmer que cette discussion n'a aucun sens.
De + coder une fonction de tri par fonction de comparaison c'est le meilleur moyen de se retrouver avec du code qui rentre pas dans le cache du cpu. Mais pour maitriser ça il faut pas aller trop loin dans les possibilités d'abstraction du langage. Bien-sûr ça dépend du nombre de fonctions mais en C on peut au moins se faire une idée du code asm qu'il y a derrière.
Et puis en C++ on peut très bien recompiler le même programme qu'en C et il fera la même chose. On peut aussi écrire le même d'une manière différente, qui donnera à peu près la même chose après la précompilation.
alors inutile de parler de la vitesse d'exécution d'un programme en C ou en C++, y'a aucune généralité là-dessus.

De toute façon, comme je le disais plus haut, le problème de perfs est un faux problème : dans 95 % des cas, une appli est lente parce que son architecture est mauvaise, ou que les algorithmes choisis sont inappropriés, pas parce que le langage est soi-disant lent.

Mouahaha ! c'est trop amusant de vous voir disputer ce sujet, c'est même parfois plutôt aggaçant tellement il y a de préjugés,
 
Selon ma modeste expérience , le meilleur chemin, qui est forcément le plus long, c'est de commencer par connaître l'électronique analogique, l'électronique numérique, la programmation en assembleur, la prommation en C, le c++ et puis éventuellement d'autres langages utilisant des couches plus hautes encore.
 
A ce stade on peux prétendre savoir programmer avec des langages de haut niveaux et de façon optimisée, parce qu'à chaque ligne de code voir chaque mot, on penses en même temps à tout ce qu'il se passe dans les couches basses jusqu'au fonctionnement même de l'électronique. Bref, c'est une toute autre façon de programmmer que pour ceux qui ce sont directement précipité sur le c++.
 
Il est donc évident que plus on utilise un langage de couche basse, plus les performances seront élevées, forte rigueur indispensable, et plus on va vers les langages structurés, plus on sera efficace sur le temps nécessaire à mettre en place une application complexe.
 
Je pense ( mdr ! je pense ) qu'il est ainsi nécessaire de connaîtres plusieurs langages de niveaux différents selon chaque type d'applications à développer.
 
 
Quel topic explosif ne trouvez-vous pas !!!?

D'accord avec nonokao.
Ça peut être intéressant de faire du C avant C++ pour voir explicitement les mécanismes de base.
Mais il ne faut pas s'embêter à le pousser trop loin: C++ résoud bien des défauts de C.
 
Pour la forme, deux sujets:
[C, C++] Pourquoi rester en C au lieu d'utiliser C++ ?
[C, C++] Le C et le C de C++ doivent-ils rester compatibles ?
 
 
 
inline existe en C99, mais n'est pas aussi puissant: injection obligée, pas de variable statique. Récursion ?
 
inline est très important en C++, car la modularisation d'un programmme en patrons et objets génère plein de petites fonctions triviales, et en empiles plein d'appels.
Si leur appel ne pouvait pas être court-circuité par le compilateur, la pénalité de performance serait conséquente.

 
Hmm non c'est trop gros la c'est un troll..
 
LeGreg

Mais au coucher du soleil les trolls se changent en pierre !
 
(désolé !)

Toutes les études montrent que pour un programmeur donné, le nombre de bugs introduits par unité de nombre de lignes de code (généralement 1000) est globalement constant, ou au moins du même ordre de grandeur. Qu'il programme en assembleur ou dans un langage de très haut-niveau.
L'explication des neuropsychologues est que le nombre d'entités que doit manipuler le cerveau pour écrire des lignes de programmation est à tout instant plus important que le nombre d'entités que la mémoire à court terme ne peut en emmagasiner.
 
Les nombreuses études montrent également que les programmeurs qui introduisent le moins de bugs dans leurs programmes sont ceux qui réussissent le mieux à réduire le nombre d'informations qu'ils doivent manipuler à un instant donné. Et comme par hasard, ce sont ceux qui, précisément, ne pensent pas à l'optimisation de leur code source au moment où ils l'écrivent (ça fait d'autant moins d'informations auxquelles il faut penser).
 
Je ne dis pas qu'il ne faille pas penser à obtenir un code efficace (vous remarquerez, je n'ai pas dit "optimisé" ), mais le principal moment où il ne vaut mieux pas trop y penser est précisément le moment où on rédige son code. Avant, c'est le moment (choisir une architecture et des algorithmes appropriés), et après, une fois que le programme fonctionne, c'est encore le moment (en passant le tout à la moulinette du profileur pour trouver les goulets d'étranglement). Mais y penser pendant l'écriture du code, c'est le meilleur moyen d'écrire un programme qui ne marche pas, et sur lequel on va devoir ensuite passer des soirées entières à déboguer avec stress et fébrilité, et des journées entières en maintenance corrective alors que le logiciel est déjà en production.

 
 
héhé ! ouep, ça me rappelle des souvenirs, mais avec le temps, on apprends à structurer ses prog et effectivement comme tu le dis, passer ensuite la moulinette