Discussion :

[hegros]

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

Troll inside.

En plus windev ne peut pas rentrer dans ce genre de statistique tronquée car c'est un AGL (et c'est pour cela qu'il est utilisé puisque l'on peut faire du .NET, Java, C ou C++ ou ..) et dans toute la liste il n'y en a aucun.

[Marco46]

Troll inside.

En plus windev ne peut pas rentrer dans ce genre de statistique tronquée car c'est un AGL (et c'est pour cela qu'il est utilisé puisque l'on peut faire du .NET, Java, C ou C++ ou ..) et dans toute la liste il n'y en à aucun.

Delphi est bien présent pourtant ?

Quelle différence entre Windev et Delphi ?

Je crois plutôt que la non-apparition de Windev tient à ce que cet outil est surtout utilisé dans la francophonie et très peu chez les anglophones.

PCSoft c'est une PME de 60 salariés/15M € de CA. C'est tout petit.

[hegros]

Delphi est bien présent pourtant ?

Quelle différence entre Windev et Delphi ?

Delphi est un RAD pas un AGL. Les différences se situent à ce niveau.

Je crois plutôt que la non-apparition de Windev tient à ce que cet outil est surtout utilisé dans la francophonie et très peu chez les anglophones.

PCSoft c'est une PME de 60 salariés/15M € de CA. C'est tout petit.

Oui je suis plutôt d'accord avec cela et j'ajouterais aussi que Windev ne nécessite pas de googler toute la journée pour trouver comment faire ceci ou cela puisque cela se veut plus simple.

[Florian Goo]

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.

Personnellement je pense au contraire qu'aujourd'hui, le C++ traine l'héritage du C comme un boulet.
Notamment, le typage de C est trop faible. Il n'y a qu'à constater les ajouts passés et futurs au C++ pour tenter de palier à ces faiblesses :
- le type bool ;
- le mot-clé nullptr (C++0x) ;
- les casts à la C++ ;
- l'idiome « safe bool » ;
- les opérateurs de conversion explicites (C++0x, entre autres une solution built-in plus propre que l'idiome « safe bool ») ;
- et j'en oublie sûrement beaucoup.

Encore une preuve que le C++ devrait davantage être perçu comme une branche du C s'étant éloignées (et s'éloignant encore) de ses origines, que comme un digne héritier perpétuant les traditions familiales.

[ruste]

Notamment, le typage de C est trop faible. Il n'y a qu'à constater les ajouts passés et futurs au C++ pour tenter de palier à ces faiblesses :
- le type bool ;
- le mot-clé nullptr (C++0x) ;
- les casts à la C++ ;
- l'idiome « safe bool » ;
- les opérateurs de conversion explicites (C++0x, entre autres une solution built-in plus propre que l'idiome « safe bool ») ;
- et j'en oublie sûrement beaucoup.

Je comprends ce que vous voulez dire. Disons que le C++ se doit d'être plus que vénérable, il doit être à la page. Je m'accorde avec vous là-dessus.

Encore une preuve que le C++ devrait davantage être perçu comme une branche du C s'étant éloignée (et s'éloignant encore) de ses origines, que comme un digne héritier perpétuant les traditions familiales.

D'un autre côté, allons trop loin et nous perdons l'avantage principal du C++. Soyons réaliste, on ne recodera pas tous les UNIX et dérivés en C++. Et UNIX ne semble pas prêt pour la retraite non plus, surtout avec Mac OS X qui vient d'entrer dans la famille. La base de C est trop considérable. C'est dans ce sens là que je parle d'héritage du C++: aucun autre langage OO, à mon avis, ne s'intègre mieux au C que le C++. Si c'est un boulet, alors c'est un boulet enviable. Il existe d'autres langages OO plus pointu, peut-être meilleurs que le C++. Quel serait l'intérêt pour le C++ de simplement devenir l'un d'entre eux?

Je crois comprendre en vous lisant que les programmeurs de C++ d'aujourd'hui ne veulent plus se familiariser avec le C. Pour ma part, je peux aussi bien mettre mon nez dans le code de Mozilla que dans celui d'UNIX, sans même me figurer si c'est du C ou du C++. Je peux aussi faire du très bon OO avec du C. Je suis confortable dans les deux (ou trois?). Je me sentirais limité autrement dans ma capacité à exploiter ma machine.

Un point sur lequel ce sujet m'a convaincu par contre: il est vital pour les plus anciens codeurs de C++ de bien se familiariser avec la nature du OO, pour éviter de faire ce que vous appelez des programmeurs C/C++. Mais encore là, je confierais ma chemise à l'un d'eux avant de me risquer avec quelqu'un qui n'aurait pas fait ses preuves. À mon travail, j'ai vu beaucoup de nouveaux par ailleurs très talentueux entrer avec leurs grandes théories et «améliorer» le code. Avant, le C++ qui était utilisé était peut-être de base et un tantinet ennuyeux à lire (on aime écrire des romans aujourd'hui), mais il fonctionnait et était simple à maintenir. Après, houlala!

[gl]

D'un autre côté, allons trop loin et nous perdons l'avantage principal du C++. Soyons réaliste, on ne recodera pas tous les UNIX et dérivés en C++. Et UNIX ne semble pas prêt pour la retraite non plus, surtout avec Mac OS X qui viens d'entrer dans la famille. La base de C est trop considérable.

La question n'est pas de recoder tout ce qui existe en C en C++ ni de ne plus pouvoir utiliser de C depuis C++.

Mais pour autant, est-il vraiment important de pouvoir compiler du code C en C++ ? Est-ce vraiment une bonne chose de coder en C++ comme l'on code en C ? Est-ce intéressant de rajouter les nouveautés C en C++ ?

Comme tu l'as dis précédement, il est très simple de lier dans un même programme des fichiers objet générés depuis du C et des fichiers générés depuis du C++ ou d'appeler des bibliothéques C en C++. N'est-ce pas suffisant ?

C'est dans ce sens là que je parle d'héritage du C++: aucun autre langage OO, à mon avis, ne s'intègre mieux au C que le C++. Si c'est un boulet, alors c'est un boulet enviable. Il existe d'autres langages OO plus pointu, peut-être meilleurs que le C++. Quel serait l'intérêt pour le C++ de simplement devenir l'un d'entre eux?

Je crois comprendre en vous lisant que les programmeurs de C++ d'aujourd'hui ne veulent plus se familiariser avec le C. Pour ma part, je peux aussi bien mettre mon nez dans le code de Mozilla que dans celui d'UNIX, sans même me figurer si c'est du C ou du C++. Je peux aussi faire du très bon OO avec du C. Je suis confortable dans les deux (ou trois?). Je me sentirais limité autrement dans ma capacité à exploiter ma machine.

Un point sur lequel ce sujet m'a convaincu par contre: il est vital pour les plus anciens codeurs de C++ de bien se familiariser avec la nature du OO, pour éviter de faire ce que vous appelez des programmeurs C/C++.

Je l'ai déjà dit (et je ne suis pas le seul), il faut arrêter de faire le lien C++ == OO. C'est très réducteur, le C++ apporte bien d'autres choses tout aussi intéressantes (voire plus). L'OO n'est qu'une des facettes du C++.

Effectivement si on voit le C++ uniquement comme un language objet proche du C (du 'C with class" quoi), il perd une grande partie de son intérêt et oui, en l'utilisant de la sorte, on peut parler de C/C++ mais on passe à côté de pas mal de choses.

[souviron34]

je signale juste que pour le débat Java <-> C++ c'est à côté

http://www.developpez.net/forums/d18...t-cpp-vs-java/

et C<->C++

http://www.developpez.net/forums/d32...equel-choisir/

[Florian Goo]

D'un autre côté, allons trop loin et nous perdons l'avantage principal du C++. Soyons réaliste, on ne recodera pas tous les UNIX et dérivés en C++. Et UNIX ne semble pas prêt pour la retraite non plus, surtout avec Mac OS X qui vient d'entrer dans la famille. La base de C est trop considérable. C'est dans ce sens là que je parle d'héritage du C++: aucun autre langage OO, à mon avis, ne s'intègre mieux au C que le C++. Si c'est un boulet, alors c'est un boulet enviable.

Le comité semble faire beaucoup d'efforts pour garder la compatibilité descendante, mais si un jour il devait y avoir rupture de compatibilité avec le C, il sera toujours possible de faire ceci :

Code :

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

1
2
3
4
5
6
extern "C"
{
    #include "une_lib_c.h"
    #include "une_autre_lib_c.h"
}

Il existe d'autres langages OO plus pointus, peut-être meilleurs que le C++. Quel serait l'intérêt pour le C++ de simplement devenir l'un d'entre eux?

À quels langages fais-tu allusion ?

Je crois comprendre en vous lisant que les programmeurs de C++ d'aujourd'hui ne veulent plus se familiariser avec le C.

Non, pas du tout. En ce qui me concerne, il m'arrive de coder en C (non sans plaisir) pour du matériel embarqué (microcontrôleur). C'est juste que je fais une forte distinction entre le C et le C++ ! Et je pense qu'il en est de même pour ceux qui partagent mon opinion.

Un point sur lequel ce sujet m'a convaincu par contre: il est vital pour les plus anciens codeurs de C++ de bien se familiariser avec la nature du OO, pour éviter de faire ce que vous appelez des programmeurs C/C++.

Je suis d'accord. Je pense même qu'il est plus sain d'aborder le C++ à partir de Java que du C, même s'il restera encore beaucoup de choses à apprendre (et à désapprendre).

Avant, le C++ qui était utilisé était peut-être de base et un tantinet ennuyeux à lire (on aime écrire des romans aujourd'hui), mais il fonctionnait et était simple à maintenir. Après, houlala!

Hm, je pense qu'on est tous d'accord ici pour dire qu'un code doit être lisible et facilement maintenable . Si un code (C++ ou non) ne l'est pas, c'est qu'il est mal écrit.


@souviron
Il ne s'agit pas d'un débat C vs C++, mais il est vrai que nous sommes un tantinet hors-sujet .

[ruste]

Pour vous mettre en contexte, j'argumentais que le C et le C++ devaient être envisagés ensembles devant la popularité du Java. Dans ma perspective, l'étude qui est le sujet de ce forum donne le C/C++ comme toujours en avance sur le Java. Mais en les considérant séparément, Java prendrait l'avance.

La plupart ne sont pas d'accord avec cette perspective qui est la mienne et me signifient par leurs arguments que ces langages doivent être comparés séparément, ce qui place Java en premier.

Java en premier, il n'en est pas question.

Le C n'a pas dit son dernier mot devant les dernières tendances (que je nomme OO, mais je veux parler des dernières tendances dans leur ensemble), le C++ est justement venu le supporter pour empêcher ce détrônement de survenir.

je signale juste que pour le débat Java <-> C++ c'est à côté

http://www.developpez.net/forums/d18...t-cpp-vs-java/

et C<->C++

http://www.developpez.net/forums/d32...equel-choisir/

[Florian Goo]

Java en premier, il n'en est pas question.

Ah, pour ça au moins on est d'accord ^^.
D'ailleurs Bjarne Stroustrup (encore lui) a déjà été sollicité à ce sujet : http://www2.research.att.com/~bs/bs_faq.html#merge

Mais bon, l'index Tiobe souffre tout de même d'(au moins) un gros biais : c'est l'enseignement.
Le C et le Java sont très utilisés dans les écoles pour l'enseignement, ce qui génère beaucoup de recherches et biaise l'index.

[ruste]

Mais pour autant, est-il vraiment important de pouvoir compiler du code C en C++ ? Est-ce vraiment une bonne chose de coder en C++ comme l'on code en C ? Est-ce intéressant de rajouter les nouveautés C en C++ ?

Compiler du code C en C++, pourquoi pas? On peut bien compiler de l'Assembleur en C++? La proximité du C et du C++ rend cette fonctionnalité possible. Au codeur de voir à ne pas se pendre avec la corde qui lui est donnée. Viva la libertad! Je crois que ceux qui veulent plus de rigueur devraient regarder du côté d'ADA. Mais ce n'est probablement pas sans raison si ce langage a périclité.

Comme tu l'as dis précédement, il est très simple de lier dans un même programme des fichiers objet générés depuis du C et des fichiers générés depuis du C++ ou d'appeler des bibliothéques C en C++. N'est-ce pas suffisant ?

Peut-être, mais vous avez toujours la possibilité de migrer facilement du code en préservant cette aptitude. Je comprends votre malaise, vous craignez le florissement de programmeurs "C/C++". Mais admettez que de préserver cette capacité facilite le fait de programmer des compilateurs qui supportent le C et le C++. Ça nous donne une certaine garanti que ces langages resteront intégrés. Qui ne risque rien n'a rien.

J'ignore si vous connaissez Java, mais pour intégrer le code C avec le Java, on doit utiliser un truc-machin nommé JNI. Selon certains tutoriels Java, JNI est «facile» à utiliser. Mais ceux qui disent ça n'ont jamais essayé de faire la même chose avec du C++, avec lequel c'est un jeu d'enfant. Personnellement, je trouve que l'intégration du Java avec le C est loin d'être naturelle. Je la trouve même plutôt encombrante.

Je l'ai déjà dit (et je ne suis pas le seul), il faut arrêter de faire le lien C++ == OO. C'est très réducteur, le C++ apporte bien d'autres choses tout aussi intéressantes (voire plus). L'OO n'est qu'une des facettes du C++.

Oui désolé. Quand je dis "OO", je suis un peu paresseux. Mais je m'accorde avec vous que le C++ a ajouté des concepts de programmation plus évolués. N'oublions pas que le C est un langage de seconde génération, ce qui fait à la fois sa force (proximité de l'Assembleur) et sa faiblesse. Sans ça le C ne serait pas du C.

[ruste]

[...]
Non.

Dans ce message (le source n'est pas recopié), vous affirmiez que le code C que j'avais édité en ligne ne compilerai pas en C aussi bien en C qu'en C++. Et bien ce n'est pas trop mal, car le code C++ a compilé du premier coup en C++, le code C a compilé du premier coup en C. Dans le programme C, j'ai changé le "this" pour "c_this" pour éviter la confusion avec le mot clé de C++ (je l'avais utilisé pour illustrer le rôle tenu par le pointeur que j'aurais normalement nommé po) et j'ai dû ajouter un cast dans la fonction main, et le code a très bien compilé en C++, et tout aussi bien en C ensuite:

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
27
28
29
#include <stdio.h>
#include <stdlib.h>

struct o {
  int o_x;
};

inline int get_x(struct o* c_this)
{
  return c_this->o_x;
}

inline void set_x(struct o* c_this, int x)
{
  c_this->o_x = x;
}

main()
{
  struct o* po1 = (struct o*)malloc(sizeof(struct o));

  set_x(po1, 10);
  printf("x=%d\n", get_x(po1));

  free(po1);

  return 0;
}

Le C++ est plus exigeant sur certains points, mais la conversion pour que ce code puisse compiler en C++ a été minime. Ce n'est pas suffisant à mon avis pour dire que le C++ n'est pas du C. Si 2% d'incompatibilité en font un autre langage, alors que dire des diverses versions de compilateurs C/C++ certifiés ISO C et ISO C++ qui ne sont pas compatibles entre eux?

[gl]

Compiler du code C en C++, pourquoi pas? On peut bien compiler de l'Assembleur en C++?

Mais ce point n'est pas, à ma connaissance, normalisé mais une extension des compilateurs.

Mais surtout, les passages où on est en assembleur et non en C++ sont clairement identifiés.
On est clairement dans un mode "on embarque un bout d'assembleur dans un programme" et pas dans un mode "l'assembleur est du C++ valide".

Au passage, personnellement je n'ai jamais eu le besoin de faire ce genre de manipulation. Par contre j'ai eu à lier des fichiers objet provenant d'un code assembleur à des fichiers objet venant de C ou de C++.

Peut-être, mais vous avez toujours la possibilité de migrer facilement du code en préservant cette aptitude. Je comprends votre malaise, vous craignez le florissement des programmeurs "C/C++".

Déjà, pourquoi vouloir absolument migrer ces codes C en C++ si ce n'est pour ne pas utiliser le C++ ? Pourquoi ne pas les laisser en C ?

Pour poser un peu la situation (et faire comprendre mon point de vue), j'utilise ou j'ai eu a utiliser, pour différentes raisons, du C (aussi bien C89 que C99 voire C K&R), du C++, des déclinaisons évoluées ou au contraire restreindre de ces langages (gnuC par exemple, C++ sans exception ou sans STL, etc.) et même avec des mélanges des deux (du C with class, ou du C avec deux-trois sucres syntaxiques C++).
Cela ne me pose pas plus de problème que ça, par contre je reste bien conscient de ce que je suis en train de faire et je ne mélange pas ces différentes situations qui sont toutes particulières.

Ce qui me gène vraiment n'est pas d'avoir à mixer les deux dans un cas précis [1] (bref de faire du "C/C++") mais de faire un amalgame systématique entre les deux langages (et donc de parler de langage C/C++).




[1] Enfin ça ne me gène pas, c'est quand même un peu plus compliqué que ça. Ça dépend de la raison qui mène à ce choix.

[ruste]

Ce qui me gène vraiment n'est pas d'avoir à mixer les deux dans un cas précis [1] (bref de faire du "C/C++") mais de faire un amalgame systématique entre les deux langages (et donc de parler de langage C/C++).

Au fond, nous ne sommes pas si en désaccord, sinon sur le fait que vous préférez ne pas laisser trop de corde aux mauvais codeurs ou aux néophytes, alors que je préfère plutôt m'en remettre à des règles de bonne pratiques.

Que faudrait-il retirer du C++ pour menotter les mauvais codeurs? Je préfèrerais plutôt m'assurer que les codeurs soient plus familier avec les normes et les bonnes pratiques du C++ et des langages modernes que de risquer de diminuer le couplage obligé entre le C et le C++ (c'est le même compilateur, souvenons-nous). La souplesse et la compatibilité a toujours caractérisé le monde du langage C, ce qui peut être un ingrédient critique de son succès.

Plutôt que de restreindre le langage, j'aimerais plutôt que le monde du C++ s'adapte et oeuvre pour moins dépendre de la prolifération de outils et normes originaires du Java ou autres, et «traduits» rapidement pour le C++, genre xerces-C++ ou log4cpp.

Un exemple parmi beaucoup d'autres, qui peut sembler minime mais qui me paraît important: la syntaxe. Ceci est un bout de code extrait de la documentation log4cpp:

Code :

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

1
2
3
4
5
log4cpp::Category main_cat = 
        log4cpp::Category::getInstance("main_cat");
        main_cat.setAdditivity(false);
	main_cat.setAppender(app);

Ce code log4cpp est un mauvais mélange de syntaxe Java et C++. Comment les nouveaux codeurs C++ peuvent-ils s'y retrouver, eux qui peuvent apprendre en partie par imitation? À mes débuts, j'ai moi même passé beaucoup de temps à me gratter la tête en me demandant quelle style était préférable. Le C++ utilise tantôt la syntaxe STL, tantôt la syntaxe X Window, tantôt la syntaxe des librairies C++ de Windows et tantôt, bien sûr, la $??$%?$%&?%&$% de syntaxe Java. J'ai fini par me dire qu'il était préférable de préserver une continuité relative dans la syntaxe du C++, qui après tout provient du C (je parle ici de syntaxe et non de fonctionnalités du langage), ce que fait bien le STL.

J'ai toujours trouvé que cette prolifération de styles a contribué à diminuer la facilité à comprendre et assimiler le C++. Le Java ne souffre pas de ce syndrome, pas autant du moins, car les bonnes pratiques Java sont si insistantes que c'est quasi gênant de s'en détourner. C'est un bon point pour Java et il faut le reconnaître.

Alors, quel serait le remède pour respecter un style C++ plus uniforme? Obliger l'utilisation d'une syntaxe stricte et interdire les combinaisons de majuscules/minuscules, ou insérer dans le monde du C++ des règles de bonnes pratiques et des exemples «certifiés» en abondance (STL en est un)? Nous ne seront jamais prémunis contre les mauvais programmeurs, mais à mon avis, nous risquerions certainement de nuire aux bons par le manque de souplesse et de compatibilité. Faites un langage pour les mauvais codeurs (impossible de contourner les règles), et vous obtiendrez une armée de mauvais codeurs enchaînés. On ira pas loin avec ça.

Donc, il me semble que nous ne sommes pas en désaccord sur le fond, juste sur où placer des limites du langage. Le C++ pour moi devrait être du C écrit selon les bonnes pratiques du C++. Mais c'est encore (plus ou moins) du C (++), comme X Window est toujours du C.

Désolé pour mon entêtement

[Bestel74]

Moi qui ne développe qu'en C (sur micro-contrôleur ) et qui "cherche" un langage durable, pourquoi pas le D ? Ce n'est pas censé être l'amélioration ultime du C/C++ ?

Compatible C et assembleur, pourquoi ce n'est pas ZE langage ?

[Camille_B]

Il y a quand même un sérieux problème avec ce classement :

Javascript derrière Objective-C ou Delphi, hum hum...

S'il y a bien un langage avec le C qui est incontournable, c'est lui.

[hegros]

Moi qui ne développe qu'en C (sur micro-contrôleur ) et qui "cherche" un langage durable, pourquoi pas le D ?

Parce que tu trouves que plus de 20 ans ce n'est pas durable pour le C

[Bestel74]

non non c'est pas ça

Juste que le C ne fait pas ce que le C++ fait, de même pour le C#, et comme le D "remplace" ces trois derniers, pourquoi n'est-il pas reconnu ?

[Florian Goo]

Bestel, tu devrais lire ce topic où j'avais soulevé les mêmes interrogations que toi : http://www.developpez.net/forums/d78...ute/langage-d/

[Bestel74]

Bestel, tu devrais lire ce topic où j'avais soulevé les mêmes interrogations que toi : http://www.developpez.net/forums/d78...ute/langage-d/

Yep merci !

Du coup je vais continuer a m'amuser avec du C en attendant ^^
(j'en suis au moment au j'en chie pour lire un vieux port série moisie )