# C et C++ > C > Contribuez >  Nouveau langage : le Safe-C

## Marc.Samuro

Bonjour au forum,

passionn de C depuis plus de 10 ans et ayant l'habitude des gros programmes de plus de 50,000 lignes, cela m'a toujours embt d'avoir autant de difficults pour trouver et corriger les bugs, le C ne vrifiant ni les indices de tableaux, ni les pointeurs.

J'ai envisag de passer au C++ ou au C#, mais ni l'un ni l'autre ne me satisfont vraiment : le C++ ne vrifie pas plus les indices et les pointeurs que le C, et le C# ne gnre pas du vrai code assembleur et en plus est lourd et lent avec son garbage collector.

Bref, une seule solution restait : crer mon propre langage qui ressemblerait trs fort au C et en garderait la vitesse que nous apprcions tous, mais en mme temps le transformer pour qu'il ne soit plus possible qu'une partie du code crive en mmoire o il ne peut pas ...

Je l'ai baptis le Safe-C, je pense que cela rsume bien ce que c'est.

Pendant tout 2010 j'ai cris les spcifications du langage ainsi qu'un  compilateur Safe-C pour Windows; maintenant en 2011 je suis en train d'crire les librairies.

C'est un vrai langage o on peut faire tout ce qu'on peut faire aussi en C, mais si l'un des indices de tableau dborde ou qu'un pointeur crit o il ne peut pas, vous aurez tout de suite une erreur qui vous indique o dans le code source il y a problme, d'o normment de temps gagn en dveloppement.

Si quelqu'un ici a envie de participer  cette aventure (il y a encore beaucoup  faire : crire des librairies, des tutorials, proposer des modifs) il est le bienvenu  ::):   Il faut qu'il connaisse bien le C parce que le Safe-C en est trs proche.

J'ai mis un premier tutorial pour dbutants en informatique sur ce site provisoire : http://newchatrooms.dyndns.dk:12000/...IAL/start.html

Je suis en train d'crire des librairies faciles  utiliser pour IPV4 et IPV6, d'autres suivront ..

Pour me contacter c'est marcsamu@hotmail.com

Si cela rencontre du succs on pourra peut-tre ouvrir une rubrique ici sur le forum ..

----------


## gl

> le C++ ne vrifie pas plus les indices et les pointeurs que le C


As-tu entendu parl de std::vector (et autres containers standards), std::string, smart pointer, rfrence, etc. ?

Mme si le C++ n'est pas parfait  ce niveau l, dire qu'il n'apporte rien de plus que le C c'est quand mme assez gros.


Sinon concernant ton langage, quelques questions suite  ta prsentation :
Tu dis que les indices et pointeurs sont vrifis par le langage, mais comment ? A quel moment (compile time ou run time) ? Que se passe-t-il prcisment en cas d'erreur ? Jusqu' quel point le comportement peut-il tre configurer ?Pourquoi ne pas avoir choisi une politique o les tableaux grent leur taille et sont capables de se redimensionner lorsque ncessaire (particulirement en ce qui concerne les chanes de caractres) ?Es-tu capables de t'interfacer avec d'autres langages (notamment le C) ? Si oui, comment ?

----------


## LLB

- Qu'en est-il de l'interoprabilit avec le C ?
- Que pensez-vous de D ?
- Quel est votre modle de compilation ? Gnrez-vous du code C, appelez-vous un back-end existant (comme LLVM) ou gnrez-vous directement le code binaire ?
- Qu'en est-il des performances (vous semblez attaquer C#, mais c'est bien plus optimis que ce que vous semblez croire) et de la portabilit ?
- Peut-on utiliser des outils existants (IDE, dbogueurs...) avec votre langage ?




> J'ai envisag de passer au C++ ou au C#, mais ni l'un ni l'autre ne me satisfont vraiment : le C++ ne vrifie pas plus les indices et les pointeurs que le C, et le C# ne gnre pas du vrai code assembleur et en plus est lourd et lent avec son garbage collector.


C++ vrifie les accs aux vecteurs, strings, etc. Du C++ correctement utilis vrifie beaucoup de choses et est beaucoup plus sr que le C. C# gnre du vrai code natif  la vole (ce qui prsente beaucoup d'avantages).

Il existe dj beaucoup de drivs du C, la plupart d'entre eux ayant essay de corriger les problmes de sret. N'y en a-t-il vraiment pas un qui vous satisfasse ? Crer un nime langage, ne proposant quasiment rien de nouveau, me semble totalement vou  l'chec.

----------


## Mat.M

Je suis totalement d'accord avec Gl les conteneurs du C++ donnent entirement satisfaction pas besoin d'tre un expert du C++ pour les utiliser  ::D: 
Et puis il y a Boost aussi ( intgre  Visual Studio 2010 )




> et le C# ne gnre pas du vrai code assembleur et en plus est lourd et lent avec son garbage collector.


l aussi je suis d'accord ( ce n'est pas le sujet ) J'ai une certaine aversion pour tout ce qui est .NET  ::mouarf::

----------


## Marc.Samuro

rponse  ql:

Q1:
c'est clair que les librairies string, vecteur, etc.. du C++ apportent une scurit, mais elle est limite  ces type de donnes (string ou vecteur).

En Safe-C je voulais une scurit  100%, mme pour les simples tableaux, mme pour les printf, les passages de paramtres, pointeurs, etc ... il n'y a pas de faille.

Il est cependant possible de crer des pointeurs non-vrifis comme en C en utilisant les pragma "#begin unsafe" et "#end unsafe". C'est ncessaire pour interfacer avec Windows.

Q2:
Les pointeurs sont vrifis  l'excution pour un mcanisme de tombstone (voir wikipedia).
C'est vrai que c'est plus lent que des pointeurs classiques, mais :
- cela offre une scurit  100% : cela vrifie les pointeurs non valides, les double-free, tous les cas sont prvus.
- c'est scalable (donc ne ralentit pas pour les gros programmes contrairement aux langages qui utilisent un garbage collector).
- on utilise beaucoup moins les pointeurs en Safe-C que dans les langages qui ont des classes, donc un lger ralentissement ne se remarque pas.

Q3:
en cas d'erreur le programme se plante  l'endroit de l'erreur. Donc il n'crase pas de donnes plus loin et ne peut pas craser la pile. On a directement l'endroit de l'erreur et on peut corriger, donc c'est mieux qu'en C. En tant que programmeur C le mcanisme d'exception du C++ me semble trop lourd et bon, le but ici est de n'avoir aucune exception.

Q4:
Le safe-C reprend la plupart des lments du C, et les strings dynamiques n'en font pas partie.

Q5:
pour le moment je peux m'interfacer avec des DLL windows, j'en suis  la version 1 du compilateur.

rponse  LLB:
Q1: l'interoprabilit est, disons, faisable. Actuellement je suis en train de reprendre toutes mes anciennes librairies source C et de les adapter, cela va quand mme assez vite.

Q2: je ne connais pas D mais c'est OO je pense ?

Q3: le compilateur Safe-C gnre du bon vieux code machine 32-bit pour Windows (processeur Intel/Amd) (je n'ai pas inclus les instructions SSE parce que tous le monde ne les a pas). Le compilateur est dj prvu pour gnrer du 64-bit, ce sera pour plus tard.

Q4: les performances sont aussi bonnes qu'en C. Les vrifications d'indice de tableau ne gnrent que 2 instructions assembleur en plus, cela ne se remarque mme pas.

Q5: non pas encore de debugger, je suis  la version 1 l.


Bon vous avez tous l'air de tirer  boulets rouge dessus, c'est vrai que ce langage ne propose rien de rvolutionnaire. C'est un driv du C qui propose plus de scurit et en profite pour amliorer 2 ou 3 choses. Le langage reste petit et simple comme le C, il n'y a pas de quoi brandir les fourches et de tout brler hein  :;): .

- Peut-on utiliser des outils existants (IDE, dbogueurs...) avec votre langage ?

ah des outils existants ! oui on peut, en fait j'utilise le debugger de visual C pour le moment. Mais j'ai cris une librairie d'exception qui redirige le vecteur d'exception de windows, donc en cas de plantage a m'affiche directement l'endroit dans le source, c'est pratique. Je n'ai pas encore d'IDE, je travaille en Dos l.

Le but du Safe-C est qu'il ne soit pas possible qu'une partie d'un programme crase les donnes d'une autre partie du programme en dehors des rgles du langage : les indices de tableau sont vrifis, les pointeurs passent par des tombstone, les strings ont un byte 0 optionnel et non obligatoire comme en C, les fonctions  nombre variable de paramtres crent un tableau sur la pile avec les paramtres variables et seul l'adresse du tableau est passe.

Il y a beaucoup de vrifications  la compilation : tout doit tre initialis, mme les tableaux (il y a d'ailleurs une commande 'clear' pour effacer une variable), le compilateur vrifie aussi que le string "%s%d" d'un printf correspond aux arguments si celui-ci est constant, ce qui vite d'avoir des erreurs  l'excution. Bref, le Safe-C reprend tous les lments du C et les rend srs.

Il y a 2 ou 3 choses nouvelles seulement : un type "opaque" qui est la mme chose que "struct" mais les champs du struct ne sont pas visible dans d'autres fichiers. (encapsulation de donnes); des packages gnriques aussi (l'quivalent des templates du C mais simplifis  l'extrme; tout se passe  la compilation, cela remplace en fait les macros du C).

----------


## LLB

> Bon vous avez tous l'air de tirer  boulets rouge dessus, c'est vrai que ce langage ne propose rien de rvolutionnaire.


Oui, et c'est le problme. C'est trs dur de populariser un nouveau langage. En gnral, un langage ne marche que s'il est vraiment novateur (et se dmarque du reste) ou s'il est pouss par une entreprise (ou universit, centre de recherche).
Si quelqu'un veut utiliser ce nouveau langage, quelle garantie a-t-il qu'il sera toujours maintenu dans 5 ou 10 ans ?

Aprs, il ne faut pas prendre les critiques mal, a permet de mieux se rendre compte des qualits ou dfauts du langage. Pour ma part, a doit tre le 10e langage que je croise qui souhaite corriger les dfauts du C. Personnellement, pour avoir travaill professionnellement sur la conception et l'implmentation de nouveaux langages, je sais  quel point c'est difficile d'en populariser un. crire un compilateur qui marche n'est pas le plus dur.




> Q2: je ne connais pas D mais c'est OO je pense ?


Oui (un peu comme en C++). Voir ici
Disons que a reprend des ides du C++, en enlevant un certain nombre de problmes (car ils n'ont pas gard la compatibilit avec le C). Un peu moins de puissance qu'en C++ (templates plus simples, par exemple), mais c'est plus sr et plus simple.




> Q1: l'interoprabilit est, disons, faisable. Actuellement je suis en train de reprendre toutes mes anciennes librairies source C et de les adapter, cela va quand mme assez vite.


Il faut rcrire le code ? Si on veut utiliser DirectX, OpenGL ou toutes les autres bibliothques populaires, a reprsente beaucoup de travail ?




> Q3: le compilateur Safe-C gnre du bon vieux code machine 32-bit pour Windows (processeur Intel/Amd) (je n'ai pas inclus les instructions SSE parce que tous le monde ne les a pas).


Tandis que le JIT de C# est capable d'utiliser les SSE quand c'est disponible (c'est un avantage du JIT). Gnrer du code efficace n'est pas simple, il y a normment d'optimisations  faire. Mme si C# n'a pas de performances optimales (parce qu'il fait de l'introspection, garde les infos de type  l'excution, parce que le JIT ne peut pas prendre 10s pour optimiser...), a m'intresse de voir des benchmarks avec votre compilateur.

Cela m'intrigue : pourquoi ne pas utiliser un backend existant ? Pourquoi ne pas utiliser par exemple LLVM ? Vous avez vraiment envie de rcrire la gnration de code pour chaque architecture  grer ? La portabilit est quand mme l'un des gros avantages du C, il ne faudrait pas l'oublier.




> Les vrifications d'indice de tableau ne gnrent que 2 instructions assembleur en plus, cela ne se remarque mme pas.


Les compilateurs existants (comme en C#) sont capables de ne pas faire la vrification d'indice dans de nombreux cas (grce  une analyse statique du code).




> En tant que programmeur C le mcanisme d'exception du C++ me semble trop lourd et bon, le but ici est de n'avoir aucune exception.


Lourd  quel niveau ? Je trouve que la gestion d'erreurs est bien plus lourde  faire correctement en C qu'en C++.




> En Safe-C je voulais une scurit  100%, mme pour les simples tableaux


Que se passe-t-il si on accde hors d'un tableau (avec un indice variable) ? Ne pensez-vous pas que lancer une exception serait la bonne chose  faire dans ce cas ?




> Il y a beaucoup de vrifications  la compilation


Les compilateurs C sont dj capables de vrifier le format d'un printf quand il est connu ou vrifier que les variables sont initialises (dans les cas simples).




> c'est clair que les librairies string, vecteur, etc.. du C++ apportent une scurit, mais elle est limite  ces type de donnes (string ou vecteur).


Les rfrences sont aussi plus sres que les pointeurs.

----------


## gl

> Bon vous avez tous l'air de tirer  boulets rouge dessus, c'est vrai que ce langage ne propose rien de rvolutionnaire. C'est un driv du C qui propose plus de scurit et en profite pour amliorer 2 ou 3 choses. Le langage reste petit et simple comme le C, il n'y a pas de quoi brandir les fourches et de tout brler hein .


Non, ma but n'est pas de tirer  boulet rouge. Je cherche simplement  savoir ce que propose ton langage et s'il est susceptible de m'intresser.
Au risque de paratre un peu brutal, s'il ne m'apporte rien, il n'y a aucune chance que j'y passe du temps dessus (je n'ai dj pas assez de temps pour me consacrer  tout les langages, bibliothques, articles, etc. qui m'intressent)




> Les pointeurs sont vrifis  l'excution pour un mcanisme de tombstone (voir wikipedia).
> C'est vrai que c'est plus lent que des pointeurs classiques, mais :
> - cela offre une scurit  100% : cela vrifie les pointeurs non valides, les double-free, tous les cas sont prvus.
> - c'est scalable (donc ne ralentit pas pour les gros programmes contrairement aux langages qui utilisent un garbage collector).


Et concernant les accs hors borne du tableau ? galement  l'excution ?
Pourquoi ne pas chercher  vrifier ce qui peut l'tre  la compilation ?




> - on utilise beaucoup moins les pointeurs en Safe-C que dans les langages qui ont des classes, donc un lger ralentissement ne se remarque pas.


Euh ! Quel est le rapport entre le faite d'avoir des classes et la densit de pointeurs dans un programme ?




> en cas d'erreur le programme se plante  l'endroit de l'erreur. Donc il n'crase pas de donnes plus loin et ne peut pas craser la pile. On a directement l'endroit de l'erreur et on peut corriger, donc c'est mieux qu'en C. En tant que programmeur C le mcanisme d'exception du C++ me semble trop lourd et bon, le but ici est de n'avoir aucune exception.


Donc un problme implique forcment un crash du programme. Il n'y a pas moyen d'intercepter les erreurs et de les traiter diffremment (ce que permettent les exceptions) ? 




> Le safe-C reprend la plupart des lments du C, et les strings dynamiques n'en font pas partie.


std::string c'est du C++ pas du C. Il n'y a actuellement pas de type string en C.




> pour le moment je peux m'interfacer avec des DLL windows, j'en suis  la version 1 du compilateur.


Ce qui ne veut pas dire grand chose.

Peux-tu passer tes tableaux et des pointeurs manags aux APIs systmes ? Sais-tu recevoir des pointeurs en retour de ces mmes APIs ? Dans ce cas deviennent-ils safe ? Comment gres-tu le fait de ne pas forcment avoir de \0 terminal dans tes chanes lorsque tu appelles une fonction qui attends la prsence de ce \0 ? Es-tu capables d'appeler des fonctions variadic ? Etc ...




> l'interoprabilit est, disons, faisable. Actuellement je suis en train de reprendre toutes mes anciennes librairies source C et de les adapter, cela va quand mme assez vite.


Qu'appelles-tu "adapter les librairies C" ? Tu ne penses quand mme pas  les rcrire en safe-C une par une. Mme si unitairement le travail n'est peut tre pas norme (et encore ?), je ne pense pas que porter plusieurs milliers de bibliothques soit vraiment ce que l'on puisse appeler interoprabilit.




> je ne connais pas D mais c'est OO je pense ?


Non, c'est multi-paradigme (tout comme le C++). L'OO n'est qu'un des paradigmes supports.




> le compilateur Safe-C gnre du bon vieux code machine 32-bit pour Windows (processeur Intel/Amd) (je n'ai pas inclus les instructions SSE parce que tous le monde ne les a pas). Le compilateur est dj prvu pour gnrer du 64-bit, ce sera pour plus tard.


Ne trouves-tu pas contradictoire de te plaindre des performances de certains langages et en mme temps ne pas supporter certaines instructions des processeurs qui permettent d'en gagner ? Surtout lorsque les compilateurs pour ces langages sont eux capables de grer ces instructions.




> les performances sont aussi bonnes qu'en C. Les vrifications d'indice de tableau ne gnrent que 2 instructions assembleur en plus, cela ne se remarque mme pas.


La question n'est pas tant le cot des instructions supplmentaires pour la gestions des bornes de tableau (bien que dans certains cas, il est possible de ne pas le faire si la vrification est faite  la compilation) mais de savoir si ton compilateur safe-C optimise aussi bien le code que le ferais un compilateur C.




> non pas encore de debugger, je suis  la version 1 l.


Le problme est qu'il est difficile actuellement de "vendre" un nouveau langage s'il n'a pas un minimum d'cosystme autour.




> Il y a beaucoup de vrifications  la compilation :


Ce qui est, ama, une bonne chose.




> tout doit tre initialis, mme les tableaux (il y a d'ailleurs une commande 'clear' pour effacer une variable)


Dans les exemples que tu donnes, tout n'est pas initialis  la cration. Par contre tout semble l'tre avant la premire utilisation. Est-ce bien de cela que tu parles ?

Certains compilateurs C (par exemple gcc) sont capables de raliser (enfin dans une certaines mesures, certaines constructions complexes posent problmes) ce type de tests.




> le compilateur vrifie aussi que le string "%s%d" d'un printf correspond aux arguments si celui-ci est constant, ce qui vite d'avoir des erreurs  l'excution.


L encore gcc (et probablement d'autres compilateurs) effectuent cette vrification pour les fonctions variadic de la bibliothque standard (dont printf).




> Il y a 2 ou 3 choses nouvelles seulement : un type "opaque" qui est la mme chose que "struct" mais les champs du struct ne sont pas visible dans d'autres fichiers.


Et ce que cel via  la place des structures ou en plus ?
Quel est l'avantage par rapport  la construction classique en C qui consiste  dfinir la structure uniquement dans le fichier source qui implmente les fonctions de celle-ci et de simplement fournir une dclaration incomplte dans le header ?




> des packages gnriques aussi (l'quivalent des templates du C mais simplifis  l'extrme; tout se passe  la compilation, cela remplace en fait les macros du C).


Peux-tu en dire plus (je n'ai rien trouver  ce sujet dans la page que tu as fourni).

Que peut-on faire avec ? Comment est-ce grer ?

----------


## Marc.Samuro

> Q: Il faut rcrire le code ? Si on veut utiliser DirectX, OpenGL ou toutes les autres bibliothques populaires, a reprsente beaucoup de travail ?


R: il faut r-crire des interface pour chacune des libraries oui, par exemple actuellement j'appelle des DLL Windows comme ceci :



```

```

Bref, il faut r-crire les include files de Windows pour le langage, mais je suppose que c'est pareil pour tout nouveau langage.

----------------------------------------------------------------------




> Q: Tandis que le JIT de C# est capable d'utiliser les SSE quand c'est disponible (c'est un avantage du JIT). Gnrer du code efficace n'est pas simple, il y a normment d'optimisations  faire. Mme si C# n'a pas de performances optimales (parce qu'il fait de l'introspection, garde les infos de type  l'excution, parce que le JIT ne peut pas prendre 10s pour optimiser...), a m'intresse de voir des benchmarks avec votre compilateur
> 
> Cela m'intrigue : pourquoi ne pas utiliser un backend existant ? Pourquoi ne pas utiliser par exemple LLVM ? Vous avez vraiment envie de rcrire la gnration de code pour chaque architecture  grer ? La portabilit est quand mme l'un des gros avantages du C, il ne faudrait pas l'oublier..


R: il ne faut pas confondre le langage et le compilateur. Bon ici j'ai cris un compilateur pour windows, j'ai essay d'optimiser au mieux le code gnr mais je suis persuad qu'il y a des spcialistes qui font cela encore mieux que moi.

D'autres personnes peuvent tout  fait crire leur compilateur, j'ai rdig des spcifications techniques trs prcises qui dcrivent le langage en dtails afin que les programmes soient tous portables (voir le lien tout en bas sur la page de dbut du site).

----------------------------------------------------------------------




> Q: Que se passe-t-il si on accde hors d'un tableau (avec un indice variable) ? Ne pensez-vous pas que lancer une exception serait la bonne chose  faire dans ce cas ?


R: En C il n'y a pas d'exceptions, j'ai cris des trs gros programmes professionellement et je n'en ai jamais eu besoin, donc pourquoi en ajouter ?  Une erreur comme un dpassement d'indice est une erreur grave qui ne devrait
jamais arriver et qui demande un arrt du process. Vouloir rattrapper cela par un handler d'exception qui redmarre le programme est une option qu'on peut aussi implmenter en redmarrant le process.

Beaucoup de langages sont trop gros et complexes, je prfre rester minimaliste, comme le C.

----------------------------------------------------------------------




> Q: Et concernant les accs hors borne du tableau ? galement  l'excution ?
> Pourquoi ne pas chercher  vrifier ce qui peut l'tre  la compilation ?


R: le compilateur vrifie les indices de tableau (et aussi de slices de tableau, =tranches)  la compilation si les indices sont des expressions constantes.

----------------------------------------------------------------------




> Q: Quel est le rapport entre le faite d'avoir des classes et la densit de pointeurs dans un programme ?


R: je prcise mon ide : en fait dans les langages OO, quand vous crez une grande variable (classe ou tableau), vous la crez sur le heap. En C (et Safe-C) vous pouvez crer une grande variable structure ou tableau sur la pile, ce qui ne ncessite aucune indirection de pointeur pour y accder (c'est mov eax,[ebp]offset pour charger un champ d'une struct dclare comme variable locale) alors qu'en OO vous avez toujours un pointeur sur chaque classe (mme si a ne s'appelle pas pointeur). Il y a donc beaucoup plus de "pointeurs" (ou indirections) en langage OO qu'en C.

Disons pour parler clairement, les langages OO crent une multitute d'objets sur le heap (pour chaque classe), le C et Safe-C n'en font que si on utilise explicitement des pointeurs.

----------------------------------------------------------------------




> Q: Peux-tu passer tes tableaux et des pointeurs manags aux APIs systmes ? Sais-tu recevoir des pointeurs en retour de ces mmes APIs ? Dans ce cas deviennent-ils safe ?


R: bien sr on sait passer des tableaux aux API. Pour passer l'addresse d'une variable  un API on utilise l'oprateur & comme en C qui permet de prendre l'adresse d'une variable et dont le rsultat est un pointeur (non-manag), exactement comme en C. Evidemment le truc c'est que l'oprateur & n'est autoris qu' l'intrieur d'une section  #begin unsafe  .... #end unsafe, donc gnralement dans une librairie. Les utilisateurs ne sont pas censs
utiliss ces sections unsafe ou en tout cas le moins possible, parce qu'avec elles on programme exactement comme en C, sans scurit.

Je prcise que les pointeurs ne sont pas "manags", les objets ne bougent pas, il n'y pas de garbage collection et il faut faire ses free soi-mme (il y un oprateur "new" trs riche pour crer mme des struct et tableau dynamiques, et une commande free).

----------------------------------------------------------------------




> Q: Comment gres-tu le fait de ne pas forcment avoir de \0 terminal dans tes chanes lorsque tu appelles une fonction qui attends la prsence de ce \0 ?


R: il faut recopier la chaine et ajouter un zro, pareil qu'en C#, pour tous les APIs qui ont besoin d'un PSTR. J'ai constat qu'il n'y en a pas tant que cela en pratique dans l'API windows, et aucun pour des fonctions qui doivent tre performantes comme read & write.

//----------------------------------------------------------------------------




> Q: Es-tu capables d'appeler des fonctions variadic ?


R: oui mais elle ne sont pas passes comme en C. Les addresses et tailles des arguments variables sont tous rassembls et mis dans un tableau et l'adresse du tableau est pass comme 1 paramtre. Je pense que le C# fait comme cela aussi. L'utilisateur peut donc crer sans problme des fonctions  nombre de paramtres variables comme printf, fprintf, etc .. avec scurit totale.

//----------------------------------------------------------------------------




> Q: Qu'appelles-tu "adapter les librairies C" ?


R: j'ai une collection de librairies source C que je soigne depuis 10 ans, pour tcpip, traitement d'image, ... Je pense qu'en 3 mois j'aurai tout adapt en Safe-C pour que je puisse continuer  programmer dans ce langage. Maintenant n'importe qui peut crer ses propres librairies, c'est comme en C, on peut partir de zro.

//----------------------------------------------------------------------------




> Q: Ne trouves-tu pas contradictoire de te plaindre des performances de certains langages et en mme temps ne pas supporter certaines instructions des processeurs qui permettent d'en gagner ? Surtout lorsque les compilateurs pour ces langages sont eux capables de grer ces instructions.


R: j'cris des programmes qui sont distribus sur internet et qui donc doivent tourner sur toutes les versions de Windows et tous les CPU. Actuellement pour mes librairies je n'utilise que des API  partir de Windows 2000 et aucune instruction SSE. Maintenant il est possible que je propose un petit moteur 3D avec des instructions SSE2 inline (c'est pratique pour multipler 4 float en 1 instruction  ::):  mais alors avec avertissement que ce n'est pas pour toutes les machines.

//----------------------------------------------------------------------------




> Q: Dans les exemples que tu donnes, tout n'est pas initialis  la cration. Par contre tout semble l'tre avant la premire utilisation. Est-ce bien de cela que tu parles ?


R: oui, toutes les variables doivent tre initialises  la premire utilisation. Le compilateur suit le flot des instructions et vrifie cela. C'est trs important pour la scurit. Initialiser un champ d'un struct ne suffit pas pour que le struct soit considr comme initialis, il faut soit un "clear", soit une assignation  la variable entire. Le langage a un trs bon support pour les constantes (simple, tableau, struct, jagged) ainsi que les aggregates, afin de rendre simple ces initialisations.

Un exemple:

   date = {day => 1, month => 1, year => 2011};

//----------------------------------------------------------------------------




> Q: Et ce que cel via  la place des structures ou en plus ?
> Quel est l'avantage par rapport  la construction classique en C qui consiste  dfinir la structure uniquement dans le fichier source qui implmente les fonctions de celle-ci et de simplement fournir une dclaration incomplte dans le header ?


R: un type opaque est dfini comme ceci dans le .h :

   struct MON_TYPE;

Dans le .c correspondant, il doit y avoir la dclaration complte :

   struct MON_TYPE;
   {
      int a, b, c;
   }

Donc videmment si un autre fichier "importe" le .h il n'a pas accs aux champs.

Je signale qu'il n'y a pas "d'#include" comme en C, c'est plus un import de libraries comme en C#, ce qui a pas mal d'avantages : l'ordre des imports n'a pas d'importance, il ne faut pas inclure une librairie avant une autre.

A signaler aussi : le compilateur 'trouve' automatiquement les fichiers  inclure. Si vous faites :

// main.c

use sys/mylib;


Il va chercher un fichier mylib.h dans le rpertoire ./sys et le compiler, ensuite il va voir s'il n'y a pas un mylib.c correspondant dans le mme rpertoire. Bref, plus la peine d'crire des makefile, le compilateur trouve les fichiers tout seul en suivant les "use" dans chaque fichier.

//----------------------------------------------------------------------------




> Q: Peux-tu en dire plus (je n'ai rien trouver  ce sujet dans la page que tu as fourni).
>    Que peut-on faire avec ? Comment est-ce grer ?


R:
Les packages gnriques c'est une ide que j'ai repris du langage Ada en simplifiant.

En gros : un gnrique consiste  crire un morceau de code en "paramtrant" un ou plusieurs "type" que vous ne spcifiez pas. Le compilateur va compiler ce gnrique en le vrifiant syntaxiquement, mais il ne va pas en gnrer de code assembleur.

Une fois crit, vous pouvez "instancier" ce package en spcifiant des types  la place des paramtres. Lors d'une commande d'instantiation le compilateur va prendre une copie du package gnrique, remplacer les types paramtres par vos types et gnrer du code. Tout cela se passe  la compilation. a ressemble  une macro en C sauf que le package gnrique est vrifi syntaxiquement. On peut aussi imbriquer un package gnrique dans un autre comme on imbrique une macro dans une autre.

C'est une forme trs simple de gnrique, destine par exemple  crire des routines de tri, d'arbres binaires qui ont des noeuds qui portent des donnes, bref, plutt des algorithmes qui resteront dans une librarie.

Aprs avoir tudi l'utilisation pratique des gnriques par 99% des programmeurs, je n'ai cr qu'un seul genre de type gnrique, priv, qui permet les assignations uniquement, c'est beaucoup plus simple que dans les autres langages, mais aussi plus comprhensible.

Il y a un exemple de gnrique pour bubble-sort au chapitre 9. Generics (le manuel de rfrence est le lien tout en bas sur la page de dbut du site).

//----------------------------------------------------------------------------

----------


## gl

> R: il ne faut pas confondre le langage et le compilateur. Bon ici j'ai cris un compilateur pour windows, j'ai essay d'optimiser au mieux le code gnr mais je suis persuad qu'il y a des spcialistes qui font cela encore mieux que moi.
> 
> D'autres personnes peuvent tout  fait crire leur compilateur, j'ai rdig des spcifications techniques trs prcises qui dcrivent le langage en dtails afin que les programmes soient tous portables (voir le lien tout en bas sur la page de dbut du site).


Certes cela ne relve pas du langage et reste du domaine de la qualit d'implmentation.

Mais d'une part si la seule implmentation dudit langage souffre de souci de performance, cela ne va pas forcment aider  faire adopter ce langage.
D'autre part, rejeter une autre langage en prtextant de mauvaises performances pour au final ne pas proposer certaines optimisations que lui fait, c'est assez ... surprenant.

Quant  l'argument de ne pas utiliser des instructions qui ne pourraient n'tre pas prsente, c'est effectivement trs louable comme objectif. Mais il reste possible de le proposer en option du compilateur.




> Q: Et concernant les accs hors borne du tableau ? galement  l'excution ?
> Pourquoi ne pas chercher  vrifier ce qui peut l'tre  la compilation ?
> 
> R: le compilateur vrifie les indices de tableau (et aussi de slices de tableau, =tranches)  la compilation si les indices sont des expressions constantes.


OK donc si je comprends bien :



```

```

va lever une erreur  la compilation. 

Par contre si je suis les exemples donns, le code suivant :



```

```

ne donnera qu'une erreur  l'excution (alors qu'elle est vrifiable  la compilation).

J'admets que a peut relever davantage du domaine de la qualit d'implmentation que de la dfinition stricte du langage, mais c'est dommage.




> R: je prcise mon ide : en fait dans les langages OO, quand vous crez une grande variable (classe ou tableau), vous la crez sur le heap. En C (et Safe-C) vous pouvez crer une grande variable structure ou tableau sur la pile, ce qui ne ncessite aucune indirection de pointeur pour y accder (c'est mov eax,[ebp]offset pour charger un champ d'une struct dclare comme variable locale) alors qu'en OO vous avez toujours un pointeur sur chaque classe (mme si a ne s'appelle pas pointeur). Il y a donc beaucoup plus de "pointeurs" (ou indirections) en langage OO qu'en C.
> 
> Disons pour parler clairement, les langages OO crent une multitute d'objets sur le heap (pour chaque classe), le C et Safe-C n'en font que si on utilise explicitement des pointeurs.


C'est peut tre vrai pour certains langages, mais il ne faut pas gnraliser.

Typiquement en C++, on peut tout  fait crer des classes sur la pile.




> Je prcise que les pointeurs ne sont pas "manags", les objets ne bougent pas, il n'y pas de garbage collection et il faut faire ses free soi-mme (il y un oprateur "new" trs riche pour crer mme des struct et tableau dynamiques, et une commande free).


Manag n'est peut tre le bon terme (c'est vrai qu'il a une connotation trs "garbage collect"). Parlons de safe-pointeur si tu prfres.




> R: il faut recopier la chaine et ajouter un zro, pareil qu'en C#, pour tous les APIs qui ont besoin d'un PSTR. J'ai constat qu'il n'y en a pas tant que cela en pratique dans l'API windows, et aucun pour des fonctions qui doivent tre performantes comme read & write.


Donc  l'appelant de le grer.




> R: oui mais elle ne sont pas passes comme en C. Les addresses et tailles des arguments variables sont tous rassembls et mis dans un tableau et l'adresse du tableau est pass comme 1 paramtre. Je pense que le C# fait comme cela aussi. L'utilisateur peut donc crer sans problme des fonctions  nombre de paramtres variables comme printf, fprintf, etc .. avec scurit totale.


Je parlais d'appeler des fonctions variadic exposes par une DLL en C. 




> R: un type opaque est dfini comme ceci dans le .h :
> 
>    struct MON_TYPE;
> 
> Dans le .c correspondant, il doit y avoir la dclaration complte :
> 
>    struct MON_TYPE;
>    {
>       int a, b, c;
> ...


C'est qui se fait en C.




> Je signale qu'il n'y a pas "d'#include" comme en C, c'est plus un import de libraries comme en C#, ce qui a pas mal d'avantages : l'ordre des imports n'a pas d'importance, il ne faut pas inclure une librairie avant une autre.


En C non plus l'ordre des header n'a pas d'importance sauf si le header a t crit avec les pieds.
Mais je pense comprendre ce que tu cherches  dire.




> A signaler aussi : le compilateur 'trouve' automatiquement les fichiers  inclure. Si vous faites :
> 
> // main.c
> 
> use sys/mylib;
> 
> 
> Il va chercher un fichier mylib.h dans le rpertoire ./sys et le compiler, ensuite il va voir s'il n'y a pas un mylib.c correspondant dans le mme rpertoire. Bref, plus la peine d'crire des makefile, le compilateur trouve les fichiers tout seul en suivant les "use" dans chaque fichier.


Si les dpendances et la compilation incrmentale sont gres, c'est intressant (au passage c'est ce que font les compilateurs JIT).

Note toutefois que l'utilisation d'un mcanisme type make, ant ou autre permettant d'effectuer d'autres tches que la simple compilation lors d'une gnration (gnration de la doc, paquetage, archivage, dploiement, etc.)




> En gros : un gnrique consiste  crire un morceau de code en "paramtrant" un ou plusieurs "type" que vous ne spcifiez pas. Le compilateur va compiler ce gnrique en le vrifiant syntaxiquement, mais il ne va pas en gnrer de code assembleur.
> 
> Une fois crit, vous pouvez "instancier" ce package en spcifiant des types  la place des paramtres. Lors d'une commande d'instantiation le compilateur va prendre une copie du package gnrique, remplacer les types paramtres par vos types et gnrer du code. Tout cela se passe  la compilation. a ressemble  une macro en C sauf que le package gnrique est vrifi syntaxiquement. On peut aussi imbriquer un package gnrique dans un autre comme on imbrique une macro dans une autre.


OK, je vois.

----------


## LLB

> R: il ne faut pas confondre le langage et le compilateur. Bon ici j'ai cris un compilateur pour windows, j'ai essay d'optimiser au mieux le code gnr mais je suis persuad qu'il y a des spcialistes qui font cela encore mieux que moi.


C'tait le sens de ma question. crire un backend demande du travail (qui doit tre en partie refait pour chaque archi), pourquoi n'avez-vous pas cherch  en rutiliser un existant ? Vous l'avez compris, c'est une question sur l'implmentation et non le langage. Si vous ne faites pas au moins les optimisations sur les tail calls, la propagation des constantes, l'inlining et une bonne allocation des registres (de type coloriage de graphe), je prdis des rsultats plus lents que ceux obtenus par C#. Ce serait le comble, puisque vous sacrifiez grand nombre de fonctionnalits au nom des performances.

(cf. les passes de LLVM et l'article Wikipedia sur les optimisations)
Je suis persuad qu'utiliser LLVM (ou autre) amliorerait beaucoup de choses.

Je ne vais pas rpondre  tous les points, mais je dirai juste que je ne suis pas convaincu par Safe-C. Si on crit du C++ proprement, en vitant l'arithmtique des pointeurs et en utilisant la STL, on obtient quelque chose d'assez sr (autant que Safe-C) tout en restant trs rapide. Si on est prt  sacrifier 5% de la vitesse, il y a le D. Si on accepte de perdre un peu plus de vitesse, mais pas tant que a, il y a alors normment d'alternatives bien sres et plus haut-niveau (qui incluent un GC).

----------


## Marc.Samuro

Q: crire un backend demande du travail (qui doit tre en partie refait pour chaque archi), pourquoi n'avez-vous pas cherch  en rutiliser un existant ?

R: et bien tout btement parce que je ne le connaissait pas .. le seul back-end que j'ai regard c'est celui de microsoft qui utilise du MSIL je crois, mais a m'a paru tellement compliqu que j'ai laiss tomber et j'ai prfr refaire quelque chose que je maitrise compltement. Au moins la doc d'Intel et AMD est claire.

----------


## Marc.Samuro

Dans mon environnement professionnel, je constate que tout le monde passe au Java ou bien C#, c'est pratiquement invitable, malgr ces bibliothques horriblement compliques o on passe son temps  chercher la bonne classe puis la bonne fonction et qui sont de plus en plus abstraites.

Et si on proposait de revenir  quelque chose de simple, un langage  taille humaine, donc faire un projet en C, on vous regarderait de travers en disant : "vous imaginez 10 programmeurs en train d'crire un programme multithread de 30,000 lignes ?  la moindre faute de pointeur vous auriez des plantages non-reproductibles que seriez incapable de diagnostiquer et corriger et cela nous couterait trop cher." Je crois que c'est pour a j'ai commenc le Safe-C, pour proposer une alternative.

----------


## LLB

> Je crois que c'est pour a j'ai commenc le Safe-C, pour proposer une alternative.


Si je comprends bien, vous voyez votre langage en concurrence de C# et Java. C'est tonnant.  moins d'avoir des contraintes particulirement fortes (systme temps-rel, embarqu, drivers...), l'utilisation du C n'a pas beaucoup de sens.




> le seul back-end que j'ai regard c'est celui de microsoft qui utilise du MSIL je crois, mais a m'a paru tellement compliqu que j'ai laiss tomber


Heureusement ! MSIL est l'assembleur de .NET, c'est--dire que vous auriez eu toutes ces choses que vous semblez dtester : garbage collector, VM, JIT, objets...




> je constate que tout le monde passe au Java ou bien C#


Il y a peut-tre d'autres raisons que le seul fait de reproduire des bugs ?

----------


## Sve@r

Beaucoup d'arguments de part et d'autres. Toutefois, il y a une chose essentielle qui n'a pas t dite (ou alors que j'ai rate), c'est que si le C est aussi rapide et aussi lger, c'est justement parce qu'il ne vrifie rien de faon totalement volontaire. Sa philosophie est "le programmeur sait ce qu'il fait". Evidemment si le programmeur fait du C sans savoir ce qu'il fait... ou sans tre capable de se grer lui-mme ses pointeurs et ses indices de tableaux, alors le C n'est pas fait pour lui.
Donc un langage volontairement sans aucun garde-fou mais en retour on a une vitesse ingale et une taille minime qui permet mme d'embarquer des codes C sur des micro contrleurs robots.

De plus, pour celui qui prfre tre protg, il existe tout un tas d'autres langages moins rapides mais avec plus de protections et qui vont mme jusqu' intgrer l'objet et la gestion automatique de la mmoire (Perl, Python par exemple).

Et donc, Marc.Samuro, tu nous proposes un langage "comme le C" (c'est  dire quand-mme bien chiant il faut le dire car crire 45 lignes pour agrandir un tableau l o a s'crit en une ligne de Python moi mme si j'aime beaucoup le C ben a me prends quand-mme la tte...) et o tu lui as enlev son avantage principal pour le remplacer par un autre qu'on trouve dj par ailleurs. Dsol, perso a ne m'intresse pas...

----------


## Marc.Samuro

oui le choix du langage dpend videmment du type de programmes qu'on crit, et dpend si on privilgie la vitesse ou la scurit.

Quand je programme pour moi je recherche plutt la vitesse donc ce n'est pas tonnant que je suis programmeur C depuis + de 10 ans; le problme que j'ai avec cela depuis quelque temps c'est qu'il m'est dj arriv de passer plusieurs jours dans le debugger en train de chercher comment diable une variable pouvait avoir reu une valeur que normalement elle ne devrait pas,
et finalement sans trouver la rponse. Les programmes qu'on distribue sur internet ce sont les pires  corriger parce qu'on reoit un rapport d'erreur et on essaye tant bien que mal de reproduire le problme sur son PC.

On finit par douter de tout, on finit par suspecter les DLL, ou on se demande si ce n'est pas  cause d'un programme que tel utilisateur a encore install sur son PC (par ex des antivirus buggs peuvent causer des problmes en se chargeant comme DLL, on dsinstalle l'antirirus et le problme disparait).

Chez Microsoft ils recoivent des rapports d'erreur sur des plantages de windows que des quipes sont charges d'analyser, ce n'est pas triste non plus. J'ai eu l'occasion de lire des articles qui expliquaient que parfois
ils trouvent encore des bugs assez normes que personne n'a vu.

Je vois aussi autour de moi des programmes buggs (acrobat reader qui a des dpassement de pile  plein d'endroits, le viewer second life qui crashe 5 fois par heure, etc ..).

Tout cela ce sont des programmes crits sans scurit afin d'avoir une vitesse maximale, mais cette vitesse a un prix : c'est une qualit de logiciel moindre, bref des plantages, et un cot trs lev pour les corriger.

Je suis toujours pour la vitesse, mais maintenant je veux un trs mince filet de scurit  100% pour ne plus avoir des maux de tte dans le dbugger. De la scurit aussi lgre que possible pour ne pas ralentir les programmes.
Par exemple 2 instructions assembleur en plus pour vrifier chaque indice de tableau ne me gnent pas trop, on ne peut pas parler d'un ralentissement gnant.

Il y a des langages qui vont au-del de la scurit et qui proposent des fonctions plus agrables  utiliser pour le programmeur (typiquement tous les langages avec garbage collection), mais a a un impact beaucoup plus important sur la vitesse. Je vois rgulirement au boulot des applications C# ou Java franchement lentes ou avec des temps de rponse bien infrieurs
 ce qu'on peux faire raliser en C, je trouve cela navrant que les jeunes programmeurs ne savent plus crer du code rapide.

----------


## Marc.Samuro

mais la technologie va peut-tre tout changer : je souriais dernirement en relisant le livre de C de Kernigan et Richie :  un moment ils proposent 2 versions d'un programme, l'une avec tableau et l'autre avec pointeurs, et ils conseillaient la version avec pointeur beaucoup plus rapide disaient-ils, par ce que sur leur processeur (PDP11 je crois), la multiplication des indices par la taille des lments pour calculer l'offset du tableau tait horriblement lente.

----------


## Sve@r

> mais la technologie va peut-tre tout changer : je souriais dernirement en relisant le livre de C de Kernigan et Richie :  un moment ils proposent 2 versions d'un programme, l'une avec tableau et l'autre avec pointeurs, et ils conseillaient la version avec pointeur beaucoup plus rapide disaient-ils, par ce que sur leur processeur (PDP11 je crois), la multiplication des indices par la taille des lments pour calculer l'offset du tableau tait horriblement lente.


Les pointeurs peuvent amliorer les performances dans le cas o on accde un grands nombres de fois aux lments d'un tableau. Passer par l'indice implique qu' chaque accs, le proc se place au dbut du tableau et dcale ensuite de l'indice * taille lment.
Alors qu'avec un pointeur dj positionn sur le bon lment, toute cette opration saute. Et a, c'est autant valable aujourd'hui qu'il y a 40 ans.

Toutefois, ce qu'on a aujourd'hui c'est des compilos de plus en plus intelligents qui sont capables de dtecter les trucs de ce genre et faire eux-mme le remplacement...

----------


## souviron34

> je souriais dernirement en relisant le livre de C de Kernigan et Richie :  un moment ils proposent 2 versions d'un programme, l'une avec tableau et l'autre avec pointeurs, et ils conseillaient la version avec pointeur beaucoup plus rapide disaient-ils, par ce que sur leur processeur (PDP11 je crois), la multiplication des indices par la taille des lments pour calculer l'offset du tableau tait horriblement lente.



ne souris pas trop  ::aie:: 

C'est effectivement une optimisation courante dans de gros programmes : par exemple les programmes de biochimie et de recherche dans le domaine de la gntique, mais aussi dans normment de calculs scientifiques, traitements de grosses images satellites ou mdicales, etc etc...

Et on voit bien que tu n'as pas trop l'exprience de a, car les gains peuvent tre faramineux : j'ai eu le cas il y a juste 4 ans d'un gain de environ 1200 %, c'est  dire passer de 18h de calcul  20 minutes juste par le fait de remplacer des indices de tableau  l'intrieur de boucles en adresses....

Sans parler de l'ordre des boucles, qui a fini par amener  5 minutes de calcul le mme programme...

Mais faire 200 millions de fois des sries (1 addition et 1 multiplicatio) (pour un seul indice), a cote.. Et quand il y a par exemple 3 ou 4 indices dans le tableau, c'est "hors de prix" par rapport au fait de se rfrer aux adresses...




Maintenant, ton ide est certainement louable, mais un certain nombre d'arguments ont t donns plus haut, et j'en rajouterais un.. :

tant donn qu'un des normes avantages des  langages deuis le C est la programmation dynamque, comment ferais-tu pour "vrifier  la compliation ou au runtime" quelque chose qui soit comme :




```

```

puis dans une fonction quelque pat :



```
buf[nb] = 'a' ;
```

ici je prend scanf, mais dans l'crasante majorit des cas ce serait un sscanf aprs avoir lu la ligne dans un fichier...


Comme le dit _Sv@r_, le C a volontarement laiss de ct les vrifications, et est fait pour des gens qui savent ce qu'ils font.. Et quand ils ne savent pas, ou bien ils apprennent, ou a les dgoute et ils vont vers un langage plus encadr...


Moi aprs 23 ans de programmation C, le C me convient parfaitement avec sa souplesse....



PS: c'est pas bien de faire du spam/multiposting sur le forum, et de dtourner des dbats (_dans la partie General Dveloppements_)....

----------


## Marc.Samuro

> Q: comment ferais-tu pour "vrifier  la compliation ou au runtime"


En safe-C, il y a 3 types d'objets qu'on peut rserver sur le heap :

*a - les objets de taille constante* (types simples, struct ou tableaux de longueur constante)

exemple:


```
  T^ p = new T;
```

donc l, pas de problme, un pointeur vers T sera toujours un pointeur vers T.


*b - les objets tableau dynamique*

exemple:


```
  float[]^ p = new float[n];
```

si 'float' occupe 4 bytes, p pointe sur une zone de 4 + n*4 bytes car il y a un header de 4 bytes au dbut de l'objet heap qui contient la longueur du tableau. p ne pourra pointer que sur des tableaux dynamiques de float;
donc si on fait : p^[n] = 1.2;  // n est vrifi grce au header de p

Faisons un petit exercice acadmique : si j'ai envie d'agrandir le tableau, disons de le rendre 2 x plus grand :



```

```

Si je veux connaitre la longueur d'un tableau j'utilise l'attribut 'length :


```
   longueur = p^'length;   // va chercher la longueur dans le header de l'objet point par p
```

*c- les structs avec variantes* 



```

```

ici p ne peut pointer que sur une struct S.
On rserve un objet heap ayant un header de 4 bytes qui contenant le discriminant (ici c) + les champs de la structure. La taille totale de l'objet dpend de la valeur c  l'excution. (il y a un tableau constant qui permet au runtime de calculer la taille de S pour chaque valeur de c)

Si on fait :  

```
 p^.rayon = 2;  // vérifie que le header de p == CERCLE.
```

C'est limit  ces 3 formes parce que ce sont les plus courantes. Si vous voulez quelque chose de plus inhabituel (par exemple un struct avec un tableau qui suit la struct pour ne consommer qu'une allocation au lieu de deux, par exemple pour stocker les lignes de texte d'un diteur), il faut travailler "sans filet" avec les unsafe pointers qui sont les mmes qu'en C.

Tout programme a des sections qui doivent tre optimises  fond : par exemple ce n'est pas trs utile de vrifier les indices de tableau lors d'une multiplication de matrices parce que les 2 boucles imbriques sont tellement simples qu'on 'voit  l'oeil nu' qu'on ne risque pas de sortir du tableau. Pour cela, en Safe-C, on peut utiliser les unsafe pointers du C : donc les oprateurs &, * et -> habituels, ainsi que les [] sur un pointer unsafe.

Exemple:


```

```

Pour avoir une ide du cot de ces vrifications, le code pour vrifier l'indice dans :


```
  p^[n] = 1.2;
```

Une fois qu'on a 'n' dans un registre (par ex: eax), et p^ dans un autre (par ex: esi), on fait :


```

```



p.s.: si quelqu'un peut m'expliquer comment on peut formater un message sur le forum ici, j'ai toutes mes lignes colles  gauche quand je publie.

----------


## diogene

> p.s.: si quelqu'un peut m'expliquer comment on peut formater un message sur le forum ici, j'ai toutes mes lignes colles  gauche quand je publie.


Tu peux dj utiliser les balises [CODE] (et les lignes ne seront alors plus tasses  gauche et le formatage sera conserv)  et [QUOTE] comme celles que j'ai places sur ton message.

----------


## Sve@r

> Q: comment ferais-tu pour "vrifier  la compliation ou au runtime" 
> R: 
> 
> En safe-C, il y a 3 types d'objets qu'on peut rserver sur le heap :
> 
> a - les objets de taille constante
> 
> exemple:
> 
> ...


Mouais bof. Comme en C++ quoi...





> b - les objets tableau dynamique
> 
> exemple:
> 
>   float[]^ p = new float[n];
> 
> si 'float' occupe 4 bytes, p pointe sur une zone de 4 + n*4 bytes car il y a un header de 4 bytes au dbut de l'objet heap qui contient la longueur du tableau. p ne pourra pointer que sur des tableaux dynamiques de float;
> 
> donc si on fait : p^[n] = 1.2;  // n est vrifi grce au header de p


Mouais. Comme le fait le Pascal...




> Faisons un petit exercice acadmique : si j'ai envie d'agrandir le tableau, disons de le rendre 2 x plus grand :
> 
>   float[]^ q;
> 
>   q = new float[n*2];    // allouer header de 4 bytes + (2*n) lments
> 
>   q^[0:n] = p^;    // recopier les n premiers lments  (tranche commenant  l'indice 0, de n lments)
>   q^[n:n] = {all=> 0.0};   // le reste  zro (tranche commenant  l'indice n, de n lments)


Ah, l on trouve une syntaxe typique Python. Saut qu'en Python il n'y a pas ce petit chapeau inutile.




> free p;   // librer l'ancien tableau
>   p = q;   // maintenant p pointe vers le grand tableau


Oh superbe. On lance un ordre de libration de p puis on indique  p une nouvelle adresse. T'as pas peur que 95% des programmeurs oublient le free p ? Surtout qu'apparemment tu inventes ce langage spcialement pour programmeurs dbiles non ?





> Si je veux connaitre la longueur d'un tableau j'utilise l'attribut 'length :
> 
>    longueur = p^'length;   // va chercher la longueur dans le header de l'objet point par p


Mouais. Bref tu rinventes Python mais en moins bien quoi. Tu veux un conseil srieux ? Commence par apprendre d'autres langages. J'ai parl plusieurs fois de Python (normal, je m'y suis mis en 2005 et depuis j'ai bascul) donc intresses-y toi et tu verras que tout ce que tu proposes a dj t fait dans ce langage. Et tu veux savoir la meilleure ? C'est que Python a t crit en... C.




> p.s.: si quelqu'un peut m'expliquer comment on peut formater un message sur le forum ici, j'ai toutes mes lignes colles  gauche quand je publie.


Tu encadre tes lignes avec des balises CODE et /CODE

----------


## Marc.Samuro

merci pour les infos de formatage, j'ai essay de r-diter mais a me met des parties en rouge donc je laisse comme cela ..
Ah, merci pour le formatage, je ferais mieux la prochaine fois, promis )


*A svear :*




> T'as pas peur que 95% des programmeurs oublient le free p ?


Le but du Safe-C est d'empcher que par une erreur d'inattention, une partie du code corrompe la mmoire d'une autre partie du code en dehors des rgles du langage, parce que cela cre des erreurs non reproductibles trs difficiles  dbugger sur les gros programmes multithread.
Un oubli de free p ne peut pas corrompre la mmoire.
Par contre un double free le peut, c'est a c'est dtect.



Python possde des classes, des exceptions, un garbage collector, des nombres complexes, des tableaux associatifs, des sets, supporte la surcharge d'oprateurs, un gnrateur yield, la rflexivit, ..

C'est un langage d'une complexit probablement 10 ou 20 fois plus grande qu'un langage proche de la machine comme le C ou Safe-C. Une comparaison entre les deux c'est comme comparer un boxeur poids lger et poids lourd ..

----------


## Sve@r

> C'est un langage d'une complexit probablement 10 ou 20 fois plus grande qu'un langage proche de la machine comme le C ou Safe-C. Une comparaison entre les deux c'est comme comparer un boxeur poids lger et poids lourd ..


Ah ben oui. Python est un langage trs encadr o tu te sens en scurit. Tu peux taper dans tab[n] en toute quitude, si n >= len(tab) t'auras une erreur immdiate  l'excution avec le n de ligne et tu pourras corriger facilement. 
On en revient donc toujours au mme point. Faire un langage "comme le C" (sous-entendu aussi galre  crire) et en y rajoutant "quelques protections" qui dgraderont forcment ses performances sans apporter vraiment la quitude des langages encadrs moi a ne m'intresse pas et j'ai pas l'impression que a intresse grand monde ici. Mais si t'es motiv alors lance-toi. Aprs-tout, c'est comme a que le crateur de Facebook est devenu multi-milliardaire...

----------


## Marc.Samuro

disons si le C est  100% de vitesse,

C++ (avec ses containers) et Safe-C (avec ses vrifications d'indices)seraient peut-tre entre 75% et 95% (c'est trs difficile  estimer videmment puisque cela dpend trs fort du type de programme)

Si on commence  utiliser un langage  Classes comme C#, Java ou Python avec garbage collector, .. l je n'ose pas donner de pronostic mais c'est srement bien plus lent et lourd pour la machine vu le nombre d'objets crs ..

Vous mettez Safe-C et Python sur le mme niveau de vitesse d'excution, pas d'accord l ..

----------


## gl

> C'est un langage d'une complexit probablement 10 ou 20 fois plus grande qu'un langage proche de la machine comme le C ou Safe-C. Une comparaison entre les deux c'est comme comparer un boxeur poids lger et poids lourd ..


Je pense que tu mlanges plusieurs notions quand tu parles de complexit.

Les langages types C++, C#, Python, Java, etc. sont effectivement plus riche en concept que peut l'tre le C et dans ce sens effectivement, on fait peut tre plus rapidement le tour du C que dans d'autres langages (et encore).

D'un autre ct, il est possible de faire des choses tout  fait srieuse et convenable sans maitriser tout les aspects d'un langage.
Mais surtout ce sont des concepts de plus haut niveau qui sont gnralement plus simple  apprhender mais surtout  utiliser.




> disons si le C est  100% de vitesse,
> 
> C++ (avec ses containers) et Safe-C (avec ses vrifications d'indices)seraient peut-tre entre 75% et 95% (c'est trs difficile  estimer videmment puisque cela dpend trs fort du type de programme)
> 
> Si on commence  utiliser un langage  Classes comme C#, Java ou Python avec garbage collector, .. l je n'ose pas donner de pronostic mais c'est srement bien plus lent et lourd pour la machine vu le nombre d'objets crs ..


Tes chiffres tu les sors d'o ? Est-ce juste un ide en l'air comme a ou as tu un vrai bench ?

sans vouloir te vexer, tu devrais vraiment faire les mesures, tu risques d'tre surpris.
D'autant que la qualit des algos, du code, du compilateur et des bibliothques utilis intervient certainement plus que le langage.

----------


## Marc.Samuro

j'ai trouv un petit benchmark ici (il est un peu vieux 2004, peut-tre quelqu'un en a-t-il d'autres ?  j'espre que Python est plus rapide qu'en 2004)

http://www.osnews.com/story/5602/Nin...ile_I_O/page3/

c'est bien difficile de trouver un bon benchmark, ce n'est plus  la mode d'en faire on dirait ?!

Ah ici c'est pas mal -> http://www.paperblog.fr/580507/debia...isis-ton-camp/

----------


## orfix

> ```
> 
> ```


    Pourquoi l'as-tu appel safe-*C* ? Cette syntaxe n'a absolument rien  voir avec celle du C.

    Je suis loin d'tre un spcialiste en la matire, mais je sais toutefois qu'il faut d'abord crire la syntaxe en notation EBNF (ou BNF) pour mettre les choses au clair.

    As-tu dj dfini d'autres langages ou crit des compilateurs ?

----------


## Marc.Samuro

> Cette syntaxe n'a absolument rien  voir avec celle du C.


les pointeurs ont une syntaxe diffrente pour les diffrencier des pointeurs pas vrifis, et la notation tab[a:b] c'est nouveau oui pour prendre une tranche de tableau (indispensable pour remplacer le memcpy), mais sinon les 95% de la syntaxe est identifique.

par exemple ceci fonctionne aussi bien en C, qu'en C++, qu'en Safe-C :



```

```

J'ai une description de la syntaxe, c'est un peu long  poster ici. Avant de commencer un compilateur on doit avoir bien dfini la syntaxe tout  fait sinon c'est la galre si a change en cours de route.


Voici encore un petit exemple, cela donne une ide de la syntaxe (string est dfini comme char[], les include sont diffrents oui parce qu'on peut spcifier de quelle librairie on inclut) :



```

```

----------


## gl

> j'ai trouv un petit benchmark ici (il est un peu vieux 2004, peut-tre quelqu'un en a-t-il d'autres ?  j'espre que Python est plus rapide qu'en 2004)
> 
> http://www.osnews.com/story/5602/Nin...ile_I_O/page3/
> 
> c'est bien difficile de trouver un bon benchmark, ce n'est plus  la mode d'en faire on dirait ?!
> 
> Ah ici c'est pas mal -> http://www.paperblog.fr/580507/debia...isis-ton-camp/


Outre le fait que dans le premier je ne trouve pas les sources utiliss (ce qui me laisse toujours dubitatif quant  la pertinence du bench), ils ne me semblent pas indiquer que le C++ atteigne systmatiquement entre 75 et 95% des performances du C, ni que C#, Java ou Python soit forcment toujours bien plus lent que le C.

Mon propos n'est pas de dire que tel ou tel langage est beaucoup plus rapide que tel autre, mais juste d'attirer ton attention sur le fait que la ralit n'est pas aussi tranche que tu sembles le croire.
Et si tu fais rentrer des critres lis  la qualit des compilateurs et bibliothques,  la comptence des dveloppeurs ou au temps pass, l'quation devient encore plus complexe.

----------


## gl

> par exemple ceci fonctionne aussi bien en C, qu'en C++, qu'en Safe-C :
> 
> 
> 
> ```
> 
> ```


En Safe-C je ne sais pas, mais ce code s'il peut fonctionner sur une implmentation particulire n'est pas portable en C ou C++.

----------


## Marc.Samuro

> ils ne me semblent pas indiquer que Java ou Python soit forcment toujours bien plus lent que le C.


??? le tableau est pourtant trs parlant : http://shootout.alioth.debian.org/gp...1&threadring=1

En tout cas il conforte mon argumentation que les langages avec garbage collector sont une catgorie plus lente que la famille C/C++/Safe-C.

----------


## gl

> ??? le tableau est pourtant trs parlant : http://shootout.alioth.debian.org/gp...1&threadring=1


Tout d'abord prend le bench  jour (le lien que tu fournis est not out of date).

Regardons un test particulier, par exemple binary-tree. Et l on trouve :
C GNU gcc : 34.52s
C GNU gcc #7 : 12.10s
C GNU gcc #5 : 66.29s
Java 6-server : 15.80s
Soit trois versions du programme en C ayant des rsultats du simple ou sextuple et un Java plus proche du premier que des deux autres.

En reprenant le premier bench dont tu as donn le lien :
Sur le test trig :
gcc C	 : 14.9
Python/Psyco : 13.1

Sur long math :
gcc C : 28.8
Java 1.4.2 : 20.2


Personnellement, je ne trouve qu'il soit vident que "les langages avec garbage collector sont une catgorie plus lente que la famille C/C++/Safe-C". Pas toujours.

Non c'est loin d'tre aussi simple que le C c'est rapide, les langages objets garbage-collects c'est bien plus lent.

----------


## souviron34

> ici p ne peut pointer que sur une struct S.


Tu ne peux donc pas avoir un type void*, ce qui est quand mme une des "features" majeures de C..







> *Si vous voulez quelque chose de plus inhabituel* (par exemple un struct avec un tableau qui suit la struct pour ne consommer qu'une allocation au lieu de deux, par exemple pour stocker les lignes de texte d'un diteur), il faut travailler "sans filet" avec les unsafe pointers qui sont les mmes qu'en C.
> 
> Tout programme a des sections qui doivent tre optimises  fond : par exemple ce n'est pas trs utile de vrifier les indices de tableau lors d'une multiplication de matrices parce que les 2 boucles imbriques sont tellement simples qu'on 'voit  l'oeil nu' qu'on ne risque pas de sortir du tableau. _Pour cela, en Safe-C, on peut utiliser les unsafe pointers du C_ : donc les oprateurs &, * et -> habituels, ainsi que les [] sur un pointer unsafe.


Donc en gros, pour tout ce qui est compliqu (et pourtant extrmement courant), il faut en rester au C..

Et donc, je rejoins _Sv@r_, tu conois le langage pour des dbutants, mais il faudra matriser le double de syntaxe et de concepts (_"certains pointeurs sont "C-like", d'autres 'C-Safe' like"_) pour l'crasante majorit des programmes...

J'ai bien peur que a ne souffre du syndrme de l'spranto...








> parce que cela cre des erreurs non reproductibles trs difficiles  dbugger sur les gros programmes multithread.
> Un oubli de free p ne peut pas corrompre la mmoire.
> Par contre un double free le peut, c'est a c'est dtect.


Je crains que tu ne bases tes remarques que sur une utilisation extrmement restreinte et dans un environnement restreint...

N'importe quel programmeur C-fluent un tantinet srieux sait dbugger (ou tout au moins localiser) trs vite ce genre de problmes.. 

Que ce soit avec les IDE , les diteurs style xemacs ou vim, ou btement des printf, ou des debuggers spcialiss (par exemple ddd)...


Et l'apprentissage du "bien savoir dbugger vite" se fait plus rapidement avec un tuteur comptent qu'apprendre une nouvelle syntaxe et modifier des programmes en les rendant non-compatibles....








> les pointeurs ont une syntaxe diffrente pour les diffrencier des pointeurs pas vrifis, et la notation tab[a:b] c'est nouveau oui pour prendre une tranche de tableau (*indispensable pour remplacer le memcpy*), mais sinon les 95% de la syntaxe est identifique.


Pourquoi diable voudrait-on remplacer memcpy ???

Tellement utile comme outil....

Avec son parallle memmove.....





En bref, comme le dit _gl_, peut-tre que je suis obtus et rtrograde et que tu vas devenir millionaire...

Mais je crois bien que tout ton effort se base sur une ide de base fausse : tu as t dans un environnement non favorable, qui ne t'a pas permis de voir et/ou d'apprendre qu'il y avait d'excellentes techniques de dbuggage, que tel ou tel outil tait utile et/ou telle ou telle feature, et dans les arguments que tu donnes je vois plutt les remarques de quelqu'un qui n'a que peu d'exprience d'environnements industriels et de vrais programmes lourds...

Donc c'est un excellent projet d'tude et d'apprentissage...

Par contre, pour en faire un "langage" utile et utilis, qui concurrence (voire supplante, au vu de tes posts), le C, il faut qu'aussi bien pour les choses simples que pour les compliques tu sois au-dessus...


Et pour tre "interfaable" tout en tant intressant et de plus haut niveau, il faudra faire mieux que C++ ou Java ou Python....

----------


## LLB

> Non c'est loin d'tre aussi simple que le C c'est rapide, les langages objets garbage-collects c'est bien plus lent.


C'est vrai. 
Java a un avantage, son JIT a plus d'info qu'un compilateur C (il sait sur quelle machine le code est excut) et peut gnrer du code spcialis. Java a un avantage, son GC peut regrouper les librations de mmoire, l o chaque free du C doit mettre  jour ses structures internes. Il a aussi bien sr des dsavantages, mais la ralit est plus complexe que certains veulent le croire.

Marc.Samuro : pour un langage plus sr, mais avec les mmes performances que le C, je suggre Lisaac. Il a t conu comme langage pour crire un OS (il a donc tout ce qu'il faut de bas-niveau et se mlange facilement avec le C... en fait, le compilateur gnre du code C optimis), tout en ayant un certain nombre de fonctionnalits plus haut-niveau - dont de l'objet.

----------


## gl

> Pourquoi diable voudrait-on remplacer memcpy ???
> 
> Tellement utile comme outil....
> 
> Avec son parallle memmove.....


Juste pour revenir sur les slices (la notation [a:b] pour prendre une partie du tableau), pour l'utiliser dans d'autres langages, c'est un outil qui, surtout lorsqu'il gre les intervalles ouverts et semi-ouverts et le parcours dans les deux sens, est assez pratique car permettant d'exprimer clairement et facilement des constructions complexes.

Maintenant de l  le prsenter comme le remplacement de memcpy() c'est autre chose (mme si pour certaines utilisations, c'est effectivement une alternative possible et peut tre plus lisible - enfin lorsqu'on a l'habitude de l'utiliser).

----------


## TropMDR

Bonjour

Je dois tout d'abord dire que je suis assez admiratif devant la quantit de boulot produit (mme si je n'ai pas regard en dtail): des specs et un compilo complet, chapeau.

Ceci tant dit, il me semble que le processus est passablement absurde...

Dj, tu pars d'une constatation trs lgrement rductrice...





> J'ai envisag de passer au C++ ou au C#, mais ni l'un ni l'autre ne me satisfont vraiment : le C++ ne vrifie pas plus les indices et les pointeurs que le C, et le C# ne gnre pas du vrai code assembleur et en plus est lourd et lent avec son garbage collector.


Il y a quand mme plus que deux langages autre que le C... On a l'impression que tu as choisi les deux seuls avec "C" dans le nom. Et comme il a t dit, le C++ ne fait pas plus que le C quand tu utilises le sous ensemble du C++ qui est l pour rester "compatible" avec le C. Et puis alors le coup du "le C# a un GC, donc il est super lent", on a l'impression que tu n'as pas regard l'volution de l'informatique depuis les annes 80 ! Ca fait longtemps qu'on n'a plus un facteur 50 entre les langages "non compils" et les "compils" hein. On a fait quelques progrs depuis le lisp.

Ensuite tu as fait le choix de tout rcrire. Quand l'objectif est d'avoir un rsultat "sr" et rapide, a me semble un choix risqu. Pour faire un compilo de qualit, il faut quand mme un paquet d'optimisations qui risque facilement d'tre buggu. Est ce que tu as une limination des sous expressions communes, une propagation des constantes, un inliner, une bonne allocation de registre, etc etc? Parce que si tu n'as pas un compilo au poil, ce n'est pas parce que ton langage est un presque C proche de la machine que le rsultat sera comptitif par rapport  un C# JIT. Et si tu as un compilo au poil, sans prjug de tes talents de programmeur, il a quand mme de bonne chance de se retrouver bugu, surtout si c'est un de tes premiers. Quelqu'un a suggr un backend LLVM, ce qui me semble une trs bonne ide. Surtout que vu que c'est support par Apple, il y a peu de chances que a disparaisse dans un futur proche. On a un peu l'impression que tu t'es dis "je vais crire un compilo" et que tu as fonc tte baisse, sans vraiment regarder autour, ce qui ne prsage rien de bon. Pourrais tu dtailler un peu plus la techno utiliser pour ton compilo, dcrire un peu les langages intermdiaires, les optims, et ce genre de choses?

Ensuite, dans tous tes posts, tu parles de "scurit  100%". Avoir un programme qui crash instantanment, c'est clairement mieux qu'une corruption de mmoire. Mais il y a quand mme un long chemin avant la "scurit  100%"!

Et ce qui est un peu triste, c'est qu'on a vraiment l'impression que tu n'as pas du tout regard ce qui se faisait en matire de C "safe". Sinon tu serais sans doute tomb sur Cyclone par exemple (http://cyclone.thelanguage.org/wiki/...20to%20Cyclone), qui est ce que tu as fait, mais en beaucoup mieux (nettement plus proche du C, et beaucoup plus sr que ce que tu as). Je ne vois rien dans ton Safe-C qui soit mieux que leur approche, mais plein de choses nettement moins bien. Peux tu nous donner une comparaison entre ton langage et Cyclone, pour qu'on voit s'il prsente le moindre intret par rapport  a ?

Bref, pour rsumer: il me semble que la premire qualit d'un informaticien est la paresse. Ne pas rinventer la roue pour un oui ou pour un nom. Et il me semble que ton approche est  l'anti-thse absolue de cette vision !

----------


## Marc.Samuro

A TropMDR:

tout d'abord merci de m'avoir fait dcouvrir Cyclone, il y a tellement de langages aux noms curieux, je ne pensais pas que Cyclone tait un driv proche du C, en tout cas le nom ne l'indique pas vraiment.

Cyclone est rest plus proche du C que Safe-C, apparemment l'un de ses objectifs est de garder exactement les mmes pointeurs que le C pour amliorer la portabilit, mais en les classant en diffrentes catgories en plaant un @ devant:

Nullable Pointers
Fat Pointers
Non-NULL Pointers
Zero-Terminated Pointers
Bounded Pointers

Si je reprend un exemple du manuel Cyclone qui illustre les fat pointers:



```

```

Un autre exemple Cyclone :



```

```

Bref il faut toujours garder  l'esprit lequel des types de pointeur on utilise. Cela semble compliqu. Et la syntaxe n'est pas trs agrable.

En Safe-C j'ai pris l'approche de garder les anciens pointeurs C (avec *) inchangs mais utilisables uniquement dans une rgion #begin unsafe .. #end unsafe, et d'introduire un nouveau type de pointeur sr (avec ^ et le mot-cl 'new'). Cela me semble plus 'propre' que l'approche Cyclone, mais aussi moins compatible avec du C en effet.

A noter que j'ai repris cette ide au C# : eux aussi ont gard les anciens pointeurs du C. Il y a une excellent raison  cette faon de faire : les anciens pointeurs sont indispensables pour interfacer les librairies avec l'operating system. Pour tout le reste (donc 95% du programme applicatif), on utilise uniquement les nouveaux pointeurs srs ^).

Donc entre les 2 objectifs : 1) Cyclone: rendre les pointeurs du C sr en les catgorisant avec des mots-cls, et 2) Safe-C: garder les anciens pointeurs C pas safe et proposer des nouveaux pointeurs safe, il y a une diffrence d'approche entre le Safe-C et Cyclone.

--------------------------------------------------------------------

Bon, concernant les critiques  propos du compilateur Safe-C :
- il a le mrite d'exister (parce qu'une spcification de langage sans compilateur n'est pas intressante du tout),
- non, il ne gnre pas le meilleur code du monde surtout qu'il n'a qu'un an d'ge,
- je l'utilise tous les jours et je ne me prive pas d'une occasion pour l'amliorer rgulirement donc il va progresser.

--------------------------------------------------------------------

Ensuite une petite mise au point, parce qu'apparemment vous en doutez (plusieurs de vos posts reprennent cette ide) :

en Safe-C,  moins d'utiliser une rgion #begin unsafe .. #end unsafe, il vous sera impossible de corrompre la mmoire, donc en clair : impossible de lire ou d'crire en mmoire en dehors d'une variable.

Si vous trouvez une faon de le faire c'est que j'ai laiss une faille dans les spcifications du langage, ce qui serait assez fcheux puisque c'est l'objectif principal.

--------------------------------------------------------------------

Je trouve la description du langage Cyclone bien crite, je crois qu'une bonne description des caractristiques du Safe-C pour programmeurs expriments manque sur mon site, je vais y rmdier en temps utile.

--------------------------------------------------------------------

C'est assez marrant de lire vos posts : beaucoup d'entre eux se terminent par : "ce que tu as fait existe dj en mieux, va voir le langage xxx".

Personnellement j'aime bien crer les choses pour les maitriser entirement. J'utilise rarement dans mes programmes du code que je n'ai pas digr ou retravaill parce qu'on est horriblement coinc s'ils contiennent des bugs ou des limitations et qu'on ne sait pas y remdier. Et puis a donne beaucoup de satisfaction et de motivation ...

--------------------------------------------------------------------

----------


## Marc.Samuro

Une chose qu'il faut prciser aussi : en Safe-C, on utilise beaucoup moins les pointeurs qu'en C.

Par exemple, pour passer des paramtres, le code C suivant :



```

```

sera r-crit comme ceci en Safe-C :



```

```

avec l'avantage que le compilateur va donner une erreur si on crit dans s puisque c'est un paramtre 'in'.


Bref: En Safe-C on utilise la notation pointeur uniquement quand on fait de l'allocation sur le heap, et pas comme C pour tous les paramtres passs par adresse. On verra donc beaucoup moins de * et de ^ dans le code.

p.s: gnralement en safe-c on remplacera encore "char[]" par "string", c'est plus facile  lire.

----------


## souviron34

> je ne pensais pas que Cyclone tait un driv proche du C, *en tout cas le nom ne l'indique pas vraiment*.


Eh bien si au contraire  ::P: 


Ah ces jeunes.... !!!

En anglais, "C" se prononce "scie"

Comme "cyclone" se prononce "scie-clone", c'est un excellent acronyme pour exprimer un "C-Clone"...

Et donc un "clone" de C...

 ::mrgreen:: 








> Personnellement j'aime bien crer les choses pour les maitriser entirement. J'utilise rarement dans mes programmes du code que je n'ai pas digr ou retravaill parce qu'on est horriblement coinc s'ils contiennent des bugs ou des limitations et qu'on ne sait pas y remdier. Et puis a donne beaucoup de satisfaction et de motivation ...


a c'est trs bien.. Comme on l'a dit plus haut, excellent exercice d'apprentissge et d'tude...

Maintenant de l  proclamer que ce que tu as fait est "un nouveau langage meilleur que C" et en faire la pub sur toutes les discussions portant sur C, C++, etc.. il y a une marge...   qu'elle soit technique et/ou de modestie...

----------


## Marc.Samuro

TropMDR:




> Je ne vois rien dans ton Safe-C qui soit mieux que leur approche, mais plein de choses nettement moins bien.


Voil je vous ai montr plusieurs choses, vous tes toujours du mme avis ?  pouvez-vous dtailler les choses qui vous semblent nettement moins bien ?

(je prcise que je ne cherche pas la polmique ou la gueguerre strile entre adeptes de diffrents langages, je demande cela dans un but constructif : j'ai l'intention de rcolter vos ractions afin d'crire un manuel d'apprentissage qui en tient compte parce que je pense que vos premires impressions sont assez reprsentatives)

----------


## Marc.Samuro

> Tu ne peux donc pas avoir un type void*, ce qui est quand mme une des "features" majeures de C..


Effectivement, il n'y pas de type void* en Safe C, parce que c'est quasiment impossible  vrifier  l'excution.

J'ai d me creuser les mninges pour trouver un quivalent pratique, et aprs avoir examin beaucoup de langages je suis arriv  la solution suivante :

- ajout d'un attribut 'byte qui permet de convertir tous les types "paqus" en tableau de byte.

- conversion implicite de tous les types "paqus" en tableau de byte (donc byte[]) lors du passage de paramtres.

En clair, ces 2 rgles permettent les choses suivantes :



```

```

et



```

```

Pour ne pas mettre en pril la scurit, il y a une restriction sur ces types 'paqus':
ils ne peuvent pas contenir de pointeur scuris (donc p^).
Cela n'est pas gnant car il est rare de devoir sauver un pointeur sur disque ..

On peut donc crire :



```

```

----------


## gl

> Une chose qu'il faut prciser aussi : en Safe-C, on utilise beaucoup moins les pointeurs qu'en C.
> 
> Par exemple, pour passer des paramtres, le code C suivant :
> 
> 
> 
> ```
> 
> ```
> ...


Juste deux petites remarques:
En C, il est possible dans les paramtres de fonctions d'crire char s[]  la place de char *s. c'est tout  fait licite.Si tu veux un pointeur en lecture seule, il suffit de le dclarer const. Ainsi tu auras le mme message d'erreur en C en dclarant non pas "char *s" mais "char const * s". La principale diffrence par rapport  ton systme en out/ref/in c'est le mode par dfaut : un oubli en safe-C rends le paramtre read-only et donc soit le code est bon, soit tu te payes une erreur  la compilation alors qu'en C un oubli se paye par un bug potentiel (le mode "lecture seule par dfaut est plus scurisant de ce point de vu l).

Sinon une petite question concernant la gestion du passage de la structure INFO dans ton cas de figure, empiles-tu toute la structure lors de l'appel de fonction ou seulement son adresse mmoire ?

----------


## souviron34

> Effectivement, il n'y pas de type void* en Safe C, parce que c'est quasiment impossible  vrifier  l'excution.
> 
> J'ai d me creuser les mninges pour trouver un quivalent pratique, et aprs avoir examin beaucoup de langages je suis arriv  la solution suivante :
> 
> - ajout d'un attribut 'byte qui permet de convertir tous les types "paqus" en tableau de byte.
> 
> - conversion implicite de tous les types "paqus" en tableau de byte (donc byte[]) lors du passage de paramtres.
> 
> En clair, ces 2 rgles permettent les choses suivantes :



ok, mais quid des utilisations comme "any function" ?

(exemple, la fonction de comparaion de qsort, ou les callbacks)..

a ne peut pas tre trait comme "un tableau de byte", si ?

----------


## Marc.Samuro

> Sinon une petite question concernant la gestion du passage de la structure INFO dans ton cas de figure, empiles-tu toute la structure lors de l'appel de fonction ou seulement son adresse mmoire ?


Les structs et les tableaux sont passs par adresse je vous rassure, on ne recopie jamais les structures comme en Pascal, ce serait terriblement inefficace.




> ok, mais quid des utilisations comme "any function" ?
> (exemple, la fonction de comparaion de qsort, ou les callbacks)..
> a ne peut pas tre trait comme "un tableau de byte", si ?


Non bien sr, a ne peut tre trait comme tableau de byte puisqu'on doit pouvoir trier une structure contenant des pointeurs.

Pour les algorithmes comme les tris j'ai t quasiment oblig d'ajouter les packages gnriques au langage, ce qui permet de paramtriser un type quelconque pour un algorithme donn (= inspir des packages gnriques Ada, des templates C++, des gnriques C#, mais en simplifiant trs fort et en sparant bien interface et corps de package). Chaque instantiation gnrique gnre alors du code spcialis pour le type donn, ce qui est comme j'ai pu le constater par des essais pratiques, trs efficace. (j'oserais presque dire plus efficace qu'en C parce que la routine qsort ne doit pas appeler la fonction de comparaison par un appel indirect mais peut utiliser un appel direct, les appels indirects comme vous le savez sans doute tant trs mal supports par le Pentium puisqu'ils vident la queue des instructions, provoquant des pnalits importantes - oui j'ai beaucoup lu les manuels d'Intel c'est trs instructif pour optimiser et choisir les instructions rapides, tenir compte des tailles de cache, etc ..)

Un autre besoin pour void* se fait sentir quand on crit un compilateur : en effet quand on cre une reprsentation syntaxique des instructions par un gigantesque arbre chain avec des pointeurs dans tous les sens, on doit reprsenter des structures pointant vers une multitude d'autres structures.

Presque tous les langages que je connais ont rsolu ce problme en utilisant le concept de 'classe', ainsi que 'classe drive'. Cependant je ne voulais pas de ce concept en Safe-C vu la complexit abstraite qu'il gnre pour la comprhension des programmes et les pnalits  l'excution, surtout en cas de conversion d'un type driv vers un autre.
Une fois qu'on introduit les classes dans un langage ce sont les casse-ttes assurs pour la suite : constructeurs, destructeurs, classe abstraite, etc .. et une multitude d'autres concepts qu'on est pratiquement oblig d'ajouter (voir problmes rencontrs par les designers du C#).

Donc j'ai choisi une autre voie, plus simple : les struct avec discriminant donc j'ai dj parl, je remets ici un exemple :



```

```

Dans l'exemple ci-dessus, la fonction dessine() peut recevoir n'importe quelle variante de la struct S et elle peut interroger s.f  l'intrieur de la fonction pour voir quelle forme a t passe en paramtre. C'est implment trs simplement : dessine() reoit l'adresse du paramtre s ainsi que son discriminant s.f qui ne fait pas partie de la structure. C'est trs similaire aux tableaux o on passe l'adresse et la longueur.

Le discriminant peut tre dynamique aussi si l'objet est rserv sur le heap :



```

```

Pour ceux qui connaissent Ada, la syntaxe en est trs proche, sauf qu'en Ada le discriminant fait partie de la structure, ce qui  mon avis est une erreur car elle peut tre corrompue par exemple si on passe la structure  une routine d'entre-sortie. En Safe-C le discriminant ne peut pas changer aprs cration de l'objet : il est soit constant soit read-only et non-accessible car stock en dehors de l'objet (un peu comme une longueur de tableau qui n'est pas stocke dans le tableau non plus).


Les callbacks sont traits comme en C, on peut crer des pointeurs vers fonctions, les paramtres doivent tre compatibles :



```

```


p.s: la syntaxe est volontairement brute ici, on peut crire aussi :



```

```

----------


## Marc.Samuro

j'ai dis plus haut qu'il n'y a pas de classes en Safe-C, en fait il y en a quand mme mais des classes ultra-simplifies : les types opaques.

Ce sont des types qu'on dclare par :

dans p.h :



```

```

et dans p.c :



```

```


L'utilisateur de P peut crire ceci :



```

```

Un type opaque est svrement restreint dans prog.c : on ne peut ni le copier par assignation, ni accder  ses champs internes, ni le convertir en tableau de byte, etc ... On peut uniquement l'initialiser  zro avec la commande 'clear' ou le passer  des fonctions. Bref, on ne peut pas corrompre son contenu, on ne peut pas non plus en prendre une copie (donc il peut contenir des pointeurs sans risque qu'ils soient dupliqus). En fait le concept vient des types 'limited private' d'Ada. Ce sont des classes super-simplifies rduites au minimum et surtout rapides.

Il n'y a pas de constructeur pour un type opaque (car les constructeurs imbriqus c'est une chose horrible qui ralentit beaucoup les programmes), on peut uniquement initialiser l'objet, soit  zro avec la commande clear, soit en le passant  une fonction avec paramtre 'out'.

----------


## jack-ft

Bonjour, 

d'abord, je suis impressionn par le travail que tu as fait!  J'espre juste pour toi que ce n'est pas en vain.  Au pire, si personne n'est intress, tu pourras toujours l'utiliser pour ton propre travail de dveloppement! 




> il m'est dj arriv de passer plusieurs jours dans le debugger en train de chercher comment diable une variable pouvait avoir reu une valeur que normalement elle ne devrait pas, et finalement sans trouver la rponse.


Personnellement, je trouve plus simple, dans le cas o le bug est reproductible, d'utiliser des outils existants de vrification de la gestion de la mmoire, comme Valgrind, Insure ou Purify.  

Je trouve d'ailleurs que ce serait une bonne chose que tout programme soit suffisamment test (et "purifi") avec ces outils avant d'tre distribu!  

)jack(

----------


## TropMDR

> Cyclone est rest plus proche du C que Safe-C, apparemment l'un de ses objectifs est de garder exactement les mmes pointeurs que le C pour amliorer la portabilit, mais en les classant en diffrentes catgories en plaant un @ devant


Je ne pense pas que l'objectif premier soit la "portabilit" mais plus la "compatibilit philosophique". En gros, la question est 'comment rendre sr du code C, tout en restant le plus proche de l'ide de "je controle tout ce que fait ma machine"'.



> En Safe-C j'ai pris l'approche de garder les anciens pointeurs C (avec *) inchangs mais utilisables uniquement dans une rgion #begin unsafe .. #end unsafe, et d'introduire un nouveau type de pointeur sr (avec ^ et le mot-cl 'new'). Cela me semble plus 'propre' que l'approche Cyclone, mais aussi moins compatible avec du C en effet.


Tes pointeurs safe-c ne sont rien de plus que les fat pointeurs de cyclone, c'est  dire des pointeurs transportant les limites du block mmoire dans lequel ils ont t allous.
Ensuite cyclone a fait le choix de ne pas offrir la possibilit d'tre unsafe. Ca vite d'avoir un peu trop vite la tentation de commencer tous ses fichiers par #pragma unsafe, et en plus a a pouss les designers du langage  trouver le plus possible de solution pour les situations les plus courantes en C.

Bien sr, il est impossible d'avoir la mme flexibilit que quand on a zro limite comme en C, mais ils sont arriv  un compromis pas dgueu me semble-t-il.
Une des limitations principale  mon sens (parce qu'elle ne se limite pas  des diffrences de performance) est la gestion de la mmoire. Je pense que pour un grand nombre d'applications, les allocations/dsallocations tant bien parenthes, l'approche par rgion est fondamentalement la bonne (et avec un bon allocateur, peut mme donner des meilleurs performances que malloc/free utilis "navement".) Beaucoup d'application ne respectant pas ce "bon parenthesage" resteront sans doute dans le domaine d'application du pointeur unique (je n'ai pas encore lu cette partie du manuel, mais je pense que c'est juste un pointeur sans alias, que l'on peut donc librer sans contrainte)
En revanche, ds qu'il faut allouer dans le tas principal (la rgion `H), il faut se reposer sur un GC conservatif, et l il y a invitablement risque de fuite de mmoire (en plus videment de l'aspect performance).





> en Safe-C,  moins d'utiliser une rgion #begin unsafe .. #end unsafe, il vous sera impossible de corrompre la mmoire, donc en clair : impossible de lire ou d'crire en mmoire en dehors d'une variable.


Est ce qu' ce sujet, tu pourrais dcrire un peu plus prcisment comment tu gres free ? En gros plutt que nous dire "c'est safe", explique nous un peu plus prcisment pourquoi  ::):  Parce qu'avoir un pointeur qui trimbale ses bornes, c'est pas trop difficile. Grer la mmoire dsallou, c'est moins simple. Je serais donc intress de voir comment tu fais a

Un autre choix de Cyclone est aussi d'ajouter des exceptions  C. Ce qui permet de ne pas juste arrter le programme avec un message d'erreur en cas de drfrencement d'un pointeur hors borne.





> Personnellement j'aime bien crer les choses pour les maitriser entirement. J'utilise rarement dans mes programmes du code que je n'ai pas digr ou retravaill parce qu'on est horriblement coinc s'ils contiennent des bugs ou des limitations et qu'on ne sait pas y remdier. Et puis a donne beaucoup de satisfaction et de motivation ...


C'est sr que rcrire ses petits outils ou ses petites fonction, c'est une bonne ide. Rcrire un compilo, c'est quand mme fortement risquer d'avoir des milliers de bugs pour des perfs bien moindre mha.

Sur la partie compilation pure, j'insiste encore, mais quelle genre d'optimisation as tu ? Parce que "lire la doc intel pour trouver la bonne instruction", c'est bien, mais si tu n'as pas de propagation des constantes ou d'limination des sous expression communes, ou encore d'inliner,c'est sans doute pas bien utile...




> Effectivement, il n'y pas de type void* en Safe C, parce que c'est quasiment impossible  vrifier  l'excution.





> ok, mais quid des utilisations comme "any function" ?


La solution naturelle ici est bien sr le polymorphisme (void*, c'est juste le polymorphisme du pauvre). C'est le choix fait en Cyclone par exemple.

----------


## Marc.Samuro

je vais rdiger un texte qui dcrit les grandes lignes du Safe-C pour programmeurs expriments, en commenant par les concepts et en terminant par les dtails. C'est vrai que ce n'est pas vident de cerner un langage sans avoir une base de travail, et le manuel de normalisation que j'ai actuellement est un peu trop indigeste  lire, et il n'explique pas les concepts ..

----------


## TropMDR

> je vais rdiger un texte qui dcrit les grandes lignes du Safe-C pour programmeurs expriments


Bon courage  ::):

----------


## Marc.Samuro

voil, ouf termin !

Un tutorial Safe-C pour programmeurs expriments : ---> http://newchatrooms.dyndns.dk:12000/...AL/manuel.html

j'aurai d commencer par cela, cela m'aurait vit pas mal de questions dans tous les sens ..

----------


## TropMDR

> voil, ouf termin !
> 
> Un tutorial Safe-C pour programmeurs expriments : ---> http://newchatrooms.dyndns.dk:12000/...AL/manuel.html
> 
> j'aurai d commencer par cela, cela m'aurait vit pas mal de questions dans tous les sens ..


Merci d'avoir crit a.

Un premier commentaire: ton blabla initial est passablement inutile et  mme de crisper les gens pas tout  fait d'accord avec toi  ::): 

Dj, un langage antique et toujours utilis aujourd'hui : le lisp. Nettement plus vieux que le C

Ensuite tu dis "un programme est fiable si quand il crash, ce n'est pas de sa faute". Un programme qui crash n'est *pas* un programme fiable.

Ensuite, tu dis "langage fiable == langage qui vrifie que les accs sont dans les bornes". Disons que la vrification des bornes est le minimum du minimum vital d'un langage "fiable". La fiabilit d'une application ne se rsume pas  "on n'a pas de corruption mmoire". Va essayer d'expliquer  une autorit de certification que ton avion peut voler sans problme par ce que "on est sur qu'il n'y a pas d'accs en dehors des bornes"..

Ensuite, tu dis que les langages modernes sont tous "10 fois plus gros et complexe que le C". Qu'est ce que tu entends par l ? Parce que si tu compare la norme du C  la norme de SML par exemple (Standard ML, langage fonctionnel de la famille Caml), tu te rendras vite compte que le C est *beaucoup* plus complexe que SML, rien qu'au nombre de page. Pour comprendre le C, tu dois maitriser son modle mmoire, et rien que a, a en fait un langage d'une complexit effroyable.

Finalement tu dis que "En clair : avec le Safe-C vous avez un langage un tout petit peu plus lent que le C afin de pouvoir satisfaire l'objectif 1 de fiabilit, mais qui reste le plus rapide qu'il soit possible de faire avec cet objectif.". Le fait qu'en restant dans la partie "safe" du safe-C, on soit oblig de se trimbaler des pointeurs "vrifi" montre que cette affirmation est fausse. Je suis prs  parier ce que tu veux que Cyclone est plus rapide que ton safe-C sur plein d'application o on peut trivialement viter les fat pointers

Puisque ton seul objectif est la suret, pourquoi forcer l'initialisation des valeurs ? Seuls la non initialisation des pointeurs pose un soucis.

En C, le chiffre derrire int est le nombre de bit, toi d'octet. C'est confusant.

Le mcanisme de "Tombstone" me semble assez tonnant. Si je comprends bien,  partir du moment o tu as cr un pointeur, sa "Tombstone" restera l pour toujours. Donc en gros, si je fais



```

```

je ferai exploser ma mmoire.
Embtant non ?
Est ce que tu as un lock par tombstone pour tre thread safe ?

Je suis vraiment dsol, je continue  penser que c'est un travail impressionnant, mais qu'il n'apporte rien d'intressant par rapport  des projets existant, tels que Cyclone :-\

----------


## TropMDR

Je viens de penser  des problmes potentiellement encore plus graves avec tes "tombstones". Est ce que tu peux nous faire une description plus pousse de ce que tu fais ? La vraie structure mmoire, et ce qu'il se passe  run time, en particulier l'arithmtique de pointeurs.

Merci !

----------


## Marc.Samuro

> ton blabla initial est passablement inutile et  mme de crisper les gens pas tout  fait d'accord avec toi


je suis d'accord, je vais raccourcir l'introduction.




> Dj, un langage antique et toujours utilis aujourd'hui : le lisp. Nettement plus vieux que le C


qui programme encore en Lisp ?




> Ensuite, tu dis que les langages modernes sont tous "10 fois plus gros et complexe que le C".


je parle de la taille du compilateur qu'il faut pour supporter le langage.

---------------------------

tu parles toujours des fat pointers de Cyclone,
est-ce que ce sont des structures composes d'un pointeur et d'une taille ?

Que se passe-t-il si 2 threads accdent  cette structure en mme temps,
par exemple une assignation d'une valeur pointeur  une variable fat pointer,
ne risquent-ils pas de la corrompre ?

En Safe-C je voulais expressment des pointeurs de la taille d'une adresse
mmoire pour que les assignations de pointeurs soient naturellement thread-safe.

----------------------------




> Puisque ton seul objectif est la suret, pourquoi forcer l'initialisation des valeurs ? Seuls la non initialisation des pointeurs pose un soucis.


Effectivement c'est une faille dans mon argumentation  laquelle j'ai pens aussi.
Le problme c'est que si je renonce  l'initialisation des variables, je ne sais plus introduire les nouveaux modes de passage de paramtres.
D'autre part, avoir des variables non-initialises cre des programmes qui ne se comportent pas d'une manire dterministe, ce qui complique fortement la recherche d'erreurs.

Il faudra peut-tre que je nuance ma dfinition de 'safe' ..




> Je suis prs  parier ce que tu veux que Cyclone est plus rapide que ton safe-C sur plein d'application o on peut trivialement viter les fat pointers


J'ai vu qu'en cyclone on peut crer un scope pour un pointeur. Pourquoi ne pas utiliser une variable locale  la place ?




```

```

tlcharge le compilateur et essaye  :;): 




> Est ce que tu as un lock par tombstone pour tre thread safe ?


Tout est thread-safe grce au prfixe "lock" d'intel qui permet les oprations atomiques.




> Je viens de penser  des problmes potentiellement encore plus graves avec tes "tombstones".


tlcharge le compilateur et essaye  :;): 
moi je pense  des problmes graves avec tes fat-pointers.

:-)

----------


## TropMDR

> qui programme encore en Lisp ?


Qui programme encore avec le C de l'poque plutt qu'en C 90 voir 99 ?




> je parle de la taille du compilateur qu'il faut pour supporter le langage.


Ca ne me semble pas vraiment tre un argument intressant pour l'utilisateur... "Tu devrais utiliser ce langage. Il est horrible  comprendre, mais c'est plus simple pour les auteurs de compilo". Mais bon, quelque part, c'est ce qui a fait que la C a gagn sur plein de langages bien mieux: il y avait un compilo avec tout nouvel OS et toute nouvelle archi, parce que c'tait tout petit  crire.





> tu parles toujours des fat pointers de Cyclone,
> est-ce que ce sont des structures composes d'un pointeur et d'une taille ?


Ils sont sur trois mots.





> Que se passe-t-il si 2 threads accdent  cette structure en mme temps,
> par exemple une assignation d'une valeur pointeur  une variable fat pointer,
> ne risquent-ils pas de la corrompre ?


Je ne sais pas ce que Cyclone promet en multithread.





> J'ai vu qu'en cyclone on peut crer un scope pour un pointeur. Pourquoi ne pas utiliser une variable locale  la place ?


Je n'ai pas compris la question




> tlcharge le compilateur et essaye


Tout le monde n'a pas windows. C'est pour a que j'aimerais une description plus fine de tes tombstones. Du peu que tu as dit, je ne vois comment ta structure intermdiaire peu disparaitre, ni comment peut fonctionner l'arithmtique de pointeurs.

J'ajouterai que mettre un lien vers ton petit projet perso sur wikipedia est assez dplac. Je suggre fortement que tu le supprimes.

----------


## Marc.Samuro

> Du peu que tu as dit, je ne vois comment ta structure intermdiaire peu disparaitre, ni comment peut fonctionner l'arithmtique de pointeurs.


Effectivement j'ai cal sur ce problme de structure intermdiaire pendant 6 mois. Le Wikipdia anglais dcrit les tombstones ("pierres tombales" en franais) comme des structure de donnes qui, une fois le block dallou, ne pouvaient plus tres alloues  nouveau, d'o consommation de mmoire de plus en plus grande.

C'est l'auteur d'une note "white paper" qui en parlant de pointeurs m'a donn l'ide qu'en fait on ne risquait pas de corrompre la mmoire si on rutilisait le slot tombstone pour le mme "type" d'objet heap. Le tombstone retient donc vers quel type d'objet il pointe.

En ce qui concerne l'arithmtique de pointeurs, elle n'est tout simplement pas autorise.

p.s: j'ai compltement enlev l'introduction, donc le texte passe directement au coeur du sujet, c'est beaucoup mieux en effet  ::): 




> J'ajouterai que mettre un lien vers ton petit projet perso sur wikipedia est assez dplac. Je suggre fortement que tu le supprimes.


pourquoi donc ?  il illustre un langage qui utilise les tombstones. Il n'y a rien de mal  cela sinon les wikipediens l'auraient dj supprim depuis le temps qu'il est l.

----------


## TropMDR

> En ce qui concerne l'arithmtique de pointeurs, elle n'est tout simplement pas autorise.


Bon, je suis dsol, mais ceci achve de dtruire dfinitivement toute crdibilit  ton "langage". Dire que c'est "exactement comme le C sauf que c'est safe", alors que tu n'autorise pas l'arithmtique de pointeur, je suis dsol, mais c'est une grosse blague. Il reste quoi comme intret au C par rapport aux autres langages si tu ne peux pas faire d'arithmtique de pointeur ?

----------


## Marc.Samuro

il faut poser la question autrement : comment cyclone rend-il l'incrmentation de pointeurs sre ?  en vrifiant chaque fois que le pointeur est toujours dans une zone mmoire donne, par deux tests : p >= dbut && p < dbut + longueur.  Il est bien plus conomique d'utiliser un tableau et de ne faire qu'un seul test non-sign sur l'indice. En rsum : l'incrmentation de pointeur safe n'a plus aucun avantage sur les indices de tableaux.

----------


## LLB

Bonjour,

Voici mon premier programme de test. En Safe-C :



```

```

Voici l'quivalent en C# (copi-coll  90%) :



```

```

Temps d'excution sur ma machine :
C# : 00.580 s
Safe-C : 09.838 s

Je retourne donc utiliser un langage "lourd et lent avec son garbage collector" (en vrai, j'utilise peu C#, mais c'tait pour rpondre  vos accusations).

----------


## Marc.Samuro

touch ...
apparemment j'ai encore pas mal de boulot pour optimiser les boucles ..  ::(:

----------


## LLB

Pour information, C# n'effectue pas de test sur l'indice quand il se rend compte statiquement que a ne sert  rien. Si je boucle de 0  Length, on sait qu'on ne dpasse pas du tableau. C'est une optimisation parmi beaucoup d'autres.

J'espre que le compilateur remplace tous les arr'length par sa valeur, qui est connue statiquement. J'espre aussi que la boucle est effectue l'envers (comparer un entier avec 0 est plus rapide qu'avec length), puisque le rsultat ne change pas. J'espre que le clear ne fait rien, puisque je mets  2 ensuite...

Je serais admiratif si vous russissez  battre C# en crivant votre propre gnration de code. C'est pour cette raison que j'ai conseill ds le dpart d'utiliser un backend prouv, comme LLVM. Vous pouvez aussi gnrer du code C et appeler un compilo C.

----------


## LLB

Un autre test :



```

```

Pourquoi mod(500000, 2) plante  l'excution, alors que presque tous les compilateurs C savent calculer le rsultat ? C'est encore une autre optimisation classique.

----------


## Marc.Samuro

> LLB : Marc.Samuro : pour un langage plus sr, mais avec les mmes performances que le C, je suggre Lisaac. Il a t conu comme langage pour crire un OS (il a donc tout ce qu'il faut de bas-niveau et se mlange facilement avec le C...


j'ai t voir le site de Lissac .. on ne peut pas dire que ce soit un langage conventionnel .. je cite : "ce langage est minimaliste avec labsence de construction pour les conditionnelles, les boucles et les itrations". Cela donne une syntaxe assez spciale  laquelle peu de programmeurs pourront s'habituer .. c'est exprimental bien sr.

----------


## gl

> Je suis vraiment dsol, je continue  penser que c'est un travail impressionnant, mais qu'il n'apporte rien d'intressant par rapport  des projets existant, tels que Cyclone :-\


Ca rsume assez bien mon ressenti galement.


Je vais essayer de prendre le temps de lire le document fourni et de faire quelques tests pratiques avec le compilateur ce we

Au vue des premiers rsutats obtenus par LLB, j'ai la vague impression que l'implmentation de ton compilateur est trs nave (comprendre par l que tu fait une simple conversion un pour un des instructions safe-C vers l'assembleur).

----------


## TropMDR

> il faut poser la question autrement : comment cyclone rend-il l'incrmentation de pointeurs sre ?  en vrifiant chaque fois que le pointeur est toujours dans une zone mmoire donne, par deux tests : p >= dbut && p < dbut + longueur.


N'importe quoi... Cyclone incrmente un pointeur en... incrmentant le pointeur. C'est  l'accs que le test de validit est fait (et eux, ils liminent les tests inutiles...)





> Il est bien plus conomique d'utiliser un tableau et de ne faire qu'un seul test non-sign sur l'indice. En rsum : l'incrmentation de pointeur safe n'a plus aucun avantage sur les indices de tableaux.


Les indices ne permettent pas de considrer un sous tableau comme un tableau  part entire, et encore moins d'avoir un pointeur vers une sous structure.

Si ta seule utilisation du C est de parcourir un tableau, en accdant  chaque case via son indice, quel est l'intrt de faire du C ? Pourquoi utiliser un langage si bas niveau, avec des types si faible, si ce n'est pas pour exposer un minimum la structure des types de donne sous jacent ? Pour poser la question diffremment, quelle est la cible, l'utilisation typique, de ton langage ?

----------


## TropMDR

> Temps d'excution sur ma machine :
> C# : 00.580 s
> Safe-C : 09.838 s


Holy crap !@#

Est ce qu'on peut voir l'assembleur produit par: (dsol, je n'ai toujours pas windows  ::(:  )


```

```

ou encore


```

```

ou bien


```

```

Est ce que


```

```

est bien accept ? Si oui, est ce que tab5 est inlin ?

est ce que


```

```

est bien rejet ?

----------


## jabbounet

je viens de lire rapidement ce post, et j'ai une petite question.

personnellement quand on me parle de sret de fonctionnement ou de langage scuris j'ai tendance a penser  ADA.

Comment safe-c se dmarque t'il par rapport a ce langage?

----------


## orfix

> Tout le monde n'a pas windows...


*+1*
Pas de code source non plus  ::?:

----------


## Marc.Samuro

j'ai regard hier comment un compilateur optimis traduisait :



```

```

c'est assez remarquable : au lieu de faire une boucle ou d'utiliser des indices, il traduit ceci en 1 seule instruction assembleur: un "rep movsb" donc instruction avec rptition. Donc pas tonnant que a aille 20x plus vite. Cela ne marche videmment que pour une boucle avec limites constantes avec exactement "ces" instructions.

J'en conclus que pour optimiser ce genre de boucle le compilateur doit probablement comparer le modle de boucle avec des centaines de modles de boucles standard simples qu'il garde dans une bibliothque, et encore a ne marche que sur un microprocesseur particulier qui a le genre d'intructions curieuses comme rep movsb. Bref, dur dur d'optimiser ..




> personnellement quand on me parle de sret de fonctionnement ou de langage scuris j'ai tendance a penser  ADA.
> 
> Comment safe-c se dmarque t'il par rapport a ce langage?


Ada a la fiabilit totale du logiciel comme objectif (en vrifiant les overflows, en imposant des contraintes d'intervalle autoriss aux variables, etc ..), alors que le Safe-C ne garantit qu'une fiabilit mmoire (on ne doit pas pouvoir crire en dehors de la zone mmoire des variables). Une autre diffrence est qu'un compilateur Ada est environ 10 fois plus grand qu'un compilateur Safe-C, cela donne une ide de la taille du langage Ada, maintenant vous me direz on n'est pas oblig d'utiliser tout le langage bien sr.

j'ai beaucoup d'admiration pour les concepteurs d'Ada (qui sont franais disons-le en passant), j'ai tudi la version 1983 de ce langage en dtail quand il a t publi. Il ont vraiment montr ce qu'tait un langage pour les applications trs scurises (ex: sous-marins nuclaires, missiles, Ariane, signalisation du tunnel sous la manche) en vrifiant absolumment tout et en misant sur la clart d'criture. Le manuel de rfrence de 1983 est un exemple de prcision et d'exactitude.

Ensuite j'ai t horrifi en voyant comment les gens du Dpartement de la Dfense avaient modifi Ada durant la rvision 1995 du langage : Ada tait dj un langage norme, mais l il explosait carrment en complexit et en rgles de toutes sortes. Il auraient pu le simplifier et retirer des choses, mais l a a t un dsastre.  ::(:   Heureusement ils sont rests compatibles avec Ada83.

Ada a choisi une syntaxe 'Pascal' qui est sans doute plus lourde  crire, actuellement tous les langages utilisent la syntaxe 'C'. Pour un slice de tableau en Ada on doit spcifier l'indice infrieur et suprieur au lieu de l'indice infrieur et de la longueur comme j'ai choisi en Safe-C, ce qui rend assez complexe les calculs d'indice et de strings (a ne se voit pas quand on tudie le langage, mais -j'ai crit pas mal de code source Ada- a donne une impression de lourdeur quand on l'utilise).

On ne peut que recommander d'tudier Ada au niveau thorique, on en apprend beaucoup. Au point de vue utilisation pratique le langage est un peu lourd  utiliser parce que la syntaxe Pascal a des consquences de toutes sortes (par ex: les tableaux ne commencent pas forcment  zro ce qui peut sembler un mieux pour le programmeur, mais en fait  l'usage, grer 2 bords de tableau se rvle plus complexe qu'un seul).

Je me suis inspir d'Ada pour certains concepts (scurit, librairies, packages et gnriques) en les simplifiant fortement, et mme en avoir amlior certains ce qui n'est pas difficile 15 ans aprs et vu les nombreuses ractions et propositions qu' eu Ada dans les revues spcialises. 

En Ada les structures (appels records) incluent le discriminant, alors qu'en Safe-C il est stock  l'extrieur.

Ada a introduit les mode de passage de paramtres in, in out, et out. Une trs bonne ide pour clarifier, mais beaucoup de gens considrent maintenant qu'un mode 'ref' aurait t mieux que 'in out' (a cre une faille qui a t publie, mais il est trop tard pour changer).

Ada a choisi de ne pas prciser la longueur d'un "integer", ce qui fait que chaque implmentation peut avoir une taille diffrente. Au lieu de a Ada permet de "construire" soi-mme un type "int" dans le range qu'on souhaite. Mais  force de vouloir faire trop thorique, a en devient compliqu. Il est bien plus simple de fixer dans le standard que int c'est 4 bytes. En 1983 il n'tait sans doute pas encore certain que toutes les machines utiliseraient des bytes  8 bits (certaines en avaient 9), Ada voulait tre sr de pouvoir tre portable partout donc ne prcisait rien sur la longueur des types. Le C a d'ailleurs ce mme problme de non-portabilit des types de base.

Kernigan et Richie ont cr le C sur le tas grce  leur exprience pratique, les concepteurs Ada sont partis d'un cahier des charges avec une approche thorique, mthodique et organise. Pour faire un bon langage il faudrait idalement les deux.

p.s: il faut que je me cache maintenant au cas o un adepte d'Ada passerait sur le forum, j'ai dj les gens de C++ et cyclone qui veulent ma peau, sans parler des spcialistes en compilateurs optimiss  ::D:

----------


## TropMDR

> j'ai regard hier comment un compilateur optimis traduisait :
> 
> 
> 
> ```
> 
> ```
> 
> c'est assez remarquable : au lieu de faire une boucle ou d'utiliser des indices, il traduit ceci en 1 seule instruction assembleur: un "rep movsb" donc instruction avec rptition. Donc pas tonnant que a aille 20x plus vite. Cela ne marche videmment que pour une boucle avec limites constantes avec exactement "ces" instructions.


Avant d'aller jusque l, ce qui ncessite effectivement de reconnaitre des patterns compltement ad hoc, il y a plein d'autres optimisations  faire. (J'aimerais d'ailleurs toujours que quelqu'un m'envoie l'asm produit pour les exemples cits plus haut, pour faire un peu de reverse enginiering sur les optims du compilo safe-C, puisque je n'arrive pas  obtenir d'info autrement)




> Bref, dur dur d'optimiser ..


De l'intrt de ne pas crire son propre back-end...

----------


## Marc.Samuro

> J'aimerais d'ailleurs toujours que quelqu'un m'envoie l'asm produit pour les exemples cits plus haut, pour faire un peu de reverse enginiering sur les optims du compilo safe-C, puisque je n'arrive pas  obtenir d'info autrement


bon je vais jouer la transparence : le compilateur Safe-C version 1.0 pour Windows que je propose sur mon site a un niveau d'optimisation trs lgrement suprieur au compilateur Visual-C 6.0 de Microsoft quand on ne lui met aucune option d'optimisation. Il ne fait pas les inlines (mais c'est prvu), il ne combine pas encore plusieurs instructions mais traduit chacune en assembleur sparemment.

Rendez-vous l'anne prochaine sans doute pour une version 2.0.

Cette anne ma priorit c'est d'avoir des librairies puissantes et simples  utiliser, et couvrant tous les domaines (fentres, traitement d'image, rseau, encryption, fichiers isam, ..). J'ai ces librairies en C, je voulais initialement les convertir simplement en Safe-C mais je me suis pris au jeu  les amliorer et  les moderniser donc a me prend plus de temps que prvu.

----------


## Thierry Chappuis

Je n'ai pas l'habitude de rveiller un fil qui dort depuis deux mois, mais j'ai eu du plaisir  suivre la discussion, mme avec un petit dcalage




> Ada a choisi une syntaxe 'Pascal' qui est sans doute plus lourde  crire, actuellement tous les langages utilisent la syntaxe 'C'.


Le point de vue expos ici est tout de mme trs rducteur et pas trs  jour. Si le lien de parent entre C, C++, C# et Java est relativement clair, il existe tout de mme d'autres langages trs populaires qui se dmarquent du C. Si python ou ruby ne sont pas des parents si loigns, Lisp est encore plus utilis que ce que j'ai pu lire dans ce fil. Sinon, Erlang, Haskell ou OCaml sont loin d'tre seulement des curiosits et proposent aujourd'hui des performances intressantes et un paradigme de programmation intressant pour certains types d'application.

En ce qui concerne la conception des langages de la "famille" du C, on a me semble-t-il dj pas mal fait le tour de la question. Aujourd'hui, je n'ai pas l'impression qu'il y a encore de la place pour un nme langage C-like. Pour innover, il convient de plancher sur de nouveaux paradigmes permettant de supporter efficacement les dfits auxquels est confront le programmeur d'aujourd'hui. Dans ce contexte, Erlang, conu par Ericsson, se profile par exemple comme une technologie intressante pour les systmes concurrents et temps rel.

En ce qui concerne les benchmarks proposs dans ce fil, c'est toujours une tche dlicate de les valuer  leur juste valeur. Sur des tests bien choisis, le RPython de PyPy s'est montr plus rapide que le C. Un programme python tournant sur un PyPy JIT, bien que plus rapide que l'implantation CPython de rfrence, reste toutefois en moyenne significativement plus lent qu'un programme crit en C. Toutefois, pour 80% du code scientifique que je suis amen  produire, python se montre simple d'utilisation, propose une performance satisfaisante et offre le niveau de scurit mmoire 100%. J'ai galement fait quelques tests avec OCaml pour du code scientifique. Les performances de ce langage sont intressantes et la philosophie sous-jacente est trs diffrente du C.

Thierry

----------


## acx01b

Salut,

je trouve l'ide du Safe-C extrmement intressante du point de vu web/hbergeur de CGI sur des serveurs non ddis :

Imaginons que je suis un hbergeur de sites web : j'ai des serveurs ddis, avec en moyenne 500 sites web par serveur.

Bien sr, il est hors de question que l'un des 500 sites web puisse faire bugger tout le serveur, et donc aussi les 499 autres sites web qui n'ont rien demand.

Donc, je n'accepte comme applications que du php, du perl, du python, du java servlet, ou du javascript node.js.

Mais pourquoi pas galement accepter les codes-sources C/C++  condition que je les compile moi mme, avec un compilateur spcial. 
Compilateur qui n'accepte que les codes C/C++ "safe". Ce type de compilateur produit du code "safe" : partout o c'est ncessaire il ajoute les vrifications de pointeurs et de dpassement de tableau. Bien sr, on ne peut pas "linker" avec n'importe quelle librairie, uniquement LA librairie wrapper vers les quelques fonctions systmes autorises.

Le problme c'est : ce langage, C/C++ "safe", il doit tre proche au maximum du  C/C++ pour que a ne soit pas difficile de convertir un CGI lambda crit en C/C++ en une version safe que le compilateur de l'hbergeur web acceptera.

a m'intresserait beaucoup marc.samuro, si tu es toujours l, d'avoir ton avis sur ce langage le plus proche du C/C++ possible, et sur le compilateur correspondant.

----------


## Sve@r

> Salut,
> 
> je trouve l'ide du Safe-C extrmement intressante du point de vu web/hbergeur de CGI sur des serveurs non ddis :
> 
> Imaginons que je suis un hbergeur de sites web : j'ai des serveurs ddis, avec en moyenne 500 sites web par serveur.
> 
> Bien sr, il est hors de question que l'un des 500 sites web puisse faire bugger tout le serveur, et donc aussi les 499 autres sites web qui n'ont rien demand.


Salut
Si tu as tes serveurs sur des os multiutilisateurs/multitches (typiquement les Unixlike) et que tu as un serveur web adapt  ces os (style Apache) alors tu n'auras aucun souci. Chaque cgi/bin sera excut dans un processus totalement indpendant et si un cgi/bin plante, il ne plantera que ce processus. Ainsi non seulement les 499 autres sites web seront protgs mais mme le site qui aura lanc le cgi/bin foireux restera lui-aussi actif (du moins pour les pages qui n'utilisent pas ledit cgi/bin)...

----------


## dragonno

Je suis poustoufl quand mme du travail accompli.

Je ne reviendrais pas sur ce qui a t dit pour ou contre, mme s'il reste beaucoup de travail  faire en optimisation du compilo d'aprs ce que j'ai pu lire tout au long du topic, mais rappelons que Marc Samuro a prcis d'avance que son compilo n'tait certainement pas des meilleurs, que l'on pouvait mieux faire et qu'il l'avait fait pour rendre concret son tude (syntaxe etc) de Safe-C.

18:58 h... annonce de l'criture d'un tuto pour programmeur expriment.
0:43 h... Postage du lien vers le tuto.

a c'est de la motivation^^

Je rajouterais que Marc Samuro il ne faudrait pas que les oppositions  ton ide t'empchent de continuer ton projet, car mme si ton projet aboutit et se distribue, cela n'empchera pas tes opposants de dormir, par contre ceux qui auront choisi ton Safe-C en toute connaissance de cause, soit ils lui donneront une place dans le monde des langages de programmation, soit ils reviendront  un autre langage plus courant aprs avoir t ventuellement dus, continue, optimise, c'est une dmarche qui te plat en plus, et l'avenir dira ce qu'il en est  :;): 

PS : Edit fait pour corrections.

----------


## Sve@r

> Je rajouterais que Marc Samuro il ne faudrait pas que les oppositions  ton ide t'empchent de continuer ton projet, car mme si ton projet aboutit et se distribue, cela n'empchera pas tes opposants de dormir, par contre ceux qui auront choisi ton Safe-C en toute connaissance de cause, soit ils lui donneront une place dans le monde des langages de programmation, soit ils reviendront  un autre langage plus courant aprs avoir t ventuellement dus, continue, optimise, c'est une dmarche qui te plat en plus, et l'avenir dira ce qu'il en est


+1. Ce n'est pas parce que certains (comme moi) ne sont absolument pas tents que a ne plaira pas  d'autres...

----------


## jabbounet

> Je rajouterais que Marc Samuro il ne faudrait pas que les oppositions  ton ide t'empchent de continuer ton projet, car mme si ton projet aboutit et se distribue, cela n'empchera pas tes opposants de dormir, par contre ceux qui auront choisi ton Safe-C en toute connaissance de cause, soit ils lui donneront une place dans le monde des langages de programmation, soit ils reviendront  un autre langage plus courant aprs avoir t ventuellement dus, continue, optimise, c'est une dmarche qui te plat en plus, et l'avenir dira ce qu'il en est


Il est toujours intressant d'avoir des points de vue divergeant sur un projet, cela permet de mettre en vidence ses points faible ou ses manques et donne donc des possibilit de les corriger.

----------


## dragonno

Effectivement Jabbounet  :;): 
Personne n'a jamais dit le contraire  :;):

----------

