/* Topic des codeurs couche-tard [1] */

Pylades · Le 22/07/2010, à 18:46

Non, je ne code rien encore ; mais je lis la doc (enfin, le tuto pour le moment) par petits bouts. Je me suis rendu compte que le classes devaient avoir un nom qui commence obligatoirement par une capitale, mais je n’en vois pas la logique.

Bon, en revanche on est obligé de constater que irb est inférieur à l’interpréteur python : pas d’aide (en tout cas je n’en ai pas vu), et il est facile de produire un suite sans fin d’erreurs de syntaxe en oubliant une quote fermante ou un truc du genre. De plus, je trouve que les « => nil » ne sont pas d’une grande utilité.

Mais sinon, ça m’a l’air d’être un langage sympa, avec une doc de qualité, et une syntaxe très claire et facilement compréhensible.

grim7reaper · Le 22/07/2010, à 19:38

Pylade a écrit :

Je me suis rendu compte que le classes devaient avoir un nom qui commence obligatoirement par une capitale, mais je n’en vois pas la logique.

Même quand le langage ne l'impose pas je le vois 99,9% du temps. C'est juste un truc international communément admis. Une sorte de convention…

Dernière modification par grim7reaper (Le 22/07/2010, à 19:38)

Pylades · Le 22/07/2010, à 19:41

Je n’étais pas au courant…

Il faut dire que je n’ai encore jamais utilisé sérieusement de classes.

Dernière modification par Pylade (Le 22/07/2010, à 19:41)

grim7reaper · Le 22/07/2010, à 19:48

Certains étendent ce principe à tout types définis par l'utilisateur (struct, enum, union, typedef, etc). À une époque je le faisais pour mes structures en C, mais maintenant j'utilise un autre formalisme.

Dernière modification par grim7reaper (Le 22/07/2010, à 19:48)

Pylades · Le 22/07/2010, à 20:01

Les unions, c’est encore utilisé ce truc ? Parce que pour moi, à part être compliqué, ça n’apporte pas grand-chose… Enfin bref…

Sinon, c’est quoi ton formalisme ?

tshirtman · Le 22/07/2010, à 20:09

La PEP8 de python, qui est la convention de base pour coder, demande aussi l'utilisation de majuscules pour les classes, mais l'interpréteur ne l'impose pas.

grim7reaper · Le 22/07/2010, à 20:22

Pylade a écrit :

Les unions, c’est encore utilisé ce truc ? Parce que pour moi, à part être compliqué, ça n’apporte pas grand-chose… Enfin bref…

Utilisé fréquemment (Xlib, SDL, GTK+, GDK, etc).
Ça peut-être utile dans certains cas (du moins en C, en C++ c'est beaucoup plus rare je pense).

Sinon, c’est quoi ton formalisme ?

J'ai un formalisme à géométrie variable car je ne suis jamais totalement satisfait >_<. Depuis quelques temps j'ai réussi à me fixer (définitivement, peut-être…).
Sinon, pour les types que je définis j'utilise des suffixes (_s, _e, _u et _a). Pour la majuscule, je vais peut-être y revenir (je les ai utilisées pour mon dernier projet, histoire de voir et mine de rien c'est pas mal au niveau visuel quand même…)
À voir…

Dernière modification par grim7reaper (Le 22/07/2010, à 20:29)

nesthib · Le 22/07/2010, à 20:51

pour le coup je m'y suis mis un peu aussi (à ruby) c'est vrai que c'est sympa mais je préfère quand même la syntaxe du python pour le moment (et puis c'est vrai que l'interpréteur de base est assez limité… t'en aurais pas un mieux à conseiller ouranos ?)

Pylades · Le 22/07/2010, à 22:27

grim7reaper a écrit :

Pylade a écrit :
Les unions, c’est encore utilisé ce truc ? Parce que pour moi, à part être compliqué, ça n’apporte pas grand-chose… Enfin bref…
Utilisé fréquemment (Xlib, SDL, GTK+, GDK, etc).
Ça peut-être utile dans certains cas (du moins en C, en C++ c'est beaucoup plus rare je pense).

Il y a quelque chose qui fait que ça ne soit que des bibliothèques graphiques que tu cites, ou c’est par hasard ?
Enfin bon, j’ai du mal à voir l’intérêt ou une valeur sémantique particulière dans les unions, et en plus ça introduit le besoin d’être certain du type utilisé lors de la dernière affectation, du coup j’ai peur que cela ne soit une source importante de bugs. Du coup, ça me plaît moyennement.

Et puis surtout, je n’ai jamais éprouvé le moindre besoin d’en utiliser, et je n’en ai vu que dans le K&R. Du coup je ne pensais pas que l’on s’en servait encore. ^^

grim7reaper a écrit :

Pylade a écrit :
Sinon, c’est quoi ton formalisme ?
J'ai un formalisme à géométrie variable car je ne suis jamais totalement satisfait >_<. Depuis quelques temps j'ai réussi à me fixer (définitivement, peut-être…).
Sinon, pour les types que je définis j'utilise des suffixes (_s, _e, _u et _a). Pour la majuscule, je vais peut-être y revenir (je les ai utilisées pour mon dernier projet, histoire de voir et mine de rien c'est pas mal au niveau visuel quand même…)
À voir…

Mouais. Bon, je n’utilise qu’un seul type que j’ai défini, du coup je ne pense pas que ça soit d’une grande utilité chez moi. ^^
Je crois que je vais rester sur les minuscules et les underscores.

Bon, tout de même, je vais vous montrer ce que j’utilise, pour que vous me disiez ce que vous en pensez :

struct option {...};
struct retr {...};   /* à renommer */

extern struct option* new_option(void);
extern int new_long_option(struct option*, char, const char*);
extern int set_short_options(struct option*, const char*, const char*);
extern void delete_option(struct option**);
extern struct option** new_option_table(int);
extern void delete_option_table(struct option***);
extern void delete_return(struct retr**);
extern struct retr* atropt(int, char**, struct option**);

grim7reaper · Le 22/07/2010, à 22:48

Pylade a écrit :

Il y a quelque chose qui fait que ça ne soit que des bibliothèques graphiques que tu cites, ou c’est par hasard ?

Non, ce n'est pas spécifique aux bibliothèques graphiques. Je les ai cités car c'est celle dont je suis sûr (j'ai un peu farfouillé dans leurs sources).
Pour avoir une idée approximative de la fréquence d'utilisation des unions tu peux lancer

grep -Rl 'union {' /usr/include/*

Enfin bon, j’ai du mal à voir l’intérêt ou une valeur sémantique particulière dans les unions, et en plus ça introduit le besoin d’être certain du type utilisé lors de la dernière affectation, du coup j’ai peur que cela ne soit une source importante de bugs. Du coup, ça me plaît moyennement.

C'est pour ça que les unions sont généralement encapsulés dans une structure qui contient un champ type.

Et puis surtout, je n’ai jamais éprouvé le moindre besoin d’en utiliser, et je n’en ai vu que dans le K&R. Du coup je ne pensais pas que l’on s’en servait encore. ^^

Perso, je ne l'ai jamais utilisé (sauf une fois, afin de faire un truc propre malgré les contraintes mal pensées d'un TP). Ça peut servir a manipuler des tableaux, listes,… de types mixte sans passer par les void*.
Bon c'est un exemple bof, mais j'ai pas mieux en tête. Tu peux regarder les codes des libs citées précédemment pour voir des exemples d'applications))

Bon, tout de même, je vais vous montrer ce que j’utilise, pour que vous me disiez ce que vous en pensez :

struct option {...};
struct retr {...};   /* à renommer */

extern struct option* new_option(void);
extern int new_long_option(struct option*, char, const char*);
extern int set_short_options(struct option*, const char*, const char*);
extern void delete_option(struct option**);
extern struct option** new_option_table(int);
extern void delete_option_table(struct option***);
extern void delete_return(struct retr**);
extern struct retr* atropt(int, char**, struct option**);

Pas grand-chose à redire en ce qui me concerne, mon style est assez proche (moi je mets les noms des params même dans les prototypes pour une plus grande clarté).

Pylades · Le 22/07/2010, à 23:03

grim7reaper a écrit :

[…]
Pour avoir une idée approximative de la fréquence d'utilisation des unions tu peux lancer
grep -Rl 'union {' /usr/include/*
[…]

Mouais… C’est du bon gros bricolage, hein. ^^
(Et puis /usr/include/ suffit, sauf si tu les veux par ordre alphabétique. )

grim7reaper · Le 22/07/2010, à 23:16

Pylade a écrit :

Mouais… C’est du bon gros bricolage, hein. ^^

Ma commande : oui ^^.
L'utilisation d'union : non, au moins dans les exemples que j'ai vu (event) dans la Xlib dans la SDL. En C++ ou autres, on aurait fait du polymophisme mais là l'union est une solution relativement élégante.

Dernière modification par grim7reaper (Le 23/07/2010, à 00:16)

Pylades · Le 23/07/2010, à 01:30

glob

compte supprimé · Le 23/07/2010, à 01:36

BN all !

Pylades · Le 23/07/2010, à 03:34

Insomnie…

nesthib · Le 23/07/2010, à 03:37

plop

samυncle · Le 23/07/2010, à 03:48

Compteur du TdCCT · Le 23/07/2010, à 09:42

Scores totaux, depuis le début :

1) 854    samuncle
2) 805    nesthib
3) 775    Pylade
4) 637+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
5) 500    mathieuI
6) 417    cm-t
7) 347    helly
8) 236    \\Ouranos//
9) 193    gnuuat
10) 174    Lagierl
11) 152    tshirtman
12) 121    ǤƦƯƝƬ
13) 93    petifrancais
14) 57    Р'tite G☢gole :mad:
15) 48    edge_one
16) 47    Kanor
17) 44    pierguiard
18) 37    ilagas
19) 30    keny
20) 25    GentooUser
21) 19    Le Rouge
22) 18    Ph3nix_
23) 15    timsy
24) 14    kouskous
25) 13    xapantu
26) 12    stratoboy
26) 12    sailing
28) 11    alexises
29) 10    CROWD
29) 10    Toineo
29) 10    NutMotion
32) 8    Mornagest
33) 7    Vista
34) 6    Zeibux
35) 4    danychou56
35) 4    Neros
35) 4    Biaise
38) 3    gulp
39) 2    SoJaS
39) 2    ceric
41) 1    pfriedK
41) 1    geenux

chart?chs=675x280&cht=p3&chco=d80020,d88000,ffd840,20d820,2080ff,101080,a020d8&chf=bg,s,fbf9f4&chl=01h%20-%2001h59|03h%20-%2003h59|07h%20-%2007h59|10h%20-%2010h59|18h%20-%2018h59|19h%20-%2019h59|20h%20-%2020h59|22h%20-%2022h59|23h%20-%2023h59&chd=t:2,3,1,4,2,3,4,2,2&chp=1.6&chtt=R%C3%A9partition%20des%20posts&chts=606060,16

Compteur du TdCCT · Le 23/07/2010, à 09:42

Scores de la période en cours :

1) 220    nesthib
2) 193    samuncle
3) 190    Pylade
4) 131    Lagierl
5) 123    cm-t
6) 117    \\Ouranos//
7) 112    grim7reaper
8) 91    helly
9) 63    mathieuI
10) 51    Р'tite G☢gole :mad:
11) 37    edge_one
12) 25    tshirtman
13) 20    gnuuat
14) 10    timsy
14) 10    Kanor
16) 2    pierguiard
17) 1    ceric

kamui57 · Le 23/07/2010, à 15:31

Salut

j'ai un fichier texte de ce genre

1.5397e+06 0
3.34842e+07 255

j'aimerais rendre les nombres "normaux"

1539700 0
33484200 255

vous me conseillez quoi ?

Dernière modification par kamui57 (Le 23/07/2010, à 15:33)

Pylades · Le 23/07/2010, à 15:38

T’entends quoi, par « normaux » ?
Si tu veux faire 3.34842e+07 → 33484200, je ferais un petit programme, utilisant le format « %e » de fscanf, puis de réécrirais le fichier avec le format « %f » de fprintf (éventuellement en jouant sur la précision selon la sortie souhaitée).
Bon, c’est la méthode C, il en existe peut-être une plus simple…

kamui57 · Le 23/07/2010, à 15:40

Ah je connaissais pas %e ! Merci, vais voir ça...
Ça marche nickel, merci !

Dernière modification par kamui57 (Le 23/07/2010, à 16:10)

grim7reaper · Le 23/07/2010, à 16:24

kamui57 a écrit :

Ah je connaissais pas %e ! Merci, vais voir ça...
Ça marche nickel, merci !

\o/, peut-être une nouvelle recrue (et qui ne rechigne pas au C \o/).

Bon /me va arrêter d'écrire des conneries et aller coder un peu

kamui57 · Le 23/07/2010, à 16:46

C'est pour mon stage
Ça va me servir à voir si une image a un fond blanc ou noir.

grim7reaper · Le 23/07/2010, à 16:49

kamui57 a écrit :

C'est pour mon stage
Ça va me servir à voir si une image a un fond blanc ou noir.

Tu fais quoi comme étude ?
C'est quoi le sujet de ton stage ?

Edit : tu utilises Archlinux \o/.

Dernière modification par grim7reaper (Le 23/07/2010, à 17:00)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1451 Le 22/07/2010, à 18:46

Re : /* Topic des codeurs couche-tard [1] */

#1452 Le 22/07/2010, à 19:38

Re : /* Topic des codeurs couche-tard [1] */

#1453 Le 22/07/2010, à 19:41

Re : /* Topic des codeurs couche-tard [1] */

#1454 Le 22/07/2010, à 19:48

Re : /* Topic des codeurs couche-tard [1] */

#1455 Le 22/07/2010, à 20:01

Re : /* Topic des codeurs couche-tard [1] */

#1456 Le 22/07/2010, à 20:09

Re : /* Topic des codeurs couche-tard [1] */

#1457 Le 22/07/2010, à 20:22

Re : /* Topic des codeurs couche-tard [1] */

#1458 Le 22/07/2010, à 20:51

Re : /* Topic des codeurs couche-tard [1] */

#1459 Le 22/07/2010, à 22:27

Re : /* Topic des codeurs couche-tard [1] */

#1460 Le 22/07/2010, à 22:48

Re : /* Topic des codeurs couche-tard [1] */

#1461 Le 22/07/2010, à 23:03

Re : /* Topic des codeurs couche-tard [1] */

#1462 Le 22/07/2010, à 23:16

Re : /* Topic des codeurs couche-tard [1] */

#1463 Le 23/07/2010, à 01:30

Re : /* Topic des codeurs couche-tard [1] */

#1464 Le 23/07/2010, à 01:36

Re : /* Topic des codeurs couche-tard [1] */

#1465 Le 23/07/2010, à 03:34

Re : /* Topic des codeurs couche-tard [1] */

#1466 Le 23/07/2010, à 03:37

Re : /* Topic des codeurs couche-tard [1] */

#1467 Le 23/07/2010, à 03:48

Re : /* Topic des codeurs couche-tard [1] */

#1468 Le 23/07/2010, à 09:42

Re : /* Topic des codeurs couche-tard [1] */

#1469 Le 23/07/2010, à 09:42

Re : /* Topic des codeurs couche-tard [1] */

#1470 Le 23/07/2010, à 15:31

Re : /* Topic des codeurs couche-tard [1] */

#1471 Le 23/07/2010, à 15:38

Re : /* Topic des codeurs couche-tard [1] */

#1472 Le 23/07/2010, à 15:40

Re : /* Topic des codeurs couche-tard [1] */

#1473 Le 23/07/2010, à 16:24

Re : /* Topic des codeurs couche-tard [1] */

#1474 Le 23/07/2010, à 16:46

Re : /* Topic des codeurs couche-tard [1] */

#1475 Le 23/07/2010, à 16:49

Re : /* Topic des codeurs couche-tard [1] */

Pied de page des forums