Le typage de OCaml n'est pas plus expressif ni plus sûr.
Il y a généralement de meilleurs messages d'erreur, mais c'est facile quand on a pas de surcharge/spécialisation (nécessaire à la spécialisation des algorithmes et à la méta-programmation) et que la signature d'un symbole contient nécessairement les types les plus restrictifs qui permettent l'exécution de son corps.
En C++, la résolution de surcharge ne prend en compte que la déclaration, pas la définition. C'est parce que généralement la déclaration est trop permissive (mais ça ne tient qu'aux gens de changer ça) que l'on obtient des messages d'erreurs "illisibles" quand une erreur survient, plus tard, dans la définition.
Néanmoins, rien n'empêche de mettre l'intégralité du corps de la fonction dans la signature, d'une manière ou d'une autre, ce qui permettra de rendre le symbole visible uniquement si les types d'entrées satisfont l'intégralité des expressions.
Ce serait encore plus pratique si on avait des lambdas polymorphiques, mais je ne suis pas certain qu'elles arrivent dans C++0x.
Pour ce qui est des modules, c'est facile en OCaml quand on implémente la généricité simplement avec un seul code de fonction qui prend en fait un pointeur générique. Quand on a un langage efficace comme C++, où tout objet n'est pas soit un entier soit un pointeur garbage collecté, et que donc par conséquent on doit générer une version de chaque fonction non monomorphique pour chaque type qui l'utilise, faire un système de modules pose certains problèmes car il faudrait en fait faire une seconde passe de compilation à l'édition de liens, ce qui n'est pas vraiment le modèle traditionnel.
OCaml, ce n'est pas si terriblement efficace, et ce par conception. Pour écrire du code efficace, (et ça concerne en fait tous les langages garbage collectés), bien souvent le seul moyen c'est d'allouer un gros Bigarray et de le manipuler comme si c'était de la mémoire. On se retrouve alors encore plus bas niveau que du C.
[^] # Re: Déçu
Posté par loufoque . En réponse à la dépêche Retard(s) pour la prochaine version de C++. Évalué à 7.
Il y a généralement de meilleurs messages d'erreur, mais c'est facile quand on a pas de surcharge/spécialisation (nécessaire à la spécialisation des algorithmes et à la méta-programmation) et que la signature d'un symbole contient nécessairement les types les plus restrictifs qui permettent l'exécution de son corps.
En C++, la résolution de surcharge ne prend en compte que la déclaration, pas la définition. C'est parce que généralement la déclaration est trop permissive (mais ça ne tient qu'aux gens de changer ça) que l'on obtient des messages d'erreurs "illisibles" quand une erreur survient, plus tard, dans la définition.
Néanmoins, rien n'empêche de mettre l'intégralité du corps de la fonction dans la signature, d'une manière ou d'une autre, ce qui permettra de rendre le symbole visible uniquement si les types d'entrées satisfont l'intégralité des expressions.
Ce serait encore plus pratique si on avait des lambdas polymorphiques, mais je ne suis pas certain qu'elles arrivent dans C++0x.
Pour ce qui est des modules, c'est facile en OCaml quand on implémente la généricité simplement avec un seul code de fonction qui prend en fait un pointeur générique. Quand on a un langage efficace comme C++, où tout objet n'est pas soit un entier soit un pointeur garbage collecté, et que donc par conséquent on doit générer une version de chaque fonction non monomorphique pour chaque type qui l'utilise, faire un système de modules pose certains problèmes car il faudrait en fait faire une seconde passe de compilation à l'édition de liens, ce qui n'est pas vraiment le modèle traditionnel.
OCaml, ce n'est pas si terriblement efficace, et ce par conception. Pour écrire du code efficace, (et ça concerne en fait tous les langages garbage collectés), bien souvent le seul moyen c'est d'allouer un gros Bigarray et de le manipuler comme si c'était de la mémoire. On se retrouve alors encore plus bas niveau que du C.