Discussion :

[neo.51]

Pour ce qui est de se reposer sur la puissance des processeurs actuels je pense que c'est une solution de facilitée enployée par les mauvais développeurs...

C'est là que je ne suis pas tout à fait d'accord avec toi, je m'explique :

Si le/les clients ont besoin d'un developpement spécifique et ont un parc de machinnes relativement récent (disons de 800-900Mhz).

Je suis tout à fait d'accord avec toi pour dire que les langages c/c++ produira surement des applications plus rapides que du .NET, java, etc..
Le débat Java/C++ en parle parfaitement.

Mais ce qui me gène le plus dans le C++ ça reste quand même le temps de développement !!! Qui influe irrémédiablement sur le prix du logiciel final !!!

Donc quand le parc informatique du client permet d'utiliser de nouvelles technologies qui permettent d'accroitre sa productivitée et faire baisser les couts du produit final pourquoi s'en priver ?

[mat.M]

De neo51 :

Mais ce qui me gène le plus dans le C++ ça reste quand même le temps de développement !!! Qui influe irrémédiablement sur le prix du logiciel final !!!

Donc quand le parc informatique du client permet d'utiliser de nouvelles technologies qui permettent d'accroitre sa productivitée et faire baisser les couts du produit final pourquoi s'en priver ?

Alors moi je dis pas d'accord !
Pourquoi le temps de développement en C++ serait-il plus long ??
Sûr que faire strcpy c'est un peu laborieux...
Au début oui cela demande effectivement plus de temps que de développer en C# ou Java ou autre.
Mais une fois qu'on a développé des librairies , qu'on a structuré ses projets pas évident que cela soit plus laborieux de développer en C++.

J'utilise VC++ et MFC ( ça y est je sens encore les critiques pleuvoir ) et lorsqu'on maîtrise cet outil on développe aussi rapidement qu'avec VB ou autre.
C'est pareil avec C++ Builder ou autre .
Lorsqu'on a fait ses librairies , du code réutilisable , le développement est plus ou moins rapide.
Question d'organisation 8) .
Et puis Java ou autre c'est bien mais il arrive à un moment où on se retrouve inévitablement bloqué techniquement car C++ permet d'utiliser toutes les ressources de la machine bref d'aller aux limites de la machine.
Et c'est le problème aussi des outils RAD : c'est conçu pour développer rapidement mais qui dit rapidité dit mauvaise qualité probable.
On ne développe pas un logiciel comme on fabrique des étagéres.
Et là je demeure très perplexe au sujet des outils de développement qui permette de développer rapidement.
Qui me dit qu'en Java ou C# on puisse faire tout ce que l'on veut ??

Je ne veux pas lancer un éniéme débat sur VB mais c'était l'outil RAD par excellence permettant une prise en main aisée.
Donc pour faire des applis développées rapidement pas de problèmes ; mais souvent des applis "jetables".
Et avec ce genre d'outil pour faire des applis très pointues on se retrouve terchniquement bloqué

[neo.51]

Sans parler de vb6, les librairies dont tu parles, le code réutilisable, c'est fesable en java et .NET, le truc c'est que beaucoup de classes "de base" sont déjà faite. Tu me dis que tu vas aussi vite "une fois qu'on a développé des librairies".

Hors de mon point de vue (qui n'engage que moi) le developpement et l'analyse de ces librairies prend quand même un certain temps. Si tu te bases sur un framework : java, .NET c'est toujours ça de gagné en temps. D'ailleur Borland l'a bien compris en rapprochant wxwindows de C++ builder X tout comme la VCL et C++ builder 6.

Mais la VCL semble avoir un avenir plutot flou, microsoft ne semble pas séduire avec son VC++.NET car faire du C++ managé par le framework.net, autant faire du C#...

Donc l'avenir du C++ dans les RAD repose un peu sur les épaules de C++ builder X

Je sais qu'il existe beaucoup d'autres libs et outils pour le C++, mais en ce moment j'ai plutot l'impression que le c++ est en déclin. Il restera surement trés utilisé en informatique industrielle par exemple, ou dans d'autres types de développement ou les performances sont trés importantes (temps réèl). Mais le C++ devient de moins en moins attirant par rapport à des plateformes comme java/.net qui sont aussi accés sur des technologies web et qui proposent des frameworks trés complets.

[HRS]

Lorsqu'on a fait ses librairies , du code réutilisable , le développement
est plus ou moins rapide.
Question d'organisation

la réutilisabilité est le secret de la réussite. pas besoin de POO pour cela.

Et c'est le problème aussi des outils RAD : c'est conçu pour développer
rapidement mais qui dit rapidité dit mauvaise qualité probable.

non. mais un outil facile à utiliser est facile à être mal utilisé. l'exemple
le plus flagrant est le téléphone portable. on fait vraiment n'importe quoi
avec.

Et là je demeure très perplexe au sujet des outils de développement qui
permette de développer rapidement.

Ce qu'oublie de dire la publicité, c'est qu'il faut maîtriser le produit
pour que la rapidité de développement soit au rendez-vous. Cette maîtrise
n'est jamais immédiate et elle sera impossible si on est tout le temps en
train de changer de produit

pour répondre à néo.51. les plateformes Java ou .NET sont forcemment des
solutions d'entreprises, qui doivent en plus être dotées d'une organisation
impeccable

des directions incompétentes croient pouvoir remplacer une organisation
bordélique par un outil miracle. Hélas l'outil sera dans ce cas, non pas
une solution mais un bordel de plus. et plus l'outil est sophistiqué et
plus le bordel sera grand. et au bout du compte, l'échec assuré.

[yahia]

comme disait je ne sait plus qui .....tout est relatif
pour des appli grands publics je crois que java prendera encore du terrain sur c/c++ mais........pour les grosses applications et des appli en temps reel la C/C++ sont imbatables et pour longtemps.
C/C++ sont le langage de programmation systeme (meme si on utilise ASM lors de la programmation des diffs controleurs). cet question et assez reccurentes depuis la venue de .NET de chez Billou. mais il faut savoir une chose je paris mon pain que .NET est faites en Visual C++
bon courage

[stephane eyskens]

moi je pense que de toute façon, on va vers des solutions de plus en plus complètes et compactes(et peut être beaucoup moins performantes). Dans un avenir probablement proche, la profession de "développeur" sera reléguée aux oubliettes sauf pour les développements très pointus nécessitant encore de mettre la main à la pâte.

L'éventuel manque de performance induit par ces solutions toutes faites sera bien évidement compensé par le hardware dont les performances ne cessent d'augmenter.

Dernier point: je pense qu'il est ridicule de toujours vouloir tout comparer, en effet, on ne compare pas des carottes et des chaussures, si?

[TitiFr]

Salut,

Je sais pas si c'est pareil que vous mais j'ai de plus en plus l'impression que la différence entre le programmeur et de développeur grandit de jour en jour... il y a d'un coté les programeurs qui sont capables de fournir des bibliothèques, des apis... avec du code très performant et de l'autre coté il y a les développeurs qui ne font que regrouper des briques préfaites pour faire un logiciel complet...

C'est un peu la différence entre un menuisier et un particulier qui monte une étagère qu'il a achetée chez Ikea....

alors pour moi l'avenir du C++ n'est pas menacer mais il restera un language réservé aux programmeurs....

[gc243]

C et C++ sont proches du système, ce langage est principalement dédié au développement des couches basses du système : drivers, éléments de configuration système et tout programme demandant des performances (en terme de temps de réponses) importantes.
Dans ce cadre là, le langage C ne me semble pas menacé, car, hormis l'assembleur je ne vois pas d'autre langage aussi efficace dans ce domaine.

Evidement, on peut développer une application de gestion en C ou en C++. Là effectivement les temps de développement risque d'être bien plus important que s'il on utilisait un autre langage plus appropriés du genre Delphi à l'extrème on peut aussi utiliser un ERP.

GC243

[laffreuxthomas]

alors pour moi l'avenir du C++ n'est pas menacé mais il restera un language réservé aux programmeurs....

Bah si justement, c'est ça la menace. On ne va pas passer 20 autres années à réinventer la poudre à chaque projet.

C et C++ se retrouvent de plus en plus cantonnés à du système, ce qui est plutôt marginal dans l'ensemble du développement logiciel tu en conviendras.

[TitiFr]

Salut,

C'est vrai que les apis que l'on trouve actuellement sont de plus en plus completes, efficaces et pratiques mais il reste encore beaucoup de travail... et celui qui dit que sont api est parfaite est un menteur...

C'est vrai que que le domaine privilégié de C/C++ est la programmation système... mais pas seulement... partout ou le temps est une contrainte forte il est présent... et contrairement à ce qu'on pense ce n'est pas marginal... Faites le tour des annonces d'enploi, il y a un bon nombre de projet temps réél. De plus la communauté scientifique est très gourmande en calcul et les soft utilisés sont parmis les plus performants...

Hors sujet !!!

C'est mon point de vue perso mais je pense que développer un soft qui est un simple assemblage de briques préfaites pour une entreprise quelconque n'a rien de gratifiant alors que développer un projet dans lequel on a mis toute sont ingéniosité et qui sera utilisé par la communauté scientifique est vraiement une satisfaction...

@+

[matrix788]

lut tt le monde,

C'est mon point de vue perso mais je pense que développer un soft qui est un simple assemblage de briques préfaites pour une entreprise quelconque n'a rien de gratifiant alors que développer un projet dans lequel on a mis toute sont ingéniosité et qui sera utilisé par la communauté scientifique est vraiement une satisfaction...

là je te rejoins presque sur ce pt de vue Titifr; en effet, il m'est tjs plaisant de voir un travail ds lequel on y a mis tout son coeur, et auquel on a sué pour avoir quelquechose de bon qui en découle, mais il peut aussi servir d'avoir des "briques" : elles permettent d'eviter de reconstruire de nvlles bouteilles(perte de temps) à chaque nouveau besoin de lait, surtout lorsque la forme de la bouteille importe peu; je préfére encore travailler le lait, plutot que le design du recipient ...

ps : désolé pour la métaphore, mais je peux pas m'en empecher ...

tcho ..

[TitiFr]

Salut,

désolé pour la métaphore, mais je peux pas m'en empecher ...

T'as pas à t'excuser de faire des métaphores... ça illustre le propos et en plus elle est super...

J'ai peut être été trop catégorique dans mon propos précédent... Je n'exclus pas la réutilisation de briques préfaites mais je trouve ça peu intéressant et très restrictif de faire un soft entièrement à partir de choses préfaites... Cela peut réduire la marge de manoeuvre si on ne trouve pas le composant exactement aproprié à la situation...

Mais en aucun je prone de réinventer le fil à couper le beurre... Ce serait une perte de temps... C'est parceque les libs sont nombreuses variées et performantes que le c/c++ à encore de très beaux jours devant lui. Mais encore plus car ses utilisateurs sont en générals très doués...

@+

[HRS]

attention, un logiciel n'est pas une oeuvre d'art

Utiliser des composants que d'autres ont crées, c'est moins gratifiant
mais plus efficace. c'est la différence entre l'artisanat et l'industrie.

C'est dommage que certains se sentent obliger de réécrire, pour des raisons
purement esthétiques, des composants existants qui fonctionnellement
répondent parfaitement aux besoins

Cependant un développeur (que TitiFr oppose à tort à programmeur) doit
être capable de créer lui-même un composant (fonction ou classe) que
d'autres pourront réutiliser

[TitiFr]

Salut,

Cependant un développeur (que TitiFr oppose à tort à programmeur)

Je vois que je me suis encore mal fait comprendre... c'est un peu ma scpécialité...

Je pensais pas une réelle opposition puisque rien empêche quelqu'un d'être tour à tour développeur puis programmeur... Je sépare juste les activités et pas les personnes...

C'est dommage que certains se sentent obliger de réécrire, pour des raisons
purement esthétiques, des composants existants qui fonctionnellement
répondent parfaitement aux besoins

C'est ce que je disais dans mon message précédent... mais il faut savoir ou s'arrêter et ne pas avoir peur de programmer ses propres composants si il n'en existe pas ou si ce qui existe est vraimement trop général...

Je vois que je me suis fait des ennemis dans les développeurs.... mais c'est juste un quiproco...

Je suis pour le juste milieu et les performances...

@+

[buzzz]

bonjour, j'ai toujours trouvé ce genre de debat amusant
d'abord on vous annonce : vaut-il mieux java ou c++
et ensuite vous entendez au boulot : si tu sais faire du C++ tu sais faire du java (et inversement)...
faudrait savoir

pour moi cette discussion entre les langages et fatiguantes. Ya 15 ans je ne jurais que par le gwbasic, qui par rapport au C de l'epoque etait une vrai perle. aujourd'hui je me drogue au c++ et la pluspart du temps il m'enerve. Heureusement l'interfance borland soulage mes nerfs contrairement a celle de vc6. Souvent j'au reve d'un meilleur c++ et j'ai pensé viré a java. J'en avais marre d'un langage avec des librairies aussi pauvres. la stl m'enerve et est a mon gout peu pratique pour ce qu'elle fait au final. Il y a tellement de structure de données pourquoi se casser le cul avec cette stl qui vous offre 36 versions de 3 structures de bases. Ah oui pcq chacune est optimisée suivant l'utilité... alors on n'a le choix, soit on prend java avec plein de classe a telecharger mais bon cote perf adieu, soit on prend c++ tres efficace mais avec 50 compilations de la meme classe suivant l'appli.

c'est triste, finalement des raisons pratiques gouvernent plus notre choix

il est aussi possible de compiler la partie a optimiser en C et faire le reste dans un autre langage, mais plus personne ne parle de ce genre de manip ???

je reve d'un langage facile a utiliser avec des bibliotheques variees (et non clonees sous plusieurs versions) et efficaces...

[xboxut]

je pense que le c/c++ a encor de belles annees devant lui.
ok les langages interpretes ou de haut niveau c bien c pas tres lourd c facil a comprendre mais cote performance c pas ca.pour exemple,half life 2d c un jump n run en 2D ecrit en flash il tourne sur un 1 ghz.avec un langage de bas niveau on pourai le pour P2 200~300 mhz.

tout le monde dit que le c/c++ est dur a comprendre et a utiliser mais maintenant avec les differeNtes librairie qui existe il devient de + en + facile de developper des app puissantes.

je connais pas trop le java,il est vachement portable ok mais le c est lui aussi portable.et on voit que les differentes app java sur les petites machines(portables) ne sont pas franchement fameuse vus la puissance de leur proc.

donc: c/c++ -->bien pour developper des appli qui demandent un max de puissance.
langages interpreter ou de o niveau--> bien pour le net,pour faire des app qui pompe pas trop;eventuellement pour aprendre a programmer.

[el muchacho]

J'aurais tendance a dire que C++ (avec C) sont de imbatables sur à peu prés tous les points: certes il ne sont pas toujours simple à utiliser et il est donc compréhensible que la plupart des débutant s'oriente de préférence vers de chose plus "simples" (Java, C#). Pourtant, en progréssant, les developpeurs sont tenté pour des raisons de performance de se diriger vers des languages plus puissant que sont C/C++ (voire ASM).

Non, pas pour la performance, mais pour la clarté, l'expressivité, la robustesse et l'extensibilité, qui sont des raisons tout aussi valables que la vitesse pure.
La programmation d'un "chatbot" en Français par exemple (un programme qui simule un interlocuteur humain, tel qu'on en trouve sur les IRC) s'écrit en quelques centaines de lignes de Lisp ou d'Ocaml et la grammaire s'étend facilement, alors que je n'ose pas imaginer la complexité d'un programme équivalent en C++ pour une grammaire comme celle du Français.

Pour bien des avantages (surtout au niveau de la puissance) C++ reste toujours plus avantageux que Java/C# dans certaines situations. On peut a titre d'éxemple (paradoxal, certes) citer le fait que malgrés le dénigrement de Visual C++ de la part de Microsoft, c'est toujours le language qu'utilisent leurs propres developpeurs!
Je crois que le seul risque pour C++ est de voir apparaitre des nouveaux conceptes de programation plus puissant que l'OO. Mais on en est pas encore là!

Des paradigmes de programmation de puissance comparable à l'OO existent depuis des décennies. Le fonctionnel en est un. Common Lisp, par exemple, implémente l'OO à l'aide de macros.

Objective Caml est fonctionnel, OO, et permet la programmation générique (les templates, la surcharge d'opérateurs) de façon plus simple que le C++, et son système de types est nettement plus puissant et plus robuste que celui de C++. Il n'y a aucun doute sur le fait que en tant que langage généraliste, Ocaml est plus puissant que C++.

[nicoo]

le C++ ne mourrera pas de si tot malgré qu'il devient tout doucement vieux. Il faut dire ce qui est ...

[el muchacho]

le C++ ne mourrera pas de si tot malgré qu'il devient tout doucement vieux. Il faut dire ce qui est ...

Non, c'est à peu près certains. Ce qui est dommage, c'est que finalement peu de gens savent l'utiliser correctement.

[Cyr1c]

Je pense que comme l'ASM, C++ est voué à vieillir mais pas à disparaitre.

Les langages de 1er niveau (ASM) sont toujours là, et ils sont necessaires pour l'écriture de code de bas niveau.

pour le C++ et le C, je pense que ca va être pareil, pour l'écriture d'OS et l'écriture de logiciels avec de grosses optimisations, c'est necessaire.

car C++ est plus près de la machine que java ou C#. Alors que les langages de haut niveau tels que java ou C# impliquent certains mécanismes lourd (au niveau de la gestion de la mémoire par exemple).

C++ sera surement utilisé pour des logiciels necessitant de tourner rapidement, car l'accès à la mémoire peut être directement faite dans le programme (pas de garbage collector) de même qu'il est possible de controler certains périphérique.

Par contre, C++ n'est pas très adapté pour des sites web ou des clients graphiques lourds (les MFC c'est pas toujours simple).

Bref, c'est simplement l'évolution de la technologie qui veut ca, avec les puissances actuelles, on peut permettre aux développeurs de se libérer de certaines contraintes (comme la gestion de la mémoire) de façon à limiter les bugs et aussi de leur permettre de se concentrer sur autre chose.

On aura toujours besoin de C++ car au meme titre que l'asm ou le C, il est un langage qui domine sur un certain niveau d'abstraction de la machine. Plus ca va, plus les langages s'écartent des contraintes matérielles, mais il faudra toujours des langages pour faire l'intermédiaire