Le C++ serait-il vraiment victime de son passé ?

Citation:

---

Envoyé par leternel

Dans ce débat inclusion/import, je me demande comment font d'autres langage intégralement compilés (dans ni Java, ni C#, ni python...)
Il faut bien au cours de la compilation associer des morceaux de codes séparés.

Cela sous-entend d'avoir un moyen d'écrire dans un morceau de code "ceci existe, et c'est là bas", tout en limitant la taille du code.
Jusque-là, on a des symboles externes (toutes les déclarations de fonctions, et les variables extern), qu'il faut déclarer manuellement dans l'unité de compilation pour pouvoir les utiliser.
Pour avoir des modules utilisables, il faudra quelque chose d'assez subtile/tordu pour ne pas changer l'aspect du code.
La force du C++, c'est que (quasiment) toutes les erreurs de code sont connues à la compilation, et garder cela avec les modules est difficile.
C'est d'ailleurs pour ca que ca prend du temps.
Ca et le fait de ne pas devoir briser les codes existant (même les récents)

---

Je te répond ici même si ce n'est pas vraiment la bonne discussion.

En réalité, toi tu vois les difficultés techniques pour réaliser les choses, mais ce ne sont pas les difficultés qui bloquent le comité de normalisation (tout simplement car il ne s'occupe pas des détails techniques, ils spécifient juste le comportement des modules). La question du "moyen de dire ceci existe et est là-bas" n'entre pas en jeu pour l'introduction dans la norme des modules.

Les questions traités dans les documents relatifs au module sont plutôt sur la syntaxe à adopter pour les nouvelles fonctionnalités, les comportements vis-à-vis des résolutions de noms (étant donné qu'un module indique ce qu'il exporte, on est plus dans une logique de copier/coller ou tout les éléments sont nécessairement pris en compte pour la résolution), le respect de l'ODR (idéalement le système va rendre ce respect plus simple à accomplir), la position des points d'instanciation pour les template et les dépendances cycliques.

Techniquement, clang avait proposé une implémentation pour une proposition de module antérieur. L'idée est la suivante, lorsqu'une unité de compilation est traitée, elle généré un/des fichiers contenant les symboles exportés par l'unité de compilation (schématiquement il y a génération d'un fichier similaire aux headers qu'on écrit aujourd'hui). Ce n'est donc pas si tordu que ça et la compatibilité avec le système actuel est conservé (il y a toujours application du pré-processeur) et aucun impact sur les erreurs détectées ou non à la compilation.

Les codeurs C sont plus rigoureux à cause du domaine où on cantonne les développeurs C et ce n'est clairement pas le langage lui-même qui implique la rigueur et de très loin.
Le "void*" du C est une vaste blague.

Citation:

---

Envoyé par leternel

Dans ce débat inclusion/import, je me demande comment font d'autres langage intégralement compilés (dans ni Java, ni C#, ni python...)
Il faut bien au cours de la compilation associer des morceaux de codes séparés.

Cela sous-entend d'avoir un moyen d'écrire dans un morceau de code "ceci existe, et c'est là bas", tout en limitant la taille du code.
Jusque-là, on a des symboles externes (toutes les déclarations de fonctions, et les variables extern), qu'il faut déclarer manuellement dans l'unité de compilation pour pouvoir les utiliser.
Pour avoir des modules utilisables, il faudra quelque chose d'assez subtile/tordu pour ne pas changer l'aspect du code.
La force du C++, c'est que (quasiment) toutes les erreurs de code sont connues à la compilation, et garder cela avec les modules est difficile.
C'est d'ailleurs pour ca que ca prend du temps.
Ca et le fait de ne pas devoir briser les codes existant (même les récents)

---

Va voir comment on fait dans Modula-2, Oberon ou même TurboPascal. Ici on ne parle pas du problème de l'inclusion, mais du mécanisme utilisé. i.e. l'inclusion d'un module (ou d'une unité dans pascal/modula2) se fait toujours de la même manière dans tous les langages statiques ou dynamiques (python et autre). Le problème survient quand un module inclus lui même d'autres modules,... dans ce cas là, il est facile d'avoir les références circulaires, i.e. les modules inclus en arrivent à inclure un module qui lui même a besoin d'inclure le module parent. A -> B -> C ->A
La gestion (et l'évitement) de ce genre d'inclusions est actuellement fait avec des IFDEF en début de chaque header dans le C/C++. En modula2 (Oberon) il y a une gestion plus intelligente des modules lors de la compilation (voir la doc sur le site de Wirth).
Actuellement, Apple (groupe de travail chez Apple apparement) qui a soumis une étude d'utilisation du système de modules au lieux des header files aux instances de certification du C++ http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf

Citation:

---

Envoyé par leternel

@Epok__
Pour le malloc!=new, il y a une manière de voire les choses: T * var = new T(...); équivaut à peu près à T * var = malloc(sizeof T);*var=T(...);.
C'est à la fois l'allocation et l'initialisation de la mémoire. Un petit peu comme un calloc, mais en mieux, beaucoup mieux.
Il s'agit de respecter une règle simple "toute chose est construite ou n'est pas du tout".
Une valeur n'est ainsi pas allouée mais inconstruite.

C'est aussi pour cela qu'on ne doit pas coder une classe avec une fonction init() que l'utilisateur doit appeler. (hors le builder...)

---

Le problème au niveau de l'allocation dynamique en C++ ne se limite pas à l'aspect simplissime des duos new/delete. Il suffit de les jumeler. Le problème provient des subtilités du C++ lors de la création automatique objets (lors des appels et le retour de fonctions, lors de certaines formes d'initialisation, ...). Aussi les problèmes peuvent survenir dans pleins de cas très subtils lors de la création automatique des constructeurs de recopie, de l'opérateur "=" non overloader, ... bref pleins de cas (faudra lire les livres Effective C++ et More Effective C++ de Scott Mayer).

Pour le moi le new/delete n'est pas l'inconvénient du C++ mais l'avantage. Les smart pointer, c'est très bien mais pas optimal, or l'intérêt du C++ c'est la rapidité et l'efficacité du code produit. Certains d'ailleurs refusent d'utiliser le C++ et préfèrent le C pour le fait que le C interdit d'utiliser les facilités. C'est la seul raison pour laquelle le C/C++ n'est pas mort.

Si vous n'utilisez que des smart pointer et des options très avancé, c'est que vous n'avez rien a faire en C++, utilisez plutôt du Java, vous risquerez moins de faire planter la machine. Tout l'intérêt du C++11 c'est de permettre l'utilisation de fonctions haut niveau pour les parties les moins critique et de garder l'utilisation de fonction très efficace (ancienne) et précise pour les parties critique.

Vous avez le même principe dans tous langages. Quand vous développez les couches haute de l'application ou une version de démonstration, alors vous cherchez la productivité. Mais pour les parties critique, vous devrez optimiser votre code. C'est vrai que vous soyez en C/C++ ou en Java, PHP, Python et même bash ou en utilisation de logiciel.
Quel informaticien ne double click sur un fichier pour l'ouvrir (Avec Eclipse ou OpenOffice) dans 90% des cas mais dans certains cas (c'est un gros fichier ou jeter un coup d'oeil rapide) ouvre le fichier avec Gedit (Notepad++) ou même vi/emacs pour éviter de le copier en local?

abriotde, ton commentaire est en total contradiction avec le concept de fossé sémantique de Seymour Cray.
C'est le genre d'argumentaire que j'écoutais dans ma prime jeunesse entre l'assembleur et le C.
Un bon programmeur choisi le langage le plus facile et maintenable permettant d'arriver aux objectifs, un point c'est tout.
Et le TimeToMarket explose quasiment systématiquement les performances (si ça rame, on prend une machine plus grande).

Citation:

---

Envoyé par sizvix

c'est, je trouve, une contrainte plutôt positive de faire un plan et de le suivre, et ça permet d'avoir un résumé clair de la classe, même si les IDE actuels permette d'afficher de tel prototypes facilement avec des classes dans d'autres langages.

---

Je suis d'accord avec ça, j'aime avoir un plan clair de ma classe. Mais je pense juste que c'est le genre de tâche automatisable très facilement.
C'est une tâche extrêmement automatique, que de faire la liste des fonctions.

En général, j'écris le prototype dans le header, et je génère automatiquement le corps avec l'IDE.

Mais autant quand je développe en C (très bas niveau en général, parfois sans OS) je comprend la nécessité du header : j'en fais parfois plusieurs pour une même librairie, un public et un privé par exemple.
Mais en C++, où la notion de public et privé est explicite, on écrit toujours le header de la même manière, strucutré, etc. D'où, automatisable.

Je pense juste que là dessus, la norme pourrait prévoir un outil pour réaliser cette tâche, tout en laissant la possibilité bien sûr de le faire manuellement.
Par exemple, rechercher dans la liste des fichiers compilés si la classe existe pour en extraire les infos nécessaires si aucun header n'est spécifié pour la classe.
Les meta-infos de type static, private, etc. devraient bien sûr alors être répétées dans le .cpp.
Mais cela pourrait au moins faciliter la tâche pour les classes au sein d'une même librairie.

Je rêve peut-être, mais n'est-ce pas le sujet de l'article ? ;)

Citation:

---

Envoyé par Guikingone

J'ai toujours considérer le C++ comme une alternative au C, en moins bien cependant, le C reste à mes yeux un modèle, il est touffu, complexe et déroutant mais il forme des dévs de qualité qui savent mettre les mains dans la sauce sans rechigner et qui savent gérer un language strict.

Le C++ n'est pas mauvais en soi, disons qu'il différe du C en une version moins directe et moins "lisible" à mes yeux, mais là encore, chacun y verra midi à sa porte.

---

J'ai, au début, considéré le C++ comme une extension du C.

Moi qui venait du C, bas niveau, strict, avec une gestion de la mémoire au plus proche, j'ai au début été très dérouté.
Ma première approche du C++ a été d'y voir un artifice d'« enrobage » du C dans une couche haut niveau. Du C pour les flemmards, presque ^^.

Mais après un usage un peu plus poussé maintenant, je ne vois en fait aucune similitude entre ces deux langages.
Une même syntaxe, bien sûr. Une compatibilité, effectivement.
Mais un style, une manière de raisonner qui se situaient sur des niveaux tellement différents qu'il est impossible de les comparer.

Pour moi, le C et le C++ sont deux langages totalement différents, et cela s'accentue je trouve avec les dernières révisions du C++, pour le meilleur.

Mais je crois qu'il est possible d'enrichir le C++, par exemple comme expliqué ci-dessus, sans pour autant casser la compatibilité. Et donc contenter à la fois les devs haut niveau comme ceux plus proches du matériel.

Bonjour.

Il y a une tendance visible à vouloir faire du C++, un CSharp like ou un Java like. Je pense que c'est problématique, car le C++ ne pourra jamais proposer des Frameworks aussi puissants, notamment au niveau IHM. Boost est sur la bonne voie, mais sans IHM gratuite/standard/portable, je ne vois pas l'intérêt de s'aligner sur les L4G.

abriotde a bien résumer la situation. La force du C++, c'est son passé.

Les smart pointeurs et autre garbage collector ont des failles, et ne maîtrisent rien du tout sur la gestion de l'allocation mémoire. Il vaut mieux un pointeur nu qui te pète à la tronche, le débuggeur te diras très vite où cela se trouve, plutôt que de passer des semaines avec des outils "one again" pour dépister la fuite.

En ce qui concerne l'inclusion de fichiers, Microsoft à résolu le problème depuis belle lurette. Cela s'appelle les en-têtes précompilés....

Citation:

---

Envoyé par abriotde

Pour le moi le new/delete n'est pas l'inconvénient du C++ mais l'avantage. Les smart pointer, c'est très bien mais pas optimal, or l'intérêt du C++ c'est la rapidité et l'efficacité du code produit.

---

Les smart pointers sont tout à fait utilisables dans un contexte où les performances comptent.

Citation:

---

Envoyé par abriotde

Certains d'ailleurs refusent d'utiliser le C++ et préfèrent le C pour le fait que le C interdit d'utiliser les facilités. C'est la seul raison pour laquelle le C/C++ n'est pas mort.

---

Et ce faisant, ils ont du code avec plus de bugs et moins de performances... J'en veux pour exemple la bibliothèque standard du C (donc quand même un truc éprouvé et sur lequel pas mal de personnes sont passées pour la corriger/l'optimiser). Il y a peu, Microsoft a réimplémenté la sienne en C++ et sans se restreindre sur les fonctionnalités du langage. Ils ont corrigé ce faisant quelques bugs/fuites mémoire, et amélioré les performances !

Le C++ n'a pas de problème.
Par contre le plus gros problème de CoderGears c'est CoderGears :mouarf:

Citation:

---

Envoyé par bacelar

Les codeurs C sont plus rigoureux à cause du domaine où on cantonne les développeurs C et ce n'est clairement pas le langage lui-même qui implique la rigueur et de très loin.
Le "void*" du C est une vaste blague.

---

Personnellement je trouve ca carrement magique quand je veux m'amuser a faire des trucs un peu "limite" et carrement degueux mais tellement fun. :D

Pour en revenir au sujet, le plus gros probleme du C++ est clairement son passe. Ajouter une nouvelle fonctionnalite ne peut se faire au detriment d'une ancienne pas trop vieille au risque de peter tous les codes qui en dependent. Il suffit de voir combien de temps il a fallu avant que le mot auto ne soit reutilise alors que je ne connais personne qui se servait de "l'original". Probleme epineux donc. Mon point de vue sur la question serait de creer une seconde branche du C++ qui ferait du breaking-change pour enfin resoudre tous les aspects les plus decries du C++ mais encore une fois, est-ce que ca sera toujours considere comme du C++ ?

Citation:

---

Envoyé par imperio

Personnellement je trouve ca carrement magique quand je veux m'amuser a faire des trucs un peu "limite" et carrement degueux mais tellement fun. :D

Pour en revenir au sujet, le plus gros probleme du C++ est clairement son passe. Ajouter une nouvelle fonctionnalite ne peut se faire au detriment d'une ancienne pas trop vieille au risque de peter tous les codes qui en dependent. Il suffit de voir combien de temps il a fallu avant que le mot auto ne soit reutilise alors que je ne connais personne qui se servait de "l'original". Probleme epineux donc. Mon point de vue sur la question serait de creer une seconde branche du C++ qui ferait du breaking-change pour enfin resoudre tous les aspects les plus decries du C++ mais encore une fois, est-ce que ca sera toujours considere comme du C++ ?

---

J'ai du mal à suivre ta logique. La norme C++11 a mis du temps à sortir, mais ce n'est pas lié spécifiquement au mot clé auto. Ce mot clé a été déprécié au même titre que export : personne ne s'en servait. Si ce mot-clé avait servi, le comité aurait eu à prendre la décision de prendre le même mot-clé pour l'inférence ou d'en choisir un autre.

Je ne parlais pas specialement de la norme C++11 a vrai dire. Je voulais juste pointer du doigt le temps qu'il a fallu pour que le mot auto soit reutilise alors qu'il n'etait deja plus utilise depuis un temps certain.

Citation:

---

Envoyé par imperio

Je ne parlais pas specialement de la norme C++11 a vrai dire. Je voulais juste pointer du doigt le temps qu'il a fallu pour que le mot auto soit reutilise alors qu'il n'etait deja plus utilise depuis un temps certain.

---

Si je me trompe pas, l'idée d'utiliser auto pour l'inférence a été introduite dès les premiers papiers proposant l'inférence en C++ (en 2003 d'après les archives). Du coup j'ai vraiment du mal à voir de quoi tu parles, tu aurais voulu qu'il soit réutiliser avant pour en faire quoi ?

Qu'importe, ce mot-cle aurait pu etre utilise pour autre chose. Je voulais juste dire par la qu'il existait mais qu'il n'etait plus utilise et qu'il a fallu attendre un long moment pour changer son utilite. Il aurait pu etre supprime entre-temps mais ca n'a pas ete le cas. Encore une fois, ce n'etait qu'a titre d'exemple.

J'ai moi même plusieurs fois tenté d'apprendre le C++ , après avoir développé en Fortran, en Java et en Php (excusez moi).
Le fait de me retrouver avec les contraintes du C (que j'avais appris par ailleurs sans pratiqué) m'a un peu dégouté d'aller plus loin.
Tant pis

Citation:

---

Envoyé par a028762

Le fait de me retrouver avec les contraintes du C (que j'avais appris par ailleurs sans pratiqué) m'a un peu dégouté d'aller plus loin.

---

Lesquelles ?

Salut,

Citation:

---

Envoyé par imperio

Qu'importe, ce mot-cle aurait pu etre utilise pour autre chose. Je voulais juste dire par la qu'il existait mais qu'il n'etait plus utilise et qu'il a fallu attendre un long moment pour changer son utilite. Il aurait pu etre supprime entre-temps mais ca n'a pas ete le cas. Encore une fois, ce n'etait qu'a titre d'exemple.

---

Je crois que tu mélange en réalité les causes et les effets...

Il y a en effet deux points à prendre en compte :
D'un coté, tu as le mot clé auto, avec

• la cause : Le mot clé auto faisait partie des premiers standard, mais un seul compilateur proposait le support de cette possibilité .
• L'effet : la norme a décidé de déprécier le mot clé dans son acception première (car comme il y a malgré tout un compilateur qui supportait ce mot clé, on ne peut exclure le fait qu'il existe une base de code qui l'utilise :D)

Et de l'autre, tu as le temps qu'il a fallu entre les premières discussions relatives à "une nouvelle norme" et sa finalisation...

• Cause 1 : les technologies, les défis auxquels doivent faire face les différents langages ont littéralement explosé depuis le début du millénaire (rappelez-vous de ce à quoi ressemblait un gsm en 1997 et de ce que peut faire un smartphone actuel ;) )...
• L'effet de la cause 1 : énormément de propositions ont été faites pendant une très grande partie du processus
• Cause 2 : certaines "guerres de religion"
• l'effet de la cause 2 : difficulté à trouver certains concensus
• Cause 3 : Les propositions sont sensées arriver avec une "proof of concept" afin de voir si c'est réalisable et utilisable... Boost a énormément aidé sur ce point, mais il a aussi fallu attendre certaines POC pour pouvoir avancer :aie:
• L'effet cumulé : La sortie de C++11 a été repoussée à de très nombreuses occasions (quand il s'appelait encore C++0x, on a même joué sur le fait que 0x était le symbole d'une écriture hexadécimale pour dire que "l'on n'est pas si en retard que cela, vu qu'on a jusqu'en 2016 :D") et pour énormément de raisons. A tel point que, pour arriver à sortir la norme, il a été décidé de supprimer purement et simplement les discussions sur de nombreux ajouts /modifications à la norme ;)

Alors, bien sur, il a fallu attendre la sortie de la norme pour que l'usage originellement prévu du mot clé auto soit officiellement déprécié. Mais cela n'a (j'espère en tout cas) pas empêché les développeurs qui l'utilisaient de prendre les mesures nécessaires dés qu'il est devenu à peu près évident qu'il serait déprécié ;)

En deux mots : la norme a mis longtemps à sortir, mais pas forcément à cause d'une fonctionnalité particulière (et surement pas à cause de la dépréciation du mot clé auto). Si elle a pris énormément de temps, c'est parce qu'il a fallu mettre des petites gouttes d'huile à de très nombreux endroits, et que ca a pris un temps fou ;)

Citation:

---

Envoyé par koala01

Le mot clé auto faisait partie des premiers standard, mais un seul compilateur proposait le support de cette possibilité .

---

Euh, je crois que tu confonds avec "export template", auto était juste inutile (et inutilisé).

Citation:

---

Envoyé par gl

Euh, je crois que tu confonds avec "export template", auto était juste inutile (et inutilisé).

---

Ah, c'est possible... au temps pour moi...

Je croyais que auto était implémenté dans un de ces compilateurs très particuliers ... IBM :question: Intell :question: ou commeau :question:

Mais je peux aussi confondre avec d'autres fonctionnalités très peu implémentées par les fournisseurs de compilateur ;) :P

Citation:

---

Envoyé par koala01

En deux mots : la norme a mis longtemps à sortir, mais pas forcément à cause d'une fonctionnalité particulière (et surement pas à cause de la dépréciation du mot clé auto). Si elle a pris énormément de temps, c'est parce qu'il a fallu mettre des petites gouttes d'huile à de très nombreux endroits, et que ca a pris un temps fou ;)

---

Hum... Je ne l'entendais pas vraiment dans ce sens-là. Je disais juste que chaque norme était bien trop longue à sortir (mais il semblerait que ça aille plus vite depuis ces dernières années) et que les choses évoluent trop lentement à mon goût à cause des problèmes de "rétro-compatibilité" (pas sûr que ce soit le bon terme dans le cas présent). J'ai voulu donner l'exemple du mot-clé auto mais peut-être que ce n'était pas le meilleur choix...