L'assassinat s'est bien passé, t'as pas eu de complications ?

Je veut bien aidé moi

Un short c'est 16 bits, un char serait encore plus économique.

0/20 pour un problème trivial d'optimisation?

Vraiment?
(Je ne dis pas que c'est un fake, mais ça me sidère)

Moi je préfère "croire que c'est un fake".

C'est ça, ou alors je pars m'isoler sur une île, de peur de me retrouver un jour face à un abruti pareil (le "correcteur").

Surtout qu'à ma connaissance, l'optimisation dans les écoles et les facs, c'est pas la première préoccupation "Faites un truc qui marche, ça sera déjà ça".

C'est pas possible ! Tu as couché avec sa femme, je ne vois que ça comme explication.

Tu as une idée des notes des autres élèves ?

Un peu raide le 0/20 juste pour de l'optimisation. SI ça marche (et qu'en plus l'IA est bien sauvage), la moyenne tout juste, ok ça se comprend, mais là tu es face à un intégriste on dirait oO

Soyons clair, ton prof est un sombre connard. Mais…

…j'ai trop entendu l'argument de la rapidité des processeurs, du coût de la mémoire pour se défendre contre l'optimisation ou l'utilisation d'un langage haut niveau. Objectivement ces arguments ne tiennent pas : vous vous plaindriez d'un redis lent, d'un nginx qui ne tient pas la charge, et il est toujours préférable de faire au mieux, non ?
Avant qu'on me réponde les classiques, je les sors ici : oui, la priorité c'est que ça marche et que ce soit lisible et oui, pour un script ou un petit programme utilisé peu souvent osef (d'ailleurs, tant qu'on y est, linkons xkcd : http://www.explainxkcd.com/wiki/index.php?title=1205:_Is_It_Worth_the_[...]).

Enfin, pour finir, je ne comprends pas l'argument du « avec la pile, la consommation mémoire est la même », quelqu'un pour m'expliquer ?

Je ne peux pas t'expliquer l'argument technique (ni même te dire s'il est juste), mais s'emmerder entre des int et des short, c'est de l'économie de bout de ficelle. Si on avait un tableau de deux cents millions de nombres a stocker, je dirais OK pour s'emmerder à mettre des shorts (mais uniquement après s'être assuré que ça ne posera pas de problème de dépassement), mais ce n'est pas le cas ici. L'optimisation, à part dans certains cas particuliers, c'est avant tout avoir un bon algorithme, pour le reste, le compilateur fera sûrement beaucoup mieux que toi.

je vois pas le rapport avec la pile, mais ajd avec les archi 32 et 64 bits, quand on utilise un short dans un programme, derrière le compilo utilise des mots de 32 bits de toutes façons, puisque c'est la taille des bus et des registres.
Pour moi l'intérêt des types plus courts (short et char) c'est quand on a des problématiques d'I/O, que ça soit dans des fichiers ou du réseau (et bien sur on parle de gros volumes)

Tu devrais tenter d'obtenir sa confirmation écrite qu'il t'a mis 0 pour ça et le montrer à d'autres professeurs ou l'administration. C'est tout à fait inacceptable.

Je le comprends, il devait vouloir voir les jambes de tes variables.

Rangez le canon à baffes, je ne suis plus là.

@danarmk : Tu sembles partir du principe que les ressources sont toujours considérables et qu'une perte de quelques octets à certains endroits est négligeable. Quid du cas d'une plateforme mobile ou embarquée ? Quid des gros volumes auxquels yomama a pensé ?
Oui ce n'est peut-être pas le cas ici, mais l'optimisation n'est pas que le choix d'un bon algorithme, c'est aussi le choix du meilleur format de données et c'est d'ailleurs ce dernier qui déterminera la méthode de traitement (sinon pourquoi s'emmerder avec des tables de hashage ou à trier ses données par fréquence d'utilisation ou ordre alphabétique ?).
C'est ici plus une question de bonne pratique (d'autogestion ?) que d'optimisation en fait, le typage du C te permet de faire presque tout ce que tu veux, moi je préfère faire au mieux. Au pire ton gain sera négligeable, au mieux tu prends une bonne habitude…

Quant à l'optimisation du compilateur, elle est souvent employée comme argument contre l'optimisation a priori mais elle n'est pas parfaite, ton code peut l'empêcher de s'appliquer et elle ne palie pas aux mauvaises décisions (il y a d'ailleurs un exemple récent à ce sujet : http://linuxfr.org/users/steckdenis/journaux/performances-des-processe[...]).

Pour finir, oui Je suis un perfectionniste et ça me fait perdre du temps, mais j'ai trop entendu « on pire on rajoutera de la RAM/des serveurs/whatnot » là où il aurait fallu consacrer du temps à prévoir le comportement du produit au lieu de simplement chercher à le faire marcher dans le plus court délais possible.

@yomama Merci de ta réponse, ça me donne une bonne raison pour remettre la tête dans de l'assembleur.

Je comprends... Très INTelligent !

C'était tellement atroce que j'ai voulu vous moinsser tous les 2. Donc du coup, je vous ai plussé.

Les gros volumes, je les ai évoqués. Pour les plates-formes embarquées, ça rentre dans « les cas particuliers » que j'ai également (certes vaguement) évoqués. Mais je ne sais pas si s'emmerder avec les shorts est une bonne pratique, vu le risque de dépassement, qu'il faut alors vérifier.

Quant au journal de Linuxfr que tu cites, le gars change un truc qui marche pas tout le temps par un autre truc dont on ne sait pas s'il est correct, puis le teste dans des conditions qui ne sont pas celles que subira le code s'il est vraiment utilisé. Et on ne sait même pas d'où sortent ces améliorations de perf (est-ce vraiment dû au compilateur ?).

Je suis pour l'optimisation, mais pas pour celle que le compilateur sait mieux faire que la plupart des humains. Et je suis aussi d'avis que passer du temps à trouver un meilleur algorithme (et ce qui va avec, à savoir une structure de données adaptée) est mieux que passer du temps à faire des économies de bout de ficelle sur un algorithme potentiellement mauvais.

Après, dans l'absolu, je suis d'accord qu'il y a des cas particuliers : embarqué, parfois programmation système, très rares cas où le compilateur rate quelque chose de significatif, etc.

Rien à voir ; j'enfile ma casquette Grammar Nazi : on dit « pallier les mauvaises décisions » et non « pallier aux mauvaises décisions ».
J'enlève ma casquette Grammar Nazi, et attend Permalien Godot la volée de bois vert.

Du moment qu'il ne demande pas à les voir en string...

Arrêtes ton char!

Seule explication envisageable pour moi : ton code est meilleur que celui proposé par sa correction. Du coup, tu mets une « correction » à sa correction.
Quant aux explications techniques, j'ai rien bit-é.

La seule explication que je voie, le correcteur s'est pris 20/0 comme l'auteur contre l'IA.

Et c'est même limite discriminatoire ... Informe l'administration.

Ceci dit, c'est qu'une note.
Les commentateurs précédents en font le drame du siècle, mais bon, ça reste un chiffre sur un bulletin, pas de quoi en faire un drame.

Une fois ces préliminaires accomplis, je vois deux solutions:
- Tu n'as pas compris (=pas voulu comprendre) les raisons du prof.
- Fake.

L'expérience montre que 99% des cas d'élèves harcelés injustement pas des profs, sont des cas d'élèves persuadés d'avoir raison, mais qui en fait ont tort.

Bon faut arrêter de faire des jeux de mots sans Array.

Ouais, sinon ils vont carrément nous jeter à la float.

En fait le prof à essayé le programme, s'est pris une branlée, a été vexé comme un pou et a cherché un prétexte quelconque pour le sacquer.

Euh, ouais, s'il veut continuer ses études, ça risque d'être problématique quoi.

Non mais sérieux, 0/20 pour une consommation mémoire? Sérieusement? Qu'ils t'enlèvent 1 ou 2 points, pourquoi pas (et encore là le motif est un peu ridicule), mais là c'est du n'importe quoi. Tu peux pas te plaindre en réclamant un autre avis par exemple?

Edit : Oups, j'ai lu un peu trop vite le motif. Alors là clairement oui, foutage de gueule au complet!

@ROB: Crois-moi, ce n'est pas un fake, j'aimerais bien avoir des preuves visuelles mais mes interros sont archivées maintenant...
@Cartman34: Malheureusement pas dans mon école !

J'ai des témoins ! (Tous les étudiants de mon groupe en l'occurrence)

À priori, je suis l'un des rares qui savait programmer en C avant de venir dans l'école, les autres étudiants ont suivi ce que la prof apprenait (Je peux garantir qu'elle n'a parlé des int qu'une seule fois: en présentant les types de variables).

Et comme en prime j'ai été "dispensé" des cours théoriques, ...

Figure-toi que j'ai été convoqué par mon professeur et un de ses collègue pour parler justement de ce dossier, j'avais deux professeurs racontant des conneries devant moi et j'ai très difficilement pu me défendre.

Par ailleurs, ces professeurs croient entre autres que la boucle infinie de type "for (;;)" est interdite par la norme C89, ou d'autres conneries encore, c'est à ce moment-là que j'ai perdu confiance dans mon école et que j'ai décroché (Ce qui m'a coûté une année, mais soyons clair, je préfère recommencer dans une autre école que de sortir diplômé de celle-ci !)

Les pauvres ! J'ai eu le même coup ce semestre avec la programmation objet : la quasi-totalité du cursus de DUT à pratiquer la COO mais obligé de supporter les conneries profondes de l'enseignant.

Tu veut dire quoi par « dispensé des cours théoriques » ?

Quand tu définis une variable, elle prends de la place sur la pile, et juste sur la pile (Raison pour laquelle c'est "gratuit").

Cependant, la pile est allouée au début du programme, et garde sa taille (1mo par défaut sous Windows), qu'on utilise des short ou des int.

Et comme le cours de C était encore loin des allocations dynamiques, nos programmes ne pouvaient utiliser que des variables sur la pile.

C'était juste pour souligner à quel point c'était crétin d'utiliser des short pour économiser de la place, parce qu'excepté dans une structure ou dans un tableau avec beaucoup de cases, ça ne sert à rien.

(Et en prime, le processeur prends techniquement plus de cycles pour les traiter car il calcule en 32/64bits, et doit donc appliquer des opérations de masquages).

Mon post avait pour objet de dire que justement, on met pas 0 pour de la conso mémoire.
Notre ami posteur avait une très haute opinion de son projet, et a eu 0.

Personne n'était la pendant l'explication du prof. Il est allé dans le bureau persuadé de s'être fait voler, et a entendu ce qu'il voulait entendre, a savoir que son projet était parfait, et qu'il s'était fait saquer pour rien.

Moi je dis que ce n'est sans doute pas ce que le prof a dit.
C'est normal, on entend ce que l'on veut entendre, et quand on a mis du coeur dans un projet, ça fout les boules de se prendre une bache. Et pour la suite des études, c'est pas une note qui va compromettre ta vie entière hein...

Pendant mes études, je m'en suis pris des toles. Je pensais aussi m'être fait voler, que le prof était un incompétent, qu'il devrait être viré sur le champ, qu'il fallait avertir l'administration, le ministère, et l'ONU sans perdre une seconde. Avec le recul, j'ai fait de la merde, j'ai pris une bache, ça m'a pas empêché de vivre.

Et après ils vont avoir les bool.

Allez, quelques précisions pour tous mes amis !

Ça n'est pas un fake, voici l'énoncé en PDF: http://pdf.lu/i2sL
Et mon code source: http://pastebin.com/KgaXLMMe (Il n'est pas parfait et j'en suis conscient)

Concernant mon professeur, ou plutôt ma professeur, elle est assez âgée (Dans moins de dix ans, elle est retraitée), et a connu le temps des processeurs 16 bits. Le problème c'est qu'elle n'a pas réussi à sortir de ce temps.

Comme l'indiquera peut-être un autre PEBKAC déjà envoyé, les cours de C de mon école comportaient pas mal de références au 16 bits, et très peu au 32 bits.
Je pense d'ailleurs que ça a été un choc pour mon professeur quand les int ont changé de taille "commune" pour avoir 32 bits au lieu de 16, un choc dont elle ne s'est sans doute pas remise.

J'ai beaucoup de reproches à faire à ce professeur, complètement fermé d'esprit, qui a au moins quinze ans de retard. Et c'est à l'image de l'école ! (Pour vous donner une idée, en cours de PHP on utilisait du mysql_* pour la base de donnée, avec une version PHP 5, ils vont avoir une surprise quand ils passeront à PHP 6...).

Donc pour la petite histoire j'ai été convoqué le lendemain du jour où j'ai rendu ce code, par mon professeur, avec un de ses collègue et la prof de BDD qui passait dans le coin.

Il faut savoir que les int ne sont pas le seul reproche qu'ils m'ont fait, j'ai osé utiliser des "break", des "continue", même une boucle infinie, qui n'étaient pas interdits, juste qui n'avaient pas été appris, mais il faut croire qu'ils n'aiment pas les autodidactes. (Pour ceux qui se posent la question: Oui j'ai déjà raté une "interro" uniquement à cause des int, sauf que ça n'était pas une interro mais mon examen de Janvier !).

Mon école vénère Linux, le truc drôle c'est quand je leur ait dit que le code source de Linux contenait des "break", des "continue" et des boucles infinies aussi, ils m'ont dit que je ne pouvais pas comparer.
Ah bon ? J'aimerais bien savoir pourquoi, parce que certaines de mes fonctions sont plus compliquées que certaines fonctions de Linux.

Mais ils ne m'ont pas laissé parler, ils m'ont interrompu sans arrêt, même la prof de BDD s'y est mise, je me souviendrais toujours de ce qu'elle m'a dit "Si vous aimez tant Linux, vous irez travailler chez Linux !")

Bref, je vais envoyer un courrier au directeur pour dénoncer ces problèmes, et tant pis pour lui s'il m'ignore, moi je ne remets plus les pieds dans cet établissement !

PS: Un truc drôle qui me revient en tête, ils prônent l'optimisation maximale, mais comme ils interdisent le break, il faut tester deux conditions dans la boucle plutôt qu'une seule, il faut croire qu'ils se préoccupent de ce qui les arrange...

PS2: Le pire c'est que c'est l'une des écoles les plus réputée de Belgique dans son domaine.
Amis belges: Apprenez par autodidactisme, je vous en supplie, les écoles c'est le mal pour apprendre la programmation.

Après deux cours théoriques, en ayant un peu marre de réapprendre ce que je savais déjà (Surtout qu'elle disait des conneries et que j'ai eu bien du mal à me retenir de ne pas lui faire remarquer), j'ai été lui demander, hors du cours, s'il était possible que je passe un test (Genre l'examen de l'année passée) pour prouver mes compétences et être dispensé du cours de C.

Pour rester poli, elle m'a traité comme de la vulgaire matière fécale, là où je suis resté bien poli, et m'a dit "De toute façon vous n'êtes pas obligé de venir en cours de théorie, seulement en laboratoire".

Et donc en dix mois, elle ne m'a revu que deux fois au cours de théorie (Je venais pour voir où ils en étaient).

Faut doser hein, j'ai passé à peine dix heures sur mon programme, pas deux mois.

J'étais juste fier d'avoir réussi avec succès à écrire un opposant dont l'algorithme vient de ma propre imagination, j'avais pas besoin qu'on me jette des roses (Déjà le fait que presque personne dans mon groupe n'ait pu battre mon "IA" était suffisamment valorisant).

Plus de détails juste en dessous.

Il faut tout de même faire attention aux "break" et "continue". Un break dans un for est à éviter (c'est pas fait pour ça, un for ayant certaines propriétés théoriques), et c'est inélégant dans un while, pour lequel on peut toujours trouver une solution (quitte à mettre une variable booléenne, niveau lecture de code source ça sera déjà plus lisible avec la bonne nomenclature).

Mais les réponses sont quand même bien merdiques ^^

Edit : Par contre pour ton IA, tu as fait du branch & bound?

C'est sujet à débat et j'en suis conscient.

Mais imagine-toi chercher une valeur dans un tableau de dix entrées, moi je ferais un for sur les dix entrées et je ferais un break pour sortir de la boucle une fois la valeur trouvée, je ne vois pas en quoi c'est malsain (Et difficile de faire plus rapide, même si à ce niveau-là, ça n'est pas pour quelques cycles qu'on va s'inquiéter).

Bon, c'est sûr qu'il faut pas en abuser non plus, mais y'a des bons cas d'utilisation (Mon école ne semble voir les choses qu'en blanc ou en noir).

Pourquoi ne pas faire une boucle while avec une condition "boucler jusqu'à trouver la valeur attendue"?

En fait, en cherchant bien, le caractère malsain de la chose est liée à la même raison qui nous pousse à ne pas utiliser goto : Il s'agit d'un saut d'étiquette, plus précisément vers l'instruction se situant juste après la structure de boucle. Pour des raisons de propreté, et également au niveau de la compilation (je ne suis pas sûr, mais tu peux louper certaines optimisations en faisant cela), il vaut mieux avoir une condition qui gouverne la boucle.

defunes, évidemment que la vie continue après, c'est pas ce que j'ai voulu dire. Simplement, s'il avait l'intention de poursuivre dans une formation sélective, qui regardera donc le dossier, se prendre une tôle ça peut être vraiment très chiant. Après on va pas non plus faire une dépression, c'est sûr...

Vous ne prenez en compte que l'économie de mémoire. Mais n'oubliez pas l'économie de temps d'accès : en utilisant un type collant au mot machine de l'archi utilisée, les temps d'accès à la valeur seront réduits, même si la consommation mémoire en prendra un coup. On en revient au bon vient débat rapidité vs. économie de mémoire.

Dans une bonne partie des cas je suis d'accord, mieux vaut restructurer son code qu'avoir ce genre de saut, sauf quand c'est bien utilisé et assez clair.

Quel est le plus clair pour toi entre

for (int i = 0; i < 5; ++i)
 {
     if (val[i] == x)
    {
         pos = i;
         break;
     }
 }

et

for (int i = 0; i < 5 && cont; ++i)
 {
     if (val[i] == x)
    {
         pos = i;
         cont = 0;
     }
 }

Comme je l'ai dit c'est sujet à débat, mais moi mon choix est fait.
Et en parlant d'optimisations, c'est encore à voir au cas par cas, mais ici on exécute une itération de plus de la boucle qu'avec le break. (Je sais qu'il ne s'agit que de broutilles, mais dans ce sera le cas avec ou sans break)

Je confirme hélas =/

Pour moi, la principale preuve d'incompétence m'est apparue dans l'énoncé : il est en Comic Sans

Attention attention, je suis dans la classe de ce cher "Lynix", et il s'avère qu'il est juste dégoûté de s'être fait remettre en place quand il la ramenait trop avec ses compétences (y'a la façon de le faire, et il l'a toujours fait de manière hautaine).

Il se la joue détaché sur la situation mais les faits sont là : il continue à poster ses anecdotes (au pire fausses, au mieux tronquées) plusieurs mois après les faits et après avoir changé d'école.

Mon cher ami ici présent pense en effet que je ne suis que dégoûté, et je dois avouer que sur l'instant j'étais vraiment dégoûté, au plus profond de mon être.

Est-ce que c'est le cas aujourd'hui ? Certains aiment penser que oui, moi j'ai juste voulu poster cette anecdote, qui ne m'atteint plus aujourd'hui pour la simple et pour la bonne raison que je me suis trompé dès le début d'option, je n'ai jamais voulu faire de la gestion de base de donnée !
J'aurais donc perdu un an de toute façon.

Je me sens assez indifférent maintenant par rapport à tout ça, je vais envoyer un courrier au directeur simplement en espérant que les choses changent pour les futurs étudiants, pour moi ça ne changera rien.

Quant à la fausseté de mes anecdotes, je n'y ai pas apporté des précisions pour rien !
La vérité est bien que ce n'est pas ce dossier que j'ai raté pour avoir utilisé des int, mais mon examen de Janvier, comme je le précise plus haut.

Il faut dire qu'après ces mois, j'ai un peu mélangé, mais au fond je ne vois pas ce que ça change (Sinon la gravité de la situation, mais ça n'est pas le point ici).

Arrêtez les jeux de mots pourris, sinon je vous envoie une booldefeu dans la face.

Vous voyez, chers étudiants, voilà pourquoi une bonne orthographe est indispensable. Le sujet peine à se faire comprendre en bredouillant quelques mots dans un dialecte que lui seul maîtrise, et de se fait est complètement isolé du groupe, rejeté par certains et juste ignoré par d'autres.

Les chercheurs qui l'ont accueillis ici travaillent jour et nuit pour essayer de communiquer avec lui, mais sans succès. La grammaire aléatoire de l'individu a jusqu'à présent mis en échec toute tentative d'élaboration d'une procédure de traduction, malgré les outils technologiques qui sont aujourd'hui à notre disposition, ce qui fait que certains considèrent que nous sommes pour la première fois réellement en présence d'une forme de vie complètement déconnectée de notre monde.

Maintenant nous nous apprêtons à rencontrer monsieur G. Nazi, directeur de ce centre de recherche, qui va répondre à toutes vos questions sur le fonctionnement du laboratoire.

/me envoie une boule de feu vers Clem

<hors-sujet> Sur le coup j'ai lu Lincolnuaubataillon, et je me demandait pourquoi l'ancien président des États-Unis se déshabillerait pour rendre visite à son armée. On va rejeter la faute à l'heure qu'il est au moment ou je me connecte. </hors-sujet>

Et si votre groupe a eu 0 pour une erreur de type mal adapté (j'ai encore du mal à y croire au moment où je tape cette ligne), quelles étaient les notes des autres groupes ?

Balance le nom ;) ça pourra aider certains nouveaux bacheliers ;)

Exactement ce que je disais plus haut. Je suis autodidacte, je connais mieux que les profs, je connais mieux que tout le monde, et j'ai forcément raison because j'ai appris sur le SdZ.

Les profs ont voulu te rapeller ta place, et je crois que ça te servira bien dans ta vie future, parce qu'avec tout mon respect, tu m'a l'air d'avoir une très haute opinion de toi même et de tes compétences, et d'avoir un rapport assez dur à la critique...

Je pense que tes profs ont voulu de rendre un service, parce que si tu continue de te la jouer comme ça avec un patron, tu risques de pas garder un job très longtemps...

(J'ai rien contre toi personellement, je te connais pas, mais je pense qu'en 5 posts ici, j'ai compris le calvaire que tu as infligé a tes profs, "moi jsuis autodidacte, je connais mieux que tout le monde, je connais mieux que vous, laissez, je vais vous apprendre". Bah un jour, la tête a claques, elle prend une claque.)

Ma parole, j'ignorais que j'avais un psychologue attitré !

Je ne dis pas ne pas avoir commis d'erreur, tant dans mon comportement que dans ma façon de dire les choses (Même si je suis toujours resté poli vis à vis de mes profs, qui eux ne peuvent pas en dire autant).

Je pense que tu fais vite de résumer la situation, je n'ai jamais dit connaître mieux que tout le monde et mon expérience est loin de se limiter au SDZ, comme tu dis.

Quant à mes compétences, en effet j'ai du mal qu'on les remette en cause sans raison.

Ce que je déplore est que le programme est daté de plusieurs années et que certains de mes profs sont réfractaires au changement (Base de l'informatique).

Attention, tous mes profs n'étaient pas comme ça, je n'ai eu le problème qu'avec ma prof de C et mon prof de PHP, d'autres ont reconnu, en privé du moins, certains problèmes dans l'école.

La situation est bien plus compliquée que tout ce que tu as pu en dire, comme mon "camarade" d'ailleurs, parce qu'à ce que je sache j'étais seul avec mes professeurs lors de ma convocation, et je me suis fait même menacer ce jour-là !

J'ai eu le support d'autres professeurs d'informatiques, pas du même établissement, mais par exemple mon ancien professeur d'informatique, qui m'a eu pendant trois ans, m'a défendu dans cette affaire, et crois-moi, il a dû affronter la même personnalité que mes profs de cette année (Ou alors j'ai un sérieux problème de dédoublement de la personnalité).

Le problème dans cette école c'est qu'ils veulent vous faire entrer dans un moule, et si t'es autodidacte tu as bien plus de mal à t'y faire.
Est-ce qu'un programmeur doit faire du code à la chaîne, sans jamais remettre quoi que ce soit en question ? Je pense que le job d'un programmeur est de penser, pas de suivre aveuglément ce qu'on lui dit.
Après, chaque entreprise possède une norme, et je n'ai aucun mal avec ceci quand on a un minimum de justification.
Par exemple, j'ai été demander pourquoi nous faisions du C89 à la place de C99 ou de C11 à un autre professeur, qui m'a expliqué qu'il était plus facile de passer du C89 aux autres normes que l'inverse, et ça m'a suffit !

Bref, tu fais un peu vite de me ranger dans une catégorie je trouve ...

Le plus clair, ça serait un do ... while, pas un for inutile comme ici.

De mon point de vue, là, tu fais juste une mauvaise utilisation de for. Donc de ce fait, utiliser du sparadrap pour rendre plus clair quelque chose que tu obscurcis par utilisation de fonction non adaptée, c'est un peu incohérent.

Je veux bien que chacun ait ses petites habitudes de code, mais utiliser un for et y mettre un break, ça me semble être une hérésie. o/

Ralala, vous êtes vraiment des boulets hein !

C'est également ce que je me suis dis en lisant le pebkac !

Je ne vais pas commettre la même erreur deux fois, je pense que mettre le nom de l'école en public pourrait porter atteinte à sa réputation, et donc à des amis qui suivent ce cursus.

L'école ne mérite pas sa réputation actuelle, c'est un fait, mais je trouve injustifié de la démonter pour seule base de l'avis de certains profs et d'une mentalité dépassée.

On verra après mon courrier au directeur, si ce sont juste des profs ou si l'école entière est contaminée.

Mais pour ceux qui cherchent une école en Belgique et qui souhaiteraient éviter de tomber sur celle-là, n'hésitez pas à me demander ça par email, mon adresse email commence par mon pseudo, est suivie par 680 puis par un at avec le domaine de mail de Google en version abrégée.

(Si les bots spammeurs arrivent à décortiquer mon email, c'est que Skynet est proche !)

Et comme tu l'as dit avant, autant utiliser char dans ce cas là.

J'avais un prof qui, quand un élève sortait un meilleur code que celui de la correction (comme dit plusieurs fois plus haut, le but n'est pas du tout de sortir le best code ever, donc la correction n'était pas extraordinaire), le prof utilisait cette correction l'année suivante.

Comme quoi, il y a des gens qui comprennent l'humilité.

Le problème c'est aussi de se faire remettre à sa place par une personne incompétente. Fais pas style tu le prendrais bien...

Beaucoup d'enseignants détestent que les élèves en sachent plus qu'eux, surtout dans une filière où il y a tout à apprendre comme l'info.

Le plus clair pour moi, c'est ça :

i = 0;
while(i < 5 && cont){

if (val[i]==x){
pos = i;
cont = 0;
}
}

J'ai retranscrit tel quel, mais t'as même pas besoin de "pos", étant donné que tu pourrais réutiliser le i

Hé bien, c'est une hérésie! Dans une formation qui se respecte, on est censé te l'apprendre, ça!

(No offense Lynix) neeko, là en l'occurence il n'a pas l'air d'en savoir + que les profs. L'autodidactie est très bien (je le suis moi-même), mais encore faut-il les bonnes sources. Manifestement ici, ça ne doit pas être le cas, puisque ne pas utiliser break avec une boucle for fait partie de l'élémentaire même (quand tu fais de l'assembleur, tu le comprends direct en fait).

Mais après ce n'est pas grave hein, on a tous débuté et tous cru faire bon quand on ne le faisait pas.

Edit :

"Est-ce qu'un programmeur doit faire du code à la chaîne, sans jamais remettre quoi que ce soit en question ? Je pense que le job d'un programmeur est de penser, pas de suivre aveuglément ce qu'on lui dit."

Ca dépend de quoi tu parles. Un développeur sortant d'un bac+2/bac+3 (faudra faire l'équivalence belge)? C'est comme ça que ça se passe oui, en SSII en tout cas. A partir du master/école d'ingénieur, c'est quand même moins le cas. Si ça t'intéresse de penser, intéresses-toi à ce qui se fait dans disons, 10% de l'informatique, notamment la recherche opérationnelle par exemple. Là t'inquiètes pas, tu n'auras pas fini de penser !

Pas une intégriste. Une shortégriste.
"est déjà très loin"

J'ai pas tout suivi, c'est quoi l'objet de votre discussion?

Je ne suis pas expert du C (ni de l'assembleur), mais en quoi faire un break avec une boucle for est si mal que ça ?
Je veux bien croire que, sauf utilisé avec extrême parcimonie, ça complique la lecture du programme, mais dans son cas, il n'en a utilisé qu'un seul (et deux continue), et sans que ça devienne un code spaghetti. Même s'il aurait probablement été possible de faire un peu plus joli, il n'y a pas de quoi faire une crise, et pas de quoi mettre 0.

Et tu fais quoi quant aux autres affirmations douteuses de la prof ?

Désolé de te contredire, mais ce que tu dis est faux. La pile n'est pas seulement alloué au début de programme, sinon tu ne pourrais pas faire d'appel récursif de fonction et elle ne porterais pas le nom de pile.

La dernière phrase m'a bien fait rire... T'inquiètes pas ton compilateur C et l'architecture actuelle ne perd pas de temps sur les short.

de ce fait*
accueilli*

Déjà, en algorithmique théorique ça a son importance : Si tu veux faire de la vérification formelle, respecter toutes les propriétés du for (à savoir arrêt à la condition en rapport avec un changement de valeur dans la variable par incré/décrémentation) te permet une certaine garantie dans la preuve. Prouver une boucle while (parce qu'un for avec un break dedans, ça finir par se prouver comme un while) est tout de même plus ardu, et je ne compte pas les problèmes inattendus pouvant survenir à l'exécution.

Maintenant au niveau pratique, il s'agit d'un arrêt inattendu de la boucle for, cela demande des opérations supplémentaires pouvant affecter les performances (le détail, je ne me souviens plus par contre).

Et c'est effectivement beaucoup plus naturel de lire ça dans un while, que dans un for. Ok, dans certains grands logiciels, les développeurs l'ont fait, il n'empêche qu'il s'agit quand même d'une faute (puis tu sais, si les logiciels étaient rigoureusement conçus, avec vérif formelle et tout le bazar, les bugtrackers seraient peut-être moins remplis du coup).

Edit : Et je me répète, ça se rapporte à un saut d'étiquette forcé, c'est le même problème qu'un goto!

@Lynix : Il y a, sur ce site, une communauté de vieux réacs paternalistes (cf http://www.pebkac.fr/pebkac/7014/). Je ne peux que te conseiller d'éviter de perdre ton temps à leur répondre.
Bien entendu, et c'est là tout le paradoxe, les laisser parler sans leur répondre c'est leur laisser l'espace et « consentir », du coup je peux pas non plus me taire. Mais sans déconner, un jour, 'faudra essayer.

@defunes43 : Comme il y a peu sur Framablog, essayons l'analogie : « Exactement ce que je disais plus haut. Je suis enseignant, je connais mieux que les élèves, je connais mieux que tout le monde, et j'ai forcément raison because j'ai appris ça pendant mes études. ». C'est tout aussi ridicule.

« Les profs ont voulu te rappeller ta place, et je crois que ça te servira bien dans ta vie future »
Je vomis ta vision du monde. Il est un être humain avant tout, que l'un soit enseignant et l'autre élève ne veut rien dire de plus que le devoir pour l'un de transmettre son savoir au mieux et pour l'autre de faire de son mieux pour l'assimiler. Ce savoir ne touche qu'à l'informatique, si un prof est évangéliste, je n'attends pas de lui qu'il me transmette sa foi, alors ce que tu crois nécessaire à la vie en société, garde-le pour toi.
Sa place est celle de l'étudiant ayant rendu un bon devoir et de l'être humain responsable ayant tenté d'engager une conversation avec un individu déraisonnable. Il lui servira, dans sa vie future, d'apprendre à se faire respecter et à quitter un poste (ou une école) où on va jusqu'à lui nier le droit à une note décente pour un code fonctionnel répondant à l'énoncé. Ou doit-on comprendre qu'il serait juste de ne pas payer un développeur web parce que c'est pas exactement la teinte de bleu que t'avais en tête pour les liens ?

« Je pense que tes profs ont voulu de rendre un service, parce que si tu continue de te la jouer comme ça avec un patron, tu risques de pas garder un job très longtemps... »
Effectivement, pebkac.fr est rempli de patrons victimes de la bêtise de leurs employés (demande à Aaargh!!!). Penser les relations patrons-employés comme un rapport de strict domination c'est juste nier l'individu employé, alors penser que ce système est normal et qu'il faut le respecter c'est juste stupide en plus d'être dangereux. Un employé est une personne recrutée pour apporter son savoir et son expérience dans son domaine de compétence, ce qui concerne aussi le gérant. Il a le droit et le DEVOIR d'exprimer son opinion sur les problématiques liées à son domaine dans l'entreprise, sinon il ne remplit pas sa fonction et si le patron le vire pour ça, c'est qu'il ne remplit pas la sienne.
Ce que tu appelles « se la jouer » c'est savoir ce que l'on vaut et surtout ce que l'on dit, si un patron empiète sur ton domaine d'expertise en t'imposant de faire quelque chose de stupide, il est de ton devoir de refuser. Et si un patron te vire pour ça, tu pourras attendre les prud'homme avec le sourire.
Fort heureusement il y a, parfois, en dehors de l'entreprise, des gens raisonnables et de bonne volonté dont on a pas à subir la connerie comme une fatalité.

@but2ene : la pile (stack) est en réalité un bête tableau de mots (32 ou 64 bits) qui sert à sauvegarder (principalement) les contextes des appels de fonctions (dont leurs variables statiques), en utilisant l'ordre LIFO (dernier entré, premier sorti). Ce mode de fonctionnement est géré par un simple pointeur sur l'altitude actuellement utilisée. Il permet d'appeler des fonctions de la manière que nous connaissons, y compris récursives (ce qui ne fait aucune différence par rapport à une fonction normale en vérité). Si la taille utile de la pile change au cours de l'exécution, sa capacité (la taille du tableau), elle, est fixée au lancement du programme (d'où la possibilité de faire un "stack overflow" si trop de fonctions sont appelées et que la pile est pleine).
En espérant avoir aidé :)

La dernière fois que j'ai vu une foire d'empoigne pareille ça parlait d'héritage...

À part 2-3 broutilles, ton code est nickel... Et bien commenté en plus.
Petits détails :
playerId = (playerId+1) % 2; est équivalent à playerId = !playerId; ("roooh le râleur"... certes)
A priori la structure de données Game est unique, donc pourrait être globale de type anonyme et ne pas être passée en paramètre (mais à mon avis ça chatouillerait encore plus tes profs...)
Et, lorsque ton IA décide au hasard entre plusieurs colonnes possibles, la répartition n'est pas équiprobable (elle a une plus faible chance de jouer la colonne la plus à gauche à partir de trois possibles). Mais je doute que ta prof l'ait réalisé de toute manière...
Quoi qu'il en soit, bon courage, d'expérience une prof incompétente et têtue c'est difficile à supporter...

C'est bien tu a étalé ta confiture.
Sinon bravo, une pile est un tableau ...
Sauf que le tableau contient aussi le tas, les lib et les entrés sorties.

http://ilay.org/yann/articles/mem/map.2.png

Même si t'as alloué toute la mémoire dispo tu peux toujours la saturée...

Je crois que tu t'embrouiles But2ene : Il y a une pile par Thread, donc une pile est créée en début de processus, puis une nouvelle pile est créée pour chaque nouveau Thread au cours de la vie du programme...

Le concept de la pile est de, justement, empiler les variables et pointeurs lors d'appels de fonctions. Typiquement, lors d'un appel récursif, la pile va se remplir jusqu'à la fonction feuille, puis se vider lorsque l'on remonte vers la racine. C'est aussi pour cette raison qu'un appel récursif infini génère un "Stack overflow" (débordement de la pile).

Une variable a courte durée de vie peut-être déclarée sur la pile, ce qui est plus rapide que de faire une réservation de bloc mémoire juste pour quelques octets. Sur ce point Lynix a raison.

Shit, j'ai oublié l'instruction i++, j'aurais dû me relire!

Au travail, je ne permet le break à mes programmeurs que dans le cas où la lisibilité est bonne. Ce qui est généralement une fonction très courte avec une seule boucle FOR : On entre dans la fonction, on fait sa/ses boucles avec le test, et on sort dès qu'on trouve.

Sinon ton code est propre. Les fonctions sont un peu longues. Et j'ai cru voir un return au milieu d'une fonction, ce qui est a éviter.

Il est clair que ce 0/20 est une vengeance de personnes avec 20 ans de retard. Ayant déjà eu affaire à ce genre de personnes, je compatis. Il est impossible de leur faire entendre raison. Comme ils sont plus âgés que toi, ils restent persuadés être plus compétent. Tu pourras dire tout ce que tu veux, ils sont juste trop obsolète pour comprendre.

Prôner l'optimisation est une hérésie ! Il ne faut jamais faire de l'optimisation présomptive. Il faut juste s'atteler à faire un code qui fonctionne, et éviter les algorithmes à complexité exponentielle dès qu'il y a un risque de gros volume de données. C'est tout !

Tu as bien fait de changer d'école.

@OzoneGrif : en quoi ça contredit ce que je dis ?
Une variable sur le tas est allouée indirectement. Donc c'est normal que ça aille plus vite sur la pile qui est directe.

Le stack overflow est quand la pile rencontre le tas. C'est juste écrit dans le manuel.
cf schéma.

Si celui-ci ne vous plaît pas prend celui-là.
http://www.dirac.org/linux/gdb/02a-Memory_Layout_And_The_Stack.php

"Sur ce point Lynix a raison." Heu tu viens d'expliquer le contraire de lynix, mais ce n'est pas grave ;) Chacun comprend ce qu'il veut.

Je dis juste que l'allocation dans la pile n'est pas gratuite.

"lorsque ton IA décide au hasard entre plusieurs colonnes possibles, la répartition n'est pas équiprobable"

Ben en fait, dans un P4, un Branch & Bound est tout à fait réalisable (ça prendra pas 1000 ans si l'élagage est bien fait). Mais parfois, dans un ensemble de solutions immense, on a tendance à utiliser des méthodes stochastiques. Celle de Monte-Carlo (me corriger si je me trompe de nom) par exemple, où dans un parcours de l'arbre, suivant certaines règles, tu choisiras un noeud "au hasard", jusqu'à effectuer un reset à la racine.

Parait que ça marche plutôt bien, pas testé personnellement cela dit.

Ozone, je suis d'accord avec toi, mais en quoi transformer un for en un while te prendra énormément de temps, au juste?

Edit : "Il faut juste s'atteler à faire un code qui fonctionne, et éviter les algorithmes à complexité exponentielle dès qu'il y a un risque de gros volume de données. C'est tout !"

Je rajouterais que dans certains cas, la méthode conçue avant peut réellement faire une différence! (Par exemple, adopter un autre point de vue sur le problème peut être plus intéressant que de choisir la meilleure fonction de tri...)

D-z : Je crois que tu confonds mot mémoire et taille de registre.

Lynix, je suis désolé mais tu sais pas utiliser une boucle "for". Certes ton code est correct, toutefois on utilises un for quand il y a un nombre défini depuis le départ d'itérations à faire. Si tu sort du cas :
`for(i = 0; i < CONSTANTE; i++)
{
//code sans break pour sortir de la boucle
}`
alors oui ça peut être correct, mais ça montre que tu aurais tu utiliser un `while`à la place.
Si tout ton projet est comme ça (j'avoue ne pas avoir lu), et si tu fais le prétentieux face aux profs style "je suis trop bon, vous racontez n'importe quoi, je ne viens plus à votre cours", forcément ils ne vont pas apprécier.
Après si ça marche, ça mérite quand même plus que 0, ils auraient pu au moins mettre quelques points. Sinon c'est vrai que les enseignants en informatique ne font pas toujours l'effort de se mettre à jour, mais bon je ne pense pas que ton 0 était du uniquement à cette erreur de short/int.

@Sonny: Il existe certains cas où utiliser un break évite tout une gymnastique de IF et de variable booléenne, dans le cas où le break améliore la lisibilité, pourquoi ne pas l'utiliser. Par contre un break en plein milieu d'une fonction longue et complexe n'est, généralement, pas une bonne idée. Car on ne sait jamais vraiment quel code sera ou pas exécuté.

Perso j'ai eu un prof qui rajouttait même des points pour des solutions meilleures que la sienne (genre tu pouvais avoir 12/10)... Un cas marginal certes mais qui méritait d'être relevé.

Ben justement il me semblait que le int sur processeur 16bits était de 16bits et de 32bits pour les 32bits.
Donc pour elle short ou int ça aurait du être pareil. Puis ils ont craqué ton code passe le C89.

Mais si ça peut te rassurer, chez nous si tu compiles tu aura quelques points voir 10 en première année.

Après on peut t'attaquer sur le style :
Le main fait un peu à la va-vite, tu pourrais faire jouer deux humains ou deux IA.
La vérification des 4 alignés peut être plus simplifiée.
Mais je doute que ce soit le but.

Je pense qu'ils pensent que tu as pompé le code sur le net. D'où le 0.

Pour info, ma fameuse boucle for était une boucle infinie, que j'écris toujours sous la forme du for (;;), parce que le while (1) provoque un warning (idiot) du côté de Visual.

Et une boucle infinie sans break, je crois que c'est un plus gros problème encore que ce que tu viens d'énoncer.

Utiliser une boucle for uniquement quand le nombre d'itérations à faire est connu d'avance est une idiotie (Avec tout le respect que je te dois), si des optimisations ne peuvent plus être appliquées, alors le code généré par une boucle while et un for devrait être identique.

Dès lors, tout devient une simple question de clarté du code, et IMHO le for est dès lors plus représentatif de la tâche à accomplir.

Mon objectif était d'écrire une boucle infinie car je ne voyais pas de façon "propre" de faire une boucle, à cause des messages à afficher en cas de condition fausse.

Pour moi une boucle infinie devrait toujours s'écrire "for (;;)", c'est celle qui cause le moins de problèmes car c'est une structure qui ne saurait être utilisée dans un autre but, contrairement à un while (1) où le compilateur peut te prévenir parce que ta condition est toujours valide (Comme si tu avais mis while ('a' == 97).

Pour avoir regardé ce comportement d'un point de vue bas-niveau, la pile simplifiée c'est comme ceci :

static char stack[1000000];

Dès lors, chaque variable possède une adresse sur cette pile, attribuée à la compilation.

int a = 5;
 int b = 4;

devient donc égal à

((int*) stack[0]) = 5;
 ((int*) stack[4]) = 5;

(Désolé je n'arrive pas à comprendre comment rajouter le déréférencement sans mettre le code en italique avec le Markdown)

D'où le seul et unique coût de l'affectation, une variable sur la pile est gratuite, comme expliqué plus haut.

Bien sûr, tout ceci n'inclut pas l'espace réservé à l'appel aux fonctions et autres trucs, mais le principe est le même.

C'est aussi la raison pour laquelle, quand on debug, il est impossible d'arrêter le débugger sur une déclaration de mémoire sur la pile : Parce qu'il n'y a aucune opération à ce niveau (Ça n'est possible que si affectation il y a, car la seule opération effectuée est alors l'affectation).

Oh et au sujet du coût du short:
http://stackoverflow.com/questions/1851468/usage-of-short-in-c

Je ne vois pas en quoi une boucle infinie sans break est un problème : Quand tu quittes la boucle, il y a une raison (fermeture fenêtre utilisateur, et j'en passe). Et de même, une boucle évènementielle ne s'écrit pas avec un for.

Question : Avez-vous eu de l'informatique fondamentale? (Vraie question, je ne connais pas ton école)

Non mais, à la limite, un break dans un while, je peux comprendre (effectivement il peut y avoir trop de conditions), mais dans ce cas on évite le for. Déjà, c'est pas lisible dans le sens où quand l'on voit un for, on ne s'attend pas à un break (quand on est attaché aux propriétés théoriques, c'est le cas). Puis on utilise un for quand on connait à l'avance le nombre d'itérations (dépendant toutefois d'une éventuelle taille ou autre donnée numérique fixée ou calculée à l'avance dans le code).

Je ne dis pas que cette pratique fout en l'air le logiciel, j'ai déjà vu des codes sources où c'est utilisé. Ce n'est juste pas approprié (et franchement, dans le domaine de la spécification formelle, on ne ferait jamais une chose pareille, ça je peux le garantir)

Bon, effectivement une boucle while avec break, ça peut se comprendre (si condition trop complexe). Mais une boucle for avec un break, définitivement je n'adhère pas du tout, vraiment.

Ce n'est pas une boucle for, elle n'a rien d'une boucle for sinon que le mot-clé, c'est une boucle infinie que je créé avec un for (;;), pour des raisons expliquées plus haut.

Sinon, tu parles d'une boucle infinie sans break, et comment tu la quittes alors ? Parce que détecter la fermeture de la fenêtre par l'utilisateur est une chose, couper la boucle en est une autre.

Ou alors tu considères qu'on tue le processus directement, et ça je doute que ça soit vraiment propre...

"Effectivement, pebkac.fr est rempli de patrons victimes de la bêtise de leurs employés (demande à Aaargh!!!). "

J'ai dû rater un épisode...

Soyons honnête, je ne connais rien de ce que tu as cité (à part la définition générale de la méthode de Monte-Carlo) ^^
Cependant, pas besoin je pense de sortir l'artillerie lourde : stocker les indices de colonnes candidates et effectuer un tirage dedans est peut-être sous-optimal, mais pour 7 colonnes maximum ça ferait l'affaire.
Sur ce, je vais me documenter sur le Branch and Bound, merci :)

Je n'ai rien compris à ton truc. J'ai un tableau static qui n'est pas dans la pile, mais dans le segment BSS. Lui par contre est définit à la compilation.
Puis tu mets deux variables dans la pile suivie de deux affectations dans le tableau que tu a alloué dans le BSS ?
Quel comportement t'es sensé montrer ?

Certes quand il fait grossir la pile il fait d'un block et mets un offset sur chaque variable. Mais elle n'est clairement pas définie à la compilation.

Comme je te disais, les adresses sur la pile ne sont pas calculées à la compilation sinon tu ne pourrais pas faire d'appel récursif. Mais à l'exécution de la fonction. Tu peux même allouer sur la pile avec alloca. Ça se fera dégommer après le return.

Ben en fait le x86 a les instructions 16Bits donc si tu veux charger un short efficacement tu l'utilises. Le mask sera fait en hard en un cycle (pipeline). Si je ne m'abuse sur les derniers ils chargent par bloc de 512o en cache d'un coup et peuvent jouer plusieurs instructions sur un accumulateur de 64 bits. Bon j'avoue je n'ai pas lu entièrement le dataset du I7 (>500 pages pour juste les instructions).
Mais bon a en croire les gugus de calcul intensif surtout ne faites pas d'optimisation la libC le fera mieux pour vous.

Quoi, que dites-vous, docteur Loutre ? Monsieur Nazi vous envoie pour m'annoncer que mon ancienne candidature a enfin été retenue ? Je peux enfin travailler dans ce centre ? Et la prise de fonction est immédiate ? Vous m'en voyez très heureux, mais laissez-moi d'abord raccompagner mes étudiants chez eux avant de...

Mais, que faites-vous avec ça ? Puis-je vous faire remarquer que c'est une camisole de force, pas une blouse de chercheur, que vous êtes en train de me mettre ? Attendez... Lâchez-moi ! Pourquoi m'enfermez-vous avec ce poney ?

regarde Gné? d'un air à la fois vide d'émotions et avide d'un désir profond de mâchonner la proie que la sécurité du centre vient de lui mettre à sa merci

s'approche doucement et d'un pas menaçant vers Gné?, qui rapidement se trouve coincé entre le coin de la salle et le Poney Mâchonneur

Question subsidiaire : pourquoi but2ene fait semblant de ne rien comprendre à ce que les gens lui expliquent tout en les prenant de haut...
Certes, je me suis gourré : ce sont des octets et pas des mots (petit fumble avec mes cours d'ASM). Cependant, et tu le montres avec un schéma, la pile est allouée au lancement du programme. À ne bien sûr pas confondre avec la compilation, où personne n'a dit que les adresses étaient hard-codées...

@Lynix : "Pour info, ma fameuse boucle for était une boucle infinie, que j'écris toujours sous la forme du for (;;), parce que le while (1) provoque un warning (idiot) du côté de Visual."
Je n'ai pas regardé ton code, mais j'imagine que tu fais ton break quand un des joueurs a gagné ? Dans ce cas pourquoi ne pas écrire tout simplement while (!gameEnd) { ... } ? Et mettre à jour le booléen en cas de victoire ?
Au moins ça respecterait l'utilisation normale des boucles for et while en algorithmique (le for(;;) c'est juste crade comme code).

PS : je serais tenté d'écrire que ce n'est pas le warning qui est idiot mais le programmeur qui ne sait pas utiliser correctement les différentes boucles prévues par le langage...

Ce que j'ai montré n'était qu'un EXEMPLE de ce qu'est la pile. Je n'ai jamais dit qu'il s'agissait d'un tableau, j'ai vraiment l'impression que tu fais en effet semblant de ne pas comprendre.

Quant aux offsets, c'était aussi un exemple, ils ne sont pas hardcodés, mais "allouer" une variable sur la pile = avancer le pointeur de la pile, ni plus, ni moins.

Excusez-moi mais moi je trouve ça gratuit.

Dans le bureau de la direction du Centre de Recherche Expérimentale en Orthographe Inappropriée de PEBKAC.fr, monsieur G. Nazi relit une dernière fois le dossier qu'il vient de rédiger. Au détour d'un paragraphe, il aperçoit avec étonnement l'absence d'un c cédille qu'il s'empresse de corriger, avant de se dire "Ach, heureusement que je me suis rendu compte de ma faute avant d'avoir archifé le dossier !", et se promettant de ne jamais parler de cette erreur d'inattention à qui que ce soit. Désormais sûr de lui sur le contenu du dossier, il le ferme et il colle sur sa couverture une étiquette sur laquelle il écrit au feutre noir "Gné?".

À l'entrée du centre, les étudiants de la classe de Gné?, encore choqués par le spectacle qui s'est déroulé devant leurs yeux, sont raccompagnés de leur visite par le docteur Loutre. Ce dernier explique rapidement au chauffeur du bus qu'il est inutile d'attendre le professeur, avant de laisser le bus ramener les étudiants chez eux.

Dans la forêt qui abrite le centre de recherche, le calme de la nuit est soudain rompu par un puissant cri sortant de la salle d'expérience numéro 106 du laboratoire. Un frisson parcourt l'échine des animaux de la forêt. Leur instinct leur permettent de comprendre ce qui se passe. Ce soir encore, le centre de recherche vient d'accueillir un nouveau pensionnaire...

Heu je ne sais pas, mais il insiste avec son histoire de compilation. je cite "Dès lors, chaque variable possède une adresse sur cette pile, attribuée à la compilation."

Je ne comprends vraiment pas ce qu'il veut m'expliquer. Ou peut-être qu'il essaye de m'expliquer comment faire une pile avec un tableau. Mais là on serait vraiment très bas. (ah non en fait on est vraiment allé très bas)

J'hallucine ou il n'y a pas que la pile sur ce schéma il y a aussi le tas, le bss, les lib et les IO, enfin tout le programme. Oui ton programme est chargé en mémoire au lancement... Tu vois vraiment que ce que tu veux voir c'est un problème enfin c'est toi qui voit ;)

Comme j'ai dit au début. Ceci n'est pas alloué à la compilation (il insiste sur ce côté-là) mais au lancement.
Donc si tu bouffes plus sur la pile ben moins t'en auras sur le tas. De mémoire le tas contient les adresses allouées grâce aux malloc, contrairement à la pile qui contient les données. Et quand tu fais trop de malloc ben ça te renvoie une erreur.

L'opérande par défaut chez le x86-64 est de 32bits pas 64bits et effectivement la granularité est toujours l'octet. Donc avec un short tu gagnes de la place sans perdre de temps avec la bonne instruction. Mais pour le projet c'est dérisoire.

@Lynix : Quand tu feras de vrais projets et que tu ne pourras plus faire de malloc ni d'appel parce que tu as saturé ta mémoire allouée au programme. Tu changeras d'avis. Mais en attendant fais ce que bon te semble ;)

Enfin faites gaffe au termes utilisés.

Je ne vois pas en quoi il est mal d'utiliser un break avec un FOR plutôt qu'avec un WHILE.

On cherche toujours à rendre le code le plus lisible possible. C'est l'unique contrainte de l'utilisation d'un break... Après, chacun ses petites manières personnelles... Il existe nombre de "bonnes pratiques" en programmation, mais interdire le break dans un FOR n'en fait pas partie à ma connaissance.

Le cas typique de l'utilisation d'un break dans un FOR est lors du parcours d'une liste pour trouver un élément correspondant à certains critères complexes. Le FOR parcours la liste, et un IF déclenche le break sur l'élément concerné. C'est un grand classique qui, dans certains cas, sera plus lisible de cette manière plutôt qu'avec un WHILE fourre-tout et une sous-fonction alourdissant encore la lisibilité du code.

L'"adresse sur la pile", c'est l'offset de pile de la variable. Attribué à la compilation, en effet.
Si on se retrouve à t'expliquer ce qu'est une pile c'est parce qu'on lit des trucs du genre "on ne peut pas stocker une pile sur un segment alloué en début de programme"...
La pile a bel et bien une taille fixe (la limite du tas). C ne prévient pas lors du franchissement de cette limite, ce qui permet de pourrir le tas comme si elle n'existait pas avant de ressortir de l'autre côté (segfault de la part de l'OS) ou de causer des bugs plus loin dans l'exécution à cause des valeurs dans le tas qui auront été écrasées. Cependant elle existe bien, sinon on risquerait de malloc un bloc en plein dans la pile...

Bravo, tu viens de te descendre tout seul.

C'est la pile qui contient les adresses (et variables locales), et le tas qui contient les données allouées dynamiquement.

Arrête d'insister sur le "tableau", c'était juste un exemple de comment recréer un genre de pile en C, au niveau du fonctionnement, je n'ai jamais dit que c'était ça qu'elle était.

Je me suis en effet trompé dans les termes employés, surtout en parlant d'adresse, j'aurais du parler d'offset.

Mais bon, j'imagine que c'était pas clair pour tout le monde

Pour la preuve par invariant par exemple avec Z3, c'est mieux sans le break. Le code n'est pas illisible pour autant.

for(i=0;i<sizeof(l) && l[i]!=x;i++);

@Acorah: Lit mon code, tu comprendras.
@But2ene: Moi je trouve ça illisible, je dois relire plusieurs fois pour comprendre réellement ce qui est fait.
Je n'ai pas ce problème avec une condition suivie d'un break dans la boucle, je trouve ça nettement plus clair :

for (i = 0; i < sizeof(l); ++i)
 {
     if (l[i] == x)
         break;
 }

Faut dire que je ne m'attends pas à trouver autre chose que la "borne limite" dans la condition du for.

@D-Z: quand tu cite quelqu'un met la citation pas ce que tu as compris. Je viens de faire un ctrl+f au cas ou j'ai trop bu. Et j'ai relis mes postes tu devrais faire de même. Malheureusement pour toi je n'ai jamais écris cela.
"La pile a bel et bien une taille fixe (la limite du tas)." Revoie encore le schéma tu n'es pas loin. Il y a encore d'autres éléments. Donc on ne peux pas trop parler de taille fixe. Vu qu'elle change à chaque malloc/free.
C n'est qu'un langage, il ne te prévient de rien lors de l'execution. Par contre ton OS (un vrai) lui va te le dire. Quoi que maintenant c'est le CPU qui fait tout le boulot. Pourrir ton tas est une faille de sécurité. Car tu pourrais changer les adresses ainsi changer les adresse des jump de retours.

@Lynix : Oui en effet, utiliser les bon termes c'est mieux. Pour se faire comprendre ;)

0/20 pour quelque chose qui n'est même pas dans les consignes c'est de l'arrogance débile de la par du prof. Quelques point en moins à la limite mais là...
Dans mon ancien lycée un prof à fini par ce faire virer à cause de ce genre de chose. (à la 10ème note annulée par la direction en 2 ans ils en ont eu mare) A noter que ça c'est passé en Suisse.

La pile ne change pas de taille après un malloc ou un free ... Tu mélanges beaucoup de choses.

On va faire simple :
http://www.dirac.org/linux/gdb/02a-Memory_Layout_And_The_Stack.php
http://net.pku.edu.cn/~course/cs101/2008/resource/heapAndStack_files/r[...]
http://www.maxi-pedia.com/web_files/images/HeapAndStack.png

Text+Bss+pile+tas= constante.
text et bss sont constants, car définis à la compilation.
Pile+tas = constante. Donc quand l'un grossis l'autre a moins de place.

Les gars c'est dans la doc, je n'invente rien. Je vais arrêter parce qu'arriver à ne pas comprendre un dessin tout con vous le faites exprès ce n'est pas possible.

"Tu mélanges beaucoup de choses." après tout ce que tu as mélangé pardon dit , lol.

but2ene : si le sens immédiat de ta phrase ne colle pas avec ce que tu as voulu dire, c'est ton problème...
"La pile n'est pas seulement alloué au début de programme, sinon [tu ne pourrais pas faire d'appel récursif de fonction et elle ne porterais pas le nom de pile] => c'est donc pas une pile, NDL" ça veut dire que tu ne peux pas allouer de pile en début de programme, point. Et c'est évidemment faux.
La partie utilisée du tas change de taille avec un malloc ou un free, certes. La marge entre cette partie et la pile ne peut cependant pas être considérée comme faisant partie de la pile : si tu l'atteins lors d'un appel de fonction et que tu malloc un bloc dessus dans cette fonction, boum. La limite pile/tas a beau ne pas être assurée au runtime en C (contrairement à Java par exemple) et être dépassable sans crash systématique, elle est bien réelle et fixe.

Tes schémas montrent ce que j'explique, c'est le tas qui change de taille avec un malloc, pas la pile (pour rappel heap = tas et stack = pile).

Pourtant ceci est issu de ton code.

 for (ptr = &game->cells[line-1][column-1]; ptr >= limit && *ptr == state; ptr -= GAME_COLUMNS+1)
                 current++;

Démasqué !
Mais, je ne sais pas si t'as déjà vu la preuve par invariant. Tu démontres que ton for sort dans l'état souhaité.
Z3 est un prouveur de Microsoft qui t'aide à vérifier ton programme par preuve.
Du coup pour lui c'est plus simple d'extraire les invariants sans break. Quoiqu'avec un simple if il devrait y arriver. Mais si t'as des bouts de code avant et d'autre après ça demande une petite gymnastique.

Contrainte du prof, rien de plus. (Au moins une qui était précisée !)

Si j'avais vraiment pu l'écrire comme je voulais, crois-bien que j'aurais utilisé des indices pour que ça soit plus clair ..

Ah ok t'en avait qui n'était pas dans l'énoncé.

C'est un cas différent, la prof a décidé d'interdire pendant toute une période l'itération sur des indices, pour mieux comprendre les pointeurs (Au fond c'est une bonne idée mais je ne l'aurais pas appliquée de cette façon).

Ce code était donc destiné à itérer sur des pointeurs selon une méthode prédéfinie.

Mais sur mes autres codes, je ne fais jamais ça, ou alors je n'en ai pas le souvenir.

but2ene : "Pourrir ton tas est une faille de sécurité. Car tu pourrais changer les adresses ainsi changer les adresse des jump de retours."

Gné ? Les adresses de retour (de fonction) sont stockées sur la pile, et non pas dans le tas. C'est grâce à ça (entre autre) qu'on exploite les vulnérabilités de type stack-based buffer overflow (à ne pas confondre avec des vulnérabilités de type stack overflow qui ont lieu lorsque la pile est pleine).

En tout cas les faits sont là (Lynix a posté son code et des détails) et on peut juger de nous même que la prof (voire l'équipe pédagogique) est complètement incompétente. Qu'il soit dégoûté ou non, ça ne change rien à ce PEBKAC.

@n0p : Tu es en train de dire que si la pile écrase ton tas tu ne pourrais pas accéder à la pile en passant par l'adresse écrasée du tas ?

Histoire de voir si j'ai bien compris. Je ne sais pas justement quand je fais ce genre de truc. Je fais un gros malloc puis j'appelle une fonction qui devrait écraser mon malloc et je cherche la structure au bout du pointeur retournée par le malloc pour changer cette valeur avant le return de la dite fonction. Mais bon chacun sa technique.

Généralement, quand deux voitures se percutent les deux sont amochées.

@Lynix: quand t'as piles + tas = 10 si tu fais un malloc de 2 combien peux tu allouer sur la pile ou le tas ? vois tu l'impact maintenant ?
@D-z: Ok, cette phrase répondait à
"Cependant, la pile est allouée au début du programme, et garde sa taille (1mo par défaut sous Windows), qu'on utilise des short ou des int.

Et comme le cours de C était encore loin des allocations dynamiques, nos programmes ne pouvaient utiliser que des variables sur la pile."

et différentes phrases qui faisait penser à des adresses hardcodés.
Désolé j'avais mal compris. Mais bon elle partage avec le tas. Mais si tu veux, tu peux allouer 200Go pour une pile, je n'ai rien contre. Après c'est moi qui fais exprès ? Hein oo? hein 0o? Oo ? (•)o ? Merde mon oeil !

Le comic sans ms ne te suffisait pas ? XD

Ouais mais t'aurais pu l'écrire comme suis

for (ptr = &game->cells[line-1][column-1]; ptr >= limit; ptr -= GAME_COLUMNS+1){
                 if(*ptr != state)
                           break;
                 current++;
 }

Ouais, je sais, je suis chiant.

Quitte à être chiant moi aussi

"Ce code était donc destiné à itérer sur des pointeurs selon une méthode prédéfinie."

Méthode prédéfinie était pour moi une référence au test au milieu de la boucle for, méthode apprise lors du cours d'algorithmie, je me suis dis que, quitte à ne pas pouvoir faire à ma façon là-dessus, autant faire exactement comme elle préconisait.

Tharkun : Toi, c'est en cours d'ironie/sarcasme que tu as dû avoir zéro.

@D-z
Utiliser de la logique pour de l'arithmétique est toujours une très mauvaise idée...
playerId = !playerId; n'est PAS TOUJOURS équivalent à playerId = (playerId+1) % 2;.
Si tu veux, tu peux utiliser playerId = 1 - playerId;. Mais je préfère toujours la première version, qui, elle, montre le pas vers la généralité playerId = (playerId+1) % numPlayers;.

Et pour reprendre ce commentaire de Link : http://www.pebkac.fr/pebkac/8090/#comment_99723
Ça aurait même pu être une charactérielle !

ah ok c'est un copié collé du cours. Du comme, c'est une fonction déjà donnée pourquoi la réécrire.

Pfiou le level des blagues... y'a de quoi trouver le temps long ><

Troisième solution : le/la prof (je sais plus) est un(e) abruti(e). J'en ai eu aussi des profs d'info grabataires et imbéciles, tout comme j'en ai eu des excellents. Mais faut pas croire, il reste encore pas mal de chaises à racler dans les écoles d'info françaises...

Je ne sais pas si c'est le cas ici, mais certains profs vont noter plus (trop) sévèrement les élèves qui ont déjà des acquis solides dans la matière qu'ils enseignent, alors qu'ils seront plus cool pour noter les autres.
J'ai vu ça dans une autre filière que l'informatique, mais ça doit exister partout. Quand on tombe sur un con pareil, ça a de quoi dégouter des études...

(PS: je suis pour l'optimisation des programmes, mais 0/20 faut pas pousser mémé dans les orties non plus ...)

but2ene : Non, je n'ai pas dis ça, j'ai dis que les "les adresses de retour (de fonction) sont stockées sur la pile, et non pas dans le tas.".

Pas compris ton 2ème paragraphe. En tout cas, si tu fais un malloc(), la mémoire réservée le sera dans le tas, donc si tu provoques un heap overflow (ce que tu sembles décrire) alors non, tu ne trouveras pas ton adresse de retour de fonction à la fin de ton buffer. Ou alors quand tu parles de "structure au bout du pointeur retourné", tu parles de la structure créée par l'allocateur pour chaque chunk ? Du coup on est vraiment dans une exploitation de heap overflow, plus du tout dans un stack-based overflow et la pile n'a rien à faire ici (et donc les adresses de retour non plus, et donc "avant le return de la dite fonction" non plus).
Bref, ça me semble bien confus tout ça :) Tu as déjà fais de l'exploitation ou c'est théorique ?

(il faut *vraiment* arrêter les analogies avec les voitures, dans l'informatique)

Si, en effet :)

Voilà, je suis tout à fait d'accord avec but2ene (j'oubliais par contre cette notion d'invariant, qu'on retrouve dans la logique de Hoare par exemple).

Après, peut-être qu'en entreprise tout le monde se fout de la sémantique (sûrement, même), mais ça ne veut pas dire pour autant que c'est bien d'utiliser un break dans un for, voilà tout.

Alors là je dis bravo ! Ma journée est illuminée ! Mersihn !

Ouais, c'est parce que je suis un vieux réac' paternaliste !

Ce qui est con, c'est qu'utiliser un int est une meilleure optimisation qu'un short : le int consomme moins de ressources CPU en contrepartie d'utiliser plus de RAM (et ça ne monopolise la RAM que pour les globales...).
L'important c'est que la contrainte CPU est plus courante que la contrainte RAM.

Sinon, faites du vrai C et choisissez où vous placez votre pile, où vous placez votre tas, etc.
L'optimisation, c'est cool dans un contexte embarqué où il n'y a pas forcément d'OS ou de machine virtuelle et où on fait ce qu'on veut avec la mémoire.
Dans mon projet, utiliser la pile réduit uniquement l'espace disponible dans la pile et n'affecte aucunement le tas. (Et aucune chance d'utiliser trop d'espace dans la pile...)

Sonny : tu peux optimiser un peu avec
pos = 0;
cont = 1;
do {
if (val[pos]==x) {
cont = 0;
}
pos = pos + 1;
} while ((pos < 5) && (cont == 1));

;)


Lynix : il y a des domaines où il est simplement interdit d'utiliser un break

Quid de ça ?

cont = 0;
for (int i = 0; cont = 1; ++i)
{
if (val[i] == x)
{
pos = i;
cont = 1;
}
}

C'est une simple question, je n'ai aucune idée de si c'est «légal» ou non, «optimisé» ou non.

Heureusement qu'elles sont unsigned, ces blagues !

Ouais, enfin, si t'as des opérations mathématiques à faire dessus, tu vas faire perdre du temps à ton programme à chaque conversion... non ?

@n0p : justement si l'overflow n'est pas detecté. C'est dans ce cas qu'on se place. Je fais un malloc pile poile jusqu'à la pile. Aucune erreur.

Puis appelle de fonction. Stack overflow non detecté, donc il écrase une parti de ce que j'ai alloué. (pollution du tas dont parlais D-Z)
Donc en allant à la fin de mon alloc, j'ai la partie de la pile qui m'a écrite dessus et ainsi la valeur de retour que je peux changer.

C'est bon ?

En ce qui me concerne, une aventure similaire m'est arrivé.
Programmation d'une calculatrice en assembleur, avec la gestion des registres pour éviter le dépassement des capacités (ouais, j'aime pas l'anglais, donc overflow pour les autres).
On utilisait si ma mémoire est bonne ASM32, qui permet de choisir différent type de registres lors de la création du projet.
Avec un autre binôme, on a tenté une chose : définir un projet en utilisant une taille de registre plus grande. Plus de dépassement à gérer, interface graphique super facile à implémenter, et j'en passe. Et ceci au prix de quelques fonctions à apprendre.
20/20 pour avoir appris un nouveau langage.
On était plus aimé dans la promo après.

ps: J'ai déjà fait ce genre d'exploitation sur un système de type minix modifié. En jouant sur les entrées de programme. Avec d'autres failles de ce genre, ça illustrait l'importance de la gestion de la mémoire. Qu'un registre haut bas ne suffit pas toujours.
Ce n'est dans aucune des deux attaques que tu cites au fait. Il en existe bien d'autres.

Je n'arrive pas à comprendre en quoi cette aventure est "similaire"..

@Peredur Tout dépend du contexte, faut compter les temps d'accès à la RAM aussi.

C'est arrivé dans quelle école ?
J'ai fait le CPLN et l'HES du Locle et j'ai eu mon lot d'abrutis congénitaux, ça m'intéresserait de savoir si l'un d'eux à fini de propager son obscurantisme.

C'est aussi pour ça que les favoris existent!

En fait ma réaction initiale provenait juste de cette phrase :

"Pourrir ton tas est une faille de sécurité. Car tu pourrais changer les adresses ainsi changer les adresse des jump de retours."

Parce que ce n'est vraiment pas la première chose à quoi on pense quand on peut corrompre le tas. En général, on pense plutôt à modifier un pointer d'un chunk de mémoire qui sera appelé lors de la libération du chunk, par exemple. Ou un pointer de fonction quelconque qu'on peut trouver via un autre leak.

Ce que tu décris existe néanmoins, on est d'accord (mais je n'avais pas compris que tu décrivais cela, ce n'était pas très clair). Sur un OS moderne (tous ? je ne sais pas...) ce n'est plus exploitable depuis quelques années puisqu'il existe une page de garde entre la stack et la heap.

Voilà une ancienne (2005) présentation d'un pote qui parle de ça : http://cansecwest.com/core05/memory_vulns_delalleau.pdf - page 15

Et ici un exemple concret sur Linux : https://lwn.net/Articles/400746/

"Ce n'est dans aucune des deux attaques que tu cites au fait. Il en existe bien d'autres."

Je n'ai jamais prétendu avoir parlé de toutes les vulnérabilités connues.

Dans le cas où playerId oscille entre 0 et 1 uniquement bien sûr ;)
Le standard spécifie bien que !1 == 0 et !0 == 1.
Ceci dit c'est plus une habitude qu'un problème, j'aurais même pas dû le citer en fait.

Heureusement que votre folie n'a pas encore donné du Bit au jeune Public de PEBKAC !

Non c'est pas dans cette région.
Je refuse d'être plus précis que de dire que c'était dans le canton de Vaud.

Très *class* comme discussion ! C'est très *for* pour une discussion *public* !

Heureusement, on est *protected* dérrière notre pseudo !

Ok ok, je ne connais pas les écoles dans ce coin, j'ai tjs habité à Neuch'.

En C il n'y a pas de conversion à faire.
Un char est un nombre au même titre qu'un int, il peut parfaitement être utilisé comme tel.