Il fut un temps au je suivais un projet appeler D :) Mais il était trop avancé pour discuter des features.
Je crois que tu as tord d'ajouter la surcharge d'opérateur, c'est une des grandes raisons de code bloat de C++.
Il serait plus sympa par contre de créer ses propres opérateurs. Genre le ".+" de mathlab ou n'importe quoi d'autre. Tu définit un paquet de symbol autour desquels tu peux mettre 2 objets, l'expression en retournant un 3ième.
Cela serait génial de pouvoir préciser la transitiviter de l'opérateur (a T (b T c) == (a T b) T c), si a T b == b T a,... Définir si une fonction est pure ou impure (l'execution de la fonction n'a pas d'effet de bord donc, l'ordre d'execution n'a pas d'importance, genre une fonction avec des IO(est impure) un opérateur devrait toujours être pure).
Cela deviendra super important pour les optimisations de compilation futures (vectorisation de code et compilation multithread). Et la compilation lève un grand nombre d'erreur.
Sinon, inclure des opérateurs sur tableau est indispensable pour des raisons de perf. Mais fait une méthode ou la taille peut être fixe car à la compilation les performances ne seront pas les mêmes qu'avec des tailles variables.
Il faudrait aussi que le compilo est 2 modes debug et release, voire un troisieme de profiling (code release + instrumentation).
Le release doit avoir le maximum de perf.
Le code debug devrait implémenter le maximum de running check possible : genre forbiden access in array tartenpion file ??? line ??? column ???, variable titi == N but N should be <N et plus ce stupide "Seg fault !".
Bon, j'en ai plein des idées pour un nouveau langages... genre :
les transactions (copy-on-write sur les donné, et rollback en cas d'exception),...
les méthode d'objet par default (comme objectif C ? genre save() et load() pour chaque objet en xml),...
utilisation des ensembles plutot que des types,...
donner des intervalles de valeur pour les entiers (vérification possible à la compilation, et en run time, et finis les grosses merde dû à l'utilisation de int qui était 16 bits, qui est 32 bits et qui passe à 64 !)
# Re: Nosica
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Nosica. Évalué à 3.
Il fut un temps au je suivais un projet appeler D :) Mais il était trop avancé pour discuter des features.
Je crois que tu as tord d'ajouter la surcharge d'opérateur, c'est une des grandes raisons de code bloat de C++.
Il serait plus sympa par contre de créer ses propres opérateurs. Genre le ".+" de mathlab ou n'importe quoi d'autre. Tu définit un paquet de symbol autour desquels tu peux mettre 2 objets, l'expression en retournant un 3ième.
Cela serait génial de pouvoir préciser la transitiviter de l'opérateur (a T (b T c) == (a T b) T c), si a T b == b T a,... Définir si une fonction est pure ou impure (l'execution de la fonction n'a pas d'effet de bord donc, l'ordre d'execution n'a pas d'importance, genre une fonction avec des IO(est impure) un opérateur devrait toujours être pure).
Cela deviendra super important pour les optimisations de compilation futures (vectorisation de code et compilation multithread). Et la compilation lève un grand nombre d'erreur.
Sinon, inclure des opérateurs sur tableau est indispensable pour des raisons de perf. Mais fait une méthode ou la taille peut être fixe car à la compilation les performances ne seront pas les mêmes qu'avec des tailles variables.
Il faudrait aussi que le compilo est 2 modes debug et release, voire un troisieme de profiling (code release + instrumentation).
Le release doit avoir le maximum de perf.
Le code debug devrait implémenter le maximum de running check possible : genre forbiden access in array tartenpion file ??? line ??? column ???, variable titi == N but N should be <N et plus ce stupide "Seg fault !".
Bon, j'en ai plein des idées pour un nouveau langages... genre :
les transactions (copy-on-write sur les donné, et rollback en cas d'exception),...
les méthode d'objet par default (comme objectif C ? genre save() et load() pour chaque objet en xml),...
utilisation des ensembles plutot que des types,...
donner des intervalles de valeur pour les entiers (vérification possible à la compilation, et en run time, et finis les grosses merde dû à l'utilisation de int qui était 16 bits, qui est 32 bits et qui passe à 64 !)
Je regarde le site promis !
"La première sécurité est la liberté"