Un langage sans "if" - Page 4

Je suis aussi un peu du même avis que Zeph pour le coup. Enfin, si j'ai bien compris son post.

Entièrement d'accord, ras le bol de l'OO pour faire de l'OO là où ça n'a aucun intérêt.

d'un autre coté, je ne crois pas t'avoir jamais vu faire la pub d'un langage OO, t'as tendance à préférer le C sans plus plus il me semble...

Bah, en ces derniers temps, j'aime bien le C++ avec Qt (la STL sux, mais le langage C++ est très bien et Qt est une très bonne bibliothèque de classes), mais j'ai tendance à penser plutôt de manière procédurale qu'OO.

Salut a tous,

Pour ceux qui me connaissent, vous savez que le C c'est vraiment impossible pour moi (C'est genetique chez moi ). Je suis a la base codeur de démos (Atari). Certaines techniques utilisés imposent un temps de fonctionnement fixe par exemple pour des synchro vidéos, qui font que le moindre changement de timing, ferait partir l'image en vrille, donc on a écrit des codes sans if et cela depuis des années.

On a basé beaucoup de choses sur le fait que le microprocesseur (68000 dans notre cas), positionnait les flags de test pour un paquet d'instructions. Ce qui evitait deja une instruction de test. Ensuite il y a par exemple l'instruction : Scc (CC étant la condition de test) qui permettait par exemple de fixer a 0 ou -1 la destination et cela sans 'if'.

Après il y a paquet d'astuces pour se passer d'un if, tout dépend bien sur de ce qu'on veux faire avec ce 'if'.


GT Sans 'if'

(oui, enfin pour le coup ça dépend aussi du CPU, de ses registres et de leur fonctionnement)

vince (./97) :
(oui, enfin pour le coup ça dépend aussi du CPU, de ses registres et de leur fonctionnement)

Pas faut bosser sur de l'Intel


GT Pro Motorola

P.S. : Je sais ce que c'est spécifique au Cpu, mais c'était juste pour parler d'experience perso.

PS : je sais que tu sais que c'est spécifique au cpu et je sais que tu n'ignores pas que je sais que t'es marié avec le 68k

D'ailleurs, je vais me marier avec GT Turbo, et on adoptera plein de petits 68000 ! Vivement le mariage pour toutes !!!

Effectivement même si techniquement ça ne fait pas de saut, ça reste un if. Sur ARM c'est encore pire puisque presque toutes les instructions peuvent être conditionnelles, par exemple:

; if (a < b) c = a; else c = b;
cmp a, b
movlt c, a
movge c, b

Peut être qu'Onur verrait ça comme une solution ?

Folco (./100) :
D'ailleurs, je vais me marier avec GT Turbo, et on adoptera plein de petits 68000 ! Vivement le mariage pour toutes !!!

GT Folco !! \o/

Brunni -> probablement pas optimal si le test lower than prend du temps, il suffit de faire

cmp a,b
mov c,a
movge c,b

ou encore

mov c,a
cmp a,b
movge c,b

Oui, mais le test ne prend pas de temps, dans ce cas ça ne changerait rien.

Et puis la double assignation c'est un peu caca si c est une adresse mémoire…

Certes, d'où le

Folco (./104) :
probablement pas optimal si le test lower than prend du temps

Zeph (./84) :

Brunni (./82) :
./79 > Tu continues à y être sensible donc ?

Oui, même si davantage pour du code perso que pour le boulot. En revanche dans les principaux critères qui me font considérer un code "beau" il y a la concision, du coup je ne suis pas un grand fan des extrémismes POO ou autres comme celui visé par onur. Et puis bon c'est un peu sans fin comme objectif, on peut toujours ajouter une couche supplémentaire qui généralise encore un peu plus un bout de code, sentir quel est le bon endroit pour s'arrêter fait partie pour moi de l'essentiel de l'expérience qu'on acquiert progressivement.

Brunni (./85) :
Ok. Oui pareil, la concision est un grand objectif, qu'un code éclaté sur 50 classes, même petites, est déjà assez mal parti pour remplir ^^

Les joies du Java, avec la théorie de 1 classe == 1 fichier (ce que je trouve absurde, et pourquoi pas 1 méthode == 1 fichier pendant qu'ils y sont ), et encore mieux, leurs int et Integer

flanker (./108) :
Les joies du Java, avec la théorie de 1 classe == 1 fichier

À bas le Java!

(ce que je trouve absurde,

+1!

et pourquoi pas 1 méthode == 1 fichier pendant qu'ils y sont

Comme MATLAB , tu veux dire? (Quel langage pourri! )

et encore mieux, leurs int et Integer

flanker (./108) :

Brunni (./85) :
Ok. Oui pareil, la concision est un grand objectif, qu'un code éclaté sur 50 classes, même petites, est déjà assez mal parti pour remplir ^^

Les joies du Java, avec la théorie de 1 classe == 1 fichier (ce que je trouve absurde, et pourquoi pas 1 méthode == 1 fichier pendant qu'ils y sont ), et encore mieux, leurs int et Integer

Hum ça c'est un choix, ça se discute (on est dans le libre et les FS qui sont faits pour gérer des millions de fichiers, et puis SVN préfère les petits fichiers), mais c'est vrai que je suis content de pouvoir tout mettre en un en C#, parce que tu crées énormément de types et de classes dès que tu travailles avec les événements.
Mon problème c'est plus le fait de créer beaucoup de classes en général, même si elle pouvaient toutes être dans un fichier.

Bin ça fait tout de même une redondance parfaitement inutile, dont je ne vois pas l'intérêt.

Ah bah pour le coup, même en C# où il n'est pas obligatoire d'avoir une classe par fichier (c'est juste l'une des recommandations de Microsoft) je me force à le faire. D'une part ça découpe la logique d'une façon assez simple à comprendre (puisqu'une classe = une et une seule responsabilité), et puis c'est un très bon moyen de se rendre compte quand on fait n'importe quoi et qu'il y a 150 petites classes qui se baladent partout, c'est plus facile à dissimuler qu'un immonde fichier de 800 lignes

Je ne comprends pas l'argument "redondance" d'ailleurs, si chaque fichier contient une classe, logiquement chaque classe remplit un rôle qu'elle est seule à accomplir, où est la redondance ? (à part dans la ligne "namespace Bidule" en haut, à la limite, mais bon ça reste raisonnable comme prix à payer ^^)

Bah, personnellement, j'aime bien les .cpp de 5000+ lignes.
http://tigcc-linux.cvs.sourceforge.net/viewvc/tigcc-linux/ktigcc/mainform.cpp?revision=1.101&view=markup

Ouais, mais t'es aussi du genre à écrire des trucs comme i[tableau] au lieu de tableau[i], alors on va dire que tu as des goûts particuliers

./113 : ouais bah code de merde, impossible d'y retrouver quoi que ce soit sans l'avoir écrit soi-même, pas grand chose à dire de plus

[edit] bon j'argumente quand même un peu : ton fichier mélange du code GUI et du code métier, du coup sans bien connaître ton soft en particulier c'est vraiment pénible à lire. En plus, si un jour tu veux faire une autre GUI, ou une version ligne de commande, ou une version HTTP, ou ce genre de choses, tu vas être obligé de jeter ton truc à la poubelle puisque la partie qui aurait pu être réutilisée à l'identique si elle avait été bien séparée dans des fichiers/classes à part est complètement emmêlée avec des histoires de composants graphiques qui n'ont rien à voir. Cas d'école de ce que je considère être un code tout sauf maintenable, on dirait celui de yAronet

(après je suis d'accord que c'est plus facile et plus rapide à écrire, mais à part pour un projet perso... )

Zerosquare (./114) :
Ouais, mais t'es aussi du genre à écrire des trucs comme i[tableau] au lieu de tableau[i], alors on va dire que tu as des goûts particuliers

Seulement quand c'est plus court (genre 2[(short*)foo] au lieu de ((short*)foo)[2]).

Zeph (./115) :
./113 : ouais bah code de merde, impossible d'y retrouver quoi que ce soit sans l'avoir écrit soi-même, pas grand chose à dire de plus

Pourtant, tu remarqueras que 2 coauteurs ont touché à ce fichier.

cross-edit

Bah, personnellement, j'aime bien voir clairement ce qui se passe quand un évènement est déclenché sans devoir traverser 10000 classes qui font abstraction de l'abstraction.

C'est vraiment casse-pieds quand on lit une source de regarder que fait l'évènement fooClicked et de voir que ça appelle core.foo, ensuite de chercher core.cpp dans un autre dossier, de regarder que fait Core::foo et de voir que ça appelle backend.foo, ensuite de devoir chercher backend.cpp dans encore un autre dossier pour enfin trouver Backend::foo qui fait le vrai travail. (Et ce n'est que le cas le plus simple. Si foo a ensuite besoin de mettre à jour l'interface, ça devient encore plus bordélique avec ce genre d'organisation.)

Et pour la ligne de commande, elle a de toute façon besoin d'un fonctionnement totalement différent, parce que l'EDI compile à partir des buffers internes de l'éditeur, qui sont écrits dans un dossier temporaire pour la compilation, pas à partir des fichiers sur disque. La ligne de commande n'a pas ces buffers.