Index TIOBE du classement des langages de programmation

[ruste]

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

Envoyé par Florian Goo

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 ?

[spidermario]

Envoyé par ruste

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 !

Envoyé par ruste

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.

[Mat.M]

'Alut

Envoyé par ruste

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

[bioinfornatics]

Envoyé par Mat.M

s tu peux optimiser ton code , utiliser le multithreading et roulez jeunesse

Tout n'est pas parrallelisable malheureusement

[spidermario]

Envoyé par Mat.M

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.

[ruste]

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+

Envoyé par spidermario

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.

[gl]

Envoyé par ruste

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.

Envoyé par ruste

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.

[Florian Goo]

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 ?

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 :

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 :

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 :

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 :

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 ?

[ruste]

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+

Envoyé par Mat.M

'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

[ruste]

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 :

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 :

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++?

Envoyé par Florian Goo

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 ?

[Florian Goo]

Envoyé par ruste

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 ?

[gl]

Envoyé par ruste

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.

Envoyé par ruste

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 :

en C++, ça devient:

Code :

Le premier compile en C++,

Non.

Envoyé par ruste

Même si le C++ supporte la programmation fonctionnelle du C

Même remarque que précédemment.

Envoyé par ruste

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

Envoyé par ruste

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.

Envoyé par ruste

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 ?

[ruste]

Envoyé par gl

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

Envoyé par gl

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.

[ruste]

Envoyé par Florian Goo

Mais aujourd'hui la situation a bien évolué.

Oui????

Envoyé par Florian Goo

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.

Envoyé par Florian Goo

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.

Envoyé par Florian Goo

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.

Envoyé par Florian Goo

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

Envoyé par Florian Goo

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 :

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.

Envoyé par Florian Goo

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.

Envoyé par Florian Goo

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.

[Luc Hermitte]

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)

[ruste]

Envoyé par gl

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.

[ruste]

Envoyé par Luc Hermitte

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.

Envoyé par Luc Hermitte

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 :

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.

[vosaray]

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

[Luc Hermitte]

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

[CrashAngel]

Du moment que windev n'est pas dans les stats ! Sinon cela voudra dire que les sécretaires se sont mise à développer. (^_^)