Personnellement, 15 min pour 450k, ca me choque pas.
Je dois vivre sur une autre planète mais je trouve que c'est de la pure folie. Handmade Hero c'est 40k lignes, ça compile en 5 secondes en release. Il y a aussi un projet de langage où l'auteur du langage prétend que c'est du "programming done right" https://odin-lang.org/
(par contre je comprend pas pourquoi tout le monde veut un langage où le type est à droite de la variable, c'est moche et ça rajoute un ":" pour rien)
Donc on se demande tous à quoi ressemble un compilateur écrit par un mec qui prétend programmer correctement. Et bien c'est très simple, j'ai téléchargé le zip, j'ai tapé "build" et c'est tout, aucune erreur, et ça compile en 18 sec en release, et il y a 98k lignes.
Quand j'avais compilé le compilateur de Lynix, ça s'est pas passé pareil, il a fallu se battre avec xmake et visual studio car il y avait des erreurs de partout et ça a mis 1 min 6 sec à compiler, après je sais pas combien il y a de lignes en tout avec les dépendances, mais dans src il y a 36k lignes dont 10k lignes de "spirv data" (je sais pas ce que c'est mais c'est pas du "code" c'est un tableau de 9500 lignes et quelques fonctions, donc pas très long à compiler)
Du coup pourquoi vous passez tout ce temps avec des outils de build etc au lieu de juste faire un truc tout simple sans erreurs et qui compile vite ?
Oui tu as raison Jade, on fait exprès de complexifier nos programmes de sorte à ce qu'ils mettent longtemps à compiler, ça nous permet de prendre des pauses café plus longues quand on compile.
Tu as parfaitement raison de comparer l'incomparable, de croire tous ceux qui disent bien faire les choses sur parole juste parce que tu en as envie, en plus les gens qui sur-estiment leurs capacités / produits c'est tellement rare, aucune chance que ça soit ça.
Tu as parfaitement raison de croire qu'il est possible de simplement ne pas faire d'erreur et d'avoir quelque chose qui compile vite, que c'est une question de volonté, qu'en fait on choisit de se complexifier la vie exprès parce qu'en fait sinon notre vie est trop simple, il nous faut quelque chose qui prenne du temps.
Tu as parfaitement raison de remettre en question des dizaines d'années d'expériences de C++ (en cumulant tous ceux qui t'ont un jour répondu on y arrive vite) sur seule base de ta compréhension et de ta naïveté incroyable.
Tu as parfaitement raison de croire qu'en fait tous autant que nous sommes nous ignorons juste la bonne façon de faire, c'est pas du tout une affaire de choix et de compromis, c'est juste qu'on est trop bête.
Au passage, pour compiler NZSL il suffit d'une seule commande, "xmake" (et d'entrer "y" pour installer les dépendances quand il le demande), alors ok il faut installer xmake avant (mais ça marche sur toute les plateformes, ça gère les dépendances, etc.)
NZSL fait 36k lignes de code (et compile en 23s sur ma machine sans unity build, 17 avec), le temps de compilation est principalement affecté par la forte utilisation de templates pour gérer la propagation de constantes, mais t'inquiète j'ai choisi de faire en sorte que ça soit lent à compiler parce que je trouvais ça marrant, c'est pas du tout un compromis accepté. Puis en plus le temps de compilation d'une dépendance que je compile une fois par mois c'est super important, chaque seconde compte.
Nazara fait 150k lignes de code (et compile en 55s sans unity build, 30s avec), puis en plus c'est super important le temps de compilation du moteur entier parce que je programme pas du tout de façon itérative dessus, à compiler le moins de .cpp possible, à chaque fois je recompile tout, on sait jamais. Puis je formate mon pc toutes les cinq compilations pour vraiment être sûr, ben oui.
J'ai hâte que tu nous donnes ton prochain point de vue absolument objectif et pas du tout poussé par ton manque d'expérience pro et une certaine naïveté.
(ce message contient peut-être un peu de second degré).
Oui tu as raison Jade, on fait exprès de complexifier nos programmes de sorte à ce qu'ils mettent longtemps à compiler, ça nous permet de prendre des pauses café plus longues quand on compile.
Ah voilà je savais bien qu'il y avait une raison comme ça, en fait c'est comme le fait que le C++ commitee fait exprès qu'il y ait plein de choses à taper pour donner l'impression qu'on est en train de travailler https://guide.handmadehero.org/code/day535/#1501
Lynix a écrit:
Au passage, pour compiler NZSL il suffit d'une seule commande, "xmake" (et d'entrer "y" pour installer les dépendances quand il le demande)
Oui dans un monde merveilleux ça devrait marcher comme ça, mais alors pourquoi j'ai du réinstaller 2 fois visual studio pour que xmake accepte de compiler avec ? Alors qu'avec le "build" de l'autre mec comme par hasard ça a fonctionné du premier coup sans cracher la moindre erreur
Moi j'ai peut être pas d'xp mais les trucs que je dit c'est des gens expérimentés qui l'ont dit
Lynix a écrit:
NZSL fait 36k lignes de code (et compile en 23s sur ma machine sans unity build, 17 avec), le temps de compilation est principalement affecté par la forte utilisation de templates pour gérer la propagation de constantes
Mais wtf comment c'est possible de compiler aussi vite, ça met plus d'une minute chez moi (je parle juste de la compilation avec VS, pas de toute l'installation des dépendances), vous avez compilé en release ? Comment vous faites pour avoir des machines si puissantes, vous avez gagné au loto ou quoi ? Si vous compiler nzsl aussi vite je me demande en combien de temps vous compilez le truc de l'autre mec (pour compiler en release il faut taper "build 1" et pas seulement "build")
Après je pense que c'est la unordered map de la reine des neiges qui met 3 heures à compiler
Lynix a écrit:
puis en plus c'est super important le temps de compilation du moteur entier parce que je programme pas du tout de façon itérative dessus, à compiler le moins de .cpp possible, à chaque fois je recompile tout, on sait jamais.
Cette technique de compiler chaque cpp indépendamment elle rend la compilation complète excessivement lente, alors ok si vous avez juste un fichier isolé à recompiler vous allez mettre quelques secondes, mais si c'était pensé en unity build dès le départ, les quelques secondes suffiraient à compiler TOUT le programme, et si vous modifiez un .hpp alors là ça va tout d'un coup mettre un temps énorme. Du coup je préfère mettre peu de temps à chaque fois plutôt que un temps énorme pour le truc complet et les .hpp et peu de temps pour les .cpp. Et je parle pas des problèmes où le programme bug car ça a pas bien recompilé un des fichiers (oui j'en parle vraiment pas car je sais pas ce que c'est, j'en ai juste entendu parler, que des fois il faut recompiler tout le truc)
michelbillaud a écrit:
Si on peut écrire une ligne sans erreur, pourquoi pas 2 pourquoi pas 10 pourquoi pas 3 millions ?
Oui aha je suis bien d'accord mais c'est pas ce que j'ai voulu dire, ce que j'ai voulu dire c'est lors de la compilation, le truc a juste compilé et c'est tout, ça m'a pas sorti des erreurs bizarres avec telle dépendance qui foire ou des conneries comme ça
- Edité par JadeSalina 18 septembre 2022 à 15:02:03
Oui dans un monde merveilleux ça devrait marcher comme ça, mais alors pourquoi j'ai du réinstaller 2 fois visual studio pour que xmake accepte de compiler avec ? Alors qu'avec le "build" de l'autre mec comme par hasard ça a fonctionné du premier coup sans cracher la moindre erreur
Parce que tu t'es vautrée dans ton installation de VS, globalement (tu peux avoir le compilateur sans avoir tout ce qu'il faut à côté, ou l'inverse)
J'utilise xmake avec des étudiants, ceux qui ont ce problème-là ont souvent fait un peu n'imp avec VS. Pour la plupart ça se passe très bien.
JadeSalina a écrit:
Moi j'ai peut être pas d'xp mais les trucs que je dit c'est des gens expérimentés qui l'ont dit
Non, c'est ce que tu comprends de ce que des gens plus expérimentés disent (c'est très différent), mais sans prendre en compte qu'ils évoluent dans des contextes spécifiques et ont des raisons de faire des choix spécifiques que nous ne partageons pas forcément.
Plus bien sûr il y a ceux qui disent être expérimentés mais font en fait n'importe quoi.
JadeSalina a écrit:
Mais wtf comment c'est possible de compiler aussi vite, ça met plus d'une minute chez moi (je parle juste de la compilation avec VS, pas de toute l'installation des dépendances), vous avez compilé en release ? Comment vous faites pour avoir des machines si puissantes, vous avez gagné au loto ou quoi ? Si vous compiler nzsl aussi vite je me demande en combien de temps vous compilez le truc de l'autre mec (pour compiler en release il faut taper "build 1" et pas seulement "build")
Oui je parle bien d'une compilation en release.
Mon processeur est un R9 5950X, particulièrement utile quand on compile du C++. Comment j'ai fait pour l'avoir ? Je l'ai acheté. J'ai jugé que c'était pas un achat perdu étant donné que mon ordinateur personnel est mon outil de travail que j'utilise le plus souvent (même cette semaine où j'étais dans les bureaux de Cyanide, mon employeur, je contrôlais mon ordinateur à distance, j'appelle ça l'anti-télétravail ).
JadeSalina a écrit:
Cette technique de compiler chaque cpp indépendamment elle rend la compilation complète excessivement lente, alors ok si vous avez juste un fichier isolé à recompiler vous allez mettre quelques secondes, mais si c'était pensé en unity build dès le départ, les quelques secondes suffiraient à compiler TOUT le programme, et si vous modifiez un .hpp alors là ça va tout d'un coup mettre un temps énorme. Du coup je préfère mettre peu de temps à chaque fois plutôt que un temps énorme pour le truc complet et les .hpp et peu de temps pour les .cpp. Et je parle pas des problèmes où le programme bug car ça a pas bien recompilé un des fichiers (oui j'en parle vraiment pas car je sais pas ce que c'est, j'en ai juste entendu parler, que des fois il faut recompiler tout le truc)
L'unity build c'est de la merde pour l'incrémental, je le vois tous les jours au boulot où on a l'unity build d'actif et où changer un .cpp en compile en fait une douzaine (pas le plus simple à désactiver dans notre contexte mais on prévoit de le faire).
L'intérêt de l'unity build c'est quand tu dois compiler le projet entier en partant de zéro (CI par exemple), pour de l'incrémental c'est souvent de la merde.
Et c'est pas une question de bien penser son projet au départ, c'est une question de compromis, tu te focalises sur un seul point qui n'est pas le plus important, nous on fait des choix en prenant plein de choses en compte, dont le temps de compilation qu'on sacrifie parfois pour certains avantages.
Alors avant il fallait pas codé du C++ moderne pour éviter les malloc à tout va. Maintenant c'est pour éviter d'avoir une compilation trop longue, y'a du progrès à ce que je vois x)
markand a écrit:
Les compilateurs sont plus lent. Moi je trouve ça indécent, j'ai beau avoir un MacBook et un ThinkPad surpuissants, ils compilent à peine plus vite que mon vieux HP ProBook (le HP ayant des vieilles versions de gcc/clang et moins de performance).
Peut être a cause des optimisations . Plus le temps passe, plus les optimisations sont pointus (de nos jours GCC utilise quasiment systématique des instructions SIMD et vectorise le code) ,et j'imagine que ça demande pas mal d'analyse pour réussir à faire ça. Et sûrement plein d'autre optimisation rajouté depuis.
- Edité par HelbaSama 18 septembre 2022 à 21:48:55
@Jade: il faudrait vraiment que tu arrives à comprendre qu'un projet n'est pas l'autre. Il se peut que, pour le projet A, compiler N lignes de code en X minutes soit jugé comme "beaucoup trop lent", alors que pour le projet B qui contient exactement le même nombre de ligne, le même temps de compilation soit jugé comme "particulièrement rapide".
De plus, il faut que tu te mette dans la tête qu'il y a deux possibilités pour compiler un projet de N lignes de code:
Soit on fait un "fresh build" en partant dans un dossier totalement vide, qui ne contient absolument aucun résidu des compilations précédentes, soit on fait une compilation "de mise à jour", par laquelle on ne recompile que les éléments qui ont été modifiés depuis la dernière compilation (réussie).
Dans le premier cas, il faut recompiler l'intégralité du projet, ce qui va ** forcément ** prendre plus de temps que le deuxième cas, vu qu'il n'y aura que ... "quelques fichiers par-ci par là" à recompiler.
Tu n' épatera personne en venant dire qu'il suffit de 5 secondes pour compiler un code de 45K lignes de codes en mode release, car, s'il n'y a qu'un seul fichier qui ait été modifié depuis la dernière compilation, nous pourrions au contraire te dire que c'est ... déjà beaucoup trop lent... ou pas.
Tu t'interroges sur la raison pour laquelle on utilise des outils de build? c'est bien simple: si on les utilise correctement -- ce qui implique sans doute effectivement qu'on les intègre correctement à notre environnement de développement -- ils vont nous faciliter énormément la vie.
Tant que tu as un projet "simple", avec peu ou pas de dépendances, tu peux effectivement t'amuser à écrire taper les instructions
# générer tous les fichier objets d'une seule fois
g++ -c *.cpp -I/chemin/vers/dossiers/contenant/les_entetes_utilisées
# générer le programme exécutable
g++ *.o -o nom_executable -L/chemin/vers/dossier/contenant/la_bibliotheque -lnom_de_la_bibliotheque
Et ca va marcher.
tu pourra sans doute même utiliser l'historique des commande pour ne pas avoir à réécrire ces deux instructions à chaque fois, et ce sera génial.
Le seul truc, c'est qu'un projet "un tantinet sérieux" (comprends: qui ne se limite pas à un but pédagogique) a de fortes chances de devenir beaucoup plus complexe que cela.
on va donc être confrontés à différents problèmes, parmi lesquels on peut citer les faits:
que cette manière de fonctionner correspond à un "fresh building" car tous les fichiers seront systématiquement recompilés
que tu risques à terme de vouloir "organiser" ton code source, en multipliant les dossiers qui le contiennent afin de regrouper les éléments "qui vont bien ensemble". Cela t'obligera à répéter la même commande encore et toujours, avec juste "quelques différences"
tu risques même à terme de vouloir créer une bibliothèque (statique ou dynamique) pour l'une des parties
tu voudra rajouter une politique de tests, et tu voudras automatiser ceux-ci
tu auras peut-être besoin de bibliothèques externes, ou peut-être te dira tu simplement que "telle bibliothèque externe permet d'éviter l'utilisation de telle partie de mon code". Comment faire pour permettre de choisir d'utiliser cette bibliothèque ou non? comment être sur que la bibliothèque en question est bien présente et que le projet sait y accéder?
tu voudras peut-être permettre la compilation de ton projet sur différents systèmes, et tu voudras d'autant plus t'assurer que les bibliothèques externes que tu utilise sont présentes dans la version adéquate
j'en passe, et sans doute de meilleures.
En un mot, tu finira tôt ou tard par vouloir automatiser la compilation de ton projet. Et tu voudras, autant que faire se peut, que cela ne te prenne pas trois heures (ni même seulement cinq minutes) à modifier une série de fichiers à gauche et à droite rien que pour pouvoir ajouter un nouveau fichier à ton projet.
C'est cela même que les outils de build, les CMake, XMake et autres systèmes te permettent: de décrire ton projet de manière suffisamment claire que pour pouvoir en automatiser la génération, et de manière suffisamment souple que pour pouvoir rajouter de nouveaux fichiers "sans te prendre la tête".
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Oui dans un monde merveilleux ça devrait marcher comme ça, mais alors pourquoi j'ai du réinstaller 2 fois visual studio pour que xmake accepte de compiler avec ? Alors qu'avec le "build" de l'autre mec comme par hasard ça a fonctionné du premier coup sans cracher la moindre erreur
Parce que tu t'es vautrée dans ton installation de VS, globalement (tu peux avoir le compilateur sans avoir tout ce qu'il faut à côté, ou l'inverse)
Oui c'est possible aha j'avais peut être pas cliqué sur les bons trucs à installer
Lynix a écrit:
(même cette semaine où j'étais dans les bureaux de Cyanide, mon employeur, je contrôlais mon ordinateur à distance, j'appelle ça l'anti-télétravail ).
Alors je connais pas forcément bien le monde du travail pro mais j'avoue que je vois pas trop l'intéret de se déplacer pour au final se retrouver sur son propre pc, d'ailleurs à quoi ça sert de se déplacer tout court vu qu'on peut tout faire de chez soi et se parler directement sur Teams ?
koala01 a écrit:
Dans le premier cas, il faut recompiler l'intégralité du projet, ce qui va ** forcément ** prendre plus de temps que le deuxième cas, vu qu'il n'y aura que ... "quelques fichiers par-ci par là" à recompiler.
Ça c'est pas si sûr car quand on compile indépendamment il faut invoquer le compilateur pour chaque fichier, et au final ça peut se retrouver plus long que de compiler beaucoup plus de code mais d'un coup, par exemple il est peut être plus rapide de compiler 10k lignes d'un coup plutôt que 1000 de ces lignes mais répartis dans 10 fichiers
koala01 a écrit:
tu auras peut-être besoin de bibliothèques externes, ou peut-être te dira tu simplement que "telle bibliothèque externe permet d'éviter l'utilisation de telle partie de mon code". Comment faire pour permettre de choisir d'utiliser cette bibliothèque ou non? comment être sur que la bibliothèque en question est bien présente et que le projet sait y accéder?
La solution est toute simple, il suffit que la librairie externe elle même suive les même principes de rester "simple" et du coup il suffira de mettre les quelques .h/.cpp dans notre projet et c'est bon. C'est ce que fait imgui https://github.com/ocornut/imgui il n'y a pas de système de build, du coup c'est très simple et rapide à utiliser dans notre projet. D'ailleurs si je ne m'abuse, je sort cette info du tréfond des ténèbres, je sais plus où j'ai vu ça ni quand donc c'est à prendre avec des pincettes mais il me semble que Lynix avait choisi un moteur physique pour Nazara notamment car il était facile à intégrer (je crois que c'était avant xmake), donc ça veut bien dire que c'est bien d'avoir un truc simple où on a pas besoin de se demander comment compiler le truc
gbdivers a écrit:
non, rien
Mais pourquoi vous enlevez tous vos messages avant que j'ai le temps de les lire aaaah je veux savoir
Alors je connais pas forcément bien le monde du travail pro mais j'avoue que je vois pas trop l'intéret de se déplacer pour au final se retrouver sur son propre pc, d'ailleurs à quoi ça sert de se déplacer tout court vu qu'on peut tout faire de chez soi et se parler directement sur Teams ?
Ben tout simplement parce que même si tu travaille "le plus souvent" directement de chez toi, il arrive que ton employeur demande à ce que tu sois physiquement présent dans les locaux pour une raison ou une autre, et qu'il soit plus facile pour toi de contrôler l'ordinateur que tu utilises généralement (celui qui se trouve chez toi) que de commencer à configurer l'ordinateur qui est mis à ta disposition dans les locaux afin de pouvoir continuer ton travail
Une des raisons bien simple pour laquelle cette approche peut s'avérer plus facile est "aussi idiote" que le fait qu'il faudrait récupérer l'ensemble de répertoire git du projet, ce qui, sur certains projet correspond à plusieurs Gb de données à récupérer.
JadeSalina a écrit:
Ça c'est pas si sûr car quand on compile indépendamment il faut invoquer le compilateur pour chaque fichier, et au final ça peut se retrouver plus long que de compiler beaucoup plus de code mais d'un coup, par exemple il est peut être plus rapide de compiler 10k lignes d'un coup plutôt que 1000 de ces lignes mais répartis dans 10 fichiers
Bien sur que cela te prendra de toutes évidence plus de temps si tu dois introduire dix commandes que si tu peux te contenter d'en écrire une seule pour obtenir le même résultat.
Mais ce n'est pas de cela qu'il est question. Ce dont il est question, c'est du temps mis par le processus de compilation de ton projet, à nombre d'introduction de ta part identique.
Si, après avoir modifié un fichier, tu n'as qu'un seul fichier qui sera recompilé, on peut effectivement s'attendre à ce que le temps nécessaire pour recompiler ce fichier soit inférieur à celui qui aurait été nécessaire pour compiler les 150 fichiers de ton projet, peu importe que ce soit fait en une, dix ou 150 commandes différentes, vu que le nombre d'instructions nécessaire pour compiler l'ensemble du projet sera toujours le même (sauf à avoir ajouter de nouveaux fichiers, bien entendu).
De même, il est "plus que probable" que la compilation d'un fichier contenant 10 000 lignes de code soit -- effectivement -- plus rapide que la compilation du même code réparti dans dix fichiers de 1000 lignes.
Seulement, dis toi bien que tu auras beaucoup plus facile à t'y retrouver dans dix fichiers composés de 1000 lignes de code que dans un seul fichier qui contiendrait les 10 000 lignes à lui seul.
Et ce fait justifie à lui seul la possibilité que la compilation prenne un peu plus de temps à s'effectuer si tu as 10 fichiers que si tu n'en a qu'un seul.
Là où les choses vont commencer à poser problème, c'est si la modification d'un fichier va provoquer la recompilation d'un nombre "excessifs" de fichiers qui n'ont de prime abord "rien à voir" les uns avec les autres
JadeSalina a écrit:
La solution est toute simple, il suffit que la librairie externe elle même suive les même principes de rester "simple" et du coup il suffira de mettre les quelques .h/.cpp dans notre projet et c'est bon. C'est ce que fait imgui https://github.com/ocornut/imgui il n'y a pas de système de build, du coup c'est très simple et rapide à utiliser dans notre projet. D'ailleurs si je ne m'abuse, je sort cette info du tréfond des ténèbres, je sais plus où j'ai vu ça ni quand donc c'est à prendre avec des pincettes mais il me semble que Lynix avait choisi un moteur physique pour Nazara notamment car il était facile à intégrer (je crois que c'était avant xmake), donc ça veut bien dire que c'est bien d'avoir un truc simple où on a pas besoin de se demander comment compiler le truc
Te revoilà avec tes "il suffit de" et tes "yaka"...
Mais, bon dieu! Tous les projets, toutes les bibliothèques externes que tu risques d'utiliser ne sont pas forcément aussi simples que imgui.
Quand tu as une bibliothèque externe qui te propose dix ou quinze modules différents qui n'ont a priori rien à avoir les uns avec les autres, qui proposent chacun plusieurs dizaines de fichiers d'en-tête réparti dans différents dossiers pour justement distinguer les différents modules, ce n'est plus "aussi simple" que cela.
Cela devient d'autant plus compliqué lorsque certains modules sont "header only" (ce qui permet d'intégrer le module en question rien qu'en incluant les fichiers d'en-tête) et que d'autres nécessitent une compilation pour une raison ou une autre, ou -- plus couramment encore -- lorsque certains de ces fichiers d'en-tête permettent de faire toute la différence entre une utilisation sous windows, sous mac ou sous linux, lorsqu'il ne s'agit pas -- en plus -- d'indiquer la présence ou non d'éléments optionnels.
Prends l'exemple de boost.
Boost, ca correspond à une cinquantaine de module (sans compter ceux qui sont dépréciés), dont certains n'ont plus "trop" de raison d'être car ils ont été repris "presque tels quels" dans la bibliothèque standard, soit.
Certains de ces modules sont header only. D'autres nécessitent une compilation. Et d'autres encore se satisfont "pas trop mal" des deux approches.
Peut être n'utilisera tu jamais certains modules. Ou peut-être décidera tu demain, pour répondre à un des besoins de ton projet, qu'il est peut etre pas mal d'utiliser "tel module" dont tu croyais jusqu'à présent que tu n'en aurais jamais besoin.
Ta solution sera complètement "à la ramasse" si tu dois intégrer chaque nouveau module dont tu as besoin "a mano" parce que tu ne sauras jamais dire ni quand ni dans quelles circonstances tu commenceras à avoir besoin de quelque chose de nouveau.
D'ailleurs, tu n'auras aucun moyen de t'assurer que tu dispose bel et bien du "nouveau truc" dont tu as besoin.
Les outils de builds servent, entre autres, à vérifier la configuration du système sur lequel on travaille, et à s'assurer que les "trucs" dont on a besoin sont bel et bien présent. Et il suffit généralement de deux ou trois instructions / lignes dans le fichier de description du projet pour que non seulement, ces outils vérifient que ton système dispose de tout ce dont tu as besoin, mais pour qu'ils s'assurent aussi que ces éléments soient utilisés au bon endroit et de la bonne manière.
Bien sur, tu peux toujours faire cela à la main, mais tu y perdra tot ou tard ton latin. Ne serait-ce que parce que tu auras acheté un nouvel ordinateur et que "tu sera persuadée" d'avoir déjà installé telle ou telle bibliothèque, sauf que ca, ca avait été fait sur l'ancien et que cela n'a pas encore été fait sur le nouveau.
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Alors je connais pas forcément bien le monde du travail pro mais j'avoue que je vois pas trop l'intéret de se déplacer pour au final se retrouver sur son propre pc, d'ailleurs à quoi ça sert de se déplacer tout court vu qu'on peut tout faire de chez soi et se parler directement sur Teams ?
Parce que le travail c'est plus que programmer dans son coin, c'est aussi des réunions sur l'avancement du projet, des problèmes résolus à plusieurs (peer programming), la vie d'entreprise, etc.
Koala l'a très bien expliqué, étant personnellement en télétravail à temps complet (plus par contrainte par rapport à mon lieu de vie) il est incroyablement plus facile pour moi de me connecter à mon pc à domicile pour travailler (et récupérer ainsi mes modifications, éviter d'installer et de compiler un projet incroyablement lourd sur l'ordinateur que la boite me met à disposition - d'ailleurs ça évite à la boite de devoir me libérer un ordinateur très puissant et permet à quelqu'un d'autre de l'utiliser).
JadeSalina a écrit:
Ça c'est pas si sûr car quand on compile indépendamment il faut invoquer le compilateur pour chaque fichier, et au final ça peut se retrouver plus long que de compiler beaucoup plus de code mais d'un coup, par exemple il est peut être plus rapide de compiler 10k lignes d'un coup plutôt que 1000 de ces lignes mais répartis dans 10 fichiers
Lorsque tu compiles une bibliothèque que tu vas utiliser, oui, c'est plus rapide de compiler tout son code source en une seule fois (à condition que ça soit possible au niveau de la mémoire que ça va demander au compilateur d'ailleurs), d'où l'unity build.
Lorsque tu travailles dessus, tu n'as pas envie de recompiler tes 10k lignes (= tous tes fichiers) dès que tu modifies trois lignes dans un seul fichier. Le projet sur lequel je travaille au taff fait des millions de lignes, j'ai plus que le temps de prendre un café lorsqu'on fait une compilation complète, je suis bien content de ne pas avoir besoin de toute les recompiler à chaque modification.
JadeSalina a écrit:
La solution est toute simple, il suffit que la librairie externe elle même suive les même principes de rester "simple" et du coup il suffira de mettre les quelques .h/.cpp dans notre projet et c'est bon. C'est ce que fait imgui https://github.com/ocornut/imgui il n'y a pas de système de build, du coup c'est très simple et rapide à utiliser dans notre projet. D'ailleurs si je ne m'abuse, je sort cette info du tréfond des ténèbres, je sais plus où j'ai vu ça ni quand donc c'est à prendre avec des pincettes mais il me semble que Lynix avait choisi un moteur physique pour Nazara notamment car il était facile à intégrer (je crois que c'était avant xmake), donc ça veut bien dire que c'est bien d'avoir un truc simple où on a pas besoin de se demander comment compiler le truc
Puisque tu me cites, demande-toi pourquoi j'ai sorti le code source de Newton Dynamics de mon repository et utilisé xmake à la place ? Parce que visiblement je suis au courant de ta solution "toute simple" (encore une !).
Koala l'a également très bien expliqué, c'est un choix qui n'est possible que parce que imgui est une lib relativement simple qui n'a pas de dépendance particulière et qui n'a pas besoin d'interagir avec le compilateur, avec le système, qui se résume à du C++ standard concrètement (à part pour le code des backend évidemment, mis dans des fichiers à part).
Sauf que ça n'est pas possible avec toutes les libs, Nazara nécessite des flags particuliers à la compilation (qu'il faudrait alors répliquer dans chaque projet ajoutant "NazaraEngine.cpp" - d'ailleurs ce serait même pas possible vu que j'ai des flags nécessairement différents entre les différents projets), NZSL dispose d'un binaire (compilateur standalone) en plus d'une lib, qui peut être nécessaire pour un projet, etc.
La raison pour laquelle j'ai viré Newton de mon repository et utilisé xmake est parce que ça me permet de ne pas avoir à me préoccuper de comment on compile les dépendances que j'utilise, ça me permet de ne pas avoir à me préoccuper de déléguer l'installation de ces libs à l'utilisation, ça me permet d'avoir automatiquement des mises à jours de certaines bibliothèques (et de garder d'autres MàJ manuelles). Sans parler de la taille du repository à l'époque où je mettais les binaires et headers des libs (pour chaque plateforme évidemment) pour les libs dont la compilation était trop complexe pour intégrer simplement le code source dans un coin (ce qui est tout aussi dégueulasse IMO).
Tu as une autre question où la réponse ne serait pas "parce que tu n'as aucune expérience et que tu parles sans savoir" ? Parce que jusqu'ici ça a systématiquement été le cas, enfin sauf les fois où tu te concentres sur un problème ultra important à tes yeux (temps de compilation ici) avec une solution toute trouvée qui apporte en fait d'autres problèmes.
Je te le redis, on n'utilise pas tes solutions "y'a qu'à" parce qu'on ne les connait pas, mais parce qu'on a évalué qu'elles n'étaient pas intéressantes. Parce qu'on se concentre sur plus d'un problème à la fois, parce qu'on fait des compromis, parce qu'on accepte de sacrifier un peu de temps de compilation pour avoir l'aisance d'utiliser des templates, parce qu'on accepte de faire des allocations dynamiques qui vont avoir un léger impact sur les performances pour simplifier l'écriture d'un programme déjà très complexe.
Tu es une enfant qui a besoin d'apprendre, d'apprendre que la réalité est plus complexe que ce qu'elle observe à travers des streams de gens particuliers, qu'il n'y a pas de solution miracle ("y'a qu'à", ça n'existe pas) parce que toutes les solutions apportent leur lot de problème.
Être un bon développeur c'est être capable de faire des compromis. De comprendre qu'on ne raisonne jamais en absolu mais en relatif, aucune solution n'est meilleure que les autres en dehors d'un ensemble de contrainte données, et les contraintes sont différentes par projet et par développeur.
La discussion devient trop digressive à mon goût (oui je suis modérateur tout puissant et c'est mon goût qui prime !).
La question de départ portait "simplement" sur le temps de compilation d'un projet spécifique de Autechre, qui plus est la taille de ce projet était erronée et à était revue en cours de discussion ...
Je ne peux pas prendre le temps de modérer tous les messages hors sujet ou polémiques de ce thread tant ils sont nombreux et intriqués.
Je vais donc laisser le thread en l'état et le clore.
Si vous avez-besoin de prolonger la discussion sur les temps de compilation, je vous propose d'ouvrir un nouveau sujet, en espérant que vous parviendrez à ne pas partir en cacahuètes ...
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Le Tout est souvent plus grand que la somme de ses parties.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Discord NaN. Mon site.
Discord NaN. Mon site.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)