n’importe quoi. pour vous un compilateur prend moins de temps à interpréter des structures complexes, des objets de class, qu’une séquence d’instructions.
Un compilateur n’interprète pas.
n’importe quoi. pour vous un compilateur prend moins de temps à interpréter des structures complexes, des objets de class, qu’une séquence d’instructions.
Pas grand monde n’est intéressé de gagner quelques millièmes de secondes (voire une poignée) à la compilation si le code à l’exécution est tout aussi rapide et que le temps de maintenance (et d’écriture du code initial) est grandement réduit.
C’est le job des compilateurs que de prendre du temps pour optimiser le programme, mieux que ne le ferait un humain. Le code informatique doit surtout être rapide à lire et à écrire par des humains, et sur ce point le C reste assez déficient.
Peu importe que le compilateur prenne 2 % (ou même 20 %) de temps en plus pour compiler un programme si
Un compilateur n’interprète pas.
(En fait dans le cas de constexpr en C++, si, mais bon je trouve que ça tombe à point nommé quand même).
cette discussion ne nous mènera à rien. de toute évidence, nous ne serons jamais d’accord
En même temps, tu ne réponds à aucun des arguments qui te sont opposés. Je cite un message de la page précédente et t’invite à y répondre.
Les classes ne coûtent absolument rien en l’absence de virtual (@tutorials x : et si tu veux contredire ce point, pose un exemple clair avec son équivalent en C et la raison pour laquelle la version est plus rapide)
Parce que si le C++ (ou le Rust) produisent bien des programmes aussi performant que le C avec un code plus sûr et plus simple, tous tes arguments tombent à l’eau.
Ah bah non c’est sûr que la majorité des gens ne peuvent pas être d’accord avec des assertions sorties du chapeau et qui sont connues pour être complètement fausses.
Bon sinon l’avis de Dan Saks qui est un expert reconnu dans le domaine de l’embarqué qui maîtrise à la fois C et C++ : http://www.dansaks.com/talks/ESC-205.pdf . Tu peux t’intéresser à la page 52 à 54 (slide 104 à 108), ça résume les fausses informations que tu cites depuis le début et pourquoi elles sont fausses.
cette discussion ne nous mènera à rien. de toute évidence, nous ne serons jamais d’accord
Comme dirait l’autre on peut tous avoir un avis mais on a les mêmes faits. Et tes messages sont farcis d’erreurs.
La réponse complète ayant été donnée par Geo au premier message, et l’auteur refusant de remettre en cause ses croyances, pourquoi ne pas en rester la et fermer ce sujet ?
Allez, hop.
Je vois bien qu’il y a eu un débat, mais je constate cependant que la réponse
qui a été apportée à l’auteur du sujet est incomplète, malgré l’apparente
expérience de certains protagonistes… en effet, par défaut, même avec
l’option -std=c90, le compilateur C de GNU active les extensions GNU,
et n’est donc pas strictement en conformité avec le standard.
Par exemple, le standard interdit l’arithmétique de pointeurs universels
(void*), et l’utilisation de variable-length arrays (apparus en C99), alors
que par défaut, GCC les active en C90.
On a alors deux possibilités :
-Wpedantic pour profiter de ces extensions tout
en sachant quoi modifier pour rendre le programme portable/cachant
l’utilisation de ces extensions derrière des macros (de préprocesseur,
j’aime pas les poissons) ;-pedantic.Il est possible de savoir si les extensions sont désactivées ou non par la
présence de la macro __STRICT_ANSI__ (même si ça marche de façon assez
bizarre avec -std=gnu89 par exemple, donc je déconseille l’utilisation
des "standards" dont le nom commence par "gnu").
Merci à Taurre d’avoir réouvert le sujet pour que je puisse mettre cette réponse ! 
Je reposte ici mon message pour ne pas polluer l’autre sujet.
La meilleure performance du C par rapport au C++ n’est même pas un mythe, c’est juste fondamentalement faux et se base sur une idée reçue de ta part que le confort d’utilisation côté programmeur est forcément lié à de mauvaises performances côté exécution. Ce n’est pas le cas : un code C++ orienté objet peut (et doit) être compilé vers le même code machine que du code C impératif.
Si tu veux apprendre pourquoi tu te trompe totalement sur ce sujet, et d’autres, on peut discuter, mais pour ça il faut un minimum d’ouverture d’esprit.
mais pas de problème. seulement, je propose de le faire dans un autre sujet, ce lui ci est déjà dans les classable et marqué comme résolu. je vous laisse donc le soin de le créer
Si on se tenait stricto sensu à la question initiale, de nombreux sujets du forum perdraient de leur intérêt. Comme la question original est résolue, vous pouvez partir en pseudo-HS (pseudo, car ça reste lié), sans aucun problème. 
C’est courant que le sujet dérive une fois le problème initial résolu, et ça fait parti de la richesse du site : le posteur originel en apprend plus encore que le strict cadre de sa question.
mais pas de problème. seulement, je propose de le faire dans un autre sujet, ce lui ci est déjà dans les classable et marqué comme résolu. je vous laisse donc le soin de le créer
Puisque c’est accepté, pourquoi ne pas me répondre ici ? Au moins, on serait sûrs que tu n’es pas juste ici pour nous faire perdre notre temps.
Un talk intéressant de Jason Turner à la CppCon sur le coût des abstractions (enfin, le non-coût, plutôt).
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
