L'équivalent Visual Studio (et il n'y à que le vcxproj, et je n'ai pas viré les sections pour les divers builds comme j'ai fait pour C::B, pour cause de non masochisme):
Je trouve effectivement que Makefile, c'est horrible. Par contre, je trouve CMake très accessible, c'est d'ailleurs en corrigeant un CMakeLists.txt de quelques centaines de ligne en moins de 15 minutes pour générer un .deb, sans le connaître au préalable (juste de nom), que je l'ai adopté.
l'assert est dégagé quand on livre. Contrairement aux exceptions, qui me permettent de logguer avant de crasher fermer violemment en désallouant les éventuelles ressources. Dans certains cas (les std::logic_error et ses filles) ce n'est pas très pertinent, mais quand il s'agit de se fermer après constat d'une erreur dans l'environnement (un fichier vital non trouvé, une entrée "utilisateur" --soyons d'accord: l'utilisateur n'est pas toujours humain…-- foireuse, ce genre de trucs) je trouve plus clair de juste lancer une exception avec un message potable (pour la logguer, c'est assez simple, il suffit de dériver une classe de std::exception, qui loggue automatiquement) que de faire un appel à une fonction pour logguer puis un autre à exit.
le message d'erreur d'une exception est à la possibilité d'être plus parlant. Bon, j'imagine qu'on peut aussi écrire une fonction avec le nom super long et qui renvoie true/false, pour l'emploi dans un assert, mais ça me semble un poil plus pénible.
on peut éventuellement récupérer d'une exception (c'est dégueu, selon moi, mais on me demande parfois de faire de la programmation défensive… à mon corps défendant :/)
Entendons nous bien, encore une fois: quand je lance une exception, ce n'est pas pour que mon programme survive, je ne m'en sers pas comme d'un switch dégueu. Je ne me sers des exceptions que signaler que le programme ne peux plus continuer, et sauver ce qui peut l'être le cas échéant.
Par exemple, imagines un IDE qui, pour une raison ou une autre, à un bug. Si, plutôt qu'utiliser des assert qui imposeront à l'utilisateur d'utiliser un outil en mode déboguage, et donc lent, afin d'avoir des messages d'erreur et qui en plus impliqueront la perte de toutes les données, le développeur utilises des exceptions, alors l'utilisateur peut utiliser une version non débug (plus rapide, moins lourde), avoir un message d'erreur, et en plus récupérer son travail dans l'état juste avant l'anomalie. Ça (peut) évite(r) des sauvegardes automatiques toutes les N minutes, qui seront plus coûteuses.
Après, je t'avoue, je ne maîtrise pas gdb, loin de là (ça ne fait pas longtemps que j'ai abandonné les IDEs) donc c'est possible que ce soit plus intéressant. Mais je viens de faire un test basique, et je ne vois aucun fichier core généré. Tu utilises quoi comme options de compilation (outre le -g, évidemment)?
utilise un simple fichier de configuration (basé sur un format très connu comme json ou xml)
On à des définitions différentes pour deux choses.
1) simple fichier de configuration
2) idéal
Désolé, mais, vraiment, pour être idéal un "simple fichier de configuration" doit être facilement lisible et modifiable par un humain. Ce n'est le cas ni du xml, ni du json, à fortiori quand le fichier en question dépasse les 20 lignes.
Je dirais même plus, les outils basés sur du xml pour la config, me hérissent le poil, et pas juste par principe. J'utilisais un IDE dans le passé. J'en ai même utilisé plus d'un… les uns avec des formats proprios (mais "lisibles" avec un éditeur de texte, les autres avec des formats genre xml/json justement… et force m'est de constater que dès que l'on à plus envie de subir /que l'on ne peut plus utiliser une IHM graphique GTK/Qt/MFC/Whatever, ces choses sont horribles à gérer.
Je ne parlerai même pas de versionner ou differ ce genre d'horreur…
Je suppose que mon opinion différente viens du fait que j'aime pouvoir assembler mon écosystème logiciel moi-même, plutôt qu'être obligé de me reposer sur les choix de quelqu'un d'autre et devoir forker (et donc maintenir) une structure complexe dès que je veux changer customiser un truc dans un sens pas prévu par le(s) dev(s) d'origine.
Ça évite aussi de se taper des bugs très pénibles sans pouvoir changer le composant en un minimum d'efforts, quand ça arrive. Mais c'est vrai que ça nécessite un peu plus de travail pour mettre en place ses outils.
Posté par freem .
En réponse au journal Retour aux sources.
Évalué à 3.
Dernière modification le 29 septembre 2014 à 12:16.
Considérant ça, printf ou un débugger c'est un peu pareil.
Non, un débogueur ne te force pas à recompiler. C'est important quand tu utilises des libs assez lourdes. Et un printf ne te permets pas de lister l'ensemble de l'état de ton programme, et encore moins de revenir en arrière. Choses qu'un dbg te permets.
Mais ça, qu'il soit en ligne de commande (gdb), en ncurses (cgdb), ou graphique (visual, ddd, ollydbg…) ils peuvent tous le faire.
Posté par freem .
En réponse au journal Retour aux sources.
Évalué à 4.
Dernière modification le 29 septembre 2014 à 12:13.
Euh, et sinon, je me permets de rappeler que j'ai écrit cgdb. C'est, franchement, un peu moins inconfortable que gdb, surtout quand on ne connaît ce dernier que de nom. Maintenant, je pourrai m'en sortir un peu, et cgdb reste primitif, mais bon, on fait avec ce qu'on à.
Il existe aussi ddd, plus complet, plus gros, graphique, mais à mon goût dur à prendre en main. Aucun d'eux ne vaut visual studio, qui lui-même n'égale pas vraiment ollydbg (qui, de mémoire, peut afficher le source). Je pourrais également citer quelques ancêtres mais ce serait abusé: windasm, et dans une autre catégorie, softice. Mais ces ancêtres n'ont pas vraiment une IHM des plus modernes…
À mon avis, si linux possède moins d'IHM sympa pour les débuggueurs, c'est pour une raison simple: moins de programmes à reverser (que ce soit pour une raison légale ou pas n'est pas la question) du fait que bien souvent, on à les sources ou ils n'ont pas de prix.
Posté par freem .
En réponse au journal Retour aux sources.
Évalué à 4.
Dernière modification le 29 septembre 2014 à 12:05.
Mouai. En fait, non, c'est pas imbitable. Je sais, mon argument est aussi puissant que le tiens, mais sincèrement, j'ai l'habitude de faire de petites (et nombreuses) classes, et d'être strict avec les contrats des méthodes/fonctions: si un param d'entrée me va pas, je lance une exception avec un message d'erreur. Vu que je ne rattrape que rarement mes exceptions (et pas toutes, en plus, histoire que ça crash bien comme il faut) quand j'ai un bug je sais très très vite d'où ça viens, même sans débuggueur. Ça m'évite la plus grosse part des douleurs.
Et pour ce qui est des structures imbriquées, j'utilise un outil nommé: typedef. Comme ça, c'est tout de suite 1) plus simple à lire et 2) plus court à taper.
Et pour l'auto-complétion, vim s'en sort pas trop mal, excepté c'est vrai, quand j'utilise un framework lourd que je ne connait pas assez. Mais c'est assez rare, et en plus isolé dans une seule "couche" de l'application.
Bon, ça à aussi des avantages niveau ergonomie, si je combine mes terminaux avec un tiling window manager. En fait, sans cet outil, je ne supporterai pas ce mode de fonctionnement et j'utiliserai effectivement un IDE. Mais grâce aux twm, l'IDE c'est mon bureau, et je ne connais pas mieux qu'un twm pour gérer du multi-screen ou pour se passer de la souris, qui est, selon moi, un véritable instrument de torture: c'est lent, peu précis, ça sert à pointer des interfaces qui risquent de changer à la moindre MaJ, et ça nécessite de lâcher le clavier (et les claviers modernes ayant ce foutu pavé numérique, le mouvement de bras n'est pas court).
Perso, c'est quand je passe sur un IDE que je me sens handicapé. Ou avec un gestionnaire de fenêtres classique. Et pourtant, je ne qualifie pas les gens qui s'en servent au quotidien de rétrogrades et non-productifs: j'accepte qu'ils aient une façon de faire différente de la mienne, sûrement plus efficace sur certains points (c'est clair, pour construire une boîte de dialogue, je suis assez emmerdé… par contre, pour switcher entre git, mon source, pondre un script rapide pour tester un truc ou deux, et autres, je pense que ma façon de faire n'est pas mauvaise.
[edit]
Ceci étant dit, il faut admettre que visual à un debugguer qui gère un max.
Bah, les .h(pp) sont inclus plusieurs fois, si tu utilises plusieurs fichiers c(pp) qui l'incluent, ton header sera inclus plusieurs fois (pour un projet donné), et c'est d'ailleurs la principale cause des lenteurs de compilation C++.
Je ne suis pas complètement d'accord (mais en grande partie quand même).
La POO est un vrai paradigme, dans le sens ou le raisonnement est différent de la programmation modulaire plus classique du C (par exemple).
Maintenant, je ne crois pas avoir vu un seul langage réellement OO, et ce, ne serait-ce que parce que de prime abord, l'OS appelle une fonction, et lui passe une liste de chaînes de caractères.
En Java, par exemple, ils utilisent une classe avec une méthode statique pour ça. Pas très pur objet, pas vrai? Si on voulait qu'un langage puisse être réellement pur objet (mais quel intérêt, sérieux?) il faudrait que lors de l'appel du programme on ait une API prédéfinie, genre une classe (et pas une méthode) main, que l'OS instancie en appelant le constructeur, puis dont il appelle une méthode précise (et pas une fonction, comme c'est le cas en Java, parce qu'une méthode statique, c'est bien plus proche d'une fonction dans un namespace, que d'une méthode), et qu'enfin l'OS dés-instancie en passant par le destructeur.
Mais franchement, quel intérêt ça aurait? Les langages "pur objet" me font bien rire, et la façon de faire du C++ (et de bien d'autres langages "bâtards" je pense) est à mon avis la bonne: exposer un certain nombre de façon de programmer, et laisser l'utilisateur faire son truc comme il le veut, en fonction de la situation.
Perso, rien jusqu'a présent n'a réussi à me convaincre que respecter un seul paradigme dans un programme est la meilleure chose à faire pour que le programme soit clair et efficace. C'est même le contraire.
Je te suggère donc un patch, si tu dépends d'une version particulière de boost: find_package(Boost $BOOST_VERSION COMPONENTS $BOOST_COMPONENTS REQUIRED) ;)
Moui. Si on exécute le programme qu'une fois, c'est possible. Si, maintenant, on le lance, disons, une fois par jour… c'est moins certain, beaucoup moins.
C'est un point de vue. Le miens est qu'il vaut mieux avoir plusieurs implémentations pour une même fonctionnalité, car cela permets de ne pas transformer des bugs/comportements indéfinis en pseudo standard. Cela évite aussi l'enfermement.
Je veux pas être méchant, mais tu es mauvaise langue.
Ceci dit, l'actuel unique_ptr est effectivement nettement mieux.
Je passerais outre le fait que tu dises n'avoir trouvé qu'eclipse comme IDE digne de ce nom, genre il plante pas. J'ai vécu l'enfer avec cet outil, pour coder en Java. J'ai un net souvenir d'une auto-complétion hyper longue, qui se déclenchait toute seule (et pas moyen de l'en empêcher, j'ai cherché partout, sauf au bon endroit je suppose) et qui faisait planter la bête si j'osais utiliser mon clavier tant qu'elle avait pas fini.
Bref, comparé à ce bon vieux code::blocks par exemple, que je n'ai que rarement vu planter et ce, probablement parce que j'utilisais la version de nightly, je ne pense pas qu'eclipse vaille la peine. À la rigueur, tu aurais dis netbeans, je t'aurais accordé le bénéfice du doute.
Mais perso, je suis passé à cmake+vim+cgdb, ça marche très bien, c'est léger, réactif, stable et ça n'a pas besoin de serveur graphique (sisi, parfois c'est utile).
Sinon, continue si tu le souhaites, de toute façon la plupart des problèmes de performances ne sont pas dus aux langages, mais aux dev. Après… c'est une évidence pour moi, quand on enlève une couche dans un SI, ça va plus vite et bouffe moins de RAM, si les choses sont faites proprement. Chacun ses goûts et opinions.
PS: vrai que c'est lent ta compilation. Mais ça doit être lié aux lib boost qui sont à base de template. À voir si il n'y à pas moyen d'améliorer ça… en-tête précompilés par exemple?
PPS: ça compile pas ici, je verrai plus tard pour fixer.
Commit: aaa9cbb9c70e
/home/****/superpaflaballe/src/assets.cpp:59:31: note: in instantiation of function template specialization
'boost::property_tree::json_parser::read_json<boost::property_tree::basic_ptree<std::basic_string<char>,
std::basic_string<char>, std::less<std::basic_string<char> > > >' requested here
boost::property_tree::read_json(path, pt_nanim);
^
Pourtant, même si la représentation interne est différente, ils sont pourtant clairement structurés en lignes de texte.
Admettons.
Donc, systemd utilise une représentation sous forme de lignes? Dans ce cas, pourquoi avoir réinventé la roue, surtout quand on sait à quel point systemd avait déjà tendance à hérisser les poils de certains? En quoi les anciens standards n'étaient-ils pas suffisants? 14 standards ce n'était pas assez?
avec ce changement de format
On verra quand j'aurai un systemd en prod. Pour le moment, ce n'est pas le cas. Par contre, oui, c'est clair, ça me ferait bien chier de devoir utiliser des outils différents pour faire la même chose, et si je me mets à la place d'un admin qui s'est constitué sa collection de scripts au fil du temps, je pense qu'on est plus sur le simple "faire chier", mais sur l'augmentation de la charge de travail: tout à refaire, à déboguer à nouveau, etc.
Youpi.
Tout ça pour quoi? Parce qu'un type à décidé que, non, les fichiers plats, c'est has been? Humpf.
En effet, entres autres. Et je travaille avec du code qui à pas loin de 10 ans, installé sur des machines dont l'âge varie de 6 ans à dans quelques jours (install et param en cours).
Au niveau des langages utilisés sur ces systèmes, on trouve (non exhaustif): du shell, du sql, du C et un peu de C++. Et clairement je trouve ça agréable de savoir que dans 10 ans, ces programmes compilerons encore avec les nouvelles versions des compilateurs (pour le code C/C++, le SQL je ne suis pas sûr même si j'ose espérer que oui, et le shell je n'en mettrais pas ma main à couper).
Mais maintenant, je pense qu'on peut pas soutenir les devs kernels qui soutiennent que les interfaces internes du kernel peuvent bouger, alors qu'il y a de la demande pour la stabilité (pour les drivers), que d'autres arrivent à le faire (solaris, windows ), et en même temps réclamer que rien ne change sur les autres projets.
Je ne dis pas que les choses ne peuvent pas bouger, je ne suis pas bête… enfin, si, mais pas à ce point là. Je dis juste que systemd ne me semble pas assez mûr pour que je me permette de baser un développement dessus, sentiment que je ressens principalement à cause du fait que, comme ceux qui ont forké, je n'ai pas l'impression que le projet ait des limites claires.
Chose que se propose de définir l'auteur du fork uselessd.
mais dans une base de données indexé lisible.
Lisible avec combien d'outils différents? Un seul? Et que faire si un "hypothétique" bug apparaît qui corrompt la base de données (qui, j'imagine, est unique: une seule BDD pour l'ensemble du système?) ? On perds tous les journaux? Je suis pas admin, mais je suppose que ce n'est pas très acceptable, si?
Alors que les journaux tels que je les connaît à l'heure actuelle, je peux les lire avec une pléthore d'outils. Et si jamais l'un d'eux, pour une raison X ou Y était corrompu, cela ne m'empêcherait pas d'accéder aux autres (manifestement, il n'y a pas qu'un seul fichier de log pour l'ensemble des services des systèmes que je côtoie, une éventuelle corruption ne me ferait donc perdre qu'un seul fichier, voire qu'une seule partie de ce fichier…).
Enfin, j'ai envie de citer le seul autre outil de journalisation binaire que j'aie vu, celui de windows. Franchement, pas quelque chose que j'ai envie de voir arriver sur Linux, vue la galère que c'est (ou du moins, que c'était à l'époque d'XP) que d'essayer d'y tirer la moindre information utile… non merci, vraiment. Après, ça s'est peut-être amélioré, et systemd est peut-être mieux… à prouver.
Et vu que les logs me servent régulièrement (toujours utile pour détecter les symptômes réels d'un bug d'une appli de ma boîte, ou pour les discerner d'un pebcak ;) ) je préfère avoir un truc en lequel j'aie confiance.
C'est gênant, parce que c'est pourtant un des points qui étaient évoqués comme l'un des points forts de systemd, non? Ceci étant dit, je pensais que Debian aurait utilisé leur système d'alternatives pour un truc comme apache/httpd, je suis déçu quelque part.
On peut aussi appeler ça, réduire la complexité, refactorer, ce qui réduit le nombre de bugs potentiels, et accroit la facilité de maintenance.
Bien sur, c'est intenable sur le long terme sauf à ce que rien d'autre ne bouge à coté.
Ou peut-être que ce qui est intenable sur le long terme, c'est un outil qui n'est pas stable dans ses fonctionnalités, qui ajoute en permanence de nouvelles choses (qui sait s'il ne finira pas par en supprimer?). Un tel outil, c'est bien pour jouer, mais en tant que dev, je ne me baserais jamais sur un outil plus glissant qu'une anguille, et les raisons sont simples:
comment je fais dans 10 ans, si tout à changé radicalement?
comment feront mes successeurs, ils vont devoir mettre le nez dans un code basé sur un outil devenu une véritable usine à gaz?
si un jour le projet meurs, comment faire pour le porter, s'il est inextricablement lié à mon propre code?
10 ans, ce n'est pas si énorme que ça, du code peut très bien tourner avec 10 ans d'âge sans souci, et on peut très bien avoir besoin de déployer le même programme sur une machine plus récente. Sauf qu'en 10 ans, bien des choses peuvent se passer en informatique…
Et d'ailleurs, un code qui augmente de taille en permanence, dont personne ne connaît la finalité réelle, c'est ça, qui est vraiment intenable. Ça finit en usine à gaz, et, en admettant que systemd ait la même solidité et le même futur que Xorg, regardes donc les arguments pour la création de wayland: repartir sur une base de code propre qui ne fasse pas peur à tout le monde, qui ne fasse pas fuir les éventuels contributeurs.
Systemd ne me semble pas du tout dans cette optique: au début, le but, c'était juste de se passer de scripts shell pour gérer les daemons, maintenant j'ai pas l'impression que ce soit toujours le même: il s'insère dans les systèmes de journalisation (ce qui aurait très bien pu être fait, mais par un projet autre, complètement séparé, pourquoi pas), de login, et j'en oublie.
Avoir un projet qui sait limiter sa sphère d'influence, c'est avoir plus de chances d'avoir un truc fiable à la fin. Et quand ça bug, c'est plus simple de cerner l'origine du bug, et de le corriger sans en rajouter ailleurs. Ça ne semble pas être le cas de systemd, et uselessd semble vouloir corriger ce problème.
J'ai toujours trouvé étrange l'histoire des logs « binaires » vs les logs « non binaires ».
Bien, alors.
Je vais faire une citation à un site souvent utilisé en tant que référence, notamment quand ça concerne les trucs de base comme c'est ici le cas:
A binary file is a computer file that is not a text file; it may contain any type of data, encoded in binary form for computer storage and processing purposes. Many binary file formats contain parts that can be interpreted as text; for example, some computer document files containing formatted text, such as older Microsoft Word document files, contain the text of the document but also contain formatting information in binary form. When downloading, a completely functional program without any installer is also often called a program binary, or binaries (as opposed to the source code).
A text file (sometimes spelled "textfile": an old alternative name is "flatfile") is a kind of computer file that is structured as a sequence of lines of electronic text. A text file exists within a computer file system. The end of a text file is often denoted by placing one or more special characters, known as an end-of-file marker, after the last line in a text file.
"Text file" refers to a type of container, while plain text refers to a type of content. Text files can contain plain text, but they are not limited to such.
At a generic level of description, there are two kinds of computer files: text files and binary files.[1]
Pourtant, il me semble que c'est assez répandu, que d'opposer les formats binaires, aux formats dits de "texte brut", c'est à dire stockant
Dans tous les cas, c'est binaire. Dans tous les cas, il faut un outil pour les lires.
Tant qu'a faire du mal aux mouches, je te dirais qu'en fait non, rien n'est binaire, puisque ton information n'est jamais exactement une suite de 0 et 1: entre les changements d'états il y à toujours une valeur indéterminée, gérée par l'électronique d'une façon ou d'une autre.
Le problème ici, c'est que pour un fichier ne contenant pas de texte brut, l'outil nécessaire pour lire ton fichier est complexe.
Au passage, chez moi, j'ai plein de logs qui sont compressés
Donc, ce ne sont pas tes logs que tu lis, avec tes outils, mais bien des archives. Et les outils en question font un travail largement différent d'un (oui je sais, version on ne peut plus naïve et bugguée):
Et au final il faut des programmes complexes pour lire des formats qui n'ont aucune fonction standard pour pouvoir les manier.
Sauf que, bien sûr, dans ton cas tu as choisi d'archiver ces journaux pour une raison X ou Y (le manque de place, logiquement?).
C'est là, à mon avis, le problème: si tu choisis de stocker tes fichiers dans un format à la con, ok, mais assumes. Si tu préfères les garder sous une forme triviale, de fichier textes, ok, mais tu assumes aussi les conséquences: les deux ont des avantages.
Dans le cas de systemd, on à un outil qui récupère du texte brut, le rentre dans des structures, puis, si tu le souhaites, recraches éventuellement (oui, je suis au courant qu'il est possible d'avoir à nouveau du texte brut) le contenu en texte brut.
Le problème, c'est que 1) ce n'est pas le comportement par défaut (sauf sur Debian, il semblerait) et 2) quel est l'intérêt de transformer un journal, qui est du texte brut à la base (une grande part des programmes qui font du log, soit écrivent dans des fichiers de texte brut, soit crachent sur stderr ou stdout sous forme de texte brut) en format complexe, puis de le décomplexifier en format texte?
Je sais que quand on parle de performance, de ne pas faire de choses inutiles, on nous rétorque qu'à l'heure actuelle ce n'est pas important, que "le client rachètera de la ram" (bon, ok, un proc plus puissant, ici, mais c'est une réplique d'un prof que j'ai eu et qui m'a vraiment marqué), mais je trouve ce raisonnement stupide. Et pire encore: ajouter des étapes complexes dans du code, ajouter du code qui au final ne sert à rien (puisqu'un peu plus loin on exécute du code qui annule… sans qu'il y ait eu de transformation entre deux!) c'est ajouter de la complexité de maintenance inutilement.
Il existe un mot pour résumer ça: bloatware!
Pour ceux qui ont la flemme d'aller cliquer sur le lien, en gros:
_ ça part de systemd208
_ ça à pour objectif d'utiliser des libC autres que celle de GNU, voire d'être utilisable avec un autre kernel. Portable quoi.
_ l'objectif est un truc qui ne gigote pas niveau features, que ça soit pas bloated.
En gros, j'ai l'impression que ça allie les qualités de systemd (les fichiers de config simples à comprendre pour quelqu'un qui n'est pas un guru shell, par exemple) sans prendre ses défauts (j'ai toujours autant de mal à piger l'intérêt des logs binaires, ou pourquoi le PID devrait gérer autant de choses).
Pour le coup, je pense que ce projet est très prometteur. Même si les fans du scripting traînerons toujours la patte, au moins ceux qui aiment les choses portables et stables n'aurons pas trop de remords à l'utiliser.
[^] # Re: Non mais oh!
Posté par freem . En réponse au journal Le troll du jour. Évalué à 1.
Tout-à-fait, on devrait faire un front pour imposer une parité homme/femme/trans sur le postage de troll le vendredi!
[^] # Re: smart pointer
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Je connaissais bt, c'est juste le fichier core que je ne sais (savais? je verrai ça dans l'aprem) générer. Merci bien!
[^] # Re: Gestionnaire de projets
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Pour yaml, je ne sais pas, j'en ai vu vite fait sur wikipedia, je n'en sais pas plus, mais c'est vrai que ça me plaît vachement plus que les autres.
Bah, non, franchement.
Exemple XML réel (code::blocks):
L'équivalent Visual Studio (et il n'y à que le vcxproj, et je n'ai pas viré les sections pour les divers builds comme j'ai fait pour C::B, pour cause de non masochisme):
Et enfin, cmake:
PS: désolé pour le délai avant la réponse, j'ai voulu avoir un truc un peu plus concret…
[^] # Re: Gestionnaire de projets
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Je trouve effectivement que Makefile, c'est horrible. Par contre, je trouve CMake très accessible, c'est d'ailleurs en corrigeant un CMakeLists.txt de quelques centaines de ligne en moins de 15 minutes pour générer un .deb, sans le connaître au préalable (juste de nom), que je l'ai adopté.
[^] # Re: smart pointer
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Je vois 3 différences avec l'assert:
crasherfermer violemment en désallouant les éventuelles ressources. Dans certains cas (les std::logic_error et ses filles) ce n'est pas très pertinent, mais quand il s'agit de se fermer après constat d'une erreur dans l'environnement (un fichier vital non trouvé, une entrée "utilisateur" --soyons d'accord: l'utilisateur n'est pas toujours humain…-- foireuse, ce genre de trucs) je trouve plus clair de juste lancer une exception avec un message potable (pour la logguer, c'est assez simple, il suffit de dériver une classe de std::exception, qui loggue automatiquement) que de faire un appel à une fonction pour logguer puis un autre à exit.està la possibilité d'être plus parlant. Bon, j'imagine qu'on peut aussi écrire une fonction avec le nom super long et qui renvoie true/false, pour l'emploi dans un assert, mais ça me semble un poil plus pénible.Entendons nous bien, encore une fois: quand je lance une exception, ce n'est pas pour que mon programme survive, je ne m'en sers pas comme d'un switch dégueu. Je ne me sers des exceptions que signaler que le programme ne peux plus continuer, et sauver ce qui peut l'être le cas échéant.
Par exemple, imagines un IDE qui, pour une raison ou une autre, à un bug. Si, plutôt qu'utiliser des assert qui imposeront à l'utilisateur d'utiliser un outil en mode déboguage, et donc lent, afin d'avoir des messages d'erreur et qui en plus impliqueront la perte de toutes les données, le développeur utilises des exceptions, alors l'utilisateur peut utiliser une version non débug (plus rapide, moins lourde), avoir un message d'erreur, et en plus récupérer son travail dans l'état juste avant l'anomalie. Ça (peut) évite(r) des sauvegardes automatiques toutes les N minutes, qui seront plus coûteuses.
Après, je t'avoue, je ne maîtrise pas gdb, loin de là (ça ne fait pas longtemps que j'ai abandonné les IDEs) donc c'est possible que ce soit plus intéressant. Mais je viens de faire un test basique, et je ne vois aucun fichier core généré. Tu utilises quoi comme options de compilation (outre le -g, évidemment)?
[^] # Re: Gestionnaire de projets
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
On à des définitions différentes pour deux choses.
1) simple fichier de configuration
2) idéal
Désolé, mais, vraiment, pour être idéal un "simple fichier de configuration" doit être facilement lisible et modifiable par un humain. Ce n'est le cas ni du xml, ni du json, à fortiori quand le fichier en question dépasse les 20 lignes.
Je dirais même plus, les outils basés sur du xml pour la config, me hérissent le poil, et pas juste par principe. J'utilisais un IDE dans le passé. J'en ai même utilisé plus d'un… les uns avec des formats proprios (mais "lisibles" avec un éditeur de texte, les autres avec des formats genre xml/json justement… et force m'est de constater que dès que l'on à plus envie de subir /que l'on ne peut plus utiliser une IHM graphique GTK/Qt/MFC/Whatever, ces choses sont horribles à gérer.
Je ne parlerai même pas de versionner ou differ ce genre d'horreur…
Je suppose que mon opinion différente viens du fait que j'aime pouvoir assembler mon écosystème logiciel moi-même, plutôt qu'être obligé de me reposer sur les choix de quelqu'un d'autre et devoir forker (et donc maintenir) une structure complexe dès que je veux changer customiser un truc dans un sens pas prévu par le(s) dev(s) d'origine.
Ça évite aussi de se taper des bugs très pénibles sans pouvoir changer le composant en un minimum d'efforts, quand ça arrive. Mais c'est vrai que ça nécessite un peu plus de travail pour mettre en place ses outils.
[^] # Re: smart pointer
Posté par freem . En réponse au journal Retour aux sources. Évalué à 3. Dernière modification le 29 septembre 2014 à 12:16.
Non, un débogueur ne te force pas à recompiler. C'est important quand tu utilises des libs assez lourdes. Et un printf ne te permets pas de lister l'ensemble de l'état de ton programme, et encore moins de revenir en arrière. Choses qu'un dbg te permets.
Mais ça, qu'il soit en ligne de commande (gdb), en ncurses (cgdb), ou graphique (visual, ddd, ollydbg…) ils peuvent tous le faire.
[^] # Re: smart pointer
Posté par freem . En réponse au journal Retour aux sources. Évalué à 4. Dernière modification le 29 septembre 2014 à 12:13.
Euh, et sinon, je me permets de rappeler que j'ai écrit cgdb. C'est, franchement, un peu moins inconfortable que gdb, surtout quand on ne connaît ce dernier que de nom. Maintenant, je pourrai m'en sortir un peu, et cgdb reste primitif, mais bon, on fait avec ce qu'on à.
Il existe aussi ddd, plus complet, plus gros, graphique, mais à mon goût dur à prendre en main. Aucun d'eux ne vaut visual studio, qui lui-même n'égale pas vraiment ollydbg (qui, de mémoire, peut afficher le source). Je pourrais également citer quelques ancêtres mais ce serait abusé: windasm, et dans une autre catégorie, softice. Mais ces ancêtres n'ont pas vraiment une IHM des plus modernes…
À mon avis, si linux possède moins d'IHM sympa pour les débuggueurs, c'est pour une raison simple: moins de programmes à reverser (que ce soit pour une raison légale ou pas n'est pas la question) du fait que bien souvent, on à les sources ou ils n'ont pas de prix.
PS: si, j'ai un IDE, c'est mon DE ;)
[^] # Re: smart pointer
Posté par freem . En réponse au journal Retour aux sources. Évalué à 4. Dernière modification le 29 septembre 2014 à 12:05.
Mouai. En fait, non, c'est pas imbitable. Je sais, mon argument est aussi puissant que le tiens, mais sincèrement, j'ai l'habitude de faire de petites (et nombreuses) classes, et d'être strict avec les contrats des méthodes/fonctions: si un param d'entrée me va pas, je lance une exception avec un message d'erreur. Vu que je ne rattrape que rarement mes exceptions (et pas toutes, en plus, histoire que ça crash bien comme il faut) quand j'ai un bug je sais très très vite d'où ça viens, même sans débuggueur. Ça m'évite la plus grosse part des douleurs.
Et pour ce qui est des structures imbriquées, j'utilise un outil nommé: typedef. Comme ça, c'est tout de suite 1) plus simple à lire et 2) plus court à taper.
Et pour l'auto-complétion, vim s'en sort pas trop mal, excepté c'est vrai, quand j'utilise un framework lourd que je ne connait pas assez. Mais c'est assez rare, et en plus isolé dans une seule "couche" de l'application.
Bon, ça à aussi des avantages niveau ergonomie, si je combine mes terminaux avec un tiling window manager. En fait, sans cet outil, je ne supporterai pas ce mode de fonctionnement et j'utiliserai effectivement un IDE. Mais grâce aux twm, l'IDE c'est mon bureau, et je ne connais pas mieux qu'un twm pour gérer du multi-screen ou pour se passer de la souris, qui est, selon moi, un véritable instrument de torture: c'est lent, peu précis, ça sert à pointer des interfaces qui risquent de changer à la moindre MaJ, et ça nécessite de lâcher le clavier (et les claviers modernes ayant ce foutu pavé numérique, le mouvement de bras n'est pas court).
Perso, c'est quand je passe sur un IDE que je me sens handicapé. Ou avec un gestionnaire de fenêtres classique. Et pourtant, je ne qualifie pas les gens qui s'en servent au quotidien de rétrogrades et non-productifs: j'accepte qu'ils aient une façon de faire différente de la mienne, sûrement plus efficace sur certains points (c'est clair, pour construire une boîte de dialogue, je suis assez emmerdé… par contre, pour switcher entre git, mon source, pondre un script rapide pour tester un truc ou deux, et autres, je pense que ma façon de faire n'est pas mauvaise.
[edit]
Ceci étant dit, il faut admettre que visual à un debugguer qui gère un max.
[^] # Re: plop
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Bah, les .h(pp) sont inclus plusieurs fois, si tu utilises plusieurs fichiers c(pp) qui l'incluent, ton header sera inclus plusieurs fois (pour un projet donné), et c'est d'ailleurs la principale cause des lenteurs de compilation C++.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par freem . En réponse au journal Retour aux sources. Évalué à 4.
Je ne suis pas complètement d'accord (mais en grande partie quand même).
La POO est un vrai paradigme, dans le sens ou le raisonnement est différent de la programmation modulaire plus classique du C (par exemple).
Maintenant, je ne crois pas avoir vu un seul langage réellement OO, et ce, ne serait-ce que parce que de prime abord, l'OS appelle une fonction, et lui passe une liste de chaînes de caractères.
En Java, par exemple, ils utilisent une classe avec une méthode statique pour ça. Pas très pur objet, pas vrai? Si on voulait qu'un langage puisse être réellement pur objet (mais quel intérêt, sérieux?) il faudrait que lors de l'appel du programme on ait une API prédéfinie, genre une classe (et pas une méthode) main, que l'OS instancie en appelant le constructeur, puis dont il appelle une méthode précise (et pas une fonction, comme c'est le cas en Java, parce qu'une méthode statique, c'est bien plus proche d'une fonction dans un namespace, que d'une méthode), et qu'enfin l'OS dés-instancie en passant par le destructeur.
Mais franchement, quel intérêt ça aurait? Les langages "pur objet" me font bien rire, et la façon de faire du C++ (et de bien d'autres langages "bâtards" je pense) est à mon avis la bonne: exposer un certain nombre de façon de programmer, et laisser l'utilisateur faire son truc comme il le veut, en fonction de la situation.
Perso, rien jusqu'a présent n'a réussi à me convaincre que respecter un seul paradigme dans un programme est la meilleure chose à faire pour que le programme soit clair et efficace. C'est même le contraire.
[^] # Re: Trop gros, passera pas.
Posté par freem . En réponse au journal Retour aux sources. Évalué à 9.
Oui, elle n'est pas fermée comme une huître.
[^] # Re: Non mais oh!
Posté par freem . En réponse au journal Le troll du jour. Évalué à 5.
C'est triste ton avis sur sa volonté.
[^] # Re: Non mais oh!
Posté par freem . En réponse au journal Le troll du jour. Évalué à 3.
On dit pas nanique?
[^] # Re: smart pointer
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Probable en effet: 1.49 ici.
Je te suggère donc un patch, si tu dépends d'une version particulière de boost:
find_package(Boost $BOOST_VERSION COMPONENTS $BOOST_COMPONENTS REQUIRED);)[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Moui. Si on exécute le programme qu'une fois, c'est possible. Si, maintenant, on le lance, disons, une fois par jour… c'est moins certain, beaucoup moins.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 4.
C'est un point de vue. Le miens est qu'il vaut mieux avoir plusieurs implémentations pour une même fonctionnalité, car cela permets de ne pas transformer des bugs/comportements indéfinis en pseudo standard. Cela évite aussi l'enfermement.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 1.
Je n'ai jamais dit que quelqu'un était forcé d'utiliser systemd. Ne me fais pas dire ce que je n'ai pas dit.
# smart pointer
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Je veux pas être méchant, mais tu es mauvaise langue.
Ceci dit, l'actuel unique_ptr est effectivement nettement mieux.
Je passerais outre le fait que tu dises n'avoir trouvé qu'eclipse comme IDE digne de ce nom, genre il plante pas. J'ai vécu l'enfer avec cet outil, pour coder en Java. J'ai un net souvenir d'une auto-complétion hyper longue, qui se déclenchait toute seule (et pas moyen de l'en empêcher, j'ai cherché partout, sauf au bon endroit je suppose) et qui faisait planter la bête si j'osais utiliser mon clavier tant qu'elle avait pas fini.
Bref, comparé à ce bon vieux code::blocks par exemple, que je n'ai que rarement vu planter et ce, probablement parce que j'utilisais la version de nightly, je ne pense pas qu'eclipse vaille la peine. À la rigueur, tu aurais dis netbeans, je t'aurais accordé le bénéfice du doute.
Mais perso, je suis passé à cmake+vim+cgdb, ça marche très bien, c'est léger, réactif, stable et ça n'a pas besoin de serveur graphique (sisi, parfois c'est utile).
Sinon, continue si tu le souhaites, de toute façon la plupart des problèmes de performances ne sont pas dus aux langages, mais aux dev. Après… c'est une évidence pour moi, quand on enlève une couche dans un SI, ça va plus vite et bouffe moins de RAM, si les choses sont faites proprement. Chacun ses goûts et opinions.
PS: vrai que c'est lent ta compilation. Mais ça doit être lié aux lib boost qui sont à base de template. À voir si il n'y à pas moyen d'améliorer ça… en-tête précompilés par exemple?
PPS: ça compile pas ici, je verrai plus tard pour fixer.
Commit: aaa9cbb9c70e
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 2.
Admettons.
Donc, systemd utilise une représentation sous forme de lignes? Dans ce cas, pourquoi avoir réinventé la roue, surtout quand on sait à quel point systemd avait déjà tendance à hérisser les poils de certains? En quoi les anciens standards n'étaient-ils pas suffisants? 14 standards ce n'était pas assez?
On verra quand j'aurai un systemd en prod. Pour le moment, ce n'est pas le cas. Par contre, oui, c'est clair, ça me ferait bien chier de devoir utiliser des outils différents pour faire la même chose, et si je me mets à la place d'un admin qui s'est constitué sa collection de scripts au fil du temps, je pense qu'on est plus sur le simple "faire chier", mais sur l'augmentation de la charge de travail: tout à refaire, à déboguer à nouveau, etc.
Youpi.
Tout ça pour quoi? Parce qu'un type à décidé que, non, les fichiers plats, c'est has been? Humpf.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 1.
En effet, entres autres. Et je travaille avec du code qui à pas loin de 10 ans, installé sur des machines dont l'âge varie de 6 ans à dans quelques jours (install et param en cours).
Au niveau des langages utilisés sur ces systèmes, on trouve (non exhaustif): du shell, du sql, du C et un peu de C++. Et clairement je trouve ça agréable de savoir que dans 10 ans, ces programmes compilerons encore avec les nouvelles versions des compilateurs (pour le code C/C++, le SQL je ne suis pas sûr même si j'ose espérer que oui, et le shell je n'en mettrais pas ma main à couper).
Je ne dis pas que les choses ne peuvent pas bouger, je ne suis pas bête… enfin, si, mais pas à ce point là. Je dis juste que systemd ne me semble pas assez mûr pour que je me permette de baser un développement dessus, sentiment que je ressens principalement à cause du fait que, comme ceux qui ont forké, je n'ai pas l'impression que le projet ait des limites claires.
Chose que se propose de définir l'auteur du fork uselessd.
Lisible avec combien d'outils différents? Un seul? Et que faire si un "hypothétique" bug apparaît qui corrompt la base de données (qui, j'imagine, est unique: une seule BDD pour l'ensemble du système?) ? On perds tous les journaux? Je suis pas admin, mais je suppose que ce n'est pas très acceptable, si?
Alors que les journaux tels que je les connaît à l'heure actuelle, je peux les lire avec une pléthore d'outils. Et si jamais l'un d'eux, pour une raison X ou Y était corrompu, cela ne m'empêcherait pas d'accéder aux autres (manifestement, il n'y a pas qu'un seul fichier de log pour l'ensemble des services des systèmes que je côtoie, une éventuelle corruption ne me ferait donc perdre qu'un seul fichier, voire qu'une seule partie de ce fichier…).
Enfin, j'ai envie de citer le seul autre outil de journalisation binaire que j'aie vu, celui de windows. Franchement, pas quelque chose que j'ai envie de voir arriver sur Linux, vue la galère que c'est (ou du moins, que c'était à l'époque d'XP) que d'essayer d'y tirer la moindre information utile… non merci, vraiment. Après, ça s'est peut-être amélioré, et systemd est peut-être mieux… à prouver.
Et vu que les logs me servent régulièrement (toujours utile pour détecter les symptômes réels d'un bug d'une appli de ma boîte, ou pour les discerner d'un pebcak ;) ) je préfère avoir un truc en lequel j'aie confiance.
[^] # Re: Surprenant, non ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 5.
C'est gênant, parce que c'est pourtant un des points qui étaient évoqués comme l'un des points forts de systemd, non? Ceci étant dit, je pensais que Debian aurait utilisé leur système d'alternatives pour un truc comme apache/httpd, je suis déçu quelque part.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 7.
On peut aussi appeler ça, réduire la complexité, refactorer, ce qui réduit le nombre de bugs potentiels, et accroit la facilité de maintenance.
Ou peut-être que ce qui est intenable sur le long terme, c'est un outil qui n'est pas stable dans ses fonctionnalités, qui ajoute en permanence de nouvelles choses (qui sait s'il ne finira pas par en supprimer?). Un tel outil, c'est bien pour jouer, mais en tant que dev, je ne me baserais jamais sur un outil plus glissant qu'une anguille, et les raisons sont simples:
10 ans, ce n'est pas si énorme que ça, du code peut très bien tourner avec 10 ans d'âge sans souci, et on peut très bien avoir besoin de déployer le même programme sur une machine plus récente. Sauf qu'en 10 ans, bien des choses peuvent se passer en informatique…
Et d'ailleurs, un code qui augmente de taille en permanence, dont personne ne connaît la finalité réelle, c'est ça, qui est vraiment intenable. Ça finit en usine à gaz, et, en admettant que systemd ait la même solidité et le même futur que Xorg, regardes donc les arguments pour la création de wayland: repartir sur une base de code propre qui ne fasse pas peur à tout le monde, qui ne fasse pas fuir les éventuels contributeurs.
Systemd ne me semble pas du tout dans cette optique: au début, le but, c'était juste de se passer de scripts shell pour gérer les daemons, maintenant j'ai pas l'impression que ce soit toujours le même: il s'insère dans les systèmes de journalisation (ce qui aurait très bien pu être fait, mais par un projet autre, complètement séparé, pourquoi pas), de login, et j'en oublie.
Avoir un projet qui sait limiter sa sphère d'influence, c'est avoir plus de chances d'avoir un truc fiable à la fin. Et quand ça bug, c'est plus simple de cerner l'origine du bug, et de le corriger sans en rajouter ailleurs. Ça ne semble pas être le cas de systemd, et uselessd semble vouloir corriger ce problème.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 4.
Bien, alors.
Je vais faire une citation à un site souvent utilisé en tant que référence, notamment quand ça concerne les trucs de base comme c'est ici le cas:
Binary file:
Text file:
Pourtant, il me semble que c'est assez répandu, que d'opposer les formats binaires, aux formats dits de "texte brut", c'est à dire stockant
Tant qu'a faire du mal aux mouches, je te dirais qu'en fait non, rien n'est binaire, puisque ton information n'est jamais exactement une suite de 0 et 1: entre les changements d'états il y à toujours une valeur indéterminée, gérée par l'électronique d'une façon ou d'une autre.
Le problème ici, c'est que pour un fichier ne contenant pas de texte brut, l'outil nécessaire pour lire ton fichier est complexe.
Donc, ce ne sont pas tes logs que tu lis, avec tes outils, mais bien des archives. Et les outils en question font un travail largement différent d'un (oui je sais, version on ne peut plus naïve et bugguée):
Et au final il faut des programmes complexes pour lire des formats qui n'ont aucune fonction standard pour pouvoir les manier.
Sauf que, bien sûr, dans ton cas tu as choisi d'archiver ces journaux pour une raison X ou Y (le manque de place, logiquement?).
C'est là, à mon avis, le problème: si tu choisis de stocker tes fichiers dans un format à la con, ok, mais assumes. Si tu préfères les garder sous une forme triviale, de fichier textes, ok, mais tu assumes aussi les conséquences: les deux ont des avantages.
Dans le cas de systemd, on à un outil qui récupère du texte brut, le rentre dans des structures, puis, si tu le souhaites, recraches éventuellement (oui, je suis au courant qu'il est possible d'avoir à nouveau du texte brut) le contenu en texte brut.
Le problème, c'est que 1) ce n'est pas le comportement par défaut (sauf sur Debian, il semblerait) et 2) quel est l'intérêt de transformer un journal, qui est du texte brut à la base (une grande part des programmes qui font du log, soit écrivent dans des fichiers de texte brut, soit crachent sur stderr ou stdout sous forme de texte brut) en format complexe, puis de le décomplexifier en format texte?
Je sais que quand on parle de performance, de ne pas faire de choses inutiles, on nous rétorque qu'à l'heure actuelle ce n'est pas important, que "le client rachètera de la ram" (bon, ok, un proc plus puissant, ici, mais c'est une réplique d'un prof que j'ai eu et qui m'a vraiment marqué), mais je trouve ce raisonnement stupide. Et pire encore: ajouter des étapes complexes dans du code, ajouter du code qui au final ne sert à rien (puisqu'un peu plus loin on exécute du code qui annule… sans qu'il y ait eu de transformation entre deux!) c'est ajouter de la complexité de maintenance inutilement.
Il existe un mot pour résumer ça: bloatware!
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 1.
Pfff j'allais le citer justement :)
Pour ceux qui ont la flemme d'aller cliquer sur le lien, en gros:
_ ça part de systemd208
_ ça à pour objectif d'utiliser des libC autres que celle de GNU, voire d'être utilisable avec un autre kernel. Portable quoi.
_ l'objectif est un truc qui ne gigote pas niveau features, que ça soit pas bloated.
En gros, j'ai l'impression que ça allie les qualités de systemd (les fichiers de config simples à comprendre pour quelqu'un qui n'est pas un guru shell, par exemple) sans prendre ses défauts (j'ai toujours autant de mal à piger l'intérêt des logs binaires, ou pourquoi le PID devrait gérer autant de choses).
Pour le coup, je pense que ce projet est très prometteur. Même si les fans du scripting traînerons toujours la patte, au moins ceux qui aiment les choses portables et stables n'aurons pas trop de remords à l'utiliser.