Reprise du message précédent :
"Pour les pros"

En VB, on peut en effet faire quasi pareil :
 

 
Y'a une syntaxe qui permet d'empiler les statements, mais je me souvient plus... Un truc genre "exit while 2" ou un truc comme ça pour indiquer qu'on veut quitter le while de second niveau

Par contre, le but du jeu, c'est de faire compiler

je viens de regarder l'aide pour vérifier mais le statement Exit ne prend pas de paramètre hormis le type de structure (For, Do, Loop)
 
Par contre le Next peut être empilé pour fermer plusieurs boucles d'un seul coup

ha, ok. je croyais pourtant avoir vu ça un coup.
désolé.
 
enfin, de toute façon, il suffit de tester la condition de sortie dans l'endroit où on tombe après le premier exit, pis on peut en faire un second

vu le nombre de posts qu'il y a eu, g ptet bienfait de le deterrer... En fait je me suis planté à cette question je crois... J'ai eu "que" 22 au questionnaire...

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.
 

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

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)
 

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

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.
 

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

 
Y'aurait quelques années, j'aurais mis un [+]
 
A l'heure actuelle, face aux nouveaux langages, Ada comence à viellir. La voie qui se dégage le plus est le déclaratif.
 
'Toute façon, les kaïds de l'industrie ont toujours pas compris les aspects un peu haut niveau du C++ (qui est largement au raz des paquerettes) alors un langage où le degré d'abstraction s'élève vraiment ... D'ici 50 ans, pas avant.

On n'en est pas encore au déclaratif, loin s'en faut : regarde quel a été le dernier langage en vogue : Java. Désolé, mais l'industrie restera encore longtemps à utiliser des langages impératifs et typés (enfin, plus ou moins typés...).

Enfin bon ... de là à voir débarquer Java dans le domaine du temps-réel, je demande à voir

 
Tous les langages récents sont déclaratifs : hakell, curry, mercury par ex. et tous trois utilisent le système hindley-milner, la réécriture de graphe.
 
La dernière innovation en impératif est les contrats de Meyer (absorbés de plus en plus par des systèmes de types plus intelligents) et peut-être 2-3 "innovations" de C# (genre les attributs en écriture, généralisation de l'accès uniforme de Meyer).
 
Maintenant, que l'industrie continue à vendre de la merde, tant que les clients en achèterons, y'a pas de raison que ça s'arrête, faut pas oublier que si l'informatique évolue aussi lentement (à beaucoup de niveux), c'est pas que de la faute des vendeurs. C'est l'intégralité des acteurs qui majoritairement ne savent pas ce qui existe sur le marché et confinent les chercheurs à "des travaux théorique aux intérêts éloignés de l'industrie" (c'est sûr que le travail sur la qualité du code, la preuve, l'accélération des cycles de développement, ça les intéresse pas !).
 
D'autre part, le travail sur les langages est bridé par un goulet d'étranglement : les processeurs Intel, générer du code efficace sur une merde pareille (essentiellement le jeu d'instruction en fait) nécessite des années et du personnel, seuls les compilos C peuvent se le permettre. Donc pas de code efficace => pas d'application jacky (skins, customisaons diverses et inutiles) => pas dans l'industrie.
 
C'est pour ça que Self a été développé sur sparc, que les travaux sur C-- démarrent sur HP (je crois) etc. Le seul warrior qui a réussi à développer un compilo pour Intel est Xavier Leroy pour O'caml résultat, son langage est sorti de l'ombre.

Je dis peut-être une connerie, mais on m'a dit à un moment qu'ADA s'est assez peu développé surtout parcequ'il est très pauvre en librairies graphiques, et que c'est une chose qu'il gère extrêment mal.
 
Du coup, on ne peux pas l'utiliser pour des programmes avec interface utilisateur (ou presque) ce qui l'a rendu moins attrayant que le C, qui lui, est très riche dans ce domaine.
 
Sinon, les programmes ADA faisant du clacul utilisent généralement des librairies écrites en Fortran, et c'est ça qui le rendent extrêment compétitif par rapport au C.
 
En effet, les librairies de calcul Fortran sont extrêment poussée, et notamment font un nombre impressionnant d'optimisation en réécrivant les différentes expression mathématiques d'une façon plus rapide pour le PC, ce que ne fais pas le C.
 
Mais bon, je tiens tout ça d'un bon gros baratineur, je sais pas si tout est bon ou si tout est à jeter.

Malheureusement, j'ai déjà entendu cette légende à plusieurs reprises.
Pourtant, il est assez facile de comprendre que ce qu'Ada est capable de faire avec Fortran, il est capable de le faire avec C. Donc toutes les librairies graphiques disponibles pour les programmes C sont utilisables en Ada.
 
Et dans la pratique, de très nombreuses librairies standard, graphiques ou non graphiques, sont disponibles pour Ada, depuis très longtemps. Je citerai par exemple GtkAda, l'interface Ada pour Gnome, X11Ada, AdaCurses, Florist (interface POSIX pour Ada), une interface Win32 pour Ada, une interface Tcl/Tk pour Ada, etc.
Et la plupart de ces librairies, comme le compilateur, sont gratuits...

si je puis me permettre un ajout, ADA est tres fortement type, mais je pense que oCaml l'est tout autant.

Oui, mais Caml n'est pas classé parmi les langages impératifs.

 
Le problème c'est qu'il faut wrapper, ça peut être long et surtout, on manque de compilos, y'a que gnat quasiment, il repose sur une vielle version de gcc.
 
L'autre jour, j'ai cherché, le portage palmos n'existe pas. Je pense qu'il y a vraiment un manque.

Oui, il faut wrapper, mais si tu tapes dans les librairies usuelles (celles auxquelles pensait Buzz), le wrapping existe déjà, et tu n'as rien d'autre à faire que d'utiliser.
 
Sinnon, quel est le problème de version avec GCC ?   Les dernières versions offrent vraiment beaucoup plus de services côté back-end ?
 
Sinon, c'est normal qu'il n'y ait plus beaucoup de compilos. Les éditeurs ne vont pas dépenser des millions d'euros pour le développement d'un compilateur Ada s'il y en a un qui existe déjà, qui est gratuit et qui fonctionne bien...
Maintenant, qu'il manque des portages sur certaines plate-formes, je reconnais, mais ça doit être dans les choses faisables, non ? Et puis, je me répète, mais ce n'est pas cela qui a empêché (et qui continue à empêcher) Java d'être un succès...

Il s'agit de gnat. Par defaut il ne doit pas verifier les acces, mais ca doit etre dispo.
 

hum ... je vois pas en quoi il gererait mal.
Sous WIndows, il existe le GUI Builder d'Aonix (Object ADA).
Ca fonctionne a la Visual Basic.
J'ai failli faire uns tage dans une boite qui developpait principalement en ADA, mais qui justement utilisait VC++ pour l'interface, car "les composants sont plus riches".
 

 
AMHA, il y a aussi la syntaxe qui joue pas mal. Avec sa syntaxe, ADA se situe dans le lignée de PASCAL. PASCAL n'a pas trop la cote dans le monde du travail.
Un programmeur C qui passe à JAVA a le sentiment d'etre en terrain connu.Et JAVA c'est un peu different, vu qu'il est multi-plateforme, que sans rien changer on fait fonctionner son prog a peu pres partout, ca c'est un argument de poids.
Et maitriser ADA en 2 semaines, c'est un peu exagéré.

 
Euh ... Java est mono-plateforme. La preuve, c'est qu'on est obligé d'émuler cette plate-forme pour qu'un programme Java tourne (remarquez, c'est de moins en moins vrai avec gcj, mais bon, j'arrête, ca va virer au Troll   )
 
Moment "je chipotte" : on ecrit Ada, pas "ADA". Ce n'est pas un acronyme, c'est un prénom (et pareil pour "JAVA" )

Mouai ...
Je veux dire qu'il tourne a peu pres partout.

Bref, tu es en train de dire que ce ne sont pas les qualités intrinsèques du langage qui sont prises en compte, mais l'impression que sa syntaxe en donne. Alors que Java est bien plus près d'Ada que de C++ du point de vue de la philosophie du langage.
 
Sinon, pour la maîtrise de la syntaxe d'Ada pour les concepts de base, si tu sais déjà programmer, je persiste sur les 2 semaines. Mais bien sûr, tu vas ensuite passer plusieurs mois à te battre régulièrement avec le compilateur parce que tu écris pas ton code avec assez de rigueur.

 
Entièrement d'accord. Il faut juste compter un petit peu plus longtemps si tu veux en plus profiter de certaines fonctionnalités du langage qui font la force de Ada : tasking, types protégés, généricité, types contrôlés, Storage pools, ... j'en passe et des meilleurs  

 
Oui, Ada ne bénéficie pas par exemple de la forme SSA (single static assignment) telle que définie dans les gcc modernes (je ne sais pas s'ils ont fait un truc à leur sauce).
 
Pareil sur les amélirations des allocateurs de registres etc.
 
Quand au portage sur certaines plateformes (en fait c'est la palm qui m'intéresse, car le C m'insuporte) je suis incapable de le faire, il n'existe pas de threads sur palm, donc rien au niveau de la synchro etc. des modes "dégradés" du langage sont-ils prévus dans la norme ?

Ah, à mon avis, là on atteint la racine du problème : je ne crois pas que le type tâche soit optionnel en Ada. Normalement, tout ce qui est optionnel se trouve dans une des annexes de la norme, or les tâches n'y sont pas...
 
edit> Mais à vérifier.

Avec l'ADA, il faut faire gaffe a bien initialiser toutes les variables qu'on utilise, sinon il va afficher le contenu de la mémoire, et donc un peu n'importe quoi
 
Ca m'est arrivé pas mal de fois en TP, surtout avec les tableaux et les chaines de caracteres