Trim a écrit:

Salut !

Je voulais juste mettre un petit message pour remercier GNU/Linux Debian (et Ubuntu), son compilateur C à jour et l'IDE Code::Blocks !

Hier, j'ai reçu mon examen de programmation et j'ai eu un joli 5,5 (en Valais le maximum est le 6), mais à 0.5 point près, j'avais 6. Je suis donc allé voir mon prof. ce matin et je lui ai montré que mon programme marchait sur mon portable et je lui ai donc demandé pourquoi il m'avait enlever autant de points sur un exercice.

Quand mon prof. a vu que mon programme fonctionnait sur mon laptop, il m'a dit qu'il devait me rajouter 0,5 point, ce qui m'a donné la note 6. Pourtant, il m'a montré que sur son PC avec Windows, le programme ne fonctionnait pas : à la base, il utilise l'environnement de développement (ou IDE) Devcpp (la dernière mise à jour date de 2005), mais le programme ne fonctionnait pas du tout. Ensuite, il a essayé avec Code::Blocks 8.02 (la même version que moi), le programme redonnait une réponse, mais c'était totalement faux.

Alors, je ne sais pas où est la différence entre son ordinateur et le mien (je ne suis pas sûr que Code::Blocks installe les bibliothèques gcc ou s'il utilise le compilateur de Windows), mais en tout cas, je remercie Linux d'avoir fait fonctionner le programme sur mon PC

Par contre, mon prof. m'a montré sa correction pour que le programme fonctionne sous windows. Et j'avais effectivement fait une erreur dans mon programme. Alors, pour ceux qui connaissent bien le C et Linux, vous saurez peut-être nous répondre : en fait, Linux avait l'aire de comprendre implicitement mon programme (un peu comme s'il corrigeait mes erreurs, tels FireFox qui corrige les erreurs de base...).

----------------------------------------------------------------------------------------------------------------------------------

Pour ceux qui aiment bien les maths et le C, voici le programme en question :

Le but du programme est de faire la fonction mathématique d'Ackermann. C'est une fonction récursive, alors elle doit s'appeler elle-même lors de son fonctionnement jusqu'à ce qu'on lui passe un argument nulle.
Voici mon programme :

Code:

#include <stdio.h>
#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int  ackermann(int x, int y)
{
    if(x==0)
        return (y+1);
    else if(x>0 && y==0)
        ackermann((x-1),1);
    else if(x>0 && y>0)
        ackermann((x-1),ackermann(x,y-1));
}

main()
{
  int m,n;
  int res;
  printf("Entrer la valeur de m \n");
  scanf("%d",&m);
  printf("entrer la valeur de n \n");
  scanf("%d",&n);
  res = ackermann(m,n);
  printf("La fonction d'Ackermann A(%d,%d) vaut %d \n",m,n,res);
  system("pause");
  return(0);
}

Normalement ce programme ne devrait pas fonctionner, parce que d'une fois que l'on passe dans la deuxième ou troisième condition, j'ai oublié de demander de retourner la valeur trouvée. Mais ça marche sous Linux... je ne sais pas pourquoi.

Déjà quand tu compiles avec GCC active le -Wall

$ gcc lol.c -Wall
lol.c: In function ‘ackermann’:
lol.c:14: attention : control reaches end of non-void function
lol.c: Hors de toute fonction :
lol.c:17: attention : return type defaults to ‘int’

Ensuite j'ai peut être la réponse.. je vais essayer d'expliquer simplement..

Un processeur travail avec un petit nombre de registres.. et il y a certaines règles quand un programme C est compilé. Une de ces règle dit que la valeur de retour d'une fonction est renvoyée dans le registre EAX (x86 32 bits), ou RAX en 64 bits (r0 pour les fan d'ARM). Un registre est une mémoire mais intégrée dans le processeur.. Elle est donc extrêmement rapide (à ne pas confondre avec le cache, ça n'a rien a voir) et si le compilateur peut utiliser ces registres alors il évite donc les accès à l'extérieur qui sont "lents" tel que la RAM.

(si t'as déjà fais de l'assembleur sur PIC, alors tu peux comparer EAX au registre de travail "w" du PIC)

Ainsi chaque fois que la fonction ackermann est appelée, la valeur de retour est sauvée dans le registre EAX. Et même si à la fin tu ne retournes pas la valeur, t'as peut être un monstre bol que GCC n'utilise pas EAX pour autre chose.. et donc tu récupères chaque fois la bonne valeur.


par exemple avec ca:

ackermann((x-1),1));

un moment ou un autre ackermann a fait le return (y+1); et a donc sauvé le calcul dans EAX. Donc t'as de la chance qu'EAX ne soit pas réutilisé par le compilateur pour faire un autre calcul.

Pour faire if(x>0 && y==0), il aurait très bien pu utiliser EAX.. mais peut être qu'il utilise EBX et(ou) ECX.

Et le compilateur de ton prof utilise peut être justement EAX pour faire les tests (donc les if)..


Pour être sûr faudrait le décompiler et regarder ce qui se passe en assembleur. C'est qu'une théorie, je n'ai pas décompilé pour vérifier.. et si ensuite tu joues avec les optimisations du compilateur, tu peux avoir des variantes encore plus farfelues..
Mais ce qui est sûr, c'est que ton programme est faux.

korbé a écrit:

Mais dans quel école en suisse on peut apprendre autant de choses?

Par ce que technicien en informatique à Genève, c'est C#, C# et quoi d'autre, ah oui C#. Et ce C# commence à me les gonfler.

Ben en fait, je suis "simplement" au collège et j'ai choisi la filière "physique et mathématiques appliquées". C'est justement pour les applications des maths qu'on doit savoir programmer, mais le choix du langage dépend du professeur (avant, le plus courant était l'enseignement du Pascal, je crois).
Par contre, 75% de la classe, si ce n'est plus, ne serait pas de ton avis : la plupart a choisi la physique et la programation est un fardeau pour eux (moi j'aime bien les deux, tant mieux).

korbé a écrit:

Dit, je peut jouer les emmer*eur ?

Euh, oui effectivement, j'ai aussi appris à la base à faire comme ça avec le site du zéro. Mais j'ai passé la veille à étudier les exercices de mon professeur où les fonctions sont définies avant la fonction main. C'est moins élégant, mais peut-être que c'est plus simple à expliquer pour ne pas faire compliquer : notre but n'est pas de programmer en soi, mais de faire des maths, donc on ne fait pas toujours dans les règles de l'art...

[GO a écrit:

Skywalker13]Donc t'as de la chance qu'EAX ne soit pas réutilisé par le compilateur pour faire un autre calcul.

Merci pour l'explication, je crois avoir plus ou moins compris. Et si c'est ainsi, j'ai vraiment de la chance, parce que je ne suis pas sûr que j'aurai compris l'erreur le jour de l'examen.

[GO a écrit:

Skywalker13]Mais ce qui est sûr, c'est que ton programme est faux.

Mon professeur confirme, parce qu'il ne m'a quand même pas mis tous les points pour l'exercice, mais il m'en a juste rajouté 0,5 parce que ça marchait.

Dernière modification par Trim (31 Mar 2009 21:59:11)

korbé a écrit:

Mais dans quel école en suisse on peut apprendre autant de choses?

Par ce que technicien en informatique à Genève, c'est C#, C# et quoi d'autre, ah oui C#. Et ce C# commence à me les gonfler.

Si tu veux étudier plus en détails comment fonctionne finalement un microprocesseur il faut tout d'abord aborder l'assembleur.. mais pas seulement..  il y a certains apprentissages comme informaticien où l'assembleur sur PIC est enseigné, mais c'est relativement simpliste.. les cours ne creusent pas tellement..
par contre dans une école d'ingénieur qui est aussi orienté électronique, alors tu descends jusqu'au niveau électrique en allant observer directement à l'oscilloscope le comportement de ton programme sur certaines i/o ou même pour dialoguer avec un contrôleur. Mais faut être conscient que tu ne fais pas que de l'informatique.. mais beaucoup d'électronique aussi bien analogique que digital. Tu travailles non plus pas qu'avec des microprocesseurs (ou controlleurs, dsp) mais aussi des FPGA et donc du VHDL et la logique combinatoire. Sans oublier le côté haut niveau et l'UML..  bref c'est très large et relativement détaillé.. faut aimer aussi (au moins un peu) les mathématiques et la physique.. (j'ai omis de citer encore pas mal de chose, comme les transmissions, la RF, ...)

Ce qui est dommage c'est que depuis que le système bachelor est entré en vigueur, les cours sont coupés à la hache.. c'est un malheureux pas en arrière dans les hautes écoles..

Trim a écrit:

korbé a écrit:

Dit, je peut jouer les emmer*eur ?

Euh, oui effectivement, j'ai aussi appris à la base à faire comme ça avec le site du zéro. Mais j'ai passé la veille à étudier les exercices de mon professeur où les fonctions sont définies avant la fonction main. C'est moins élégant, mais peut-être que c'est plus simple à expliquer pour ne pas faire compliquer : notre but n'est pas de programmer en soi, mais de faire des maths, donc on ne fait pas toujours dans les règles de l'art...

Détrompe toi, ce n'est pas moins élégant..  le fait de ne pas déclarer les prototypes au sommet du fichier te force à organiser la moindre le code. Et naturellement, les fonctions qui dépendent de beaucoup d'autres fonctions se retrouveront au fond et inversement. Ce qui donne une certaine cohérence dans l'organisation du fichier.

fbianco a écrit:

[Mais bon le C c'est mieux que le Pascal, et de toutes façons mieux que le TopPascal (et LOGO) que j'ai appris ;-)

Je n'en suis pas si sur. J'ai debute en C. C'est apres qu'on se rend compte que l'on a certaines mauvaises habitudes...
Je pense que l'on ferait mieux d'apprendre un langage pascal-like (ADA, eiffel).

[GO a écrit:

Skywalker13]
Ce qui est dommage c'est que depuis que le système bachelor est entré en vigueur, les cours sont coupés à la hache.. c'est un malheureux pas en arrière dans les hautes écoles..

C'est vrai mais cela permet aussi de voir des choses differentes enseignes par des gens travaillant dans des domaines tres different.
Je trouve que c'est plutot bien. C'est vrai que des fois on a l'impression que certain cours sont sans rapport (on pense que tu as deja fait certaines choses et c'est pas le cas) avec d'autres.

PS. dsl pour les accents mais je peut pas les faire

korbé a écrit:

Mais dans quel école en suisse on peut apprendre autant de choses?

Par ce que technicien en informatique à Genève, c'est C#, C# et quoi d'autre, ah oui C#. Et ce C# commence à me les gonfler.

Fallait faire école d'ing

sebseb01 a écrit:

Si je suis aller jusqu'à sainte-croix c'est pas pour le fun

T'y <es|étais> de quand à quand ?
Si ça se trouve, on s'est croisés...

korbé a écrit:

Mais dans quel école en suisse on peut apprendre autant de choses?

Par ce que technicien en informatique à Genève, c'est C#, C# et quoi d'autre, ah oui C#. Et ce C# commence à me les gonfler.

Je confirme. Si je suis entré à l'école technique du Locle (ma ville) c'était pour y apprendre le C(++).
Eh bien non dès que je suis arrivé c'était C#, grosse déception.
Vivement l'école d'ing' pour le Java...

C'est quoi leur problème aujourd'hui avec ce langage qui va nous mener à rien?
Encore heureux que j'aie appris le C(++) par mes propres moyens...

Hello,

  Très honnêtement, après avoir touché à C, Perl, Haskell, Erlang, J, R, et dieu sait quoi d'autre, je considère que C# et Java sont très, très proches (Et ça doit être plus facile de traduire du Java en C# que l'inverse).

Le processus de modélisation est quasiment identique dans ces deux langages, et c'est ce processus qui est important pour produire du bon code, plus que les petits détails de la syntaxe.

100% d'accord avec les avantages d'un langage fortement typé, mais de la bonne manière. ava et C# ne sont pas parfaits, mais ils ont évolué depuis Java 1.4, et le support des génériques est tout à fait décent, et globalement mieux pensé que les templates C++; Scala a même une inférence de type partielle et des annotations de variance.

La par contre, je ne suis moins d'accord

Mais faut se rendre compte de ce qui se passe en dessous et ne pas voir le PC comme une boite noire.

Mais toute la notion de portabilité se résume à ca; on n'a pas encore trouvé d'architecture universelle meilleure que toutes les autres dans tous les domaines. Même si tu maitrises à la perfection deux ou trois architectures, il y en aura 50 pour lesquelles le compilateur fera un meilleur travail...

Un petit exemple.. en C, toute valeurs différentes de 0 est considérées comme VRAI, autrement comme FAUX. (...)Mais on se pose cette question jusqu'au jour où on sait qu'un CPU ne peut pas adresser moins de 8 bits (c'est foutu pour les 2 valeurs) et donc que les variables booléennes n'ont pas de sens d'un point de vue CPU

Mais l'approche C est un choix totalement arbitraire et pas optimal dans tous les cas. Imaginons que j'aie :

a = 1;
b = 2;
....
if (a && b) { ...

si j'avais imposé une valeur canonique (1,-1, whatever) pour True, je pourrais remplacer && par & en toute sécurité, et utiliser les instructions asm correspondantes. Au lieu de ça, je suis en réalité obligé de calculer (!a | !b). Cela se paie d'une manière ou d'une autre, soit en ajoutant de la circuiterie au hardware, soit en compliquant la génération de code.  Parce que l'information structurelle n'est pas suffisante, le compilateur ne peut pas savoir si mieux vaut mettre tous les booléens sous forme canonique a leur affectation, ou s'il vaut mieux attendre le test...

Ce genre de raisonnement étant impossible avec des langages bien plus haut niveau comme le Java.. et finalement on ne sait plus du tout ce qui se passe en dessous.

Mais c'est exactement l'intérêt. Plus le langage est abstrait, plus le compilateur a d'informations sur le programme, et plus il peut être agressif. dans un langage single-assignment comme Erlang ou Haskell, le code généré mappera de la même manière des variables différentes vers des mêmes registres, mais il pourra le faire sans se soucier des dépendances dans le code, et pourra librement réordonnancer les instructions pour mieux coller au pipeline, voire parallelliser automatiquement les calculs, et de manière parfaitement sûre.

Puis en second lieu qu'un processeur contient un registre de status dans lequel il y a un flag Z (pour Zero) qui prend la valeur '1' quand le résultat d'une instruction est 0. Ce qui explique pourquoi le C (et donc en dessous l'assembleur) se comporte ainsi..

Mais même dans un langage avec un booléen fortement typé, le compilateur serait capable d'exploiter cette caractéristique...

Un contre-exemple: les x86 incluent le Parity Flag qui indique la parité des bits du dernier résultat. C'est un super gadget qui permet (par exemple) d'évaluer des polynomes dans K de manière très simple et compacte (and + test parity). Mais c'est horriblement compliqué pour un compilateur d'en reconnaitre un usage potentiel de manière fiable, alors la seule solution vraiment efficace est de se tourner vers l'assembleur...

BOFH a écrit:

La par contre, je ne suis moins d'accord

Mais faut se rendre compte de ce qui se passe en dessous et ne pas voir le PC comme une boite noire.

Mais toute la notion de portabilité se résume à ca; on n'a pas encore trouvé d'architecture universelle meilleure que toutes les autres dans tous les domaines. Même si tu maitrises à la perfection deux ou trois architectures, il y en aura 50 pour lesquelles le compilateur fera un meilleur travail...

J'ai jamais parlé de portabilité ou de maitrise de l'arch, c'était pas la "question". Ma première phrase était bien
"Reste à définir le "on". En fonction de ce qui doit être fait, tel ou tel langage est plus adapté."
Bien qu'en pratique les programmes C sont largement portés sur beaucoup d'architectures contrairement à d'autres, mais c'est un autre débat (je pense au C# made in Microsoft par exemple).

Le fait de ne pas considérer la machine comme une boite noire permet de garder à l'esprit que certaines manières de coder seront plus efficaces que d'autres. Toutes les architectures gardent énormément de similitudes.. même si ce n'est pas absolu.

BOFH a écrit:

Un petit exemple.. en C, toute valeurs différentes de 0 est considérées comme VRAI, autrement comme FAUX. (...)Mais on se pose cette question jusqu'au jour où on sait qu'un CPU ne peut pas adresser moins de 8 bits (c'est foutu pour les 2 valeurs) et donc que les variables booléennes n'ont pas de sens d'un point de vue CPU

Mais l'approche C est un choix totalement arbitraire et pas optimal dans tous les cas. Imaginons que j'aie :

Code:

a = 1;
b = 2;
....
if (a && b) { ...

si j'avais imposé une valeur canonique (1,-1, whatever) pour True, je pourrais remplacer && par & en toute sécurité, et utiliser les instructions asm correspondantes. Au lieu de ça, je suis en réalité obligé de calculer (!a | !b). Cela se paie d'une manière ou d'une autre, soit en ajoutant de la circuiterie au hardware, soit en compliquant la génération de code.  Parce que l'information structurelle n'est pas suffisante, le compilateur ne peut pas savoir si mieux vaut mettre tous les booléens sous forme canonique a leur affectation, ou s'il vaut mieux attendre le test...

Le but de l'exemple était uniquement de montrer que les choix qui ont été fait dans le C ne sont pas le fruit du hasard mais ont des raisons précises. Je n'ai jamais dis que c'était la meilleur façon de faire. Je répondais d'une certaine manière à cette remarque de tguillod:
"En C, avec le typage quand ca marche pas on a tendance à bidouiller."
Il n'y a pas de "bidouille" si on comprend comment ça se passe.. c'est tout..

BOFH a écrit:

Ce genre de raisonnement étant impossible avec des langages bien plus haut niveau comme le Java.. et finalement on ne sait plus du tout ce qui se passe en dessous.

Mais c'est exactement l'intérêt. Plus le langage est abstrait, plus le compilateur a d'informations sur le programme, et plus il peut être agressif. dans un langage single-assignment comme Erlang ou Haskell, le code généré mappera de la même manière des variables différentes vers des mêmes registres, mais il pourra le faire sans se soucier des dépendances dans le code, et pourra librement réordonnancer les instructions pour mieux coller au pipeline, voire parallelliser automatiquement les calculs, et de manière parfaitement sûre.

Puis en second lieu qu'un processeur contient un registre de status dans lequel il y a un flag Z (pour Zero) qui prend la valeur '1' quand le résultat d'une instruction est 0. Ce qui explique pourquoi le C (et donc en dessous l'assembleur) se comporte ainsi..

Mais même dans un langage avec un booléen fortement typé, le compilateur serait capable d'exploiter cette caractéristique...

La encore.. je n'ai jamais affirmé le contraire.. je dis juste qu'avec un langage de plus haut niveau t'auras beaucoup plus de difficulté d'imaginer la circuiterie qu'il y a derrière.. il suffit de compiler un programme écrit en C avec l'argument -S de gcc pour s'en rendre compte, et de comparer le code ASM généré avec le code C.



Je ne critique pas les autres langage et ne dit pas que le C est meilleur que tous les autres (bien qu'il soit meilleur que certains). Tout ce que je voulais dire c'est qu'il reste proche de la machine et donc que les choix qui y ont été fait sont des choix précis et non pas là pour emmerder le monde, et que si on est conscient des raisons (au moins en partie), il n'y a rien a bidouiller ou à trouver peu clair dans le C. Ce langage est parfaitement clair.
Et personnellement j'aime ce langage peu importe que d'autres soient meilleurs ou non. Mais finalement tout est une question de contexte dans lequel on doit développer.. si c'est pour faire des calculs de physique, alors quitte à faire du scripting via Octave.. Si c'est pour écrire un kernel, faut peut être oublier le Java et plutôt se tourner sur le C et l'ASM.
(ce qui était ma première phrase)

Skywalker13 a écrit:

tguillod a écrit:

La majorité des informaticiens n'ont pas de rapport "direct" avec le hardware.

Ce qui est dommage.. mais c'est compréhensible; je suis aussi passé par là.

Ca risque surtout de devenir de plus en plus difficile, avec l'augmentation de la complexité des systèmes informatiques. Entre les méthodes hardwares spécifiques (chemins balancés pour la crypto, arithmetique sur des trits), les pipelines superscalaires, les machines multi-processeur, la virtualisation,  qui peut prétendre maitriser la chaîne d'un bout à l'autre ?

Il y a clairement un avantage à se concentrer sur des aspects spécifiques. Dans ce contexte, les langages haut niveau aident les programmeurs métier à se concentrer sur la production de code correct et algorithmiquement efficace, et les auteurs de compilateurs à créer des compilateurs optimisants plus efficaces.

Pour ma part, je n'ai non plus pas dit que le C était peu clair ou incohérent. Je pense qu'mil restera incontournable tant qu'on aura des architectures Von Neumann; mais il se fait des choses extrêmement intéressantes sur des architectures complètement exotiques (FPGA-based, massivement parallele, etc). Mais il devrait rester une spécialité de la programmation système (et eventuellement pour bootstrapper un compilo).

Faut pas oublier qu'une partie significative des vulnérabilités de sécurité dans les programmes C répandus sont des problèmes de mémoire (buffer overflow, mémoire non initialisée.. ) ou de typage insuffisant (injection dans des strings, mauvaise validation du domaine d'entrée, ...). Les premiers sont inexistants dans les langages garbage-collectés, les seconds sont évités bien plus facilement quand le système de types y encourage le programmeur...

korbé a écrit:

Tien, d'ailleurs, vous auriez pas des livres à me conseiller pour apprendre le Python?

Salut à tous, et pas seulement à korbé

Ma formation d'électronicien s'étant terminée en 81, à l'école professionnelle on en était qu'au langage machine sur 8bits avec une horloge manuelle. Tout cela sur un micro-dauphin 6800 (pour les passionnés d'antiquités). Je vous explique pas, environ 4 heures de programmation pour lui faire jouer "Frère Jacques", et pas au clair de lune, mais dans une salle de classe particulièrement austère.

Personnellement, j'ai décider de me former en langage de programmation....quand j'ai migré sous Ubuntu.
Jusqu'à ce jour j'avais bidouillé sous vba avec ex??l,  je savais que je devrais bien m'y mettre pour de vrai, et reprendre toutes les notions de base TRÈS SÉRIEUSEMENT, d'autant plus que je voulais continuer à faire de la programmation dans mon tableur.

Vba sous Ooo, c'est vraiment pas ça, et on ne va quand même pas mélanger les torchons (win??ws) et les serviettes (entendez le très bon et très excellent LINUX) à l'aide de wine.

Quand j'ai ouvert Ooo, il me proposait: OpenOffice.org Basic - Python - BeanShell - JavaScript

Après quelques recherches sur www et un certain nombre de discutions, j'ai opté pour PYTHON. Les détracteurs de tout poil auront l'envie de me faire changer d'avis (j'en ai déjà rencontrés), mais j'ai commencé et j'irais jusqu'au bout . J'ai fait un choix et je m'y tiendrais pour ne pas me noyer dans de grandes discutions stériles qui me feront perdre un temps considérable.

Pour ce faire, j'utilise un livre qui est très intéressant, Apprendre à programmer avec Python (peut-être ce que recherche korbé). Le seul problème que j'ai rencontré à ce jour ( j'en suis à 7.1.4 Fonction avec plusieurs paramètres) réside dans les exercices. Il m'est arrivé plusieurs fois qu'il me manquait une notion de théorie. J'ai donc passé plusieurs heures sur www pour comprendre les solutions proposées par Gérard SWINNEN, mais globalement je m'en sort.

Si quelqu'un a envie de partager mon expérience, on pourrait éventuellement ouvrir un nouveau topic.

Passez de bonnes vacances de Pâques (je serais absent, et pas de wifi sur la plage). Je vais "apner" en Mer Rouge

A tout bientôt.

Dernière modification par samf (09 Apr 2009 10:09:29)