Quel est le langage le plus fortement type???
C
Pascal
ADA
JAva
 
D apres moi ce serait le pascal mais je ne suis pas sure vous!

Je dirais C

Sans hésitations, Ada
 
Tric : Dans le tas, C est le MOINS fortement typé.

[edtdd]--Message édité par kadreg--[/edtdd]

Ada

moi je dirais...que c po bien de chercher la réponse à des concours sur hfr    
 
tu sauras lequel est le + typé mais pas pourquoi. m'enfin bon...

c'est quoi encore le fait qu'un language soit fortement typée ? j'ai oublié

en C tu fais  
char c='a';
int i;
i=a+2;
 
ou float f=0.0;
   char tab[80];
 
tab[f]='a';
 
 
ca ne pause pas de pb , essia de le faire en java ( j'ai pas f'ait d'ADA)
un langage est fortement typée quand on ne peux pas ( ou difficilement ) passer d'un type a l'autre.

tu ferai pas le coucours pro login toi ??
 
ps : la réponse est ada

Oui je voudrais faire le concour prologin mais je ne suis pas sure d avoir le niveau!!
Alors je cherche les reponse enfin j en connais quelques unes mais je ne sais pas si j enverrais ma candidature car j ai appris pas mal de chose depuis que je cherche les reponse au QCM alors je ne pense pas que je suis assez cale pour y participer!!

eheh ca c'est une question qui ferait jubiler mon prof d'info (fan d'ada)
 
ouais le langage considéré comme le plus typé de ceux la est l'ada sans hesitations (cf fendan, le fameux prof )...
 
bone chance pour le concours...

 
ah tu sais tu risque rien a tenter ta chance.
 
une fois que tu a passé le stade du QCM, la seule compétence info necessaire c'est l'algo.
 
j'ai un pote qui est arrivé en finale l'an dernier.

Ok merci du conseille enfin j espere reussir qlq chose mais je cherhce des cours sur l algo et l analyse

introduction à l'algorithmique, edition dunod, isbn : 2100031287, 1000 pages de très bon niveau. Mon bouquin de chevet quand je veux me taper une bonne migraine. Ya tout dedans. note qu'il vaut dans les 50?

1an après...

 
Dans le cas d'ADA, ca veut dire :

j'avais même pas vu que c'était un topic déterré
 
NicolBolas > ça t'arrive de regarder la date du dernier post avant de poster?

 
C'est pire que ça :  
 

raaah ça fait rêver ce genre de trucs

ah oui je me disais que j'avais déjà vu ça quelque part

Un langage est fortement typé lorsque les types, même voisins (char et string, integer et long) sont rigoureusement incopatibles.
 
Un langage est très fortement typé lorsqu'en plus de l'impossibilité de passer d'un type à l'autre sans transtypage explicite, il est impossible d'utiliser les opérateurs classiques pour les types utilisateurs, sans avoir à les surcharger.
 
ADA est TRES fortement typé, car si tu crées un type "tNombreAVirgule" qui est simplement un alias du type double d'ADA, il te faudra surcharger tous les opérateurs (=, +, *, -, /, etc.)

 
1- c'est Ada
 
2- extrait du RM95 :  

En Pascal c'est un peu pareil (en moins fort quand même)

je sais pas si c'est vrai, mais si oui, ca suxe terriblement

C'est vrai, et au contraire, c'est absolument génial.
 
Un programme écrit en ADA peut, sans avoir besoin de faire un audit poussé du code, être certifié sans bug, car :
 
1) A aucun moment le compilateur ne prends la moindre décision.
2) Tu es à 100% maître de tout ce qu'il se basse dans ton code, d'un bout à l'autre, sans la moindre surprise.
3) Le compilateur va vérifier la cohérence de tout ce que tu écrit.
 
Notamment le coup des indices hors tableau. Si le compilateur trouve une ligne de ce genre, il va planter. En C++, il fa laisser passer, et soit planter quand tu vas appeler la fonction (dans le meilleur des cas) soit avoir un comportement totalement imprévu car il va commencer à lire dans des zones mémoires dont tu n'es pas maître.
 
Ada est le résultat d'un appel d'offre de l'armée américaine, et est encore aujourd'hui utilisé dans des applications qui nécessitent l'infaillibilité a plus totale.
 
En France par exemple, les calculateurs de la SNCF permettant d'étudier la courbure des voies sur les lignes TGV sont écrits en ADA, l'intégralité de l'informatique dans Ariane 5 est en ADA. C'est un des langages les plus robustes qui soient.

C'est à la fois vrai et faux. C'est vrai, mais le mécanisme d'héritage (plus exactement de dérivation) permet de se faciliter la vie.
 
Ainsi, on peut écrire un truc du genre :

Désormais, toutes les opérations précédemment définies sur Float le sont sur Longueur, mais affecter une valeur de type Longueur à une variable de type Float est interdite, car il s'agit de 2 types strictement différents.
 
Pour compléter ce que dit Buzz, Ada est conçu suivant le principe de la surprise minimum : on essaie de faire en sorte que le lecteur d'un programme Ada ne soit jamais surpris par le comportement du programme qu'il lit. C'est aussi cela qui le rend aussi sûr.
 
Par ailleurs, le langage est conçu de telle sorte que le compilateur puisse effectuer de très nombreuses optimisations globales sans être gêné par d'hypothétiques optimisations locales faites au niveau source par le programmeur. Ce qui fait que les programmes Ada sont souvent très efficaces, à tel point que c'est un langage de prédilection dans l'embarqué et le temps-réel.

Pour exemple, hier encore, un pote se retrouvait à utiliser un type utilisateur "damier", et un autre "case" (où damier était un array de case)
 
Sans faire plus gaffe que ça, il a intégralement écrit son programme en C en partant du principe que case était un entier.
 
Aucune erreur de compilation, le programme fonctionnait très bien.
 
Seulement, il faisait n'importe quoi.
 
Après investigation, on a découvert que case n'était pas un type entier, mais un struct.
 
Le compilateur a laissé passer ça, et le programme, au lieu de bosser avec le nombre de boules sur chaque case, utilisait leurs adresses mémoires... Et le plus fort, lors de l'affectation, pas d'erreur non plus. Après avoir eu quelques écrans bleus sous Windows et des comportements bizarres dans d'autres application, il a découvert sa connerie.
 
Avec Ada, ça n'aurait jamais compilé. A moins évidement que surcharger les différents opérateurs afin de faire les calculs directement avec le bon élement de la struc... Ce qui à ce moment devient absolument génial, car tu peux effectuer des calculs totalement divers entre différents types, selon la surcharge que tu as fait des opérateurs. Mais c'est déconseillé, car ça a vite fait de devenir le bordel...
 
Genre :
 
int + case = int + case.nbPions
 
et
 
case + int = case.forcePions + int
 
Evidement, si tu fais ça, après t'es dans la merde, le code est imbittable

PUTAIN, J'AVAIS ECRIT UNE SUPER REPONSE POUR MONTRER A MAGIC QU4IL RACONTE N4IMPORTE QUOI? QU4IL CONFOND PLUSIEURS CHOSES SANS TOUT COMPRENDRE ET CE CON DE MOZ A PLANTE

 
Il est écrit en C++ et pas en ADA

 
Oué, c'est GKLayout qui a pété

antp>    
 
Le pire, c'est que c'est vrai... Mais je désespère de voir le jour où les décideurs accepteront de choisir le langage de programmation de leurs développeurs en fonction des véritables qualités du langage et non en fonction de raisons politiques ou idéologiques...  

De koi ? OK, c un peu loin, mais quand même, je crois pas avoir dit beaucoup de conneries... Les termes sont pas forcément les bons, mais dans le fonctionnement de base, je crois pas être bien loin de la réalité, du moins c'est ce dont je me souviens... Faut dire que j'en ai fait 1 an à l'école il y a 4 ans et demi, ça commence à faire loin

Je me souvient noramment, pour le coup de la surcharge des oppérateurs qu'à l'IUT on utilisait le type "tEntier", qui était le type entier de base d'ADA, contraint sur l'intervalle [-1000..1000]
 
Hé bien pour le faire bosser avec une constante de type entier "normal", il fallait surcharger tous les oppérateurs utilisés, car sinon ça nous pétait à la gueule.
 
Idem si dans une ligne on écrivait, avec "t1" et "t2" de type tEntier :
 
t1 := 600;
t2 := 600;
t1 := t1 + t2;
 
Ca plantait parceque le compilateur avait détecté que t1 allait sortir de l'intervalle authorisé.
 
Idem pour les structs, je me souviens très bien avoir fait des oppérations sur des variables de type struct, sans expliciter les éléments sur lesquels portaient les calculs, simplement parcequ'on surchargait les types et qu'ils prenaient un élement précis, un peu comme une propriété par défaut dans un objet.

 
Si, toutes les lignes. Je refait le post ce soir.

Disons que l'esprit y est.
 
Bien sûr, tu peux toujours écrire un programme buggé en Ada qui pourtant compile, mais le principe du langage est de rendre le maximum d'erreurs détectables à la compilation. A tel point que parfois, le compilateur donne un warning disant "attention, à telle ligne, le code est syntaxiquement correct, mais l'exception XXXX risque fort d'être levée" (typiquement l'exception Constraint_Error). Et à tous les coups, ça marche : quand le compilateur fait ce genre de prédiction, elle se vérifie systématiquement.
 
Et bien sûr que le compilateur prend des décisions, mais simplement il refuse le code du programmeur lorsque ce code est ambigu (c'est dans ce sens-là que buzz parlait d'absence de décision du compilateur : ce dernier refuse de choisir à la place du programmeur). MAis ensuite, une fois que le code a été vérifié comme étant non ambigu, l'optimiseur du compilateur prendra de très nombreuses décisions pour améliorer l'efficacité du code généré.
 
Par ailleurs, tu peux aussi manipuler des pointeurs et des adresses en Ada, et donc tu peux faire des erreurs mémoire. Mais les concepteurs du langage ont volontairement rendu ces manipulations lourdes au niveau source, ce qui fait que le programmeur ne va utiliser ces mécanismes que lorsqu'il en a vraiment besoin. Et par là même réduire de lui-même le risque de bugs par manipulation d'adresses mémoire incorrecte.
 
Et bien sûr que tu ne contrôles pas tout. En particulier, la notion de multi-tâches et de temps-réel fait partie intégrante de la définition du langage. Or qui dit vrai multi-tâche, dit non reproductibilité a priori. Mais le langage est fait de telle sorte qu'il permettre d'exprimer ce que tu veux faire de la manière à la fois la plus simple possible et la plus sûre possible.
 
Enfin, je signale à ceux qui croient qu'Ada n'est pas efficace parce que, notamment, il vérifie la validité de chaque accès à un tableau, que les vérifications de ce type à l'exécution peuvent être débrancher de manière très très simple, par un simple pragma voire une directive de compilation. Même si bien sûr, c'est déconseillé. Le meilleur, en plus, c'est que si vous écrivez bien votre code, ces vérifications sont même supprimées automatiquement par le compilateur parce qu'elle sont carrément inutiles ! Exemple, si "tab" est un tableau :

Ici, l'accès au "i"-ème élément de "tab" n'est jamais vérifié, parce que par construction, "i" est toujours dans les bornes du tableau...

ADA est tout indique pour les gros projets car c'est un langage concu pour cela. (les paquetages ADA sont tres souvent cites comme reference en genie logiciel).
J'ai debute avec. J'avais alors un pietre opinion de lui. Avec le temps, je m'apperçoit que c'est pas si mal, et meme que c'est bien.
Pour un pro, un programme qui compile, c'est un programme qui marche.
 
 

 
 
je suppose que tu voulais dire

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

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".
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 chois 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.
Du coup, bcp de boites ne sont pas 100% ADA, mais jonglent entre ADA et C++.
Moi j'aime bien l'ADA car on peut faire des progs vraiment lisibles, et c'est le seul langage que je connaisse ou on peut vraiment se passer du goto.
Vous savez le cas classique des boucles imbriquees :

en C/C++, le goto peut ici se justifier :

 
en ADA, il suffit de nommer la boucle a quitter et de la quitter :

Il me semble que y'a un truc un peu comparable en VB (Exit For, ...) mais la c'est le must.
Son systeme de "in debut .. fin" est aussi tres agreable. (acces / initialisation de tableaux ...)
En revanche, je reconnais que des fois c'est lourd.
Et je trouve aussi que si le C++ est syntaxiquement moins interressant, il l'est en revanche d'avantage pour toutes ses libs de dispo.
 

 
Le 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, ...)

C'est marrant cette resurection de topic en même temps que celui là => http://forum.hardware.fr/forum2.ph [...] h=&subcat=
 

en ADA, si ca compile, ca marche !
 
c'est pas totu à fait vrai mais c'est pas loin !

"Pour les pros"