Publicité
+ Répondre à la discussion
Page 2 sur 4 PremièrePremière 1234 DernièreDernière
Affichage des résultats 21 à 40 sur 77
  1. #21
    Expert Confirmé Sénior
    Avatar de Sve@r
    Homme Profil pro Frédéric
    Ingénieur développement logiciels
    Inscrit en
    février 2006
    Messages
    4 144
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric
    Âge : 45
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : février 2006
    Messages : 4 144
    Points : 9 006
    Points
    9 006

    Par défaut

    Citation Envoyé par Marc.Samuro Voir le message
    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...


    Citation Envoyé par Marc.Samuro Voir le message
    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...

    Citation Envoyé par Marc.Samuro Voir le message
    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.

    Citation Envoyé par Marc.Samuro Voir le message
    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 ?


    Citation Envoyé par Marc.Samuro Voir le message
    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.

    Citation Envoyé par Marc.Samuro Voir le message
    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
    Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
    Tout ce qu'un individu reçoit sans rien faire pour l'obtenir, un autre individu a dû travailler pour le produire sans en tirer profit.
    Tout Pouvoir ne peut distribuer aux uns que ce qu'il a préalablement confisqué à d'autres car on n'accroît pas les biens en les divisant.
    Quand la moitié d'un peuple croit qu'il ne sert à rien de faire des efforts car l'autre moitié les fera pour elle, et quand cette dernière moitié se dit qu'il ne sert à rien d'en faire car ils bénéficieront à d'autres, cela s'appelle le déclin et la fin d'une nation.
    Dr. Adrian Rogers, 1931

  2. #22

    Inscrit en
    janvier 2011
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 30
    Points : -4
    Points
    -4

    Par défaut

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

  3. #23
    Expert Confirmé Sénior
    Avatar de Sve@r
    Homme Profil pro Frédéric
    Ingénieur développement logiciels
    Inscrit en
    février 2006
    Messages
    4 144
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric
    Âge : 45
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : février 2006
    Messages : 4 144
    Points : 9 006
    Points
    9 006

    Par défaut

    Citation Envoyé par Marc.Samuro Voir le message
    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...
    Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
    Tout ce qu'un individu reçoit sans rien faire pour l'obtenir, un autre individu a dû travailler pour le produire sans en tirer profit.
    Tout Pouvoir ne peut distribuer aux uns que ce qu'il a préalablement confisqué à d'autres car on n'accroît pas les biens en les divisant.
    Quand la moitié d'un peuple croit qu'il ne sert à rien de faire des efforts car l'autre moitié les fera pour elle, et quand cette dernière moitié se dit qu'il ne sert à rien d'en faire car ils bénéficieront à d'autres, cela s'appelle le déclin et la fin d'une nation.
    Dr. Adrian Rogers, 1931

  4. #24

    Inscrit en
    janvier 2011
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 30
    Points : -4
    Points
    -4

    Par défaut

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

  5. #25
    gl
    gl est déconnecté
    Rédacteur/Modérateur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 077
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 077
    Points : 4 192
    Points
    4 192

    Par défaut

    Citation Envoyé par Marc.Samuro Voir le message
    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.

    Citation Envoyé par Marc.Samuro Voir le message
    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.

  6. #26

    Inscrit en
    janvier 2011
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 30
    Points : -4
    Points
    -4

    Par défaut

    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/

  7. #27
    Membre Expert Avatar de orfix
    Homme Profil pro Mounir Orfi
    Inscrit en
    avril 2007
    Messages
    706
    Détails du profil
    Informations personnelles :
    Nom : Homme Mounir Orfi
    Localisation : Maroc

    Informations professionnelles :
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : avril 2007
    Messages : 706
    Points : 1 075
    Points
    1 075

    Par défaut

    Citation Envoyé par Marc.Samuro Voir le message
    Code :
    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 ?
    To start press any key. (reading screen) Where's the "any" key? I see Esc, Catarl, and Pig Up. There doesn't seem to be any "any" key. Wo! All this computer hacking is making me thirsty. I think I'll order a Tab. (presses TAB key). -- HOMER --

  8. #28

    Inscrit en
    janvier 2011
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 30
    Points : -4
    Points
    -4

    Par défaut

    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 :
    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 :
    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);
      }
    }

  9. #29
    gl
    gl est déconnecté
    Rédacteur/Modérateur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 077
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 077
    Points : 4 192
    Points
    4 192

    Par défaut

    Citation Envoyé par Marc.Samuro Voir le message
    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.

  10. #30
    gl
    gl est déconnecté
    Rédacteur/Modérateur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 077
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 077
    Points : 4 192
    Points
    4 192

    Par défaut

    Citation Envoyé par Marc.Samuro Voir le message
    par exemple ceci fonctionne aussi bien en C, qu'en C++, qu'en Safe-C :

    Code :
    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++.

  11. #31

    Inscrit en
    janvier 2011
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 30
    Points : -4
    Points
    -4

    Par défaut

    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.

  12. #32
    gl
    gl est déconnecté
    Rédacteur/Modérateur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 077
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 077
    Points : 4 192
    Points
    4 192

    Par défaut

    Citation Envoyé par Marc.Samuro Voir le message
    ??? 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.

  13. #33
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 132
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 132
    Points : 13 087
    Points
    13 087

    Par défaut

    Citation Envoyé par Marc.Samuro Voir le message
    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..




    Citation Envoyé par Marc.Samuro Voir le message
    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...





    Citation Envoyé par Marc.Samuro Voir le message
    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....





    Citation Envoyé par Marc.Samuro Voir le message
    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....
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  14. #34
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 160
    Points
    1 160

    Par défaut

    Citation Envoyé par gl Voir le message
    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.

  15. #35
    gl
    gl est déconnecté
    Rédacteur/Modérateur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 077
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 077
    Points : 4 192
    Points
    4 192

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    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).

  16. #36
    Membre chevronné
    Inscrit en
    mars 2010
    Messages
    281
    Détails du profil
    Informations forums :
    Inscription : mars 2010
    Messages : 281
    Points : 756
    Points
    756

    Par défaut

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


    Citation Envoyé par Marc.Samuro Voir le message
    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 !

  17. #37

    Inscrit en
    janvier 2011
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 30
    Points : -4
    Points
    -4

    Par défaut

    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 :
    1
    2
    3
    4
    5
    6
     
    int main(int argc, char *@fat *@fat argv)
    {
      argc--; argv++; /* skip command name */
      // ...
    }
    Un autre exemple Cyclone :

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

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

  18. #38

    Inscrit en
    janvier 2011
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 30
    Points : -4
    Points
    -4

    Par défaut

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

  19. #39
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 132
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 132
    Points : 13 087
    Points
    13 087

    Par défaut

    Citation Envoyé par Marc.Samuro Voir le message
    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...







    Citation Envoyé par Marc.Samuro Voir le message
    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...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  20. #40

    Inscrit en
    janvier 2011
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 30
    Points : -4
    Points
    -4

    Par défaut

    à 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)

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •