[gull] Types : [was: Php/MsSQL obsoletes?]

[Leopoldo Ghielmetti]

Un autre avis sur le typage fort est donné par la wikipedia (ou ai-je
entendu ce mot récemment????).

http://en.wikipedia.org/wiki/Data_type

...
Strong and weak typing
Main article: strongly-typed programming language

A strongly typed language has several meanings; for a clearer
discussion, see the main article on the topic. One definition involves
it not allowing an operation to succeed on arguments which are of the
wrong type. An example of the absence of strong typing is a C cast gone
wrong; if you cast a value in C, not only is the compiler required to
allow the code, but the runtime is expected to allow it as well. This
allows C code to be compact and fast, but it can make debugging more
difficult.
...

Elle donne le C comme exemple de langage "non fortement typé" par la
suite elle cite le Visual Basic et le REXX (qui sont encore moins typés
que le C), mais pour cela je vous laisse lire l'article. :-)

Par contre je n'ai pas vu d'exemple de langage fortement typé.
Il y a un autre article qui donne d'autres raison et qui explique que
l'argument est quand même plus compliqué qu'on ne le pense car il y a
plusieurs caractéristiques du typage qui ne permettent pas de séparer
clairement Strong et Weak typing.

http://en.wikipedia.org/wiki/Strongly-typed_programming_language

ciao, Leo

On Fri, 2005-09-30 at 09:02, Daniel Cordey wrote:
> On Friday 30 September 2005 00:30, Marc Mongenet wrote:
> 
> > La fonction printf a le prototype suivant :
> > int printf(const char *, ...);
> > L'usage des "..." sert justement à faire sauter la vérification du type
> > et du nombre de paramètres passés.
> 
> Dans le sens ou cette verification ne sera pas faite de maniere 'statique' par 
> le compilateur. Il est evident que ce genre de truc et laisse a l'execution 
> le choix du 'trap' a generer en cas d'erreur...
> 
> > Printf me semble donc plutôt démontrer le fort typage de C,
> 
> C'est aussi mon avis.
> 
> > puisqu'il faut avoir recourt à un mécanisme certes fort utilisé
> > (avec printf, sprintf, fprintf) mais finalement exotique et très
> > peu connu
> 
> Heureusement !
> 
> > (qui a déjà écrit une fonction C à liste de paramètres 
> > variable ?)
> 
> Moi... et en assembleur... pour printf() justement. C'est la que l'on decouvre 
> les joies des differentes architectures, OS, compilateurs... Par exemple sur 
> HP-PA (HP-UX), les arguments ne sont pas passes dans le stack, mais, pour les 
> 6/8 premiers, par les registres. Le probleme se corse lorsque l'on passe des 
> double/float... ces arguments ne sont pas passes dans les registres generaux 
> mais dans les regirtres FP... Doux melange entre registres genereaux et FP... 
> Les arguments aditionnels sont par contre dans le stack. C'est vraiment 
> galere. 
> 
> Pour de multiples raisons, il est donc fortement deconseille d'adopter ce 
> genre de pratique en C et C++. Dans le cas de Python (ou autres langages 
> interpretes), il est possible de traitre ce probleme de maniere propre. Voir 
> d'utiliser des arguments 'nommes', comme :
> 
> 	fonction(**kwd)
> 
> On peut alors appeler la fonction avec :
> 
> 	x = fonction(file = 'toto', mode = 'rw', append = False)
> 
> On peut mettre les arguments dans un order quelconque et l'on recupere ceux-ci 
> dans la fonction sous une forme de dictionnaire. CAD, Tableau indexe a l'aide 
> des noms des arguments.
> 
> Il est aussi possible, comme en C, d'avoir des arguments "libres" a l'appel. 
> CAD que l'on peut appeler la fonction avec moins d'arguments que le nombre 
> defini. Ceci, seulement si l'on a declarer explicitement ces arguments comme 
> optionnels en precisant une valeur par defaut en cas d'absence. 
> 
> Naturellement, ce luxe a un prix qui se paie au runtime, puisque 
> l'interpreteur doit effectuer toutes ces verifications lors de chaque appel. 
> 
> > Si C était né avec toutes les vérifications de types que chacun utilise
> > aujourd'hui, tous le monde citerait C comme exemple de langage
> > fortement typé avec simplement quelques (dangeureux mais pour la
> > plupart évitables) archaïsmes. Je soupçonne d'ailleurs 90% de la
> > critique actuel de C de n'être que des échos de la critique, en ce
> > temps fondée, des années1970.
> 
> On ne peut plus vrai !
> 
> 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/20050930/dce4ea44/attachment.pgp>