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.