Ubuntu-fr

Rolinh

Re : /* Topic des codeurs [7] */

Cela dit, si tu as des questions tu sais où les poser

C'est bien connu par ici que tu es une référence en ce qui concerne le C (et pas que le C d'ailleurs!).

Sinon, si tu es OK pour ma proposition de gestion des formats de sortie je peux déjà adapter le code existant (sortie console en texte simple) pour qu’il utilise cette architecture et te soumettre un patch.

Pour l'idée je suis d'accord. En revanche, j'ai pour habitude de ne pas utiliser de typedef car je trouve que cela obscurci le code.
Ceci dit, merci pour ta proposition que j'accepte bien volontiers.

grim7reaper

Re : /* Topic des codeurs [7] */

Cela dit, si tu as des questions tu sais où les poser

C'est bien connu par ici que tu es une référence en ce qui concerne le C (et pas que le C d'ailleurs!).

Merci.
Mais je suis une référence que sur ce forum, à mon modeste niveau. Il y a des gens bien plus compétents que moi dans le vaste Internet.

Sinon, si tu es OK pour ma proposition de gestion des formats de sortie je peux déjà adapter le code existant (sortie console en texte simple) pour qu’il utilise cette architecture et te soumettre un patch.

Pour l'idée je suis d'accord. En revanche, j'ai pour habitude de ne pas utiliser de typedef car je trouve que cela obscurci le code.
Ceci dit, merci pour ta proposition que j'accepte bien volontiers.

Bah si tu veux, je le fais sans typedef, mais pour le coup j’en ai mis pour la lisibilité (parce que les pointeurs de fonction brut, c’est pas super lisible).
Donc tu me dis, et je fais comme tu le souhaites

Après, mon avis perso c’est que les typedef c’est plus clair. Dans l’absolu, l’utilisateur n’a pas besoin de savoir si c’est une structure, une énumération, une union, un type primitif ou que sais-je. C’est un détail d’implémentation, et à la limite c’est mieux de le cacher (ça permet de changer plus facilement par la suite).

Édit : Sinon, j’ai vu que pour tes gardiens tu utilises (comme beaucoup de gens en fait) la forme FILENAME_H. Personnellement j’évite cette forme et je préfère H_FILENAME (plus d’autres trucs, mais ça c’est pour ma maniaquerie personelle) pour la simple et bonne raison que les identifiants commençant par E[0-9] ou E[A-Z] sont réservé par POSIX (source : http://pubs.opengroup.org/onlinepubs/00 … 02_02.html, section 2.2.2 The Name Space) et que si ton nom de fichier commence par un 'e' tu pourrais potentiellement (maintenant ou dans le futur) être en conflit avec un identifiant POSIX (et du coup ton gardien serait inutile, c’est un peu dommage).
C’est aussi pour cette raison que tout ceux qui suffixent "_t" au nom de leurs structures ou de leur typedef sont pas très malin…

Dernière modification par grim7reaper (Le 31/03/2012, à 19:59)

---

Blog

tshirtman

Re : /* Topic des codeurs [7] */

@grim: je crois que ton idée est le principe du design pattern Factory, tu construit un renderer ayant une interface générique en utilisant des pièces adaptées au type de rendu, non?

---

Le blog de tshirtman, du python, du shell, du libre, et d'autres choses.
Mon petit frère écrit des trucs biens!
Ultimate smash friends, un smash bros like, libre paquet natty!

grim7reaper

Re : /* Topic des codeurs [7] */

Effectivement, ça reprend bien le principe du design pattern Factory
Je me disais bien que mon idée ressemblait à un design pattern, mais je n’arrivais plus à me rappeler lequel ^^

---

Blog

Rolinh

Re : /* Topic des codeurs [7] */

Bah si tu veux, je le fais sans typedef, mais pour le coup j’en ai mis pour la lisibilité (parce que les pointeurs de fonction brut, c’est pas super lisible).
Donc tu me dis, et je fais comme tu le souhaites

Ça sera sans typedef m'sieu siouplait Ton idée ainsi que ton initiative me plaisent beaucoup.

Après, mon avis perso c’est que les typedef c’est plus clair. Dans l’absolu, l’utilisateur n’a pas besoin de savoir si c’est une structure, une énumération, une union, un type primitif ou que sais-je. C’est un détail d’implémentation, et à la limite c’est mieux de le cacher (ça permet de changer plus facilement par la suite).

Un avis parfaitement justifié... mais je ne le partage pas. Si je voulais cacher les choses, j'utiliserais un langage orienté-objet et pas du C.

Édit : Sinon, j’ai vu que pour tes gardiens tu utilises (comme beaucoup de gens en fait) la forme FILENAME_H. Personnellement j’évite cette forme et je préfère H_FILENAME (plus d’autres trucs, mais ça c’est pour ma maniaquerie personelle) pour la simple et bonne raison que les identifiants commençant par E[0-9] ou E[A-Z] sont réservé par POSIX (source : http://pubs.opengroup.org/onlinepubs/00 … 02_02.html, section 2.2.2 The Name Space) et que si ton nom de fichier commence par un 'e' tu pourrais potentiellement (maintenant ou dans le futur) être en conflit avec un identifiant POSIX (et du coup ton gardien serait inutile, c’est un peu dommage).
C’est aussi pour cette raison que tout ceux qui suffixent "_t" au nom de leurs structures ou de leur typedef sont pas très malin…

J'ai pas encore eu le temps de toute lire ton lien mais j'avoue que je n'ai pas tout compris de ta remarque.

grim7reaper

Re : /* Topic des codeurs [7] */

Ça sera sans typedef m'sieu siouplait Ton idée ainsi que ton initiative me plaisent beaucoup.

Pas de soucis .
Bon, par contre faut modifier 2-3 trucs dans l’architecture de dfc car c’est trop monolithique. J’ai commencé un petit bout hier avec la liste, faudrait aussi virer les flags en static (vu que la portée est limité et que tu les utilises dans les fonctions disp_*).
Comme les globales je suis vraiment pas pour, je serais pour faire une structure Context ou Flags ou que-sais-je qui contiendrai les flags et qui serais passé en paramètre aux fonctions disp_* ou qui serait membre de la structure Display (je peux m’en charger aussi, je te fais un patch et après tu adaptes à ta convenance si ça te convient pas tout à fait )

Après, mon avis perso c’est que les typedef c’est plus clair. Dans l’absolu, l’utilisateur n’a pas besoin de savoir si c’est une structure, une énumération, une union, un type primitif ou que sais-je. C’est un détail d’implémentation, et à la limite c’est mieux de le cacher (ça permet de changer plus facilement par la suite).

Un avis parfaitement justifié... mais je ne le partage pas. Si je voulais cacher les choses, j'utiliserais un langage orienté-objet et pas du C.

Bof, je trouve pas ton raisonnement très juste.
Tu caches déjà des choses en utilisant le C, en poussant un peu tu pourrais utiliser l’assembleur au lieu du C. Les types abstraits ça existe en C, c’est pas spécifique à l’orienté objet (FILE dans la bibliothèque standard, pid_t dans POSIX, etc)

J'ai pas encore eu le temps de toute lire ton lien mais j'avoue que je n'ai pas tout compris de ta remarque.

Si tu as un fichier error.h, tu auras le gardien ERROR_H, or c’est un peu problématique sachant que POSIX se réserve tout les identifiants commençant par E[0-9] ou E[A-Z] (Cf. lien).
Alors même si c’est peut probable d’avoir un conflit un jour, par principe je met H en premier (car POSIX ne réserve pas les identifiants commençant par H).

Dernière modification par grim7reaper (Le 01/04/2012, à 12:03)

---

Blog

Pylades

Re : /* Topic des codeurs [7] */

Qu’est-ce que tu ne comprends pas ?

Les identificateurs en E([0-9]|[A-Z])+, c’est réserve par POSIX (et pas que, par le C standard aussi, en tous cas pour E[A-Z]+, pour ce que je m’en rappelle). Donc le truc, c’est d’éviter de les utiliser accidentellement, donc mieux vaut commencer ses gardiens par H.

Je ne sais pas si j’ai été beaucoup plus clair, mais bon…
Et grillé, en plus…

Dernière modification par Πυλάδης (Le 01/04/2012, à 11:53)

---

“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
                Linus Torvalds – 12 janvier 2003

Rolinh

Re : /* Topic des codeurs [7] */

Bon, par contre faut modifier 2-3 trucs dans l’architecture de dfc car c’est trop monolithique.

Oui, c'est vrai. Il faut dire que la version 2.3.0 fait déjà 1211 lignes mais que je n'avais jamais prévu en arriver là! C'était juste un petit programme pour le fun...
Donc c'est clair, je vais réorganiser un peu tout ça et je t'avoue avoir déjà pensé à remanier suivant ta suggestion.

J’ai commencé un petit bout hier avec la liste, faudrait aussi virer les flags en static (vu que la portée est limité et que tu les utilises dans les fonctions disp_*).
Comme les globales je suis vraiment pas pour, je serais pour faire une structure Context ou Flags ou que-sais-je qui contiendrai les flags et qui serais passé en paramètre aux fonctions disp_* ou qui serait membre de la structure Display

Dans ce contexte, l'utilisation de globales de ne parait pas inappropriée. Les flags sont setté au début et jamais retouché ensuite, c'est un principe.  Passer un structure contenant les flags me parait un peu trop pénible pour pas de gains au final.

Tu caches déjà des choses en utilisant le C, en poussant un peu tu pourrais utiliser l’assembleur au lieu du C. Les types abstraits ça existe en C, c’est pas spécifique à l’orienté objet (FILE dans la bibliothèque standard, pid_t dans POSIX, etc)

Oui, tu pousses un peu là. Je pense que tu as compris où je voulais en venir.

Si tu as un fichier error.h, tu auras le gardien ERROR_H, or c’est un peu problématique sachant que POSIX se réserve tout les identifiants commençant par E[0-9] ou E[A-Z] (Cf. lien).
Alors même si c’est peut probable d’avoir un conflit un jour, par principe je met H en premier (car POSIX ne réserve pas les identifiants commençant par H).

Ok, c'est vrai. Merci pour l'explication.

Sinon, dfc est déjà dans les ports FreeBSD!

grim7reaper

Re : /* Topic des codeurs [7] */

Dans ce contexte, l'utilisation de globales de ne parait pas inappropriée. Les flags sont setté au début et jamais retouché ensuite, c'est un principe.

Le problème c’est que ça tu ne peux pas le garantir (et on est jamais à l’abri d’une typo’), et en cas de soucis bah ça a pu être modifié n’importe où. Avec une structure, ça limite déjà le champ d’investigation aux fonctions qui prennent la structure en paramètre.
Après oui, si toutes les fonctions utilisent la structure, tu n’es pas plus avancé et autant utiliser des globales.

Passer un structure contenant les flags me parait un peu trop pénible pour pas de gains au final.

Pour éviter ça, tu peux la passer en arguments lors de la création de la structure Display, comme ça pas besoin de la passer à chaque appel des fonctions disp_*

Tu caches déjà des choses en utilisant le C, en poussant un peu tu pourrais utiliser l’assembleur au lieu du C. Les types abstraits ça existe en C, c’est pas spécifique à l’orienté objet (FILE dans la bibliothèque standard, pid_t dans POSIX, etc)

Oui, tu pousses un peu là. Je pense que tu as compris où je voulais en venir.

Oui, je caricature évidemment.

---

Blog

Pylades

Re : /* Topic des codeurs [7] */

Hey, sinon, je me suis dit qu’il faudrait que change le nom de ma bibliothèque sur les options (et que je finisse de la coder, un jour), parce que Libstropt, ça ne veut plus rien dire. J’ai pensé à OptBall, en utilisant OB_ comme préfixe. J’ai fait des recherches sur le nom, et je n’ai rien trouver de bien folichon, donc a priori c’est bon. Des objections ?

---

“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
                Linus Torvalds – 12 janvier 2003

grim7reaper

Re : /* Topic des codeurs [7] */

Ball c’est pourquoi ?

---

Blog

Pylades

Re : /* Topic des codeurs [7] */

C’est pour que ça ressemble un peu a « tarball ».

Oui, je sais, c’est nul, mais j’assume.

---

“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
                Linus Torvalds – 12 janvier 2003

Rolinh

Re : /* Topic des codeurs [7] */

Dans ce contexte, l'utilisation de globales de ne parait pas inappropriée. Les flags sont setté au début et jamais retouché ensuite, c'est un principe.

Le problème c’est que ça tu ne peux pas le garantir (et on est jamais à l’abri d’une typo’), et en cas de soucis bah ça a pu être modifié n’importe où. Avec une structure, ça limite déjà le champ d’investigation aux fonctions qui prennent la structure en paramètre.
Après oui, si toutes les fonctions utilisent la structure, tu n’es pas plus avancé et autant utiliser des globales.

C'est pour ça que tous mes flags portent "flag" dans le nom. Si j'en rencontre un ailleurs que dans le main, je sais pertinemment que faut pas y toucher.

Pour éviter ça, tu peux la passer en arguments lors de la création de la structure Display, comme ça pas besoin de la passer à chaque appel des fonctions disp_*

Oui mais je pense m'en tenir à mes globales.

Rolinh

Re : /* Topic des codeurs [7] */

@Pylade: libstropt je trouve ça parlant pour une lib. En revanche, OptBall ça ne me dit rien a priori. Que propose-t-elle cette bibliothèque?

grim7reaper

Re : /* Topic des codeurs [7] */

C'est pour ça que tous mes flags portent "flag" dans le nom.

Sauf unit, fais gaffe.

Oui mais je pense m'en tenir à mes globales.

Ok, bah je commence à bosser dessus alors

Dernière modification par grim7reaper (Le 01/04/2012, à 13:54)

---

Blog

Pylades

Re : /* Topic des codeurs [7] */

@Pylade: libstropt je trouve ça parlant pour une lib. En revanche, OptBall ça ne me dit rien a priori. Que propose-t-elle cette bibliothèque?

Bah le truc, c’est que str c’était pour « structure », que je maintenant je suis passé à des types opaques ; et qu’en plus j’envisage de faire plus ou moins disparaître mon type LS_Option, en fait de l’utiliser surtout en interne, et de rendre facultatif son usage pour l’utilisateur.

Et sinon, c’est plus ou moins une alternative à getopt (mais et plus haut niveau et orientée objet (même si finalement, ça ne sera pas vraiment de l’objet)), qui me corresponde plus, que je compte faire.

Dernière modification par Πυλάδης (Le 01/04/2012, à 14:05)

---

“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
                Linus Torvalds – 12 janvier 2003

Rolinh

Re : /* Topic des codeurs [7] */

Sauf unit, fais gaffe.

Oui, c'est vrai.

Ok, bah je commence à bosser dessus alors

Merci
De mon côté, je vais splitter les sources selon ta suggestion.

Rolinh

Re : /* Topic des codeurs [7] */

Bah le truc, c’est que str c’était pour « structure »

Ah ouais, alors le nom n'était pas très bien choisit. J'étais persuadé que str tenait pour string...

Et sinon, c’est plus ou moins une alternative à getopt (mais et plus haut niveau et orientée objet (même si finalement, ça ne sera pas vraiment de l’objet)), qui me corresponde plus, que je compte faire.

Qu'apporte-t-elle que ne propose pas déjà getopt(3)?

Pylades

Re : /* Topic des codeurs [7] */

Bah, elle ne fonctionne pas pareil. Avec, on ne fait pas de boucle, on construit un OB_OptBall en lui passant argv, on y enregistre les options dont on a besoin, puis on appelle OB_parse qui renvoie les résultats de son analyse dans OB_Log (ça inclue un tableau des arguments qui ne sont pas des options). Des fonctions pour lire le OB_Log sont fournies. Pour le moment, ça supporte les formes d’options courtes et longues traditionnelles, dont le --. Chaque option peut être modifiée par n’importe quel nombre de switch sur la ligne de commande, qui peuvent affecter ou non une valeur à l’option (voire la forcer pour les formes courtes, comme le -x de GCC), et changer son statut (qui est un int). Chaque option sauvegarde au choix la première, toutes, ou la dernière valeur passée, on peut lui donner des valeurs par défaut…

Enfin bref, elle me correspond plus.

---

“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
                Linus Torvalds – 12 janvier 2003

Rolinh

Re : /* Topic des codeurs [7] */

Merci pour l'explication.
C'est déjà où que l'on peut trouver les sources?

grim7reaper

Re : /* Topic des codeurs [7] */

Ici si j’ai bonne mémoire.

---

Blog

Rolinh

Re : /* Topic des codeurs [7] */

Merci.

Pylades

Re : /* Topic des codeurs [7] */

Un commit en 2012 ?

Je suis productif…

---

“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
                Linus Torvalds – 12 janvier 2003

Rolinh

Re : /* Topic des codeurs [7] */

Bah, sur linuxfr on me fait le reproche du contraire
Enfin, cela concerne plutôt la vitesse à laquelle sont sorties les releases.

grim7reaper

Re : /* Topic des codeurs [7] */

Allez, je m’y remets enfin un peu :

grim7reaper@smile Tests]$runhaskell -i../../../ RunTests.hs
***Egyptian Tests***
Cases: 33  Tried: 33  Errors: 0  Failures: 0
+++ OK, passed 1000 tests.
+++ OK, passed 1000 tests.
***Armenian Tests***
Cases: 33  Tried: 33  Errors: 0  Failures: 0
+++ OK, passed 1000 tests.
+++ OK, passed 1000 tests.
***Weekday Tests***
Cases: 33  Tried: 33  Errors: 0  Failures: 0
+++ OK, passed 1000 tests.
+++ OK, passed 1000 tests.
+++ OK, passed 1000 tests.
+++ OK, passed 1000 tests.
***Gregorian Tests***
Cases: 33  Tried: 33  Errors: 0  Failures: 0
+++ OK, passed 1000 tests.
+++ OK, passed 1000 tests.

En ce moment, écriture de tests. Pas super fun, mais très utile.

---

Blog