[gull] Types : [was: Php/MsSQL obsoletes?]
Leopoldo Ghielmetti
Leopoldo.Ghielmetti at a3.epfl.ch
Thu Sep 29 14:04:26 CEST 2005
On Thu, 2005-09-29 at 13:43, Daniel Cordey wrote:
> On Wednesday 28 September 2005 23:00, JM Nunes wrote:
>
> > ou dynamiquement (Pyhton, Perl -je crois), à l'exécution.
>
> Ben oui... les langages interpretes ne passent pas par la phase de
> compilation :-)
>
> > Ainsi en C c'est
> > char* x = "123"
> > et en Ocaml c'est
> > let x = "123"
> >
> > -"strongly typed"...
>
> Que veux-tu dire par la... ?
>
> >
> > *************** en C ****************
> > main () {
> > char* x = "123";
> > printf ("x=%i"; x);
> > }
> > ************
> > compilé et exécuté résulte en:
> > ./a.out
> > x=134513860
> >
> > *************** en Ocaml ********************
> > $ ledit ocaml
> > Objective Caml version 3.08.3
> >
> > # let x = "123";;
> > val x : string = "123"
> > # Printf.printf "x=%i" x;;
> > This expression has type string but is here used with type int
> > #
> > ***********************
> > **************** en Python **********************
> > $ python
> > Python 2.3.5 (#2, May 4 2005, 08:51:39)
> > [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> >
> > >>> x = "123"
> > >>> print 'x=%i' % x
> >
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in ?
> > TypeError: int argument required
> >
> > ******************
> > et donc C est plus faiblement typé que Ocaml et Python.
>
> Ce ne sont pas dut tout les memes choses. Je crois que la confusion viend du
> fait que les chaines de caracteres sont manipulees a l'aide de pointeurs,
> alors que dans tous les autres langages (aurais-je oublier un langage qui
> fasse pareil ?) il existe un type "string", totalement absent en C. Un 'char
> *' n'est pas un type "tring"; ce n'est qu'un vulgaire pointeur sur des
> valeurs de 1 byte !!! A ce titre, on ne compare pas du tout la meme chose. On
> peut discuter longtemps de l'absence d'un type de base "string" en C... il se
> trouve que c'est comme ca, que c'est tres simple mais c'est tout. Idealement,
> d'ailleurs, on devrait ecrire :
>
> const char x[] = "123";
>
> Mais ca n'a pas beaucoup d'importance...
>
> Ce qui fait que toute cette discussion concernant les chaines de caractere est
> biaisee. Un pointeur n'est qu'un "symbole" contenant une adresse. A ce titre,
> un "char *" ou un "double *" ne sont pas pareils. Tous les pointeurs ont une
> "empreinte" identique en memoire, mais les operations arithmetiques sur
> chacun d'eux ne sont pas identiques ! Exemple :
>
> int main(int argc, char *argv[])
> {
> char *pc;
> double *pd;
>
> char c = 'X';
> double d = 1.234;
>
> pc = &c;
> pd = &d;
>
> printf("pc\t: 0x%x\npc + 1\t: 0x%x\npd\t: 0x%x\npd + 1\t: 0x%x\n", pc, pc
> + 1, pd, pd + 1);
> printf("pc delta\t: %d\npd delta\t: %d\n", pc + 1 - pc, pd + 1 - pd);
> }
>
>
>
> pc : 0xbfffefef
> pc + 1 : 0xbfffeff0
> pd : 0xbfffefe0
> pd + 1 : 0xbfffefe8
> pc delta : 1
> pd delta : 1
>
> On voit que chaque pointeur est incremente en fonction du "type" sur lequel il
> pointe. pc est incremente de 1 byte, alors que pd est incremente de 8 bytes !
>
> Les pointeurs sont donc aussi "fortement" types, et le traitement des chaines
> de caracteres est une utlisation particuliere d 'un type de pointeur. Une
> chaine de catactere n'est en aucun cas un type en C; ce n'est qu'une suite de
> bytes en memoire, conventionnellement terminee par un carcatere NULL.
>
>
> > Essayons maintenant
> > ***************** C ****************
> > main(){
> > int x = 123;
> > printf ("x=%s",x);
> > }
> > **************
> > le résultat est
> > $ ./a.out
> > Segmentation fault
>
> Ici, normal... c'est plutot la librairie C qui est coupable. Elle "balaie" la
> chaine de caractere representant le format, afin de determiner ce qu'elle
> doit recuperer comme argument dans la liste. Sur la base du %s, elle
> considere que le deuxieme argument de la fonction est un pointeur, elle en
> prend donc la valeur et essaie de lire les byte a cette adresse...
> Naturellement, avec une valeur de '495051', on a toute les chances de genere
> un 'segmentation fault'; cette adresse ne faisant certaienement pas partie
> des pages de la zone data du process...
>
> Comme dans Ocaml, c'est donc une mauvaise definition de format d'impression
> qui est a mettre en cause, plutot que le type.
>
> > ************ Python ****************
> >
> > >>> x=123
> > >>> print 'x=%s' % x
> >
> > x=123
> > ******************
> >
> > D'où Python est plus faiblement typé que Ocaml.
>
> Absolument pas ! C'est exactement le contraire... en Python, chaque type est
> un objet, or, un objet 'int' a une methode __str__() definie par defaut... et
> cest cette methode qui est appelee automatiquement par le fait de la
> definition '%s' dans le format d'impression. Pour vous en convaincre, il vous
> suffit de creer une classe quelqconque, sans methode __str__. En essayent
> d'imprimer un instance de votre objet avec le format "%s", vous aurez une
> exeption due au fait que l'interpreteur ne trouve pas de methode __str__
> associee a cet objet ! Ce qui est parfaitement logique... meme elegant :-)
Pas tout a fait exact:
Python 2.3.3 (#1, Feb 5 2005, 16:22:10)
[GCC 3.3.3 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class toto:
... def __init__(self):
... pass
...
>>> a=toto()
>>> print a
<__main__.toto instance at 0x4039828c>
>>>
Pas d'exception!
ciao, Leo
> On voit bien qu'il n'est pas necessaire de discuter pour savoir si un langage
> est plus "type" qu'un autre. Cela n'amene rien de plus. Il suffit de bien
> comprendre comment chaque langage manipule ses types et ses donnees, d'en
> connaitres les limites et les contraintes. A partir de la, on peut programmer
> proprement.
>
> > <troll>
> > Si toutefois on cherche le langage le moins mauvais pour exprimer tout
> > algorithme ---i.e., *le* langage de programmation générique--- on finit
> > par trouver Ocaml. Mais je vous laisse le temps de le découvrir...
> > </troll>
>
> Pourquoi pas :-) Chaque lanagage poursuit un objectif prioritaire. Certains
> sont plsu adaptes que d'autres pour certaines taches, mais aucun langage ne
> peut pretendre tout faire mieux que tous les autres. Si aucun langage ne vous
> satisfait, ecrivez le votre ! C'est ce que les auteurs de tous les langages
> dont on parle on fait... sauf Ada et PL/1 (entre autre) :-)
>
> dc
> _______________________________________________
> gull mailing list
> gull at lists.alphanet.ch
> http://lists.alphanet.ch/mailman/listinfo/gull
>
>
-------------- 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/20050929/be790eb6/attachment.pgp>
More information about the gull
mailing list