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

grim7reaper · Le 04/11/2010, à 23:45

Il est de retour \o/.

Alors, il avait quoi ?

Dernière modification par grim7reaper (Le 04/11/2010, à 23:46)

Pylades · Le 04/11/2010, à 23:58

Je penche pour une erreur 500 ou un truc du genre…

grim7reaper a écrit :

(Pylade aussi a eu son heure de gloire lorsqu'il a posté les premières versions de sa lib)

Bon, sinon, ce n'est pas obligé de faire un realloc, hein, une seule alloc suffit. Et puis dans ce cas là, on peut se contenter de sizeof WORD à la place de strlen(WORD) + 1, c'est très pratique.

Et non, gnuuat, nous ne t'agressons pas, mais le code propre est préféré sur le TdCCT, sinon on corrige. Je suis désolé si tu t'es senti offensé.

Au fait, grim7reaper, j'aimerais bien que tu m'expliques ce que tu apprécies dans Perl. J'avais essayé il y a deux mois, et j'ai trouvé ça très rebutant. Le truc rédhibitoire, ça a été qu'il n'existe pas de division entière, et qu'il faille faire un truc bien moche pour l'émuler. Alors, j'ai bien perçu la puissance des regex… mais j'ai trouvé ça très moche. T'en penses quoi, de ces considérations ?

Édit : j'ai décidé de te croire sur parole pour l'heure d'édition de ton message.

Dernière modification par Pylade (Le 05/11/2010, à 00:19)

grim7reaper · Le 05/11/2010, à 00:50

Pylade a écrit :

Je penche pour une erreur 500 ou un truc du genre…

Ouais, ça expliquerais le fail de celui du TdCT.

Bon, sinon, ce n'est pas obligé de faire un realloc, hein, une seule alloc suffit.

Ouais c'est vrai, suffit d'allouer suffisamment pour pouvoir accueillir la plus grande des deux (ça évite une réallocation, action qui n'est jamais gratuite même s'il n'y a pas de recopie), mais bon…

Et puis dans ce cas là, on peut se contenter de sizeof WORD à la place de strlen(WORD) + 1, c'est très pratique.

Ptain ouais, quel con (décidément, aujourd'hui c'était ma journée >_<). C'est vrai que là on bosse sur un tableau et non pas un pointeur.
Bien vu .

*** Attention : Pavé en approche ***

Au fait, grim7reaper, j'aimerais bien que tu m'expliques ce que tu apprécies dans Perl. J'avais essayé il y a deux mois, et j'ai trouvé ça très rebutant. Le truc rédhibitoire, ça a été qu'il n'existe pas de division entière, et qu'il faille faire un truc bien moche pour l'émuler. Alors, j'ai bien perçu la puissance des regex… mais j'ai trouvé ça très moche. T'en penses quoi, de ces considérations ?

Bon tout d'abord, je pense que mon avis est forcément un peu biaisé vu que c'est le premier langage de script que j'ai appris (tout comme le C est le premier langage que j'ai appris).

Ce que j'aime dans ce langage c'est que la syntaxe est vraiment libre ce qui permet d'adapter plus facilement le code selon nos critères esthétiques. Mais cela implique aussi de faire attention afin de garder un code lisible.
L'approche est aussi différente par rapport à d'autres langages, ça doit venir du fait qu'il a été mis au point par un linguiste (ce qui se voit grâce au sigil entre autre : $ est pour le singulier et @ pour le pluriel ^^).

J'adore aussi toutes les petites fonctionnalités "cachés" ($_, opérateur secrets tel que l'eskimo greeting, le flaming X-Wing ou encore la double-bladed killer orc sword ). C'est en partie elles qui valent à Perl sa réputation 'read-only' car ce n'est pas forcément simple à lire quand on débute ou que l'on ne connaît pas certaines subtilités, mais franchement des fois c'est le pied (il ne faut pas en abuser, mais il y a moyen d'être très expressif avec peu de symbole).

L'adaptation au contexte aussi est sympa, même si ça peut porter à confusion quand on débute.
Un exemple :

@t = (3, 7, 33, 42, 77);
@v = @t;                   # tableau en contexte de liste : copie de tableau
$n = @t;                   # tableau en contexte scalaire : $n contient le nombre d'éléments de @t, soit 5
($a, $b, $c, $d, $e) = @t; # tableau en contexte de liste : $a contient 3, $b contient 7, etc.
($f) = @t;                 # tableau en contexte de liste : $f contient 3.
$g = $b;                   # scalaire en contexte scalaire : $g contient $b.
@w = $a;                   # scalaire en contexte de liste : @w a un élément, $a.

Pour la division entière c'est dû au système de typage (il n'y a pas de type int ou float). Mais bon c'est pas non plus super moche de faire

int(5/2)

Ça ressemble un peu à un cast en C.

Pour les regexp, j'adore c'est super balèze mais c'est sûr que ça devient vite difficile à lire. Avec un peu d'expérience ça se lit un peu plus facilement, mais bon on ne fait pas non plus des miracles. D'où l'intérêt de les commenter et/ou de mettre un exemple de chaîne sur laquelle on va bosser et ce que l'on veut extraire.

Par contre, je te rejoins sur l'aspect esthétique (pas seulement niveau regexp), je trouve toujours mon code Perl "moche" (comparé à un code C par exemple) même si le code en lui-même est propre. Mais bon, je n'ai jamais eu un bon feeling avec les langages de script de toute façon.

Un dernier point, l'orienté objet en Perl.
Je n'aime pas vraiment comment c'est implémenté (c'est assez déroutant) et on voit que ce n'était pas prévu à l'origine dans le langage. Il y a une espèce de sensation de truc bancal, genre bricolé à l'arrache mais ce n'est pas le cas, il y a bien presque ce qu'il faut et il y a même l'héritage multiple (on aime ou on n'aime pas, mais c'est dispo). Mais c'est vraiment de l'orienté objet qui est très différent des autres de par son fonctionnement. Tout ça a été revu pour Perl 6 et ce n'est pas un mal .

Sinon tout ce que j'ai dit précédemment s'applique à Perl 5, le 6 je ne l'ai pas encore trop regardé (c'est un tout nouveau langage de toute manière, quasiment rien à voir avec Perl 5).

Au finale, je ne conseille pas particulièrement le Perl (mais je ne le déconseille pas non plus) car je conçois qu'il n'est pas fait pour tous les goûts, faut aimer cette espèce de liberté qu'il offre. En général, le Perl on aime ou on déteste ^^ .

Édit : j'ai décidé de te croire sur parole pour l'heure d'édition de ton message.

Merci, au pire mon édit sur le TdCT prouve que j'étais éveillé à 3h. Après pour les points, je n'exige pas réparation car après tout c'est moi qui est merdé tout seul donc je laisse ça à votre appréciation.

Dernière modification par grim7reaper (Le 05/11/2010, à 01:04)

gnuuat · Le 05/11/2010, à 01:08

Pareil que sur l'autre post

Кຼزດ · Le 05/11/2010, à 02:36

Points.

cm-t · Le 05/11/2010, à 03:00

'Nuit;

nesthib · Le 05/11/2010, à 03:00

plop

samυncle · Le 05/11/2010, à 03:45

Compteur du TdCCT · Le 05/11/2010, à 07:42

Scores totaux, depuis le début :

1) 1761    nesthib
2) 1700    samuncle
3) 1449    Pylade
4) 1047    Кຼزດ
5) 873    cm-t
6) 713+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
7) 676    Р☢w ! ✰ :mad: ✰ (эй !)
8) 662    \\Ouranos//
9) 636    helly
10) 367    Lagierl
11) 310    gnuuat
12) 266    tshirtman
13) 167    Kanor
14) 136    Askelon
15) 121    ǤƦƯƝƬ
16) 93    petifrancais
17) 78    edge_one
18) 72    nathéo
19) 70    gulp
20) 66    pierguiard
21) 59    kamui57
22) 50    The Uploader
23) 37    ilagas
24) 30    keny
25) 27    Le Rouge
26) 25    GentooUser
27) 24    ไ୦บเઢ'
28) 20    Morgiver
28) 20    CROWD
30) 18    Ph3nix_
30) 18    xapantu
32) 15    timsy
33) 14    kouskous
34) 12    stratoboy
34) 12    sailing
36) 11    alexises
36) 11    Crocoii
38) 10    Toineo
38) 10    NutMotion
38) 10    pseudovingtcinqcaracteres
38) 10    pfriedZ
42) 8    Mornagest
43) 7    Vista
44) 6    Zeibux
44) 6    ubuntlin
44) 6    asma.geek
47) 5    tendances-tdct
48) 4    danychou56
48) 4    Neros
48) 4    Biaise
48) 4    totoflute
48) 4    pinballyoda ㋛
53) 2    SoJaS
53) 2    ceric
55) 1    geenux

chart?chs=675x280&cht=p3&chco=d80020,d88000,ffd840,20d820,2080ff,101080,a020d8&chf=bg,s,fbf9f4&chl=00h%20-%2000h59|01h%20-%2001h59|02h%20-%2002h59|03h%20-%2003h59|07h%20-%2007h59|09h%20-%2009h59|15h%20-%2015h59|22h%20-%2022h59|23h%20-%2023h59&chd=t:1,1,1,3,1,1,1,1,3&chp=1.6&chtt=R%C3%A9partition%20des%20posts&chts=606060,16

Compteur du TdCCT · Le 05/11/2010, à 07:42

Scores de la période en cours :

1) 40    samuncle
1) 40    nesthib
1) 40    nathéo
4) 35    grim7reaper
5) 27    cm-t
6) 24    Кຼزດ
7) 21    gnuuat
8) 14    Pylade
9) 10    tshirtman
10) 8    \\Ouranos//
11) 7    Lagierl
12) 6    Askelon
13) 3    Kanor

Pylades · Le 05/11/2010, à 18:56

Ouais, je comprends. Je vois la puissance du langage. Mais il faut aimer…

grim7reaper a écrit :

[…]
Pour la division entière c'est dû au système de typage (il n'y a pas de type int ou float). Mais bon c'est pas non plus super moche de faire
int(5/2)
Ça ressemble un peu à un cast en C.
[…]

Mais bon, je trouve que ce n'est pas beau du tout.D'autant plus que je me demande si cela ne pourrait pas être une source de bug sur les grands nombres…

Bon, sinon Perl 6 a un typage statique disponible. Du coup je vais peut-être attendre qu'il soit possible de faire un simple yaourt -S perl6 pour m'y mettre ; d'autant plus qu'il semble qu'il y ait eu de nombreuses autres améliorations. On va voir, pour le moment je n'ai pas trop envie de m'y replonger (je dois bosser ><').

Dernière modification par Pylade (Le 05/11/2010, à 18:57)

grim7reaper · Le 05/11/2010, à 19:14

Pylade a écrit :

Ouais, je comprends. Je vois la puissance du langage. Mais il faut aimer…

Voilà, c'est tout à fait ça.

Mais bon, je trouve que ce n'est pas beau du tout.D'autant plus que je me demande si cela ne pourrait pas être une source de bug sur les grands nombres…

Sans inférence de type il n'y a pas vraiment d'autre solution. Sinon je ne pense pas que ça soit source de bug (mais faudrait voir comment c'est géré en interne ou faire des tests pour en être sûr).
Mais bon, le Perl n'est clairement pas adapté pour mettre au point des programmes avec beaucoup de calculs (ou des programmes de maths, style analyse numérique par exemple)

Bon, sinon Perl 6 a un typage statique disponible. Du coup je vais peut-être attendre qu'il soit possible de faire un simple yaourt -S perl6 pour m'y mettre ; d'autant plus qu'il semble qu'il y ait eu de nombreuses autres améliorations. On va voir, pour le moment je n'ai pas trop envie de m'y replonger (je dois bosser ><').

Faudra attendre un peu je pense, ça fait un moment que c'est en gestation. D'ailleurs, heureusement qu'Audrey Tang à sortie Pugs pour faire avancer le bordel. Depuis ça avance beaucoup mieux .
Pour les nouveautés, ouais il y en a énormement. Comme je disais, c'est limite un nouveau langage.
Tiens, une bonne news (dont j'avais déjà donné le lien et que tu as donc peut-être déjà lu) sur le sujet.

Sinon, yaourt ? Tu es (ou tu comptes) passez sur Arch ?

Dernière modification par grim7reaper (Le 05/11/2010, à 19:15)

Pylades · Le 05/11/2010, à 19:32

Oui, je me souviens avoir lu cette news, au moins partiellement.

Et je compte me faire une Arch (et une Debian aussi) dès que j'aurai un DDE.

xapantu · Le 05/11/2010, à 19:45

Je suis en train de regarder un programme et je tombe là dessus :

gint cb_save_recent_files_list(GSList *list)
{
  gchar *path_list;
  FILE *f;
  GSList *node;
  gint i;
      
  if (list!=NULL)
    {
      path_list=g_strdup_printf("%s/.ellarecentfiles",getenv("HOME"));
      f=fopen(path_list,"w");
      for(i = 0; node = g_slist_nth(recent_files_list, i); i++)
        {
            fprintf(f,"%s\n",(gchar *)(node->data));
        }
      fclose(f);
      g_free(path_list);    
      return 0;
    }    
  else
    return -1;    
}

Quel est l'intérête d'utiliser un gint au lieu d'un int ?! Aucun ?

edit : Et est-ce qu'il y a un intérêt à utiliser un int au lieu d'un gint ?

Dernière modification par xapantu (Le 05/11/2010, à 19:47)

grim7reaper · Le 05/11/2010, à 20:01

Aucun, si ce n'est d'être homogène avec le reste de la GLib.

C'est strictement la même chose. D'ailleurs, dans le header glib/gtypes.h on trouve

typedef int    gint;

Du coup, aucun intérêt à utiliser un int au lieu d'un gint. Par contre, selon les applis, il peut être intéressant d'utiliser les types du genre gint8, gint32, etc.

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

xapantu · Le 05/11/2010, à 20:12

grim7reaper a écrit :

Aucun, si ce n'est d'être homogène avec le reste de la GLib.
C'est strictement la même chose. D'ailleurs, dans le header glib/gtypes.h on trouve
typedef int    gint;
Du coup, aucun intérêt à utiliser un int au lieu d'un gint. Par contre, selon les applis, il peut être intéressant d'utiliser les types du genre gint8, gint32, etc.

ok merci

Pylades · Le 05/11/2010, à 20:12

Ouais, mais à ce niveau-là, les types de stdint.h sont tout de même plus portables.

grim7reaper · Le 05/11/2010, à 20:20

Pylade a écrit :

Ouais, mais à ce niveau-là, les types de stdint.h sont tout de même plus portables.

En quoi ?
Équivalent à la limite je veux bien. Sachant que les types du genre intN_t ou uintN_t n'existent que depuis C99 et leur présence n'est pas exigé par la norme.

ISO/IEC 9899:TC3 Committee Draft -- Septermber 7, 2007 a écrit :

7.18.1.1 Exact-width integer types
1 The typedef name intN_t designates a signed integer type with width N , no padding
bits, and a two's complement representation. Thus, int8_t denotes a signed integer
type with a width of exactly 8 bits.
2 The typedef name uintN_t designates an unsigned integer type with width N . Thus,
uint24_t denotes an unsigned integer type with a width of exactly 24 bits.
3 These types are optional. However, if an implementation provides integer types with
widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a
two's complement representation, it shall define the corresponding typedef names.
7.18.1.2 Minimum-width integer types
1 The typedef name int_leastN_t designates a signed integer type with a width of at
least N , such that no signed integer type with lesser size has at least the specified width.
Thus, int_least32_t denotes a signed integer type with a width of at least 32 bits.
2 The typedef name uint_leastN_t designates an unsigned integer type with a width
of at least N , such that no unsigned integer type with lesser size has at least the specified
width. Thus, uint_least16_t denotes an unsigned integer type with a width of at
least 16 bits.
3 The following types are required:
int_least8_t uint_least8_t
int_least16_t uint_least16_t
int_least32_t uint_least32_t
int_least64_t uint_least64_t
All other types of this form are optional.

Donc plus portable je me demande .

De toute façon, quitte a utiliser GLib autant rester homogène .

Dernière modification par grim7reaper (Le 05/11/2010, à 20:30)

compte supprimé · Le 05/11/2010, à 21:19

Bn;

nathéo · Le 05/11/2010, à 22:06

10 points…

Pylades · Le 05/11/2010, à 22:38

Ben stdint.h, ça apparaît dans la norme. Même si ce n'est que depuis C99, même si ce n'est qu'optionnel, ça apparaît. Alors qu'utiliser la GLib pour le plaisir, bof… Tout le monde n'est pas sensé en disposer. Bon, après je suis bien entendu conscient que quand tu en as vraiment besoin pour autre chose, mieux vaut utiliser gint32 et ses copains. ^^

grim7reaper · Le 05/11/2010, à 23:27

Nan mais je suis totalement d'accord qu'il vaut mieux utiliser stdint que GLib si l'on veux juste des types à taille fixe (parce que GLib c'est quand même bien plus que ça).

Mais si j'ai mis "quitte a utiliser GLib" c'est parce que le code de xapantu vient d'Ella un logiciel codé en GTK+ (donc avec la GLib d'office) par un gars du forum, alors quitte à l'utiliser autant utiliser ses types (c'est ça que j'ai voulu dire) .

Dernière modification par grim7reaper (Le 05/11/2010, à 23:33)

Pylades · Le 05/11/2010, à 23:39

OK. ^^

http://gitorious.org/libstropt/
Bon, c'est peut-être libre, Gitorious, mais c'est lent. Mais bon, pas grave, je préfère ça.

\\Ouranos// · Le 05/11/2010, à 23:53

grim7reaper · Le 05/11/2010, à 23:59

Cool, jme suis rappelé comment fallait faire en C pour passer les membres d'une structure en private (enfin, émuler le private des langages orienté objets) et ainsi empêcher l'utilisateur de foutre ses sales pattes dans les attributs (au risque de tout péter).

Un

const char test[] = "Hello World!";
Str str = Str_new_with_text(test);
str->mlen_ = 42;

donne

erreur: déréférencement d'un pointeur de type incomplet

\o/

Dernière modification par grim7reaper (Le 06/11/2010, à 00:04)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1076 Le 04/11/2010, à 23:45

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

#1077 Le 04/11/2010, à 23:58

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

#1078 Le 05/11/2010, à 00:50

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

#1079 Le 05/11/2010, à 01:08

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

#1080 Le 05/11/2010, à 02:36

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

#1081 Le 05/11/2010, à 03:00

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

#1082 Le 05/11/2010, à 03:00

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

#1083 Le 05/11/2010, à 03:45

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

#1084 Le 05/11/2010, à 07:42

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

#1085 Le 05/11/2010, à 07:42

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

#1086 Le 05/11/2010, à 18:56

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

#1087 Le 05/11/2010, à 19:14

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

#1088 Le 05/11/2010, à 19:32

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

#1089 Le 05/11/2010, à 19:45

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

#1090 Le 05/11/2010, à 20:01

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

#1091 Le 05/11/2010, à 20:12

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

#1092 Le 05/11/2010, à 20:12

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

#1093 Le 05/11/2010, à 20:20

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

#1094 Le 05/11/2010, à 21:19

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

#1095 Le 05/11/2010, à 22:06

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

#1096 Le 05/11/2010, à 22:38

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

#1097 Le 05/11/2010, à 23:27

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

#1098 Le 05/11/2010, à 23:39

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

#1099 Le 05/11/2010, à 23:53

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

#1100 Le 05/11/2010, à 23:59

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

Pied de page des forums