[gull] Php/MsSQL obsoletes?

[Leopoldo Ghielmetti]

On Wed, 2005-09-28 at 13:04, Daniel Cordey wrote:
> 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... 

Je suis d'accord, ma remarque portait entre le fortement typé et le
typé. C n'est pas fortement typé.

Mais tu peut très bien écrire une chose comme celle la (en ANSI C):

module.c:
void fonction(int a)
{
  printf("%d\n", a);
}

module.h:
void fonction();

main.c:
include "module.h"

int main()
{
  float b = 1.0;
  fonction(b);
  return 0;
}

Et ça passe très bien. Et la plus part des programmes sont encore écrits
comme ça car c'était une syntaxe courante dans les années 80 et encore
beaucoup de programmeurs ont ce réflexe.

Ceci est possible car dans C la vérification des types n'est pas
obligatoire et on peut s'en passer. Donc on risque d'avoir des problèmes
de typage.

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

Le fait que la conversion est autorisée et correcte dans le sens de la
définition ANSI ne change rien sur le fait que le langage n'est pas
fortement typé. ANSI peut très bien définir un langage fortement type et
un non fortement type, les deux seront standard mais leur typage sera
différent.
Mais le fait qu'il existe des conversions implicites implique que le
langage n'est pas fortement typé. Ensuite on peut aimer ou pas.

Le fait que je sais qu'on ne perd pas en précision ne m'aide pas
forcement, il faut toujours avoir bien à l'esprit le type de chaque
variable pour être sûr de ne pas changer le type sans s'en rendre compte
(chose qui est bien plus facile de ce qu'on pourrait croire, surtout si
on utilise des anciennes librairies). Et ceci peut causer pas mal de
problèmes si on accède au matériel ou si on travaille au niveau du bit.

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

Je suis d'accord.

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

Mais il s'agit quand même d'une conversion qui n'a pas été explicitée
par le programmeur.

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

Bien sûr qui peut poser des problèmes car la variable à changé de nature
et le programmeur n'en sait rien.

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

Je suis tout à fait d'accord. L'utilisation des pointeurs peut être très
dangereuse si on ne fait pas attention.

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

Pas totalement vrai, p.e. le compilateur cc de Sun c'est une vraie merde
de ce côté. J'ai vu du code qui donne 1000 Warning sur le gcc et sur le
cc Alpha de Digital et seulement 100 sur le compilateur cc de Sun. Et
parfois c'était des vraies merdes. S'ils ont utilisé un compilateur
comme celui la, qui même avec toutes les options de compilation ne donne
rien, il est normal qu'ils n'ont pas vu certaines fautes. Il est vrai
qu'ils auraient pu utiliser lint ou tout autre programme similaire. Mais
je ne dirais pas qu'il s'agit d'une négligence commise sciemment, juste
d'une négligence qui peur aussi être due simplement à l'ignorance.

> dc

ciao, Leo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://forum.linux-gull.ch/pipermail/gull/attachments/20050928/076da155/attachment.pgp>