Discussion :

[Sve@r]

Q: comment ferais-tu pour "vérifier à la compliation ou au runtime"
R:

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

a - les objets de taille constante

exemple:

T^ p = new T;

donc là, pas de problème, un pointeur vers T sera toujours un pointeur vers T.

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 début 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 vérifié grâce au header de p

Mouais. Comme le fait le Pascal...

Faisons un petit exercice académique : 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) éléments

q^[0:n] = p^; // recopier les n premiers éléments (tranche commençant à l'indice 0, de n éléments)
q^[n:n] = {all=> 0.0}; // le reste à zéro (tranche commençant à l'indice n, de n éléments)

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

free p; // libérer l'ancien tableau
p = q; // maintenant p pointe vers le grand tableau

Oh superbe. On lance un ordre de libération 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 spécialement pour programmeurs débiles 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 réinventes Python mais en moins bien quoi. Tu veux un conseil sérieux ? 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 intéresses-y toi et tu verras que tout ce que tu proposes a déjà é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 collées à 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'empêcher que par une erreur d'inattention, une partie du code corrompe la mémoire d'une autre partie du code en dehors des règles du langage, parce que cela crée des erreurs non reproductibles très difficiles à débugger sur les gros programmes multithread.
Un oubli de free p ne peut pas corrompre la mémoire.
Par contre un double free le peut, c'est ça c'est détecté.



Python possède des classes, des exceptions, un garbage collector, des nombres complexes, des tableaux associatifs, des sets, supporte la surcharge d'opérateurs, un générateur yield, la réflexivité, ..

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 léger 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 léger et poids lourd ..

Ah ben oui. Python est un langage très encadré où tu te sens en sécurité. Tu peux taper dans tab[n] en toute quiétude, si n >= len(tab) t'auras une erreur immédiate à l'exécution avec le n° de ligne et tu pourras corriger facilement.
On en revient donc toujours au même point. Faire un langage "comme le C" (sous-entendu aussi galère à écrire) et en y rajoutant "quelques protections" qui dégraderont forcément ses performances sans apporter vraiment la quiétude des langages encadrés moi ça ne m'intéresse pas et j'ai pas l'impression que ça intéresse grand monde ici. Mais si t'es motivé alors lance-toi. Après-tout, c'est comme ça que le créateur 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 vérifications d'indices)seraient peut-être entre 75% et 95% (c'est très difficile à estimer évidemment puisque cela dépend très 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 sûrement bien plus lent et lourd pour la machine vu le nombre d'objets créés ..

Vous mettez Safe-C et Python sur le même niveau de vitesse d'exécution, 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 léger et poids lourd ..

Je pense que tu mélanges 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 côté, il est possible de faire des choses tout à fait sérieuse et convenable sans maitriser tout les aspects d'un langage.
Mais surtout ce sont des concepts de plus haut niveau qui sont généralement plus simple à appréhender mais surtout à utiliser.

disons si le C est à 100% de vitesse,

C++ (avec ses containers) et Safe-C (avec ses vérifications d'indices)seraient peut-être entre 75% et 95% (c'est très difficile à estimer évidemment puisque cela dépend très 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 sûrement bien plus lent et lourd pour la machine vu le nombre d'objets créés ..

Tes chiffres tu les sors d'où ? Est-ce juste un idée 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 bibliothèques 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'espère 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]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
  float[]^ q;
 
  q = new float[n*2];    // allouer header de 4 bytes + (2*n) éléments
 
  q^[0:n] = p^;    // recopier les n premiers éléments  (tranche commençant à l'indice 0, de n éléments)
  q^[n:n] = {all=> 0.0};   // le reste à zéro (tranche commençant à l'indice n, de n éléments)
 
  free p;   // libérer l'ancien tableau
  p = q;   // maintenant p pointe vers le grand tableau

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

Je suis loin d'être un spécialiste en la matière, 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 déjà défini 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 différente pour les différencier des pointeurs pas vérifiés, 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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
   void main ()
   {
      int i, tab[32];
 
      for (i=0; i<32; i++)
         tab[i] = (1 << i);
   }

J'ai une description de la syntaxe, c'est un peu long à poster ici. Avant de commencer un compilateur on doit avoir bien défini la syntaxe tout à fait sinon c'est la galère si ça change en cours de route.


Voici encore un petit exemple, cela donne une idée de la syntaxe (string est défini comme char[], les include sont différents oui parce qu'on peut spécifier de quelle librairie on inclut) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
// date3.c
 
from std use calendar, console;
 
void main()
{
  const string mois[12] = {"Janvier", "Février", "Mars", "Avril", "Mai", "Juin",
                           "Juillet", "Aout", "Septembre", "Octobre", "Novembre",
                           "Decembre"};
  const string jours_semaine[7] = {"Lundi", "Mardi", "Mercredi", "Jeudi",
                                   "Vendredi", "Samedi", "Dimanche"};
  DATE_TIME now;
  int       jour;
 
  get_datetime (out now);
 
  for (jour=1; jour<=max_days_in_month (now.month, now.year); jour++)
  {
    printf ("%9s : Le %2d %s %d\n",
            jours_semaine[day_of_week (jour,now.month, now.year)-1],
            jour,
            mois[now.month-1],
            now.year);
  }
}

[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'espère 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 utilisés (ce qui me laisse toujours dubitatif quant à la pertinence du bench), ils ne me semblent pas indiquer que le C++ atteigne systématiquement entre 75 et 95% des performances du C, ni que C#, Java ou Python soit forcément 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 réalité n'est pas aussi tranchée que tu sembles le croire.
Et si tu fais rentrer des critères liés à la qualité des compilateurs et bibliothèques, à la compétence des développeurs 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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
   void main ()
   {
      int i, tab[32];
 
      for (i=0; i<32; i++)
         tab[i] = (1 << i);
   }

En Safe-C je ne sais pas, mais ce code s'il peut fonctionner sur une implémentation particulière n'est pas portable en C ou C++.

[Marc.Samuro]

ils ne me semblent pas indiquer que Java ou Python soit forcément toujours bien plus lent que le C.

??? le tableau est pourtant très 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 catégorie plus lente que la famille C/C++/Safe-C.

[gl]

??? le tableau est pourtant très 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 résultats 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 catégorie 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-collectés 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 même 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 mêmes qu'en C.

Tout programme a des sections qui doivent être optimisées à fond : par exemple ce n'est pas très utile de vérifier les indices de tableau lors d'une multiplication de matrices parce que les 2 boucles imbriquées 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 opérateurs &, * et -> habituels, ainsi que les [] sur un pointer unsafe.

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

Et donc, je rejoins Sv@r, tu conçois le langage pour des débutants, mais il faudra maîtriser 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 syndrôme de l'éspéranto...

parce que cela crée des erreurs non reproductibles très difficiles à débugger sur les gros programmes multithread.
Un oubli de free p ne peut pas corrompre la mémoire.
Par contre un double free le peut, c'est ça c'est détecté.

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

N'importe quel programmeur C-fluent un tantinet sérieux sait débugger (ou tout au moins localiser) très vite ce genre de problèmes..

Que ce soit avec les IDE , les éditeurs style xemacs ou vim, ou bêtement des printf, ou des debuggers spécialisés (par exemple ddd)...


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

les pointeurs ont une syntaxe différente pour les différencier des pointeurs pas vérifiés, 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 parallèle memmove.....





En bref, comme le dit gl, peut-être que je suis obtus et rétrograde et que tu vas devenir millionaire...

Mais je crois bien que tout ton effort se base sur une idée 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 débuggage, que tel ou tel outil était utile et/ou telle ou telle feature, et dans les arguments que tu donnes je vois plutôt les remarques de quelqu'un qui n'a que peu d'expérience 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 compliquées tu sois au-dessus...


Et pour être "interfaçable" tout en étant intéressant 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-collectés 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 exécuté) et peut générer du code spécialisé. Java a un avantage, son GC peut regrouper les libérations de mémoire, là où chaque free du C doit mettre à jour ses structures internes. Il a aussi bien sûr des désavantages, mais la réalité est plus complexe que certains veulent le croire.

Marc.Samuro : pour un langage plus sûr, mais avec les mêmes performances que le C, je suggère Lisaac. Il a été conçu comme langage pour écrire un OS (il a donc tout ce qu'il faut de bas-niveau et se mélange facilement avec le C... en fait, le compilateur génère du code C optimisé), tout en ayant un certain nombre de fonctionnalités plus haut-niveau - dont de l'objet.

[gl]

Pourquoi diable voudrait-on remplacer memcpy ???

Tellement utile comme outil....

Avec son parallèle 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 gère 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 présenter comme le remplacement de memcpy() c'est autre chose (même 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 (même si je n'ai pas regardé en détail): des specs et un compilo complet, chapeau.

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

Déjà, tu pars d'une constatation très légèrement réductrice...

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

Il y a quand même 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 années 80 ! Ca fait longtemps qu'on n'a plus un facteur 50 entre les langages "non compilés" et les "compilés" hein. On a fait quelques progrès depuis le lisp.

Ensuite tu as fait le choix de tout réécrire. Quand l'objectif est d'avoir un résultat "sûr" et rapide, ça me semble un choix risqué. Pour faire un compilo de qualité, il faut quand même 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 résultat sera compétitif par rapport à un C# JITé. Et si tu as un compilo au poil, sans préjugé de tes talents de programmeur, il a quand même de bonne chance de se retrouver bugué, surtout si c'est un de tes premiers. Quelqu'un a suggéré un backend LLVM, ce qui me semble une très bonne idée. 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é tête baissée, sans vraiment regarder autour, ce qui ne présage rien de bon. Pourrais tu détailler un peu plus la techno utiliser pour ton compilo, décrire un peu les langages intermédiaires, les optims, et ce genre de choses?

Ensuite, dans tous tes posts, tu parles de "sécurité à 100%". Avoir un programme qui crash instantanément, c'est clairement mieux qu'une corruption de mémoire. Mais il y a quand même un long chemin avant la "sécurité à 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 matière 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 sûr 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 présente le moindre intéret par rapport à ça ?

Bref, pour résumer: il me semble que la première qualité d'un informaticien est la paresse. Ne pas réinventer la roue pour un oui ou pour un nom. Et il me semble que ton approche est à l'anti-thèse absolue de cette vision !

[Marc.Samuro]

A TropMDR:

tout d'abord merci de m'avoir fait découvrir Cyclone, il y a tellement de langages aux noms curieux, je ne pensais pas que Cyclone était un dérivé 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 mêmes pointeurs que le C pour améliorer la portabilité, mais en les classant en différentes catégories en plaçant 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:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
int main(int argc, char *@fat *@fat argv)
{
  argc--; argv++; /* skip command name */
  // ...
}

Un autre exemple Cyclone :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
void foo (char *s, int offset)
{
    char *@fat @nozeroterm fat_s = (char *@fat @nozeroterm)s;
    // ...
}

Bref il faut toujours garder à l'esprit lequel des types de pointeur on utilise. Cela semble compliqué. Et la syntaxe n'est pas très agréable.

En Safe-C j'ai pris l'approche de garder les anciens pointeurs C (avec *) inchangés mais utilisables uniquement dans une région #begin unsafe .. #end unsafe, et d'introduire un nouveau type de pointeur sûr (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 idée au C# : eux aussi ont gardé les anciens pointeurs du C. Il y a une excellent raison à cette façon 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 sûrs ^).

Donc entre les 2 objectifs : 1) Cyclone: rendre les pointeurs du C sûr en les catégorisant avec des mots-clés, et 2) Safe-C: garder les anciens pointeurs C pas safe et proposer des nouveaux pointeurs safe, il y a une différence d'approche entre le Safe-C et Cyclone.

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

Bon, concernant les critiques à propos du compilateur Safe-C :
- il a le mérite d'exister (parce qu'une spécification de langage sans compilateur n'est pas intéressante du tout),
- non, il ne génère 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'améliorer régulièrement donc il va progresser.

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

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

en Safe-C, à moins d'utiliser une région #begin unsafe .. #end unsafe, il vous sera impossible de corrompre la mémoire, donc en clair : impossible de lire ou d'écrire en mémoire en dehors d'une variable.

Si vous trouvez une façon de le faire c'est que j'ai laissé une faille dans les spécifications du langage, ce qui serait assez fâcheux puisque c'est l'objectif principal.

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

Je trouve la description du langage Cyclone bien écrite, je crois qu'une bonne description des caractéristiques du Safe-C pour programmeurs expérimentés manque sur mon site, je vais y rémédier en temps utile.

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

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

Personnellement j'aime bien créer les choses pour les maitriser entièrement. J'utilise rarement dans mes programmes du code que je n'ai pas digéré ou retravaillé parce qu'on est horriblement coincé s'ils contiennent des bugs ou des limitations et qu'on ne sait pas y remédier. Et puis ça donne beaucoup de satisfaction et de motivation ...

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

[Marc.Samuro]

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

Par exemple, pour passer des paramètres, le code C suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
void foo (char        *s,    // in
          char        *t,    // ref
          struct INFO *p)    // out
{
  s[5] = 'a';
  p->age = 30;
}

sera ré-écrit comme ceci en Safe-C :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
void foo (    char[] s,
          ref char[] t,
          out INFO   p)
{
  s[5] = 'a';   // compilation error : s is read-only
  p.age = 30;
}

avec l'avantage que le compilateur va donner une erreur si on écrit dans s puisque c'est un paramètre '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 paramètres passés par adresse. On verra donc beaucoup moins de * et de ^ dans le code.

p.s: généralement en safe-c on remplacera encore "char[]" par "string", c'est plus facile à lire.

[souviron34]

je ne pensais pas que Cyclone était un dérivé proche du C, en tout cas le nom ne l'indique pas vraiment.

Eh bien si au contraire


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...

Personnellement j'aime bien créer les choses pour les maitriser entièrement. J'utilise rarement dans mes programmes du code que je n'ai pas digéré ou retravaillé parce qu'on est horriblement coincé s'ils contiennent des bugs ou des limitations et qu'on ne sait pas y remédier. Et puis ça donne beaucoup de satisfaction et de motivation ...

ça c'est très 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 même avis ? pouvez-vous détailler les choses qui vous semblent nettement moins bien ?

(je précise que je ne cherche pas la polémique ou la gueguerre stérile entre adeptes de différents langages, je demande cela dans un but constructif : j'ai l'intention de récolter vos réactions afin d'écrire un manuel d'apprentissage qui en tient compte parce que je pense que vos premières impressions sont assez représentatives)