..:: Topic des Codeurs Couche-Tard [0] ::..

Pylades · Le 20/04/2010, à 00:19

cm-t a écrit :

sinon, ton histoire de copier/coller de code, ca fait pas avec les inline?

Non.

Grünt · Le 20/04/2010, à 00:50

Plop.

Ça existe pas déjà, un truc qui gère les options? C'est recodé à chaque fois?

Pylades · Le 20/04/2010, à 01:03

Plop.

Je veux proposer un truc qui me convienne vraiment, l’autre truc existant étant trop compliqué et pas assez efficace à mon goût.

Pylades · Le 20/04/2010, à 02:04

Bon, un ’tit plop et au dodo.

Release pas pour aujourd’hui. ^^

samυncle · Le 20/04/2010, à 02:04

crowd · Le 20/04/2010, à 03:13

<?php
       echo 'hello world';
?>

samυncle · Le 20/04/2010, à 03:22

ilagas a écrit :

samuncle a écrit :

oracle_bot · Le 20/04/2010, à 05:34

Scores totaux, depuis le début:

1) 60    samuncle
2) 37    nesthib
3) 34    Pylade
4) 33    helly
5) 30    cm-t
6) 27    ilagas
7) 24    grim7reaper
8) 23    ǤƦƯƝƬ
9) 11    Ouranos999
10) 10    CROWD
11) 7    tshirtman
12) 5    stratoboy
12) 5    pierguiard
14) 4    Ph3nix_
14) 4    oracle_bot
14) 4    danychou56
17) 3    kouskous
17) 3    Р'tite G☢gole :mad:
19) 2    Kanor
19) 2    mathieuI
19) 2    Le Rouge
22) 1    ceric
22) 1    pfriedK
22) 1    geenux

WCFCF XELEX ZYGDE VEMSQ SKXTZ VMGYX ELENL FCENG CTCES GPWHY G

oracle_bot · Le 20/04/2010, à 05:34

scores de la période en cours:

1) 60    samuncle
2) 37    nesthib
3) 34    Pylade
4) 33    helly
5) 30    cm-t
6) 27    ilagas
7) 24    grim7reaper
8) 23    ǤƦƯƝƬ
9) 11    Ouranos999
10) 10    CROWD
11) 7    tshirtman
12) 5    stratoboy
12) 5    pierguiard
14) 4    Ph3nix_
14) 4    oracle_bot
14) 4    danychou56
17) 3    kouskous
17) 3    Р'tite G☢gole :mad:
19) 2    Kanor
19) 2    mathieuI
19) 2    Le Rouge
22) 1    ceric
22) 1    pfriedK
22) 1    geenux

WCFCF XELEX ZYGDE VEMSQ SKXTZ VMGYX ELENL FCENG CTCES GPWHY G

grim7reaper · Le 20/04/2010, à 08:25

Hello World !

Pylade a écrit :

grim7reaper a écrit :
Ça casse la lecture, c'est difficile à lire, ça complique le repérage des points de sortie de tes fonctions et ça s'oppose un peu à la programmation structurée.
?
Plutôt que de rajouter des tests partout, ça me permet de quitter proprement dès que je tombe sur une erreur.

Hum, proprement c'est vite dit, mais là on entre dans le subjectif. Donc tu fais comme tu veux, moi je préfère faire un ou deux tests en plus et avoir un unique return quand c'est possible, même si je ne trouve pas toujours ça esthétique, ça à le mérite d'être moins brutal pour le flot du programme que la multiplication return.
Mais c'est un avis strictement perso.

grim7reaper a écrit :
Pourquoi ça te dérange de faire des fonctions ?
Cela permet au contraire de diminuer la complexité en repartissant les tâches (quand au return, il suffit d'en utiliser moins.)
Dans certaines de tes fonctions il suffit d'ajouter une variable, modifier quelques conditions et/ou rajouter un else pour supprimer les return multiple.
Mouais. Utiliser moins de return, ça va être dur.

Tout dépend de ta façon de coder, moi j'aurais du mal à coder des fonctions avec 6 return (pourtant à mes débuts, qui ne sont pas si lointain, je le faisais).

Pylades · Le 20/04/2010, à 08:39

Bug… (du forum)

grim7reaper · Le 20/04/2010, à 08:43

Ouais, Seren sabote de TDCCT (il est connecté en double) .

Et personne n'a remarqué mon flood sur les erreurs HTTP .

Pylades · Le 20/04/2010, à 08:44

Si, mais c’était du flood.

grim7reaper · Le 20/04/2010, à 08:48

Oui mais pas du vulgaire food tout de même, il avait un petit quelquechose en plus

Seren · Le 20/04/2010, à 09:57

Pour info il y a des endroits où dans les "coding rules" on t'impose de n'avoir qu'un retour par fonction.

Just pour info (ou pour la culture générale), les règles obligatoires et conseillées pour développer en C dans l'automobile. (règles MISRA)

http://computing.unn.ac.uk/staff/cgam1/teaching/0703/misra%20rules.pdf

82 (adv): A function should have a single exit point

82 (conseillée) : Une fonction doit avoir un seul point de sortie.

C'est dommage le document n'est pas complet et ne donne pas le détail de l'explication.

Je suis pas sûr que ce soit uniquement pour ça, mais quand on debug, c'est déjà plus simple de mettre un point d'arrêt quand il y a un seul return que lorsqu'il y en a dix par fonctions.

Ca évite aussi d'avoir du code mort dans son code quand les "chemins" sont plus simples.

Ou si on veut tester la valeur de retour c'est aussi plus simple quand il y a un passage obligé.

C'est pas totallement anecdotique dans le sens où lorsque le constructeur va faire son appel d'offre il va exiger que le code fourni respecte les règles MISRA (en totalité ou en partie).

Dernière modification par Seren (Le 20/04/2010, à 10:40)

PPdM · Le 20/04/2010, à 10:04

seren
deco reco tu es en double

grim7reaper · Le 20/04/2010, à 10:08

+1 pour Seren
Ça confirme ce que je disais précedemment.

Intéressant comme document (beaucoup de ces règles sont valables dans la cas général), tu bosses dans ce domaine ?

Dernière modification par grim7reaper (Le 20/04/2010, à 10:13)

Seren · Le 20/04/2010, à 10:35

grim7reaper a écrit :

Intéressant comme document (beaucoup de ces règles sont valables dans la cas général), tu bosses dans ce domaine ?

Plus maintenant, mais j'ai bossé dans l'automobile.

Même si il y a beaucoup de bons conseils il faut voir qu'il y a pas mal de règles casse-couilles, comme pas d'arithmétique sur les pointeurs (pas de p++), pas d'allocation dynamique de mémoire (donc pas de malloc), pas de transtypage de pointeurs, etc

C'est sûr que ça limite les chances de faire des erreurs, mais ça limite pas mal ce qu'on peut écrire aussi.

Dernière modification par Seren (Le 20/04/2010, à 10:36)

grim7reaper · Le 20/04/2010, à 10:40

Seren a écrit :

grim7reaper a écrit :
Intéressant comme document (beaucoup de ces règles sont valables dans la cas général), tu bosses dans ce domaine ?
Plus maintenant, mais j'ai bossé dans l'automobile.
Même si il y a beaucoup de bons conseils il faut voir qu'il y a pas mal de règles casse-couilles, comme pas d'arithmétique sur les pointeurs (pas de p++), pas d'allocation dynamique de mémoire (donc pas de malloc), pas de transtypage de pointeurs, etc
C'est sûr que ça limite les chances de faire des erreurs, mais ça limite pas mal ce qu'on peut écrire aussi.

Oui je suis d'accord, c'est bien pour ça que j'ai mis beaucoup et pas toutes (je pensais à ces exemples là entre autres).
Mais certaines sont peut-être dû aux contraintes matérielles (genre le malloc), car c'est du hardware un peu spécifique qui doit être utilisé dans ce domaine (du moins je suppose) ?

Dernière modification par grim7reaper (Le 20/04/2010, à 10:42)

tshirtman · Le 20/04/2010, à 10:46

ou alors c'est pour éviter toute chance de memory leak ou pire de segfault…

mais bon, c'est vrai que ça doit être génant…

Seren · Le 20/04/2010, à 10:49

grim7reaper a écrit :

Mais certaines sont peut-être dû aux contraintes matérielles (genre le malloc), car c'est du hardware un peu spécifique qui doit être utilisé dans ce domaine (du moins je suppose) ?

Je crois que la principale raison, c'est que dans un système critique, on veut pas qu'un "malloc" échoue à un moment critique qu'on avait pas prévu. Et c'est dur dans un système dynamique de prévoir toutes les états possibles du système.

Donc pour s'en prémunir, on alloue toute la mémoire de façon statique au démarrage comme ça on aura jamais de problème de "out of memory".

Edit : ah oui j'avais pas pensé aux memory leaks, ça doit être aussi pour ça.

Dernière modification par Seren (Le 20/04/2010, à 10:50)

Pylades · Le 20/04/2010, à 10:54

Seren a écrit :

Ca évite aussi d'avoir du code mort dans son code quand les "chemins" sont plus simples.

Je compile avec -Wunreachable-code, ça aussi ça évite le code mort ; et il ne m’a jamais renvoyé de warning.
Donc je ne pense pas que ça soit un problème.

Après, ne pas faire d’allocation dynamique, ça évite les fuites de mémoire, OK, mais on peut aussi ne pas coder, ça évite les bugs…

Bon, maintenant je vais arrêter de me trouver des excuses, et essayer de diminuer un peu le nombre de return dans mon code.

grim7reaper · Le 20/04/2010, à 11:02

J'imagine le comportement de la voiture si elle SIGSEGV .

C'est d'ailleurs pour ça que dans les secteurs critique, l'Ada a plus la cote que le C je crois (ce qui est la raison pour laquelle l'Ada a été créé il me semble). Il est vrai que le C est permissif et pour faire des composants logiciels fiables il est nécessaire de s'astreindre à des règles très strictes.

J'ai des amis qui ont des cours d'Ada et apparement c'est plutôt bien comme langage (encore un truc, parmis les millions d'autres , sur lequel il faudra que je me penche un de ces quatre).

Pylades · Le 20/04/2010, à 11:16

grim7reaper a écrit :

J'imagine le comportement de la voiture si elle SIGSEGV .

Ouais, il faut bien sûr tout tester pour s’assurer que ce genre de choses ne se produira pas.
Ce qu’on gagne en SIGSEGV évités, on perd en code moins pur et moins lisible (je suis bien placé pour dire ça, tiens ), donc risque de bug. Après il faut voir de quel côté on préfère se situer…

tshirtman · Le 20/04/2010, à 16:27

j'ai eu des cours d'Ada, j'ai pas retenus grand chose à part

BEGIN
...
END

et comment dire… >_<

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#401 Le 20/04/2010, à 00:19

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#402 Le 20/04/2010, à 00:50

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#403 Le 20/04/2010, à 01:03

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#404 Le 20/04/2010, à 02:04

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#405 Le 20/04/2010, à 02:04

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#406 Le 20/04/2010, à 03:13

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#407 Le 20/04/2010, à 03:22

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#408 Le 20/04/2010, à 05:34

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#409 Le 20/04/2010, à 05:34

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#410 Le 20/04/2010, à 08:25

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#411 Le 20/04/2010, à 08:39

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#412 Le 20/04/2010, à 08:43

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#413 Le 20/04/2010, à 08:44

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#414 Le 20/04/2010, à 08:48

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#415 Le 20/04/2010, à 09:57

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#416 Le 20/04/2010, à 10:04

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#417 Le 20/04/2010, à 10:08

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#418 Le 20/04/2010, à 10:35

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#419 Le 20/04/2010, à 10:40

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#420 Le 20/04/2010, à 10:46

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#421 Le 20/04/2010, à 10:49

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#422 Le 20/04/2010, à 10:54

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#423 Le 20/04/2010, à 11:02

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#424 Le 20/04/2010, à 11:16

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#425 Le 20/04/2010, à 16:27

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

Pied de page des forums