Le topic de la programmation: Et envoyez des sioux!

[Lazyjoe]

Cette syntaxe tu la retrouves dans beaucoup de langages modernes.
La seule différence va être de remplacer les parenthèses par des crochets ou des accolades parfois.

Oui c'était le point, en C++ moderne on commence vraiment à avoir des syntaxes très simples sans sacrifier aucune des caractéristiques du langage pour autant.

[Tramb]

Tu ferais comment pour retourner plusieurs valeurs sans tuple ?
Plus exactement, y aurait-il un intérêt à ne pas rendre ça compatible avec les tuples ?

Un tuple est un type qui groupe un nombre fini et prédeterminé de valeurs, chacune avec son type (pour les langages statiquement typés). Ça correspond exactement au besoin de valeurs de retour multiples.
Ça n'est pas pour rien qu'autant de langages (tous ?) l'implémentent avec un tuple ou ce qu'ils ont de plus proche. Bonus : il n'y a rien à ajouter au langage pour que ça marche.

Ensuite chaque langage fait avec ce qu'il a à disposition (vérification runtime ou pas, déstructuration, ...).

Quand tu appelles une fonction, en général,tu ne packes pas un tuple pour ça (il y a plein de finesses sur cette phrase, mais d'un point de vue syntaxe de surface, je passe). Donc on peut se demander s'il y a raison de devoir en dépacker un pour devoir renvoyer plusieurs valeurs.
En général dans langages statiquement typés, oui, et c'est le sucre qui fait la sauce.
Dans les langages dynamiquement typés, ça se débat.

Edit : je vire mon exemple, qui a besoin de plein de prérequis et n'est pas très éclairant.

- - - Mise à jour - - -

(Très) souvent un tuple se remplace par un objet du domaine. Et si tu vois pas comment le modéliser par un objet du domaine faut ptet se poser la question de ce que fait ta fonction.

D'ailleurs c'est pas pour rien que les langages avancés rajoutent du sucre syntaxiques pour les ramener sur une structure objet avec des propriétés bien nommée (mais arrivé là, mieux vaux créer son objet comme un grand).

Pas faux mais très souvent une lambda se ramène à une fonction du domaine. Enfin tu vois où je veux en venir
Nommer ou considérer que c'est juste la glue, y a pas de vérité objective, on sait juste détester le code qui fait pas le "bon" truc quand on le lit.

[Anonyme20240202]

Putain de nom de dieu, va me falloir un expert Windows pour m'expliquer. J'arrive pas à rester calme et courtois avec cet OS, pardonnez moi l'énervement

Comment vous bossez en C++ sous Windows sérieusement

J'ai voulu reproduire mon setup pour programmation GPU (que j'ai sous Linux) sur Windows.

Windows qui a apparemment quelque défenseurs sur le forum, donc ça va être le moment de sortir la sauce parce qu'a priori cet OS de merde, pue effectivement bien la merde. Je laisse le bénéfice du doute, peut être que je connais pas, mais là j'ai d'énormes doutes.

Donc la question à 2 Milliards c'est:

Comment vous choppez une dépendance pour un de vos projet.

Exemple, je veux faire un super cube qui tourne avec ma carte graphique.

Sur Linux ça ressemble à ça:
# Install
package-manager install vulkan
package-manager install glfw3
# CMake
find_package(Vulkan)
find_package(glfw3)

Fini.

Sur Windows je suis TRES CURIEUX de savoir quelle est la norme.

Parce que là je vois que le site de Vulkan propose un installeur qui met les variables kivonbien dans le path, et effectivement ça fonctionne, rien de sorcier, mais faut passer par un putain de navigateur web, cliquer 10 fois et enfin avoir l'install.
Tu peux aussi tenter de passer par un package manager genre scoop ou choco truc voir vcpkg, mais les versions sont carrément en retard et ça a l'air de merder au niveau du path.

Cette chiasse de vcpkg (qui d'ailleurs t'opt-in par défaut pour envoyer des données ces fils de pute, pas la décence d'opt-out par défaut ou de demander) te demande de toute façon de passer par le site de Vulkan, mais quel est l'intérêt de ce truc sérieux.

Bon on va dire que pour Vulkan on va faire à la main, mais ensuite si tu veux GLFW pour un peu de cross plateforme, il faut download le truc à la main, et l'installer/linker à la main? Hors de question, je veux du générique, je veux du standard, jamais tu verras un chemin absolu dans mon projet tu m'entends§§§ (Bon en vrai j'aurais p'têt eu plus vite fait de compiler les sources en mode sous module)

Et je parle même pas de l'installation de Git sur windows avec l'installer de leur site internet putain de merde, faut littéralement cliquer 40 fois pour installer ça (mais quelle honte), sur linux t'as une commande à faire.

Mon but c'était de faire un projet cross plateforme que n'importe qui puisse utiliser, que ce soit un glandu sous windows ou un mec sur linux mais là ça motive carrément pas pour partager le projet sur windows.

Le pire c'est que je vois nombre de guides de mecs sérieux qui te demande de clicker comme sur démineur pendant 3 heures pour installer les trucs.

Bon là j'admets ma défaite et j'installe Vulkan à la mano comme un bon toutou, ensuite j'installe GLFW avec vcpkg parce qu'il faut pas déconner, après m'être battu avec le fait qu'il faut gérer à la main x86 vs X64 quand j'installe la merde

Ensuite je découvre avec horreur, que les démos de Vulkan sont taillées pour Visual Studio, et que si t'essayes de faire la même chose à coup de CMake t'es pas dans la merde pour savoir quoi linker, je connais tellement pas visual studio que je sais pas où on voit comment le compiler est invoqué, enfin bref, j'ai vite laissé tombé tous ces trucs visual studio.

Je suis reparti sur mon projet perso et miracle, j'ai un CMake cross platform, mais c'était pas gagné

cmake_minimum_required(VERSION 3.19)
project(test_cpp)

set(CMAKE_CXX_STANDARD 20)

find_package(glfw3 REQUIRED)
find_package(Vulkan REQUIRED)

add_executable(test_cpp main.cpp)

target_link_libraries(test_cpp glfw Vulkan::Vulkan)

Et je passe sur Visual Studio que je préfère ignorer pour ma santé mentale, mais 90% des projets que je vois avec cette merde gère les dépendances n'importe comment, chemins absolu, rien de cross platform avec des dépendances fortes sur Visual Studio, aucun respect. Les mecs tu leur enlèves leur IDE ils ont aucune idée de ce qu'il se passe. Et ce putain de compilo planqué dans la cambrousse avec l'IDE mais quelle daube.

------------

'Fin bref mis à part ça je suis curieux de savoir quel compilo offre les meilleurs perf sur windows, je vais checker ça

[TwinBis]

À ce niveau je pense que l'OS n'est pas le seul problème.

[Anonyme20240202]

J'avais besoin des les insulter, ça va mieux

Je vais aller jeter un oeil aux repos les plus populaires voir comment ils gèrent ça, vcpkg et conan ont l'air d'être les trucs les plus "sérieux"

[rOut]

Je ricane.

Je vais aller jeter un oeil aux repos les plus populaires voir comment ils gèrent ça, vcpkg et conan ont l'air d'être les trucs les plus "sérieux"

D'autant plus. Hin hin.

En gros : c'est la grosse foire, et y'a pas un projet pour rattraper l'autre.

[Cwningen]

Ma solution de non-expert Windows est d'utiliser msys2, c'est presque comme Linux. Mais dans ce cas c'est du mingw au lieu de msvc et peut-être que ça ne te convient pas. On peut faire des compromis aussi, il m'est arrivé d'utiliser le git de msys2 avec msvc dans cmd.exe à coté.

Pour les dépendances, j'ai malheureusement l'impression que la mode devient de tout inclure dans des sous-modules git. Je vois de plus en plus de projets libres faire ça. C'est peut-être mieux pour Windows, mais je trouve ça horrible sous Linux.

[Anonyme20240202]

À la base j'allais partir sur mingw, mais je me suis dit tant qu'à faire je vais jeter un oeil à msvc vu que je l'utilise jamais (je vais voir où ils en sont dans l'intégration du C++20 et je vais checker ce que ça donne niveau perfs).

Jamais entendu parler de msys2, je vais me renseigner!

Perso j'aime bien l'approche git submodule mais il faut s'y acclimater un peu ouais, c'est surtout quand tu build tout from source, ça résout pas le problème des trucs pré compilé à moins de complètement corrompre l'idée des submodules.

Sinon j'ai installé le fameux WSL (windows submodule machin for Linux), on passera sur l'aspect conceptuel plus que douteux mais dans la pratique j'ai même plus envie de sortir du terminal, plus besoin d'utiliser leur explorer de fichier pourrave, et mlocate fonctionne mieux que la fonction de recherche windows haha, ça dépanne bien

[gros_bidule]

Question de néophyte en C/C++ : pourquoi le fais-tu sous Windows ? Ne peux-tu pas compiler depuis Linux, et produire des binaires Windows ?
Si tu dois vraiment être sous Windows, ne peux-tu pas utiliser WSL2 (ou une vm VirtualBox/VMware) pour quand même avoir tes outils dans un environnement Linux, puis ça produit des binaires dans un répertoire accessible que tu vas tester direct dans ton Windows ?

C'est ce que je compte faire pour du Rust. Bon, ça s'est apparemment amélioré sous Windows, mais j'ai l'impression que c'est pas encore ça. C'est quand même bête, car pour du Java, Python, Go, JS, ça se passe super bien. Mais tout ce qui est C / Rust, il y a comme une entente, une conspiration pour nous faire c****. Je ne vois que ça.

[Dross]

Oh un exercice de mauvaise foi !
Attendez, j'arrive !

Comment vous bossez en C++ sous Windows sérieusement

On bosse pas en C++ nous monsieur, on a évolué nous, MS nous a dit que C# était l'élu. Situé à gauche de Dieu .NET.
Donc on bosse en C#.
Mécréant.

Comment vous choppez une dépendance pour un de vos projet.

Par Nuget.
C'est comme celui du MacDo: simple, rapide, croustillant.

Exemple, je veux faire un super cube qui tourne avec ma carte graphique.

Sur Linux ça ressemble à ça:
# Install
package-manager install vulkan
package-manager install glfw3
# CMake
find_package(Vulkan)
find_package(glfw3)

Fini.

Sur Windows je suis TRES CURIEUX de savoir quelle est la norme.

La norme c'est simple : t'est chez tonton MS maintenant, alors c'est via l'outil de tonton : Visual Studio.
Clic droit sur le projet dans VS/manage nugets.
Je recherche une lib d'opengl, install, done.

Parce que là je vois que le site de Vulkan propose un installeur qui met les variables kivonbien dans le path, et effectivement ça fonctionne, rien de sorcier, mais faut passer par un putain de navigateur web, cliquer 10 fois et enfin avoir l'install.
Tu peux aussi tenter de passer par un package manager genre scoop ou choco truc voir vcpkg, mais les versions sont carrément en retard et ça a l'air de merder au niveau du path.

Cette chiasse de vcpkg (qui d'ailleurs t'opt-in par défaut pour envoyer des données ces fils de pute, pas la décence d'opt-out par défaut ou de demander) te demande de toute façon de passer par le site de Vulkan, mais quel est l'intérêt de ce truc sérieux.

Bon on va dire que pour Vulkan on va faire à la main, mais ensuite si tu veux GLFW pour un peu de cross plateforme, il faut download le truc à la main, et l'installer/linker à la main? Hors de question, je veux du générique, je veux du standard, jamais tu verras un chemin absolu dans mon projet tu m'entends§§§ (Bon en vrai j'aurais p'têt eu plus vite fait de compiler les sources en mode sous module)

Bah c'est une dépendance, donc on regarde sur Nuget.
What else?

Et je parle même pas de l'installation de Git sur windows avec l'installer de leur site internet putain de merde, faut littéralement cliquer 40 fois pour installer ça (mais quelle honte), sur linux t'as une commande à faire.

A oui mais là faut arrêter avec cette habitude de linuxien à toujours vouloir faire de la ligne de commande et avoir tout fourni en kit de pièces détachées : t'est sur un OS de gens qui on autre chose à foutre là !

C'est l'installeur de VS qui est ton ami, tout le reste tu oublie, tu réinvente la roue, et ça c'est bon pour les autres, toi t'est un homme qui n'est pas rien, qui traverse la rue, qui a des choses à faire pour devenir millionnaire.

L'installeur de VS contient tout ce qu'il faut pour bosser, l'UI est aussi très claire, c'est simple comme tout - je sais sur linux t'est pas habitué - regarde :



Tu veux développer sous Node ? Clique Node. Du Python ?.. clique Python ! T'a besoin de git ? Yeah baby clique sur Git. Un truc qui manque ? C'est probablement dans la liste des modules individuels.

Tu va quand même pas passer 4h à installer ta machine, t'est sur un OS de gens qui ont du taf à faire là !

Et je passe sur Visual Studio que je préfère ignorer pour ma santé mentale, mais 90% des projets que je vois avec cette merde gère les dépendances n'importe comment, chemins absolu, rien de cross platform avec des dépendances fortes sur Visual Studio, aucun respect. Les mecs tu leur enlèves leur IDE ils ont aucune idée de ce qu'il se passe. Et ce putain de compilo planqué dans la cambrousse avec l'IDE mais quelle daube.

Bah voilà aussi, monsieur veux pas utiliser le saint VS et après ça râle qu'il se prends des murs. C'est du joli. Bravo.

T'est sur WINDOWS, et ici on est enfermé dans la grotte de MS, on est nombreux mais MS pourvois à tout, c'est la machine éternelle, si tu as besoin de quelque-chose, MS te l'a déjà prémâché avant, t'a juste à cliquer ici et là, et boom, t'est déjà sur le market alors que les autres sont encore à débugger leur CMAKE.
Alors oui, y'a foule, et y'a 2-3 losers un peu pénibles avec leur post-it MVP collé sur le front, mais en dehors de ça c'est chill, aller viens ! On est bien !


Blague à part, du C++/Opengl j'en ai fait qu'étant étudiant et à l'époque c'était folklo, mais milieu universitaire aussi donc c'est possible qu'il existe des choses aussi soigné qu'en .NET, mais comme MS a vraiment énormément investi sur sa stack .NET (avec .NET Core) il est aussi possible que le tooling soit un peu désuet ailleurs.
En plus pour ne pas larguer les Linuxiens qui sont paumés dès que c'est différent de leurs habitudes, MS a progressivement migré son tooling en mode exécutable qu'on peut utilise en ligne de commande (comme le programme "dotnet").

Pour la compilation à l'ancienne (dont les stacks C/C++) tu aura probablement besoin d'utiliser une console avec toutes les variables d'env et tooling pour le build. T'a déjà essayé et ça marchais pas ? Ah mais oublie pas : t'est chez MS maintenant, on a une "Console Visual Studio" ! Et dans la Console Visual Studio tout est préchargé pour toi pour faire tes opérations de build. (ça fait longtemps que j'ai pas utilisé mais de mémoire c'est ça).

T'a pas le choix, t'aime Visual Studio, c'est ton pote maintenant, alors vous vous faites la bise et tu va voir que tout tes soucis vont disparaître d'un seul coup.

[Anonyme20240202]

Question de néophyte en C/C++ : pourquoi le fais-tu sous Windows ? Ne peux-tu pas compiler depuis Linux, et produire des binaires Windows ?
Si tu dois vraiment être sous Windows, ne peux-tu pas utiliser WSL2 (ou une vm VirtualBox/VMware) pour quand même avoir tes outils dans un environnement Linux, puis ça produit des binaires dans un répertoire accessible que tu vas tester direct dans ton Windows ?

C'est ce que je compte faire pour du Rust. Bon, ça s'est apparemment amélioré sous Windows, mais j'ai l'impression que c'est pas encore ça. C'est quand même bête, car pour du Java, Python, Go, JS, ça se passe super bien. Mais tout ce qui est C / Rust, il y a comme une entente, une conspiration pour nous faire c****. Je ne vois que ça.

Bonne remarque, la distinction c'est que je souhaite partager un projet en mode open source, donc pas hyper intéressé par les binaires en eux-mêmes mais surtout par le fait de partager le projet et que n'importe quel pékin puisse compiler depuis les sources et contribuer.

WSL2 ou une Box ça te forcerait tout de même à cross compiler mais ça fonctionnerait ouais, mais du coup un peu lourd de demander ce genre de setup aux gens qui souhaitent contribuer. Y'a aussi le setup Wine + msvc, mais un peu la même remarque, et tu souffres niveau perf.

Y'a aussi le fait que le problème se propage pour les dépendances... Ce qui peut vite devenir très lourd, tu ne vas pas cross compiler toute tes dépendances, mais du coup ça implique que tu choppes absolument toutes tes dépendances en version pour Windows avant de cross compiler ton projet, ce qui peut t'amener très loin car tes dépendances peuvent également avoir leurs dépendances...

Du coup pour toutes ces raisons je préfère une approche native, aussi aucune idée de la maturité de la cross compilation pour ça.

-------

@Dross merci pour les explications, curieux de savoir si y'a des approches purement ligne de commande pour tout ça (genre invoquer nuget, j'imagine que oui). Le truc cool quand tu évites les clics c'est qu'ultimement ça permet de scripter, donc l'utilisateur n'a qu'une seule action à faire et tu t'occupes du reste. L'approche via clics dans la GUI je souhaite vraiment l'éviter à tout prix pour Visual Studio car ça rend un peu trop dépendant de l'outil, la moindre mis à jour pourrait rendre ton truc bancale et s'pas viable de demander à un mec de reproduire une séquence de clics. En gros mon but ça serait de faire un projet 100% portable que n'importe qui puisse ouvrir et éditer puis compiler, que ce soit Visual Studio ou VS Code. Donc pas de .sln si possible, etc.

[Dross]

@Dross merci pour les explications, curieux de savoir si y'a des approches purement ligne de commande pour tout ça (genre invoquer nuget, j'imagine que oui). Le truc cool quand tu évites les clics c'est qu'ultimement ça permet de scripter, donc l'utilisateur n'a qu'une seule action à faire et tu t'occupes du reste. L'approche via clics dans la GUI je souhaite vraiment l'éviter à tout prix pour Visual Studio car ça rend un peu trop dépendant de l'outil, la moindre mis à jour pourrait rendre ton truc bancale et s'pas viable de demander à un mec de reproduire une séquence de clics. En gros mon but ça serait de faire un projet 100% portable que n'importe qui puisse ouvrir et éditer puis compiler, que ce soit Visual Studio ou VS Code. Donc pas de .sln si possible, etc.

Oui, MS est vraiment revenu de sa période Ballmer et du "tout doit être chez nous", et même si au quotidien on utilise les UI, tout est utilisable par ligne de commande, même les .sln. Par exemple un "dotnet restore" va restaurer tes dépendances ou "dotnet test" va aller trouver tout les tests de ta solution et les rouler.

"dotnet" étant le CLI de .NET Core c'est même cross-plateforme, pas de soucis de ce coté là, en fait t'est pas vraiment bloqué sur VS ensuite (je build d'ailleurs du .NET pour linux quotidiennement via CICD hébergé sur TFS en interne et publié ensuite sur un repo privé Docker, la stack est devenu très ouverte).

Et même avant, on avait des trucs comme msbuild (ça build d'ailleurs aussi du C++, sait pas si ça te sera utile) qui permettait de gérer aussi le CICD, ou de préparer des process de build complexe à base de pré et post-traitement comme le name mangling et obfuscation.

[deathdigger]

Oh un exercice de mauvaise foi !
Attendez, j'arrive !

...

T'aurais pu noter que nuget est aussi disponible en ligne de commande, qui est aussi intégrée à VS :


Et que comme c'est chiant de se rappeler des 50 millions de commandes différentes, MS a fait simple :

Tu cherches un package ?

Find-Package toto

Tu veux installer un package dans ton projet tata (pour qu'il ajoute automatiquement les dépendances) ?

Install-Package toto -ProjectName tata

[vectra]

Ca la ramène pour parler de C# sous Visual Studio?
Si, à 30 ans, t'as toujours pas de Rider@Jetbrains, t'as raté ta vie


Un truc "bien" sur Linux en C++, c'est qu'il est très facile de ramener des libs standard à l'échelle du système avec apt-get. Si on veut intégrer le source dans le projet pour être un peu robuste, tant que le projet dispose d'un CMake standard, ça se fait littéralement tout seul en rajoutant une ligne dans le CMake.
Au passage, Visual supporte maintenant très correctement les projets CMake. Même Qt s'y est officiellement mis.

[Nilsou]

Sinon j'ai installé le fameux WSL (windows submodule machin for Linux), on passera sur l'aspect conceptuel plus que douteux mais dans la pratique j'ai même plus envie de sortir du terminal, plus besoin d'utiliser leur explorer de fichier pourrave, et mlocate fonctionne mieux que la fonction de recherche windows haha, ça dépanne bien

Dans l'enseignement en ce moment on est passé sous WSL là ou je bosse pour les élèves. Et tu peut tout compiler sous WSL si tu veut, mais ça fait des exécutable linux, évidemment (lançable sous WSL ceci dit, mais si il y a du graphique il te faudra un MobaXterm d'installé pour que les appels graphiques linux passent à Windows)

- - - Mise à jour - - -

Putain de nom de dieu, va me falloir un expert Windows pour m'expliquer. J'arrive pas à rester calme et courtois avec cet OS, pardonnez moi l'énervement

Comment vous bossez en C++ sous Windows sérieusement

En dehors de la non-réponse de dross qui te dit de passer à C# , la vrai réponse c'est que Msys2/mingw fait le taf pour toi pour 95% des bibliothèques standards. Vulkain inclut. (j'ai un projet sous vulkain, ça m'a ne m'a pris longtemps à configuré avec msys2 et cie), pour le reste faut effectivement installer les choses à la main, pas de bol.
En gros pour Vulkain tu suit ceci :
https://vulkan-tutorial.com/Developm...t#page_Windows

Tu l'adapte légèrement à msys et ça fait un truc très très court.

Moi ça donne juste ça pour Vulkain + GLFW sous windows :
-std=c++2a -IC:\msys64\mingw64\include\c++\9.3.0 -IC:\msys64\mingw64\include -IC:\msys64\usr\include -IC:\VulkanSDK\1.2.131.2\Include -I"\Projet_Vulk\include" -O0 -g3 -Wall -Wextra -c -fmessage-length=0

Et les include c'est tout GLFW qui gère
#define GLFW_INCLUDE_VULKAN // Dit à GLFW d'inclure vulkan et de s'en occuper
#include <GLFW/glfw3.h> // inclut automatiquement Vulkan.h et autres, donc inutile de le faire

Bref, c'est vrai que sous windows faut à chaque fois se creuser la tête, mais avec les bons outils c'est assez court au final.

Donc, par exemple, je ne sais pas comment tu en est venu à télécharger, installer et linker GLFW à la main, mais c'est totalement inutile (du moins, pour développer, ensuite il faut effectivement distribuer l'application et c'est une autre histoire en fonction de comment tu link les choses etc.)

[Garrluk]

Même Qt s'y est officiellement mis.

Même si ça marche officiellement, je vous déconseille d'essayer de faire du qtcreator + cmake, c'est une vrai purge à faire cohabiter pour le moment.

[vectra]

CLion + Designer (la version lite qui produit un .ui) + CMake.
Besoin de rien d'autre, même sous windows.

[Taro]

CLion paraît que c'est très cool, mais ça coûte une blinde.

[Anonyme20240202]

J'utilise Clion aussi, j'aime beaucoup, et ouais je suis pas super satisfait du fait que y'ait pas d'alternative open source/gratos comme ils le font avec PyCharm et sa community edition.

Le produit est cool, mais c'est le seul maillon de la chaine qui n'est pas open source dans mon workflow il me semble. D'ailleurs cette année je n'ai pas encore renouvelé ma license perso avec tous les outils Jetbrains, j'utilise mon compte pro (payé par la boite) avec seulement CLion.

Et certes j'aime beaucoup CLion, le fait est qu'au fond l'outil se repose énormément sur des trucs open source (clang-tidy, clang format, etc.), mais n'offre pas tant de fonctionnalités finalement.

Bref, je suis tiraillé. Je vais peut-être m'essayer aux alternatives gratos, ou alors renouveler ma license comme un mouton (j'ai aussi la possibilité de la fallback version qui reste gratos pour toujours)

C'est pas que ça me dérange de payer, mais quand je fais de l'open source je veux avoir la garantie que les gens qui utilisent mon projet soient conforts, et si je vois tout au travers du prisme CLion (qui bundle gdb, cmake, trouve automatiquement les trucs sous windows, linux, etc.), ça donne pas une bonne vision, tout le monde ne peut pas forcément se procurer CLion.

Après la version d'essai de CLion est bien, et très facile à """hack""" à vrai dire (renouveler la période de 30 jours).

S'ils passaient CLion open source je re-paierai ma license direct. Je suis sûr qu'ils gagneraient plus de thune à vrai dire.

Y'a Aseprite qui fait ça, c'est open source et gratos mais y'a les builds payants sur Steam.

[Cwningen]

Tu l'adapte légèrement à msys et ça fait un truc très très court.

Moi ça donne juste ça pour Vulkain + GLFW sous windows :
-std=c++2a -IC:\msys64\mingw64\include\c++\9.3.0 -IC:\msys64\mingw64\include -IC:\msys64\usr\include -IC:\VulkanSDK\1.2.131.2\Include -I"\Projet_Vulk\include" -O0 -g3 -Wall -Wextra -c -fmessage-length=0

Tant qu'à utiliser msys2, autant utiliser le shell qui va avec pour ne pas écrire tous les chemins d'include. Et installer vulkan avec le gestionnaire de paquet aussi.

[Anonyme20240202]

Ca a l'air génial ce msys2, exactement ce qu'il me fallait, bizarre que j'en ai jamais entendu parler auparavant, 'fin c'est pas comme si je suivais l'actu windows, mais tout de même c'est la première fois que je le vois mentionné

- - - Mise à jour - - -

Edit: ah, une recherche sur le forum m'indique qu'il avait déjà été mentionné sur ce topic par ci par là, cool. Impatient de tester ça

[Nilsou]

CLion paraît que c'est très cool, mais ça coûte une blinde.

Sauf si tu es enseignant, c'est totalement gratuit

- - - Mise à jour - - -

Tant qu'à utiliser msys2, autant utiliser le shell qui va avec pour ne pas écrire tous les chemins d'include. Et installer vulkan avec le gestionnaire de paquet aussi.

Je crois que j'avais fait ça pour profiter de la dernière version de Vulkain, qui n'était pas encore présente sur Msys2 à l'époque ou j'avais codé.
Sinon je vois pas trop ce que tu veut dire par « utiliser le shell pour éviter d'écrire tout les chemins d'include » dans ce contexte Tu veut dire rajouter le machin dans la variable path ?

- - - Mise à jour - - -

Ca a l'air génial ce msys2, exactement ce qu'il me fallait, bizarre que j'en ai jamais entendu parler auparavant, 'fin c'est pas comme si je suivais l'actu windows, mais tout de même c'est la première fois que je le vois mentionné

- - - Mise à jour - - -

Edit: ah, une recherche sur le forum m'indique qu'il avait déjà été mentionné sur ce topic par ci par là, cool. Impatient de tester ça

C'est qu'un genre d'encapsulation ++ de mingw en définitive, mais ça fait très bien le job.
Note que ça ne change rien pour quand tu va devoir distribué ton programme : tu ne peut pas demander aux gens d'avoir Msys2 donc faudra distribuer les dll à la mano avec, comme d'habitude. Ça ne te simplifie la vie que pour le dev.

[Anonyme20240202]

Ouais c'est ce que je dis plus haut, je m'intéresse aux devs, distribuer les binaires c'est pas le problème. Ca me dérange absolument pas d'imposer un truc aux devs qui veulent contribuer du moment que c'est relativement standard et stable pour leur plateforme (de la même manière que CMake est plus ou moins "imposé" souvent, bien sûr tu peux tout compiler à la main si tu veux), et surtout simple d'utilisation. Sachant que les devs plus velus pourront de tout façon setup leur environnement from scratch donc juste avec les sources ils sont autonomes, et c'est d'ailleurs des commits/pull request classiques, proposer une install par d'autres biais.

Quoiqu'en vrai je peux faire un package MSYS2 et distribuer mes binaires comme ça, HAHA!

[Cwningen]

Sinon je vois pas trop ce que tu veut dire par « utiliser le shell pour éviter d'écrire tout les chemins d'include » dans ce contexte Tu veut dire rajouter le machin dans la variable path ?

Je sais pas ce que ça configure exactement, mais il n'y a pas besoin de configurer les includes standard (-IC:\msys64\mingw64\include\c++\9.3.0 -IC:\msys64\mingw64\include -IC:\msys64\usr\include).

[vectra]

Cette année j'ai claqué 115 boules pour avoir la licence all products; d'habitude je me contente de CLion mais cette année il me fallait également Rider.
C'est pas donné, mais avec un salaire, normalement, ça passe. Et ça rentre dans les frais réels.

L'an dernier j'ai payé 53€ pour ma licence CLion, et pour l'avoir poncé toute l'année ça valait la peine. C'est plus cher les deux premières années par contre.

Accessoirement, si tu es travailles effectivement sur un projet open-source, tu peux obtenir une licence gratuite pour un an renouvelable. Y faut un GitHub à montrer notamment.
Ce sont des conditions similaires pour les enseignants et les étudiants, ces derniers étant condamnés à gagner leur fric au bout de 2 à 5 ans.

Sinon je comprends totalement Kamikaze; à un moment j'ai eu besoin d'intégrer une simple lib pour gérer des archives zip: aller niquer vos mères.
Sur Linux, la lib et le SDK doivent être déjà installés par défaut; là t'as rien. Un projet pour la lib zip sans CMake bien sûr, un autre pour la gestion de l'archivage
Le bordel que c'est de créer une pauvre dll, le .lib: aller vous faire voir
Quand je pense que certains voulaient me faire faire ça sous Visual





(PS: PyCharm est gratuit en version lite, mais résolument pas Open-source).

[Anonyme20240202]

Me semble que si ici: https://github.com/JetBrains/intelli.../master/python

"PyCharm Community Edition

The "python" directory in the source repository contains the source code of PyCharm Community Edition and the Python plugin for IntelliJ IDEA Community Edition."

Mais j'ai jamais testé (berk le java), donc je sais pas si t'obtiens un truc viable from scratch?

[Dross]

Ca la ramène pour parler de C# sous Visual Studio?
Si, à 30 ans, t'as toujours pas de Rider@Jetbrains, t'as raté ta vie

Franchement Rider c'est pas terrible. Je l'ai installé, il est même encore sur ma machine faudrait que je le relance, mais on est loin d'un VS+Resharper. Ptet une question d'habitude après.

Ps: je viens de le relancer, bon ça a l'air de bien avoir évolué j'essayerai de lui donner une seconde chance.

[Anonyme20240202]

Reeeejoins nous~~~~

[Robix66]

C# + Github Actions + Github Packages, de rien.

[gros_bidule]

(PS: PyCharm est gratuit en version lite, mais résolument pas Open-source).

PyCharm Community est bien opensource
https://github.com/JetBrains/intelli.../master/python