| BifaceMcLeOD |
HelloWorld a écrit :
ben si ca t'en averti, c'est tant mieux.
Mais, dans la pratique, il me semble que ca ne verifie les acces qu'en debug et pas en release (arf sinon c'est trop lent).
|
On surestime beaucoup trop souvent le coût de ce genre de vérifications. Néanmoins, le compilateur dispose d'options permettant de déconnecter les vérifications de bornes.
Citation :
Aujourd'hui encore, le compilo a merdé : tableau de 1..10, acces à 0, le programme se bloque ...
Il me semble qu'un autre compilo sous Windows refusait de compiler un tableau commencant à 0. Mais bon ici sous Linux c'est bon.
Donc, faut se mefier quand meme ...
|
Tu parles de compilateur Ada, là ? :??: Ca m'étonnerait que ce soit le cas, ou alors c'est un compilateur pas standard. De toute façon, les compilateurs Ada subissent des validations extrêmement poussées pour pouvoir s'appeler "Ada", et un compilateur qui se planterait là serait immédiatement rejeté.
Citation :
Y'a un article qui a ete ecrit pour expliquer pourquoi l'ADA n'a pas tres bien marche. L'une des grandes idees est que "le monde n'etait pas pret pour un nouveau gros langage".
|
C'est faux, le boom de Java le prouve. Or rien n'interdit d'utiliser Ada comme on utilise Java aujourd'hui (d'ailleurs certains le font, en faisant générer du bytecode Java plutôt que du code natif à leur compilateur Ada)
Citation :
Y'a aussi les raisons economiques.
Quand une boite developpe depuis 10 ans en C, qu'elle a des millions de lignes qui fonctionnent.
Si elle souhaite enrichir ses sources, le choix entre :
"en ADA, faut tout recoder et apprendre un nouveau langage"
"en C++, ca recompile avec tres peu d'effort, votre connaissance du C n'est pas perdue"
ben c'est vite tranché ... et ca se comprend.
|
Là encore, c'est basé sur un raisonnement complètement faux.
1. Java en est le contre-exemple parfait : des tas de boites, pour les projets nouevaux, choisissent Java au lieu de garder C ou C++. Pourquoi ils ne l'ont pas fait avec Ada il y a 5, 10, 15 ans ? Et pourquoi ne le font-ils pas plus aujourd'hui ?
1. En Ada, tu peux réutiliser toutes les librairies C ou C++ sans problème (un peu comme avec JNI en Java).
2. Un jeune qui sort de l'école ne peut pas prétendre connaître C++ sur le bout des doigts. Il faut des années de pratique quotidienne pour maîtriser tous les aspects de ce langage. Langage qui requiert en plus la maîtrise d'outils extérieurs (genre make ou shell). Bref, maîtriser C++, c'est compliqué et c'est long.
Est-ce qu'apprendre Ada est plus compliqué ? L'expérience prouve que non. Mieux : l'expérience prouve que maîtriser Ada, malgré ses aspects les plus complexes (qui ne sont pas utiles pour la plupart des programmes, au demeurant), cela demande beaucoup moins de temps que pour maîtriser C++.
3. Qu'est-ce qui coûte le plus cher en logiciel ? Coder, ou maintenir le code ? Je ne comprends toujours pas que la plupart des gestionnaires n'aient toujours pas réalisé que c'était la 2ème réponse qui était la bonne, et de très loin : les temps de debug et les coûts de maintenance évolutive n'ont absolument rien à voir entre la plupart des programmes C et leurs équivalents Ada (et ce n'est clairement pas en faveur de C...). Pourquoi, on continue à dépenser sans compter en gardant C ou C++ (au passage, je signale que la plupart des programmeurs qui disent programmer en C++ programment en fait en C et compilent avec un compilateur C++).
Et puis entre nous, pour apprendre la syntaxe d'Ada en programmation classique (pas de multi-tâche ou de temps-réel, juste les types, les classes, les exceptions, les packages et au pire la généricité), ça ne va pas prendre des années ; en 2 semaines, pour quelqu'un qui sait déjà programmer, c'est bouclé...
Citation :
Du coup, bcp de boites ne sont pas 100% ADA, mais jonglent entre ADA et C++.
|
Oui, mais entre adopter Ada sur le long terme tout en gardant son existant C++, et rejeter Ada parce qu'on a un existant C++, il y a une différence. Pourtant la plupart des boites choisissent la 2ème option. Pire : ils ont choisi la 2è option peu après qu'Ada soit sorti, et ils continuent à la choisir, année après année.
Citation :
Là je suis assez sceptique. J'ai toujours entendu dire que les meilleurs compilos etaient ceux du C. Les compilos ADA doivent en effet etre performants, mais je suis pas sur que ce soit pour cela qu'on choisit l'ADA.
Il me semble que son succes dans le domaine du temps réel et surtout lié aux facilités de programmation multitache / synchronisation qu'il propose (task, rendez vous, ...)
|
Il y a des librairies C ou C++ qui offrent des services temps-réel. Mais dans ces domaines-là, les gens sont beaucoup sensibles à la notion de sécurité de programmation que dans les autres domaines où l'informatique est cruciale. Ce n'est donc pas l'efficacité qui est a priori le critère numéro un de sélection du langage de programmation.
Néanmoins, l'expérience a montré que les temps d'exécution des programmes Ada étaient comparables à celui des programmes C++ équivalents. Autrement, ce n'est pas parce le compilateur fait beaucoup plus de vérifications à la compilation (et qu'il génère un peu de code de vérification à l'exécution), que le programme est plus lent.
En fait, les compilateurs C sont le plus souvent les plus rapides parce que C est un assembleur de haut niveau. La traduction C -> assembleur est assez simple. Mais c'est comme dire qu'il vaut mieux programmer en asembleur plutôt qu'en C prace que le programme est plus rapide. La question est : qu'est-ce qui coûte le moins cher. Tant qu'on se focalisera sur l'efficacité supposée du programme et qu'on acceptera que les clients utilisent des programmes buggés, alors on continuera à utiliser C. Le jour où on voudra écrire un programme avec le coût global le plus faible (en comptant les coûts de maintenance), et avec la garantie de ne pas faire déraper le budget ou les délais, alors on jettera C et C++.
Mais vu comment la plupart des gestionnaires estiment le coût du logiciel, ce n'est pas demain la veille... |
