[gull] Php/MsSQL obsoletes?

[Daniel Cordey]

On Wednesday 28 September 2005 12:08, Leopoldo Ghielmetti wrote:

> Je ne dirais pas que C est fortement typé, il est typé mais pas
> fortement.

Je crois que nous divergeons au sujet de la notion de "type". C EST un langage type dans le sens ou aucun symbole ne peut etre utilise sans une definition ! De plus, toutes les fonctions sont aussi typee, meme si l'absence de declaration implique un 'int' par defaut. Par exemple, on ne peut ecrire :

int toto()
{
    return;
}

Le compilateur n'aime pas... 

> C permet des conversion tacites entre types, chose qui 
> affaiblit son typage.

Stop ! Toutes les conversion "autorisees" entre certains type sont explicitement definies par le standard ANSI. Il n'y a aucune zone d'ombre... De plus, lors de conversion implicite dans le passage de parametres dans des fonctions, ou lors d'assignation a un type "autorise" mais different, des limitations sont verifiees et notifiees si necessaire. C'est particulierement vrai pour les suites 'long -> int -> short' et 'double -> float'. Dans chacun de ces cas, il y a risque de perte de precision ou de valeurs. Or, ceci doit etre detecte par le compilateur. Comme il est evident que l'on ne peut ecrire :

float f;
char s[10];

f = s;
s = f;

Il donc bien d'un langage "type" qui ne permet pas n'importe quoi. Il est donc beaucoup plus limitatif que Python (par exemple) qui permet d'effectuer le genre d'ecriture ci-dessus, simplement parce que l'on peut redefinir des operateurs internes de conversion : __str__, __repr__, etc.

Il est bien entendu que ce que j'ai mentionne a propos de C n'est valable qu'a condition que l'on utilise la compilation en mode ANSI et que toutes les signatures de donctions soient declarees !

> Un langage fortement typé se plaint même si on 
> fait une chose pareille:
> int a
> long b
> float c
> a = 5
> b = a  <--- Erreur, int <> long

Non, il n'y a pas de perte de precison. Par contre l'inverse si !

> c = a  <--- Erreur, int <> float

Non plus... Dans le cas inverse, ca devrait etre flaguer car un float (32 bits IEEE) donne 6.7 chiffres significatifs, alors que int nous donne un peu plus de 9 chiffres significatifs...  

> Tandis que C laisse passer et considère ça comme:
> b = (long)a
> c = (float)a

C'est exactement l'operation qui est effectuee. Et cela ne pose aucun probleme du tout. Par contre, C permet d'ecrire ceci :

double d;
short i;
void *p;

p = &d;
i = *(short *)(p);  /* Different de  : i = (short)(*p) !!! */

Il y a perte de precision evidente et le compilateur n'y voit que du feu ! C'est la le vrai danger du C.

Ces regles sont exactement les memes que pour le 'C++' ! A la difference pret que C++ donne la possibilite d'ecrire du code qui peut "oriente" les conversions selon les desires du programmeurs.

> Celle-ci c'est l'une des principales faiblesses du C qui pose des
> problèmes de compatibilité et qui d'ailleurs avait fait tomber l'Ariane
> 5 lors du premier lancement car une routine était faite pour traiter des
> short (16 bits) et qui avait été utilisée pour la nouvelle fusée qui
> utilisait des int (32 bits) ou quelque chose dans le genre, pendant le
> vol il y a eu un dépassement et les calculs ont foiré. Boummm!

Boum sur les doigts de ceux qui ont ecrit le code !!!!!!!!! Le compilateur a parfaitement les moyens de verifier que l'on manipule bien des API equivalentes. Or, dans ce cas, le/les programmeurs ont sans doute commis une erreur (que je considere comme grave) dans la declaration de l'API. Mais,meme dans le cas ou ils auraient ommis la declaration de la signature des fonctions de l'API, ou declares des 'int', ils auraient du recevoir les warnings du compilateur. Donc, soit ils ont utilise le compilateur de mode "standard C", soit ils ont ignores les warnings, soit... Dans tous les cas, il s'agit d'une negligence qui a ete commise sciemment !

dc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://forum.linux-gull.ch/pipermail/gull/attachments/20050928/211c8adf/attachment.htm>