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

Je pense que supprimer new et delete est une connerie monumentale qui ne devrait pas avoir débat.
C'est justement la possibilité de pouvoir géré la mémoire de façon custom qui fait la force du C++. Le C++ Modern ne doit pas remplacer les aspects existants, il doit les améliorer/compléter, ce n'est pas la même chose.
Certains métiers n'utilisent pas la STL mais le C++ pure pour plusieurs raisons, notamment que la STL ne répond pas à un besoin spécifique mais à tout les besoins imaginables, ce qui provoque toujours un overhead qui n'est peut être pas acceptable pour certains métier de la programmation.

Donc les inclusions pourquoi pas, bien qu'il faut voir le temps gagner selon la taille des projets, certains vont y perdre et d'autres y gagner je pense... Et il existe des méthodes d'inclusions qui règles le problème des inclusions multiples cf: "Core.h" + #pragma once (pour ceux qui ne savent pas c'est pas uniquement Windows...). Toujours pareil, il ne faut pas supprimer mais compléter.

De plus, il faut pas oublier que le C++ est toujours à la bourre sur les normalisations (atomics, thread, par exemple) heureusement que les entreprises n'attendent pas que la STL les intègrent.

Il n'est pas possible d'enlever le new et le delete de toute façon. Beaucoup trop de codes dépendent de ces deux mots-clés donc nous sommes tranquilles.

Citation:

---

Envoyé par Astraya

a- Je pense que supprimer new et delete est une connerie monumentale qui ne devrait pas avoir débat.
b- De plus, il faut pas oublier que le C++ est toujours à la bourre sur les normalisations (atomics, thread, par exemple) heureusement que les entreprises n'attendent pas que la STL les intègrent.

---

Le débat est que beaucoup de gens qui développent en C++, ou pire qui l'enseignent, n'ont pas assimilé les conséquences des exceptions en C++.
Les conséquences font que l'ont ne peut pas avoir des deletes non encapsulés et espérer avoir des codes robustes. Et les deletes encapsulés, c'est ce que l'on appelle le C++ moderne. Et il n'y a pas d'overhead derrière le C++ moderne.

Si par leur billet de blog CoderGears veulent nous dire que leur outil (CppDepend), est capable de traquer les ressources brutes et les manquements au RAII, je dis "champagne !". J'attends un tel outil d'analyse statique de code pour le promouvoir dans la boite et en faire acheter des licences. J'avoue ne pas présenter le moindre intérêt pour les outils qui détectent les UB et les étranges pratiques interdites par MISRA, CERT et cie. Maintenant si c'est ça le message, il est tout sauf clair.

b- hum ... Suite aux mises à jour du C++, il y a des proposition d'évolutions dans Java pour profiter des "nouveautés" du C++11 côté instructions bas-niveau sur les memory order & cie.

Citation:

---

Envoyé par imperio

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...

---

Il est vrai que la rétrocompatibilité (car oui, c'est bel et bien le terme qui convient) représente en effet un défi de taille qui peut, dans certaines circonstances, provoquer "certains retards"...

Ceci dit, je préfèrerai toujours un langage qui ne m'obligera pas à passer subitement toute ma base de code en revue simplement parce que "la norme" (ou la machine virtuelle) a évolué :aie: (je rappelle que c'est arrivé plus d'une fois avec java ;) :S )

Par contre, je ne crois sincèrement pas que les problèmes de rétrocompatibilité aient été la source principale des retards subits à l'occasion de C++11. Je crois d'avantage que c'est suite à un certain manque d'organisation face à la quantité de travail présente sur la table :P

Et il semblerait que le comité de normalisation ait fait le même constat, car il a radicalement modifié sa manière de travailler pour la suite : Maintenant, il s'est divisé en "petits groupes de travail" qui s'occupent d'un aspect particulier, autorisés à sortir une "pré-norme" à chaque fois qu'ils estiment avoir fait le tour et quelques "deadlines" pour regrouper tout ce qui a été fait en une norme stable.

Certains groupes de travail avaient comme deadline 2014, d'autres, pour des fonctionnalités plus complexes (ou plus interdépendantes) ayant une deadline en 2017. Et il semble que ca marche, parce que le draft de C++2014 est disponible depuis un bout de temps déjà ;)

Citation:

---

Envoyé par Astraya

Je pense que supprimer new et delete est une connerie monumentale qui ne devrait pas avoir débat.
C'est justement la possibilité de pouvoir géré la mémoire de façon custom qui fait la force du C++. Le C++ Modern ne doit pas remplacer les aspects existants, il doit les améliorer/compléter, ce n'est pas la même chose.

---

Attention, je pense qu'il y a confusion sur le sens de "supprimer". Il n'y a jamais eu la moindre volonté de les supprimer du langage. Quand on parle de supprimer new et delete, il faut comprendre les supprimer de son code. Car 99% du code peut s'écrire sans new et delete, et gagnera énormément à être écrit ainsi.

Citation:

---

Envoyé par Astraya

Certains métiers n'utilisent pas la STL mais le C++ pure pour plusieurs raisons, notamment que la STL ne répond pas à un besoin spécifique mais à tout les besoins imaginables, ce qui provoque toujours un overhead qui n'est peut être pas acceptable pour certains métier de la programmation.

---

Mais aussi, hélas, aussi pour de mauvaises raisons... Je ne nie pas que la STL n'est pas adaptée à tous les besoins (même si des alternatives existent généralement, plutôt que tout refaire soi-même), mais j'ai rencontré tant de gens qui croyaient être dans un cas spécial qui méritait de tout refaire (souvent en moins bien au final), que je me méfie désormais quand j'entends ce discours.

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)

---

Dans les langages intégralement compilés, tu vas avoir Ada qui va effectivement vérifier les utilisations de code externe sans passer par la copie brutale de l'intégralité du header dans le corps de ton code.
Comment fait-il ? Il considère l'entête comme du code à part entière qu'il est possible de compiler. De cette compilation sont produits des fichiers de description qui servent ensuite à la compilation des fichiers objet (grosso modo) puis des objets au link.
Un avantage de la méthode est que tout est traité comme du code et pas comme un simple fichier texte dans le cas d'un include C/C++.
Le principal inconvénient, c'est le temps de compilation.

Dans le cas d'un module externe comme une bibliothèque dynamique, les fichiers .ali, les fameux descripteurs, sont fournis avec la .dll ou le .so.

Pour moi, l'inconvénient principale d'Ada, c'est la séparation entre la déclaration et l'implémentation, comme en C et en C++. :weird:

Citation:

---

Pour moi, l'inconvénient principale d'Ada, c'est la séparation entre la déclaration et l'implémentation, comme en C et en C++.

---

Justement, pour moi, non. La séparation, c'est le contrat et ses contraintes, d'un côté et de l'autre l'implémentation dont l'utilisateur n'a rien à savoir.
Il n'y a rien de choquant.
Je fais du Java depuis 15 ans et franchement, si tu n'ouvres pas le code dans un éditeur ad-hoc mais avec un simple éditeur texte ou un navigateur, c'est lourd.

Citation:

---

d'un côté et de l'autre l'implémentation dont l'utilisateur n'a rien à savoir

---

Sauf que t'es pas l'utilisateur, t'es l'implémenteur.

S'il y a contrat à respecter, c'est à mettre dans un fichier dédié à cela, les interfaces de COM/JAVA/C#/...

Dans ce type d'interface, les membres privés ou protected, il devrait disparaitre, etc...

C'est bien le souci du C et du C++, c'est qu'il a des trucs qui n'ont strictement rien à y faire si c'est pour spécifier des interfaces.
Les .h n'ont pas été conçus pour spécifier des interfaces mais pour permettre une génération en 2 phases : compilation + édition de lien.
Très efficace pour faire tourner le biniou sur les machines des années 70, mais plus vraiment le cas maintenant.

=> Donc, putain que oui "Le C++ est vraiment victime de son passé !!!"

Citation:

---

Sauf que t'es pas l'utilisateur, t'es l'implémenteur.

---

Pas forcément, sur des projets d'une certaine taille, même au sein d'une même équipe, tu n'as pas le temps, ni l'envie de regarder l'implémentation et ce n'est pas pour ça que l'on doive forcément te filer une interface. Dans ce cas, tu es l'utilisateur.
Donc, je persiste mais une spécification, ça peut avoir son importance.

Citation:

---

Dans ce type d'interface, les membres privés ou protected, il devrait disparaitre, etc...

---

Ben, dans le cas de la compilation Ada, c'est normalement le cas à quelques exceptions près.

Citation:

---

Les .h n'ont pas été conçus pour spécifier des interfaces mais pour permettre une génération en 2 phases : compilation + édition de lien.
Très efficace pour faire tourner le biniou sur les machines des années 70, mais plus vraiment le cas maintenant.

---

Sauf que la notion même de .h n'est que pure convention dans le cas du C/C++ et que l'inclusion est l'oeuvre du macro-processeur qui n'a rien à voir avec une quelconque compilation, c'est de la substitution de texte. D'ailleurs, on peut très bien inclure un .cpp dans un autre sans qu'il ne se passe rien de dramatique à la compilation.

Bonjour,

Ce fil de discussion m'inquiète beaucoup.

en effet, je viens du VB6 et j'attaque le C++. J'ai déjà créé une classe en C++ ANSI. J'ai étudié "Ivor Horton's Beginning Visual C++ 2008" et je lis "Pensez en C++" qui date de 2008.

Je me rends compte en lisant vos posts que toutes ces lectures sont obscolètes. Pouvez-vous me le confirmer ?

Merci

"Pensez en C++" est bien plus vieux que 2008.
Côté design, il est très intéressant, mais côté bonnes pratiques sur le C++, c'est du C++ historique -- et tu risques de te voir corriger à chaque post sur les posts -> les gens qui répondent finissent par être fainéants et ne plus vouloir prendre la peine de chercher à corriger des codes qui ont des pointeurs qui se baladent nus.

Pour les livres qui ciblent un outil, je me méfie toujours. Je te renvoie au fil qui traite des livres pour le C++: http://www.developpez.net/forums/d68...rs-livres-cpp/ (il y a peut-être un autre fil -- si /C++ Primer/ n'est pas cité, la dernière version est bien normalement)

Bonjour,

Il me semble que le C# qui est un dialecte C++ répond déjà à beaucoup des interrogations mentionnées ici :
-plus d'include
-plus de pointeur sauf à définir des portions "unsafe" dans le code
-un système de référence généralisé ...

Où situez-vous le C# par rapport au modern C++ ?

Le C++ semble être en phase de métamorphose. Il peut s'adapter sans doute à différents contextes et ainsi se partager en sous-dialecte. Cette plasticité c'est peut-être aussi ce qui fait sa force...

Je rappelle que le C# n'est plus une propriété Microsoft.

Citation:

---

Envoyé par fgets

Où situez-vous le C# par rapport au modern C++ ?

---

Sur le plan technique, je ne peux pas répondre (les références de C# sont comme celles de C++ ou plutôt comme celles de Java ?)
Mais :
- pas normalisé à partir de C# 3.0 (et pas vraiment portable).
- basé sur un garbage collector et non le RAII.

Citation:

---

Envoyé par fgets

Je rappelle que le C# n'est plus une propriété Microsoft.

---

L'implémentation de Microsoft si ; et actuellement, il n'existe pas d'implémentation libre ou open source de la même version.
De plus, les implémentations libres ou open source implémentent le langage mais pas forcément la bibliothèque .NET (qui est la propriété de Microsoft ?)

A la base C# est bien plus proche de JAVA que de C++.
C++/CLI est un dialecte C++ mais pas C#.

Actuellement, Mono est toujours limité à C# 2.0, l'avancement est ici.

Et encore, j'aurais plutôt l'impression que dire que le C++/CLI est un dialecte de C++, c'est un peu comme dire que le C++ est un dialecte de C.

Je parlais plutôt de ça :

Citation:

---

le gêne est que « nous avons encore la possibilité d'utiliser new et delete

---

Je voulais parler de ça mais il est parfois nécessaire de devoir libérer de la mémoire explicitement.

Dans ce cas là delete est la seule solution.

Citation:

---

Envoyé par Lolilolight

Je voulais parler de ça mais il est parfois nécessaire de devoir libérer de la mémoire explicitement.

Dans ce cas là delete est la seule solution.

---

Rien n'empêche ta capsule RAII de fournir ce qu'il faut pour ça dans son interface (unique_ptr<T>::reset(), vector<T>::resize, etc ...), et celles de base répondent à une très vaste partie des besoins. Tu peux avoir besoin de delete si tu implémentes ton propre type RAIIsant mais encore une fois, il est fort possible que l'utilisation des conteneurs existant te permette cette implémentation (efficace). Même si tu implémentes ton propre type, avec un GC en manager derrière, il est très fortement probable que tu n'aies pas besoin de delete.

Bonjour.

Citation:

---

Envoyé par fgets

-plus de pointeur sauf à définir des portions "unsafe" dans le code

---

En C++ il y a new/delete. En C# il y a new et parfois dispose... Même pas besoin de parler de ces "Pin" pointeurs et autres unsafe design.

En gros si tu oublies de disposer un objet, le programme va fuité. Par contre va chercher la fuite. Je ne parle pas des delagate avec les +=, malheur à toi si tu oublies le -= équivalent. En somme, l'équivalent d'un delete en C++. Bref, garbage collector : loose.

Le garbage collector ne gère rien du tout, sauf si tu fais un simple "Hello world". Ils ont inventé "using" d'ailleurs. Cela veut dire que tu dois quand même gérer le "delete" et savoir ce que tu fais. Donc le garbage collector, c'est juste du Marketing. L'idée est bonne, la réalité beaucoup moins.

Ce qui me fait peur, c'est que le C++ se dirige vers ce type de langage. Et pour lancer un troll, le mot clé "auto" du C++ ne devrait pas exister... (sauf dans une boucle, à la rigueur, à cause des stl type). Le mot clé auto, l'équivalent de var en C#, juste une purge pour la maintenance de code...