Le topic de la programmation: Et envoyez des sioux!

**Tramb** · 09/05/2021, 09h42

Envoyé par acdctabs

Euh non. Tout est défini dans la loi.
C'est même plutôt clair (même s'ils veulent tout changer à terme pour simplifier/moderniser tout ça).
Il y a tellement eu de problèmes avec Louvois que c'est compliqué de définir une cause.

Enfin la loi, niveau specs formelles, on a vu légèrement mieux.
coqc codepenal.v

**acdctabs** · 09/05/2021, 09h56

Comme je dis, il y avait tellement de problèmes... Le successeur marche très bien.
Le truc cool avec le successeur c'est qu'il y a un site (interne) qui nous donne une visu sur notre situation, on a l'historique, bref c'est bien foutu.
Le petit truc en + c'est qu'une dizaine de jours avant d'être payé, on sait le montant du virement.
Quand on attend des primes, ça nous permet de savoir si ça tombe ce mois-ci ou pas

**Orhin** · 10/05/2021, 17h39

Envoyé par TwinBis

Vous êtes en train de dire que vos employeurs ne vous payent pas de license pour votre IDE ?

Moi aussi je trouve ça aberrant mais c'est le cas malheureusement pour plein de boîtes.
Ce qui est complètement con, on parle de licences à 500€ grand max, soit 1 à 2 jours de boulot à un TJM classique en SSII.
Si ton IDE te fait gagner ne serait ce que 1% de productivité sur l'année, c'est rentabilisé.

Perso j'ai le all-product de JetBrains depuis plusieurs années et ma boîte ne me pose même pas de questions lors du renouvellement de la licence.

**Kesitem** · 10/05/2021, 17h58

Envoyé par Kamikaze

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é

Code:

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

Salut, je te réponds longtemps après la bataille (je suis de loin le thread),

mais pour ma part, j'utilise vcpkg: https://github.com/microsoft/vcpkg

Ca répond en grande partie aux manques de paquets distribués pour windows et ça fonctionne parfaitement avec CMAKE.

Je te conseille d'éviter le "integrate install" mais de passer par le script CMAKE en ajoutant le "-DCMAKE_TOOLCHAIN_FILE=...".

La grosse difficulté qui n'est pas mise en avant dans la doc et la gestion des triplets, c'est la première chose à configurer aussi. Il faut penser à définir ton option "DVCPKG_TARGET_TRIPLET".

Edit: Ajout d'une partie manquante à mon message.

Edit 2: Les triplets.

**vectra** · 10/05/2021, 18h58

Enorme, merci

**Nilsou** · 17/05/2021, 15h25

Dites, quelqu'un pourrait me résumer l’intérêt de l'approche signals/slots de QT par rapport à l'approche de GTK et autre à base de callback ?
Au départ je pensais que ça avait un intérêt parce qu'on pouvait n'avoir pas besoin de définir précisément l'instance des classes dont les signaux nous intéressé mais en fait, si, on a besoin aussi en QT dans le connect ...

Et je vois que dans les versions modernes de QT on utilise maintenant des pointeurs de fonctions dans le connect. Alors je suis un peu perdu. Que fait QT de plus dans ce contexte ?

**Cwningen** · 17/05/2021, 15h48

Des signaux façon libsigc++ par rapport à des callbacks simples a l'avantage de pouvoir connecter plusieurs callbacks/slots par signal.

Qt va plus loin grâce à ses boucles d'évènements. Les slots peuvent être appelés directement (comme des callbacks) ou être mis dans la file d'attente d'une boucle d'évènements. En mode automatique, la méthode d'appel est décidée en comparant le thread courant et le thread du QObject. https://doc.qt.io/qt-5/qt.html#ConnectionType-enum

**Robix66** · 17/05/2021, 15h49

Question .Net : quelqu'un a un tuto à jour et compréhensible pour charger des dll en dehors de l'application base du programme ? Quand je cherche, ça tourne en boucle sur 2-3 solutions, mais impossible de les faire marcher (assembly ou une de ses dépendances non trouvée), et pas moyen d'avoir autre chose que "si si, utilise ça" sans autres explications.

**Nilsou** · 17/05/2021, 15h52

Envoyé par Cwningen

Des signaux façon libsigc++ par rapport à des callbacks simples a l'avantage de pouvoir connecter plusieurs callbacks/slots par signal.

Qt va plus loin grâce à ses boucles d'évènements. Les slots peuvent être appelés directement (comme des callbacks) ou être mis dans la file d'attente d'une boucle d'évènements. En mode automatique, la méthode d'appel est décidée en comparant le thread courant et le thread du QObject. https://doc.qt.io/qt-5/qt.html#ConnectionType-enum

Ok, j'ai effectivement lu ça plusieurs fois, mais je ne vois pas trop ce qui empêche de connecter plusieurs callback à un signal, ou dans l'autre sens, avec les callback de GTK. Ça appelle un pointeur de fonction, plusieurs signal peuvent appeler les même pointeurs de fonctions si ils en ont envie il me semble ...

Pour le multithread, oui j'ai bien vu l'avantage. Mais ça reste assez spécifique (intérêt uniquement quand on a des trucs lourds à calculer dans l'affichage) parce que si le but c'est juste d'appeler l'IHM depuis des thread de calcul, on le fait depuis GTK aussi (avec des gdk_threads_add_idle et autres).

(Notez que je pose la question pas pour défoncer QT mais parce que j'aurais un cours à donner dans quelques temps ou j'ai un passage GTK vs QT et globalement c'est un point ou c'est pas encore super clair pour moi, à force j'utilise les deux dans mes codes, mais sans trop voir de grandes différences fondamentale).

**vectra** · 17/05/2021, 16h45

Le multithread tu as vite fait d'y venir. Et c'est notamment là que le framework commence à bien s'illustrer.

L'intérêt de signal/slot également, c'est de pouvoir définir des signaux à émettre sans se préoccuper de qui va les recevoir, ce qui casse le besoin de double inclusion entre émetteur et récepteur.
Le récepteur associe un émetteur et un signal à un slot, mais l'émetteur s'en balec d'où ça va.

Après, ça fait très longtemps que je n'ai pas touché de callbacks.

La syntaxe simplifiée avec les lambda, c'est juste pour ne pas faire de clutter de déclarations/définitions dans des cas triviaux. Tu peux aussi définir directement des slots sans les déclarer si leur nom est on_nomduwidget_nomdusignal.

**Nilsou** · 17/05/2021, 16h58

Envoyé par vectra

L'intérêt de signal/slot également, c'est de pouvoir définir des signaux à émettre sans se préoccuper de qui va les recevoir, ce qui casse le besoin de double inclusion entre émetteur et récepteur.
Le récepteur associe un émetteur et un signal à un slot, mais l'émetteur s'en balec d'où ça va.

Après, ça fait très longtemps que je n'ai pas touché de callbacks.

C'est à dire qu'avec les callback c'est l'inverse. C'est le receveur qui s'en balec de qui l’appelle il me semble. Mais au final dans les deux cas il faut que tu appelle ton connect ou ton g_signal_connect après que les deux objets soient créés. Je ne me souviens pas de « double inclusions » avec le système de callback

**vectra** · 17/05/2021, 17h02

Après, ça fait très longtemps que je n'ai pas touché de callbacks. (bis)

Sinon, tu peux aussi chercher les bonnes raisons pour lesquelles Qt supplante GTK en tant que framework multi-plateforme.
Il risque d'y en avoir quelques unes.

Perso j'ai trouvé que le code callback devenait très très vite dégueulasse, mais encore une fois ça remonte à loin.

**Cwningen** · 17/05/2021, 18h40

Callback et signaux/slots c'est le même pattern. Et pour les inclusions c'est pareil : au moment de l'ajout/connexion, il faut connaitre le signal ou la fonction ajoutant le callback (du module source) et le callback/slot à appeler (du module destination), mais ni la source ni la destination n'ont besoin de se connaitre.

**Nilsou** · 17/05/2021, 19h03

Envoyé par vectra

Sinon, tu peux aussi chercher les bonnes raisons pour lesquelles Qt supplante GTK en tant que framework multi-plateforme.
Il risque d'y en avoir quelques unes.

Oui, ça clairement, il y en a quelques unes (quoi que j'ai cru comprendre que le changement de stratégies financière de la part de QT remettait en question pas mal de choses de ce que j'ai compris ... ).

Envoyé par Cwningen

Callback et signaux/slots c'est le même pattern. Et pour les inclusions c'est pareil : au moment de l'ajout/connexion, il faut connaitre le signal ou la fonction ajoutant le callback (du module source) et le callback/slot à appeler (du module destination), mais ni la source ni la destination n'ont besoin de se connaitre.

Ok, merci pour la précision.
Mais du coups c'est pareil aussi sur les ajouts multiples. D’où vient le mythe récurrent que le système de QT propose ça ou les autres ne le peuvent pas ...

**Dross** · 17/05/2021, 20h15

Envoyé par Robix66

Question .Net : quelqu'un a un tuto à jour et compréhensible pour charger des dll en dehors de l'application base du programme ? Quand je cherche, ça tourne en boucle sur 2-3 solutions, mais impossible de les faire marcher (assembly ou une de ses dépendances non trouvée), et pas moyen d'avoir autre chose que "si si, utilise ça" sans autres explications.

C'est pour faire des plugins ?

Il y a quelques années je t'aurai dirigé vers le MAF, mais je vois que maintenant ils ont un nouveau truc dans .NET 5.

T'est dans quel framework de .NET, quel type d'app, c'est pour faire quoi ?

**vectra** · 17/05/2021, 20h30

Envoyé par Cwningen

Callback et signaux/slots c'est le même pattern. Et pour les inclusions c'est pareil : au moment de l'ajout/connexion, il faut connaitre le signal ou la fonction ajoutant le callback (du module source) et le callback/slot à appeler (du module destination), mais ni la source ni la destination n'ont besoin de se connaitre.

Dans la syntaxe par défaut, le récepteur précise l'instance qui émet le signal.
J'ai ptet raté un truc; dans ce cas je veux bien un coup de main.

- - - Mise à jour - - -

Envoyé par Nilsou

Ok, merci pour la précision.
Mais du coups c'est pareil aussi sur les ajouts multiples. D’où vient le mythe récurrent que le système de QT propose ça ou les autres ne le peuvent pas ...

Je ne sais pas qui dit cela.

Mais j'ai une autre question: ces callbacks, ils interviennent dans une hiérarchie de classes?
Tu peux dériver tes propres widgets en GTK? Parce que si ça n'était pas le cas, tu aurais ta réponse.

**Cwningen** · 17/05/2021, 20h50

Envoyé par vectra

Dans la syntaxe par défaut, le récepteur précise l'instance qui émet le signal.
J'ai ptet raté un truc; dans ce cas je veux bien un coup de main.

Style C

Code:

// Module A
struct A
{
	void add_foo_callback(void (*f)(void *), void *user);
};


// Module B
struct B
{
	void f();
};

// Module C
	A a;
	B b;
	a.add_foo_callback([](void *user) {
		B *b = static_cast<B *>(user);
		b->f();
	}, &b);

Style Qt

Code:

// Module A
class A: public QObject
{
	Q_OBJECT
signals:
	void foo();
};


// Module B
class B: public QObject
{
	Q_OBJECT
public:
	void f();
};


// Module C
	A a;
	B b;
	QObject::connect(&a, &A::foo, &b, &B:::f);

Dans les deux cas, seul le module C doit tout connaitre. Les modules A et B sont complètement indépendants.

**Robix66** · 17/05/2021, 20h58

Envoyé par Dross

C'est pour faire des plugins ?

Il y a quelques années je t'aurai dirigé vers le MAF, mais je vois que maintenant ils ont un nouveau truc dans .NET 5.

T'est dans quel framework de .NET, quel type d'app, c'est pour faire quoi ?

On n'es pas encore en .Net 5 (on y travaille, mais pas pour ce soft), là on est en 4.7.2.
Là notre client nous fournit des dll pour faire des calculs, et voudrait pouvoir les changer sans faire appel à nous quand ils veulent changer des trucs dedans.

J'ai vu plein de trucs pour créer un AppDomain avec une ApplicationBase différente, et charger les dll dedans, mais pas moyen de le faire marcher.

**vectra** · 17/05/2021, 21h01

Envoyé par Cwningen

Style C

Code:

// Module A
struct A
{
	void add_foo_callback(void (*f)(void *), void *user);
};


// Module B
struct B
{
	void f();
};

// Module C
	A a;
	B b;
	a.add_foo_callback([](void *user) {
		B *b = static_cast<B *>(user);
		b->f();
	}, &b);

Style Qt

Code:

// Module A
class A: public QObject
{
	Q_OBJECT
signals:
	void foo();
};


// Module B
class B: public QObject
{
	Q_OBJECT
public:
	void f();
};


// Module C
	A a;
	B b;
	QObject::connect(&a, &A::foo, &b, &B:::f);

Dans les deux cas, seul le module C doit tout connaitre. Les modules A et B sont complètement indépendants.

Au temps pour moi.

**Dross** · 17/05/2021, 21h05

Envoyé par Robix66

On n'es pas encore en .Net 5 (on y travaille, mais pas pour ce soft), là on est en 4.7.2.
Là notre client nous fournit des dll pour faire des calculs, et voudrait pouvoir les changer sans faire appel à nous quand ils veulent changer des trucs dedans.

J'ai vu plein de trucs pour créer un AppDomain avec une ApplicationBase différente, et charger les dll dedans, mais pas moyen de le faire marcher.

Les AppDomain c'est une des façons de faire, mais comme souvent dans .NET on a des outils plus haut niveau pour avoir moins de trucs à gérer, tu a notamment le MAF (cf mon lien) et pour ce besoin de chargement dynamique (donc pas le coté isolation mémoire) tu a aussi le MEF.

Ça fait longtemps que j'ai pas utilisé tout ça mais de mémoire MAF et MEF c'est plug&play. Perso dans ton cas je partirai sur le MEF, regarde l'exemple dans la doc il semble être bien fait.

**Robix66** · 17/05/2021, 21h13

Envoyé par Dross

Les AppDomain c'est une des façons de faire, mais comme souvent dans .NET on a des outils plus haut niveau pour avoir moins de trucs à gérer, tu a notamment le MAF (cf mon lien) et pour ce besoin de chargement dynamique (donc pas le coté isolation mémoire) tu a aussi le MEF.

Ça fait longtemps que j'ai pas utilisé tout ça mais de mémoire MAF et MEF c'est plug&play. Perso dans ton cas je partirai sur le MEF, regarde l'exemple dans la doc il semble être bien fait.

Merci, je regarderai ça.
En cherchant, je me suis dit plusieurs fois "de toutes façons, je tombe probablement sur des réponses qui correspondent à des vieilles méthodes", chose qui arrivent souvent en .Net, et que j'avais d'ailleurs expliqué à un de mes gars la semaine dernière.

**rOut** · 17/05/2021, 22h36

Bah Qt ou Gtk c'est la même chose niveau fonctionnalités hein. Gtk supporte tout autant les signaux asynchrones et boucle d'évènements, c'est juste la syntaxe qui change, avec plus de sucre pour Qt (gaffe à l'indigestion).

**Dross** · 17/05/2021, 22h46

Envoyé par Robix66

Merci, je regarderai ça.
En cherchant, je me suis dit plusieurs fois "de toutes façons, je tombe probablement sur des réponses qui correspondent à des vieilles méthodes", chose qui arrivent souvent en .Net, et que j'avais d'ailleurs expliqué à un de mes gars la semaine dernière.

Yup, après je te conseillerai vivement de tester tout ça sur un projet Proof-of-Concept tout beau tout propre pour tester la techno et bien la comprendre, et une fois que ça marche faire ton intégration dans ton outil de prod (y'a toujours des surprises).

**Robix66** · 18/05/2021, 12h56

Oh, j'y compte bien.

**Nilsou** · 18/05/2021, 13h26

Envoyé par vectra

Je ne sais pas qui dit cela.

Mais j'ai une autre question: ces callbacks, ils interviennent dans une hiérarchie de classes?
Tu peux dériver tes propres widgets en GTK? Parce que si ça n'était pas le cas, tu aurais ta réponse.

Il y a une encapsulation de gtk en C++ oui. C'est plus brut de décoffrage que QT mais ça fait le taf.

**deathdigger** · 18/05/2021, 13h57

Envoyé par Dross

Yup, après je te conseillerai vivement de tester tout ça sur un projet Proof-of-Concept tout beau tout propre pour tester la techno et bien la comprendre, et une fois que ça marche faire ton intégration dans ton outil de prod (y'a toujours des surprises).

Faut vérifier surtout ce qu'ils souhaitent faire.
Si le but est d'avoir des DLL qui évoluent indépendamment des projets qui les utilisent (faire des corrections, ajouter de nouvelles méthodes, etc.), ça ne vaut pas le coût de se prendre la tête. Ils te fournissent les DLL qui vont bien en s'assurant de ne pas supprimer les méthodes que t'appelles et voilà.

**Dross** · 18/05/2021, 18h40

Bah c'est justement pas le besoin de son client : "voudrait pouvoir les changer sans faire appel à nous". A partir de là, la compilation avec les liens en dur est à proscrire et mieux vaux passer par du chargement dynamique/etc.

**acdctabs** · 19/05/2021, 18h47

C'est marrant je me plaignais d'éclipse l'autre fois.
Pour faire court je récupère un projet en +, en php ce coup-ci, avec du symfony mais surtout on me file une licence PhpStorm. A moi la joie de développer dans le luxe !

**Captain_Cowkill** · 19/05/2021, 19h36

Dites les canards, c'est normal pour un noob comme moi de totalement galérer sur les objets/prototypes/héritage en JS ?

Je viens de passer le chapitre MDN sur les objets, et j'en ressors totalement paumé. J'y ai passé des heures mais j'ai l'impression d'être totalement à côté de la plaque (concernant l'héritage et les prototypes).

**Robix66** · 19/05/2021, 19h47

J'ai envie de dire oui, c'est des notions complexes à comprendre tant que tu n'as pas un vrai cas pour les appliquer. Et c'est pas l'objet Voiture qui hérite de Véhicule qui va beaucoup t'aider à les maitriser.

Discussion: Le topic de la programmation: Et envoyez des sioux!

Outils de la discussion

Règles de messages