IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Actualités Discussion :

Index TIOBE du classement des langages de programmation

  1. #201
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Novembre 2008
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Finance

    Informations forums :
    Inscription : Novembre 2008
    Messages : 44
    Points : 66
    Points
    66
    Par défaut
    Dans un forum C++, on me dirait surement l'inverse... Mais ce sujet traite bien de la position du C et du C++ dans le palmares des langages les plus utilisés. Ils font mordre la poussière aux autres...

    Puisqu'en bon intégriste, vous cherchez les hérésies, alors vous devrez monter une croisade contre cette excellente référence du C++, qui ose inclure indisctinctement des références sur le langage C avec celles sur le C++:

    http://www.cplusplus.com/reference/

    Quant au français, si tout latin était compris des français, alors ça serait du français de base, non? Pas fort votre exemple.

    Bref, je vous laisse parler religion. Moi c'est l'informatique qui m'intéresse

    P.S. Je me considère comme un programmeur de C/C++. Il est pas né celui qui me l'enlèvera pour me camper d'un côté ou de l'autre...

    Citation Envoyé par Florian Goo Voir le message
    C'est un peu comme dire que le français et le latin, puisque l'un hérite de l'autre, c'est la même chose…
    De même que le latin est partie intégrante du français, le C l'est pour le C++. Ce n'est pas pour autant que mélanger indistinctement l'un et l'autre est une pratique recommandée !

    Le « C/C++ », c'est bien un truc d'ancien (sans vouloir être péjoratif ni insultant, hein ).

    Mais peut-être que ce débat mériterait un topic dédié dans la section C++, non ?

  2. #202
    Membre éprouvé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2006
    Messages
    519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Septembre 2006
    Messages : 519
    Points : 1 104
    Points
    1 104
    Par défaut
    Citation Envoyé par ruste Voir le message
    Puisqu'en bon intégriste, vous cherchez les hérésies, alors vous devrez monter une croisade contre cette excellente référence du C++, qui ose inclure indisctinctement des références sur le langage C avec celles sur le C++:

    http://www.cplusplus.com/reference/
    Mais l'inverse n'est pas vrai. C++ a pris le C comme base, quel scoop !

    Citation Envoyé par ruste Voir le message
    Quant au français, si tout latin était compris des français, alors ça serait du français de base, non? Pas fort votre exemple.
    Je ne saisis pas ce que tu veux dire.

  3. #203
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 360
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 360
    Points : 20 377
    Points
    20 377
    Par défaut
    'Alut

    Citation Envoyé par ruste Voir le message
    J'avais été tenté de faire exclusivement du C++, question d'évoluer. Jeunesse oblige Jusqu'à ce que je m'amuse à réécrire un outil qui écoutait le buffer d'un port série. Ma réécriture C++ qui implémentait un ring en objet était très clean, très esthétique. Franchement, c'était de l'art! Mais aussi belle soit-elle, elle n'était pas assez rapide pour écouter sans perdre du contenu.
    je fais un peu du hors sujet mais faut voir.
    Si tu fais une classe avec usage intensif d'héritage cela risque d'entrainer des ralentissements...
    mais j'en doute parce que les compilateurs sont particulièrement bien optimisés pour ce genre de code...
    maintenant avec les duo et quad cores tu peux optimiser ton code , utiliser le multithreading et roulez jeunesse

  4. #204
    Membre confirmé

    Profil pro
    Inscrit en
    Mars 2009
    Messages
    349
    Détails du profil
    Informations personnelles :
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : Mars 2009
    Messages : 349
    Points : 590
    Points
    590
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    s tu peux optimiser ton code , utiliser le multithreading et roulez jeunesse
    Tout n'est pas parrallelisable malheureusement

  5. #205
    Membre éprouvé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2006
    Messages
    519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Septembre 2006
    Messages : 519
    Points : 1 104
    Points
    1 104
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    Si tu fais une classe avec usage intensif d'héritage cela risque d'entrainer des ralentissements...
    Plutôt des méthodes virtuelles, je dirais.

  6. #206
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Novembre 2008
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Finance

    Informations forums :
    Inscription : Novembre 2008
    Messages : 44
    Points : 66
    Points
    66
    Par défaut
    Vous devez comprendre que le C++ n'est pas une déviation du C, mais une extension. Il est 100% compatible, dans le sens de PC compatible ou autre compatibilité logicielle: backward compatible.

    Je vais prendre un autre exemple: le broken english est une version de base de l'anglais courant. C'est pourtant bien de l'anglais.

    Le C++, c'est du C enrichi, avec des extensions pour lui permettre de supporter l'orienté objet. Les mots clés et opérateurs de base du C y sont tous, sans exceptions. Le C++ en ajoute quelques uns pour permette aux programmeurs C qui le désirent d'implémenter de l'OO. Mais la base en C reste intacte, aucunement déformée, car le C++ c'est du C.

    Si vous n'êtes toujours pas d'accord, alors vous devrez classifier le C de Kernigham & Ritchie comme n'étant pas du C non plus. Le K&R C est moins compatible avec le ANSI C que vous utilisez probablement que le AINSI C++. La seule hérésie du C++, c'est de ne pas porter la griffe de Dennis Ritchie! Mais elle porte quand même celle du ANSI/ISO, à qui le C a été transmis.

    A+

    Citation Envoyé par spidermario Voir le message
    Mais l'inverse n'est pas vrai. C++ a pris le C comme base, quel scoop !


    Je ne saisis pas ce que tu veux dire.

  7. #207
    gl
    gl est déconnecté
    Rédacteur

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

    Informations forums :
    Inscription : Juin 2002
    Messages : 2 165
    Points : 4 637
    Points
    4 637
    Par défaut
    Citation Envoyé par ruste Voir le message
    Vous devez comprendre que le C++ n'est pas une déviation du C, mais une extension. Il est 100% compatible, dans le sens de PC compatible ou autre compatibilité logicielle: backward compatible.
    Non, ce n'était déjà pas vrai à l'époque et c'est encore moins vrai avec C99 :
    Les incompatibilités entre le C et le C++. Le C++ englobe certes une grande partie du C, mais il n'est pas 100% compatible.

    Citation Envoyé par ruste Voir le message
    Le C++, c'est du C enrichi, avec des extensions pour lui permettre de supporter l'orienté objet. Les mots clés et opérateurs de base du C y sont tous, sans exceptions. Le C++ en ajoute quelques uns pour permette aux programmeurs C qui le désirent d'implémenter de l'OO. Mais la base en C reste intacte, aucunement déformée, car le C++ c'est du C.
    Outre la remarque précédente sur la compatibilité du C++ avec le C, restreindre le C++ à "C avec le support objet" est horriblement réducteur. Le C++ amène aussi le support des exceptions, la S(T)L, les templates et bien d'autres choses.

  8. #208
    Membre éclairé
    Avatar de Florian Goo
    Profil pro
    Inscrit en
    Septembre 2008
    Messages
    680
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Septembre 2008
    Messages : 680
    Points : 858
    Points
    858
    Par défaut
    Malheureusement pour toi, le créateur du C++ lui-même n'est pas d'accord avec toi. Peut-être devrais-tu remettre tes certitudes en question ?
    Citation Envoyé par Bjarne Stroustrup
    What do you think of C/C++?
    No that's not really a question I often get. In that sense, it is the only "fake FAQ" in this FAQ. However, it ought to be a FAQ because people use "C/C++" as if it meant something specific and as if they knew what it meant, leading to much confusion and misery. People should ask "What is C/C++?" and then on reflection stop using the term. It does harm.

    There is no language called "C/C++". The phrase is usually used by people who don't have a clue about programming (e.g. HR personnel and poor managers). Alternatively, it's used by people who simple do not know C++ (and often not C either). When used by programmers, it typically indicates a "C++ is C with a few useful and a lot of useless complicated features added" attitude. Often, that is the point of view of people who like to write their own strings and hash tables with little knowledge of the standard library beyond printf and memcpy. There are people who stick to a restricted subset of C++ for perfectly good reasons, but they (as far as I have noticed) are not the people who say "C/C++".

    I use C/C++ only in phrases such as "C/C++ compatibility" and "C/C++ community".
    http://www2.research.att.com/~bs/bs_faq.html#C-slash
    Mais peut-être que Bjarne Stroustrup est un « intégriste » qui ne « s'intéresse pas à l'informatique » ?


    Quand tu prétends à une compatibilité à 100%, là encore tu te trompes :
    In the strict mathematical sense, C isn't a subset of C++. There are programs that are valid C but not valid C++ and even a few ways of writing code that has a different meaning in C and C++. However, C++ supports every programming technique supported by C. Every C program can be written in essentially the same way in C++ with the same run-time and space efficiency. It is not uncommon to be able to convert tens of thousands of lines of ANSI C to C-style C++ in a few hours. Thus, C++ is as much a superset of ANSI C as ANSI C is a superset of K&R C and much as ISO C++ is a superset of C++ as it existed in 1985.

    Well written C tends to be legal C++ also. For example, every example in Kernighan & Ritchie: "The C Programming Language (2nd Edition)" is also a C++ program.

    Examples of C/C++ compatibility problems:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    int main()
    {
    	double sq2 = sqrt(2);   /* Not C++: call undeclared function */
    	int s = sizeof('a');    /* silent difference: 1 in C++ sizeof(int) in C */
    }
    Calling an undeclared function is poor style in C and illegal in C++. So is passing arguments to a function using a declaration that doesn't list argument types:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    void f();	/* argument types not mentioned */
    
    void g()
    {
    	f(2);	/* poor style C. Not C++ */
    }
    In C, a void* can be implicitly converted to any pointer type, and free-store allocation is typically done using malloc() which has no way of checking if "enough" memory is requested:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    void* malloc(size_t);
    
    void f(int n)
    {
    	int* p = malloc(n*sizeof(char));  /* not C++. In C++, allocate using `new' */
    	char c;
    	void* pv = &c;
    	int* pi = pv;   /* implicit conversion of void* to int*. Not in C++ */
    }
    Note the potential alignment error caused by the implicit conversion of the void* to a int*. See the C++ alternative to void* and malloc().

    When converting from C to C++, beware that C++ has more keywords than C:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    int class = 2;    /* ok in C. Syntax error in C++ */
    int virtual = 3;  /* ok in C. Syntax error in C++ */
    Except for a few examples such as the ones shown above (and listed in detail in the C++ standard and in Appendix B of The C++ Programming Language (3rd Edition)), C++ is a superset of C. (Appendix B is available for downloading).

    Please note that "C" in the paragraphs above refers to Classic C and C89. C++ is not a descendant of C99; C++ and C99 are siblings. C99 introduces several novel opportunities for C/C++ incompatibilities.

    Les mots clés et opérateurs de base du C y sont tous, sans exceptions.
    Mmh… au hasard… restrict ?
    Cours : Initiation à CMake
    Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
    Ce message a été tapé avec un clavier en disposition bépo.

  9. #209
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Novembre 2008
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Finance

    Informations forums :
    Inscription : Novembre 2008
    Messages : 44
    Points : 66
    Points
    66
    Par défaut
    C'est surtout la redirection répétée pour accéder aux index qui ralentissait le programme. Il faut dire qu'on parle de cycles CPU en MHz ici Le code n'avait pas le temps de capturer les inputs et gérer les index sans que le buffer du ring soit plein et perde les inputs suivants. J'imagine que j'aurais pu trouver quelque chose, mais à quoi bon puisque la version C que j'avais sous la main était parfaitement fonctionnelle? Pour moi, c'était du C de toute façon, du très bon code.

    A+

    Citation Envoyé par Mat.M Voir le message
    'Alut



    je fais un peu du hors sujet mais faut voir.
    Si tu fais une classe avec usage intensif d'héritage cela risque d'entrainer des ralentissements...
    mais j'en doute parce que les compilateurs sont particulièrements bien optimisés pour ce genre de code...
    maintenant avec les duo et quad cores tu peux optimiser ton code , utiliser le multithreading et roulez jeunesse

  10. #210
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Novembre 2008
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Finance

    Informations forums :
    Inscription : Novembre 2008
    Messages : 44
    Points : 66
    Points
    66
    Par défaut
    L'essentiel est dit ici:

    «Thus, C++ is as much a superset of ANSI C as ANSI C is a superset of K&R C and much as ISO C++ is a superset of C++ as it existed in 1985»

    C'est exactement ce que je dis.

    Quant à M. Stroustrup, il parle pour parler. Il devrait aussi nous dire pourquoi les codeurs de C/C++, comme il dit, ont été obligé pendant longtemps d'utiliser les librairies C avec le C++, parce que les librairies C++ qu'il a proposé au départ (les iostream & cie) étaient nettement insuffisantes. Je sais ici de quoi je parle, ça m'a stressé longtemps. Nul besoin de dire que nous ne nous sommes pas privé des librairies C avant l'arrivé du STL Et il passe ça sur le dos des codeurs...

    On va lui pardonner, on lui doit bien ça Notons qu'il écorche au passage quelques grands du C qui ont adopté le C++ avec enthousiasme, sans nécessairement perdre leur habitudes de vieux renards. C'était pourtant tout l'intérêt du C++: récupérer cette base là.

    Il me fait penser un peu à Linus Torval, que j'aime bien aussi, mais qui se tire dans le pied périodiquement. Il a passé des années à tenter d'assassiner GNOME pour louanger KDE, pour finalement changer son fusil d'épaule et inviter tout le monde à adopter GNOME pour proposer de boycotter KDE4. Les génies ne sont pas le bon Dieu. Pourtant, moi qui n'aurait jamais une fraction de son génie, il y a longtemps que j'ai compris que si IBM et Sun ont adopté GNOME, si GNOME est la base des suites Mozilla et OpenOffice, c'est que ça fait un moment que GNOME a gagné la course... Pourquoi a-t-il perdu sa salive?

    L'article référé ensuite dit que malloc(), c'est du C, et "new" c'est du C++. Évidemment, parce que "new", c'est de l'OO, alors que malloc c'est de la programmation fonctionnelle. C'est l'évidence que si on veut coder du OO, on doit utiliser new et autres outils "++", sinon, on se complique la vie. Par exemple (pardonnez, je suis rouillé un peu en C):

    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
    struct o {
      int o_x;
    };
    
    inline int get_x(struct o* this)
    {
      return this->o_x;
    }
    
    inline void set_x(struct o* this, int x)
    {
      this->o_x = x;
    }
    
    main()
    {
      struct o* po1 = malloc(sizeof(struct o));
    
      set_x(po1, 10);
      printf("x=%d\n", get_x(po1));
    
      free(po1);
    
      return 0;
    }
    en C++, ça devient:

    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
    class o {
      int o_x;
    
    public:
      int get_x() // implémenté en inline
      {
        return o_x;
      }
    
      void set_x(int x) // implémenté en inline
      {
        o_x = x;
      }
    };
    
    main() { // ou bien une classe statique app::main(...) maison
      o* po1 = new o();
    
      po1->set_x(10);
      cout << "x=" << po1->get_x() << endl; // je pourrais utiliser printf
    
      delete po1;
    
      return 0;
    }
    Le premier compile en C++, et le second lui est quand même très similaire, en plus bref, avec la possibilité d'utiliser les extensions ++: les héritages, les overload, les encapsulations et les fonctions virtuelles. Même si le C++ supporte la programmation fonctionnelle du C, on essaie de programmer objet plutôt que fonctionnel. Et Même M. Stroustrup doit bien se rabattre sur le C quand il faut du bas niveau. Sinon, pourquoi a-t-il permis de définir des fonctions avec le fameux extern "C"????

    Soyons logique!

    Ce n'est en fin de compte qu'une question de perception. Ou une question de purisme, c'est selon.



    P.S. autre détail genre "cassé", de Brice de Nice, les fichiers objets C peuvent être linkés et donc inclus avec les programmes C++. Quelques extern "C" et le tour est joué. Un seul et même programme. C ou C++?

    Citation Envoyé par Florian Goo Voir le message
    Malheureusement pour toi, le créateur du C++ lui-même n'est pas d'accord avec toi. Peut-être devrais-tu remettre tes certitudes en question ?

    http://www2.research.att.com/~bs/bs_faq.html#C-slash
    Mais peut-être que Bjarne Stroustrup est un « intégriste » qui ne « s'intéresse pas à l'informatique » ?


    Quand tu prétends à une compatibilité à 100%, là encore tu te trompes :




    Mmh… au hasard… restrict ?

  11. #211
    Membre éclairé
    Avatar de Florian Goo
    Profil pro
    Inscrit en
    Septembre 2008
    Messages
    680
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Septembre 2008
    Messages : 680
    Points : 858
    Points
    858
    Par défaut
    Citation Envoyé par ruste Voir le message
    Quand à M. Stroustrup, il parle pour parler. Il devrait aussi nous dire pourquoi les codeurs de C/C++, comme il dit, ont été obligé pendant longtemps d'utiliser les librairies C avec le C++, parce que les librairies C++ qu'il a proposé au départ (les iostream & cie) étaient nettement insuffisantes. Je sais ici de quoi je parle, ça m'a stressé longtemps. Nul besoin de dire que nous ne nous sommes pas privé des librairies C avant l'arrivé du STL Et il passe ça sur le dos des codeurs...
    En effet, il était pertinent (voire nécessaire) d'utiliser des libs C à cette époque, donc de faire ce qu'on appelle du C-style C++. Cette situation justifiait d'ailleurs les méthodes d'apprentissage des cours de C++ dont les premiers chapitres étaient consacrés au C.
    Mais aujourd'hui la situation a bien évolué. Le C++ n'est plus le « C with classes » de ses débuts, mais bel et bien un langage à part entière. Ce qui était justifié à l'époque ne l'est plus aujourd'hui. Tu ne peux pas te baser sur la situation telle qu'elle était il y a 20 ans pour justifier tes méthodes d'aujourd'hui.

    Un exemple que je trouve significatif (bien qu'il ne s'agisse que de code et non de conception) est le cast. La façon C, c'est « (type)valeur ». La façon C++, c'est static_cast<type>(valeur), dynamic_cast, const_cast et reinterpret_cast. Beaucoup de livres sur les bonnes pratiques en C++ déconseillent l'utilisation des casts à la C.
    Et c'est un exemple parmi tant d'autres.

    L'article référé ensuite dit que malloc(), c'est du C, et "new" c'est du C++. Évidemment, parce que "new", c'est de l'OO, alors que malloc c'est de la programmation fonctionnelle.
    Non, on peut utiliser « new » avec les types primitifs (ainsi que « new[] » pour les tableaux).
    C'est juste l'allocation mémoire « à la C++ » (encore un exemple).

    Le premier compile en C++, et le second lui est quand même très similaire, en plus bref, avec la possibilité d'utiliser les extensions ++: les héritages, les overload, les encapsulations et les fonctions virtuelles.
    Ce qui me chagrine, c'est le fait que tu perçois le C++ comme un panel d'extensions pratiques, alors que de la conception au code, la résolution des problèmes changent du tout au tout.

    Même si le C++ supporte la programmation fonctionnelle du C, on essait de programmer objet plutôt que fonctionnel.
    Impératif, tu veux dire ?
    Quand tu dis que tu essaies de programmer objet, ça renforce ma sensation que tu résous tes problèmes d'un point de vue de programmeur C, et que tu te contentes de piocher dans le C++ un sous-ensemble de petites fonctionnalités pratiques.

    Et Même M. Stroustrup doit bien se rabattre sur le C quand il faut du bas niveau. Sinon, pourquoi a-t-il permis de définir des fonction avec le fameux extern "C"????
    Justement, je te retourne la question.
    Si le C était à proprement parler un sous-ensemble du C++, quelle serait l'utilité d'expliciter l'usage de code C via un bloc « extern "C" » ?
    L'intérêt de « extern "C" » est justement de permettre une rétrocompatibilité qui n'est pas naturelle (vu qu'elle doit être explicitée).

    Sinon, bien entendu que le paradigme objet se retrouverait manchot sans le paradigme impératif.
    Par ailleurs, le C++ se revendique comme étant multi-paradigme.
    En revanche, comme je l'ai expliqué avec quelques exemples (C-style cast vs C++-style casts, malloc/realloc/free vs new/delete), on ne peut pas assimiler le versant impératif du C++ au C.

    P.S. autre détail genre "cassé", de Brice de Nice, les fichier objets C peuvent être linkés et donc inclus avec les programmes C++. Quelques extern "C" et le tour est joué. Un seul et même programme. C ou C++?
    Autre réponse du genre « cassé » : la VCL de C++Builder est codée en Pascal Objet (ou en Delphi, pour reprendre les propos approximatifs de Tiobe). Tout est linké ensemble, un seul et même programme. Le C++ et le Pascal Objet seraient alors un même langage ?
    Je ne vais quand même pas t'apprendre les différentes étapes de construction d'un binaire, non ?
    Cours : Initiation à CMake
    Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
    Ce message a été tapé avec un clavier en disposition bépo.

  12. #212
    gl
    gl est déconnecté
    Rédacteur

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

    Informations forums :
    Inscription : Juin 2002
    Messages : 2 165
    Points : 4 637
    Points
    4 637
    Par défaut
    Citation Envoyé par ruste Voir le message
    L'article référé ensuite dit que malloc(), c'est du C, et "new" c'est du C++. Évidemment, parce que "new", c'est de l'OO, alors que malloc c'est de la programmation fonctionnelle.
    Pardon ? de la programmation fonctionnelle en C ?

    Étrangement, je comprends mieux ta position maintenant.

    Citation Envoyé par ruste Voir le message
    C'est l'évidence que si on veut coder du OO, on doit utiliser new et autres outils "++", sinon, on se complique la vie. Par exemple (pardonnez, je suis rouillé un peu en C):

    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
    struct o {
      int o_x;
    };
    
    inline int get_x(struct o* this)
    {
      return this->o_x;
    }
    
    inline void set_x(struct o* this, int x)
    {
      this->o_x = x;
    }
    
    main()
    {
      struct o* po1 = malloc(sizeof(struct o));
    
      set_x(po1, 10);
      printf("x=%d\n", get_x(po1));
    
      free(po1);
    
      return 0;
    }
    en C++, ça devient:

    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
    class o {
      int o_x;
    
    public:
      int get_x() // implémenté en inline
      {
        return o_x;
      }
    
      void set_x(int x) // implémenté en inline
      {
        o_x = x;
      }
    };
    
    main() { // ou bien une classe statique app::main(...) maison
      o* po1 = new o();
    
      po1->set_x(10);
      cout << "x=" << po1->get_x() << endl; // je pourrais utiliser printf
    
      delete po1;
    
      return 0;
    }
    Le premier compile en C++,
    Non.

    Citation Envoyé par ruste Voir le message
    Même si le C++ supporte la programmation fonctionnelle du C
    Même remarque que précédemment.

    Citation Envoyé par ruste Voir le message
    on essaie de programmer objet plutôt que fonctionnel.
    Non, on essaie pas de programmer objet. On essaie plutôt d'utiliser le paradigme le plus adéquat pour le problème donné.

    Citation Envoyé par ruste Voir le message
    Et Même M. Stroustrup doit bien se rabattre sur le C quand il faut du bas niveau. Sinon, pourquoi a-t-il permis de définir des fonctions avec le fameux extern "C"????
    Je ne nie pas que ce soit intéressant d'appeler du code C depuis du code C++, ni même qu'une part importante du C fasse partie du C++.

    Sans n'en reste pas moi deux langages différents.

    Citation Envoyé par ruste Voir le message
    P.S. autre détail genre "cassé", de Brice de Nice, les fichier objets C peuvent être linkés et donc inclus avec les programmes C++. Quelques extern "C" et le tour est joué. Un seul et même programme. C ou C++?
    De nombreux langages sont capables d'appeler du code C et de se lier avec des fichiers objets provenant d'un code source C. Cela veut-il dire que tout ces langages sont du C ?

  13. #213
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Novembre 2008
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Finance

    Informations forums :
    Inscription : Novembre 2008
    Messages : 44
    Points : 66
    Points
    66
    Par défaut
    Citation Envoyé par gl Voir le message
    Pardon ? de la programmation fonctionnelle en C ?
    On se calme, je ne parle pas de la programmation fonctionnelle comme le ML, je faisais plutôt référence à la programmation classique (il y a un terme spécifique qui m'échappe), que plusieurs adeptes de l'OO ont nommé «spaghetti code». Je ne me souviens plus du terme exact, désolé.

    Citation Envoyé par gl Voir le message
    De nombreux langages sont capables d'appeler du code C et de se lier avec des fichiers objets provenant d'un code source C. Cela veut-il dire que tout ces langages sont du C ?
    Il y a une nuance entre appeler du code C et pouvoir l'intégrer tel quel. Et ils ne deviennent pas tous du language machine non plus. Le C/C++ est le seul langage que je pouvais traduire à main en assembleur sans trop m'éloigner du code produit effectivement par le compilateur (vérifiable avec -S). J'aurais aussi pu prendre du code généré avec -S et l'intégrer à n'importe quel programme assembleur. Pour moi, le C, c'est un raccourci pour l'assembleur. Seul le language machine exploite véritablement à fond la machine, alors je n'aime pas trop m'en éloigner avec tous ces languages de Nième génération et tous leur flafla. Seul le C++ me satisfait à cet égard, car il me permet de rester coller au C (et donc à l'assembleur), tout en profitant des fonctionnalités OO.

    Là, vous pouvez dire que vous comprenez ma position. La religion du C ou du C++, n'en ai rien à faire.

  14. #214
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Novembre 2008
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Finance

    Informations forums :
    Inscription : Novembre 2008
    Messages : 44
    Points : 66
    Points
    66
    Par défaut
    Citation Envoyé par Florian Goo Voir le message
    Mais aujourd'hui la situation a bien évolué.
    Oui????

    Citation Envoyé par Florian Goo Voir le message
    Le C++ n'est plus le « C with classes » de ses débuts, mais bel et bien un langage à part entière. Ce qui était justifié à l'époque ne l'est plus aujourd'hui. Tu ne peux pas te baser sur la situation telle qu'elle était il y a 20 ans pour justifier tes méthodes d'aujourd'hui.
    Non, en effet. Je me base sur la situation aujourd'hui, sur les plus récents ouvrages sur le C++, sur les programmes C++ que nous développons aussi chez mon employeur, et même sur un ouvrage sur le C++ écrit à la fin des années '90, et qui comprend à peu près toutes les plus récentes évolutions du C++, à peu de choses près comme les auto_ptr. J'ai d'ailleurs été marqué de voir comment le C++ avait quasi stoppé son évolution depuis. Vivement le C++OX.

    Citation Envoyé par Florian Goo Voir le message
    Beaucoup de livres sur les bonnes pratiques en C++ déconseillent l'utilisation des casts à la C.
    C'est compréhensible, l'OO a besoin de plus de validation à ce niveau. Le C est très libertin là dessus. C'était un ajout incontournable pour dire qu'on fait du C objet. Ça m'a d'ailleurs causé des mots de tête quand j'ai du apprendre d'autres language typés comme le Java et le ADA.

    Citation Envoyé par Florian Goo Voir le message
    Non, on peut utiliser « new » avec les types primitifs (ainsi que « new[] » pour les tableaux).
    C'est juste l'allocation mémoire « à la C++ » (encore un exemple).
    Tellement que j'ai déjà vu un compilateur C++ implémenter new avec malloc. J'avais bien rigolé en voyant ça. Mais je ne crois pas me tromper en disant que si le "new" a été adopté, c'est pour respecter la manière OO.

    Citation Envoyé par Florian Goo Voir le message
    Ce qui me chagrine, c'est le fait que tu perçois le C++ comme un panel d'extensions pratiques, alors que de la conception au code, la résolution des problèmes changent du tout au tout.
    Pourtant, ce n'est pas moi qui dit ça:

    Thus, C++ is as much a superset of ANSI C as ANSI C is a superset of K&R C and much as ISO C++ is a superset of C++ as it existed in 1985
    Citation Envoyé par Florian Goo Voir le message
    Quand tu dis que tu essaies de programmer objet, ça renforce ma sensation que tu résous tes problèmes d'un point de vue de programmeur C, et que tu te contentes de piocher dans le C++ un sous-ensemble de petites fonctionnalités pratiques.
    Hé, vous parlez à un codeur Java par les temps qui courrent. Je fais du J2EE. À ma connaissance, l'OO est supposé implémenter des objets encapsulés accessible avec des méthodes, qui envoient des messages à l'objet pour communiquer avec. Dans cette perspective, le C++ est quasi du simili-OO. Même le C a réussi une implémentation plus vrai de l'OO avec X Window:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    Widget top_wid;
    Widget main_w;
        
    /* MAIN_W */
        main_w = (Widget)XmCreateForm(top_wid, "main_window", NULL, 0);
        XtManageChild(main_w);
    Là, ce code Motif/CDE (CDE est-il du vrai Motif???) utilise XMCreate* pour créer des objets, et pas malloc!!! On peut utiliser XtAlloc, si on veut faire des allocationsur le serveur X plutôt que sur le serveur d'application. X Window implémente l'encapsulation et l'héritance à 100%, en langage C s.v.p. Si on suit les arguments que je lis ici, il faudrait dire que de coder du X Window, ce n'est pas du vrai C puisque il ne suit pas la façon recommandée de coder en C (ca se voit a l'oeil dans l'exemple ci-haut). Aaah l'absolutisme!

    Note en passant: admettons que le MIT a fait du beau boulot avec X Window.

    Citation Envoyé par Florian Goo Voir le message
    Justement, je te retourne la question.
    Si le C était à proprement parler un sous-ensemble du C++, quelle serait l'utilité d'expliciter l'usage de code C via un bloc « extern "C" » ?
    À cause de la façon dont les étiquettes du code objet sont définient par le compilateur. En C, une fonction abc sera étiquetée comme _abc ou abc, selon le compilateur. En C++, certains paramètres viennent contribuer à préfixer et à "suffixer" l'objet de façon imprévisible. Par exemple, un code que j'ai compilé avec gcc -S a traduit une fonction start_routine en _Z13start_routinePv. Celle-ci même si elle est codée en C ne pourra pas être appelé par du C ordinaire avec un simple appel à start_routine(). En précédant la définition de start_routine avec extern "C", gcc l'a étiqueté au format C. Il pourra donc être appelé normalement par du code compilé en C ou autre. Mais si vous compilez votre module C en C++, le extern "C" n'est plus nécessaire.

    Pour la rétrocompatibilité, les compilateurs C/C++ peuvent souvent encore compiler du K&G C. Pourquoi donc? C'est encore et toujours du C. Et que dire du C AIX et du C Solaris? Sont-ils compatibles? Alors, si on suit votre raisonnement, aucun d'eux n'est du C. Bref, vous tiquez sur les détails ici.

    Citation Envoyé par Florian Goo Voir le message
    Autre réponse du genre « cassé » : la VCL de C++Builder est codée en Pascal Objet (ou en Delphi, pour reprendre les propos approximatifs de Tiobe). Tout est linké ensemble, un seul et même programme. Le C++ et le Pascal Objet seraient alors un même langage ?
    Je ne vais quand même pas t'apprendre les différentes étapes de construction d'un binaire, non ?
    Pas mal Brice Mais l'aspect compilation commune n'est qu'un des aspect de mon argumentation, et pas tous les aspects. Mais si je vous disait qu'avec des macros, on peut coder du Pascal et le compiler avec un compilateur C (véridique), me diriez-vous que c'est du Pascal ou du C?

    On pourrait continuer longtemps comme ça. Tout est une question de perspective. Par tradition, le K&R C a précédé le C, qui a précédé le C++. Tous sont en relative continuité évolutive et backward compatibles directement ou avec des options à l'exécution du compilateur. C'est toujours du C pour moi (it's still rock'n'roll to me ). Si quelqu'un veut faire une option pour compiler en Pascal, ce n'est pas moi qui se fera du stress à décider si c'est encore du C ou non. Dans mon esprit, je n'ai jamais arrêté d'être un programmeur et un adepte du C, ce à toute époque.

    Cordialement.

  15. #215
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Août 2003
    Messages : 5 275
    Points : 10 985
    Points
    10 985
    Par défaut
    Pourquoi on pinaille ?
    Parce que bien utilisés, ces langages ne se manipulent pas du tout de la même façon. La faute aux exceptions. Tu parlais de l'avancée qu'est le GC en sous-entendant, qu'en C/C++ on n'a rien d'équivalent. En C/C++ (et j'assume mon sentiment péjoratif à l'égard de ce terme), c'est vrai.
    En C++, c'est on ne peut plus faux.

    On remplace un système non déterministe de libération implicite de mémoire (GC) doublé d'un système explicite déterministe de libération de ressources (finally) par un seul et même système implicite et déterministe de libération de ressources (dont mémoire) : le RAII.
    C'est le truc qui fait que le C++ bien employé ne peut sérieusement ressembler à du C, ou du moins intégrer impunément les méthodes de développement propres au C. (Certes les types sont un chouilla plus long à taper. Mais vu qu'on le rattrape sur tous les codes de gestion d'erreur, c'est un excellent investissement.)

    Bien sûr, on peut toujours le faire, ou croire qu'on le fait bien si on fait semblant de vivre dans le pays magique où new ne renverrait aucune exception. Bien sûr, on peut forcer new a avoir un comportement pré-standard (<98), est-ce qu'on y gagne ? Pas en ce qui me concerne.
    En quoi je programme ? En C++ et définitivement pas en C/C++, chose qui dans mon acception est dépourvu de la systématisation de l'utilisation du RAII.

    (je décrypte entre mes lignes : la différence profonde entre C et C++, ce n'est pas l'OO ou les templates, ce sont les exceptions et le RAII)
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  16. #216
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Novembre 2008
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Finance

    Informations forums :
    Inscription : Novembre 2008
    Messages : 44
    Points : 66
    Points
    66
    Par défaut
    Citation Envoyé par gl Voir le message
    Pardon ? de la programmation fonctionnelle en C ?

    Étrangement, je comprends mieux ta position maintenant.
    Ça y est, je me rappelle. Le buz word pour les langages du type C, Pascal et autres c'est «programmation structurée». C'est ce que je voulais dire. J'étirerais peut-être la sauce en disant aussi «langage procédural», mais comme en C les procédures sont des fonctions, je l'ai traduis plus ou moins consciemment en programmation «fonctionnelle», sans faire attention au type récursif auquel ça fait référence.

  17. #217
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Novembre 2008
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Finance

    Informations forums :
    Inscription : Novembre 2008
    Messages : 44
    Points : 66
    Points
    66
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    Tu parlais de l'avancée qu'est le GC en sous-entendant, qu'en C/C++ on n'a rien d'équivalent.
    Hé ho! Lecture rapide. J'essayais de dire que la masse requise de développeurs pour répondre aux besoins actuels fait que ce qui sort des écoles d'informatique modernes exige un système qui pardonne moins de science machine et donc plus de négligence. Ce n'est plus comme avant, où l'informatique était d'usage limité et exclusif à quelques uns. Maintenant, à part les geeks, on (qui exclue la personne qui parle) ne veut plus rien savoir du Heap. On veut juste coder du Java, faire des flammèches, faire du RAD RAD RAD et rentrer se coucher. Je ne le blâme pas, je constate simplement. C'est ainsi.

    Je n'ai jamais dis que le GC était une évolution autant qu'un mal nécessaire. C'est précisément pour solutionner ce problème nouveau que le GC est utilisé en Java. Le C/C++ (appelez le simplement C++, ça m'indifère, c'est pareil pour moi) nécessite un niveau de maîtrise élevé pour être utilisé efficacement (les pointeurs), ce qui est un luxe que beaucoup ne peuvent pas se permettre. Tant mieux pour nous qu'ils n'aient pas choisi de niveller par le bas le langage C/C++ et plutôt opté d'en dériver le Java.

    Citation Envoyé par Luc Hermitte Voir le message
    C'est le truc qui fait que le C++ bien employé ne peut sérieusement ressembler à du C, ou du moins intégrer impunément les méthodes de développement propres au C.
    Il est évident que le C++ OO ne ressemble pas au C. C'est aussi le cas avec le code de X Window, pourtant 100% codé en C. Un PC Compatible reste un PC Compatible, quand bien même les programmes plus récents ne roulent pas sur les vieilles machines. De la même façon, le C reste du C. C'est pourquoi on s'est contenté de placer un simple ++ après, car c'est une extension du C qui nous permet de coder du OO avec du langage C. Si on dit C/C++, c'est que le C est un fondement du C++. Pas seulement au niveau des librairies, mais aussi du legacy du C, accessible aussi au C++. 25 ans c'est long à rattraper, et convertir le code, ça coûte cher. Mieux vaut souvent intégrer. Très brillant l'auteur du C+. UNIX est un bel exemple, avec son OS en C et ses applications souvent en C++.

    Pour la librairie C, comment allez-vous, par simple exemple, vous y prendre pour faire de la gestion de répertoires en C++ ou questionner la date d'un fichier ou du système (pour ne nommer que ça)? À ma connaissance, l'outil standard pour faire ce genre de travail en C++ reste ceux de la librairie C. C'est 25 ans d'héritage dont on parle, accessible à même le C++.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    /** @file include/cstdlib
     *  This is a Standard C++ Library file.  You should @c #include this file
     *  in your programs, rather than any of the "*.h" implementation files.
     *
     *  This is the C++ version of the Standard C Library header @c stdlib.h,
     *  and its contents are (mostly) the same as that header, but are all
     *  contained in the namespace @c std (except for names which are defined
     *  as macros in C).
     */
    Je lis bien dans ce code "This is the C++ version of the Standard C Library header".

    J'ai ici le source d'un mozilla récent, qui inclut Firefox. J'ai compté vite 4656 fichiers avec une extension cpp, et 1593 avec une extention c. Selon vous, du C ou du C++? D'évidence, on a voulu et/ou éviter de recoder, et/ou profiter des forces de chacun. Tout ça compilé avec le même outil.

    Moi, ce qui m'intéresse, ce n'est pas le flafla du langage, c'est-ti du C, c'est-ti du C++, mais bien d'exploiter au maximum la machine sur laquelle mon logiciel roule. Je soupçonne que c'est aussi ce qui intéresse mon employeur. Or, le C++ est handicapé de bien des façons sans l'héritage du C et le C traîne de l'arrière sans son extension ++. Mon avis seulement.

  18. #218
    Membre actif
    Avatar de vosaray
    Profil pro
    Architecte technique
    Inscrit en
    Mai 2004
    Messages
    217
    Détails du profil
    Informations personnelles :
    Localisation : France

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

    Informations forums :
    Inscription : Mai 2004
    Messages : 217
    Points : 299
    Points
    299
    Par défaut
    HS : Je ne savais pas que les discussion C/C++ pouvaient autant enflammer les topics, surtout de nos jours ...

    Pour revenir à l'article et surtout au classement TIOBE, je mets vraiment en doute la méthode utilisée ...

    Si je cherche par exemple JQuery est que ce résultat sera associé à JavaScript ?

    D'après, ce que j'ai compris, pas du tout puisque JavaScript regroupe les keywords JavaScript, JScript et ECMAScript...

    Et ruby ? Tiens il n'y a même pas rails dans le grouping.

    Du coup je trouve les résultats assez drôles (par exemple Delphi en 10eme position .. ) et l'étude assez peu pertinente ...

  19. #219
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Août 2003
    Messages : 5 275
    Points : 10 985
    Points
    10 985
    Par défaut
    @ruste, de ta réponse, je perçois que tu es passé à côté de ce que je disais.
    Comme toi, je ne mets pas la différence au niveau OO. Après tout, c'était bien ça les origines du C/C++ : du C avec des classes.

    Seulement je vois une différence très importante : la façon canonique de traiter les cas non nominaux. L'introduction des exceptions au C++ change suffisamment la donne pour que l'on renonce dans les codes "métiers" à l'approche C.
    Et pourtant il y a quantité de codes qui n'ont pas réalisé cette migration, quantité de codes qui sont infernaux à maintenir, quantité de code qui méritent leur appellation C/C++ ...

    @vosaray. Ben oui, c'est tiobe ... Je ne pensais pas que l'on mérite que l'on s'attarde dessus. Quoique j'ai lu ici des réactions qui me font dire que certains le trouvait ... intéressant, voire ... pertinent.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  20. #220
    Membre du Club
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Février 2006
    Messages
    38
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : Février 2006
    Messages : 38
    Points : 53
    Points
    53
    Par défaut
    Du moment que windev n'est pas dans les stats ! Sinon cela voudra dire que les sécretaires se sont mise à développer. (^_^)

Discussions similaires

  1. JavaScript en tête du classement des langages de programmation
    Par Hinault Romaric dans le forum Actualités
    Réponses: 31
    Dernier message: 07/08/2014, 12h45
  2. Parts de marchés des langages de programmation
    Par Marc Lussac dans le forum Langages de programmation
    Réponses: 51
    Dernier message: 21/05/2013, 13h51
  3. L'avenir des langages de programmation
    Par LordBob dans le forum Langages de programmation
    Réponses: 14
    Dernier message: 02/04/2006, 23h03
  4. Classement des langages
    Par trattos dans le forum Langages de programmation
    Réponses: 9
    Dernier message: 07/12/2005, 12h09

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo