Discussion :

[Luc Hermitte]

Il y a ça, mais je pensais aussi à certaines fonctionnalités comme les contrats (que j'attendais depuis un bout de temps) ; et typiquement le genre de truc qui devrait un max être vérifié de façon statique (compilation ou analyse statique). Après, je n'ai pas regardé en détail quelles seraient les choses sans équivalences, celles qui seraient plus compliquées à mettre en place ou le contraire.

[jo_link_noir]

A propos ça fait longtemps qu'il y a des sortes de modes "hardened" dans les implémentations de la SL. Mais si je comprends, la différence est que maintenant l'ABI reste compatible selon le mode de défensivité de la SL qui est choisi lorsque l'on compile?

Cela se veut toujours compatible avec l'ABI, quel que soit le niveau choisi. Et c'est prévu pour être utilisable en production (au moins pour un mode). Des tests Google pour Android, le coût est de 0.8% avec libc++ (je crois d'ailleurs que c'est eux qui l'ont introduit dans clang). Les précédentes manières de faire ont été supprimées côté clang et msstl.

Pour gcc par contre, ça fait effectivement bien longtemps qu'il existe les modes assertion et debug (le dernier cassant l'ABI), mais à ma connaissance, ce n'est pas spécialement pensé pour être utilisable en production et le coût est proche de 10% (de mémoire, je ne me souviens pas où j'avais vu le chiffre). En plus d'être activé si pas d'opti, c'est aussi fait avec la nouvelle option -fhardened qui regroupe plusieurs options (voir --help=hardened avec gcc-15).

Il y a ça, mais je pensais aussi à certaines fonctionnalités comme les contrats (que j'attendais depuis un bout de temps) ; et typiquement le genre de truc qui devrait un max être vérifié de façon statique (compilation ou analyse statique).

Pour les contrats, il n'y en a pas besoin puisqu'on ne peut pas utiliser un générique sans spécifier un trait qui définit son interface. Par contre, la généricité à un certain nombre de limitation comme pas de spécialisation (si on se débrouille bien, le compilateur pointe l'issue ouverte depuis 7 ans) ou pas d'opération avec des constantes (pas possible de faire array</*Len*/10>::drop_last</*N*/3> -> array</*Len-N*/7> à cause de la soustraction). On peut plus ou moins contourner ou faire différemment, mais c'est ce qui m'a le plus embêté sur le petit projet que j'avais.

Pour la vérification statique, il n'y en a pas moins qu'en C++ et le langage ne se traîne pas les casseroles du C.

[Luc Hermitte]

Pour les contrats, il n'y en a pas besoin puisqu'on ne peut pas utiliser un générique sans spécifier un trait qui définit son interface. Par contre, la généricité à un certain nombre de limitation comme pas de spécialisation (si on se débrouille bien, le compilateur pointe l'issue ouverte depuis 7 ans) ou pas d'opération avec des constantes (pas possible de faire array</*Len*/10>::drop_last</*N*/3> -> array</*Len-N*/7> à cause de la soustraction). On peut plus ou moins contourner ou faire différemment, mais c'est ce qui m'a le plus embêté sur le petit projet que j'avais.

Pour la vérification statique, il n'y en a pas moins qu'en C++ et le langage ne se traîne pas les casseroles du C.

Hum... Pas sûr que l'on parle de la même chose. Je parlais des contrats (C++26), pas des concepts. Même s'il y a un rapport lointain où le concept est une sorte de contrat sur le type, les contrats ne sont pas lié à la généricité. Ca peut aller de "le nombre d'éléments stockables est cohérent avec la RAM alloué" (difficile à exprimer) à ce "flottant doit être positif", en passant par "ce pointeur ne doit pas être null si on est en pleine Lune". Sans parler des "je sais que le flottant appartient à [2; 42[".

Mon espoir est que les contrats qui ne seront demain que des asserts sous stéroïdes, puissent être un jour exploités pour faire de l'analyse statique -- même si ce n'est qu'une exploitation partielle. C'est l'intérêt d'une solution standardisée dans le langage et non sous forme de lib, ou d'annotation propriétaire à un outil.

[destroyedlolo]

Les temps de compilations sont catastrophiques.

Assez caustique quand on voit le temps de compilation de RUST

Quand à la dete technique, souvent, c'est parce que l'accent n'a pas été assez mis sur la documentation en particulier des interfaces.

[jo_link_noir]

Hum... Pas sûr que l'on parle de la même chose. Je parlais des contrats (C++26), pas des concepts.

J'ai mal lu .
Du coup non, y a pas.

@OuftiBoy:

ptr + vec, je ne comprends pas l'accumulation. Ni pourquoi un ptr seul à besoin d'être alloué, mais pas un ptr vec. Mais si je comprends bien, vec est builtin, on ne peut pas implémenter vec.add ?

Je rejoins bacelar sur la facilité d'utilisation: un pointeur est une notion compliquée pour un débutant, ce n'est pas simple. Plein de langages se débarrassent du problème en ce reposant sur un GC.

[OuftiBoy]

Bonjours çà tous,

Le fil de la discution concernant mon langage (Home), a été déplacé vers:

Sujet : « Home » : réflexions sur un nouveau langage (https://www.developpez.net/forums/d2...uveau-langage/)
Nouveau forum : Langages de programmation (https://www.developpez.net/forums/f4...programmation/)

J'inite donc ceux et celles qui veulent continuer là discution de la faire là-bas.

Merci à tous,

Et Peace & Love.