Exercices,langage C

[fakbill]

Hé non ils mettent des "" autour de "strongly typed" pour bien expliqué que ça n'a pas vraiment de sens dans le cadre du duck typing.

Ce que je voulais préciser c'est que duck typing signifiait deux choses. Que la vérification de type se fait à l'exécution (typage dynamique), donc au moment ou on accède à la valeur

Non. Bien souvent, python ne vérifie pas le type car ça n'a pas de sens de le cadre du duck typing.
Le nom "duck typing" est un peu trompeur. Python se fiche royalement du type. La notion même de type (à la C, C++ ou Caml) n'a pas vraiment de sens en python. Tout ce qui compte, c'est de savoir si l'objet possède ou pas la méthode qu'on veut au moment où on en a besoin. Comme tout est dynamique en python, on peut rajouter on enlever des méthodes à n'importe quel moment. Ça ne change pas le "type" (au sens classique, pré duck typing) du terme) de l'objet car cette notion de type n'a pas de sens dans le cadre du duck typing. Partant de là, dire que c'est "typé fort" n'a pas grand sens...d'où les guillemets.

[fakbill]

ps : tout ça va au delà de ce qu'on attend d'un débutant hein...
Ca peut sembler étrange si on a appris un langage typé avant le python. Cependant, je trouve que le duck typing est une superbe idée....quand on y pense, tout ces systèmes de types sont là pour tenter d'assurer que ça merdouille le moins possible...et la solution que je trouve la plus pragmatique...ben c'est le duck typing.

[fakbill]

Je crois que tu n'as pas bien compris l'étendue du duck typing en python.
Ou alors ce que tu appelles "un type" n'est pas la même chose que ce que j'appelle un type.
Pour moi, simplement, un type, c'est une étiquette : http://en.wikipedia.org/wiki/Data_type# ... .22type.22
Il se trouve qu'en python, on vérifie rarement l'étiquette. Ho oui, si tu instancies un objet alors cet objet a un type au sens de type() ou de isinstance() mais on s'ent tape un peu en python.

En python, on fait "def sum(a,b):" et ca marchera du moment que a sait faire "ajouter b". Le type de a et de b n'entrent pas en jeu (puisque de toutes facon on ne dit pas pour quels types la fonction est écrite).

C'est pour ca que je dis que OUI, python est typé mais "strong" ou "weak" bof bof...ca n'a pas trop de sens dans ce contexte. Le paradigme en python est tout autre : on ne vérifie pas l'étiquette mais seulement le fait que, le moment venu, l'objet sait faire coincoin.

[fakbill]

Mais si tu écris, x = 3 + "hello", ou si tu écris "x = 3" puis "x.toto" tu auras une erreur générée par le run-time etc... Le compilateur ne vérifie pas le type, parce que c'est du typage dynamique. Mais à l'exécution, le programme le vérifie et renvoie une erreur en cas d'incompatibilité.

Vraiment on ne parle pas le même langage
Ce n'est pas parce que c'est dynamique qu'on ne check pas le type. On peut avoir du dynamique qui check le type si on veut dans d'autres langages.

Regarde ca:
x=3+"foo"
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-1-ad174166c699> in <module>()
----> 1 x=3+"foo"

TypeError: unsupported operand type(s) for +: 'int' and 'str'

Python ne dit pas "types incompatibles" comme gcc le dirait sur du C. Il dit juste "int ne sait pas ajouter une str à lui même).
Encore une fois, je n'appelle pas ca une vérification du type mais une véfication du fait que les objets sache faire ce qu'on leur demande *le moment venu*. C'est important. C'est *le moment venu*. Dans les langages où on déclare les types, le compilo râle dès qu'on passe un type qui n'est pas celui déclaré dans le prototype. Je trouve ca assez peu souple finalement.
Prenons def sum(a,b). Soit tu déclares explicitement les types du genre (int a, int b) mais là tu as le pb de "et pour floats? et pour double?" Le problème est réglé en C par des cast implicites ce qui est relativement moche. En C++, si tu écrits int sum(Foo int, Foo int), c'est un peu dommage que ca ne marche pas si tu passes un 'a' ou un 'b' de type Bar (sans lien d'héritage avec Foo). La facon de régler ce problème en C++ est un système d'héritage complexe et, d'un autre point de vue (à la compilation), les templates. Tout ce machin complexe permet de faire ce qu'on VEUT en fait faire le plus souvent : écrire une fonction sum qui somme 'a' et 'b' du moment qu'ils savent le faire. C'est pour ca que j'aime bien le duck typing...mais oui c'est une question de gout.

[fakbill]

ok
En tant que system eng, je plaide coupable : "toujours vérifier qu'on se comprend bien sur les TERMES du blabla avant de poursuivre le dit blabla".

[Professeur Rectangle]

Comme dit plus haut, c'est plus simple de vérifier soit-même si son programme marche ou pas du coup.

Pour avoir enseigné C, je trouve que dans ce langage il est difficile pour l'étudiant de vérifier lui-même son programme.
Il est très facile d'avoir fait une erreur "invisible", par exemple un débordement de tableau, de la lecture dans de la mémoire désallouée, etc. Dans d'autres langage, c'est impossible (une erreur arrête le programme en cas de débordement de tableau par exemple).
Sans compter qu'on peut "croire" que son code marche quand il ne va marcher que sur 1 compilateur.

[fakbill]

Sans compter qu'on peut "croire" que son code marche quand il ne va marcher que sur 1 compilateur.

Non ca c'est si on compile sans le plus haut niveau de warnings ET qu'on ne véfirie pas (e.g. avec valgrind) que la mémoire est ok.
Un programme qui déborbe en mémoire ne **marche** sur AUCUN compilo. "Marche" au sens "fait le calcul de facon prédictible".

Pour avoir enseigné C, je trouve que dans ce langage il est difficile pour l'étudiant de vérifier lui-même son programme.

Le langage C est plus compliqué pour un débutant qu'un autre langage comme python car, en C, on gère la mémoire à la main.
Une fois qu'on a compris ca, on peut faire tourner ses PETITS codes à la main. Si suffit d'avoir en tête ce qui se passe en mémoire.
Taper en dehors d'un tableau est une errreur en C et en python (évidence...). Je ne vois pas pourquoi ce serait plus dur en C de voir à la main qu'on a un pb. Aue l'erreur puisse passer inappercue et/OU planter le code plus loin en C est une chose...mais quand on fait tourner le machin à la main sur un exemple de petites dimensions, ca ne fait aucune différence avec disons du python.

Le tout est de bien comprendre ce qu'est un pointeur.

[Professeur Rectangle]

Sans compter qu'on peut "croire" que son code marche quand il ne va marcher que sur 1 compilateur.

Non ca c'est si on compile sans le plus haut niveau de warnings ET qu'on ne véfirie pas (e.g. avec valgrind) que la mémoire est ok.
Un programme qui déborbe en mémoire ne **marche** sur AUCUN compilo. "Marche" au sens "fait le calcul de facon prédictible".

Il n'y a pas que les problèmes de mémoire qui rendent compilateur-dépendant. Et mettre le plus haut niveau de warning dépend de comment le compilateur respecte le standard.

[fakbill]

Il n'y a pas que les problèmes de mémoire qui rendent compilateur-dépendant. Et mettre le plus haut niveau de warning dépend de comment le compilateur respecte le standard.

Non et non.
Sauf à aller taper dans des projets aussi bas niveau et complexe que le noyau linux, n'importe quel compilo C non ridicule fera l'affaire de la même façon. Tu as donné des cours à des experts en C ou quoi?? De plus, "les pbs de mémoire" ne sont pas compilo-dépendant. Qu'un code faux plante de façon différente d'un compilo à l'autre n'est pas une observation intéressante car, si on gère mal la mémoire, alors le comportement du programme est "undef". Une fois ça va marcher un fois ça va planter et c'est fonction d'un tas de choses très bas niveau.
Bref, le message "ça dépend du compilo" n'est pas le bon du tout. Le bon message c'est "si la mémoire est mal gérée, alors que ça marche ou pas sur un exemple n'a pas d’intérêt : un jour ça plantera". Les variantes dans le détail des options et des perfo d'un compilo à l'autre....laissons ça aux experts.

Certains compilo émettent des warnings plus "justes" et plus informatifs que d'autres mais ce n'est pas spécifié par le standard ISO à ce que je sache (d'ailleurs, certains warnings tentent de résoudre un problème indécidable en toute généralité (Wunused par exemple) donc je vois mal ce que le standard pourrait en dire