Le pub des programmeurs
- 1 927 réponses
- 117 participants
- 131 718 vues
- 130 followers
y a des programeurs sur AF si oui vous bossez sous quoi ?
batman14
cptn.io
Pov Gabou
En java, tu as jni qui permet de faire ca, mais c'est pas super commode a utiliser. En plus sympathique, tu as swig qui permet de sortir du java.
Si t'es debutant, c'est pas le plus facile non plus, quand meme, interfacer avec le C. Surtout que tu vas devoir avoir un systeme d'instanciation de ton plugin complexe (l'hote s'attend a voir un wrapper avec des fonctions C/C++, donc va falloir lancer une machine virtuelle, exposer ton plug in, etc....). Ca doit etre possible, mais loin d'etre facile.
Fondamentalement, c'est pas une bonne idee de faire des plugs en java, je pense, a cause du garbage collector. Je connais pas beaucoup java, mais je pense pas qu'il soit possible, au moins facilement, de lancer un thread avec un systeme d'allocation memoire compatible avec le "temps reel". Et java ne permet pas non plus un prototypage rapide, donc je suis pas sur que ca ait un grand interet pour les plugs ins; je suis pas un gros fan de java, faut dire, donc bon, je suis pas forcement objectif
Citation :
La taille des chunks varie constamment sur FL Studio...lors de l'augmentation de la polyphonie, qui doit entraîner une surcharge CPU à ce moment, les chunks sont plus petits...
Oui, c'est oblige d'avoir des tailles variables, donc de ce cote la, VST est pas en faute. Par contre, je suis d'accord sur le fait qu'ils pourraient avoir un exemple qui traite de ce probleme (taille variable en E/S-> taille constante pour l'algo interne).
Citation :
Ce que je trouve aussi dommage est l'ncompatibilité de VST avec d'autres environnements non Windows.
Ca, c'est inexact. Je crois que certains softs steinberg ont ete developpes sous IRIX a la base (entre autre nuendo ?), et ardour supporte VST. Ce qui est fondamentalement imconpatible, c'est la GUI, mais de toute facon, tu peux pas le faire de facon cross platform, ca (je parle du framework; si tu imposes un quelconque toolkit, ca marchera pas sous linux, parce que tu as gtk et qt, etc...)
Citation : A priori, c'est la même chose. J'utilise Juce comme crossplateforme, et je fais l'export pour tous ces formats à partir de cet overlay.
JUCE le fait pour toi, ou tu dois gerer ca toi meme ?
Le probleme de JUCE et de VST, c'est qu'en theorie, je crois pas que ce soit possible d'utiliser les deux en meme temps question license (a moins que tu developpes avec la version non GPL de JUCE).
Encore une fois, c'est vraiment chiant cette histoire de redistribution de VST.
batman14
batman14
Pov Gabou
batman14
cptn.io
cptn.io
batman14
Pov Gabou
Dr Pouet
Citation : Le seul langage que tu dois vraiment connaitre a mon avis, c'est le C, parce qu'il n'y a qusiment aucune chance que tu n'aies pas a en faire de temps en temps
Je pense que ça dépend quand même vachement des contextes. En plus si tu sais faire du C++ tu sais faire du C, il y a même des chances que tu pondes du meilleur C, et que les ajouts objets (type Gtk ou Qt) soient plus naturels.
Citation : objective-C
Là encore, ça dépend des contextes. Objective-C a l'air sympa, mais c'est orienté typage dynamique si je ne m'abuse. Quand tu travailles sur des gros logiciels et que tu recherches des outils qui te permettent d'éviter les bugs au maximum, il vaut mieux détecter les erreurs de type dès la compilation.
Qt est effectivement élégant, mais a aussi ses défauts. Autrefois il ajoutait au C++ de mots clés qui lui sont propres (pour ses signaux je crois), je ne sais pas si c'est encore le cas aujourd'hui, mais du coup on ne programme plus réellement en C++, et du coup les outils capables de manipuler du C++ ne marchent plus, par exemple les outils pour éviter les fuites mémoire (insure/purify), ceux pour mesurer la qualité du code (type Coverity), ceux pour optimiser (appelés profiler)...
Bref, pas de vérité absolue dans tout ça. Après on a chacun nos préférences personnelles. Pas mal de gens qui ont touché à pas mal de langages préfèrent encore l'ADA pour coder vite et bien (perso je n'ai jamais pratiqué). Ya aussi objective-CAML ou OCAML qui jouit d'une très bonne réputation.
Il y a de quoi apprendre en tous cas !
Pov Gabou
Citation :
Je pense que ça dépend quand même vachement des contextes. En plus si tu sais faire du C++ tu sais faire du C, il y a même des chances que tu pondes du meilleur C, et que les ajouts objets (type Gtk ou Qt) soient plus naturels.
A ce niveau la, le C ou le C++, ca change rien; je parlais du C comme langage systeme par excellence, avec parfois des melanges C et C++ (windows ou mac, par rapport a linux). Objet, pas objet, c'est assez pipo je trouve comme argument pour des langages qui sont tres pratiques, surtout pour le C++ qui est tout sauf elegant (suffit de regarder ce que disent djikstra, knuth, Meyer ou Kay). En plus, ca depend de la definition que tu as d'objet (par contre, aucune reference en milieu academique te dira que le C++ est un bon langage objet).
Citation :
Quand tu travailles sur des gros logiciels et que tu recherches des outils qui te permettent d'éviter les bugs au maximum, il vaut mieux détecter les erreurs de type dès la compilation.
Si tu travailles sur des gros logiciels (ceux dont tu parles tout du moins, si je comprends bien que tu sous entends des softs bien specifies et cie, softs d'entreprise), tu ne le fais pas en C++ en general de toute facon. Detecter des bugs a la compilation: le C++ est incapable de detecter les bugs d'allocation memoire, qui sont la premiere plaie du langage, ni les depassements de bornes; a eux deux, ca fait une sacre part des bugs en C++ ? java, c'est quoi ? Fondamentalement, c'est le C++ avec un GC, et une grosse librairie. La gestion a la main de la memoire, c'est debile dans la majorite des programmes, maintenant, tellement le cout est faible en general: Programmation web, qui est un gros truc maintenant depuis un moment, y a pas grand monde qui le fait en C++.
Entre nous, pour un projet logiciel, tu pense qu'entre un programme en C++ ou en java, lequel prendra plus de temps a programmer en general ? Sur lequel il y aura le plus de bugs ? Entre utiliser la STL et les containers java, il y en a un qui est plus facile que l'autre, quand meme. En Java, t'as pas a te prendre la tete sur les semantiques de tes objets, etc...
Il y a bien sur des exceptions: jeux (au moins le moteur 3d), programmation systeme, grosses interfaces graphiques, etc...
Quand je parlais de l'objective C, je voulais dire que perso, j'aimerais bien un langage entre le C et le C++: quand je programme en C avec des structures un peu complique, j'utilise toujours le principe utilise dans la librairie standart pour fopen/close; ie une structure opaque definie dans un fichier prive, que tu ne peux acceder qu'au travers de fonctions, comme FILE. Dans les fonctions, tu passes en premier argument un pointeur vers la structure; en C++, c'est fait par le compilateur au travers de this. J'aimerais bien un langage avec gestion automatique de this, plus garbage collector, plus eventuellement heritage simple et quelques autre trucs quand je fais du code destine a etre appele par des langages de plus haut niveau (python en general). Pas de template, pas de surcharge d'operateur, pas de differences merdiques virtual/non virtual, pas d'exception, pas de RTTI, etc...
Un truc comme C++ embedded (qui est utilise pour certaines parties/drivers de mac os X par exemple). Un langage *simple*, dont je comprends les messages d'erreurs, dont la compilation ne met pas 3 heures pour 4 fichiers, dont je n'ai pas besoin de lire un bouquin de 1300 pages pour voir tous les problemes possibles et inimaginables a chaque coin du langage. Comme le dit stroustrup lui meme "Within C++, there is a much smaller and cleaner language struggling to get out."
C++, pour moi, c'est un peu le windows du langage de programmation. T'as une justification pour chaque merde du systeme, mais ca en fait pas un bon systeme pour autant. Quand tu lis le blog the old new thing, qui explique tous les trucs de compatibilite dans windows, tu vois le boulot gargantuesque, et tu vois que Raymond Chen est un sacre programmeur; quand tu lis le bouquin de Stroustrup (je l'ai lu plusieurs fois, la e edition de plus 1000 pages), tu vois que le gars est clairement intelligent. Mais a la fin, ca fait vraiment un truc enorme, ingerable. Encore un peu de mauvais foi, mais tellement vrai: "Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said, "OK, we'll do them both". So the language is too baroque for my taste. " (Knuth).
Y a des niches pour lesquelles le C++ a encore du sens (grosses GUI par exemple; pour tout ce qui est softs de MAO, je le ferais en C pour la partie dsp et en C++ pour la plupart du reste avec un langage de script pour le scriptage), mais y en a pas beaucoup a mon avis.
Tiens, la, je lis un article pour gerer les graphs avec boost:
https://www.informit.com/articles/article.asp?p=673259&seqNum=5&rl=1
Serieux, c'est du delire integral a ce niveau la, et c'est revelateur de pas mal de code C++ que j'ai pu voir/utilise. Les template de template, c'est le pire truc du monde; utiliser du C++ pour ce type de problemes, c'est vraiment n'importe quoi. Ca revient a utiliser les template comme des mini compilateurs totalement non teste et non specifie.
Citation :
Autrefois il ajoutait au C++ de mots clés qui lui sont propres (pour ses signaux je crois), je ne sais pas si c'est encore le cas aujourd'hui, mais du coup on ne programme plus réellement en C++, et du coup les outils capables de manipuler du C++ ne marchent plus, par exemple les outils pour éviter les fuites mémoire (insure/purify), ceux pour mesurer la qualité du code (type Coverity), ceux pour optimiser (appelés profiler)...
C'est toujours le cas, les mots cles, mais je vois vraiment pas le probleme. C'est toujours du C++, puisque tout le code est compile par un compilateur C++. Le fait que insure ou purify ou les profiler ne marchent pas, j'ai jamais utilise les outils dont tu parles, mais j'ai deja utilise des profiler et des outils de gestion memoire sous linux avec qt sans aucun probleme (valgrind, dmalloc et gcov); j'ai plus l'impression que c'est une limitation des outils cites qu'un probleme de qt.
Ensuite, le *vrai* C++, je sais pas ce que ca veut dire, vu que c'est un des langages les moins portables au monde, et qu'aucun n'implemente le standart a 100 %. Suffit de regarder le C++ utilise par mozilla pour voir que ca limite pas mal d'utiliser seulement les parties portables de C++ (cas extreme et pas vraiment pertinent, je reconnais ma mauvaise foi
).Bien sur qt n'est pas parfait, mais ca rend le C++ utilisable a mon avis en donnant (y a d'autres trucs; on parlait de JUCE, que je n'ai jamais utilise mais qui visiblement a l'air pas mal, etc...) le multi threading, du reseau, de la gestion XML, la gestion de l'unicode.
Je suis en train de bosser sur une petite appli de visualisation pour python, une sorte de mini editeur audio. Ben c'est clair que le widget de base, il sera fait en C++.
Citation :
Bref, pas de vérité absolue dans tout ça.
Je pretends pas detenir une quelconque verite absolue, evidemment. Je peux comprendre que certaines personnes aiment utiliser le C++ (en fait, aimer, non). Mais en tout cas, faut pas se limiter au C ou au C++ si on veut apprendre a programmer dans la plupart des cas; faut voir d'autres langages (a moins qu'on soit vraiment un genie, j'en ai deja vu, mais c'est pas la majorite). Moi, j'aime bien python, mais il y a aussi lisp et derives, occaml, etc... Ada, au niveau expressivite, c'est comme le C/C++, donc ca changera pas ta maniere de penser un programme, je pense, en general.
Dr Pouet
Pov Gabou
jujupauty
Pov Gabou
batman14
Dr Pouet
Citation : > Par exemple les trucs largement interprétés (au lieu de compilé) ça ne les choque pas, pourtant c'est beaucoup plus sujets aux bugs.
Ca, j'y crois pas une seconde. Tu te bases sur quoi pour dire ca ? En plus, la difference compile, interprete, elle est super vague. Java, c'est interprete, compile ? IronPython (implementation de python en bytecode .net), c'est interprete ? La tendance de tous les langages a utiliser de la memoire automatiquement, a avoir des structures de haut niveau, bref, l'oppose du C++, c'est une tendance hyper lourde, je pense.
Effectivement, j'aurais du écrire à typage statique, ou plutôt à typage fort. Par exemple en C++ un pointeur sur un type T c'est pas un pointeur sur autre chose, et l'erreur sera détectée dès la compilation. En java, jusqu'à récemment (les génériques), une liste d'objets était une liste, indépendamment du type des objets manipulés. De ce point de vue les templates sont plus rigoureux.
Les langages genre Perl, Python, php qui ne sont quasiment pas typés (juste la distinction scalaire / liste), sont très propices aux erreurs. Les langages dont on peut changer le type des objet en cours d'exécution (ça doit être le cas pour Eiffel, objective-C et d'autres), sont aussi propices aux erreurs. Par contre Ocaml semble à la fois souple (peu de déclarations de types par le programmeur) tout en étant très rigoureux (analyse de type très poussée par le compilo).
Citation : Il y a compatibilite avec le C; des nouveaux projets en C++, je pense pas qu'il y en ait beaucoup aujourd'hui.
Ben yen a. Dans les gros trucs critiques que je croise, en gros c'est un peu plus de la moitié en java, le reste en C++.
Citation : Le calcul scientifique, t'as de moins en moins de gens a utiliser du Fortran
Chez ceux qui utilisent des machines dédiées (genre supercalculateur Fujitsu), il n'est pas courant que le compilo et la librairie de caclul soit optimisés dans d'autres langages que le Fortran. A la limite le C démarre mais représente qu'une petite part de marché. Faut voir que pour ces machines si tu utilises pas les outils optimisés, tu perds l'essentiel de la puissance, vu le prix (et les objectifs qui justifient l'achat de la bête), ce serait dommage.
Citation : Ben non, parce que la librairie standart est ecrite avec le C++ en tete, donc les templates et autres saloperies. Deja que c'est pas super fourni a la base...
Tu peux très bien utiliser la STL, sans définir toi même des templates acrobatiques. Je l'ai fait longtemps, alors me dis pas qu'on ne peut pas !
Citation : Je sais pas, donne moi un exemple concret ou ca t'as pose probleme, parce que perso, je vois pas.
Ben je te l'ai déjà donné. Tu prends un source de pseudo C++ (avec des mots clés genre Qt, ou Ilog Broker ou autre) et tu essaies de passer dessus un outil comme Insure ou Purify, et ben c'est cuit. Et si jamais tu as besoin d'une autre librairie qui elle aussi a enrichi le langage, généralement c'est indémerdable. C'est pour ça que le mieux est que personne le fasse.
Citation : J'ai jamais dit le contraire, j'ai presque l'impression que tu sous entends que parce que je pense que le C++ est presque jamais approprie, je pense qu'un autre langage peut tout faire...
Meuh non, faut pas s'emporter comme ça ! Je pense juste qu'il y a pas mal de cas où le C++ est le moins mauvais compromis. Il est évident que ce sont des situations où il y a pas mal de contraintes externes ; mais c'est souvent le cas dans de gros projets industriels.
Citation : Par exemple, pour mes projets lies a ma these, j'ai choisi python non parce que c'est le meilleur langage, mais parce que justement il y a un bon compromis performance - popularite - communaute vivate - expressivite.
Ben quand tu fais un truc qui ne vient pas se brancher dans des tas de choses existantes, qui n'est pas censé être maintenu pendant 15 ans par 6 dévelopeurs différents, c'est certainement un très bon choix. Pas de doute là-dessus.
Citation : Il faut etre capable d'apprendre de nouveaux langages, je pense que c'est fondamental une fois un langage bien maitrise; parce que chaque nouveau langage suffisament different t'apprend vraiment qqch de different.
Complètement d'accord avec toi. Et tu fais même des progrès avec ceux que tu connais déjà, ça te donne des idées à ré-utiliser (genre le toString de java à implémenter en C++)
Citation : > je ne ferais pas confiance à des universitaires pour choisir un langage de programmation.
Je trouve cette remarque vraiment typique de l'état d'esprit français qui scinde aussi nettement les mondes industriels et universitaires. A l'étranger la frontière entre les deux mondes est poreuse. On a moins cette espece de condescendance d'un millieu envers l'autre. Ca me navre de voir à quel point chacun s'ignore dans le meilleur des cas, ou se méprise dans le pire des cas.
C'était un peu de la provoc hein !
Moi aussi je regrette que les deux mondes soit aussi séparés. Je me trouve côté industriel actuellement, et j'ai essayé plusieurs fois de proposer des problématiques industrielles à des universitaires proches ; mais généralement c'est trop "terre à terre" pour les intéresser. Je trouve que c'est pourtant intéressant pour une université ou une grande école de bosser sur des projets du type ACE / TAO : c'est plus proche de l'info des industriels, ça oblige à travailler en groupe, à faire des compromis, des plannings, et ça contribue au renom de l'école.
Mais souvent (et j'espère que ça peut changer) on préfère en France des trucs plus théoriques, typiquement on a Bertrand Meyer face à Douglas Schmidt ou Richard Stallman.
Citation : c'est qu'on peut avoir des langages qui sont plus elegants que le C++
Là je suis d'accord.
Citation : qui sont *souvent* plus appropries, et que j'ai du mal a comprendre comment on peut *aimer* le C++.
Ben c'est le souvent qui dépend du contexte. Souvent tu vas avoir le choix entre C et C++. Ben personnellement je préfère largement le C++, étant bien entendu que je vais l'utiliser d'une manière très simple, en visant perpétuellement un code le plus humainement compréhensible. Et là je suis d'accord avec Stroustrup sur "C++ is a better C". ;)
Croisement avec batman14, je vois que nous sommes d'accord sur pas mal de points
Pov Gabou
Citation :
Je pense qu'il y a énormément de domaines où la gestion fine de la mémoire est importante.
Ok, t'as des exemples precis ? Parce que sur ce point, je suis en desaccord absolu. La performance de l'allocation a la main, c'est vrai dans certains cas, mais dans la majorite, un systeme automatique sera plus performant, j'en suis persuade, et ke le constate dans la plupart du code que j'utilise/developpe.
Pour la partie DSP des plug ins, la gestion memoire, il y en a pas, c'est simple, ou alors super bas niveau (en utilisant des pools; mais tu utilises pas de malloc classiques en tout cas)
Citation :
Effectivement, j'aurais du écrire à typage statique, ou plutôt à typage fort. Par exemple en C++ un pointeur sur un type T c'est pas un pointeur sur autre chose, et l'erreur sera détectée dès la compilation. En java, jusqu'à récemment (les génériques), une liste d'objets était une liste, indépendamment du type des objets manipulés. De ce point de vue les templates sont plus rigoureux.
Mais ton raisonnement ne tient que si tout le reste est inchange, ce qui est evidemment faux. T'auras plus d'erreurs ou d'exceptions en python qu'en C++, oui; mais de l'autre cote, ca a aussi contribue a la souplesse du langage. Avec python, t'auras pas de segmentation fault, t'as pas de dangling pointer, t'as pas de problemes de chaines de caracteres sans charactere de fin, etc... T'as la rapidite de protypage qui est une consequence directe du duck typing, et qui te permet de te focaliser sur l'api plutot que sur des details d'implementations, et ca a de sacres consequences sur le nombre de bugs. Donc t'as quand de sacres avantages qui vont avec.
J'ai une question vraiment sans arriere pensee: t'as deja programme en python ? Parce que sur le papier, tu rates la plupart des trucs. C'est vraiment lorsque j'ai converti un projet matlab -> python que j'ai eu ma premiere "revelation" quant a la puissance du truc. Tu peux refactoriser du code, de maniere vraiment differente du C/C++/java.
Pov Gabou
Dr Pouet
Pov Gabou
Citation :
Chez ceux qui utilisent des machines dédiées (genre supercalculateur Fujitsu), il n'est pas courant que le compilo et la librairie de caclul soit optimisés dans d'autres langages que le Fortran. A la limite le C démarre mais représente qu'une petite part de marché. Faut voir que pour ces machines si tu utilises pas les outils optimisés, tu perds l'essentiel de la puissance, vu le prix (et les objectifs qui justifient l'achat de la bête), ce serait dommage.
Supercalculateurs, je connais pas vraiment, donc je vais rien dire. Mais par contre, python est utilise pour de tres tres gros projets scientifiques (au Cern, pyroot est utilise sur des donnees qui se chiffrent en tera octets), et aussi comme glue pour sur de gros clusters (rien que google
). Evidemment, le core algebre lineaire, c'est BLAS/LAPACK. c'est du fortran ou du C a la limite; et la, le C++ n'a rien a apporter. Mais il y a la aussi, d'apres ce que j'observe, une tendance lourde vers un environnement ou de plus en plus de glue est faite dans un langage haut niveau.Et dans ces cas, de plus en plus courants, le C++ est une horreur, car impossible a appeler depuis d'autres langages (au moins sous linux, qui est la aussi de plus en plus utilise sur de gros clusters en calcul scientifique).
Pov Gabou
Citation :
J'imagine que ce moc traduit le Qt en C++ ? Le problème c'est si tu as un autre outil qui a la même démarche, à ce moment là il faudrait que tu ajoutes les mots clés de l'autre outil à ce qui sort de moc... T'imagines le bordel ?
Oui, c'est ca, pour moc. Clair que c'est pas super lisible; mais ton machine insure, c'est la mort avec n'importe quel truc non trivial a base de template. Genre la STL, ca doit etre pire que QT, parce qu'a debugger, laisse tomber. La, c'est carrement les messages du compilo que tu comprends pas (quand c'est pas le compilateur qui crashe; me souviens de VS 6 qui crashait plus que souvent avec les templates; et g++ m'a plante plusieurs fois. J'ai jamais vu gcc planter en mode C, meme dans des configurations farfelues genre compiler du code binaire pour solaris ultra sparc sur linux powerpc
).En fait, tu me donnes des arguments contre le C++ ?
batman14
Dr Pouet
Citation : Mais ton raisonnement ne tient que si tout le reste est inchange, ce qui est evidemment faux. T'auras plus d'erreurs ou d'exceptions en python qu'en C++, oui; mais de l'autre cote, ca a aussi contribue a la souplesse du langage. Avec python, t'auras pas de segmentation fault, t'as pas de dangling pointer, t'as pas de problemes de chaines de caracteres sans charactere de fin, etc... T'as la rapidite de protypage qui est une consequence directe du duck typing, et qui te permet de te focaliser sur l'api plutot que sur des details d'implementations, et ca a de sacres consequences sur le nombre de bugs. Donc t'as quand de sacres avantages qui vont avec.
Pour les char* et pbs de pointeurs, il faut effectivement prendre des mesures pour s'en sortir (à commencer par utiliser la librairie string des STL), mais ce serait un point pour Python.
Que signifie "duck typing" ?
Pour la rapidité de prototypage, ben dans les gros softs ce n'est pas recherché, au contraire. On essaie de faire des .h complets et élégants, et après on en bouge le moins possible.
Citation : J'ai une question vraiment sans arriere pensee: t'as deja programme en python ? Parce que sur le papier, tu rates la plupart des trucs.
Python j'ai juste regardé. Par contre j'ai pratiqué php et Perl qui ont pas mal de caractéristiques communes (même si Python est plus élégant). En Perl j'ai fait des générateurs de code C++
Mais sur des gros softs que tu maintiens pendant des années, un typage fort est vraiment un plus, quand même. Le côté lourdingue des .h devient plutôt un avantage. Mais là-dessus, le Pascal de Borland (qui n'a pourtant jamais du percer des des gros systèmes) avait beaucoup de qualité ; et avec une vitesse de compilation fabuleuse. Les belles technos sont-elles toutes vouées à la poubelle ?
Citation : pour la reutilisablite, y a une grosse difference entre le C et le C++ (c'est quasiment impossible d'appeler du C++ a partir d'autres langages directement dans la majorite des langages
On peut appeler du C++ à partir de C (déjà fait d'ailleurs !), donc on s'en sort. C'est sûr que le C est un meilleur candidat au mélange de langages.
Citation : sans parler du probleme que le standart C++ ne definit rien sur les conventions de linkage, ce qui est la encore vraiment une plaie
Complètement d'accord.
Citation : quand c'est pas le compilateur qui crashe; me souviens de VS 6 qui crashait plus que souvent avec les templates; et g++ m'a plante plusieurs fois.
Ha oui, il était très facile (et peut-être encore maintenant) de trouver quelques lignes de codes faisant planter g++ (xlc était un peu plus costaud, mais pas des masses, et non standard pour les templates). Ca t'encourage à faire du code simple !
Citation : En fait, tu me donnes des arguments contre le C++ ?
Ouais en fait on se place généralement pas dans le même contexte, mais je crois que quand on parle de la même chose on est d'accord ! En fait c'est juste que quand on a pas encore connu le cas de projets de plusieurs centaines de milliers de lignes (voire quelques millions), avec maintenance sur au moins 10 ans, avec des équipes qui tournent, des produits imposés (outils, librairies), des contraintes externes (brancher tel soft sur tel autre, l'un en C++ sur PC 32 bits little endian l'autre en ADA sur DEC 64bits big endian, et encore c'est un cas facile)... on imagine pas toutes ces difficultés !
Le mot compromis prend alors tout son sens ;)
- < Liste des sujets
- Charte