Amour, gloire et cpp
Bonjour Nal,
Si tu suis régulièrement mes aventures, tu sais que depuis quelques années je n'utilise plus qu'une seule plateforme de développement pour tous mes projets: Java.
Portable, performant et surtout productif, ce mariage de raison n'a pas empêché quelques aventures avec Python ou Javascript, mais est resté assez solide.
Toutefois je n'ai jamais complètement pu oublier mon premier amour pour le C++, celui-ce ne cessant de se rappeler à mon bon souvenir, me promettant qu'il n'était plus le même, qu'il avait changé.
J'ai fini par craquer et convenu d'un rendez-vous autour d'un prototype de jeu de sport dont je te reparlerais bientôt j'espère, bien que je ne sache pas si j'irais jusqu'au bout. En effet, la mise en place du projet n'a pas été un retour aux sources chaudes, mais plutôt une douche glacée façon ice bucket challenge avec un seau oublié pendant 3 mois dans un congélateur industriel.
Le choix des larmes
Le panel de choix de l'outillage a été très décevant.
J'ai essayé quelques IDE, avant de me rendre compte que Eclipse ou Netbeans sont les seuls à proposer une bonne complétion, du refactoring qui marche et à ne pas planter lamentablement (kdevelop, c'est de toi que je parle). Les meilleurs IDE C++ sont donc en Java…
Pour le gestionnaire de projet, c'est bien simple, ça n'existe pas. Je n'ai trouvé aucun outil qui semble seulement s'approcher du centième de ce que fait un maven hors de la boite. Il faut donc utiliser une sorte script de compilation et gérer ses dépendances à la main comme à la préhistoire de l'informatique. J'ai pris cmake, car tout le monde semble l'utiliser de nos jours, mais mes yeux saignent en voyant le genre d'horreurs qu'il faut écrire:
if (${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU" OR ${CMAKE_CXX_COMPILER_ID} STREQUAL "Clang")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -pedantic -std=c++11")
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS} -g")
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS} -O2")
endif()J'ai aussi regardé comment faire de la cross compilation, créer des packages ou des binaires portables: là aussi il n'y a rien de bien au point, juste des tutoriaux ou des recommandations au détour d'un blog ou d'un forum.
Le vent du changement c'est maintenant
Une fois passée la douloureuse mise en place du projet, j'ai quand même été content de voir que C++ a bien changé. Fini les functors, vive les lambdas! Enfin vous voilà, smart pointers dans la STL! Oh et boost qui s'est bonifié avec le temps!
Je peux enfin écrire sans honte de belles lignes de code comme celles ci-dessous sans recourir à 150000 lignes de templates, de macros et de libs externes:
boost::property_tree::read_json(path, pt_nanim);
boost::filesystem::path parent_path = boost::filesystem::path(path).parent_path();
auto collec = std::make_shared<nanim::collection>();
for (auto& pt_animation : pt_nanim.get_child("animations")) {
auto anim = std::make_shared<nanim::animation>();
for (auto& pt_frame_child : pt_animation.second.get_child("frames")) {
auto pt_frame = pt_frame_child.second;
...Si le langage a bien évolué sur des points qui me faisaient mordre mon clavier tous les jours à l'époque, je constate qu'il n'a pas bougé d'un poil sur des sujets fondamentaux:
- l'absence de système de modules: des entêtes avec #ifndef … #endf en 2014, c'est très moche.
- j'ai une dizaine de classes et la compilation se fait déjà longuette.
- toujours pas de stacktrace lors d'une exception.
Si tu reviens, je compile tout
Ah Nal! Tu l'auras compris, retrouver une ancienne amour, c'est souvent se rendre compte que tout a changé pour que rien ne change.
A ton avis, dois-je continuer cette aventure risquée ou revenir à la Raison?
# Yahou peut être enfin des jeux qui marchent !
Posté par reynum (site web personnel) . Évalué à 10.
En voila une idée quelle est bonne, si Newton adventure ou Ned et les maki sont réécrit en C++ je vais peut être enfin pouvoir y jouer (sans mettre mon CPU à 400% et lagger comme un fou) ?
Même QtCreator ou Code::Blocks n'ont pas réussit à te satisfaire ?
Je soupçonne un parti pris ôO
Pourquoi changer un équipe qui gagne ? ;-)
A mon avis tu aurais raison de continuer l'aventure.
kentoc'h mervel eget bezan saotred
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
L'intérêt pour moi, c'est de ne pas perdre la main en C++. Mais à part ça?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par Firwen (site web personnel) . Évalué à 10. Dernière modification le 26 septembre 2014 à 12:06.
J'hesite entre classé ton poste en troll ou en démonstration flagrante d'ignorance d'un dev Java.
ça dépend de ta définition d'IDE. Si par IDE tu entends bloatware qui prends 4G de ta ram toute en réduisant dramatiquement ta productivité par sa lenteur. Effectivement Eclipse est un bon candidat.
Si tu cherches quelques chose de rapide, qui a l'auto complétion, la gestion des projets, des SCM, gestion des plugins, et qui plus est, est bien intégré à CMake.
ça s'appelle QtCreator.
Ne reproche pas le fait que tu ne sais pas utiliser cmake à cmake en fait.
Tout ce que tu as fait précédent existe déja en modules, tu aurais pu le faire en une ligne:
include(blabla REQUIRED)
Tu veux dire ça en fait ?
include(CPack)
mmh
#pragma once.
De rien.
http://cs.baylor.edu/~donahoo/tools/gdb/tutorial.html
De rien.
Sinon j'imagine que tu as posté ce troll entre deux compilation maven ?
Vu qu'elles téléchargent la moitié du web à chaque fois, il est vrai que ça laisse tu temps libre.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par devnewton 🍺 (site web personnel) . Évalué à 10. Dernière modification le 26 septembre 2014 à 12:14.
J'ai fait du C++ pendant 15 ans, mais 3 ans de pause suffisent à oublier ou à ne plus être au courant des 42000 choses à savoir pour faire un hello world C++ correct :-)
Comment remplacerais-tu les lignes que j'ai mise? Sur mon temps libre, j'utilise la technique "fapless coding", cad que je prends le premier truc qui marche sans me prendre la tête, donc oui je n'ai pas pris le temps de lire les centaines de page de Mastering cmake à 59$…
Tu veux vraiment comparer les temps de compilation java et c++???
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par fearan . Évalué à -3.
en même temps tu met IDE et eclipse dans la même phrase, forcément ça coince. Même pour le java j'utilise pas (je lui préfère intelliJ).
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par Albert_ . Évalué à 5. Dernière modification le 26 septembre 2014 à 12:57.
je n'ai pas pris le temps de lire les centaines de page de Mastering cmake
Ne perd pas ton temps avec… malheureusement il ne sert pas a grand chose ce bouquin. Tres decevant.
CMake c'est super bien mais c'est un peu … bugge. Par exemple il arrive parfois qu'il n'arrive pas a faire le lien avec un bibliotheque qu'il a pourtant trouve. La raison c'est que le chemin n'as pas ete mis a la creation du Makefile enfin c'est ce que j'ai cru comprendre. Je dois avouer que j'ai fait simple et que j'ai mis la bibliotheque dans un chemin classique (/usr/local/lib) et la ca passe nickel… Je sais c'est porc et il va falloir que je corrige le fichier Find…
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par Firwen (site web personnel) . Évalué à 0. Dernière modification le 26 septembre 2014 à 13:12.
echo -e '#include \n int main(int argc, char** argv){ std::cout << "Hello World" << std::endl; }' | g++ -x c++ -o /tmp/test -
/tmp/test
Tu me fais le même en Java ? je veux rire un peu.
curl http://pastebin.com/raw.php?i=ywnLKdJu -o cmake/modules/ReleaseDebugFlags.cmake
include(ReleaseDebugFlags REQUIRED);
Oui si on considère les 2 min de compilation JIT, de chargement JVM et d'optimization "server" à chaque exécution du bloat.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par dyno partouzeur du centre . Évalué à 10.
echo -e 'class Hello {\n public static void main(String[] args) {\n System.out.println("Hello Troll");\n }\n}' > Hello.java && javac Hello.java && java Hello
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par rakoo (site web personnel) . Évalué à 10.
Je rêve ! On est bien en train d'assister a un concours de kekettes sur le temps de compilation d'un programme tellement trivial qu'il n'est pas représentatif d'un vrai programme ?
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par barmic . Évalué à 10.
Même pas, c'est sur la manière d'écrire un tel programme grâce à un uniligne…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par Michaël (site web personnel) . Évalué à 0.
C'est triste ton avis sur les motardes.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par leovilok . Évalué à 10.
je vous bat tous :
echo hello world
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par kupka . Évalué à 10.
On peut faire comme ça aussi :
env x='() { :;}; echo hello world' bash -c "echo "
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par Maxime (site web personnel) . Évalué à 3.
gcc est capable de lire stdin, je vois pas pourquoi vous vous prenez tous la tête à passer par un fichier intermédiaire.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par jame_s . Évalué à 1.
Pas sûr ! En ruby :
p hello world
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par gnx . Évalué à 10.
Pfff, en HQ9+ :
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par Olivier Serve (site web personnel) . Évalué à 9.
Mouhahaha ! Même en comptant tout ça, la compilation C++ est à des années-lumières derrière…
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par reynum (site web personnel) . Évalué à 10.
C'est pour mieux te pulvériser avec le binaire mon enfant. :-D
kentoc'h mervel eget bezan saotred
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par zebra3 . Évalué à 8.
Purée, j'ose pas imaginer ce que donnerait un KDE entièrement en Java…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
http://sourceforge.net/projects/jdx/ ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par Firwen (site web personnel) . Évalué à 10. Dernière modification le 26 septembre 2014 à 15:59.
Définitivement un projet qui va révolutionner le monde: Étendre la laideur, la lenteur et l'over-engineering de SWING à un environnement bureau complet, j'en salive déja rien qu'a l'idée.
Ça ferait presque passé Xorg et Motif pour des environnements modernes et respectables en fait.
Allez juste pour le troll final, je copie colle ça depuis la dernière news du projet:
"New feature includes hot key support and many bug fixes. However, Swing's single thread model has been known to cause performance problems in this release when running multiple Java applications.."
Sounds awesome
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par freem . É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: Yahou peut être enfin des jeux qui marchent !
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
C'est pas très différent je trouve :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par groumly . Évalué à 10.
clair qu'écrire du code a coup de echo et de pipe, c'est super pertinent et vachement courant, cette possibilité se place tres tres haut sur la liste des trucs importants qui font vraiment une difference.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par Firwen (site web personnel) . Évalué à 5.
Bof mon objectif n'était pas de lancer un concours de qui peut faire le plus de choses inutiles à coup de pipe initialement :D
Plutôt de souligner la stupidité de l'affirmation
Tout en défendant un langage à la verbosité légendaire où tu as besoin de créer une classe pour faire un "Hello world".
```
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
man hyperbole
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par dyno partouzeur du centre . Évalué à -7.
Si ton C++ te permet de te passer des classes pour un programme simple, c'est qu'il n'est pas vraiment objet. Ca reste du C auquel on a rajouté des classes en pourrissant la syntaxe déjà un peu crade d'origine.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par xcomcmdr . Évalué à 4.
Rien à voir.
Déjà il y a deux familles de langages orienté objet (au moins) : ceux basés sur des classes (C#, Java, …), et ceux basés sur le passage de messages (Ruby par exemple).
Et Ruby permet aussi de se passer de classes. On peut pas dire pour autant qu'il n'est pas vraiment objet, loin de là !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par flan (site web personnel) . Évalué à 2.
Même si sur le fond il n'a pas tort (le C++ est du C avec une couche objet), ce n'est pas parce qu'on peut se passer de classes qu'il n'est pas objet.
On pourrait dire que Python est bien plus objet que Java, vu que tout est objet (y compris les classes, les méthodes, les fonctions, les entiers, …). Pourtant, on peut s'en servir sans faire de classe.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par Zylabon . Évalué à 10.
Quand on parle de paradigme de programmation il y a souvent confusion entre :
Après, il y a clairement des langages plus ou moins « orienté objet » mais savoir qui de python ou java est le plus objet est aussi intéressant que de savoir si quelqu'un dont les deux parents sont juifs est plus juifs que quelqu'un dont le père est catholique.
Je ne peux m'empêcher de penser que le paradigme objet a beaucoup d'une escroquerie intellectuelle. C'est pas un paradigme de programmation… Tout au plus c'est une vague idée de génie logiciel élevée au rang de doctrine. Parce qu'au fond, c'est rarement autre chose que de la programmation impératives.
La programmation logique, ça c'est VRAI paradigme. On exprime notre problème sous forme logique, et l’exécution du programme est en fait la recherche d'une preuve de la solution. Et il n'y a pas à ergoter pour savoir si tel ou tel langage est plus ou moins « orienté logique ». Soit le langage permet de prendre en entrée un ensemble de formule logique et de sortir une solution au problème, soit il ne le peut pas.
Bref, savoir si tel langage est plus ou moins orienté que tel autre c'est comme savoir si un livre est plus ou moins un livre de coloriage qu'un autre parce qu'il y a plus de traits à ne pas dépasser.
Please do not feed the trolls
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par freem . É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: Yahou peut être enfin des jeux qui marchent !
Posté par Firwen (site web personnel) . Évalué à 9. Dernière modification le 27 septembre 2014 à 12:52.
Si j'avais envie de troller encore un peu je dirai:
Une personne en 2014 qui ne prêche que le 100% pure-objet à l'heure du multi-core et la programmation concurrente devrait sincèrement internée.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par navaati . Évalué à 1. Dernière modification le 27 septembre 2014 à 12:06.
edit: mauvais endroit en fait
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par galactikboulay . Évalué à 8.
Bel exemple de mauvaise foi crasse. Maven ne télécharge les artefacts (plugins et dépendances) que lorsqu'ils ne sont pas déjà présents dans le repository local.
La 1ère compilation d'un projet peut effectivement demander pas mal de téléchargements, mais sur les compilations suivantes il n'y aura plus nécessiter de télécharger quoi que ce soit.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par navaati . Évalué à 6.
Ah wep ok et donc les ptites recettes magiques, les modules qu'y faut utiliser et tout, on les découvre comment ? Pasque la doc de CMake est plutôt sèche (c'est une doc de référence, ya pas de "comment y faut faire pour bien faire") et les ressources en lignes se résument à un wiki chelou et des mailing lists, et tu te retrouve fatalement à faire ce qu'il fait : du gros copier coller.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par louiz’ (site web personnel) . Évalué à 1. Dernière modification le 28 septembre 2014 à 02:15.
Non, c’est pas standard.Edit: Ah bon ça a déjà été discuté à côté.
# Question
Posté par fearan . Évalué à 4.
Dans tes includes tu utilises plutôt des directives #include pour déclarer les classes où tu utilise class Plop; ?
Dans le premier cas regardes du coté des precompiled header ou tente de passer au maximum par le second ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Un .h peut maintenant se compiler comme les .c. Cela permet de gagner du temps.
Non, mais il existe des bout de code qui permet de le faire, en récupérant les exceptions.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par devnewton 🍺 (site web personnel) . Évalué à 4. Dernière modification le 26 septembre 2014 à 10:25.
Il y a des trucs portables qui marchent facilement pour faire tout ça?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: ...
Posté par jseb . Évalué à 5. Dernière modification le 26 septembre 2014 à 10:46.
Question #1 : avec gcc, tout simplement.
Lors des compilations suivantes, gcc détectera le .gch et l'utilisera.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: ...
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Comment faire ça avec cmake?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: ...
Posté par zul (site web personnel) . Évalué à 3.
Il n'y a toujours pas de support officiel pour les entêtes précompilés dans cmake (mais il y'a plein de pistes dans le bug associé
http://www.cmake.org/Bug/print_bug_page.php?bug_id=1260).
[^] # Re: ...
Posté par barmic . Évalué à 8.
Est-ce que cmake t'apporte un vrai gain ? Il est pas mal pour la gestion des dépendance (qu'il est le seul à gérer avec les autotools), mais si ça ne t'arrange pas il y a un paquet d'outils de build qui te ferront du café torréfié sous l'aisselle, font revenir l'être aimé et rende le poil plus soyeux, les plus avancés soignent les phobies administratives.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ...
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Une gestion des dépendances dans cmake? Où ça?
J'ai pris celui là pour faire comme tous les développeurs modernes. Les autres outils de build ont l'air préhistoriques ou morts.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
moi j'aime bien "gcc -MM" avec make.
Mais c'est pour des trucs simple.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Mr. Magne . Évalué à 3.
Comme ide sympa avec CMake, qtcreator est bien, en plus on peut faire du vim comme à la maison :)
Pour les temps de compilation, en effet les forward declarations c'est ce qu'il y a de mieux. Si tu cherches néanmoins du côté des precompiled headers je te conseilles d'éviter les includes guards (#ifndef au début du .h) et de préférer les #pragma once. En effet si ton include est inclus par d'autres headers, il sera lu à chaque fois avec différentes variables de préprocesseur (et donc recompilé). Concernant la portabilité du pragma once, marche avec gcc, clang et visual donc ça me suffit :)
A propos de clang, j'ai de bien meilleurs temps de compilation avec (surtout avec du boost).
Pour les stacks trace, j'ai pas mieux que lancer dans gdb (ou activer les fichier core pour du post-mortem)
[^] # Re: ...
Posté par fearan . Évalué à 2.
ou a l'init signal(11, fonction());
et dans la fonction faire tout ce qu'il faut pour la stacktrace, attention cependant :
pas d'allocation dynamique dans une fonction appelé via un signal (théoriquement que du signal safe)
typiquement
et hop magie (bon c'est dun GNU ) ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: ...
Posté par Gof (site web personnel) . Évalué à 4.
Les compilateurs modernes reconnaissent les include guards et effectuent la même optimisation que pour
#pragma once.(mais je ne veux pas dissuader l'utilisation de
#prama oncequi est bien moins sujet à l'erreur)[^] # Re: ...
Posté par Mr. Magne . Évalué à 1.
Le compilateur reconnaît oui, mais il n'empêche que le fichier n'est pas compilé avec les même définitions, donc dans le cas d'en-têtes pré-compilées, elles seront re-compilées. Je parle ici d'un A.h qu'on veut pré-compiler, s'il est inclus par B.h et C.h, il sera pré-compilé avec INCLUDEGUARD_A_H, puis pré-compilé avec INCLUDEGUARD_B_H.
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
pour le 1), c'est gcc (et sans doute aussi visual studio).
pour le 2), c'est du linux, il me semble.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par serge_sans_paille (site web personnel) . Évalué à 4.
Si tu penses à
backtrace()deexecinfo.houi :-)cf. http://stackoverflow.com/questions/3355683/c-stack-trace-from-unhandled-exception
[^] # Re: ...
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
Ne pas oublier non plus :
- ccache (assez trivial à mettre en place)
- distcc (si tu as d'autres bécanes sous la main)
- éviter le couplage fort entre les sources en utilisant le PIMPL idiom
- …
[^] # Re: ...
Posté par dguihal . Évalué à 4.
Faire tourner dans gdb (et un on IDE qui wrapper bien autour de gdb) est assez efficace pour trapper les exceptions.
Sinon dans l'idée c'est de réactiver la génération des fichiers core en cas de crash, et du coup pareil, avec ton fichier core (pas strippé par contre) et un bon IDE tu peux retrouver l'endroit du plantage
# Cross-compilation
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 26 septembre 2014 à 11:13.
Salut,
Pour la cross-compilation, j'ai découvert depuis mon projet crossroad que c'est vraiment pas un problème du moment que tu fais du code ok et des Makefiles normaux (que ce soit autotools ou cmake), puis tu testes une cross-compilation régulièrement (avec crossroad, qui prend en charge justement autotools et cmake!) pour t'assurer que ça cross-compiles bien et corriger les éventuels accrocs.
Il m'est déjà arrivé de corriger des projets en un mini-patch qui n'avaient jamais même pensé que leur projet marcherait avec win32. C'est le cas par exemple de la bibliothèque GExiv2 (quand on s'est mis à utiliser Exiv2 et son wrapper GExiv2 pour GIMP, il fallait bien sûr que cela fonctionne sous Windows aussi). Ils utilisaient à l'époque un Makefile fait à la main, à l'ancienne. Je l'ai transposé en un Makefile.am + configure.ac tout à fait classiques. Je cross-compile. Pof! Ça marche! En un temps record, GExiv2 fut porté sous Windows (je pense même pas avoir eu à toucher une seule ligne de code). Les développeurs de cette bibliothèque m'ont dit qu'ils n'avaient jamais développé cette lib sur Windows, n'avaient jamais tenté de la compiler pour cette plateforme et ne s'étaient même pas dit que ce serait possible (puisqu'ils ne s'en préoccupaient pas depuis le début). C'est la magie des chaînes de compilation standards sous Linux (en tous cas, pour les 2 les plus répandus, autotools et cmake. Je n'ai jamais eu l'occasion d'en essayer d'autre dans un contexte de crossbuild).
Franchement, la cross-compilation, c'est pas un gros problème. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Cross-compilation
Posté par rewind (Mastodon) . Évalué à 2.
Ha tiens, il faudra que je réessaie pour mon jeu. Il y a eu des mises à jour de Mingw-W64, ça va peut-être corriger le bug que j'ai eu la dernière fois.
[^] # Re: Cross-compilation
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
N'hésite pas à me tenir au courant sur comment ça se passe.
Aussi j'ai déjà plusieurs évolutions sur ma copie locale. Dès que j'aurai un peu tout mis au propre et bien testé sur mes crossbuilds locaux, faudra que je sorte une v0.6 qui commencera à bien s'approcher d'un outil que je pense vraiment indispensable pour enfin se débarrasser de tous les scripts sales et non portables "par projet" que chacun fait dans son coin pour chaque cross-compilation.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# IDE
Posté par barmic . Évalué à 8.
Pour aussi bosser en Java (mais c'est pareil pour les développeurs C#), c'est vraiment des manières de travailler différentes. Un intellij est capable de faire de l'autocomplétion intelligente, de faire des refactoring sophistiqués (tu utilise un identifiant qui n'existe pas, il te propose d'ajouter un paramètre à ta fonction avec un type cohérent (que tu peut changer), et de lui donner une valeur par défaut (partout où la méthode sera appelée il ajoutera cette valeur dans les paramètre) ou d'ajouter une donnée membre à ta classe etc).
Bien sûr les IDE c'est mal quand on apprend, il faut comprendre ce qu'on fait, etc, etc. Mais personnellement j'ai plus à apprendre les bases du langage dans le quel je travail, maintenant je l'utilise et j'essaie de produire du code de qualité. Plus important, je relis mes diff avant de commiter/pusher. Au lieux de perdre 2h à faire des refacto à la main (à coup de Ctrl+c/Ctrl+v, pas très enrichissant1) voir à coup de
grep/sed(pour ceux qui utilisent cette dernière méthode j'ose espérer qu'ils relisent en détail les diff parce que c'est nettement plus casse gueule que ce que fait un IDE), je passe 10-15 minutes à relire mes diff. Le gain est réel.Aucun rapport mais pour l'édition du code, moi qui utilise vim à longueur de temps j'ai commencé à jouer avec les multi-curseur. C'est vachement bien ça ! Il va vraiment falloir que ce soit ajouté dans vim ou au pire emacs.
les macro vim peuvent aider, intellij a une fonctionnalité pas mal aussi avec SSR. ↩
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: IDE
Posté par Dinosaure (site web personnel) . Évalué à 2.
Il y a un plugin pour ça: https://github.com/terryma/vim-multiple-cursors (et il y en a d'autres)
# Jeux de mots tard
Posté par kupka . Évalué à 10.
Tu racontes tes amours à Nal ?
Ben bravo, c'est du propre !
[^] # Re: Jeux de mots tard
Posté par reynum (site web personnel) . Évalué à 5. Dernière modification le 26 septembre 2014 à 15:29.
Mouai, jeu de mots laid pour gens bêtes ;-)
mais très bon au demeurantkentoc'h mervel eget bezan saotred
[^] # Re: Jeux de mots tard
Posté par kupka . Évalué à 5.
Pour les moinsseurs pressés, il s'agit d'une référence à l'excellentissime Bobby Lapointe.
Très bonne référence \o/
# plop
Posté par CrEv (site web personnel) . Évalué à 3.
Il y a aussi CLion. Je le teste depuis quelques temps et à part une mauvaise gestion des macros du type
__LINE__(il ne l'utilise pas bien et affiche des erreurs dans le code alors qu'il n'y en a pas, par exemple sur des macros qui créent des identifiants uniques) ça marche plutôt pas mal.Hein ? Nan mais ça fait un moment qu'on est plus obligé d'utiliser ce genre de truc pour gérer les
.h…#pragma onceFranchement je sais pas pour quelle foutu raison les gens ne se sortent pas les doigts pour l'utiliser. Certes, si on lit wikipedia il parait que c'est pas standard et non supporté par tout le monde, mais bon quand on regarde la liste on a tout de suite 'achement moins peur. Donc
#pragma once.[^] # Re: plop
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Il n'y a pas une option pour avoir l'effet de
#pragma oncepour tous les .h? Je ne me souviens pas une seule fois d'avoir eu un .h à inclure plusieurs fois…Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: plop
Posté par vincent LECOQ (site web personnel) . Évalué à 1.
J'ai déjà vu ce cas se produire une fois chez un collègue dans une histoire de modules/plugins sous windows.
Il me semble bien que tout le code est parti à la poubelle quelques mois plus tard.
[^] # Re: plop
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu n'as jamais de class utilitaire définit dans un fichier util.h que tu utilises un peu partout ?
"La première sécurité est la liberté"
[^] # Re: plop
Posté par CrEv (site web personnel) . Évalué à 2.
nan mais au final tu ne l'inclus qu'une seule fois.
Je pense que ce qu'il veut dire c'est un .h que tu inclus réellement plusieurs fois (donc sans #ifndef)
[^] # Re: plop
Posté par freem . É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: plop
Posté par CrEv (site web personnel) . Évalué à 3.
Heu, oui mais non.
Certes il sera inclus, mais comme il va rencontrer (là deuxième fois et les suiantes) un
#findef BLABLA_Hqui sera défini, il ne va rien inclure du tout.Donc le code de ton
.hsera bel est bien inclus une seule fois (sauf cas très particuliers)[^] # Re: plop
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Il fallait comprendre "plusieurs fois avec le besoin que le contenu soit répété et non gardé par un ifndef/pragma".
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: plop
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
A part dans des cas tordu, je ne crois pas.
https://en.wikipedia.org/wiki/X_Macro
"La première sécurité est la liberté"
[^] # Re: plop
Posté par Gof (site web personnel) . Évalué à 3.
Exactement. Exemple:
Le premier bout de code est dans un header mais le tout fini dans la même translation unit
Le fichier super_value.def ressemble à ça:
(possiblement auto-généré)
[^] # Re: plop
Posté par Zenitram (site web personnel) . Évalué à -5.
http://en.wikipedia.org/wiki/Pragma_once
In the C and C++ programming languages, #pragma once is a non-standard but widely supported preprocessor directive (…)
Programmer en non standard, ce n'est pas terrible (sympa pour les compilos qui se conforment au standard mais n'ont pas ce truc). A utiliser que si on n'a pas pour but de diffuser son code plus que ça.
[^] # Re: plop
Posté par CrEv (site web personnel) . Évalué à 10.
Bien.
Maintenant tu peux relire mon message jusqu'au bout :
Ho tiens, c'est le même lien et la même information…
Ha oué ? Et tu peux m'expliquer dans quel cas normal ça ne passerait pas ? Parce que justement si on suit le lien on a :
[^] # Re: plop
Posté par karteum59 . Évalué à 3. Dernière modification le 26 septembre 2014 à 14:22.
Pas sûr que ça soit supporté par TCC ? (cela dit ce dernier ne gère que ISOC99 et pas C++, donc hors-sujet pour Devnewton)
[^] # Re: plop
Posté par Thomas Debesse (site web personnel) . Évalué à 5. Dernière modification le 26 septembre 2014 à 12:41.
Est-ce qu’il existe un autre compilateur que Clang, Comeau C/C++, C++Builder XE3, Digital Mars C++, GCC, Intel C++ Compiler, Microsoft Visual C++, Pelles C, ARM DS-5 et IAR C/C++ qui sera susceptible de compiler le nouveau jeu de devnewton< ? C’est la vraie question en fait.
cf. https://en.wikipedia.org/wiki/Pragma_once#Portability
[Edit: arg, grillé par CrEv :D]
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: plop
Posté par Kekun (site web personnel, Mastodon) . Évalué à 5.
Si c'est pour un jeu, faut voir quels compilos sont utilisés (ou utilisables) pour les "homebrew" sur consoles de jeux (Pandora, PSP, DS…), ça pourrait être un frein à la portabilité pour le jeu.
[^] # Re: plop
Posté par flan (site web personnel) . Évalué à 1.
Alors, peut-on avoir un retex sur CLion, à part ce problème de macros ? Bon, il est encore en beta à ma connaissance, c'est normal qu'il ne soit pas encore parfait.
Je commence à bien connaître PyCharm (qui m'a fait totalement oublier un VIM configuré avec amour), et un peu IntelliJ (qui m'a fait mettre rapidement Eclipse à la poubelle, comme tous ceux que je connais et qui ont essayé IntelliJ ou PHPStorm), et du coup j'attendais avec impatience qu'ils fassent un IDE C/C++. Maintenant, plus qu'à trouver un projet à faire en C++ :D
Pour ceux qui ne connaissent pas, contrairement à Eclipse qui est multilangage, Jetbrains publie un IDE par langage (IntelliJ pour le Java/Scala, PyCharm pour le Python, PHPStorm pour le PHP, RubyMine pour le Ruby), avec parfois des plugins pour une prise en charge limitée d'autres langages.
[^] # Re: plop
Posté par CrEv (site web personnel) . Évalué à 2.
Pour le moment j'ai aucun problème avec, l'auto reload de cmake fonctionne plutôt bien, la complétion aussi.
Ça prend un peu de ram quand même… mais sinon c'est sympa, il y a des symboles pour passer du prototype à l'implémentation d'une méthode facilement, l'intégration aux gestionnaires de sources est bonne, etc.
Le problème des macros est quand même assez spécifique, genre si on utiliser
__LINE__ou__COUNTER__pour créer des variables uniques, les deux macros ne sont pas bien interprétées et sont à 0. Résultat les variables uniques ne le sont plus pour l'IDE et il affiche en rouge.Ex :
Le résultat devrait être
pour CLion le résultat est
Et donc forcément ça ne passe pas. Bon c'est génant mais pas ultra horrible. Le problème c'est que c'est souvent utilisé dans les framework de tests unitaires.
D'ailleurs question bonus, si quelqu'un sait comment faire une macro pour avoir un nom de variable unique sans
__LINE__ni__COUNTER__ça m'intéresse vraiment ;-)[^] # Re: plop
Posté par flan (site web personnel) . Évalué à 2.
Effectivement, c'est un peu dommage :(
Au passage, que donne le debuggueur ? Si j'ai bien compris, il est encore basé sur gdb.
N'y a-t-il pas de debuggueir plus récent ? Comme lldb ?
# KDevelop
Posté par Gof (site web personnel) . Évalué à 6.
Chez moi ça marche très bien.
Quelle version de KDevelop as tu utilisé ? Pourquoi plantait-il ?
[^] # Re: KDevelop
Posté par pamputt . Évalué à 3.
Idem ici. Si c'est une version récente, est ce que tu as rapporté les backtraces du crash sur le bugzilla ?
[^] # Re: KDevelop
Posté par GuiBrother . Évalué à 1.
Idem. J'ai bien connu le crash lamentable, c'était de kdevelop 4.0 à 4.4.
J'ai compilé la version de développement (4.6 à l'époque) et maintenant tout fonctionne parfaitement.
Ça vaut le coup de (re)tenter les toutes dernières versions.
# smart pointer
Posté par freem . É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: smart pointer
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Peut être la version de boost? Pour l'instant je ne garantis la compilation que sous Ubuntu 14 LTS :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: smart pointer
Posté par freem . É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: smart pointer
Posté par pasBill pasGates . Évalué à 0.
Et c'est totalement imbitable pour voir des structures imbriquees, genre STL.
Pour avoir passe l'annee derniere a developper sur Linux apres des siecles dans Visual Studio, j'ai vraiment l'impression d'etre passe du 21eme siecle a la prehistoire niveau debuggage, c'est incroyable a quel point c'est douloureux et non-productif. J'ai du mal a comprendre qu'une communaute tellement portee sur le developpement n'ait pas resolu ce point la.
[^] # Re: smart pointer
Posté par Anthony Jaguenaud . Évalué à 3.
Tu sais, dans l’industrie, j’ai des clients qui nous demande encore visual 6… alors tu sais…
Pour ton information, kdevelop, qtcreator, emacs sont très bien, font de la très bonne complétion. Kdev te propose même les inclusions. Visual a aussi pas mal progressé que ce soit au niveau du compilateur comme de l’IDE… mais personnellement, pour faire des remplacements, compilation… je préfère une ligne de commande. C’est juste une question de gout et d’habitude.
[^] # Re: smart pointer
Posté par pasBill pasGates . Évalué à 4.
Je parles de debuggage
Ni KDevelop, ni Emacs, ni Eclipse (que j'ai tous essaye) ne sont foutus de permettre de proprement debugger un programme sans y passer des heures. Car ils se basent tous sur gdb qui est un homme des cavernes de ce cote la (et je n'oses meme pas en parler quand tu ajoutes openmp dans le mix…), et leur capacite a interpreter proprement les containers STL par exemple est proche de zero.
[^] # Re: smart pointer
Posté par vincent LECOQ (site web personnel) . Évalué à 4.
Pour avoir passé ces quelques derniers mois du temps sous visual, en effet un debugger qui invente parfois des breakpoints de toutes pièces c'est à la limite de skynet en effet !
Et que dire de l'environnement qui freeze 4fois par jour parce que j'ai eu la drôle d'idée d'appuyer sur F7 …
Ou encore d'intellisense qui met 5 minutes à chercher la définition d'un truc placé honteusement 15 lignes plus haut dans le même fichier.
Que penser aussi de la boite de dialogue de configuration des entrées du linker qui date au moins des ergonomistes de windows 3.11
Et bien sur je ne parle pas des compils qui s'arrêtent sur une erreur inattendue de visual (certaines sont attendues au fait ?)
C'est con de payer une licence aussi chère pour se taper l'achat en parallèle d'un truc genre visual Assist pour enfin avoir une complétion honnête et du refactoring pas trop con.
paye paye paye …
[^] # Re: smart pointer
Posté par Gof (site web personnel) . Évalué à 5.
Sans oublier que MSVC, le compilateur C++ de Microsoft, est l'équivalent de IE en ce qui concerne le support des standard.
C++11 est normalisé depuis 3 ans. MSVC est terriblement en retard comparer aux équivalent libre (clang et GCC). Même la dernière version ne supporte pas encore tout.
[^] # Re: smart pointer
Posté par pasBill pasGates . Évalué à 1.
Chacun ses gouts. Je me contentes de constater qu'il m'est bcp, bcp, plus rapide de developper un soft sous Windows avec VStudio, eliminer un max de bugs grace a un debugger qui fonctionne proprement, et faire alors le portage sous Linux que faire le codage principalement sous Linux avec Eclipse/Emacs/KDevelop et gdb.
C'est quand meme con de devoir utiliser un Windows pour accelerer le developpement d'un soft Linux…
[^] # Re: smart pointer
Posté par Albert_ . Évalué à 2.
C' est fou tu es en train de dire que tu as tes habitudes et que tu n'aimes pas en changer. Comme c' est curieux tu es bien le premier humain comme cela…
[^] # Re: smart pointer
Posté par pasBill pasGates . Évalué à 2.
Tu remarqueras que j'ai liste un probleme tres precis : l'impossibilite du debugger utilise a afficher des conteneurs STL.
Quand ton soft est totalement base sur STL, vecteurs, maps, string, smart pointers, … on va dire que c'est un probleme sacrement dur a vivre avec.
[^] # Re: smart pointer
Posté par Shuba . Évalué à 2.
Je sais pas pour les autres conteneurs STL mais Qt Creator s'en sort très bien avec les std::vector et les std::string, probablement parce qu'il inclut de base des scripts gdb pour bien les gérer.
[^] # Re: smart pointer
Posté par freem . Évalué à 5.
Chez moi ça marche.
Source:
Sortie de gdb (enfin, cgdb, mais c'est juste un frontend):
Bien entendu, je n'ai exécuté en pas à pas que quelques itérations, pour l'exemple. Donc, problème résolu?
À noter tout de même pour l'honnêteté intellectuelle, il me semblait qu'il fallait faire appel à des trucs plus retors (à l'époque ou j'utilisais C::B, il me semble qu'il y avait besoin de faire appel à du python. Je n'ai jamais creusé la question ceci dit…), il y à quelques mois. J'imagine que ça ne fonctionne que sur des versions un minimum récentes de gdb donc.
[^] # Re: smart pointer
Posté par LeMagicien Garcimore . Évalué à 2.
C'est assez récent: GDB 7.0 il me semble, avec l'introduction de l'API Python et ses pretty-printer (qui est vraiment pas mal).
https://sourceware.org/gdb/current/onlinedocs/gdb/Writing-a-Pretty_002dPrinter.html#Writing-a-Pretty_002dPrinter
[^] # Re: smart pointer
Posté par lasher . Évalué à 2.
Est-ce que c'est aussi vrai pour debugger des programmes multithreadés ? (c'est une vraie question, mon expérience sous unix est que de toute manière comme j'écris mes propres bibliothèques de threads au-dessus des PThreads, je me retrouve à avoir des outils pour faire des traces, et je n'utilise que rarement la capacité de gdb à suivre les PThreads…)
[^] # Re: smart pointer
Posté par pasBill pasGates . Évalué à 0.
J'ai un layer d'abstraction pour la creation de threads/lock/unlock/… et ca n'a donc pas vraiment d'effet pour moi. Mais pour avoir utilise OpenMP, gdb pourrit totalement le debuggage avec ca(du moins c'est l'experience que j'en ai eue a travers Eclipse)
[^] # Re: smart pointer
Posté par lasher . Évalué à 2.
OpenMP c'est différent : ils utilisent un système de user threads au-dessus des pthreads. Du coup à moins de patcher gdb pour avoir les bons hooks vers les threads omp, tu pourras pas faire grand chose. Un de mes collègues au CEA avait pris un stagiaire juste pour rajouter les bons outils de debug dans gdb pour sa bibliothèque de threads mixtes (pthreads+user threads). Ça marchait très bien ensuite.
[^] # Re: smart pointer
Posté par pasBill pasGates . Évalué à 0.
Pour moi peu importe la raison… OpenMP est dans gcc depuis un moment, mais du fait de l'impossibilite de debugger ce code car tous les IDEs utilisent gdb, c'est inutilisable sur Linux. J'ai du me resoudre a faire ca sous Visual Studio et ensuite porter la chose. On va dire que c'est vraiment pas ideal comme experience pour un developpeur.
[^] # Re: smart pointer
Posté par lasher . Évalué à 2.
Moui enfin, OpenMP est dans MVC++ mais seulement en v2.0, alors qu'on est passé à v2.5 puis 3.0, puis 3.1. Et tous les compilos — Intel cc, gcc, Sun cc, etc., implémentent le standard1. Est-ce que MSVC++ permet de débugger les threads OpenMP ? (là encore, vraie question)
Bon par contre OpenMP 4.0 sortie l'an dernier rajoute le support des GPU et du coup à part Intel qui propose une implémentation partielle, y'a pas grand chose de mise en œuvre pour cette version-ci. ↩
[^] # Re: smart pointer
Posté par pasBill pasGates . Évalué à 0.
Ben oui, c'est justement comme ca que je l'ai fait… Codage / debuggage sous Windows autant que possible et portage aussi tard que possible.
C'est bien sympa que gcc soit a la pointe avec openmp, mais si c'est impossible a utiliser car impossible a debugger, ca sert a rien… :/
[^] # Re: smart pointer
Posté par lasher . Évalué à 3.
En même temps, à ma connaissance, le compilo d'Intel ne fait pas mieux, et idem pour la plupart des concurrents Quelque part j'ai envie de dire « C'est bien beau de fournir un env. de debugging pour OpenMP 2.0, mais on n'est plus en 2004. » :-P
De plus, les gens qui bossent sur des applis avec plusieurs centaines ou milliers de threads OpenMP n'utilisent pas de debuggers parce que trop compliqué (à moins de te faire pousser quelques dizaines d'yeux, comment tu fais pour surveiller les cas chiants du type data race ?). Du coup la plupart des gens qui bossent sur des applis massivement multithreadées passent par des trucs du genre
omp barrierouomp taskwait+printf. En règle générale, dans le monde du HPC, il y a peu voire pas de vraie solution de debug pour le parallélisme massif. Et la réponse des gens à ce problème est en gros « utilise un langage qui limite les possibilités de data race, genre DSL, langages fonctionnels, ou quasi-fonctionnels (i.e. multi-paradigmes) ».Pour ce genre d'applications (HPC), le debugger « idéal » serait sans doute un truc qui permet d'enregistrer une trace sur N cycles ou secondes, puis qui permette de « rejouer » la séquence et d'analyser les valeurs. Le problème est la taille de la trace résultante, et surtout les heisenbugs : même comme ça tu risques d'avoir des soucis pour trouver le bug en question.
Note que j'aime beaucoup le debugger de MSVC++, juste que le manque de fonctionnalités du compilo en fait quelque chose de pas très intéressant pour faire du dév OpenMP un peu poussé (il y a tout un tas d'applis de simulation numériques qui tirent fortement partie des
tasksOpenMP pour la traversées de structures de graphe ou tableaux « creux »).[^] # Re: smart pointer
Posté par pasBill pasGates . Évalué à 0.
Notes bien que je ne blames pas le compilo hein, c'est gdb et les IDEs qui l'utilisent qui sont le probleme de mon point de vue.
Mon utilisation d'openmp n'est pas du tout pour du HPC, c'est simplement pour tres facilement parralleliser des boucles qui s'y pretent bien (quasiment rien a locker dedans, juste besoin d'un join a la fin de la boucle).
[^] # Re: smart pointer
Posté par lasher . Évalué à 2.
Je comprends bien. Apparemment, le compilo d'Intel (idb) ne fait rien pour OpenMP. Celui de
SunOracle permet d'insérer un break point à l'entrée d'une région parallèle, mais sans réellement permettre de décider quel thread on veut surveiller (le premier thread arrivé est celui qu'on surveille), du coup je trouve ça assez limité aussi… Du coup le manuel propose plutôt d'utiliser les stack traces (voir ici par ex). XL/C (le compilo d'IBM) ne semble pas avoir de support du tout, etc.[^] # Re: smart pointer
Posté par Michaël (site web personnel) . Évalué à 4.
J'ai travaillé plusieurs années sous VisualStudio 2008 sur un très gros projet — appli industrielle de gestion de risque financier — en C++ et je dois dire que le débogueur visuel est excellent — à ceci près que notre version n'incluait pas de fonction
trace, mais les fonctions offertes sont très bonnes. Il a toujours fonctionné de façon à peu près correcte — ce qui sur une codebase pré-STL de plus de 30 ans, qui sert accessoirement de vitrine à toutes les mauvaises pratiques de programmation imaginables, est un succès non-négligeable.Le problème de la boîte est qu'il était utilisé en guise de documentation technique — c'est à dire, pour comprendre l'organisation du code, la seule ressource était de faire du pas à pas! :)
[^] # Re: smart pointer
Posté par Anthony Jaguenaud . Évalué à 2.
Moi j’ai eu des cas, ou tu as du matériel de test pendant 4h. Tu trouves un premier bug, mais si on le corrige, il y a 5h de recompilation… donc, pouvoir scripter un test, ajouter un breakpoint, modifier une variable avancer de 5 instructions, remodifier une variable, pour enfin être prêt à trouver un deuxième bug… et bien je suis content que gdb soit en ligne de commande, qu’on puisse lui passer des scripts, etc.
Après, pour des softs avec IHM, un débogueur en IHM aussi peut suffire.
[^] # Re: smart pointer
Posté par Sufflope (site web personnel) . Évalué à 2.
Je ne suis pas sûr de bien comprendre, donc je vais éviter de m'énerver, parce que mon incompréhension vient peut-être simplement du fait que tu ne sais pas t'exprimer de manière construite, mais… si je lis ce que j'ai cité, j'en déduis que tu crois qu'on ne peut
avec un debugger "sale" (pour un langage "sale" genre Java dans un outil "sale" donc graphique) ?
Dans quel monde tu vis ?
Du coup je vais jouer au même jeu du "ma feature basique est inimaginable pour les autres" et poser des questions basées sur mon usage basique du debugger d'IntelliJ IDEA dans mon code Groovy.
[^] # Re: smart pointer
Posté par Anthony Jaguenaud . Évalué à 5.
Non, ce n'est ni ce que j'ai dit, ni ce que je crois.
Dans un monde où les bancs industriels coûte cher, ils sont donc partagés. Donc quand tu as une après midi sur le banc pour faire tes tests, tu y restes coûte que coûte. Si tu trouves un bug rapidement à 14h30. Tu as deux choix, soit tu corrigse et recompiles, mais le temps de recompilation (4h) me donnera un nouvel essai dans, heu ben demain en fait. Sauf que le lendemain, je n'ai pas de créneau avant 16h.
Pour optimiser mon temps sur le banc, je recommence en « corrigeant » le bug dans le débugger. A ce point, j'ai deux choix, soit je contourne le bug à chaque fois manuellement (avec une interface graphique), avec gdb, je peux scripter cette partie et gagner du temps.
Il est possible qu'une bonne interface graphique de debug permette de scripter, mais je n'en connais pas.
Oui.
Je ne suis pas sûr de comprendre le « peu importe ce qu'il se passe ».
Je ne sais pas le faire, mais il me semble que gdb sait faire depuis quelques versions.
[^] # Re: smart pointer
Posté par CrEv (site web personnel) . Évalué à 4.
Vous n'utilisez pas d'IDE ?
Mais c'est vrai que je n'ai toujours pas compris comment on peut être content à ce point de gdb (enfin non pas de l'outil en lui même mais de son "utilisabilité")
[^] # Re: smart pointer
Posté par pasBill pasGates . Évalué à 1.
Moi si, mais tous les IDEs Linux se basent sur gdb, et aucun n'est foutu d'afficher correctement le contenu d'objets en C++ donc bon, ca ne resoud rien…
[^] # Re: smart pointer
Posté par freem . É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 groumly . Évalué à 0.
Parce que c'est une communaute qui met un point d'honneur a utiliser les outils les plus pourris possibles pour prouver a quel point ils sont l33t et plus malin que les autres.
Syndromes du "nan mais j'ai pas besoin de ca moi, je suis plus malin que le compilo".
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: smart pointer
Posté par Troy McClure (site web personnel) . Évalué à 4.
Peut etre aussi qu'au fond les debuggers c'est un peu de la merde, ça passe son temps à perdre les symboles de debug ou à afficher de la merde parce que le niveau d'optim est trop fort, et que ce n'est pas si indispensable que ça.
[^] # Re: smart pointer
Posté par Gof (site web personnel) . Évalué à 3.
Je debug quasi uniquement à l'aide de
printfqDebug()[^] # Re: smart pointer
Posté par CrEv (site web personnel) . Évalué à 2.
Si encore quelqu'un expliquait qu'il ne debug pas mais fait tout par des tests (unitaires et autres) je comprendrais, mais là ça devient vraiment triste :-(
[^] # Re: smart pointer
Posté par Troy McClure (site web personnel) . Évalué à 1.
qu'est-ce qui est triste exactement ?
[^] # Re: smart pointer
Posté par CrEv (site web personnel) . Évalué à 3.
les gens qui "debug" à coup de printf/qDebug/etc
[^] # Re: smart pointer
Posté par Troy McClure (site web personnel) . Évalué à 3.
oh vraiment ? et tu peux prouver que tu es plus efficace avec ton gros debuggeur lourdingue ? J'en doute. Moi je ne sors le debugger que pour les bugs triviaux (genre ca segfault). Le reste du temps, les bugs un peu plus vicieux et compliqués , c'est au printf + affichage de stack trace. Je ne vois pas ce qu'un debuggeur apporte de plus a part de la lourdeur et de la fragilité.
[^] # Re: smart pointer
Posté par Zylabon . Évalué à 7.
Moi je peux… C'est juste que tu ne sais pas te servir d'un debuggeur.
Ton debug flow c'est :
Avec un debuggeur, tu pourrait faire exactement la même chose, en plus efficace :
T'économise le temps qu'il faut pour écrire plein de printf, tu ne pourri pas ton code source, tu n'a pas à faire des grep avec les yeux, tu n'a pas à recompiler 15000 fois juste pour trouver le bug…
En plus ! Tu peux programmer le debuggeur pour amener directement le programme au bug par exemple, ou pour afficher joliment une structure compliquée… Tu peux suivre chaque thread séparément, sauter de l'un à l'autre,… bref, avec tu peux vraiment entrer dans l’exécution du programme, avec des printf on ne fait que lui faire semer des petits cailloux.
Please do not feed the trolls
[^] # Re: smart pointer
Posté par Gof (site web personnel) . Évalué à 7.
Tu as raisons. (Puisque tu peux simuler facilement des printf avec un bon débugger, utiliser les printf est un sous ensemble d'utiliser un débugger)
Cependant, je pense que la tache qui prends le plus de temps et d'effort est le point 1. (essayer d'imaginer ce qui peut se passer).
L'art de débugger consiste à déterminer l'endroit ou mettre les printf / breakpoint: pauser des hypothèses et les vérifier. Ne pas trop so focaliser sur les symptomes mais essayer de trouver la cause d'un problème. Et bien comprendre le problème.
Considérant ça, printf ou un débugger c'est un peu pareil. L'avantage de printf est que c'est écrit dans le même langage que le produit et que tu à accès à toute les bibliothèques pour afficher les valeurs que tu veux. L'inconvénient c'est qu'il faut recompiler et relancer. (Ce que tu devras quand même faire si tu cherche à corriger le problème)
[^] # Re: smart pointer
Posté par xcomcmdr . Évalué à 3.
Pour ça et déboguer en même temps, il y a les "espions" dans Visual Studio. Je peux y mettre une variable existante pour savoir sa valeur actuelle ou un appel/expression, et autant que je veux. Nul besoin d'arrêter, coder des appels à prinf/echo/au log managaer, et de relancer. Vu le temps gagné, adieu printf !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: smart pointer
Posté par freem . É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 CrEv (site web personnel) . Évalué à 3.
Ok, tu en doutes. Et tu peux prouver que tu es plus efficace avec ton printf limité ? Genre comment tu affiches une structure un peu complexe sans y passer plein de temps ? Comment tu affiches une donnée que tu ne pensais pas initialement nécessaire (je veux dire sans modifier ton code, recompiler, réexécuter ?)
Et bon, un debuggeur ça ne se limite pas qu'à du printf/stacktrace. Si c'était le cas peut-être qu'on pourrait comparer un peu, mais ce n'est pas le cas du tout.
Comment tu fais pour que ton programme s'arrête à un état donné (un breakpoint conditionnel) ? Tu écris du code avec un while(true) ?
Et comment tu sautes à une instruction avec ton printf ?
Alors c'est sur que gdb et la pauvreté des interfaces dans le monde linux ça ne donne pas du tout envie de debugger quoi que ce soit, ça c'est vrai. Mais dire qu'on en a pas besoin moi ça me fait penser à tous ceux qui disent que les IDE ça ne sert à rien puisqu'il y a grep/sed/awk. Mais va faire un refactoring correct simplement avec ça…
[^] # Re: smart pointer
Posté par pasBill pasGates . Évalué à 3.
Moi oui je peux.
Au hasard :
Tu peux mettre un breakpoint et voir les variables du systeme, incluant la stack, incluant la valeur des variables dans chaque frame, incluant les valeurs sur lesquelles les pointeurs pointent … n'importe ou a chaud.
Tu peux changer de breakpoint, l'enlever, … a chaud, n'importe quand. En 3 secondes.
Tu peux modifier le code a la volee, continuer l'execution
Tu peux bouger le registre d'instruction et le remettre au debut d'un bout de code pour revoir son execution sans devoir tout relancer
Tu peux voir ton buffer en memoire a chaud, pas a pas, y inclus les qqe bytes suivant / precedant le buffer, et t'assurer que le probleme n'est pas du a un ecrasement d'une autre variable par exemple.
etc…
Un debugger et printf, c'est aussi different qu'une BMW et une Trabant. Les 2 permettent de rouler, mais un des deux est bcp plus rapide, plus agreable et plus fiable.
[^] # Re: smart pointer
Posté par lolop (site web personnel) . Évalué à 0.
Un test unitaire te dis que ça ne passe pas, vers où ça ne passe pas, mais il t'indique rarement directement la correction à faire et où. Ou alors y'a eu de forts progrès dans le domaine de l'ingénierie du développement de logiciels.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: smart pointer
Posté par GeneralZod . Évalué à 4.
Si à la simple vue du nom du test qui échoue, tu n'es pas capable d'identifier le code fautif, c'est que ton test est pourri.
[^] # Re: smart pointer
Posté par 2PetitsVerres . Évalué à 2.
Je bosse dans un milieu où on fait tout un tas de tests (unitaires ou non) et franchement, même en test unitaire ce n'est pas toujours facile de comprendre d'où vient un bug. (ou alors parfois c'est évident mais on se dit quand même que le programmeur ne peut pas s'être planté 3 fois dans l'implémentation du calcul d'une médiane, mais c'est un autre problème)
Dernièrement j'ai eu pas mal de mes tests unitaires qui passaient sur ma machine, sur d'autres PC, mais pas une fois compilés pour la plateforme cible. Du coup si je n'avais fait que le test sur la plateforme cible, j'aurais eu du mal à dire ce qui était fautif dans le code juste à la vue du nom, vu que ce n'était pas dans le code.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: smart pointer
Posté par groumly . Évalué à 6.
Ton test unitaire va te donner LA fonction dans laquelle il ya un bug et LE cas dans lequel ca bug.
En clair, dans l'immense majorite des cas, ca va faire 70% du boulot, a savoir identifier le bug et te pointer vers une 20aine de ligne qui sont fautives dans un cas tres precis.
Si ton test ne fait pas ca, reecrit les (ou arrete d'en ecrire, tu perds ton temps).
Le probleme en general, c'est plutot d'avoir un test qui choppe le probleme, mais si t'as un test qui passe pas, la correction devient tres simple.
Apres, si tu veux tester une UI, les test unitaires vont pas t'aider des masses. Ya des outils pour ca, mais ca reste douloureux en general.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: smart pointer
Posté par Spack . Évalué à 2.
Oui… Dans le cas où le test unitaire test un cas qui reproduit le bug. Dans la majorité des cas, on définit des tests plutôt simples. Et les bugs sont rarement détectés par ce moyen.
Par contre, les tests unitaires peuvent très bien déceler certaines régressions.
[^] # Re: smart pointer
Posté par xcomcmdr . Évalué à 4.
Bah dans ce cas tu rajoutes du code dans ton test qui reproduit le bug. Sinon, ça n'a pas beaucoup d'intérêt d'avoir des tests.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: smart pointer
Posté par Spack . Évalué à 2.
Cela implique de connaître le bug à l'avance, dans ce cas autant écrire un code sans bug. Ou alors, que le bug a été découvert par un autre moyen et cela permet d'adapter les tests.
Sauf à utiliser du fuzzing, un test unitaire va rarement te découvrir un bug.
[^] # Re: smart pointer
Posté par xcomcmdr . Évalué à 4.
Euh, je parlais de rajouter un test/modifier un test pour reproduire le comportement qui à mis à jour le bug, une fois le bug corrigé. Pour éviter de l'introduire à nouveau dans le futur.
Je vois pas le rapport avec de de la divination ou être parfait
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: smart pointer
Posté par TeXitoi (site web personnel) . Évalué à 4.
Mais c'est vrai que ça fait pas longtemps que Debian configure correctement gdb par défaut.
[^] # Re: smart pointer
Posté par grim7reaper . Évalué à 2.
Oui, depuis GDB 7.0 y'a des pretty-printer en Python pour la STL (et tu peux ajouter les tiens pour tes propres types).
[^] # Re: smart pointer
Posté par freem . É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: smart pointer
Posté par rewind (Mastodon) . Évalué à 3.
Et ça marcherait pas aussi bien avec un
assert? Personnellement, j'en mets des tonnes partout où je peux. et quand ça crache via unassert, ça me crée un fichiercoreet je peux connaître la stack trace viagdb(c'est d'ailleurs ma seule utilisation de cet outil).[^] # Re: smart pointer
Posté par freem . É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: smart pointer
Posté par rewind (Mastodon) . Évalué à 3.
Aucune option particulière, mais j'autorise les fichiers
core(aveculimit -c unlimited), c'est peut-être ça ton souci. Ensuite, je lancegdbavec le nom de l'exécutable et le fichier core et je tape la commande magiquebt(comme backtrace) et là, il m'affiche la pile d'appel avec toutes les lignes dans les fichiers qui vont bien.[^] # Re: smart pointer
Posté par freem . É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: smart pointer
Posté par lasher . Évalué à 3.
Pour les
asserts qui doivent toujours échouer, tu ne peux pas bêtement faire ça ?[^] # Re: smart pointer
Posté par freem . Évalué à 2.
Tu veux dire pour le manque de message d'erreur… C'est une bonne idée en effet.
[^] # Re: smart pointer
Posté par Pierre Roc . Évalué à 2. Dernière modification le 03 octobre 2014 à 15:11.
C’est la revanche des gauchers. MOUHAHAHA !
# Trop gros, passera pas.
Posté par Guillaume Camera . Évalué à 0.
Je sais qu'on est vendredi , mais quand même !
[^] # Re: Trop gros, passera pas.
Posté par LeXa1979 . Évalué à 2.
Non non, il ne s'y prend pas si mal que ça.
L'acacia acajou de l'académie acoustique est acquitté de ses acrobaties. Tout le reste prend "acc".
[^] # Re: Trop gros, passera pas.
Posté par reynum (site web personnel) . Évalué à 4.
Il faut dire que la moule est joueuse aujourd'hui !
kentoc'h mervel eget bezan saotred
[^] # Re: Trop gros, passera pas.
Posté par freem . Évalué à 9.
Oui, elle n'est pas fermée comme une huître.
# J'aurais dû faire un journal qui troll pour qu'on réponde à mes questions, moi aussi
Posté par fox . Évalué à 7.
Tu es trop balèze, devnewton. Tu as rameuté tout plein de dev C++ qui montrent la puissance du C++ par rapport au Java (alors qu'il y a pas vraiment de comparaison à faire).
La prochaine fois, je ferai aussi un journal pour poser des questions sur des IDE, et tout et tout, concernant le C++ :
http://linuxfr.org/forums/programmation-c/posts/autocompletion-dans-qtcreator-comme-dans-eclipse (petite pub pour mon topic, siouplait :))
Il faut croire qu'il n'y a pas grand monde qui aime les forum mais quand il y a un journal qui écorche la techno préférée de quelques-un, wahou, c'est la fête :D
[^] # Re: J'aurais dû faire un journal qui troll pour qu'on réponde à mes questions, moi aussi
Posté par devnewton 🍺 (site web personnel) . Évalué à 10. Dernière modification le 26 septembre 2014 à 17:03.
Les gens sont plus motivés pour te montrer que tu es wrong on the internet que pour t'aider!
Savoir bien exploiter ce travers de l'internaute permet d'obtenir une aide de qualité!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: J'aurais dû faire un journal qui troll pour qu'on réponde à mes questions, moi aussi
Posté par totof2000 . Évalué à 8.
Arrête, tu vas donner des idées aux étudiants qui veulent nous faire faire leurs devoirs !!!
[^] # Re: J'aurais dû faire un journal qui troll pour qu'on réponde à mes questions, moi aussi
Posté par lasher . Évalué à 2.
À ce sujet, je me posais la question de la meilleure façon d'implémenter une liste chaînée en C, et du coup je me disais que comme ça ça pourrait le faire :
Vous en pensez quoi ? :P
# Projet perso = ce qui te fait plaisir !
Posté par Enerian . Évalué à 1.
C'est pour un projet perso, et les deux langages te permettront de faire la même chose -> utilise celui qui t'éclate le plus (ou qui te prend le moins la tête) ;)
[^] # Re: Projet perso = ce qui te fait plaisir !
Posté par devnewton 🍺 (site web personnel) . Évalué à 6. Dernière modification le 26 septembre 2014 à 20:56.
Ce qui m'éclate c'est de faire des jeux, le langage importe peu. Pour le premier, j'ai pris Java pour me former. Pour le second, il fallait aller vite, j'ai repris Java, car j'avais tout le code prêt à copier coller. Cette fois je prends C++ pour ne pas perdre la main.
Dans la vie quand on a un marteau, les problèmes ressemblent tous à des clous.
En IT, c'est la même chose, mais on prends un tournevis.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Projet perso = ce qui te fait plaisir !
Posté par gaaaaaAab . Évalué à 10.
pour terminer le proverbe, "et quand ton marteau, c'est C++, tout ressemble à un doigt" ! :D
# Gestionnaire de projets
Posté par Meku (site web personnel) . Évalué à 5.
Ça fait un moment que je n'ai pas eu à programmer en C ou C++, donc je ne suis plus trop au fait des derniers outils de build modernes. Quand je fais du C ou C++, j'utilise encore make.
Toutefois, en Ada (oui j'ai cette chance de développer en Ada au boulot), il y a depuis quelques années maintenant, un langage de haut niveau pour décrire les projets qui est élégant, simple à utiliser et assez complet. La syntaxe est proche du langage Ada, ce qui fait que c'est facilement lisible par des humains. C'est d'ailleurs devenu le standard dans le monde Ada pour décrire un projet.
Ces fichiers projet sont compris par tout plein d'outils de développement Ada : IDE, chaîne de compilation, analyse de code, etc. Parmi ces outils, il ya GPRbuild qui sait également compiler d'autres langages que Ada (genre le C++). On peut également mixer assez aisément plusieurs langages. Bref c'est vraiment du bonheur ce truc. Bon le seul bémol, c'est que ça fait partie des chaînes de compilation Ada. C'est pas forcément une dépendance couramment installée chez tous les développeurs. Et c'est quand même un peu orienté Ada ;-)
Un exemple tout simple pour illustrer quand même :
Je rêve de voir un truc similaire s'imposer (i.e., devenir quasiment un standard) pour le C et le C++.
Un peu de doc pour ceux que ça intéresse : http://docs.adacore.com/gprbuild-docs/html/gprbuild_ug.html
[^] # Re: Gestionnaire de projets
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
L'idéal pour moi, c'est un outil qui impose une organisation (les sources dans src, les binaires générés dans build… peu importe les noms), utilise un simple fichier de configuration (basé sur un format très connu comme json ou xml) pour renseigner les quelques propriétés nécessaires (nom du projet et liste des dépendances) et prends entièrement en charge le téléchargement des dépendances, la (cross)compilation et la génération des installeurs/packages.
Bref, je n'ai pas envie d'un nième maker basé sur un langage de script pour faire tout et n'importe, mais d'un outil qui me fait gagner du temps.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de projets
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
asdf.
De rien.
[^] # Re: Gestionnaire de projets
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Lapin compris :-(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de projets
Posté par Tonton Th (Mastodon) . Évalué à 3.
Tu devrais attendre un trolldi 13 pour ça.
[^] # Re: Gestionnaire de projets
Posté par TeXitoi (site web personnel) . Évalué à 2.
Cargo : http://crates.io/
Bon, OK, c'est pour Rust et encore un peu limité ;)
[^] # Re: Gestionnaire de projets
Posté par freem . É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: Gestionnaire de projets
Posté par barmic . Évalué à 3.
Un format qui fait plus q'une liste clef => valeur de facile à modifier pour un humain, personnellement j'en connais pas (mais je suis intéressé si tu as).
Ça se fait plutôt bien (le versionnement très bien) le diff un peu moins pour XML.
JSON s'en sort un peu mieux.
Mais YAML est le meilleur AMHA pour ça (il est sensible au retour à la ligne).
Je ne vois pas ce que ça change. Que ce soit du protobuf, de l'INI, du YAML ou autre ça ne te change pas grand chose pour ça.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de projets
Posté par freem . É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 barmic . Évalué à 3.
On doit pouvoir l'écrire en XML ainsi :
L'avantage c'est que tu as un format qui est largement supporté. Je peux facilement écrire un truc qui va l'analyser (pour mon intégration continue par exemple).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de projets
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Et si l'outil propose de bonnes options par défaut pour 99% des projets (les sources dans src, les options Wall & co…), on pourrait réduire à:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de projets
Posté par freem . Évalué à 2.
Utiliser -O3 par défaut serait une ânerie, ce niveau d'optim peut déclencher des bugs (je n'ai pas d'exemples précis en tête, cependant, mais une recherche devrait pouvoir te guider rapidement. Du côté du wiki de gentoo, peut-être?).
Idem, "-DPLUMA_EXPORTS" n'à rien de standard.
Générer des libs shared par défaut serait, encore, de bien mauvais goût, selon la taille, ça peut juste être un coup à générer du méchant bloatware (dans le cas de pluma, comme tout le monde l'aura lu dans le très concis exemple de VS, il y à 4 cibles: debug/release et share/static).
Imposer des paths n'est pas non plus une bonne idée, j'ai cru constater que les dev c++ sont loin de tous avoir les mêmes conventions, et ça peut même varier selon le projet: par exemple pour une lib, séparer les include d'interface des include utilisés par le source est fréquent.
Je ne parle même pas du cas ou le src contiens des sous-dossiers en fonction de l'interface utilisé… (aptitude est un exemple).
D'ailleurs, je pense qu'il est largement faisable de faire ce que tu as fait en autant de lignes avec cmake, si tu as un template à inclure… je ne vois pas pourquoi ça le serait.
Un truc genre (syntaxe à l'arrache):
Ne doit pas être infaisable. À ce niveau, je me demande(en tout cas on peut creer des fonctions) si on ne pourrait pas construire un template, ou plutôt une lib, qui permettrait d'écrire:
Alors, ok, c'est pas en standard, mais bon, ça fait bien ce que tu demandes, avec encore moins d'infos "inutiles" que ton xml.
[^] # Re: Gestionnaire de projets
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
C'est bien ça le problème: rien n'est standard.
Avant de démarrer un projet, il faut choisir des conventions, une organisation, utiliser des scripts compliqués…
Vu qu'il faut gérer les dépendances à la main, il faut se taper non seulement sa propre organisation, mais aussi celles de toutes les libs dont on dépends.
Oui tout est faisable, mais on perds un temps infini sur des tâches que les autres langages (java, go, python, ruby…) ont standardisées et automatisées.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de projets
Posté par freem . Évalué à 3.
"On doit", contre des "exemples concrets"…
Donnes-moi un outil concret qui accepte ton truc et compile?
Enfin, admettons. Tu trouves ton truc plus lisible pour un humain (enfin, pour un dev, puisque ce sont les dev qui maintiennent les cmakelists.txt en général) que le pendant cmake? Plus maintenable?
Dans ce cas, vraiment, on à des goûts différents et je doute qu'on puisse se convaincre l'un l'autre.
Quant au format… je vois ton truc, j'ai peur. Parce que je me dis que si je dois utiliser un outil de manipulation de texte (grep, sed, cut, etc) pour extraire une info précise de ce machin, je suis dans une merde assez profonde. Mais nul doute que ton
usine à gazoutil qui interprète ça te fournira tout ce dont tu as besoin je suppose?[^] # Re: Gestionnaire de projets
Posté par barmic . Évalué à 1. Dernière modification le 29 septembre 2014 à 19:45.
Pour un dev, tu peux utiliser à peu près n'importe quoi ça ne poeseras pas de problème, json, cmake, makefile, gpr, xml, script shell ou scons, c'est du détail.
La seule chose que je dis c'est que la grammaire XML est simple et elle est connu là où celle de cmake est spécifique.
Ouai si tu commence à utiliser ce genre d'outil pour aller chercher des choses dans ton cmakelits.txt t'es mal. Ça peut marcher pour pleins de cas simples mais tu ne peux pas distribuer tes scripts sans très largement t'emmerder à gérer les instructions multiples et de vérifier les données que tu récupère. Tu va aussi devoir gérer les commentaire par exemple.
Pour aller faire des recherches dans du XML de manière fiables tu a les requêtes XPath avec les commandes
xpath(fourni avec le module perlXML::XPath) ouxfind.Ben en fait, il y a un énorme paquets de gens qui fournissent tout ce dont je peux avoir besoin, chaque langage a plusieurs bibliothèques, mais tu as aussi des outils qui sont directement capable de faire du xpath (jenkins a un module pour ça par exemple). L'écosystème autour d'XML est largement plus grand que celui de CMake.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de projets
Posté par CrEv (site web personnel) . Évalué à 2.
Oué mais XML c'est bien pour du déclaratif, ce que n'est pas le langage de CMake.
Et on voit bien avec Maven que le déclaratif c'est bien sur le papier mais dans le vrai monde on fabrique des plugins en java pour pouvoir passer outre et avoir les comportements attendus.
[^] # Re: Gestionnaire de projets
Posté par rewind (Mastodon) . Évalué à 5.
Exactement, les cas particuliers sont gérés par du code particulier. Et le cas simple de 99% des gens, et bien une simple déclaration suffit. Et c'est tout ce que demande devnewton.
[^] # Re: Gestionnaire de projets
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Ajoutons que dans le monde java, l'un des effets bénéfiques de maven a été de faire des builds particuliers de vilains petits canards qu'on évite comme la grippe aviaire.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de projets
Posté par barmic . Évalué à 4.
Ah bon ?
On ne doit pas être dans le même vrai monde. Dans le miens c'est rare qu'on ai à le faire et le faire avec un langage complet comme celui de ton programme est plutôt agréable (la seule fois où j'en ai eu besoin c'était pour manipuler un fichier xls et remplacer la macro qui s'y trouvait (tu fais ça comment avec make ou cmake ?
J'apprécie beaucoup gradle et sbt mais c'est pas pour autant que maven est pourri.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de projets
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Et on configure ses plugins avec du déclaratif. Le système est bien fait.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de projets
Posté par Claude SIMON (site web personnel) . Évalué à 3.
On n'est pas obligé de subir le XML des autres.
Pour ma part, pour chacun de mes logiciels, j'écris un fichier XML, nommons-le 'Project.xml', dont c'est moi qui ai décidé de la signification des balises et attributs qu'il contient. Il y a ainsi quelques balises descriptives (nom du logiciel, numéro de version du logiciel, auteur…), et de nombreuses autres plus techniques (nom et localisation des fichiers sources, options de compilation…). Grâce à un ensemble de scripts et de fichiers XSL que j'ai développés, je génère, à partir de ce 'Project.xml', les fichiers '.vcxproj' et '.vcxproj.filters' qui permettent de compiler le logiciel à l'aide de Visual Studio, ainsi que le Makefile qui permet de compiler le logiciel sous Cygwin avec G++ et MinGW, ainsi que sous GNU/Linux et MacOS.
Lorsque je veux, par exemple, ajouter/enlever/modifier un option de compilation, je ne passe pas par l'interface de Visual Studio, ni ne modifie le Makefile, mais modifie uniquement 'Project.xml', puis relance les scripts pour régénérer les différents fichiers.
J'envisage, dans un futur proche, d'offrir la possibilité d'utiliser Clang sous Windows pour compiler les logiciels que je développe. Et bien, pour cela, il suffira que je modifie les scripts et les fichiers XSL, sans toucher aux différents 'Project.xml', pour que les Makefile générés prennent automatiquement en charge Clang. Pas besoin de modifier manuellement tous les Makefile pour cela.
Je gère ainsi chacun de mes projets à partir d'un seul et unique fichier 'Project.xml', dont j'ai la totale maîtrise du contenu, puisque qu'il n'est destiné à être traité que par des outils que j'ai moi-même développé. Bien entendu, il a fallu développer ces différents scripts et fichiers XSL, ce qui m'a pris au final bien moins de temps que je ne le pensais, ayant l'habitude de travailler avec XML/XSLT, mais depuis que ces dernier sont écrits, je n'ai plus eu à modifier de Makefile ou équivalent, ni à me replonger dans la documentation de Visual Studio, ou de GNU make, ou d'un quelconque autre outil similaire…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Gestionnaire de projets
Posté par barmic . Évalué à 3.
Tu décris un cmake-like au final. Tu n'a pas trop de rupture de compatibilité avec les formats de fichiers projet de VS et C::B ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de projets
Posté par Claude SIMON (site web personnel) . Évalué à 2.
D'après ce que j'en sais, cmake est similaire, dans son usage, à make, donc utilisé pour la compilation. Or, je ne lance pas mes scripts pour compiler le logiciel, mais pour générer les fichiers permettant cette compilation. La compilation proprement dite se fait à l'aide d'outils traditionnels (Visual Studio, make…). Donc, je ne pense pas que l'on puisse qualifier mes scripts de 'cmake-like'. Ils seraient plutôt, toutes proportions gardées, 'automake-like'.
Concernant Visual Studio, la dernière version est capable d'utiliser tel quel ou de convertir les fichiers issus de certaines précédentes versions. Cependant, j'ai modifié mes scripts lorsque j'ai changé de version, et ce ne devait pas être bien compliqué, car la seule chose dont je me souvienne, c'est d'avoir modifié le contenu de l'attribut qui semble correspondre à la version de Visual Studio. En tout cas, après modification de la valeur ce cet attribut ('ToolsVersion'), Visual Studio acceptait le fichier généré par mes scripts tel quel, sans demande de conversion.
Je n'ai jamais utilisé C::B…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Gestionnaire de projets
Posté par barmic . Évalué à 3.
Non justement cmake est un descripteur de projet qui ne sais pas compiler lui même, il sait générer des fichiers/script de build dans différents format.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de projets
Posté par Claude SIMON (site web personnel) . Évalué à 1.
En fait, j'avais regardé http://fr.wikipedia.org/wiki/CMake et m'était arrêté à : [CMake] est comparable au programme Make… (et cela correspondait à ce que je croyais savoir de CMake). Il est vrai que la description qui en est faite dans la suite de l'article présente de fortes similarités avec ce que réalisent mes scripts.
Ceci dit, l'avantage de ma démarche, c'est que je parvenais au résultat désiré juste en utilisant des outils qui n'étaient très familiers, et un fichier dont j'avais la maîtrise totale du contenu (modulo la structure due à l'utilisation de XML) et de sa signification. Mais ce qui est un avantage pour moi, parce que j'ai développé ces scripts, n'en serait pas un pour une tierce personne…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Gestionnaire de projets
Posté par barmic . Évalué à 3.
Je ne remet pas du tout en cause ton approche, c'est juste une manière de décrire (je me suis bien plus amusé sur certains doom-like que sur doom :) ).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de projets
Posté par freem . Évalué à 3.
Ce n'est pas parce que c'est un *-like, que c'est moins bien ou pas pertinent. Au contraire, surtout que toi, tu utilises une approche radicalement différente (xml au lieu de langage de script).
Je ne sais pas si tu publies tes scripts, mais je pense qu'ici plusieurs seraient intéressés, à lire les différentes interventions.
[^] # Re: Gestionnaire de projets
Posté par rewind (Mastodon) . Évalué à 3.
Tu as un exemple de projet.xml et les feuilles XSLT sur un dépôt quelque part ?
[^] # Re: Gestionnaire de projets
Posté par Claude SIMON (site web personnel) . Évalué à 1.
On peut trouver un exemple de 'Project.xml' à cette adresse : http://hg.savannah.gnu.org/hgweb/epeios/file/tip/tools/expp/CLI. Le Makefile situé à la même adresse a d'ailleurs été généré à partir de ce 'Project.xml'. On peut trouver d'autres 'Project.xml', et les Makefile correspondants, disséminés un peu partout dans ce même dépôt.
Les XSL ne sont par contre pas hébergés sur un dépôt.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Gestionnaire de projets
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Que proposes-tu? Parce que un Makefile et des scripts, c'est pas spécialement plus lisible et modifiable par un humain…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de projets
Posté par freem . É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: Gestionnaire de projets
Posté par flan (site web personnel) . Évalué à 3.
Pour moi, un bon fichier de configuration doit également être facilement modifiable de façon automatique, histoire d'être utilisable avec les outils classiques de gestion de conf'.
[^] # Re: Gestionnaire de projets
Posté par freem . Évalué à 2.
Ce n'est pas faux. Du coup, tu utilises quels outils classiques pour modifier de la conf xml/json? Parce que sed, grep, cut & co, ça me paraît difficilement adapté?
[^] # Re: Gestionnaire de projets
Posté par flan (site web personnel) . Évalué à 2.
Je ne suis pas admin sys, donc je fais assez peu de gestion de conf' (uniquement à la maison, avec Salt Stack). J'ai codé quelques petites extensions Python quand j'ai eu à le faire (assez rarement).
Accessoirement, j'ai un peu participé à la lib plistlib Python (elle ne savait pas travailler avec la représentation binaire du plist, uniquement avec la représentation XML).
Malheureusement, sed/cut/grep et Cie sont en effet assez peu adaptés à la manipulation des fichiers de conf (même textuels), c'est le bon plan pour ajouter des bugs discrètement ($ dans les mots de passe, option répartie sur plusieurs lignes, etc.).
[^] # Re: Gestionnaire de projets
Posté par freem . Évalué à 2.
Je suis aussi loin d'être admin, mais j'essaie de me mettre aux scripts shell, parce que c'est vraiment puissant, même à mon très faible niveau.
Par exemple, quand on doit se taper des comparaisons de fichiers de log qui peuvent différer d'un serveur à un autre, ou d'une date à une autre, pour trouver des infos supplémentaires au sujet d'un bug qu'il faut corriger.
Ou quand on est dans une petite boîte et qu'il faut modifier une entrée SQL dans 5 bases de données, répliquées sur un autre serveur ( ce qui fait donc 10 fois la même manipulation à faire, à la main… c'est ce que mes collègues faisaient, c'est ce que je refuse de faire. ).
Pour ces situations, écrire un programme complet serait un peu overkill, quand on peut coder ça en 10-20 lignes de shell.
En fait, dans ma boîte je fait un peu de tout, sûrement pas du grand art, mais bon, faut bien que quelqu'un le fasse, et j'avoue que ça ne me déplaît pas. Tant qu'on me demandera pas de faire ce genre de trucs sur des serveurs windows du moins :)
Si, ils sont très efficaces quand il s'agit de gérer des fichiers de type clé=valeur, genre INI ou… en fait la plupart de ce que je trouve dans mes /etc.
[^] # Re: Gestionnaire de projets
Posté par barmic . Évalué à 4.
Pour json, je ne sais pas.
Pour xml, tu as les commandes xpath et xfind en ligne de commande.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de projets
Posté par freem . Évalué à 2.
Je trouve bien xpath, mais pas moyen de mettre la main sur un man de xfind. Tu aurais une URI?
[^] # Re: Gestionnaire de projets
Posté par barmic . Évalué à 3.
Le site officiel : http://uucode.com/texts/xfind/index.html
Mais ce ne sont que des exemples tu as aussi xqilla pour tout ce qui est xpath et xquery (plus puissant) et qui est souvent packagé.
Tout ça pour dire que manipuler du XML ça se fait largement plus facilement (et de manière plus fiable)que de manipuler le format de CMake et surtout pour freem qui pense que le xml oblige à passer par l'outil dédié :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# C'est plus de boulot, mais ça vaut le coup
Posté par small_duck (site web personnel) . Évalué à 8.
Salut!
J'arrive un peu après la bataille, mais voila néanmoins mon avis.
Tout d'abord, ayant récemment, et à mon corps défendant, fait pas mal de Java, j'ai pu apprécier l'intégration du langage avec ses outils, la simplicité du build, et la gestion de dépendances façon Maven ou Ivy. Je n'ai pas pu retrouver une intégration aussi bonne avec le C++, je comprends donc ta douleur.
Je suis passé par de nombreux IDE, mais je n'ai jamais rien trouvé qui me satisfasse complètement. CodeBlocks était probablement un des meilleurs. J'ai entendu beaucoup de bien de QCreator. Mais la solution qui a fonctionné pour moi, c'est ce bon vieux Emacs. En utilisant le modes compilation, qui permettent d'aller à l'erreur via un clic ou via une touche du clavier, et le mode gdb, qui permet, via gdb-many-windows, d'obtenir un très bon environnement de debug, l'on se retrouve avec une solution très intégrée et productive. Pub inside, je détaille mon utilisation d'Emacs dans ma série Coder efficacement avec Emacs (les posts les plus anciens ne sont pas correctement taggés, mais ils ne sont pas difficiles à trouver).
Pour la solution de build, il n'existe pas de remède miracle. Ton choix semble judicieux, cmake est très utilisé et devient de plus en plus une référence, mais l'outil gagne à être un petit peu étudié, l'utilisation des modules simplifie énormément la vie.
Le temps de compilation est toujours aussi problématique. J'ai utilisé dans le passé les en-têtes pré-compilées, mais j'en suis revenu, ayant trouvé qu'un peu d'attention dans les #include et qu'une utilisation massive de la forward declaration me donnait de bien meilleurs résultats. Surtout, utiliser Boost le plus parcimonieusement possible, en particulier dans les fichiers d'en-tête, et utiliser plutôt les primitives de la bibliothèque standard, laquelle s'est bien étoffée avec une panoplie de pointeurs intelligents, de primitives pour gérer le parallélisme, la mesure du temps ou même les expressions régulières.
Au passage le linker "gold" (Goooooold linker!!!!) améliore fortement les performances à l'édition de liens, ce qui est toujours ça de pris.
Ccache et distcc aident également beaucoup, mais c'est encore du boulot supplémentaire de mettre tout cela en place.
Je ne peux que t'encourager à investir un peu de temps pour te construire un environnement aux petits oignons, et à tirer meilleur parti du langage. D'excellentes bibliothèques sont disponibles pour programmer des jeux. Nommons en particulier SFML, le couteau suisse de l'interaction avec le matériel (vidéo, audio, contrôleurs), et OpenSceneGraph, qui est un graphe de scène basé sur OpenGL, et dont les capacités sont remarquables.
Bon courage!
[^] # Re: C'est plus de boulot, mais ça vaut le coup
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
On a pas mal débattu de la SFML ici et sur #jeuxlibres. Rewind l'utilise pour Akagoria et en est très content. Je suis plus sceptique et je pense que je vais partir sur cette bonne vieille SDL. En fait mon point de vue n'a pas beaucoup changé depuis ce journal :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: C'est plus de boulot, mais ça vaut le coup
Posté par rewind (Mastodon) . Évalué à 10.
En fait, il faut qu'on se cotise pour offrir à devnewton un ordinateur qui gère un truc aussi moderne qu'OpenGl ES 2 pour qu'il arrête de vouloir des bibliothèques qui utilisent encore OpenGL 1 parce que ses cartes graphiques ne gèrent que ça.
# Retourne à la raison!
Posté par Michaël (site web personnel) . Évalué à 1.
C++ a d'immenses problèmes, qui sont essentiellement liés à la présence dans le langage de technologies ou méthodes concurrentes et à tous les outils de code obfuscation dont il dispose.
Le préprocesseur n'a pas été abandonné au profit des templates et const int ce qui rend quasiment impossible l'analyse statique du code et beaucoup de raisonnements élémentaires sur le code source. Résultat: la compilation est très lente dès qu'on sort du cadre d'un projet trivial.
Les références font essentiellement double emploi avec les pointeurs, elles enrichissent le lexique d'un langage déjà touffu pour une sémantique (passage de pointeur sans transfert de propriété) essentiellement dupliquée par les smart pointers.
Il est très difficile de tirer correctement parti des champs constants. Bien utiliser l'attribut
constnécessite de préparer une vraie stratégie de développement.Le langage est tellement compliqué qu'il n'y a pas foule de compilateurs implémentant complètement le langage — la dernière fois que j'ai fait des recherches là-dessus il y en avait exactement un. Et puis les implémentations sont boguées! J'ai appris C++ et exactement 3 mois plus tard j'ai découvert un bogue dans le compilateur!
J'abrège un peu parce que c'est Samedi: C++ est utilisable si
Dans tous les autres cas, s'abstenir.
[^] # Re: Retourne à la raison!
Posté par Gof (site web personnel) . Évalué à 7.
Comme le disait Bjarne Stroustrup, le créateur de C++: « Il y a deux sorte de languages de programmation: ceux dont on se plaint, et ceux que personne n'utilise »
Toujours d'après Stroustrup, L'une des caractéristique qui contribue au succès de C++ est la compatibilité avec le C. Le fait que du code écrit il y a plusieurs décénies peux être utiliser avec du C++ moderne.
Il est tout à fait possible d'utiliser le C++ sans utiliser les fonctionalités rétrogrades.
Et le C++ moderne n'est pas si horrible.
Les languages « meilleurs » qui ont retiré la compatibilité n'ont pas eu beaucoup de succès. (Exemple: D.) (Et je suis curieux de voir ce que va devenir Rust.)
[^] # Re: Retourne à la raison!
Posté par rewind (Mastodon) . Évalué à 4.
Les compilateurs modernes (dont Clang) savent remonter une erreur jusqu'à l'instruction préprocesseur fautive.
Les références ne font pas double emploi, au contraire, et elles n'ont pas du tout la sémantique que tu veux leur donner. Et les smart pointers, c'est encore autre chose.
C'est une blague ? Il n'y a pas besoin de «stratégie», juste d'un peu de bon sens et normalement, tout se passe bien et les
constsont au bons endroits.C'est là qu'on voit que tu n'as sans doute pas pratiqué C++ depuis un moment. Certes pour C++98, seul Comeau C++ implémentait la norme complète et en particulier le mot-clef
export. Mais celui-ci a été enlevé de C++11 et depuis, Clang et GCC implémente la norme complètement. Après, si tu connais des compilateurs (peu importe le langage) sans bug, dis le, ça va intéresser plein de gens.[^] # Re: Retourne à la raison!
Posté par Michaël (site web personnel) . Évalué à 2.
Oui c'est exactement comme ça que ça marche. Quand on parle de blague! Au passage, le bon sens c'est la dialectique typique des gens qui n'ont pas d'argument, comme nous l'a rappelé à souhait un de nos précédents gouvernements, c'est donc une expression à éviter invariablement si on veut être pris au sérieux.
Exemple au hasard: si je décide de mettre une référence constante dans une object, et bien je ne peux plus utiliser le classique
clone & swappour implémenter l'assignement, ce qui oblige à dupliquer une bonne partie du clonage et de l'assignement. Le bon sens ici ne suffit pas.Autre exemple: dans la vraie vie on travaille avec des APIs toutes pourries qui ne connaissent pas
constet penser une interface vaguement propre ne se fait pas sur un coin de table de bar avec un peu de bon sens.Pour avoir travaillé sur une importante base de code C++ développée avec “le bon sens” j'ai une expérience qui dit que ça se passe plutôt mal.
Si tu as des choses utiles à dire — du type, une affirmation positive — ne t'en prive pas, on est toujours content d'apprendre quelque chose.
Effectivement. Mais il ne faut pas oublier que dans la vie de beaucoup de développeurs contemporains C++11 c'est de la science-fiction, ne parlons pas de C++14.
Tu t'appuies tes arguments sur le bon sens et ensuite tu exagères les propos de tes contradicteurs pour les contredire par le ridicule. Merci pour tes contributions inestimables à la qualité du débat sur LinuxFR.
[^] # Re: Retourne à la raison!
Posté par Pazns . Évalué à 5.
Référence ou pointeur ?
Un pointeur indique un emplacement mémoire. Il peut être nul (
nullptr). Une référence indique un objet. Elle ne peut pas être nulle.Certes, on peut maladroitement produire des références à partir de pointeurs invalides ou nuls, donc dans le fond ce n'est qu'un déguisement.
Néanmoins l'information est bien là. C'est un peu comme un argument de fonction qui serait un
uintet pas unint.De plus, cela permet techniquement un maniement un peu plus fin sur les
lvalue,rvalue,prvaluedu programme, comme avec l'opérateur && (qui n'est pas une référence de référence : quel agréable choix de symbole…) .Un pointeur est un outil assez bourrin. Efficace mais peut-être trop direct ?
Les smart pointers ont un objectif assez différent, plutôt orienté gestion mémoire partagée. Je ne suis pas convaincu qu'on puisse les faire rentrer dans une question autour de la pertinence des références.
Liberté
Dans le fond, ce que tu reproches à C++, c'est de ne pas assez restreindre le développeur, c'est ça ?
Même si des aspects de C++ comme les exceptions ou les templates sont objectivement maladroits, dans le fond, est-ce vraiment grave ?
On peut toujours s'en passer et coder uniquement avec des codes de retour d'erreur et des pointeurs, s'en tenir à du "C Objet".
Parce qu'après tout une exception sécurisée est assez peu rentable.
Et comme on aura toujours moyen de bousiller un programme malgré des références, autant utiliser des pointeurs pour garder un programme simple. Et ce serait pertinent.
Un développeur maladroit fera toujours de la merde, même avec un langage prison.
Y aura toujours moyen de corrompre un jeu de données, outrepasser la limite d'un conteneur, faire une division par zéro… Peu importe le langage !
C++ est une drôle de connerie inutilement compliquée, mais il ne faut pas non plus lui mettre sur le dos l'éventuelle incompétence des programmeurs.
[^] # Re: Retourne à la raison!
Posté par Michaël (site web personnel) . Évalué à 3.
Mais ce n'est pas du tout la différence entre un pointeur et une référence — en dépit de la litanie lénifiante qu'on peut lire à beaucoup d'endroits. Comme tu le dis plus bas on peut maladroitement — mais de façon complètement anodine — passer un référence nulle. En réalité la seule véritable différence de fonctionnalité entre un pointeur et une référence c'est que le pointeur permet de déconstruire l'objet et pas la référence.
Autrement dit les références implémentent les pointeurs sans transfert de propriété — le propriétaire est responsable de la libération de mémoire. Et les rapprocher d'un outil de gestion comme les smart pointers n'a rien de farfelu.
Pas du tout. Ce que je reproche à C++ est d'être un langage complètement byzantin, absolument illisible, et où il y a 36 réponses à chaque problème d'organisation qu'on se pose — et aucun des choix de réponse qu'on fait n'est anodin et les interdépendances et incompatibilités entre ces choix n'apparaissent souvent que lorsqu'on a écrit une quantité substantielle de code.
Pour en revenir à la discussion, mon message à DevNewton est que les problèmes d'ingénierie logicielle posés par C++ sont plus difficiles que dans beaucoup d'autres langages. Une façon de commencer à les résoudre est de faire, comme tu les suggères, du C with classes mais ce n'est pas forcément la plus intéressante.
[^] # Re: Retourne à la raison!
Posté par Pazns . Évalué à 0. Dernière modification le 27 septembre 2014 à 23:42.
Byzanterie
Complètement d'accord.
De toute évidence le C++ n'est pas une réussite, et ses nombreux besoins de rétrocompatibilités l'enchaînent encore plus. Trop tard pour lui, dommage.
Mais est-il vraiment à jeter pour autant ? N'est-ce pas là tout simplement le prix à payer pour avoir à la fois puissance et abstraction ?
Références et pointeurs
Les pointeurs purs non plus n'ont pas d'information de propriétés, non ?
Ce sont de simples adresses de mémoire.
Euh, j'ai un doute là, du coup. La condition pour faire un
deletepropre est d'avoir allouer sur le tas avec unnewla mémoire pointée par le pointeur donné en argument dedelete.On peut parfaitement
deletel'adresse d'une référence crée depuis un objet allouée sur le tas si ça nous amuse. Puisqu'au fond c'est un pointeur pur déguisé.Ou bien peut-être que mon GCC 4.8 (en c++11) est permissif sur ce point ? J'avoue ne pas avoir lu la spéc' officielle. Trop chiant.
D'ailleurs, j'ai même le droit de
deleteun objet alloué sur la pile.[^] # Re: Retourne à la raison!
Posté par Michaël (site web personnel) . Évalué à 3.
Oui, non. C'est mon avis, et devnewton s'intéresse à l'avis des gens… ☺
Quand on passe une référence, inutile de préciser (dans la documentation, p.ex.) qu'on reste propriétaire de l'objet. C'est ce que je veux dire. Les pointeurs eux, ne disent rien sur la propriété mais je parle des références.
On peut faire
deletesur un pointeur et pas sur une référence: c'est une fonctionnalité du pointeur qui n'est pas autorisée par une référence. Et si on prend un pointeur sur l'objet référencé par une référence, et bien on travaille avec un pointeur et plus avec une référence.Ça, certainement pas, ça sent l'UB à plein nez. À moins que je n'aie pas compris ce à quoi tu fais allusion.
[^] # Re: Retourne à la raison!
Posté par Pazns . Évalué à 0.
Hm… tu veux parler du fait que, logiquement parlant, les pointeurs signalent de façon claire qu'on travaille sur un objet vivant dans une portée distante ?
Le flou peut exister dans le cas des références, pour un œil non-attentif (l'opérateur
.au lieu de->). Avec un pointeur c'est plus évident de rester attentif sur les effets de bords. Surtout avecunique_ptr/std::movej'imagine.Ah bah, oui, puisque la référence est un objet ! En fait je ne comprends pas vraiment ce qui te chagrine avec les références sur ce plan-là. Ce n'est qu'une manière de reproduire un objet sans copie, ni affectation, ni déplacement.
Personnellement, je vois ça comme quelque chose de cosmétique, de confort. Ça revient au même qu'un pointeur déréférencé, un peu enjolivé.
Bon, j'avoue que je ne sais pas encore sur quoi me fixer, 100% pointeur ou mixte pointeurs références. Après tout les références n'apportent rien qui n'existe pas déjà, dans l'absolu.
Probablement. Mais bon, de toute manière, un pointeur invalide aussi respire l'UB à plein poumon, et on a assez vite plein de pointeurs invalides partout.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Retourne à la raison!
Posté par Sufflope (site web personnel) . Évalué à 3.
Ouais euh, quand tu vois qu'il y a régulièrement des buffer overflow parce qu'un dév. C (c'est pas la master race tellement douée qu'elle peut tout gérer à la main peu importe la complexité du projet ?) a oublié de vérifier la taille de sa chaîne, et même dans des programmes "éprouvés"… et je ne parlerai pas des Bobby Tables parce qu'au fond même un développeur PHP a droit à un respect de sa personne humaine…
J'accepterai les critiques sur ces fonctionnalités quand les bug ridicules sus-nommés n'arriveront plus jamais, et en attendant je suis bien content d'être un programmeur qui utilise un ORM et un langage à ramasse-miettes.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Retourne à la raison!
Posté par Gof (site web personnel) . Évalué à 2.
Même si les en têtes était pré compilé dans un fichier
.class, une modification annodine de l'en-tête changerait aussi le fichier .class (ne fut-ce que le modtime) et forcerait aussi la recompilation de tous les fichier qui référencent directement ou indirectement ce fichier.Oh! Et les en-tête précompilée ça existe déjà. Ça s'appelle
.gchavec GCC et.pchavec clang. Et ça améliore effectivenement le temps de compilation car le compilateur ne dois pas recompiler le header pour chaque fichier qui le contiens.Les entête pré-compilés ont leur propre problèmes, mais marchent assez bien en pratique.
Mais l'avenir nous offre une solution presque parfaite: les Modules. Déjà partiellement implémentés dans clang.
http://clang.llvm.org/docs/Modules.html
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Retourne à la raison!
Posté par barmic . Évalué à 4.
Faut savoir qu'est ce que tu compare avec quoi. Bien des développeurs ne sont pas très grands connaisseurs des SGBD et ne font pas forcément des requêtes bien optimisées. À cela il faut ajouter le coup de la gestion de la donnée dans ton programme (la sérialisation et déserialisation dans une structure/un objet).
La question qui est intéressante c'est : est-ce que je saurais faire mieux que l'ORM ?
C'est un peu comme de dire qu'il faut acheter un reflex parce que le RAW c'est génial. Oui c'est génial quand tu sais correctement développer du RAW et que tu saura faire mieux que ce que fais l'appareil. Dans la pratique ce n'est pas le cas très souvent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# CMake ?
Posté par Plume . Évalué à 6.
J'aimerai bien mieux comprendre comment utiliser CMake. Si quelqu'un à une bonne source, je serais bien intéressé.
# Revenons à l'essentiel
Posté par Julien Jorge (site web personnel) . Évalué à 4.
Je vois bien ce que tu fais devnewton ; sous couvert de trolls tu veux surtout nous montrer ton dernier jeu ;) Et bien j'ai testé et je dois dire que hormis une petit problème de recherche d'assets vite corrigé, le jeu est… waw ! C'est complètement différent de tout ce qu'on a pu voir jusqu'à maintenant. Bien que légèrement répétitif au début, on se prend vite au jeu et on se laisse entraîner par le rythme. C'est simple, sobre et efficace. À quand une version Apple Watch ?
[^] # Re: Revenons à l'essentiel
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Disons que le gameplay est très casual pour l'instant!
J'ai voulu me faire un "hello devnewton" pour tester la SDL2. Je vais sans doute faire un autre essai avec http://www.polycode.org/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.