Ubuntu-fr

Elzen

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

Le C n’a pas de mascotte.

Donc le C n'a pas une mascotte plus cool que celle de PHP

---

Elzen : polisson, polémiste, polymathe ! (ex-ArkSeth)
Un script pour améliorer quelques trucs du forum.
La joie de t'avoir connu surpasse la peine de t'avoir perdu…
timezone[blocklist]

Pylades

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

Le C est au-dessus de tout ça.

---

“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] */

C’est vrai que le shell de base de Python est pourri quand même, y’a rien même pas de completion (truc de base quand même)

import rlcompleter, readline
readline.parse_and_bind("tab: complete")

(À placer dans un fichier dont l'adresse est indiquée dans la variable d'environnement $PYTHONSTARTUP pour que ce soit lancé automatiquement au démarrage).

Ok, c’est juste bête qu’il faille importer un module et lancer une fonction pour l’avoir. Ça devrait être intégré par défaut.
Car à ce compte-là, irb doit pouvoir faire un truc similaire.
M’enfin c’est toujours bon à savoir, merci pour l’info

dfc(1) ne veut pas compiler avec le support des traductions sous OpenBSD. Si je vous en parle, c'est que je trouve un des warnings assez... marrant.

/usr/local/lib/libintl.so.6.0: warning: stpcpy() is dangerous GNU crap; don't use it

, pas mal.
Cela dit :

This function was added to POSIX.1-2008. Before that, it was not part of the C or POSIX.1 standards, nor customary on UNIX systems, but was not a GNU invention either.  Perhaps  it came from MS-DOS.  It is also present on the BSDs.

on t'a pas appris que c'était mal strcpy? même à l'iut on me disais déjà de prendre strncpy

J’espère bien que non, ça serait une connerie.
strcpy ce n’est pas mal, il faut juste bien l’utiliser (c’est à dire connaître/vérifier la taille des données et/ou prévoir un buffer de la taille adéquate). C’est chiant, mais bon c’est du C (donc gestions des entrées/sorties et chaînes de caractères chiantes).
strncpy ça ne te prévient pas quand ça tronque, et ça bourre avec des octets nuls. Donc pas génial pour vérifier si tu as bien tout copié et ça te fais des copies pour rien si tu mets une taille trop grande…
strncpy n’est pas une version sécurisée de strcpy, faut arrêter avec ça. Les deux fonctions n’ont juste pas les mêmes applications (ce n'est pas que mon point de vue).
strncpy n’apporte pas plus de sécurité, et est source de faille aussi.

D'ailleurs, FreeBSD 10 se passera de GCC au profit de LLVM (mais ça c'est à cause de la GPL3).

Et ils vont faire comment ?
Parce que moi aussi dans l’absolu j’aimerais tenter mais clang dépend de gcc >_< (du moins sur Archlinux, et ça semble ne pas avoir changé depuis ma dernière tentative).
D’ailleurs, clang++ utilise les headers de gcc (et est infoutu de les parser correctement depuis que gcc à changé je ne sais quoi dedans, ce qui le rend inutilisable…).

In file included from main.c++:1:
In file included from ./record.h:15:
In file included from /usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/fstream:39:
In file included from /usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/istream:39:
In file included from /usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ios:42:
In file included from /usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/ios_base.h:40:
/usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ext/atomicity.h:48:45: error: use of undeclared identifier '__ATOMIC_ACQ_REL'
  { return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
                                            ^
/usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ext/atomicity.h:52:38: error: use of undeclared identifier '__ATOMIC_ACQ_REL'
  { __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }

Sinon, un truc drôle avant la dernière mise à jour de clang, il crashait en compilant certains de mes codes C (bon ça c’est corrigé depuis ).

Dernière modification par grim7reaper (Le 21/05/2012, à 06:07)

---

Blog

Rolinh

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

Ouep, après ce warning mon premier réflexe a été d'ouvrir la manpage de stpcpy et je suis tombé sur le même pamphlet.
Ah mon avis, si je me prend ce warning, c'est parce qu'avant la glibc 2.10 et l'inclusion à POSIX, _GNU_SOURCE était requis.

Comment ils vont faire? Bah ce que je sais, c'est que cela fait depuis 2009 que le kernel FreeBSD est compilable avec clang et que FreeBSD 9 compile sans problème avec (voir wiki). Cela devient de toute façon nécessaire puisqu'ils sont bloqués sur la version 4.2.1 de GCC. Ceci dit, cela ne répond pas à ta question... et je suis le premier étonné par le fait que gcc soit une dépendance de clang!

grim7reaper

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

Oui, je sais que clang peut compiler le noyau FreeBSD tout seul comme un grand , mais le truc c’est qu’il à besoin de gcc pour fonctionner (ou du moins de certains bouts), et ça c’est moche. C’est probablement à cause de

GCC is currently the defacto-standard open source compiler today, and it routinely compiles a huge volume of code. GCC supports a huge number of extensions and features (many of which are undocumented) and a lot of code and header files depend on these features in order to build.

While it would be nice to be able to ignore these extensions and focus on implementing the language standards to the letter, pragmatics force us to support the GCC extensions that see the most use. Many users just want their code to compile, they don't care to argue about whether it is pedantically C99 or not.

As mentioned above, all extensions are explicitly recognized as such and marked with extension diagnostics, which can be mapped to warnings, errors, or just ignored.

Après, si on compile soi même clang il est peut-être possible de jeter la compat’ gcc et du coup on n’en a plus besoin. Si oui, c’est probablement ce que les BSD vont faire.

Dernière modification par grim7reaper (Le 21/05/2012, à 07:23)

---

Blog

Rolinh

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

Ouais, sûrement. Même si je trouve cela:

Many users just want their code to compile, they don't care to argue about whether it is pedantically C99 or not.

particulièrement déplorable... Il faut croire que pas mal de dev n'en ont rien à taper des standards, pourvu que ça compile et fonctionne avec les outils qu'ils préfèrent.

tshirtman

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

Bien sur que pleins de devs n'en ont rien à taper des standards, des warnings, des failles potentielles, du formatage du code ou même du fait que leur code soit correct, ils veulent que ça fasse ce pour quoi ils sont payés pour, et n'en ont rien a faire du reste, dans quel monde vous vivez? oO, la plupart des logiciels commerciaux (mais aussi de nombreux logiciels open sources) ont un code tout simplement affreux, mais tant que ça marche, la plupart des gens s'en moquent ! Et certains de ces logiciels au code horrible, imbitable, techniquement faux ou dangereux, n'en sont pas moins un vrai bonheur à utiliser, répondant parfaitement au besoin utilisateur, et sans bugs apparent,  Je n'ai rien contre la qualité de code hein, bien au contraire, mais pleins de gens s'en passent très bien.

Dernière modification par tshirtman (Le 21/05/2012, à 09:31)

---

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!

Rolinh

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

Ben le pire dans tout ça, c'est que ça ne les aide pas puisque cela rend le code difficilement maintenable, produit des bugs, etc.
Je suis peut-être trop tatillon mais il m'arrive régulièrement, en ce qui concerne les petits et moyens projets, de jeter un coup d'œil au code source avant de l'installer.
Par exemple, récemment, je suis tombé sur ce projet sur le forum archlinux et j'ai pensé qu'il pouvait être intéressant.
Donc, premier réflexe: je clone le dépôt, je compile avec des flags strict et *PAF*, je vois des horreurs. J'ai fourni quelques patches au projet mais la qualité du code m'empêche de l'utiliser...
Enfin, c'est pour ça que j'essaie de me retenir d'aller voir les sources afin de m'éviter de passer à côté d'un logiciel sympa à l'utilisation (htop fait partie de ceux-là par exemple: un outil génial mais un code source affreux ).

Dernière modification par Rolinh (Le 21/05/2012, à 09:50)

The Uploader

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

Bien sur que pleins de devs n'en ont rien à taper des standards, des warnings, des failles potentielles, du formatage du code ou même du fait que leur code soit correct, ils veulent que ça fasse ce pour quoi ils sont payés pour, et n'en ont rien a faire du reste, dans quel monde vous vivez? oO, la plupart des logiciels commerciaux (mais aussi de nombreux logiciels open sources) ont un code tout simplement affreux, mais tant que ça marche, la plupart des gens s'en moquent ! Et certains de ces logiciels au code horrible, imbitable, techniquement faux ou dangereux, n'en sont pas moins un vrai bonheur à utiliser, répondant parfaitement au besoin utilisateur, et sans bugs apparent,  Je n'ai rien contre la qualité de code hein, bien au contraire, mais pleins de gens s'en passent très bien.

Chez moi quand la qualité du code est horrible, c'est un nid à bugs. Si ça ne l'est pas, c'est qu'il y a des gens héroïques qui passent des journées cauchemardesques à maintenir le bouzin.

Donc oui quand on est réaliste on s'inquiète de la qualité du code. On peut vivre sans, mais c'est au dépend de l'évolutivité du truc (et dans évolutivité, j'y met aussi le fait de résoudre le moindre bug).

edit : Tiens d'ailleurs ça décrit assez bien PHP : "tant que ça fonctionne, on s'en fiche du reste."

Dernière modification par The Uploader (Le 21/05/2012, à 12:04)

---

- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

tshirtman

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

Chez moi quand la qualité du code est horrible, c'est un nid à bugs. Si ça ne l'est pas, c'est qu'il y a des gens héroïques qui passent des journées cauchemardesques à maintenir le bouzin.

Pour moi aussi, mais il semble que beaucoup de monde, en passant leur temps à résoudre les bugs de façon douloureuse, au lieu de le passer à faire des trucs tout beau tout propres, s'en sortent très bien, et livrent parfois plus vite… oui ça me dépasse aussi, mais je crois savoir que la qualité du code dans les jeux vidéos, par exemple… hum… on va dire qu'ils sont pas là pour ça quoi…

Donc oui quand on est réaliste on s'inquiète de la qualité du code. On peut vivre sans, mais c'est au dépend de l'évolutivité du truc (et dans évolutivité, j'y met aussi le fait de résoudre le moindre bug).

edit : Tiens d'ailleurs ça décrit assez bien PHP : "tant que ça fonctionne, on s'en fiche du reste."

Pas seulement de PHP, oui, mais c'est un sacré nid, en effet ^^

---

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!

HP

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

Donc oui quand on est réaliste on s'inquiète de la qualité du code. On peut vivre sans, mais c'est au dépend de l'évolutivité du truc (et dans évolutivité, j'y met aussi le fait de résoudre le moindre bug).

Ouais… si on veut faire de l'intégration continue, par exemple…

---

cat /dev/urandom >/dev/null 2>&1 #github

Pylades

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

Bon, je ne fais plus que 4,6 s sur les tours d’Hanoï avec ma machine. Je ne pense pas descendre plus bas dans l’immédiat (difficile à cause du buffer infini bi-directionnel) ; en revanche, il reste du proprage de code à faire (sept warnings pour Clang, onze pour gcc).

---

“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] */

Hum, pas mal.
Tu as fait quoi comme optimisation (à part regrouper les additions/soustractions consécutives et les déplacements consécutifs) ?

---

Blog

Pylades

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

Bah je fais ça et je repère les « [-] ». Faudrait que j’essaie d’en rajouter (merci pour la liste que tuas liée, d’ailleurs), mais je ne passe pas énormément de temps dessus et je me concentre plus sur faire un code rapide dans les contraintes que je me suis fixées que sur les optimisations.

D’façons, chuis pas un vrai codeur.

---

“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

Pylades

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

Le simple fait de déplacer la boucle principale dans une fonction à part pour avoir un main de taille raisonnable vient de me faire perdre 0,3 s sur les tours d’Hanoï, youhou !
Ça coûte 0,3 s, un appel de fonction ?

---

“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

The Uploader

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

C'est énorme. O_o

---

- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

grim7reaper

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

Non, c’est beaucoup moins que ça (encore heureux, parce que rien que faire un printf ça fait appel à pas mal de fonctions…)
La perte vient d’ailleurs.

---

Blog

Pylades

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

Mais j’ai juste scindé le main en deux. Je veux bien que je lui passe les structures par copie, mais bon, une structure de deux pointeurs et une structure de deux pointeurs et d’un size_t, ce n’est pas monstrueux non plus. J’ai aussi changé à deux endroits un appel à exit par un appel à die et rajouté un « (void) argc; » dans main, mais ça m’étonnerait beaucoup que ça change les perfs.
C’est incompréhensible. Vous connaissez un outil qui permettrait d’essayer de comprendre ?

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

---

“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] */

Tu peux faire du profilage avec Valgrind sur avant ta modif’ et après, ensuite tu analyses les fichiers générés.

---

Blog

sweetly

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

On peut le récupérer ton code ?

grim7reaper

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

On ne pourra pas le voir tant qu’il ne l’aura pas nettoyé ^^

---

Blog

Rolinh

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

Plop,

bon, il y un truc qui me dépasse: dfc installé dans /usr/local prend bien en compte la traduction française mais installé par le paquet dfc-git de AUR, je ne l'ai plus alors que la traduction est bien là.

dfc-git /etc/
dfc-git /etc/xdg/
dfc-git /etc/xdg/dfc/
dfc-git /etc/xdg/dfc/dfcrc
dfc-git /etc/xdg/dfc/fr/
dfc-git /etc/xdg/dfc/fr/dfcrc
dfc-git /usr/
dfc-git /usr/bin/
dfc-git /usr/bin/dfc
dfc-git /usr/share/
dfc-git /usr/share/doc/
dfc-git /usr/share/doc/dfc/
dfc-git /usr/share/doc/dfc/AUTHORS
dfc-git /usr/share/doc/dfc/HACKING
dfc-git /usr/share/doc/dfc/LICENSE
dfc-git /usr/share/doc/dfc/README
dfc-git /usr/share/doc/dfc/TRANSLATORS
dfc-git /usr/share/licenses/
dfc-git /usr/share/licenses/dfc/
dfc-git /usr/share/licenses/dfc/LICENSE
dfc-git /usr/share/locale/
dfc-git /usr/share/locale/fr/
dfc-git /usr/share/locale/fr/LC_MESSAGES/
dfc-git /usr/share/locale/fr/LC_MESSAGES/dfc.mo
dfc-git /usr/share/man/
dfc-git /usr/share/man/fr/
dfc-git /usr/share/man/fr/man1/
dfc-git /usr/share/man/fr/man1/dfc.1.gz
dfc-git /usr/share/man/man1/
dfc-git /usr/share/man/man1/dfc.1.gz

Ce n'est pas la première fois que je fais face à ce problème mais je n'ai toujours pas trouvé la cause. Si quelqu'un a une piste, une idée ou mieux, une solution, je suis preneur.

xapantu

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

Ah, j'ai une vague idée. Je viens de regarder ton fichier CMake, tu te bases sur le prefix pour obtenir LOCALEDIR. Mais quand tu build avec AUR, yaourt (ou pkgbuild, ou un truc du genre ?) ne met pas le prefix à un truc du genre /tmp/yaourt-1/dfc-git pour ne pas toucher à /usr ? Du coup, tu aurais LOCALEDIR dans /tmp/... et ça ne peut pas marcher. Peut-être qu'il faudrait rajouter une option dans le PKGBUILD.

Rolinh

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

Woaow, c'était rapide!

Tu m'as donné l'idée et je crois bien que j'ai trouvé

EDIT: c'est bon comme ça

Dernière modification par Rolinh (Le 23/05/2012, à 21:19)

tshirtman

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

http://lesjoiesducode.tumblr.com

j'ai bien ris ^^

---

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!