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
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.
C'est la faute à Arteis
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.
Dernière modification par Kesitem ; 11/05/2021 à 09h56.
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 ?
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
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.
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).
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.
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
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.
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.
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 ... ).
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 ...
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 - - -
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.
Style C
Style QtCode:// 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);
Dans les deux cas, seul le module C doit tout connaitre. Les modules A et B sont complètement indépendants.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);
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.
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).
"Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."
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à.
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.
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 !
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).
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.