Afficher les réponses par date
On 2012-07-04, at 4:33 PM, chevalma@iro.umontreal.ca wrote:
http://en.wikipedia.org/wiki/C%2B%2B#Philosophy _______________________________________________ Dlteam-list mailing list Dlteam-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/dlteam-list
Donc, ça n'a pas été un objectif de design de concevoir un langage qui offre des features aux limites de ce qui est analysable. D'autre part, un langage qui a l'opérateur de cast (tel qu'il est dans C/C++) ne peut pas se dire "statically typed". Anyways, ça ne vaut pas la peine de s'embarquer dans du "C++ bashing"... il y a amplement de commentaires à ce sujet.
Marc
In The Design and Evolution of C++ (1994), Bjarne Stroustrup describes some rules that he used for the design of C++:[page needed] • C++ is designed to be a statically typed, general-purpose language that is as efficient and portable as C • C++ is designed to directly and comprehensively support multiple programming styles (procedural programming, data abstraction, object-oriented programming, and generic programming) • C++ is designed to give the programmer choice, even if this makes it possible for the programmer to choose incorrectly • C++ is designed to be as compatible with C as possible, therefore providing a smooth transition from C • C++ avoids features that are platform specific or not general purpose • C++ does not incur overhead for features that are not used (the "zero-overhead principle") • C++ is designed to function without a sophisticated programming environment Inside the C++ Object Model (Lippman, 1996) describes how compilers may convert C++ program statements into an in-memory layout. Compiler authors are, however, free to implement the standard in their own manner.
Donc, ça n'a pas été un objectif de design de concevoir un langage qui offre des features aux limites de ce qui est analysable.
En effet, je faisait référence au "zero-overhead principle". On ne paie pas pour les features qu'on utilise pas.
C'est moi qui suggère de concevoir un language en fonction de ce qui s'analyse bien. Pas nécessairement "aux limites" de ce qui est analysable. Il s'agirait plutôt de concevoir les règles de typage pour rendre la tâche d'analyse facile et efficace.
Par exemple:
- Si davantage d'opérations en JS lancaient des exceptions quand elles recoivent des types invalides, les valeurs undefined ne pourraient pas se propager partout.
- Les objets pourraient ne pas permettre de rajouter des champs après leur création, ou sinon, accèder à un champ non défini pourrait lancer une exception.
- Les opérations numériques sur des entier pourraient guarantir de ne produire que des entiers en permettant l'overflow, par design. Ceci élimine le problème de savoir si un nombre est un entier ou un float, ou s'il entre dans 30 ou 32 bits.
- Eval pourrait prendre un environnement en paramètre, voir être complètement éliminé en faveur de la génération de nouvelles fonctions dynamiquement
Anyways, ça ne vaut pas la peine de s'embarquer dans du "C++ bashing"
Ce n'est certainement pas moi qui déteste C++ ici. Le language, malgré ses failles, a connu un énorme succès, en grande partie parce qu'il a été conçu avec un esprit pragmatique (e.g.: réutiliser tout l'héritage de C).
- Maxime
-
chevalma＠iro.umontreal.ca -
Marc Feeley