Exercices,langage C

Modérateur : Michel Quercia

Avatar du membre
fakbill
Messages : 11264
Enregistré le : mer. juil. 30, 2008 4:59 pm
Classe : Dr.-Ing

Re: Exercices,langage C

Message par fakbill » lun. déc. 08, 2014 11:57 pm

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.
Pas prof.
Prépa, école, M2, thèse (optique/images) ->ingé dans le privé.

Avatar du membre
fakbill
Messages : 11264
Enregistré le : mer. juil. 30, 2008 4:59 pm
Classe : Dr.-Ing

Re: Exercices,langage C

Message par fakbill » mar. déc. 09, 2014 12:02 am

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.
Pas prof.
Prépa, école, M2, thèse (optique/images) ->ingé dans le privé.

Yodsanklai
Messages : 90
Enregistré le : ven. nov. 21, 2014 2:37 pm

Re: Exercices,langage C

Message par Yodsanklai » mar. déc. 09, 2014 12:33 am

fakbill a écrit :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.


Je pense qu'ils mettent les guillemets tout simplement parce que "weak/strong" typing n'est pas quelque chose de bien défini. Toujours selon wikipedia

These terms do not have a precise definition, but in general a strongly typed language is more likely to generate an error or refuse to compile a program if the argument passed to a function does not closely match the expected type.


A chaque utilisation d'une valeur (appel d'une méthode d'un objet, paramètre) python vérifie que les types sont compatibles. Et sinon, il renvoie une erreur de typage. Ça rentre dans la catégorie "strongly typed".

Non. Bien souvent, python ne vérifie pas le type car ça n'a pas de sens de le cadre du duck typing.



Je ne comprends pas ce que tu veux dire.

Si on écrit "y = x", non, il n'y a aucune vérification à faire puisqu'il ne s'agit que de copier une référence. 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é.

L'histoire de "duck typing", c'est autre chose, c'est juste qu'on peut appeler la méthode toto sur n'importe quel objet qui possede cette méthode (par opposition à seulement des objets qui seraient instance d'une classe donnée). Si tu veux, la vérification à l'exécution est un peu plus "laxiste" que dans d'autres langages, mais elle est la.

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.


Mais python est un langage typé !! :)

Pour moi la solution la plus pragmatique, c'est un langage typé statiquement, mais avec inférence de type. Comme OCaml, Scala, Go par exemple. L'inconvénient du typage dynamique c'est de ne pas détecter les erreurs à la compilation. Potentiellement, tu risques de passer à coté de bugs évidents.
Ce que tu gagnes, c'est de pas avoir à déclarer des types (et puis une certaine dynamicité qui est parfois commode). Ton programme est plus concis. On l'écrit avec moins de contraintes.

Pour moi, ce qu'on gagne en temps de développement, on le perd tres clairement en temps de maintenance, debuggage etc...

Avec l'inférence, tu as le meilleur des deux mondes. Tu ne déclares pas les types, mais ils sont inférés par le compilateur qui te détecte des erreurs que tu n'aurais pas vu autrement.

Mais bon, c'est un débat sans fin. Il y a des tonnes et des tonnes de discussion la dessus sur des forums spécialisés genre "lambda the ultimate". D'ailleurs, il y a même des chercheurs qui ont fait des études pour comparer la productivité de programmeurs qui utilisaient l'un ou l'autre de ces langages. Voir ici pour une liste http://danluu.com/empirical-pl/

Avatar du membre
fakbill
Messages : 11264
Enregistré le : mer. juil. 30, 2008 4:59 pm
Classe : Dr.-Ing

Re: Exercices,langage C

Message par fakbill » mar. déc. 09, 2014 1:16 pm

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.
Pas prof.
Prépa, école, M2, thèse (optique/images) ->ingé dans le privé.

Avatar du membre
fakbill
Messages : 11264
Enregistré le : mer. juil. 30, 2008 4:59 pm
Classe : Dr.-Ing

Re: Exercices,langage C

Message par fakbill » mar. déc. 09, 2014 1:32 pm

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.
Pas prof.
Prépa, école, M2, thèse (optique/images) ->ingé dans le privé.

Yodsanklai
Messages : 90
Enregistré le : ven. nov. 21, 2014 2:37 pm

Re: Exercices,langage C

Message par Yodsanklai » mar. déc. 09, 2014 2:39 pm

fakbill a écrit :Ou alors ce que tu appelles "un type" n'est pas la même chose que ce que j'appelle un type.


C'est effectivement la source de confusion. Un type n'est pas nécessairement une étiquette. Ça l'est en Java et C (ce que j'appelle typage nominal, basé sur des noms), ça ne l'est pas en OCaml ou Python (typage structurel). Encore une fois, en caml, on peut écrire fun x -> x#a qui acceptera en argument n'importe quel type possedant un attribut "a". Python est dynamique et structurel (= duck typing), Caml est statique et structurel etc...

Avatar du membre
fakbill
Messages : 11264
Enregistré le : mer. juil. 30, 2008 4:59 pm
Classe : Dr.-Ing

Re: Exercices,langage C

Message par fakbill » mar. déc. 09, 2014 3:20 pm

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".
Pas prof.
Prépa, école, M2, thèse (optique/images) ->ingé dans le privé.

Avatar du membre
Professeur Rectangle
Messages : 61
Enregistré le : sam. mai 24, 2014 7:50 pm

Re: Exercices,langage C

Message par Professeur Rectangle » ven. déc. 19, 2014 9:25 am

Taupelvl a écrit :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.

Avatar du membre
fakbill
Messages : 11264
Enregistré le : mer. juil. 30, 2008 4:59 pm
Classe : Dr.-Ing

Re: Exercices,langage C

Message par fakbill » ven. déc. 19, 2014 2:58 pm

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.
Pas prof.
Prépa, école, M2, thèse (optique/images) ->ingé dans le privé.

Avatar du membre
Professeur Rectangle
Messages : 61
Enregistré le : sam. mai 24, 2014 7:50 pm

Re: Exercices,langage C

Message par Professeur Rectangle » sam. déc. 20, 2014 3:27 pm

fakbill a écrit :
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.

Avatar du membre
fakbill
Messages : 11264
Enregistré le : mer. juil. 30, 2008 4:59 pm
Classe : Dr.-Ing

Re: Exercices,langage C

Message par fakbill » sam. déc. 20, 2014 5:14 pm

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 ;)
Pas prof.
Prépa, école, M2, thèse (optique/images) ->ingé dans le privé.

Répondre

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 2 invités